メンテナンス期間
適用対象:
Azure SQL Database Azure SQL Managed Instance
メンテナンス期間機能を使用すると、Azure SQL Database と Azure SQL Managed Instance リソースのメンテナンス スケジュールを構成して、影響のあるメンテナンス イベントを予測可能にし、ワークロードの中断を減らすことができます。
Note
メンテナンス期間機能では、アップグレードや予定メンテナンスから見込まれる予定される影響のみを防ぎます。 フェールオーバーのあらゆる原因を防ぐことはありません。メンテナンス期間の外で短い接続中断を引き起こしうる例外には、ハードウェアの故障、クラスターの負荷分散、データベースの Service Level Objective の変更などのイベントに起因するデータベース再構成などがあります。
事前通知 (プレビュー) は、既定以外のメンテナンス期間と、任意の構成 (既定の構成を含む) のマネージド インスタンスを使用するように構成されたデータベースで使用できます。 事前通知を使用すると、顧客は、計画されたイベントの 24 時間前までに通知が送信されるように構成できます。
概要
Azure では、SQL Database と SQL マネージド インスタンス リソースの計画メンテナンスを定期的に実行します。 Azure SQL メンテナンス イベントの間、データベースは完全に利用可能ですが、SQL Database と SQL マネージド インスタンスのそれぞれの可用性 SLA 内で短時間の再構成が行われる可能性があります。
メンテナンス期間は、データベースまたはインスタンスの再構成に対して回復性がなく、計画メンテナンス イベントによる短時間の接続中断を許容できない運用環境のワークロードを対象としています。 希望するメンテナンス期間を選択することで、計画メンテナンスの影響を最小限に抑えることができます。それが営業時間のピーク時以外に行われるためです。 回復性があるワークロードと非運用環境ワークロードは、Azure SQL の既定のメンテナンス ポリシーに依存できます。
メンテナンス期間は無料で、作成時に構成することも、既存の Azure SQL リソースに対して構成することもできます。 これは、Azure portal、PowerShell、CLI、または Azure API を使用して構成できます。
重要
メンテナンス期間の構成は、Azure SQL リソースのサービス レベルの変更と同様に、時間のかかる非同期操作です。 操作の終了時に発生する短い再構成を除いて、操作中にリソースを使用できます。これは、長時間のトランザクションが中断された場合でも、通常は最大 8 秒です。 再構成の影響を最小限に抑えるには、ピーク時以外に操作を実行する必要があります。
メンテナンス期間の予測可能性を高める
既定では、Azure SQL のメンテナンス ポリシーは、一般的な営業時間のピーク時の中断を回避するために、毎日現地時刻で午前 8 時から午後 5 時までの間、最も影響のある更新をブロックします。 現地時刻は、リソースをホストする Azure リージョンの場所によって決定され、ローカル タイム ゾーンの定義に従って夏時間が適用される場合があります。
次の 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 つ以上の隣接する期間にまたがる場合があります。
Note
Azure SQL Database と Azure SQL Managed Instance は、Azure ペア リージョンが同時にデプロイされないことを保証する安全なデプロイ プラクティスに従います。 ただし、最初にアップグレードされるリージョンを予測することはできないため、デプロイの順序は保証されません。 プライマリ インスタンスが最初にアップグレードされる場合もあれば、セカンダリが最初になる場合もあります。
- データベースで geo レプリケーションまたは自動フェールオーバー グループが有効になっており、geo レプリケーションが Azure リージョンのペアリングと一致しない場合、プライマリ データベースとセカンダリ データベースに対して異なるメンテナンス期間のスケジュールを設定する必要があります。 たとえば、geo セカンダリ データベースのメンテナンス期間には [平日] を選択し、geo プライマリ データベースのメンテナンス期間には [週末] を選択できます。
- Azure SQL マネージド インスタンスに自動フェールオーバー グループがあり、グループが Azure リージョンのペアリングと一致しない場合、プライマリ データベースとセカンダリ データベースに対して異なるメンテナンス期間のスケジュールを設定する必要があります。 たとえば、geo セカンダリ データベースのメンテナンス期間には [平日] を選択し、geo プライマリ データベースのメンテナンス期間には [週末] を選択できます。
重要
重要なセキュリティ パッチの適用など、アクションの延期によって重大な影響が生じる可能性がある非常にまれな状況では、構成されたメンテナンス期間が一時的にオーバーライドされることがあります。
事前通知
メンテナンス通知は、今後予定されている Azure SQL Database と Azure SQL Managed Instance のメンテナンス イベントを通知するように構成できます。 アラートは、24 時間前、メンテナンス期間が始まる前、そしてメンテナンス期間の終了時に届きます。 詳しくは、「事前通知」をご覧ください。
使用可能な機能
サポートされているサブスクリプションの種類
メンテナンス期間の構成と使用は、従量課金制、クラウド ソリューション プロバイダー (CSP)、マイクロソフトエンタープライズ契約、または Microsoft 顧客契約のプランの種類で使用できます。
開発やテストの使用に限定されたプランは対象外です (開発テスト用の従量課金制プランや Enterprise Dev/Test など)。
Note
Azure オファーとは、ご利用の Azure サブスクリプションの種類です。 たとえば、従量課金制料金、Azure イン オープン プラン、および Visual Studio Enterprise のサブスクリプションはすべて Azure プランです。 オファーまたはプランごとに、使用条件と利点は異なります。 オファーまたはプランは、サブスクリプションの概要に表示されます。 サブスクリプションを別のオファーに変更する方法について詳しくは、「Azure サブスクリプションを別のオファーに変更する」を参照してください。
サポートされるサービス レベル目標
既定以外のメンテナンス期間は、すべての SLO で選択できますが、次の場合を除きます。
- インスタンス プール
- Basic、S0、および S1
- DC、Fsv2、M シリーズ
- ゾーン冗長を備えた Hyperscale サービス レベル
Azure リージョンへの対応
既定以外のメンテナンス期間は、現在、次のリージョンで選択できます。
| Azure リージョン | SQL Managed Instance | SQL Database | Azure 可用性ゾーン内の SQL Database |
|---|---|---|---|
| オーストラリア中部 1 | はい | ||
| オーストラリア中部 2 | はい | ||
| オーストラリア東部 | はい | はい | はい |
| オーストラリア南東部 | はい | はい | |
| ブラジル南部 | はい | はい | |
| ブラジル南東部 | はい | はい | |
| カナダ中部 | はい | はい | はい |
| カナダ東部 | はい | Yes | |
| インド中部 | Yes | はい | |
| 米国中部 | はい | はい | はい |
| 中国東部 2 | はい | はい | |
| 中国北部 2 | はい | はい | |
| East US | はい | はい | はい |
| 米国東部 2 | はい | はい | はい |
| 東アジア | はい | はい | |
| フランス中部 | はい | はい | |
| フランス南部 | はい | はい | |
| ドイツ中西部 | はい | はい | |
| ドイツ北部 | はい | ||
| 東日本 | はい | はい | はい |
| 西日本 | はい | はい | |
| 韓国中部 | はい | ||
| 韓国南部 | はい | ||
| 米国中北部 | はい | はい | |
| 北ヨーロッパ | はい | はい | はい |
| ノルウェー東部 | はい | ||
| ノルウェー西部 | はい | ||
| 南アフリカ北部 | はい | ||
| 南アフリカ西部 | はい | ||
| 米国中南部 | はい | はい | はい |
| インド南部 | はい | はい | |
| 東南アジア | はい | はい | はい |
| スイス北部 | はい | はい | |
| スイス西部 | はい | ||
| アラブ首長国連邦中部 | はい | ||
| アラブ首長国連邦北部 | はい | はい | |
| 英国南部 | はい | はい | はい |
| 英国西部 | はい | はい | |
| US Gov アリゾナ | はい | ||
| US Gov テキサス | はい | はい | |
| US Gov バージニア州 | Yes | はい | |
| 米国中西部 | はい | はい | |
| 西ヨーロッパ | はい | はい | はい |
| インド西部 | はい | ||
| 米国西部 | はい | はい | |
| 米国西部 2 | はい | はい | はい |
| 米国西部 3 | はい |
ゲートウェイのメンテナンス
メンテナンス期間の最大のメリットを得るには、クライアント アプリケーションでリダイレクト接続ポリシーを使用していることが必要です。 リダイレクトは推奨の接続ポリシーであり、このときクライアントはデータベースをホストしているノードへの直接接続を確立します。これにより、待機時間が短縮され、スループットが向上します。
Azure SQL Database では、プロキシ接続ポリシーを使用した接続は、選択したメンテナンス期間とゲートウェイ ノードのメンテナンス期間の両方の影響を受ける可能性があります。 ただし、推奨のリダイレクト接続ポリシーを使用したクライアント接続であれば、ゲートウェイ ノードのメンテナンス再構成の影響を受けません。
Azure SQL Managed Instance では、ゲートウェイ ノードは仮想クラスター内でホストされ、マネージド インスタンスと同じメンテナンス期間を使用しますが、メンテナンス イベント中の中断の回数を最小限に抑えるために、リダイレクト接続ポリシーを使用することをお勧めします。
Azure SQL Database でのクライアント接続ポリシーについて詳しくは、Azure SQL Database の接続ポリシーに関するページをご覧ください。
Azure SQL Managed Instance でのクライアント接続ポリシーについて詳しくは、「Azure SQL Managed Instance の接続の種類」をご覧ください。
Azure SQL Managed Instance に関する考慮事項
Azure SQL Managed Instance は、お客様の仮想ネットワーク サブネット内で実行される、隔離された一連の専用仮想マシンでホストされたサービス コンポーネントで構成されます。 これらの仮想マシンは、複数のマネージド インスタンスをホストできる仮想クラスターを形成します。 1 つのサブネットのインスタンスに対して構成されたメンテナンス期間は、サブネット内の仮想クラスターの数、仮想クラスター間でのインスタンスの分散、および仮想クラスター管理操作に影響を与える可能性があります。 これには、いくつかの影響を考慮する必要がある場合があります。
メンテナンス期間の構成は長期の操作です
仮想クラスターでホストされているすべてのインスタンスは、メンテナンス期間を共有します。 既定では、すべてのマネージド インスタンスは、既定のメンテナンス期間を使用して仮想クラスターでホストされます。 その作成時または作成後にマネージド インスタンスに対して別のメンテナンス期間を指定すると、それは、対応するメンテナンス期間を持つ仮想クラスターに配置する必要があります。 そのような仮想クラスターがサブネット内に存在しない場合は、そのインスタンスを格納するために、最初に新しいものを作成する必要があります。 既存の仮想クラスターに追加のインスタンスを格納するには、クラスターのサイズ変更が必要になる場合があります。 どちらの操作も、マネージド インスタンスのメンテナンス期間の構成にかかる時間に影響します。 マネージド インスタンスでのメンテナンス期間の構成に予想される時間は、インスタンス管理操作の予想時間を使用して計算できます。
重要
メンテナンス期間の構成操作の終了時に短い再構成が発生します。これは、長期のトランザクションが中断された場合でも、通常は最大で 8 秒です。 再構成の影響を最小限に抑えるには、ピーク時以外に操作を開始します。
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 Database'
| 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
サブスクリプション内のすべてのマネージド インスタンスを確認するには、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 サンプル クエリ」を参照してください。