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

この記事では、地域災害が発生した場合に備えた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データを復元した後に以下の手順を踏み入れてください:

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

Notebook

プライマリーのノートブックは顧客に利用できず、ノートブックのコードはセカンダリージョンに複製されません。 新しい領域でノートブックコードを復元するには、以下のいずれかの方法を用いてください。

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

Fabric Git連携を使ってノートブックをAzure DevOps(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の過去の実行履歴は復元されません。

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

1. 新しいワークスペースC2で新しいSJDアイテム(例えばSJD1)を作成します。W2は、元のSJDアイテムと同じ設定や設定(例:言語、環境など)で作成します。

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

   

3. コードの内容は新たに作成されたSJDに現れます。 新たに復元されたLakehouseの参照をジョブに手動で追加する必要があります( Lakehouseの復元ステップを参照)。 ユーザーは元のコマンドライン引数を手動で再入力する必要があります。

   

これで、新しく復旧した 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. GraphQLの定義を更新し、ソースワークスペースID、ソースアイテムID、接続詳細などの環境固有の参照を修正して、新たに回復したリソースを指すようにします。 この手順により、デプロイ時に正しいバインドが保証されます。

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データベース)は、それぞれの回復手順に従って復元します。  

6. 必要に応じてアイテムレベル設定を再適用し、役割やアクセス制御も含めて行ってください。  

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

重要 

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

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

Azure Databricks Storage

Azure Databricks Storage は OneLake にデータを保存します。 データをリージョン障害から保護するには、Azure Databricks ストレージを含む Fabric 容量で災害復旧設定を有効にしてください。 この設定を有効にすると、OneLake は非同期にデータを Azure のペア リージョンに複製します。

OneLakeが地域フェイルオーバーを開始すると、フェイルオーバーの完了後に、アプリケーションはOneLakeグローバルエンドポイントを通じて複製されたデータに引き続きアクセスできます。 OneLakeの公開APIを通じた継続的なアクセスは、別のAzure Databricksストレージアイテムを作成したり、データを別のワークスペースにコピーしたりする必要はありません。

OneLake の災害復旧およびデータ保護 について、該当する動作、考慮事項、制限について確認してください。

Azure Databricks特有の災害復旧計画については、「Disaster recovery - Azure Databricks」を参照してください。

Data Science

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

機械学習モデルと実験

プライマリーリージョンのデータサイエンスアイテムは顧客に利用できず、MLモデルや実験のコンテンツやメタデータもセカンダリーリージョンには複製されません。 これらを新しいリージョンで完全に復旧するには、コードの内容をバージョン管理システム (Git など) に保存し、障害発生後にコードの内容を手動で再実行します。

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

2. 設定、過去に実行されたメトリクス、メタデータはペアリージョンに複製されません。 災害後にMLモデルや実験を完全に復旧させるには、データサイエンスの各バージョンを再度実行する必要があります。

Data Warehouse

このガイドでは、Fabric Data Warehouse ワークロードの回復手順について説明します。 倉庫の品物をカバーしています。

倉庫

元の地域から倉庫にはアクセスできません。 ウェアハウスを復旧するには、次の 2 つの手順を使用します。

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

2. ウェアハウス エクスプローラーと T-SQL の機能を使用して、ウェアハウスの Delta テーブルにデータを取り込みます (Fabric Data Warehouse のテーブル を参照)。

レイクハウスと 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を用います。 以下のコードを使う場合は、サンプルを実際のテーブル名や列名に置き換えてください。

   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 Warehouseを使うアプリケーションでは接続文字列を変更してください。

ミラー データベース

顧客はプライマリリージョンからミラーされたデータベースにアクセスできず、設定もセカンダリリージョンには複製されません。 地域障害後にミラーされたデータベースを復元するには、別の地域のワークスペースで再作成する必要があります。

Data Factory

顧客はプライマリリージョンからData Factoryアイテムにアクセスできず、パイプラインやDataflow Gen2のアイテムの設定や設定もセカンダリーリージョンに複製されません。 地域障害後にこれらの項目を復元するには、別の地域のワークスペースでデータ統合項目を再作成する必要があります。 以下のセクションで詳細について説明します。

データフロー Gen2

新しい地域でDataflow Gen2のアイテムを復元するには、 .pqt ファイルをGitなどのバージョン管理システムにエクスポートし、災害後に手動でDataflow Gen2のコンテンツを復元します。

1. Dataflow Gen2の項目から、Power Queryエディターのホームタブで「テンプレートエクスポート」を選択してください。

   

