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

Azure 虛擬機器

在本文中，我們將概述在 Azure 現成虛擬機（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 VM 定價工具來預估成本。如需詳細資訊，請參閱：

您也可以查詢 Azure 零售價格 API，以程式設計方式取得任何感興趣的 SKU 的現成定價。

瞭解可中斷的工作負載

可中斷的工作負載是現成 VM 的最佳使用案例。可中斷的工作負載有一些常見的特性。它們最少到沒有時間限制、組織優先順序低，以及處理時間短。他們會執行可能會突然停止並稍後繼續的程式，而不會損害必要的組織程式。可中斷工作負載的範例包括批處理應用程式、數據分析，以及為非生產環境建立持續整合持續部署代理程式的工作負載。這些功能與具有服務等級協定（SLA）、黏性會話和具狀態數據的一般或任務關鍵性工作負載形成對比。數據表提供這兩種工作負載類型的範例。

	可中斷的工作負載功能	一般工作負載功能
功能	最少到沒有時間限制低組織優先順序處理時間短	服務等級協定（SLA）黏性會話需求具狀態工作負載

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

瞭解收回

現成 VM 在建立後沒有服務等級協定（SLA），且隨時都無法存取計算。我們稱之為計算遺失收回。計算供需磁碟驅動器收回。當特定 VM 大小的需求超過特定層級時，Azure 會發現 VM 可供一般 VM 使用。需求是特定位置。區域 A 中的需求增加不會影響區域 B 中的現成 VM。

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

收回類型

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

容量僅收回：當計算容量過剩消失時，此收回類型會觸發收回。根據預設，價格會以隨用隨付率上限。當您願意支付隨用隨付 VM 價格時，請使用此收回類型。

Price 或容量收回：此收回類型有兩個觸發程式。當計算容量過剩消失或 VM 成本超過您設定的最大價格時，Azure 會收回現成 VM。此收回類型可讓您設定最高價格遠低於隨用隨付價格。使用此收回類型來設定您自己的價格上限。

收回原則

為現成 VM 選擇的收回原則會影響其協調流程。藉由協調流程，我們表示處理收回的程式。我們稍後會詳細說明協調流程。收回原則是「停止/解除分配原則」和「刪除原則」。

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

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

彈性協調流程的設計

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

速度設計

對於在現成 VM 上執行的工作負載，計算容量是一個寶庫。收回的迫在眉睫潛力應提高您對配置計算時間的欣賞，並應轉譯為有意義的設計決策，以排定工作負載速度的優先順序。一般而言，您應該將計算時間優化。您應該使用預安裝的所有必要軟體來建置 VM 映像。預安裝的軟體有助於將收回與完全執行的應用程式之間的時間降到最低。您想要避免在不會造成工作負載用途的處理程式上使用計算時間。例如，數據分析的工作負載應該將大部分的計算時間放在數據處理上，以及盡可能少地收集收回元數據。從您的應用程式中排除無性進程。

使用多個 VM 大小和位置

建議您建置協調流程，以使用多個 VM 類型和大小來增加彈性。目標是提供協調流程選項來取代收回的 VM。 Azure 有不同的 VM 類型和大小，可提供相同價格的類似功能。您應該篩選 VM 最小 vCPU/Cores 和/或最小 RAM，以及最大價格，以尋找具有執行工作負載且符合預算的多個 VM。

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

此外，請考慮使用功能 Spot Placement Score 來評估個別 Spot 部署成功的可能性，作為協調流程系統的一部分。如需詳細資訊，請參閱：

使用最具彈性的收回原則

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

請先考慮刪除原則：如果您的工作負載可以處理刪除原則，建議您使用刪除收回原則。刪除可讓協調流程將取代現成 VM 部署到新的區域和區域。此部署彈性可協助您的工作負載尋找比已停止/已解除分配的 VM 更快的備用計算容量。已停止/已解除分配的 VM 必須等候其建立所在的相同區域中的備用計算容量。針對刪除原則，您需要一個程式來監視應用程式外部的收回，並協調部署至不同區域和/或使用不同的 VM SKU。

瞭解已停止/已解除分配的原則：已停止/已解除分配的原則彈性低於刪除原則。現成 VM 必須保留在相同的區域和區域中。您無法將已停止/已解除分配的 VM 移至另一個位置。因為 VM 有固定的位置，因此當計算容量可用時，您需要一些地方來重新配置 VM。無法預測計算容量的可用性。因此，您應該使用自動化排程管線在收回后嘗試重新部署。收回應該觸發排程管線，而重新部署嘗試應該持續檢查計算容量，直到它變成可用為止。

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

持續監視收回

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

使用排程的事件：針對每個 VM 使用排程的事件服務。當基礎結構維護會影響 VM 時，Azure 會將訊號傳送給 VM。收回符合基礎結構維護資格。 Azure 會在收回 VM 之前，至少 30 秒傳送 Preempt 訊號給所有 VM。稱為排程事件的服務可讓您藉由查詢靜態、不可路由IP位址的端點 169.254.169.254來擷取此 Preempt 訊號。

使用頻繁的查詢：查詢排程事件端點通常足以協調正常關機。您可以查詢排程的事件端點，最多每秒，但所有使用案例可能不需要一秒的頻率。這些查詢必須來自在現成 VM 上執行的應用程式。查詢不能來自外部來源。因此，查詢會耗用 VM 計算容量，並從主要工作負載竊取處理能力。您需要平衡這些競爭優先順序，以符合您的特定情況。

自動化協調流程：收集 Preempt 訊號后，協調流程應該在該訊號上採取行動。鑒於時間限制，Preempt 訊號應該嘗試正常關閉工作負載，並啟動取代現成 VM 的自動化程式。如需詳細資訊，請參閱：

建置部署系統

您的協調流程需要自動化管線，才能在收回時部署新的現成 VM。管線應該在可中斷的工作負載本身之外執行，以確保工作。部署管線的運作方式取決於您為現成 VM 選取的收回原則。

針對刪除原則，建議您建置管線，以使用不同的 VM 大小並部署到不同的區域。針對停止/已解除分配的原則，部署管線需要兩個不同的動作。若要初始建立 VM，管線必須將正確的 VM 大小部署至正確的位置。針對收回的 VM，管線必須嘗試重新啟動 VM，直到它運作為止。 Azure 監視器警示和 Azure Functions 的組合是自動化部署系統的數種方式之一。管線可以使用 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標識符的令牌。如需詳細資訊，請參閱受控識別。

範例案例

此範例案例會部署佇列處理應用程式，其限定為可中斷的工作負載。案例中的腳本是說明性的。此案例會逐步引導您完成一次性手動推送以部署資源。此實作沒有部署管線。但部署管線對於自動化協調程序至關重要。此圖說明範例案例的架構。

下列注意事項說明架構的重要層面：

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 會使用 RBAC，以使用者指派的身分識別，將現成 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 存放庫，可即時範本、腳本和部署此架構的逐步指示。

下一步

如需現成虛擬機的詳細資訊，請參閱 Azure Spot 虛擬機。

共用方式為