次の方法で共有

Azure SQL Managed Instance での管理操作の概要

適用対象:Azure SQL Managed Instance

この記事では、 Azure SQL Managed Instance の管理時に発生するさまざまな操作の概要について説明します。 管理操作は、インスタンスを作成、更新、または削除するときにバックエンドで実行される操作です。

各管理操作の手順と推定期間の詳細については、管理操作の 期間を確認します。

管理操作とは

Azure SQL Managed Instance の管理には、次の操作が含まれます。

  • 作成: 新しい SQL マネージド インスタンスを最初に作成するときに発生する操作。 これには、基になる仮想マシン (VM) グループの作成と、SQL Database Engine プロセスのデプロイが含まれます。
  • 更新: コンピューティングまたはストレージのスケーリング、サービス レベルの変更、インスタンス構成の更新など、既存の SQL マネージド インスタンスのプロパティを変更するときに発生する操作。 更新を行うには、多くの場合、VM グループのサイズ変更と、データのシード処理、および新しい SQL Database エンジン プロセスへのフェールオーバーが含まれます。
  • 削除: インスタンスに関連付けられている VM グループなどのリソースのクリーンアップなど、既存の SQL マネージド インスタンスを削除するときに発生する操作。

各管理操作の手順と推定期間の詳細については、管理操作の 期間を確認します。

SQL Managed Instance の管理操作は、次の基になるプロセスによって実行されます。

  • 仮想マシン (VM) グループの操作: SQL マネージド インスタンスをホストする基になる VM グループの作成と管理を伴う操作。 これには、VM グループのサイズ変更、新しい VM グループの作成、それらのグループ内の仮想マシンの管理が含まれます。
  • シード処理: SQL Database Engine プロセス間でのデータの初期化と同期。通常は、フェールオーバーの準備を行います。
  • フェールオーバー: 同じまたは新しい VM グループ内の別の SQL Database Engine プロセスへのトラフィックのフェールオーバーに関連する操作。

VM グループの操作

Azure 仮想ネットワーク内のデプロイをサポートし、顧客に分離とセキュリティを提供するため、SQL Managed Instance では仮想クラスターに依存しています。 仮想クラスターは、仮想ネットワーク サブネット内にデプロイされ、VM グループ内に編成された、分離された仮想マシン ( VM) の専用セットを表します。 基本的に、空のサブネットにデプロイされたすべての SQL マネージド インスタンスは、最初の VM グループを構築する新しい仮想クラスターになります。

SQL マネージド インスタンスに対する後続の管理操作は、基になる VM グループに影響を与える可能性があります。 基になる VM グループに影響を与える変更は、管理操作の期間に影響を与える可能性があります。仮想クラスターへの仮想マシンのデプロイには、新しいデプロイや既存のインスタンスへの更新を計画するときに考慮する必要があるオーバーヘッドが伴います。

仮想クラスター アーキテクチャの詳細については、「 仮想クラスター アーキテクチャ」を参照してください。

シード

シード処理は、特にデータベースのセットアップとレプリケーション中に、Azure SQL Managed Instance の操作において重要な役割を果たします。 シード処理は、インスタンス管理の重要な部分である SQL Database Engine プロセス間でデータを初期化および同期するプロセスです。 多くの場合、長時間の操作で最も時間のかかる手順ですが、シード処理は、正常で機能的な SQL マネージド インスタンス環境を確立するための基礎として機能します。

シード処理操作の推定期間については、「 管理操作の期間」を参照してください。

シード処理プロセスには、通常、サービス レベルに関係なく、次のステージが含まれます。

  • 初期化: システムはソースデータベースと移行先データベースを識別し、データ転送用に SQL Database Engine プロセスを準備するタスクを多数開始します。
  • データ転送: 実際のデータ パッケージは、ソースからターゲット SQL Database Engine プロセスに転送されます。これには、シナリオに応じて、データベースの完全コピーまたは部分コピーが含まれます。
  • 同期: 初期データ転送が完了すると、システムはトランザクション ログ ブロックのレプリケーションを通じて後続の更新または変更を同期して、データの整合性を確保します。
  • 検証と最終処理: プロセスが最終処理され、ターゲット SQL Database エンジン プロセスが検証され、レプリケーションとシード処理が成功したことが確認されます。 新しい SQL データベース エンジン プロセスにトラフィックがルーティングされるようにフェールオーバーが発生します。