2. テンプレート のエクスポート ダイアログで、このテンプレートの名前(必須)と説明(任意)を入力してください。 終了したら、OK を選択します。

   

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

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

   

5. 「開く」ダイアログで、デフォルトのダウンロードフォルダに行き、前のステップで保存した.pqtファイルを選択します。 その後、 [開く] を選択します。

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

Dataflowsの 「名前を付けて保存 」機能は、災害復旧時にサポートされていません。

Pipelines

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

コピー作業

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

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

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

1. ワークスペースのGit統合を設定し、「Azure DevOpsリポジトリと接続・同期」を選択してください。

   

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

   

2. Azure DevOpsリポジトリからCopyJobをリカバリーしてください。

   1. 新しく作成したワークスペースで、再びAzure DevOpsリポジトリに接続し同期してください。 このリポジトリ内のすべてのFabricアイテムは、新しいワークスペースに自動的にダウンロードされます。

      

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

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

Apache Airflow ジョブ

地域の災害からFabricのApache Airflowの仕事を守るために、積極的に対策を講じる必要があります。

冗長性はFabric Git統合を使って管理してください。 まず、Airflowの作業をADOリポジトリと同期させます。 もしサービスが別のリージョンにフェイルオーバーした場合、リポジトリを使って新しく作成したワークスペースでAirflowジョブを再構築できます。

この目標を達成するためには以下のステップを踏みます:

1. ワークスペースのGit連携を設定し、 ADOリポジトリと「接続」を選択して 同期してください。

2. その後、AirflowジョブがADOリポジトリに同期されているのが見えます。

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

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

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

Activator

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

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

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

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

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

顧客はプライマリリージョンからGraphモデルやGraphクエリセットのアイテムにアクセスできず、Fabricはこれらのアイテムをセカンダリーリージョンに複製しません。 別の領域で容量を復元・作成・使用し、そこでグラフモデルおよびクエリセットアイテムを再作成する方法。

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

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

3. ステップ2で参照した二次ワークスペースでグラフモデルアイテムを再作成します。 ノードやエッジなどを含むモデル定義を再構成し、元のグラフモデルに合わせます。

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

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

6. 新しいワークスペースでグラフモデルのデータロードスケジュールや接続を再設定してください。

7. セカンダリワークスペースでGraph querysetのアイテムを再作成します。 クエリと保存済みのクエリ設定を元のGraphクエリセットから手動で再入力してください。

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

KQLデータベースおよびクエリセットのユーザーは、地域災害から守るために積極的に対策を講じる必要があります。 以下のアプローチにより、地域災害が発生した場合にKQLデータベースやクエリセット内のデータは安全かつアクセス可能に保たれます。

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

1. 独立したKQLデータベースを設置する:専用のFabric容量で2つ以上の独立したKQLデータベースとクエリセットを構成します。 これらのデータベースは、2つの異なるAzureリージョン(できればAzureペアのリージョン)にまたがって設定し、レジリエンスを最大化しましょう。

2. 管理活動の再現:一方のKQLデータベースで行う管理操作をもう一方のデータベースにミラーリングします。 このアプローチにより、両方のデータベースが同期し続けられます。再現すべき主な活動には以下が含まれます:

   • テーブル:テーブル構造とスキーマ定義がデータベース間で一貫していることを確認しましょう。

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

   • ポリシー:両方のデータベースが類似したデータ保持、アクセス、その他の関連ポリシーを持っていることを確認してください。

3. 認証と認可を管理する:各レプリカに必要な権限を設定します。 必要な人員にアクセスを許可しつつ、セキュリティ基準を維持しつつ適切な権限レベルを設定してください。

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

Eventstream

eventstream は、コードなしのエクスペリエンスでリアルタイム イベントをキャプチャ、変換、およびさまざまな宛先 (lakehouses、KQL データベース/クエリセットなど) にルーティングするための、Fabric プラットフォームの一元的な場所です。 宛先が災害復旧をサポートしている限り、イベントストリームはデータを失いません。 したがって、これらのデスティネーションシステムの災害復旧機能を活用してデータの可用性を保証してください。

複数のAzureリージョンに同一のイベントストリームワークロードを展開することで、マルチサイトのアクティブ/アクティブ戦略の一環としてジオ・レダンダンシーを実現することもできます。 マルチサイト・アクティブ/アクティブ方式では、どの展開リージョンでもワークロードにアクセスできます。 この方法は、ディザスター リカバリーに対する最も複雑でコストの高い方法ですが、ほとんどの状況で復旧時間をほぼゼロに短縮できます。 完全な地理的冗長性を持たせるには:

1. 異なる地域でデータソースのレプリカを作成しましょう。

