Laxcus大資料管理系統2.0（11）- 第九章 容錯

標籤：

第九章 容錯

　　在當前，由於叢集龐大的組織體系和複雜性，以及使用者普遍要求低成本硬體，使得叢集在運行過程中發生的錯誤機率，遠遠高於單一且效能穩定的小型機伺服器，並且叢集在運行過程中幾乎是不允許停止的，這就更需要提供比單機環境複雜得多的錯誤管理方案。實際上，我們在產品設計、開發、運營的各個階段，有相當大一部分精力，都是用來擷取各種故障，和解決各種故障發生後的錯誤處理問題。對於這些錯誤處理，我們整體遵循這樣一個思路來解決：首先由軟體感知來發現和定位故障點，然後進行判斷，如果屬於軟體可以解決的故障，那麼通過軟體自修複機制來完成，否則，這個錯誤就提交給叢集管理員人工處理。按照這樣的兩條錯誤處理基準，我們把各種錯誤處理分別融入到它們的模組中，並與這些模組嵌合，實現整個叢集的容錯管理。下面我們將從硬體和軟體兩個角度，來闡述Laxcus會面對的一些主要故障以及處理這些故障的辦法。

9.1 硬體容錯

　　在Laxcus叢集錯誤管理中，我們把運行環境或者硬體本身問題所造成、且不能通過軟體自行修複來解決的錯誤，統一稱為硬體錯誤。硬體錯誤的處理工作由叢集管理員來完成，軟體在這裡起發現和警示的作用。根據我們過往的一些經驗，本節就介紹一些經常發生的硬體故障和軟體感知它們的辦法。

9.1.1 網路故障

　　目前的網路故障由以下硬體組件造成：交換器、路由器、集線器、網線、接線頭、網卡。在這些故障中，其中一部分是可以人工方式修複的，比如接線頭鬆動、網卡接觸不良等。另一部分屬於硬體損壞，需要關閉裝置更換。軟體發現這些故障的辦法也很簡單，主要是通過網路握手來偵測發現，比如在軟體裡整合ICMP這樣的功能，在運行時去追蹤節點，發現可疑現象後，通過在本網段和外網段之間對比排查，可以很快判斷和定位故障點。這類故障檢查工作一般由管理節點來執行，其它類型的節點如果在運行過程中發現問題或者故障，也會主動提交給管理節點，供管理節點做進一步檢查核對。

9.1.2 電腦故障

　　電腦故障是由電腦內部組件失效引發的錯誤，這組件包括了主板、晶片、記憶體、網卡、硬碟、電源。根據我們過往的使用經驗，大部分電腦故障是由主板和硬碟導致，其中主板又佔了相當大部分。電腦故障通過內、外兩種手段來檢查發現。在內部，由節點自檢機制來探測組件，在外部，由管理節點來追蹤節點。無論誰先檢測得到，軟體感知之後，都會馬上提交給管理員處理。

9.1.3 硬碟故障

　　硬碟故障有三種情況：硬碟完全損壞（通常是引導區損壞導致）、扇區損壞、磁碟空間已滿。第一種情況通常在電腦啟動時發生，對於這種故障，最好的解決辦法是管理員在開機時跟蹤一下電腦的運行情況。第二種故障通常是節點讀寫資料過程中產生，這種情況軟體通過故障即時感知能夠馬上發現，會立即報告給管理員。第三種情況由寫入資料太多溢出導致，不是硬碟本身問題，這種情況也會被節點馬上捕捉到，然後去通知管理員。

9.2 節點容錯

　　本節點所說的“節點”，包含了軟體的”進程“和硬體的”電腦“兩個概念。這和之前所提略有不同，請諸位注意一下。在早期版本中，節點故障更多是軟體故障造成的，比如節點的運行管理機制處理不善，模組間的API介面協同、銜接的錯誤。這些問題都與詳細設計和編程有很大關係，隨著版本演化，現在越來越多的情況是硬體問題導致。在Laxcus叢集裡，由於Front節點歸使用者使用，而且功能簡單，實質只是一個用於輸入輸出的顯示終端，所以本節忽略它，將主要介紹叢集管理員管理下的節點容錯。

9.2.1 管理節點容錯

　　前面已經提到過，無論是主域叢集還是子域叢集，都只能有一個Master管理節點來負責所屬叢集的管理工作，它在自己叢集裡的地位是獨一無二的，是保證整個叢集正常啟動並執行關鍵。同時，為保證叢集不會因為Master節點故障造成叢集的管理混亂，通常還有一至數個Monitor管理節點做為備份存在著，它們將監視Master節點運行。

