Azure Arc 対応 SQL Managed Instance の事業継続とディザスター リカバリー

Azure Arc 対応 SQL Managed Instance では、事業継続とディザスター リカバリー (BCDR) の機能が提供されます。これにより、企業は中断から復旧し、最小限のダウンタイムで運用を継続できます。

この記事では、ポイントインタイム リストア、高可用性、ディザスター リカバリーなどの事業継続の機能を構成および管理するための主要な設計上の考慮事項と推奨事項について説明します。

アーキテクチャ

次のアーキテクチャ図は、ダウンタイムがほぼゼロのフェールオーバーをサポートする、Business Critical サービス レベルでの Arc 対応 SQL Managed Instance の高可用性機能を示しています。 プライマリ インスタンスに障害が発生すると、ロード バランサーはそのインスタンスへのトラフィックの送信を停止します。 その後、セカンダリ インスタンスの 1 つがプライマリに昇格され、新しく昇格されたインスタンスがロード バランサーからの読み取り/書き込みトラフィックの受信を開始します。 障害が発生したインスタンスがオンラインに戻ると、セカンダリ インスタンスとして追加されます。

次のアーキテクチャ図は、ディザスター リカバリーのために、2 つの異なるサイトの 2 つの個別の Kubernetes クラスターに Arc 対応 SQL Managed Instance をデプロイする方法を示しています。

次のアーキテクチャ図は、ディザスター リカバリーのフェールオーバーが開始されたときに Arc 対応 SQL Managed Instance がどのように応答するかを示しています。

設計上の考慮事項

Azure Arc 対応 SQL Managed Instance が BCDR モデル全体に及ぼす影響を評価するには、「事業継続とディザスター リカバリー」でランディング ゾーンに関する BCDR の推奨事項を確認します。 事業継続とディザスター リカバリーの焦点は、事業継続に関する設計上の推奨事項のみですが、インスタンスの高可用性と回復性も、基になる Kubernetes インフラストラクチャの可用性に依存しています。

ポイントインタイム リストア

• 回復ポイントの目標 (RPO) と目標復旧時間 (RTO) のターゲットを定義します。

• サポートされている保持期間内でバックアップを保持および復元する期間を決定します。

• バックアップの保持期間を延長する場合のストレージへの影響とコストを考慮してください。 既定の保持期間は 7 日です。 この期間では、最大 7 日分復元でき、1 回の完全バックアップ、毎日の差分バックアップ、約 5 分ごとのトランザクション ログのバックアップが取得されます。

• バックアップ用の永続ボリュームに使用するストレージ クラスを検討します。 ガイダンスについては、「Azure Arc 対応 SQL Managed Instance のストレージ規範」を参照してください。

• 予想されるデータ サイズと構成された保持期間のコンテキストで、バックアップの永続ボリュームのサイズを検討します。

• ストレージのベスト プラクティスについては、「Azure Arc 対応 SQL Managed Instance のストレージ規範」を参照してください。

• バックアップは常にプライマリ レプリカで実行されます。 インスタンスに割り当てられるリソースを決定する際は、バックアップと復元のプロセスのパフォーマンスの影響を考慮してください。

• データベースのポイントインタイム リストアでは既存のデータベースを上書きできないことを考慮してください。 ただし、同じインスタンス上の新しいデータベースにデータを復元できます。

• 復元プロセス中にアプリケーションがオンラインの場合は、データベースを完全に復旧するために必要な追加の手順を検討してください。

• 「マルチレプリカ インスタンスへのデータベースの復元」の説明に従って、マルチレプリカ インスタンスにデータベースを復元するために必要な追加の手順を検討してください。

• データベース管理者がバックアップの構成と復元に使用するツールを決定します。 詳細については、「Azure Arc 対応 SQL Managed Instance に接続する」を参照してください。

高可用性

• ワークロードの可用性要件を確認し、Arc 対応 SQL Managed Instance のデプロイに最適なサービス レベルを決定します。

  • General Purpose サービス レベルでは、使用可能なレプリカは 1 つであり、Kubernetes オーケストレーションを使用して高可用性が実現されます。
  • Business Critical サービス レベルでは、Kubernetes オーケストレーションによってネイティブに提供されるものに加えて、Azure Arc 対応 SQL Managed Instance により包含型可用性グループが提供されます。

• General Purpose サービス レベルでは、レプリカが 1 つだけ存在することが原因で発生する可能性があるダウンタイムのビジネス上の影響を考慮してください。

• Business Critical サービス レベルにデプロイするレプリカの数 (1 から 3) を検討します。

• 2 つ以上のレプリカを使用して Business Critical サービス レベルにインスタンスをデプロイする場合は、セカンダリ レプリカを読み取り可能として構成できます。 Business Critical サービス レベルにデプロイするセカンダリ レプリカの数を決定します。 数の変更については、「読み取り可能なセカンダリを構成する」を参照してください。

• オプションのパラメーター --sync-secondary-to-commit を使用して、Business Critical サービス レベルでトランザクションをコミットするために必要なセカンダリ レプリカの数により、可用性よりも一貫性を優先することを決定します。 レプリカ間で接続の問題が発生した場合、プライマリはトランザクションをコミットしない可能性があります。

  • 2 つのレプリカ構成では、プライマリが成功メッセージを受信するには、両方のレプリカでトランザクションがコミットされる必要があります。
  • 3 つのレプリカ構成では、成功メッセージを返すには、3 つのレプリカのうち少なくとも 2 つでトランザクションがコミットされる必要があります。

