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