エクスペリエンス固有のディザスター リカバリーのガイダンス

このドキュメントでは、地域障害が発生した場合にFabric データを復旧するためのエクスペリエンス固有のガイダンスを提供します。

シナリオ例

このドキュメントの多くのガイダンス セクションでは、説明と図の目的で次のサンプル シナリオを使用します。 必要に応じて、このシナリオに戻って参照してください。

リージョン A にワークスペース W1 があり、容量は C1 であるとします。 容量 C1 のディザスター リカバリーに戻った場合、OneLake データはリージョン B のバックアップにレプリケートされます。リージョン A が中断に直面した場合、C1 のFabric サービスはリージョン B にフェールオーバーします。

このシナリオを次の図に示します。 左側のボックスは、中断したリージョンを示しています。 中央のボックスは、フェールオーバー後にデータの可用性が継続されていることを表し、右側のボックスは、顧客がサービスを完全機能状態に復元する操作を行った後の、すべての対応が済んだ状況を示しています。

一般的な復旧計画を次に示します。

1. 新しいリージョンに新しいFabric容量 C2 を作成します。

2. C2 に新しい W2 ワークスペースを作成し、C1.W1 のものと同じ名前を付けて、対応する項目を含めます。

3. 中断した C1.W1 から C2.W2 にデータをコピーします。

4. コンポーネントごとの専用の手順に従って、項目を完全機能状態に復元します。

この復旧計画では、テナント のホーム リージョンが引き続き運用可能であることを前提としています。 テナント のホーム リージョンで障害が発生した場合、このドキュメントに記載されている手順は復旧に関連しています。この手順は、Microsoftによって最初に開始および完了する必要があります。

エクスペリエンス固有の復旧計画

次のセクションでは、復旧プロセスを通じて顧客を支援する各Fabricエクスペリエンスのステップ バイ ステップ ガイドを提供します。

Data Engineering

このガイドでは、Data Engineering エクスペリエンスでの復旧手順について説明します。 レイクハウス、ノートブック、Sparkジョブ定義、ユーザーデータ関数、GraphQL APIをカバーしています。

レイクハウス

顧客が、元のリージョンのレイクハウスを使用できないままになっています。 レイクハウスを復旧するために、顧客がワークスペース C2.W2 でそれを再作成できます。 レイクハウスを復旧するためにお勧めする方法は 2 つあります。

方法 1: カスタム スクリプトを使用して、レイクハウスの Delta テーブルとファイルをコピーする

顧客は、カスタム Scala スクリプトを使用してレイクハウスを再作成できます。

1. 新しく作成したワークスペース C2.W2 に、レイクハウス (LH1 など) を作成します。

2. ワークスペース C2.W2 に新しいノートブックを作成します。

3. 元の lakehouse からテーブルとファイルを回復するには、abfss などの OneLake パスを持つデータを参照します ( OneLake への Microsoft接続を参照してください)。 ノートブックに次のコード例 (Microsoft Spark Utilities の概要を参照) を使用して、"元の" lakehouse からファイルとテーブルの ABFS パスを取得できます。 (C1.W1 は実際のワークスペース名に置き換えます)

   notebookutils.fs.ls('abfs[s]://<C1.W1>@onelake.dfs.fabric.microsoft.com/<item>.<itemtype>/<Tables>/<fileName>')
   

4. 次のコード例を使用して、テーブルとファイルを新しく作成したレイクハウスにコピーします。

   1. Delta テーブルについては、テーブルを順番に1つずつコピーして新しいレイクハウスに復旧する必要があります。 レイクハウス ファイルの場合は、基になるすべてのフォルダーを含むファイル構造全体を 1 回の実行でコピーできます。

   2. スクリプトに必要なフェールオーバーのタイムスタンプについては、サポート チームにお問い合わせください。

   %%spark
   val source="abfs path to original Lakehouse file or table directory"
   val destination="abfs path to new Lakehouse file or table directory"
   val timestamp= //timestamp provided by Support
   
   notebookutils.fs.cp(source, destination, true)
   
   val filesToDelete = notebookutils.fs.ls(s"$source/_delta_log")
       .filter{sf => sf.isFile && sf.modifyTime > timestamp}
   
   for(fileToDelete <- filesToDelete) {
       val destFileToDelete = s"$destination/_delta_log/${fileToDelete.name}"
       println(s"Deleting file $destFileToDelete")
       notebookutils.fs.rm(destFileToDelete, false)
   }
   
   notebookutils.fs.write(s"$destination/_delta_log/_last_checkpoint", "", true)
   

5. スクリプトを実行すると、テーブルが新しい lakehouse に表示されます。

方法 2: Azure Storage Explorerを使用してファイルとテーブルをコピーする

元の Lakehouse から特定の Lakehouse ファイルまたはテーブルのみを回復するには、Azure Storage Explorerを使用します。 詳細な手順については、 Azure Storage Explorerを参照してください。 データ サイズが大きい場合は、方法 1 を使用します。

Fabricの具体化された湖ビューを復元する

フェールオーバー後も、元の地域で具体化されたレイクビューはお客様から利用できません。 更新スケジュールと実行履歴はセカンダリ リージョンにレプリケートされません。 それらを回復するには、Lakehouse データを復旧した後、次の手順を実行します。

• 前述のアプローチ 1 またはアプローチ 2 を使用して、Lakehouse テーブルを復旧します。 ソース テーブルのみをコピーします。
• MLV 定義を含むノートブックを回復します。 回復手順については、「 ノートブック」 セクションを参照してください。
• 回復したノートブックを実行して、新しい Lakehouse で MLV を再作成します。 MLV の作成の詳細については、「 具体化された Lake View を作成する」を参照してください。 MLV も前の手順でコピーされた場合は、 CREATE または REPLACE を実行して再作成します。
• 新しいワークスペースで MLV 更新スケジュールを手動で再作成します。 スケジュール履歴と実行メトリックは回復できません。
• MLV がセマンティック モデルまたはレポートをフィードする場合は、必要に応じて Lakehouse ID とデータセット ID の参照を確認して更新します。 更新されたセマンティック モデルにレポートを再接続し、データの鮮度を検証します。

Notebook

プライマリ リージョンのノートブックはお客様が使用できず、ノートブック内のコードはセカンダリ リージョンにレプリケートされません。 新しいリージョンにノートブック コードを復旧する場合、ノートブック コードの内容を復旧する方法は 2 つあります。

