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 Engine プロセスへの フェールオーバーが含まれます。
• 削除: インスタンスに関連付けられている VM グループなどのリソースのクリーンアップなど、既存の SQL マネージド インスタンスを削除するときに発生する操作。

作成操作

作成操作では、仮想ネットワーク サブネット内に新しい SQL マネージド インスタンスのデプロイが開始され、インスタンスのコンピューティング、ストレージ、および SQL Database Engine 環境が設定されます。

通常、作成プロセスは次の 3 つのフェーズを経ます。

1. 要求の検証: 送信されたパラメーターは構文的および意味的に検証されます。 パラメーターが無効な場合 (間違ったサブネットやサポートされていない SKU など)、操作はすぐにエラーで失敗します。
2. VM グループを作成またはサイズ変更する: 新しいインスタンスをホストする VM グループを作成または拡張します。 操作の期間は、インスタンスがゾーン冗長かどうかによって異なります。
3. 新しい SQL インスタンスを起動する: 割り当てられた VM に対して SQL Database Engine プロセスをデプロイして開始します。

更新操作

更新操作では、コンピューティングやストレージのスケーリング、サービス レベルの変更、インスタンス構成の更新など、既存の SQL マネージド インスタンスのプロパティが変更されます。

通常、更新プロセスは次の 5 つのフェーズを経ます。

1. 要求の検証: 送信されたパラメーターは構文的および意味的に検証されます。 現在のインスタンス構成と要求された変更に基づいて、サポートされている更新プログラムの種類を確認します。 要求が無効な場合、操作はエラーで失敗します。
2. VM グループの作成またはサイズ変更: 変更に応じて、既存の VM グループのサイズが変更されるか、次の更新操作のように新しい VM グループが作成されます。
   • ストレージのスケールアップまたはスケールダウン
   • コンピューティングのスケールアップまたはスケールダウン
   • サービス レベルの変更
   • ハードウェアの変更
   • メンテナンス期間の調整
   • ゾーン冗長の有効化または無効化
3. SQL インスタンスの起動: 新しい SQL データベース エンジン プロセスが更新された構成で初期化されます。
   • 新しい VM グループが作成された場合、または既存の VM グループのサイズが変更された場合は、完全な SQL Database エンジンのデプロイが行われます。
4. シード/ストレージのアタッチ: 新しい VM グループまたはサイズ変更された VM グループにデータベースを準備します。 インスタンスは、このプロセス中に使用できます。
5. 準備してフェールオーバーする: トラフィックは新しいインスタンスにリダイレクトされます。
   • インスタンスは、新しい SQL Database エンジン プロセスにトラフィックが再ルーティングされるときに、フェールオーバー中にのみ使用できません。 Business Critical サービス レベルでは、インスタンスは最大 20 秒間使用できませんが、General Purpose サービス レベルでは、インスタンスを最大 2 分間使用できません。
6. 古い SQL インスタンスをクリーンアップする: 古い仮想マシンの割り当てを解除し、不要になった SQL プロセスを削除します。

削除操作

削除操作では、既存の SQL マネージド インスタンスが削除され、関連付けられているリソースがクリーンアップされます。 削除操作がトリガーされるとすぐに、SQL Managed Instance の課金は無効になります。 削除操作の期間は、課金には影響しません。

通常、削除プロセスは次の 4 つのフェーズを経ます。

1. 要求の検証: 送信されたパラメーターは構文的および意味的に検証されます。 要求が無効な場合、操作はエラーで失敗します。
2. ログ末尾のバックアップ: インスタンスが空でない場合は、インスタンスが削除された後にデータが失われないように、すべてのデータベースに対してログ末尾のバックアップが実行されます。 バックアップは、各データベースの保持ポリシーに基づいて保持されます。
3. SQL インスタンスのクリーンアップ: SQL Database Engine プロセスが VM グループから削除され、インスタンスに関連付けられているリソースの割り当てが解除されます。
4. VM グループの削除: サブネットに他のインスタンスがある場合、VM グループはそれらのインスタンスに対してそのまま残ります。 削除されるインスタンスがサブネット内の最後のインスタンスである場合、VM グループは最後の手順として同期的に削除されます。 サブネット内の最後のインスタンスが削除されると、VM グループを削除すると、仮想クラスターの削除が自動的に開始されます。

インスタンス プール