2. 対応する地域でイベントストリームの項目を作成します。

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

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

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

ビジネスイベント、Fabricイベント、AzureイベントはMicrosoft Fabricで同じ Real-Time ハブインフラを共有していますが、それぞれ異なる起源、挙動、復旧要件を持っています。 災害復旧を計画する前に、これらの違いを理解しましょう:

• Fabric Eventsは、Fabricリソース自身が生成した活動に反応するイベントサブスクリプションです。 これらのイベントには、ワークスペースのアイテムライフサイクル変更(レイクハウス、ノートブック、ウェアハウスの作成、更新、削除など)、ジョブ実行(パイプライン実行やノートブック実行など)、OneLakeのファイルおよびフォルダ操作が含まれます。 これらのサブスクリプションは、プッシュベースおよびエフェメラルです。 サブスクリプションは二次リージョンには複製されません。

• Azure イベントは、Azure Blob Storage アカウントによって生成されたアクティビティのイベント サブスクリプションです。 これらのAzure リソースは、Fabricの容量またはリージョンとは別に存在します。 Azure Blob Storageリソース自体はFabric地域障害時にも利用可能かもしれませんが、ハブ 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. Explore Fabric events in Fabric Real-Time hub の記事に従って、復旧リージョンで復元したワークスペース項目、ジョブ、または OneLake パスを指す Fabric 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 項目を効果的に復元します。

オントロジーエージェント

オントロジーエージェントのユーザーは、地域的な災害復旧に備えるために積極的に対策を講じる必要があります。 このセクションで説明するアプローチにより、地域災害後に新たに作成されたワークスペースでOntology Agent体験が復元されることを保証します。

オントロジーエージェントは、オントロジーアイテムや、レイクハウスなどオントロジーに接続されたデータソースに依存します。 地域災害後、顧客はプライマリリージョンのオントロジーエージェントセッションにアクセスできず、オントロジーエージェントセッションはセカンダリーリージョンに複製されません。 影響を受けた地域のアクティブなチャットセッション、進行中のアクション、会話履歴は再開できません。

災害時にOntology Agentのエクスペリエンスを復元するには、Fabric Git統合を設定し、Ontologyアイテムを事前にAzure DevOps (ADO) リポジトリと同期してください。

リカバリー中、Fabric内の新しいリージョンと容量が設定されたら、以下のステップを踏みます。

1. 新しい capacity で新しいワークスペースを作成しましょう。
2. 新しいワークスペースを、オントロジーアイテムを含む同じADOリポジトリに接続します。
3. Git syncを使ってOntology項目を新しいワークスペースに復元してください。
4. レイクハウスなどの依存するデータ項目は、それらの項目タイプのガイダンスに従って復元してください。
5. 復元されたデータがペア領域で利用可能であることを確認してください。 OneLake によってサポートされるデータの場合、データがペアリージョンに複製されていると仮定しますが、復旧時に複製されたデータの順序は想定しないでください。
6. 新たに復元されたオントロジーアイテムを復元したデータソースに接続します。
7. 新しいオントロジーエージェントセッションを開始し、エージェントが復旧したオントロジーアイテムおよびデータソースに接続できるかを検証します。

Planning

この記事では、IQにおける計画体験の回復手順について説明します。 計画シート、PowerTableシート、インテリジェンスシート、InfoBridgeおよび関連データ資産を含む主要コンポーネントを復元するために必要な手順が概説されています。

プラン項目を復元するための 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)、ファイル ベースのソースを使用するワークロード間シートなど、これらの項目を回復することはできません。
• インテリジェンス： すべてのグラフとマトリックス。

計画向けの 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) データベースまたはリージョン固有のデータ ソースが新しいリージョンでアクセス可能であることを確認します。 必要に応じて、エージェント構成のエンドポイント参照を更新します。 最後に、エージェントを再起動し、ユーザーに新しいチャット セッションを開始させます。 以前の会話は再開できません。

Databases

このガイドは、データベース体験のための復旧手順を説明しています。

SQL データベース

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

データベースの移植性を提供し、データベース展開を容易にする SqlPackage CLIツールを活用してください。

1. SqlPackage ツールを使用して、データベースを .bacpac ファイルにエクスポートします。 詳細については、「 SqlPackage を使用したデータベースのエクスポート 」を参照してください。
2. .bacpacファイルをデータベースとは異なる安全な場所に保存してください。 例としては、.bacpacファイルを別の地域にあるLakehouseに保存したり、地理的冗長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ワークスペース内の項目です。 アイテムをグループ化し、展開の順序を設定します。 各アイテムの展開前後にアクションを実行することができます。 アイテム定義にはこれらの設定、入力、アイテム参照が保存されます。 プランには実行時に使われる値のための別個ストアはありません。