方法 1: Git 統合を使用したユーザー管理の冗長性 (パブリック プレビュー段階)

これを簡単かつ迅速に行う最善の方法は、git 統合Fabric使用し、ノートブックを ADO リポジトリと同期することです。 サービスを別のリージョンにフェールオーバーした後に、リポジトリを使用して、作成した新しいワークスペースでノートブックを再構築できます。

1. ワークスペースの Git 統合を構成し、Connect を選択し、ADO リポジトリと を同期します。

   

   次の図は、同期されたノートブックを示しています。

   

2. ノートブックを ADO リポジトリから復旧します。

   1. 新しく作成したワークスペースで、Azure ADO リポジトリにもう一度接続します。

      

   2. [ソース管理] ボタンを選択します。 次に、リポジトリの関連するブランチを選択します。 次に、[すべて更新] を選択します。 元のノートブックが表示されます。

      

      

   3. 元のノートブックに既定のレイクハウスがある場合、ユーザーは、「レイクハウス」セクションを参照してレイクハウスを復旧し、新しく復旧したレイクハウスを新しく復旧したノートブックに接続できます。

      

   4. Git 統合では、ノートブック リソース エクスプローラーでのファイル、フォルダー、またはノートブック スナップショットの同期をサポートしていません。

      1. ノートブック リソース エクスプローラーで元のノートブックにファイルがある場合:

         1. ファイルまたはフォルダーは、必ずローカル ディスクまたは他の場所に保存します。

         2. ローカル ディスクまたはクラウド ドライブから、ファイルを、復旧したノートブックに再アップロードします。

      2. 元のノートブックにノートブック スナップショットがある場合は、ノートブック スナップショットも独自のバージョン管理システムまたはローカル ディスクに保存します。

         

         

Git 統合の詳細については、「Git 統合の概要」を参照してください。

方法 2: 手動でコードの内容をバックアップする方法

Git 統合による方法を使用しない場合は、最新バージョンのコード、リソース エクスプローラー内のファイル、Git などのバージョン管理システム内のノートブック スナップショットを保存し、障害発生後にノートブックの内容を手動で復旧できます。

1. [ノートブックのインポート] 機能を使用して、復旧するノートブック コードをインポートします。

   

2. インポート後、目的のワークスペース ("C2.W2" など) に進んでそこにアクセスします。

3. 元のノートブックに既定のレイクハウスがある場合は、「レイクハウス」セクションを参照してください。 次に、新しく復旧したレイクハウス (元の既定のレイクハウスと同じ内容を含みます) を、新しく復旧したノートブックに接続します。

4. 元のノートブックでリソース エクスプローラーにファイルまたはフォルダーがある場合は、ユーザーのバージョン管理システムに保存されているファイルまたはフォルダーを再アップロードします。

Spark ジョブ定義

顧客が、プライマリ リージョンの Spark ジョブ定義 (SJD) を使用できないままになっていて、ノートブック内のメイン定義ファイルと参照ファイルは、OneLake 経由でセカンダリ リージョンにレプリケートされます。 SJD を新しいリージョンに復旧する場合は、以下で説明する手動の手順に従うと SJD を復旧できます。 SJD の履歴データは復旧されません。

Azure Storage Explorerを使用して元のリージョンからコードをコピーし、障害発生後に Lakehouse 参照を手動で再接続することで、SJD 項目を回復できます。

1. 新しい SJD 項目 (SJD1 など) を新しいワークスペース C2.W2 に作成します。設定と構成は、元の SJD 項目 (言語、環境など) と同じにします。

2. Azure Storage Explorerを使用して、Libs、Mains、Snapshots を元の SJD 項目から新しい SJD 項目にコピーします。

   

3. コードの内容が、新しく作成した SJD に表示されます。 新しく復旧したレイクハウスの参照は、手動でジョブに追加する必要があります (レイクハウスの復旧手順を参照してください)。 ユーザーは、元のコマンド ライン引数を手動で再入力する必要があります。

   

これで、新しく復旧した SJD を実行またはスケジュール設定できます。

Azure Storage Explorerの詳細については、「Integrate OneLake with Azure Storage Explorer」を参照>。

ユーザー データ関数

ユーザーデータ機能を健全な領域で回復するには、以下のいずれかの方法を用いてください。

アプローチ1:Git統合(推奨)

推奨される復旧メカニズムはFabric Git統合です。 ユーザーデータ機能プロジェクトをAzure DevOpsやGitHubリポジトリと同期させることで、フェイルオーバー後に新しいワークスペースで素早く再構築できます。

災害の前に備えろ

1. ユーザーデータ機能をホストするワークスペースに対してFabric Git統合を設定してください。
2. ワークスペースをAzure DevOpsまたはGitHubリポジトリに接続してください。
3. すべてのユーザーデータ機能をリポジトリにコミットし、変更を定期的に同期してください。
4. 必要に応じて、環境固有の設定を変数ライブラリに別々に保存することもできます。

回復後の手順

地域災害の後:

1. C2 のような正常なリージョンに新しい Fabric キャパシティを作成してください。
2. 新しい容量でW2のような新しいワークスペースを作成します。
3. ワークスペースを同じAzure DevOpsまたはGitHubリポジトリに接続してください。
4. ソース管理 を開き、リポジトリの内容をワークスペースに同期します。
5. レイクハウス、Fabric内のSQLデータベース、倉庫、ビジネスイベントなど、すべての依存するFabricリソースを再作成または復元できます。
6. ユーザーデータ機能を再デプロイします。
7. 関数の実行と依存関係の接続性を検証します。
8. 下流アプリケーション、データパイプライン、または統合された他の機能を更新して、復元された機能を参照してください。
9. すべてのシナリオをエンドツーエンドで検証します。

重要な考慮事項

• Git統合はソースコードとプロジェクトの資産のみを復元します。
• 過去の実行ログは復元されません。
• 下流のシステムではエンドポイントの再バインドが必要になることがあります。

詳細については、 ユーザーデータ機能のソース管理およびデプロイをご覧ください。

アプローチ2:手動回復

災害前にGit統合が設定されていなければ、ソースコードのバックアップからユーザーデータ機能を手動で再構築できます。

災害の前に備えろ

以下の作業を定期的に完了し、アーティファクトを外部ソース管理リポジトリまたはバックアップ場所に保存してください:

• 関数のソースコードをGitHubリポジトリにエクスポートします。
• 依存関係の情報を記録し保存しましょう。
• ドキュメント環境設定。

