Share via

Azure 上任務關鍵性工作負載的應用程式平臺考慮

  • 發行項

Azure 提供許多計算服務來裝載高可用性應用程式。 服務的功能和複雜度不同。 建議您根據下列專案選擇服務：

  • 可靠性、可用性、效能和安全性的非功能需求。
  • 延展性、成本、操作性和複雜度等決策因素。

選擇應用程式裝載平臺是影響所有其他設計區域的重要決策。 例如，舊版或專屬的開發軟體可能不會在 PaaS 服務或容器化應用程式中執行。 這項限制會影響您選擇的計算平臺。

任務關鍵性應用程式可以使用多個計算服務來支援多個複合工作負載和微服務，每個都有不同的需求。

此設計區域提供與計算選取、設計和組態選項相關的建議。 我們也建議您熟悉 計算決策樹。

重要

本文是 Azure Well-Architected Framework 任務關鍵性工作負載 系列的一部分。 如果您不熟悉此系列，建議您從 什麼是任務關鍵性工作負載開始？。

平臺資源的全域散發

任務關鍵性工作負載的典型模式包括全域資源和區域資源。

未受限於特定 Azure 區域的 Azure 服務會部署或設定為全域資源。 某些使用案例包括將流量分散到多個區域、儲存整個應用程式的永久狀態，以及快取全域靜態資料。 如果您需要同時容納 縮放單位架構 和 全域散發，請考慮資源如何以最佳方式分散或複寫到 Azure 區域。

其他資源會以區域方式部署。 這些資源會部署為部署戳記的一部分，通常對應至縮放單位。 不過，區域可以有多個戳記，而且戳記可以有多個單位。 區域資源的可靠性很重要，因為它們負責執行主要工作負載。

下圖顯示高階設計。 使用者可透過中央全域進入點存取應用程式，然後將要求重新導向至適當的區域部署戳記：

顯示任務關鍵架構的圖表。

任務關鍵性設計方法需要多區域部署。 此模型可確保區域容錯，因此即使整個區域停止運作，應用程式仍可供使用。 當您設計多區域應用程式時，請考慮不同的部署策略，例如主動/主動和主動/被動，以及應用程式需求，因為每個方法都有顯著的取捨。 對於任務關鍵性工作負載，我們強烈建議使用中/主動模型。

並非所有工作負載都支援或需要同時執行多個區域。 您應該根據取捨來衡量特定應用程式需求，以判斷最佳設計決策。 對於可靠性較低的特定應用程式案例，主動/被動或分區化可能是適合的替代方案。

可用性區域 可以在區域內的不同資料中心提供高可用性的區域部署。 幾乎所有 Azure 服務都可在區域設定中使用，其中服務會委派至特定區域，或區域備援組態，其中平臺會自動確保服務跨越區域且可承受區域中斷。 這些設定提供資料中心層級的容錯能力。

設計考量

  • 區域和區域性功能。 並非所有服務和功能都可在每個 Azure 區域中使用。 此考慮可能會影響您選擇的區域。 此外，每個區域都無法使用 可用性區域 。

  • 區域配對。 Azure 區域會分組成區域 配對 ，由單一地理位置中的兩個區域組成。 某些 Azure 服務會使用配對的區域來確保商務持續性，並提供保護層級以防止資料遺失。 例如，Azure 異地備援儲存體 (GRS) 自動將資料複寫到次要配對區域，確保資料在主要區域無法復原時是永久性的。 如果中斷會影響多個 Azure 區域，則每個配對中至少有一個區域優先進行復原。

  • 資料一致性。 針對一致性挑戰，請考慮使用全域分散式資料存放區、戳記的區域架構，以及部分作用中/主動部署。 在部分部署中，某些元件在所有區域中都處於作用中狀態，而其他元件則位於主要區域內。

  • 安全部署。 Azure 安全部署實務 (SDP) 架構可確保所有程式碼和設定變更 (規劃維護) 至 Azure 平臺進行階段式推出。 健康情況會在發行期間進行分析，以降低效能。 成功完成 Canary 和試驗階段之後，平臺更新會跨區域配對序列化，因此每個配對中只有一個區域會在指定時間更新。

  • 平臺容量。 如同任何雲端提供者，Azure 有有限的資源。 無法使用可能是區域容量限制的結果。 如果發生區域性中斷，當工作負載嘗試在配對區域內復原時，資源的需求會增加。 中斷可能會造成容量問題，其中供應專案暫時不符合需求。

