作者簡介:

顧炯

中國電信浙江公司中國電信雲端計算實驗室、SDx聯合技術開放實驗室專家委員。作為第一完成人，多個專案獲得省部級和集團級科技進步獎。

上篇中我們講了關於分散式儲存的知識結構的前三部分內容，儲存型別、檔案系統、儲存介質等，可點選下面的連結檢視：

今天我們繼續來講講關於Raid和副本、分散式儲存的架構以及存在的問題和解決辦法，即下面四至七部分的內容：

一、儲存型別

二、檔案系統

三、儲存介質

四、Raid和副本

五、分散式儲存的架構

六、分散式儲存存在的問題

七、解決的方法

四、Raid和副本

把磁碟們相同偏移量的一塊空間橫向進行分割，組成一條邏輯上儲存空間。

資料是先寫滿一條條帶，再寫下一條條帶。一個卷可以有很多條條帶組成。條帶的劃分應該的磁碟配置初級就完成。條帶包含扇區（或塊）的個數叫條帶長度；每個磁碟內包含屬於這個條帶的扇區（或塊）的個數叫條帶深度。

為什麼要引入條帶的概念呢，是因為要解決單個磁碟一次只能同時併發一個IO和保證資料完整性。

圖14

我們知道磁碟的IO實際上是磁碟尋找對應扇區地址的過程，是在磁片旋轉和磁頭在機械臂的控制下橫向尋道的結果，而且一個磁碟一次只能完成一個IO申請，而通過條帶的方式可以讓多個磁碟一起協同完成任務，這種方法叫做raid0。

從理論上看磁碟越多，條帶深度越小，速度就越快。

但是也不是條帶深度越小速度就越快，因為深度太小，併發的概率就降低了。沒有了併發，就不會提高速度了。所以一般來說當隨機的小塊IO多，就適當加大條帶深度，當順序的大塊多，就減小條帶的深度。Raid0體現的是人多力量大的哲理。

但是如果raid0的方式下有一塊磁碟出現故障了，那資料的完整性被破壞了，資料不可用了。為了確保資料完整性，所以就有了raid1。

raid1就是將一份資料寫到2個物理磁碟上，即資料有映象，二資料副本。就算壞了一塊盤也不會導致資料不可用。和單塊盤比Raid1方式寫的慢，讀快，道理很明顯。

將raid0和raid1組合起來，就可以吸取各自的優點，但是要注意組合的順序，raid10比raid01冗餘度高、資料更安全，如圖：

圖15

當左邊的raid10系統有一塊故障，底層資料是做raid1映象的，資料的完整性沒有被破壞，還可以再壞一塊另外raid1組的一個磁碟。

而raid01，當底層的raid0組的磁碟壞掉一塊，整個raid0組資料就無效了，所有的IO都會到剩下的raid0組，並且如果再壞一塊盤，整個資料就無效了。

Raid5和raid6也是常用的raid方法。

• Raid5最少需要3塊盤，有1個數據副本和1個數據校驗；即最多可以壞1塊盤；
• Raid6最少需要4塊盤，有1個數據副本和2個數據校驗，即最多可以壞2塊盤。

這些資料副本和資料校驗都均勻的打散在磁碟中。Raid5和raid6的磁碟利用率最低為66.7%和50％，是兼顧利用率和效能的方案。Raid6的安全性比raid5更好，效能差別不大。

Raid都有一定的計算量，來決定這些資料塊存放的磁碟、計算出校驗資料，或根據校驗資料計算出資料。這些都需要CPU和記憶體資源。為了減少對主機CPU和記憶體的壓力。現在一般在主機的PCI總線上配置raid卡，硬碟都連線在raid卡下。

Raid 卡其實就是一臺小型的計算機，有CPU、記憶體和快取，減輕了主機的負擔。但是raid卡不能跨越主機，所以在分散式儲存中，網路raid就不能利用本地的raid卡，只能用主機的CPU和記憶體。

