Azure 虛擬機器 基準架構

本文提供部署在 Azure 虛擬機器 上的工作負載的基礎參考架構。

此架構假設的範例工作負載是因特網面向的多層式 Web 應用程式，部署在個別的虛擬機集 （VM） 上。 VM 會布建為 Azure 虛擬機器擴展集 部署的一部分。 此架構可用於下列案例：

• 私人應用程式。 這些應用程式包括內部企業營運應用程式或現成的商業解決方案。
• 公用應用程式。 這些應用程式是因特網面向的應用程式。 此架構不適用於高效能運算、任務關鍵性工作負載、受到延遲或其他特殊使用案例影響的應用程式。

此架構的主要焦點不是應用程式。 相反地，本文提供設定和部署應用程式互動之基礎結構元件的指引。 這些元件包括計算、記憶體、網路和監視元件。

此架構可作為基礎結構即服務 （IaaS） 裝載工作負載的起點。 數據層會刻意從本指南中排除，以維護計算基礎結構的焦點。

文章版面配置

架構	設計決策	架構完善的架構方法
▪ 架構圖 ▪ 工作負載資源 ▪ 支持資源 ▪ 使用者流程	▪ VM 設計選擇 ▪ 磁碟 ▪ 聯網 ▪ 監測 ▪ 更新管理	▪ 可靠性 ▪ 安全 ▪ 成本優化

架構

下載此架構的 Visio 檔案。

如需這些資源的相關信息，請參閱相關資源中列出的 Azure 產品檔。

元件

此架構包含數個適用於工作負載資源和工作負載支持資源的 Azure 服務。 下列各節將說明每個及其角色的服務。

工作負載資源

• Azure 虛擬機器 可作為應用程式的計算資源，並分散於可用性區域。 為了說明目的，會使用 Windows 和 Linux VM 的組合。

  彈性協調流程模式中的 Azure 虛擬機器擴展集 可用來布建和管理 VM。

  範例應用程式可以以兩個層級來表示，每個層都需要自己的計算。

  • 前端會執行網頁伺服器並接收使用者要求。
  • 後端會執行另一部做為 Web API 的 Web 伺服器，以公開執行商業規則的單一端點。

  前端 VM 已連結資料磁碟（Premium_LRS），可用來部署無狀態應用程式。 後端 VM 會將數據保存在Premium_ZRS 本機磁碟 ，作為其作業的一部分。 此配置可以擴充為包含資料庫層，以儲存前端和後端計算的狀態。 該層超出此架構的範圍。

• Azure 虛擬網絡 為所有工作負載資源提供專用網。 網路會分割成子網，做為隔離界限。

• Azure 應用程式閘道 是將要求路由傳送至前端伺服器的單一輸入點。 選取的 SKU 包含整合式 Azure Web 應用程式防火牆 （WAF），以取得額外的安全性。

• 內部 Azure Load Balancer 會將流量從前端層路由傳送至後端伺服器。

• Azure Load Balancer Standard SKU 會使用三個公用 IP 位址，為 VM 提供輸出因特網存取。

• Azure 金鑰保存庫 會儲存用於端對端傳輸層安全性 （TLS） 通訊的憑證。 它也可用於應用程式秘密。

工作負載支持資源

• Azure Bastion 提供透過安全通訊協定對 VM 的操作存取。

• Application Insights 會從應用程式收集記錄和計量。 由於應用程式不是此架構的重點，因此實作中不會示範記錄收集。

• Log Analytics 是監視數據接收，可從 Azure 資源和 Application Insights 收集記錄和計量。 記憶體帳戶會布建為工作區的一部分。

使用者流程

有兩種類型的使用者與工作負載資源互動： 工作負載使用者 和 操作員。 這些使用者的流程會顯示在上述架構圖表中。

工作負載使用者

1. 用戶會使用公開 應用程式閘道的公用IP位址來存取網站。

2. 應用程式閘道 接收 HTTPS 流量、使用外部憑證解密數據以進行 WAF 檢查，並使用內部通配符憑證重新加密數據，以傳輸至前端。

3. 應用程式閘道 平衡前端 VM 之間的流量，並將要求轉送至前端 VM。

4. 選取的前端 VM 會使用負載平衡器的私人 IP 位址，而不是任何個別 VM 的 IP，與後端 VM 通訊。 此通訊也會使用內部通配符憑證進行加密。

5. 後端 VM 會使用內部憑證來解密要求。 後端處理要求之後，它會將結果傳回前端，將結果傳回至應用程式網關，最後會將結果傳回給使用者。

運算子

此架構中的 VM 可能需要操作員的直接存取，但我們建議透過自動化將遠端訪問降至最低，並監視該存取。 存取權可能適用於中斷修正情況、疑難解答或自動化部署程式的一部分。 此架構沒有用於控制平面存取的公用IP。 Azure Bastion 可作為無伺服器閘道，可讓作業透過 SSH 或 RDP 存取 VM。 此設定可確保安全且有效率的存取管理。

1. 操作員會登入 Azure 入口網站 或 Azure CLI。
2. 操作員會存取 Azure Bastion 服務，並從遠端連線到所需的 VM。

VM 設計選擇

選取 SKU 時，請務必有基準效能預期。 數個特性會影響決策程式，包括：

• 每秒 CPU、記憶體和磁碟輸入/輸出作業 （IOPS）。
• 處理器架構。
• 操作系統 （OS） 映射大小。

例如，如果您要從需要 Intel 處理器機器的內部部署環境移轉工作負載，請選擇支援 Intel 處理器的 VM SKU。

如需支援的 VM SKU 相關信息，請參閱 Azure 中虛擬機的大小。

啟動

