編輯

共用方式為

適用於 Azure Data Factory 和 Azure Synapse Analytics 管線的 BCDR

Azure Data Factory
Azure Repos
Azure Synapse Analytics
GitHub

災害可能是硬體失敗、自然災害或軟體失敗。 為災害做準備並從中復原的程序稱為災害復原 (DR)。 本文討論為 Azure Data Factory 和 Azure Synapse Analytics 管線實現商務持續性和災害復原 (BCDR) 的建議做法。

BCDR 策略包括可用性區域備援、Azure 災害復原所提供的自動化復原，以及使用持續整合和持續傳遞的使用者管理復原 (CI/CD)。

架構

此圖顯示 Azure Synapse Analytics 和 Data Factory 管線 BCDR 的可用性區域和區域。

下載此架構的 Visio 檔案。

工作流程

  1. Data Factory 和 Azure Synapse 管線會使用 Azure 區域和 Azure 可用性區域來達成復原能力。

    • 每個 Azure 區域都有一組資料中心，這些資料中心會部署在延遲定義的周邊內。
    • 每個可容忍本機失敗的 Azure 區域中，Azure 可用性區域的實際位置都不同。
    • 所有 Azure 區域和可用性區域都透過專用的區域低延遲網路和高性能網路連接。
    • 所有啟用可用區區域的區域都至少有三個獨立的可用性區域以確保復原能力。

  2. 當資料中心、資料中心的一部分或區域中的可用性區域關閉時，區域復原 Data Factory 和 Azure Synapse 管線的容錯移轉會零停機。

元件

案例詳細資料

Data Factory 和 Azure Synapse 管線會儲存包含下列資料的成品：

中繼資料

  • 管線
  • 資料集
  • 連結服務
  • 整合執行階段
  • 觸發程序

監視資料

  • 管線
  • 觸發程序
  • 活動執行

災難可能以不同的方式發生，例如硬體故障、自然災害或人為錯誤或網路攻擊導致的軟體故障。 視失敗類型而定，其地理影響可以是區域或全球。 規劃災害復原策略時，請考慮災害的性質及其地理影響。

Azure 中的 BCDR 適用於共用責任模型。 許多 Azure 服務都需要客戶明確設定其 DR 策略，而 Azure 則視需要提供基準基礎結構和平台服務。

您可以使用下列建議做法，在各種失敗案例下達成適用於 Data Factory 和 Azure Synapse 管線的 BCDR。 如需實作，請參閱部署此案例。

透過 Azure 災難復原進行自動復原

透過 Azure 備份和災難復原提供的自動復原，當具有配對區域的 Azure 區域發生完全區域中斷時，Data Factory 或 Azure Synapse 管道會在您設定自動復原時自動容錯移轉到配對區域。 例外狀況是東南亞和巴西區域，其中資料落地需求需要資料留在這些區域。

在 DR 容錯移轉中，Data Factory 會復原生產管線。 如果您需要驗證已復原的管線，您可以在秘密儲存體中備份生產管線的 Azure Resource Manager 範本，並將復原的管線與備份進行比較。

Azure 全球小組會定期進行 BCDR 演練，Azure Data Factory 和 Azure Synapse Analytics 會參與這些演練。 BCDR 演練會模擬區域失敗，並將 Azure 服務容錯移轉至配對的區域，而不需要任何客戶介入。 如需 BCDR 演練的詳細資訊，請參閱測試服務。

使用 CI/CD 的使用者管理備援

若要在發生整個區域失敗時達成 BCDR，您需要次要地區中的資料處理站或 Azure Synapse 工作區。 如果是意外的 Data Factory 或 Azure Synapse 管線刪除、中斷或內部維護事件，您可以使用 Git 和 CI/CD 手動復原管線。

您可以選擇性地使用主動/被動實作。 主要區域會處理一般作業並維持作用中，而次要 DR 區域需要預先規劃的步驟，視特定實作而定，才能升級為主要。 在此案例中，基礎結構的所有必要組態都可在次要地區中使用，但不會佈建。

潛在使用案例

使用者管理的備援在下列案例中很實用：

  • 透過人為錯誤意外刪除管線成品。
  • 未觸發 BCDR 的擴充中斷或維護事件，因為未回報任何災害。

您可以快速地將生產工作負載移至其他區域，而不會受到影響。

考量

這些考量能實作 Azure Well-Architected Framework 的要素，其為一組指導原則，可以用來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework (部分機器翻譯)。

可靠性