回復後の手順

地域災害の後:

1. C2 のような正常なリージョンに新しい Fabric キャパシティを作成してください。
2. 新しいワークスペース(例えばW2)を作成します。
3. 関数に必要なすべてのリソースを回復します。レイクハウス、Fabric内のSQLデータベース、ウェアハウス、イベントハウス、外部サービスなどです。
4. 新しいユーザーデータ関数プロジェクトを作成しましょう。
5. 関数のソースコードをインポートまたは再作成してください。
6. ランタイム設定を再適用してください。
7. すべての関数依存関係を再インストールしてください。
8. 関数を再デプロイしてください。
9. 認証と認可を再設定してください。
10. ビジネスイベントの出版社や消費者を再現する(もし使われるなら)。
11. シナリオや統合に対してエンドツーエンドの検証テストを完了させてください。

GraphQL

プライマリ リージョンの GraphQL 項目は、リージョンの障害後は使用できません。また、GraphQL の定義と構成はセカンダリ リージョンにレプリケートされません。 新しいリージョンで GraphQL を回復するには、次のいずれかの方法を使用します。

アプローチ1:Git統合を用いたユーザー管理冗長性

このプロセスを簡単かつ迅速に行う最善の方法は、git 統合Fabric使用し、GraphQL を ADO リポジトリと同期することです。 サービスが別のリージョンにフェールオーバーした後、リポジトリを使用して、作成した新しいワークスペースで GraphQL を再構築できます。

1. ターゲット容量とリージョンに新しいワークスペースを作成します。

2. それぞれの復旧手順に従って、Lakehouse、Warehouse、SQL データベースなど、すべての依存データ ソースを復旧します。

3. ソース ワークスペース ID、ソース成果物 ID、接続の詳細などの環境固有の参照を変更して、新しく復旧されたリソースを指すように GraphQL 定義を更新します。 この手順により、デプロイ時に正しいバインドが保証されます。

4. Git リポジトリから新しいワークスペースに GraphQL アーティファクトを再デプロイします。 この手順では、更新された定義を使用して API の構造と構成を再作成します。

5. ロール、アクセス制御、認証構成など、成果物の設定を再適用します。

6. 新しく作成された GraphQL エンドポイントを使用するようにアプリケーションまたは統合を更新して、エンドポイント参照を再適用します。

7. 新しく作成されたワークスペースを参照するように、古いワークスペースを指していた既存のデプロイ パイプラインを更新します。

8. API のエンド ツー エンドの機能を検証します。

方法 2: 手動によるアプローチ

Git 統合アプローチを使用しない場合は、次の手動アプローチを使用して GraphQL を復旧できます。

1. ターゲット容量とリージョンに新しいワークスペースを作成します。

2. Lakehouse、Warehouse、SQL データベースなど、依存するすべてのデータ ソースを復旧します。

3. スキーマ定義、データ ソース接続、リレーションシップなど、GraphQL API を新しいワークスペースで手動で再作成します。

4. ロール、アクセス制御、認証構成など、成果物の設定を再適用します。

5. 新しく作成された GraphQL エンドポイントを使用するようにアプリケーションまたは統合を更新して、エンドポイント参照を再適用します。

6. 新しく作成されたワークスペースを参照するように、古いワークスペースを指していた既存のデプロイ パイプラインを更新します。

7. API のエンド ツー エンドの機能を検証します。

重要な考慮事項

1. GraphQL は外部依存関係 (Lakehouse、Warehouse、SQL など) に依存しており、GraphQL デプロイの前に復旧する必要があります。

2. GraphQL API 定義には、環境固有の参照 ( sourceWorkspaceId や sourceItemIdなど) が含まれます。 新しいリージョンで復旧すると、これらの参照が無効になる可能性があります。 新しくプロビジョニングされたリソースを指すよう更新します。

3. ディザスター リカバリーシナリオでは、特に保存された資格情報またはワークスペース間接続を使用する場合、データ ソースの自動再バインドは保証されません。

4. 監視、承認、RBAC、イントロスペクションなどの他のアーティファクト設定は、フェールオーバー後に引き継がれない。 これらの設定は、新しいリージョンで再確立する必要があります。

References

• Fabric Git 統合の概要 - Microsoft Fabric |Microsoft Learn

• GraphQL 用 API のソース管理とデプロイ パイプライン - Microsoft Fabric |Microsoft Learn 

App

システムはFabricアプリ(コード、設定、メタデータを含む)を二次領域に複製しません。 プライマリーリージョンが失敗すると、アプリは利用できません。 復旧のために、アプリのソースコードをシステム外のGitHub、Azure DevOps、または他のソース管理システムに保存してください。 各基盤となるFabricデータストアの災害復旧ガイダンスに従い、アプリデータを個別に復旧してください。

手動によるアプローチ

地域の災害発生後に、アプリケーションのソースコードとRayfin CLIを使って手動でFabricアプリを復元できます。 

Prerequisites 

災害が発生する前:

• Fabric AppのソースコードをGitHub、Azure DevOps、または他のソース管理リポジトリに保存してください。 

• 回復のためのプロセスを記録してください。  

回復ステップ 

1. ターゲット容量とリージョンに新しいワークスペースを作成します。 

2. アプリケーションを再デプロイする前に、依存するリソースを復元してください。  

3. 最新のFabric Appソースコードはソース管理リポジトリまたはローカルバックアップから取得できます。 

4. アプリケーションソースディレクトリから、Rayfin CLIを使ってFabricアプリをリカバリーワークスペースに展開します。 rayfin up --workspace <new workspace> を実行します。 

5. アプリの子項目(Fabric SQL Database)は、それぞれの回復手順に従って復元します。  

6. 必要に応じて役割やアクセス制御を含むアーティファクトレベルの設定を再適用します。  

7. アプリケーションの機能を検証し、ユーザーが適切な権限を持っているか確認しましょう。  

重要 

• Fabric AppのソースコードをFabric領域外に保持してリカバリーを有効にしてください。  

• データベース内のアプリケーションデータはFabricアプリのデプロイプロセスの一部として復元されず、別途復元する必要があります。  地域の災害発生後に、アプリケーションのソースコードとRayfin CLIを使って手動でFabricアプリを復元できます。 

Data Science

このガイドでは、Data Science エクスペリエンスでの復旧手順について説明します。 ここでは、ML モデルと実験を取り上げます。

