Azure Batch 的可靠性

Azure Batch 在 Azure 中執行大規模平行運算及高性能運算（HPC）批次工作。 Batch 會建立和管理運算節點池，安裝你想執行的應用程式，並排程工作在節點上執行。

當您使用 Azure 時， 可靠性是共同的責任。 Microsoft 提供一系列功能以支援韌性與復原。 您有責任瞭解這些功能在您使用的所有服務中如何運作，並選取符合業務目標和正常運作時間目標所需的功能。

本文說明如何讓 Azure Batch 對暫時性故障、運算節點故障、可用性區域故障、整個區域的故障及服務維護具韌性。 同時也說明了生產部署建議、批次可靠性架構、備份與還原，以及關於 Azure Batch 服務層級協議（SLA）的關鍵資訊。

生產部署建議

對於生產工作負載，請遵循 Azure Batch 的最佳實務，包括以下可靠性建議：

  • 設計任務以容忍中斷與重複執行。 讓任務具有冪等性，為長時間執行的工作建立檢查點，並將必要的輸出與診斷資料保存到持久儲存。 更多資訊請參閱「 對瞬態故障的韌 性」及 「計算節點故障的韌性」。

  • 當節點故障後工作負載必須繼續時，使用多個運算節點。 個別運算節點並不保證會持續可用。 配置足夠的節點，讓剩餘可用的節點能執行重新排程的任務。

  • 支援時使用可用性區域配置。 當區域、虛擬機（VM）SKU 及工作負載設定支援時，設定可用性區域的放置。 健康區域的節點在區域中斷期間仍可執行任務，但應規劃容量減少，因為替代容量取決於健康區域的配額與虛擬機可用性。 欲了解更多資訊，請參閱 對於可用性區域失效的韌性。

  • 設計工作時動態指定集區，而非固定的集區 ID。 這種設計允許你在原本的資源池無法使用或無法擴展到所需容量時，將工作重新定位到健康的池子。 它能在集區維護或故障期間提升業務連續性。

  • 保持集區設定為最新狀態。 監視 Batch 支援的虛擬機映像與 SKU 的終止生命週期（EOL）日期，並在 EOL 前遷移集區。 請依照服務維護指引，保持 Batch 節點代理程式為最新狀態。

可靠性架構概觀

本節說明服務運作中從可靠性角度來看最為重要的部分。 本節介紹邏輯架構，包含你部署和使用的部分資源與功能。 它還討論了物理架構，其中提供了有關服務如何在幕後工作的詳細信息。

邏輯架構

Azure Batch 使用多種資源類型來執行批次工作負載。 這些資源的配置決定了你的工作負載對故障的反應。

所有批次處理和資源都綁定在批次 帳號上。 批次解決方案使用以下邏輯元件：

  • 批次帳戶： 一個區域資源，與池、工作、任務及其他批次資源相關聯。 你建立帳號並選取其區域、池分配模式和驗證設定。

  • 集區： 一組運算節點，任務可在其上執行。 池的設定定義了其虛擬機映像與大小、目標節點數量、擴展行為、網路配置及可用區放置。 你可以配置每個池子，以提供符合你的工作負載需求的容量、位置和運作環境。 目標節點數量即為請求容量，但因配額限制、容量限制或配置失敗，分配節點數量可能更少。

  • 工作與任務：工作會管理一組任務，並與一個集區相關聯。 任務會在運算節點上執行應用程式或腳本。 您定義工作、任務、約束條件、相依性、重試行為，以及各工作執行所在的集區。

  • 相關的儲存帳戶：一個 Azure 儲存體 帳號，你可以選擇性地連結到 Batch 帳號。 大多數批次解決方案會使用相關的儲存帳號來存放應用程式檔案、任務資源檔案、輸入資料和輸出資料。

    當你將儲存帳號連結到 Batch 帳號後，Batch 會稱它為 自動儲存帳號。 應用程式封裝需要自動儲存體帳戶，且該帳戶也可儲存任務資源檔案。

    批次解決方案的可靠性取決於其儲存資源。 當你建立儲存帳號時，你有責任選擇符合復原需求的儲存冗餘配置。 將任務輸出及其他耐用資料從運算節點移至儲存體中。 關於 Azure 儲存體 可靠性選項的資訊，請參見 Azure Blob 儲存體 中的可靠性。

