※この記事は翻訳されたものです。本記事の原文はこちら
はじめに
SQL Server フェールオーバー クラスター インスタンス（FCI）、またはAzureのSAP ASCS/ERSクラスターを構築しているとしましょう。クラスターの各ノードは異なる可用性ゾーン（AZ）に配置されています。また、厳しいレイテンシー要件があったり、近接配置グループ（PPG）を使用していたり、すべてのノードが同じ可用性セットに存在していたりするかもしれません。どのようなシナリオであっても、ビジネスクリティカルなアプリケーションの可用性レベルは、単一のインスタンスを実行する場合よりもはるかに高くなります。
さて、高可用性（HA）を確保したところで、ディザスターリカバリーはどうするつもりでしょうか？複数のAZを破壊するような広範囲にわたる災害はめったにありませんが、最近の状況を見ると、母なる自然は本当に恐ろしいものです。リージョン全体がオフラインになるような事態に備える必要があります。
Azure Site Recovery（ASR）は、Microsoftが提供するDRaaS（Disaster Recovery-as-a-Service、サービスとしてのディザスターリカバリー）で、あるリージョンから別のリージョンへVM全体をレプリケートすることが可能です。オンプレミスからAzureに仮想マシンや物理サーバーをレプリケートすることもできますが、この記事では、Azureのリージョン間DRの機能に焦点を当てたいと思います。
Azure Site Recovery のセットアップ
ここでは、すでにSIOS DataKeeperを使ってクラスターを構築していることを想定しています。まだ構築していない方のために、構築に役立ついくつかのポイントをご紹介します。
Azure Virtual Machines 上の SQL Server を使用したフェールオーバー クラスター インスタンス
ASCS/SCS クラスター共有ディスク用の SIOS DataKeeper Cluster Edition
また、ここでは読者の皆さんがAzure Site Recoveryに精通していることを前提に話を進めていきます。ASRのセットアップについては、Microsoftの最新のドキュメントをお読みいただくことをお勧めします。この記事では、皆さんが考慮していないと思われるいくつかの事柄と、別のサブネットへのフェールオーバー後にクラスターを修正するために必要な特定の手順について説明します。
リージョンのペアリング
DR対応を開始する前に、Azureリージョンペアの概念を理解しておく必要があります。Azureのすべてのリージョンには、優先DRリージョンがあります。リージョンペアについて詳しく知りたい場合は、こちらのドキュメントを参照してください。リージョンペアを使用することには非常に優れた利点がありますが、DRサイトをホストするためにどのリージョンを使用するかを決定するのは、ユーザー次第です。
クラウド監視の場所
最初にクラスターを構築する時にクォーラムの監視タイプを選択する必要がありますが、ファイル共有監視またはクラウド監視を選択したと思います。通常、これらの監視タイプのいずれかを、クラスターノードとは別のAZに置く必要があります。
しかし、障害が発生した場合にクラスター全体がDRリージョンで実行されることを考えた場合、もっと良い選択肢があります。クラウド監視を使用して、これをDRリージョンに配置するのです。クラウド監視をDRリージョンに配置することで、ローカルAZの障害に対する回復力が得られるだけでなく、リージョン全体で障害が発生し、ASRを使用してDR リージョンでクラスターを回復する必要がある場合にも保護されます。動的クォーラム（Dynamic Quorum）と動的監視（Dynamic Witness）により、DRリージョンが一時的にオフラインになったとしても、本番クラスターが影響を受けないようにすることができます。
マルチVM整合性
ASRを使用してクラスターをレプリケートする場合、各クラスターノードのリカバリーポイントが確実に同じ時点のものになるようにするために、マルチVM整合性を有効にすることが重要です。これにより、VM間で発生するDataKeeperのブロックレベルのレプリケーションは、完全な再同期を必要とせずに、リカバリー後も継続できるようになります。
クラッシュ整合性復旧ポイント
アプリケーション整合性復旧ポイントは、レプリケートされたクラスターではサポートされていません。ASRレプリケーションオプションを構成する際は、アプリケーション整合性復旧ポイントを有効にしないでください。
フェールオーバー後もIPアドレスを保持する？
ASRを使用してDRサイトにレプリケートする場合、VMのIPアドレスを同じにする方法があります。マイクロソフトは、記事「フェールオーバー時に IP アドレスを保持する」で、この方法を紹介しています。フェールオーバー後も同じIPアドレスを保持できれば、クラスターのIPアドレスやIPアドレスに基づくDataKeeperのミラーエンドポイントを修正する必要がなくなるため、復旧プロセスを簡素化できます。
ところが、私の経験では実際に上記のガイダンスに従った人を見たことがないので、別のサブネットのクラスターを復旧するには、クラスターをオンラインにする前に、復旧後に追加の手順をいくつか実施する必要があります。
最初のフェールオーバー試行
復旧計画
マルチVM整合性を使用している場合には、復旧計画を使用してVMをフェールオーバーする必要があります。こちらのドキュメントには、その方法について非常にわかりやすいガイダンスが記載されています。復旧計画では、復旧したいVMをグループ化し、すべてのVMが一緒にフェールオーバーするようにします。また、複数のVMグループを同じ復旧計画に追加することで、インフラ全体を整然とフェールオーバーさせることも可能です。
復旧計画では、復旧後のスクリプトを起動して、フェールオーバーが正常に復旧を完了できるようにすることもできます。以下で説明する手順はすべて、復旧計画の一部としてスクリプト化できるため、完全な復旧プロセスを完全に自動化できます。このブログ記事ではこのプロセスについては説明しませんが、マイクロソフトのこちらのドキュメントに説明が記載されています。
静的IPアドレス
リカバリープロセスの一環として、新しいVMが静的IPアドレスを持つことを確認する必要があります。VMが常に同じアドレスを使用するように、Azureポータルでインターフェースのプロパティを調整する必要があります。もし、インターフェースにパブリックIPアドレスを追加したい場合は、この時点で追加する必要があります。
ネットワーク設定
レプリケートされたVMがDRサイトに正常に復旧したら、まず基本的な接続（IP構成は正しいか、インスタンスは正しいDNSサーバを使用しているか、名前解決は正しく機能しているか、リモートサーバーにpingを打てるか）を確認します。
ネットワーク通信に問題がある場合、以下に説明する残りの手順は必ず失敗します。このステップをスキップしないでください。
ロードバランサー
ご存知のように、Azureのクラスターでは、クライアント接続を機能させるためにロードバランサーを構成する必要があります。ロードバランサーは、復旧計画の一部としてフェールオーバーしません。この新しいvNetに現在存在するクラスターに基づいて、新しいロードバランサーを構築する必要があります。これは手動で行うことも、復旧計画の一部としてスクリプト化して自動的に行うこともできます。
ネットワークセキュリティグループ
この新しいサブネットで実行するということは、これらのインスタンスに適用するネットワークセキュリティグループを指定しなければならないということも意味します。インスタンスが必要なポートで通信できることを確認する必要があります。この作業も手動で行うことができますが、復旧計画の一環としてスクリプト化することをお勧めします。
IPクラスターアドレスを修正する
前述の変更を行って同じサブネット内のインスタンスを復元できない場合は、次の手順を実施して、新しいサブネットで使用するためにクラスターのIPアドレスとDataKeeperのアドレスを更新する必要があります。
すべてのクラスターには、コアクラスターのIPアドレスがあります。フェールオーバー後にWSFC UIを起動すると、クラスターが接続できないことがわかります。これは、クラスターが使用しているIPアドレスが新しいサブネットで有効でないためです。
そのIPアドレスリソースのプロパティを開くと、新しいサブネットで機能するIPアドレスに変更することができます。ネットワークとサブネットマスクも必ず更新してください。
このIPアドレスを修正したら、クラスターリソースで使用する他のクラスターアドレスについても同じことを行う必要があります。
DataKeeperのミラーアドレスを修正する
SIOS DataKeeperのミラーは、ミラーエンドポイントとしてIPアドレスを使用します。これらはミラーとミラージョブに保存されます。DataKeeperベースのクラスターを別のサブネットにリカバリーする場合、ミラーは「Resync Pending（再同期保留中）」の状態になります。また、ソースIPとターゲットIPは、DRサイトのサブネットではなく、元のサブネットを反映します。
この問題を修正するには、SIOSからCHANGEMIRRORENDPOINTSというコマンドを実行する必要があります。CHANGEMIRRORENDPOINTS の使い方は以下の通りです。
emcmd <NEW source IP> CHANGEMIRRORENDPOINTS <volume letter> <ORIGINAL target IP> <NEW source IP> <NEW target IP>
この例では、コマンドと出力は次のようになります。
コマンド実行後、DataKeeperのGUIは以下のように新しいIPアドレスを反映したものに更新されます。また、ミラーはミラーリング状態になります。
おわりに
高い可用性を実現するDataKeeper、ディザスターリカバリーに対応するAzure Site Recoveryを組み合わせて、ビジネスクリティカルなアプリケーションの構成とテストに成功しました。
SQL Server、SAP ASCSおよびERS、SAP HANA、Oracleなどのビジネスクリティカルなアプリケーションの高可用性とディザスタリカバリーを実現するための設計と実装について、ご質問がある場合は、サイオステクノロジーまでご連絡ください。
