Nomad是一個功能強大、靈活的調度器，適用于長期運行的服務和批處理任務。通過廣泛的驅動程序，Nomad可以調度基于容器的工作負載、原始二進制文件、java應用程序等等。Nomad操作簡單，易伸縮，與HashiCorp Consul（服務注冊），Vault（證書管理）產品無縫集成。

Nomad為開發人員提供了自助服務基礎設施。Nomad任務使用高級聲明格式語法進行描述，該語法是版本控制的，并將基礎結構作為代碼進行推廣。一旦任務提交給Nomad，它就負責部署和確保服務的可用性。運行Nomad的好處之一是提高了計算基礎設施的可靠性和彈性。

歡迎來到我們關于用Nomad構建彈性基礎設施的系列文章，在這里我們將探討Nomad如何處理意外故障、停機和集群基礎設施的日常維護，通常不需要操作員干預。

在第一篇文章中，我們將了解Nomad如何自動重啟失敗和無響應的任務，以及如何將反復失敗的任務重新調度到其他節點。

Tasks and job 聲明

一個Nomad task是由其驅動程序在Nomad客戶端節點上執行的命令、服務、應用程序或其他工作負載。task可以是短時間的批處理作業（batch）或長時間運行的服務(service)，例如web應用程序、數據庫服務器或API。

Tasks是在用HCL語法的聲明性job規范中定義的。Job文件提交給Nomad服務端，服務端決定在何處以及如何將job文件中定義的task分配給客戶端節點。另一種概念化的理解是:job規范表示工作負載的期望狀態，Nomad服務端創建并維護其實際狀態。

job定義的層次是:job→group→task。每個job文件只有一個job，但是一個job可能有多個group，每個group可能有多個task。group包含一組要放在同一個節點上的task。

下面是一個定義Redis工作負載的簡單job文件:

job "example" {datacenters = ["dc1"]type = "service"constraint {attribute = "${attr.kernel.name}"value = "linux"}group "cache" {count = 1task "redis" {driver = "docker"config {image = "redis:3.2"}resources {cpu = 500 # 500 MHzmemory = 256 # 256MB}}} }

job作者可以為他們的工作負載定義約束和資源。約束（constraint）通過內核類型和版本等屬性限制了工作負載在節點上的位置。資源（resources）需求包括運行task所需的內存、網絡、CPU等。

有三種類型的job：system、service和batch，它們決定Nomad將用于此job中task的調度器。service 調度器被設計用來調度永遠不會宕機的長壽命服務。batch作業對短期性能波動的敏感性要小得多，壽命也很短，幾分鐘到幾天就可以完成。system調度器用于注冊應該在滿足作業約束的所有客戶端上運行的作業。當某個客戶端加入到集群或轉換到就緒狀態時也會調用它。

Nomad允許job作者為自動重新啟動失敗和無響應的任務指定策略，并自動將失敗的任務重新調度到其他節點，從而使任務工作負載具有彈性。

重啟失敗的任務

任務失敗可能發生在任務未能成功完成時，例如批處理（batch）類型作業或服務（service）由于致命錯誤或內存耗盡而失敗。

Nomad將根據job文件的restart節中的指令在同一個節點上重啟失敗的任務。attempts指定允許重啟的次數，delay指定Nomad在重啟任務之前應該等待多長時間，interval限制嘗試重新啟動到間隔時間的時間量。使用(fail)模式指定在給定間隔內的所有重啟嘗試都已耗盡之后，如果job沒有運行，Nomad應該做什么。

默認的失敗模式是fail，它告訴Nomad不要嘗試重啟job。這是對非冪等job的推薦值，這些job在幾次失敗后不太可能成功。另一個選項是delay，告訴Nomad在重啟作業之前等待interval指定的時間。

下面的restart節告訴Nomad在30分鐘內最多重啟2次，每次重啟之間延遲15秒，在2次重啟之后不要再嘗試重啟。這也是非批處理類型job的默認重啟策略。

group "cache" {...restart {attempts = 2interval = "30m"delay = "15s"mode = "fail"}task "redis" {...} }

這種本地重啟行為旨在使任務對bug、內存泄漏和其他臨時問題具有彈性。這類似于使用過程管理器，例如systemd、upstart或Nomad外部的runit。

重啟沒有響應的任務

另一個常見的場景是需要重啟一個任務，該任務還沒有失敗，但已經變得沒有響應或不健康。

Nomad將根據check_restart節中的指令重啟沒有響應的任務。這將與Consul健康檢查功能結合。當健康檢查失敗limit次時，Nomad將重啟任務。limit值為1表示在第一次失敗時重啟。默認值0則表示禁止基于健康檢查的重啟。

失敗必須是連續的。一次健康檢查將重置計數，因此在passing狀態和失敗狀態之間交替進行的服務可能不會重啟。使用grace指定重啟后恢復健康檢查的等待時間。設置 ignore_warnings = true 讓Nomad將警告狀態當作一個passing狀態，而不觸發重啟。

下面的check_restart策略告訴Nomad在其健康檢查連續失敗3次后重啟Redis任務，在重啟任務后等待90秒以恢復健康檢查，并在警告狀態下重啟(除了失敗之外)。

task "redis" {...service {check_restart {limit = 3grace = "90s"ignore_warnings = false}} }

在傳統的數據中心環境中，重啟失敗的任務通常由流程管理器（process supervisor）處理，該管理器需要由操作員配置。自動檢測和重新啟動不健康的任務更加復雜，需要定制腳本集成監控系統或操作員干預。而對于Nomad，它們會自動發生，不需要操作員干預。

重新調度失敗任務

在指定的重啟次數之后沒有成功運行的任務可能會失敗，原因是它們運行的節點出現了問題，例如硬件故障、內核死鎖或其他不可恢復的錯誤。

使用reschedule節，操作員告訴Nomad在什么情況下要將失敗的作業重新調度（reschedule）到另一個節點。

Nomad更喜歡重新調度到以前沒有用于此任務的節點。與restart節一樣，您可以使用attempts指定Nomad應該嘗試的重新調度的次數，delay指定Nomad應該在重新調度嘗試之間等待多長時間，interval指定重新調度嘗試限制的間隔時間。

另外，使用delay_function指定用于計算初始延遲后的后續重新調度嘗試的函數。選項有常數（constant）、指數（exponential）和斐波那契數（fibonacci）。對于service任務，斐波那契調度具有快速重新調度的特性，它可以在短時間內從中斷中恢復，同時減慢速度以避免在較長時間內中斷時出現中斷。當使用指數或斐波那契delay_function時，使用max_delay設置延遲時間的上限，在此之后延遲時間不會增加。將unlimited設置為true或false以允許無限制的重新調度嘗試。

要完全禁用重新調度，設置?attempts = 0?和 unlimited = false。

下面的reschedule?節告訴Nomad嘗試重新調度任務組無限次，并在隨后的嘗試之間以指數級增加延遲，開始延遲30秒，最多1小時。

group "cache" { ... reschedule { delay = "30s" delay_function = "exponential" max_delay = "1hr" unlimited = true } }

reschedule?節不適用于system作業，因為它們在每個節點上都運行。

從Nomad 0.8.4版本開始，reschedule?節在部署期間應用。

在傳統的數據中心中，節點故障將由監控系統檢測到，并觸發報警給操作員。然后操作人員需要手動進行干預，要么恢復失敗的節點，要么將工作負載遷移到另一個節點。有了重新調度功能，操作員可以為最常見的故障場景進行規劃，Nomad將自動響應，無需人工干預。Nomad應用了合理的默認值，這樣大多數用戶都可以在本地重新啟動和重新調度，而不必考慮各種重啟參數。

總結

在我們用Nomad構建彈性基礎架構系列的第一篇文章中，我們介紹了Nomad如何通過自動重新啟動和重新調度失敗和無響應的任務，為計算基礎架構提供彈性。

對于失敗的任務，操作員使用restart節指定Nomad的本地重啟策略。當與Consul和check_restart節一起使用時，Nomad將根據重啟參數在本地重啟無響應的任務。操作員通過reschedule 節指定Nomad重新調度失敗任務的策略。

在下一篇文章中，我們將討論Nomad客戶端如何通過驅動健康檢查和活躍的心跳來實現快速、準確的調度以及自我修復。

總結

以上是生活随笔為你收集整理的使用Nomad构建弹性基础架构：重新启动任务的全部內容，希望文章能夠幫你解決所遇到的問題。

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