Red Hat Enterprise Linux for SAP Solutions　ーHA Addonー

レッドハット　ソリューションアーキテクト石倉です。

今回はSAPシステムのHigh Availability(高可用性)の構成方法について紹介します。

SAPシステムの高可用性は、SAPシステムが提供する、SAP HANA System Replication (HSR)などの機能と、レッドハットが提供する高可用性アドオン機能との組み合わせで実装します。

レッドハットが提供する高可用性アドオンそのものの補足については以下のブログも御覧下さい。

まずはSAP HANAの高可用性の実装方法に関して、幾つか代表的なシナリオをご紹介します。

1. Performance Optimized

PRIMARYノードと同スペックのコンピュートリソースをSECONDARYノードとして用意し、HSRの機能でデータ同期します。

＃SECONDARYノードではSAP HANAがメモリ上にPreloadされた状態です。

PRIMARYノードに障害が発生した際、高可用性アドオンの仕組みでVirtual IPをSECONDARYノードに移動する事で、次の「2. Cost Optimized」モードと比べて、短時間での切り替えを可能にします。

＃一方、通常状態では稼働していない、SECONDARYノード分の倍のコンピュートリソースを用意する必要があるという、コスト的なデメリットも存在します。

具体的な構成手順に関しては以下のガイドもご参照下さい。

2. Cost Optimized

SECONDARYノードでは通常時はTESTあるいはQA環境のSAP HANAが動作するイメージになります。

＃データ同期はされますが、別用途のSAP HANAがSECONDARYノードで稼働しているので、本番SAP HANAはメモリ上にPreloadされていません。

従って、PRIMARYノードに障害が発生した際のノード切り替え処理内で、別用途のSAP HANAの停止処理や本番SAP HANAの起動処理が必要となり、「1. Performance Optimized」モードと比べて切り替え時間が長くなります。

3. HANA 2 Active-Active

HANA2.0から、SECONDARYノードをRead Onlyモードで提供する事が可能になりました。

これにより、通常稼働状態におけるデータベースへの参照処理を、PRIMARY/SECONDARYノードで分散するという事も可能になります。

次に、アプリケーションサーバの高可用性に関しては、Standalone Enqueue Server 2(ENSA2)への考慮が必要です。

＃これからSAP社ERPソフトウェア(SAP ERP Central Component(ECC))をSAP S/4HANAへ移行する方を想定し、ABAP Platform 1809以降の前提で記載しています。

ENSA2では、Multi-nodeクラスター構成と、従来からあるEnqueue Replication Server(ERS)へフェールオーバーするTwo-nodeクラスター構成が構成可能です。

具体的な構成手順に関しては以下のガイドもご参照下さい。

レッドハット　ソリューションアーキテクト石倉