序言

最近花了很多時間在分布式存儲上面，不想在這個上面再花費很多時間了，所以用這篇文章做一個最后的總結。

在面對分布式存儲的時候，分為兩種角度，一種是客戶側，一種是運維側，客戶是上帝，所以不談上帝的操作，專注于運維側的系統構建。

其實所有的系統構建，都應該分成兩個緯度，一個是客戶緯度，專注于客戶體驗，進行各種定制化輸出；一個是運維緯度，專注于底層的運維，各種監控數據，各種操作，都使用白屏的操作，而不是天天命令行操作，使用平臺層面，可以防止誤操作，系統扛了大部分的責任，也可以讓運維不用每天記憶那些傻逼命令，傻逼參數，減輕低等級的操作，讓大腦有更多的空間來想想其他的事情。。。例如，看看藍天白日黃昏。。。。

[[227132]]

分布式存儲運維系統構建

分布式的架構一般如下所示：

在分布式系統中，主要有幾個對象。

運維測對象：一個是master，控制節點對象，主要用來提供元數據的保存，統計相關的信息，對外提供統一的API；一個是chunkserver，工作節點對象，主要是用來存儲數據。

master涉及到動作有：查詢master節點，進行master節點切換，備份元數據，生成checkpoint文件用于恢復，生成操作日志用于同步，修改master啟動參數，重啟master進程。

chunkserver涉及到動作有：查詢chunkserver列表，顯示總的空間大小，剩余的空間大小，磁盤的狀態，進程狀態，修改chunkserver進程參數，重啟chunkserver進程，擴容，縮容。

客戶側對象：一個是目錄，一個是文件，在此主要涉及到的動作有，查看目錄，查看文件，查看分片數量，設置分片數量，檢查分片數量，處理分片異常，設置用戶的邏輯空間占用多少，物理空間占用多少，目錄文件遷移，設置回收策略，設置文件的replica數量。

以下為對動作的解釋，為什么需要這些動作：

1、 主節點為三個，主要是因為使用了paxos算法來進行選主操作，為什么要有一個主？提供服務的高可用，而使用三個節點，則是為了防止分區的情況出現。

2、 為什么要生成checkpoint文件，當master存儲了大量的元數據的時候，這些數據都放在磁盤上，如果服務器宕機，那么在啟動進程的時候，會將所有的數據都要加載進內存，時間上來說，是不可以接受的，從而定時生成checkpoint文件，便于宕機恢復，或者是進程掛了進行恢復。

3、 為什么要有操作日志，操作日志主要是在三個master節點上，都使用的是相同的一份數據，在master與其他的slave進行同步的時候，使用操作日志進行同步。

4、 為什么要有立刻生成chenckpoint文件和操作日志的動作，一般生成checkpoint都是定時生成的，當我要進行升級，或者修改參數的時候，需要保證數據的一致性，從而即可生成，在啟動的時候，減少啟動的時間。

5、 為什么要顯示chunkserver的磁盤空間，chunkserver主要是用來存儲的，那么必然要顯示磁盤的剩余空間和總的空間，這個也是分布式存儲的主要作用。

6、 修改chunkserver進程的參數是為了在重啟chunkserver進程的時候，無須去服務器上手動進行修改相關的參數。

7、 擴容縮容一鍵化操作，大大減少運維操作的復雜性。

8、 為什么要處理分片異常，在有些異常的情況下，分片有的時候少了，有的時候沒有，有的時候沒有達到期望值，從而需要對分片異常的情況進行處理，這個主要是為了保障數據安全。。。而在這個進行操作的時候，可以使用replica的自動刪除和添加機制，也就是修改一下文件的分片數量，從而也就會刪除老版本的分片，并且將分片數量達到自己期望的狀態。

9、 在分布式文件系統中，刪除數據是有策略的，一般會設置一個回收站，當刪除數據的時候，會將數據加入到回收站中，保留一天或者兩天時間，如果還沒有進行恢復，那么說明數據可以刪除，會有一個定時任務來定時清理這些數據，從而需要一個回收刪除的策略。

10、 設置文件的replica數量，這個是最基本的功能了，分布式存儲的可靠性和可用性的唯一保障就是分片數量，一般為三份。

如果說，你看了上面的那么多內容，還不能做出一個運維測的分布式運維系統，那我也就無話可說了，對象有了，動作有了，剩下的就是代碼了。。。

等風來。。。。

閑扯。。。