ML モデルと実験

顧客が、プライマリ リージョンの Data Science 項目を使用できないままになっていて、ML モデルと実験の内容とメタデータはセカンダリ リージョンにレプリケートされません。 これらを新しいリージョンで完全に復旧するには、コードの内容をバージョン管理システム (Git など) に保存し、障害発生後にコードの内容を手動で再実行します。

1. ノートブックを復旧します。 ノートブックの復旧手順を参照してください。

2. 構成、過去に実行されたときのメトリック、メタデータは、ペアになっているリージョンにはレプリケートされません。 障害発生後に ML モデルと実験を完全に復旧するには、データ サイエンス コードの各バージョンを再実行する必要があります。

Data Warehouse

このガイドでは、Data Warehouse エクスペリエンスの復旧手順について説明します。 ここでは、ウェアハウスを取り上げます。

倉庫

顧客は、元のリージョンのウェアハウスを使用できないままになっています。 ウェアハウスを復旧するには、次の 2 つの手順を使用します。

1. 元のウェアハウスからコピーするデータ用に、ワークスペース C2.W2 に新しい中間レイクハウスを作成します。

2. ウェアハウス エクスプローラーと T-SQL 機能を利用して、ウェアハウスの Delta テーブルを設定します ( Microsoft Fabricを参照)。

レイクハウスと T-SQL コードを使用したデータ インジェスト

新しく作成したワークスペース C2.W2 で:

1. C2.W2 で中間レイクハウス "LH2" を作成します。

2. 元のウェアハウスから、中間レイクハウスにある Delta テーブルを、レイクハウスの復旧手順に従って復旧します。

3. C2.W2 に新しいウェアハウス "WH2" を作成します。

4. ウェアハウス エクスプローラーで中間レイクハウスを接続します。

5. データ インポートの前にテーブル定義をどのようにデプロイするかに応じて、インポートに使用される実際の T-SQL は異なる可能性があります。 ウェアハウス テーブルをレイクハウスから復旧する場合、INSERT INTO、SELECT INTO、または CREATE TABLE AS SELECT のいずれかの方法を使用できます。 さらにこの例では、INSERT INTO flavor を使用する予定です。 (以下のコードを使用する場合は、サンプルを実際のテーブルと列の名前に置き換えます)

   USE WH1
   
   INSERT INTO [dbo].[aggregate_sale_by_date_city]([Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit])
   
   SELECT [Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit]
   FROM  [LH11].[dbo].[aggregate_sale_by_date_city] 
   GO
   

6. 最後に、Fabric ウェアハウスを使用してアプリケーションの接続文字列を変更します。

ミラー データベース

お客様はプライマリ リージョンのミラー化されたデータベースを使用できないままになり、設定はセカンダリ リージョンにレプリケートされません。 リージョンの障害が発生した場合にそれを回復するには、異なるリージョンの別のワークスペースにミラー化されたデータベースを作り直す必要があります。

Data Factory

プライマリ リージョンの Data Factory 項目はお客様が使用できなくなり、パイプラインまたはデータフロー gen2 項目の設定と構成はセカンダリ リージョンにレプリケートされません。 リージョンの障害が発生した場合にこれらの項目を復旧するには、別のリージョンの別のワークスペースに Data Integration 項目を再作成する必要があります。 以下のセクションで詳細について説明します。

データフロー Gen2

新しいリージョンに Dataflow Gen2 項目を復旧する場合は、PQT ファイルを Git などのバージョン管理システムにエクスポートし、障害発生後に Dataflow Gen2 の内容を手動で復旧する必要があります。

1. Dataflow Gen2 項目の Power Query エディターの [ホーム] タブで、Export テンプレート を選択します。

   

2. [テンプレートのエクスポート] ダイアログで、このテンプレートの名前 (必須) と説明 (省略可能) を入力します。 終了したら、OK を選択します。

   

3. 障害発生後、新しいワークスペース "C2.W2" に新しい Dataflow Gen2 項目を作成します。

4. Power Query エディターの現在のビュー ウィンドウで、Power Query テンプレートから Import を選択します。

   

5. [開く] ダイアログで、既定のダウンロード フォルダーを参照し、前の手順で保存した .pqt ファイルを選択します。 その後、 [開く] を選択します。

6. その後、テンプレートが新しい Dataflow Gen2 項目にインポートされます。

ディザスターリカバリー発生時には、データフローの「名前を付けて保存」機能は利用できません。

Pipelines

リージョン障害が発生した場合、お客様はパイプラインにアクセスできません。また、構成はペアリージョンにレプリケートされません。 異なるリージョン間で複数のワークスペースに重要なパイプラインを構築することをお勧めします。

ジョブのコピー

CopyJob ユーザーは、地域の災害から保護するための予防的な対策を講じなければなりません。 次の方法では、地域的な障害が発生した後も、ユーザーの CopyJobs を引き続き使用できます。

Git 統合によるユーザー管理の冗長性 (パブリック プレビュー段階)

このプロセスを簡単かつ迅速に行う最善の方法は、Git 統合Fabric使用してから、CopyJob を ADO リポジトリと同期することです。 サービスが別のリージョンにフェールオーバーした後、リポジトリを使用して、作成した新しいワークスペースで CopyJob を再構築できます。

1. ワークスペースの Git 統合を構成し、ADO リポジトリとの [接続と同期] を選択します。

   

   次の図は、同期された CopyJob を示しています。

   

2. ADO リポジトリから CopyJob を回復します。

   1. 新しく作成したワークスペースで、Azure ADO リポジトリにもう一度接続して同期します。 このリポジトリ内のすべてのFabric項目は、新しいワークスペースに自動的にダウンロードされます。

      

   2. 元の CopyJob が Lakehouse を使用している場合、ユーザーは Lakehouse セクション を参照して Lakehouse を回復し、新しく回復した CopyJob を新しく回復した Lakehouse に接続できます。

Git 統合の詳細については、「Git 統合の概要」を参照してください。

Apache Airflow ジョブ

Fabricユーザーの Apache エアフロー ジョブは、地域の災害から保護するための予防的な対策を講じなければなりません。

Fabric Git 統合を使用して冗長性を管理することをお勧めします。 まず、エアフロー ジョブを ADO リポジトリと同期します。 サービスが別のリージョンにフェールオーバーする場合は、リポジトリを使用して、作成した新しいワークスペースでエアフロー ジョブを再構築できます。

