適用於 Azure 數據平臺的 DR - 建議

經驗教訓

1. 請確定相關各方都瞭解高可用性（HA）和災害復原（DR）之間的差異：常見的陷阱是混淆這兩個概念，並與其相關聯的解決方案不符。
2. 與業務項目關係人討論他們對下列層面的期望，以定義恢復點目標（RPO）和復原時間目標（RTO）：
   1. 他們可以容忍多少停機時間，請記住，通常，復原速度越快，成本就越高。
   2. 他們想要保護的事件類型，並提及這類事件的相關可能性。 例如，伺服器關閉的機率高於影響整個區域所有數據中心的自然災害。
   3. 系統無法使用對業務有何影響？
   4. 解決方案的營運費用 （OPEX） 預算向前邁進。
3. 請考慮終端使用者可以接受哪些降級的服務選項。 這可能包括：
   1. 即使沒有最新的數據，即使沒有最新的數據，如果擷取管線無法運作，使用者仍然可以存取其數據。
   2. 具有讀取許可權，但沒有寫入許可權。
4. 您的目標 RTO 和 RPO 計量可以定義您選擇要實作的災害復原策略：
   1. 使用中/主動。
   2. 主動/被動。
   3. 災害時作用中/重新部署。
   4. 請考慮您自己的 複合服務等級目標 （SLO）， 以考慮可容忍的停機時間。
5. 請確定您瞭解可能影響系統可用性的所有元件，例如：
   1. 身分識別管理。
   2. 網路拓撲。
   3. 秘密/金鑰管理。
   4. 資料來源。
   5. 自動化/作業排程器。
   6. 來源存放庫和部署管線（GitHub、Azure DevOps）。
6. 早期偵測中斷也是大幅減少 RTO 和 RPO 值的一種方式。 以下是應涵蓋的幾個層面：
   1. 定義中斷是什麼，以及它如何對應至Microsoft中斷的定義。 Microsoft定義可在產品或服務層級的 Azure 服務等級協定 （SLA） 頁面上取得。
   2. 具有責任小組的有效監視和警示系統，可及時檢閱這些計量和警示，有助於達成目標。
7. 關於訂用帳戶設計，災害復原的其他基礎結構可以儲存在原始訂用帳戶中。 平臺即服務 （PaaS） 服務，例如 Azure Data Lake Storage Gen2 或 Azure Data Factory 通常具有原生功能，可允許故障轉移至其他區域中的次要實例，同時保留原始訂用帳戶中。 某些客戶可能想要考慮針對僅供成本用途之DR案例中使用的資源使用專用資源群組。
   1. 請注意， 訂用帳戶限制 可作為此方法的條件約束。
   2. 其他條件約束可能包括設計複雜度和管理控制件，以確保DR資源群組不會用於企業一般（BAU） 工作流程。
8. 根據解決方案的關鍵性和相依性設計DR工作流程。 例如，在數據倉儲啟動並執行之前，請勿嘗試重建 Azure Analysis Services 實例，因為它會觸發錯誤。 稍後請離開開發實驗室，先復原核心企業解決方案。
9. 嘗試識別可跨解決方案平行處理的復原工作，減少 RTO 總數。
10. 如果在解決方案中使用 Azure Data Factory，別忘了在範圍中包含自我裝載整合運行時間。 Azure Site Recovery 非常適合這些機器。
11. 手動作業應盡可能自動化，以避免人為錯誤，尤其是在壓力不足時。 建議您：
    1. 透過 Bicep、ARM 範本或 PowerShell 腳本採用資源布建。
    2. 採用原始碼和資源設定的版本控制。
    3. 使用 CI/CD 發行管線，而不是隨選即用。
12. 由於您有故障轉移計劃，您應該考慮復原至主要實例的程式。
13. 定義明確的指標和計量，以驗證故障轉移是否成功，且解決方案已啟動並執行，或情況恢復正常（也稱為主要功能）。
14. 決定在故障轉移之後，您的服務等級協定 （SLA） 是否應該維持不變，或者您是否允許降級的服務。
    1. 此決策將在很大程度上取決於支援的商務服務程式。 例如，會議室預約系統的故障轉移看起來與核心操作系統大不相同。
15. RTO/RPO 定義應以特定使用者案例為基礎，而不是以基礎結構層級為基礎。 這樣做可讓您更細微地了解發生中斷或災害時，應該先復原哪些程式和元件。
16. 請務必在目標區域中包含容量檢查，再繼續進行故障轉移：如果發生重大災害，請注意許多客戶會同時嘗試故障轉移至相同的配對區域，這可能會導致布建資源時發生延遲或爭用。
    1. 如果無法接受這些風險，則應考慮主動/主動或主動/被動DR策略。
