|
本文主要討論如何在系統內部的邏輯處理上防止系統整體雪崩的發生。預防的重要性大于事故之后的處理，預測集群狀態、提前進行優化也成為預防雪崩的一個方向。 下面選取可能發生過的幾個場景與大家分享。
1. 跨機架副本選擇算法和機器資源、用戶邏輯隔離現場還原： 某天運維同學發現某集群幾十臺機器瞬間失聯，負責觸發修復副本的主控節點開始進行瘋狂的副本修復。大量用戶開始反饋集群變慢，讀寫夯住。 現場應對: 優先解決——副本修復量過大造成的集群整體受影響。 a. 處理的工程師當機立斷，gdb到進程更改修復副本的條件為副本<2，而非原本的3（replicas_num），讓主控節點這個時候僅修復副本數小于2個的文件，即保證未丟失的文件有至少一個冗余副本，防止只有一個副本的數據因可能再次發生的掛機造成文件丟失。 b. 緊急解決這批機器失聯問題，發現是交換機問題，a.b.c.d ip網段的c網段機器批量故障。催促網絡組盡快修復。 c. 副本修復到>=2之后，Gdb更改檢測副本不足周期，將幾十秒的檢測時間推遲到1天。等待網絡組解決交換機問題。 d. 網絡恢復，原有的機器重新加入集群。大量2副本文件重新變為3副本，部分3副本全丟失文件找回。 e. 恢復主控節點到正常參數設置狀態，系統開始正常修復。 改進措施: 在改進措施前，先分析下這次事件暴露的系統不足： 1) Master參數不支持熱修正，Gdb線上進程風險過大。 2) 一定數量但局域性的機器故障影響了整體集群（幾十臺相對一個大集群仍屬于局域性故障）。如上所述，月千分之幾的故障率總有機會讓你的存儲系統經歷一次交換機故障帶來的集群影響。 案例分析后的改進措施出爐： 1) Master支持熱修正功能排期提前，盡早支持核心參數的熱修改。 熱修改在上線后的效果可觀，后續規避過數次線上問題。 2) 在選擇數據副本存儲宿主機器的pickup算法中加入跨交換機（機架位）策略，強制——或者盡量保證——副本選擇時跨機架位。這種算法底下的副本，至少有1個副本與其他兩個副本處于不同的交換機下（IP a.b.c.d的c段）。 該措施同時作用于新的存儲數據副本選擇和副本缺失后的副本補全策略，能在副本宿主選擇上保證系統不會因為交換機的宕機而出現數據丟失，進而避免一直處于副本補全隊列/列表的大量的丟失副本節點加重主控節點負載。 3) 機器按region劃分隔離功能提上日程；用戶存儲位置按照region進行邏輯劃分功能提上日程；Pickup算法加入跨region提上日程。 a) 機器按照物理位置劃分region、用戶按照region進行邏輯存儲位置劃分，能讓集群在局部故障的情況下僅影響被邏輯劃分進使用這部分機器的用戶。 這樣一來，最壞情況無非是這個region不可用，導致擁有這個region讀寫權限的用戶受影響。Pickup算法跨region的設計進一步保證被劃分region的用戶不會因為一個region不可用而出現數據丟失，因為其他副本存到其他region上了。于是，核心交換機故障導致一個region數百臺機器的宕機也不會對集群造成范圍過大的影響了。 b) 增加region可信度概念，將機器的穩定性因素加入到副本冗余算法中。 當集群規模達到一定量后，會出現機器穩定性不同的問題（一般來說，同一批上線的機器穩定性一致）。通過標記region的穩定性，能強制在選擇數據副本的時候將至少一個副本至于穩定副本中，減少全部副本丟失的概率。 c) Region劃分需要綜合考慮用戶操作響應時間SLA、物理機器穩定情況、地理位置等信息。 合理的region劃分對提升系統穩定性、提升操作相應時間、預防系統崩潰都有益處。精巧的劃分規則會帶來整體的穩定性提升，但也增加了系統的復雜度。這塊如何取舍，留給讀者朋友深入思考了。 2. 讓集群流控起來流控方面有個通用且符合分布式存儲系統特點的原則：任何操作都不應占用過多的處理時間。這里的“任何操作”包含了在系統出現流量激增、局部達到一定數量的機器宕機時進行的操作。只有平滑且成功的處理這些操作，才能保證系統不因為異常而出現整體受影響，甚至雪崩。
現場還原： 1) 場景1 某天運維同學發現，集群寫操作在某段時間大增。通過觀察某個存儲節點，發現不僅是寫、而且是隨機寫！某些產品線的整體吞吐下降了。 2) 場景2 某集群存儲大戶需要進行業務調整，原有的數據做變更，大量數據需要刪除。 運維同學發現，a. 整個集群整體上處于瘋狂gc垃圾回收階段 b. 集群響應速度明顯變慢，特別是涉及到meta元信息更新的操作。 3) 場景3 某天運維同學突然發現集群并發量激增，單一用戶xyz進行了大量的并發操作，按照原有的用戶調研，該用戶不應該擁有如此規模的使用場景。 此類集群某些操作預期外的激增還有很多，不再累述。 現場應對: 1) 立刻電聯相關用戶，了解操作激增原因，不合理的激增需要立刻處理。 我們發現過如下不合理的激增： a. 場景1類：通過Review代碼發現，大量的操作進行了隨機讀寫更改。建議用戶將隨機讀寫轉換為讀取后更改+寫新文件+刪除舊文件，轉換隨機讀寫為順序讀寫。 b. 場景3類：某產品線在線上進行了性能測試。運維同學立刻通知該產品線停止了相關操作。所有公有集群再次發通過郵件強調，不可用于性能測試。如有需要，聯系相關人員在獨占集群進行性能場景測試。 2) 推動設計和實現集群各個環節的流控機制功能并上線。 改進措施： 1) 用戶操作流控 a. 對用戶操作進行流控限制可通過系統內部設計實現，也可通過外部的網絡限流等方式實現，對單用戶做一定的流控限制，防止單個用戶占用過多整個集群的資源。 b. 存儲節點操作流控可按照對集群的資源消耗高低分為High – Medium – Low三層，每層實現類似于搶token的設計，每層token數目在集群實踐后調整為比較適合的值。這樣能防止某類操作過多消耗集群負載。若某類操作過多消耗負載，其他操作類的請求有較大delay可能，繼而引發timeout后的重試、小范圍的崩潰，有一定幾率蔓延到整個集群并產生整體崩潰。 c. 垃圾回收gc單獨做流控處理。刪除操作在分布式存儲系統里面常用設計是：接收到用戶刪除操作時，標記刪除內容的meta信息，直接回返，后續進行策略控制，限流的刪除，防止大量的gc操作消耗過多單機存儲節點的磁盤處理能力。具體的限流策略和token值設置需要根據集群特點進行實踐并得出較優設置。 2) 流控黑名單用戶因為對線上做測試類的場景可以通過人為制度約束，但無法避免線上用戶bug導致效果等同于線上測試規模的場景。這類的場景一般在短時間內操作數嚴重超過限流上限。 對此類場景可進行流控黑名單設置，當某用戶短時間內（e.g. 1小時）嚴重超過設置的上限時，將該用戶加入黑名單，暫時阻塞操作。外圍的監控會通知運維組同學緊急處理。 3) 存儲節點并發修復、創建副本流控大量的數據副本修復操作或者副本創建操作如果不加以速度限制，將占用存儲節點的帶寬和CPU、內存等資源，影響正常的讀寫服務，出現大量的延遲。而大量的延遲可能引發重試，加重集群的繁忙程度。 同一個數據宿主進程需要限制并發副本修復、副本創建的個數，這樣對入口帶寬的占用不會過大，進程也不會因為過量進行這類操作而增加大量其他操作的延遲時間。這對于采用分發的副本復制協議的系統尤其重要。分發協議一般都有慢節點檢查機制，副本流控不會進一步加重系統延遲而增大成為慢節點的可能。如果慢節點可能性增大，新創建的文件可能在創建時就因為慢節點檢查機制而缺少副本，這會讓集群狀況更加惡化。
3. 提前預測、提前行動1) 預測磁盤故障，容錯單磁盤錯誤。 場景復現： 某廠商的SSD盤某批次存在問題，集群上線運行一段時間后，局部集中出現數量較多的壞盤，但并非所有的盤都損壞。當時并未有單磁盤容錯機制，一塊磁盤壞掉，整個機器就被置成不可用狀態，這樣導致擁有這批壞盤的機器都不可用，集群在一段時間內都處于副本修復狀態，吞吐受到較大影響。 改進措施: a) 對硬盤進行健康性預測，自動遷移大概率即將成為壞盤的數據副本近年來，對磁盤健康狀態進行提前預測的技術越來越成熟，技術上已可以預判磁盤健康程度并在磁盤擁有大概率壞掉前，自動遷移數據到其他磁盤，減少磁盤壞掉對系統穩定性的影響。 b) 對單硬盤錯誤進行容錯處理存儲節點支持對壞盤的異常處理。單盤掛掉時，自動遷移/修復單盤的原有數據到其他盤，而不是進程整體宕掉，因為一旦整體宕掉，其他盤的數據也會被分布式存儲系統當做缺失副本，存儲資源緊張的集群經歷一次這樣的宕機事件會造成長時間的副本修復過程。在現有的分布式存儲系統中, 也有類似淘寶TFS那樣，每個磁盤啟動一個進程進行管理，整機掛載多少個盤就啟動多少個進程。 根據現有存儲分布，預測均衡性發展，提前進行負載均衡操作。 這類的策略設計越來越常見。由于分布式存儲集群掛機后的修復策略使得集群某些機器總有幾率成為熱點機器，我們可以對此類的機器進行熱點預測，提前遷移部分數據到相對負載低的機器。 負載均衡策略和副本選擇策略一樣，需要取舍復雜度和優化程度問題。復雜的均衡策略帶來好的集群負載，但也因此引入高復雜度、高bug率問題。如何取舍，仍舊是個困擾分布式存儲系統設計者的難題。 |
- 關注天氣:
