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

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 價格時，請使用此收回類型。

價格或容量收回：此收回 類型有兩個觸發程式。當計算容量過剩消失或 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 資料。如需詳細資訊，請參閱

使用最具彈性的收回原則

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

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

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

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

持續監視收回

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

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

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

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

建置部署系統

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

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

準備立即收回

您的現成 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 環境之外。儲存體帳戶可以運作。

測試協調流程

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

設計等冪工作負載

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

使用應用程式熱身期間

大部分可中斷的工作負載都會執行應用程式。應用程式需要時間來安裝和開機時間。他們需要時間連線到外部儲存體，並從檢查點收集資訊。建議您先有應用程式熱身期間，再允許它開始處理。在熱身期間，應用程式應開機、連線及準備參與。在驗證應用程式健康情況之後，您應該只允許應用程式開始處理資料。

Diagram of the workload lifecycle with an application warmup period

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

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

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

範例案例

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

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

VM 應用程式定義： VM 應用程式定義是在 Azure 計算資源庫中建立。它會定義應用程式名稱、位置、作業系統和中繼資料。應用程式版本是 VM 應用程式定義的編號版本。應用程式版本是 VM 應用程式的具現化。它必須位於與現成 VM 相同的區域中。應用程式版本會連結至儲存體帳戶中的來源應用程式套件。
儲存體帳戶： 儲存體帳戶會儲存來源應用程式套件。在此架構中，它是名為 worker-0.1.0.tar.gz 的壓縮 tar 檔案。其中包含兩個檔案。一個檔案是 orchestrate.sh 安裝 .NET 背景工作角色應用程式的 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 logo 我們已使用範本、腳本和部署此架構的逐步指示，在現場建立稱為可中斷工作負載的 GitHub 存放庫。您可以在此存放庫中找到更多有關架構和工程成品的技術詳細資料。

後續步驟

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