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

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之間的網路流量不受影響。

 

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