使用案例定義
為了支援此工作範例,虛構的公司 「Contoso」 將搭配以Microsoft參考架構為基礎的 Azure 數據平臺使用。
數據服務 - 元件檢視
Contoso 已實作下列基礎 Azure 架構,這是企業登陸區域設計的子集。
下列描述中的數字會對應至上圖。
Contoso 的 Azure 基礎 - 工作流程
- 企業註冊 - Contoso 在 Azure 中最高的父企業註冊,反映其與Microsoft的商業協定、其組織帳戶結構和可用的 Azure 訂用帳戶。 它提供訂用帳戶的計費基礎,以及數字資產的管理方式。
- 身分識別和存取管理 – 在 Contoso 的 Azure 資產中提供身分識別、驗證、資源存取和授權服務所需的元件。
- 管理群組和訂用帳戶組織 - 可調整的群組階層,符合數據平臺的核心功能,允許使用集中管理的安全性和控管大規模運作,其中工作負載有清楚的區隔。 管理群組可以提供訂閱之上的治理範圍。
- 管理訂用帳戶 - 支持數據平臺所需之各種管理層級功能的專用訂用帳戶。
- 線上訂 用帳戶 - 數據平臺連線功能的專用訂用帳戶,可讓它識別具名服務、判斷內部和外部服務之間的安全路由和通訊。
- 登陸區域訂 用帳戶 – Azure 原生、在線應用程式、內部和外部面向工作負載和資源的單對多訂用帳戶
- DevOps 平臺 - 支持整個 Azure 資產的 DevOps 平臺。 此平臺包含程式代碼基底原始檔控制存放庫和 CI/CD 管線,可自動部署基礎結構即程式代碼 (IaC)。
注意
許多客戶仍然保留大型基礎結構即服務(IaaS)使用量。 若要跨 IaaS 提供復原功能,要新增的主要元件是 Azure Site Recovery。 Site Recovery 會將區域、內部部署虛擬機和實體伺服器之間的 Azure VM 複寫協調並自動化至 Azure,以及將內部部署機器復寫至次要數據中心。
在此基礎結構中,Contoso 已實作下列元素來支援其企業商業智慧需求,並符合 Analytics 端對端與 Azure Synapse 中的指導方針。
Contoso 的數據平臺 - 工作流程
工作流程會從左至右讀取,並遵循數據流:
- 數據來源 - 資料平臺可從中取用的來源或資料類型。
- 內嵌 - 平台從各種不同結構和速度來源擷取數據的功能。 此設計反映 Lambda 架構。
- Store - 能夠安全地大規模儲存已內嵌到平台的數據。
- Process - 平台處理數據的功能,使其「適合」用於下游程式,例如清理、標準化和模型化。 數據的前置處理通常可確保其處於「位置與條件,可供使用」。
- 擴充 - 透過統計、機器學習或其他模型化技術或預先建置的 Azure AI 服務,增強平臺上處理數據的功能。
- 服務 - 平台能夠塑造和呈現下游耗用量的數據。
- 數據取用者 - 個人、應用程式或下游程式,可從平臺的各種服務觸控點取用數據。
- 探索與控管 - 平臺用來控管其包含之數據的功能,並確保其已編製索引、可探索/可搜尋、妥善描述,且具有完整譜系,而且對終端使用者和取用程式而言是透明的。
- 平臺 - 建置平台的基礎,也就是 Contoso 的 Azure 基礎,如上所述。
注意
對許多客戶而言,所使用的數據平臺參考架構概念層級會一致,但實體實作可能會有所不同。 例如,ELT(擷取、載入、轉換)程式可透過 Azure Data Factory 執行,以及 Azure SQL 伺服器的數據模型化。 為了解決這個問題,下方的 具狀態與無狀態元件 一節將提供指引。
針對數據平臺,Contoso 已針對所有元件選取最低建議的生產服務層級,並已根據作業成本最小化方法,選擇採用 「災害時重新部署」 災害復原(DR) 策略。
下列各節將提供對DR程式和槓桿的基準瞭解,讓客戶能夠提升這種狀態。
Azure 服務和元件檢視
下表列出 Contoso – 數據平臺所使用的每個 Azure 服務和元件明細,以及 DR 提升的選項。
注意
下列各節是由具狀態與無狀態服務所組織。
具狀態基礎元件
Microsoft項目標識碼,包括角色權利
- 元件復原責任:Microsoft
- 工作負載/設定復原責任:Microsoft
- Contoso SKU 選取專案:進階 P1
- DR 提升選項:Microsoft Entra 復原功能是其軟體即服務(SaaS)供應專案的一部分。
- 筆記
Azure Key Vault
- 元件復原責任:Microsoft
- 工作負載/設定復原責任:Microsoft
- Contoso SKU 選取專案:N/A
- DR 提升選項:N/A,涵蓋為 Azure 服務的一部分。
復原服務保存庫
Azure DevOps
- 元件復原責任:Microsoft
- 工作負載/設定復原責任:Microsoft
- Contoso SKU 選取專案:DevOps Services
- DR 提升選項:DevOps 服務和數據復原 是其 SaaS 供應專案的一部分。
- 筆記
- DevOps Server 作為內部部署供應專案,仍將是客戶負責災害復原。
- 如果使用第三方服務(例如 SonarCloud、Jfrog Artifactory、Jenkins 建置伺服器),他們仍將是客戶從災害中復原的責任。
- 如果在 DevOps 工具鏈內使用 IaaS VM,他們仍將是客戶從災害中復原的責任。
無狀態基礎元件
訂用帳戶
- 元件復原責任:Microsoft
- 工作負載/設定復原責任:Microsoft
- Contoso SKU 選取專案:N/A
- DR 提升選項:N/A,涵蓋為 Azure 服務的一部分。
管理群組
- 元件復原責任:Microsoft
- 工作負載/設定復原責任:Microsoft
- Contoso SKU 選取專案:N/A
- DR 提升選項:N/A,涵蓋為 Azure 服務的一部分。
Azure 監視器
- 元件復原責任:Microsoft
- 工作負載/設定復原責任:Microsoft
- Contoso SKU 選取專案:N/A
- DR 提升選項:N/A,涵蓋為 Azure 服務的一部分。
成本管理
- 元件復原責任:Microsoft
- 工作負載/設定復原責任:Microsoft
- Contoso SKU 選取專案:N/A
- DR 提升選項:N/A,涵蓋為 Azure 服務的一部分。
適用於雲端的 Microsoft Defender
- 元件復原責任:Microsoft
- 工作負載/設定復原責任:Microsoft
- Contoso SKU 選取專案:N/A
- DR 提升選項:N/A,涵蓋為 Azure 服務的一部分。
Azure DNS
- 元件復原責任:Microsoft
- 工作負載/設定復原責任:Microsoft
- Contoso SKU 選取專案:單一區域 - 公用
- DR 提升選項:N/A、DNS 的設計具有高可用性。
網路監看員
- 元件復原責任:Microsoft
- 工作負載/設定復原責任:Microsoft
- Contoso SKU 選取專案:N/A
- DR 提升選項:N/A,涵蓋為 Azure 服務的一部分。
虛擬網絡,包括子網、使用者定義路由 (UDR) 和網路安全組 (NSG)
- 元件復原責任:Contoso
- 工作負載/設定復原責任:Contoso
- Contoso SKU 選取專案:N/A
- DR 提升選項: VNET 可以復 寫到次要配對的區域。
Azure 防火牆
Azure DDoS
- 元件復原責任:Microsoft
- 工作負載/設定復原責任:Contoso
- Contoso SKU 選取專案:DDoS 網路保護
- DR 提升選項:N/A,涵蓋為 Azure 服務的一部分。
ExpressRoute 線路
- 元件復原責任:Contoso、連線合作夥伴和Microsoft
- 工作負載/設定復原責任:連線夥伴和Microsoft
- Contoso SKU 選取項目:標準
- DR 提升選項:
- ExpressRoute 可以提升為使用 私人對等互連,並提供異地備援服務。
- ExpressRoute 也有 高可用性 (HA) 設計 可供使用。
- 站對站 VPN 連線 可作為 ExpressRoute 的備份。
- 筆記
- ExpressRoute 具有 內建備援,每個線路都包含兩個連線至兩個來自連線提供者/用戶端網路邊緣的 ExpressRoute 位置的兩個 Microsoft Enterprise Edge 路由器 (MSE)。
- ExpressRoute 進階 線路將可存取全球所有 Azure 區域。
VPN 閘道
- 元件復原責任:Contoso
- 工作負載/設定復原責任:Contoso
- Contoso SKU 選取專案:單一區域 - VpnGw1
- DR 提升選項:VPN 閘道可以部署到 具有 VpnGw#AZ SKU 的可用性區域 ,以提供 區域備援服務。
Azure Load Balancer
- 元件復原責任:Contoso
- 工作負載/設定復原責任:Contoso
- Contoso SKU 選取項目:標準
- DR 提升選項:
- 負載平衡器可以針對 具有可用性區域的區域內的區域備援進行設定。 如果是,只要區域內的一個區域維持良好狀態,數據路徑就會存留。
- 視主要區域而定, 可以針對高可用性的跨區域部署部署部署跨區域負載平衡器 。
- 筆記
- Azure 流量管理員是以 DNS 為基礎的流量負載平衡器。 此服務支援跨全球 Azure 區域散發公開應用程式的流量。 此解決方案將針對高可用性設計內的區域性中斷提供保護。
具狀態數據平臺特定服務
記憶體帳戶:Azure Data Lake Gen2
- 元件復原責任:Microsoft
- 工作負載/設定復原責任:Contoso
- Contoso SKU 選取專案:LRS
- DR 提升選項:記憶體帳戶有廣泛的 數據備援 選項,從主要區域備援到次要區域備援。
- 筆記
- 建議使用 GRS 來提升備援性,以提供配對區域中數據的複本。
Azure 事件中樞
Azure IoT 中樞
- 元件復原責任:Microsoft
- 工作負載/設定復原責任:Contoso
- Contoso SKU 選取項目:標準
- DR 提升選項:
- 筆記
- IoT 中樞可將資料複寫至每個 IoT 中樞的配對區域,藉此提供 Microsoft 起始的容錯移轉和手動容錯移轉。
- IoT 中樞 提供區域內部HA,且會在預先定義的 Azure 區域集合中建立時,自動使用可用性區域。
Azure 串流分析
- 元件復原責任:Microsoft
- 工作負載/設定復原責任:Contoso
- Contoso SKU 選取項目:標準
- DR 提升選項:雖然 Azure 串流分析是完全受控的平臺即服務(PaaS)供應專案,但不會提供自動異地故障轉移。 在多個 Azure 區域中部署相同的串流分析作業,即可達成異地備援 。
Azure Machine Learning
- 元件復原責任:Contoso 和 Microsoft
- 工作負載/設定復原責任:Contoso
- Contoso SKU 選取專案:一般用途、D 系列實例
- DR 提升選項:
- 注意:
- Azure 機器學習 本身不提供自動故障轉移或災害復原。
Power BI
- 元件復原責任:Microsoft
- 工作負載/設定復原責任:Microsoft
- Contoso SKU 選取專案:Power BI Pro
- DR 提升選項:N/A、Power BI 的復原能力是其 SaaS 供應專案的一部分。
- 筆記
- Power BI 位於 Office365 租用中,而不是 Azure 的租使用者。
- Power BI 使用 Azure 可用性區域 來保護 Power BI 報表、應用程式和資料免於資料中心失敗。
- 在區域失敗的情況下,Power BI 會故障轉移至新的區域,通常位於相同的地理位置,如Microsoft信任中心所述。
Azure Cosmos DB
- 元件復原責任:Microsoft
- 工作負載/設定復原責任:Microsoft
- Contoso SKU 選項:具有定期備份的單一區域寫入
- DR 提升選項:
- 單一區域帳戶可能會在區域性中斷后失去可用性。 復原能力可以提升至單一 寫入區域和至少一秒(讀取)區域,並啟用服務管理的故障轉移。
- 建議用於生產工作負載的 Azure Cosmos DB 帳戶啟用自動故障轉移。 在沒有此設定的情況下,帳戶將會在寫入區域中斷的所有持續時間內發生寫入可用性遺失的情況,同時由於缺少區域連線能力,手動容錯移轉將不會成功。
- 筆記
- 為了防止區域中的數據遺失,Azure Cosmos DB 提供兩 種不同的備份模式 - 定期 和 連續。
- 在 Azure Cosmos DB 用戶端中偵測並處理區域故障轉移 。 這些容錯移轉不須對應用程式進行任何變更。
- 下列指引說明 以 Cosmos DB 設定為基礎的區域中斷影響。
Azure Data Share
- 元件復原責任:Microsoft
- 工作負載/設定復原責任:Microsoft
- Contoso SKU 選取專案:N/A
- DR 提升選項:AZURE Data Share 復原功能可由 HA部署提升至次要區域。
Microsoft Purview
- 元件復原責任:Microsoft
- 工作負載/設定復原責任:Contoso
- Contoso SKU 選取專案:N/A
- DR 提升選項:N/A
- 筆記
- 自 2024 年 10 月起,Microsoft Purview 不支援自動化商務持續性和災害復原(BCDR)。 在新增該支援之前,客戶須負責所有備份和還原活動。
無狀態數據平臺特定服務
Azure Synapse:Pipelines
- 元件復原責任:Microsoft
- 工作負載/設定復原責任:Contoso
- Contoso SKU 選取專案:計算優化 Gen2
- DR 提升選項:N/A、Synapse 復原功能是其使用 自動故障轉移 功能的 SaaS 供應專案的一部分。
- 筆記
- 如果使用自我裝載數據管線,他們仍會負責從災害中復原。
Azure Synapse:數據總管集區
- 元件復原責任:Microsoft
- 工作負載/設定復原責任:Contoso
- Contoso SKU 選取專案:計算優化、小型 (4 核心)
- DR 提升選項:N/A、Synapse 復原能力是其 SaaS 供應專案的一部分。
- 筆記
Azure Synapse:Spark 集區
- 元件復原責任:Microsoft
- 工作負載/設定復原責任:Contoso
- Contoso SKU 選取專案:計算優化、小型 (4 核心)
- DR 提升選項:N/A、Synapse 復原能力是其 SaaS 供應專案的一部分。
- 筆記
- 目前,Azure Synapse Analytics 僅支援專用 SQL 集區的災害復原,且不支援 Apache Spark 集區。
Azure Synapse:無伺服器和專用 SQL 集區
Azure AI 服務(先前稱為認知服務)
- 元件復原責任:Microsoft
- 工作負載/設定復原責任:Microsoft
- Contoso SKU 選項:隨用隨付
- DR 提升選項:N/A,AI 服務的 API 是由 Microsoft管理的數據中心所裝載。
- 筆記
- 如果 AI 服務已透過客戶部署的 Docker 容器進行部署,復原仍會由客戶負責。
Azure AI 搜尋服務 (先前稱為認知搜尋)
- 元件復原責任:Microsoft
- 工作負載/設定復原責任:Microsoft
- Contoso SKU 選取專案:標準 S1
- DR 提升選項:
- AI 搜尋可以透過跨可用性區域和區域使用複本來提升至 HA 設計。
- 不同區域中的 多個服務可以進一步擴充復原能力。
- 筆記
- 在 AI 搜尋業務持續性(和災害復原)中,可透過多個 AI 搜尋服務 來達成。
- 沒有災害復原的內建機制。 如果在重大失敗期間需要連續服務,建議在不同的區域中有第二個服務,並實作異地復寫策略,以確保索引在所有服務中都是完全備援的。
具狀態與無狀態元件
Microsoft產品套件和 Azure 的創新速度,尤其表示我們用於此工作範例的元件集將快速演進。 為了防止提供過時的指引,並將本指引延伸至本檔中未明確涵蓋的元件,下一節會根據狀態的粗細分類提供一些指示。
如果元件/服務的設計是為了記住先前的事件或用戶互動,則可以將其描述為具狀態。 無狀態表示沒有先前互動的記錄,而且每個互動要求都必須完全根據隨附的信息來處理。
針對呼叫重新部署的DR案例:
- 「無狀態」的元件/服務,例如 Azure Functions 和 Azure Data Factory 管線,可以透過至少抽煙測試從原始檔控制重新部署,以驗證可用性,然後再引入更廣泛的系統。
- 「具狀態」的元件/服務,例如 Azure SQL 資料庫 和記憶體帳戶,需要更多注意。
- 採購元件時,關鍵決策會選取數據備援功能。 此決策通常著重於可用性和持久性與營運成本之間的取捨。
- 數據存放區也需要數據備份策略。 基礎記憶體的數據備援功能可降低某些設計的風險,而其他設計,例如SQL資料庫將需要個別的備份程式。
- 如有必要,您可以透過抽煙測試,從原始檔控制重新部署元件,並透過驗證的設定。
- 重新部署的數據存放區必須將其數據集解除凍結。 解除凍結可以透過數據備援來完成(可用時)或備份數據集。 完成解除凍結時,必須驗證其精確度和完整性。
- 根據備份程序的本質,備份數據集可能需要驗證才能套用。 備份程式損毀或錯誤可能會導致先前的備份使用,以取代可用的最新版本。
- 元件日期/時間戳與目前日期之間的任何差異,都應該透過重新執行或重新執行該點的數據擷取進程來解決。
- 一旦元件的數據集是最新的,就可以將其引入更廣泛的系統。
其他重要服務
本節包含其他重要 Azure 數據元件和服務之高可用性 (HA) 和 DR 指引。
- Azure Databricks - DR 指引可在產品檔中找到。
- Azure Analysis Services - HA 指引可在產品檔中找到。
- 適用於 MySQL 的 Azure 資料庫
- SQL
下一步
既然您已瞭解案例的架構,您可以瞭解 案例詳細數據。