次の方法で共有


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

適用対象:Azure SQL Managed Instance

この記事では、同じ仮想ネットワーク内のサブネット間、または別のサブネットに Azure SQL Managed Instance を移動する方法について説明します。 この操作は、仮想コアのスケーリングやインスタンス サービス レベルの変更に似ています。 移動中、SQL Managed Instance は、フェールオーバーが発生したときの短いダウンタイムを除き、引き続き使用できます。通常は、実行時間の長いトランザクションが中断された場合でも、最大 10 秒間持続します。

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

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

要件と制限

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

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

サブネットの準備

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

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

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

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

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

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

すべての要件が満たされると、サブネットは [準備ができていません ] から [ マネージド インスタンスの準備完了 ] カテゴリに移動し、SQL マネージド インスタンスに使用できます。

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

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

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

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

注意

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

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

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

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

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

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

注意

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

フェールオーバー グループを使用して SQL Managed Instance を移行する場合は、次の前提条件が適用されます。

  • ターゲット サブネットには、フェールオーバー グループのレプリケーションに必要なセキュリティ規則がソース サブネットと同じである必要があります。

    • 2 つのインスタンス間のレプリケーション トラフィックを許可するために、他の SQL マネージド インスタンス サブネット (フェールオーバー グループ レプリカを保持するサブネット) からの接続用に、受信ポートと送信ポート 5022 とネットワーク セキュリティ グループ (NSG) の範囲 11000 ~ 11999 の両方を開きます。
  • ターゲット サブネットには、フェールオーバー グループのセカンダリ インスタンス レプリカを保持するサブネットと重複するアドレス範囲を含めることはできません。

    • たとえば、MI1 がサブネット S1 にある場合、フェールオーバー グループ内のセカンダリ インスタンスはサブネット S2 の MI2 です。 MI1 をサブネット S3 に移動する必要があります。 サブネット S3 のアドレス範囲をサブネット S2 と重複させることはできません。

フェールオーバー グループのネットワーク構成の詳細については、「 SQL マネージド インスタンス間の 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 の[概要]ウィンドウからインスタンスの移動操作を監視します。 通知を選択して、現在のステップに関する情報、合計ステップ、および操作を取り消すボタンを含む別のウィンドウを開きます。

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