Azure Batch 最佳做法

本文會討論有效使用 Azure Batch 服務的最佳做法和實用秘訣。 這些秘訣可協助您增強效能，並避免 Batch 解決方案中的設計錯誤。

評估你的批次設計

在實施生產工作負載前，請檢視最影響規模、可靠性、安全性與成本的決策：

在選擇初始設計後，請參考本文中的建議。 當工作量擴大、截止日期或合規要求改變時，請重新評估這些決策。

池

集區是用於在 Batch 服務上執行作業的計算資源。 下列各節將提供使用 Batch 集區時的建議。

集區設定和命名

• 集區配置模式：建立 Batch 帳戶時，您可以選擇兩個集區配置模式：Batch 服務或使用者訂用帳戶。 在大多數情況下，您應使用預設的 Batch 服務模式，其中集區會在背景配置於 Batch 管理的訂用帳戶中。 在其他使用者訂用帳戶模式中，在建立集區時，會直接在您的訂用帳戶中建立 Batch VM 和其他資源。 使用者訂用帳戶主要是用來啟用重要但較小的案例子集。 如需深入瞭解，請參閱使用者訂閱模式的設定。

• classic 或 simplified 節點通訊模式： 集區可設定為兩種節點通訊模式之一 (傳統或簡化)。 傳統節點通訊模式會啟動批次服務並計算節點通訊，而計算節點也需要跟 Microsoft Azure 儲存體進行通訊。 在簡化節點通訊模式，計算節點會啟動批次服務通訊。 由於所需的傳入/傳出連線範圍縮小，而且不需要 Microsoft Azure 儲存體傳出存取權行基準操作，因此建議使用簡化的節點通訊模式。 將來對批次服務的某些改進也需要簡化節點通訊模式。 傳統節點通訊模型將於 2026年 3 月 31 日淘汰。

• 工作及任務執行階段間注意事項：如果工作主要包含短期執行的任務，並且預期的任務總數很少，作業的整體預期執行階段間不長，請不要為每個作業分配新的集區。 節點的配置時間將會降低作業的執行時間。

• 多計算節點：並不能保證個別節點永遠可用。 雖然不常見，但硬體故障、作業系統更新和具有其他問題的主機可能會導致個別節點離線。 若 Batch 工作負載需要確定性的保證進度，則應配置具有多個節點的集區。

• 具有即將到達生命週期終止 (EOL) 日期的映像：強烈建議避免使用即將結束 Batch 支援的映像。 您可以透過 ListSupportedImagesAPI、PowerShell 或 Azure CLI 來探索這些日期。 您有責任定期更新與您的集區相關的 EOL 日期檢視，並在 EOL 日期到來前移轉工作負載。 如果您使用的是指定節點代理程式的自訂映像，請確保遵循該自訂映像所衍生或對應之映像的 Batch 支援終止日期。 映像若未指定 batchSupportEndOfLife 日期，表示批次服務尚未決定此日期。 不具日期並不表示對應映像可獲得無限期支援。 可於將來隨時新增或更新 EOL 日期。

• 影像驗證狀態： 影像 verificationType 反映目前批次驗證測試的覆蓋範圍，且可能隨時間改變。 今天為verified的映像，日後可能會被回報為unverified，例如當它從 Batch 驗證測試套件中移除，或已屆 Batch 終止支援 (EOL) 日期時。 指定 verified 並不代表該影像會無限期被驗證。 驗證狀態可能隨時更新，因此請定期重新整理您對集區相關verificationType值的檢視。

• 具有即將到達生命週期終止 (EOL) 日期的 VM SKU：與 VM 映像相同，VM SKU 或系列也可能達到 Batch 支援終止生命週期 (EOL)。 您可以透過 ListSupportedVirtualMachineSkusAPI、PowerShell 或 Azure CLI 來探索這些日期。 透過建立具有適當支援的 VM SKU 的新集區，規劃將您的工作負載移轉至非 EOL 的 VM SKU。 VM SKU 缺少相關聯的 batchSupportEndOfLife 日期並不表示該特定 VM SKU 將受到無限期支援。 可於將來隨時新增或更新 EOL 日期。