VM 通常需要啟動，這是 VM 準備並微調以執行應用程式的程式。 常見的啟動載入工作包括：安裝憑證、設定遠端訪問、安裝套件、微調和強化OS設定，以及格式化和掛接數據磁碟。 請務必盡可能自動化啟動載入程式，讓應用程式可以在 VM 上啟動，而不需要延遲或手動介入。 以下是自動化的建議：

• 虛擬機擴充功能。 這些擴充功能是透過基礎結構即程序代碼 （IaC） 部署所管理的 Azure Resource Manager 物件。 如此一來，任何失敗會回報為您可以採取動作的失敗部署。 如果您的啟動載入需求沒有擴充功能，請建立自定義腳本。 建議您透過 Azure 自定義腳本擴充功能執行腳本。

  以下是一些其他擴充功能，可用來在 VM 上自動安裝或設定功能。

  • Azure 監視器代理程式 （AMA） 會從客體OS收集監視數據，並將其傳遞給 Azure 監視器。
  • Azure 自定義腳本擴充功能 （Windows， Linux） 第 2 版會在 Azure 虛擬機 （VM） 上下載並執行腳本。 此擴充功能適用於自動化部署後設定、軟體安裝或任何其他設定或管理工作。
  • Azure 金鑰保存庫 虛擬機擴充功能 （Windows， Linux） 藉由偵測變更並安裝對應的憑證，來自動重新整理儲存在 金鑰保存庫 中的憑證。
  • 當 Azure 虛擬機器擴展集 執行自動滾動升級時，具有 虛擬機器擴展集 的應用程式健康情況擴充功能很重要。 Azure 依賴個別實例的健康情況監視來執行更新。 您也可以使用擴充功能來監視擴展集中每個實例的應用程式健康情況，並使用自動實例修復來執行實例修復。
  • Microsoft Entra ID 和 OpenSSH （Windows， Linux） 與 Microsoft Entra 驗證整合。 您現在可以使用 Microsoft Entra ID 作為核心驗證平臺，以及使用 Microsoft Entra ID 和 OpenSSH 憑證型驗證，透過 SSH 連線到 Linux VM 的證書頒發機構單位。 此功能可讓您使用 Azure 角色型存取控制 （RBAC） 和條件式存取原則來管理對 VM 的存取。

• 代理程式型設定。 Linux VM 可以使用各種 Azure 提供的 VM 映像上透過 cloud-init 提供的羽量型原生預期狀態設定。 設定是使用您的 IaC 成品來指定並建立版本。 自備設定管理解決方案是另一種方式。 大部分的解決方案都遵循宣告式優先的啟動載入方法，但確實支援自定義腳本以取得彈性。 熱門選項包括適用於 Windows 的 Desired 狀態設定、適用於 Linux 的 Desired 狀態設定、Ansible、Chef、Puppet 等。 所有這些設定解決方案都可以與 VM 擴充功能配對，以獲得最佳體驗。

在參考實作中，所有啟動載入都是透過 VM 擴充功能和自定義腳本來完成，包括自動化數據磁碟格式和掛接的自定義腳本。

請參閱架構完善的架構： RE：02 - 自動化設計的建議。

VM 連線能力

若要在特定虛擬網路中啟用 VM 與其他裝置之間的私人通訊，VM 的網路介面卡 （NIC） 會連線到虛擬網路的其中一個子網。 如果您需要 VM 的多個 NIC，請知道每個 VM 大小的 NIC 數目上限。

如果工作負載在虛擬網路中的 VM 之間需要低延遲的通訊，請考慮使用 Azure VM NIC 支援的加速網路功能。 如需詳細資訊，請參閱 加速網路的優點。

使用彈性協調流程 虛擬機器擴展集

VM 會布建為具有彈性協調流程 虛擬機器擴展集 的一部分。 虛擬機器擴展集 是用來符合商務需求的 VM 邏輯群組。 群組中的 VM 類型可以相同或不同。 其可讓您使用標準 Azure VM API 和命令來管理機器、網路介面和磁碟的生命週期。

彈性協調流程模式可協助大規模作業，並協助進行細微調整決策。

需要容錯網域設定，以限制實體硬體故障、網路中斷或電源中斷的影響。 使用擴展集，Azure 會將實例平均分散到容錯網域，以針對單一硬體或基礎結構問題進行復原。

建議您將容錯網域配置卸除至 Azure，以取得最大實例分散、增強復原能力和可用性。

Disks

若要執行 OS 和應用程式元件，記憶體磁碟會連結至 VM。 請考慮針對OS使用暫時磁碟，並將受控磁碟用於數據記憶體。

Azure 提供一系列效能、多功能性和成本的選項。 從大部分生產工作負載的進階 SSD 開始。 您的選擇取決於 VM SKU。 支援進階 SSD 的 SKU 包含 資源名稱中的 s ，例如 Dsv4 而非 Dv4。

如需磁碟選項的詳細資訊，以及容量、IOPS 和輸送量等計量，請參閱 磁碟類型比較。

選取磁碟時，請考慮磁碟特性和效能預期。

• VM SKU 限制。 磁碟會在所連結的 VM 內運作，其具有 IOPS 和輸送量限制。 請確定磁碟未限制 VM 的限制，反之亦然。 選取以最佳方式執行應用程式元件的磁碟大小、效能和 VM 功能（核心、CPU、記憶體）。 避免過度布建，因為它會影響成本。

• 組態變更。 您可以在 VM 執行時變更一些磁碟效能和容量設定。 不過，許多變更可能需要重新布建和重建磁碟內容，因而影響工作負載可用性。 因此，請仔細規劃磁碟和 VM SKU 選項，以將可用性影響降到最低並重新作業。

