Azure SQL Managed Instance のメンテナンス期間
適用対象: 
Azure SQL Managed Instance
メンテナンス期間機能を使用すると、Azure SQL Managed Instance リソースのメンテナンス スケジュールを構成して、影響のあるメンテナンス イベントを予測可能にし、ワークロードの中断を減らすことができます。
Note
メンテナンス期間機能では、アップグレードや予定メンテナンスから見込まれる予定される影響のみを防ぎます。 フェールオーバーのあらゆる原因を防ぐことはありません。メンテナンスウィンドウ外で短時間の接続中断を引き起こす可能性のある例外には、ハードウェアの故障やその他の再設定などがあります。
事前通知を使用すると、顧客は、計画されたイベントの 24 時間前までに通知が送信されるように構成できます。
概要
Azure では、SQLマネージド インスタンス リソースの計画メンテナンスを定期的に実行します。 メインテナント イベント中、SQL マネージド インスタンスは完全に使用可能ですが、SQL マネージド インスタンスの可用性サービス レベル アグリーメント (SLA) 内で短い再構成が行われる可能性があります。
メンテナンス期間は、インスタンスの再構成に対して回復性がなく、計画メンテナンス イベントによる短時間の接続中断を許容できない運用環境のワークロードを対象としています。 希望するメンテナンス期間を選択することで、計画メンテナンスの影響を最小限に抑えることができます。それが営業時間のピーク時以外に行われるためです。 回復性があるワークロードと非運用環境ワークロードは、Azure SQL の既定のメンテナンス ポリシーに依存できます。
メンテナンス期間は無料で、作成時に構成することも、既存の リソースに対して構成することもできます。 これは、Azure portal、PowerShell、CLI、または Azure API を使用して構成できます。
重要
メンテナンス期間の構成は、Azure SQL リソースのサービス レベルの変更と同様に、時間のかかる非同期操作です。 操作の終了時に発生する短い再構成を除いて、操作中にリソースを使用できます。これは、長時間のトランザクションが中断された場合でも、通常は最大 8 秒です。 再構成の影響を最小限に抑えるには、ピーク時以外に操作を実行する必要があります。
メンテナンス期間の予測可能性を高める
既定では、Azure SQL のメンテナンス ポリシーは、一般的な営業時間のピーク時の中断を回避するために、毎日現地時刻で午前 8 時から午後 5 時までの間、最も影響のある更新をブロックします。 現地時刻は、リソースをホストする Azure リージョンの場所によって決定され、ローカル タイム ゾーンの定義に従って夏時間が適用される場合があります。
メインテナント中は、データベースは引き続き使用できますが、一部の更新ではフェールオーバーが必要になる場合があります。 システムの既定のメインテナンス期間 (午後 5 時から午前 8 時) は、ほとんどのアクティビティをこの時間に制限しますが、緊急の更新がそれ以外で発生する可能性があります。 メインテナント ウィンドウ内でのみすべての更新が行われるようにするには、既定以外のオプションを選択します。
次の 2 つの追加メンテナンスウインドウスロットから選択することにより、メンテナンスの更新をウインドウを Azure SQL リソースに適した時間に調整できます。
- 平日 のウィンドウ: 現地時間の午後 10:00 から午前 6:00、月曜日から木曜日
- 週末 のウィンドウ: 現地時間の午後 10:00 から午前 6:00、金曜日から日曜日
一覧リストされているメンテナンスウィンドウの日数は、各 8 時間のメンテナンス時間の開始日を示します。 たとえば、"10:00 PM to 6:00 AM local time, Monday – Thursday" は、メンテナンス期間が毎日 (月曜日から木曜日) の現地時刻の午後 10:00 に開始され、次の日 (火曜日から金曜日) の現地時刻の午前 6 時に完了します。
メンテナンス期間を選択し、サービスの構成が完了すると、計画メンテナンスは、選択した期間中のみ行われます。 通常、メンテナンス イベントは 1 つの期間内で完了しますが、一部のイベントは 2 つ以上の隣接する期間にまたがる場合があります。
重要
Azure ペア リージョンが同時にデプロイされないことを保証する安全なデプロイ プラクティスに従います。 ただし、最初にアップグレードされるリージョンを予測することはできないため、デプロイの順序は保証されません。 プライマリ インスタンスが最初にアップグレードされる場合もあれば、セカンダリが最初になる場合もあります。
SQL Managed Instance がフェールオーバー グループを持っていて、グループ内のインスタンスが Azure リージョンのペア設定と一致しない場合は、プライマリ データベースとセカンダリ SQL Managed Instance に対して別々のメンテナンス期間スケジュールを選択します。 たとえば、geo セカンダリ のメンテナンス期間には [平日] を選択し、geo プライマリ データベースのメンテナンス期間には [週末] を選択できます。
重要なセキュリティ パッチの適用など、アクションの延期によって重大な影響が生じる可能性がある非常にまれな状況では、構成されたメンテナンス期間が一時的にオーバーライドされることがあります。
事前通知
メンテナンス通知は、今後予定されている Azure SQL Managed Instance のメンテナンス イベントを通知するように構成できます。 アラートは、24 時間前、メンテナンス期間が始まる前、そしてメンテナンス期間の終了時に届きます。 詳しくは、「事前通知」をご覧ください。
使用可能な機能
サポートされているサブスクリプションの種類
メンテナンス期間の構成と使用は、従量課金制、クラウド ソリューション プロバイダー (CSP)、マイクロソフトエンタープライズ契約、または Microsoft 顧客契約のプランの種類で使用できます。
開発やテストの使用に限定されたプランは対象外です (開発テスト用の従量課金制プランや Enterprise Dev/Test など)。
Note
Azure オファーとは、ご利用の Azure サブスクリプションの種類です。 たとえば、従量課金制料金、Azure イン オープン プラン、および Visual Studio Enterprise のサブスクリプションはすべて Azure プランです。 オファーまたはプランごとに、使用条件と利点は異なります。 オファーまたはプランは、サブスクリプションの概要に表示されます。 サブスクリプションを別のオファーに変更する方法について詳しくは、「Azure サブスクリプションを別のオファーに変更する」を参照してください。
サポートされるサービス レベル目標
既定以外のメンテナンス期間は、Azure SQL Managed Instanceプールを除くすべての SLO で選択できます。
メンテナンス期間に対する Azure SQL Managed Instance リージョンのサポート
Azure SQL Managed Instance のデフォルト以外のメンテナンス期間は、すべてのリージョンで選択できます。
ゲートウェイのメンテナンス
Azure SQL Managed Instance では、ゲートウェイ ノードは仮想クラスター内でホストされ、SQL マネージド インスタンスと同じメインテナント ウィンドウを持ちます。
重要
リダイレクト接続ポリシーは、メインテナント イベント中の中断の数を最小限に抑えるために推奨されます。接続の種類を参照してください。
Azure SQL Managed Instance に関する考慮事項
Azure SQL Managed Instance は、お客様の仮想ネットワークのサブネット内で実行される、隔離された一連の専用仮想マシンでホストされたサービス コンポーネントで構成されます。 これらの仮想マシンは、複数のマネージド インスタンスをホストできる仮想クラスターを形成するため、グループで管理されます。 同じサブネット内のインスタンスに対して構成されたメンテナンス期間は、仮想クラスター内の仮想マシン グループの数と仮想クラスター管理操作に影響を与える可能性があるため、メンテナンス期間を構成する前に考慮すべき点がいくつかあります。
メンテナンス期間の構成は長期の操作です
同じ仮想マシン グループでホストされているすべてのインスタンスは、同じメンテナンス期間を共有します。 既定では、すべてのマネージド インスタンスは、既定のメンテナンス期間を使用してグループでホストされます。 インスタンスの作成中、またはインスタンスの作成後に別のメンテナンス期間を指定した場合、インスタンスは対応するメンテナンス期間を持つ別のマシン グループに配置されます。 クラスターにそのようなグループが存在しない場合は、インスタンスの新しい構成に対応するために新しいグループが作成されます。 同じメンテナンス期間を使用するように仮想クラスター内の追加インスタンスを構成した場合、それらのインスタンスもグループに追加されます。つまり、グループのサイズ変更をする必要がある場合があります。 新しいマシン グループにインスタンスを追加し、既存のマシン グループのサイズを変更すると、メンテナンス期間を構成する操作の期間が長くなる場合があります。
マネージド インスタンスでのメンテナンス期間の構成に予想される時間は、インスタンス管理操作の見積もり期間を使用して計算できます。
重要
メインテナント ウィンドウを構成する場合、操作の最後の手順では、長期のトランザクションが中断された場合でも、通常は最大 8 秒続くインスタンスの再構成が必要です。 影響を最小限に抑えるには、ピーク時以外のメンテナンス期間を構成します。
IP アドレス空間の要件
サブネット内の新しい各仮想マシン グループには、仮想クラスターの IP アドレスの割り当てに従って、追加の IP アドレスが必要です。 既存のマネージド インスタンスのメンテナンス期間を変更するには、対応するサービス レベルの仮想コアの数をスケーリングする場合と同様に、一時的な追加 IP 容量も必要です。
IP アドレスの変更
メンテナンス期間の構成または変更を行うと、サブネットの IP アドレス範囲内で、インスタンスの IP アドレスが別のIP アドレス に変更されます。
重要
IP アドレスを変更した後、ネットワーク セキュリティ グループ (NSG) とファイアウォール規則によってデータ トラフィックがブロックされないようにしてください。
仮想クラスター管理操作のシリアル化
サービスのアップグレードや仮想クラスターのサイズ変更 (新しいコンピューティング ノードの追加や未使用のコンピューティング ノードの削除) のような、仮想クラスターに影響を与える操作はシリアル化されます。 そのため、新しい仮想クラスター操作は、前の操作が完了するまで開始できません。 進行中のメンテナンス操作が完了する前にメンテナンス期間が閉じると、進行中のメンテナンス操作は次のメンテナンス期間まで保留されます。 その間に送信されたその他の管理操作も保留になり、元の進行中のメンテナンス操作が完了した後、次のメンテナンス期間の間または後に再開されます。 一般的に、クラスター内の仮想マシン グループあたりのメンテナンス操作が 1 つのメンテナンス期間より長くかかることはありませんが、メンテナンス操作が非常に複雑な場合には発生する可能性があります。
仮想クラスター管理操作のシリアル化は、既定のメンテナンス ポリシーにも適用される一般的な動作です。 メンテナンス期間のスケジュールを構成する場合、隣接する 2 つの期間の間が数日になることもあります。 まれに、メンテナンス操作が 2 つの期間にまたがる場合、新しく送信された操作が数日間保留になり、新しいインスタンスの作成や既存のインスタンスのサイズ変更など、追加の計算ノードを必要とする操作がブロックされる可能性があります。
メンテナンス イベントの一覧の取得
Azure Resource Graph は、Azure Resource Management を拡張するように設計された Azure サービスです。 Azure Resource Graph Explorer は、効率的でパフォーマンスの高いリソース探索を提供し、環境を効果的に管理できるように、特定のサブスクリプションのセットにわたって大規模なクエリを実行する機能を備えています。
Azure Resource Graph Explorer を使用して、メンテナンス イベントのクエリを実行できます。 これらのクエリを実行する方法の概要については、「クイック スタート: Azure Resource Graph Explorer を使用して最初の Resource Graph クエリを実行する」を参照してください。
サブスクリプション内のすべてのSQLマネージド インスタンスを確認するには、Azure Resource Graph Explorer で次のサンプル クエリを使用します。
servicehealthresources
| where type =~ 'Microsoft.ResourceHealth/events'
| extend impact = properties.Impact
| extend impactedService = parse_json(impact[0]).ImpactedService
| where impactedService =~ 'SQL Managed Instance'
| extend eventType = properties.EventType, status = properties.Status, description = properties.Title, trackingId = properties.TrackingId, summary = properties.Summary, priority = properties.Priority, impactStartTime = todatetime(tolong(properties.ImpactStartTime)), impactMitigationTime = todatetime(tolong(properties.ImpactMitigationTime))
| where eventType == 'PlannedMaintenance'
| order by impactStartTime desc
サンプル クエリの完全なリファレンスと、PowerShell や Azure CLI など、ツール間でそれらを使用する方法については、「Azure Service Health 用の Azure Resource Graph サンプル クエリ」を参照してください。