在現成虛擬機上建置工作負載

Azure 虛擬機器

本文說明如何在 Azure Spot 虛擬機上建置的最佳做法。其中包含可部署的範例案例。現成虛擬機（現成 VM）以低於一般 VM 的價格提供計算容量的存取權。此折扣可讓想要將成本優化的組織成為不錯的選擇。但儲蓄是取捨的。現成 VM 可以隨時收回，這表示它們無法存取計算資源。在現成 VM 上執行的工作負載必須能夠處理計算中的這些中斷。正確的工作負載和彈性協調流程機制是成功關鍵。下列建議說明如何在現成 VM 上建置。

了解現成 VM

在技術層級上，現成 VM 與一般 VM 相同。它們使用相同的映像、硬體和磁碟來轉譯為相同的效能。現成 VM 和一般 VM 之間的主要差異在於其優先順序和可用性。現成 VM 沒有存取計算容量的優先順序，而且在存取該計算容量之後沒有可用性保證。

沒有優先順序存取。 一般 VM 具有計算容量的優先順序存取權。他們會在要求計算容量時存取計算容量。不過，只有在有備用計算容量時，才會發現 VM。它們只會在一般 VM 不需要基礎硬體時繼續執行。
沒有可用性保證。 現成 VM 沒有任何可用性保證或服務等級協定（SLA）。現成 VM 可能會立即失去計算容量的存取權，或在部署或收回之後隨時存取。現成 VM 較便宜，因為它們可以收回。當 Azure 需要計算容量回來時，會傳送收回通知並收回現成 VM。在實際收回發生之前，Azure 提供至少 30 秒的提前通知。如需詳細資訊，請參閱持續監視收回。

了解現成 VM 定價

現成 VM 最多可比一般隨用隨付 VM 便宜 90%。折扣會根據需求、VM 大小、部署區域和操作系統而有所不同。若要取得成本節省的估計值，請參閱 Azure Spot 虛擬機定價工具和 Spot 虛擬機定價概觀。您也可以查詢 Azure 零售價格 API，以程式設計方式取得任何 SKU 的現成定價。

瞭解可中斷的工作負載

現成 VM 適用於可中斷的工作負載，其共用數個常見特性。可中斷的工作負載最少到沒有時間限制、組織優先順序低，以及處理時間短。他們會執行可能會突然停止並稍後繼續的程式，而不會損害必要的組織程式。可中斷工作負載的範例包括批處理應用程式、數據分析，以及為非生產環境建立持續整合和持續部署代理程式的工作負載。這些功能會與具有 SLA、黏性工作和具狀態數據的一般或任務關鍵性工作負載進行比較。

您可以在不可中斷的工作負載中使用現成 VM，但它們不應該是唯一的計算容量來源。視需要使用盡可能多的一般 VM，以符合您的運行時間需求。

瞭解收回

現成 VM 在建立之後沒有 SLA，而且可以隨時失去計算的存取權。我們稱之為計算遺失收回。計算供需驅動收回。當特定 VM 大小的需求超過特定層級時，Azure 會發現 VM 可供一般 VM 使用。需求是特定位置。例如，區域 A 中的需求增加不會影響區域 B 中的現成 VM。

現成 VM 有兩個會影響收回的組態選項。這些組態是現成 VM 的 收回類型 和 收回原則。當您建立現成 VM 時，您可以設定這些組態。收回類型會定義收回的條件。收回原則會決定收回對現成 VM 的用途。

收回類型

容量變更或價格變更會導致收回。容量和價格變更的方式會影響現成 VM，取決於您在建立 VM 時所選擇的收回類型。收回的類型會定義收回的條件。收回類型是 僅限容量的收回，價格或容量收回。

僅限容量收回： 此收回類型會在無法使用多餘的計算容量時觸發收回。根據預設，價格會以隨用隨付率上限。當您不想支付超過隨用隨付 VM 價格時，請使用此收回類型。
價格或容量收回： 此收回類型有兩個觸發程式。當無法使用多餘的計算容量，或 VM 的成本超過您設定的最大價格時，Azure 會收回現成 VM。此收回類型可讓您設定最高價格遠低於隨用隨付價格。使用此收回類型來設定您自己的價格上限。

收回原則

您為現成 VM 選擇的收回原則會影響其協調流程。協調流程是處理收回的程式，本文稍後會討論。收回原則是 停止/解除分配原則，以及 刪除原則。

