IBM Cloud Docs
Red Hat Enterprise Linux High Availability Add-On クラスタ内の SAP S/4HANA (ASCS および ERS) 用の高可用性の設定

Red Hat Enterprise Linux High Availability Add-On クラスタ内の SAP S/4HANA (ASCS および ERS) 用の高可用性の設定

Red Hat Enterprise Linux (RHEL) High Availability Add-On クラスタにおける ABAP SAP Central Services (ASCS) および Enqueue Replication Server (ERS) の構成について説明します。 クラスタは、仮想サーバーインスタンスを IBM® Power® Virtual Server クラスタノードとして使用しています。

この設定例は 、スタンドアロンエンキューサーバー の第2世代にも適用されます。 ENSA2。

SAP S/4HANA 1809 のリリースから、 ENSA2 はデフォルトでインストールされ、2ノードまたはマルチノードクラスターで構成することができます。 この例では、 ENSA2 2ノードの RHEL HA アドオンクラスターのセットアップを使用しています。 2ノードクラスタ でASCSサービスが停止した場合*、ERSインスタンスが実行されているノード上で再起動します。 SAP アプリケーションのロックエントリは、ERSインスタンス内のロックテーブルのコピーから復元されます。 管理者が障害が発生したクラスタノードをアクティブ化すると、ERSインスタンスは*ロックテーブルのコピーを保護するために、もう一方のノード（アンチコロケーション）に移動します。

SAP データベースインスタンスとその他の SAP アプリケーションサーバーインスタンスは、 ASCS と ERS の2ノードクラスター外の仮想サーバーインスタンスにインストールすることをお勧めします。

開始前に

IBM Power Virtual Server リファレンスでの SAP アプリケーションの高可用性の実装」 に記載されている一般要件、製品ドキュメント、サポート記事、および SAP ノートを確認してください。

前提条件

  • この情報は、クラスタノードの両方でアクセス可能な共有ストレージボリュームを使用するセットアップについて説明しています。 特定のファイルシステムは、クラスタノードの両方にマウントできるように、共有可能なストレージボリューム上に作成されます。 この設定は両方のインスタンスディレクトリに適用されます。

    • /usr/sap/<SID>/ASCS<INSTNO> ASCSインスタンスの。
    • /usr/sap/<SID>/ERS<INSTNO> ERSインスタンスの。

    これらのファイルシステム用に作成されたストレージボリュームが、両方の仮想サーバーインスタンスにアタッチされていることを確認してください。 SAP インスタンスのインストールとRHEL HAアドオンクラスタの構成中、各インスタンスのディレクトリは適切なノードにマウントする必要があります。 HA-LVMは、2つのインスタンスディレクトリのそれぞれが同時に1つのノードにのみマウントされるようにします。

    インスタンスディレクトリの異なるストレージ設定、例えば NFS マウントなどが可能です。 ファイルストレージのセットアップ手順やクラスタファイルシステムリソースの作成手順については、本書では説明しません。

  • ASCS とERSインスタンスの仮想ホスト名は 、 SAP ABAP Platformサーバーのホスト名に記載されている要件を満たす必要があります。 SAP インスタンスの仮想IPアドレスがネットワークアダプタに割り当てられ、ネットワーク上で通信できることを確認してください。

  • SAP アプリケーションサーバーのインスタンスには、 読み取りおよび書き込みアクセス権を持つ共通の共有ファイルシステム sapmnt /sapmnt/<SID> と、 saptrans /usr/sap/trans などの他の共有ファイルシステムが必要です。 これらのファイルシステムは通常、外部の NFS サーバーによって提供されます。 NFS サーバーは高可用性でなければならず、クラスターの一部である仮想サーバーにはインストールしないでください。 ENSA2 クラスターの一部である仮想サーバーにインストールしないでください。

    Red Hat 高可用性クラスターでアクティブ/パッシブ NFS サーバーを構成するでは、 Power Virtual Server の仮想サーバーインスタンスを使用して、 Red Hat Enterprise Linux 8 を搭載した RHEL HA アドオンクラスターにアクティブ/パッシブ NFS サーバーを実装する方法について説明します。 アクティブ-パッシブ構成の NFS サーバー用のRHEL HAアドオンクラスターは、単一の Power Virtual Server ワークスペースに展開する必要があります。

ASCSおよびERSインスタンスをインストールするためのノードの準備

次の情報では、 SAP ASCS および ERS インスタンスをインストールするためにノードを準備する方法について説明します。

環境変数の準備

セットアップを簡素化するために、クラスタノードの両方で、ユーザー root 用の以下の環境変数を準備します。 これらの環境変数は、この情報では、後のオペレーティングシステムコマンドで使用されます。

両方のノードで、以下の環境変数を設定します。

# General settings
export SID=<SID>                   # SAP System ID (uppercase)
export sid=<sid>                   # SAP System ID (lowercase)

# ASCS instance
export ASCS_INSTNO=<INSTNO>        # ASCS instance number
export ASCS_VH=<virtual hostname>  # ASCS virtual hostname
export ASCS_IP=<IP address>        # ASCS virtual IP address
export ASCS_VG=<vg name>           # ASCS volume group name
export ASCS_LV=<lv name>           # ASCS logical volume name

# ERS instance
export ERS_INSTNO=<INSTNO>         # ERS instance number
export ERS_VH=<virtual hostname>   # ERS virtual hostname
export ERS_IP=<IP address>         # ERS virtual IP address
export ERS_VG=<vg name>            # ERS volume group name
export ERS_LV=<lv name>            # ERS logical volume name

# NFS settings
export NFS_SERVER="NFS server"           # Hostname or IP address of the highly available NFS server
export NFS_SHARE="NFS server directory"  # Exported file system directory on the NFS server
export NFS_OPTIONS="rw,sec=sys"          # Sample NFS client mount options

ボリュームグループおよび論理ボリュームには、その内容を意味する名前を使用することが推奨されます。 例えば、 SID とascs または ers を名前に含めます。 ボリュームグループ名や論理ボリューム名にはハイフンを使用しないでください。

  • s01ascsvg そして s01ascslv
  • s01ersvg そして s01erslv

仮想IPアドレスの割り当て

「仮想 IP アドレスの予約 」の情報を確認してください。

SAP インスタンスの仮想IPアドレスが存在しているかどうかを確認します。 そうでない場合は、IPアドレスを割り当てるために正しいネットワークアダプタを特定する必要があります。

両方のノードで、現在アクティブなIPアドレスのリストを確認します。

ip -o -f inet address show | '/scope global/ {print $2, $4}'

前のコマンドの出力例。

# ip -o -f inet address show | awk '/scope global/ {print $2, $4}'
env2 10.51.0.66/24
env3 10.52.0.41/24
env4 10.111.1.28/24

ネットワークアダプタのデバイス名が最初の列に表示されます。 2番目の列には、アクティブなIPアドレスと、ネットマスク用に予約されているビット数が記載されています。これらはスラッシュで区切られています。

