このページは Cloud Translation API によって翻訳されました。

RHEL 上の SAP MaxDB の HA クラスタ構成ガイド

このガイドでは、アクティブ/パッシブクラスタ構成を使用して、 Google Cloudの Red Hat Enterprise Linux（RHEL）高可用性クラスタに SAP MaxDB システムをデプロイする方法について説明します。

Linux に単一ノード SAP MaxDB システムをデプロイするには、SAP MaxDB デプロイガイドをご覧ください。

このガイドは、SAP システムの Linux HA 構成に精通している SAP MaxDB の上級ユーザーを対象としています。

このガイドでデプロイするシステム

このガイドでは、次の手順について説明します。

障害発生時にトラフィックを再ルーティングするように内部パススルーネットワークロードバランサを構成する
RHEL に Pacemaker クラスタを構成して、フェイルオーバー中に SAP システムやその他のリソースを管理する

デプロイされたクラスタには、以下の機能が含まれます。

異なるゾーンにある 2 つの Compute Engine VM（SAP MaxDB のインスタンスを実行可能）
SAP MaxDB のインストール用のリージョン Persistent Disk。
Pacemaker 高可用性クラスタリソースマネージャー。
STONITH フェンシングメカニズム。

SAP NetWeaver の高可用性インストールについては、このガイドでは説明しません。

前提条件

SAP MaxDB 高可用性クラスタを作成する前に、次の前提条件を満たしていることを確認してください。

SAP MaxDB プランニングガイドを参照した。
Red Hat サブスクリプションを持っている。
個人または組織で Google Cloud アカウントを所有していて、SAP MaxDB をデプロイするプロジェクトを作成済みである。
データ所在地、アクセス制御、サポート担当者、規制要件に準拠しながら SAP ワークロードを実行する必要がある場合は、必要な Assured Workloads フォルダを作成する必要があります。詳細については、 Google Cloudでの SAP のコンプライアンスと主権管理をご覧ください。
プロジェクトメタデータで OS Login が有効になっている場合は、デプロイが完了するまで一時的に OS Login を無効にする必要があります。デプロイのために、次の手順によりインスタンスメタデータで SSH 認証鍵を構成します。OS Login が有効になっている場合、メタデータベースの SSH 認証鍵構成は無効になり、このデプロイは失敗します。デプロイが完了したら、再度 OS Login を有効にできます。

詳細情報
- OS Login を有効または無効にする
- メタデータベースの SSH 認証鍵を使用する VM に SSH 認証鍵を追加する

VM インスタンスが意図せずインターネットに公開されるのを防ぐため、次の推奨事項に従ってください。

NAT ゲートウェイを使用する。
不要な外部アクセスをすべてブロックするファイアウォールルールを作成する。
VM の作成時に次のことを行う。
- 各 VM にルーティングルールとファイアウォールルールで使用するネットワークタグを指定する。 Google Cloud が提供する Deployment Manager テンプレートを使用する場合は、networkTag: [TAG] を使用したタグを指定してください。
- 外部 IP を持たない VM を作成する。 Google Cloudが提供する Deployment Manager テンプレートを使用する場合は、publicIP: No を指定します。

ネットワークの作成

セキュリティ上の理由から、新しいネットワークを作成します。アクセスできるユーザーを制御するには、ファイアウォールルールを追加するか、別のアクセス制御方法を使用します。

プロジェクトにデフォルトの VPC ネットワークがある場合、デフォルトは使用せず、明示的に作成したファイアウォールルールが唯一の有効なルールとなるように、独自の VPC ネットワークを作成してください。

デプロイ中、VM インスタンスは通常、 Google Cloudの SAP 用エージェントをダウンロードするためにインターネットにアクセスする必要があります。 Google Cloudから入手できる SAP 認定の Linux イメージのいずれかを使用している場合も、ライセンスを登録して OS ベンダーのリポジトリにアクセスするために、VM インスタンスからインターネットにアクセスする必要があります。このアクセスをサポートするために、NAT ゲートウェイを配置し、VM ネットワークタグを使用して構成します。ターゲット VM に外部 IP がない場合でもこの構成が可能です。

ネットワークを設定するには:

Console

Google Cloud のコンソールで、[VPC ネットワーク] ページに移動します。
[VPC ネットワーク] に移動
[VPC ネットワークを作成] をクリックします。
ネットワークの名前を入力します。
命名規則に従って名前を付けてください。VPC ネットワークは、Compute Engine の命名規則を使用します。
[サブネット作成モード] で [カスタム] をクリックします。
[新しいサブネット] セクションで、サブネットに次の構成パラメータを指定します。
1. サブネットの名前を入力します。
2. [リージョン] で、サブネットを作成する Compute Engine のリージョンを選択します。
3. [IP スタックタイプ] で [IPv4（シングルスタック）] を選択し、CIDR 形式で IP アドレス範囲を入力します。（10.1.0.0/24 など）
  これはサブネットのプライマリ IPv4 範囲です。複数のサブネットワークを追加する場合は、ネットワーク内の各サブネットワークに重複しない CIDR IP 範囲を割り当ててください。各サブネットワークとその内部 IP 範囲は、単一のリージョンにマッピングされることに注意してください。
4. [完了] をクリックします。
さらにサブネットを追加するには、[サブネットを追加] をクリックして前の手順を繰り返します。ネットワークを作成した後で、ネットワークにさらにサブネットを追加できます。
[作成] をクリックします。

gcloud

Cloud Shell に移動します。
Cloud Shell に移動
カスタムサブネットワークモードで新しいネットワークを作成するには、次のコマンドを実行します。
```
gcloud compute networks create NETWORK_NAME --subnet-mode custom
```
NETWORK_NAME は、新しいネットワークの名前に置き換えます。命名規則に従って名前を付けてください。VPC ネットワークは、Compute Engine の命名規則を使用します。

デフォルトの自動モードでは、各 Compute Engine リージョンにサブネットが自動的に作成されます。この自動モードを使用しないようにするには、--subnet-mode custom を指定します。詳しくは、サブネット作成モードをご覧ください。
サブネットワークを作成し、リージョンと IP 範囲を指定します。
```
gcloud compute networks subnets create SUBNETWORK_NAME \
    --network NETWORK_NAME --region REGION --range RANGE
```
次のように置き換えます。
- SUBNETWORK_NAME: 新しいサブネットワークの名前
- NETWORK_NAME: 前の手順で作成したネットワークの名前。
- REGION: サブネットワークを配置するリージョン。
- RANGE: CIDR 形式で指定された IP アドレス範囲（例: 10.1.0.0/24）。
  複数のサブネットワークを追加する場合は、ネットワーク内の各サブネットワークに重複しない CIDR IP 範囲を割り当ててください。各サブネットワークとその内部 IP 範囲は、単一のリージョンにマッピングされることに注意してください。
必要に応じて前の手順を繰り返し、サブネットワークを追加します。

NAT ゲートウェイの設定

パブリック IP アドレスなしで 1 台以上の VM を作成する必要がある場合は、ネットワークアドレス変換（NAT）を使用して、VM がインターネットにアクセスできるようにする必要があります。Cloud NAT は、 Google Cloud の分散ソフトウェア定義マネージドサービスであり、VM からインターネットへのパケットの送信と、それに対応するパケットの受信を可能にします。また、別個の VM を NAT ゲートウェイとして設定することもできます。