• 暫時的OS磁碟。 將OS磁碟布建為 暫時磁碟。 只有在需要保存 OS 檔案時，才使用受控磁碟。 避免使用暫時磁碟來儲存應用程式元件和狀態。

  暫時OS磁碟的容量取決於所選的VM SKU。 請確定您的 OS 映射磁碟大小小於 SKU 的可用快取或暫存磁碟。 您可以使用剩餘空間來儲存暫存空間。

• 磁碟效能。 根據尖峰負載預先布建磁碟空間很常見，但可能會導致使用量過低的資源，因為大部分的工作負載不會維持尖峰負載。

  監視工作負載的使用模式、指出尖峰或持續的高讀取作業，並將這些模式納入您的 VM 和受控磁碟 SKU 選取範圍。

  您可以變更 效能層級 ，或使用 某些受控磁碟 SKU 中所提供的高載功能 ，視需要調整效能。

  過度布建可減少高載的需求，但可能會導致您支付的未使用容量。 在理想情況下，請結合這兩個功能以獲得最佳結果。

• 微調工作負載的快取。 根據應用程式元件使用量設定所有磁碟的快取設定。

  主要執行讀取作業的元件不需要高磁碟交易一致性。 這些元件可以受益於唯讀快取。 需要高磁碟交易一致性的大量寫入元件通常會停用快取。

  如果 VM 當機，而且不建議在大部分的數據磁碟案例中，使用讀寫快取可能會導致數據遺失。

在此架構中：

• 所有 VM 的 OS 磁碟都是暫時的，且位於快取磁碟上。

  前端 （Linux） 和後端 （Windows Server） 中的工作負載應用程式能夠容忍個別 VM 失敗，而且都使用小型映像（約 30 GB）。 這類屬性可讓它們符合使用在 VM 本機記憶體（快取分割區）中建立的暫時 OS 磁碟，而不是儲存在遠端 Azure 記憶體資源中的永續性 OS 磁碟。 這種情況不會產生 OS 磁碟的記憶體成本，也藉由提供較低的延遲並減少 VM 部署時間來改善效能。

• 每個 VM 都有自己的進階 SSD P1 受控磁碟，提供適合工作負載的基底布建輸送量。

網路配置

此架構會在單一虛擬網路中部署工作負載。 網路控制是此架構的重要部分，如安全性一節所述。

此配置可以與企業拓撲整合。 該範例會顯示在 Azure 登陸區域的虛擬機基準架構中。

虛擬網路

您的其中一個初始網路配置決策與網路位址範圍相關。 請記住容量規劃階段的預期網路成長。 網路應該夠大，才能維持成長，這可能需要額外的網路建構。 例如，虛擬網路應該具有容量來容納因調整作業而產生的其他 VM。

相反地，將您的位址空間大小正確。 過度大型的虛擬網路可能會導致使用量過低。 請務必注意，建立虛擬網路之後，就無法修改位址範圍。

在此架構中，位址空間會設定為 /21，這是根據預測成長的決策。

子網考慮

在虛擬網路內，子網會根據功能和安全性需求進行分割，如下所述：

• 裝載應用程式閘道的子網，可作為反向 Proxy。 應用程式閘道 需要專用子網。
• 用來裝載內部負載平衡器的子網，用於將流量分散到後端 VM。
• 用來裝載工作負載 VM 的子網，一個用於前端，另一個用於後端。 這些子網會根據應用程式的層來建立。
• Azure Bastion 主機的子網，可協助對工作負載 VM 的作業存取。 根據設計，Azure Bastion 主機需要專用的子網。
• 用來裝載私人端點的子網，用來透過 Azure Private Link 存取其他 Azure 資源。 雖然這些端點不需要專用子網，但建議使用它們。

類似於虛擬網路，子網的大小必須正確。 例如，您可能想要套用彈性協調流程所支援的 VM 上限，以符合應用程式的調整需求。 工作負載子網應該能夠容納該限制。

另一個需要考慮的使用案例是 VM OS 升級，這可能需要暫時 IP 位址。 正確重設大小可讓您藉由確定將類似的資源分組，讓透過網路安全組 （NSG） 有意義的安全性規則可以套用至子網界限，以達到所需的分割層級。 如需詳細資訊，請參閱 安全性：分割。

輸入流量

兩個公用IP位址用於輸入流程。 其中一個位址適用於做為反向 Proxy 的 應用程式閘道。 使用者使用該公用IP位址進行連線。 反向 Proxy 負載平衡輸入流量至 VM 的私人 IP。 另一個位址是透過 Azure Bastion 進行作業存取。

下載此架構的 Visio 檔案。

輸出流量

此架構會使用標準 SKU Load Balancer 搭配從 VM 實例定義的輸出規則。 已選擇Load Balancer，因為它是區域備援。

下載此架構的 Visio 檔案。

此設定可讓您使用負載平衡器的公用IP，為VM提供輸出因特網聯機。 輸出規則可讓您明確定義來源網路位址轉換 （SNAT） 埠。 這些規則可讓您透過手動埠配置來調整和調整這項功能。 根據後端集區大小和 數目 frontendIPConfigurations 手動配置 SNAT 埠，有助於避免 SNAT 耗盡。

建議您根據後端實例數目上限來配置埠。 如果新增的實例數目超過剩餘的 SNAT 埠允許，虛擬機器擴展集 調整作業可能會遭到封鎖，或新的 VM 未收到足夠的 SNAT 埠。

將每個實例的埠計算為： Number of front-end IPs * 64K / Maximum number of back-end instances。

您可以使用其他選項，例如部署連結至子網的 Azure NAT 閘道資源。 另一個選項是使用 Azure 防火牆 或其他網路虛擬設備搭配自定義使用者定義路由（UDR），作為下一個躍點通過防火牆。 此選項會顯示在 Azure 登陸區域的虛擬機基準架構中。

