使用 Azure Data Explorer 建立商務持續性和災害復原解決方案

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

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

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

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

建立多個獨立叢集

在多個區域中建立多個 Azure Data Explorer 叢集。 請確定在 Azure 配對區域中至少建立兩個叢集。

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

複寫管理活動

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

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

   • 資料庫：您可以使用 Azure 入口網站 或其中一個 SDK 來建立新的資料庫。
   • 資料表
   • 對應
   • 原則

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

   

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

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

使用事件中樞設定擷取

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

注意

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

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

最佳化成本

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

• 建立隨選數據復原組態
• 啟動和停止複本
• 實作高可用性應用程式服務
• 在主動-主動設定中優化成本

建立隨選數據復原組態

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

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

啟動和停止複本

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

• Power Automate (Preview) 的 Azure Data Explorer 連接器

• Azure 入口網站 中 [概觀] 索引標籤中的 [停止] 按鈕。 如需詳細資訊，請參閱 停止並重新啟動叢集。

• Azure CLI：

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

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

建立 Azure App 服務 BCDR 用戶端

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

提示

在相同服務中的複本之間有多個連線，可讓您增加可用性。 此設定不僅適用於區域性中斷的實例。

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

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

測試 Azure App 服務BCDR用戶端

我們已使用多個 Azure Data Explorer 複本執行測試。 在主要和次要叢集的模擬中斷之後，您可以看到應用程式服務 BCDR 用戶端如預期般運作。

Azure Data Explorer 叢集會分散到西歐 (2xD14v2 主要) 、東南亞和美國東部 (2xD11v2) 。

注意

回應時間變慢的原因是不同的 SKU 和跨行星查詢。

執行動態或靜態路由

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

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

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

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

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

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

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

相關內容

• 商務持續性和災害復原概觀