綜合各種因素，分散式儲存一般都採用副本的方法。

五、分散式儲存的架構

一般來說，分散式儲存不管是檔案儲存、物件儲存還是塊儲存的基本架構都是大同小異的。即客戶端或應用端、元資料（MDS）伺服器和資料節點伺服器。

圖16

客戶端和元資料伺服器之間互動是“信令互動”，而客戶端到資料節點是“媒體互動”。元資料伺服器或通過資料節點伺服器獲取各節點伺服器的基本配置情況和狀態資訊。

比如，客戶端需要讀取某一個檔案的資訊，客戶端會將相應的要求發給元資料伺服器：“喂！我需要XXX，存在哪裡了”，元資料伺服器查詢後回答“你到xxx伺服器的xxx地址+xxx伺服器的xxx地址取”。

客戶端拿到這個指示後，向這2臺伺服器發出指令，資料節點獲得指令後，將相應的資料返回給客戶端。

大家可能都會奇怪，為什麼塊儲存、物件和檔案的架構都是一樣的。有什麼區別呢？

我們在前面基礎知識講述中，塊儲存是一種裸裝置，它是將儲存裝置以“塊”的方式直接提供給客戶，由客戶自己的作業系統裡的檔案系統進行管理。

• 分散式塊儲存裡是沒有檔案系統的，是通過客戶端直接將最簡單明瞭的命令傳遞給儲存的“塊”來執行。
• 物件儲存和檔案儲存雖然結構類似，但並不將儲存底層的“塊”直接提供出來，而是通過隱藏著一個檔案系統，包裝成為“檔案”或“物件”提供出來。

這些儲存“不挑”作業系統或終端，最終執行命令的是儲存裡面的檔案系統操控儲存執行的，所以共享性很好。

檔案儲存通過“目錄+檔名+偏移量”來檢索，檔案間有目錄層次的；

而物件儲存採用“唯一物件ID+偏移量”來檢索，物件扁平儲存的，是沒有層次的。而且塊、物件、檔案儲存是可以相互轉換的，這個問題以後單獨講。

華為的FusionStorage是一個典型的“塊”儲存，我們來了解一下結構。

圖17

FusionStorage也分成了MDC、OSD和Client三部分。和其他分散式儲存重大的差別是:

MDC是記錄、更新OSD伺服器、磁碟等的狀態，並把這些狀態資料實時同步給Vbs，由Vbs計算出來資料所落的位置。MDC可以單獨部署，也可以集中部署，也可以分佈部署。

如果MDC全出現故障，並不會影響儲存的正常執行。

但是如果在MDC故障期間OSD的狀態發生了改變，比如某塊磁碟故障，就會導致部分IO訪問不正常。所以一般MDC部署在3臺OSD上，確保安全。

一般分散式儲存的MDC採用的是資料庫或記憶體儲資料庫來記錄資料塊和物理位置關係。客戶端向MDC發出詢問位置的請求，MDC查詢資料庫後返回請求資料的儲存位置。

這種方法儲存訪問的速度較慢，而且MDC作為交通的“樞紐”，絕對是整個儲存的核心，當MDC發生故障，會導致整個儲存都不能使用。但是採取這個方式，也有好處，比如可以根據不同需求設定不同的副本策略等。

VBS是計算資料塊儲存位置的重要網元。一個VBS就是一個“機頭”。VBS部署很靈活，有很多種部署方法，可以根據不同的需求進行選擇。

比如，在VMWARE虛擬機器中，可以在物理機上開設一臺虛擬機器部署VBS，在XEN/KVM部署在domain0上；或者部署在每臺OSD伺服器上，或專門設定VBS伺服器群。

圖18

VBS採取一致性雜湊演算法，如圖3，將資料塊的邏輯地址計算出KEY值。並將計算出來的KEY對映到雜湊環上，在雜湊環上劃分了N段（Partition），每個Partition對應一個硬碟，並根據出partition主和osd節點的對映關係ioview，和partitio主備對應的osd關係，得到該資料塊的路由，如圖4。

