这是 使用Nomad构建弹性基础架构 系列文章的第二篇。在本系列中，我们将探讨Nomad如何处理意外故障、停机和集群基础设施的常规维护，通常不需要操作员干预。
在这篇文章中，我们将会看到Nomad客户端如何通过驱动健康检查和心跳来实现快速、准确的调度以及自我修复。
Nomad 客户端代理
Nomad代理是一个长期运行的进程，运行在属于Nomad集群的每台机器上。代理的行为取决于它是在client模式还是server模式下运行。客户端负责运行任务，而服务端负责管理集群。每个集群通常有3或5个服务器节点代理，可能有数千个客户端。
client模式代理的主要目的是运行docker容器等用户工作负载。为了实现这一点，客户端将对其环境进行采集，以确定主机的功能和资源，并确定可用的驱动程序。完成后，客户端向服务器注册，并定期与服务器进行登记，以便提供节点信息、心跳活性，并运行分配给它们的任何任务。
调度
调度是Nomad服务端的核心功能之一。它是将job的任务分配给客户端的过程。此过程必须遵守job文件中声明的约束，并优化资源利用率。
您将从本系列的第1部分中回忆到，job是任务的声明性描述，包括任务的约束和所需的资源。job由用户提交，并表示所需的状态。job中任务组到客户端的映射是使用分配完成的。分配声明job中的一组任务应该在特定节点上运行。调度是确定适当分配的过程，是评估的一部分。
当job创建、更新或节点失败时，将创建评估。
作为Nomad服务端的一部分，调度器负责处理评估和生成分配计划。Nomad中有三种调度器类型，每一种都针对特定的工作负载类型进行了优化:service、batch和system。
首先，调度器将所需的状态(由job文件指示)与集群的实际状态进行协调，以确定必须执行的操作。可能需要进行新的分配。现有的分配可能需要更新、迁移或停止。
分配被分成两个不同的阶段:可行性检查和排名。在第一阶段，调度器通过过滤不健康的节点、缺少必要的驱动程序和没有达到指定的作业约束的节点来找到可行的节点。这就是Nomad使用Nomad客户端提供的节点指纹和驱动信息的地方。
第二阶段是排名，调度程序对可用节点进行打分，以找到最合适的节点。打分是基于装箱和反亲和性(不鼓励任务组的多个实例共存)的组合，它优化了密度，同时减少了相关故障的可能性。在Nomad 0.9.0，下一个主要版本中，打分还将考虑用户指定的亲和性和反亲和性。
在传统的数据中心环境中，在哪里以及如何放置工作负载通常是需要操作员进行决策和干预的手工操作。使用Nomad，调度决策是自动的，并针对所需的工作负载、集群的当前状态和功能进行了优化。
根据驱动程序健康检查限制job位置
Nomad客户端使用任务驱动来执行任务并提供资源隔离。Nomad提供了一组可扩展的任务驱动程序，以支持跨所有主要操作系统的大量工作负载。任务驱动程序的配置选项、可用于的环境以及可用的资源隔离机制各不相同。
Nomad中的任务驱动类型有:Docker、独立的fork/exec、Java、LXC、Qemu、raw fork/exec、Rkt以及用Go编写的自定义驱动(Nomad 0.9.0中即将出现的可插拔驱动系统)。
在Nomad 0.8中引入的驱动程序健康检查功能，使Nomad能够根据驱动程序健康状态和将驱动程序健康状态显示给操作员来限制分配。对于支持健康检查的任务驱动程序，Nomad将排除将任务分配给那些报告为不健康的驱动程序的节点。
从丢失的客户端节点中恢复
当Nomad客户端运行时，它与服务端一起执行心跳以保持活力。如果心跳失败，Nomad服务端假定客户端节点已经失败，并且停止分配新任务并开始创建替代分配。要区分网络故障和Nomad代理崩溃是不可能的，因此这两种情况的处理是相同的。一旦网络恢复或崩溃的代理重启，节点状态将被更新，正常操作将恢复。
限制基于驱动程序健康状况的job放置、自动检测失败的客户节点和相应的重新定位job是Nomad的两个自修复特性，无需额外的监视、脚本编写或其他操作员干预。
总结
在关于使用Nomad构建弹性基础架构的系列文章(第1部分)的第二篇文章中，我们介绍了Nomad客户机-服务器代理如何通过驱动健康检查和活力心跳实现快速、准确的调度以及自愈。
Nomad客户端代理负责确定主机的资源和功能，包括哪些驱动程序可用，以及运行任务。Nomad服务端代理负责维护集群状态和调度任务。客户端和服务端代理协同工作，以支持快速、准确的调度以及自修复操作，例如自动重新调度失败节点上的任务，并将失败驱动程序的节点标记为不适合接收需要这些驱动程序的任务。
在下一篇文章中，我们将了解Nomad如何帮助操作人员管理job生命周期:更新、滚动部署(包括金丝雀和蓝绿部署)，以及迁移任务(作为客户端节点退役的一部分)。