新しいリージョンへのリソースの移動 - Azure SQL Database & Azure SQL Managed Instance

  • [アーティクル]

適用対象:Azure SQL データベースAzure SQL Managed Instance

この記事では、データベースまたはマネージド インスタンスを新しいリージョンに移動する方法に関する一般的なワークフローについて説明します。

概要

既存のデータベースまたはマネージド インスタンスをリージョン間で移動することが必要になるさまざまなシナリオがあります。 たとえば、ビジネスを新しいリージョンに拡張しており、新しい顧客ベース用にそれを最適化したい場合があります。 コンプライアンス上の理由により、操作を別のリージョンに移動する必要がある場合や、 Azure が、近接性を向上させ、カスタマー エクスペリエンスを向上させる、新しいリージョンをリリースした場合もあります。

この記事では、リソースを別のリージョンに移動するための一般的なワークフローについて説明します。 このワークフローは次のステップで構成されます。

  1. 移動の前提条件を確認します。
  2. スコープ内のリソースの移動を準備します。
  3. 準備プロセスを監視します。
  4. 移動プロセスをテストします。
  5. 実際の移動を開始します。
  6. ソース リージョンからリソースを削除します。

Note

この記事は、Azure パブリック クラウド内または同じソブリン クラウド内での移行に適用されます。

Note

Azure SQL データベースとエラスティック プールを別の Azure リージョンに移動する場合、Azure Resource Mover (推奨) を使用することもできます。 これを行う詳細な手順については、このチュートリアルを参照してください。

Note

この記事では、Azure と対話するために推奨される PowerShell モジュールである Azure Az PowerShell モジュールを使用します。 Az PowerShell モジュールの使用を開始するには、「Azure PowerShell をインストールする」を参照してください。 Az PowerShell モジュールに移行する方法については、「AzureRM から Az への Azure PowerShell の移行」を参照してください。

データベースの移動

前提条件を確認する

  1. 各ソース サーバーにターゲット サーバーを作成します。

  2. PowerShell を使用して、適切な例外でファイアウォールを構成します。

  3. 正しいログインを使用してサーバーを構成します。 サブスクリプション管理者または SQL サーバー管理者でない場合は、管理者に協力を求め、必要なアクセス許可を割り当てます。 詳細については、ディザスター リカバリーの後に Azure SQL Database セキュリティを管理する方法に関する記事を参照してください。

  4. データベースが透過的なデータ暗号化 (TDE) で暗号化されていて、Azure Key Vault で独自の暗号化キー (BYOK またはカスタマー マネージド キー) を使用している場合は、ターゲット リージョンで適切な暗号化マテリアルがプロビジョニングされていることを確認してください。

    • 最も簡単な方法は、(ソース サーバーで TDE プロテクターとして使用されている) 既存のキー コンテナーからターゲット サーバーに暗号化キーを追加し、そのキーをターゲット サーバーの TDE プロテクターとして設定することです。

      Note

      1 つのリージョンのサーバーまたはマネージド インスタンスを、他のリージョンのキー コンテナーに接続できるようになりました。

    • ターゲット サーバーが古い暗号化キー (データベースのバックアップの復元に必要) にアクセスできるようにするためのベスト プラクティスとして、ソース サーバーで Get-AzSqlServerKeyVaultKey コマンドレットを実行するか、ソースのマネージド インスタンスで Get-AzSqlInstanceKeyVaultKey コマンドレットを実行して使用可能なキーの一覧を取得し、それらのキーをターゲット サーバーに追加します。
    • ターゲット サーバーで顧客が管理する TDE を構成する方法の詳細とベスト プラクティスについては、Azure Key Vault でのカスタマー マネージド キーを使用した Azure SQL Transparent Data Encryptionに関する記事を参照してください。
    • キー コンテナーを新しいリージョンに移動するには、「リージョン間で Azure キー コンテナーを移動する」を参照してください。

  5. データベース レベルの監査が有効になっている場合は、無効にし、代わりにサーバー レベルの監査を有効にします。 フェールオーバー後、データベース レベルの監査では、リージョン間のトラフィックが必要になります。これは、移動後には不要となり、不可能になります。

  6. サーバー レベルの監査では、次のことを確認します。

    • 既存の監査ログを含むストレージ コンテナー、Log Analytics、またはイベント ハブが、ターゲット リージョンに移動されていること。
    • ターゲット サーバーで監査が構成されていること。 詳細については、「SQL Database 監査の使用」を参照してください。

  7. インスタンスに長期リテンション ポリシー (LTR) がある場合、既存の LTR バックアップは現在のサーバーに関連付けられたままになります。 ターゲット サーバーが異なるため、たとえサーバーが削除されても、ソース サーバーを使用してソース リージョンのそれ以前の LTR バックアップにアクセスできるようになります。

    Note

    これは、ソブリン クラウドとパブリック リージョン間の移動には不十分です。 このような移行では、現在サポートされていない LTR バックアップをターゲット サーバーに移動する必要があります。

リソースを準備する

  1. ソースのサーバーとターゲットのサーバーとの間でフェールオーバー グループを作成します。

  2. 移動したいデータベースをフェールオーバー グループに追加します。

    追加されたすべてのデータベースのレプリケーションが自動的に開始されます。 詳細については、SQL Database でフェイルオーバー グループを使用する を参照してください。

準備プロセスを監視する

Get-AzSqlDatabaseFailoverGroup を定期的に呼び出して、ソースからターゲットへのデータベースのレプリケーションを監視することができます。 Get-AzSqlDatabaseFailoverGroup の出力オブジェクトには、Get-AzSqlDatabaseFailoverGroup のプロパティが含まれます。

  • ReplicationState = 2 (CATCH_UP) は、データベースが同期されており、安全にフェールオーバーできることを示します。
  • ReplicationState = 0 (SEEDING) は、データベースがまだシード処理されておらず、フェールオーバーの試行が失敗することを示します。

同期をテストする

ReplicationState が 2 になったら、セカンダリ エンドポイント <fog-name>.secondary.database.windows.net を使用して各データベースまたはデータベースのサブセットに接続し、データベースに対して任意のクエリを実行して、接続性、適切なセキュリティ構成、データ レプリケーションを保証します。

移動を開始する

  1. セカンダリ エンドポイント <fog-name>.secondary.database.windows.net を使用してターゲット サーバーに接続します。
  2. Switch-AzSqlDatabaseFailoverGroup を使用して、セカンダリ マネージド インスタンスを完全に同期したプライマリに切り替えます。 この操作は成功するか、そうでなければロールバックします。
  3. nslook up <fog-name>.secondary.database.windows.net を使用してコマンドが正常に完了したことを検証して、DNS CNAME エントリがターゲット リージョンの IP アドレスを指していることを確認します。 switch コマンドが失敗した場合、CNAME は更新されません。

ソース データベースを削除する

移動が完了したら、不要な料金が発生しないように、ソース リージョンのリソースを削除します。

  1. Remove-AzSqlDatabaseFailoverGroup を使用して、フェールオーバー グループを削除します。
  2. ソース サーバー上の各データベースに対して、Remove-AzSqlDatabase を使用して各ソース データベースを削除します。 これにより、geo レプリケーション リンクが自動的に終了します。
  3. Remove-AzSqlServer 使用してソース サーバーを削除します。
  4. キー コンテナー、監査ストレージ コンテナー、イベント ハブ、Microsoft Entra インスタンス、その他の依存リソースを削除して、課金されないようにします。

エラスティック プールの移動