　　在我們的測試環境，有1個Master節點和2個Monitor節點。為檢查管理節點容錯能力，我們進行了這樣的實驗。我們使用Linux  kill命令殺掉一個Master節點進程，在第5秒鐘的時候，其中一個Monitor節點感知到Master節點發生了故障，並且立即啟動故障協商機制，詢問另一個Monitor節點，它對Master節點的判斷，雙方很快共同確認了Master節點發生了故障。然後，它們按照自己的網路地址排序，選擇數字最大的那個Monitor節點，成為新的Master節點。新Master節點立即將自己從Monitor狀態轉入Master狀態，並且通知原來所有下屬節點（包括另一個Monitor節點），讓它們重新註冊到新Master節點下面，同時將故障的Master節點和切換過程通知給Watch節點。整個容錯處理在20秒內完成。

 

圖9.2.1 管理節點容錯處理流程

9.2.2 Data節點容錯

　　Data節點儲存著叢集的全部資料，它的重要性僅次於管理節點，所以Data節點的容錯管理也與其它節點大不相同。上面已經介紹過，每個節點宕機都會被管理節點及時捕捉到。在Data節點宕機後，管理節點會在警示的同時，對Data節點的資料做出如下處理：取出這個Data節點的資料區塊編號，按照資料區塊編號，找到同源備份，產生一個新的備份到其它節點上，如果是Data主節點，其它從節點備份會恢複到一個新的主節點上，並且這些從塊也升級成主塊。如果是Data從節點，這些備份會從主節點產生備份，分發到其它從節點上。由於Data主節點的資料量一般都比較大（最多時候有幾個TB)，又要保證不能太過於佔用網路頻寬，實際上這個恢複備份過程是緩慢的。在這段時間裡，管理員有足夠的時間來檢查和恢複故障電腦。當重新啟動電腦後，它會在網路上進行主塊衝突檢查，避免同質資料區塊出現。尤其是主節點故障，在恢複完成前，存在著資料不全的可能性，這個時間內發生的更新/刪除操作，Call節點將拒絕它們執行，直到全部資料完成恢複。

 

 

圖9.2.2 Data節點容錯

9.2.3 叢集內其它節點容錯

　　相較於以上兩種，叢集內的其它節點不儲存資料，也不負責叢集管理工作，它們只是為了滿足分布處理流程而存在，運行過程中通常也不止一個節點，每類節點之間可以互相替代。這些單個節點的退出和加入，對於整個叢集的運行來說，只產生微小的影響。所以在Laxcus容錯設計裡，對這些節點的容錯管理要寬泛很多，它們的故障，通常都是以警示方式通知給Watch節點，由管理員來進行判斷和處理。它們缺失的工作，也會由管理節點通知其它同類節點來取代。

9.3 資料容錯

　　在我們統計的多組Laxcus叢集故障中，因為節點導致的故障機率並不高，大量發生的是資料錯誤。造成資料錯誤的主要原因是磁碟出現了壞區，這種故障通常在電腦讀寫磁碟資料被捕獲。處理資料錯誤的辦法是冗餘複製，由出現錯誤塊的Data節點使用自修複機制來實現。其過程是錯誤塊所屬Data節點通過網路去尋找其它Data節點上同編號的資料區塊，然後把正確的資料區塊下載下來，取代已經出現錯誤的資料區塊。在資料區塊複製過程中，這個表下面的全部資料區塊將被鎖定，直到完成更新後才被解鎖。錯誤的資料區塊將被Data節點標記起來，並且停止使用它。最後Data節點將資料區塊編號和自己的網路地址發送給Watch節點上，提供管理員注意已經發生了資料錯誤。

9.4 分布工作群組件容錯

　　現在的分布工作群組件故障基本都來源於使用者，是程式員在編程時處理不善導致。這樣的錯誤在程式員編程過程中，以及叢集測試環境裡都難以發現，只有在正式的運營環境才有可能發生。負責監管分布工作群組件錯誤的是沙箱，這是它在安全管理之外的另一個主要責任。為了防止故障擴散，沙箱將分布工作群組件錯誤限制在它自己的空間裡，不會波及節點和其它分布工作群組件。故障發生後，沙箱會立即卸載這個分布工作群組件，並且向源頭髮送一個錯誤碼和它的錯誤堆棧，同時也把這些資訊提交給管理員，由管理員去負責和使用者交涉。

9.5 管理員責任

　　雖然叢集提供了故障感知能力，也實現了一些錯誤自恢複處理，但是仍然有各種後期管理工作，需要管理員來執行才能解決。要完成這些工作，管理員應該具備一定的專業知識和職業責任。

　　對於很多因為軟體問題產生的故障，現在已經基本可以通過追蹤日誌和斷點分析得到；對於硬體故障，則更需要維護經驗和專業知識，這些都需要一定時間的工作積累，付出很多時間和學習為代價。實際上，根據我們的運營和管理叢集的經曆，隨著未來大資料超市需要的儲存量和計算量的增加，網路和叢集規模會越來越大。要做好叢集管理工作，不是一件輕鬆的事，叢集管理員要能夠瞭解叢集和各種節點的績效參數、執行處理範圍、故障特點和原因，並且能夠在發現問題後能夠很快解決問題，線上上和線下與各種人進行溝通和聯絡。這些要求，做為叢集管理員，需要有充分準備。

Laxcus大資料管理系統2.0（11）- 第九章 容錯