設計建議

  • 在至少兩個 Azure 區域中部署您的解決方案，以協助防止區域性中斷。 將其部署在具有工作負載所需功能和特性的區域。 這些功能應符合效能和可用性目標，同時滿足資料落地和保留需求。

    例如，某些資料合規性需求可能會限制可用的區域數目，並可能強制設計入侵。 在這種情況下，強烈建議您在操作包裝函式中新增額外的投資，以預測、偵測和回應失敗。 假設您受限於具有兩個區域的地理位置，而且只有其中一個區域支援可用性區域 (3 + 1 個資料中心模型) 。 使用容錯網域隔離建立次要部署模式，以允許這兩個區域部署在作用中設定中，並確保主要區域包含多個部署戳記。

    如果適合的 Azure 區域並非所有都提供您需要的功能，請準備好危害區域部署戳記的一致性，以設定地理分佈的優先順序，並將可靠性最大化。 如果只適合單一 Azure 區域，請在所選區域中部署多個部署戳記 (區域縮放單位) ，以降低某些風險，並使用可用性區域來提供資料中心層級容錯。 不過，地理分佈中的這種重大入侵會大幅限制可取得的複合 SLA 和整體可靠性。

    重要

    針對以大於或等於 99.99% 為目標的 SLO，我們建議至少三個部署區域，以最大化複合 SLA 和整體可靠性。 計算所有使用者流程 的複合 SLA 。 確定複合 SLA 與商務目標一致。

  • 針對具有大量流量的高大規模應用程式案例，請設計解決方案以跨多個區域進行調整，以流覽單一區域內的潛在容量限制。 其他區域部署戳記將會達到更高的複合 SLA。 使用全域資源可限制您藉由新增更多區域而達到的複合 SLA 增加。

  • (RPO) 和復原時間目標 (RTO) 定義及驗證復原點目標。

  • 在單一地理位置內，優先使用區域配對，以受益于 SDP 序列化推出以進行計劃性維護，以及非計劃性維護的區域優先順序。

  • 異地將 Azure 資源與使用者共置，以將網路延遲降到最低，並將端對端效能最大化。

  • 選擇部署區域時，請讓目前的服務可用性與產品藍圖保持一致。 某些服務可能無法立即在每一個區域中使用。

容器化

容器包含應用程式程式碼和應用程式需要執行的相關組態檔、程式庫和相依性。 容器化提供應用程式程式碼及其相依性的抽象層，並建立與基礎裝載平臺的區隔。 單一軟體套件具有高度可攜性，而且可在各種基礎結構平臺和雲端提供者之間一致地執行。 開發人員不需要重寫程式碼，而且可以更快速且更可靠地部署應用程式。

重要

建議您針對任務關鍵性應用程式套件使用容器。 它們可改善基礎結構使用率，因為您可以在相同的虛擬化基礎結構上裝載多個容器。 此外，因為所有軟體都包含在容器中，所以不論執行時間或程式庫版本為何，您都可以跨各種作業系統移動應用程式。 相較于傳統的虛擬化裝載，管理也更容易使用容器。

任務關鍵性應用程式需要快速調整，以避免效能瓶頸。 因為容器映射是預先建置的，所以您只能在應用程式的啟動期間限制啟動，以提供快速的延展性。

設計考量

  • 監視。 監視服務存取容器中的應用程式可能很困難。 您通常需要協力廠商軟體來收集及儲存容器狀態指標，例如 CPU 或 RAM 使用量。

  • 安全性。 裝載平臺 OS 核心會跨多個容器共用，以建立單一攻擊點。 不過，主機 VM 存取的風險會受到限制，因為容器會與基礎作業系統隔離。

  • 狀態。 雖然可以在執行中的容器檔案系統中儲存資料，但重新建立容器時不會保存資料。 相反地，請掛接外部儲存體或使用外部資料庫來保存資料。