前提条件を確認する

  1. 各ソース サーバーにターゲット サーバーを作成します。

  2. PowerShell を使用して、適切な例外でファイアウォールを構成します。

  3. 正しいログインを使用してサーバーを構成します。 サブスクリプション管理者またはサーバー管理者でない場合は、管理者に協力を求め、必要なアクセス許可を割り当てます。 詳細については、ディザスター リカバリーの後に Azure SQL Database セキュリティを管理する方法に関する記事を参照してください。

  4. データベースが透過的なデータ暗号化で暗号化されていて、Azure Key Vault で独自の暗号化キーを使用している場合は、ターゲット リージョンで適切な暗号化マテリアルがプロビジョニングされていることを確認してください。

  5. ソース エラスティック プールごとにターゲット エラスティック プールを作成して、同じ名前と同じサイズのプールが同じサービス レベルで作成されるようにします。

  6. データベース レベルの監査が有効になっている場合は、無効にし、代わりにサーバー レベルの監査を有効にします。 フェールオーバー後、データベース レベルの監査では、リージョン間のトラフィックが必要になります。これは、移動後には不要または不可能になります。

  7. サーバー レベルの監査では、次のことを確認します。

    • 既存の監査ログを含むストレージ コンテナー、Log Analytics、またはイベント ハブが、ターゲット リージョンに移動されていること。
    • 監査構成は、ターゲット サーバーで構成されます。 詳細については、SQL Database の監査に関する記事を参照してください。

  8. インスタンスに長期リテンション ポリシー (LTR) がある場合、既存の LTR バックアップは現在のサーバーに関連付けられたままになります。 ターゲット サーバーが異なるため、たとえサーバーが削除されても、ソース サーバーを使用してソース リージョンのそれ以前の LTR バックアップにアクセスできるようになります。

    Note

    これは、ソブリン クラウドとパブリック リージョン間の移動には不十分です。 このような移行では、現在サポートされていない LTR バックアップをターゲット サーバーに移動する必要があります。

移動の準備をする

  1. ソース サーバー上の各エラスティック プールとターゲット サーバー上の対応するエラスティック プールとの間に、個別のフェールオーバー グループを作成します。

  2. プール内のすべてのデータベースをフェールオーバー グループに追加します。

    追加されたデータベースのレプリケーションが自動的に開始されます。 詳細については、SQL Database でフェイルオーバー グループを使用する を参照してください。

    Note

    複数のエラスティック プールを含むフェールオーバー グループを作成することはできますが、プールごとに個別のフェールオーバー グループを作成することを強くお勧めします。 移動する必要のある複数のエラスティック プールにわたって多数のデータベースがある場合は、準備手順を並行して実行してから、移動手順を並行して開始することができます。 このプロセスは、同じフェールオーバー グループ内に複数のエラスティック プールがある場合と比べて、拡張性が高く、所要時間は短くなります。

準備プロセスを監視する

Get-AzSqlDatabaseFailoverGroup を定期的に呼び出して、ソースからターゲットへのデータベースのレプリケーションを監視することができます。 Get-AzSqlDatabaseFailoverGroup の出力オブジェクトには、Get-AzSqlDatabaseFailoverGroup のプロパティが含まれます。

  • ReplicationState = 2 (CATCH_UP) は、データベースが同期されており、安全にフェールオーバーできることを示します。
  • ReplicationState = 0 (SEEDING) は、データベースがまだシード処理されておらず、フェールオーバーの試行が失敗することを示します。

同期をテストする

ReplicationState が 2 になったら、セカンダリ エンドポイント <fog-name>.secondary.database.windows.net を使用して各データベースまたはデータベースのサブセットに接続し、データベースに対して任意のクエリを実行して、接続性、適切なセキュリティ構成、データ レプリケーションを保証します。

移動を開始する

  1. セカンダリ エンドポイント <fog-name>.secondary.database.windows.net を使用してターゲット サーバーに接続します。
  2. Switch-AzSqlDatabaseFailoverGroup を使用して、セカンダリ マネージド インスタンスを完全に同期したプライマリに切り替えます。 この操作は成功するか、成功しなかった場合はロールバックされます。
  3. nslook up <fog-name>.secondary.database.windows.net を使用してコマンドが正常に完了したことを検証して、DNS CNAME エントリがターゲット リージョンの IP アドレスを指していることを確認します。 switch コマンドが失敗した場合、CNAME は更新されません。

ソース エラスティック プールを削除する

移動が完了したら、不要な料金が発生しないように、ソース リージョンのリソースを削除します。

  1. Remove-AzSqlDatabaseFailoverGroup を使用して、フェールオーバー グループを削除します。
  2. Remove-AzSqlElasticPool を使用して、ソース サーバー上の各ソース エラスティック プールを削除します。
  3. Remove-AzSqlServer 使用してソース サーバーを削除します。
  4. キー コンテナー、監査ストレージ コンテナー、イベント ハブ、Microsoft Entra テナント、その他の依存リソースを削除して、課金されないようにします。

マネージド インスタンスの移動