SAP インスタンスの仮想IPアドレスが存在しない場合は、それが誤って別の仮想サーバーインスタンスに設定されていないことを確認してください。

NODE1 で、以下のコマンドを実行する。

ping -c 3 ${ASCS_VH}

出力例:

# ping -c 2 cl-sap-scs
PING cl-sap-scs (10.111.1.248) 56(84) bytes of data.
From cl-sap-1.tst.ibm.com (10.111.1.28) icmp_seq=1 Destination Host Unreachable
From cl-sap-1.tst.ibm.com (10.111.1.28) icmp_seq=2 Destination Host Unreachable

--- cl-sap-ers ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 2112ms
pipe 3

ping の出力が Destination Host Unreachable と表示された場合、IPアドレスが利用可能であり、IPエイリアスを仮想サーバーインスタンスに割り当てることができます。 IPアドレスのサブネットに一致するネットワークアダプタの正しい デバイス名env を使用してください。

上の例のコマンド NODE1:

ip addr add ${ASCS_IP} dev env4

上の例のコマンド NODE2:

ip addr add ${ERS_IP} dev env4

ネットワーク構成によっては、ネットワークアダプタのデバイス名が異なる場合があります。

SAP のインストールにはIPアドレスが必要であり、手動で設定します。 その後、仮想 IP アドレスは Red Hat HA Cluster Add-on によって制御されます。

ボリュームグループ、論理ボリューム、共有ファイルシステムの準備

共有ストレージはクラスタにおいて重要なリソースです。 ENSA2 クラスタにおいて重要なリソースです。 ASCS と ERSは両方のノードで実行できなければならず、その実行環境は共有ストレージボリュームに保存されます。 すべてのクラスタノードは共有ストレージボリュームにアクセスする必要がありますが、ボリュームへの排他的な読み取りおよび書き込みアクセス権限を持つのは1つのノードのみです。

論理ボリュームマネージャの高可用性設定の準備

ボリュームグループにシステムID を含めるために、 /etc/lvm/lvm.conf ファイルを編集します。

両方のノードで、 lvm.conf ファイルを編集します。

vi /etc/lvm/lvm.conf

system_id_source パラメータを検索し、その値を uname に変更します。

etc/lvm/lvm.conf における system_id_source パラメータの設定例。

system_id_source = "uname"

共有ストレージボリュームのワールドワイド名を特定する

共有ボリュームグループの一部である各ストレージボリュームのワールドワイド名（WWN）を決定します。

  1. IBM Cloud® にログインして、 Power Virtual Server の ストレージボリュームの表示にアクセスします。

  2. ワークスペースを選択します。

  3. ストレージボリュームのリストで ボリュームのプレフィックスをフィルタし、 ASCS とERSインスタンスの対象となるボリュームのワールドワイド名をすべて特定します。 ワールドワイド・ネームは32桁の16進数です。

    それらのボリュームの属性 「共有可能」 が 「オン」 になっていることを確認してください。

仮想サーバーインスタンスの表示で、クラスタの仮想サーバーインスタンスの両方に移動します。 ASCS とERS の対象となるすべてのボリュームが両方の仮想サーバーインスタンスにアタッチされていることを確認します。

新しいストレージボリュームを仮想サーバーインスタンスに追加する際には、新しいボリュームを検出するためにSCSIバスを再スキャンしてください。 その後、仮想サーバーインスタンスの マルチパス構成を更新します。

新しいストレージボリュームがアタッチされたノードで、次のコマンドを実行します。

rescan-scsi-bus.sh && sleep 10 && multipathd reconfigure

両方のクラスタノードにログインし、ユーザ root の環境変数に WWN を追加します。

pvs --all コマンドを使用して、適切な WWN値を決定します。

NODE1 で、 ASCS_PVID 環境変数をエクスポートします。

export ASCS_PVID=3<WWN>  # WWN of shared storage volume for ASCS

NODE2 で、 ERS_PVID 環境変数をエクスポートします。

export ERS_PVID=3<WWN>   # WWN of shared storage volume for ERS

環境変数の設定は、必ず16進数表記で小文字を使用して設定してください。

物理ボリュームの作成

NODE1 で、以下のコマンドを実行する。

pvcreate /dev/mapper/${ASCS_PVID}

出力例:

# pvcreate /dev/mapper/${ASCS_PVID}
  Physical volume "/dev/mapper/360050768108103357000000000002ddc" successfully created.

NODE2 で、以下のコマンドを実行する。

pvcreate /dev/mapper/${ERS_PVID}

出力例:

# pvcreate /dev/mapper/${ERS_PVID}
  Physical volume "/dev/mapper/360050768108103357000000000002e31" successfully created.

ボリュームグループの作成

ASCS用のボリュームグループを作成します。

NODE1 で、以下のコマンドを実行する。

vgcreate ${ASCS_VG} /dev/mapper/${ASCS_PVID}

システムID が設定されていることを確認してください。

vgs -o+systemid

出力例:

# vgs -o+systemid
  VG          #PV #LV #SN Attr   VSize   VFree   System ID
  s01ascsvg     1   0   0 wz--n- <50.00g <50.00g cl-sap-1

ERS用のボリュームグループを作成します。

NODE2 で、以下のコマンドを実行する。

vgcreate ${ERS_VG} /dev/mapper/${ERS_PVID}

システムIDが設定されていることを確認してください。

出力例:

# vgs -o+systemid
  VG          #PV #LV #SN Attr   VSize   VFree   System ID
  s01ersvg     1   0   0 wz--n- <50.00g <50.00g cl-sap-2

論理ボリュームとファイルシステムの作成

ASCS用の論理ボリュームを作成し*、XFSファイルシステムとして*フォーマットします。

NODE1 で、以下のコマンドを実行する。

lvcreate -l 100%FREE -n ${ASCS_LV} ${ASCS_VG}

mkfs.xfs /dev/${ASCS_VG}/${ASCS_LV}

ERS用の論理ボリュームを作成し*、XFSファイルシステムとして*フォーマットします。

NODE2 で、以下のコマンドを実行する。

lvcreate -l 100%FREE -n ${ERS_LV} ${ERS_VG}

mkfs.xfs /dev/${ERS_VG}/${ERS_LV}

ボリュームグループが複数のクラスタノードでアクティブ化されていないことを確認する

クラスタによって管理されるボリュームグループは、起動時に自動的にアクティブ化されてはなりません。

RHEL 8.5 以降では、ボリュームグループを作成する際に、vgcreateコマンドで --setautoactivation n フラグを指定して自動アクティベーションを無効にします。

両方のノードで、 /etc/lvm/lvm.conf ファイルを編集し、 auto_activation_volume_list エントリを変更して、自動アクティベーションを特定のボリュームグループに制限します。

vi /etc/lvm/lvm.conf

auto_activation_volume_list パラメータを見つけ、 NFS クラスタ用に定義したボリュームグループを除くすべてのボリュームグループをこのリストに追加します。

/etc/lvm/lvm.conf の auto_activation_volume_list の入力方法の例をご覧ください