17. 應建立和維護災害復原計劃，以記錄復原程式和動作擁有者。 此外，請考慮人員可能休假，因此請務必包含次要聯繫人。
18. 應執行一般災害復原演練，以驗證DR計劃工作流程、符合所需的 RTO/RPO，以及訓練負責任的小組。
    1. 數據與組態備份也應該定期測試，以確保它們「適合」以支援任何復原活動。
19. 與負責網路、身分識別和資源布建的小組進行早期共同作業，將能就最佳解決方案達成協定：
    1. 如何將使用者和流量從主要月臺重新導向至次要月臺。 您可以評估 DNS 重新導向之類的概念，或使用像是 Azure 流量管理員 等特定工具。
    2. 如何及時且安全地提供次要月臺的存取權和許可權。
20. 在災害期間，有關各方之間的有效溝通是有效且快速執行計劃的關鍵。 Teams 可能包括：
    1. 決策者。
    2. 事件回應小組。
    3. 受影響的內部使用者和小組。
    4. 外部小組。
21. 適當時間協調不同資源的協調流程可確保災害復原計劃執行的效率。

考量

反模式

• 複製/貼上本文系列 本文系列 旨在提供指引給尋找 Azure 特定DR程式的下一層詳細數據的客戶。 因此，它是以一般Microsoft IP 和參考架構為基礎，而不是任何單一客戶特定的 Azure 實作。

雖然提供的詳細數據將有助於支援堅實的基礎瞭解，但客戶必須先套用自己的特定內容、實作和需求，才能取得「適合用途」的DR策略和程式。

• 將DR視為僅限技術的程式 商務項目關係人，對於定義DR的需求和完成確認服務復原所需的商務驗證步驟，扮演重要角色。 確保所有DR活動都參與商務項目關係人，會提供「適合用途」的DR程式、代表商業價值，而且是可執行的。

• Azure 的「設定和忘記」DR 方案 不斷演進，個別客戶會使用各種元件和服務。 「適合用途」DR 程式必須隨著它們演進。 無論是透過軟體開發生命週期 （SDLC） 程式或定期檢閱，客戶都應該定期重新流覽其DR方案。 目標是確保服務復原方案的有效性，以及已考慮跨元件、服務或解決方案的任何差異。

• 以紙張為基礎的評估 雖然DR事件的端對端模擬在現代數據生態系統中將會很困難，但應努力盡可能接近受影響的元件的完整模擬。 定期排程的演練會建置組織所需的「肌肉記憶」，以便有信心執行DR計劃。

• 依賴Microsoft在Microsoft Azure 服務中執行所有 工作，有明確的 責任劃分，由使用的雲端服務層級所錨定： 即使使用完整的 軟體即服務堆棧（SaaS）堆疊 ，客戶仍會保留責任，以確保帳戶、身分識別和數據正確/最新，以及用來與 Azure 服務互動的裝置。

事件範圍和策略

災害事件範圍

不同的事件會有不同的影響範圍，因此會有不同的回應。 下圖說明災害事件：

災害策略選項

災害復原策略有四個高階選項：

• 等候Microsoft - 如其名所示，解決方案會脫機，直到Microsoft完整復原受影響區域中的服務為止。 復原之後，客戶會驗證解決方案，然後提出最新的服務復原。
• 在災害 時重新部署 - 解決方案會從頭開始手動重新部署到可用的區域，發生災害後事件。
• 暖備援 （主動/被動） - 次要託管解決方案是在替代區域中建立，而且會部署元件以確保最小容量;不過，元件不會接收生產流量。 替代區域中的次要服務可能會「關閉」或以較低的效能等級執行，直到發生DR事件這類時間為止。
• 熱備援 （主動/主動） - 解決方案裝載於多個區域的主動/主動設定中。 次要裝載的解決方案會接收、處理及提供數據做為較大系統的一部分。

DR 策略影響

雖然歸因於較高層級服務復原的作業成本通常佔據DR策略的關鍵設計決策（KDD）。 還有其他重要的考慮。

此工作範例的DR案例是完整的 Azure 區域中斷，直接影響裝載 Contoso 數據平臺的主要區域。 在此中斷案例中，對四個高階DR策略的相對影響如下：

分類索引鍵

• 復原時間目標 （RTO）： 從災害事件到平臺服務復原的預期經過時間。
• 執行的複雜度： 組織執行復原活動的複雜性。
• 實作的複雜度： 組織實作DR策略的複雜性。
• 對客戶的影響： 從DR策略直接影響數據平臺服務的客戶。
• 以上行 OPEX 成本：實作此策略所需的額外成本， 例如針對其他元件和支援所需的額外資源增加每月計費。

下一步

既然您已瞭解與案例相關的建議，您可以瞭解如何 部署此案例

相關資源

• 適用於 Azure 數據平臺的 DR - 概觀
• 適用於 Azure 數據平臺的 DR - 架構
• 適用於 Azure 數據平臺的 DR - 案例詳細數據
• 適用於 Azure 數據平臺的 DR - 摘要