前提条件を確認する

  1. ソース マネージド インスタンスごとに、ターゲット リージョン内に同じサイズである SQL Managed Instance のターゲット インスタンスを作成します。
  2. マネージド インスタンスのネットワークを構成します。 詳細については、「ネットワーク構成」を参照してください。
  3. 適切なログインを使用して、ターゲット master データベースを構成します。 サブスクリプションまたは SQL Managed Instance の管理者でない場合は、管理者に協力を求め、必要なアクセス許可を割り当てます。
  4. データベースが透過的なデータ暗号化で暗号化されており、Azure Key Vault で独自の暗号化キーを使用している場合は、同じ暗号化キーを持つ Azure Key Vault がソースおよびターゲットの両方のリージョンに存在していることを確認してください。 詳細については、Azure Key Vault のカスタマー マネージド キーを使用した Transparent Data Encryption に関する記事を参照してください。
  5. マネージド インスタンスに対して監査が有効になっている場合は、次のことを確認します。
    • 既存のログを含むストレージ コンテナーまたはイベント ハブが、ターゲット リージョンに移動されていること。
    • 監査がターゲット インスタンスで構成されていること。 詳細については、「SQL Managed Instance での監査に関する記事を参照してください。
  6. インスタンスに長期リテンション ポリシー (LTR) がある場合、既存の LTR バックアップは現在のインスタンスに関連付けられたままになります。 ターゲット インスタンスが異なるため、たとえインスタンスが削除されても、ソース インスタンスを使用してソース リージョンのそれ以前の LTR バックアップにアクセスできるようになります。

Note

これは、ソブリン クラウドとパブリック リージョン間の移動には不十分です。 このような移行では、現在サポートされていない LTR バックアップをターゲット インスタンスに移動する必要があります。

リソースを準備する

各ソース マネージド インスタンスと対応する SQL Managed Instance のターゲット インスタンスの間に、フェールオーバー グループを作成します。

各インスタンスのすべてのデータベースのレプリケーションが自動的に開始されます。 詳細については、自動フェールオーバー グループに関する記事を参照してください。

準備プロセスを監視する

Get-AzSqlDatabaseFailoverGroup を定期的に呼び出して、ソースからターゲットへのデータベースのレプリケーションを監視します。 Get-AzSqlDatabaseInstanceFailoverGroup の出力オブジェクトには、Get-AzSqlDatabaseInstanceFailoverGroup のプロパティが含まれます。

  • ReplicationState = CATCH_UP は、データベースが同期されており、安全にフェールオーバーできることを示します。
  • ReplicationState = SEEDING は、データベースがまだシード処理されておらず、フェールオーバーの試行が失敗することを示します。

同期をテストする

ReplicationState が CATCH_UP になったら、セカンダリ エンドポイント <fog-name>.secondary.<zone_id>.database.windows.net を使用して geo セカンダリに接続し、データベースに対して任意のクエリを実行して、接続性、適切なセキュリティ構成、データ レプリケーションを確認します。

移動を開始する

  1. セカンダリ エンドポイント <fog-name>.secondary.<zone_id>.database.windows.net を使用して、ターゲット マネージド インスタンスに接続します。
  2. Switch-AzSqlDatabaseFailoverGroup を使用して、セカンダリ マネージド インスタンスを完全に同期したプライマリに切り替えます。 この操作は成功するか、そうでなければロールバックします。
  3. nslook up <fog-name>.secondary.<zone_id>.database.windows.net を使用してコマンドが正常に完了したことを検証して、DNS CNAME エントリがターゲット リージョンの IP アドレスを指していることを確認します。 switch コマンドが失敗した場合、CNAME は更新されません。

ソース マネージド インスタンスを削除する

移動が完了したら、不要な料金が発生しないように、ソース リージョンのリソースを削除します。

  1. Remove-AzSqlDatabaseFailoverGroup を使用して、フェールオーバー グループを削除します。 これにより、フェールオーバー グループの構成が削除され、2 つのインスタンス間の geo レプリケーション リンクが終了します。
  2. Remove-AzSqlInstance を使用して、ソース マネージド インスタンスを削除します。
  3. リソース グループ内のその他のリソース (仮想ネットワーク、セキュリティ グループなど) をすべて削除します。

次のステップ

移行後のデータベースを管理します。