プロジェクトに Cloud NAT インスタンスを作成する方法については、Cloud NAT の使用をご覧ください。

プロジェクトに Cloud NAT を構成すると、VM インスタンスはパブリック IP アドレスなしでインターネットに安全にアクセスできるようになります。

ファイアウォールルールの追加

デフォルトでは、暗黙のファイアウォールルールにより、Virtual Private Cloud（VPC）ネットワークの外部からの受信接続がブロックされます。受信側の接続を許可するには、VM にファイアウォールルールを設定します。VM との受信接続が確立されると、トラフィックはその接続を介して双方向に許可されます。

特定のポートへの外部アクセスを許可するファイアウォールルールや、同じネットワーク上の VM 間のアクセスを制限するファイアウォールルールも作成できます。VPC ネットワークタイプとして default が使用されている場合は、default-allow-internal ルールなどの追加のデフォルトルールも適用されます。追加のデフォルトルールは、同じネットワークであれば、すべてのポートで VM 間の接続を許可します。

ご使用の環境に適用可能な IT ポリシーによっては、データベースホストへの接続を分離するか制限しなければならない場合があります。これを行うには、ファイアウォールルールを作成します。

目的のシナリオに応じて、次の対象にアクセスを許可するファイアウォールルールを作成できます。

すべての SAP プロダクトの TCP/IP にリストされているデフォルトの SAP ポート。
パソコンまたは企業のネットワーク環境から Compute Engine VM インスタンスへの接続。使用すべき IP アドレスがわからない場合は、社内のネットワーク管理者に確認してください。

ファイアウォールルールを作成するには:

コンソール

Google Cloud コンソールで、Compute Engine の [ファイアウォール] ページに移動します。

[ファイアウォール] に移動
ページ上部の [ファイアウォールルールを作成] をクリックします。
- [ネットワーク] フィールドで、VM が配置されているネットワークを選択します。
- [ターゲット] フィールドで、このルールが適用される Google Cloud上のリソースを指定します。たとえば、[ネットワーク上のすべてのインスタンス] を指定します。 Google Cloud上の特定のインスタンスにルールを制限するには、[指定されたターゲットタグ] にタグを入力します。
- [ソースフィルタ] フィールドで、次のいずれかを選択します。
  - 特定の IP アドレスからの受信トラフィックを許可する場合は、[IP 範囲] を選択します。[ソース IP の範囲] フィールドで IP アドレスの範囲を指定します。
  - サブネット: 特定のサブネットワークからの受信トラフィックを許可する場合に使用します。次の [サブネット] フィールドにサブネットワーク名を指定します。このオプションを使用すると、3 層構成またはスケールアウト構成で VM 間のアクセスを許可できます。
- [プロトコルとポート] セクションで、[指定したプロトコルとポート] を選択して tcp:PORT_NUMBER を指定します。
[作成] をクリックしてファイアウォールルールを作成します。

gcloud

次のコマンドを使用して、ファイアウォールルールを作成します。

$ gcloud compute firewall-rules create firewall-name
--direction=INGRESS --priority=1000 \
--network=network-name --action=ALLOW --rules=protocol:port \
--source-ranges ip-range --target-tags=network-tags

VM のデプロイと MaxDB のインストール

HA クラスタの構成を開始する前に、HA クラスタのプライマリノードとセカンダリノードとして機能する VM インスタンスと SAP MaxDB システムを定義してデプロイします。

MaxDB のデプロイ用に VM を作成する

HA デプロイの一環として、2 つの Google Cloud Compute Engine VM を作成する必要があります。ガイドの Compute Engine インスタンスを作成して起動するを参照してください。

リージョン Persistent Disk は、E2、N1、N2、N2D マシンタイプの使用のみをサポートしています。詳細については、リージョン Persistent Disk ガイドをご覧ください。

サイズ設定に基づいて適切なマシンタイプを選択するには、SAP Note 2456432 - SAP applications on Google Cloud: Supported products and Google Cloud machine types をご覧ください。

ゾーン復元力を得るために、2 つの VM を別々のゾーンに作成し、次の最小要件を満たすようにします。

VM の詳細:
- Instance Name
- Zone - 優先ゾーン
- Machine Type - サイズに基づく
- Subnet - このリージョン用に作成されたサブネット名
次の API へのアクセススコープが少なくとも付与されているサービスアカウント。
- https://www.googleapis.com/auth/compute
- https://www.googleapis.com/auth/servicecontrol
- https://www.googleapis.com/auth/service.management.readonly
- https://www.googleapis.com/auth/logging.write
- https://www.googleapis.com/auth/monitoring.write
- https://www.googleapis.com/auth/trace.append
- https://www.googleapis.com/auth/devstorage.read_write
/usr/sap に使用する各 VM の追加ディスク（最小 20 GB）

SAP MaxDB 用にリージョンディスクを 1 つ作成する

このデプロイでは、1 つのリージョンディスクを使用して、/sapdb ディレクトリ内に MaxDB ファイルを保持します。

ディスクを作成します。リージョンディスクのレプリケーションゾーンが、2 つの VM を作成したゾーンと一致していることを確認します。

リージョンディスクを、MaxDB のインストールと構成タスクを実行する VM の 1 つにアタッチします。

SAP のインストール用に RHEL OS を準備する

SAP 製品のインストールには、特定のオペレーティングシステムの設定とパッケージが必要です。SAP Note: 2772999 - Red Hat Enterprise Linux 8.x: Installation and Configuration のガイドラインに沿って操作します。

このタスクは両方のノードで行う必要があります。

ファイルシステムを作成する

SSH を使用して両方のインスタンスに接続し、/usr/sap/SID マウントポイントと /sapdb マウントポイントを作成します。
```
# sudo mkdir -p /usr/sap/SID
# sudo mkdir -p /sapdb
```
mkfs を使用して、VM にアタッチされた 2 つの追加ディスクにファイルシステムを作成します。

この時点で、リージョンディスクはいずれかの VM にアタッチされるだけであるため、/sapdb ファイルシステムの作成は 1 回のみ行われます。
/etc/fstab ファイルを編集して、両方のノードで再起動時に常に /usr/sap/SID をマウントするようにします。
MaxDB のインストールを行うノードに /sapdb ファイルシステムを手動でマウントします。

ファイルシステムの作成とマウントについては、Linux VM で非ブートディスクをフォーマットしてマウントするをご覧ください。

LVM 構成を変更する

論理ボリューム管理（LVM）の設定を変更し、共有ボリュームグループ（VG）が常に 1 つのノードにのみアタッチされ、アクセスできるようにする必要があります。

これを行うには、両方のノードで次の手順を実行します。

root として /etc/lvm/lvm.conf ファイルを編集し、system_id_source の値を none から uname に変更します。

結果を確認します。

# grep -i system_id_source /etc/lvm/lvm.conf

次のような出力が表示されます。

# Configuration option global/system_id_source.
        system_id_source = "uname"

