次の方法で共有


Azure SQL Managed Instance を複数のサブネットに移動する

適用対象: Azure SQL Managed Instance

この記事では、仮想コアのスケーリングやインスタンスのサービス レベルの変更と同様に、あるサブネットから別のサブネット (同じ VNet 内または別の VNet 内) に Azure SQL Managed Instance を移動する方法について説明します。 SQLManaged Instance は、移動中に使用できます。ただし、更新の最後にフェールオーバーが発生した場合を除き、短時間で実行されるトランザクションが中断された場合でも、通常は最大で10秒かかります。

インスタンスを別のサブネットに移動すると、次の仮想クラスター操作がトリガーされます。

  • 仮想クラスターにより、移動先サブネット内の基になるインフラストラクチャが構築されるか、サイズが変更されます。
  • 仮想クラスターは、ソースサブネットで削除または最適化されます。

要件と制限

SQL Managed Instance は、Azure 仮想ネットワーク内の専用サブネット内にデプロイする必要があります。 サブネット内にデプロイできるマネージインスタンスの数は、サブネットのサイズ (サブネットの範囲) によって異なります。 マネージインスタンスをデプロイするか、別のサブネットに移動するには、移行先サブネットに特定の ネットワーク要件が必要です。

インスタンスを別のサブネットに移動する前に、次の概念を理解しておくことをお勧めします。

サブネットの準備

マネージインスタンスを移動する前に、サブネットが Managed Instance の準備完了としてマークされていることを確認します。

Azure portal の 仮想ネットワーク UI では、マネージインスタンスの前提条件を満たす仮想ネットワークが Managed Instance の準備完了として分類されます。 マネージド インスタンスが既にデプロイされているサブネットがある仮想ネットワークには、仮想ネットワーク名の前に SQL Managed Instance アイコンが表示されます。 マネージド インスタンスの準備が整っている空のサブネットには、仮想ネットワーク サブネット アイコンが表示されます。

[準備中] としてマークされているサブネットは、SQL Managed Instance デプロイのすべての要件を満たしているわけではありません。 サブネット名の右側にある情報アイコンを使用して、サブネットの準備が整っていない理由と、サブネットがネットワーク要件を満たすことができるかどうかを確認します。 これらの要件の内容は次のとおりです。

  • Microsoft .Sql/managedInstances リソースプロバイダーへの委任
  • ルートテーブルのアタッチ
  • ネットワークセキュリティグループを接続する

サブネットが他の仮想ネットワークの一部である場合、追加の要件は次のようになります。

  • 現在の仮想ネットワークと移行先の仮想ネットワーク間の双方向ピアリング
  • 現在のサブネットと移行先サブネットでは、別々のルート テーブルとネットワーク セキュリティ グループが使用されます。

すべての要件が満たされると、サブネットは [準備中] カテゴリから [Ready for Managed Instance] (Managed Instance の準備完了) カテゴリに移動し、マネージド インスタンスに使用できるようになります。

既に使用されているサブネット (インスタンスのデプロイに使用されているサブネットに他のリソースを含めることはできません)、またはサブネットに異なる DNS ゾーン (サブネット間インスタンスの移動制限) があることは、常に [準備中] カテゴリの一部です。

Azure SQL Managed Instance サブネット オプションのスクリーンショット。

サブネットの状態と指定に応じて、移行先のサブネットに対して次の調整を行うことができます。

  • Managed Instance の準備ができています (既存の SQL Managed Instance が含まれています) : 調整は行われません。 これらのサブネットには既にマネージインスタンスが含まれているため、サブネットを変更すると既存のインスタンスに影響を与える可能性があります。
  • Managed Instance の準備完了 (空) : ワークフローは、ネットワークセキュリティグループとルートテーブル内のすべての必要な規則を検証し、必要であるが不足しているすべての規則を追加します。 1

注意

1 ソースサブネットの構成に追加されたカスタム規則は、移行先のサブネットにコピーされません。 ソースサブネット構成のカスタマイズは、移行先サブネットに手動でレプリケートする必要があります。 これを実現する1つの方法は、送信元と送信先のサブネットに同じルートテーブルとネットワークセキュリティグループを使用することです。

宛先サブネットの制限事項

既存のインスタンスの宛先サブネットを選択するときは、次の制限事項を考慮してください。

  • SQL Managed Instance は、次のいずれかのサブネットに移動できます。

  • 移動先サブネット内のインスタンスの DNS ゾーンは、移動元のインスタンスの DNS ゾーンと一致している必要があります。 この制限は、空でないサブネットに移動する予定の場合に適用されます。

    • 移動元の SQL Managed Instance の DNS ゾーンが保持されるように、移動先サブネットを特別に準備することができます。 準備を行うには、空のサブネットに新しい SQL Managed Instance を作成し、作成要求に dnsZonePartner パラメーターを指定します。 このパラメーターは値として SQL Managed Instance の ID を受け入れ、その場合に後で新しいサブネットに移動されるインスタンスを使用できます1

