Microsoft Fabric 中的可靠性
本文說明 Microsoft Fabric 中的可靠性支援，以及具有可用性區域的區域復原能力和跨區域復原和商務持續性。 如需更多關於 Azure 可靠性的詳細概觀，請參閱 Azure 可靠性。
可用性區域支援
Azure 可用性區域是每個 Azure 區域內至少三個實體獨立的資料中心群組。 每個區域內的資料中心都配備了獨立的電源、冷卻系統和網路基礎結構。 在本機區域失敗的案例中，可用性區域的設計在於，當一個區域受影響時，讓其餘兩個區域支援區域服務、容量和高可用性。
這類失敗的範圍可從軟體和硬體故障，擴及到如地震、淹水和火災的事件。 透過 Azure 服務的備援和邏輯隔離，實現對失敗的容錯。 如需深入了解 Azure 的可用性區域，請參閱區域和可用性區域。
已啟用 Azure 可用性區域的服務旨在提供正確程度的可靠性和彈性。 您可以透過兩種方式加以設定。 它們可以是區域備援，具有跨區域自動複寫功能，或者是區域性的，將執行個體釘選在特定區域。 兩種方法可以結合使用。 如需區域與區域備援結構的詳細資訊，請參閱使用可用性區域和區域的建議。
Fabric 可在商業上合理地支援區域備援可用性區域，其中的資源會自動跨區域複寫，而不需要您安裝或設定。
必要條件
- Fabric 目前在有限的區域中提供部分可用性區域支援。 此部分可用性區域支援涵蓋多項體驗 (及/或體驗內的特定功能)。
- 事件串流之類的體驗不支援可用性區域。
- 如果您使用 OneLake，數據工程支援可用性區域。 如果您使用ADLS Gen2等其他數據源，則必須確定已啟用區域備援記憶體 （ZRS）。
- 區域可用性可能或可能不適用於處於預覽狀態的網狀架構體驗和/或功能/功能。
- Power BI 中的內部部署閘道和大型語意模型不支援可用性區域。
- Data Factory (管線) 支援西歐的可用性區域，但如果區域中斷，新的或正在進行的管線執行可能會失敗。
支援的區域
Fabric 可在商業上合理地為各種區域提供可用性區域支援，如下所示：
| 美洲 | Power BI | 資料超市 | 資料倉儲 | 即時分析 | Data Factory (管線) | 資料工程 |
|---|---|---|---|---|---|---|
| 巴西南部 | 
|
|
|
|
|
|
| 加拿大中部 |
|
|
|
|
||
| 美國中部 |
|
|
||||
| 美國東部 |
|
|
|
|
|
|
| 美國東部 2 |
|
|
|
|
|
|
| 美國中南部 |
|
|
||||
| 美國西部 2 |
|
|
|
|
||
| 美國西部 3 |
|
|
|
|
||
| 歐洲 | ||||||
| 法國中部 |
|
|
|
|
|
|
| 德國中西部 |
|
|
||||
| 義大利北部 |
|
|
||||
| 北歐 |
|
|
|
|
|
|
| 挪威東部 |
|
|
|
|
||
| 波蘭中部 |
|
|
||||
| 英國南部 |
|
|
|
|
|
|
| 西歐 |
|
|
|
|||
| 中東 | ||||||
| 卡達中部 |
|
|||||
| 以色列中部 |
|
|
||||
| 非洲 | ||||||
| 南非北部 |
|
|
|
|
||
| 亞太地區 | ||||||
| 澳大利亞東部 |
|
|
|
|
||
| 日本東部 |
|
|
|
|||
| 東南亞 |
|
|
區域關閉體驗
在全區域中斷期間，不需在區域復原期間採取任何動作。 支援區域中所列區域的 Fabric 功能會自動自我修復和重新平衡，以充分利用狀況良好的區域。 如果主要節點位於失敗的區域，執行Spark作業可能會失敗。 在這種情況下，必須重新提交作業。
重要
雖然 Microsoft 努力提供統一且一致的可用性區域支援，但在發生某些可用性區域失敗時，位於 Azure 區域中的 Fabric 容量可能會有比平常還高的延遲。
跨區域災害復原和商務持續性
災害復原 (DR)是指從重大影響事件中復原，例如自然災害或不成功的部署 (導致停機和資料遺失)。 無論原因為何，解決災害的最佳辦法是定義完善且經過測試的 DR 方案，以及主動支援 DR 的應用程式設計。 開始思考建立災害復原方案之前，請參閱設計災害復原策略的建議。
Microsoft 在災害復原方面採取共同責任模型。 在共同責任模型中，Microsoft 確保基準基礎結構和平台服務可供使用。 此時，許多 Azure 服務不會自動複寫資料，或從失敗區域回復為交叉複寫到另一個已啟用的區域。 您需要為這些服務制定適合工作負載的災害復原方案。 在 Azure 平台即服務 (PaaS) 供應項目上執行的多數服務，都有提供支援災害復原的功能和指導，您可以使用特定服務功能快速復原，制定災害復原方案。
本節描述 Fabric 的災害復原方案，其設計目的是協助組織在發生非計劃性區域災害時，讓資料保持安全且可供存取。 方案中會涵蓋下列主題：
跨區域複寫：Fabric 為儲存在 OneLake 中的資料提供跨區域複寫。 您可以根據需求加入或退出此功能。
災害後的資料存取：在區域性災害案例中，Fabric 會保證資料存取，但有特定限制。 雖然容錯移轉後會限制新項目的建立或修改，但主要焦點會維持在確保現有資料保持可供存取且完好無損。
復原指導：Fabric 提供一組結構化的指示，以引導您完成復原程序。 結構化指導可讓您更輕鬆地轉換回一般作業。
Power BI 現在是 Fabric 的一部分，已備妥穩固的災害復原系統，並提供下列功能：
預設使用 BCDR:Power BI 會自動在其預設供應項目中包含災害復原功能。 您不需要個別選擇加入或啟用此功能。
跨區域複寫：Power BI 使用 Azure 儲存體異地備援複寫和 Azure SQL 異地備援複寫，以保證備份執行個體存在於其他區域，而且可供使用。 這表示資料會跨不同區域複寫，以強化其可用性，並降低與區域中斷相關的風險。
災害後的持續服務和存取：即使在干擾性事件期間，Power BI 項目仍可供在唯讀模式下存取。 這些項目包括語意模型、報表和儀表板，可確保企業可以繼續其分析和決策程序，而不會造成重大障礙。
如需詳細資訊，請參閱 Power BI 高可用性、容錯移轉和災害復原常見問題
重要
對於主區域沒有 Azure 配對區域且受到災害影響的客戶，使用 Fabric 容量的能力可能會受到危害，即使這些容量內的資料已複寫也一樣。 這項限制與主區域的基礎結構有關，對於容量的作業至關重要。
主區域和容量功能
若要有效地規劃災害復原，請務必了解主區域與容量位置之間的關聯性。 了解主區域和容量位置可協助您有策略地選取容量區域，以及對應的複寫和復原程序。
組織租用護和資料儲存體的主區域會設定為所註冊第一個使用者的帳單地址所在位置。 如需租用戶設定的進一步詳細資料，請移至 Power BI 實作規劃：租用戶設定。 當您建立新的容量時，資料儲存體預設會設定為主區域。 如果您想要將資料儲存體區域變更為另一個區域，則必須啟用 Fabric Premium 的功能 Multi-Geo。
重要
為容量選擇不同的區域並不會將所有資料整個重新放置到該區域。 某些資料元素仍會儲存在主區域中。 若要查看哪些資料會留在主區域，以及哪些資料會儲存在已啟用 Multi-Geo 的區域，請參閱設定 Fabric Premium 的 Multi-Geo 支援。
如果主區域沒有配對區域，則當主區域發生災害時，任何已啟用 Multi-Geo 的區域中的容量都可能會面臨作業問題，因為核心服務功能會繫結至主區域。
如果您選取歐盟內已啟用 Multi-Geo 的區域，則您的資料保證會儲存在歐盟資料界限內。
若要了解如何識別主區域，請參閱尋找 Fabric 主區域。
災害復原容量設定
Fabric 會在容量設定頁面上提供災害復原開關。 Azure 的區域配對與 Fabric 的服務存在保持一致的地方便可使用。 以下是此開關的具體細節：
角色存取：只有具有容量管理員角色或更高階角色的使用者才能使用此開關。
細微性：此開關的細微性是容量層級。 其同時適用於 Premium 和 Fabric 容量。
資料範圍：災害復原切換特別適用於 OneLake 資料，其中包括 Lakehouse 和倉儲資料。 此開關不會影響儲存在 OneLake 外部的資料。
Power BI 的 BCDR 持續性：雖然 OneLake 資料的災害復原可以開啟和關閉，但不論開關是開啟還是關閉，都一律支援適用於 Power BI 的 BCDR。
頻率：變更災害復原容量設定後，必須等候 30 天才能再次改變。 等候期間已設定就緒，以維持穩定性並防止持續切換，
注意
在開啟災害復原容量設定後，資料最多可能需要一週才能開始複寫。
資料複寫
當您開啟災害復原容量設定時，跨區域複寫會啟用為 OneLake 資料的災害復原功能。 Fabric 平台會與 Azure 區域一致，以佈建異地備援配對。 不過，某些區域沒有 Azure 配對區域，或配對區域不支援 Fabric。 針對這些區域，便無法使用資料複寫。 如需詳細資訊，請參閱具有可用性區域但沒有區域配對的區域和 Fabric 區域可用性。
注意
雖然 Fabric 在 OneLake 中提供資料複寫解決方案來支援災害復原，但有顯著的限制。 例如，KQL 資料庫和查詢集的資料會儲存在 OneLake 外部，這表示需要個別的災害復原方法。 如需每個 Fabric 項目的災害復原方法詳細資料，請參閱本文件的其餘部分。
計費
Fabric 中的災害復原功能可讓您異地複寫資料，以提高安全性和可靠性。 此功能會耗用更多儲存體和交易，兩者分別會以 BCDR 儲存體和 BCDR 作業的形式計費。 您可以在 Microsoft Fabric 容量計量應用程式中監視和管理這些顯示為個別明細項目的成本。
如需所有相關災害復原成本的詳盡明細，以協助您據此進行規劃和編列預算，請參閱 OneLake 計算和儲存體耗用量。
設定災害復原
雖然 Fabric 提供災害復原功能來支援資料復原，但您必須遵循特定手動步驟，才能在中斷期間還原服務。 本節詳細說明為了針對潛在的中斷做好準備，您所應該採取的動作。
階段 1：準備
啟用災害復原容量設定：定期檢閱並設定災害復原容量設定，以確保其符合您的保護和效能需求。
建立資料備份：以符合災害復原方案的方式，將儲存在 OneLake 外部的重要資料複製到另一個區域。
階段 2：災害容錯移轉
當重大災害使得主要區域無法復原時，Microsoft Fabric 會起始區域容錯移轉。 在容錯移轉完成且 Microsoft Fabric 支援頁面上張貼通知之前，會無法存取 Fabric 入口網站。
容錯移轉完成所需的時間可能不同，但通常不到一小時。 容錯移轉完成後，預期會有以下情況：
Fabric 入口網站：您可以存取入口網站，而且瀏覽現有工作區和項目等讀取作業會繼續運作。 所有寫入作業 (例如建立或修改工作區) 則會暫停。
Power BI：您可以執行讀取作業，例如顯示儀表板和報表。 不支援重新整理、報表發佈作業、儀表板和報表修改，以及其他需要變更中繼資料的作業。
Lakehouse/倉儲：您無法開啟這些項目，但可以透過 OneLake API 或工具來存取檔案。
Spark 作業定義：您無法開啟 Spark 作業定義，但可透過 OneLake API 或工具來存取程式碼檔案。 容錯移轉後會儲存任何中繼資料或設定。
筆記本：您無法開啟筆記本，而且在災害發生後不會儲存程式碼內容。
ML 模型/實驗：您無法開啟 ML 模型或實驗。 災害發生後不會儲存程式碼內容和中繼資料，例如執行計量和設定。
資料流程 Gen2/管線/Eventstream：您無法開啟這些項目，但可以使用受支援的災害復原目的地 (lakehouses 或倉儲) 來保護資料。
KQL 資料庫/查詢集：容錯移轉後無法存取 KQL 資料庫和查詢集。 需要進行更多必要步驟才能保護 KQL 資料庫和查詢集中的資料。
在災害案例中，Fabric 入口網站和 Power BI 處於唯讀模式，而且其他 Fabric 項目無法使用，您可以使用 API 或第三方工具來存取儲存在 OneLake 中的資料。 入口網站和 Power BI 都會保有對該資料執行讀寫作業的能力。 此能力可確保重要資料仍可供存取和可供修改，並降低業務營運的中斷可能性。
OneLake 資料仍可透過多個通道來存取：
OneLake ADLS Gen2 API：請參閱連線到 Microsoft OneLake
可連線到 OneLake 資料的工具範例：
Azure 儲存體總管：請參閱整合 OneLake 與 Azure 儲存體總管
OneLake 檔案總管：請參閱使用 OneLake 檔案總管來存取 Fabric 資料
階段3：復原方案
雖然 Fabric 可確保資料在災害發生後仍可供存取，但您也可以採取行動，將其服務完全恢復到事件發生前的狀態。 本節提供逐步指南，以協助您完成復原程序。
復原步驟
在災害發生後，於任何區域中建立新的 Fabric 容量。 鑒於這類事件發生期間的需求很高，建議您選取主要地理位置以外的區域，以提高計算服務可用性的可能性。 如需如何建立容量的相關資訊，請參閱購買 Microsoft Fabric 訂用帳戶。
在新建立的容量中建立工作區。 如有必要，請使用與舊工作區相同的名稱。
使用與您想要復原的項目相同的名稱建立項目。 如果您使用自訂指令碼來復原 Lakehouse 和倉儲，此步驟便很重要。
還原項目。 針對每個項目，請遵循體驗特定災害復原指導中的相關章節來還原項目。