DNS 解析

Azure DNS 會作為所有解析使用案例的基礎服務，例如，解析與工作負載 VM 相關聯的完整功能變數名稱 （FQDN）。 在此架構中，VM 會使用虛擬網路組態中設定的 DNS 值，也就是 Azure DNS。

Azure 私人 DNS 區域可用來解析用來存取具名 Private Link 資源的私人端點要求。

監視

此架構具有與工作負載公用程式分離的監視堆疊。 焦點主要在於數據源和集合層面。

計量和記錄會在各種數據源產生，可在各種高度提供可觀察性深入解析：

• 基礎基礎結構和元件 會被視為 VM、虛擬網路和記憶體服務。 Azure 平台記錄提供 Azure 平臺內作業和活動的相關信息。

• 應用層級 可讓您深入了解系統上執行之應用程式的效能和行為。

Log Analytics 工作區是用來從 Azure 資源和 Application Insights 收集記錄和計量的建議監視數據接收。

下圖顯示基準的監視堆疊，其中包含從基礎結構和應用程式、數據接收和各種取用工具收集數據的元件，以進行分析和視覺效果。 實作會部署一些元件，例如 Application Insights、VM 開機診斷和 Log Analytics。 會描述其他元件來展示擴充性選項，例如儀錶板和警示。

下載此架構的 Visio 檔案。

基礎結構層級監視

下表連結至 Azure 監視器所收集的記錄和計量。 可用的警示可協助您在影響使用者之前主動解決問題。

Azure 資源	計量與記錄	警示
應用程式閘道	應用程式閘道 計量和記錄描述	應用程式閘道 警示
Application Insights	Application Insights 計量和記錄 API	Application Insights 警示
Azure Bastion	Azure Bastion 計量
金鑰保存庫	金鑰保存庫 計量和記錄描述	金鑰保存庫 警示
標準負載平衡器	負載平衡器記錄和計量	Load Balancer 警示
公用 IP 位址	公用IP位址計量和記錄描述	公用IP位址計量警示
虛擬網路	虛擬網路計量和記錄參考	虛擬網路警示
虛擬機器和 虛擬機器擴展集	VM 計量和記錄參考	VM 警示和教學課程
Web 應用程式防火牆	Web 應用程式防火牆計量和記錄描述	Web 應用程式防火牆 警示

如需收集計量和記錄成本的詳細資訊，請參閱Log Analytics成本計算和Log Analytics工作區的選項和定價。 工作負載的性質，以及收集的計量和記錄的頻率和數目，嚴重影響了計量和記錄收集成本。

虛擬機器

啟用 Azure 開機診斷 ，藉由收集序列記錄資訊和螢幕快照，在開機期間觀察 VM 的狀態。 在此架構中，該數據可透過 Azure 入口網站 和 Azure CLI vm boot-diagnostics get-boot-log 命令來存取。 數據是由 Azure 管理，而且您無法控制或存取基礎記憶體資源。 不過，如果您的商務需求需要更多控制權，您可以布建自己的記憶體帳戶來儲存開機診斷。

VM 深入解析 提供有效率的方式來監視 VM 和擴展集。 它會從 Log Analytics 工作區收集數據，並提供預先定義的活頁簿來呈現效能數據趨勢。 此數據可以檢視每個 VM，或跨多個 VM 匯總。

應用程式閘道 和內部負載平衡器會使用健康情況探查來偵測 VM 的端點狀態，再傳送流量。

網路

在此架構中，會從參與流程的數個網路元件收集記錄數據。 這些元件包括 應用程式閘道、負載平衡器和 Azure Bastion。 它們也包含網路安全性元件，例如虛擬網路、NSG、公用IP位址和 Private Link。

受控磁碟

磁碟計量取決於您的工作負載，需要混合密鑰計量。 監視應該結合這些檢視方塊來隔離OS或應用程式輸送量問題。

• Azure 平台檢視方塊代表指出 Azure 服務的計量，不論與其連線的工作負載為何。 您可以針對所有 VM 連結的磁碟，個別或集體檢視磁碟效能計量（IOPS 和輸送量）。 使用記憶體 IO 使用率計量來針對潛在磁碟上限進行疑難解答或警示。 如果您使用高載進行成本優化，請監視點數百分比計量，以找出進一步優化的機會。

• 客體OS檢視方塊代表工作負載操作員會檢視的計量，不論基礎磁碟技術為何。 建議針對連結磁碟上的重要計量使用 VM 深入解析，例如所使用的邏輯磁碟空間，以及 OS 核心對磁碟 IOPS 和輸送量的觀點。

應用層級監視

雖然參考實作並未使用它， 但 Application Insights 仍會布建為應用程式效能管理 （APM），以達到擴充性目的。 Application Insights 會從應用程式收集數據，並將該數據傳送至 Log Analytics 工作區。 它也可將工作負載應用程式的數據可視化。

應用程式健康情況 擴充 功能會部署到 VM，以監視擴展集中每個 VM 實例的二進位健康情況狀態，並視需要使用擴展集自動實例修復來執行實例修復。 它會測試與 應用程式閘道和內部 Azure 負載平衡器健康情況探查相同的檔案，以檢查應用程式是否回應。

更新管理

VM 必須定期更新和修補，這樣它們就不會削弱工作負載的安全性狀態。 建議您進行自動和定期的 VM 評量，以便早期探索和套用修補程式。

基礎結構更新

Azure 會定期更新其平臺，以增強虛擬機主機基礎結構的可靠性、效能和安全性。 這些更新包括修補裝載環境中的軟體元件、升級網路元件或解除委任硬體等等。 如需更新程式的相關信息，請參閱 Azure 中虛擬機的維護。