設計建議

  • 將所有應用程式元件容器化。 使用容器映射作為應用程式部署套件的主要模型。

  • 盡可能設定 Linux 型容器執行時間的優先順序。 映射更輕量，Linux 節點/容器的新功能經常發行。

  • 使用簡短生命週期讓容器不可變且可取代。

  • 請務必從容器、容器主機和基礎叢集收集所有相關記錄和計量。 將收集的記錄和計量傳送至統一的資料接收，以進一步處理和分析。

  • 將容器映射儲存在Azure Container Registry中。 使用 異地複 寫跨所有區域複寫容器映射。 啟用容器登錄的Microsoft Defender，以提供容器映射的弱點掃描。 請確定登錄的存取權是由Microsoft Entra識別碼所管理。

容器裝載和協調流程

數個 Azure 應用程式平臺可以有效地裝載容器。 每個平臺都有相關聯的優點和缺點。 比較商務需求內容中的選項。 不過，一律將可靠性、延展性和效能優化。 如需詳細資訊，請參閱這些文章：

重要

Azure Kubernetes Service (AKS) 和Azure Container Apps應該根據您的需求，成為容器管理的第一個選項。 雖然Azure App 服務不是協調器，但身為低摩擦容器平臺，但它仍然是 AKS 的可行替代方案。

Azure Kubernetes Service的設計考慮和建議

AKS 是受控 Kubernetes 服務，可讓您快速布建叢集，而不需要複雜的叢集管理活動，並提供包含進階網路和身分識別功能的功能集。 如需一組完整的建議，請參閱 Azure Well-Architected Framework 檢閱 - AKS。

重要

有一些基本設定決策，您無法在不需要重新部署 AKS 叢集的情況下變更。 範例包括公用和私人 AKS 叢集、啟用 Azure 網路原則、Microsoft Entra整合，以及使用 AKS 的受控識別，而不是服務主體。

可靠性

AKS 會管理原生 Kubernetes 控制平面。 如果控制平面無法使用，工作負載就會發生停機。 利用 AKS 所提供的可靠性功能：

  • 將 AKS 叢集部署至不同的 Azure 區域 作為縮放單位，以最大化可靠性和可用性。 使用 可用性區域 ，將 AKS 控制平面和代理程式節點分散到實體不同資料中心，以最大化 Azure 區域內的復原能力。 不過，如果共置延遲是問題，您可以在單一區域內執行 AKS 部署，或使用 鄰近放置群組 將節點間延遲降至最低。

  • 使用生產叢集的 AKS 執行時間 SLA ，將 Kubernetes API 端點可用性保證最大化。

可擴縮性

考慮 AKS 規模限制，例如節點數目、每個叢集的節點集區，以及每個訂用帳戶的叢集。

隔離性

維護工作負載和系統工具所使用的基礎結構之間的界限。 共用基礎結構可能會導致高資源使用率和雜訊鄰近案例。

  • 針對系統和工作負載服務使用不同的節點集區。 工作負載元件的專用節點集區應根據特殊基礎結構資源的需求，例如高記憶體 GPU VM。 一般而言，若要減少不必要的管理額外負荷，請避免部署大量的節點集區。

  • 使用 Taint 和 Toleration 來提供專用節點，並限制需要大量資源的應用程式。

  • 評估應用程式親和性和反親和性需求，並在節點上設定適當的容器共置。

安全性

預設 vanilla Kubernetes 需要大量設定，以確保適合任務關鍵性案例的安全性狀態。 AKS 可解決現成的各種安全性風險。 功能包括私人叢集、稽核和登入 Log Analytics、強化的節點映射，以及受控識別。

  • 套用 AKS 安全性基準中提供的設定指引。

  • 使用 AKS 功能來處理叢集身分識別和存取管理，以減少作業額外負荷，並套用一致的存取管理。

  • 使用受控識別，而不是服務主體，以避免管理和輪替認證。 您可以在叢集層級新增 受控識別 。 在 Pod 層級，您可以透過Microsoft Entra 工作負載 ID使用受控識別。

  • 使用Microsoft Entra整合進行集中式帳戶管理和密碼、應用程式存取管理，以及增強的身分識別保護。 針對最低許可權使用 Kubernetes RBAC 搭配Microsoft Entra識別碼，並將授與系統管理員許可權降到最低，以協助保護設定和秘密存取。 此外，使用 Azure 角色型存取控制來限制 Kubernetes 叢集組態 檔的存取。 限制 容器可執行檔動作存取、提供最少的許可權，並避免使用根許可權提升。