更多資訊請參閱批次服務工作流程與資源，以及批次帳號和 Azure 儲存體 帳號。

實體架構

Azure Batch 有一個區域控制平面，負責處理針對批次帳號及其他批次資源（如池、工作和任務）的管理操作。 它和執行任務的運算節點是分開的。

Azure Batch 池使用 Azure 虛擬機器 和 虛擬機器擴展集. 運算節點是一種虛擬機，負責處理批次工作負載的一部分。 每個節點都屬於一個池，執行批次服務指派給它的任務。 批次節點代理在每個節點上運行，並提供節點與批次服務之間的指令與控制介面。 運算節點及其本地儲存是暫時性的。 當節點離開池時，其作業系統和檔案的變更都會遺失。

Batch 帳戶的池配置模式決定 Batch 建立計算及虛擬機相關資源的位置：

  • 批次服務池配置模式：Batch 會在 Batch 服務管理的 Azure 訂閱中分配資源。
  • 用戶訂閱池分配模式： 批次會直接在包含批次帳號的訂閱中建立資源。

實體架構的職責分配如下：

  • Microsoft：Microsoft 負責區域批次控制平面及服務基礎設施的運作。 Batch 會根據池組態與可用容量配置運算節點，排程任務，監控節點健康狀況，並在基礎設施故障後嘗試恢復節點。 批次處理可以將中斷的任務重新排隊，以便在其他可用節點執行。

  • 你： 你可以選擇虛擬機映像檔和大小、節點類型、目標節點數量、縮放設定、網路配置以及可用性區的配置。

    你還要負責維持足夠的容量以容忍節點故障、監控節點和任務狀態、使來賓作業系統和節點代理保持在最新狀態、設計可容忍重複執行的任務，以及將耐久性資料從計算節點移出。

批次節點恢復並不保證工作負載能持續不中斷。 欲了解更多資訊，請參閱「對計算節點故障的復原能力」。

對瞬態故障的彈性

暫時性錯誤是元件中的短暫間歇性失敗。 它們經常出現在雲端等分散式環境中，而且是作業的一般部分。 暫時性錯誤會在短時間內自行修正。 請務必確保您的應用程式能妥善處理暫時性錯誤，通常透過重試受影響的請求來進行。

所有雲端託管應用程式在與任何雲端託管的 API、資料庫及其他元件通訊時，都應遵循 Azure 暫態故障處理指引。 如需相關資訊，請參閱處理瞬態故障的建議。

在批次解決方案中，暫時性故障可能影響執行任務的應用程式與腳本，以及任何呼叫批次 API 來管理批次資源的應用程式。 批次在任務層級提供重試機制。 你負責設定任務約束、讓任務成為 等冪（可安全地執行多次且結果不變），以及設定呼叫批次服務及其他相依項目的重試行為。

任務重試與時間限制

設定 maxTaskRetryCount 以控制 Batch 在程序以非零退出碼退出後，重試任務的次數：

  • 預設值 0 表示 Batch 在非零退出碼後不會重試任務。
  • 正整數則設定了初次嘗試後的最大重試次數。
  • 值為 -1 允許無限次重試。 此數值不建議，因為持續失敗可能導致任務無限期執行。

設計每個任務都必須是冪等的，這樣重試就不會造成資料損壞或重複輸出。 對於長期執行的任務，可以使用檢查點功能，讓重試能從儲存的進度繼續進行。 欲了解更多資訊，請參閱 重試與重執行設計。

對某項任務或工作設定maxWallClockTime約束條件，以終止在容許時間內毫無進展的工作。 時間限制也限制了反覆失敗的影響。 選擇與工作負載復原目標相符的重試次數與時間限制。

任務相依關係中的暫態故障

作為批次任務執行的應用程式和腳本，通常會呼叫其他元件，例如 Azure 儲存體、資料庫或 API。 Batch 不會管理任務程式碼發送給這些相依性的個別要求。 可在任務程式碼中實作暫態錯誤處理，或使用相依軟體 SDK 提供的重試功能。 依照每個相依性的指引辨識可重試錯誤，選擇適當的退避與逾時設定，並遵循例如 Retry-After 標頭等重試指示。 僅重試可安全重複執行的操作。

若依賴性失敗導致任務程序以非零退出碼退出，Batch 可依照 maxTaskRetryCount 重新嘗試整個任務。 然而，批次處理不會在執行中的任務中重試單一依賴請求。

