共用方式為

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

  • 發行項

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

減輕干擾性事件

人為錯誤

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

意外的叢集或資料庫刪除

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

意外刪除資料表

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

意外刪除外部資料表

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

Azure 數據總管的高可用性

高可用性是指 Azure 數據總管的容錯、其元件，以及 Azure 區域內的基礎相依性。 此容錯可避免實作中的單一失敗點 （SPOF）。 在 Azure 數據總管中，高可用性包括持續性層、計算層和領導者追蹤者組態。

持續性層

Azure 數據總管會利用 Azure 儲存體 作為其持久持續性層。 Azure 儲存體 會自動提供容錯，並提供資料中心內提供本地備援記憶體 （LRS） 的預設設定。 會保存三個複本。 如果在使用中時遺失複本，則會部署另一個複本，而不會中斷。 區域備援記憶體 （ZRS） 可以進一步恢復功能，以智慧方式跨 Azure 區域可用性區域放置複本，以節省額外的容錯能力。 當 Azure 資料總管叢集部署至 可用性區域 時，會自動設定已啟用 ZRS 的記憶體。

計算層

Azure 數據總管是分散式運算平臺，根據縮放比例和節點角色類型，可以有兩到多個節點。 在布建階段，選取可用性區域以將節點部署分散到區域，以達到區域內復原能力上限。 可用性區域失敗不會造成完整的中斷，而是在復原區域之前，效能降低。

領導者追蹤叢集組態

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

Azure 可用性區域的中斷

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

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

注意

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

Azure 資料中心中斷

Azure 可用性區域隨附成本，有些客戶選擇部署，而不需要區域性備援。 透過這類 Azure 數據總管部署，Azure 資料中心中斷會導致叢集中斷。 因此，處理 Azure 資料中心中斷與 Azure 區域中斷情況相同。

Azure 區域的中斷

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

災害復原組態

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

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

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

以下是熱門的災害復原組態，如下所述。

主動-主動-主動設定

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

Active-active-active-n 組態。

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

主動-主動設定

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

主動-主動設定。

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

作用中-熱待命組態

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

作用中熱待命組態。

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

隨選數據復原設定

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

隨選數據復原叢集組態。

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

災害復原組態選項的摘要

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

最佳作法

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

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

後續步驟

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