如果更新不需要重新啟動，則在更新主機時，VM 會暫停，或將 VM 實時移轉至已更新的主機。 如果維護需要重新啟動，您會收到計劃性維護的通知。 Azure 也提供一個時間範圍，可讓您在方便時開始維護。 如需自我維護期間以及如何設定可用選項的資訊，請參閱 處理計劃性維護通知。

某些工作負載可能無法容忍數秒的 VM 凍結或中斷連線以進行維護。 如需更充分控制所有維護活動，包括零影響和無重新啟動更新，請參閱 維護設定。 建立維護設定可讓您選擇略過所有平臺更新，並在方便時套用更新。 設定此自定義設定時，Azure 會略過所有非零影響更新，包括無重新啟動更新。 如需詳細資訊，請參閱 使用維護設定管理平臺更新

操作系統 （OS） 映射升級

執行OS升級時，具有經過測試的黃金映像。 請考慮使用 Azure 共用映像庫 和 Azure 計算資源庫發佈自定義映像。 您應該已備妥程式，每次發行者發佈新的映像時，都會以滾動方式升級實例批次。

在 VM 映射到達生命週期結束之前，先淘汰 VM 映射，以減少介面區。

您的自動化程式應該考慮過度布建的額外容量。

您可以使用 Azure 更新管理 來管理 Azure 中 Windows 和 Linux 虛擬機的操作系統更新。Azure Update Manager 提供 SaaS 解決方案，管理跨 Azure、內部部署和多重雲端環境的 Windows 和 Linux 機器軟體更新。

客體OS修補

Azure VM 提供自動 VM 客體修補的選項。 啟用此服務時，會定期評估 VM，並分類可用的修補程式。 建議啟用評定模式，以允許對擱置的修補程式進行每日評估。 不過，您可以執行隨選評定，這不會觸發修補程式的套用。 如果未啟用評定模式，請以手動方式偵測擱置的更新。

只有分類為 重要 或 安全性 的修補程式會自動套用到所有 Azure 區域。 定義套用其他修補程式的自定義更新管理程式。

針對治理，請考慮在 虛擬機器擴展集 Azure 原則 上要求自動修補 OS 映射。

自動修補可能會給系統帶來負擔，而且可能會造成干擾，因為 VM 會使用資源，而且可能會在更新期間重新啟動。 建議過度布建以用於負載管理。 在不同的 可用性區域 中部署 VM，以避免並行更新，並維護每個區域的至少兩個實例，以提供高可用性。 相同區域中的 VM 可能會收到不同的修補程式，這應該經過一段時間的協調。

請注意與過度布建相關聯的成本取捨。

健康情況檢查包含在自動 VM 客體修補的一部分。 這些檢查會確認修補程式應用程式是否成功，並偵測問題。

如果有自定義程式可套用修補程式，請使用私人存放庫來取得修補程式來源。 這樣做可讓您更妥善地控制測試修補程式，以確保更新不會對效能或安全性造成負面影響。

如需詳細資訊，請參閱 Azure VM 的自動 VM 客體修補。

可靠性

此架構會使用可用性區域作為基礎元素，以解決可靠性考慮。

在此設定中，個別 VM 會系結至單一區域。 如果發生失敗，可以使用 虛擬機器擴展集，將這些 VM 立即取代為其他 VM 實例。

此架構中的所有其他元件都是：

• 區域備援，這表示會跨多個區域複寫以提供高可用性，例如 應用程式閘道 或公用IP。
• 區域復原，表示它們可以承受區域失敗，例如 金鑰保存庫。
• 跨區域或全域可用的區域或全域資源，例如Microsoft Entra ID。

工作負載設計應該在應用程式程式代碼、基礎結構和作業中納入可靠性保證。 下列各節說明一些策略，以確保工作負載能夠復原失敗，而且如果基礎結構層級發生中斷，就能復原。

架構中使用的策略是以 Azure Well-Architected Framework 中提供的可靠性設計檢閱檢查清單為基礎。 這些區段會加上該檢查清單的建議批注。

由於未部署任何應用程式，因此應用程式程式代碼中的復原能力超出此架構的範圍。 建議您檢視檢查清單中的所有建議，並視需要在您的工作負載中加以採用。

排定每位使用者流程的可靠性保證優先順序

在大部分的設計中，都有多個使用者流程，每個流程都有自己的一組商務需求。 並非所有流程都需要最高層級的保證，因此建議分割為可靠性策略。 每個區段都可以獨立管理，確保一個區段不會影響其他人，並在每一層中提供正確的復原層級。 此方法也會讓系統具有彈性。

在此架構中，應用層會實作分割。 系統會針對前端和後端層布建個別的擴展集。 此區隔可獨立調整每一層，以根據其特定需求實作設計模式，以及其他優點。

請參閱架構完善的架構： RE：02 - 識別和評等流程的建議。

識別潛在的失敗點

每個架構都容易受到失敗的影響。 失敗模式分析的練習可讓您預期失敗，並備妥風險降低措施。 以下是此架構中的一些潛在失敗點：

元件	風險	可能性	效果/風險降低/附注	Outage
Microsoft Entra ID	設定錯誤	中	Ops 用戶無法登入。 沒有下游效果。 技術支援中心向身分識別小組回報設定問題。	無
應用程式閘道	設定錯誤	中	部署期間應該攔截設定錯誤。 如果在設定更新期間發生這些錯誤，DevOps 小組必須回復變更。 大部分使用 v2 SKU 的部署大約需要 6 分鐘才能佈建。 不過，視部署類型而定，可能需要更長的時間。 例如，部署到具有許多執行個體的多個可用性區域時，可能需要花費超過 6 分鐘。	完整
應用程式閘道	DDoS 攻擊	中	可能中斷。 Microsoft管理 DDoS （L3 和 L4） 保護。 L7 攻擊的潛在影響風險。	完整
虛擬機器擴展集	服務中斷	低	如果觸發自動修復的 VM 實例狀況不良，可能會中斷工作負載。 相依於要補救的Microsoft。	潛在中斷
虛擬機器擴展集	可用性區域中斷	低	沒有影響。 擴展集會部署為區域備援。	無