批次 API 請求重試

服務外的應用程式可以呼叫批次 API，來建立和管理池、工作、任務、運算節點及其他批次資源。 將這些用戶端設定為使用重試期間至少持續五分鐘的重試原則，以處理暫時性 Batch 服務或網路故障。

當內建的 SDK 重試支援可用時，請使用該支援。 例如，適用於 .NET 的 Azure.Compute.Batch 用戶端程式庫透過Azure.Core 重試選項提供重試行為。

如果您直接從程式碼與 Batch 服務的 API 互動，請等待幾秒鐘再重試， 帶有隨機 (抖動) 的指數退避，以避免同步處理的重試要求，並遵循節流回覆 (例如429 Too Many Requests和503 Service Unavailable) 中傳回的Retry-After標頭。

請求逾時不一定代表 Batch 未能處理該請求。 逾時後，在安全時重試操作，或取回資源狀態以判斷原始操作是否成功。 欲了解更多資訊，請參閱 Azure Batch 中的錯誤處理與偵測。

對計算節點故障的韌性

運算節點可能因基礎設施故障、作業系統問題或設定問題而無法使用。 批次處理嘗試恢復受基礎設施故障影響的節點，但無法自動恢復所有與配置相關的故障。 例如，如果應用程式套件或容器安裝失敗，你必須修正根本問題，可能需要移除並替換受影響的節點。

若節點故障中斷任務，Batch 可在可能的情況下於同一節點上重試該任務，最多到內部限制為止。 如果任務無法在該節點繼續，Batch 可以將該任務重新排入佇列，以便在另一個可用節點上執行。 這些 服務驅動的恢復重試 與 maxTaskRetryCount 無關，即使其值為 0 時仍可能發生。

Microsoft 管理的節點復原流程

Microsoft 管理服務驅動的節點復原與任務重新排入佇列。 如果 Batch 服務停止接收節點的心跳足夠長的時間以觸發恢復，Batch 可以執行以下動作：

  1. 隔離節點： 批次會將該節點視為不健康，將其狀態設為 unusable，並停止在該節點上排程新的任務。
  2. 辨識受影響的任務： 批次處理用來識別節點上正在執行的任務，作為重新排程的候選任務。
  3. 重新排入佇列的合格任務：如果受影響的任務仍維持在 running 狀態，Batch 可以將其重設為 active，以便排程器將其指派給另一個節點。 Batch 不會重設或重新執行已維持在completed狀態的任務。
  4. 恢復節點： Batch 會嘗試將節點恢復到健康狀態或替換底層虛擬機。

恢復不是瞬間的。 任務可以保持該 running 狀態，而 Batch 偵測節點故障並嘗試重新排程任務。 若無其他運算節點可用，任務可維持該狀態，直到 Batch 可以重新排定該任務。 更多資訊請參閱 批次任務的已知限制。

如果原始節點在替換開始前恢復良好的活動訊號，Batch 可以將其恢復到穩定狀態。 如果替換已經開始，Batch 可以改為移除原本的虛擬機並佈建替代 VM。

您的責任

服務驅動的復原無法保證任務不中斷執行或剩餘容量充足。 您需負責以下工作：

  • 維持足夠的容量： 如果工作負載必須在某個節點無法使用時繼續執行，請預備足夠的節點，讓其餘節點能執行重新排程的任務。 沒有其他可用節點，已中斷的任務必須等待。

  • 監控可用容量： 追蹤聚合節點的數量和狀態，這樣你就能偵測到某個池子何時已經沒有足夠可用的節點來應付你的工作負載。 狀態如 unusable、 startTaskFailed、 unknown、 preempted 表示容量降低。 如需詳細資訊，請參閱依狀態計算作業和節點數目以監視 Batch 解決方案。

  • 調查問題節點： 若任務反覆失敗、被重新排入佇列，或在其指派的節點無法使用或離開集區後仍停留在 running 狀態，請利用任務中繼資料判斷問題是否與特定節點相關。

    在移除問題節點之前，先上傳其批次節點代理日誌並保留相關任務日誌，因為移除該節點會刪除其本地檔案。 Node agent 日誌能協助 Microsoft 支援服務 診斷批次服務或節點問題，而任務日誌如 stdout 和 stderr 則能協助你識別應用程式與設定問題。 欲了解更多資訊，請參閱 節點代理日誌檔案。

  • 保護任務進度與資料： 設計任務以容忍中斷與重複執行。 將檢查點、輸出及其他耐用資料移離運算節點，因為它們的本地儲存是短暫的。