在寫入的時候，採用強一致性，即當主和備副本都返回寫成功後，才認為這個IO寫成功了。讀IO時只讀主副本，當主副本故障的時候，會在備副本中選舉出主副本。目前，一個資源池可以支援2000塊硬碟。

圖19

作業系統看到的連續的資料邏輯地址（LBA），實際上被打散到資源池內所有硬碟上了，類似所有硬碟都做了raid0，這樣就利用了所有磁碟的效能，提高了儲存的效能。

作業系統實際是直接讀寫物理磁碟的塊，並沒有封裝額外的檔案系統，是一個raw裝置。

OSD是一臺插了較多硬碟的X86伺服器，我們採用的是12塊SATA 3T的硬碟作為資料的持久化儲存介質。

如果VBS不承載在OSD上，那麼OSD伺服器的計算壓力實際上很小，也沒有必要配置計算能力很強、記憶體配置很高的伺服器。

上一篇文章計算過，12塊SATA盤提供的iops或吞吐量其實很有限，需要配置SSD作為快取，加速儲存的效能。由此看來，分散式儲存的效能是由SSD的效能和熱點資料計算演算法決定的。

和一般儲存不同，一般分散式儲存的寫效能會好於讀效能。主要是主和備副本寫入SSD就返回成功了，而SSD什麼時候寫入硬碟，怎麼寫入硬碟，客戶端是不知道的。

而讀資料的時候，如果資料是熱點資料，已經在快取在SSD上，效能會很好，如果沒有在快取中，就需要到硬碟中直接讀取，那效能就很差了。

這也是當分散式儲存在初始化的時候，測試效能指標不如執行一段時間後的指標。所以測試分散式儲存有很多陷阱，大家要注意。

為了提高儲存的安全性，達到6個9以上的安全性，我們採取的是通行的3副本（2副本在96塊盤以下，可以達到6個9）。副本可以根據實際情況設定成為在不同機架、不同伺服器、不同硬碟的安全級別。

當磁碟或主機故障，會被MDC監控到，會選舉主副本、踢出故障點、重構副本等操作。為了確保資料的安全，副本重構的時間很關鍵，我們要求，每T資料重構時間不超過30分鐘。

為了確保資料重構流量不影響正常儲存IO訪問流量，實現快速資料重構。我們沒有采取華為推薦的網路方案，而是採用環形虛擬化堆疊的方案，交換機間的堆疊鏈路採用40G光路,如圖5。

將儲存的重構流量都壓制在儲存環形網路中。交換機到伺服器採用2*10G連線，可以根據情況採用主備或分擔的模式。

圖20

說過了“塊”儲存，再簡單瞭解一下“物件儲存”。

物件儲存是在同樣容量下提供的儲存效能比檔案儲存更好，又能像檔案儲存一樣有很好的共享性。實際使用中，效能不是物件儲存最關注的問題，需要高效能可以用塊儲存，容量才是物件儲存最關注的問題。

所以物件儲存的持久化層的硬碟數量更多，單盤的容量也更大。物件儲存的資料的安全性保障也各式各樣，可以是單機raid或網路raid，也可以副本。

對效能要求不高，可以直接用普通磁碟，或利用raid卡的快取，也可以配些SSD作為快取。我們現在使用單機35塊7200轉4T SATA盤+raid卡快取加速的自研物件儲存，並計劃在今年使用60塊7200轉8T SATA盤。即每臺伺服器提供480T的裸容量。

Ceph和google基於GFS的儲存就是典型的物件儲存。

Ceph是目前最為熱門的儲存，可以支援多種介面。Ceph儲存的架構和華為的FusionStorage異曲同工，都是靠“算”而不是“查”。

• 一種是為數眾多的、負責完成資料儲存和維護功能的OSD。
• 另一種則是若干個負責完成系統狀態檢測和維護的monitor。

