我發現，在云架構或者Hadoop中，由于考慮到企業級SAS和SATA驅動器之間巨大的成本差距，沒有人會采用企業級SAS驅動器，大多數都使用了最廉價的硬件。
      讀取一個2TB驅動器的時間

                                
      下文中你將看到為什么這很重要的原因。現在，先看一看讀取驅動器上的數據需要的時間：

      占滿一個通道的驅動器數量
     
  了解占滿不同速度SONET通道所需的驅動器數量是很重要的。我在去掉TCP/IP和其他封包及重試延遲對通道的影響之后估計通道的性能，在以這樣的速度雙向運行于全雙工時通道的速率約為90%。

      顯然，占滿有故障的磁盤驅動器的網絡帶寬并不需要大量的驅動器。

   每年的磁盤驅動器故障
     
  磁盤驅動器故障公式分為兩個部分。第一個部分是基于硬錯誤率。如果你遷移111TB的數據，你可以假設一個磁盤無法讀取寫入到消費級SATA驅動器中的數據。企業級SATA驅動器的數量是1.1TB。另一個部分是年故障率（AFR）。這是每年故障驅動器占驅動器總量的比例，是驅動器廠商自己提供的一個估算值。應該注意的是，很少有驅動器廠商會提供消費級SATA驅動器的AFR數據。下表顯示的是使用2TB  SATA用于不同存儲的驅動器數量，以及每年故障驅動器的估算量。

      另一方面是基于BER的故障，因為這是基于數據遷移的，所以我再次選擇了一個保守的數量，并推測驅動器占全年總帶寬的5%。

         

      為了確定總故障數量，你需要向AFR數量中增加BER（5%）：

         

      如果你使用5%這個值并除以365，那么你將得出每天的故障數量：

         

      將總帶寬利用率小幅提高到7.5%的話，將得到每天每個存儲卷的故障數：

          

  遷移數據總量的故障
     
  下面得出的結論：當使用率為5%、存儲容量為10PB的時候，每天平均你會有15個消費級SATA驅動器發生故障。在最好情況下，你大約需要24390秒通過網絡進行讀取或者寫入每個驅動器。你最多可以獲得3.37個驅動器的全部帶寬，24小時獲得總共276 MB/s的帶寬。因此，簡單計算一下，276 MB/sec×3600×24得出每天的總MB/s。對于每個驅動器，你需要82 MB/s×24390×15個驅動器故障。以下是不同情況的計算結果：

      任何負數意味著驅動器復制的要求超過了通道帶寬。例如，在10PB、OC-48和5%驅動器使用率的情況下，帶寬相當于6167659 MB（這超過了通道帶寬）或者24小時內71 MB/s。顯然，隨著時間的推移，這個問題越來越明顯，因為你復制數據的速度還趕不上丟失的速度。從統計概率上說，如果你有10PB的話，最終你將丟掉數據，而且不會用太長時間。唯一的架構選擇就是保留數據的第三個副本，而這么做的成本很高。對于一個OC-48通道、使用率為5%的存儲系統來說，拐點發生在5 PB～10 PB之間，在5 PB、使用率為7.5%的情況下，你只有42 MB/s的多余帶寬（3652149，3600×24）。這時候就需要更高速的網絡（付出更多成本）或者更可靠的存儲（成本也不低）。
     
  我相信云公司每天都在權衡著這些成本因素，找出什么是優化成本的最佳方法。有沒有可能其中一些人并不了解基本的硬件問題？我當然希望不會是這種情況。顯然，云存儲適用于5PB、OC-48通達和消費級SATA存儲。現在，有多少云是超過這個存儲容量的？我不之道，但肯定是存在的，對于大型存儲用戶來說，多達10～20 PB的歸檔是很常見的。
     
  云架構要比本地存儲架構復雜得多。云存儲可以設計成一個RAID后端，消除了很多問題，但是我所了解的大多數云由于成本因素而沒有使用RAID。總的來說，云架構和云設計并不簡單，對于大型數據卷來說，我看不出云比本地存儲便宜多少。
     
  驅動器可靠性和帶寬將限制云的采用，而且這是一個可能永遠也得不到解決的問題。帶寬將越來越便宜，但是驅動器可靠性并沒有多大改善，數據的增長速度仍將超過帶寬。也許基于網絡的重復數據刪除功能會起到一些幫助作用——如果數據可以被重復數據刪除的話。但是就目前來看，對于非常大型的數據存儲來說，還沒有一個比老式數據中心更好的選擇。