これを実現する手順を次に示します。

1. ワークスペースの Git 統合を構成し、ADO リポジトリとの "接続と同期" を選択します。

2. その後、エアフロー ジョブが ADO リポジトリに同期されていることがわかります。

3. ADO リポジトリからエアフロー ジョブを回復する必要がある場合は、新しいワークスペースを作成し、Azure ADO リポジトリに再度接続して同期します。 このリポジトリ内のすべてのFabric項目 (エアフローを含む) は、新しいワークスペースに自動的にダウンロードされます。

リアルタイム インテリジェンス

このガイドでは、リアルタイムインテリジェンス・エクスペリエンスでの復旧手順について説明します。 ここでは、KQL データベース/クエリセットとイベントストリームを取り上げます。

Activator

プライマリ リージョンのアクティベーター項目はお客様が使用できず、アクティブ化トリガーの定義はセカンダリ リージョンにレプリケートされません。 アクティベーター ユーザーは、地域のディザスター リカバリーに備えるために事前に手順を実行する必要があります。

地域的な障害が発生した場合に Activator 項目を確実に回復できるようにするには、トリガー定義をバックアップし、別のリージョンのワークスペースに復元するように、Fabric Git 統合を設定します。

1. Activator 項目を含むワークスペースFabric Git 統合を構成し、トリガー定義を Git リポジトリと同期します。
2. アクティブ化トリガー定義を定期的にコミットおよび同期したままにします。
3. 復旧中に、ターゲット リージョンに新しいワークスペースを作成します (C2.W2)、同じリポジトリに接続し、同期してトリガー定義を復元します。
4. 新しいワークスペース内のすべての Activator データ ソースと依存関係を再構成して検証します。

Git 統合の詳細については、「Git 統合の概要」を参照してください。

グラフ モデル/クエリセット

プライマリ リージョンの Graph モデルと Graph クエリセットの項目はお客様が使用できなくなり、これらの項目はセカンダリ リージョンにレプリケートされません。 復旧するには、別のリージョンで容量を作成または使用し、グラフ モデルと Graph クエリセットの項目を再作成します。

1. 障害の影響を受けない別のリージョンに既存のFabric容量を作成または使用します。

2. 新しいワークスペースを作成するか、その容量内の既存のワークスペースを使用します。

3. セカンダリ ワークスペースでグラフ モデル項目を再作成します (手順 2 で参照)。 ノード、エッジなどを含むモデル定義を、元のグラフ モデルと一致するように再構成します。

4. 元のレイクハウスが障害が発生したリージョンにある場合は、まず Lakehouse セクションに従って復旧します。

5. 新しく作成されたグラフ モデル項目の OneLake データ ソースとして lakehouse を接続します。 回復したレイクハウスが障害が発生したリージョンに存在する場合は使用し、使用可能な状態が維持されている場合は既存のレイクハウスに再接続します。

6. 新しいワークスペースの Graph モデルのデータ読み込みスケジュールまたは接続を再構成します。

7. セカンダリ ワークスペースで Graph クエリセット項目を再作成します。 元の Graph クエリセットからクエリと保存されたクエリ構成を手動で再入力します。

KQL データベース/クエリセット

KQL データベース/クエリセットのユーザーは、地域的な障害に対する予防的な保護対策を講じる必要があります。 次の方法を講じると、地域的な障害が発生した場合に、KQL データベースのクエリセット内のデータが安全でアクセス可能な状態に維持されます。

次の手順を使用すると、KQL データベースとクエリセットのための効果的なディザスター リカバリー ソリューションが確実に得られます。

1. 独立した KQL データベース: 専用のFabric容量に対して、2 つ以上の独立した KQL データベース/クエリセットを構成します。 耐障害性を最大化するためには、2 つの異なる Azure リージョン (できれば Azure ペア地域) に設定してください。

2. 管理アクティビティのレプリケート: 1 つの KQL データベースで実行された管理アクションを、もう一方にミラー化する必要があります。 こうすると、両方のデータベースの同期が維持されます。レプリケートする主なアクティビティは次のとおりです。

   • テーブル: テーブル構造とスキーマ定義がデータベースで整合していることを確認します。

   • マッピング: 必要なマッピングをすべて複製します。 データ ソースとコピー先が正しく揃っていることを確認します。

   • ポリシー: 両方のデータベースのデータ保持、アクセス、およびその他の関連ポリシーが同様であることを確認します。

3. 認証と認可の管理: レプリカごとに、必要なアクセス許可を設定します。 適切な認可レベルが確立され、セキュリティ標準を維持しながら、必要な担当者にアクセス権が付与されていることを確認します。

4. 並列データ インジェスト: 複数のリージョンでデータの整合性と準備態勢を維持するには、取り込み時と同じデータセットを同じタイミングで各 KQL データベースに読み込みます。

Eventstream

eventstream は、コードなしのエクスペリエンスでリアルタイム イベントをキャプチャ、変換、およびさまざまな宛先 (lakehouses、KQL データベース/クエリセットなど) にルーティングするための、Fabric プラットフォームの一元的な場所です。 コピー先がディザスター リカバリーに対応している限り、イベントストリームにおいてデータは失われません。 そのため、顧客は、これらのコピー先システムのディザスター リカバリー機能を使用してデータの可用性を確保する必要があります。

お客様は、複数サイトのアクティブ/アクティブ戦略の一環として、複数のAzure リージョンに同じ Eventstream ワークロードをデプロイすることで、geo 冗長性を実現することもできます。 複数サイトのアクティブ/アクティブ手法を使用すると、顧客はデプロイされたすべてのリージョンのワークロードにアクセスできます。 この方法は、ディザスター リカバリーに対する最も複雑でコストの高い方法ですが、ほとんどの状況で復旧時間をほぼゼロに短縮できます。 完全なジオ冗長性を実現するために、顧客は以下を行うことができます

1. 複数の異なるリージョンにデータ ソースのレプリカを作成する。

2. 対応するリージョンに Eventstream 項目を作成する。

3. これらの新しい項目を同じデータ ソースに接続する。

4. 異なるリージョンの eventstream ごとに同じ宛先を追加する。

ビジネス イベント、Fabric イベント、およびAzure イベント

ビジネス イベント、Fabric イベント、およびAzure イベントは、Microsoft Fabricで同じ Real-Time ハブ インフラストラクチャを共有しますが、ディザスター リカバリーを計画する前に理解しておく必要がある明確な起源、動作、および復旧要件があります。