• 唯一資源名稱：Batch 資源 (作業、集區等) 通常會隨時間建立與消失。 例如，您可以在星期一建立集區、在星期二將其刪除，然後在星期四建立另一個類似的集區。 您建立的每個新資源，都應該被賦予一個您之前未曾使用過的唯一名稱。 您可利用 GUID (作為資源名稱的整體或其中一部分) 或在資源名稱內建資源建立的日期與時間，來建立唯一性。 Batch 支援 DisplayName，此屬性可為資源提供更容易讀取的名稱 (即使實際的資源識別碼不是人類易懂的內容)。 使用唯一名稱可讓您更輕鬆地區分特定資源在記錄和計量中的作用。 如果您必須為資源提出支援案例，此方式也有助於避免模稜兩可的情況。

• 集區維護與故障期間的連續性：建議讓作業動態使用集區。 如果您的作業針對所有項目使用相同集區，則當集區發生問題時，作業可能會無法執行。 此原則對於具時間敏感性的工作負載尤為重要。 例如，當您排定每項工作時，可動態選取或建立集區，或可找到方式覆寫集區名稱，以便略過狀況不良的集區。

• 集區維護和失敗期間的商務持續性：有許多原因會造成集區可能無法成長到您想要的大小，例如內部錯誤或容量限制。 請確保在必要時可透過 BatchClient.UpdateJob，將工作重新導向至另一個不同的集區 (可能使用不同的 VM 大小)。 請避免在預期永遠不會刪除且永遠不會變更的情況下依賴靜態集區識別碼。

• 監控運算節點健康狀況：對於使用使用者訂閱池分配模式的批次帳號，請使用 Azure 監視器 Agent 從池運算節點收集訪客作業系統效能資料與日誌。 只選擇符合你工作量所需的計數器和取樣頻率，以控制攝取成本。 欲了解更多資訊，請參閱 使用 Azure 監視器代理程式監視 Azure Batch 集區中的計算節點。

集區安全性

隔離界限

為了達到隔離目的，如果您的情境需要讓作業或工作彼此隔離，請將它們放在不同的集區中。 集區是批次的安全性隔離邊界，兩個集區預設互不可見，也無法相互通訊。 除非 Batch 帳戶作業所在的大環境需要隔離，否則請避免使用個別的 Batch 帳戶作為安全性隔離的方法。

如有需要，必須在 Batch 帳戶和 API 上套用適當的訪問控制，以防止存取 Batch 帳戶下的所有集區。 建議停用共用金鑰存取，並只允許使用 Entra 驗證來啟用 角色型存取控制。

批次節點代理程式更新

針對計算節點非零的集區，批次節點代理程式不會自動將其升級。 若要確保批次集區接收批次節點代理程式的最新安全性修正程式與更新，您需將集區大小調整為零計算節點，或重新建立集區。 建議您隨時注意 批次節點代理程式版本說明，了解新批次節點代理程式版本的變更。 定期檢查是否已發行更新版本，讓您規劃升級至最新代理程式版本。

在重新建立集區或調整集區大小之前，若您在使用批次集區或計算節點時遇到問題，您應下載任何節點代理程式記錄進行偵錯。 此處理序將在節點章節進一步討論。

作業系統更新

建議用於 Batch 集區的 VM 映像應保持最新狀態，並包含發行者提供的最新安全性更新。 某些映像可能會在開機時執行自動套件更新 (或開機不久之後)，這可能會干擾某些使用者導向的動作，例如擷取套件存放庫更新 (例如 apt update)，或在 StartTask 等動作期間安裝套件。

建議啟用 Batch 集區的自動作業系統升級，這樣底層的 Azure 基礎結構就可以協調集區中的更新。 可以將此選項設定為不中斷工作執行。 自動作業系統升級不支援 Batch 支援的所有作業系統。 如需詳細資訊，請參閱虛擬機器規模設定自動操作系統升級支援矩陣。 對於 Windows 作業系統，在使用 Batch 集區上的自動作業系統升級時，請確保您沒有啟用 virtualMachineConfiguration.windowsConfiguration.enableAutomaticUpdates 屬性。

