Cloudflare分散式系統中的拜占庭式失敗與Raft選舉問題 - cloudflare

banq發表於2020-11-29
Cloud分散式Raft

當我們在Cloudflare審查設計文件時，我們總是在尋找單點故障（SPOF）。消除這些問題是構建您有信心的系統的必要步驟。具有諷刺意味的是，當您設計具有內建冗餘的系統時，您會花費大量時間來考慮冗餘失敗時系統的功能執行是否正常。
2020年11月2日，Cloudflare發生了一個事件，該事件在6小時33分鐘內影響了API和儀表板的可用性。在此事件期間，對我們的API的查詢成功率定期下降至75％，並且儀表板體驗比正常情況下慢80倍之多。儘管Cloudflare的優勢已在全球範圍內廣泛分佈（並且一直保持正常執行），但Cloudflare的控制平面（API和儀表板）由大量的在兩個區域冗餘的微服務組成。對於大多數服務，支援這些微服務的資料庫一次只能寫在一個區域中。
Cloudflare的每個控制平面資料中心都有多個伺服器機架。這些機架中的每個機架都具有兩個成對工作的開關-通常都處於活動狀態，但是如果一個發生故障，則另一個可以繼續處理負載。
Cloudflare透過在機架之間分佈最關鍵的服務來解決機架級故障。每個硬體都有兩個或多個電源不同的電源。每臺儲存關鍵資料的伺服器都使用RAID 10冗餘磁碟或儲存系統，它們可以在不同機架中的至少三臺計算機之間（或同時在這兩者之間）複製資料。我們需要審查和要求每一層都有冗餘。那麼-怎麼會出錯？
在這篇文章中，我們介紹了發生的事情的時間表，以及稱為拜占庭式故障的困難故障模式如何在一系列事件中發揮了作用。
 

2020-11-02 14:43 UTC：部分交換機故障
在時間14:43時，網路交換機開始行為異常。警報開始觸發有關ping無法到達的開關。裝置處於部分執行狀態：LACP和BGP等網路控制平面協議仍可執行，而vPC等其他協議則未執行。
vPC連結用於在多個交換機之間同步埠，以使它們在連線到與它們相連的伺服器時顯示為一臺大型聚合交換機。同時，資料平面（或轉發平面）未處理和轉發從連線的裝置收到的所有資料包。
由於LACP的負載平衡特性，每個伺服器只能看到部分流量問題，因此這種故障情況對於連線的節點是完全不可見的。如果交換機完全失敗，則所有流量都將故障轉移到對等交換機，因為連線的鏈路將完全斷開，並且埠將從轉發LACP捆綁包中退出。
六分鐘後，切換恢復，無需人工干預。但是這種奇特的故障模式導致了進一步的問題，這些問題在交換機恢復到正常操作後持續了很長時間。
 

2020-11-02 14:44 UTC：etcd錯誤開始
交換機行為異常的機架在我們的etcd叢集中包含一臺伺服器。每當我們需要在多個節點之間可靠的高度一致的資料儲存時，我們都會在核心資料中心大量使用etcd。
如果叢集領導者發生故障，etcd將使用RAFT協議保持一致性並建立共識以提升新領導者。在RAFT協議中，假定群整合員可用或不可用，並且僅提供準確的資訊或根本不提供任何資訊。當計算機崩潰時，這可以很好地工作，但並不總是能夠處理群集中不同成員具有衝突資訊的情況。
在這種特殊情況下：

  • 節點1（在受影響機架中）和節點3（領導者）之間的網路流量正在透過處於降級狀態的交換機傳送，
  • 節點1和節點2之間的網路流量正在透過其工作對等方，並且
  • 節點2和節點3之間的網路流量不受影響。

這導致叢集成員對現實存在衝突，這在分散式系統理論中被稱為拜占庭斷層。由於此衝突的資訊，節點1反覆發起了領導者選舉，為自己投票，而節點2反覆投票了仍可以連線到的節點3。這導致它繫結到了節點1無法訪問的領導者。
RAFT領導者的選舉具有破壞性，阻止所有寫入，直到它們被解決為止，因此這使群集變為只讀，直到故障交換機恢復並且節點1可以再次訪問節點3。

Cloudflare分散式系統中的拜占庭式失敗與Raft選舉問題 - cloudflare
 

.....
 
拜占庭容錯（BFT）是一個熱門的研究主題。解決方案自1982年以來就廣為人知，但是必須在各種工程設計之間做出選擇，包括安全性，效能和演算法簡單性。大多數通用叢集管理系統選擇完全放棄BFT，而使用基於PAXOS的協議，或者使用PAXOS的簡化版本（例如RAFT），其效能優於BFT共識協議。在許多情況下，已知一種易受罕見故障模式影響的簡單協議比難以正確實施或除錯的複雜協議更安全。
BFT共識的最初用途是在安全關鍵型系統中，例如飛機和航天器控制系統。這些系統通常具有嚴格的實時延遲約束，這些約束要求將共​​識與應用程式邏輯緊密耦合，從而使這些實現不適用於etcd等通用服務。關於BFT共識的當代研究主要集中在跨越信任邊界的應用程式上，這些應用程式需要防禦惡意叢集成員和故障叢集成員的攻擊。這些設計更適合於實現諸如etcd之類的通用服務，我們期待與研究人員和開源社群合作，使其適合生產叢集管理。
 
評論：
不能確定者就是拜占庭式失敗，但可能反映出Raft相對於傳統Paxos較差的活躍特性 
 
我確實認為拜占庭需要積極的不誠實行為，但是根據Wikipedia的定義，這是“向不同的觀察者呈現不同症狀的任何錯誤”。
 
人們通常將故障分為故障停止行為（例如崩潰）或拜占庭行為（其他所有因素）。
 
裂腦是拜占庭式攻擊。這是當您對一個方說一件事而對另一方說另一件事時。
 
prevote是一種（部分）改善Raft活躍性的方法。預設情況下，etcd可能沒有實現prevote。
 
早在2015年，我就用Raft強調了這些問題，但被告知我的示例場景是人為設計的，並且在現代資料中心中部分網路故障是不現實的。現在，這些人為造成的情況之一就是6個小時Cloudflare中斷的根源。
  
的確如此-太多的開發人員將這種“冗餘交換機架對”的思維模型作為魔術框圖元件。
 
這些年來，分散式計算的謬論仍然成立。結合從CAP中獲得的經驗教訓，忽略在“現代”環境中人為造成的和不可能的明顯問題永遠是不明智的。
 
區域性網路故障很少見，但可能會造成災難性的後果。我擔心它們在我們複雜的資料中心中會越來越普遍。基於超時的正確性和活躍性是一個令人擔憂的問題。
 
您可以透過多種方式使選舉成為非搶先。還需要確保客戶對可能失去與當前領導者聯絡的特定成員不粘接在一起。


 

相關文章