編輯

共用方式為

多租使用者控制平面的考慮

Azure

多租用戶解決方案有多個 平面，而且每個都有自己的責任。 數據 平面 可讓使用者和用戶端與系統互動。 控制 平面 是跨所有租使用者管理較高層級工作的元件，例如訪問控制、布建和系統維護，以支援平台系統管理員的工作。

本文提供控制平面責任的相關信息，以及如何設計符合您需求的控制平面。

顯示邏輯系統設計的圖表。單一控制平面可跨多個租使用者特定數據平面提供管理。

例如，請考慮管理財務記錄的記賬系統。 多個租使用者將其財務記錄儲存在系統中。 當使用者存取系統以檢視並輸入其財務記錄時，他們會使用數據平面。 數據平面可能是解決方案的主要應用程式元件。 您的租使用者可能會將其視為將系統用於其預定用途的方式。 相反地，控制平面是將新租用戶上線、為每個租使用者建立資料庫，以及執行其他管理和維護作業的元件。 如果系統沒有控制平面，系統管理員必須執行許多手動程式。 或者，數據平面和控制平面工作會混合在一起，使解決方案複雜化。

許多複雜的系統包括控制平面。 例如，Azure 控制平面 Azure Resource Manager 是一組 API、工具和後端元件，負責部署和設定 Azure 資源。 Kubernetes 控制平面會管理許多工作，例如在背景工作節點上放置 Kubernetes Pod。 幾乎所有的軟體即服務 （SaaS） 解決方案都有控制平面來處理跨租使用者工作。

當您設計多租用戶解決方案時，需要考慮控制平面。 下列各節提供界定及設計控制平面所需的詳細數據。

控制平面的責任

控制平面或其責任沒有單一範本。 您的解決方案需求和架構會決定控制平面需要執行的動作。 在一些多租用戶解決方案中，控制平面具有廣泛的責任，而且本身是一個複雜的系統。 在其他多租用戶解決方案中，控制平面只有基本責任。

一般而言，控制平面可能有許多下列核心責任：

如果您使用 完全多租使用者租用模型 ，且未部署任何租使用者特定資源，基本控制平面可能只會追蹤租使用者及其相關聯的元數據。 例如，每當新的租用戶註冊您的服務時，控制平面就可以更新資料庫中的適當記錄，讓系統的其餘部分能夠處理新租使用者的要求。

相反地，假設您的解決方案使用需要租使用者特定基礎結構的部署模型，例如 自動化的單一租使用者模型。 在此案例中，您的控制平面可能會承擔更多責任，例如在您上線新租使用者時部署或重新設定 Azure 基礎結構。 在這類解決方案中，控制平面可能需要與您所使用的服務和技術，例如 Azure Resource Manager 或 Kubernetes 控制平面，與控制平面互動。

更進階的控制平面也可能承擔更多責任：

  • 執行自動化維護作業： 一般維護作業包括刪除或封存舊數據、建立和管理資料庫索引，以及輪替秘密和密碼編譯憑證。
  • 租使用者放置： 將租使用者配置給現有的部署或戳記，這可能以各種準則為基礎，包括戳記使用率目標、租使用者需求和 量化封裝策略。
  • 租使用者重新平衡： 在部署戳記變更時，跨部署戳記重新平衡現有的租使用者。
  • 客戶活動追蹤： 與外部客戶管理解決方案整合，例如 Microsoft Dynamics 365，以追蹤客戶活動。

設定控制平面的範圍

您必須仔細考慮為解決方案建置控制平面所花費多少精力。 控制平面本身不會提供立即的客戶價值，因此在設計和建置高品質控制平面上花費工程工作可能不容易。 不過，隨著系統成長和調整，您越來越需要自動化管理和作業，才能跟上成長。

在某些情況下，您可能不需要完全控制平面。 如果您的系統將少於5-10個租使用者，則這種情況可能會適用。 相反地，您的小組可以承擔控制平面的責任，並且可以使用手動作業和程式來上線和管理租使用者。 不過，您仍然應該有一個流程和集中位置來追蹤您的租使用者及其設定。

提示

如果您決定不建立完全控制平面，系統化管理程式仍是個好主意：

  • 徹底記錄您的程式。
  • 盡可能為您的管理作業建立及重複使用腳本。

如果您需要在未來將程式自動化，您的文件和腳本可以形成控制平面的基礎。

當您成長超過少數租使用者時，可能會因為有辦法追蹤每個租使用者，並在您的資源和租用戶車隊中套用監視。 您可能也會注意到您的小組在租使用者管理上花費越來越多的時間和精力。 或者，您可能會注意到錯誤或作業問題，因為小組成員執行管理工作的方式不一致。 如果發生這些情況，值得考慮建立更全面的控制平面來承擔這些責任。

注意

如果您提供自助租使用者管理，則需要在旅程初期的控制平面。 您可以選擇建立基本控制平面，並只自動化一些最常用的功能。 您可以隨著時間逐漸新增更多功能。

設計控制平面

在您判斷控制平面的需求和範圍之後，您需要設計並建構它。 控制平面是重要的元件。 您需要仔細規劃，就像規劃系統的其他元素一樣。