さらに、ノードが再起動したときに VM がクラスタで管理される VG を有効にしないように、/etc/lvm/lvm.conf 構成ファイルで次のパラメータに、クラスタで管理されない VG の完全な名前をカンマで区切って指定します。

注: デフォルトでは、このファイルに値は保持されていないため、パラメータ auto_activation_volume_list の使用方法を説明するセクションに移動して、手動で追加する必要があります。
たとえば、usrsap がクラスタで管理されていない VG 名である場合:
```
auto_activation_volume_list = [ usrsap ]
```
たとえば、クラスタで管理されていない VG が存在しない場合、このパラメータは空の値で追加する必要があります。
```
auto_activation_volume_list = [  ]
```

データベースと SAP Host Agent のインストール

オペレーティングシステムが構成されたら、SAP MaxDB データベースと SAP Host Agent をインストールできます。MaxDB は通常、統合されている SAP プロダクトとともにインストールされます。

インストールは、リージョン Persistent Disk をアタッチしたインスタンスでのみ 1 回のみ実行されます。

VM に SAP MaxDB をインストールするには:

Linux ベースの VM への SSH 接続を確立します。
SAP インストールガイドに従って、SAP Software Provisioning Manager（SWPM）、SAP プロダクトインストールメディア、MaxDB インストールメディアをダウンロードします。
SAP プロダクトの SAP インストールガイドに従って、SAP プロダクトと SAP MaxDB データベースをインストールします。追加のガイダンスについては、SAP MaxDB documentation をご覧ください。

追加のインストール情報については、SAP Note 1020175 - FAQ: SAP MaxDB installation, upgrade or applying a patch をご覧ください。

インストールが完了したら、次の検証を実行します。

sidadm ユーザーとして、MaxDB のステータスを確認します。
```
# dbmcli -d  SID -u control,password db_state
```
出力は次の例のようになります。
```
>dbmcli -d  MDB -u control, my_p4$$w0rd db_state
OK
State
ONLINE
```

x_server のステータスも確認します。

# x_server

出力は次の例のようになります。

>x_server
2024-10-23 19:01:43 11968 19744 INF  12916          Found running XServer on port 7200
2024-10-23 19:01:43 11968 19744 INF  13011            version 'U64/LIX86 7.9.10   Build 004-123-265-969'
2024-10-23 19:01:43 11968 19744 INF  13010            installation MDB  - path: /sapdb/MDB/db
2024-10-23 19:01:45 11971 13344 INF  12916          Found running sdbgloballistener on port 7210
2024-10-23 19:01:45 11971 13344 INF  13011            version 'U64/LIX86 7.9.10   Build 004-123-265-969'

SAP Host エージェントが実行されているかどうかを確認します。

# ps -ef | grep -i hostctrl

出力は次の例のようになります。

>ps -ef | grep -i hostctrl
root      1543     1  0 Oct18 ?        00:00:15 /usr/sap/hostctrl/exe/saphostexec pf=/usr/sap/hostctrl/exe/host_profile
sapadm    1550     1  0 Oct18 ?        00:03:00 /usr/sap/hostctrl/exe/sapstartsrv pf=/usr/sap/hostctrl/exe/host_profile -D
root      1618     1  0 Oct18 ?        00:03:48 /usr/sap/hostctrl/exe/saposcol -l -w60 pf=/usr/sap/hostctrl/exe/host_profile
mdbadm   12751 11261  0 19:03 pts/0    00:00:00 grep --color=auto -i hostctrl

インストールの検証後、MaxDB インスタンスと x_server を停止します。
```
# dbmcli -d SID -u control, and password db_offline
# x_server stop
```

インストール後のタスクの実行

SAP MaxDB インスタンスを使用する前に、次のデプロイ後の手順を実行することをおすすめします。

最新のパッチがある場合は、それを使用して SAP MaxDB ソフトウェアを更新します。
追加のコンポーネントをインストールします。
新しい SAP MaxDB データベースを構成してバックアップします。

詳細については、SAP MaxDB Database Administration をご覧ください。

SAP MaxDB システムが正常にデプロイされたら、HA クラスタを定義して構成します。

Cloud Load Balancing のフェイルオーバーサポートを構成する

フェイルオーバーをサポートする内部パススルーネットワークロードバランササービスは、ヘルスチェックサービスに基づいて、SAP MaxDB クラスタ内のアクティブホストにトラフィックをルーティングします。

仮想 IP の IP アドレスを予約する

仮想 IP（VIP）アドレスはフローティング IP アドレスとも呼ばれ、アクティブな SAP MaxDB システムに従います。ロードバランサは、VIP に送信されるトラフィックを、アクティブな SAP MaxDB システムをホストしている VM に転送します。

Cloud Shell を開きます。

Cloud Shell に移動
仮想 IP の IP アドレスを予約します。これは、アプリケーションが SAP MaxDB へのアクセスに使用する IP アドレスです。--addresses フラグを省略すると、指定したサブネット内の IP アドレスが自動的に選択されます。
```
$ gcloud compute addresses create VIP_NAME \
  --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
  --addresses VIP_ADDRESS
```
静的 IP の予約の詳細については、静的内部 IP アドレスの予約をご覧ください。

IP アドレスの予約を確認します。

$ gcloud compute addresses describe VIP_NAME \
  --region CLUSTER_REGION

出力は次の例のようになります。

address: 10.0.0.19
addressType: INTERNAL
creationTimestamp: '2024-10-23T14:19:03.109-07:00'
description: ''
id: '8961491304398200872'
kind: compute#address
name: vip-for-maxdb-ha
networkTier: PREMIUM
purpose: GCE_ENDPOINT
region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1
selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/addresses/vip-for-maxdb-ha
status: RESERVED
subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-subnet-us-central1

ホスト VM のインスタンスグループを作成する

Cloud Shell で 2 つの非マネージドインスタンスグループを作成し、プライマリホスト VM を 1 つのグループに、セカンダリホスト VM をもう一方のグループに割り当てます。

$ gcloud compute instance-groups unmanaged create PRIMARY_IG_NAME \
  --zone=PRIMARY_ZONE
$ gcloud compute instance-groups unmanaged add-instances PRIMARY_IG_NAME \
  --zone=PRIMARY_ZONE \
  --instances=PRIMARY_HOST_NAME
$ gcloud compute instance-groups unmanaged create SECONDARY_IG_NAME \
  --zone=SECONDARY_ZONE
$ gcloud compute instance-groups unmanaged add-instances SECONDARY_IG_NAME \
  --zone=SECONDARY_ZONE \
  --instances=SECONDARY_HOST_NAME

インスタンスグループが作成されたことを確認します。

$ gcloud compute instance-groups unmanaged list

出力は次の例のようになります。

NAME          ZONE           NETWORK          NETWORK_PROJECT        MANAGED  INSTANCES
maxdb-ha-ig-1  us-central1-a  example-network  example-project-123456 No       1
maxdb-ha-ig-2  us-central1-c  example-network  example-project-123456 No       1

Compute Engine ヘルスチェックを作成する

