本文說明如何透過在不同 Azure 區域複製你的 Azure Data Explorer 資源、管理和資料擷取，來準備應對 Azure 區域故障。 文章中包含使用 Azure 事件中樞 進行資料擷取的範例。 同時也討論了不同架構配置的成本優化。 如需深入瞭解架構考慮和復原解決方案，請參閱 商務持續性概觀。
準備 Azure 區域中斷以保護您的數據
Azure 數據總管不支援自動保護，以防止整個 Azure 區域的中斷。 這種破壞可能發生在自然災害期間，就像地震一樣。 如果您需要災難復原解決方案，請遵循以下步驟以確保業務持續性。 在這些步驟中，你會在兩個 Azure 配對區域複製叢集、管理活動和資料擷取。
- 在兩個 Azure 配對區域中建立兩個以上的獨立叢集 。
- 復寫所有管理活動 ，例如在每一個叢集上建立新的數據表或管理使用者角色。
- 以平行的方式將數據內嵌至每個叢集。
建立多個獨立叢集
在多個區域中建立多個 Azure 數據總管叢集 。 在 Azure 配對區域中建立至少兩個此類叢集。
下圖顯示三個不同區域的複製叢集。
複寫管理作業
複製管理活動，讓每個副本擁有相同的叢集配置。
在每個複製品上建立相同的資源：
- 資料庫：使用 Azure 入口網站或其中一個 SDK 來建立新的資料庫。
- 表格
- 映射
- 原則
-
使用 Event Hubs 資料擷取的災難復原解決方案
完成 準備因應 Azure 區域性中斷以保護您的資料後，Azure Data Explorer 會將您的資料和管理作業儲存在多個區域中。 如果某個區域發生故障，Azure Data Explorer 可以使用其他副本。
使用 Event Hubs 設定擷取
若要將數據從 Azure 事件中樞 擷取到每個區域的 Azure 數據總管叢集，請先在每個區域中複寫您的 Azure 事件中樞 設定。 然後將每個區域的 Azure 數據總管複本設定為 從其對應的事件中樞內嵌數據。
注意
透過 Azure 事件中樞、IoT 中樞 或儲存體進行資料擷取的能力相當穩健。 如果叢集無法長時間使用，它會在之後補上並插入任何待處理的訊息或 blob。 此程序依賴檢查點機制。
這張圖顯示你的資料來源會在所有區域的事件中心產生事件，而每個 Azure Data Explorer 副本都會消耗這些事件。 像 Power BI、Grafana 或 SDK 驅動的網頁應用程式等資料視覺化元件可以查詢一個副本。
最佳化成本
現在你準備好透過以下幾種方法來優化你的複製品了：
建立隨選數據復原設定
複製並更新 Azure Data Explorer 設定會隨著副本數量增加，線性增加成本。 為了優化成本，實施一種架構變體，平衡時間、故障轉移與成本。 隨選資料復原組態可透過使用被動式 Azure Data Explorer 複本來最佳化成本。 只有在主要區域中發生災害時，才會開啟這些複本（例如，區域 A）。 B 區和 C 區的複製品不需要全天候 24 小時運作，這大大降低了成本。 但在大多數情況下，這些複本無法運作，主要叢集也無法運作。 如需詳細資訊，請參閱 隨選數據復原組態。
在下圖中，只有一個叢集會從事件中心（Event Hubs）接收資料。 區域 A 中的主要叢集會 執行所有數據的連續數據匯出 至記憶體帳戶。 次要副本 透過外部資料表存取資料。
啟動和停止副本
啟動與停止次要複本可使用以下方法之一：
Azure 入口網站中的 「概觀」 頁籤內的 「停止」 按鈕。 如需詳細資訊，請參閱 停止和重新啟動叢集。
Azure CLI：
az kusto cluster stop --name=<clusterName> --resource-group=<rgName> --subscription=<subscriptionId>
實作高可用性應用程式服務
建立 Azure App 服務 BCDR 用戶端
本節說明如何建立 Azure App 服務，以支持單一主要和多個次要 Azure 數據總管叢集的連線。 下圖說明 Azure App 服務 設定。
提示
在同一服務中的各個複本之間建立多個連線，可提升可用性。 此設定不僅在區域性中斷的實例中很有用。
將此 未定案程式代碼用於應用程式服務。 要實作多叢集客戶端，請使用 AdxBcdrClient 類別。 這個客戶端執行的每個查詢都會 先送回主要叢集。 若發生故障，查詢會被送往次要副本。
利用 自訂的應用程式洞察指標 來衡量效能，並將請求分配到主叢集與次叢集。
測試 Azure App 服務 BCDR 用戶端
以下測試使用多個 Azure Data Explorer 副本。 在模擬主叢集與次要叢集故障後，App Service BCDR 用戶端會依預期運作。
Azure 數據總管叢集會分散到西歐（2xD14v2 主要版）、東南亞和美國東部（2xD11v2）。
注意
回應時間變慢是因為不同的 SKU 和跨行星查詢所造成。
執行動態或靜態路由
使用 Azure 流量管理員 的路由方法來進行動態或靜態請求路由。 Azure 流量管理員 是一個基於 DNS 的流量負載平衡器，可以用來分配 App Service 流量。 此流量已針對全球 Azure 區域的服務進行優化，同時提供高可用性和回應性。
您也可以使用 Azure Front Door 型路由。 如需這兩種方法的比較，請參閱 負載平衡與 Azure 的應用程式傳遞套件。
在主動-主動組態中最佳化成本
使用主動-主動組態進行災難復原，會使成本呈線性增加。 成本包括節點、儲存體、加價，以及因 頻寬 增加而產生的網路成本。
使用最佳化自動調整來最佳化成本
使用優化的自動調整功能來設定次要叢集的水平調整。 調整次要叢集的規模，以因應資料擷取負載。 當主叢集無法被存取時，次叢集會獲得更多流量，並依照設定擴展。
在這個例子中，優化的自動縮放比在所有複製品上使用相同的水平和垂直縮放節省了約 50% 的成本。