編輯

共用方式為


適用於 Azure 數據平臺的 DR - 部署此案例

Azure Synapse Analytics
Azure Machine Learning
Azure Cosmos DB
Azure Data Lake
Azure 事件中樞

需要客戶活動

事件前

針對 Azure 服務

針對 Power BI

事件期間

針對 Azure 服務

針對 Power BI

復原后Microsoft

如需此詳細數據,請參閱下列各節。

事後事件

針對 Azure 服務

針對 Power BI

等候Microsoft程式

「等候Microsoft」程式只是等待Microsoft復原受影響主要區域中的所有元件和服務。 復原之後,驗證數據平臺與企業共用或其他服務的系結、數據集的日期,然後執行使系統達到目前日期的程式。

完成此程序之後,即可完成技術和商業主題專家(SME)驗證,讓項目關係人核准服務復原。

在災害時重新部署

如需「在災害上重新部署」策略,可以描述下列高階程式流程。

  1. 復原 Contoso 的企業共用服務和來源系統

    此圖顯示 Contoso 共用服務和來源系統的復原。

    • 此步驟是復原數據平臺的必要條件。
    • 此步驟將由負責企業共用服務和操作來源系統的各種 Contoso 作業支援群組完成。
  2. 復原 Azure 服務 Azure 服務是指讓 Azure 雲端供應項目成為 Azure 雲端供應專案的應用程式和服務,可在次要區域內進行部署。

    顯示 Azure 服務復原的圖表。

    Azure 服務是指讓 Azure 雲端供應項目成為 Azure 雲端供應專案的應用程式和服務,可在次要區域內取得以進行部署。

    • 此步驟是復原數據平臺的必要條件。
    • 此步驟將由Microsoft和其他平臺即服務 (PaaS)/軟體即服務 (SaaS) 合作夥伴完成。
  3. 復原數據平台基礎

    此圖顯示數據平臺基礎系統的復原。

    • 此步驟是平台復原活動的進入點。
    • 針對重新部署策略,系統會採購每個必要的元件/服務,並將其部署至次要區域。
    • 此程式也應該包含系結至企業共用服務、確保存取/驗證的連線能力,以及驗證記錄卸除是否正常運作的活動,同時確保與上游和下游進程的連線。
    • 應該確認數據/處理。 例如,驗證復原平台的時間戳。
      • 如果數據完整性有疑問,可以在執行新的處理之前,先決定要及時回復,讓平臺處於最新狀態。
    • 擁有流程的優先順序(根據業務影響)將有助於協調復原。
    • 除非商務使用者直接與服務互動,否則技術驗證應關閉此步驟。 如果有直接存取權,就必須有商務驗證步驟。
    • 一旦驗證完成,就會將移交給個別解決方案小組,以開始自己的災害復原 (DR) 復原程式。
      • 此交接應該包含確認數據和進程的目前時間戳。
      • 如果要執行核心企業數據程式,則應該注意此個別解決方案,例如輸入/輸出流程。
  4. 復原平臺所裝載的個別解決方案

    顯示個別平台系統的復原圖表。

    • 每個個別解決方案都應該有自己的DR Runbook。 Runbook 至少應包含將測試並確認服務復原已完成的已提名商務項目關係人。
    • 根據資源爭用或優先順序而定,主要解決方案/工作負載可能會優先於其他解決方案/工作負載,例如,核心企業程式會優先於臨機操作實驗室。
    • 完成驗證步驟之後,將移交給下游解決方案,以啟動其DR復原程式。
  5. 交接至下游相依系統

    顯示相依系統的圖表。

    • 復原相依服務之後,E2E DR 復原程式就會完成。

    注意

    雖然理論上可以完全自動化 E2E DR 程式,但不太可能考慮到事件的風險與涵蓋 E2E 程式所需的 SDLC 活動成本。

  6. 後援至主要區域 後援是將數據平臺服務及其數據移回主要區域的程式,一旦可供BAU使用。

根據來源系統和各種數據處理程式的性質,數據平臺的後援可以獨立於數據生態系統的其他部分進行。

