这是"用Nomad构建弹性基础设施"系列文章的第四篇，也是最后一篇文章（第1部分，第2部分，第3部分）。在本系列中，我们将探讨Nomad如何处理意外的故障、停机和集群基础设施的日常维护，而通常不需要操作员干预。在这篇文章中，我们将探讨Nomad的Raft共识算法的设计和使用如何为数据丢失提供弹性，以及如何从中断中恢复。我们将假设一个生产部署，建议最少使用3到5个Nomad服务器。有关在生产中部署Nomad集群的信息，请参阅引导Nomad集群。在本系列的第2篇文章中，您会记得Nomad集群是由运行Nomad代理的节点组成的，无论是在服务器模式还是在客户机模式下。客户机负责运行任务，而服务器负责管理群集。客户机节点占集群的大部分，并且非常轻量级，因为它们与服务器节点交互，并且维护自己的很少状态。每个集群通常有3到5个服务器模式代理和数千个客户机。Nomad将基础设施建模为区域和数据中心。区域可能包含多个数据中心。例如，"美国"地区可能有一个"美国西部"和"美国东部"数据中心。Nomad服务器管理状态并为分配给它们的区域做出调度决策。»游牧者和木筏Nomad使用基于Raft算法的共识协议来提供区域内服务器节点之间的数据一致性。Raft节点总是处于以下三种状态之一：跟随者、候选者或领导者。所有节点最初都是作为跟随者开始的。在这种状态下，节点可以接受来自领导者的日志条目并进行投票。如果一段时间内没有收到任何条目，则节点会自我提升到候选状态。在候选状态下，节点向其对等方请求投票。如果一个候选人获得多数票，那么他就被提升为领导人。领导者必须接受新的日志条目并复制到所有其他关注者基于Raft的一致性在大多数节点可用的情况下是容错的。否则，将无法处理日志条目或有关对等成员身份的原因。例如，一个由3个节点组成的Raft集群可以容忍1个节点故障，因为剩下的2个服务器构成了多数仲裁。由5个节点组成的群集可以容忍2个节点故障等。建议的配置是每个区域运行3个或5个Nomad服务器。这在不牺牲性能的情况下最大限度地提高了可用性。下面的部署表总结了潜在的集群大小选项和每个选项的容错能力。服务器仲裁大小失效容限110220三214三15三264274三Nomad的容错性意味着您可能会遇到两种类型的停机：一个区域内少数服务器的故障，不会导致仲裁损失一个区域内大多数服务器发生故障，导致仲裁丢失每个场景都有不同的恢复过程。»从少数服务器的故障中恢复（不丢失仲裁）Nomad使用Raft意味着少数服务器的故障对客户端是透明的。群集操作将正常继续，作业在客户端节点上运行，服务器继续计划作业并监视群集。但是，为了在服务器节点进一步发生故障时防止数据丢失，应该通过修复或更换发生故障的服务器并将它们重新连接到群集来将群集恢复到完全健康状态。这需要操作员干预，但过程相当简单。对于每个出现故障的服务器，首先尝试使发生故障的服务器重新联机，并使用与以前相同的IP地址重新加入群集。如果需要重建新服务器以替换发生故障的服务器，请使用与故障服务器相同的IP地址将新服务器加入群集。一旦所有失败的服务器重新加入，这两个选项都将使群集恢复到完全正常的状态。如果重建的服务器不能具有与其替换的服务器相同的IP地址，则需要从群集中删除发生故障的服务器。这种死服务器清理作为自动驾驶仪的一部分自动进行。操作员还可以使用nomad server force leave命令手动删除服务器。如果该命令无法删除服务器，请使用nomad operator raft remove peer命令动态删除过时的对等服务器，而不需要停机。»从大多数服务器的故障中恢复（失去仲裁）在一个区域内大多数服务器发生故障的情况下，quorum将丢失，从而导致控制平面级别的完全中断，并且可能会丢失一些数据。幸运的是，可以使用剩余服务器上的数据进行部分恢复。这需要操作员干预。另外，需要注意的是，Nomad服务器宕机并不一定意味着工作负载已经停止。如果Nomad客户机及其主机可以运行，那么当Nomad服务器没有仲裁时，工作负载将继续运行。简单地说，恢复过程包括停止所有剩余的服务器，创建一个raft/peers.json所有剩余服务器的条目，然后重新启动它们。集群应该能够在剩余的服务器都用相同的raft重新启动之后选出一个领导者/peers.json配置。您稍后引入的任何新服务器，例如恢复多数仲裁，都可以使用完全干净的数据目录刷新，并使用Nomad的server join命令加入。在极端情况下，应该可以只使用一个剩余的服务器进行恢复，方法是将该服务器作为筏中唯一的对等服务器启动/peers.json恢复文件。但是，使用木筏/peers.jsonfor recovery可能会导致未提交的Raft日志条目隐式提交，因此只有在没有其他选项可用于恢复丢失的服务器的中断之后才应使用此方法。确保你没有任何自动化的进程，将定期把对等文件放在适当的地方。有关从任一类型的中断中恢复的完整详细信息，请参阅停机恢复。»停机和区域在某些情况下，为了可用性或可伸缩性，您可以选择运行多个区域。Nomad支持将多个区域联合到一个集群中。一个地区通常映射到一个大的地理区域，例如美国或欧洲，可能有多个区域，这些区域映射到美国西部和美国东部等数据中心。属于同一个数据中心的节点应该并置（它们应该共享一个本地局域网连接）。区域是调度边界。他们彼此完全独立，不共享工作、客户或国家。它们通过广域网上的八卦协议松散耦合，允许用户向任何区域提交作业或透明地查询任何区域的状态。请求被转发到适当区域的服务器进行处理并返回结果。数据不会在区域之间复制。这使得区域可以成为防止其他区域故障的"散装头"。客户机被配置为与其区域服务器通信，并使用远程过程调用（RPC）进行通信，以注册自己、发送心跳信号以获得活跃度、等待新的分配以及更新分配的状态。由于Nomad的两层方法，如果您在一个数据中心内失去多个Nomad服务器，您可能不会遇到仲裁损失，因为同一区域内其他数据中心中的服务器参与Raft协商一致意见将计入仲裁。如果您在一个区域内丢失了少数Nomad服务器，那么您的集群就不会出现宕机，也不必进行任何数据恢复。使用上面提到的过程将您的集群恢复到完全健康状态，并在我们的停机指南中详细介绍。如果一个区域内的大多数服务器节点发生故障，那么在控制平面级别上将会丢失仲裁和完全中断，并且可能会丢失有关在该区域中运行的作业的一些数据。集群中的其他区域不会受到停机的影响。在其他区域运行的作业将继续运行，即使它们是通过受影响区域中的Nomad服务器提交的。在受影响的区域中，只要Nomad客户机及其主机正常运行，工作负载就会继续运行。上面和我们的停机指南中简要解释了这种情况下的恢复过程。一旦您恢复了故障服务器并恢复了群集运行状况，Nomad将意识到所有仍在运行的作业并协调状态。»摘要在本系列关于使用Nomad构建弹性基础设施的第四篇也是最后一篇文章（第1部分，第2部分，第3部分），我们介绍了Nomad的基础设施模型和Raft共识算法的使用如何提供针对数据丢失的弹性以及如何从中断中恢复。Nomad旨在优雅地处理客户机和服务器的瞬时和永久性故障，使其易于运行高度可靠的基础设施。