AWS上にHA構成のSAP on Oracleを構築する際のOSについて

2024.01.22

この記事を書いたメンバー：

清野宏

はじめに

AWS上にSAP on Oracle環境を構築する際、様々な制約がありますが、下記SAPノートに網羅的に記載があります。

2358420 - Oracle Database Support for Amazon Web Services EC2

上記ノートにはサポートOSに関して下記のような記載があります。

Oracle Database Serverと（Oracle Instant Clientを備えた）SAP NetWeaver Application Serverともに、Oracle Linuxでサポートされる。
SAP NetWeaver Application Server用のOracleクライアントソフトウェアは、Oracle Linuxでのみサポートされる。
Oracle Real Application Clusters(RAC)は、Amazon EC2ではサポートされない。

このノートからは、AWS上のSAP on Oracle環境では、AP/DB問わずOSは「Oracle Linuxのみ」がサポートされる、と書いてあるように見えます。

したがって、SAP on Oracleを高可用性構成（以下、HA構成と呼ぶ）で構築する場合でも、PAS/ASCS/DBいずれもOSはOracle Linuxで構築し、ASCSのHA構成にはサードパーティのクラスタソフトウェアを用い、DB(Oracle Database Server)のHA構成にはOracle Data Guardを用いる、とてっきり思っておりました。おそらく多くのBASISの方はそう思っていたはず。

これに対して以下のSAPノートがあります。

3074643 OLNX: FAQ: if Pacemaker for Oracle Linux is supported in SAP Environment

要約すると以下のようになります。

Oracleは、SAP環境のOracle LinuxでのPacemaker/Corosyncの使用をサポートしない。
Oracleクライアントを使用しないASCS、SCS、ERSインスタンスは、SAPがサポートされている他のOSでも実行可能である。
これらOSベンダーまたはサードパーティが提供する高可用性クラスターソフトウェアを、サポートステートメントに従い使用できる。

こちらのノートには、ASCS(およびSCS、ERS)のOSはOracle Linuxでなくてもよい、Redhat、SUSE、さらにはWindowsでもよい。そして、それらOSがサポートするクラスタソフトウェアを利用できる、と書いてあります。

言われてみれば確かに・・・と考えられなくもないですが、最初にご紹介したSAPノートの内容と異なっているように見えるため、本内容をSAPサポートに問い合わせてみると、

「はい、可能でございます。」

とのこと。うーん、ずいぶんあっさりだなぁ。

というわけで、今回、社内関係者を少しざわつかせたASCS HA構成時のOSについて、構築、検証してみたいと思います。

目的

ASCSのOSはRedhat Linux for SAP、PAS/DBのOSはOracle Linuxで構成し、SAP on Oracle環境を構築する。
ASCSはHA構成にする。（DBはHA構成しない）。ASCSのクラスタソフトウェアはRedhat Linux for SAPに付属するPacemaker/Corosyncを採用し、必要なクラスタ設定内容を確認する。
構築した環境（Oracle Linux、およびRedhat Linux混在環境）でASCS HA構成の動作が問題ないことを確認する。

なお、本ブログは詳細な設定手順の説明を目的とするところではありません。今回、Redhat LinuxのASCS HA構成の設定は、下記URLのドキュメント（以下、参照ドキュメント）に従い設定しましたので、具体的な手順を確認されたい方は、参照ドキュメントをご参照ください。

https://docs.aws.amazon.com/ja_jp/sap/latest/sap-netweaver/rhel-ha.html

全体構成

全体図

検証環境の全体構成図は下記になります。PAS/DBは各シングル構成、ASCS/ERSはHA構成にし、OSはそれぞれOracle Linux、Redhat Linux for SAPを採用します。

パラメータ

製品バージョン、インフラならびにSAPの設定パラメータは下記のとおりです。（一部環境固有の値はサンプル値になっています。）

各製品バージョン

グローバル AWS パラメータ

EC2インスタンスパラメータ

PAS

ASCS/ERS

SAP および Pacemaker のリソースパラメータ

RHEL クラスターのパラメーター

設定概要

設定の全体的な流れは下記になります。

全手順を記載しませんが、いくつか参照ドキュメントと異なる設定をした箇所について、手順を記載します。

①AWS設定

サブネット構成