建議客戶檢閱自己的數據平臺相依性(上游和下游),以做出適當的決策。 下一節假設數據平台的獨立復原。

  • 在主要區域中提供所有必要的元件/服務之後,客戶會完成煙霧測試,以驗證Microsoft復原。
  • 元件/服務元件/服務元件將會經過驗證。 差異會透過從原始檔控制重新部署來解決。
  • 主要區域中的系統日期會跨具狀態元件建立。 建立的日期與次要區域中的日期/時間戳之間的差異,應該藉由重新執行或重新執行該點的數據擷取進程來解決。
  • 透過商務和技術項目關係人的認可,將會選取後援視窗。 在理想情況下,這應該會在系統活動和處理期間發生。
  • 在後援期間,主要區域會在系統切換之前,與次要區域同步。
  • 在平行執行期間之後,次要區域會從系統脫機。
  • 視選取的DR策略而定,次要區域中的元件會卸除或移除。

暖備援程式

針對「暖備援」策略,高層級流程與「災害時重新部署」的流程密切相關,主要差異在於元件已在次要區域中採購。 此策略可消除其他組織想要在該區域中完成其DR的資源爭用風險。

熱備援程式

「熱備援」策略表示平台服務,包括 PaaS 和基礎結構即服務 (IaaS) 系統,儘管當次要系統與主要系統一起執行時發生災害事件,仍會持續存在。 如同「暖備援」策略,此策略可消除其他想要在該區域中完成自己DR的組織的資源爭用風險。

熱備援客戶會監視主要區域中元件/服務的Microsoft復原。 完成後,客戶會驗證主要區域系統,並完成主要區域的後援。 此程式類似於DR故障轉移程式,也就是檢查可用的程式代碼基底和數據,並視需要重新部署。

注意

此處應特別注意,以確保這兩個區域之間的任何系統元數據都一致。

  • 完成後,系統負載平衡器可以更新為將主要區域帶回系統拓撲。 如果有的話,Canary 發行方法可用來以累加方式切換系統的主要區域。

DR 計劃結構

有效的DR方案提供 Azure 技術資源可執行的服務復原逐步指南。 因此,下列列出DR方案的建議MVP結構。

  • 程式需求
    • 任何客戶DR程式特定詳細數據,例如啟動DR所需的正確授權,並視需要做出有關復原的重要決策(包括「完成的定義」)、服務支援DR票證參考,以及戰房詳細數據。
    • 資源確認,包括DR潛在客戶和執行程式備份。 所有資源都應該記錄主要和次要聯繫人、呈報路徑,以及離開行事曆。 在嚴重的DR情況下,可能需要考慮名冊系統。
    • 適用於DR執行程式、DR備份和任何呈報點的膝上型電腦、電源套件或備份電源、網路連線和行動電話詳細數據。
    • 如果不符合任何程式需求,則會遵循此程式。
  • 聯繫人清單
    • DR 領導和支援群組。
    • 將完成技術復原測試/檢閱週期的企業中小企業。
    • 受影響的企業擁有者,包括服務復原核准者。
    • 受影響的技術擁有者,包括技術復原核准者。
    • 所有受影響領域的 SME 支援,包括平臺所裝載的主要解決方案。
    • 受影響的下游系統 – 作業支援。
    • 上游來源系統 – 作業支援。
    • 企業共用服務聯繫人。 例如,存取和驗證支援、安全性監視和閘道支援
    • 任何外部或第三方廠商,包括雲端提供者的支持聯繫人。
  • 架構設計
    • 描述端端 (E2E) 案例詳細數據,並附加所有相關的支援檔。
  • 相依性
    • 列出所有元件的關聯性和相依性。
  • DR 必要條件
    • 確認上游來源系統已視需要提供。
    • 已將跨堆疊的提高存取權授與DR執行程序資源。
    • Azure 服務會視需要提供。
    • 如果任何必要條件尚未符合,要遵循的程式。
  • 技術復原 - 逐步指示
    • 執行順序。
    • 步驟描述。
    • 步驟必要條件。
    • 每個離散動作的詳細程式步驟,包括URL。
    • 驗證指示,包括所需的辨識項。
    • 完成每個步驟的預期時間,包括應變措施。
    • 如果步驟失敗,所要遵循的程式。
    • 失敗或 SME 支援時的呈報點。
  • 技術復原 - 必要條件
    • 確認系統跨主要元件的目前日期時間戳。
    • 確認DR系統URL和IP。
    • 準備商務項目關係人檢閱程式,包括確認系統存取權,以及完成驗證和核准的企業中小企業。
  • 商務項目關係人檢閱和核准
    • 商務資源聯繫人詳細數據。
    • 根據上述技術復原,商務驗證步驟。
    • 從商務核准者簽署復原所需的證據線索。
  • 復原后的必要條件
    • 交接至作業支援,以執行數據處理程式,讓系統更新為最新狀態。
    • 交接下游進程和解決方案 – 確認DR系統的日期和連線詳細數據。
    • 使用DR潛在客戶確認復原程式完成 – 確認辨識項線索和已完成 Runbook。
    • 通知安全性小組,提高訪問許可權可以從DR小組中移除。

