Share via

Azure 上任務關鍵性工作負載的設計方法

  • 發行項

在任何雲端平臺上建置任務關鍵性應用程式需要大量的技術專業知識和工程投資，特別是因為有與下列專案相關聯的重大複雜度：

  • 瞭解雲端平臺，
  • 選擇正確的服務和組合，
  • 套用正確的服務組態，
  • 將已使用的服務運作化，以及
  • 持續配合最新的最佳做法和服務藍圖。

此設計方法致力於提供容易遵循的設計路徑，以協助流覽此複雜度，並通知產生最佳目標架構所需的設計決策。

1 — 商務需求設計

並非所有任務關鍵性工作負載都有相同的需求。 預期此設計方法所提供的檢閱考慮和設計建議會針對不同的應用程式案例產生不同的設計決策和取捨。

選取可靠性層級

可靠性是相對的概念，而且任何工作負載都適當可靠，它應該反映其周圍的商務需求。 例如，具有 99.999% 可用性服務等級目標的任務關鍵性工作負載 (SLO) 需要比 SLO 為 99.9% 的另一個較不重要工作負載更高的可靠性層級。

此設計方法會套用以可用性 SLA 表示的可靠性層級概念，以通知所需的可靠性特性。 下表擷取與常見可靠性層級相關聯的允許錯誤預算。

可靠性層 (可用性 SLO) 允許的停機時間 (周) 允許的停機時間 (月份) 允許的停機時間 (年)
99.9% 10 分鐘，4 秒 43 分鐘，49 秒 8 小時，45 分鐘，56 秒
99.95% 5 分鐘，2 秒 21 分鐘，54 秒 4 小時，22 分鐘，58 秒
99.99% 1 分鐘 4 分鐘 22 秒 52 分鐘，35 秒
99.999% 6 秒 26 秒 5 分鐘，15 秒
99.9999% <1 秒 2 秒 31 秒

重要

此設計方法會將可用性 SLO 視為比簡單的執行時間還多，而是相對於已知狀況良好應用程式狀態的一致應用程式服務層級。

在初始練習中，建議讀者藉由判斷可接受的停機時間來選取目標可靠性層級？ 特定可靠性層級的實現最終會對設計路徑產生重大影響，並包含設計決策，這會導致不同的目標架構。

此圖顯示不同可靠性層級和基礎商務需求如何影響概念參考實作的目標架構，特別是關於區域部署數目和已使用全球技術。

任務關鍵性可靠性撥號

復原時間目標 (RTO) 和復原點目標 (RPO) 是判斷必要可靠性時的進一步重要層面。 例如，如果您努力達到少於一分鐘的應用程式 RTO，則備份型復原策略或主動-被動部署策略可能不足。

2- 使用設計原則評估設計區域

此方法的核心在於由下列專案組成的重要設計路徑：

每個設計區域內所做的決策影響，將會在其他設計區域和設計決策之間殘響。 請檢閱提供的考慮和建議，以進一步瞭解內含決策的結果，這可能會在相關的設計區域中產生取捨。

例如，若要定義目標架構，請務必判斷如何監視關鍵元件之間的應用程式健康情況。 強烈建議您使用概述的建議來檢閱健康情況模型設計區域，以協助推動決策。

3— 部署您的第一個任務關鍵性應用程式

請參閱這些參考架構，這些參考架構會根據此方法描述設計決策。

提示

GitHub 標誌 此架構是由 任務關鍵性線上 實作所支援，可說明設計建議。

生產等級成品 每個技術成品都已準備好在生產環境中使用，並考慮所有端對端作業層面。

以真實世界體驗為根 所有技術決策都是由 Azure 客戶的經驗和從部署這些解決方案中學到的經驗所引導。

Azure 藍圖對齊 任務關鍵參考架構有自己的藍圖，與 Azure 產品藍圖一致。

4— 在 Azure 登陸區域中整合您的工作負載

Azure 登陸區域訂 用帳戶為需要集中式治理的企業部署提供共用基礎結構。

請務必評估您的任務關鍵性應用程式需要哪些連線使用案例。 Azure 登陸區域支援兩個主要原型，以不同的管理群組範圍分隔： 線上 或 公司， 如下圖所示。

線上和公司管理群組的圖表，並與任務關鍵性工作負載整合。

線上訂用帳戶

任務關鍵性工作負載會以獨立的解決方案運作，而不需要任何直接的公司網路連線到其餘的 Azure 登陸區域架構。 應用程式會透過原則 驅動的治理 進一步受到保護，並透過原則自動與集中式平臺記錄整合。

基準架構和Mission-Critical Online實作與 Online 方法一致。

公司訂用帳戶

在 Corp.訂用帳戶中部署時，任務關鍵性工作負載取決於 Azure 登陸區域以提供連線資源。 此方法允許與其他應用程式和共用服務整合。 您必須針對一些基礎資源進行設計，這些資源將會在共用服務平臺中預先存在。 例如，區域部署戳記不應該再包含暫時虛擬網路或 Azure 私用 DNS 區域，因為這些會存在於 Corp. 訂用帳戶中。

若要開始使用此使用案例，建議您 在 Azure 登陸區域參考架構中建立基準架構 。

提示

GitHub 標誌 上述架構是由 任務關鍵連線 實作所支援。

5— 部署沙箱應用程式環境

與設計活動平行，強烈建議使用Mission-Critical參考實作來建立沙箱應用程式環境。

這提供實作機會，藉由複寫目標架構來驗證設計決策，讓設計不確定性得以快速評估。 如果正確套用代表性需求涵蓋範圍，可能會發現大部分有問題的問題可能會阻礙進度，並後續加以解決。

6- 持續隨著 Azure 藍圖演進

使用此設計方法建立的應用程式架構必須繼續 與 Azure 平臺藍圖一致 ，以支援優化的永續性。

後續步驟

檢閱任務關鍵性應用程式案例的設計原則。

設計原則