OSD和monitor之間相互傳輸節點狀態資訊，共同得出系統的總體工作狀態，並形成一個全域性系統狀態記錄資料結構，即所謂的cluster map。這個資料結構與特定演算法相配合，便實現了Ceph“無需查表，算算就好”的核心機制以及若干優秀特性。

圖21

但資料的的組織方法是不同的。首先ceph的核心是一個物件儲存，是以物件為最小組織單位。

1、首先檔案是被對映成為一個或多個物件。

2、然後每個物件再被對映到PG（Placement Group）上，PG和物件之間是“一對多”對映關係。

3、而PG會對映到n個OSD上，n就是副本數，OSD和PG是“多對多”的關係。

由若干個monitor共同負責整個Ceph叢集中所有OSD狀態的發現與記錄，並且共同形成cluster map的master版本，然後擴散至全體OSD以及客戶端。

OSD使用cluster map進行資料的維護，而客戶端使用cluster map進行資料的定址。

Google三大寶之一的“GFS”是google物件儲存的基礎。

圖22

核心不同是資料的組織架構：master伺服器（即元資料伺服器）儲存了檔名和塊的名字空間、從檔案到塊的對映、副本位置，由客戶端來查詢。是一個典型的信令和媒體分開的架構。

六、分散式儲存存在的問題

分散式儲存一般情況下都是靠“副本”來確保資料的安全性和完整性。每塊盤記錄的資料內容都不一樣，當某一塊盤出現問題，都需要從其他不同盤內的資料塊中進行快速的資料重構。

資料重構是需要時間的，如果大量盤同時故障，將會發生什麼？另外，OSD的擴容，也會導致資料的遷移，也會影響儲存。

分散式儲存一般都採用副本的方式來確保資料的安全性。寫入磁碟前不需要進行額外複雜的計算，就可以將資料寫入磁碟，是最快速的方式。是一種空間換時間的方法，即想得到較好的儲存效能，就採用副本的方式。

當有副本出現丟失的情況，系統就會啟動資料重構。一般情況下，用於生產的分散式儲存採用的是3副本。副本一般放置在不同機架、不同伺服器主機的硬碟上。3副本就是放置在3臺不同的伺服器的硬碟上。

而每個使用者的資料是由很多個副本均勻的分佈在儲存資源池內的所有主機上的。所以，可以認為任意一臺伺服器會儲存著所有使用者資料的某些資料副本，一臺伺服器出現故障，會影響所有使用者。

從理論上來說，副本方式可以允許n-1臺的伺服器出現故障，n是副本數。比如3副本，不管這個分散式儲存資源池內有幾臺伺服器組成，就只能允許2臺伺服器出現故障。2臺伺服器出現故障，其實這個儲存就很危險了。

當資料的持久化層OSD出現故障的時候，必須啟動副本的恢復工作，即要在短時間內恢復完整的副本數。不同儲存的結構、演算法不同恢復的時間長短也不一樣。

但從副本恢復所使用到的磁碟、網路等基礎裝置是一樣的。今天我們從基礎角度上來分析，看看副本的恢復到底需要多少時間和當新增加OSD節點需要多長時間，並看看因為採用了X86伺服器帶來的隱患。

我們在實驗室內做了實驗，具體瞭解一下：

試驗環境：2臺萬兆交換機、4臺X86伺服器（12塊3T 7200轉 SATA盤+1塊1.2G PCIeSSD）。包括所有副本在內，每塊磁碟有1T資料，共有48T資料。

實驗一:無IO情況在，拔出一個磁碟

實驗二:在儲存上建立了4個360G的虛擬卷，載入少量的IO，即8K隨機讀寫，佇列深度為1，總iops為2600左右。

在拔出一個磁碟後，在15分鐘後（可配，延遲15分鐘是為了防止無操作、無報警等），系統開始對缺失的副本進行重構，得出結果：

