共用方式為


使用 Azure 資料總管建立商務持續性和災害復原解決方案

本文詳細說明如何在不同的 Azure 區域中複寫 Azure 數據總管資源、管理和擷取,以準備 Azure 區域中斷。 提供具有 Azure 事件中樞 的數據擷取範例。 也會針對不同的架構組態討論成本優化。 如需深入瞭解架構考慮和復原解決方案,請參閱 商務持續性概觀

準備 Azure 區域中斷以保護您的數據

Azure 數據總管不支援自動保護,以防止整個 Azure 區域的中斷。 這種破壞可能發生在自然災害期間,就像地震一樣。 如果您需要災害復原情況的解決方案,請執行下列步驟以確保商務持續性。 在這些步驟中,您將復寫兩個 Azure 配對區域中的叢集、管理和數據擷取。

  1. 在兩個 Azure 配對區域中建立兩個以上的獨立叢集
  2. 復寫所有管理活動 ,例如在每一個叢集上建立新的數據表或管理使用者角色。
  3. 以平行的方式將數據內嵌至每個叢集。

建立多個獨立叢集

在多個區域中建立多個 Azure 數據總管叢集 。 請確定至少有兩個叢集是在 Azure 配對區域中建立的。

下圖顯示複本、三個不同區域中的三個叢集。

建立獨立的叢集。

複寫管理活動

複寫管理活動,以在每個復本中具有相同的叢集組態。

  1. 在每個複本上建立相同的:

  2. 管理每個復本的驗證和授權

    重複的管理活動。

使用事件中樞擷取的災害復原解決方案

完成準備 Azure 區域中斷以保護數據後,您的數據和管理會分散到多個區域。 如果某個區域發生中斷,Azure 數據總管將能夠使用其他複本。

使用事件中樞設定擷取

若要將數據從 Azure 事件中樞 擷取到每個區域的 Azure 數據總管叢集,請先在每個區域中複寫您的 Azure 事件中樞 設定。 然後將每個區域的 Azure 數據總管複本設定為 從其對應的事件中樞內嵌數據。

注意

透過 Azure 事件中樞/IoT 中樞/記憶體進行擷取是健全的。 如果叢集在一段時間內無法使用,則會在稍後趕上,並插入任何擱置的訊息或 Blob。 此程式依賴檢查點。

透過 Azure 事件中樞 擷取。

如下圖所示,您的數據源會產生事件至所有區域中的事件中樞,而每個 Azure 數據總管複本都會取用事件。 Power BI、Grafana 或 SDK 支援的 WebApps 等數據視覺效果元件可以查詢其中一個複本。

數據視覺效果的數據源。

最佳化成本

現在您已準備好使用下列其中一些方法來優化複本:

建立隨選數據復原設定

複寫和更新 Azure 資料總管設定會以線性方式增加複本數目的成本。 若要將成本優化,您可以實作架構變體,以平衡時間、故障轉移和成本。 在隨選數據復原設定中,已透過引進被動 Azure 數據總管複本來實作成本優化。 只有在主要區域中發生災害時,才會開啟這些複本(例如,區域 A)。 區域 B 和 C 中的複本不需要使用中 24/7,可大幅降低成本。 不過,在大部分情況下,這些複本的效能不會和主要叢集一樣好。 如需詳細資訊,請參閱 隨選數據復原組態

在下圖中,只有一個叢集會從事件中樞內嵌數據。 區域 A 中的主要叢集會 執行所有數據的連續數據匯出 至記憶體帳戶。 次要復本可以使用外部數據表存取數據

隨選數據復原組態的架構。

啟動和停止複本

您可以使用下列其中一種方法來啟動和停止次要複本:

az kusto cluster stop --name=<clusterName> --resource-group=<rgName> --subscription=<subscriptionId>"

實作高可用性應用程式服務

建立 Azure App 服務 BCDR 用戶端

本節說明如何建立 Azure App 服務,以支持單一主要和多個次要 Azure 數據總管叢集的連線。 下圖說明 Azure App 服務 設定。

建立 Azure App Service。

提示

在相同服務中的複本之間有多個連線,可讓您提高可用性。 此設定不僅在區域性中斷的實例中很有用。

  1. 將此 未定案程式代碼用於應用程式服務。 若要實作多叢集用戶端, 已建立 AdxBcdrClient 類別。 使用此客戶端執行的每個查詢都會先傳送 至主要叢集。 如果失敗,查詢將會傳送至次要複本。

  2. 使用 自定義 Application Insights 計量 來測量效能,以及要求散發至主要和次要叢集。

測試 BCDR 用戶端 Azure App 服務

我們已使用多個 Azure 數據總管複本執行測試。 在主要和次要叢集的模擬中斷之後,您可以看到 App Service BCDR 客戶端的行為如預期般運作。

確認 App Service BCDR 用戶端。

Azure 數據總管叢集會分散到西歐(2xD14v2 主要版)、東南亞和美國東部(2xD11v2)。

跨行星查詢回應時間。

注意

回應時間變慢是因為不同的 SKU 和跨行星查詢所造成。

執行動態或靜態路由

使用 Azure 流量管理員 路由方法進行要求的動態或靜態路由。 Azure 流量管理員 是以 DNS 為基礎的流量負載平衡器,可讓您散發應用程式服務流量。 此流量已針對全球 Azure 區域的服務進行優化,同時提供高可用性和回應性。

您也可以使用 Azure Front Door 型路由。 如需這兩種方法的比較,請參閱 負載平衡與 Azure 的應用程式傳遞套件

在主動-主動設定中將成本優化

使用主動-主動設定進行災害復原會增加成本線性。 成本包括節點、記憶體、標記,以及頻寬的網路成本增加。

使用優化的自動調整將成本優化

使用優化的自動調整功能來設定次要叢集的水平調整。 它們應以維度來處理擷取負載。 無法連線到主要叢集之後,次要叢集會根據組態取得更多流量並進行調整。

在此範例中使用優化的自動調整,相較於在所有複本上具有相同的水準和垂直縮放比例,節省了大約 50% 的成本。