欲了解更多資訊，請參閱 Azure Batch 池與節點錯誤，以及 Azure Batch 中的錯誤處理與偵測。

對可用性區域故障的抵抗力

可用性區域 是 Azure 區域內物理上獨立的資料中心群組。 當某個區域發生故障時，服務可以切換至其他剩餘的區域。

Batch 以兩種主要方式支援可用性區：

  • 控制平面： Batch 控制平面在許多區域具備可用性區域韌性。 在這些區域中，針對批次帳戶及其他批次資源的管理操作可在區域失效時繼續進行。 Microsoft 並未公布哪些區域提供這種控制平面韌性。

  • 集區： 你可以設定批次集區來使用 可用性區域放置。 若某區域無法使用，健康區域中的運算節點仍可進行任務排程。

    對於運算節點配置，這種支援模式類似於其他 Azure 服務中的區域冗餘，因為單一池可包含多個可用區的運算節點。 然而，Batch 以盡力而為的方式將節點散布到不同區域。 它嘗試使用該區域中的所有可用區，但不保證會部署到每個可用區，也不保證在各可用區之間平均分布。 你無法選擇特定區域，也無法控制每個區域放置的節點數量。

下圖展示了一個 Batch 帳戶的範例。 該帳號擁有一個單一的池，其節點分布於三個可用區域：

圖示顯示一個 Batch 集區，計算節點分布於三個可用區域。

你要負責讓其他相依資源（例如儲存體帳戶）具備區域備援能力。 請參考每項服務的可靠性指南。 欲了解更多資訊，請參閱 Azure 服務的可靠性指南。

Requirements

跨區域分佈的執行個體

當你啟用可用區域放置時，Batch 會嘗試在所選區域內所有可用區域分配計算節點。 此分配是以盡力而為的方式進行。 批次控制分配，且每個區域的節點數量可能不相等。

Cost

Batch 不會針對啟用可用區域配置收取費用。 你需為工作負載所使用的運算、儲存體、網路及其他 Azure 資源付費。 如果您為了容忍區域損失而佈建額外節點，這些節點會產生其正常費用。 欲了解更多資訊，請參閱 Azure Batch 定價。

設定可用性區域支援

  • 建立新的集區，並設置可用性區域： 若要建立啟用可用性區域擺放的集區，請參見「跨可用性區域建立 Batch 集區」。

  • 變更現有集區的可用性區域配置：建立集區時，您必須選取可用性區域配置。 你不能把現有的池改成使用可用區。

    你可以建立替換池，並透過以下步驟更新每個工作以使用該池：

    1. 停用該工作：使用停用工作操作，並選擇在您提交要求時，Batch 要如何處理正在執行的任務：

      • 等待： 批次會停止啟動新任務，並允許現有池中執行的任務完成。 工作會保持在 disabling 狀態，直到執行中的任務完成。
      • 重新排隊： 批次中斷正在執行的任務並將其返回隊列。 啟用工作後，任務可以再次執行。
      • 終止： 批次會中斷執行中的任務，並以失敗資訊標記任務已完成，表示任務已被終止。 啟用工作後，任務不會再執行。

      已經處於active狀態的任務，也就是已排入佇列但未執行的任務，無論選擇哪個選項，都會維持在佇列中。

      等工作觸達disabled狀態後再繼續。 那時沒有任務在執行，Batch 也不會排程新任務。

    2. 編輯作業的集區： 使用 更新作業 操作將作業的 poolInfo.poolId 設定為替換集區。 批次只允許這個屬性在工作處於 disabled 狀態期間變更。 在啟用工作前，請確保替換池存在且有可用容量。 如果集區不存在，Batch 會接受更新，但在你建立集區之前，它無法排程工作。

    3. 啟用該工作： 使用 啟用工作 操作。 工作會從 enabling 狀態轉移到 active 狀態。 批次接著在替換集區上排程已排隊任務，包括透過 重新排隊 選項回傳到佇列的任務。 Batch 套用等待選項時完成的任務，以及由終止選項完成的任務不會再次執行。

容量規劃和管理