圖23（為了便於計算1T=1000G）

分析：

在實驗分散式儲存中，原來共有資料48塊1T資料，拔出1塊磁碟資料重構完成後，還是48T資料，即每塊盤增加了(1T/47)1000=21.28GB的資料。

• 在無IO情況下12分鐘內重構了1T的資料：

網路速度：(11000 )/(1260)=1.39GB/s*8=11Gb/s，也就是說在無IO的情況下，網路的總的流量是11Gb/s。其中3臺伺服器網路速度是2.84Gb/s，1臺被拔出硬碟的伺服器流量是2.57Gb/s。為了計算方便，平均每臺伺服器為2.75Gb/s，網路利用率是27.5%。

磁碟寫入速度：21.281000/(1260)=29.56MB/s。

• 在少量IO情況下24分鐘內重構了1T的資料：

網路速度：(11000 )/(2460)=1.39GB/s*8=5.5Gb/s，也就是少量IO的情況下，網路的總的流量是5.5Gb/s。

平均每臺伺服器為是1.38Gb/s。

磁碟寫入速度：21.281000/(2460)=15MB/s。

實驗現象：

1、無流量壓力情況下資料重構速度即每塊盤最大寫速度為30MB/s。但隨著IO的增加，寫的速度也會越來越慢。

2、雖然每個伺服器接入網路是10Gb/s，但受到儲存軟體的控制，重構時最大網路利用率近30%。

在有IO的情況下，重構時間迅速增加。主要是為了不影響正常IO的處理，軟體對副本重構的速度進行了控制。

在實際生產中，用於副本重構的網路利用率控制在5%以下，對儲存正常的IO不會產生影響。

由此計算:

29.56M/(27.5%/5%)=5.37M，即在10G接入網路下，每臺伺服器重構流量在0.5Gb/s（ 62.5MB/s）和每塊磁碟讀寫資料在5MB/s以下，資料重構是安全的。

副本恢復的過程，實際上是從現有的磁碟中讀取需要重構的副本，再根據一定的規則寫入某些磁碟的過程。每塊盤承擔了讀取副本，也承擔了寫入副本的職責。也就是說平均每塊磁碟讀2.5M，寫也是2.5M。

從這個角度上看，每臺伺服器配置12塊硬碟（60MB/s）是能產生讀寫能力和網路（ 62.5MB/s）能力匹配。伺服器接入頻寬越大，可以配置的硬碟數量就越大。

小結：

1、如果主機和磁碟比大於等於12：

1TB資料重構時間=10008/（0.25n）      n: 伺服器數量

比如 57臺12塊磁碟的2P資源池重構1T資料的最短時間=（10008）/(0.2557)=560秒。

2、如果主機和磁碟比小於12:

1TB資料重構時間=10001000/（2.5m）   m：參與重構磁碟數量

如果1臺12塊盤的伺服器故障，最大重構36T資料，需要最短時間是342分鐘，5.7小時。

結論：伺服器或參與重構的磁碟數量越多，重構的速度就越快

我們繼續實驗，在資料重構完成後，重新插入這塊盤，我們會發現，副本又開始重構了，但這次資料是搬家，並不生成新的副本。是因為系統認為插入了新盤，資料需要均衡導致的。

分散式儲存採用的是“共產主義”，擴容伺服器的數量可以線性的增加儲存的能力，但新擴容的磁碟並不是只接受新的副本資料，而是需要搬遷寫入平均值大小的“老”副本資料。

實際上每次非正常IO的副本的寫入，都伴隨著其他節點副本的刪除。頻繁的寫入、刪除對磁碟的壽命有較大的影響。

我們再看看實驗結果：

圖24

在無io時，磁碟寫入的速度是68MB/s，68MB/s其實也已經達到SATA磁碟平均寫入速度的最大值的正常範圍。這樣，平均每臺伺服器網路中平均貢獻68*8/4=136Mb/s流量。