auto_activation_volume_list = [ "rhel_root" ]

initramfsブートイメージを再構築し、クラスタによって制御されているボリュームグループが起動イメージによって起動されないようにします。

両方のノードで、以下のコマンドを実行します。

dracut -H -f /boot/initramfs-$(uname -r).img $(uname -r)

両方のノードを再起動します。

SAP インストール用のファイルシステムのマウント

ボリュームグループをアクティブにし、 SAP インスタンスファイルシステムをマウントします。

NODE1 （ASCS ）で、以下のコマンドを実行します。

vgchange -a y ${ASCS_VG}

mkdir -p /usr/sap/${SID}/ASCS${ASCS_INSTNO}

mount /dev/${ASCS_VG}/${ASCS_LV} /usr/sap/${SID}/ASCS${ASCS_INSTNO}

NODE2 （ERS ）で、以下のコマンドを実行します。

vgchange -a y ${ERS_VG}

mkdir -p /usr/sap/${SID}/ERS${ERS_INSTNO}

mount /dev/${ERS_VG}/${ERS_LV} /usr/sap/${SID}/ERS${ERS_INSTNO}

必要な NFS ファイルシステムのマウント

両方のノードで、 NFS ファイルシステム /sapmnt と /usr/sap/trans がマウントされていることを確認してください。

mount | grep nfs

もう一方のノードにASCSとERSマウントポイントを作成する

インスタンスファイルシステムのマウントポイントを作成し、所有権を調整します。

NODE1 で、以下のコマンドを実行する。

mkdir /usr/sap/${SID}/ERS${ERS_INSTNO}

chown ${sid}adm:sapsys /usr/sap/${SID}/ERS${ERS_INSTNO}

NODE2 で、以下のコマンドを実行する。

mkdir /usr/sap/${SID}/ASCS${ASCS_INSTNO}

chown ${sid}adm:sapsys /usr/sap/${SID}/ASCS${ASCS_INSTNO}

ASCSとERSインスタンスのインストール

SAP Software Provisioning Manager （SWPM）を使用して、両方のインスタンスをインストールします。

  • クラスタノードに SAP のインスタンスをインストールします。

    • ASCS用の仮想IPアドレスに関連付けられた仮想ホスト名 ${ASCS_VH} を使用して、 NODE1 に ASCSインスタンスをインストールします
    <swpm>/sapinst SAPINST_USE_HOSTNAME=${ASCS_VH}
    • ERSの仮想IPアドレスに関連付けられた仮想ホスト名 ${ERS_VH} を使用して、 NODE2 にERSインスタンスをインストールします
    <swpm>/sapinst SAPINST_USE_HOSTNAME=${ERS_VH}

  • SAP アプリケーションの他のインスタンスはすべてクラスタ外にインストールします。

RHEL HAアドオンクラスターのインストールと設定

Red Hat Enterprise Linux High Availability Add-On クラスタの実装 」に従って、RHEL HA Add-On クラスタをインストールしてセットアップします。

フェンシングデバイスの作成 で説明されているように、フェンシングを設定し、テストします。

クラスタ統合のためのASCSとERSインスタンスの準備

以下の手順を使用して、 SAP インスタンスをクラスタ統合用に準備します。

ASCSとERSの SAP インスタンスエージェントの自動起動を無効にする

再起動後、 ASCSと ERS インスタンスの両方で sapstartsrv インスタンスエージェントの自動起動を無効にする必要があります。

SAP インスタンスエージェントの統合タイプの確認

SAP インスタンスエージェント sapstartsrv の最近のバージョンは、 Linux でネイティブな systemd サポートを提供している。 詳しくは、 SAP 「注意事項 」に記載されている SAP 「注意事項」を参照されたい。

両方のノードで、 /usr/sap/sapservices ファイルの内容を確認する。

cat /usr/sap/sapservices

systemd 、行頭は systemctl。

例:

systemctl --no-ask-password start SAPS01_01 # sapstartsrv pf=/usr/sap/S01/SYS/profile/S01_ASCS01_cl-sap-scs

ASCS と ERS のエントリが systemd 形式になっている場合は、 ASCS と ERS SAP インスタンスの systemd サービスを無効にする のステップを続行します。

classic 、行頭は LD_LIBRARY_PATH。

例:

LD_LIBRARY_PATH=/usr/sap/S01/ASCS01/exe:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH;/usr/sap/S01/ASCS01/exe/sapstartsrv pf=/usr/sap/S01/SYS/profile/S01_ASCS01_cl-sap-scs -D -u s01adm

ASCSとERSのエントリーが classic 形式である場合、 /usr/sap/sapservices ファイルを修正し、再起動後に ASCSと ERS インスタンスの両方で sapstartsrv インスタンスエージェントが自動起動しないようにします。

両ノードで、 SAP サービスファイルの ASCSと ERSの sapstartsrv エントリを削除またはコメントアウトします。

sed -i -e 's/^LD_LIBRARY_PATH=/#LD_LIBRARY_PATH=/' /usr/sap/sapservices

例:

#LD_LIBRARY_PATH=/usr/sap/S01/ASCS01/exe:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH;/usr/sap/S01/ASCS01/exe/sapstartsrv pf=/usr/sap/S01/SYS/profile/S01_ASCS01_cl-sap-scs -D -u s01adm

永続的な SAP ライセンスキーのインストールに 進む。

ASCSとERSインスタンスのsystemdサービスを無効にする

両方のノードで、ASCSのインスタンスエージェントを無効にします。

systemctl disable --now SAP${SID}_${ASCS_INSTNO}.service

両方のノードで、ERSのインスタンスエージェントを無効にします。

systemctl disable --now SAP${SID}_${ERS_INSTNO}.service

クラッシュした ASCS または ERS インスタンスの systemd 再起動の無効化

Systemd は、クラッシュしたサービスを再起動するための独自のメカニズムを持っている。 高可用性の設定では、HAクラスタのみが SAP ASCSとERSインスタンスを管理する責任があります。 systemd がクラッシュした SAP インスタンスを再起動しないように、両方のクラスタ・ノードに systemd drop-in files を作成します。

両方のノードに、ドロップイン・ファイル用のディレクトリを作成する。

mkdir /etc/systemd/system/SAP${SID}_${ASCS_INSTNO}.service.d

mkdir /etc/systemd/system/SAP${SID}_${ERS_INSTNO}.service.d

両方のノードで、ASCSとERS用のドロップインファイルを作成します。

cat >> /etc/systemd/system/SAP${SID}_${ASCS_INSTNO}.service.d/HA.conf << EOT
[Service]
Restart=no
EOT

cat >> /etc/systemd/system/SAP${SID}_${ERS_INSTNO}.service.d/HA.conf << EOT
[Service]
Restart=no
EOT

Restart=no が セクションにあり、ドロップイン・ファイルがすべてのクラスタ・ノードで利用可能でなければならない。 [Service]

両方のノードで、 systemd ユニットファイルをリロードする。

systemctl daemon-reload

永続的な SAP ライセンスキーのインストール