• 特定のレプリカをプライマリとして指定する必要があるかどうかを決定します。 プライマリ レプリカの指定については、「推奨されるプライマリ レプリカ」を参照してください。

• 使用する Kubernetes サービスの種類 (LoadBalancer または NodePort) を決定します。 ロード バランサーを使用する場合、アプリケーションは同じプライマリ エンドポイントに再接続でき、Kubernetes は新しいプライマリに接続をリダイレクトします。 ノード ポートを使用する場合、アプリケーションは新しい IP アドレスに再接続する必要があります。

障害復旧

• geo プライマリと geo セカンダリ サイト両方の Azure Arc 対応 SQL Managed Instance のインスタンスは、コンピューティングと容量が同一であり、かつ同じサービス レベルにデプロイされる必要があります。

• ディザスター リカバリー構成を作成するときに、インスタンスをホストする両方のクラスターからアクセスできるミラーリング証明書を格納する場所を決定します。

• セカンダリ インスタンスへのフェールオーバーを実行するタイミングを決定するために、プライマリ インスタンスのダウンタイムを監視する方法を検討します。

• 各インスタンスには専用のエンドポイントがあります。 フェールオーバーが発生した場合に、中断を最小限に抑えてアプリケーションがプライマリ エンドポイントにアクセスする方法を検討します。

設計の推奨事項

次のセクションでは、ポイントインタイム リストア、高可用性、ディザスター リカバリーに関する設計上の推奨事項を示します。

ポイントインタイム リストア

• Arc 対応 SQL Managed Instance の新しいインスタンスをデプロイする場合は、既定のデータ ストレージ クラスにならないように、必ずバックアップ用のストレージ クラスを定義します。

• バックアップ ボリュームには ReadWriteMany (RWX) をサポートするストレージ クラスを使用します。 ガイダンスについては、「Azure Arc 対応 SQL Managed Instance のストレージ規範」を参照してください。

• 復元操作を開始する前に、省略可能なパラメーター --dry-run を使用して、最初に操作が成功するかどうかを検証します。 詳細については、「az CLI を使用して特定の時点からデータベースを作成する」を参照してください。

• より長い保持期間を必要とするバックアップを Azure またはその他のオンプレミスのコールド ストレージに送信するプロセスを作成します。

• バックアップによって消費されるストレージを監視して、必要であれば、より長い保持期間に対応できるかどうかを判断します。

高可用性

• 定期的な演習を実施して、Arc 対応 SQL Managed Instance のインスタンスの高可用性を検証します。 演習の例としては、General Purpose インスタンス内のポッドの削除や、Business Critical インスタンス内のレプリカの障害などがあります。

• Business Critical レベルでは、データ損失をほぼゼロにするには、2 つのレプリカ構成の代わりに 3 つのレプリカ構成にインスタンスをデプロイします。

• 可用性を向上するには、インスタンスをデプロイするときに、サービスの種類として LoadBalancer を使用します。

• Azure Arc 対応 SQL Managed Instance の高可用性の制限事項を確認します。

• サポートされている可用性モードを確認し、高可用性のニーズに基づいて使用するモードを決定します。

• 複数のレプリカを使用して Business Critical インスタンスをデプロイする場合は、"読み取り" ワークロードにセカンダリ レプリカのいずれかを使用します。 アプリケーションの接続文字列では、セカンダリ レプリカへのリダイレクトのサービス リスナーとしてセカンダリ エンドポイントを指定する必要があります。 エンドポイントの詳細について、「プライマリ エンドポイント、セカンダリ エンドポイント、AG の状態を取得する」を参照してください。

• インスタンスの可用性を監視するためのベスト プラクティスについて、Azure Arc 対応 SQL Managed Instance の管理と監視に関するページを参照してください。

障害復旧

• Arc 対応 SQL Managed Instance のインスタンスの名前がプライマリ サイトとセカンダリ サイトで異なっていること、およびサイトの shared-name の値が同じであることを確認します。

• 定期的なディザスター リカバリー訓練を実行して、フェールオーバー プロセスを検証します。

• 手動フェールオーバーと強制フェールオーバーの両方を開始するプロセスを作成します。

• クラスターの正常性を監視するためのベスト プラクティス、およびフェールオーバーが必要な場合については、Azure Arc 対応 SQL Managed Instance の管理と監視に関するページを参照してください。

• フェールオーバー中に DNS レコードを手動で作成する必要がないように、DNS サーバー内の分散可用性グループの共有名の DNS レコードを定義します。

次のステップ

ハイブリッドとマルチクラウドでのクラウドの取り組みの詳細については、次の記事を参照してください。

• Azure Arc 対応データ サービスとは
• 概要: Azure Arc 対応 SQL Managed Instance のビジネス継続性
• Azure Arc 対応データ サービス Kubernetes 検証
• ハイブリッドおよびマルチクラウド運用間でポートフォリオを管理する
• Azure Arc Jumpstart を使用した自動シナリオ用の Azure Arc 対応データ サービス
• Azure Arc を使用してハイブリッド環境に Azure イノベーションを実現する (Microsoft Learn のラーニング パス)