停止/解除分配原則： 當工作負載可以等候相同位置和 VM 類型內的釋放容量時，停止/解除分配原則是理想的。 Stop/Deallocate 原則會停止 VM，並以基礎硬體結束其租用。停止和解除分配現成 VM 與停止和解除分配一般 VM 相同。 VM 仍可在 Azure 中存取，您稍後可以重新啟動相同的 VM。 VM 會因為停止/解除分配原則而失去計算容量和非靜態 IP 位址。不過，VM 數據磁碟會維持，並繼續產生費用。 VM 也會佔用訂用帳戶中的核心。即使 VM 已停止或解除分配，也無法從其區域或區域移動。如需詳細資訊，請參閱 Power states 和 billing。

刪除原則：如果工作負載可以變更位置或 VM 大小， 使用刪除原則。變更位置或 VM 大小可讓 VM 更快速地重新部署。刪除原則會刪除 VM 和任何數據磁碟。 VM 不會佔用訂用帳戶中的核心。如需詳細資訊，請參閱收回原則。

彈性協調流程的設計

協調流程是在收回后取代現成 VM 的程式。這是建置可靠中斷工作負載的基礎。良好的協調流程系統具有內建的彈性。彈性表示設計協調流程以有選項、使用多個 VM 大小、部署到不同的區域、擁有收回感知，以及考慮不同的收回案例，以改善工作負載可靠性和速度。

速度設計

對於在現成 VM 上執行的工作負載，計算容量至關重要。由於收回的可能性，請確定您瞭解已配置的計算時間，讓您可以做出明智的設計決策，以排定工作負載速度的優先順序。一般而言，您應該將擁有的計算時間優化。建置已預安裝所有必要軟體的 VM 映像。預安裝的軟體有助於將收回與完整運作應用程式之間的時間降至最低。避免在未參與工作負載用途的處理程式上使用計算時間。例如，數據分析的工作負載應該將大部分的計算時間集中在數據處理上，以及盡可能少地收集收回元數據的時間。從您的應用程式中排除無性進程。

使用多個 VM 大小和位置

若要提高彈性，請建置協調流程以使用多個 VM 類型和大小。目標是提供協調流程選項來取代收回的 VM。 Azure 具有不同類型的 VM 大小，可提供相同價格的類似功能。篩選最小 vCPU 或核心、VM 的最小 RAM，以及最高價格。此程式可協助您尋找符合預算的多個 VM，並有足夠的能力來執行您的工作負載。