インスタンス プール を使用すると、共有リソースを使用して複数のインスタンスを作成および管理できるため、コストの削減と管理の簡素化に役立ちます。 インフラストラクチャは既に使用可能であるため、既存のプール内に個々のインスタンスをデプロイする方が、スタンドアロン マネージド インスタンスのプロビジョニングよりも大幅に高速です。

インスタンス プールを作成するには 、次の手順を実行します。

• 要求の検証: 送信されたパラメーターは構文的および意味的に検証されます。 要求が無効な場合、操作はエラーで失敗します。
• VM グループを作成する: Azure 仮想ネットワークのサブネット内でインスタンス プールをホストする新しい VM グループが作成されます。 仮想クラスターに割り当てられる仮想コアの数は、プール内のすべてのインスタンスで使用される仮想コアの最大数です。 これは、複数のマネージド インスタンスの基になるインフラストラクチャを設定する 1 回限りの操作です。
• インスタンスの作成: インスタンスはインスタンス プール内に作成されます。これには、割り当てられた VM に SQL Database Engine プロセスをデプロイする必要があります。 インスタンスは仮想クラスターのリソースを共有します。これにより、リソースをより効率的に使用できます。 インスタンスは、必要に応じて顧客によって作成されます。

プール内にインスタンスを作成するには、 次の手順を実行します。

• 要求の検証: 送信されたパラメーターは構文的および意味的に検証されます。 要求が無効な場合、操作はエラーで失敗します。
• インスタンスの作成: インスタンスはインスタンス プール内に作成されます。これには、割り当てられた VM に SQL Database Engine プロセスをデプロイする必要があります。

インスタンスプールへのインスタンスの移動 には、次の手順が含まれます。

• 要求の検証: 送信されたパラメーターは構文的および意味的に検証されます。 要求が無効な場合、操作はエラーで失敗します。
• 仮想コアの割り当て: インスタンスには、プールから必要な仮想コアの数が適切に割り当てられている必要があります。 プールに既に仮想コアがプロビジョニングされているため、これは簡単で、プール内に新しいインスタンスをプロビジョニングする場合と同じように動作します。

インスタンス プールからインスタンスを移動するには、 次の手順を実行します。

• 要求の検証: 送信されたパラメーターは構文的および意味的に検証されます。 要求が無効な場合、操作はエラーで失敗します。
• VM グループを作成またはサイズ変更する: これには、プールの外部のインスタンスに十分な数の必要な仮想コアを提供する必要があります。 仮想コアの準備ができていないため、プロビジョニングする必要があるため、この操作は、既存の VM グループのサイズを変更するか、新しい VM グループを作成する必要がある更新期間と同じです。

ゾーン冗長

ゾーンの冗長性を有効にすると、コンピューティングレイヤーとストレージレイヤーが複数の可用性ゾーンに分散され、高可用性とデータの整合性が確保されます。

ゾーンの冗長性により、管理操作の期間が延長され、複数の可用性ゾーンにわたるリソースの変更に対応できます。

管理操作の期間

管理操作の期間は、SQL Managed Instance のサービス レベルによって異なります。 次のセクションでは、各サービス レベルの管理操作の期間に関する詳細情報を提供します。

トラフィックが新しい SQL Database Engine プロセスにリダイレクトされるときに、最後の フェールオーバー 手順中を除くすべての管理操作の間、インスタンスを使用できます。 Business Critical サービス レベルでは、インスタンスは最大 20 秒間使用できませんが、General Purpose および Next-Gen General Purpose サービス レベルでは、インスタンスを最大 2 分間使用できません。

シード処理の期間

シード処理 は、SQL Database Engine プロセス間でデータを初期化および同期するプロセスです。 シード処理の期間は、主にデータベースのサイズによって異なります。 シード処理は、平均して 1 時間あたり約 220 GB の速度で行われます。

シード処理は、8 つの並列チャネルを介して同時に実行されます。 データ転送には、いつでも 8 つのデータベースが選択されます。 1 つのデータベースの転送が完了するとすぐに、次に使用可能なデータベースが現在の空きチャネルに割り当てられ、継続的かつ効率的なスループットが保証されます。

次の表に、次の情報を示します。

• ほとんどの場合、シード処理の推定時間が予想されます
• 95% のケースで予想される最大シード処理時間

関連コンテンツ

• クイックスタート: Azure SQL Managed Instance の作成
• 機能の比較:Azure SQL Database と Azure SQL Managed Instance
• Azure SQL Managed Instance の接続アーキテクチャ
• 仮想クラスター アーキテクチャ - Azure SQL Managed Instance
• Database Migration Service を使用した SQL Managed Instance の移行