• Fabric イベントは、ワークスペース アイテムのライフサイクルの変更 (lakehouse、ノートブック、またはウェアハウスの作成、更新、削除など)、ジョブの実行 (パイプラインの実行やノートブックの実行など)、OneLake ファイルとフォルダーの操作など、Fabric リソース自体によって生成されたアクティビティに反応するイベント サブスクリプションです。 これらのサブスクリプションは、プッシュベースおよびエフェメラルです。 サブスクリプションはセカンダリ リージョンにレプリケートされません。

• Azure イベントは、Azure Blob Storage アカウントによって生成されたアクティビティのイベント サブスクリプションです。 これらのAzure リソースは、Fabricの容量またはリージョンとは別に存在します。 Fabricリージョンの停止中も、Azure Blob Storage リソース自体は引き続き使用できますが、Real-Time ハブで構成されたサブスクリプションはセカンダリ リージョンにレプリケートされず、再作成する必要があります。

• ビジネス イベントは、チームが意味のあるビジネス シグナルを定義、発行、および操作できるようにする、Fabric Real-Time インテリジェンスの個別の機能です。 ビジネス イベントは、Activator、Spark ノートブック、またはユーザー データ関数を介してFabric内から生成され、その後、Activator、Eventhouse、Power Automateなどのダウンストリーム コンシューマーがそれらに対応できる Real-Time ハブに発行されます。 イベント スキーマは、スキーマ レジストリを通じて一元的に管理されます。 Eventhouse では、発行されたすべてのビジネス イベントが自動的に格納されるため、その復旧はビジネス イベント履歴の可用性に直接影響します。 パブリッシャーまたはコンシューマーの構成、スキーマ定義、またはサブスクリプションのいずれもセカンダリ リージョンにレプリケートされません。

次の手順を使用して、復旧リージョンの新しいワークスペースにビジネス イベント、Fabric イベント、およびAzure イベントを復元します。

ビジネス イベントの場合:

1. 発行元とコンシューマーが使用するビジネス イベントを再作成する方法については、Fabric Real-Time Hub でのビジネス イベントの作成に関する記事を参照してください。 ビジネス イベントの作成時に、イベント スキーマ セット リソースを作成します。 Eventhouse リソースは、シナリオに応じて省略可能です。 もしイベントスキーマセットをGit統合でバックアップしているなら、まず イベントスキーマセットのセクションに従って復元し、その後ビジネスイベントを復元したスキーマセットに向けます。

2. 次のパブリッシャーに関する記事 ユーザー データ関数をビジネス イベント パブリッシャーとして使用する、Activator をビジネス イベント パブリッシャーとして使用する、Notebook をビジネス イベント パブリッシャーとして使用する、Eventstream をビジネス イベント パブリッシャーとして使用する に従って、Spark ノートブックやユーザー データ関数など、ビジネス イベントを生成するパブリッシャー項目を新しいワークスペースに再作成します。

3. Eventhouse と Real-Time Dashboard Integration with Business Events and Consume Business Events from Activator の記事に従って、影響を受けるリージョンのビジネス イベントに最初に反応していたコンシューマー サブスクリプション (アクティベーター ルール、ノートブック トリガー、Power Automate フローなど) を Real-Time ハブに再作成します。

4. サブスクリプションがアクティブであり、データが復旧リージョン内の予想される宛先に到着していることを確認して、イベントがエンド ツー エンドでフローしていることを確認します。

Fabric イベントの場合:

1. Fabric Real-Time hub で Fabric イベントを確認するの記事に従って、復旧リージョンで復元されたワークスペース項目、ジョブ、または OneLake パスを指すサブスクリプションを Real-Time hub で再作成します。

2. サブスクリプションがアクティブであり、データが復旧リージョン内の予想される宛先に到着していることを確認して、イベントがエンド ツー エンドでフローしていることを確認します。

Azure イベントの場合:

1. Azure Blob Storage アカウントは、Fabricリージョンの停止の影響を受けません。 同じAzure Blob Storage アカウントを指す Real-Time ハブでイベント サブスクリプションを再作成するには、「Real-Time ハブのAzure Blob Storage イベントにアラートを設定する」の記事に従います。

2. サブスクリプションがアクティブであり、データが復旧リージョン内の予想される宛先に到着していることを確認して、イベントがエンド ツー エンドでフローしていることを確認します。

イベント スキーマ セット

イベントスキーマセットは、Real-Time Intelligenceにおけるイベントタイプおよびスキーマ定義を保持するFabric項目です。 他の機能はこれを基盤としています。出版社はそのスキーマに準拠したイベントを書き、消費者は同じ定義に対して読みます。

プライマリリージョンのイベントスキーマセットは顧客に利用できず、セカンダリリージョンにも複製されません。 しかし、イベントスキーマセットは一時的なサブスクリプションではなく、耐久性のある著者による定義であるため、事前にバックアップして復元し、手作業で再作成するのではなく復元できます。

推奨:Fabric Gitとの連携でバックアップを取ること

地域災害後にイベントスキーマセットを復元するには、災害発生前にFabric Git統合を設定し、イベントスキーマセットを含むワークスペースをGitリポジトリと同期してください。

1. イベントスキーマセットを含むワークスペースにFabric Git統合を設定し、Gitリポジトリと同期させます。

2. イベントスキーマセットはコミットし、定期的に同期させておきましょう。特にイベントタイプを追加したり、新しいスキーマバージョンを公開した後はなおさらです。

3. リカバリー中に、ターゲット領域(C2.)に新しいワークスペースを作成します。W2)を同じリポジトリに接続し、同期してイベントスキーマセットを復元します。 新しいワークスペースが空なので、Git同期はリポジトリからワークスペースの内容を取り込みます。

4. スキーマセットを使用しているパブリッシャーや消費者は、それらのアイテムタイプのガイダンスに従って再作成してください。

5. パブリッシャーが復元されたイベントタイプに対して公開できること、そして消費者が期待通りにイベントを受け取れることを検証してください。

同期定義には、スキーマセット内のイベントタイプ、スキーマ、そしてスキーマバージョンが含まれます。 出版社登録、消費者購読、イベント履歴は含まれていません。 スキーマセットを使うアイテムタイプのガイダンスに従い、それらを別途復旧してください。

代替案:手動で再作成する

