Nomad是一个功能强大且灵活的调度程序，用于长时间运行的服务和批处理作业。通过广泛的驱动程序，Nomad可以调度基于容器的工作负载、原始二进制文件、java应用程序等等。Nomad易于操作和扩展，并与HashiCorp consur无缝集成，用于服务到服务通信，HashiCorp Vault用于机密管理。Nomad为开发人员提供自助式基础设施。Nomad作业使用高级声明性格式语法进行描述，该语法受版本控制，并将基础设施升级为代码。一旦作业提交给Nomad，它就负责部署和确保服务的可用性。运行Nomad的好处之一是提高计算基础设施的可靠性和弹性。欢迎来到我们关于使用Nomad构建弹性基础设施的系列文章，在这里我们将探讨Nomad如何处理意外故障、停机和集群基础设施的日常维护，而通常不需要操作员干预。在第一篇文章中，我们将了解Nomad如何自动重新启动失败和无响应的任务，以及将反复失败的任务重新调度到其他节点。»任务和工作声明Nomad任务是由其驱动程序在Nomad客户机节点上执行的命令、服务、应用程序或其他工作负载。任务可以是短期的批处理作业，也可以是长期运行的服务，如web应用程序、数据库服务器或API。任务在HCL语法中的声明性jobspec中定义。作业文件被提交到Nomad服务器，服务器决定将作业文件中定义的任务分配给客户机节点的位置和方式。另一种概念化的方法是：作业规范表示工作负载的期望状态，Nomad服务器创建并维护实际状态。作业的层次结构是：作业→组→任务。每个作业文件只有一个作业，但是一个作业可能有多个组，每个组可能有多个任务。组包含一组要在同一节点上共存的任务。下面是一个定义Redis工作负载的简化作业文件：工作"例子"{数据中心=dc1"]type="服务"约束{属性="${内核名称.attr}"value="linux"}组"缓存"{计数=1任务"redis"{driver="docker"配置{图像="redis:3.2版"}资源{cpu=500#500兆赫内存=256Ť256MB}}}}作业作者可以为其工作负载定义约束和资源。约束通过诸如内核类型和版本之类的属性限制工作负载在节点上的放置。资源需求包括任务运行所需的内存、网络、CPU等。作业有三种类型：系统、服务和批处理，这决定了Nomad将用于此作业中的任务的调度程序。服务调度器是为调度不应该停止的长寿命服务而设计的。批处理作业对短期性能波动的敏感性要低得多，而且生命周期短，只需几分钟到几天就可以完成。系统调度程序用于注册应在满足作业约束的所有客户端上运行的作业。当客户机加入集群或转换到就绪状态时，也会调用它Nomad允许作业作者指定自动重新启动失败和无响应任务的策略，以及自动将重复失败的任务重新调度到其他节点，从而使任务工作负载具有弹性。»重新启动失败的任务当任务无法成功完成时（如批处理类型的作业），或由于致命错误或内存不足而导致服务失败时，可能会发生任务失败。Nomad将根据作业文件的restart节中的指令在同一节点上重新启动失败的任务。运算符指定允许尝试重新启动的次数、Nomad在延迟重新启动任务之前应等待多长时间、将尝试的重新启动限制为具有间隔的时间量。使用（失败）模式指定如果作业在给定间隔内的所有重新启动尝试都已用尽后未运行，则Nomad应执行的操作。默认的故障模式是fail，它告诉Nomad不要尝试重新启动作业。这是非幂等作业的建议值，这些作业在几次失败后不太可能成功。另一个选项是delay，它告诉Nomad在重新启动作业之前等待interval指定的时间量。下面的重新启动节告诉Nomad在30分钟内尝试最多2次重新启动，每次重新启动之间延迟15秒，并且在这些重新启动用尽后不要再尝试重新启动。组"缓存"{...重新启动{尝试次数=2次间隔="30米"延迟="15秒"mode="失败"}任务"redis"{...}}这种本地重新启动行为旨在使任务能够抵御bug、内存泄漏和其他短暂的问题。这类似于在Nomad之外使用诸如systemd、upstart或runit之类的过程管理器。»重新启动无响应的任务另一种常见的情况是需要重新启动尚未失败但已变得无响应或不健康的任务。Nomad将根据check_restart节中的指令重新启动无响应的任务。这与领事健康检查一起工作。当健康检查失败时，Nomad将重新启动任务限制时间。值为1会导致第一次失败时重新启动。默认值0禁用基于运行状况检查的重新启动。失败必须是连续的。单次通过检查将重置计数，因此在通过和失败状态之间交替的服务可能不会重新启动。使用宽限期指定重新启动后恢复运行状况检查的等待时间。设置ignore_warnings=true可使Nomad将警告状态视为传递状态而不触发重新启动。以下check_restart策略告诉Nomad在Redis任务的运行状况检查连续3次失败后重新启动，在重新启动任务后等待90秒以恢复运行状况检查，并在出现警告状态（除了失败之外）时重新启动。任务"redis"{...服务{检查并重新启动{限制=3格蕾丝="90年代"ignore_warnings=错误}}}在传统的数据中心环境中，重新启动失败的任务通常由流程主管来处理，流程主管需要由操作员配置。自动检测和重新启动不正常的任务更为复杂，需要自定义脚本来集成监控系统或操作员干预。在Nomad中，它们自动发生，无需操作员干预。»重新安排失败的任务在指定的重新启动次数之后没有成功运行的任务可能会因为运行它们的节点出现问题而失败，例如硬件故障、内核死锁或其他不可恢复的错误。使用reschedule节，操作员告诉Nomad在什么情况下将失败的作业重新调度到另一个节点。Nomad倾向于重新调度以前不用于该任务的节点。与restart节一样，您可以指定Nomad应尝试尝试的重新计划尝试次数，Nomad在延迟的重新计划尝试之间应等待多长时间，以及将尝试的重新计划尝试限制为间隔的时间量。此外，请指定用于计算初始延迟后的后续重新调度尝试的函数。选项有常数、指数和斐波那契。对于服务作业，fibonacci调度有一个很好的特性：快速重新调度最初是为了从短时间的停机中恢复过来，而在较长的停机时间内则会减速以避免混乱。当使用指数或斐波那契延迟函数时，使用max_delay设置延迟时间的上限，在该上限之后它将不会增加。将unlimited设置为true或false可启用无限制的重新调度尝试。若要完全禁用重新计划，请将尝试次数设置为0，并将"无限制"设置为false。下面的重排节告诉Nomad尝试无限次地重新安排任务组，并以指数方式增加后续尝试之间的延迟，起始延迟为30秒，最长为1小时。组"缓存"{...重新安排{延迟="30秒"延迟函数="指数""最大延迟时间"无限=真}}重新调度节不适用于系统作业，因为它们在每个节点上运行。从Nomad版本0.8.4开始，重新调度节在部署期间适用。在传统的数据中心中，节点故障会被监控系统检测到并触发操作员警报。然后，操作员需要手动干预，要么恢复故障节点，要么将工作负载迁移到另一个节点。通过重新安排功能，操作员可以计划最常见的故障情况，Nomad将自动响应，避免手动干预的需要。Nomad应用了合理的默认值，这样大多数用户就可以在本地重新启动和重新调度，而不必考虑各种重启参数。»摘要在我们使用Nomad构建弹性基础设施系列的第一篇文章中，我们介绍了Nomad如何通过自动重启和重新安排失败和无响应任务来为计算基础设施提供弹性。运算符使用restart节为失败的任务指定Nomad的本地重新启动策略。当与consur和check_restart节一起使用时，Nomad将根据重新启动参数本地重新启动无响应的任务。操作员使用reschedule节指定Nomad重新调度失败任务的策略。在下一篇文章中，我们将了解Nomad客户端如何通过驾驶员健康检查和活跃的心跳来实现快速准确的调度以及自我修复。