Cloud Shell で、ヘルスチェックを作成します。ヘルスチェックで使用するポートには、他のサービスと競合しないようにプライベート範囲の 49152～65535 を選択します。チェック間隔とタイムアウトの値は、Compute Engine のライブマイグレーションイベント中のフェイルオーバーの許容範囲を広げるために、デフォルトよりも少し長くなっています。必要に応じて値を調整できます。
```
$ gcloud compute health-checks create tcp HEALTH_CHECK_NAME --port=HEALTHCHECK_PORT_NUM \
  --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \
  --healthy-threshold=2
```

ヘルスチェックが作成されたことを確認します。

$ gcloud compute health-checks describe HEALTH_CHECK_NAME

出力は次の例のようになります。

checkIntervalSec: 10
creationTimestamp: '2023-10-23T21:03:06.924-07:00'
healthyThreshold: 2
id: '4963070308818371477'
kind: compute#healthCheck
name: maxdb-health-check
selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/maxdb-health-check
tcpHealthCheck:
 port: 60000
 portSpecification: USE_FIXED_PORT
 proxyHeader: NONE
timeoutSec: 10
type: TCP
unhealthyThreshold: 2

ヘルスチェック用のファイアウォールルールを作成する

プライベート範囲のポートのファイアウォールルールを定義して、Compute Engine のヘルスチェックで使用される IP 範囲（35.191.0.0/16 と 130.211.0.0/22）からホスト VM へのアクセスを許可します。詳細については、ヘルスチェック用のファイアウォールルールの作成をご覧ください。

ホスト VM にネットワークタグを追加します（まだ設定されていない場合）。このタグは、ファイアウォールルールのヘルスチェックで使用されます。

$ gcloud compute instances add-tags PRIMARY_HOST_NAME \
  --tags NETWORK_TAGS \
  --zone PRIMARY_ZONE
$ gcloud compute instances add-tags SECONDARY_HOST_NAME \
  --tags NETWORK_TAGS \
  --zone SECONDARY_ZONE

まだ作成していない場合は、ヘルスチェックを許可するファイアウォールルールを作成します。

$ gcloud compute firewall-rules create RULE_NAME \
  --network NETWORK_NAME \
  --action ALLOW \
  --direction INGRESS \
  --source-ranges 35.191.0.0/16,130.211.0.0/22 \
  --target-tags NETWORK_TAGS \
  --rules tcp:HLTH_CHK_PORT_NUM

例:

gcloud compute firewall-rules create  fw-allow-health-checks \
--network example-network \
--action ALLOW \
--direction INGRESS \
--source-ranges 35.191.0.0/16,130.211.0.0/22 \
--target-tags cluster-ntwk-tag \
--rules tcp:60000

ロードバランサとフェイルオーバーグループを構成する

ロードバランサのバックエンドサービスを作成します。

$ gcloud compute backend-services create BACKEND_SERVICE_NAME \
  --load-balancing-scheme internal \
  --health-checks HEALTH_CHECK_NAME \
  --no-connection-drain-on-failover \
  --drop-traffic-if-unhealthy \
  --failover-ratio 1.0 \
  --region CLUSTER_REGION \
  --global-health-checks

プライマリインスタンスグループをバックエンドサービスに追加します。

$ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --instance-group PRIMARY_IG_NAME \
  --instance-group-zone PRIMARY_ZONE \
  --region CLUSTER_REGION

セカンダリのフェイルオーバーインスタンスグループをバックエンドサービスに追加します。

$ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --instance-group SECONDARY_IG_NAME \
  --instance-group-zone SECONDARY_ZONE \
  --failover \
  --region CLUSTER_REGION

転送ルールを作成します。IP アドレスには、VIP 用に予約した IP アドレスを指定します。以下で指定されているリージョンの外部から SAP MaxDB システムにアクセスする必要がある場合は、定義に --allow-global-access フラグを含めます。
```
$ gcloud compute forwarding-rules create RULE_NAME \
  --load-balancing-scheme internal \
  --address VIP_ADDRESS \
  --subnet CLUSTER_SUBNET \
  --region CLUSTER_REGION \
  --backend-service BACKEND_SERVICE_NAME \
  --ports ALL
```
SAP MaxDB 高可用性システムへのリージョン間アクセスの詳細については、内部 TCP/UDP ロードバランシングをご覧ください。

ロードバランサの構成をテストする

バックエンドインスタンスグループはすぐには正常として登録されませんが、ヘルスチェックに応答するようにリスナーを設定することで、ロードバランサの構成をテストできます。リスナーを設定した後、ロードバランサが正しく構成されていれば、バックエンドインスタンスグループのステータスは正常に変わります。

以降のセクションでは、構成のテストに使用できるさまざまな方法について説明します。

`socat` ユーティリティでロードバランサをテストする

socat ユーティリティを使用して、ヘルスチェックポートを一時的にリッスンできます。

両方のホスト VM に socat ユーティリティをインストールします。
```
$ sudo yum install -y socat
```
socat プロセスを開始して、ヘルスチェックポートで 60 秒間リッスンします。
```
$ sudo timeout 60s socat - TCP-LISTEN:HLTH_CHK_PORT_NUM,fork
```

Cloud Shell で、ヘルスチェックがリスナーを検出するまで数秒待ってから、バックエンドインスタンスグループのヘルスチェックを行います。

$ gcloud compute backend-services get-health BACKEND_SERVICE_NAME \
  --region CLUSTER_REGION

出力は次のようになります。

---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/maxdb-ha-ig-1
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/maxdb-ha-vm-1
   ipAddress: 10.0.0.35
   port: 80
 kind: compute#backendServiceGroupHealth
---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/maxdb-ha-ig-2
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/maxdb-ha-vm-2
   ipAddress: 10.0.0.34
   port: 80
 kind: compute#backendServiceGroupHealth

ポート 22 を使用してロードバランサをテストする

ホスト VM で SSH 接続用にポート 22 が開いている場合、ヘルスチェッカーに応答できるリスナーを備えたポート 22 を使用するように、ヘルスチェッカーを一時的に編集できます。

ポート 22 を一時的に使用するには、次の手順に従います。

コンソールでヘルスチェックをクリックします。

[ヘルスチェック] ページに移動
[編集] をクリックします。
[ポート] 項目で、ポート番号を 22 に変更します。
[保存] をクリックし、1～2 分待ちます。

Cloud Shell で、バックエンドインスタンスグループのヘルスチェックを行います。

$ gcloud compute backend-services get-health BACKEND_SERVICE_NAME \
  --region CLUSTER_REGION

出力は次のようになります。

---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/maxdb-ha-ig-1
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/maxdb-ha-vm-1
   ipAddress: 10.0.0.35
   port: 80
 kind: compute#backendServiceGroupHealth
---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/maxdb-ha-ig-2
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/maxdb-ha-vm-2
   ipAddress: 10.0.0.34
   port: 80
 kind: compute#backendServiceGroupHealth

完了したら、ヘルスチェックのポート番号を元のポート番号に戻します。

Pacemaker を設定する

次の手順では、SAP MaxDB 用の Compute Engine VM に Pacemaker クラスタの Red Hat 実装を構成します。

この手順は、以下を含む高可用性クラスタを構成するための Red Hat のドキュメントに基づいています。

Google Cloud への Red Hat Enterprise Linux 7.6（以降）高可用性クラスタのインストールと構成