請參閱架構完善的架構： RE：03 - 執行失敗模式分析的建議。

可靠性目標

若要做出設計決策，請務必計算可靠性目標，例如工作負載的複合服務等級目標（SLO）。 這樣做牽涉到了解架構中使用的 Azure 服務所提供的服務等級協定（SLA）。 工作負載 SLA 不得高於 Azure 所保證的 SLA。 仔細檢查每個元件，從 VM 及其相依性、網路和記憶體選項。

以下是主要目標是提供近似複合 SLO 的範例計算。 雖然這是一個粗略的指導方針，但您應該到達類似的內容。 除非您對架構進行修改，否則不應該為相同的流程取得較高的複合 SLO 上限。

作業流程

元件	SLO
Microsoft Entra ID	99.99%
Azure Bastion	99.95%

複合 SLO：99.94% |每年停機：0d 5h 15m 20s

應用程式使用者流程

元件	SLO
應用程式閘道	99.95%
Azure Load Balancer （内部）	99.99%
使用進階記憶體的前端 VM（複合 SLO）	99.70%
使用進階記憶體的後端 VM（複合 SLO）	99.70%

複合 SLO：99.34% |每年停機：2d 9h 42m 18s

在上述範例中，會包含 VM 和相依性的可靠性，例如與 VM 相關聯的磁碟。 與磁碟記憶體相關聯的 SLA 會影響整體可靠性。

計算複合 SLO 時有一些挑戰。 請務必注意，不同的服務層級可能會隨附不同的 SLA，而這些層級通常包含可設定可靠性目標的財政支持保證。 最後，可能有未定義 SLA 的架構元件。 例如，就網路而言，NIC 和虛擬網路沒有自己的 SLA。

商務需求及其目標必須清楚定義並納入計算。 請注意組織所強加的服務限制和其他限制。 與其他工作負載共用您的訂用帳戶可能會影響 VM 可用的資源。 工作負載可能會允許使用 VM 可用的有限核心數目。 瞭解訂用帳戶的資源使用量，可協助您更有效率地設計 VM。

請參閱架構完善的架構： RE：04 - 定義可靠性目標的建議。

備援

此架構會針對數個元件使用區域備援。 每個區域皆由一或多個配備獨立電力、冷卻系統及網路功能的資料中心所組成。 在個別區域中執行實例可保護應用程式免於資料中心失敗。

• 虛擬機器擴展集 配置指定的實例數目，並將其平均分散到可用性區域和容錯網域。 此分佈是透過 最大分散 功能達成，我們建議使用此功能。 將 VM 實例分散到容錯網域可確保所有 VM 不會同時更新。

  請考慮有三個可用性區域的案例。 如果您有三個實例，每個實例都會配置給不同的可用性區域，並放在不同的容錯網域中。 Azure 保證每個可用性區域中一次只會更新一個容錯網域。 不過，在某些情況下，跨三個可用性區域裝載 VM 的所有三個容錯網域都會同時更新。 所有區域和網域都會受到影響。 每個區域中至少有兩個實例會在升級期間提供緩衝區。

• 受控磁碟只能連結至相同區域中的 VM。 其可用性通常會影響 VM 的可用性。 針對單一區域部署，您可以將磁碟設定為備援，以承受區域性失敗。 在此架構中，數據磁碟會在後端 VM 上設定區域備援記憶體 （ZRS）。 需要復原策略才能利用可用性區域。 復原策略是重新部署解決方案。 理想情況下，在備妥的替代可用性區域中預先布建計算，即可從區域性失敗復原。

• 區域備援 應用程式閘道 或標準負載平衡器可以使用單一IP位址，將流量路由傳送到跨區域的VM，確保即使區域失敗也一樣。 這些服務會使用健康情況探查來檢查 VM 可用性。 只要區域中的一個區域仍可運作，儘管其他區域中可能會發生失敗，但路由仍會繼續。 不過，相較於區域內部路由，區域間路由的延遲可能會較高。

  此架構中使用的所有公用IP都是區域備援。

• Azure 提供區域復原服務，以提升可靠性，例如 金鑰保存庫。

• Azure 全域資源一律可供使用，並視需要切換至另一個區域，例如基礎識別提供者Microsoft Entra ID。

請參閱架構完善的架構： RE：05 - 設計備援的建議。

調整策略

若要防止服務等級降低和失敗，請確定可靠的調整作業。 水平調整工作負載（相應放大）、垂直（相應增加），或使用這兩種方法的組合。 使用 Azure 監視器自動調整 來布建足夠的資源，以支援應用程式的需求，而不需要配置超過所需的容量，並產生不必要的成本。

自動調整可讓您根據不同的事件類型定義不同的配置檔，例如時間、排程或計量。 計量型配置檔可以使用內建計量（主機型）或更詳細的計量（客體 VM 計量），需要安裝 Azure 監視器代理程式來收集它們。 每個配置檔都包含相應放大（增加）和相應縮小的規則（減少）。 請考慮根據設計配置檔探索所有不同的調整案例，並針對可能導致一系列相反的縮放事件的潛在迴圈條件進行評估。 Azure 監視器會先等候冷卻期間再調整，以嘗試減輕這種情況。

雖然彈性模式中的 Azure 虛擬機器擴展集 支援異質環境，但不支援自動調整多個配置檔。 如果您打算搭配多個 VM 類型使用自動調整，請考慮建立不同的擴展集以個別管理它們。