SAP ASCS インスタンスが Power Virtual Server インスタンスにインストールされている場合、 SAP ライセンスメカニズムはパーティションUUIDに依存します。 詳細については、 SAP note 2879336 - Hardware key based on unique IDを参照してください。

両方のノードで、ユーザー <sid>adm として以下のコマンドを実行し、ノードの HARDWARE KEY を特定する。

sudo -i -u ${sid}adm -- sh -c 'saplikey -get'

出力例:

$ sudo -i -u ${sid}adm -- sh -c 'saplikey -get'

saplikey: HARDWARE KEY = H1428224519

各ノードの HARDWARE KEY。

2つの異なる SAP ライセンスキーをリクエストするには、両方のハードウェアキーが必要です。 SAP ライセンスキーのリクエストに関する詳細は、以下の SAP ノートをご確認ください：

SAP リソースエージェントのインストール

必要なソフトウェアパッケージをインストールする。 resource-agents-sap には、 SAP インスタンスを管理するための SAPInstance クラスターリソースエージェントが含まれています。

SAP インスタンスに sap_cluster_connector が設定されていない限り、RHEL HA Add-On クラスタはインスタンスの状態変化を問題とみなします。 インスタンスの管理に sapcontrol などの他の SAP ツールが使用されている場合、 sap_cluster_connector はクラスタ内部で実行されている SAP インスタンスを制御する権限を付与します。 SAP インスタンスがクラスタツールだけで管理されている場合、以下の実装が必要となる。 sap_cluster_connector は必要ない。

リソース・エージェントと SAP Cluster Connector ライブラリのパッケージをインストールします。 詳細については、 RHEL HAアドオンが管理する SAP ABAPアプリケーションサーバーインスタンスで SAP HAインタフェースを有効にする方法を参照してください

両方のノードで以下のコマンドを実行する。

必要であれば、 subscription-manager を使って SAP NetWeaver リポジトリを有効にする。 RHEL for SAP Subscriptions and Repositories 』では、必要なリポジトリを有効にする方法を説明しています。

subscription-manager repos --enable="rhel-8-for-ppc64le-sap-netweaver-e4s-rpms"

必要なパッケージをインストールします。

dnf install -y resource-agents-sap  sap-cluster-connector

SAP Cluster Connector の設定

ユーザー ${sid}adm を haclient グループに追加する。

両方のノードで以下のコマンドを実行する。

usermod -a -G haclient ${sid}adm

SAP インスタンスプロファイルの適応

クラスタ外の SAP ツールで管理されているすべての SAP インスタンスの開始プロファイルを変更します。 ASCSと ERS インスタンスはどちらも、RHEL HAアドオンクラスターとそのリソースエージェントによって制御することができます。 インスタンス・プロセスの自動再起動を防ぐために、 SAP インスタンス・プロファイルを調整する。

NODE1 で、 SAP プロファイル・ディレクトリに移動する。

cd /sapmnt/${SID}/profile

ASCSと ERSの両方のインスタンスプロファイルで、 Restart_Program を Start_Program に変更する。

sed -i -e 's/Restart_Program_\([0-9][0-9]\)/Start_Program_\1/' ${SID}_ASCS${ASCS_INSTNO}_${ASCS_VH}

sed -i -e 's/Restart_Program_\([0-9][0-9]\)/Start_Program_\1/' ${SID}_ERS${ERS_INSTNO}_${ERS_VH}

ASCSと ERS インスタンスの sap_cluster_connector を設定するために、 SAP インスタンスプロファイルの最後に以下の2行を追加します。

service/halib = $(DIR_EXECUTABLE)/saphascriptco.so
service/halib_cluster_connector = /usr/bin/sap_cluster_connector

ASCSとERSクラスタリソースの設定

ここまでは、以下のことが前提となっています

  • RHEL HAアドオンクラスタは両方の仮想サーバーインスタンスで稼働しており、ノードのフェンシングがテストされました。
  • SAP システムが稼働中です。
    • SAP ASCSはクラスタのノード1にインストールされ、稼働しています。
    • SAP ERSはクラスタのノード2にインストールされ、アクティブになっています。
  • クラスタ統合のためのASCSとERSインスタンスの準備 は完了しました。

sapmnt クラスタリソースの設定

外部 NFS サーバーからすべてのクラスターノードにSAPMNT共有をマウントするために、クローン化されたファイルシステムクラスターリソースを作成します。

環境変数 ${NFS_VH} が NFS サーバーの仮想ホスト名に設定され、 ${NFS_OPTIONS} が希望するマウントオプションに設定されていることを確認してください。

NODE1 で、以下のコマンドを実行する。

pcs resource create fs_sapmnt Filesystem \
    device="${NFS_VH}:/${SID}/sapmnt" \
    directory="/sapmnt/${SID}" \
    fstype='nfs' \
    options="${NFS_OPTIONS}" \
    clone interleave=true

ASCSリソースグループの設定

ASCSの仮想IPアドレスのリソースを作成します。

NODE1 で、以下のコマンドを実行する。

pcs resource create ${sid}_vip_ascs${ASCS_INSTNO} IPaddr2 \
    ip=${ASCS_IP} \
    --group ${sid}_ascs${ASCS_INSTNO}_group

共有ストレージボリューム上のHA-LVMファイルシステムのリソースを作成するこの例では、LVM-activateとASCSのインスタンスファイルシステムのリソースを作成します。

pcs resource create ${sid}_fs_ascs${ASCS_INSTNO}_lvm LVM-activate \
    vgname="${ASCS_VG}" \
    vg_access_mode=system_id \
    --group ${sid}_ascs${ASCS_INSTNO}_group

pcs resource create ${sid}_fs_ascs${ASCS_INSTNO} Filesystem \
    device="/dev/mapper/${ASCS_VG}-${ASCS_LV}" \
    directory=/usr/sap/${SID}/ASCS${ASCS_INSTNO} \
    fstype=xfs \
    --group ${sid}_ascs${ASCS_INSTNO}_group

ASCSのインスタンスファイルシステムがHA NFS サーバーによって提供される代替例では、ファイルシステムリソースのみが必要となります。 NFS サーバー に合わせて環境変数 ${NFS_VH} を定義し、 ASCSインスタンスの SAP インストール中に NFS ルートディレクトリの下に ${SID}/ASCS ディレクトリを作成したことを確認してください。

pcs resource create ${sid}_fs_ascs${ASCS_INSTNO} Filesystem \
    device="${NFS_VH}:${SID}/ASCS" \
    directory=/usr/sap/${SID}/ASCS${ASCS_INSTNO} \
    fstype=nfs \
    options="${NFS_OPTIONS}" \
    force_unmount=safe \
    op start interval=0 timeout=60 \
    op stop interval=0 timeout=120 \
    --group ${sid}_ascs${ASCS_INSTNO}_group

ASCSインスタンスを管理するためのリソースを作成します。