Batch 的 正常節點復原程序 會嘗試替換區域故障時無法使用的節點，並將集區恢復到其設定的目標節點數量。 它不會提高該目標值。 為了在某個區域無法使用時，仍保有足夠的容量使工作負載得以持續運作，請考慮透過自動縮放或手動方式，將超額佈建用於集區的容量：

  • 如果你使用自動縮放：參考池自動擴展公式中的$UsableNodeCount服務定義變數，以偵測可用容量何時低於你的工作負載所需的基準線。 $UsableNodeCount 是其公式正在被評估的集區之 Batch 自動縮放變數，而非 Azure 監視器 指標。 Azure 監視器 會在批次帳戶範圍內發布批次節點計數指標，而這些指標沒有 poolId 維度。

  • 如果您手動管理容量：使用列出集區節點計數作業，檢索每個集區中各狀態的專用節點與 Spot 節點計數。 操作不會回傳單一的可用節點數量。 評估可執行任務的狀態（如 idle 和 running）與不可用或有問題的狀態（如 unusable、unknown、offline 和 startTaskFailed）。 回傳的計數可能不是最新的，所以需要精確計數時，可以列舉池的計算節點。

Batch 以盡力而為的方式將節點散布到各區域，因此實際散布可能不完全相同。 規劃容量時，不要假設節點在各區域平均分布。 驗證您的工作量是否能在減少池容量的情況下達成復原目標。

所有區域都狀況良好時的行為

本節說明當批次集區使用可用性區域配置且所有區域均運作時，可預期的情況。

  • 跨區作業： 批次排程會針對池中可用的運算節點排定任務，無論每個節點所在的區域為何。

  • 跨區域資料複寫： Batch 運算節點是短暫的，Batch 不會在區域間複製任務檔案。 你負責將必須在節點遺失後保存的輸入、輸出、檢查點和診斷資料轉移到耐用儲存裝置。 設定儲存帳戶冗餘以符合你的可用性需求。

區域失敗期間的行為

本節說明當批次池使用可用性區塊配置且某一可用區無法使用時，應預期的情況。

  • 偵測與回應：Microsoft 監控批次服務及運算節點健康狀況。 在區域故障期間，批次會偵測受影響節點持續心跳喪失，並開始 正常的節點恢復程序。 健康區域中的節點仍然可用，Batch 仍可繼續排程任務。

    批次會嘗試透過正常的復原程序將池恢復到設定的目標節點數量，但不會增加該目標節點數量。 如果目標無法提供足夠的容量來應付工作負載，你就負責申請額外容量。

  • 通知： Microsoft 不會在區域關閉時自動通知您。 不過，你可以使用 Azure 服務健康狀態 來了解服務整體健康狀況，包括任何區域故障，並且可以設定 Service Health 警示來通知你問題。

  • 執行中任務： 受影響節點上執行的任務會被中斷。 批次可能會在其內部復原行為中，將任務重新排程到可用節點上。 設計任務以容忍重試與重複執行，如 暫態故障的韌性 與 運算節點故障的韌性 所述。

  • 預期資料遺失： 受影響的運算節點上的檔案在中斷期間無法使用，若節點被重新映像化或從池中移除，檔案也會遺失。 Batch 不會跨不同區域複寫這些檔案。 保存到耐用儲存的資料會依據該儲存資源的冗餘配置保持可用性。

  • 預期的停機時間： 健康節點的任務持續進行。 中斷的任務會經歷停機，直到 Batch 能將其重新排程到可用節點。 若無可用節點，任務可能會停留在running狀態，直到 Batch 能重新排程。 復原時間取決於可用池容量及排隊工作負載。

    如果帳戶位於控制平面具有區域韌性的區域，對批次帳戶及其他批次資源的管理作業仍會繼續進行。 在其他地區，管理作業可能要等到受影響區域恢復後才能使用。

  • 重新散布：在持續活動訊號消失後， Batch 會將受影響的節點標記為unusable，並透過其正常節點恢復流程提交它們以進行替換。 批次會嘗試將池恢復到其設定的目標節點數量，但替代容量取決於健康區域的配額與虛擬機可用性。

    在此過程中，作業仍與集區相關聯。 Batch 則持續在健康區域的可用節點上排程活躍工作中的任務。 若替換節點被分配並可用，批次也能在這些節點上排程任務。

    這個復原過程不會增加設定的目標節點數量。 如果你的工作量需要超過目標容量，請手動增加容量，或設定池的自動縮放公式來增加。