升級

叢集和節點必須定期升級。 AKS 支援 Kubernetes 版本 ，以符合原生 Kubernetes 的版本週期。

  • 訂閱 GitHub 上的公用 AKS 藍圖 和 版本資訊 ，以隨時掌握即將進行的變更、改進，以及最重要的 Kubernetes 版本版本發行和取代。

  • 套用 AKS 檢查清單中 提供的指引，以確保與最佳做法保持一致。

  • 請注意 AKS 針對 更新節點和/或叢集所支援的各種方法。 這些方法可以手動或自動化。 您可以使用 計劃性維護 來定義這些作業的維護期間。 每週會發行新的影像。 AKS 也支援 自動升級通道， 以便在可用時自動將 AKS 叢集升級至較新版本的 Kubernetes 和/或較新的節點映射。

網路

評估最適合使用案例的網路外掛程式。 判斷您是否需要細微控制 Pod 之間的流量。 Azure 支援 kubenet、 Azure CNI，並針對特定使用案例 攜帶您自己的 CNI 。

在評估網路需求和叢集大小之後，優先使用 Azure CNI。 Azure CNI 可讓您使用 Azure 或 Calico 網路原則來控制叢集內的流量。

監視

您的監視工具應該能夠從執行中的 Pod 擷取記錄和計量。 您也應該從 Kubernetes 計量 API 收集資訊，以監視執行中資源和工作負載的健康情況。

控管

使用原則，以一致的方式將集中式保護套用至 AKS 叢集。 在訂用帳戶範圍或更高層級套用原則指派，以推動開發小組之間的一致性。

  • 使用Azure 原則來控制哪些函式授與 Pod，以及是否執行衝突的原則。 此存取權是透過AKS Azure 原則 附加元件所提供的內建原則所定義。

  • 使用Azure 原則，為 AKS 叢集和Pod設定建立一致的可靠性和安全性基準。

  • 使用AKS 的Azure 原則附加元件來控制 Pod 函式，例如根許可權，以及不允許不符合原則的 Pod。

注意

當您部署至 Azure 登陸區域時，Azure 原則可協助您確保登陸區域實作應提供一致的可靠性和安全性。

任務關鍵 性參考實作 提供一套基準原則，以推動建議的可靠性和安全性設定。

Azure App 服務的設計考慮和建議

針對 Web 和 API 型工作負載案例，App Service可能是 AKS 的可行替代方案。 它提供低摩擦容器平臺，而不需要 Kubernetes 的複雜度。 如需一組完整的建議，請參閱App Service的可靠性考慮和App Service的營運卓越。

可靠性

評估使用 TCP 和 SNAT 連接埠。 TCP 連線會用於所有輸出連線。 SNAT 埠用於對公用 IP 位址的輸出連線。 SNAT 埠耗盡是常見的失敗案例。 使用Azure 診斷監視埠時，您應該透過負載測試預測性地偵測此問題。 如果發生 SNAT 錯誤，您必須跨更多或較大的背景工作角色進行調整，或實作程式碼撰寫做法，以協助保留及重複使用 SNAT 埠。 您可以使用的程式碼撰寫做法範例包括連線共用和資源延遲載入。

TCP 埠耗盡是另一個失敗案例。 當來自指定背景工作角色的輸出連線總和超過容量時，就會發生此情況。 可用的 TCP 埠數目取決於背景工作角色的大小。 如需建議，請參閱 TCP 和 SNAT 埠。

可擴縮性

