はじめに
企業がパブリック クラウド上に SAP HANAを導入する過程で、その可用性要件に対処する事が重要です。そのために、HANA データベース フレームワークは、組み込みの高可用性 およびシステム レプリケーション (HSR) 機能を提供します。ほとんどの障害をカバーしますが、幾つかの障害イベントが発生した場合、復旧の際に手動のオペレーションが必要になります。
本記事では、InfoScale Enterprise を使用して AWS クラウドにデプロイされるSAP HANA および SAP NetWeaver/ S/4HANA 環境の可用性を向上させるために必要な技術情報を説明しております。
InfoScaleによって、AWS上のSAP HANA の可用性が向上するユースケース
以下の図は、InfoScale for SAP HANA でサポートされる可用性の構成シナリオを表しています。本番環境で SAP HDB インスタンスに障害が発生した場合、InfoScale は障害を検出し、そのインスタンスを開発ノードまたはテストノードに移動します。 InfoScale Enterpriseでは、次のユース ケースで SAP HANA データベース インスタンスを監視および制御できます。
同じ AZ 内の SAP HANA インスタンス
このシナリオでは、マスター インスタンス (レプリケーションのプライマリ) とスタンバイ インスタンス (レプリケーションのセカンダリ) が同じ AZ 内の HANA システム レプリケーションと共に構成されます。 マスター・インスタンスに障害が発生すると、SAPHDB Agentはセカンダリをプライマリに昇格させます。
メモ: フェイルオーバー操作は HANA HA フェイルオーバーのガイドラインに従って実行され、SAPHDB Agentは HANA フェイルオーバー・ルールに従います。
同じ AWSリージョン内のAZ全体のSAP HANAインスタンス
この設定では、SAP HANA のプライマリインスタンスとセカンダリインスタンスが同じ AZ または同じリージョン内の異なる AZ に存在します。HANA システム レプリケーションが 2 つのインスタンス間で有効になっている場合、データとログはセカンダリ インスタンスにレプリケートされます。 この例では、プライマリ (マスター) インスタンスとセカンダリ (ワーカー) インスタンスは、ローカル クラスタリングを使用して異なる AZ で構成されています。
プライマリインスタンスに障害が発生したり、利用できなくなったりすると、SAPHDB Agentは障害を識別し、セカンダリインスタンスでのフェイルオーバーのオペレーションが自動的に起動します。次の図は、その動作の説明です。
古いプライマリ インスタンスで障害をクリアし、その他の必要なメンテナンスアクティビティを実行することもできます。SAPHDB Agentは、自動再登録機能を使用して、元のプライマリ インスタンスをセカンダリ インスタンスとして自動で指定できます。その後、HANA システム レプリケーションは、データレプリケーションの方向を逆転させます。次の図は、その動作の説明です。
AWS リージョン間の単一インスタンス SAP HANA データベース
AWSリージョン全体で単一のHANAデータベースインスタンスを構成することができ、GCO構成を使用してInfoScale Agentによって制御および監視することができます。次の図は、その動作の説明です。
プライマリインスタンスに障害が発生したり、利用できなくなったりすると、SAPHDB Agentは障害を識別し、他のリージョンのセカンダリインスタンスでのフェイルオーバーのオペレーションを自動的に起動します。次の図は、その動作の説明です。
障害をクリアし、古いプライマリ インスタンスで必要なその他のメンテナンスアクティビティを実行する必要があります。SAPHDB Agentは、自動再登録機能を使用して、元のプライマリ インスタンスをセカンダリ インスタンスとして自動的に指定できます。次の図は、その動作の説明です。
AWS リージョン間の SAP HANA データベースインスタンス (カスケードシナリオ)
このシナリオでは、HANA データベースのプライマリとセカンダリは、それぞれ N.バージニア リージョンのアベイラビリティーゾーン1とアベイラビリティーゾーン2で構成されます。3 番目の HANA データベース インスタンスはオハイオ リージョンにあります。次の図は、そのカスケード構成の説明です。
プライマリ・インスタンスに障害が発生すると、SAPHDB Agentは、同じリージョン内の 1 次インスタンスから 2 次インスタンスに IP リソースをフェイルオーバーすることによって、自動的にフェイルオーバーを起動します。仮想 IP フェイルオーバー操作は、AWSIP および IP Agentによって管理されます。次の図は、セカンダリがプライマリになり、アベイラビリティーゾーン2でアクティブになっている動作の説明です。
AZ またはリージョン内のすべてのインスタンスに障害が発生した場合、SAPHDB Agentは、プライマリからリモートリージョンのセカンダリ・インスタンスに IP リソースをフェイルオーバーすることによって、フェイルオーバーを自動的に起動します。 次の図は、リモート領域のセカンダリがプライマリになる動作の説明です。
その後、N.Virginia リージョンのインスタンスの障害をクリアし、オハイオ州の現在のプライマリに再登録する必要があります。次の図は、レプリケーションの方向が逆になっている動作の説明です。
詳しい内容については、ベリタスよりホワイトペーパーが公開されています。是非こちらをご覧ください。
おわりに
如何でしたでしょうか？ 今回の記事と記事中に紹介したホワイトペーパーによって、AWS上のInfoScale Enterpriseを用いたSAP HANAの可用性向上と災害対策をイメージできたのではないでしょうか？ 今回の内容は、InfoScale Enterpriseを用いたSAP HANAの可用性向上と災害対策【AWS編】でした。【Microsoft Azure編】、【Google Cloud Platform編】の記事もよろしければ続けてご覧下さい！
商談のご相談はこちら
本稿からのお問合せをご記入の際には「コメント/通信欄」に#GWCのタグを必ずご記入ください。
ご記入いただきました内容はベリタスのプライバシーポリシーに従って管理されます。
その他のリンク
【まとめ記事】ベリタステクノロジーズ 全記事へのリンク集もよろしくお願いいたします。