架構完善的控制平面

因為控制平面是它自己的系統，所以當您設計一個架構時，請務必考慮 Azure Well-Architected Framework 的所有五個要素。 下列各節會醒目提示一些要關注的特定區域。

可靠性

控制平面通常是任務關鍵元件。 請務必規劃控制平面所需的復原和可靠性層級。

請考慮如果您的控制平面無法使用，會發生什麼事。 在極端情況下，控制平面中斷可能會導致整個解決方案無法使用。 即使您的控制平面不是單一失敗點，中斷可能會有下列一些影響：

  • 您的系統無法讓新租用戶上線，這可能會影響您的銷售和業務成長。
  • 您的系統無法管理現有的租使用者，這會導致對支援小組進行更多呼叫。
  • 您無法測量租使用者的使用量，或為其使用量計費，這會導致收入損失。
  • 您無法藉由停用或重新設定租用戶來回應安全性事件。
  • 維護債務累積，導致系統長期受損。 例如，如果您的解決方案需要夜間清除舊數據，您的磁碟可能會填滿，或效能可能會降低。

定義 控制平面的服務等級目標 ，包括可用性目標、復原時間目標 （RTO） 和恢復點目標 （RPO）。 您為控制平面設定的目標可能與您為客戶提供的目標不同。

遵循 Azure 架構完善的架構指引，在整個系統中建置可靠的解決方案，包括您的控制平面。

安全性

控制平面通常是高度特殊許可權的系統。 控制平面內的安全性問題可能會產生災難性的後果。 視其設計和功能而定，控制平面可能容易受到許多不同類型的攻擊，包括下列各項：

  • 控制平面可能會存取所有租用戶的密鑰和秘密。 可存取控制平面的攻擊者，或許能夠存取任何租用戶的數據或資源。
  • 控制平面通常會將新的資源部署至 Azure。 攻擊者可能會利用控制平面將自己的資源部署至您的訂用帳戶，而可能會產生大量費用。
  • 如果攻擊者成功將控制平面脫機，系統與企業可能會立即且長期受損。 如需控制平面無法使用的範例結果，請參閱 可靠性 。

當您設計和實作控制平面時，請務必遵循安全性最佳做法並建立完整的威脅模型，以記錄並降低解決方案中的潛在威脅和安全性問題。 如需詳細資訊，請參閱 建置安全解決方案的 Azure 架構指導方針。

卓越營運

因為控制平面是關鍵元件，所以您應該仔細考慮如何在生產環境中部署及操作它。

如同解決方案的其他部分，您應該部署控制平面的非生產實例，以便徹底測試其功能。 如果您的控制平面執行部署作業，請考慮非生產控制平面如何與您的 Azure 環境互動，以及您要部署非生產資源的 Azure 訂用帳戶。 此外，請規劃如何快速清除測試資源，使其不會意外累積費用。

您也應該規劃如何控管小組對控制平面的存取權。 請遵循最佳做法，只授與小組成員執行其職責所需的許可權。 除了協助避免安全性事件之外，這種方法也有助於降低意外設定錯誤的影響。

元件

控制平面沒有單一範本，而您設計和建置的元件取決於您的需求。 通常，控制平面是由 API 和背景背景背景工作者元件所組成。 在某些解決方案中，控制平面也可能包含使用者介面，您的小組甚至您的客戶可能會使用。

隔離控制平面與租使用者工作負載

最好將控制平面的資源與用來為租用戶的數據平面提供服務的資源分開。 例如，您應該考慮使用不同的資料庫伺服器、應用程式伺服器和其他元件。 最好將控制平面的資源與包含租使用者特定資源的資源放在個別的 Azure 資源群組中。

藉由將控制平面與租使用者的工作負載隔離，您會獲得數個優點：

  • 您可以個別設定調整。 例如，您的控制平面可能會有一致的資源需求，而租用戶的資源可能會根據其需求彈性調整。
  • 您的控件和數據平面之間有一個 散文， 有助於防止 在解決方案的平面之間散佈嘈雜的鄰近問題 。
  • 控制平面通常是具有高層級存取權的高許可權系統。 藉由將控制平面與數據平面分開，您可以降低安全性弱點可能允許攻擊者在整個系統提高其許可權的可能性。
  • 您可以部署不同的網路和防火牆組態。 數據平面和控制平面通常需要不同類型的網路存取。

協調長時間執行作業的序列

控制平面執行的作業通常是長時間執行的，且牽涉到多個系統之間的協調。 作業也可以有複雜的失敗模式。 當您設計控制平面時，請務必使用適當的技術來協調長時間執行的作業或工作流程。

例如，假設當您將新租用戶上線時，您的控制平面會依序執行下列動作：

  1. 部署新的資料庫。 此動作是 Azure 部署作業。 可能需要幾分鐘的時間才能完成。
  2. 更新您的租用戶元數據目錄。 此動作可能涉及對 Azure SQL 資料庫執行命令。
  3. 傳送歡迎電子郵件給新的租使用者。 此動作會叫用第三方 API 來傳送電子郵件。
  4. 更新您的計費系統，以準備向新租用戶開立發票。 此動作會叫用第三方 API。 您已注意到其間歇性失敗。
  5. 更新您的客戶關係管理 （CRM） 系統以追蹤新的租使用者。 此動作會叫用第三方 API。