規劃未來的延展性需求和應用程式成長，以便從頭開始套用適當的建議。 如此一來，您就可以在解決方案成長時避免技術性移轉債務。

  • 啟用自動調整，以確保有足夠的資源可供服務要求使用。 針對App Service上的高密度裝載評估每個應用程式調整規模。

  • 請注意，App Service每個App Service方案都有預設的軟性實例限制。

  • 套用自動調整規則。 如果符合設定檔內的任何規則，但只有在符合設定檔內的所有規則時，才會相應放大App Service計畫。 使用相應放大和相應縮小規則組合，確保自動調整可以採取動作來相應放大和相應縮小。 瞭解單一設定檔中多個調整規則的行為。

  • 請注意，您可以在App Service計畫的層級啟用個別應用程式調整，以允許應用程式獨立于裝載應用程式的App Service方案進行調整。 應用程式會透過對偶數散發的最佳做法方法，配置給可用的節點。 雖然不保證偶數散發套件，但平臺可確保相同應用程式的兩個實例未裝載于相同的實例上。

監視

監視應用程式行為，並存取相關的記錄和計量，以確保您的應用程式如預期般運作。

  • 您可以使用診斷記錄，透過Azure 事件中樞將應用層級和平台層級記錄內嵌至 Log Analytics、Azure 儲存體或協力廠商工具。

  • Application Insights 的應用程式效能監視可提供對應用程式效能的深入解析。

  • 如果失敗，任務關鍵性應用程式必須能夠自我修復。 啟用 自動修復 以自動回收狀況不良的背景工作角色。

  • 您必須使用適當的健康情況檢查來評估所有重要的下游相依性，這有助於確保整體健康情況。 強烈建議您啟用 健康情況檢查 ，以識別非回應式背景工作角色。

部署

若要解決每個App Service方案的預設實例限制，請在單一區域中以多個縮放單位部署App Service方案。 在可用性區域設定中部署App Service方案，以確保背景工作節點分散到區域內的區域。 請考慮開啟支援票證，將背景工作角色數目上限增加到您需要提供一般尖峰負載的兩倍實例計數。

容器登錄

容器登錄會裝載部署到 AKS 等容器執行時間環境的映射。 您必須仔細設定任務關鍵性工作負載的容器登錄。 中斷不應造成提取映射的延遲，特別是在調整作業期間。 下列考慮和建議著重于Azure Container Registry，並探索與集中式和同盟部署模型相關聯的取捨。

設計考量

  • 格式。 請考慮使用依賴 Docker 提供的格式和標準進行推送和提取作業的容器登錄。 這些解決方案相容且大部分可交換。

  • 部署模型。 您可以將容器登錄部署為組織中多個應用程式所取用的集中式服務。 或者，您可以將它部署為特定應用程式工作負載的專用元件。

  • 公用登錄。 容器映射會儲存在Docker Hub或其他存在於 Azure 外部和指定虛擬網路的公用登錄中。 這不一定是問題，但可能會導致與服務可用性、節流和資料外泄相關的各種問題。 在某些應用程式案例中，您必須在私人容器登錄中複寫公用容器映射，以限制輸出流量、增加可用性，或避免潛在的節流。

設計建議

  • 使用專用於應用程式工作負載的容器登錄實例。 除非組織可用性和可靠性需求與應用程式完全一致，否則請避免對集中式服務建立相依性。

    在建議 的核心架構模式中，容器登錄是長時間運作的全域資源。 請考慮針對每個環境使用單一全域容器登錄。 例如，使用全域生產登錄。

  • 請確定公用登錄的 SLA 符合您的可靠性和安全性目標。 請特別記下取決於Docker Hub的使用案例節流限制。

  • 優先處理裝載容器映射的Azure Container Registry。

Azure Container Registry的設計考慮和建議

此原生服務提供一系列功能，包括異地複寫、Microsoft Entra驗證、自動化容器建置，以及透過 Container Registry 工作修補。

可靠性

設定所有部署區域的異地複寫，以移除區域相依性並優化延遲。 Container Registry 支援透過 異地複 寫至多個已設定區域的高可用性，以提供區域中斷的復原能力。 如果區域無法使用，其他區域會繼續提供映射要求。 當區域重新上線時，Container Registry 會復原並複寫其變更。 這項功能也會在每個設定的區域內提供登錄共置，以減少網路延遲和跨區域資料傳輸成本。