踏み台サーバ（Bastion）があるパブリックサブネットとSAP環境（PAS、ASCS、ERS、DB）があるプライベートサブネットの複数サブネットがある点が参照ドキュメントと異なります。

そのため、それぞれのサブネットのルートテーブルにオーバーレイIPアドレスを追加する必要があります。また、EC2に割り当てるIAMロールのIAMポリシーに、それぞれのルートテーブルの参照、変更権限が必要です。

AWS オーバーレイ IP ポリシー

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:ReplaceRoute",
            "Resource": [
                 "arn:aws:ec2:ap-northeast-1:123456789100:route-table/rtb-xxxxx",
                 "arn:aws:ec2:ap-northeast-1:123456789100:route-table/rtb-yyyyy"
                        ]
        },
        {
            "Effect": "Allow",
            "Action": "ec2:DescribeRouteTables",
            "Resource": "*"
        }
    ]
}

②OS設定

SAP用OS設定

参照ドキュメントに記載ありませんが、下記のSAP用のOS設定を実施しています。

AWS DataProvider for SAP 4.3のインストール

AWS DataProvider for SAPは、AWS上のSAP環境がSAPサポートを受けるにあたって必要なエージェントですが、下記ドキュメントの記載に従いインストールを実施します。

https://docs.aws.amazon.com/sap/latest/general/data-provider-installallation.html

SAPノート記載のOS固有設定

Oracle Linux、Redhat Linux それぞれ下記SAPノートに従い実施します。

Note 2936683 - Oracle Linux 8: SAP Installation and Upgrade

Note 2772999 - Red Hat Enterprise Linux 8.x: Installation and Configuration

オーバーレイIPをホストIP構成に追加する

参照ドキュメントでは、ip addr addコマンドで設定する手順となっていますが、これは一時的な設定でOS再起動すると設定が元に戻っておりました。

恒常的に設定するため、以下のnmcliコマンドで設定を行います。

nwxascs01（ASCS）サーバ

nmcli connection show
ip addr show
nmcli connection modify "System eth0" +ipv4.addresses "172.16.0.1/32"
nmcli con up "System eth0"

nwxascs02（ERS）サーバ

nmcli connection show
ip addr show
nmcli connection modify "System eth0" +ipv4.addresses "172.16.0.2/32"
nmcli con up "System eth0"

共有ファイルシステム

参照ドキュメントでは、EFSにnfsを指定してマウントしていましたが、今回はEFSマウントヘルパーを使用してマウントしました。

EFSマウントヘルパーのインストール

下記ドキュメントに従い、EFSマウントヘルパーのインストールします。

https://docs.aws.amazon.com/efs/latest/ug/installing-amazon-efs-utils.html

yum -y install git
yum -y install make
yum -y install rpm-build
cd /tmp
git clone https://github.com/aws/efs-utils
cd /tmp/efs-utils
make rpm
yum -y install ./build/amazon-efs-utils*rpm

/etc/fstab を更新する

nwxap（PAS）、nwxdb（DB）サーバには、/sapmnt、/usr/sap/trans用のエントリを/etc/fstabを追加します。

fs-xxxxx:/SAPMNT /sapmnt efs _netdev,noresvport,tls,accesspoint=fsap-xxxxxxxxxxxxxxxxx 0 0
fs-xxxxx:/USR_SAP_TRANS /usr/sap/trans efs _netdev,noresvport,tls,accesspoint=fsap-xxxxxxxxxxxxxxxxx 0 0

nwxascs01（ASCS）、nwxascs02（ERS）サーバには、上記に加え、ASCS、ERS用のエントリを/etc/fstabを追加します。

fs-xxxxx:/SAPMNT /sapmnt efs _netdev,noresvport,tls,accesspoint=fsap-xxxxxxxxxxxxxxxxx 0 0
fs-xxxxx:/USR_SAP_NWX_ASCS00 /usr/sap/NWX/ASCS00 efs _netdev,noresvport,tls,accesspoint=fsap-xxxxxxxxxxxxxxxxx 0 0
fs-xxxxx:/USR_SAP_NWX_ERS10 /usr/sap/NWX/ERS10 efs _netdev,noresvport,tls,accesspoint=fsap-xxxxxxxxxxxxxxxxx 0 0
fs-xxxxx:/USR_SAP_TRANS /usr/sap/trans efs _netdev,noresvport,tls,accesspoint=fsap-xxxxxxxxxxxxxxxxx 0 0