圖說文字

  • 建議您包含每個步驟程序的系統螢幕快照。 這些螢幕快照可協助解決系統 SME 的相依性,以完成工作。
    • 若要跟上快速演進的雲端服務,DR 方案應該定期重新流覽、測試及執行資源,瞭解 Azure 及其服務的最新知識。
  • 技術復原步驟應反映元件和解決方案對組織的優先順序。 例如,核心企業數據流會在臨機操作數據分析實驗室之前復原。
  • 技術復原步驟應遵循工作流程的順序(通常是由左至右),一旦復原 金鑰保存庫 等基礎元件或服務。 此策略可確保上游相依性可供使用,而且可以適當測試元件。
  • 完成逐步計劃之後,應該取得具有應變性的活動總時間。 如果此總計超過已同意的復原時間目標 (RTO),則有數個選項可用:
    • 自動化選取的復原程式(可能的話)。
    • 尋找機會以平行方式執行選取的復原步驟(可能的話)。 不過,請注意,此策略可能需要額外的DR執行程序資源。
    • 將關鍵元件提升至較高層級的服務層級,例如 PaaS,其中Microsoft對服務復原活動承擔更大的責任。
    • 使用項目關係人擴充 RTO。

DR 測試

Azure 雲端服務供應項目的本質會導致任何DR測試案例的限制。 因此,指引是使用數據平臺元件來支援DR訂用帳戶,因為它們可在次要區域中使用。

在此基準中,可以選擇性地執行DR計劃 Runbook,並特別注意可部署和驗證的服務與元件。 此程式需要經過策劃的測試數據集,以便根據方案確認技術和商務驗證檢查。

DR 計劃應該定期測試,不僅要確保它是最新的,而且要為執行故障轉移和復原活動的小組建立「肌肉記憶」。

  • 數據與組態備份也應該定期測試,以確保它們「適合」以支援任何復原活動。

DR 測試期間的重點領域是確保規定步驟仍然正確,且估計的計時仍然相關。

  • 如果指示反映入口網站畫面而非程序代碼,則由於雲端變更頻率,應該至少每 12 個月驗證一次指示。

雖然想要有完全自動化的DR程式,但完全自動化可能不太可能因為事件的罕見。 因此,建議使用 Desired 狀態設定 (DSC) 基礎結構建立復原基準,做為提供平臺的程式代碼 (IaC),然後在新專案以基準為基礎建置時提升。

  • 隨著元件和服務擴充,應該強制執行 NFR,要求重構生產部署管線以提供DR的涵蓋範圍。

如果您的 Runbook 計時超過 RTO,有幾個選項:

  • 使用項目關係人擴充 RTO。
  • 透過自動化、平行執行工作或移轉至較高雲端伺服器層級,降低復原活動所需的時間。

Azure Chaos Studio

Azure Chaos Studio 是受控服務,可將錯誤插入 Azure 應用程式,以改善復原能力。 Chaos Studio 可讓您使用實驗,以安全且受控制的方式協調 Azure 資源上的錯誤插入。 如需目前支援之錯誤類型的描述,請參閱產品檔。

Chaos Studio 目前的反覆專案只涵蓋 Azure 元件和服務集。 在新增更多錯誤連結庫之前,Chaos Studio 是隔離復原測試的建議方法,而不是完整的系統DR測試。

如需 Chaos Studio 的詳細資訊,請參閱 Azure Chaos Studio 檔

Azure Site Recovery

針對 IaaS 元件,Azure Site Recovery 會保護在支援的 VM 或實體伺服器上執行 的大部分工作負載

有強大的指導方針:

下一步

既然您已瞭解如何部署案例,您可以閱讀 適用於 Azure 數據平臺系列的DR摘要