在提供可用性區域支援的 Azure 區域中， 進階容器登錄層支援區域備援 ，以針對區域性失敗提供保護。 進階層也支援 私人端點 ，協助防止未經授權的登錄存取，這可能會導致可靠性問題。

在相同的 Azure 區域內，靠近取用計算資源的主機映射。

影像鎖定

影像可能會因為手動錯誤而刪除。 Container Registry 支援 鎖定映射版本或存放庫 ，以防止變更或刪除。 當先前部署的映射版本就地變更時，相同 版本 部署可能會在變更前後提供不同的結果。

如果您想要保護 Container Registry 實例免于刪除，請使用 資源鎖定。

標記的影像

標記的 Container Registry 映射預設為可變，這表示相同的標籤可以在推送至登錄的多個映射上使用。 在生產案例中，這可能會導致可能會影響應用程式執行時間的無法預測行為。

身分識別和存取管理

使用Microsoft Entra整合式驗證來推送和提取映射，而不是依賴存取金鑰。 為了增強安全性，請完全停用系統管理員存取金鑰的使用。

無伺服器計算

無伺服器運算會視需要提供資源，並不需要管理基礎結構。 雲端提供者會自動布建、調整及管理執行已部署應用程式程式碼所需的資源。 Azure 提供數個無伺服器計算平臺：

  • Azure Functions。 當您使用Azure Functions時，應用程式邏輯會實作為不同的程式碼區塊或函式，以回應 HTTP 要求或佇列訊息等事件。 每個函式會視需要調整以符合需求。

  • Azure Logic Apps。 Logic Apps 最適合用來建立和執行自動化工作流程，以整合各種應用程式、資料來源、服務和系統。 如同Azure Functions，Logic Apps 會使用內建觸發程式來處理事件驅動。 不過，您可以使用支援條件和迴圈等程式碼區塊的圖形化使用者介面來建立邏輯應用程式，而不是部署應用程式程式碼。

  • Azure API 管理。 您可以使用API 管理來發佈、轉換、維護及監視使用層的增強式安全性 API。

  • Power Apps 和 Power Automate。 這些工具提供低程式碼或無程式碼開發體驗，以及可透過使用者介面中的連線設定的簡單工作流程邏輯和整合。

對於任務關鍵性應用程式，無伺服器技術提供簡化的開發與作業，這對簡單的商務使用案例而言相當重要。 不過，這種簡單性代價在於延展性、可靠性和效能方面具有彈性，而且對大部分任務關鍵性應用程式案例而言並不可行。

下列各節提供使用 Azure Functions 和 Logic Apps 作為非關鍵工作流程案例替代平臺的設計考慮和建議。

Azure Functions的設計考慮和建議

任務關鍵性工作負載具有重要和非關鍵系統流程。 Azure Functions是流程的可行選擇，這些流程與重要系統流程沒有相同的嚴格商務需求。 它非常適合具有短期進程的事件驅動流程，因為函式會執行儘快執行的不同作業。

選擇適合應用程式可靠性層級的Azure Functions裝載選項。 建議您使用 Premium 方案，因為它可讓您設定計算實例大小。 專用方案是無伺服器選項。 它提供自動調整，但這些調整作業的速度會比其他方案的作業慢。 我們建議您使用進階方案，將可靠性和效能最大化。

有一些安全性考慮。 當您使用 HTTP 觸發程式來公開外部端點時，請使用 web 應用程式防火牆 (WAF) ，為 HTTP 端點提供一般外部攻擊媒介的保護層級。

建議您使用私人端點來限制對私人虛擬網路的存取。 它們也可以減輕資料外泄風險，例如惡意系統管理員案例。

您必須在Azure Functions程式碼上使用程式碼掃描工具，並將這些工具與 CI/CD 管線整合。

Azure Logic Apps 的設計考慮和建議

如同Azure Functions，Logic Apps 會使用內建觸發程式來處理事件驅動。 不過，您可以使用支援條件、迴圈和其他建構等區塊的圖形化使用者介面，來建立邏輯應用程式，而不是部署應用程式程式碼。