區域復原

Batch 是在區域失敗後恢復時管理恢復流程。 Batch 依循對運算節點故障的復原力中定義的相同流程。

Batch 並不保證恢復後節點會平均平衡於可用性區域間。 區域配置仍採盡力而為方式。

測試區域失敗

你無法模擬實際的 Azure 可用性區域中斷來進行測試。 相反地，使用非實際執行集區來中斷具代表性的任務，並讓足夠的運算節點停止服務，以模擬預期的容量損失。 請考慮使用 以下支援的節點操作：

  • 重啟選中的節點。
  • 在選定節點上關閉任務排程。
  • 從池中移除選定的節點。

當操作允許你選擇如何處理正在執行的任務時，選擇 重新佇列 選項，讓 Batch 能在剩餘節點上排程中斷的任務。

測試期間，請確認批次是否會重新排程中斷的任務，且重執行不會產生重複或不一致的輸出。 確認檢查點與輸出仍可從耐用儲存中取得，監控偵測節點損失與容量減少，且工作負載可利用剩餘容量完成。

這些操作驗證任務中斷與重新排程、冪等性、檢查點及持久輸出處理。 然而，它們無法重現整個區域失敗的所有效果。

對區域範圍故障的復原能力

批次帳號及其池的範圍只限於一個 Azure 區域。 如果區域發生故障，你的 Batch 作業和集區可能會受到影響。

批次處理不會將帳號、池組設定、工作、任務、應用程式套件或任務資料複製到其他區域，也沒有內建跨區域故障轉移。 當你的工作負載必須容忍區域性故障時，你負責部署並營運多區域 Batch 解決方案。

客製化多區域韌性解決方案

要建立多區域解決方案，請在你的復原設計所使用的每個區域至少部署一個 Batch 帳戶。 批次帳戶在不同地區獨立運作。 你負責選擇區域、部署與操作每個區域的資源，並協調配置、複製、故障轉移與故障回復。

你可以設計主動 -主動 方式，在正常運作時在多個區域提交工作，或是主動 -被動 方式，讓次要部署隨時準備好進行故障轉移。 主動-主動設計可縮短恢復時間，因為兩個部署在正常運作期間都會處理工作負載，而主動-被動設計則能降低穩態運算成本。

以下清單列出您在設計解決方案時的職責範例：

  • 部署： 預先建立 Batch 帳戶、集區或集區部署定義、儲存體帳戶、網路資源及其他相依性。 確認每個選定區域是否支援批次功能、虛擬機大小及你工作負載所需的相依服務。 盡可能將每個批次帳號及其任務使用的儲存資源保持在同一區域，以避免不必要的延遲。 透過使用基礎設施作為程式碼，定義批次帳號、池及支援資源，使配置能在不同區域間一致重現。

  • 配額與容量： 在每個復原區域核實適用的 Batch 帳戶、訂閱和虛擬機器家族配額，並在需要時於發生中斷之前請求增加。 配額是一種限制，不是容量保證。 虛擬機的可用性會依地區、虛擬機家族及時間而異。 更多資訊請參閱 批次帳戶與核心配額。

  • 資料複製： 在每個復原區域都保持應用程式套件、容器映像、輸入資料及參考資料可用。 Batch 不會幫您複寫這些項目。

  • 儲存複製： 根據你的復原點目標，配置儲存冗餘與跨區域資料複製。 確認每個復原區域都能存取複製的資料。 關於儲存可靠性選項，請參閱 Azure Blob 儲存體 中的可靠性。

  • 區域目標： 如果你的應用程式可與你的 Batch 帳戶搭配運作，請將其設計成能選擇另一個 Batch 帳戶及其相關的儲存資源，而不需要進行程式碼部署。

  • 備援轉換： 批次處理不會自動把你的工作負載移到另一個區域。 你負責偵測故障、判斷故障對工作負載的影響、停止提交到受影響的批次帳號、將新工作導向健康區域的批次帳號，以及決定是否重新提交中斷的工作。 你未在受影響區域外複製的作業或任務輸出可能會無法使用或遺失。 你的復原時間取決於你的部署模式、可用容量、資料複製及自動化。

  • 區域恢復： 在受影響區域恢復服務可用性後，先驗證批次帳戶、池、儲存相依性及工作狀態，再將工作導向該區域。 重新提交前，請先處理重複或部分完成的任務。 Batch 不會協調此流程，也不會調節區域性帳戶之間的狀態。

  • 測試： 定期在非生產環境中測試完整的區域復原流程。 模擬一個區域部署無法使用，直接提交到另一個區域批次帳號，驗證對應用程式套件與輸入資料的存取，執行代表性工作，收集輸出，並練習讓已復原的部署重新投入服務。 將結果與你的恢復時間目標及復原點目標做比較。

