Azure Batch 最佳做法

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

提示

如需 Azure Batch 中安全性的指引，請參閱 Batch 安全性與合規性最佳做法。

集區

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

集區設定和命名

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

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

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

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

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

• 即將終止生命週期 (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，此屬性可為資源提供更容易讀取的名稱 (即使實際的資源識別碼不是人類易懂的內容)。 使用唯一名稱可讓您更輕鬆地區分特定資源在記錄和計量中的作用。 如果您必須為資源提出支援案例，此方式也有助於避免模稜兩可的情況。

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

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

集區安全性

隔離界限

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

Batch 節點代理程式更新

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

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

注意

如需有關 Azure Batch 中安全性的一般指導方針，請參閱 Batch 安全性與合規性最佳做法。

作業系統更新

針對 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 中的成品快取。

Azure 區域相依性

如果您的工作負載重視時間性或用於生產，那麼就不該依賴單一 Azure 區域。 雖然很罕見，但還是有可能發生會影響整個區域的問題。 例如，如果您的處理需要在特定時間啟動，請考慮在「開始時間之前」，就在您主要區域中擴大集區。 如果該集區調整失敗，您可以切換回備份區域中來擴大集區。

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

工作

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

作業少，工作多

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

當設計批次解決方案時，請避免同時進行數千項作業。 由於沒有工作配額，因此請盡可能利用較少作業來執行許多工作，以便有效使用您的工作與工作排程配額。

作業存留期

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

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

預設為進行中工作與工作排程配額。 處於完成狀態的工作與工作排程不會計入此配額。

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

工作

工作是組成作業的個別作用單位。 工作會由使用者提交，並由 Batch 安排到計算節點上。 針對設計工作來處理問題並有效率地執行，下列各節會提供建議。

儲存工作資料

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

批次已整合支援 Microsoft Azure 儲存體，可透過輸出檔案與各種共用檔案系統來上傳資料，或者您也可透過工作自行執行上傳作業。

管理工作存留期

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

刪除工作會完成兩件事：

• 確保您的工作不會累積任務。 當尋找目標工作時，必須篩選已完成任務，因此可能會遇到困難，此動作有助避免發生此情況。
• 清除節點的對應工作資料 (前提是 retentionTime 尚無點擊記錄)。 此動作有助確保節點不會填滿工作資料，導致磁碟空間不足。

注意

對於剛提交至 Batch 的工作，DeleteTask API 呼叫最多需要 10 分鐘才會生效。 在生效之前，其他工作排程可能會無法進行。 這是因為 Batch 排程器仍會嘗試對剛刪除的工作進行排程。 如果您想要在提交工作後不久將其刪除，請改為終止該工作 (因為終止工作要求會立即生效)。 然後在 10 分鐘後刪除該工作。

在集合中提交大量工作

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

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

Batch 支援節點上有超載的工作 (執行的工作數目比節點具有的核心還多)。 您必須確保您的工作大小適合集區的節點。 例如，如果您嘗試將八個各耗用 25% CPU 使用量的工作安排到一個節點上 (在具有 taskSlotsPerNode = 8 的集區中) 時，您可能會感受到降級的體驗。

重試和重新執行的設計

Batch 可以自動重試工作。 重試的類型有兩種：使用者控制和內部。 使用者控制的重試是由工作的 maxTaskRetryCount 來指定。 當工作中指定的程式以非零結束代碼結束時，工作會重試到達到 maxTaskRetryCount 的值。

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

無論在專用或現成節點上執行您的工作，設計上都不會有任何差異。 無論是在現成節點上執行工作時遭到佔用，或因為專用節點失敗而造成工作中斷，這兩種情況都是藉由設計能承受失敗的工作來降低風險。

建置耐用的工作

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

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

避免短時間執行

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

使用 Windows 節點上簡短工作的集區範圍

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

節點

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

開始工作：存留期和等冪性

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

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

提示

當 Batch 重新執行啟動工作時，其會嘗試刪除啟動工作目錄，並重新建立一個。 如果 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

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

連結及準備資料磁碟

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

提示

在 Linux 中掛接資料磁碟時，如果在 /mnt 或 /mnt/resource 之類的 Azure 暫存掛接點下有巢狀掛接點，則應該小心不會引進任何相依性競爭。 例如，如果作業系統會自動執行這些掛接，則掛接的暫存磁碟與掛接在父系下的資料磁碟之間可能會發生競爭。 應採取步驟，以確保適當的相依性是由可用的設施強制執行 (例如 systemd)，或將資料磁碟掛接延遲至啟動工作，作為等冪資料磁碟準備指令碼的一部分。

在 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 集區準備資料磁碟

連結到 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 代理程式記錄。 您可以使用上傳 Batch 服務記錄 API 來收集 Batch 代理程式記錄。 這些記錄可以作為 Microsoft 支援票證的一部分提供，並有助於對問題進行疑難排解。

Batch API

逾時失敗

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

連線性

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

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

當佈建虛擬網路 Batch 集區時，請務必密切遵守指示以利使用 Batch 節點管理。區域服務標籤、連接埠、通訊協定及規則方向。 強烈建議使用服務標籤；請勿使用基礎 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 分鐘的間隔。 自動重試功能可透過各種 Batch SDK 提供，例如 .NET RetryPolicyProvider 類別。

靜態公用 IP 位址

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

Batch 節點基礎相依性

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

系統建立的資源

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

Windows：

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

Linux：

• 名為 _azbatch 的使用者

提示

這些使用者或群組的命名是實作成品，隨時可能會變更。

檔案清理

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

若您透過啟動工作工作目錄在 Windows 執行服務，則會封鎖工作目錄的自動清理，因為該資料夾仍在使用。 這個動作會導致效能降低。 若要修正這個問題，請將該服務的目錄變更為不受 Batch 管理的個別目錄。

下一步

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