分布式存儲就像風一樣，你不知道花落誰家，你也可能找不到它到底存儲在哪個節點的哪個chunk上，。。。其實是可以找到的，哈哈

分布式系統用來保證數據的可靠性，分片是唯一手段，保存來保存去，其實還是保存在磁盤上，無論你怎么跑，你要么存儲在ssd磁盤上，要么存儲在sata磁盤上。

分布式存儲的可用性，無論怎么可用，最后都是使用linux系統中，無論怎么存儲，都是使用的操作系統提供的文件系統，所以不管你是不是分布式存儲，分布式文件，分布式表格，分布式鍵值，都存在于ext3？ext4文件系統中。。。。那么問題來了，在存儲的時候，都是先寫入內存，然后返回客戶端寫成功，如果。。。這個時候服務器宕機了，是不是就丟失數據了呢？？？

丟數據，有什么關系，但是，可以不丟么，可以的。。。只要禁用swap，禁用操作系統層面的緩存就可以了，損失了部分性能，換取了更強的可靠性。

在使用分布式存儲的時候，使用ssd，使用sata，可以優化么？那是必須可以的，在操作系統層面，總是存儲各種元數據，例如atime，diratime，但是在分布式系統中，可以不存儲已提高性能，在進行掛載的時候，加入這些參數就好了。。

這就是所謂的優化？？？是的，就那么幾個參數，也算是優化。。。你不能修改源碼進行適配，所以。。。加幾個參數就算是優化了，這個。。。算是一種搞笑的行為，不過。。很多人以為這種優化酷斃了。。。。淡然一笑。。。不語。。。

有的時候，感覺有的操作很酷，因為在構建一個運維平臺的時候，不僅僅有各種測試數據，各種TPS，各種QPS，各種http latency，還有。。。我做這個動作需要幾步。。。例如我擴容，點擊3次，輸入3次，就完成了一次擴容。。。可控的風險，可控的升級。。。。這種還是極好的。。。

沒有冪等性，如何做到唯一性？？？在使用分布式系統的時候，可能會經常碰到超時，那么這種超時，怎么辦？？？業務方面一般認為存儲系統是可靠的，返回成功就是成功，而返回失敗則是失敗，而沒有考慮到如果服務端處理成功，客戶端超時沒接受到響應，咋整。。。。業務序列號的唯一性，查詢此筆業務的序列號，然后查詢記錄，從而可以得到成功或者失敗，只能根據歷史情況查詢。。。

突然記起來了，在分布式存儲中，還有一個動作就是數據打散，也就是rebalance，這種操作感覺好高端，例如。。。在擴容的時候，新上線的機器需要遷移數據，例如，在使用DHT算法的時候，需要將相鄰的數據遷移到新上限的機器上，那么進行rebalance，如果此時數據量過大，可能會影響整體分布式存儲的IO能力，從而在進行rebalance的時候，需要手動進行操作，進行限流，也就是限制遷移的速度，可能是20M/S，也可能是100M.S，主要看你的帶寬來進行評估了。。。不要讓屁股決定腦袋。。。

突然記起來上次一個故障，客戶端寫存儲，寫不進去，業務報錯，查詢，發現客戶端響應碼，5XXX，內部錯誤，查詢日志，發現是，，，分區未找到。。。初步判斷為可能服務器宕機，不可能。。。進程重啟。。。不可能，都沒收到報警。。。那么就認定為是服務器內部進行了rebalance的操作。。。但是最后再一看，發現所有的rebalance都必須手動，自動進行rebalance的操作都已經關閉，然后查詢對應的時間點，發現。。。對應的chunkserver上面的進程進行了重啟。。。。然后再查為什么重啟，發現是進程使用的內存過大，而cgroup對這個進程使用的內存做了限制，從而把這個進程殺了，然后監控進程一看，這個傻逼掛了，然后又把它給啟動了，。。。裝作什么事都沒有發生。。。而就在一分鐘之內，啪啪啪，報錯報錯。。。。那么問題來了，啟動一個chunkserver進程需要一分鐘么。。。那么問題又來了，前端的nginx或者lvs發現了進程掛了15S，拉起來進程，假設是15S，那么檢查間隔15S，大于45S，再加上各種延時，考慮一下服務器的負載，差不多一分鐘。。。。那么這種問題。。。主管判斷？日志檢查？這種才是好玩的問題排查。。。。

JUST FUCK...............好了，這篇文章只花一個小時，浪費太多時間不好