サービス レベルを Business Critical サービス レベルに変更する場合を除き、General Purpose サービス レベルにはデータ シード処理はありません。 General Purpose サービス レベルでの管理操作には、古い SQL Database Engine プロセスからリモート ストレージをデタッチし、それを新しい SQL Database Engine プロセスにアタッチする必要があります。

逆に、高パフォーマンスワークロード用に設計された Business Critical サービス レベルには、ローカル ストレージとコンピューティング層とストレージ レイヤーのコード傾向が必要です。 そのため、このサービス レベルのほぼすべての操作とシナリオでは、データの可用性と一貫性を確保するためにシード処理が必要になります。

シード処理がトリガーされるかどうかは、次のような特定のシナリオとサービス レベルによって異なります。

  • General Purpose および Next-Gen General Purpose サービス レベル:
    • Business Critical サービス レベルへの変更 - データは、リモート ストレージから General Purpose サービス レベルで使用されるローカル ストレージに転送する必要があります。
    • ゾーン冗長の有効化または無効化 - ゾーン冗長リージョン間でデータをコピーする必要があります。
  • Business Critical サービス レベル:
    • ストレージのスケーリング: ストレージはローカル コンピューターに物理的に接続されているため、すべてのストレージ変更で新しい VM グループを作成する必要があるため、データを古いマシンから新しいマシン (4 つのレプリカすべて) に転送する必要があります。
    • 仮想コアのスケーリング: すべてのコンピューティング スケーリング操作では新しい VM グループを作成する必要があるため、古いマシンから新しいマシン (4 つのレプリカすべて) にデータをコピーする必要があります。
    • ハードウェアまたはメンテナンス期間の変更: 一致する構成のサブネット内に VM グループが既に存在する場合、その VM グループのサイズが変更されます。 これが新しい構成の場合は、新しい VM グループが作成されます。 データは、古い VM グループから新しい VM グループ (4 つのレプリカすべて) にコピーする必要があります。
    • サービス レベルの変更: データは、ローカル ストレージから General Purpose サービス レベルで使用されるリモート ストレージにコピーする必要があります。
    • ゾーン冗長の有効化または無効化 - ゾーン冗長リージョン間でデータをコピーする必要があります。

シード処理の速度

シード処理プロセスの期間には、次の要因が影響します。

  • データベース サイズ: データベースのサイズを大きくすると、データを転送し、SQL Database Engine プロセス間で同期する時間が長くなります。
  • ネットワークの依存関係: ネットワーク帯域幅と待機時間は、シード処理の速度に大きな影響を与える可能性があります。
  • バックアップ操作と復元操作: ソース SQL Database エンジン プロセスでの継続的なバックアップ操作は、別の SQL Database エンジン プロセスに送信するデータの準備に影響を与える可能性があります。
  • インスタンス ワークロード: シード処理中のインスタンス ワークロードは、調整を引き起こし、プロセスを大幅に延長する可能性があります。

これらの要因のほとんどは制御できませんが、インスタンス トラフィックを管理してシード処理速度を大幅に最適化できます。 シード処理では、インスタンス トラフィックを管理するのと同じインスタンス コンピューティング リソースが使用されます。 シード処理中に大量のトラフィックが発生すると、仮想コアの可用性が低下し、シード処理プロセスの容量が不足し、調整が発生する可能性があります。

シード処理は、現在保存されているすべてのデータを 1 回の操作でパッケージ化して転送するように設計されているため、シード処理中のトラフィックが多い場合、同期に影響を与える可能性があります。 シード処理が開始された後に到着する古い SQL Database エンジン プロセスに対する後続のデータ変更は、フェールオーバーが発生する前に、トランザクション ログ ブロック レプリケーションを使用して新しい SQL Database Engine プロセスに増分同期する必要があります。 インスタンスの負荷が高い場合、シード処理が受信データに追いつくのが困難になり、同期フェーズで遅延や潜在的な障害が発生する可能性があります。 シード処理の開始後に古い SQL Database エンジン プロセスで継続的に高いトラフィックが発生すると、新しいデータが到着し続け、転送する必要があり、同期フェーズが完了しない状況が発生する可能性があります。 これにより、新しい SQL Database エンジン プロセスへのフェールオーバーを妨げる永続的なデータ転送サイクルが発生する可能性があります。