資料副本的搬遷是一個動態過程。磁盤裡的資料副本一定有1/3的資料是主副本，可能會被正常的IO讀取到，所以新加入的磁碟也不是全力進行資料搬遷，也和其他磁碟一樣，只能用有限的能力應付副本遷移。

測試結果上看，在少量IO業務下測試磁碟寫速度為45MB/s, 平均每臺伺服器網路中平均貢獻90Mb/s。在無IO的情況下，資料完成重新部署居然需要4.3小時了。

大家一定沒有想到吧，因為這次是47塊盤共1T的資料搬到1塊磁碟上，就像47個人喂1個人吃飯，飯總得一口一口吃，所以增加磁碟的時候，在大部分情況下和網路的速度無關，和磁碟寫入的速度直接相關。

上面提過，為了不讓副本遷移不影響正常IO，每臺伺服器可以提供主機網路的5%的頻寬，即62.5MB/s，磁碟讀寫為5MB/s來處理副本的遷移。

3、如果主機和磁碟比大於等於12：

一起重構的磁碟數量=62.5*n/m  n：伺服器的數量 m:磁碟寫入速度

4、如果主機和磁碟比小於12：

一起重構的磁碟數量=5*n/m  n:磁碟的數量  m:磁碟寫入速度

如果m=5M，n= 57， 可以一起寫入磁碟=712塊

1-712塊磁碟，1T資料遷移完成最長需要55.56個小時。可以這樣認為，在目前2PB容量的分散式儲存，在不影響業務情況下，如果擴容在2PB以下，資料副本遷移1TB需要56個小時。

大家一直在問我，分散式儲存的風險在哪裡。風險就是因為多副本特性所引起的。

首先不管這個叢集有多大，最多可以有n-1臺伺服器出現故障。一般是3副本，就是允許有2臺服務出現故障。

當出現故障的時候，就進行了資料重構，重構副本的時間相對較短，在2P的儲存，每T資料恢復需要10分鐘，恢復時間是以小時計。但是2臺伺服器同時出現故障，本身存在的風險就很大了，應儘量避免。

當故障的伺服器恢復了，重新加入儲存資源池，副本就需要遷移，那恢復的時間需要用天計算。所以當儲存的OSD出現故障到完全恢復的時間很長。但在正常情況下，還是能接受的。

但非正常情況呢？怎麼會出現非正常情況呢？

因為分散式儲存常用的是X86伺服器，x86伺服器是有正常使用週期，大約是5年。同一批次的伺服器的壽命是差不多的，在使用壽命的末期，伺服器出現故障的概率是很大的。

1臺伺服器發生故障，副本重構，可能會是最後一根稻草，導致伺服器群的“老太太們”壓力發生變化，也出現故障。

一旦發生2臺以上的同時故障，儲存就會出現嚴重故障，儲存就只能停止服務，運氣好可以離線恢復資料，運氣不好，副本完全丟失，資料完全不可用了。

大家知道，在資源池裡，儲存一旦停止服務，整個資源池就癱瘓了。這種情況一定會發生，只是早晚的問題，所以要提前干預，不能讓這樣的事情發生。

七、解決的辦法

於是定期更換伺服器，別讓伺服器變成“老太太”，不斷補充新鮮血液。但是，更換伺服器和擴容不一樣，擴容的時候可以一下子增加幾十臺伺服器，用個2天時間就可以靜悄悄的完成擴容。

更換伺服器的過程是先將伺服器退出服務，再增加伺服器的過程。原來伺服器上有多少資料，就需要搬遷多少資料，比如原來伺服器每塊有2T資料了，就需要搬遷12*2T的資料。為了確保儲存的正常使用，最好只能同時退出n-2臺伺服器，並增加相應的伺服器。

比如3副本，就只能先退出1臺伺服器，再增加1臺伺服器。換1臺伺服器需要2*2=4天時間。最多同時換2臺，但風險很大，萬一更換的過程中出現1臺故障，那這個儲存系統就掛了。