每種類型的 VM 都有以百分比範圍表示的收回率，例如 0%-5%、5%-10%、10%-15%、15%-20%或 20+%。收回率可能會因區域而異。您可能會發現不同區域中相同類型 VM 的較佳收回率。您可以在入口網站的 [基本] 索引標籤下，找到每個 VM 類型的收回率。在 [大小旁，選取 [檢視 檢視定價歷程記錄 或 [查看所有大小]。您也可以使用 Azure Resource Graph 以程式設計方式取得現成 VM 數據。

在您的協調流程系統中，請考慮使用現成放置分數功能來評估個別現成部署成功的可能性。

如需詳細資訊，請參閱下列資源：

使用最具彈性的收回原則

收回的現成 VM 收回原則會影響取代程式。例如，刪除原則比停止/解除分配原則更有彈性。

請先考慮刪除原則： 如果您的工作負載可以處理刪除原則，請使用刪除原則。刪除可讓協調流程將取代現成 VM 部署到新的區域和區域。此部署彈性可協助您的工作負載尋找比已停止或已解除分配的 VM 更快的備用計算容量。已停止或解除分配的 VM 必須等候在建立所在的相同區域中備援計算容量。針對刪除原則，您需要外部程式來監視收回，並協調部署至各種區域、使用不同的 VM SKU，或兩者。
瞭解停止/解除分配原則： Stop/Deallocate 原則的彈性低於刪除原則。現成 VM 必須保留在相同的區域和區域中。您無法將已停止或已解除分配的 VM 移至另一個位置。因為 VM 有固定的位置，因此當計算容量可用時，您需要一些地方來重新配置 VM。無法預測計算容量的可用性。因此，您應該使用自動化排程管線在收回后嘗試重新部署。收回應該觸發排程管線，而重新部署嘗試應該持續檢查計算容量，直到它變成可用為止。

政策	使用原則的時機
刪除原則	- 暫時計算和數據 - 不想支付數據磁碟的費用 - 最低預算
停止/解除分配原則	- 需要特定的 VM 大小 - 無法變更位置 - 長時間的應用程式安裝程式 - 無限期等候時間 - 不受成本節省所驅動

持續監視收回

監視是現場 VM 工作負載可靠性的關鍵。現成 VM 在建立之後沒有 SLA，而且可以隨時收回。改善現場 VM 工作負載可靠性的最佳方式，是預期何時將收回工作負載。如果您有這項資訊，您可以嘗試工作負載正常關機並觸發自動化來協調取代。

使用排程事件： 針對每個 VM 使用排程的事件服務。當基礎結構維護會影響 VM 時，Azure 會將訊號傳送給 VM。收回符合基礎結構維護資格。 Azure 會先將 Preempt 訊號傳送給所有 VM，至少 30 秒才會被收回。排程的事件服務可讓您藉由查詢靜態、不可路由IP位址的端點 169.254.169.254來擷取此 Preempt 訊號。
使用頻繁的查詢： 查詢排程的事件端點通常足以協調正常關機。您可以查詢排程的事件端點最多每秒，但所有使用案例可能不需要一秒的頻率。這些查詢必須來自在現成 VM 上執行的應用程式。查詢不能來自外部來源。因此，查詢會耗用 VM 計算容量，並從主要工作負載竊取處理能力。您需要平衡這些競爭優先順序，以符合您的特定情況。
自動化協調流程： 收集 Preempt 訊號之後，協調流程應該在該訊號上採取行動。鑒於時間限制，Preempt 訊號應該嘗試正常關閉工作負載，並啟動取代現成 VM 的自動化程式。如需詳細資訊，請參閱下列資源：

建置部署系統

您的協調流程需要自動化管線，才能在收回後部署新的現成 VM。管線應該在可中斷的工作負載之外執行，以協助確保工作。部署管線應該根據您為現成 VM 選擇的收回原則運作。

針對刪除原則，建議您建置管線，以使用不同的 VM 大小並部署到不同的區域。針對停止/解除分配原則，部署管線需要兩個不同的動作。若要初始建立 VM，管線必須將正確的 VM 大小部署至正確的位置。針對收回的 VM，管線必須嘗試重新啟動 VM，直到它運作為止。 Azure 監視器警示和 Azure 函式的組合是自動化部署系統的一種方式。管線可以使用 bicep 範本。它們是宣告式和等冪性，代表基礎結構部署的最佳做法。

準備立即收回

Azure 可以在您建立現成 VM，並在工作負載執行之前立即收回現成 VM。在某些情況下，可能會有足夠的容量來建立現成 VM，但不會持續。建立后，現成 VM 沒有可用性保證或 SLA。您的協調流程必須考慮立即收回。 Preempt 訊號提供至少 30 秒的收回通知。

將 VM 健康情況檢查納入協調流程，以準備立即收回。立即收回的協調流程不能取決於已排程的事件 Preempt 訊號。只有 VM 本身可以查詢 Preempt 訊號，而且沒有足夠的時間啟動應用程式、查詢排程的事件端點，以及正常關閉。因此，健康情況檢查必須位於工作負載環境之外。健康狀態檢查需要監視現成 VM 的狀態，並啟動部署管線，以在狀態變更為 解除分配 或停止時取代現成 VM。

規劃多個同時收回

如果您執行現成 VM 的叢集，請建構工作負載以承受多個同時收回。工作負載中的多個現成 VM 可以同時收回。同時收回多個 VM 可能會影響應用程式的輸送量。若要避免這種情況，您的部署管線應該能夠收集來自多個 VM 的訊號，並同時部署多個替代 VM。

正常關機的設計

VM 關機程式應該小於 30 秒，並允許 VM 在收回之前關閉。關機的時間量取決於工作負載查詢排程事件端點的頻率。您查詢端點的頻率愈高，關機程式所花費的時間越長。關機程式應該釋放資源、清空連線，以及排清事件記錄檔。您應該定期建立並儲存檢查點，以保留內容並建立更有效率的復原策略。檢查點只是下一個 VM 需要啟動之進程或交易的相關信息。它們應該指出 VM 是否應該在先前的 VM 中斷位置繼續，或新的 VM 是否應該還原變更，然後再次啟動整個程式。將檢查點儲存在現成 VM 環境之外，例如在記憶體帳戶中。

測試協調流程

模擬收回事件，以在開發/測試環境中測試協調流程。如需詳細資訊，請參閱模擬收回。

設計等冪工作負載

建議您設計等冪工作負載。處理事件的結果應該與一次處理事件的結果相同。儘管努力確保正常關機，但收回可能會導致強制關機。強制關機可以在完成之前終止進程。等冪工作負載可以多次接收相同的訊息，而不會變更結果。如需詳細資訊，請參閱等冪。

使用應用程式熱身期間

大部分可中斷的工作負載都會執行應用程式。應用程式需要時間來安裝和啟動。它們也需要時間才能連線到外部記憶體，並從檢查點收集資訊。在您允許應用程式開始處理之前，請先有應用程式熱身期間。在熱身期間，應用程式應該啟動、建立連線，並準備參與。在您驗證應用程式的健康情況之後，只允許應用程式開始處理數據。

設定使用者指派的受控識別

指派使用者指派的受控識別，以簡化驗證和授權程式。使用者指派的受控識別可讓您避免將認證放入程式代碼中，而且不會繫結至單一資源，例如系統指派的受控識別。使用者指派的受控識別包含來自 Microsoft Entra 識別碼的許可權和存取令牌，可在協調流程期間重複使用並指派這些令牌來找出 VM。跨現成 VM 的令牌一致性有助於簡化協調流程，並簡化對現成 VM 所具備工作負載資源的存取。

如果您使用系統指派的受控識別，新的現成 VM 可能會從 Microsoft Entra ID 取得不同的存取令牌。如果您需要使用系統指派的受控識別，讓工作負載能夠復原 403 Forbidden Error 回應。您的協調流程必須取得具有正確許可權Microsoft Entra標識符的令牌。如需詳細資訊，請參閱受控識別。

範例案例

此範例案例會部署佇列處理應用程式，其限定為可中斷的工作負載。案例中的腳本可作為範例。此案例會引導您完成一次性手動推送以部署資源。此實作沒有部署管線。不過，部署管線是自動化協調程式的必要條件。下圖顯示範例案例的架構。

下載此架構的 Visio 檔案。

下列工作流程對應至上圖：

VM 應用程式定義： AZURE 計算資源庫中會建立 VM 應用程式定義。它會定義應用程式名稱、位置、操作系統和元數據。應用程式版本是 VM 應用程式定義的編號版本。應用程式版本代表 VM 應用程式。它必須位於與現成 VM 相同的區域中。應用程式版本會連結至記憶體帳戶中的來源應用程式套件。
記憶體帳戶： 記憶體帳戶會儲存來源應用程式套件。在此架構中，它是名為 worker-0.1.0.tar.gz的壓縮 tar 檔案。其中包含兩個檔案。其中一個檔案是安裝 .NET 背景工作應用程式的 orchestrate.sh bash 腳本。
現成 VM： 現成 VM 部署。它必須位於與應用程式版本相同的區域中。它會在部署後將 worker-0.1.0.tar.gz 下載至 VM。 bicep 範本會在標準系列 VM 上部署 Ubuntu 映射。這些設定符合此應用程式的需求，而且不是應用程式的一般建議。
記憶體佇列： .NET 背景工作角色中執行的其他服務包含消息佇列邏輯。 Microsoft Entra ID 會使用角色型訪問控制，將現成 VM 存取權授與 Azure 佇列記憶體中具使用者指派身分識別的現成 VM 存取權。
.NET 背景工作角色應用程式：orchestrate.sh 腳本會安裝執行兩個背景服務的 .NET 背景工作應用程式。第一個服務會查詢已排程的事件端點、尋找 Preempt 訊號，並將此訊號傳送至第二個服務。第二個服務會處理來自記憶體佇列的訊息，並接聽來自第一個服務的 Preempt 訊號。當第二個服務收到訊號時，它會中斷記憶體佇列處理，並開始關閉。
查詢排程事件端點： API 要求會傳送至靜態不可路由 IP 位址 169.254.169.254。 API 要求會查詢已排程的事件端點，以取得基礎結構維護訊號。
Application Insights： 架構只會針對學習目的使用 Application Insights。這不是可中斷工作負載協調流程的基本元件，但可讓您驗證來自 .NET 背景工作角色應用程式的遙測。 .NET 背景工作應用程式會將遙測傳送至 Application Insights。如需詳細資訊，請參閱從 .NET 應用程式啟用即時計量。

部署此案例

GitHub 標誌有一個稱為可中斷工作負載的 GitHub 存放庫，其有範本、腳本和部署此架構的逐步指示。

下一步

Spot 虛擬機

共用方式為