備份與還原

Azure Batch 並不是作業負載輸入與輸出資料的持久性存放區。 Microsoft 維護批次服務，但你必須負責保留重建工作負載所需的設定和資料：

  • 批次配置：利用基礎設施作為程式碼（如 Bicep）及版本控制的工作定義，定義批次帳號、池、工作及支援資源。 這些產物提供了可重複的方式，可以在同一區域或其他區域重現配置。 定期測試定義是否能部署池並執行具代表性的作業。

  • 批次元資料： 批次會保留工作和任務記錄，直到你刪除相關的工作或任務，但這些記錄不是備份。 如果你需要保留這些歷史紀錄，請將必要的紀錄保留在 Batch 之外。

  • 計算節點資料： 運算節點是短暫的，他們的檔案系統不是備份或持久性儲存體。 當節點被重新映像化或離開池時，該節點的資料會遺失。 批次處理也能在保留期限屆滿後刪除任務檔案。 在任務完成前，將所需的輸出與診斷日誌保存到持久性儲存體。 對於長期執行的任務，在執行期間持久化檢查點。 更多資訊請參閱「持續保存工作與任務輸出」及「監控 Azure Batch」。

  • 自動儲存帳戶中的資料： 相關的自動儲存帳號可以存放應用程式套件和任務資源檔案。 除了設定符合復原目標的冗餘外，還要考慮是否需要保護這些資料免於意外刪除或損壞。 更多資訊請參閱 Azure Blob 儲存體 中的備份與復原。

還原與復原測試

若要恢復，請部署 Batch 及支援資源組態、還原或重新連接所需輸入資料與應用程式成品，並重新提交未完成的工作。 定期在隔離或非生產的復原環境中測試資源重建與資料還原。 使用受版本控制的定義與備份資料，執行具代表性的工作，驗證結果輸出以及對相依性的存取權，並將已達成的復原時間與復原點與您的目標進行比較。 確認任務是否冪等，避免重新提交不確定的工作時損壞資料或產生重複輸出。

服務維護的韌性

Microsoft 負責平台維護並協調 Azure Batch 及其他服務的基礎架構更新。 你負責設定池更新行為，並設計能容忍中斷的任務。

  • 主機維護：Azure 在可能的情況下會使用維護技術，例如即時遷移。 若維護需要運算節點重新啟動或移動，執行中的任務可能會中斷，而 Batch 可能會重新排程這些任務。 讓任務成為冪等型，並將檢查點和輸出持久化到耐久儲存體。

  • 訪客作業系統： 你負責保持訪客作業系統和批次節點代理的最新狀態。 作業系統更新的行為取決於映像檔和更新設定。 透過適當的設定， 批次池的自動作業系統映像升級 可以在不中斷執行任務的情況下更新池節點。 自動作業系統映像升級並不支援所有 Batch 作業系統映像檔。

  • 節點代理更新： 自動作業系統映像升級不會自動更新批次節點代理。 當集區中有運算節點時，批次節點代理程式不會自動升級。 若要接收較新的 node agent，請將集區大小調整為零個節點，再將其擴增，或取代集區。 移除節點前，請保留所有必要的任務輸出與診斷日誌。 欲了解更多資訊，請參閱批次節點代理更新。

遵循 生產部署建議 及 運算節點故障指引 ，協助您的工作負載持續或在維護中斷任務或導致運算節點無法使用時恢復。

服務等級協定

Azure 服務的服務層級協議（SLA）描述了每項服務的預期可用性，以及您的解決方案必須符合的條件，以達成該可用性預期。 欲了解更多資訊，請參閱線上服務的服務等級協議。

Azure Batch 可用性 SLA 適用於你針對批次 API 執行的操作。 欲了解包含哪些作業類型的詳細資訊，請參閱SLA條款。 你的池大小、區域分布和依賴服務會影響工作負載的端到端可用性，但不會改變批次服務等級協議（Batch SLA）的條款。

相關內容

  • 上次更新時間：