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

適用対象: Azure SQL Managed Instance

この記事では、Azure SQL Managed Instance を新しいリージョンに移行する方法に関する一般的なワークフローについて説明します。

概要

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

リソースを別のリージョンに移動する一般的なワークフローは、次の手順で構成されます。

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

前提条件の確認

1. ソース マネージド インスタンスごとに、ターゲット リージョン内に同じサイズのインスタンスを作成します。
2. マネージド インスタンスのネットワークを構成します。 詳細については、「ネットワーク構成」を参照してください。
3. 適切なログインを使用して、ターゲット master データベースを構成します。 サブスクリプションまたは SQL Managed Instance の管理者でない場合は、管理者に協力を求め、必要なアクセス許可を割り当てます。
4. データベースが透過的なデータ暗号化 (TDE) で暗号化されていて、Azure Key Vault で独自の暗号化キー (BYOK またはカスタマー マネージド キー) を使用している場合は、ターゲット リージョンで適切な暗号化マテリアルがプロビジョニングされていることを確認してください。
   • これを行う最も簡単な方法は、(ソース インスタンスで TDE プロテクターとして使用されている) 既存のキー コンテナーからターゲット インスタンスに暗号化キーを追加し、そのキーをターゲット インスタンスの TDE プロテクターとして設定することです。これは、単一リージョン内のインスタンスが、他の任意のリージョンのキー コンテナーに接続できるようになっているためです。
   • ターゲット インスタンスが古い暗号化キー (データベースのバックアップの復元に必要) にアクセスできるようにするためのベスト プラクティスとして、ソース インスタンスで Get-AzSqlServerKeyVaultKey コマンドレットを実行するか、ソースのマネージド インスタンスで Get-AzSqlInstanceKeyVaultKey コマンドレットを実行して使用可能なキーの一覧を取得し、それらのキーをターゲット インスタンスに追加します。
   • ターゲット インスタンスで顧客が管理する TDE を構成する方法の詳細とベスト プラクティスについては、「Azure Key Vault でのカスタマー マネージド キーを使用した Azure SQL Transparent Data Encryption」に関する記事を参照してください。
5. マネージド インスタンスに対して監査が有効になっている場合は、次のことを確認します。
   • 既存のログを含むストレージ コンテナーまたはイベント ハブが、ターゲット リージョンに移動されていること。
   • 監査がターゲット インスタンスで構成されていること。 詳細については、「SQL Managed Instance での監査に関する記事を参照してください。
6. インスタンスに長期リテンション ポリシー (LTR) がある場合、既存の LTR バックアップは現在のインスタンスに関連付けられたままになります。 ターゲット インスタンスが異なるため、たとえインスタンスが削除されても、ソース インスタンスを使用してソース リージョンのそれ以前の 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. リソース グループ内のその他のリソース (仮想ネットワーク、セキュリティ グループなど) をすべて削除します。

関連するコンテンツ

• パフォーマンス ガイダンス
• 高可用性