pcs resource create ${sid}_ascs${ASCS_INSTNO} SAPInstance \
    InstanceName="${SID}_ASCS${ASCS_INSTNO}_${ASCS_VH}" \
    START_PROFILE=/sapmnt/${SID}/profile/${SID}_ASCS${ASCS_INSTNO}_${ASCS_VH} \
    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 ${sid}_ascs${ASCS_INSTNO}_group

meta resource-stickiness=5000 オプションは、フェイルオーバーの制約とERSをバランスさせるために使用され、リソースが開始されたノードに留まり、クラスタ内で制御不能に移動しないようにします。

グループにリソースの粘着性を追加して*、ASCSが*ノード上に残るようにします。

pcs resource meta ${sid}_ascs${ASCS_INSTNO}_group \
    resource-stickiness=3000

ERSリソースグループの設定

ERSの仮想IPアドレスのリソースを作成します。

NODE1 で、以下のコマンドを実行する。

pcs resource create ${sid}_vip_ers${ERS_INSTNO} IPaddr2 \
    ip=${ERS_IP} \
    --group ${sid}_ers${ERS_INSTNO}_group

共有ストレージボリューム上のHA-LVMファイルシステム用のリソースを作成する例では、LVM-activate とERSのインスタンスファイルシステム用のリソースを作成します。

pcs resource create ${sid}_fs_ers${ERS_INSTNO}_lvm LVM-activate \
    vgname="${ERS_VG}" \
    vg_access_mode=system_id \
    --group ${sid}_ers${ERS_INSTNO}_group

pcs resource create ${sid}_fs_ers${ERS_INSTNO} Filesystem \
    device="/dev/mapper/${ERS_VG}-${ERS_LV}" \
    directory=/usr/sap/${SID}/ERS${ERS_INSTNO} \
    fstype=xfs \
    --group ${sid}_ers${ERS_INSTNO}_group

ERSのインスタンスファイルシステムがHA NFS サーバーによって提供される代替例では、ファイルシステムリソースのみが必要となります。 NFS サーバー に合わせて環境変数 ${NFS_VH} を定義し*、ERSインスタンスの* SAP インストール時に NFS ルートディレクトリの下に ${SID}/ERS ディレクトリを作成したことを確認してください。

pcs resource create ${sid}_fs_ers${ERS_INSTNO} Filesystem \
    device="${NFS_VH}:${SID}/ERS" \
    directory=/usr/sap/${SID}/ERS${ERS_INSTNO} \
    fstype=nfs \
    options="${NFS_OPTIONS}" \
    force_unmount=safe \
    op start interval=0 timeout=60 \
    op stop interval=0 timeout=120 \
    --group ${sid}_ers${ERS_INSTNO}_group

ERSインスタンスを管理するためのリソースを作成します。

pcs resource create ${sid}_ers${ERS_INSTNO} SAPInstance \
    InstanceName="${SID}_ERS${ERS_INSTNO}_${ERS_VH}" \
    START_PROFILE=/sapmnt/${SID}/profile/${SID}_ERS${ERS_INSTNO}_${ERS_VH} \
    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 ${sid}_ers${ERS_INSTNO}_group

クラスタリソースの制約を設定する

コロケーションの制約により、リソースグループ ${sid}_ascs${ASCS_INSTNO}_group と ${sid}_ers${ERS_INSTNO}_group は、可能な限り同じノード上でアクティブにならないようにしています。 -5000 のスティッキネススコアにより、単一のノードしか利用できない場合でも、同じノード上で実行されるようになっています。

pcs constraint colocation add \
    ${sid}_ers${ERS_INSTNO}_group with ${sid}_ascs${ASCS_INSTNO}_group -- -5000

順序制約により、リソースグループ ${sid}_ascs${ASCS_INSTNO}_group が ${sid}_ers${ERS_INSTNO}_group より前に開始することが制御されます。

pcs constraint order start \
    ${sid}_ascs${ASCS_INSTNO}_group then stop ${sid}_ers${ERS_INSTNO}_group \
    symmetrical=false \
    kind=Optional

次の2つの順序制約により、リソースグループ ${sid}_ascs${ASCS_INSTNO}_group と ${sid}_ers${ERS_INSTNO}_group が起動する前に、 SAPMNT がマウントするファイルシステムが確実に起動します。

pcs constraint order fs_sapmnt-clone then ${sid}_ascs${ASCS_INSTNO}_group

pcs constraint order fs_sapmnt-clone then ${sid}_ers${ERS_INSTNO}_group

クラスタのセットアップは完了しました。

SAP ENSA2 クラスターのテスト

クラスタが正しく動作していることを確認するためには、クラスタ構成を徹底的にテストすることが不可欠です。 以下の情報は、フェイルオーバーテストのいくつかのサンプルシナリオを提供していますが、テストシナリオの完全なリストではありません。

例えば、各テストケースの説明には、以下の情報が含まれています。

  • テスト対象コンポーネント
  • テストの説明
  • フェールオーバーテスト前の前提条件と初期状態
  • 試験手順
  • 期待される動作と結果
  • リカバリー手順

テスト1 - ASCSインスタンスの障害テスト

テスト1 - 説明

NODE1 で実行中の SAP の ASCS インスタンスのクラッシュをシミュレートします。

テスト1 - 前提条件

  • SAP ENSA2 用の機能的な2ノード RHEL HA アドオンクラスター。
  • 両方のクラスタノードが稼働中です。
  • NODE1 と NODE2 でクラスタが起動します。
    • リソースグループ ${sid}_ascs${ASCS_INSTNO}_group は NODE1 でアクティブです。
    • リソース ${sid}_vip_ascs$ {ASCS_INSTNO}、${sid}_fs_ascs${ASCS_INSTNO}_lvm、${sid}_fs_ascs$ {ASCS_INSTNO}、${sid}_ascs$ {ASCS_INSTNO} は、 Started on NODE1 です。
    • リソースグループ ${sid}_ers${ERS_INSTNO}_group は NODE2 でアクティブです。
    • リソース ${sid}_vip_ers$ {ERS_INSTNO}、${sid}_fs_ers${ERS_INSTNO}_lvm、${sid}_fs_ers$ {ERS_INSTNO}、${sid}_ers$ {ERS_INSTNO} は、 Started on NODE2 です。
  • SAP のインスタンスプロセスを確認する：
    • ASCS インスタンスは NODE1 で実行中です。
    • ERSインスタンスは NODE2 で実行中です。
pcs status

出力例:

# pcs status
Cluster name: SAP_ASCS
Cluster Summary:
  * Stack: corosync
  * Current DC: cl-sap-1 (version 2.0.5-9.el8_4.5-ba59be7122) - partition with quorum
  * Last updated: Tue Feb 14 07:59:16 2023
  * Last change:  Tue Feb 14 05:02:22 2023 by hacluster via crmd on cl-sap-1
  * 2 nodes configured
  * 11 resource instances configured

Node List:
  * Online: [ cl-sap-1 cl-sap-2 ]