Azure Batch 不會驗證或保證可與服務搭配使用的映像具有最新的安全性更新。 映像的更新位於映像發行者的責任範圍下，而不是 Azure Batch 的責任範圍。 對於在 microsoft-azure-batch 下發佈的特定映像，我們不保證這些映像會與其上游衍生映像一起保持在最新狀態。

資源集區存留期和計費

集區存留期可能會因為配置的方法和套用至集區設定的選項而有所不同。 集區在任何時間點都可以有不固定的存留期和不同數目的計算節點。 您有責任以明確的方式或使用服務提供的功能（自動調整或autopool）來管理集區中的運算節點。

• 池槽重建： 避免每天刪除並重新建立池槽。 反之，請建立新的集區，並將現有作業更新為指向新的集區。 當所有工作都已移至新集區之後，再刪除舊的集區。

• 資源池效率和計費：批次本身不會產生額外費用。 不過，若您使用 Azure 資源則需支付費用，例如計算、儲存空間、網路功能，以及批次工作負載可能需要的任何其他資源。 您需針對集區中的每個計算節點支付費用，而且不論其狀態為何。 如需詳細資訊，請參閱 Azure Batch 的 成本分析和預算。

• 暫時性 OS 磁碟：虛擬機器設定集區可以使用暫時性 OS 磁碟 (其會在 VM 快取或暫存 SSD 上建立 OS 磁碟)，以避免與受控磁碟相關聯的額外成本。

集區配置失敗

集區配置失敗可能會在第一次配置或後續調整大小的任何時間點發生。 此類失敗可能是因區域容量暫時耗盡，或是批次所依賴的其他 Azure 服務發生故障所致。 您的核心配額不是保證，而是上限。

非計畫的停機時間

Batch 集區在 Azure 中可能會發生停機事件。 了解可能會出現問題，應設計您的工作流程，使其具備可因應重新執行的彈性。 如果節點失敗，Batch 會自動嘗試代表您復原這些計算節點。 這次復原可能會觸發在已還原節點或其他不同可用節點上重新排程任何正在執行的工作。 如需有關中斷工作的詳細資訊，請參閱重試設計。

自訂映像集區

當您使用虛擬機器設定建立 Azure Batch 集區時，需指定 VM 映像，以提供集區中每個計算節點的作業系統。 您可以使用支援的 Azure Marketplace 映像來建立集區，或使用 Azure Compute Gallery 映像來建立自訂映像。 雖然您也可以使用受控映像來建立自訂映像集區，但我們建議您盡可能使用 Azure Compute Gallery 來建立自訂映像。 利用 Azure Compute Gallery 可協助您加快佈建集區、大量擴充 VM，並在佈建 VM 時改善可靠性。

協力廠商映像

您可以使用發佈至 Azure Marketplace 的協力廠商映像來建立集區。 在使用者訂用帳戶模式的 Batch 帳戶中，當使用特定第三方映像建立集區時，可能會看到「因 Marketplace 購買資格檢查而導致配置失敗」錯誤。 若要解決此錯誤，請接受映像發行者所設定的條款。 您可以使用 Azure PowerShell 或 Azure CLI 來完成。

容器集區

當您使用虛擬網路建立 Batch 集區時，指定的虛擬網路與預設的 Docker bridge 之間可能會產生互動的副作用。 Docker 預設會建立網路橋接器，其子網路規格為 172.17.0.0/16。 確保 Docker 網路 bridge 與您的虛擬網路之間沒有衝突的 IP 範圍。

Docker Hub 會限制映像提取的數目。 請確定您的工作負載不會超過 Docker Hub 型映像的已發佈比率限制。 建議您直接使用 Azure Container Registry，或利用 ACR 中的 Artifact 快取。

Azure 區域相依性