両方のノードにクラスタエージェントをインストールする

両方のノードで次の手順を行います。

root として、Pacemaker コンポーネントをインストールします。
```
# yum -y install pcs pacemaker fence-agents-gce resource-agents-gcp resource-agents-sap-hana
# yum update -y
```
Google 提供の RHEL-for-SAP イメージを使用している場合、これらのパッケージはすでにインストールされていますが、一部更新が必要な場合があります。
パッケージの一部としてインストールされる hacluster ユーザーのパスワードを設定します。
```
# passwd hacluster
```
プロンプトで、hacluster のパスワードを指定します。
Google Cloudが提供する RHEL イメージでは、OS ファイアウォールサービスがデフォルトで有効になっています。高可用性トラフィックを許可するようにファイアウォールサービスを構成します。
```
# firewall-cmd --permanent --add-service=high-availability
```
```
# firewall-cmd --reload
```
pcs サービスを起動し、起動時に有効化するように構成します。
```
# systemctl start pcsd.service
# systemctl enable pcsd.service
```

pcs サービスのステータスを確認します。

# systemctl status pcsd.service

出力は次のようになります。

● pcsd.service - PCS GUI and remote configuration interface
  Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; vendor preset: disabled)
  Active: active (running) since Sat 2023-10-23 21:17:05 UTC; 25s ago
    Docs: man:pcsd(8)
          man:pcs(8)
Main PID: 31627 (pcsd)
  CGroup: /system.slice/pcsd.service
          └─31627 /usr/bin/ruby /usr/lib/pcsd/pcsd
Oct 23 21:17:03 maxdb-ha-vm-1 systemd[1]: Starting PCS GUI and remote configuration interface...
Oct 23 21:17:05 maxdb-ha-vm-1 systemd[1]: Started PCS GUI and remote configuration interface.

両方のノードで必要なすべての HA サービスが有効化されており、起動していることを確認します。
```
# systemctl enable pcsd.service pacemaker.service corosync.service
```

/etc/hosts ファイルに、クラスタ内の両方のホストの完全なホスト名と内部 IP アドレスを追加します。次に例を示します。

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.0.0.40 maxdb-ha-vm-1.us-central1-a.c.example-project-123456.internal maxdb-ha-vm-1  # Added by Google
10.0.0.41 maxdb-ha-vm-2.us-central1-c.c.example-project-123456.internal maxdb-ha-vm-2
169.254.169.254 metadata.google.internal  # Added by Google

RHEL クラスタノードでの /etc/hosts ファイルの設定に関する Red Hat からの詳細情報については、https://access.redhat.com/solutions/81123 をご覧ください。

クラスタを作成する

いずれかのノードの root として、hacluster ユーザーを承認します。RHEL バージョンのタブをクリックすると、コマンドが表示されます。
RHEL 8 以降
```
# pcs host auth primary-host-name secondary-host-name
```
RHEL 7
```
# pcs cluster auth primary-host-name secondary-host-name
```
プロンプトが表示されたら、hacluster ユーザーに設定した hacluster ユーザー名とパスワードを入力します。

クラスタを作成します。

RHEL 8 以降

# pcs cluster setup cluster-name primary-host-name secondary-host-name

RHEL 7

# pcs cluster setup --name cluster-name primary-host-name secondary-host-name

corosync.conf のデフォルト設定を編集する

プライマリホストの /etc/corosync/corosync.conf ファイルを編集して、 Google Cloud上の HA クラスタのフォールトトレラントをテストするためのより適切な開始ポイントを設定します。

どちらのホストでも、任意のテキストエディタを使用して /etc/corosync/corosync.conf ファイルを編集用に開きます。
```
# /etc/corosync/corosync.conf
```
/etc/corosync/corosync.conf が新しいファイルまたは空の場合は、/etc/corosync/ ディレクトリでサンプルファイルを確認し、corosync ファイルの基礎として使用できます。
corosync.conf ファイルの totem セクションに、次のプロパティと RHEL のバージョンごとの推奨値を追加します。
RHEL 8 以降
- transport: knet
- token: 20000
- token_retransmits_before_loss_const: 10
- join: 60
- max_messages: 20
例:
```
totem {
version: 2
cluster_name: hacluster
secauth: off
transport: knet
token: 20000
token_retransmits_before_loss_const: 10
join: 60
max_messages: 20
}
...
```
RHEL 7
- transport: udpu
- token: 20000
- token_retransmits_before_loss_const: 10
- join: 60
- max_messages: 20
例:
```
totem {
version: 2
cluster_name: hacluster
secauth: off
transport: udpu
token: 20000
token_retransmits_before_loss_const: 10
join: 60
max_messages: 20
}
...
```
編集した corosync.conf ファイルを含むホストから、クラスタ全体に corosync 構成を同期します。
RHEL 8 以降
```
# pcs cluster sync corosync
```
RHEL 7
```
# pcs cluster sync
```
自動的に起動するようにクラスタを設定します。
```
# pcs cluster enable --all
```
```
# pcs cluster start --all
```
corosync-cmapctl ユーティリティを使用して、クラスタで新しい corosync 設定が有効なことを確認します。
```
# corosync-cmapctl
```

フェンスを設定する

Google Cloud が提供する RHEL イメージには、 Google Cloudに固有の fence_gce フェンスエージェントが含まれています。fence_gce を使用して、各ホスト VM のフェンスデバイスを作成します。

フェンシングアクションの後に適切なイベントのシーケンスを保証するには、VM のフェンス後に Corosync が再起動するようにオペレーティングシステムを構成します。また、遅延を考慮して、再起動の Pacemaker タイムアウトも調整します。

fence_gce フェンスエージェントで利用可能なすべてのオプションを確認するには、fence_gce -h を発行します。

フェンシングデバイスリソースを作成する

プライマリホストで root として以下を行います。

各ホスト VM にフェンスデバイスを作成します。

# pcs stonith create primary-fence-name fence_gce \
  port=primary-host-name \
  zone=primary-host-zone \
  project=project-id \
  pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
  op monitor interval="300s" timeout="120s" \
  op start interval="0" timeout="60s"
# pcs stonith create secondary-fence-name fence_gce \
  port=secondary-host-name \
  zone=secondary-host-zone \
  project=project-id \
  pcmk_reboot_timeout=300 pcmk_monitor_retries=4 \
  op monitor interval="300s" timeout="120s" \
  op start interval="0" timeout="60s"

各フェンスデバイスを他のホスト VM に対して制限します。

# pcs constraint location primary-fence-name avoids primary-host-name
# pcs constraint location secondary-fence-name avoids secondary-host-name

プライマリホストで root として、セカンダリフェンスデバイスをテストします。
1. セカンダリホスト VM をシャットダウンします。
```
# fence_gce -o off -n secondary-host-name --zone=secondary-host-zone
```
  コマンドが成功すると、セカンダリホスト VM への接続が失われ、その VM は Google Cloud コンソールの [VM インスタンス] ページで停止したものとして表示されます。ページの更新が必要になる場合があります。
