這是Nomad構建彈性基礎架構系列文章的第四篇也是最后一篇(第1部分，第2部分，第3部分)。在本系列文章中，我們將探討Nomad如何處理意外故障、停機和集群基礎設施的常規維護，通常不需要操作員干預。

在這篇文章中，我們將探索Nomad的設計和使用Raft一致性算法來提供數據丟失的彈性，以及如何從停機中恢復。

我們將假設一個生產部署，建議最少使用3或5個Nomad服務器。有關在生產中部署Nomad集群的信息，請參閱引導Nomad集群。

您可以從本系列的第2篇文章中回憶起，Nomad集群是由運行Nomad代理的節點組成的，可以是server模式，也可以是client模式。客戶端負責運行任務，而服務端負責管理集群。客戶端節點占集群的大部分，并且非常輕量級，因為它們與服務端節點交互，并且維護自己的狀態非常少。每個集群通常有3或5個sercer模式代理，而可能有數千個客戶端代理。

Nomad將基礎架構建模為區域（regions）和數據中心（datacenters）。一個區域可能包含多個數據中心。例如，“us”區域可能有一個“us-west”和“us-east”數據中心。Nomad服務端管理狀態，并為分配它們的區域做出調度決策。

Nomad 和 Raft

Nomad使用基于Raft算法的一致性協議，為一個區域內跨服務器的節點提供數據一致性。Raft節點總是處于以下三種狀態之一：follower、candidate或leader。所有節點一開始都是follower。在這種狀態下，節點可以接受來自leader的日志條目并進行投票。如果在一段時間內沒有收到條目，節點會自動提升到candidate狀態。在candidate狀態中，節點請求同伴的投票。如果一個candidate獲得多數選票，那么他就會被提升為leader。leader必須接受新的日志條目，并復制到所有其他candidate。

在大多數節點可用的情況下，基于Raft的共識是容錯的。否則，就不可能處理日志條目或考慮對等成員關系。

例如，由3個節點組成的Raft集群可以容忍1個節點故障，因為剩下的2個服務器構成了多數仲裁。一個由5個節點組成的集群可以容忍2個節點故障，等等。建議的配置是在每個區域運行3個或5個Nomad服務器。這可以在不犧牲性能的情況下最大化可用性。下面的部署表總結了可能的集群大小選項和每個選項的容錯。

服務器合法數容忍失敗

1	1	0
2	2	0
3	2	1
4	3	1
5	3	2
6	4	2
7	4	3

Nomad的容錯能力意味著您可能會遇到兩種類型的中斷:

• 區域內少數服務器的失敗，不會導致仲裁的損失
• 區域內大多數服務器的失敗，導致仲裁的損失

每個場景都有不同的恢復過程。

從少數服務器數量故障中恢復(不損失仲裁)

Nomad對Raft的使用意味著少數服務器的故障對客戶端來說是透明的。集群操作將繼續在客戶端正常運行，服務端將繼續調度作業并監視集群。

但是，為了防止在服務端節點出現進一步故障時數據丟失，應該通過修復或替換失敗的服務端并將它們重新連接到集群來恢復集群的完全健康。這需要操作員的干預，但過程相當簡單。

對于每個失敗的服務器，首先嘗試將失敗的服務器重新聯機，并讓它以與以前相同的IP地址重新加入集群。如果您需要重新構建一個新服務器來替換失敗的服務器，讓新服務器使用與失敗服務器相同的IP地址加入集群。一旦所有失敗的服務器重新連接，這兩種情況都將使集群恢復到完全健康的狀態。

如果重新構建的服務器不能具有與其正在替換的服務器相同的IP地址，則需要從集群中刪除失敗的服務器。自動駕駛儀的一部分會自動進行服務器清理。操作員還可以使用?nomad server force-leave命令手動刪除服務器。如果該命令無法刪除服務器，請使用nomad operator raft remove-peer?命令在沒有停機的情況下動態刪除陳舊的對等服務器。

從大多數服務器數量的失敗中恢復(仲裁損失)