可靠性可確保您的應用程式符合您對客戶的承諾。 如需詳細資訊，請參閱可靠性要素的概觀 (部分機器翻譯)。

Data Factory 和 Azure Synapse 管線是支援可用性區域的主流 Azure 服務，其設計目的是提供適當的復原能力和彈性層級，以及超低延遲。

使用者管理的復原方法可讓您在主要區域中發生任何維護事件、中斷或人為錯誤時繼續作業。 藉由使用 CI/CD，資料處理站和 Azure Synapse 管線可以整合至 Git 存放庫，並部署到次要地區以進行立即復原。

成本最佳化

成本最佳化是關於考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱成本最佳化要素的概觀。

使用者管理的復原會使用 CI/CD 整合 Data Factory 與 Git，並選擇性地使用具有所有必要的基礎結構設定做為備份的次要 DR 區域。 此案例可能會產生額外的成本。 若要預估成本，使用 Azure 定價計算機。

如需 Data Factory 和 Azure Synapse Analytics 定價的範例，請參閱：

卓越營運

卓越營運涵蓋部署應用程式並使其持續在生產環境中執行的作業流程。 如需詳細資訊，請參閱卓越營運要素的概觀 (部分機器翻譯)。

藉由使用使用者管理的 CI/CD 復原方法，您可以整合至 Azure Repos 或 GitHub。 有關最佳 CI/CD 做法的更多資訊，請參閱 CI/CD 最佳做法。

部署此案例

採取下列動作，為 Data Factory 和 Azure Synapse 管線設定自動化或使用者管理的 DR。

設定自動化復原

在 Data Factory 中，您可以為活動執行設定 Azure 整合執行階段 (IR) 區域，或在整合運執行階段設定中調度。 若要在發生完整區域中斷時啟用自動容錯移轉，請將 [區域] 設定為 [自動解決]。

顯示選取 [自動解決] 以在整合執行階段設定中啟用自動容錯移轉的螢幕擷取畫面。

在整合執行期間的內容中，當您選取 [自動解決] 做為 IR 區域時，IR 會自動容錯移轉至配對的區域。 對於其他特定位置區域，您可以在另一個區域中建立次要資料處理站，並使用 CI/CD 從 Git 存放庫佈建資料處理站。

容錯移轉之後未完全啟用連結服務，因為區域較新網路中擱置的私人端點。 您必須在復原區域中設定私人端點。 您可以使用核准 API 將私人端點建立自動化。

透過 CI/CD 設定使用者管理的復原

您可以使用 Git 和 CI/CD，在 Data Factory 或 Azure Synapse 管線刪除或中斷時手動復原管線。

當您使用 CI/CD 部署使用者管理的備援時，請採取下列動作：

停用觸發程序

在原始主要資料處理站重新上線後，停用觸發程序。 您可以手動停用觸發程序，或實作自動化，定期檢查原始主要複本的可用性。 在原廠復原之後，立即停用原始主要資料處理站上的所有觸發程序。

若要使用 Azure PowerShell 來關閉或開啟 Data Factory 觸發程序，請參閱與管線觸發程序部署相關的範例前置和部署後指令碼和 CI/CD 改善。

處理重複的寫入

大部分的擷取、轉換、載入 (ETL) 管線都是設計來處理重複的寫入，因為回填和重新填入需要它們。 支援透明容錯移轉的資料接收器可以處理記錄合併的重複寫入，或藉由刪除並插入特定時間範圍中的所有記錄。

對於在容錯移轉之後變更端點的資料接收器，主要和次要儲存體可能會有重複或部分資料。 您需要手動合併資料。

檢查見證並控制管線流程 (選擇性)

一般而言，您需要設計管線以包含活動，例如失敗和查閱活動，以便從感興趣的點重新啟動失敗的管線。

  1. 在資料處理站中新增全域參數，以指出區域，例如region='EastUS'主要和region='CentralUS'次要資料處理站。

  2. 在第三個區域中建立見證。 見證可以是 REST 呼叫或任何類型的儲存體。 見證預設會傳回目前的主要區域，例如 'EastUS'。

  3. 發生災害時，手動更新見證以傳回新的主要區域，例如 'CentralUS'。

  4. 在管線中新增活動以查閱見證，並將目前的主要值與全域參數進行比較。

    • 如果參數相符，此管線會在主要區域上執行。 繼續進行實際工作。
    • 如果參數不相符，則此管線正在次要地區上執行。 只傳回結果。

注意

此方法會在管線中引進見證查閱的相依性。 讀取見證失敗會停止所有管線執行。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主要作者：

其他投稿人：

若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。

下一步