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 インフラストラクチャの可用性にも依存することに注意してください。
ポイントインタイム リストア
サポートされている保持制限内でバックアップを保持および復元する期間を決定します。
ストレージへの影響と、バックアップの保有期間を長くするコストを考慮してください。 既定のリテンション期間は 7 日間です。 この期間では、最大 7 日間復元でき、1 回の完全バックアップ、毎日の差分バックアップ、トランザクション ログのバックアップを約 5 分ごとに取得できます。
バックアップの永続ボリュームに使用するストレージ クラス を検討します。 ガイダンスについては、Azure Arc 対応 SQL Managed Instance のストレージ規範のを参照してください。
予想されるデータ サイズと構成された保有期間のコンテキストでのバックアップの永続ボリュームのサイズを検討してください。
ストレージのベスト プラクティスについては、Azure Arc 対応 SQL Managed Instance のStorage 規範に関するページを参照してください。
バックアップは常にプライマリ レプリカで実行されます。 インスタンスに割り当てられているリソースを識別するときに、バックアップおよび復元プロセスのパフォーマンスへの影響を考慮してください。
データベースの特定の時点への復元で既存のデータベースを上書きできないことを考慮してください。 ただし、同じインスタンス上の新しいデータベースにデータを復元できます。
復元プロセス中にアプリケーションがオンラインの場合は、データベースを完全に復旧するために必要な追加の手順を検討してください。
「マルチレプリカ インスタンスへのデータベースの復元」の説明に従って、データベースをマルチレプリカ インスタンスに復元するために必要な追加の手順検討してください。
データベース管理者がバックアップの構成と復元に使用するツールを決定します。 詳細については、「Azure Arc 対応 SQL Managed Instanceへの接続」を参照してください。
高可用性
ワークロードの可用性要件を確認し、Arc 対応 SQL Managed Instance のデプロイに最適なサービス レベルを決定します。
- General Purpose サービス レベルでは、使用可能なレプリカが 1 つあり、高可用性は Kubernetes オーケストレーションを介して実現されます。
- Business Critical サービス レベルでは、Azure Arc 対応 SQL Managed Instance は、Kubernetes オーケストレーションによってネイティブに提供される可用性グループに加えて、包含可用性グループを提供します。
1 つのレプリカのみが存在するため、General Purpose サービス レベルでダウンタイムが発生する可能性があるビジネス上の影響を考慮してください。
Business Critical サービス レベルにデプロイするレプリカの数 (1 ~ 3 個) を検討します。
2 つ以上のレプリカを持つ Business Critical サービス レベルにインスタンスをデプロイする場合は、セカンダリ レプリカを読み取り可能として構成できます。 Business Critical サービス レベルにデプロイするセカンダリ レプリカの数を決定します。 番号の変更については、「読み取り可能なセカンダリを構成する」を参照してください。
Business Critical サービス層でトランザクションをコミットするために必要なセカンダリ レプリカの数を決定し、のオプションパラメーター--sync-secondary-to-commitを使用して可用性より一貫性を優先する方法を決定します。 レプリカ間に接続の問題がある場合、プライマリはトランザクションをコミットしない可能性があります。
- 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 のStorage の規範を参照してください。
復元操作を開始する前 省略可能なパラメーター--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 のインスタンスの名前がプライマリ サイトとセカンダリ サイトで異なっていること、およびサイトの共有名の値が同じであることを確認します。
定期的なディザスター リカバリー訓練を実行して、フェールオーバー プロセスを検証します。
手動フェールオーバーと強制フェールオーバーの両方を開始するプロセスを作成します。
クラスターの正常性を監視し、フェールオーバーが必要なタイミングを理解するためのベスト プラクティスについては、「Azure Arc 対応 SQL Managed Instanceの管理と監視」を参照してください。
フェールオーバー中に DNS レコードを手動で作成する必要がないように、DNS サーバーで 分散型可用性グループの共有名の DNS レコードを定義します。
次の手順
ハイブリッドクラウドとマルチクラウドクラウド体験の詳細については、次の記事を参照してください。
- Azure Arc 対応データ サービスとは
- の概要: Azure Arc 対応 SQL Managed Instance のビジネス継続性
- Azure Arc 対応データ サービス Kubernetes 検証
- ハイブリッドおよびマルチクラウド運用 全体でポートフォリオを管理する
- Azure Arc Jumpstart を使用した自動シナリオ用の Azure Arc 対応データ サービス
- Microsoft Learn のラーニング パスである Azure Arcを使用して、ハイブリッド環境に Azure イノベーションをもたらす