如果您的工作負載有時間敏感性或屬於生產環境，那麼就不該倚賴單一的 Azure 區域。 雖然很罕見，但還是有可能發生會影響整個區域的問題。 例如，如果您的處理需要在特定時間開始，請考慮在開始時間前，提前於主要區域擴展集區規模。 如果該集區擴展失敗，您可以改為在備援區域 (或多個備援區域) 中擴展集區。

集區如果橫跨不同區域中的多個帳戶，則可在另一個集區發生問題時，提供已就緒且容易存取的備份。 如需詳細資訊，請參閱設計應用程式以獲得高可用性。

工作

作業是一種容器，其設計目的是要包含數百個、數千個或甚至數百萬個工作。 建立作業時，請遵循這些指導方針。

作業少，工作多

使用一個工作來執行單一任務相當沒效率。 例如，相較於建立各包含 10 個工作的 100 項作業，使用包含 1,000 個工作的單一作業會更有效率。 如果您使用 1,000 項作業，而每項作業均為個別工作，這將是效率最低、最慢且最昂貴的方法。

在設計 Batch 解決方案時，應避免需要同時啟動數千個作業。 由於沒有工作配額，因此請盡可能利用較少作業來執行許多工作，以便有效使用您的工作與工作排程配額。

作業存留期

Batch 作業在從系統中刪除之前，會有無限的存留期。 其狀態會表明其是否可以接受更多工作來進行排程。

除非明確終止，否則工作不會自動移至完成狀態。 此動作可透過 BatchAllTasksCompleteMode 屬性或 maxWallClockTime 自動觸發。

系統預設具有作用中作業與作業排程配額。 處於完成狀態的工作與工作排程不會計入此配額。

當不再需要作業時將其刪除，即使作業處於已完成的狀態也一樣。 儘管已完成的作業不計入作用中的作業配額，但定期清理已完成的作業還是有好處的。 例如，當作業總數較少時，即使在要求中套用適當篩選條件，列出作業也會更有效率。

任務

任務是組成工作的個別工作單位。 工作由使用者提交，並由 Batch 排程至計算節點執行。 下列各節提供設計任務以處理問題並有效執行的建議。

儲存工作資料

就本質來說，計算節點的存在時間相當短暫。 Batch 功能 (例如 autopool 和自動調整) 可讓節點輕鬆地消失。 節點離開集區時 (由於調整大小或集區刪除)，也會一併刪除這些節點上的所有檔案。 由於此行為，工作應在完成前將輸出從執行節點移出，並寫入持久性儲存體。 同樣地，如果工作失敗，則應該將診斷失敗所需的記錄移到長期存放區。

Batch 已與 Azure 儲存體整合，支援透過 OutputFiles 上傳資料，並可搭配各種共用檔案系統，或由您在工作中自行執行上傳。

管理任務生命週期

當不再需要任務時加以刪除，或設定 retentionTime 工作限制。 如果設定了 retentionTime，Batch 會在 retentionTime 到期時，自動清除工作所使用的磁碟空間。

刪除工作會產生兩個結果：

• 確保作業中不會累積過多工作。 此操作可避免在已完成工作中進行篩選時，難以找到您所關注的工作。
• 清除節點上的相應任務數據（前提是 retentionTime 尚未被觸發）。 此動作有助確保節點不會填滿工作資料，導致磁碟空間不足。

在集合中提交大量工作

工作可以個別提交或以集合的方式提交。 在提交大量工作時，您可以透過集合提交最多 100 個工作，以減少額外負荷和提交時間。

適當設定每個節點的工作數目上限

Batch 支援在節點上超額配置工作 (執行的工作數量多於節點核心數)。 您有責任確保工作的規模適合您集區中的節點。 例如，如果您嘗試將八個各耗用 25% CPU 使用量的工作安排到一個節點上（在具有 taskSlotsPerNode = 8 的集區中），您可能會感受到性能下降的體驗。

重試與重新執行設計