請考慮其他層面，例如啟動載入、正常關機、安裝工作負載及其所有相依性，以及在建立或刪除 VM 實例時進行磁碟管理。

具狀態工作負載可能需要額外管理需要超過工作負載實例的受控磁碟。 在調整事件底下，針對工作負載數據的一致性、同步處理、復寫和完整性，設計數據管理的工作負載。 針對這些案例，請考慮 將預先填入的磁碟新增至擴展集。 針對使用調整來防止存取數據時發生瓶頸的使用案例，請規劃數據分割和分區化。 如需詳細資訊，請參閱 自動調整最佳做法。

請參閱架構完善的架構： RE：06 - 設計可靠調整策略的建議。

自我修復和復原能力

自動修復實例會在 虛擬機器擴展集 中啟用，以自動復原 VM 失敗。 應用程式健康情況 擴充 功能會部署到 VM，以支援偵測沒有回應的 VM 和應用程式。 針對這些實例，會自動觸發修復動作。

請參閱架構完善的架構： 自我修復和自我保護的建議。

安全性

此架構說明 Azure 良好架構架構中所提供的安全性設計檢閱檢查清單中所提供的一些安全性保證。 這些區段會加上該檢查清單的建議批注。

安全性不只是指技術控制件。 建議您遵循整個檢查清單，以了解安全性要素的操作層面。

分割

• 網路分割。 工作負載資源會放在虛擬網路中，以提供與因特網的隔離。 在虛擬網路內，子網可以當做信任界限使用。 共置處理一個子網中交易所需的相關資源。 在此架構中，虛擬網路會根據應用程式和作為工作負載一部分的各種 Azure 服務的邏輯群組，分成子網。

  子網分割的優點是您可以將安全性控制放在周邊，以控制進出子網的流量，進而限制對工作負載資源的存取。

• 身分識別分割。 將不同的角色指派給具有足夠許可權來執行其工作的不同身分識別。 此架構會使用 Microsoft Entra ID 所管理的身分識別來區隔資源的存取權。

• 資源分割。 應用程式會依階層分割成不同的擴展集，以確保不會共置應用程式元件。

請參閱架構完善的架構：SE： 04 - 建置分割策略的建議。

身分識別和存取管理

我們建議 Microsoft Entra ID ，以驗證和授權用戶和服務。

VM 的存取需要用戶帳戶，由Microsoft Entra ID 驗證控制，並由安全組支援。 此架構支援將Microsoft Entra ID驗證延伸模組部署到所有 VM。 我們建議人類用戶在組織的 Microsoft Entra ID 租使用者中使用其公司身分識別。 此外，請確定不會跨函式共用任何服務主體型存取。

工作負載資源，例如 VM，會使用指派的受控識別向其他資源進行自我驗證。 這些身分識別會根據Microsoft Entra ID 服務主體自動管理。

例如，金鑰保存庫 擴充功能會安裝在 VM 上，以就地啟動具有憑證的 VM。 在此架構中，應用程式閘道、前端 VM 和後端 VM 會使用使用者指派的受控識別來存取 金鑰保存庫。 這些受控識別會在部署期間設定，並用於針對 金鑰保存庫 進行驗證。 金鑰保存庫 上的存取原則設定為只接受上述受控識別的要求。

基準架構會混合使用系統指派和使用者指派的受控識別。 存取其他 Azure 資源時，必須使用這些身分識別Microsoft Entra ID 來進行授權。

請參閱架構完善的架構： SE：05 - 身分識別和存取管理的建議。

網路控制

• 輸入流量。 工作負載 VM 不會直接公開至公用因特網。 每個 VM 都有私人 IP 位址。 工作負載使用者會使用 應用程式閘道 的公用IP位址進行連線。

  透過與 應用程式閘道整合的 Web 應用程式防火牆 來提供更多安全性。 它有檢查輸入流量的規則，而且可以採取適當的動作。 WAF 會追蹤防止已知攻擊的開放式 Web 應用程式安全性專案 （OWASP） 弱點。

• 輸出流量。 除了 VM 子網上的輸出 NSG 規則之外，輸出流量沒有控制。 我們建議所有輸出因特網流量都流經單一防火牆。 此防火牆通常是組織提供的中央服務。 該使用案例會顯示在 Azure 登陸區域的虛擬機基準架構中。

• 東西交通。 子網之間的流量流量受限於套用細微的安全性規則。

  網路安全組會 根據IP位址範圍、埠和通訊協定等參數來限制子網之間的流量。 應用程式安全組 （ASG） 會放在前端和後端 VM 上。 它們會與 NSG 搭配使用，以篩選來自 VM 的流量。

• 操作流量。 我們建議透過 Azure Bastion 提供對工作負載的安全作業存取，以移除公用 IP 的需求。 在此架構中，該通訊是透過 SSH 進行，而且受到 Windows 和 Linux VM 的支援。 Microsoft Entra ID 會使用對應的 VM 擴充功能，與這兩種 VM 類型的 SSH 整合。 該整合可讓操作員的身分識別透過Microsoft Entra標識碼進行驗證和授權。

  或者，使用個別的 VM 作為跳躍方塊，部署至自己的子網，您可以在其中安裝您選擇的系統管理員和疑難解答工具。 操作員會透過 Azure Bastion 主機存取跳躍方塊。 然後，他們會從跳躍方塊登入負載平衡器後方的 VM。

  在此架構中，作業流量會使用NSG規則來保護流量，並在 VM上啟用 Just-In-Time （JIT） VM 存取 。 此功能 適用於雲端的 Microsoft Defender 允許對選取的埠進行暫時的輸入存取。

  若要增強安全性，請使用 Microsoft Entra Privileged Identity Management （PIM） 。 PIM 是一項Microsoft Entra 標識符中的服務，可讓您管理、控制及監視組織中重要資源的存取權。 PIM 提供以時間為基礎和以核准為基礎的角色啟用，可降低因重要資源上有過多、不必要或誤用的存取權限而帶來的風險。

