Azure SQL Managed Instance の管理操作の概要
適用対象:
Azure SQL Managed Instance
Azure SQL Managed Instance には、新しいマネージド インスタンスを自動的にデプロイしたり、インスタンスのプロパティを更新したり、不要になったインスタンスを削除したりする際に使用できる管理操作が用意されています。
管理操作とは
すべての管理操作は次のように分類できます。
- インスタンスのデプロイ (新しいインスタンスの作成)
- インスタンスの更新 (仮想コアや予約済み記憶域などの、インスタンスのプロパティの変更)
- インスタンスの削除
Azure 仮想ネットワーク内のデプロイをサポートし、顧客に分離とセキュリティを提供するため、SQL Managed Instance では仮想クラスターに依存しています。 仮想クラスターは、お客様の仮想ネットワーク サブネット内にデプロイされ、仮想マシン グループ内で構成されている分離された仮想マシンの専用セットを表します。 基本的に、空のサブネットにデプロイされたそれぞれのマネージド インスタンスは、最初の仮想マシン グループをビルドする新しい仮想クラスター構成となります。
マネージド インスタンスに対する後続の管理操作は、基になる 仮想マシン グループに影響を与える可能性があります。 基になる仮想マシン グループに影響を与える変更は、管理操作の期間に影響を与える可能性があります。仮想クラスターへの仮想マシンのデプロイには、新しいデプロイや既存のマネージド インスタンスへの更新を計画するときに考慮する必要があるオーバーヘッドが伴います。
Fast provisioning (迅速なプロビジョニング)
2022 年 11 月の機能ウェーブが有効になっているサブネットは、SQL Managed Instance のプロビジョニングを利用できます。これにより、サブネット内に最初のインスタンスを作成するのにかかる時間を (平均 45～60 分から) 30 分にまで短縮できます。 操作の所要時間に関する詳細は、「管理操作」を確認してください。
高速プロビジョニングは、以下に対してのみ適用されます。
- サブネットでプロビジョニングされた最初のインスタンス。
- 4～8 個の仮想コアを持つインスタンス。
- 既定のメンテナンス期間を使用するインスタンス。
- ゾーン冗長ではないインスタンスに対して。
Duration
仮想クラスターに対する操作は、所要時間がさまざまですが、通常かなり時間がかかります。
次の表に、作成、更新、または削除操作の一部としてトリガーできる実行時間の長いステップを示します。 表には、既存サービスの利用統計情報に基づいて、通常予想できる所要時間も示されています。
| 手順 | 説明 | 推定所要時間 |
|---|---|---|
| 仮想クラスターの作成 (高速プロビジョニング)1 | 高速プロビジョニングは、インスタンス管理操作の同期手順であり、その間、最初の仮想マシン グループをすぐに使用できるようになります。 | 操作の 90% は 30 分で完了 |
| 仮想クラスターの作成 | 作成は、インスタンス管理操作の同期ステップであり、その間に最初の仮想マシン グループが作成されます。 | 操作の 90% は 4 時間未満で完了 |
| 仮想クラスターのサイズ変更 (拡張または縮小) | 既存の仮想マシン グループへの新しいマシンの追加、未使用の仮想マシンの削除、仮想マシン グループ全体の追加または削除。 拡張は同期ステップですが、圧縮は非同期的に実行されます (インスタンス管理操作の期間には影響しません)。 | 新しい仮想マシン グループの作成によるクラスター拡張の 90% は 4 時間未満で完了 既存の仮想マシン グループの拡張によるクラスター拡張の 90% が 60 分で完了 |
| 仮想クラスターの削除 | 仮想クラスターの削除は、最後のインスタンスがサブネットから削除されたときにトリガーされます。 | クラスターの削除の 90% は 1.5 時間で完了 |
| データベース ファイルのシード処理2 | Business Critical サービス レベルにおけるコンピューティング (仮想コア) やストレージのスケーリング中、および General Purpose から Business Critical (またはその逆) へのサービス レベルの変更時にトリガーされる同期的ステップ。 この操作の期間は、データベースの合計サイズと現在のデータベース アクティビティ (アクティブなトランザクションの数) に比例します。 インスタンスを更新しているときのデータベース アクティビティによって、総所要時間は大きく変動する場合があります。 | これらの操作の 90% は毎時 220 GB 以上で実行される |
1 高速プロビジョニングは現在、サブネット内の最初のインスタンス (4 個または 8 個の仮想コアあり) で、既定のメンテナンス期間構成でのみサポートされています。
2 Business Critical サービス レベルでコンピューティング (仮想コア) またはストレージをスケーリングする場合、またはサービス レベルを General Purpose から Business Critical に切り替える場合、シード処理には Always On 可用性グループのシード処理も含まれます。
重要
General Purpose サービス レベルでのストレージのスケールアップまたはスケールダウンは、メタデータの更新と送信された要求の応答の伝達で構成されます。 ダウンタイムとフェールオーバーなしで、最大 5 分で完了する高速な操作です。
管理操作での実行時間の長いセグメント
次の表は、操作と標準的な総所要時間を、操作のカテゴリごとにまとめたものです。
カテゴリ: デプロイ
| 操作 | 実行時間の長いセグメント | 推定所要時間 |
|---|---|---|
| 空のサブネットへの最初のインスタンス1 | 仮想クラスターの作成 (高速プロビジョニング) | 操作の 90% は 30 分で完了。 |
| 空のサブネットへの最初のインスタンス | 仮想クラスターの作成 | 操作の 90% は 4 時間未満で完了します。 |
| 空ではないサブネット内の別のハードウェア生成またはメンテナンス期間の最初のインスタンス (たとえば、Standard シリーズ インスタンスを含むサブネット内の Premium シリーズ インスタンス) | 仮想クラスターへの新しい仮想マシン グループの追加 2 | 操作の 90% は 4 時間未満で完了します。 |
| 空ではないサブネットに後続のインスタンス (第 2、第 3 のインスタンスなど) を作成 | 仮想クラスターのサイズ変更 | 操作の 90% は 60 分で完了。 |
1 高速プロビジョニングは現在、サブネット内の最初のインスタンス (4 個または 8 個の仮想コアあり) で、既定のメンテナンス期間構成でのみサポートされています。 2 ハードウェアの生成とメンテナンス期間の構成ごとに、個別の仮想マシン グループが作成されます。
カテゴリ: 更新
| 操作 | 実行時間の長いセグメント | 推定所要時間 |
|---|---|---|
| インスタンス プロパティの変更 (管理者パスワード、Microsoft Entra ログイン、Azure ハイブリッド特典フラグ) |
該当なし | 最大 1 分。 |
| インスタンス ストレージのスケールアップ/スケールダウン (General Purpose) |
実行時間の長いセグメントはありません | 操作の 99% は 5 分以内に完了。 |
| インスタンス ストレージのスケールアップ/スケールダウン (Business Critical) |
- 仮想クラスターのサイズ変更 - Always On 可用性グループのシード処理 |
操作の 90% は 60 分で完了。それに加えて、すべてのデータベースにシード処理する時間 (毎時 220 GB) |
| インスタンス ストレージのスケールアップ/スケールダウン (Next-gen General Purpose) |
- 仮想クラスターの作成/仮想マシン グループのサイズ変更 - Always On 可用性グループのシード処理 |
操作の 90% は、4 時間未満 (仮想マシン グループの作成) または 60 分 (仮想マシン グループのサイズ変更) と、すべてのデータベースのシード処理 (220 GB/時間)、フェールオーバー、古いインスタンスのクリーンアップにかかる時間で終了します |
| インスタンスのコンピューティング (仮想コア) のスケールアップとスケールダウン (General Purpose) |
- 仮想クラスターのサイズ変更 | 操作の 90% は 60 分で完了。 |
| インスタンスのコンピューティング (仮想コア) のスケールアップとスケールダウン (Business Critical) |
- 仮想クラスターのサイズ変更 - Always On 可用性グループのシード処理 |
操作の 90% は 60 分で完了。それに加えて、すべてのデータベースにシード処理する時間 (毎時 220 GB) |
| インスタンスのコンピューティング (仮想コア) のスケールアップとスケールダウン (Next-gen General Purpose) |
仮想クラスターの作成/仮想マシン グループのサイズ変更 - Always On 可用性グループのシード処理 |
操作の 90% は、4 時間未満 (仮想マシン グループの作成) または 60 分 (仮想マシン グループのサイズ変更) と、すべてのデータベースのシード処理 (220 GB/時間)、フェールオーバー、古いインスタンスのクリーンアップにかかる時間で終了します |
| インスタンス サービス レベルの変更 (General Purpose から Business Critical とその逆) |
- 仮想クラスターのサイズ変更 - Always On 可用性グループのシード処理 |
操作の 90% は 60 分で完了。それに加えて、すべてのデータベースにシード処理する時間 (毎時 220 GB) |
| インスタンス サービス レベルの変更 (General Purpose または Business Critical から Next-gen General Purpose とその逆) |
仮想クラスターの作成/仮想マシン グループのサイズ変更 - Always On 可用性グループのシード処理 |
操作の 90% は、4 時間未満 (仮想マシン グループの作成) または 60 分 (仮想マシン グループのサイズ変更) と、すべてのデータベースのシード処理 (220 GB/時間)、フェールオーバー、古いインスタンスのクリーンアップにかかる時間で終了します |
| インスタンス ハードウェアまたはメンテナンス期間の変更 (General Purpose) |
- 仮想クラスターのサイズ変更1 | 90% の操作が 4 時間以内 (仮想マシン グループの作成) または 60 分 (仮想マシン グループのサイズ変更) で完了します。 |
| インスタンス ハードウェアまたはメンテナンス期間の変更 (Business Critical) |
- 仮想クラスターのサイズ変更1 - Always On 可用性グループのシード処理 |
操作の 90% は、4 時間未満 (仮想マシン グループの作成) または 60 分 (仮想マシン グループのサイズ変更) および、すべてのデータベースのシード処理 (220 GB/時間) にかかる時間で完了します。 |
| インスタンス ハードウェアまたはメンテナンス期間の変更 (Next-gen General Purpose) |
- 仮想クラスターの作成/仮想マシン グループのサイズ変更 - Always On 可用性グループのシード処理 |
操作の 90% は、4 時間未満 (仮想マシン グループの作成) または 60 分 (仮想マシン グループのサイズ変更) と、すべてのデータベースのシード処理 (220 GB/時間)、フェールオーバー、古いインスタンスのクリーンアップにかかる時間で終了します |
1 マネージド インスタンスは、同一の対応するハードウェアとメンテナンス期間を持つ仮想マシン グループに配置する必要があります。 そのようなグループが仮想クラスターに存在しない場合は、そのインスタンス構成を格納するために、最初に新しいものを作成する必要があります。
カテゴリ: 削除
| 操作 | 実行時間の長いセグメント | 推定所要時間 |
|---|---|---|
| 最後以外のインスタンスの削除 | すべてのデータベースに対するログ テールのバックアップ | 操作の 90% は最長 1 分で完了。1 |
| 最後のインスタンスの削除 | - すべてのデータベースのログテールバックアップ - 仮想クラスターの削除 |
操作の 90% は最長 1.5 時間で完了。2 |
1 クラスターに複数の仮想マシン グループがある場合、グループ内の最後のインスタンスを削除すると、すぐに仮想マシン グループ の非同期的な削除がトリガーされます。
2 サブネット内の最後のインスタンスが削除されると、仮想クラスターの削除が直ちに、同期的にトリガーされます。
重要
削除操作がトリガーされるとすぐに、SQL Managed Instance に対する課金が無効になります。 削除操作の期間は、課金には影響しません。
インスタンスの可用性
SQL Managed Instance は、更新操作中の利用が可能です。ただし、更新の最後に実行されるフェールオーバーによって短いダウンタイムが発生します。 高速データベース復旧のおかげで、実行時間の長いトランザクションが中断された場合でも、通常は最大で 10 秒です。
Note
General Purpose マネージド インスタンス ストレージをスケーリングしても、更新の終了時にフェールオーバーは発生しません。
SQL Managed Instance は、デプロイおよび削除操作中にクライアント アプリケーションで使用できません。
重要
実行時間の長いトランザクション (データのインポート、データ処理ジョブ、インデックスの再構築など) と同時に、Azure SQL Managed Instance のコンピューティングやストレージをスケーリングしたり、サービス レベルを変更したりすることは推奨されません。 操作の最後に実行されるデータベースのフェールオーバーで、実行中のトランザクションはすべてキャンセルされます。
管理操作のステップ
管理操作は、複数のステップから成ります。 監視 APIでは、操作のサブセット (デプロイと更新) に対してこれらの手順が公開されます。 デプロイ操作は 3 つのステップから成ります。一方、更新操作は 6 つのステップで実行されます。 操作の所要時間の詳細については、管理操作の所要時間に関するセクションを参照してください。 ステップは、実行順に一覧表示されます。
マネージド インスタンスのデプロイ ステップ
| [ステップ名] | ステップの説明 |
|---|---|
| 要求の検証 | 送信したパラメーターが検証されます。 構成に誤りがある場合、操作はエラーで失敗します。 |
| 仮想クラスターのサイズ変更と作成 | 仮想クラスターの状態に応じて、クラスターは作成中またはリサイズ中の状態になります。 |
| 新しい SQL インスタンスの起動 | デプロイされた仮想マシンで SQL プロセスが起動されます。 |
マネージド インスタンスの更新ステップ
| [ステップ名] | ステップの説明 |
|---|---|
| 要求の検証 | 送信したパラメーターが検証されます。 構成に誤りがある場合、操作はエラーで失敗します。 |
| 仮想クラスターのサイズ変更と作成 | 仮想クラスターの状態に応じて、クラスターは作成中またはリサイズ中の状態になります。 |
| 新しい SQL インスタンスの起動 | デプロイされた仮想マシンで SQL プロセスが起動されます。 |
| データベース ファイルのシード処理とデータベース ファイルのアタッチ | 更新処理の種類に応じて、データベースのシード処理またはデータベース ファイルのアタッチが実行されます。 |
| フェールオーバーの準備とフェールオーバー | データがシード処理されるか、データベース ファイルが再アタッチされた後、システムはフェールオーバー用に準備されています。 すべての準備が整うと、短いダウンタイムでフェールオーバーが実行されます。 |
| 古い SQL インスタンスのクリーンアップ | 古い SQL プロセスを仮想マシンから削除する |
マネージド インスタンスの削除ステップ
| [ステップ名] | ステップの説明 |
|---|---|
| 要求の検証 | 送信したパラメーターが検証されます。 構成に誤りがある場合、操作はエラーで失敗します。 |
| SQL インスタンスのクリーンアップ | 仮想マシンから SQL プロセスを削除する |
| 仮想クラスターの削除 | 削除されるインスタンスがサブネット内で最後かどうかによって、仮想クラスターは最後のステップとして同期的に削除されます。 |
Note
インスタンスのスケーリングの結果、基になる仮想クラスターは、未使用の容量と可能な容量の最適化を解放するプロセスを経て、作成/スケーリング操作に関与していないインスタンスに影響を与える可能性があります。
管理操作の相互影響
マネージド インスタンスでの管理操作は、同じサブネット内に配置された他のインスタンスの管理操作に影響を及ぼす場合があります。
仮想クラスター内の実行時間の長い復元操作により、同じ仮想マシン グループ内の、作成やスケーリングなどの他の操作が保留されます。
例: 実行時間の長い復元操作と、仮想マシン グループの縮小が必要なスケール要求がある場合、復元操作が完了するまでに圧縮要求の完了に時間がかかります。
後続のインスタンスの作成またはスケーリングの操作は、以前に開始されたインスタンスの作成、または仮想マシン グループのサイズ変更を開始したインスタンスのスケールによって保留されます。
例: 同じ仮想マシン グループの下に同じサブネット内に複数の作成要求またはスケール要求があり、そのうちの 1 つが仮想マシン グループのサイズ変更を開始した場合、最初の操作要求の 5 分以上後に送信されたすべての要求は、再開する前にサイズ変更が完了するまで待機する必要があるためです。
5 分間のウィンドウで送信された作成/スケール操作 バッチ処理され、並列で実行されます。
例: 5 分のウィンドウで送信されたすべての操作に対して 1 つの仮想クラスターのサイズ変更のみが実行されます (最初の操作要求を実行した時点から測定)。 最初の要求が送信されてから 5 分以上後に別の要求が送信された場合、仮想クラスターのサイズ変更が完了するまで待機してから実行が開始されます。
重要
進行中の別の操作のために保留になっている管理操作は、続行する条件が満たされると自動的に再開されます。 一時停止された管理操作を再開するために必要なユーザー操作はありません。
管理操作の監視
管理操作の進行状況と状態を監視する方法については、「azure SQL Managed Instance 管理操作の監視
管理操作の取り消し
管理操作を取り消す方法については、「Azure SQL Managed Instance 管理操作の取り消しを参照してください。
関連コンテンツ
- クイックスタート: Azure SQL Managed Instance を作成する
- 機能の比較: Azure SQL Database と Azure SQL Managed Instance
- Azure SQL Managed Instance の
接続アーキテクチャ - 仮想クラスター アーキテクチャ - Azure SQL Managed Instance
- SQL Managed Instance の移行 は、Database Migration Service を使用して行います。