災害発生前に Git 統合を設定していなかった場合は、イベントスキーマセットを作成および管理する の手順に従って復旧リージョンでイベントスキーマセットを再作成し、その後、スキーマセット内のイベントスキーマを作成および管理する の手順に従って、元のスキーマセットに含まれていたイベントタイプとスキーマを追加します。

Map

プライマリ リージョンのマップ アイテムは顧客が使用できなくなり、マップ アイテムはセカンダリ リージョンにレプリケートされません。

障害が発生したときに Map アイテムを回復する場合は、Fabric Git 統合を設定し、Map アイテムを Git リポジトリに>synchronize

復旧中に、Fabricの新しいリージョン/容量を設定した後、リポジトリを使用して、作成した新しいワークスペース内の Map 項目を再構築できます。 新しいワークスペースは空であるため、Git sync はリポジトリから空のワークスペースにコンテンツを取得します。 この手順により、マップ 項目が生き返ります。

オントロジ

Ontology ユーザーは、地域のディザスター リカバリーに備えるために積極的な手順を実行する必要があります。 以下に示すアプローチにより、地域の災害が発生した後も Ontology を回復可能な状態に保ち、迅速に復元できます。

復旧を有効にする最も簡単で最速の方法は、Fabric Git 統合を使用し、ontology を Azure DevOps (ADO) リポジトリと同期することです。 サービスが別のリージョンにフェールオーバーする場合は、このリポジトリを使用して、新しく作成されたワークスペースで Ontology を再構築できます。

プライマリ リージョンのオントロジ項目は、地域の災害後に顧客が利用できなく、オントロジ項目はセカンダリ リージョンにレプリケートされません。

障害発生時に Ontology 項目を復旧するには、Fabric Git 統合、および synchronize を事前に ADO リポジトリと共に構成します。

復旧中に、Fabricの新しいリージョンと容量が設定されたら、リポジトリを使用して新しいワークスペース内の Ontology 項目を再構築できます。 新しいワークスペースは空であるため、Git sync はリポジトリからワークスペースにコンテンツをプルし、Ontology 項目を効果的に復元します。

Plan

この記事では、IQ でのプラン エクスペリエンスの復旧手順について説明します。 計画、PowerTable、Intelligence、InfoBridge、関連するデータ資産など、主要なコンポーネントを復元するために必要な手順について説明します。

Plan項目を復元するためのGit統合

推奨される方法は、Fabric Git連携を使ってすべてのプラン項目をAzure DevOps(ADO)またはGitHubリポジトリと同期することです。 フェールオーバー後、リポジトリを使用して新しいワークスペース内の項目を復元します。

災害前（事前対策）:

1. ワークスペース W1 で、[ ワークスペースの設定] に移動し、Git 統合を構成します。

2. [接続] を選択し、ADO または GitHub リポジトリと同期します。

3. リポジトリにアップロードするプラン項目を選択し、「 コミット」を選択します。

   

4. プラン項目の Gitステータス が 同期されていることを確認してください。

5. コミット規範を確立する - プラン定義を大幅に変更するたびにコミットし、リポジトリが常に最新の状態を反映するようにします。

回復後の手順:

1. 正常なリージョンの容量 C2 内に新しいワークスペース W2 を作成します。

2. ワークスペース W2 で、[ワークスペースの設定] に移動し、同じ ADO/GitHub リポジトリに再接続します。

3. [ソース管理] を選択します。 関連するリポジトリ ブランチを選択し、[ すべて更新] を選択します。 すべてのプラン項目はW2にダウンロードされます。

次のコンポーネントは、復旧後に復元されます。

• PowerTable シート: ソース テーブルの設定、列の構成、行アクセス、ビジュアル プロパティ (レイアウト、形式など)、行の識別、コメント設定、緩やかに変化するディメンション (SCD)、承認、自動化、フォーム。
• 計画シート: シートのプロパティ (書式設定、条件付き書式など)、コメント設定、書き戻し設定、データ入力列、データ入力行、シナリオ、ブックマーク。
• InfoBridge: InfoBridge ソース、InfoBridge クエリ、変換手順、書き戻し先、書き戻し設定、リンクされたクエリ マッピング、クエリ グループ、ビジュアル プロパティ (ブレンド)。 ファイル ベースのソース (CSV、Excel)、ファイル ベースのソースを使用するワークロード間シートなど、これらの項目を回復することはできません。
• インテリジェンス： すべてのグラフとマトリックス。

Plan 用の Fabric SQL 復元

計画シートに入力されたデータ、PowerTable で使用されるテーブル、および書き戻しデータは SQL データベースに格納されるため、ディザスター リカバリー戦略の一部として考慮する必要があります。 SQL データベースを復旧するには、「 SQL データベース 」セクションを参照してください。

• 計画メタデータの復元:各計画項目は、コメント、シナリオ、データ入力、書き込み設定などの計画機能のメタデータを保存する__fabric_plan_sysデータベースに関連付けられています。 __fabric_plan_sys データベースは自動的に復元されないため、明示的に復旧する必要があります。

• 書き戻しデータベースの復元: プランで SQL 書き戻し先を使用している場合は、関連付けられているデータベースも手動で復旧する必要があります。 構成された SQL 書き戻し先は自動的には復元されません。

• PowerTable で使用されるテーブルの復元: PowerTable を使用して作成されたすべてのテーブルは、Fabric SQL データベースに格納されます。 また、DR 中にこれらのテーブルを復旧する必要があります。

操作エージェント

運用エージェントのユーザーは、リージョンのディザスター リカバリーに備えて事前に手順を実行する必要があります。 このセクションで説明する方法に従うと、リージョンの停止後にエージェントを迅速に復元できます。

Fabric Git 統合を使用して、ワークスペースをリポジトリと同期します。 この方法では、サービスが別のリージョンにフェールオーバーした場合に、新しいワークスペースでエージェント構成を再構築できます。

プライマリ リージョンのオペレーション エージェント項目は、リージョンの障害発生時に使用できません。 エージェントの構成、動作モデル、アクティビティ ログはセカンダリ リージョンにレプリケートされません。 進行中の操作、アクティブなチャット セッション、および障害発生時に以前に取り込まれたイベントも失われます。

復旧を準備するには、Fabric Git 統合を構成し、障害が発生する前にエージェント項目を ADO リポジトリと同期します。

