次の方法で共有

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

このドキュメントでは、地域的な障害の発生時に 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 ジョブ定義を取り上げます。

レイクハウス

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

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

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

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

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

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

    mssparkutils.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

mssparkutils.fs.cp(source, destination, true)

val filesToDelete = mssparkutils.fs.ls(s"$source/_delta_log")
    .filter{sf => sf.isFile && sf.modifyTime > timestamp}

for(fileToDelte <- filesToDelete) {
    val destFileToDelete = s"$destination/_delta_log/${fileToDelte.name}"
    println(s"Deleting file $destFileToDelete")
    mssparkutils.fs.rm(destFileToDelete, false)
}

mssparkutils.fs.write(s"$destination/_delta_log/_last_checkpoint", "", true)

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

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

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

Note

上記で説明する 2 つの方法では、Delta 形式のテーブルのメタデータとデータの両方を復旧します。メタデータは OneLake のデータと併置され、保存されているからです。 Spark データ定義言語 (DDL) のスクリプト/コマンドを使用して作成されたデルタ形式以外のテーブル (CSV、Parquet など) の場合、ユーザーは Spark DDL スクリプト/コマンドを維持して再実行して回復する必要があります。

Notebook

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

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

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

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

    ADO リポジトリとノートブックを接続して同期する方法を示すスクリーンショット。

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

    ADO リポジトリと同期されたノートブックを示すスクリーンショット。

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

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

      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 を使用して元のリージョンからコードをコピーし、障害発生後にレイクハウスの参照を手動で再接続すると、SJD 項目を復旧できます。

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

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

    元の Spark ジョブ定義から新しい Spark ジョブ定義にコピーする方法を示すスクリーンショット。

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

    Spark ジョブ定義を回復するためのコマンド ライン引数を示すスクリーンショット。

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

Azure Storage Explorer の詳細については、「OneLake と Azure Storage Explorer の統合」を参照してください。

Data Science

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

ML モデルと実験

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

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

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

Data Warehouse

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

倉庫

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

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

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

Note

開発手法に従って、ウェアハウス コード (スキーマ、テーブル、ビュー、ストアド プロシージャ、関数定義、セキュリティ コード) を、安全な場所 (Git など) でバージョン管理し、保存しておくことをお勧めします。

レイクハウスと 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 ウェアハウスを使用してアプリケーションの接続文字列を変更します。

Note

リージョンをまたがるディザスター リカバリーと完全に自動化されたビジネス継続性を必要とする顧客の場合、Fabric Warehouse の 2 つのセットアップを別々の Fabric リージョンに保持し、両方のサイトに対して定期的なデプロイとデータ インジェストを行って、コードとデータ パリティのメンテナンスを行うことをお勧めします。

ミラー データベース

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

Data Factory

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

データフロー Gen2

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

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

    Power Query エディターを示すスクリーンショット。[テンプレートのエクスポート] オプションが強調されています。

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

    テンプレートのエクスポート方法を示すスクリーンショット。

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

  4. Power Query エディターの現在のビュー ペインで、[Power Query テンプレートからインポート] を選択します。

    [Power Query テンプレートからインポート] が強調されている現在のビューを示すスクリーンショット。

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

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

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

Pipelines

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

ジョブのコピー

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

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

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

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

    ADO リポジトリとワークスペースを接続して同期する方法を示すスクリーンショット。

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

    ADO リポジトリと同期された CopyJob を示すスクリーンショット。

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

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

      ADO リポジトリに再接続されたワークスペースを示すスクリーンショット。

    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 データベース/クエリセットとイベントストリームを取り上げます。

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

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

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

  1. 独立した KQL データベースの確立: 専用ファブリック容量に対して、2 つ以上の独立した KQL データベース/クエリセットを構成します。 回復性を最大限に高めるために、これらは 2 つの異なる Azure リージョン (できれば Azure でペアになったリージョン) にまたがって設定する必要があります。

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

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

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

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

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

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

Eventstream

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

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

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

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

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

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

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

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

SQL データベース

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

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

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

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

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

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

Platform

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

変数ライブラリ

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 設定の有効化と無効化、キーの更新という操作はサポートされません。

  • Last updated on