Full List of Resources:
  * res_fence_ibm_powervs	(stonith:fence_ibm_powervs):	 Started cl-sap-2
  * Resource Group: s01_ascs01_group:
    * s01_vip_ascs01	(ocf::heartbeat:IPaddr2):	 Started cl-sap-1
    * s01_fs_ascs01_lvm	(ocf::heartbeat:LVM-activate):	 Started cl-sap-1
    * s01_fs_ascs01	(ocf::heartbeat:Filesystem):	 Started cl-sap-1
    * s01_ascs01	(ocf::heartbeat:SAPInstance):	 Started cl-sap-1
  * Resource Group: s01_ers02_group:
    * s01_vip_ers02	(ocf::heartbeat:IPaddr2):	 Started cl-sap-2
    * s01_fs_ers02_lvm	(ocf::heartbeat:LVM-activate):	 Started cl-sap-2
    * s01_fs_ers02	(ocf::heartbeat:Filesystem):	 Started cl-sap-2
    * s01_ers02	(ocf::heartbeat:SAPInstance):	 Started cl-sap-2
  * Clone Set: fs_sapmnt-clone [fs_sapmnt]:
    * Started: [ cl-sap-1 cl-sap-2 ]

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

テスト1 - テスト手順

SAP のASCSインスタンスをクラッシュさせるには、ユーザー ${sid}adm としてenqueサーバーにSIGKILLシグナルを送信します。

NODE1 で、キューイングサーバーの PID を特定します。

pgrep -af "(en|enq).sap"

特定したプロセスに SIGKILL シグナルを送信します。

出力例:

# pgrep -af "(en|enq).sap"
30186 en.sapS01_ASCS01 pf=/usr/sap/S01/SYS/profile/S01_ASCS01_cl-sap-scs
# kill -9 30186

テスト1 - 期待される動作

  • SAP NODE1 上の ASCS インスタンスがクラッシュ。
  • クラスタはクラッシュした ASCS インスタンスを検出します。
  • クラスタは、 NODE1 （仮想IPアドレス、ファイルシステム /usr/sap/${SID}/ASCS${ASCS_INSTNO}、LVMリソース）上の従属リソースを停止し、 NODE2 上でそれらを取得します。
  • クラスタは NODE2 で ASCS を開始します。
  • クラスタは、 NODE2* 上のERSインスタンス*を停止します。
  • クラスタは、 NODE1 （仮想IPアドレス、ファイルシステム /usr/sap/${SID}/ERS${ERS_INSTNO}、LVMリソース）上の従属リソースを停止し、 NODE1 上でそれらを取得します。
  • クラスタは NODE1* でERS* を開始します。

数秒後、次のコマンドでステータスを確認します。

pcs status

出力例:

# pcs status
Cluster name: SAP_ASCS
Cluster Summary:
  * Stack: corosync
  * Current DC: cl-sap-1 (version 2.0.5-9.el8_4.5-ba59be7122) - partition with quorum
  * Last updated: Tue Feb 14 08:10:18 2023
  * Last change:  Tue Feb 14 05:02:22 2023 by hacluster via crmd on cl-sap-1
  * 2 nodes configured
  * 11 resource instances configured

Node List:
  * Online: [ cl-sap-1 cl-sap-2 ]

Full List of Resources:
  * res_fence_ibm_powervs	(stonith:fence_ibm_powervs):	 Started cl-sap-2
  * Resource Group: s01_ascs01_group:
    * s01_vip_ascs01	(ocf::heartbeat:IPaddr2):	 Started cl-sap-2
    * s01_fs_ascs01_lvm	(ocf::heartbeat:LVM-activate):	 Started cl-sap-2
    * s01_fs_ascs01	(ocf::heartbeat:Filesystem):	 Started cl-sap-2
    * s01_ascs01	(ocf::heartbeat:SAPInstance):	 Started cl-sap-2
  * Resource Group: s01_ers02_group:
    * s01_vip_ers02	(ocf::heartbeat:IPaddr2):	 Started cl-sap-1
    * s01_fs_ers02_lvm	(ocf::heartbeat:LVM-activate):	 Started cl-sap-1
    * s01_fs_ers02	(ocf::heartbeat:Filesystem):	 Started cl-sap-1
    * s01_ers02	(ocf::heartbeat:SAPInstance):	 Started cl-sap-1
  * Clone Set: fs_sapmnt-clone [fs_sapmnt]:
    * Started: [ cl-sap-1 cl-sap-2 ]

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

テスト2 - ASCSインスタンスを実行しているノードの障害をテストする

ASCSインスタンスを実行しているノードの障害をテストするには、以下の情報をご利用ください。

テスト2 - 説明

ASCSインスタンスが実行されているノードのクラッシュをシミュレートします。

テスト2 - 前提条件

  • SAP ENSA2 用の機能的な2ノード RHEL HA アドオンクラスター。
  • 両方のクラスタノードが稼働中です。
  • NODE1 と NODE2 でクラスタが起動します。
    • リソースグループ ${sid}_ascs${ASCS_INSTNO}_group は NODE2 でアクティブです。
    • リソース ${sid}_vip_ascs$ {ASCS_INSTNO}、${sid}_fs_ascs${ASCS_INSTNO}_lvm、${sid}_fs_ascs$ {ASCS_INSTNO}、${sid}_ascs$ {ASCS_INSTNO} は、 Started on NODE2 です。
    • リソースグループ ${sid}_ers${ERS_INSTNO}_group は NODE1 でアクティブです。
    • リソース ${sid}_vip_ers$ {ERS_INSTNO}、${sid}_fs_ers${ERS_INSTNO}_lvm、${sid}_fs_ers$ {ERS_INSTNO}、${sid}_ers$ {ERS_INSTNO} は、 Started on NODE1 です。
  • SAP のインスタンスプロセスを確認する：
    • ASCS インスタンスは NODE2 で実行中です。
    • ERSインスタンスは NODE1 で実行中です。

テスト2 - テスト手順

NODE2 にクラッシュシステムリクエストを送信してクラッシュさせる。

NODE2 で、以下のコマンドを実行する。

sync; echo c > /proc/sysrq-trigger

テスト2 - 期待される動作

  • NODE2 再起動。
  • クラスタは故障したノードを検知し、その状態をオフライン（UNCLEAN）に設定します。
  • クラスタは、 NODE1 上の ASCSリソース （仮想IPアドレス、ファイルシステム /usr/sap/${SID}/ASCS${ASCS_INSTNO}、LVMアイテム）を取得します。
  • クラスタは NODE1 で ASCS を開始します。
  • クラスタは、 NODE1* 上のERSインスタンス*を停止します。
  • クラスタは、 NODE1 （仮想IPアドレス、ファイルシステム /usr/sap/${SID}/ERS${ERS_INSTNO}、LVMリソース）上の従属リソースを停止し、解放します。

しばらくしてから、以下のコマンドでステータスを確認します。

2番目のノードはオフラインで、両方のリソースグループは1番目のノード上で実行されています。

pcs status

出力例:

# pcs status
Cluster name: SAP_ASCS
Cluster Summary:
  * Stack: corosync
  * Current DC: cl-sap-1 (version 2.0.5-9.el8_4.5-ba59be7122) - partition with quorum
  * Last updated: Tue Feb 14 08:34:16 2023
  * Last change:  Tue Feb 14 08:34:04 2023 by hacluster via crmd on cl-sap-1
  * 2 nodes configured
  * 11 resource instances configured

Node List:
  * Online: [ cl-sap-1 ]
  * OFFLINE: [ cl-sap-2 ]

Full List of Resources:
  * res_fence_ibm_powervs	(stonith:fence_ibm_powervs):	 Started cl-sap-1
  * Resource Group: s01_ascs01_group:
    * s01_vip_ascs01	(ocf::heartbeat:IPaddr2):	 Started cl-sap-1
    * s01_fs_ascs01_lvm	(ocf::heartbeat:LVM-activate):	 Started cl-sap-1
    * s01_fs_ascs01	(ocf::heartbeat:Filesystem):	 Started cl-sap-1
    * s01_ascs01	(ocf::heartbeat:SAPInstance):	 Started cl-sap-1
  * Resource Group: s01_ers02_group:
    * s01_vip_ers02	(ocf::heartbeat:IPaddr2):	 Started cl-sap-1
    * s01_fs_ers02_lvm	(ocf::heartbeat:LVM-activate):	 Started cl-sap-1
    * s01_fs_ers02	(ocf::heartbeat:Filesystem):	 Started cl-sap-1
    * s01_ers02	(ocf::heartbeat:SAPInstance):	 Started cl-sap-1
  * Clone Set: fs_sapmnt-clone [fs_sapmnt]:
    * Started: [ cl-sap-1 ]
    * Stopped: [ cl-sap-2 ]

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

テスト2 - 回復手順

NODE2 が再起動するまで待ち、その後クラスタフレームワークを再起動します。

NODE1 で、以下のコマンドを実行する。

pcs cluster start
  • クラスタは NODE2 で起動し、 NODE2 で ERS リソース （仮想 IP アドレス、ファイルシステム /usr/sap/${SID}/ERS${ERS_INSTNO}、LVM リソース）を取得します。
  • クラスタは NODE2 上で ERSインスタンスを起動します。

しばらく待ってから、次のコマンドでステータスを確認してください。 ERSリソースグループは2番目のノードに移動しました。

pcs status

出力例:

# pcs status
Cluster name: SAP_ASCS
Cluster Summary:
  * Stack: corosync
  * Current DC: cl-sap-1 (version 2.0.5-9.el8_4.5-ba59be7122) - partition with quorum
  * Last updated: Tue Feb 14 08:41:23 2023
  * Last change:  Tue Feb 14 08:34:04 2023 by hacluster via crmd on cl-sap-1
  * 2 nodes configured
  * 11 resource instances configured

Node List:
  * Online: [ cl-sap-1 cl-sap-2 ]

Full List of Resources:
  * res_fence_ibm_powervs	(stonith:fence_ibm_powervs):	 Started cl-sap-1
  * Resource Group: s01_ascs01_group:
    * s01_vip_ascs01	(ocf::heartbeat:IPaddr2):	 Started cl-sap-1
    * s01_fs_ascs01_lvm	(ocf::heartbeat:LVM-activate):	 Started cl-sap-1
    * s01_fs_ascs01	(ocf::heartbeat:Filesystem):	 Started cl-sap-1
    * s01_ascs01	(ocf::heartbeat:SAPInstance):	 Started cl-sap-1
  * Resource Group: s01_ers02_group:
    * s01_vip_ers02	(ocf::heartbeat:IPaddr2):	 Started cl-sap-2
    * s01_fs_ers02_lvm	(ocf::heartbeat:LVM-activate):	 Started cl-sap-2
    * s01_fs_ers02	(ocf::heartbeat:Filesystem):	 Started cl-sap-2
    * s01_ers02	(ocf::heartbeat:SAPInstance):	 Started cl-sap-2
  * Clone Set: fs_sapmnt-clone [fs_sapmnt]:
    * Started: [ cl-sap-1 cl-sap-2 ]

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

テスト3 - ERSインスタンスの障害テスト

ERSインスタンスの障害をテストするには、以下の情報をご利用ください。

テスト3 - 説明

ERSインスタンスのクラッシュをシミュレートします。

テスト3 - 前提条件

  • SAP ENSA2 用の機能的な2ノード RHEL HA アドオンクラスター。
  • 両方のクラスタノードが稼働中です。
  • NODE1 と NODE2 でクラスタが起動します。
    • リソースグループ ${sid}_ascs${ASCS_INSTNO}_group は NODE1 でアクティブです。
    • リソース ${sid}_vip_ascs$ {ASCS_INSTNO}、${sid}_fs_ascs${ASCS_INSTNO}_lvm、${sid}_fs_ascs$ {ASCS_INSTNO}、${sid}_ascs$ {ASCS_INSTNO} は、 Started on NODE1 です。
    • リソースグループ ${sid}_ers${ERS_INSTNO}_group は NODE2 でアクティブです。
    • リソース ${sid}_vip_ers$ {ERS_INSTNO}、${sid}_fs_ers${ERS_INSTNO}_lvm、${sid}_fs_ers$ {ERS_INSTNO}、${sid}_ers$ {ERS_INSTNO} は、 Started on NODE2 です。
  • SAP のインスタンスプロセスを確認する：
    • ASCS インスタンスは NODE1 で実行中です。
    • ERSインスタンスは NODE2 で実行中です。

テスト3 - テスト手順

SAP ERS インスタンスに SIGKILL シグナルを送信してクラッシュさせます。

NODE2 で、キューに追加されたレプリケーションサーバーの PID を特定します。

pgrep -af "(er|enqr).sap"

特定したプロセスに SIGKILL シグナルを送信します。

出力例:

# pgrep -af "(er|enqr).sap"
2527198 er.sapS01_ERS02 pf=/usr/sap/S01/ERS02/profile/S01_ERS02_cl-sap-ers NR=01
# kill -9 2527198

テスト 3 - 期待される動作

  • SAP NODE2 上のキューイングレプリケーションサーバーはすぐにクラッシュします。
  • クラスタは停止した ERS を検出し、リソースを故障としてマークします。
  • クラスタは NODE2 上で ERSを再起動します。

以下のコマンドでステータスをチェックする。

pcs status

${sid}_ers${ERS_INSTNO} ERS リソースが2番目のノードで再起動しました。 pcs status コマンドを実行するのが早すぎると*、ERSリソース*が一時的に FAILED というステータスになる場合があります。

出力例:

# pcs status
Cluster name: SAP_ASCS
Cluster Summary:
  * Stack: corosync
  * Current DC: cl-sap-1 (version 2.0.5-9.el8_4.5-ba59be7122) - partition with quorum
  * Last updated: Tue Feb 14 08:50:53 2023
  * Last change:  Tue Feb 14 08:50:50 2023 by hacluster via crmd on cl-sap-2
  * 2 nodes configured
  * 11 resource instances configured