シード処理操作の推定期間については、「 管理操作の期間」を参照してください。

Azure インフラストラクチャと通知

シード処理は、 共有 Azure サービスに依存するため、正確に定量化したり、厳密に予測したりできないプロセスです。 データ転送とシード処理の操作は、Azure エコシステム全体で共有されるさまざまな内部 Azure サービスとインフラストラクチャに依存します。 これらのサービスは、Azure 内の他の多くの関連のないサービスによって利用されます。 Azure エコシステム内のすべてのサービスが利用可能なリソースを競合するため、複数の要因の影響を受けて一瞬の可用性が変動します。 Microsoft はインフラストラクチャの容量が動作する範囲を提供できますが、正確な予測を行うのは困難です。

フェールオーバー

インスタンス のフェールオーバーは、古い SQL データベース エンジン プロセスから、SQL マネージド インスタンスを含む VM グループ内のノードのグループ内の新しい SQL Database エンジン プロセスにトラフィックがルーティングされる瞬間です。 フェールオーバーは、特にインスタンスを更新する場合に、ほとんどの管理操作の重要な部分です。 トラフィックが新しい SQL Database エンジン プロセスにリダイレクトされている間に接続が切断された瞬間は、 フェールオーバーと呼ばれます。

インスタンスは、新しい SQL Database エンジン プロセスにトラフィックが再ルーティングされるときに、 フェールオーバー中にのみ使用できません。 Business Critical サービス レベルでは、インスタンスは最大 20 秒間使用できませんが、General Purpose サービス レベルでは、インスタンスを最大 2 分間使用できません。 Business Critical サービス レベルでのデータベースの再シードなど、管理操作のためにフェールオーバーの準備のために発生するバックエンド操作はバックグラウンドで発生し、インスタンスの可用性には影響しません。

サービス レベル間のアーキテクチャの違いについては、可用性の詳細について説明 します。

管理操作の相互影響

SQL マネージド インスタンスに対する管理操作は、同じサブネット内に配置された他のインスタンスの管理操作に影響する可能性があります。

  • 仮想クラスターで実行時間の長い復元操作を実行すると、作成操作やスケール操作など、同じ仮想クラスター内の他の操作が保留になります。

    例： 実行時間の長い復元操作と、VM グループを縮小するスケール要求がある場合、復元操作が完了するまでに圧縮要求の完了に時間がかかります。

  • その後のインスタンスの作成またはスケーリング 操作は、VM グループのサイズ変更を開始した、以前に開始されたインスタンスの作成またはインスタンス スケールによって保留されます。

    例： 同じ VM グループの下に同じサブネットに複数の作成要求またはスケール要求があり、そのうちの 1 つが VM グループのサイズ変更を開始した場合、最初の操作要求の 5 分以上後に送信されたすべての要求は予想よりも長く続きます。これらの要求は、再開する前にサイズ変更が完了するまで待機する必要があるためです。

  • 1 分間に送信された作成/スケール操作 はバッチ処理され、並列で実行されます。

    例： 1 分間に送信されたすべての操作に対して 1 つの仮想クラスターサイズ変更のみが実行されます (最初の操作要求が送信された時点から測定されます)。 最初の要求が送信されてから 1 分以上後に別の要求が送信された場合、仮想クラスターのサイズ変更が完了するまで待機してから実行が開始されます。

重要

進行中の別の操作のために保留になっている管理操作は、続行する条件が満たされると自動的に再開されます。 一時停止された管理操作を再開するために必要なユーザー操作はありません。

管理操作の監視

管理操作の進行状況と状態を監視する方法については、「azure SQL Managed Instance 管理操作の監視を参照してください。

管理操作の取り消し

管理操作を取り消す方法については、「Azure SQL Managed Instance 管理操作の取り消しを参照してください。

関連コンテンツ