2. セカンダリホスト VM を再起動します。
```
# fence_gce -o on -n secondary-host-name --zone=secondary-host-zone
```
セカンダリホストで root として、コマンド内のプライマリホストの値を使用し、前述の手順を繰り返してプライマリフェンスデバイスをテストします。

いずれかのホストで root として、クラスタのステータスを確認します。

# pcs status

クラスタステータスのリソースセクションに、次の例のようにフェンスリソースが表示されます。

[root@maxdb-ha-vm-2 ~]# pcs status
Cluster name: maxdb-ha-cluster
Stack: corosync
Current DC: maxdb-ha-vm-1 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
Last updated: Mon Jun 15 17:19:07 2020
Last change: Mon Jun 15 17:18:33 2020 by root via cibadmin on maxdb-ha-vm-1

2 nodes configured
2 resources configured

Online: [ maxdb-ha-vm-1 maxdb-ha-vm-2 ]

Full list of resources:

 STONITH-maxdb-ha-vm-1   (stonith:fence_gce):    Started maxdb-ha-vm-2
 STONITH-maxdb-ha-vm-2   (stonith:fence_gce):    Started maxdb-ha-vm-1

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

Corosync の再起動の遅延を設定する

両方のホストで、root として Corosync の起動を遅延させる systemd ドロップインファイルを作成し、フェンス付き VM の再起動後に適切な一連のイベントが行われるようにします。
```
systemctl edit corosync.service
```
このファイルに次の行を追加します。
```
[Service]
ExecStartPre=/bin/sleep 60
```
ファイルを保存し、エディタを終了します。
systemd マネージャー構成を再読み込みします。
```
systemctl daemon-reload
```

ドロップインファイルが作成されていることを確認します。

service corosync status

次の例に示すように、ドロップインファイルの行が表示されます。