③SAPインストール

sapinstオプション

注意点は、参照ドキュメントに記載があります。ASCS、ERSインストール時、 SAPINST_USE_HOSTNAME=<ASCS/ERSの仮想ホスト名> オプションを指定して実行します。

sapinst SAPINST_USE_HOSTNAME=<ASCS/ERSの仮想ホスト名>

エンキューサーバー

参照ドキュメントではオプション作業扱いですが、スタンドアロンエンキューサーバー２（ENSA2）に置き換えました。下記ドキュメントに従い、SAPプロファイルを修正し置き換えます。

なお、ENSA2は SAP NetWeaver7.52（SAP_BASIS 752）以上で利用可能ですので、ご注意ください。

https://help.sap.com/docs/ABAP_PLATFORM/cff8531bc1d9416d91bb6781e628d4e0/2490d16609204c45a3ec94822b7fed5a.html?locale=en-US

今回は下記のようにプロファイルを修正しENSA2に置き換えました。

デフォルトプロファイル

次のENSA1のパラメータを削除します。

enque/serverhost = nwxascs
enque/serverinst = 00
enque/deque_wait_answer = TRUE

次のENSA2のパラメータを追加します。

enq/enable = TRUE
enq/serverhost = nwxascs
enq/serverinst = 00
enq/replicatorhost = nwxers
enq/replicatorinst = 10
enq/client/max_async_requests = 0
enque/process_location = REMOTESA

ASCSインスタンスプロファイル

次のENSA1のパラメータを削除します。

enque/table_size = 64000
enque/server/threadcount = 4
enque/server/replication = true

_EN = en.sap$(SAPSYSTEMNAME)_$(INSTANCE_NAME)
Execute_04 = local rm -f $(_EN)
Execute_05 = local ln -s -f $(DIR_EXECUTABLE)/enserver$(FT_EXE) $(_EN)
Start_Program_01 = local $(_EN) pf=$(_PF)

次のENSA2のパラメータを追加します。

enq/server/schema_0 = NAME=$(SAPSYSTEMNAME),MAX_LOCKS=500000,SESSION_QUOTA=100
enq/server/replication/enable = TRUE

_ENQ = enq.sap$(SAPSYSTEMNAME)_$(INSTANCE_NAME)
Execute_04 = local rm -f $(_ENQ)
Execute_05 = local ln -s -f $(DIR_EXECUTABLE)/enq_server$(FT_EXE) $(_ENQ)
Start_Program_01 = local $(_ENQ) pf=$(_PF)

ERSインスタンスプロファイル

次のENSA1のパラメータを削除します。

enque/serverinst = $(SCSID)
enque/serverhost = $(SCSHOST)

_ER = er.sap$(SAPSYSTEMNAME)_$(INSTANCE_NAME)
Execute_03 = local rm -f $(_ER)
Execute_04 = local ln -s -f $(DIR_EXECUTABLE)/enrepserver$(FT_EXE) $(_ER)
Restart_Program_00 = local $(_ER) pf=$(_PFL) NR=$(SCSID)

次のENSA2のパラメータを追加します。

_ENQR = enqr.sap$(SAPSYSTEMNAME)_$(INSTANCE_NAME)
Execute_03 = local rm -f $(_ENQR)
Execute_04 = local ln -s -f $(DIR_EXECUTABLE)/enq_replicator$(FT_EXE) $(_ENQR)
Start_Program_00 = local $(_ENQR) pf=$(_PF) NR=$(SCSID)

④クラスタ設定、⑤クラスタリソース設定

クラスタは参照ドキュメント通りに設定をしております。以下に、設定後の設定内容をパラメータシートとしてまとめましたので、ご参照ください。

クラスタ構成ノード

クラスタノード認証

クラスタプロパティ

リソースデフォルト

オペレーションデフォルト

リソース構成

リソースパラメータ

STONITHの実行順序

Primitiveリソース

クラスタグループに含まれる各リソースの設定値は以下の通りです。

リソースrsc_fs_NWX_ASCS00、rsc_fs_NWX_ERS10はEFSマウントヘルパーが利用できなかった（エラーとなった）ため、参照ドキュメント記載通りのNFS4で設定しています。

STONITHリソース