有多個 部署模式 可供使用。 我們建議使用標準模式，以確保單一租使用者部署並減輕雜訊鄰近案例。 此模式會使用以Azure Functions為基礎的容器化單一租使用者 Logic Apps 執行時間。 在此模式中，邏輯應用程式可以有多個具狀態和無狀態的工作流程。 您應該注意設定限制。

透過 IaaS 的限制移轉

許多具有現有內部部署的應用程式都會使用虛擬化技術和備援硬體，以提供任務關鍵性的可靠性層級。 現代化通常會受到商務條件約束所阻礙，這些條件約束可防止與 North Star) 架構模式完全一致 (，這些模式是針對任務關鍵性工作負載建議的。 這就是為什麼許多應用程式採用階段式方法，使用虛擬化和 Azure 虛擬機器 作為主要應用程式裝載模型的初始雲端部署。 在某些情況下，可能需要使用 IaaS 虛擬機器：

  • 可用的 PaaS 服務不提供必要的效能或控制等級。
  • 工作負載需要作業系統存取、特定驅動程式或網路和系統組態。
  • 工作負載不支援在容器中執行。
  • 協力廠商工作負載沒有廠商支援。

本節著重于使用 Azure 虛擬機器和相關聯服務的最佳方式，以最大化應用程式平臺的可靠性。 它會強調關鍵性設計方法的重要層面，以轉置雲端原生和 IaaS 移轉案例。

設計考量

  • 使用 IaaS 虛擬機器的營運成本明顯高於使用 PaaS 服務的成本，因為虛擬機器和作業系統的管理需求。 管理虛擬機器需要經常推出軟體套件和更新。

  • Azure 提供增加虛擬機器可用性的功能：

    • 可用性設定組 可透過將虛擬機器分散到容錯網域和更新網域，協助防範網路、磁片和電源故障。
    • 可用性區域 可透過將 VM 分散到區域內實體分隔的資料中心，協助您達到更高的可靠性層級。
    • 虛擬機器擴展集提供自動調整群組中虛擬機器數目的功能。 它們也提供監視實例健康情況和自動修復 狀況不良實例的功能。

設計建議

重要

盡可能使用 PaaS 服務和容器來降低作業複雜度和成本。 只有在您需要時才使用 IaaS 虛擬機器。

  • 正確調整 VM SKU 大小 ，以確保有效的資源使用率。

  • 跨 可用性區域 部署三或多部虛擬機器，以達到資料中心層級容錯。

    • 如果您要部署現成的商務軟體，請先洽詢軟體廠商並適當地進行測試，再將軟體部署到生產環境。

  • 對於無法跨可用性區域部署的工作負載，請使用包含三個或多個 VM 的可用性設定組 。

    • 只有在可用性區域不符合工作負載需求時，才考慮可用性設定組，例如針對低延遲需求的聊天工作負載。

  • 優先使用虛擬機器擴展集進行延展性和區域備援。 對於具有不同負載的工作負載而言，這點特別重要。 例如，如果作用中的使用者數目或每秒要求數目是不同的負載。

  • 請勿直接存取個別的虛擬機器。 盡可能在前面使用負載平衡器。

  • 若要防範區域性中斷，請跨多個 Azure 區域部署應用程式虛擬機器。

    • 如需如何在作用中部署區域之間以最佳方式路由傳送流量的詳細資訊，請參閱 網路和連線設計區域 。

  • 對於不支援多區域主動/主動部署的工作負載，請考慮使用經常性/暖待命虛擬機器進列區域容錯移轉，以實作主動/被動部署。

  • 使用來自Azure Marketplace的標準映射，而不是需要維護的自訂映射。

  • 實作自動化程式，以部署和推出虛擬機器的變更，避免任何手動介入。 如需詳細資訊，請參閱操作程式設計區域中的IaaS 考慮。

  • 實作混亂實驗，將應用程式錯誤插入虛擬機器元件，並觀察錯誤的風險降低。 如需詳細資訊，請參閱 持續驗證和測試。

  • 監視虛擬機器，並確保診斷記錄和計量已內嵌到 整合的資料接收中。

  • 在適用時實作任務關鍵性應用程式案例 的安全性做法，以及 Azure 中 IaaS 工作負載的安全性最佳做法。

後續步驟

檢閱資料平臺的考慮。

資料平台