Batch 可以自動重試工作。 重試可以分為兩種：使用者控制的重試和內部重試。 使用者控制的重試是由工作的 maxTaskRetryCount 來指定。 當工作中指定的程式以非零結束代碼結束時，系統會依 maxTaskRetryCount 的設定值重試該工作。

雖然很罕見，但工作會因為計算節點發生失敗而在內部重試，例如無法在工作執行時更新內部狀態或節點上發生失敗。 工作會盡可能在相同的計算節點上重試，直到達到內部限制為止；之後才會放棄該工作，並由 Batch 延後重新排程 (可能在不同的計算節點上執行)。

無論在專用或現成節點上執行您的工作，設計上都不會有任何差異。 無論是在 Spot 節點上執行時工作被中斷，或因專用節點發生故障而中斷，這兩種情況都可透過設計具備容錯能力的工作來加以緩解。

建立持久的工作

工作應設計為可承受失敗並可配合重試。 此原則對長時間執行的工作尤為重要。 請確保您的工作會產生相同的單一結果，即使執行多次也是如此。 達成此結果的其中一種方式，就是讓您的工作進行「目標搜尋」。另一種方式是確保您的工作具有「等冪性」(不論工作執行多少次，都會有相同的結果)。

常見的範例是將檔案複製到計算節點的工作。 其中一個簡單的方法是在每次執行時複製所有指定檔案，但這樣的方法不具備效率，也不具備防故障能力。 應改為建立能確定檔案位於計算節點上的工作；不會重新複製已存在檔案的工作。 如此一來，工作就會從中斷的地方繼續進行。

避免執行時間過短

只執行一到兩秒鐘的工作並不理想。 請嘗試在個別工作中執行大量的工作 (最少 10 秒，最多可以到數小時或數天)。 如果每個工作都執行一分鐘 (或以上)，則排程負荷在整體計算時間中所佔的部份就會比較小。

在 Windows 節點上使用集區範圍進行簡短工作

在 Batch 節點上排程工作時，您可以選擇使用工作範圍或集區範圍來執行工作。 如果工作只會執行一小段時間，工作範圍可能會效率不佳，因為建立該工作的自動使用者帳戶需要資源。 為了提升效率，請考慮將這些工作設定至集區範圍。 如需詳細資訊，請參閱以具有集區範圍的自動使用者身分執行工作。

節點

計算節點是 Azure 虛擬機器 (VM) 或雲端服務 VM，專門用來處理您應用程式的部分工作負載。 使用節點時，請遵循這些指導方針。

開始任務：生命週期和等冪性

如同其他任務，開始任務節點應具有等冪性。 當計算節點重新啟動或 Batch 代理程式重新啟動時，就會重新執行啟動工作。 冪等工作是指執行多次仍會產生一致結果的工作。

啟動工作不應長時間執行，或與計算節點的存留期結合。 如果您需要啟動本質上是服務或類似服務的程式，請建構啟動工作，讓這些程式能夠由 Linux 或 Windows 服務上的 systemd 等作業系統設施來啟動和管理。 啟動工作仍應設計為具等冪性，以便在這些程式先前已安裝為服務時，後續執行啟動工作仍能正確處理。

這些服務不得鎖定 Batch 管理節點中的目錄內的任何檔案，否則因檔案鎖定無法刪除這些目錄。 例如，與其直接在啟動任務的工作目錄中設定服務的啟動，不如以等冪方式將檔案複製到其他位置。 然後使用作業系統功能從該位置安裝服務。

隔離式節點

請考慮針對具有合規性或法規需求的工作負載使用個別的 VM 大小。 虛擬機器組態模式中支援的隔離大小包含 Standard_E80ids_v4、Standard_M128ms、Standard_F72s_v2、Standard_G5、Standard_GS5 和 Standard_E64i_v3。 如需隔離式 VM 大小的詳細資訊，請參閱 Azure 中的虛擬機器隔離。

避免在 Windows 中建立目錄連接

目錄連接（有時稱為目錄硬連結）在進行工作和作業清理時很難處理。 請使用符號連結 (軟連結)，而不是永久連結。

暫存磁碟與 AZ_BATCH_NODE_ROOT_DIR

對於與 Batch 相容的 VM 大小，Batch 依賴 VM 暫存磁碟來儲存與工作執行相關的中繼資料，以及每次工作執行的任何成品。 此類暫存磁碟掛接點或目錄的範例如下：/mnt/batch、/mnt/resource/batch 與 D:\batch\tasks。 以下各項均不支援以下操作，且可能導致系統不穩定：取代、重新掛接、接合、符號連結，或以其他方式重新導向這些掛接點與目錄，或其任何父系目錄。 若您需更多磁碟空間，請根據您所需的暫存磁碟空間，考慮使用符合的 VM 大小或系列，或連結資料磁碟。 如需詳細資訊，請參閱下一章節，了解如何為計算節點連結並準備資料磁碟。

掛載與準備資料磁碟

若於 Batch 集區執行個體中指定資料磁碟，每個計算節點都會連接規格完全相同的資料磁碟。 僅新資料磁碟可連結至批次集區。 連結至計算節點的資料磁碟不會自動分割、格式化或掛接。 您有責任於開始任務時執行這些作業。 這些啟動工作必須設計為具等冪性。 您可以重新執行計算節點上的啟動工作。 若啟動任務不具冪等性，則資料磁碟可能會發生資料遺失。

在 Linux批次集區準備資料磁碟

Linux 的 Azure 資料磁碟會顯示為區塊裝置，並指派一般 sd[X] 識別碼。 您不應依賴靜態 sd[X] 分配，此類標籤會在啟動時進行動態分配，並且無法保證在第一次與任何後續啟動之間保持一致。 您應透過 /dev/disk/azure/scsi1/ 所提供的對應關係來識別已附加的磁碟。 例如，如果您在 AddPool API 指定資料磁碟為 LUN 0，則該磁碟會顯示為 /dev/disk/azure/scsi1/lun0。 舉例來說，若您列出此目錄，您可能會看見：

user@host:~$ ls -l /dev/disk/azure/scsi1/
total 0
lrwxrwxrwx 1 root root 12 Oct 31 15:16 lun0 -> ../../../sdc

在您的準備指令碼中，不需要將參考還原為 sd[X] 對應關係，請直接引用裝置。 在本範例，此裝置為/dev/disk/azure/scsi1/lun0。 您可將此 ID 直接提供給 fdisk、mkfs，以及工作流程所需的任何其他工具。 或者，您可以使用 lsblk 搭配 blkid 來對應磁碟的 UUID。

如需進一步了解 Linux 中的 Azure 資料磁碟，包括尋找資料磁碟的替代方法和 /etc/fstab 選項，請參閱這篇文章。 在將您的方法投入生產使用之前，請確保不存在提示中所述的任何相依性或競爭條件。

在 Windows 批次集區中準備資料磁碟

連結到 Batch Windows 計算節點的 Azure 資料磁碟會顯示為未分割及未格式化。 當您啟動工作時，需列舉具 RAW 個分割區的磁碟以執行操作。 您可利用 Get-DiskPowerShell cmdlet 來擷取此資訊。 例如，您可能會看見：

PS C:\Windows\system32> Get-Disk

Number Friendly Name Serial Number                    HealthStatus         OperationalStatus      Total Size Partition
                                                                                                             Style
------ ------------- -------------                    ------------         -----------------      ---------- ----------
0      Virtual HD                                     Healthy              Online                      30 GB MBR
1      Virtual HD                                     Healthy              Online                      32 GB MBR
2      Msft Virtu...                                  Healthy              Online                      64 GB RAW

磁碟編號 2 是未初始化資料磁碟，已連結至這個計算節點。 然後，根據工作流程需求，您可對磁碟進行初始化、分割及格式化。

如需進一步資訊了解 Windows 中的 Azure 資料磁碟 (包括 PowerShell 指令碼範例)，請參閱這篇文章。 在進一步用在生產環境之前，請務必驗證任何範例指令碼是否具有等冪性。

收集批次代理程式紀錄

如果您注意到節點行為有異或在節點上執行的工作有問題，請在解除配置問題節點之前，先收集 Batch 代理程式記錄。 您可以使用上傳 Batch 服務記錄 API 來收集 Batch 代理程式記錄。 這些記錄可以作為 Microsoft 支援票證的一部分提供，並有助於對問題進行疑難排解。

批次應用程式介面

逾時失敗

逾時錯誤不一定表示服務未能處理該要求。 發生逾時失敗時，您應該重試作業，或視情況擷取資源的狀態，以確認作業是否成功或失敗的狀態。

連線性

關於 Batch 解決方案中的連線能力，請參閱下列指導方針。

網路安全性群組 (NSG) 和使用者定義路由 (UDR)

當佈建虛擬網路中的 Batch 集區時，請務必密切遵守相關指示，以便正確使用 BatchNodeManagement.region 服務標籤、連接埠、通訊協定及規則的方向。 強烈建議使用服務標籤；請勿使用基礎 Batch 服務 IP 位址，因其可能會隨時間變更。 直接使用 Batch 服務 IP 位址可能會導致您的 Batch 集區不穩定或中斷。

有關使用者定義的路由器 (UDR)，建議使用 Batch 節點管理。區域服務標籤，而非 Batch 服務 IP 位址，因其可能會隨時間變更。

遵循 DNS

確保您的系統遵循 Batch 帳戶服務 URL 的 DNS 存留時間 (TTL)。 此外，請確保 Batch 服務用戶端與 Batch 服務的其他連線機制不依賴 IP 位址。

任何具有 5xx 級狀態碼的 HTTP 要求，並且回應中包含「連線：關閉」標頭的情況下，都需要調整 Batch 服務客戶端的行為。 您的 Batch 服務用戶端應遵循建議，先關閉現有連線，並重新解析 Batch 帳戶服務 URL 的 DNS，然後在新連線上嘗試後續請求。

自動重試請求

請確定您的 Batch 服務用戶端已有適當的重試原則，即使在正常作業期間也可以自動重試您的要求，而不是僅限於任何服務維護期間。 這些重試原則應具有至少 5 分鐘的間隔。 各種批次 SDK 提供自動重試功能。 在 Azure.Compute.Batch 中，重試行為是透過 Azure.Core ClientOptions.Retry 進行設定。

靜態公用 IP 位址

一般而言，Batch 集區中的虛擬機器會透過可在集區存留期內變更的公用 IP 位址來存取。 若資料庫或其他外部服務限制存取特定 IP 位址，則這種動態性質可能會導致與其互動發生困難。 若要解決這個問題，您可利用您控制的一組靜態公用 IP 位址來建立集區。 如需詳細資訊，請參閱使用指定的公用 IP 位址建立 Azure Batch 集區。

Batch 節點的基礎相依性

設計 Batch 解決方案時，請考慮下列相依性和限制。

系統建立的資源

Azure Batch 會在 VM 建立並管理一組使用者與群組，而該使用者與群組不應變更：

Windows：

• 名為 PoolNonAdmin 的使用者
• 名為 WATaskCommon 的使用者群組

Linux：

• 名為 _azbatch 的使用者

檔案清理

Batch 會在工作保留時間到期後，主動嘗試清理任務執行所在的工作目錄。 您必須清除在此目錄外寫入的任何檔案，以避免填滿磁碟空間。

若您在 Windows 上從啟動工作的工作目錄執行服務，由於該資料夾仍在使用中，將會阻止工作目錄的自動清理。 這個動作會導致效能降低。 若要修正這個問題，請將該服務的目錄變更為不受 Batch 管理的個別目錄。

下一步

• 了解 Batch 服務工作流程和主要資源，例如集區、節點、作業和工作。
• 了解預設的 Azure Batch 配額、限制和條件約束，以及如何要求增加配額。
• 深入了解如何在集區和節點背景作業中偵測並避免失敗。