ディザスター リカバリー ガイダンス - Azure SQL Managed Instance

適用対象: Azure SQL Managed Instance

• Azure SQL Database
• Azure SQL Managed Instance

Azure SQL Managed Instance は、ミッション クリティカルで 常に利用できるようになっている必要がある さまざまなアプリケーションをサポートするために、業界トップの 99.99% 以上の高可用性を保証しています。 また、Azure SQL Managed Instance には、リージョンで障害が発生した場合にディザスター リカバリーを迅速に実行するための、ターン キーのビジネス継続性機能を用意する機能も備わっています。 この記事には、アプリケーションのデプロイ前に確認する重要な情報が含まれています。

高可用性を継続的に提供することに努めてはいますが、Azure SQL Managed Instance サービスの障害でデータベースが利用できなくなり、アプリケーションへの影響が出ることがあります。 サービスの監視によって、接続エラー、障害、パフォーマンスの問題を広範囲にわたって引き起こす問題が検出されると、ユーザーに逐次情報を提供するために、サービスで自動的に停止が宣言されます。

サービス停止

Azure SQL Managed Instance サービスが停止した場合は、次の場所でその停止に関連する追加の詳細を確認できます。

• Azure portal のバナー

  サブスクリプションが影響を受けることが確認された場合は、Azure portal の [通知] にサービスに問題があることを知らせる停止アラートが発生します。

  

• [ヘルプとサポート] または [サポートとトラブルシューティング]

  [ヘルプとサポート] または [サポートとトラブルシューティング] からサポート チケットを作成すると、リソースに影響を与える問題に関する情報が表示されます。 影響の詳細と概要を確認するには、[View outage details] (停止の詳細を確認する) を選択します。 アラートは [新しいサポート リクエスト] ページでも確認できます。

  

• サービス正常性

  Azure portal の [サービス正常性] ページでは、Azure データ センターの全体的な状態に関する情報を確認できます。 Azure portal の検索バーで「サービス正常性」と検索し、[有効なイベント] カテゴリの [サービスの問題] を確認します。 また、[ヘルプ] メニューの任意のリソースの [リソース正常性] ページで、個々のリソースの正常性を確認することもできます。 次に示すのは [サービス正常性] ページのサンプル スクリーンショットで、東南アジアでのアクティブなサービスの問題に関する情報が表示されています。

  

• 電子メール通知

  アラートが設定されている場合、サービスの停止によりサブスクリプションとリソースが影響を受けると、azure-noreply@microsoft.com からメール通知が届きます。 メールの本文は一般的に、"アクティビティ ログ アラート ... が Azure サブスクリプション ... のサービスの問題によってトリガーされました" で始まります。 サービス正常性のアラートの詳細については、「Azure portal を使用して Azure サービスの通知でアクティビティ ログ アラートを受け取る」を参照してください。

停止中にディザスター リカバリーを開始するタイミング

アプリケーション リソースに影響を与えるサービスの停止が発生した場合は、次の一連のアクションを実施することを検討してください。

• Azure チームはできるだけ早くサービスが利用できるようになるように取り組みますが、根本原因によってはしばらくかかることがあります。 長いダウンタイムを許容できるアプリケーションの場合は、回復が完了するのを待つだけで済みます。 この場合、ユーザーによる操作は必要ありません。 [ヘルプ] メニューの任意のリソースの [リソース正常性] ページで、個々のリソースの正常性を確認します。 停止に関する更新情報と最新情報については、[リソース正常性] ページを参照してください。 リージョンの回復後に、アプリケーションの可用性が復元されます。

• 別の Azure リージョンへの復旧には、アプリケーション接続文字列の変更や DNS リダイレクトの使用が必要になる可能性があり、永続的なデータ損失が発生する場合があります。 したがって、ディザスター リカバリーは、停止期間がアプリケーションの目標復旧時間 (RTO) に迫っている場合にのみ実行してください。 アプリケーションを運用環境にデプロイする際には、アプリケーションの正常性を定期的に監視し、アプリケーション層からデータベースへの接続エラーが長引いている場合にのみ復旧が保証されることを表明する必要があります。 ダウンタイムに対するアプリケーションの許容度とビジネス上の責任に応じて、サービスが復旧するまで待つか、ディザスター リカバリーを開始するかどうかを自分で決めることができます。

障害復旧ガイダンス

あるリージョンの Azure SQL Managed Instance の障害が長期間にわたって対処されず、アプリケーションのサービス レベル アグリーメント (SLA) に影響が出ている場合は、次の手順を検討してください。