リソース配置制約 (ノード)

リソース配置制約 (ルール)

今回ENSA2を設定したので本制約は設定しませんでしたが、ENSA1設定時は必要となる設定です。

リソース同居制約

リソース起動順序制約

検証

最後に正常にASCS HA構成が機能するか、いくつか障害を想定し検証します。

フェイルオーバーのテスト

プライマリノードの障害をシミュレートし、リソースのフェイルオーバーをテストします。

フェイルオーバーとフェンシングの両方を検証するため、プライマリノードで下記コマンドでネットワークインターフェースをオフラインにします。

ip link set eth0 down

予期される動作は、STONITHリソースでフェンシング動作が再起動（pcmk_reboot_action=reboot）となっているため、プライマリノードが再起動し、ASCSはセカンダリノードにフェイルオーバー、その後ERSはリソース同居制約によりプライマリノードにフェイルオーバーとなる想定です。

上記コマンドを実行すると、プライマリノード（nwxascs01）のフェンシング動作が待機中になります。(下記は、crm_monコマンドのクラスタステータス確認画面）

しばらくすると、プライマリノードがOS再起動します。

プライマリノード起動後、ASCSはセカンダリノードにフェイルオーバーし、ERSはプライマリノードにフェールオーバーします。

以上、プライマリノード障害時のフェンシングとリソースのフェールオーバー動作を確認できました。

ロックのエントリが保持されていることの確認

次に上記同様のフェイルオーバー時に更新処理があった場合を想定し、フェイルオーバー全体にロックエントリが保持されるかをテストします。

ロックエントリの生成にはSAP GUIで適当な画面を変更モードにしてもよいですが、下記コマンドでも可能です。ASCSがアクティブなサーバーで実行します。10個のロックエントリを生成しています。

enq_admin --set_locks=10:X:DIAG::TAB:%u pf=/sapmnt/NWX/profile/NWX_ASCS00_nwxascs

このタイミングで下記コマンドを実行しエンキューにロックエントリが登録されていることを確認します。

sapcontrol -nr 00 -function EnqGetStatistic | grep locks_now

結果は下記のとおりです。

10個登録されていることを確認できました。SAP GUIでT-cd：SM12でも確認できます。

ERSにもロックエントリが複製されていることを確認します。ERSがアクティブなサーバーで以下コマンドを実行します。

sapcontrol -nr 10 -function EnqGetStatistic | grep locks_now

結果は次の通りです。

ERSも10個のロックエントリが登録されていることを確認できました。

では、障害発生前の準備が整いましたので、AWS管理コンソールから強制的にプライマリノード(nwxascs01)を再起動します。

再起動後のリソース状況を確認すると、ASCSがセカンダリノード(nwxascs02)に、ERSがプライマリノード(nwxascs01)にフェイルオーバーしています。

ASCSがフェイルオーバーしたタイミングで、ロックエントリの状況を確認します。

T-cd：SM12でエンキューのロックエントリを確認すると、

10個のエントリがあります。

ERSがフェイルオーバーしたプライマリノードで以下コマンドを実行します。

sapcontrol -nr 10 -function EnqGetStatistic | grep locks_now

結果は次のように10個のロックエントリがERSに保持されています。

以上、フェイルオーバー全体でロックエントリが保持されていることを確認できました。

本コマンドで登録したロックエントリの解除はASCSがアクティブなサーバーで下記コマンドを実行します。

enq_admin --release_locks=10:X:DIAG::TAB:%u pf=/sapmnt/NWX/profile/NWX_ASCS00_nwxascs

まとめ

AWS上にSAP on Oracleの高可用性環境を構築しました。

ASCSのOSにRedhat Linux、PAS/DBのOSにOracle Linuxで構成し、ASCS HAのクラスタソフトウェアにPacemaker/Corosyncを採用しました。

OS混在環境下でも基本的な動作に問題無いこと、数パターンの障害にもHA動作に問題ないことを確認しました。

少しトリッキーと感じるOS構成ですが、SAPにサポートもされており、ASCSのOSにRedhat Linux またはSUSE Linuxを採用すれば、追加費用なしでクラスタソフトウェアPacemaker/Corosyncを利用した高可用性構成を組めます。AWS上でSAP on Oracle構築時の一案としてご検討ください。

以上、参考になれば幸いです。