注意

1 SQL Managed Instance の DNS ゾーンはランダムに生成されるため、この方法以外にこれを指定する方法はありません。 また、現在のところ、既存の SQL Managed Instance の DNS ゾーンを更新する方法はありません。

  • フェールオーバー グループを使用して SQL Managed Instance を移行する場合は、次の前提条件が適用されます。
    • ターゲット サブネットには、ソース サブネットと同じフェールオーバー グループのレプリケーションに必要なセキュリティ規則がある必要があります。2 つのインスタンス間のレプリケーション トラフィックを許可するために、他のマネージド インスタンス サブネット (フェールオーバー グループ レプリカを保持するもの) からの接続に対して、受信と送信のポート 5022 とネットワーク セキュリティ グループ (NSG) の範囲 11000 から 11999 の両方を開きます。
    • ターゲット サブネットには、フェールオーバー グループのセカンダリ インスタンス レプリカを保持するサブネットと重複するアドレス範囲を含めることはできません。 たとえば、MI1 がサブネット S1 にある場合、フェールオーバー グループ内のセカンダリ インスタンスはサブネット S2 の MI2 です。 MI1 をサブネット S3 に移動する必要があります。 サブネット S3 のアドレス範囲をサブネット S2 と重複させることはできません。

フェールオーバー グループのネットワークを構成する方法の詳細については、マネージド インスタンス間の geo レプリケーションの有効化に関するページを参照してください。

操作の手順

インスタンスをあるサブネットから別のサブネットに移動するには、複数のステップが必要で、SQL Managed Instance の構成方法によっては、30 分から 6 時間かかる場合があります。

次の表は、インスタンスの移動操作中に発生する操作の手順の詳細を示しています。

[ステップ名] ステップの説明
要求の検証 送信されたパラメーターを検証します。 構成の誤りが検出された場合、操作は失敗し、エラーが発生します。
仮想クラスターのサイズ変更と作成 移行先サブネットの状態に応じて、仮想クラスターが作成またはサイズ変更されます。
新しいインスタンスの起動 SQL プロセスは、デプロイ先のサブネットにデプロイされている仮想クラスターで開始されます。
データベース ファイルのシード処理とデータベース ファイルのアタッチ サービスレベルによっては、データベースがシード処理されるか、データベースファイルがアタッチされます。
フェールオーバーの準備とフェールオーバー データがシード処理されるか、データベースファイルが再アタッチされると、システムによってフェールオーバーが準備されます。 すべての準備が整うと、システムは 短時間でフェールオーバーを実行します (通常は10秒未満)。
古い SQL インスタンスのクリーンアップ ソース仮想クラスターから古い SQL プロセスを削除します。
仮想クラスターの削除 ソースサブネット内の最後のインスタンスの場合、最後の手順では仮想クラスターを同期的に削除します。 それ以外の場合、仮想クラスターは非同期に最適化されます。

操作手順の詳細については、 「Azure SQL Managed Instance 管理操作の概要」を参照してください。

インスタンスを移動する

クロスサブネットインスタンスの移動は、インスタンスの更新操作の一部です。 既存のインスタンス更新 API、Azure PowerShell、Azure CLI の各コマンドは、サブネット ID プロパティを使用して強化されています。

Azure Portal で、[ネットワーク]ウィンドウの[サブネット] フィールドを使用して、インスタンスを移行先のサブネットに移動します。 Azure PowerShell または Azure CLI を使用する場合は、update コマンドで別のサブネット ID を指定して、インスタンスを既存のサブネットから宛先サブネットに移動します。

インスタンス管理コマンドの完全なリファレンスについては、「 management API reference for Azure SQL Managed Instance」を参照してください。

インスタンス サブネットを選択するオプションは、Azure Portal の [ネットワーク]ウィンドウにあります。 インスタンスの移動操作は、サブネットを選択して変更を保存すると開始されます。

移動操作の最初の手順は、移行先のサブネットをデプロイ用に準備することです。これには数分かかる場合があります。 サブネットの準備が整うと、インスタンスの移動管理操作が開始され、Azure portal に表示されます。

SQL Managed Instance の [ネットワーク] ペインでサブネットを選択する方法

Azure Portal の[概要]ウィンドウからインスタンスの移動操作を監視します。 通知を選択し、現在のステップ、全体のステップ、操作をキャンセルするボタンに関する情報が含まれる追加のウィンドウを開きます。

移動操作を監視してキャンセルできる [概要] ページを示すスクリーンショット。

次のステップ