geo レプリケーションされたセカンダリ インスタンスへのフェールオーバー (データ損失なし)

フェールオーバー グループが有効になっている場合は、Azure portal でプライマリおよびセカンダリ インスタンスのリソースの状態がオンラインになっていることを確認します。 その場合、プライマリ インスタンスとセカンダリ インスタンスの両方のデータ プレーンは正常です。

次を使用して、セカンダリ リージョンへのフェールオーバー グループのフェールオーバーを開始します。

• Azure Portal
• PowerShell
• Azure CLI。

Note

フェールオーバーでは、ロールを切り替える前に完全なデータ同期が必要であり、データが失われることはありません。 サービスの停止の種類によっては、データが失われないフェールオーバーが成功するという保証はありませんが、最初の復旧オプションとして試してみる価値はあります。

geo レプリケーションされたセカンダリ インスタンスへの強制フェールオーバー (データ損失が発生する可能性あり)

フェールオーバーが円滑に完了せずにエラーが発生するか、プライマリ データベースのステータスが オンラインでない 場合、セカンダリ リージョンへのデータ損失の可能性を伴う強制フェールオーバーを慎重に検討してください。

強制フェールオーバーを開始するには、次のものを使用します。

• Azure portal。ただし、強制フェールオーバーを選択します。
• PowerShell。ただし --allow-data-loss を使用します。
• Azure CLI。ただし、-AllowDataLoss を使用します。

geo リストア

フェールオーバー グループを有効にしていない場合は、最後の手段として geo リストアを使用して障害から復旧できます。 geo リストアには、geo レプリケートされたバックアップがソースとして使われます。 geo レプリケートされた最新のバックアップから任意の Azure リージョン内の任意のインスタンスでデータベースを復元することができます。 障害によってインスタンスまたは全体のリージョンデータセンターにアクセスできない場合でも、geo リストアを要求できます。

Azure CLI、Azure portal、PowerShell、または REST API による geo リストアの詳細については、「geo リストア」をご覧ください。

復旧後のデータベースの構成

geo フェールオーバーまたは geo リストアを使用して停止から復旧する場合は、通常のアプリケーション機能を再開できるように、新しいインスタンスへ接続が正しく構成されていることを確認する必要があります。 復旧後のデータベースをすぐ運用できるようにするためのタスクのチェックリストを次に示します。

重要

ディザスター リカバリー戦略の定期的な訓練を実施して、アプリケーションの許容度と、復旧手順のすべての運用面を確認することをお勧めします。 アプリケーション インフラストラクチャの他のレイヤーでは、再構成が必要になる場合があります。 回復性があるアーキテクチャの手順の詳細については、「高可用性とディザスター リカバリーのチェックリスト」を確認してください。

接続文字列を更新する

• geo リストアを使用する場合は、通常のアプリケーション機能を再開できるように、新しいデータベースへの接続を正しく構成する必要があります。 復旧後のデータベースは別のインスタンスにあるため、そのサーバーを示すようにアプリケーションの接続文字列を更新する必要があります。 接続文字列の変更の詳細については、 接続ライブラリの適切な開発言語を参照してください。
• フェールオーバー グループを使用して停止から復旧し、アプリケーション接続文字列で読み取り/書き込みリスナーと読み取り専用リスナーを使用している場合、接続は新しいプライマリに自動的にリダイレクトされるため、それ以上の操作は必要ありません。

ファイアウォール規則の構成

セカンダリ インスタンス用に構成された NSG とルート テーブルの規則を、プライマリ インスタンスで構成されているものと一致させてください。 詳細については、「サービス支援サブネット構成」を確認してください。

ログインとデータベース ユーザーを構成する

セカンダリ インスタンスの master データベースに必要なログインを作成し、該当する場合は、これらのログインに master データベースでの適切なアクセス許可があることを確認します。

テレメトリ アラートを設定する

既存のアラート ルール設定が更新され、新しいプライマリ インスタンスにマップされていることを確認します。 データベースのアラート ルールの詳細については、「アラート通知の受信」および「サービス正常性を追跡する」を参照してください。

監査を有効にする

プライマリ インスタンスで監査が構成されている場合は、セカンダリ インスタンスで同じものを適用します。 詳細については、「Azure SQL Managed Instance での Azure SQL 監査」をご覧ください。

関連するコンテンツ

詳細については、次を参照してください。

• 継続性のシナリオ。
• 自動バックアップ
• サービスによって開始されたバックアップからデータベースを復元します。
• フェールオーバー グループ。
• 障害復旧ガイダンス
• 高可用性とディザスター リカバリー チェックリスト
• ゾーン冗長データベース