Node List:
  * Online: [ cl-sap-1 cl-sap-2 ]

Full List of Resources:
  * res_fence_ibm_powervs	(stonith:fence_ibm_powervs):	 Started cl-sap-1
  * Resource Group: s01_ascs01_group:
    * s01_vip_ascs01	(ocf::heartbeat:IPaddr2):	 Started cl-sap-1
    * s01_fs_ascs01_lvm	(ocf::heartbeat:LVM-activate):	 Started cl-sap-1
    * s01_fs_ascs01	(ocf::heartbeat:Filesystem):	 Started cl-sap-1
    * s01_ascs01	(ocf::heartbeat:SAPInstance):	 Started cl-sap-1
  * Resource Group: s01_ers02_group:
    * s01_vip_ers02	(ocf::heartbeat:IPaddr2):	 Started cl-sap-2
    * s01_fs_ers02_lvm	(ocf::heartbeat:LVM-activate):	 Started cl-sap-2
    * s01_fs_ers02	(ocf::heartbeat:Filesystem):	 Started cl-sap-2
    * s01_ers02	(ocf::heartbeat:SAPInstance):	 Started cl-sap-2
  * Clone Set: fs_sapmnt-clone [fs_sapmnt]:
    * Started: [ cl-sap-1 cl-sap-2 ]

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

テスト3 - 回復手順

NODE2 で、以下のコマンドを実行する。

pcs resource refresh

pcs status --full

テスト4 - ASCSインスタンスの手動移動のテスト

ASCSインスタンスの手動移動をテストするには、以下の情報をご利用ください。

テスト4 - 説明

SAP 制御コマンドを使用して、メンテナンス目的で ASCSインスタンスを他のノードに移動します。

テスト4 - 前提条件

  • SAP ENSA2 用の機能的な2ノード RHEL HA アドオンクラスター。
  • sap_cluster_connector がインストールされ、設定されました。
  • 両方のクラスタノードが稼働中です。
  • NODE1 と NODE2 でクラスタが起動します。
    • リソースグループ ${sid}_ascs${ASCS_INSTNO}_group は NODE1 でアクティブです。
    • リソース ${sid}_vip_ascs$ {ASCS_INSTNO}、${sid}_fs_ascs${ASCS_INSTNO}_lvm、${sid}_fs_ascs$ {ASCS_INSTNO}、${sid}_ascs$ {ASCS_INSTNO} は、 Started on NODE1 です。
    • リソースグループ ${sid}_ers${ERS_INSTNO}_group は NODE2 でアクティブです。
    • リソース ${sid}_vip_ers$ {ERS_INSTNO}、${sid}_fs_ers${ERS_INSTNO}_lvm、${sid}_fs_ers$ {ERS_INSTNO}、${sid}_ers$ {ERS_INSTNO} は、 Started on NODE2 です。
  • SAP のインスタンスプロセスを確認する：
    • ASCS インスタンスは NODE1 で実行中です。
    • ERSインスタンスは NODE2 で実行中です。

テスト4 - テスト手順

NODE1 にログインし、 sapcontrol を実行して*、ASCS インスタンス*を他のノードに移動します。

sudo -i -u ${sid}adm -- sh -c "sapcontrol -nr ${ASCS_INSTNO} -function HAFailoverToNode"

テスト4 - 期待される動作

  • sapcontrol sap-cluster-connector を通じてクラスタと通信します。
  • クラスタはリソースを移動するための位置制約を作成します。

以下のコマンドでステータスをチェックする。 ASCSリソースグループが2番目のノードに移動したことを念頭に置いてください。 pcs status コマンドを早急に実行すると、いくつかのリソース stopping および starting が表示される場合があります。

pcs status

出力例:

# pcs status
Cluster name: SAP_ASCS
Cluster Summary:
  * Stack: corosync
  * Current DC: cl-sap-1 (version 2.0.5-9.el8_4.5-ba59be7122) - partition with quorum
  * Last updated: Tue Feb 14 09:03:19 2023
  * Last change:  Tue Feb 14 09:01:40 2023 by s01adm via crm_resource on cl-sap-1
  * 2 nodes configured
  * 11 resource instances configured

Node List:
  * Online: [ cl-sap-1 cl-sap-2 ]

Full List of Resources:
  * res_fence_ibm_powervs	(stonith:fence_ibm_powervs):	 Started cl-sap-1
  * Resource Group: s01_ascs01_group:
    * s01_vip_ascs01	(ocf::heartbeat:IPaddr2):	 Started cl-sap-2
    * s01_fs_ascs01_lvm	(ocf::heartbeat:LVM-activate):	 Started cl-sap-2
    * s01_fs_ascs01	(ocf::heartbeat:Filesystem):	 Started cl-sap-2
    * s01_ascs01	(ocf::heartbeat:SAPInstance):	 Started cl-sap-2
  * Resource Group: s01_ers02_group:
    * s01_vip_ers02	(ocf::heartbeat:IPaddr2):	 Started cl-sap-1
    * s01_fs_ers02_lvm	(ocf::heartbeat:LVM-activate):	 Started cl-sap-1
    * s01_fs_ers02	(ocf::heartbeat:Filesystem):	 Started cl-sap-1
    * s01_ers02	(ocf::heartbeat:SAPInstance):	 Started cl-sap-1
  * Clone Set: fs_sapmnt-clone [fs_sapmnt]:
    * Started: [ cl-sap-1 cl-sap-2 ]

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

テスト4 - 回復手順

NODE2 で ASCSインスタンスがアクティブになるまでお待ちください。 5分後、クラスタは自動的に作成された場所の制約を削除します。

以下の手順では、手動で制約を削除する方法を説明します。

NODE2 で、以下のコマンドを実行する。

pcs constraint

出力例:

# pcs constraint
Location Constraints:
  Resource: s01_ascs01_group
    Constraint: cli-ban-s01_ascs01_group-on-cl-sap-1
      Rule: boolean-op=and score=-INFINITY
        Expression: #uname eq string cl-sap-1
        Expression: date lt 2023-02-08 09:33:50 -05:00
Ordering Constraints:
  start s01_ascs01_group then stop s01_ers02_group (kind:Optional) (non-symmetrical)
  start fs_sapmnt-clone then start s01_ascs01_group (kind:Mandatory)
  start fs_sapmnt-clone then start s01_ers02_group (kind:Mandatory)
Colocation Constraints:
  s01_ers02_group with s01_ascs01_group (score:-5000)
Ticket Constraints:

pcs resource clear ${sid}_ascs${ASCS_INSTNO}_group

場所の制約が解除されます

pcs constraint

出力例:

# pcs constraint
Location Constraints:
Ordering Constraints:
  start s01_ascs01_group then stop s01_ers02_group (kind:Optional) (non-symmetrical)
  start fs_sapmnt-clone then start s01_ascs01_group (kind:Mandatory)
  start fs_sapmnt-clone then start s01_ers02_group (kind:Mandatory)
Colocation Constraints:
  s01_ers02_group with s01_ascs01_group (score:-5000)
Ticket Constraints: