Share via

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

  • 發行項

Azure Data Explorer 中的商務持續性和災害復原可讓您的企業在發生中斷時繼續運作。 本文討論可用性 (內部區域) 和災害復原。 它會詳細說明復原 Azure Data Explorer 部署的原生功能和架構考慮。 它會詳細說明從人為錯誤復原、高可用性，後面接著多個災害復原組態。 這些設定取決於復原需求，例如恢復點目標 (RPO) 和復原時間目標 (RTO) 、需要投入時間和成本。

減輕干擾性事件

人為錯誤

人為錯誤是不可避免的。 使用者可能會不小心卸除叢集、資料庫或數據表。

意外刪除叢集或資料庫

意外的叢集或資料庫刪除是無法復原的動作。 身為 Azure Data Explorer 資源擁有者，您可以在 Azure 資源層級啟用刪除鎖定功能，以防止數據遺失。

意外刪除資料表

允許具有數據表管理員許可權或更高許可權的使用者 卸除數據表。 如果其中一個使用者不小心卸除數據表，您可以使用 命令加以復原 .undo drop table 。 若要讓此命令成功，您必須先在保留原則中啟用可復原性屬性。

意外刪除外部數據表

外部數據表 是參考儲存在資料庫外部數據的 Kusto 查詢架構實體。 刪除外部數據表只會刪除資料表元數據。 您可以重新執行資料表建立命令來復原它。 使用 虛刪除 功能可防止使用者設定的時間量意外刪除或覆寫檔案/Blob。

Azure Data Explorer 的高可用性

高可用性是指 Azure Data Explorer、其元件和 Azure 區域內的基礎相依性容錯。 此容錯可避免實作中的單一失敗點 (SPOF) 。 在 Azure Data Explorer 中，高可用性包括持續性層、計算層和領導者追蹤者設定。

持續性層

Azure Data Explorer 會利用 Azure 記憶體作為其永久性持續性層。 Azure 記憶體會自動提供容錯功能，預設設定會在資料中心內提供本地備援記憶體 (LRS) 。 保存三個複本。 如果在使用中時遺失複本，則會部署另一個複本，而不會中斷。 區域備援記憶體 (ZRS) 可以進一步復原，以智慧方式跨 Azure 區域可用性區域放置複本，以額外成本達到容錯上限。 當 Azure Data Explorer 叢集部署至 可用性區域 時，會自動設定已啟用 ZRS 的記憶體。

計算層

Azure Data Explorer 是分散式運算平臺，視規模和節點角色類型而定，可以有兩到多個節點。 在布建時，選取可用性區域以將節點部署分散到區域，以達到最大區域內復原能力。 可用性區域失敗不會造成完整的中斷，而是在復原區域之前效能降低。

Leader-follower 叢集設定

Azure Data Explorer 提供選擇性的追蹤程式功能，讓領導者叢集後面接著其他追蹤者叢集，以唯讀方式存取領導者的數據和元數據。 領導者中的變更，例如 create、 append和 drop 會自動同步至追蹤者。 雖然領導者可以跨越 Azure 區域，但追蹤者叢集應該裝載在與領導者相同的區域中 () 。 如果領導者叢集已關閉或資料庫或數據表意外卸除，則追蹤者叢集將會失去存取權，直到在領導者中復原存取為止。

Azure 可用性區域的中斷

Azure 可用性區域是相同 Azure 區域內的唯一實體位置。 他們可以保護 Azure Data Explorer 叢集的計算和數據免於部分區域失敗。 區域失敗是可用性案例，因為它位於區域內。

將 Azure Data Explorer 叢集釘選到與其他已連線 Azure 資源相同的區域。 如需啟用可用性區域的詳細資訊，請參閱 建立叢集。

注意

在建立叢集或 稍後可以移轉至可用性區域時，可以部署至可用性區域。

Azure 資料中心中斷

Azure 可用性區域隨附成本，而有些客戶選擇部署而不需區域性備援。 使用這類 Azure Data Explorer 部署，Azure 資料中心中斷將會導致叢集中斷。 因此，處理 Azure 資料中心中斷與 Azure 區域中斷的情形相同。

Azure 區域的中斷

Azure Data Explorer 不會針對整個 Azure 區域的中斷提供自動保護。 若要將發生這類中斷的商務影響降到最低，跨 Azure 配對區域有多個 Azure Data Explorer 叢集。 根據您的復原時間目標 (RTO) 、恢復點目標 (RPO) ，以及投入時間和成本考慮，有多個 災害復原設定。 Azure Advisor 建議和 自動調整 設定可以進行成本和效能優化。

災害復原組態