● corosync.service - Corosync Cluster Engine
   Loaded: loaded (/usr/lib/systemd/system/corosync.service; disabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/corosync.service.d
           └─override.conf
   Active: active (running) since Tue 2021-07-20 23:45:52 UTC; 2 days ago

リスナーをインストールし、ヘルスチェックリソースを作成する

ヘルスチェックリソースを構成するには、まずリスナーをインストールする必要があります。

リスナーをインストールする

ロードバランサは、各ホストのヘルスチェックポートでリスナーを使用して、MaxDB インスタンスが実行されている場所を判断します。

両方のホストの root として、TCP リスナーをインストールします。以下の手順では、HAProxy をインストールしてリスナーとして使用します。
```
# yum install haproxy
```

構成ファイル haproxy.cfg を編集用に開きます。

# vi /etc/haproxy/haproxy.cfg

haproxy.cfg のデフォルト セクションで、mode を tcplog に変更します。

デフォルト セクションの後に、以下を追加して新しいセクションを作成します。

#---------------------------------------------------------------------
# Health check listener port for SAP MaxDB HA cluster
#---------------------------------------------------------------------
listen healthcheck
  bind *:healthcheck-port-num

バインドポートは、ヘルスチェックの作成時に使用したポートと同じです。

完了したら、次の例のように更新されます。

#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
  mode                    tcp
  log                     global
  option                  tcplog
  option                  dontlognull
  option http-server-close
  # option forwardfor       except 127.0.0.0/8
  option                  redispatch
  retries                 3
  timeout http-request    10s
  timeout queue           1m
  timeout connect         10s
  timeout client          1m
  timeout server          1m
  timeout http-keep-alive 10s
  timeout check           10s
  maxconn                 3000

#---------------------------------------------------------------------
# Set up health check listener for SAP MaxDB HA cluster
#---------------------------------------------------------------------
listen healthcheck
 bind *:60000

各ホストで root として、サービスを開始し、正しく構成されていることを確認します。
```
# systemctl start haproxy.service
```
Google Cloud コンソールの [ロードバランサ] ページで、ロードバランサのエントリをクリックします。

負荷分散ページ

[ロードバランサの詳細] ページの [バックエンド] セクションで、両方のホストで HAProxy サービスがアクティブな場合、各インスタンスグループエントリの [正常] の列に 1/1 が表示されます。
各ホストで、HAProxy サービスを停止します。
```
# systemctl stop haproxy.service
```
各ホストで HAProxy サービスを停止すると、各インスタンスグループの [正常] の列に 0/1 が表示されます。

後でヘルスチェックが構成されると、クラスタはアクティブノードのリスナーを再起動します。

ヘルスチェックリソースを作成する

HAProxy サービスのヘルスチェックリソースを、いずれかのホスト上で root として作成します。

# pcs resource create healthcheck_resource_name service:haproxy op monitor interval=10s timeout=20s —-group SAPMaxDB_Group

ヘルスチェックサービスが SAP MaxDB インスタンスと同じホスト上でアクティブであることを確認します。
```
# pcs status
```
ヘルスチェックリソースが MaxDB と同じホスト上にない場合は、次のコマンドを使用して移動します。
```
# pcs resource move healthcheck_resource_name target_host_name
# pcs resource clear healthcheck_resource_name
```
コマンド pcs resource clear は、リソースを新しいロケーションに残し、pcs resource move コマンドによって作成された不要なロケーション制約を削除します。

ステータスのリソースセクションは次の例のようになります。
```
Full list of resources:

STONITH-maxdb-ha-vm-1   (stonith:fence_gce):    Started maxdb-ha-vm-2
STONITH-maxdb-ha-vm-2   (stonith:fence_gce):    Started maxdb-ha-vm-1

Resource Group: SAPMaxDB_Group
  rsc_healthcheck_MDB    (service:haproxy):      Started maxdb-ha-vm-1
```

クラスタのデフォルトを設定する

移行のしきい値と継続性を設定して、障害が発生する前に試行するフェイルオーバーの回数を決定し、最初に現在のホストで再起動を試みるようにシステムを設定します。この処理は、1 つのノードに設定するだけで、クラスタに適用されます。

いずれかのホストの root として、リソースのデフォルトを設定します。
```
# pcs resource defaults resource-stickiness=1000
# pcs resource defaults migration-threshold=5000
```
プロパティ resource-stickiness は、サービスの運用が継続される可能性を制御します。値が大きいほど、サービスの継続性が高まります。1000 の値はサービスの継続性が高いことを意味します。

プロパティ migration-threshold は、サービスが別のホストにフェイルオーバーするまでに発生する必要がある障害の数を指定します。5,000 という値は、存続期間が短いエラー状況でのフェイルオーバーを回避するのに十分に高い値です。

リソースのデフォルトを確認するには、pcs resource defaults を入力します。
リソースのオペレーションタイムアウトのデフォルトを設定します。
```
# pcs resource op defaults timeout=600s
```
リソースのオペレーションのデフォルトを確認するには、pcs resource op defaults を入力します。
次のクラスタプロパティを設定します。
```
# pcs property set stonith-enabled="true"
# pcs property set stonith-timeout="300s"
```
プロパティの設定は、pcs property list で確認できます。

クラスタに MaxDB リソースを作成する

これらの手順を実行する前に、MaxDB と x_server が停止しており、/sapdb ファイルシステムがマウント解除されていることを確認します。

gcp-pd-move リソースを作成する

gcp-pd-move リソースは、クラスタフェイルオーバー時にノード間で永続ディスクを移動するためのリソースエージェントです。

いずれかのノードで root として次のコマンドを使用してリソースを作成します。

# pcs resource create pd_move_resource_name gcp-pd-move \
  disk_name=regional_pd_name mode="READ_WRITE" disk_scope=regional \
  op monitor interval=10s timeout=15s \
  op start interval=0s timeout=300s \
  op stop interval=0s timeout=15s \
  --group SAPMaxDB_Group

LVM リソースを作成する

LVM が有効なリソースエージェントは、ディスクを他のノードに移動した後に LVM を有効にするために使用されます。

いずれかのノードで root として次のコマンドを使用して、LVM リソースを作成します。

# pcs resource create lvm_resource_name LVM-activate \
  vgname=vgname_for_maxdb \
  vg_access_mode=system_id activation_mode=exclusive \
  --group SAPMaxDB_Group

次に例を示します。

# pcs resource create sapdb_lvm LVM-activate \
  vgname=sapdb vg_access_mode=system_id \
  activation_mode=exclusive \
  --group SAPMaxDB_Group

ファイルシステムリソースを作成する

ファイルシステムリソースは、フェイルオーバー操作中に /sapdb のマウントを解除し、別のノードにマウントするためにクラスタ内で使用されます。

いずれかのノードで root として次のコマンドを実行して、ファイルシステムリソースを作成します。

# pcs resource create fs_resource_name Filesystem \
  device=filesystem directory=/sapdb fstype=fs_type \
  --group SAPMaxDB_Group

次に例を示します。

# pcs resource create sapdb_FS Filesystem \
  device=/dev/mapper/sapdb-sapdblv directory=/sapdb fstype=ext4 \
  --group SAPMaxDB_Group

MaxDB リソースグループの準備

MaxDB リソースグループを有効にするには、次の手順を実施する必要があります。

MaxDB のインストールを行ったノードから他のノードにユーザーとグループを同期します。
1. SAP MaxDB ユーザーは、/etc/passwd のエントリをコピーしてノード間で同期する必要があります。次に例を示します。
```
 sdb:x:1002:1003:MaxDB User:/home/sdb:/bin/false
 madbadm:x:1003:1005:SAP System Administrator:/home/mdbadm:/bin/csh
```
2. 同様に、/etc/group のエントリをノード間でコピーして、SAP グループも同期する必要があります。次に例を示します。
```
 dba:x:1003:mdbadm
 sapsys:x:1005:
```

オペレーティングシステムのディレクトリに格納される MaxDB 固有のファイルを同期します。root ユーザーとして、次のコマンドを実行します。

# rsync -av /etc/services target_host:/etc/services
# rsync -av /home/* target_host:/home
# rsync -av --exclude=sapservices /usr/sap/* target_host:/usr/sap
# rsync -av --ignore-existing /usr/sap/sapservicestarget_host:/usr/sap/sapservices
# rsync -av /etc/init.d/sapinittarget_host:/etc/init.d/

# MaxDB specific files
# rsync -av /etc/opttarget_host:/etc
# rsync -av /var/lib/sdbtarget_host:/var/lib

2 番目のノードの SAP OS ユーザーの場合は、ホームディレクトリでそれぞれのホスト名を使用するように次の環境ファイルの名前を変更します。

mv .sapenv_maxdb-ha-vm-1.sh .sapenv_maxdb-ha-vm-2.sh
mv .sapenv_maxdb-ha-vm-1.csh .sapenv_maxdb-ha-vm-2.csh
mv .sapsrc_maxdb-ha-vm-1.sh  .sapsrc_maxdb-ha-vm-2.sh
mv .sapsrc_maxdb-ha-vm-1.csh  .sapsrc_maxdb-ha-vm-2.csh
mv .dbenv_maxdb-ha-vm-1.sh .sapenv_maxdb-ha-vm-2.sh
mv .dbenv_maxdb-ha-vm-1.csh .dbenv_maxdb-ha-vm-2.csh

SAPDatabase リソースエージェントは、データベースの停止または起動のために DB 固有のコマンドを使用せず、saphostctrl コマンドに依存しています。SAP Host Agent は、saphostctrl を使用して MAXDB を正常にモニタリングおよび制御するために、xuser エントリを作成する必要があります。詳細については、SAP Note 2435938 - SAP Host Agent SAP MaxDB: DBCredentials for DB connect をご覧ください。

root として次のコマンドを実行して、アクティブノードで SetDatabaseProperty を実行します。

/usr/sap/hostctrl/exe/saphostctrl -host primary-host-name -user sapadm password \
  -dbname SID -dbtype ada -function SetDatabaseProperty DBCredentials=SET \
  -dboption User=SUPERDBA -dboption Password=password

次のコマンドを使用してエントリをテストします。データベースが停止している場合でも、このコマンドでステータスを戻すことができるはずです。

/usr/sap/hostctrl/exe/saphostctrl -host secondary-host-name -dbname SID \
  -dbtype ada -function GetDatabaseStatus

saphostctrl エージェントコマンドは、MaxDB インストール時の xuser プログラムを使用します。2 番目のノードを準備するために、SAPMaxDB_group を maxdb-node-b に移動します。

任意のノードで、root として次のコマンドを実行します。
```
pcs resource move SAPMaxDB_group
```

作成した 4 つのリソース（ヘルスチェック、gcp-pd-move、LVM、ファイルシステム）が移行され、2 番目のノードで正常に起動したことを確認します。

いずれのノードでも、次のコマンドを使用して、実行されているアクションを確認できます。
```
watch pcs status
```

4 つのリソースすべてが 2 番目のノードで正常に起動したら、saphostctrl コマンドを実行します。

root として、次のコマンドを実行して、現在アクティブなノードで SetDatabaseProperty を実行します。

/usr/sap/hostctrl/exe/saphostctrl -host secondary-host-name -user sapadm password \
  -dbname SID -dbtype ada -function SetDatabaseProperty DBCredentials=SET \
  -dboption User=SUPERDBA -dboption Password=password

ノード b で、MaxDB と x_server を手動で起動し、それらが適切に起動できるかどうかを確認します。
```
# dbmcli -d SID -u control, and password db_online
# x_server start
```

SAP データベースのリソースを作成する次の手順に進みます。この時点でエラーが発生した場合は、データベースリソースを作成しないでください。

SAP MaxDB のリソースを作成する

RHEL Pacemaker は、SAP データベースリソースエージェントを使用して SAP データベースをモニタリングおよび制御します。

次のコマンドを使用して、SAPMaxDB_group が有効になっているノードにデータベースリソースを作成します。

# pcs resource create SAPDatabase_resource_name SAPDatabase \
  DBTYPE="ADA" SID="SID" STRICT_MONITORING="TRUE" \
  MONITOR_SERVICES="Database|x_server" AUTOMATIC_RECOVER="TRUE"
  --group SAPMaxDB_Group

最終的なクラスタリソースは pcs status を使用して確認できます。期待される結果は次のとおりです。

# pcs status
  Cluster name: maxdb-cluster
  Stack: corosync
  Current DC: maxdb-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
  Last updated: Wed Oct 23 02:04:32 2024
  Last change: Wed Oct 23 02:01:41 2024 by hacluster via crmd on maxdb-ha-vm-1

  2 nodes configured
  7 resource instances configured

  Online: [ maxdb-ha-vm-1 maxdb-ha-vm-2 ]

  Full list of resources:

  STONITH-maxdb-ha-vm-1  (stonith:fence_gce):    Started maxdb-ha-vm-2
  STONITH-maxdb-ha-vm-2  (stonith:fence_gce):    Started maxdb-ha-vm-1
  Resource Group: SAPMaxDB_Group
     healthcheck_maxdb  (service:haproxy):      Started maxdb-ha-vm-1
     sapdb_regpd        (ocf::heartbeat:gcp-pd-move):   Started maxdb-ha-vm-1
     lvm_sapdb  (ocf::heartbeat:LVM-activate):  Started maxdb-ha-vm-1
     sapdb_fs   (ocf::heartbeat:Filesystem):    Started maxdb-ha-vm-1
     MDB_SAPMaxDB       (ocf::heartbeat:SAPDatabase):   Started maxdb-ha-vm-1

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

フェイルオーバーをテストする

アクティブホストで障害をシミュレートして、クラスタをテストします。テストシステムを使用するか、システムをリリースする前に本番環境システムでテストを実施します。

テストの前にシステムをバックアップします。

次のようなさまざまな方法で障害をシミュレートできます。

MaxDB または x_server を手動で停止する
MaxDB または x_server プロセスを強制終了する
reboot（アクティブノード）
単一のネットワークインターフェースを持つインスタンスの場合は ip link set eth0 down
複数のネットワークインターフェースを持つインスタンスの場合は iptables ... DROP
echo c > /proc/sysrq-trigger

次の手順では、ip link set eth0 down または iptables を使用して、クラスタ内の 2 つのホスト間のネットワークの中断をシミュレートします。単一のネットワークインターフェースを持つインスタンスの場合は ip link コマンドを使用し、複数のネットワークインターフェースを持つインスタンスの場合は iptables コマンドを使用します。このテストでは、フェイルオーバーとフェンシングの両方を検証します。インスタンスに複数のネットワークインターフェースが定義されている場合は、セカンダリホストで iptables コマンドを使用します。プライマリホストがクラスタ通信に使用している IP に基づいて受信トラフィックと送信トラフィックをドロップし、プライマリへのネットワーク接続の損失をシミュレートします。

アクティブホストで、root としてネットワークインターフェースをオフラインにします。
```
# ip link set eth0 down
```
SSH を使用していずれかのホストに再接続し、root ユーザーに変更します。

pcs status と入力して、以前はパッシブだったホストにリージョン Persistent Disk がアタッチされ、MaxDB サービスが実行されていることを確認します。次の例に示すように、クラスタで自動再起動が有効になっているため、停止したホストが再起動し、パッシブホストの役割を引き継ぎます。

Cluster name: maxdb-ha-cluster
Stack: corosync
Current DC: maxdb-ha-vm-2 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
Last updated: Wed Oct 23 02:01:45 2024
Last change: Wed Oct 23 02:01:41 2024 by hacluster via crmdon maxdb-ha-vm-2

2 nodes configured
7 resources configured

Online: [ maxdb-ha-vm-1 maxdb-ha-vm-2 ]

Full list of resources:

STONITH-maxdb-ha-vm-1   (stonith:fence_gce):    Started maxdb-ha-vm-2
STONITH-maxdb-ha-vm-2   (stonith:fence_gce):    Started maxdb-ha-vm-1

Resource Group: SAPMaxDB_Group
 healthcheck_maxdb  (service:haproxy):      Started maxdb-ha-vm-2
 sapdb_regpd        (ocf::heartbeat:gcp-pd-move):   Started maxdb-ha-vm-2
 lvm_sapdb  (ocf::heartbeat:LVM-activate):  Started maxdb-ha-vm-2
 sapdb_fs   (ocf::heartbeat:Filesystem):    Started maxdb-ha-vm-2
 MDB_SAPMaxDB       (ocf::heartbeat:SAPDatabase):   Started maxdb-ha-vm-2

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

トラブルシューティング

RHEL 上の SAP システムの高可用性構成に関する問題のトラブルシューティングについては、SAP 高可用性構成のトラブルシューティングをご覧ください。

RHEL 上の SAP HANA のサポートを受ける

RHEL 上での SAP HANA 用の高可用性クラスタの問題を解決するには、必要な診断情報を収集し、Cloud カスタマーケアまでお問い合わせください。詳細については、RHEL の診断情報での高可用性クラスタをご覧ください。

RHEL 上の SAP MaxDB の HA クラスタ構成ガイド

このガイドでデプロイするシステム

前提条件

ネットワークの作成

Console

gcloud

NAT ゲートウェイの設定

ファイアウォール ルールの追加

コンソール

gcloud

VM のデプロイと MaxDB のインストール

MaxDB のデプロイ用に VM を作成する

SAP MaxDB 用にリージョン ディスクを 1 つ作成する

SAP のインストール用に RHEL OS を準備する

ファイルシステムを作成する

LVM 構成を変更する

データベースと SAP Host Agent のインストール

インストール後のタスクの実行

Cloud Load Balancing のフェイルオーバー サポートを構成する

仮想 IP の IP アドレスを予約する

ホスト VM のインスタンス グループを作成する

Compute Engine ヘルスチェックを作成する

ヘルスチェック用のファイアウォール ルールを作成する

ロードバランサとフェイルオーバー グループを構成する

ロードバランサの構成をテストする

socat ユーティリティでロードバランサをテストする

ポート 22 を使用してロードバランサをテストする

Pacemaker を設定する

両方のノードにクラスタ エージェントをインストールする

クラスタを作成する

RHEL 8 以降

RHEL 7

RHEL 8 以降

RHEL 7

corosync.conf のデフォルト設定を編集する

RHEL 8 以降

RHEL 7

RHEL 8 以降

RHEL 7

フェンスを設定する

フェンシング デバイス リソースを作成する

Corosync の再起動の遅延を設定する

リスナーをインストールし、ヘルスチェック リソースを作成する

リスナーをインストールする

ヘルスチェック リソースを作成する

クラスタのデフォルトを設定する

クラスタに MaxDB リソースを作成する

gcp-pd-move リソースを作成する

LVM リソースを作成する

ファイル システム リソースを作成する

MaxDB リソース グループの準備

SAP MaxDB のリソースを作成する

フェイルオーバーをテストする

トラブルシューティング

RHEL 上の SAP HANA のサポートを受ける

ファイアウォールルールの追加

SAP MaxDB 用にリージョンディスクを 1 つ作成する

Cloud Load Balancing のフェイルオーバーサポートを構成する

ホスト VM のインスタンスグループを作成する

ヘルスチェック用のファイアウォールルールを作成する

ロードバランサとフェイルオーバーグループを構成する

`socat` ユーティリティでロードバランサをテストする

両方のノードにクラスタエージェントをインストールする

フェンシングデバイスリソースを作成する

リスナーをインストールし、ヘルスチェックリソースを作成する

ヘルスチェックリソースを作成する

ファイルシステムリソースを作成する

MaxDB リソースグループの準備