復旧するときは、Fabricで新しいリージョンと容量を設定し、同期されたリポジトリを使用してエージェント構成を新しいワークスペースに復元します。 Git 同期では、リポジトリから空のワークスペースに格納されたコンテンツがプルされ、エージェント項目が再作成されます。

構成が復元されたら、参照されている Eventhouse (KQL) データベースまたはリージョン固有のデータ ソースが新しいリージョンでアクセス可能であることを確認します。 必要に応じて、エージェント構成のエンドポイント参照を更新します。 最後に、エージェントを再起動し、ユーザーに新しいチャット セッションを開始させます。 以前の会話は再開できません。

トランザクション データベース

このガイドでは、トランザクション データベース エクスペリエンスの復旧手順について説明します。

SQL データベース

リージョンの障害から保護するために、SQL データベースのユーザーは、データを定期的にエクスポートし、エクスポートされたデータを使用して、必要に応じて新しいワークスペースにデータベースを再作成するためのプロアクティブな対策を講じます。

これは、データベースの移植性を提供し、データベースのデプロイを容易にする SqlPackage CLI ツールを使用して実現できます。

1. SqlPackage ツールを使用して、データベースを .bacpac ファイルにエクスポートします。 詳細については、「 SqlPackage を使用したデータベースのエクスポート 」を参照してください。
2. .bacpac ファイルは、データベースとは異なるリージョンにある安全な場所に格納します。 たとえば、.bacpac ファイルを別のリージョンにある Lakehouse に格納したり、geo 冗長Azure Storage アカウントを使用したり、別のリージョンにある別のセキュリティで保護されたストレージ メディアを使用したりします。
3. SQL データベースとリージョンが使用できない場合は、sqlPackage で .bacpac ファイルを使用して、新しいリージョン (ワークスペース C2) のワークスペースにデータベースを再作成できます。上記のシナリオで説明したように、リージョン B の W2。 「SqlPackage を使用したデータベースのインポート」の手順に従って、.bacpac ファイルを使用してデータベースを再作成します。

再作成されたデータベースは、元のデータベースから独立したデータベースであり、エクスポート操作時のデータの状態を反映します。

フェールバックに関する考慮事項

再作成されたデータベースは独立したデータベースです。 再作成されたデータベースに追加されたデータは、元のデータベースには反映されません。 ホーム リージョンが使用可能になったときに元のデータベースにフェールバックする場合は、再作成されたデータベースから元のデータベースにデータを手動で調整することを検討する必要があります。

Platform

プラットフォームとは、すべてのワークロードに適用される、基になる共有サービスとアーキテクチャを指します。 このセクションでは、共有Fabric機能の復旧手順について説明します。

ワークスペースの監視

ワークスペースの監視は、有効にしたワークスペース内のアクティビティに関するログを収集します。 ワークスペースをC2として復旧した後。W2でワークスペース監視を有効にしてください。 復旧したワークスペースの監視データの収集を開始します。

元のワークスペースからのモニタリングデータ(C1.W1)は引き継がれません。なぜなら、モニタリングは動作するワークスペースの活動を反映しているからです。

変数ライブラリ

Microsoft Fabric変数ライブラリを使用すると、開発者はワークスペース内で項目の構成をカスタマイズして共有し、コンテンツライフサイクル管理を合理化できます。 ディザスター リカバリーの観点から、可変ライブラリ のユーザーは、地域の災害から予防的に保護する必要があります。 これは、Fabric Git 統合を通じて行うことができます。これにより、地域的な障害が発生した後も、ユーザーの変数ライブラリを引き続き使用できます。 変数ライブラリを回復するには、次のことをお勧めします。

• Fabric Git 統合を使用して、変数ライブラリを ADO リポジトリと同期します。 障害が発生した場合は、リポジトリを使用して、作成した新しいワークスペースで変数ライブラリを再構築できます。 次の手順を使用します。

  1. ここで説明するように、ワークスペースを Git リポジトリに接続します。
  2. WS とリポジトリが コミット と 更新と同期されていることを確認します。
  3. 復旧 - 障害が発生した場合は、リポジトリを使用して、新しいワークスペースで変数ライブラリを再構築します。

• 新しく作成したワークスペースで、Azure ADO リポジトリにもう一度接続して同期します。

• このリポジトリ内のすべてのFabric項目は、新しいワークスペースに自動的にダウンロードされます。

• Git から項目を同期した後、新しいワークスペースで変数ライブラリを開き、目的の アクティブな値セットを手動で選択します。

Fabric ワークスペースの顧客管理キー

Azure Key Vaultに格納されているカスタマー マネージド キー (CMK) を使用して、保存データのMicrosoftマネージド キーの上に暗号化レイヤーを追加できます。 Fabricリージョンでアクセスできなくなったり、操作できなくなったりした場合、そのコンポーネントはバックアップ インスタンスにフェールオーバーされます。 フェールオーバー中、CMK 機能は読み取り専用操作をサポートします。 Azure Key Vault サービスが正常であり、コンテナーへのアクセス許可がそのままである限り、Fabricは引き続きキーに接続し、データを正常に読み取れるようにします。 つまり、フェールオーバー中は、ワークスペース CMK 設定の有効化と無効化、キーの更新という操作はサポートされません。

OneLake

このセクションでは、OneLake 機能の回復手順について説明します。 OneLake データのディザスター リカバリーの詳細については、「 OneLake のディザスター リカバリー」を参照してください。

ライフサイクル管理ポリシー

リージョンでFabricアクセスできなくなったり、操作できなくなったりした場合でも、フェールオーバー中に OneLake ライフサイクル ポリシーを読み取って更新できます。 クール層またはコールド 層に移動されたデータは、その層に残ります。 次の手順に従って、既存のポリシーを新しい回復ワークスペースに適用できます。

1. 元のワークスペースでエクスポート ポリシーを呼び出し、ライフサイクル ポリシー全体を保存します。
2. エクスポートしたライフサイクル ポリシーを要求本文として使用して、回復したワークスペースでインポート ポリシーを呼び出します。

リソース インスタンスルール

リソース インスタンス ルールは、信頼されたAzureリソース ID を使用して、OneLake 内のデータへのアクセスを安全に制御するのに役立ちます。 リージョンフェールオーバー中、システムは引き続き読み取りアクセスに対して既存の規則を適用します。 ただし、ワークスペースが書き込み可能な状態に戻るまで、リソース インスタンス ルールを作成、更新、または削除することはできません。

関連情報

• Microsoft Fabricディザスター リカバリー ガイド