Red Hat Enterprise Linux for SAP Applications マルチ SID 上の Azure VM での SAP NetWeaver の高可用性
この記事では、Red Hat Enterprise Linux for SAP Applications を使用して、Azure VM の 2つの ノード クラスターに複数の SAP NetWeaver 高可用性システム (マルチ SID) をデプロイする方法について説明します。
この例の構成では 3 つの SAP NetWeaver 7.50 システムを、1 つの 2 ノード高可用性クラスターにデプロイします。 SAP システムの SID は次のとおりです。
NW1: ASCS インスタンス数 00 と仮想ホスト名msnw1ascs。 ERS インスタンス数 02 と仮想ホスト名msnw1ers。NW2: ASCS インスタンス数 10 と仮想ホスト名msnw2ascs。 ERS インスタンス数 12 と仮想ホスト名msnw2ers。NW3: ASCS インスタンス数 20 と仮想ホスト名msnw3ascs。 ERS インスタンス数 22 と仮想ホスト名msnw3ers。
この記事では、データベース層および SAP NFS 共有のデプロイについては説明しません。
この記事の例では、NFS 共有に Azure NetApp Files のボリューム sapMSID を使用し、このボリュームは既にデプロイされているものとします。 この例では、Azure NetApp Files ボリュームが NFSv3 プロトコルでデプロイされていることを前提としています。 これらは、SAP システムNW1、NW2、NW3の ASCS および ERS インスタンスのクラスター リソースに対して次のファイル パスを使用し次のようになります:
- ボリューム sapMSID (nfs://10.42.0.4/sapmntNW1)
- ボリューム sapMSID (nfs://10.42.0.4/usrsapNW1ascs)
- ボリューム sapMSID (nfs://10.42.0.4/usrsapNW1sys)
- ボリューム sapMSID (nfs://10.42.0.4/usrsapNW1ers)
- ボリューム sapMSID (nfs://10.42.0.4/sapmntNW2)
- ボリューム sapMSID (nfs://10.42.0.4/usrsapNW2ascs)
- ボリューム sapMSID (nfs://10.42.0.4/usrsapNW2sys)
- ボリューム sapMSID (nfs://10.42.0.4/usrsapNW2ers)
- ボリューム sapMSID (nfs://10.42.0.4/sapmntNW3)
- ボリューム sapMSID (nfs://10.42.0.4/usrsapNW3ascs)
- ボリューム sapMSID (nfs://10.42.0.4/usrsapNW3sys)
- ボリューム sapMSID (nfs://10.42.0.4/usrsapNW3ers)
始める前に、次の SAP のノートとペーパーを参照してください:
- SAP Note 1928533: 次の情報が含まれています。
- SAP ソフトウェアのデプロイでサポートされる Azure VM サイズの一覧。
- Azure VM サイズの容量に関する重要な情報。
- サポートされる SAP ソフトウェア、およびオペレーティング システム (OS) とデータベースの組み合わせ。
- Microsoft Azure 上の Windows と Linux に必要な SAP カーネル バージョン。
- Azure NetApp Files のドキュメント。
- SAP Note 2015553は SAP でサポートされる Azure 上の SAP ソフトウェア デプロイの前提条件が記載されています。
- SAP Note 2002167: Red Hat Enterprise Linux 用の OS 設定が推奨されています。
- SAP Note 2009879: Red Hat Enterprise Linux 用の SAP HANA ガイドラインが記載されています。
- SAP Note 2178632: Azure 上の SAP について報告されるすべての監視メトリックに関する詳細情報が記載されています。
- SAP Note 2191498: Azure 上の Linux に必要な SAP Host Agent のバージョンが記載されています。
- SAP Note 2243692: Azure 上の Linux で動作する SAP のライセンスに関する情報が記載されています。
- SAP Note 1999351はAzure Enhanced モニタリング拡張機能 for SAP に関するその他のトラブルシューティング情報が記載されています。
- SAP Community WIKI: Linux に必要なすべての SAP Note を参照できます。
- Linux 上の SAP のための Azure Virtual Machines の計画と実装。
- Linux 上の SAP のための Azure Virtual Machines のデプロイ。
- Linux 上の SAP のための Azure Virtual Machines DBMS のデプロイ。
- Pacemaker クラスターでの SAP Netweaver。
- 一般的な RHEL ドキュメント:
- Azure 固有の RHEL ドキュメント:
- Azure NetApp Files を使用した Microsoft Azure 上の NetApp SAP アプリケーション
概要
クラスターに参加している仮想マシンは、フェールオーバーが発生したときのために、すべてのリソースを実行できるサイズになっている必要があります。 マルチ SID 高可用性クラスターでは、各 SAP SID は、相互に独立してフェールオーバーできます。
高可用性を実現するには、SAP NetWeaver に高可用性の共有が必要です。 このアーティクルでは、Azure NetApp Files の NFS ボリュームにデプロイされる SAP 共有の例を紹介します。 複数の SAP システムで使用できる高可用性の GlusterFS クラスターで共有をホストすることもできます。
重要
Azure VM でゲスト オペレーティング システムとして Red Hat Linux を使用する SAP ASCS/ERS のマルチ SID クラスタリングのサポートでは、同じクラスター上の SAP SID は 5 個に制限されています。 新しい SID が追加されるたびに、複雑さが増します。 SAP エンキュー レプリケーション サーバー 1 とエンキュー レプリケーション サーバー 2 を同じクラスター上に配置することは、サポートされていません。 マルチ SID クラスタリングとは、1 つの Pacemaker クラスター内での異なる SID を持つ複数の SAP ASCS/ERS インスタンスのインストールを指します。 現在、マルチ SID クラスタリングは ASCS/ERS に対してのみサポートされています。
ヒント
SAP ASCS/ERS のマルチ SID クラスタリングは、さらに複雑なソリューションです。 実装するのがいっそう複雑になります。 また、メンテナンス作業 (OS のファイルの部分置換など) を行うときの管理労力も増加します。 実際の実装を始める前に、デプロイと、VM、NFS マウント、VIP、ロード バランサーの構成などの関連するすべてのコンポーネントを、時間をかけて慎重に計画してください。
SAP NetWeaver ASCS、SAP NetWeaver SCS、SAP NetWeaver ERS では、仮想ホスト名と仮想 IP アドレスが使用されます。 Azure では、仮想 IP アドレスを使用するためにロード バランサーが必要になります。 Standard Load Balancer の使用をお勧めします。
- ASCS のフロントエンド IP アドレス: 10.3.1.50 (NW1)、10.3.1.52 (NW2)、10.3.1.54 (NW3)
- ERS のフロントエンド IP アドレス: 10.3.1.51 (NW1)、10.3.1.53 (NW2)、10.3.1.55 (NW3)
- NW1 ASCSのプローブ ポート 62000、NW2 ASCSの62010、NW3 ASCSの62020
- NW1 ASCSのプローブ ポート62102、 NW2 ASCSの62112、NW3 ASCSの62122
重要
フローティング IP は、負荷分散シナリオの NIC セカンダリ IP 構成ではサポートされていません。 詳細については、Azure Load Balancer の制限事項に関する記事を参照してください。 VM に追加の IP アドレスが必要な場合は、2 つ目の NIC をデプロイします。
注意
パブリック IP アドレスのない VM が、内部 (パブリック IP アドレスがない) Standard の Azure ロード バランサー のバックエンド プール内に配置されている場合、パブリック エンドポイントへのルーティングを許可するように追加の構成が実行されない限り、送信インターネット接続はありません。 送信接続を実現する方法の詳細については、「SAP の高可用性シナリオにおける Azure Standard Load Balancer を使用した Virtual Machines のパブリック エンドポイント接続」を参照してください。
重要
Azure Load Balancer の背後に配置された Azure VM では TCP タイムスタンプを有効にしないでください。 TCP タイムスタンプを有効にすると正常性プローブが失敗します。 パラメーターnet.ipv4.tcp_timestampsを0へセットします。 詳細については、「Load Balancer の正常性プローブ」を参照してください。
SAP 共有
SAP NetWeaver では、転送、プロファイル ディレクトリなどに対する共有ストレージが必要です。 高可用性の SAP システムの場合、高可用性の共有を使用することが重要です。 SAP 共有のアーキテクチャを決定する必要があります。 1 つの方法は、Azure NetApp Files NFS ボリュームに共有をデプロイすることです。 Azure NetApp Files には、SAP NFS 共有の高可用性が組み込まれています。
もう 1 つの方法は、Red Hat Enterprise Linux for SAP NetWeaver における Azure VM での GlusterFS を構築して、複数の SAP システム間で共有できるようにすることです。
最初の SAP システムをクラスターにデプロイする
SAP 共有のアーキテクチャを決定したので、次に、対応するドキュメントに従って、クラスターに最初の SAP システムをデプロイします。
- Azure NetApp Files NFS ボリュームを使用する場合は、SAP アプリケーション用の Azure NetApp Files を使用した Red Hat Enterprise Linux 上の SAP NetWeaver 用の Azure Virtual Machines の高可用性に従ってください。
- GlusterFS クラスターを使用する場合は、SAP NetWeaver用のRed Hat Enterprise Linux上の Azure VM での GlusterFSに従ってください。
このアーティクルには、必要なインフラストラクチャを準備する、クラスターをビルドする、SAP アプリケーションを実行するための OS を準備するステップが説明されています。
ヒント
最初のシステムをデプロイした後は、クラスターに別の SAP SID を追加する前に、クラスターのフェールオーバー機能を必ずテストします。 それにより、クラスターにSAP システムを追加して複雑さが増す前に、クラスターの機能が動作することがわかります。
クラスターに他の SAP システムをデプロイする
この例では、システム NW1 がクラスターに既にデプロイされているものとします。 この例では、クラスター内にSAP システム NW2 と NW3をデプロイする方法を示します。
以下の項目には、次のいずれかのプレフィックスが付いています:
- [A]すべてのノードに当てはまる
- [1]ノード 1 にのみ当てはまる
- [2] ノード 2 にのみ当てはまる
前提条件
重要
クラスタに追加の SAP システムをデプロイする手順に従う前に、クラスタの最初の SAP システムをデプロイします。 最初のシステム展開時にのみ必要なステップがあります。
この記事では、以下のことを前提としています。
- Pacemaker クラスターが既に構成され、実行されています。
- 少なくとも 1 つの SAP システム (ASCS/ERS インスタンス) が既にデプロイされており、クラスターで実行されています。
- クラスターのフェールオーバー機能のテストが完了しています。
- すべての SAP システムの NFS 共有がデプロイされています。
SAP NetWeaver のインストールを準備する
Azure portal 経由での手動による Azure Load Balancer のデプロイの手順に従って、新しくデプロイされたシステム (つまり、
NW2、NW3) の構成を、既存の Azure Load Balancer に追加します。 構成の IP アドレス、正常性プローブ ポート、負荷分散規則を調整します。[A] 追加の SAP システムの名前解決を設定します。 DNS サーバーを使用するか、すべてのノードの /etc/hosts を変更します。 この例では、/etc/hosts ファイルを使用する方法を示しています。 IP アドレスとホスト名を環境に合わせて調整します。
sudo vi /etc/hosts # IP address of the load balancer frontend configuration for NW2 ASCS 10.3.1.52 msnw2ascs # IP address of the load balancer frontend configuration for NW3 ASCS 10.3.1.54 msnw3ascs # IP address of the load balancer frontend configuration for NW2 ERS 10.3.1.53 msnw2ers # IP address of the load balancer frontend configuration for NW3 ERS 10.3.1.55 msnw3ers[A] クラスターにデプロイする
NW2とNW3SAP システム の共有ディレクトリを作成します。sudo mkdir -p /sapmnt/NW2 sudo mkdir -p /usr/sap/NW2/SYS sudo mkdir -p /usr/sap/NW2/ASCS10 sudo mkdir -p /usr/sap/NW2/ERS12 sudo mkdir -p /sapmnt/NW3 sudo mkdir -p /usr/sap/NW3/SYS sudo mkdir -p /usr/sap/NW3/ASCS20 sudo mkdir -p /usr/sap/NW3/ERS22 sudo chattr +i /sapmnt/NW2 sudo chattr +i /usr/sap/NW2/SYS sudo chattr +i /usr/sap/NW2/ASCS10 sudo chattr +i /usr/sap/NW2/ERS12 sudo chattr +i /sapmnt/NW3 sudo chattr +i /usr/sap/NW3/SYS sudo chattr +i /usr/sap/NW3/ASCS20 sudo chattr +i /usr/sap/NW3/ERS22[A] クラスターにデプロイする他のSAP システム用に /sapmnt/SID および /usr/sap/SID/SYS ファイル システムのマウント エントリを追加します。 この例では
NW2とNW3です。クラスターにデプロイする他のSAP システム用のファイル システムで、ファイル
/etc/fstabを更新します。- Azure NetApp Files を使用する場合は、Azure NetApp Files を使用した RHEL 上の SAP NW 用の Azure VM の高可用性に関する指示に従ってください。
- GlusterFS クラスターを使用する場合は、RHEL上 での SAP NW 用の Azure VM の高可用性に関する指示に従って下さい。
ASCS/ERS をインストールする
クラスターにデプロイする他のSAP システムの ASCS インスタンス用に、仮想 IP と正常性プローブのクラスター リソースを作成します。 以下の例は、NFSv3 プロトコルを使ってAzure NetApp Files ボリューム上の NFS を使用して、
NW2およびNW3ASCS を使用します。sudo pcs resource create fs_NW2_ASCS Filesystem device='10.42.0.4:/sapMSIDR/usrsapNW2ascs' \ directory='/usr/sap/NW2/ASCS10' fstype='nfs' force_unmount=safe \ op start interval=0 timeout=60 op stop interval=0 timeout=120 op monitor interval=200 timeout=40 \ --group g-NW2_ASCS sudo pcs resource create vip_NW2_ASCS IPaddr2 \ ip=10.3.1.52 \ --group g-NW2_ASCS sudo pcs resource create nc_NW2_ASCS azure-lb port=62010 \ --group g-NW2_ASCS sudo pcs resource create fs_NW3_ASCS Filesystem device='10.42.0.4:/sapMSIDR/usrsapNW3ascs' \ directory='/usr/sap/NW3/ASCS20' fstype='nfs' force_unmount=safe \ op start interval=0 timeout=60 op stop interval=0 timeout=120 op monitor interval=200 timeout=40 \ --group g-NW3_ASCS sudo pcs resource create vip_NW3_ASCS IPaddr2 \ ip=10.3.1.54 \ --group g-NW3_ASCS sudo pcs resource create nc_NW3_ASCS azure-lb port=62020 \ --group g-NW3_ASCSクラスターの状態が正常であることと、すべてのリソースが起動されていることを確認します。 リソースがどのノードで実行されているかは重要ではありません。
[1] SAP NetWeaver ASCS をインストールします。
root として SAP NetWeaver ASCS をインストールします。そのとき、ASCS に対するロード バランサー フロントエンド構成の IP アドレスに対応する仮想ホスト名を使用します。 たとえば、システム
NW2の場合、仮想ホスト名はmsnw2ascs、10.3.1.52、およびロード バランサーのプローブに使用したインスタンス番号 (たとえば10) になります。 システムNW3の場合、仮想ホスト名はmsnw3ascs、10.3.1.54、およびロード バランサーのプローブに使用したインスタンス番号 (たとえば20) になります。 SAP SID ごとに ASCS をインストールしたクラスター ノードを書き留めておきます。sapinstパラメーターSAPINST_REMOTE_ACCESS_USERパラメーターを使用すると、root 以外のユーザーが sapinst に接続することを許可できます。 仮想ホスト名を使用して SAP をインストールするには、パラメーターSAPINST_USE_HOSTNAMEを使用します。# Allow access to SWPM. This rule is not permanent. If you reboot the machine, you have to run the command again sudo firewall-cmd --zone=public --add-port=4237/tcp sudo swpm/sapinst SAPINST_REMOTE_ACCESS_USER=sapadmin SAPINST_USE_HOSTNAME=virtual_hostnameインストールで /usr/sap/<SID>/ASCS<Instance#>、へのサブフォルダーの作成が失敗する場合は、所有者を <sid>adm に設定し、グループを ASCS<Instance#>の sapsys に設定して、もう一度試してください。
[1] クラスターにデプロイする他の SAP システムの ERS インスタンス用に、仮想 IP と正常性プローブのクラスター リソースを作成します。 以下の例は、NFSv3 プロトコルを使用しているAzure NetApp Files ボリューム上の NFSを使っている、
NW2およびNW3ERS に対してです。sudo pcs resource create fs_NW2_AERS Filesystem device='10.42.0.4:/sapMSIDR/usrsapNW2ers' \ directory='/usr/sap/NW2/ERS12' fstype='nfs' force_unmount=safe \ op start interval=0 timeout=60 op stop interval=0 timeout=120 op monitor interval=200 timeout=40 \ --group g-NW2_AERS sudo pcs resource create vip_NW2_AERS IPaddr2 \ ip=10.3.1.53 \ --group g-NW2_AERS sudo pcs resource create nc_NW2_AERS azure-lb port=62112 \ --group g-NW2_AERS sudo pcs resource create fs_NW3_AERS Filesystem device='10.42.0.4:/sapMSIDR/usrsapNW3ers' \ directory='/usr/sap/NW3/ERS22' fstype='nfs' force_unmount=safe \ op start interval=0 timeout=60 op stop interval=0 timeout=120 op monitor interval=200 timeout=40 \ --group g-NW3_AERS sudo pcs resource create vip_NW3_AERS IPaddr2 \ ip=10.3.1.55 \ --group g-NW3_AERS sudo pcs resource create nc_NW3_AERS azure-lb port=62122 \ --group g-NW3_AERSクラスターの状態が正常であることと、すべてのリソースが起動されていることを確認します。
次に、新しく作成した ERS グループのリソースが、同じ SAP システムの ASCS インスタンスをインストールしたクラスター ノードとは逆のクラスター ノードで実行されていることを確認します。 たとえば、NW2 ASCS が
rhelmsscl1にインストールされている場合は、NW2 ERS グループがrhelmsscl2で実行されていることを確認します。 グループ内のいずれかのクラスター リソースに対して次のコマンドを実行して、NW2 ERS グループをrhelmsscl2に移行できます。pcs resource move fs_NW2_AERS rhelmsscl2[2] SAP NetWeaver ERS をインストールします。
root として SAP NetWeaver ERS を他のノードにインストールします。そのとき、ERS に対するロード バランサー フロントエンド構成の IP アドレスに対応する仮想ホスト名を使用します。 たとえば、システム
NW2の場合、仮想ホスト名はmsnw2ers、10.3.1.53、およびロード バランサーのプローブに使用したインスタンス番号 (たとえば12) になります。 システムNW3の場合、仮想ホスト名はmsnw3ers、10.3.1.55、およびロード バランサーのプローブに使用したインスタンス番号 (たとえば22) になります。sapinstパラメーターSAPINST_REMOTE_ACCESS_USERパラメーターを使用すると、root 以外のユーザーが sapinst に接続することを許可できます。 仮想ホスト名を使用して SAP をインストールするには、パラメーターSAPINST_USE_HOSTNAMEを使用します。# Allow access to SWPM. This rule is not permanent. If you reboot the machine, you have to run the command again sudo firewall-cmd --zone=public --add-port=4237/tcp sudo swpm/sapinst SAPINST_REMOTE_ACCESS_USER=sapadmin SAPINST_USE_HOSTNAME=virtual_hostnameNote
SWPM SP 20 PL 05 以降を使用します。 これより下位のバージョンではアクセス許可が正しく設定されないため、インストールが失敗します。
インストールで /usr/sap/<NW2>/ERS<Instance#>へのサブフォルダーの作成が失敗する場合は、所有者を <sid>adm に設定し、グループを ERS<Instance#>フォルダーの sapsys に設定して、もう一度試してください。
新しくデプロイした SAP システムの ERS グループを別のクラスター ノードに移行する必要があった場合は、ERS グループに対する場所の制約を忘れずに削除してください。 以下のコマンドを実行することで、制約を削除することができます。 この例は、SAP システム
NW2とNW3に示されます。 必ず、ERS クラスター グループを移動するコマンドで使用したのと同じリソースの一時的な制約を削除してください。pcs resource clear fs_NW2_AERS pcs resource clear fs_NW3_AERS[1] 新しくインストールした SAP システムの ASCS/SCS および ERS インスタンスのプロファイルを調整します。 次に
NW2の例を示します。 クラスターに追加したすべての SAP インスタンスの ASCS/SCS および ERS のプロファイルを調整する必要があります。ASCS/SCS プロファイル
sudo vi /sapmnt/NW2/profile/NW2_ASCS10_msnw2ascs # Change the restart command to a start command #Restart_Program_01 = local $(_EN) pf=$(_PF) Start_Program_01 = local $(_EN) pf=$(_PF) # Add the keep alive parameter, if using ENSA1 enque/encni/set_so_keepalive = trueENSA1 と ENSA2 の両方について、
keepaliveOS パラメーターが SAP ノートkeepaliveの説明に従って設定されていることを確認します。ERS プロファイル
sudo vi /sapmnt/NW2/profile/NW2_ERS12_msnw2ers # Change the restart command to a start command #Restart_Program_00 = local $(_ER) pf=$(_PFL) NR=$(SCSID) Start_Program_00 = local $(_ER) pf=$(_PFL) NR=$(SCSID) # remove Autostart from ERS profile # Autostart = 1
[A]/usr/sap/sapservices ファイルを更新します。
Sapinit スタートアップ企業スクリプトによってインスタンスが開始されるのを防ぐために、Pacemaker によって管理されているすべてのインスタンスを /usr/sap/sapservices ファイルからコメントをアウトする必要があります。 次に示す例は、SAP システム
NW2とNW3に対するものです。# Depending on whether the SAP Startup framework is integrated with systemd, you may observe below entries on the node for ASCS instances. You should comment out the line(s). # LD_LIBRARY_PATH=/usr/sap/NW2/ASCS10/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/NW2/ASCS10/exe/sapstartsrv pf=/usr/sap/NW2/SYS/profile/NW2_ASCS10_msnw2ascs -D -u nw2adm # LD_LIBRARY_PATH=/usr/sap/NW3/ASCS20/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/NW3/ASCS20/exe/sapstartsrv pf=/usr/sap/NW3/SYS/profile/NW3_ASCS20_msnw3ascs -D -u nw3adm # systemctl --no-ask-password start SAPNW2_10 # sapstartsrv pf=/usr/sap/NW2/SYS/profile/NW2_ASCS10_msnw2ascs # systemctl --no-ask-password start SAPNW3_20 # sapstartsrv pf=/usr/sap/NW3/SYS/profile/NW3_ASCS20_msnw3ascs # Depending on whether the SAP Startup framework is integrated with systemd, you may observe below entries on the node for ERS instances. You should comment out the line(s). #LD_LIBRARY_PATH=/usr/sap/NW2/ERS12/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/NW2/ERS12/exe/sapstartsrv pf=/usr/sap/NW2/ERS12/profile/NW2_ERS12_msnw2ers -D -u nw2adm #LD_LIBRARY_PATH=/usr/sap/NW3/ERS22/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/NW3/ERS22/exe/sapstartsrv pf=/usr/sap/NW3/ERS22/profile/NW3_ERS22_msnw3ers -D -u nw3adm # systemctl --no-ask-password start SAPNW2_12 # sapstartsrv pf=/usr/sap/NW2/ERS12/profile/NW2_ERS12_msnw2ers # systemctl --no-ask-password start SAPNW3_22 # sapstartsrv pf=/usr/sap/NW3/ERS22/profile/NW3_ERS22_msnw3ers重要
systemd ベースの SAP スタートアップ フレームワークにより、SAP インスタンスを systemd で管理できるようになりました。 必要な Red Hat Enterprise Linux (RHEL) の最小バージョンは RHEL 8 for SAP です。 SAP ノート 3115048 で説明されているように、systemd ベースの SAP スタートアップ フレームワークが統合された SAP カーネルを新しくインストールすると、常に systemd 制御の SAP インスタンスが生成されます。 ただし、既存の SAP インストールの SAP カーネルを systemd ベースの SAPスタートアップ フレーム サポートが含まれるカーネルにアップグレードした後に、SAP ノート 3115048 に記載されているように、いくつかの手動手順を実行して、既存の SAP スタートアップ環境を systemd 制御の環境に変換する必要があります。
SAP 向け RED Hat HA サービス (クラスター構成) を使用して SAP ASCS や SAP ERS などの SAP アプリケーション サーバー インスタンスを管理する場合は、SAPInstance リソース エージェントと新しい systemd ベースの SAP スタートアップ フレームワークとの間の互換性を確保するために、追加の変更が必要になります。 そのため、SAP ノート 3115048 に従って SAP アプリケーション サーバー インスタンスがインストールされたか、systemd 対応 SAP カーネルに切り替えられたら、Red Hat KBA 6884531 に記載されている手順を、すべてのクラスター ノードで正常に完了する必要があります。
[1] 新しくインストールした SAP システム用の SAP クラスター リソースを作成します。
ENSA1 システムと ENSA2 システムのどちらを実行しているかに応じて、それぞれのタブを選択して SAP システム
NW2のリソースを定義し、NW3次のように定義します。 SAP では、SAP NetWeaver 7.52 で、レプリケーションを含む ENSA2 のサポートを導入しました。 ABAP Platform 1809 以降では、ENSA2 が既定でインストールされます。 ENSA2 のサポートについては、エンキュー サーバー 2 のサポートに関する SAP Note 2630416 を参照してください。エンキュー サーバー 2 アーキテクチャ (ENSA2) を使用する場合は、resource agent resource-agents-sap-4.1.1-12.el7.x86_64 以降をインストールし、SAP システム
NW2NW3のリソースを定義します。次のようにします。sudo pcs property set maintenance-mode=true sudo pcs resource create rsc_sap_NW2_ASCS10 SAPInstance \ InstanceName=NW2_ASCS10_msnw2ascs START_PROFILE="/sapmnt/NW2/profile/NW2_ASCS10_msnw2ascs" \ AUTOMATIC_RECOVER=false \ meta resource-stickiness=5000 migration-threshold=1 failure-timeout=60 \ op monitor interval=20 on-fail=restart timeout=60 \ op start interval=0 timeout=600 op stop interval=0 timeout=600 \ --group g-NW2_ASCS sudo pcs resource meta g-NW2_ASCS resource-stickiness=3000 sudo pcs resource create rsc_sap_NW2_ERS12 SAPInstance \ InstanceName=NW2_ERS12_msnw2ers START_PROFILE="/sapmnt/NW2/profile/NW2_ERS12_msnw2ers" \ AUTOMATIC_RECOVER=false IS_ERS=true \ op monitor interval=20 on-fail=restart timeout=60 op start interval=0 timeout=600 op stop interval=0 timeout=600 \ --group g-NW2_AERS sudo pcs constraint colocation add g-NW2_AERS with g-NW2_ASCS -5000 sudo pcs constraint location rsc_sap_NW2_ASCS10 rule score=2000 runs_ers_NW2 eq 1 sudo pcs constraint order start g-NW2_ASCS then stop g-NW2_AERS kind=Optional symmetrical=false sudo pcs resource create rsc_sap_NW3_ASCS20 SAPInstance \ InstanceName=NW3_ASCS20_msnw3ascs START_PROFILE="/sapmnt/NW3/profile/NW3_ASCS20_msnw3ascs" \ AUTOMATIC_RECOVER=false \ meta resource-stickiness=5000 migration-threshold=1 failure-timeout=60 \ op monitor interval=20 on-fail=restart timeout=60 \ op start interval=0 timeout=600 op stop interval=0 timeout=600 \ --group g-NW3_ASCS sudo pcs resource meta g-NW3_ASCS resource-stickiness=3000 sudo pcs resource create rsc_sap_NW3_ERS22 SAPInstance \ InstanceName=NW3_ERS22_msnw3ers START_PROFILE="/sapmnt/NW3/profile/NW2_ERS22_msnw3ers" \ AUTOMATIC_RECOVER=false IS_ERS=true \ op monitor interval=20 on-fail=restart timeout=60 op start interval=0 timeout=600 op stop interval=0 timeout=600 \ --group g-NW3_AERS sudo pcs constraint colocation add g-NW3_AERS with g-NW3_ASCS -5000 sudo pcs constraint location rsc_sap_NW3_ASCS20 rule score=2000 runs_ers_NW3 eq 1 sudo pcs constraint order start g-NW3_ASCS then stop g-NW3_AERS kind=Optional symmetrical=false sudo pcs property set maintenance-mode=false以前のバージョンからアップグレードし、エンキューする サーバー 2 に切り替えている場合は、SAP Note 2641019 を参照してください。
注意
上記のタイムアウト構成はほんの一例であり、特定の SAP 設定では調整する必要がある場合があります。
クラスターの状態が正常であることと、すべてのリソースが起動されていることを確認します。 リソースがどのノードで実行されているかは重要ではありません。 次の例では、SAP システム
NW2とNW3をクラスターに追加した後の、クラスター リソースの状態を示します。sudo pcs status # Online: [ rhelmsscl1 rhelmsscl2 ] # Full list of resources: # rsc_st_azure (stonith:fence_azure_arm): Started rhelmsscl1 # Resource Group: g-NW1_ASCS # fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 # vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 # nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 # rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 # Resource Group: g-NW1_AERS # fs_NW1_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl2 # vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 # nc_NW1_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl2 # rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 # Resource Group: g-NW2_ASCS # fs_NW2_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 # vip_NW2_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 # nc_NW2_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 # rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 # Resource Group: g-NW2_AERS # fs_NW2_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 # vip_NW2_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 # nc_NW2_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 # rsc_sap_NW2_ERS12 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 # Resource Group: g-NW3_ASCS # fs_NW3_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 # vip_NW3_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 # nc_NW3_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 # rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 # Resource Group: g-NW3_AERS # fs_NW3_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 # vip_NW3_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 # nc_NW3_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 # rsc_sap_NW3_ERS22 (ocf::heartbeat:SAPInstance): Started rhelmsscl1[A] ASCS および ERS に対するファイアウォール規則を両方のノード上に追加します。 次の例は、SAP システム
NW2とNW3の両方に対するファイアウォール規則を示しています。# NW1 - ASCS sudo firewall-cmd --zone=public --add-port={62010,3210,3610,3910,8110,51013,51014,51016}/tcp --permanent sudo firewall-cmd --zone=public --add-port={62010,3210,3610,3910,8110,51013,51014,51016}/tcp # NW2 - ERS sudo firewall-cmd --zone=public --add-port={62112,3212,3312,51213,51214,51216}/tcp --permanent sudo firewall-cmd --zone=public --add-port={62112,3212,3312,51213,51214,51216}/tcp # NW3 - ASCS sudo firewall-cmd --zone=public --add-port={62020,3220,3620,3920,8120,52013,52014,52016}/tcp --permanent sudo firewall-cmd --zone=public --add-port={62020,3220,3620,3920,8120,52013,52014,52016}/tcp # NW3 - ERS sudo firewall-cmd --zone=public --add-port={62122,3222,3322,52213,52214,52216}/tcp --permanent sudo firewall-cmd --zone=public --add-port={62122,3222,3322,52213,52214,52216}/tcp
SAP のインストールを続ける
次のようにして、SAP のインストールを完了します。
- SAP NetWeaver アプリケーションサーバーを準備します。
- DBMS インスタンスをインストールします。
- Aプライマリ SAP アプリケーション サーバーをインストールします。
- 1 つまたは複数のSAP アプリケーション インスタンスをインストールします。
マルチ SID クラスターのセットアップをテストする
次のテストは、Red Hat のベスト プラクティス ガイドに記載されているテスト ケースのサブセットです。 作業を容易にするためにここに含めてあります。 クラスター テストの完全な一覧については、次のドキュメントを参照してください。
- Azure NetApp Files NFS ボリュームを使用する場合は、SAP アプリケーション用の Azure NetApp Files を使用した Red Hat Enterprise Linux 上の SAP NetWeaver 用の Azure Virtual Machines の高可用性に従ってください
- 高可用性の
GlusterFSを使用する場合は、 SAP aアプリケーション用のRed Hat Enterprise Linux での SAP NetWeaver のための Azure Virtual Machines 高可用性に従ってください。
常に Red Hat のベスト プラクティス ガイドを読み、追加されている可能性があるすべての追加テストを実行してください。 示されているテストは、3 つの SAP システムがインストールされた、2 ノードのマルチ SID クラスターでのものです。
ASCS インスタンスを手動で移行します。 この例では、SAP システム NW3 の ASCS インスタンスの移行を示します。
テスト開始前のリソースの状態:
Online: [ rhelmsscl1 rhelmsscl2 ] Full list of resources: rsc_st_azure (stonith:fence_azure_arm): Started rhelmsscl1 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW2_ASCS fs_NW2_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW2_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW2_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW2_AERS fs_NW2_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW2_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW2_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW2_ERS12 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW3_ASCS fs_NW3_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW3_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW3_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW3_AERS fs_NW3_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW3_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW3_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW3_ERS22 (ocf::heartbeat:SAPInstance): Started rhelmsscl1次のコマンドを root として実行して、NW3 ASCS インスタンスを移行します。
pcs resource move rsc_sap_NW3_ASCS200 # Clear temporary migration constraints pcs resource clear rsc_sap_NW3_ASCS20 # Remove failed actions for the ERS that occurred as part of the migration pcs resource cleanup rsc_sap_NW3_ERS22テスト後のリソースの状態:
Online: [ rhelmsscl1 rhelmsscl2 ] Full list of resources: rsc_st_azure (stonith:fence_azure_arm): Started rhelmsscl1 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW2_ASCS fs_NW2_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW2_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW2_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW2_AERS fs_NW2_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW2_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW2_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW2_ERS12 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW3_ASCS fs_NW3_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW3_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW3_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW3_AERS fs_NW3_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW3_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW3_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW3_ERS22 (ocf::heartbeat:SAPInstance): Started rhelmsscl2ノードのクラッシュをシミュレートする。
テスト開始前のリソースの状態:
Online: [ rhelmsscl1 rhelmsscl2 ] Full list of resources: rsc_st_azure (stonith:fence_azure_arm): Started rhelmsscl1 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW2_ASCS fs_NW2_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW2_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW2_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW2_AERS fs_NW2_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW2_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW2_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW2_ERS12 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW3_ASCS fs_NW3_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW3_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW3_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW3_AERS fs_NW3_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW3_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW3_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW3_ERS22 (ocf::heartbeat:SAPInstance): Started rhelmsscl2少なくとも 1 つの ASCS インスタンスが実行されているノードで、次のコマンドを root として実行します。 この例では、
NW1、NW2、NW3のASCS インスタンスが動作している場所のrhelmsscl1でコマンドを実行します。echo c > /proc/sysrq-triggerテストの後、クラッシュしたノードが再び開始された後の状態は、次のような結果になります:
Full list of resources: rsc_st_azure (stonith:fence_azure_arm): Started rhelmsscl2 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW2_ASCS fs_NW2_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW2_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW2_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW2_AERS fs_NW2_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW2_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW2_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW2_ERS12 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW3_ASCS fs_NW3_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW3_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW3_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW3_AERS fs_NW3_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW3_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW3_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW3_ERS22 (ocf::heartbeat:SAPInstance): Started rhelmsscl1失敗したリソースに関するメッセージがある場合は、失敗したリソースの状態をクリーンアップします。 次に例を示します。
pcs resource cleanup rsc_sap_NW1_ERS02
次のステップ
- SAP のための Azure Virtual Machines の計画と実装
- SAP のための Azure Virtual Machines のデプロイ
- SAP のための Azure Virtual Machines DBMS のデプロイ
Azure VM 上の SAP HANA の高可用性を確保し、ディザスター リカバリーを計画する方法を確認するには、「Azure Virtual Machines (VM) 上の SAP HANA の高可用性」を参照してください。