如果一個區域內的大多數服務器出現故障，則會丟失仲裁，從而導致在控制平面上完全停機，可能還會丟失一些數據。幸運的是，可以使用剩余服務器上的數據進行部分恢復。這需要操作員的干預。另外，需要注意的是，Nomad服務器宕機并不一定意味著工作負載已經停止。如果Nomad客戶機及其主機處于運行狀態，工作負載將繼續運行，而只是Nomad服務器沒有仲裁。

簡單地說，恢復過程包括停止所有剩余的服務器，創建一個raft/peer.json中包含所有剩余服務器的條目，然后重啟它們。一旦其余的服務器都以相同的raft/peer.json配置重新啟動，集群應該能夠選舉一個leader。您稍后引入的任何新服務器，例如恢復多數仲裁，都可以使用完全干凈的數據目錄，并使用Nomad的server join?命令進行連接。

在極端的情況下，應該可以僅使用一個剩余的服務器進行恢復，方法是啟動該服務器，并將其本身作為raft/peer.json恢復文件中的唯一對等點。

然而,使用raft/peers.json用于恢復會導致未提交的Raft log條目被隱式提交，因此只有在宕機之后才應該使用它，因為沒有其他選項可用來恢復丟失的服務器。確保您沒有任何自動的進程，將對等文件放在適當的定期基礎上。

有關從任何類型的停機恢復的完整詳細信息，請參閱停機恢復。

停機和地區

在某些情況下，對于可用性或可伸縮性，您可以選擇運行多個區域。Nomad支持將多個區域聯合成一個集群。

一個區域通常映射到一個大的地理區域，例如美國或歐洲，可能有多個區域，這些區域映射到數據中心，如us-west和us-east。屬于相同數據中心的節點應該進行合并(它們應該共享本地LAN連接)。

區域是調度邊界。它們完全獨立于彼此，不共享工作、客戶或國家。它們使用WAN上的gossip協議松散耦合，該協議允許用戶向任何區域提交作業，或透明地查詢任何區域的狀態。請求被轉發到要處理的適當區域中的服務器，并返回結果。數據不會在區域之間復制。這允許區域作為“批量頭”，以應對其他區域的故障。

客戶機被配置為與其區域服務器通信，并使用遠程過程調用(RPC)進行通信，以注冊自己、發送心跳以獲取活性、等待新的分配以及更新分配狀態。

由于Nomad的兩層方法，如果您在一個數據中心中丟失了幾個Nomad服務器，那么您可能不會經歷仲裁的損失，因為在同一區域內的其他數據中心中的服務器都參與了Raft共識的計算。如果您在單個區域中丟失了少數的Nomad服務器，那么您的集群將不會出現停機，您也不必進行任何數據恢復。使用上面提到的過程并在我們的停用指南中詳細介紹，將集群恢復到完全健康狀態。

如果一個區域內的大多數服務器節點出現故障，那么在控制平面級別將會丟失仲裁和完全停機，并且可能會丟失關于該區域中運行的作業的數據。集群中的其他區域不會受到停機影響。在其他區域運行的作業將繼續運行，即使它們是通過受影響區域的Nomad服務器提交的。在受影響的區域，只要Nomad客戶機及其主機處于運行狀態，工作負載就會繼續運行。上面和我們的停用指南中簡要介紹了此場景的恢復過程。一旦您恢復了失敗的服務器并恢復了集群的健康狀態，Nomad就會意識到所有仍在運行和協調狀態的作業。

總結

在我們關于用Nomad構建彈性基礎架構的系列文章(第1部分，第2部分，第3部分)的第四篇也是最后一篇文章中，我們介紹了Nomad的基礎架構模型和Raft 一致性算法的使用如何提供數據丟失的彈性以及如何從停機中恢復。Nomad設計用于優雅地處理客戶端和服務器的臨時和永久故障，以便于運行高度可靠的基礎架構。

總結

以上是生活随笔為你收集整理的使用Nomad构建弹性基础架构: 容错和中断恢复的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。