如果順序中的任何步驟失敗，您需要考慮該怎麼做，例如：

  • 重試失敗的作業。 例如，如果步驟 2 中的 Azure SQL 命令因暫時性錯誤而失敗，您可以重試它。
  • 繼續至下個步驟。 例如，您可能會決定，如果您的計費系統更新失敗，可以接受，因為您的銷售小組稍後可以手動新增客戶。
  • 放棄工作流程並觸發手動復原程式。

您也需要考慮每個失敗案例的用戶體驗為何。

管理共用元件

控制平面必須注意未專用於特定租使用者，而是共用的任何元件。 某些元件可能會在戳記內的所有租用戶之間共用。 其他元件可能會在區域中的所有戳記之間共用，或甚至跨所有區域和戳記全域共用。 每當租用戶上線、重新設定或下架時，您的控制平面必須知道這些共用元件的用途。

每當新增或移除租使用者時，可能需要重新設定某些共享元件。 例如，假設您有全域共用的 Azure Front Door 配置檔。 如果您新增具有自定義功能變數名稱的租使用者，您的控制平面可能需要更新配置檔的組態，以將該功能變數名稱的要求路由傳送至正確的應用程式。 同樣地，當租使用者下線時，您的控制平面可能需要從 Azure Front Door 配置檔中移除自定義功能變數名稱，以避免 子域接管攻擊。

共用元件可能有控制平面必須遵循的複雜調整規則。 例如，假設您遵循 bin 封裝 方法來部署租用戶的資料庫。 當新的租用戶上線時，您會為該租使用者新增 Azure SQL 資料庫，然後將它指派給 Azure SQL 彈性集區。 您可能已判斷您需要針對您新增的每十個資料庫增加配置給集區的資源。 當您新增或移除租使用者時，您的控制平面必須重新評估集區的設定，並決定是否要變更集區的資源。 當您達到可以指派給單一彈性集區的資料庫數目上限時，您必須建立新的集區，並開始使用該集區供新的租用戶資料庫使用。 您的控制平面必須負責管理每個共用元件、調整和重新設定，每當發生變更時。

當控制平面管理共用元件時，請務必注意競爭狀況，當多個作業平行發生時，可能會發生這種狀況。 例如，如果您在將新租用戶上線的同時，將不同的租用戶下線，您必須確保最終結束狀態一致，並符合您的調整需求。

使用多個控制平面

在複雜的環境中，您可能需要使用多個控制平面，每個控制平面都有不同的責任領域。 許多多租用戶解決方案遵循 部署戳記模式 ，以及跨多個戳記的分區租使用者。 當您使用此模式時，您可以針對全域和戳記責任建立個別的控制平面。

提示

跨多個控制平面協調很複雜，因此請嘗試將您所建置的控制平面數目降至最低。 大部分的解決方案只需要一個控制平面。

全域控制平面

全域控制平面通常負責租用戶的整體管理和追蹤。 全域控制平面可能會有下列責任：

  • 租使用者放置。 全域控制平面會決定租用戶應該使用的戳記。 根據租用戶區域、每個戳記的容量使用率，以及租用戶的服務等級需求等因素，可能會做出此判斷。
  • 租用戶上線和生命週期管理。 這些責任包括追蹤所有部署的所有租使用者。

戳記控制平面

戳記控制平面會部署到每個部署戳記，並負責配置給該戳記的租用戶和資源。 戳記控制平面可能會有下列責任：

  • 在戳記內建立和管理租使用者特定資源，例如資料庫和記憶體容器。
  • 管理共享資源，包括監視共用資源的耗用量，以及在接近最大容量時部署新實例。
  • 在戳記內執行維護作業，例如資料庫索引管理和清除作業。

每個戳記的控制平面會與全域控制平面協調。 例如，假設新的租用戶註冊。 全域控制平面最初負責選取租用戶資源的戳記。 然後，全域控制平面會提示戳記的控制平面為租使用者建立必要的資源。

下圖顯示兩個控制平面如何在單一系統中共存的範例：

顯示邏輯系統設計的圖表。設計具有全域控制平面和戳記控制平面。

租使用者控制平面

租使用者可能會使用租用戶層級控制平面來管理自己的邏輯或實體資源。 租使用者控制平面可能有下列責任：

  • 管理租使用者特定設定，例如使用者存取。
  • 租使用者起始的維護作業，例如備份數據或下載先前的備份。
  • 如果您允許租使用者控制其應用程式自己的更新，則更新管理。

下圖顯示具有全域控制平面、戳記控制平面，以及每個租使用者的控制平面的複雜系統：

顯示邏輯系統設計的圖表。設計具有全域控制平面、戳記控制平面，以及每個租使用者的控制平面。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主體作者：

其他投稿人：

若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。

下一步