Fabric Git統合を利用して回復に備えましょう:

1. プランを含むワークスペースをAzure DevOpsまたはGitHubリポジトリに接続してください。
2. プランと使用しているすべてのワークスペース項目をコミットしてください。
3. 各変更をコミットして、Gitが最新の定義を得られるようにしてください。

地域災害の後:

1. 健康的な領域に作業スペースを作りましょう。
2. ワークスペースを同じリポジトリとブランチに接続してください。
3. Gitからワークスペースを更新してください。 このステップで設計図とその項目が復元されます。

Gitはプランの定義を完全に復元します。 リンクされたアイテムのデータ復元や実行状態は行いません。 この記事のセクションを使って、それらのアイテムを回収してください。

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

Azure Key Vaultに保存された顧客管理鍵(CMK)を使い、Microsoft管理キーの上にデータ休止情報の暗号化層を追加できます。 Fabricがある地域でアクセス不能または動作不能になった場合、そのコンポーネントはバックアップインスタンスにフェイルオーバーされます。 フェールオーバー中、CMK 機能は読み取り専用操作をサポートします。 Azure Key Vaultサービスが正常で、Vaultへの権限が維持されている限り、Fabricは引き続き鍵に接続し、通常通りデータを読み取ることを可能にします。 つまり、フェールオーバー中は、ワークスペース CMK 設定の有効化と無効化、キーの更新という操作はサポートされません。

Fabric 内の SQL データベース向け Fabric Migration Assistant

Fabric Migration AssistantはSQL ServerデータベースをFabric段階でSQLデータベースに移行できます。移行ウィザードはターゲットデータベースを作成し移行を開始し、移行モニターはDACPACからのスキーマ展開中の進捗を追跡し、Migration Assistantはスクリプトエラーのレビューと修正、データベースの準備、コピージョブでデータのコピー、コピーの最終化をサポートします。

移行の進行状況は他の地域に複製されず、中断された展開も再開できません。 これらの失敗は元のSQL Serverデータベースには影響しないので、再度移行アシスタントを実行できます。 元のリージョンが利用できない場合は、まずこの記事の一般的な復旧計画に従ってペアリージョンでキャパシティC2とワークスペースW2を作成し、その後W2で移行を実行します。 元のリージョンが回復すれば、元のワークスペースで移行を再試すことができます。

地域的な混乱は、移住を失敗させる三つの原因となり得ます。

• ターゲットデータベースは作成されません

  もしFabricがターゲットデータベースを作成できない場合、移行ウィザードがエラーを表示し、移行が開始されません。 再試行は 移行開始 を選択し、後で再試行してください。

  ウィザードは不完全なデータベースを削除しようとしますが、障害時にクリーンアップが失敗することがあります。 再試す前に、ワークスペースでターゲット名のデータベースがないか確認してください。 削除する前に、失敗した未完成のデータベースであることを確認してください。

• 展開が失敗する

  展開が中断されると、移行モニターは進捗報告を停止し、ターゲットデータベースを開き、展開失敗を示すダイアログを表示します。 失敗したデプロイメントは再開できず、その試みによって作成されたデータベースはワークスペースに残ります。

  回復するには:

  1. Fabricが利用可能で、元の移行に使われたDACPACが使われているかを確認してください。
  2. 失敗した試みによって作成されたデータベースを特定してください。 保存する必要のないものがなければ削除してください。 そうでなければ、そのままにして新しいデータベースの名前を変えてください。
  3. ソースDACPACから新しい移行を実行してください。 移行によって新しいデータベースが作成されます。

  データはData Factoryのコピージョブによってコピーされます。 中断前にコピージョブをGitと同期していれば、 Data Factoryのガイダンスのコピージョブを参照してください。 そうでなければ、新しい移行の一環として新しいコピージョブを作成してください。

• 移行履歴が読み込まれません

  もしMigration Assistantが移行履歴を取得できない場合、移行情報が利用できなくなったと報告します。 現在のブラウザに保存された進行状況は保持され、ターゲットデータベースには影響を受けません。 ページをリフレッシュして再度移行履歴を読み込みます。

OneLake

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

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

もしFabricが特定の地域でアクセス不能または動作不能になった場合でも、フェイルオーバー中にOneLakeのライフサイクルポリシーを読み、更新することができます。 クール層またはコールド層に移動されたデータは、その層に保持されます。 既存のポリシーを新しいリカバリーワークスペースに適用するには、以下の手順に従ってください:

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

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

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

関連情報

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