• 平臺即服務的私人連線能力（PaaS） 服務。 VM 與 金鑰保存庫 之間的通訊是透過 Private Link。 此服務需要放置於個別子網中的私人端點。

• DDoS 保護。 請考慮在 應用程式閘道 和 Azure Bastion 主機公開的公用 IP 上啟用 Azure DDoS 保護，以偵測威脅。 DDoS 保護也會透過監視提供警示、遙測和分析。 如需詳細資訊，請參閱 Azure DDoS 保護：最佳做法和參考架構。

請參閱架構完善的架構： SE：06 - 網路和連線的建議。

加密

• 傳輸中的資料。 使用者與 應用程式閘道 公用IP之間的使用者流量會使用外部憑證加密。 應用程式閘道與前端 VM 之間的流量，以及前端和後端 VM 之間的流量會使用內部憑證加密。 這兩個憑證都會儲存在 金鑰保存庫：

  • app.contoso.com：用戶端和 應用程式閘道 用於安全公用因特網流量的外部憑證。
  • *.workload.contoso.com：基礎結構元件用來保護內部流量的通配符憑證。

• 待用資料。 記錄數據會儲存在連結至 VM 的受控磁碟。 該數據會在 Azure 上使用平臺提供的加密來自動加密。

請參閱架構完善的架構： SE：07 - 數據加密的建議。

秘密管理

下載此架構的 Visio 檔案。

金鑰保存庫 提供秘密的安全管理，包括 TLS 憑證。 在此架構中，TLS 憑證會儲存在 金鑰保存庫 中，並由 應用程式閘道 和 VM 的受控識別在布建程式期間擷取。 初始設定之後，這些資源只會在重新整理憑證時存取 金鑰保存庫。

VM 會使用 金鑰保存庫 VM 擴充功能來自動重新整理受監視的憑證。 如果在本機證書存儲中偵測到任何變更，擴充功能會從 金鑰保存庫 擷取並安裝對應的憑證。 延伸模組支持憑證內容類型 PKCS #12 和 PEM。

請參閱架構完善的架構： SE：09 - 保護應用程式秘密的建議。

成本最佳化

工作負載需求必須滿足，請記住成本限制。 架構中使用的策略是以 Azure Well-Architected Framework 中提供的成本優化設計檢閱檢查清單為基礎。 本節說明優化成本的一些選項，並加上該檢查清單的建議批注。

元件成本

選取已針對工作負載優化的 VM 映像，而不是使用一般用途映像。 在此架構中，會針對 Windows 和 Linux 選擇相對較小的 VM 映射，每個映像都是 30 GB。 使用較小的映射時，具有磁碟的 VM SKU 也較小，因而降低成本、降低資源耗用量，以及更快的部署和開機時間。 優點是增強安全性，因為介面區減少。

實作大小限制的記錄輪替是另一個節省成本的策略。 它允許使用小型數據磁碟，這可能會導致成本較低。 此架構的實作會使用 4 GB 磁碟。

使用暫時 OS 磁碟也會導致節省成本並改善效能。 這些磁碟的設計目的是使用您已經支付的 VM 資源，因為它們會安裝在隨 VM 布建的快取磁碟上。 它可消除與傳統永續性磁碟相關聯的記憶體成本。 由於這些磁碟是暫時的，因此沒有與長期數據記憶體相關聯的成本。

請參閱架構完善的架構： CO：07 - 優化元件成本的建議。

流程成本

根據流程的關鍵性選擇計算資源。 針對設計為容許不確定長度的流程，請考慮使用具有 虛擬機器擴展集 彈性協調流程模式的現成 VM。 這種方法對於在低優先順序 VM 上裝載低優先順序流程可能有效。 此策略允許成本優化，同時仍符合不同流程的需求。

請參閱架構完善的架構： CO：09 - 優化流程成本的建議。

調整成本

如果主要成本驅動程式是實例數目，則藉由增加 VM 的大小或效能來相應增加可能會更有成本效益。 這種方法可能會導致在數個區域中節省成本：

• 軟體授權。 較大的 VM 可以處理更多工作負載，進而減少所需的軟體授權數目。
• 維護時間：較少的較大型 VM 可以降低營運成本。
• 負載平衡：較少的 VM 可能會導致負載平衡成本較低。 例如，在此架構中，有多層的負載平衡，例如前端的應用程式網關和中間的內部負載平衡器。 如果需要管理較高的實例數目，負載平衡成本會增加。
• 磁碟記憶體。 如果有具狀態的應用程式，更多實例需要更多連結的受控磁碟，增加記憶體成本。

請參閱架構完善的架構： CO：12 - 優化調整成本的建議。

營運成本

自動 VM 客體修補可減少手動修補的額外負荷，以及相關聯的維護成本。 此動作不僅有助於讓系統更安全，還能優化資源配置，以提升整體成本效益。

請參閱架構完善的架構： CO：13 - 優化人員時間的建議。

部署此案例

此參考架構的部署可在 GitHub 上取得。

相關資源

如需特定 Azure 服務的詳細數據，請參閱產品檔：

• Azure 虛擬機器
• Azure 虛擬機器擴展集
• Azure 虛擬網路
• Azure 應用程式閘道 Standard_v2
• Azure Load Balancer
• Azure Key Vault
• Azure Bastion
• Application Insights
• Log Analytics

後續步驟

檢閱顯示資料層選項的 IaaS 參考架構：

• 在 Azure 上使用 SQL Server 的 Windows N 層應用程式