Red Hat Enterprise Linux での SAP NetWeaver のための Azure Virtual Machines 高可用性
この記事では、仮想マシン (VM) のデプロイ、VM の構成、クラスター フレームワークのインストール、高可用性 SAP NetWeaver 7.50 システムのインストールの方法について説明します。
構成およびインストール コマンドの例では、ASCS インスタンス番号 00、ERS インスタンス番号 02、SAP システム ID NW1 が使用されています。 この例のリソース (VM、仮想ネットワークなど) の名前は、リソース プレフィックス NW1 で ASCS/SCS テンプレートを使用してリソースを作成していることを想定しています。
前提条件
はじめに、次の SAP Note およびガイドを確認してください
- SAP Note 1928533: 次の情報が含まれています。
- SAP ソフトウェアのデプロイでサポートされる Azure VM サイズの一覧。
- Azure VM サイズの容量に関する重要な情報。
- サポートされる SAP ソフトウェア、オペレーティング システム (OS) とデータベースの組み合わせ。
- Microsoft Azure 上の Windows と Linux に必要な SAP カーネル バージョン。
- SAP Note 2015553: SAP でサポートされる Azure 上の SAP ソフトウェア デプロイの前提条件が記載されています。
- SAP Note 2002167 には、Red Hat Enterprise Linux (RHEL) 用の推奨 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 のデプロイ
- Red Hat Gluster Storage 用の製品ドキュメント
- Pacemaker クラスターでの SAP NetWeaver
- 一般的な RHEL ドキュメント:
- Azure 固有の RHEL ドキュメント:
概要
高可用性を実現するため、SAP NetWeaver には共有ストレージが必要です。 GlusterFS は別のクラスターで構成されており、複数の SAP システムでそれを使用できます。
SAP NetWeaver ASCS、SAP NetWeaver SCS、SAP NetWeaver ERS、SAP HANA データベースでは、仮想ホスト名と仮想 IP アドレスが使用されます。 Azure 上で仮想 IP アドレスを使用するには、ロード バランサーが必要です。 Standard Azure Load Balancer を使用することをおすすめします。 次の構成は、次のものを含むロード バランサーを示しています。
- ASCS のフロントエンド IP アドレス 10.0.0.7
- ERS のフロントエンド IP アドレス 10.0.0.8
- ASCS のプローブ ポート 62000
- ERS のプローブ ポート 62101
GlusterFS の設定
SAP NetWeaver では、転送とプロファイル ディレクトリ用の共有ストレージが必要です。 GlusterFS for SAP NetWeaver を設定する方法については、「Red Hat Enterprise Linux for SAP NetWeaver における Azure VM での GlusterFS」を参照してください。
インフラストラクチャの準備
Azure Marketplace には、高可用性アドオンを備えた SAP に適したイメージが含まれています。これは、さまざまなバージョンの Red Hat を使用して新しい VM をデプロイするために使用できます。
Azure portal 経由での手動による Linux VM のデプロイ
このドキュメントは、Azure 仮想ネットワーク、サブネット、リソース グループが既にデプロイ済みであることを前提としています。
SAP ASCS、ERS、アプリケーション サーバー用の VM をデプロイします。 SAP システムでサポートされている適切な RHEL イメージを選択します。 VM は、仮想マシン スケール セット、可用性ゾーン、可用性セットのいずれかの可用性オプションでデプロイできます。
Azure Load Balancer の構成
VM 構成中に、ネットワーク セクションでロード バランサーを作成するか既存のものを選択する選択肢もあります。 以下の手順に従って、SAP ASCS と SAP ERS の高可用性セットアップ用に標準ロード バランサーを構成します。
「ロード バランサーの作成」のガイドに従い、Azure portal を使って高可用性 SAP システム用に Standard ロード バランサーを設定します。 ロード バランサーの設定においては、以下の点を考慮してください。
- フロントエンド IP 構成: 2 つのフロントエンド IP を作成します。1 つは ASCS 用、もう 1 つは ERS 用です。 ASCS/ERS 仮想マシンと同じ仮想ネットワークとサブネットを選択します。
- バックエンド プール: バックエンド プールを作成し、ASCS および ERS VM を追加します。
- 受信規則: 2 つの負荷分散規則を作成します。1 つは ASCS 用、もう 1 つは ERS 用です。 両方の負荷分散規則に対して同じ手順を実行します。
- フロントエンド IP アドレス: フロントエンド IP を選択します
- バックエンド プール: バックエンド プールを選択します
- [High availability ports] (高可用性ポート) をオンにします
- プロトコル: TCP
- 正常性プローブ: 以下の詳細を使用して正常性プローブを作成します (ASCS と ERS の両方に適用されます)
- プロトコル: TCP
- ポート: [例: ASCS に対しては 620<Instance-no.>、ERS に対しては 621<Instance-no.>]
- 間隔: 5
- プローブしきい値: 2
- アイドル タイムアウト (分): 30
- [Floating IP を有効にする] をオンにします
Note
正常性プローブ構成プロパティ numberOfProbes (ポータルでは [異常のしきい値] と呼ばれます) が順守されていません。 このため、成功または失敗した連続プローブの数を制御するには、プロパティ "probeThreshold" を 2 に設定します。 現在、このプロパティは Azure portal を使用して設定できないため、Azure CLI または PowerShell コマンドを使用してください。
Note
パブリック IP アドレスのない VM が、内部の (パブリック IP アドレスのない) Standard Azure Load Balancer のバックエンド プール内に配置されている場合、パブリック エンドポイントへのルーティングを許可するように追加の構成が実行されない限り、送信インターネット接続はありません。 送信接続を実現する方法の詳細については、「SAP の高可用性シナリオにおける Azure Standard Load Balancer を使用した VM のパブリック エンドポイント接続」を参照してください。
重要
Azure Load Balancer の背後に配置された Azure VM では TCP タイムスタンプを有効にしないでください。 TCP タイムスタンプを有効にすると正常性プローブが失敗します。 パラメーター net.ipv4.tcp_timestamps
を 0
に設定します。 詳細については、「Load Balancer の正常性プローブ」を参照してください。
(A)SCS を設定する
次に、SAP ASCS と ERS のインスタンスを準備してインストールします。
Pacemaker クラスターの作成
「Azure で Red Hat Enterprise Linux に Pacemaker を設定する」の手順に従って、この (A)SCS サーバーに対して基本的な Pacemaker クラスターを作成します。
SAP NetWeaver のインストールを準備する
以下の項目には、次のいずれかのプレフィックスが付いています:
- [A] :すべてのノードに適用できます
- [1]: ノード 1 にのみ当てはまる
- [2]: ノード 2 にのみ当てはまる
[A] ホスト名解決を設定します。
DNS サーバーを使用するか、すべてのノードの
/etc/hosts
ファイルを変更することができます。 この例では、/etc/hosts
ファイルを使用する方法を示します。 次のコマンドの IP アドレスとホスト名を置き換えます。sudo vi /etc/hosts
/etc/hosts
ファイルに次の行を挿入します。 お使いの環境に合わせて IP アドレスとホスト名を変更します。# IP addresses of the GlusterFS nodes 10.0.0.40 glust-0 10.0.0.41 glust-1 10.0.0.42 glust-2 # IP address of the load balancer frontend configuration for SAP NetWeaver ASCS 10.0.0.7 nw1-ascs # IP address of the load balancer frontend configuration for SAP NetWeaver ASCS ERS 10.0.0.8 nw1-aers
[A] 共有ディレクトリを作成します。
sudo mkdir -p /sapmnt/NW1 sudo mkdir -p /usr/sap/trans sudo mkdir -p /usr/sap/NW1/SYS sudo mkdir -p /usr/sap/NW1/ASCS00 sudo mkdir -p /usr/sap/NW1/ERS02 sudo chattr +i /sapmnt/NW1 sudo chattr +i /usr/sap/trans sudo chattr +i /usr/sap/NW1/SYS sudo chattr +i /usr/sap/NW1/ASCS00 sudo chattr +i /usr/sap/NW1/ERS02
[A] GlusterFS クライアントとその他の必要なパッケージをインストールします。
sudo yum -y install glusterfs-fuse resource-agents resource-agents-sap
[A]
resource-agents-sap
のバージョンを確認します。インストールされている
resource-agents-sap
パッケージのバージョンが、3.9.5-124.el7 以上であることを確認します。sudo yum info resource-agents-sap # Loaded plugins: langpacks, product-id, search-disabled-repos # Repodata is over 2 weeks old. Install yum-cron? Or run: yum makecache fast # Installed Packages # Name : resource-agents-sap # Arch : x86_64 # Version : 3.9.5 # Release : 124.el7 # Size : 100 k # Repo : installed # From repo : rhel-sap-for-rhel-7-server-rpms # Summary : SAP cluster resource agents and connector script # URL : https://github.com/ClusterLabs/resource-agents # License : GPLv2+ # Description : The SAP resource agents and connector script interface with # : Pacemaker to allow SAP instances to be managed in a cluster # : environment.
[A] マウント エントリを追加します。
sudo vi /etc/fstab # Add the following lines to fstab, save and exit glust-0:/NW1-sapmnt /sapmnt/NW1 glusterfs backup-volfile-servers=glust-1:glust-2 0 0 glust-0:/NW1-trans /usr/sap/trans glusterfs backup-volfile-servers=glust-1:glust-2 0 0 glust-0:/NW1-sys /usr/sap/NW1/SYS glusterfs backup-volfile-servers=glust-1:glust-2 0 0
新しい共有をマウントします。
sudo mount -a
[A] スワップ ファイルを構成します。
sudo vi /etc/waagent.conf # Set the property ResourceDisk.EnableSwap to y # Create and use swapfile on resource disk. ResourceDisk.EnableSwap=y # Set the size of the SWAP file with property ResourceDisk.SwapSizeMB # The free space of resource disk varies by virtual machine size. Make sure that you do not set a value that is too big. You can check the SWAP space with command swapon # Size of the swapfile. ResourceDisk.SwapSizeMB=2000
エージェントを再起動して変更をアクティブにします。
sudo service waagent restart
[A] RHEL を構成します。
RHEL バージョンに基づいて、SAP Note 2002167、SAP Note 2772999、または SAP Note 3108316 に記載されている構成を実行します。
SAP NetWeaver ASCS をインストールする
[1] クラスターの既定のプロパティを構成します。
pcs resource defaults resource-stickiness=1 pcs resource defaults migration-threshold=3
[1] ASCS インスタンス用の仮想 IP リソースと正常性プローブを作成します。
sudo pcs node standby nw1-cl-1 sudo pcs resource create fs_NW1_ASCS Filesystem device='glust-0:/NW1-ascs' \ directory='/usr/sap/NW1/ASCS00' fstype='glusterfs' \ options='backup-volfile-servers=glust-1:glust-2' \ --group g-NW1_ASCS sudo pcs resource create vip_NW1_ASCS IPaddr2 \ ip=10.0.0.7 \ --group g-NW1_ASCS sudo pcs resource create nc_NW1_ASCS azure-lb port=62000 \ --group g-NW1_ASCS
クラスターの状態が正常であることと、すべてのリソースが起動されていることを確認します。 リソースがどのノードで実行されているかは重要ではありません。
sudo pcs status # Node nw1-cl-1: standby # Online: [ nw1-cl-0 ] # # Full list of resources: # # rsc_st_azure (stonith:fence_azure_arm): Started nw1-cl-0 # Resource Group: g-NW1_ASCS # fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started nw1-cl-0 # nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started nw1-cl-0 # vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started nw1-cl-0
[1] SAP NetWeaver ASCS をインストールします。
root として SAP NetWeaver ASCS を最初のノードにインストールします。その際、ASCS のロード バランサー フロントエンド構成の IP アドレスに対応する仮想ホスト名 (nw1-ascs と 10.0.0.7 など) と、ロード バランサーのプローブに使用したインスタンス番号 (00 など) を使用します。
sapinst
のパラメーターSAPINST_REMOTE_ACCESS_USER
を使用すると、ルート以外のユーザーがsapinst
に接続することを許可できます。# 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
インストールで /usr/sap/NW1/ASCS00 へのサブフォルダーの作成に失敗する場合は、ASCS 00 フォルダーの所有者とグループを設定し、もう一度試してください。
sudo chown nw1adm /usr/sap/NW1/ASCS00 sudo chgrp sapsys /usr/sap/NW1/ASCS00
[1] ERS インスタンス用の仮想 IP リソースと正常性プローブを作成します。
sudo pcs node unstandby nw1-cl-1 sudo pcs node standby nw1-cl-0 sudo pcs resource create fs_NW1_AERS Filesystem device='glust-0:/NW1-aers' \ directory='/usr/sap/NW1/ERS02' fstype='glusterfs' \ options='backup-volfile-servers=glust-1:glust-2' \ --group g-NW1_AERS sudo pcs resource create vip_NW1_AERS IPaddr2 \ ip=10.0.0.8 \ --group g-NW1_AERS sudo pcs resource create nc_NW1_AERS azure-lb port=62102 \ --group g-NW1_AERS
クラスターの状態が正常であることと、すべてのリソースが起動されていることを確認します。 リソースがどのノードで実行されているかは重要ではありません。
sudo pcs status # Node nw1-cl-0: standby # Online: [ nw1-cl-1 ] # # Full list of resources: # # rsc_st_azure (stonith:fence_azure_arm): Started nw1-cl-1 # Resource Group: g-NW1_ASCS # fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started nw1-cl-1 # nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started nw1-cl-1 # vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started nw1-cl-1 # Resource Group: g-NW1_AERS # fs_NW1_AERS (ocf::heartbeat:Filesystem): Started nw1-cl-1 # nc_NW1_AERS (ocf::heartbeat:azure-lb): Started nw1-cl-1 # vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started nw1-cl-1
[2] SAP NetWeaver ERS をインストールします。
root として SAP NetWeaver ERS を 2 番目のノードにインストールします。その際、ERS のロード バランサー フロントエンド構成の IP アドレスに対応する仮想ホスト名 (たとえば、nw1-aers、10.0.0.8) と、ロード バランサーのプローブに使用したインスタンス番号 (たとえば、02) を使用します。
sapinst
のパラメーターSAPINST_REMOTE_ACCESS_USER
を使用すると、ルート以外のユーザーがsapinst
に接続することを許可できます。# 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
インストールで /usr/sap/NW1/ERS02 へのサブフォルダーの作成に失敗する場合は、ERS 02 フォルダーの所有者とグループを設定し、もう一度試してください。
sudo chown nw1adm /usr/sap/NW1/ERS02 sudo chgrp sapsys /usr/sap/NW1/ERS02
[1] ASCS/SCS および ERS のインスタンス プロファイルを適用します。
ASCS/SCS プロファイル。
sudo vi /sapmnt/NW1/profile/NW1_ASCS00_nw1-ascs # 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 = TRUE
ENSA1 と ENSA2 の両方について、
keepalive
OS パラメーターが SAP Note 1410736 の説明に従って設定されていることを確認します。ERS プロファイル。
sudo vi /sapmnt/NW1/profile/NW1_ERS02_nw1-aers # 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] キープ アライブを構成します。
SAP NetWeaver アプリケーション サーバーと ASCS/SCS の間の通信は、ソフトウェア ロード バランサーを介してルーティングされます。 ロード バランサーは、構成可能なタイムアウト後に非アクティブな接続を切断します。 このアクションを回避するには、SAP NetWeaver ASCS/SCS プロファイルにパラメーターを設定します (ENSA1 を使用する場合)。 ENSA1 と ENSA2 の両方について、すべての SAP サーバーの Linux システムの
keepalive
設定を変更します。 詳細については、SAP Note 1410736 をご覧ください。# Change the Linux system configuration sudo sysctl net.ipv4.tcp_keepalive_time=300
[A]
/usr/sap/sapservices
ファイルを更新します。sapinit
スタートアップ スクリプトによってインスタンスが開始されないようにするには、Pacemaker によって管理されているすべてのインスタンスを/usr/sap/sapservices
ファイルからコメント アウトする必要があります。sudo vi /usr/sap/sapservices # On the node where you installed the ASCS, comment out the following line # LD_LIBRARY_PATH=/usr/sap/NW1/ASCS00/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/NW1/ASCS00/exe/sapstartsrv pf=/usr/sap/NW1/SYS/profile/NW1_ASCS00_nw1-ascs -D -u nw1adm # On the node where you installed the ERS, comment out the following line # LD_LIBRARY_PATH=/usr/sap/NW1/ERS02/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/NW1/ERS02/exe/sapstartsrv pf=/usr/sap/NW1/ERS02/profile/NW1_ERS02_nw1-aers -D -u nw1adm
[1] SAP クラスター リソースを作成します。
ENSA1 システムと ENSA2 システムのどちらを実行しているかに応じて、それぞれのタブを選択してリソースを定義します。 SAP では、SAP NetWeaver 7.52 で、レプリケーションを含む ENSA2 のサポートを導入しました。 ABAP Platform 1809 以降では、ENSA2 が既定でインストールされます。 ENSA2 のサポートについては、エンキュー サーバー 2 のサポートに関する SAP Note 2630416 を参照してください。
エンキュー サーバー 2 アーキテクチャ (ENSA2) を使用する場合は、resource-agents-sap-4.1.1-12.el7.x86_64 以降のリソース エージェントをインストールし、リソースを次に示すように定義します。
sudo pcs property set maintenance-mode=true sudo pcs resource create rsc_sap_NW1_ASCS00 SAPInstance \ InstanceName=NW1_ASCS00_nw1-ascs START_PROFILE="/sapmnt/NW1/profile/NW1_ASCS00_nw1-ascs" \ 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-NW1_ASCS sudo pcs resource meta g-NW1_ASCS resource-stickiness=3000 sudo pcs resource create rsc_sap_NW1_ERS02 SAPInstance \ InstanceName=NW1_ERS02_nw1-aers START_PROFILE="/sapmnt/NW1/profile/NW1_ERS02_nw1-aers" \ 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-NW1_AERS sudo pcs constraint colocation add g-NW1_AERS with g-NW1_ASCS -5000 sudo pcs constraint location rsc_sap_NW1_ASCS00 rule score=2000 runs_ers_NW1 eq 1 sudo pcs constraint order start g-NW1_ASCS then stop g-NW1_AERS kind=Optional symmetrical=false sudo pcs node unstandby nw1-cl-0 sudo pcs property set maintenance-mode=false
Note
以前のバージョンからアップグレードし、エンキュー サーバー 2 に切り替えている場合は、SAP Note 2641322 を参照してください。
Note
前の構成のタイムアウトは例にすぎないため、特定の SAP セットアップに適合させる必要がある場合があります。
クラスターの状態が正常であることと、すべてのリソースが起動されていることを確認します。 リソースがどのノードで実行されているかは重要ではありません。
sudo pcs status # Online: [ nw1-cl-0 nw1-cl-1 ] # # Full list of resources: # # rsc_st_azure (stonith:fence_azure_arm): Started nw1-cl-0 # Resource Group: g-NW1_ASCS # fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started nw1-cl-1 # nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started nw1-cl-1 # vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started nw1-cl-1 # rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started nw1-cl-1 # Resource Group: g-NW1_AERS # fs_NW1_AERS (ocf::heartbeat:Filesystem): Started nw1-cl-0 # nc_NW1_AERS (ocf::heartbeat:azure-lb): Started nw1-cl-0 # vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started nw1-cl-0 # rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started nw1-cl-0
[A] ASCS および ERS に対するファイアウォール規則を両方のノード上に追加します。
# Probe Port of ASCS sudo firewall-cmd --zone=public --add-port={62000,3200,3600,3900,8100,50013,50014,50016}/tcp --permanent sudo firewall-cmd --zone=public --add-port={62000,3200,3600,3900,8100,50013,50014,50016}/tcp # Probe Port of ERS sudo firewall-cmd --zone=public --add-port={62102,3202,3302,50213,50214,50216}/tcp --permanent sudo firewall-cmd --zone=public --add-port={62102,3202,3302,50213,50214,50216}/tcp
SAP NetWeaver アプリケーション サーバーの準備
一部のデータベースでは、データベース インスタンスのインストールがアプリケーション サーバーで実行される必要があります。 このような場合に使用できるようにアプリケーション サーバー VM を準備します。
次の手順では、ASCS/SCS および HANA サーバーとは別のサーバーにアプリケーション サーバーをインストールすることを前提としています。 そうでない場合、手順の一部 (ホスト名解決の構成など) は必要ありません。
ホスト名解決を設定します。
DNS サーバーを使用するか、すべてのノードの
/etc/hosts
ファイルを変更することができます。 この例では、/etc/hosts
ファイルを使用する方法を示します。 次のコマンドの IP アドレスとホスト名を置き換えます。sudo vi /etc/hosts
/etc/hosts
に次の行を挿入します。 お使いの環境に合わせて IP アドレスとホスト名を変更します。# IP addresses of the GlusterFS nodes 10.0.0.40 glust-0 10.0.0.41 glust-1 10.0.0.42 glust-2 # IP address of the load balancer frontend configuration for SAP NetWeaver ASCS 10.0.0.7 nw1-ascs # IP address of the load balancer frontend configuration for SAP NetWeaver ASCS ERS 10.0.0.8 nw1-aers # IP address of the load balancer frontend configuration for database 10.0.0.13 nw1-db
sapmnt
ディレクトリを作成します。sudo mkdir -p /sapmnt/NW1 sudo mkdir -p /usr/sap/trans sudo chattr +i /sapmnt/NW1 sudo chattr +i /usr/sap/trans
GlusterFS クライアントとその他の要件をインストールします。
sudo yum -y install glusterfs-fuse uuidd
マウント エントリを追加します。
sudo vi /etc/fstab # Add the following lines to fstab, save and exit glust-0:/NW1-sapmnt /sapmnt/NW1 glusterfs backup-volfile-servers=glust-1:glust-2 0 0 glust-0:/NW1-trans /usr/sap/trans glusterfs backup-volfile-servers=glust-1:glust-2 0 0
新しい共有をマウントします。
sudo mount -a
スワップ ファイルを構成します。
sudo vi /etc/waagent.conf # Set the property ResourceDisk.EnableSwap to y # Create and use swapfile on resource disk. ResourceDisk.EnableSwap=y # Set the size of the SWAP file with property ResourceDisk.SwapSizeMB # The free space of resource disk varies by virtual machine size. Make sure that you do not set a value that is too big. You can check the SWAP space with command swapon # Size of the swapfile. ResourceDisk.SwapSizeMB=2000
エージェントを再起動して変更をアクティブにします。
sudo service waagent restart
データベースをインストールする
この例では、SAP HANA に SAP NetWeaver がインストールされます。 このインストールではサポートされているすべてのデータベースを使用できます。 Azure への SAP HANA のインストール方法の詳細については、「High availability of SAP HANA on Azure VMs on Red Hat Enterprise Linux」 (Red Hat Enterprise Linux 上の Azure VM での SAP HANA の高可用性) をご覧ください。 サポートされているデータベースの一覧については、SAP Note 1928533 を参照してください。
SAP データベース インスタンスのインストールを実行します。
root として SAP NetWeaver データベース インスタンスをインストールします。その際、データベースのロード バランサー フロントエンド構成の IP アドレスに対応する仮想ホスト名 (たとえば、nw1-db と 10.0.0.13) を使用します。
sapinst
のパラメーターSAPINST_REMOTE_ACCESS_USER
を使用すると、ルート以外のユーザーがsapinst
に接続することを許可できます。sudo <swpm>/sapinst SAPINST_REMOTE_ACCESS_USER=sapadmin
SAP NetWeaver アプリケーション サーバーのインストール
次の手順に従って、SAP アプリケーション サーバーをインストールします。
アプリケーション サーバーを準備します。
前のセクション「SAP NetWeaver アプリケーション サーバーの準備」の手順に従って、アプリケーション サーバーを準備します。
SAP NetWeaver アプリケーション サーバーをインストールします。
プライマリまたは追加の SAP NetWeaver アプリケーション サーバーをインストールします。
sapinst
のパラメーターSAPINST_REMOTE_ACCESS_USER
を使用すると、ルート以外のユーザーがsapinst
に接続することを許可できます。sudo <swpm>/sapinst SAPINST_REMOTE_ACCESS_USER=sapadmin
SAP HANA Secure Store を更新します。
SAP HANA システム レプリケーション セットアップの仮想名を指すように SAP HANA Secure Store を更新します。
次のコマンドを実行して、エントリを <sapsid>adm として一覧表示します。
hdbuserstore List
すべてのエントリが一覧表示され、次のようになります。
DATA FILE : /home/nw1adm/.hdb/nw1-di-0/SSFS_HDB.DAT KEY FILE : /home/nw1adm/.hdb/nw1-di-0/SSFS_HDB.KEY KEY DEFAULT ENV : 10.0.0.14:30313 USER: SAPABAP1 DATABASE: NW1
出力には、既定のエントリの IP アドレスがロード バランサーの IP アドレスではなく VM を指していることが示されます。 このエントリは、ロード バランサーの仮想ホスト名を指すように変更する必要があります。 同じポート (前の出力 30313) とデータベース名 (前の出力の HN1) を使用してください。
su - nw1adm hdbuserstore SET DEFAULT nw1-db:30313@NW1 SAPABAP1 <password of ABAP schema>
クラスターの設定をテストする
ASCS インスタンスを手動で移行します。
テスト開始前のリソースの状態:
rsc_st_azure (stonith:fence_azure_arm): Started nw1-cl-0 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started nw1-cl-0 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started nw1-cl-0 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started nw1-cl-0 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started nw1-cl-0 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started nw1-cl-1 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started nw1-cl-1 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started nw1-cl-1 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started nw1-cl-1
次のコマンドを root として実行して、ASCS インスタンスを移行します。
[root@nw1-cl-0 ~]# pcs resource move rsc_sap_NW1_ASCS00 [root@nw1-cl-0 ~]# pcs resource clear rsc_sap_NW1_ASCS00 # Remove failed actions for the ERS that occurred as part of the migration [root@nw1-cl-0 ~]# pcs resource cleanup rsc_sap_NW1_ERS02
テスト後のリソースの状態:
rsc_st_azure (stonith:fence_azure_arm): Started nw1-cl-0 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started nw1-cl-1 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started nw1-cl-1 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started nw1-cl-1 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started nw1-cl-1 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started nw1-cl-0 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started nw1-cl-0 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started nw1-cl-0 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started nw1-cl-0
ノードのクラッシュをシミュレートします。
テスト開始前のリソースの状態:
rsc_st_azure (stonith:fence_azure_arm): Started nw1-cl-0 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started nw1-cl-1 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started nw1-cl-1 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started nw1-cl-1 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started nw1-cl-1 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started nw1-cl-0 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started nw1-cl-0 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started nw1-cl-0 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started nw1-cl-0
ASCS インスタンスが実行されているノードで、次のコマンドを root として実行します。
[root@nw1-cl-1 ~]# echo b > /proc/sysrq-trigger
ノードの起動後の状態は、再び次のようになります。
Online: [ nw1-cl-0 nw1-cl-1 ] Full list of resources: rsc_st_azure (stonith:fence_azure_arm): Started nw1-cl-0 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started nw1-cl-0 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started nw1-cl-0 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started nw1-cl-0 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started nw1-cl-0 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started nw1-cl-1 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started nw1-cl-1 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started nw1-cl-1 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started nw1-cl-1 Failed Actions: * rsc_sap_NW1_ERS02_monitor_11000 on nw1-cl-0 'not running' (7): call=45, status=complete, exitreason='', last-rc-change='Tue Aug 21 13:52:39 2018', queued=0ms, exec=0ms
Note
SBD を STONITH メカニズムとして使用している場合、再起動後にノードがクラスターに再参加しようとすると、/var/log/messages で "we were allegendly just fenced" というメッセージを受信し、Pacemaker サービスと Corosync サービスをシャットダウンします。 この問題に対処するには、ノードがフェンスされ、corosync と pacemaker を再起動した後にノードが pacemaker をシャットダウンするという RedHat KB に記載されている回避策に従うことができます。 ただし、Azure では、Corosync サービスが起動するまでに 150 秒の遅延を設定します。 これらの手順がすべてのクラスター ノードに適用されていることを確認します。
次のコマンドを実行して、失敗したリソースを取り除きます。
[root@nw1-cl-0 ~]# pcs resource cleanup rsc_sap_NW1_ERS02
テスト後のリソースの状態:
rsc_st_azure (stonith:fence_azure_arm): Started nw1-cl-0 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started nw1-cl-0 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started nw1-cl-0 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started nw1-cl-0 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started nw1-cl-0 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started nw1-cl-1 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started nw1-cl-1 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started nw1-cl-1 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started nw1-cl-1
ネットワーク通信をブロックします。
テスト開始前のリソースの状態:
rsc_st_azure (stonith:fence_azure_arm): Started nw1-cl-0 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started nw1-cl-0 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started nw1-cl-0 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started nw1-cl-0 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started nw1-cl-0 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started nw1-cl-1 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started nw1-cl-1 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started nw1-cl-1 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started nw1-cl-1
ファイアウォール規則を実行して、いずれかのノードでの通信をブロックします。
# Execute iptable rule on nw1-cl-0 (10.0.0.7) to block the incoming and outgoing traffic to nw1-cl-1 (10.0.0.8) iptables -A INPUT -s 10.0.0.8 -j DROP; iptables -A OUTPUT -d 10.0.0.8 -j DROP
クラスター ノードが相互に通信できない場合、スプリット ブレイン シナリオのリスクがあります。 このような状況では、クラスター ノードは互いに同時にフェンスを試行し、フェンス レース合を発生させます。 このような状況を回避するには、クラスター構成で priority-fencing-delay プロパティを設定することをおすめします (pacemaker-2.0.4-6.el8 以降にのみ適用されます)。
priority-fencing-delay
プロパティを有効にすると、クラスターでは、特に ASCS リソースをホストしているノード上でフェンス アクションに遅延が発生し、ノードがフェンス レースに勝つ可能性があります。次のコマンドを実行して、ファイアウォール規則を削除します。
# If the iptables rule set on the server gets reset after a reboot, the rules will be cleared out. In case they have not been reset, please proceed to remove the iptables rule using the following command. iptables -D INPUT -s 10.0.0.8 -j DROP; iptables -D OUTPUT -d 10.0.0.8 -j DROP
メッセージ サーバー プロセスを強制終了します。
テスト開始前のリソースの状態:
rsc_st_azure (stonith:fence_azure_arm): Started nw1-cl-0 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started nw1-cl-0 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started nw1-cl-0 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started nw1-cl-0 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started nw1-cl-0 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started nw1-cl-1 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started nw1-cl-1 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started nw1-cl-1 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started nw1-cl-1
次のコマンドを root として実行して、メッセージ サーバーのプロセスを特定し、強制終了します。
[root@nw1-cl-0 ~]# pgrep -f ms.sapNW1 | xargs kill -9
メッセージ サーバーを 1 回だけ強制終了すると、
sapstart
はメッセージ サーバーを再起動します。 強制終了を複数回実行すると、Pacemaker は最終的に ASCS インスタンスを他のノードに移動します。 テスト後に、次のコマンドを root として実行して、ASCS と ERS インスタンスのリソースの状態をクリーンアップします。[root@nw1-cl-0 ~]# pcs resource cleanup rsc_sap_NW1_ASCS00 [root@nw1-cl-0 ~]# pcs resource cleanup rsc_sap_NW1_ERS02
テスト後のリソースの状態:
rsc_st_azure (stonith:fence_azure_arm): Started nw1-cl-0 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started nw1-cl-1 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started nw1-cl-1 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started nw1-cl-1 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started nw1-cl-1 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started nw1-cl-0 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started nw1-cl-0 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started nw1-cl-0 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started nw1-cl-0
エンキュー サーバー プロセスを強制終了します。
テスト開始前のリソースの状態:
rsc_st_azure (stonith:fence_azure_arm): Started nw1-cl-0 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started nw1-cl-1 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started nw1-cl-1 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started nw1-cl-1 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started nw1-cl-1 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started nw1-cl-0 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started nw1-cl-0 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started nw1-cl-0 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started nw1-cl-0
ASCS インスタンスが実行されているノードで、次のコマンドを root として実行して、エンキュー サーバーを強制終了します。
#If using ENSA1 [root@nw1-cl-1 ~]# pgrep -f en.sapNW1 | xargs kill -9 #If using ENSA2 [root@nw1-cl-1 ~]# pgrep -f enq.sapNW1 | xargs kill -9
ENSA1 の場合、ASCS インスタンスがすぐに他のノードにフェールオーバーします。 ASCS インスタンスの開始後に、ERS インスタンスもフェールオーバーします。 テスト後に、次のコマンドを root として実行して、ASCS と ERS インスタンスのリソースの状態をクリーンアップします。
[root@nw1-cl-0 ~]# pcs resource cleanup rsc_sap_NW1_ASCS00 [root@nw1-cl-0 ~]# pcs resource cleanup rsc_sap_NW1_ERS02
テスト後のリソースの状態:
rsc_st_azure (stonith:fence_azure_arm): Started nw1-cl-0 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started nw1-cl-0 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started nw1-cl-0 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started nw1-cl-0 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started nw1-cl-0 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started nw1-cl-1 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started nw1-cl-1 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started nw1-cl-1 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started nw1-cl-1
エンキュー レプリケーション サーバー プロセスを強制終了します。
テスト開始前のリソースの状態:
rsc_st_azure (stonith:fence_azure_arm): Started nw1-cl-0 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started nw1-cl-0 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started nw1-cl-0 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started nw1-cl-0 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started nw1-cl-0 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started nw1-cl-1 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started nw1-cl-1 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started nw1-cl-1 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started nw1-cl-1
ERS インスタンスが実行されているノードで、次のコマンドを root として実行して、エンキュー レプリケーション サーバー プロセスを強制終了します。
#If using ENSA1 [root@nw1-cl-1 ~]# pgrep -f er.sapNW1 | xargs kill -9 #If using ENSA2 [root@nw1-cl-1 ~]# pgrep -f enqr.sapNW1 | xargs kill -9
コマンドを 1 回だけ実行した場合、
sapstart
はプロセスを再起動します。 複数回実行すれば、sapstart
によるプロセスの再起動はなくなり、リソースは停止状態になります。 テスト後に、次のコマンドを root として実行して、ERS インスタンスのリソースの状態をクリーンアップします。[root@nw1-cl-0 ~]# pcs resource cleanup rsc_sap_NW1_ERS02
テスト後のリソースの状態:
rsc_st_azure (stonith:fence_azure_arm): Started nw1-cl-0 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started nw1-cl-0 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started nw1-cl-0 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started nw1-cl-0 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started nw1-cl-0 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started nw1-cl-1 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started nw1-cl-1 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started nw1-cl-1 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started nw1-cl-1
エンキュー
sapstartsrv
プロセスを強制終了します。テスト開始前のリソースの状態:
rsc_st_azure (stonith:fence_azure_arm): Started nw1-cl-0 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started nw1-cl-0 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started nw1-cl-0 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started nw1-cl-0 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started nw1-cl-0 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started nw1-cl-1 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started nw1-cl-1 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started nw1-cl-1 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started nw1-cl-1
ASCS が実行されているノードで、次のコマンドを root として実行します。
[root@nw1-cl-0 ~]# pgrep -fl ASCS00.*sapstartsrv # 59545 sapstartsrv [root@nw1-cl-0 ~]# kill -9 59545
sapstartsrv
プロセスは、監視の一環として Pacemaker リソース エージェントによって常に再起動される必要があります。 テスト後のリソースの状態:rsc_st_azure (stonith:fence_azure_arm): Started nw1-cl-0 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started nw1-cl-0 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started nw1-cl-0 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started nw1-cl-0 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started nw1-cl-0 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started nw1-cl-1 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started nw1-cl-1 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started nw1-cl-1 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started nw1-cl-1
次のステップ
- RHEL 上の SAP NetWeaver HA クラスターに PAS と AAS インスタンスがデプロイされているコスト最適化シナリオをデプロイするには、RHEL での SAP ASCS/SCS 高可用性 VM を使用した SAP ダイアログ インスタンスのインストールに関する記事を参照してください。
- 「RHEL for SAP アプリケーション マルチ SID 上の Azure VM での SAP NW の HA ガイド」を参照してください。
- 「SAP のための Azure Virtual Machines の計画と実装」を参照してください。
- 「SAP のための Azure Virtual Machines のデプロイ」を参照してください。
- 「SAP のための Azure Virtual Machines DBMS のデプロイ」を参照してください。
- SAP HANA on Azure (L インスタンス) の HA を確保し、ディザスター リカバリーを計画する方法を確認するには、「Azure での SAP HANA L インスタンスの高可用性とディザスター リカバリー」を参照してください。
- Azure VM 上の SAP HANA の HA を確保し、ディザスター リカバリーを計画する方法を確認するには、「Azure Virtual Machines 上の SAP HANA の高可用性」を参照してください。