本節詳述多個災害復原設定，視 RPO 和 RTO) 、需要的工作和成本 (復原需求而定。

復原時間目標 (RTO) 是指從中斷復原的時間。 例如，2 小時的 RTO 表示應用程式必須在中斷的兩小時內啟動並執行。 恢復點目標 (RPO) 是指在該期間遺失數據數量之前，可能會在中斷期間所經過的時間間隔大於允許的閾值。 例如，如果 RPO 為 24 小時，且應用程式的數據是從 15 年前開始，則它們仍位於同意 RPO 的參數內。

規劃災害復原時，擷取、處理和策劃程式需要事先設計。 擷取是指從各種來源整合至 Azure Data Explorer 的數據;處理是指轉換和類似的活動;策劃是指具體化檢視、導出至數據湖等等。

以下是熱門的災害復原組態，以下詳述每個設定。

Active-active-active 設定

此設定也稱為「永遠開啟」。 對於無法容錯中斷的重要應用程式部署，您應該跨 Azure 配對區域使用多個 Azure Data Explorer 叢集。 設定與所有叢集平行擷取、處理和策展。 叢集 SKU 必須跨區域相同。 Azure 可確保在 Azure 配對區域中推出和交錯更新。 Azure 區域中斷不會造成應用程式中斷。 您可能會遇到一些延遲或效能降低的情況。

Active-active-active-n 組態。

Configuration 復原點目標 (RPO) 復原時間目標 (RTO) 投入量 成本
Active-Active-Active-n 0 小時 0 小時 較低 最高

Active-Active 設定

此設定與 主動-主動-主動組態相同，但只涉及兩個 Azure 配對區域。 設定雙重擷取、處理和策劃。 使用者會路由傳送至最接近的區域。 叢集 SKU 必須跨區域相同。

主動-主動設定。

Configuration 復原點目標 (RPO) 復原時間目標 (RTO) 投入量 成本
主動-主動 0 小時 0 小時 較低 高

Active-Hot 待命設定

Active-Hot 組態類似於雙擷取、處理和策展中的 Active-Active 組態 。 雖然待命叢集已上線以進行擷取、處理和策劃，但無法查詢。 待命叢集不需要位於與主要叢集相同的 SKU 中。 它可以是較小的SKU和規模，這可能會導致效能較低。 在災害案例中，系統會將使用者重新導向至待命叢集，選擇性地相應增加以提升效能。

作用中-熱待命設定。

Configuration 復原點目標 (RPO) 復原時間目標 (RTO) 投入量 成本
作用中-熱待命 0 小時 低 中 中

隨選數據復原設定

此解決方案提供最低復原能力 (最高 RPO 和 RTO) ，是成本最低且投入成本最高。 在此設定中，沒有數據復原叢集。 除非也需要原始和元數據，) 才能將策劃數據 (連續匯出至設定 GRS (異地備援記憶體) 的記憶體帳戶。 如果有災害復原案例，就會啟動數據復原叢集。 此時會套用 DDL、設定、原則和進程。 數據會從記憶體擷取ingestion屬性 kustoCreationTime 擷取到預設為系統時間的擷取時間過度。

隨選數據復原叢集設定。

Configuration 復原點目標 (RPO) 復原時間目標 (RTO) 投入量 成本
隨選數據復原叢集 最高 最高 最高 最低

災害復原組態選項的摘要

Configuration 復原 復原點目標 (RPO) 復原時間目標 (RTO) 投入量 成本
Active-Active-Active-n 最高 0 小時 0 小時 較低 最高
主動-主動 高 0 小時 0 小時 較低 高
作用中-熱待命 中 0 小時 低 中 中
隨選數據復原叢集 最低 最高 最高 最高 最低

最佳做法

不論選擇哪一種災害復原組態，請遵循下列最佳做法：

  • 所有資料庫對象、原則和組態都應該保存在原始檔控制中，以便從您的發行自動化工具將它們釋出至叢集。 如需詳細資訊，請參閱 Azure Data Explorer 的 Azure DevOps 支援。
  • 設計、開發及實作驗證例程，以確保所有叢集都從數據觀點同步。 Azure Data Explorer 支援跨叢集聯結。 數據表中的簡單計數或數據列有助於驗證。
  • 發行程式應該牽涉到治理檢查和平衡，以確保叢集的鏡像。
  • 完全瞭解從頭開始建置叢集所需的內容。
  • 建立部署單位的檢查清單。 您的清單對您的需求而言是唯一的，但應該包括：部署腳本、擷取連線、BI 工具和其他重要組態。

後續步驟

建立商務持續性和災害復原解決方案