所以一臺一臺更替是最妥當的方法，57臺伺服器全部替換完成，不停的幹，順利的話，也需要大半年時間，算上節假日1年可能都做不完。這個過程漫長而複雜，充滿的變數，卻一定是可行的。

當然劃小分散式儲存的故障域，在一個故障域的伺服器減少，對應替代伺服器的工作時間相應減少了，風險也相應減小。但是分散式儲存是雲端計算快速發展後對儲存效能、容量帶來新需求發展起來的。

幾百臺伺服器共享一個儲存，執行幾千、上萬臺虛擬機器，從這個角度考慮，分散式塊儲存最好是一個可以無限線性擴容的儲存系統。但是就是因為有了上面的問題，只能將儲存資源池劃分成為一個一個較小的故障域。

這個故障域的大小我們認為在裸容量在2P（有效容量666T）、IOPS在100萬次以上是可以滿足資源池的需要，即在60臺伺服器左右。

分散式塊儲存實際上是來替代所謂高階FCSAN儲存的。小叢集替代低端小容量的FCSAN在價格上、效能上都沒有優勢。

如果只是伺服器出故障，而磁碟是正常的，還有一種比較快速的人工介入辦法。這個辦法是一種應急方案的延伸。實現的原理就是利用檢測到磁碟故障後15分鐘後才啟動副本的重建。

如果15分鐘內磁碟又恢復了，那在故障時間內原來需要寫入的副本是需要追溯的。也就是說在這15分鐘內，其實有些副本只寫了2個，還有一個1副本原來要寫到這個磁碟中的。

如果15分鐘內原磁碟恢復了，就將增量資料補充進去，如果15分鐘不恢復，就進行副本重構。當然這個時間長短是可以配置，但不是所有的分散式儲存系統都有這個功能。

不少儲存系統一檢測到磁碟或伺服器不線上，就會立即啟動副本重構，本質上就是沒有“追溯”。知道這個原理了，下面的事情就簡單了。

發現整臺伺服器發生故障後，將伺服器設定成為“維護/更換”模式，就不受15分鐘的限制了（可能需要新開發這模式）。準備好裝了系統的伺服器（不插入持久化層的磁碟），當主機發生故障或更換的時候，人工將故障伺服器裡的磁碟插入備用伺服器裡，加入儲存系統中，提供服務。

這個伺服器，在寫入新資料的同時，還要追溯故障時間段的資料。

這種方法是應急方案的延伸，可以快速解決非磁碟故障的情況，但並不根本解決問題。因為如果這插拔磁碟的過程中，如果有一塊盤損壞了，又回到以前資料搬遷慢的問題上了。而且只換主機，不換磁碟，老化問題還是存在，還是不能高枕無憂。

全SSD分散式儲存的擁護者會興奮了，因為用全SSD的好像可以提高速度，加快這個過程。用全SSD的同時，最好也提高伺服器接入的頻寬，比如用40G網絡卡或用IB網路，不要讓網路成為新的瓶頸，但分散式儲存帶來的隱患不可能根除，只是快了，問題還是一樣。

其實還有一個比較嚴重的老化問題——作為快取的SSD。SSD作為整個儲存“效能擔當”在儲存中起到核心作用。但SSD的寫壽命是一個突出問題，怎麼樣線上更換SSD也是一個需要解決的問題。

分散式“塊”儲存存在這樣的風險，伺服器載入更多磁碟的物件儲存和檔案儲存類似的問題更突出，風險更大。

儲存內的資料一定要有價值，因為儲存他們的代價很大。但是現在儲存的使用是一種多多益善的觀念，只管寫，不管刪，不管什麼需求都往塊儲存裡寫等等。儲存按需選擇型別和容量是目前儲存使用中遇到的最普遍問題，這個問題將來詳談。

分散式儲存當下不存在風險，而遠期的風險巨大！

文章出處：高效運維