IBM Cloud Docs
マルチゾーン環境での Red Hat Enterprise Linux High Availability Add-On クラスタの実装

マルチゾーン環境での Red Hat Enterprise Linux High Availability Add-On クラスタの実装

以下の情報と手順を使用して、 Red Hat Enterprise Linux (RHEL) High Availability Add-Onクラスタをマルチゾーン・リージョン環境に実装します。 クラスタは、クラスタノードとしてインスタンスを使用します。 IBM® Power® Virtual Server クラスタノードとして使用しています。 仮想サーバーインスタンスは、マルチゾーンリージョン内の異なるゾーンで実行されます。 このセットアップでは、 powervs-subnet クラスター リソース エージェントを使用して、マルチゾーン リージョン実装内のアプリケーションのサービス IP アドレスを管理します。 リソースエージェントは、同じマルチゾーン地域内の異なるゾーンの使用のみをサポートしています。 複数の地域にまたがる展開はサポートされていません。 マルチゾーン地域(MZR )と IBM Cloud 地域については、マルチゾーン地域と利用可能な場所の詳細をご覧ください。

この情報では、個々の仮想サーバーインスタンスをクラスターに変換する方法について説明しています。

これらの手順には、各クラスタノードに高可用性パッケージとエージェントをインストールすること、およびフェンシングデバイスの設定が含まれます。

この情報は、 Power Virtual Server 上で SAP アプリケーションの高可用性展開を計画しているアーキテクトや専門家を対象としています。 これは、既存の SAP または Red Hat のドキュメントを置き換えることを意図したものではありません。

開始前に

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

クラスタ用の仮想サーバ・インスタンスの作成

高可用性クラスタ用のインスタンスの作成 」の説明に従って、クラスタノードとして使用する仮想サーバインスタンスを作成します。

マルチゾーンリージョンの2つのゾーンに2つのワークスペースを作成します。 作成し、 Transit Gateway し、両方のワークスペースを接続に追加します。 各ワークスペースに仮想サーバーインスタンスを2つ作成します。

RHEL HAアドオンインストール用のノードの準備

次のセクションでは、クラスタノードの基本的な準備手順について説明します。 両方のノードで手順に従っていることを確認してください。

各クラスタノードにルートユーザーとしてログインします。

クラスタノードのエントリをホストファイルに追加する

両方のノードで、両方のノードのIPアドレスとホスト名を /etc/hosts ファイルに追加します。

詳細については 、「RHELクラスタノードでの /etc/hosts ファイルの設定 」を参照してください。

環境変数の準備

セットアッププロセスを簡素化するために、ルートユーザー用の環境変数をいくつか用意します。 これらの環境変数は、この情報では、後のオペレーティングシステムコマンドで使用されます。

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

# General settings
export CLUSTERNAME="SAP_CLUSTER"         # Cluster name

export APIKEY=<APIKEY>                   # API Key of the IBM Cloud IAM ServiceID for the fencing agent
export CLOUD_REGION=<CLOUD_REGION>       # Multizone region name
export PROXY_IP=<IP_ADDRESS>             # IP address of proxy server

# Workspace 1
export IBMCLOUD_CRN_1=<IBMCLOUD_CRN_1>   # Workspace CRN
export GUID_1=<GUID_1>                   # Workspace GUID

# Workspace 2
export IBMCLOUD_CRN_2=<IBMCLOUD_CRN_2>   # Workspace CRN
export GUID_2=<GUID_2>                   # Workspace GUID

# Virtual server instance 1
export NODE1=<HOSTNAME_1>                # Virtual server instance hostname
export POWERVSI_1=<POWERVSI_1>           # Virtual server instance id

# Virtual server instance 2
export NODE2=<HOSTNAME_2>                # Virtual server instance
export POWERVSI_2=<POWERVSI_2>           # Virtual server instance id

APIKEYIBMCLOUD_CRN_?GUID_?POWERVSI_? 変数の設定を見つけるには、 高可用性クラスタを構成するためのパラメータを収集する の手順に従ってください。

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

IBM Power Virtual Server の2ノードクラスタをセットアップするには、以下の手順に従います。

手順は 、 IBM Power Virtual Server リファレンス 上の SAP アプリケーションの高可用性の実装 に記載されている Red Hat 製品のドキュメントと記事に基づいています。

両方のノードでいくつかのステップを完了し、 NODE1 または NODE2 のどちらかでいくつかのステップを完了する必要があります。

RHEL HAアドオンソフトウェアのインストール

必要なソフトウェアパッケージをインストールする。 powervs-subnet リソースエージェントを使用するために必要なオペレーティングシステムの最小バージョンは、RHEL 9.2 です。

@serverグループはオペレーティングシステムにインストールされている必要があります。 このインストールは、 SAP アプリケーションの標準要件です。

RHEL HA リポジトリの確認

次のコマンドを使用して、両方のノードで適切なリポジトリが有効になっていることを確認してください。

dnf repolist

HAリポジトリが存在しない場合は、以下のコマンドを使用して有効にしてください。

subscription-manager repos \
    --enable="rhel-9-for-ppc64le-highavailability-e4s-rpms"
dnf clean all
dnf repolist

RHEL HAアドオンソフトウェアパッケージのインストール

次のコマンドを実行して、両方のノードに必要なソフトウェアパッケージをインストールします。

dnf install -y pcs pacemaker fence-agents-ibm-powervs

Red Hat Enterprise Linux リリースに依存する fence-agents-ibm-powervsパッケージの最小バージョンをインストールしていることを確認してください

RHEL 9
fence-agents-ibm-powervs-4.10.0-43.el9

RHEL HAアドオンクラスターの設定

以下の手順に従って、RHEL HAアドオンクラスタを設定してください。

ファイアウォールサービスの設定

RHEL ファイアウォールに高可用性サービスを追加します。 firewalld.service インストールされ、有効になっている場合。

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

firewall-cmd --permanent --add-service=high-availability
firewall-cmd --reload

PCSデーモンを起動する

PCSを介してRHEL HAアドオンクラスターを制御および設定するために使用されるPCSデーモンを起動します。

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

systemctl enable --now pcsd.service

PCSサービスが実行されていることを確認する。

systemctl status pcsd.service

ハクラスターユーザーIDのパスワード設定

ハクラスター・ユーザーIDのパスワードを設定する。

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

passwd hacluster

クラスタノードの認証

クラスタ内のノードの PCS デーモンに対してユーザー hacluster を認証するには、以下のコマンドを使用します。 コマンドは、前のステップで設定したパスワードの入力を求めます。

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

pcs host auth ${NODE1} ${NODE2} -u hacluster

クラスタノードの設定と起動

クラスタ構成ファイルを設定し、指定したノードに構成を同期します。

--start オプションもノード上でクラスタサービスを開始します。

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

pcs cluster setup ${CLUSTERNAME} --start ${NODE1} ${NODE2}
pcs status

フェンス装置を作成する

STONITHは「Shoot The Other Node In The Head」の頭文字を取ったもので、スプリットブレイン状況におけるデータの破損からデータを保護します。

RHEL HAアドオンプロダクションクラスタでは、STONITH(フェンシング)を有効にする必要があります。

Power Virtual Server クラスタ上のSTONITHデバイスでサポートされている唯一のエージェントは、fence agent fence_ibm_powervs です。

マルチゾーン領域内の2つのワークスペースそれぞれに対してフェンシングデバイスを設定する必要があります。 フェンスエージェントは、一般的な APIKEY および CLOUD_REGION パラメータを使用して 、Power Cloud API に接続します。 パラメータ IBMCLOUD_CRN_<n>GUID_<n>、およびインスタンスID POWERVSI_<n> はワークスペース固有です。 高可用性クラスタを構成するためのパラメータを収集する セクションで収集したパラメータを使用して、エージェントの起動をテストできます。

フェンシング対象の仮想サーバーインスタンスの特定

fence_ibm_powervsの リストオプションを使用して、2つのクラスタノードのインスタンスIDを識別および/または確認します。

任意のノードで、以下のコマンドを実行する。

fence_ibm_powervs \
    --token=${APIKEY} \
    --crn=${IBMCLOUD_CRN_1} \
    --instance=${GUID_1} \
    --region=${CLOUD_REGION} \
    --api-type=public \
    -o list
fence_ibm_powervs \
    --token=${APIKEY} \
    --crn=${IBMCLOUD_CRN_2} \
    --instance=${GUID_2} \
    --region=${CLOUD_REGION} \
    --api-type=public \
    -o list

仮想サーバーインスタンスがプライベートネットワークのみにアクセスできる場合は、 --api-type=private オプションを使用する必要があります。また、 --proxy オプションも必要です。

例:

fence_ibm_powervs \
    --token=${APIKEY} \
    --crn=${IBMCLOUD_CRN_1} \
    --instance=${GUID_1} \
    --region=${CLOUD_REGION} \
    --api-type=private \
    --proxy=http://${PROXY_IP}:3128 \
    -o list

以下の例では、 --api-type=private オプションを使用しています。

仮想サーバーインスタンス両方のステータスを確認する

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

time fence_ibm_powervs \
    --token=${APIKEY} \
    --crn=${IBMCLOUD_CRN_1} \
    --instance=${GUID_1} \
    --region=${CLOUD_REGION} \
    --plug=${POWERVSI_1} \
    --api-type=private \
    --proxy=http://${PROXY_IP}:3128 \
    -o status
time fence_ibm_powervs \
    --token=${APIKEY} \
    --crn=${IBMCLOUD_CRN_2} \
    --instance=${GUID_2} \
    --region=${CLOUD_REGION} \
    --plug=${POWERVSI_2} \
    --api-type=private \
    --proxy=http://${PROXY_IP}:3128 \
    -o status

仮想サーバーインスタンスに対するフェンスエージェントの status アクション --plug=<POWERVSI_n> は、その電源ステータスを表示します。

両方のノードで、2つのコマンドが Status: ON と報告しなければなりません。

time コマンドの出力は、STONITHデバイスのタイムアウトを選択する際に後で役立つ可能性があります。

-v フラグを追加すると、Power Cloud APIへの接続と仮想サーバーの電源状態の照会に関する詳細情報が表示されます。

ストーンイッシュデバイスの作成

次のコマンドは*、fence_ibm_powervs フェンシングエージェントの*デバイス固有のオプションを表示します。

pcs stonith describe fence_ibm_powervs

仮想サーバーインスタンスの両方に対して、stonithデバイスを作成します。

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

pcs stonith create fence_node1 fence_ibm_powervs \
    token=${APIKEY} \
    crn=${IBMCLOUD_CRN_1} \
    instance=${GUID_1} \
    region=${CLOUD_REGION} \
    api_type=private \
    proxy=http://${PROXY_IP}:3128 \
    pcmk_host_map="${NODE1}:${POWERVSI_1}" \
    pcmk_reboot_timeout=600 \
    pcmk_monitor_timeout=600 \
    pcmk_status_timeout=60
pcs stonith create fence_node2 fence_ibm_powervs \
    token=${APIKEY} \
    crn=${IBMCLOUD_CRN_2} \
    instance=${GUID_2} \
    region=${CLOUD_REGION} \
    api_type=private \
    proxy=http://${PROXY_IP}:3128 \
    pcmk_host_map="${NODE2}:${POWERVSI_2}" \
    pcmk_reboot_timeout=600 \
    pcmk_monitor_timeout=600 \
    pcmk_status_timeout=60

fence_ibm_powervs エージェントは、コマンドラインから起動された場合、オプションとして api-type を使用しますが、stonith リソースは api_type を使用して作成する必要があります。

以下のコマンドで構成を確認します。

pcs config
pcs status
pcs stonith config
pcs stonith status

stonith-actionクラスタプロパティの設定

powervs-subnet リソースエージェントを動作させるには*、stonith-action* クラスタープロパティを off に設定する必要があります。 クラスタがフェンシング操作を実行すると、フェンシングされたインスタンス の再起動ではなく、 オフ操作がトリガーされます。

この変更後は、 IBM Cloud コンソールに必ずログインし、クラスタによってフェンスされたインスタンスを手動で起動する必要があります。

pcs property set stonith-action=off

変更を確認します。

pcs config

フェンスの操作テスト

STONITH構成をテストするには、手動でノードをフェンスで囲みます。

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

pcs stonith fence ${NODE2}
pcs status

結果として、 NODE2 は停止します。

NODE2 を起動し、ノード上でクラスタを起動し、 NODE1 をフェンス化してみてください。

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

pcs cluster start
pcs status
pcs stonith status
pcs stonith fence ${NODE1}

NODE1 停止する。

NODE2 を起動し、ノード上でクラスタを起動します。

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

pcs cluster start
pcs status
pcs stonith status

サーバー起動時のクラスタサービスの自動起動を無効にする

仮想サーバーインスタンスが再起動した後、 そのステータスが 「ACTIVE」 になり、 ヘルスステータスが 「OK」 になるまでには時間がかかります。 powervs-subnet リソースエージェントが適切に機能するには、これらの状態が必要です。 したがって、クラスターの自動起動を無効にし、インスタンスが要求された状態に達した後に手動でクラスターを起動する必要があります。

どのノードでも、起動時のクラスタサービスの自動起動を無効にします。

pcs cluster disable --all

インスタンスを再起動する際は、 IBM Cloud コンソールでインスタンスのステータスを確認し、 ステータスフィールドが 「アクティブ」 で緑色のチェックマークが表示されるまでお待ちください。 次に、以下のコマンドを使用してクラスタを手動で起動します。

pcs cluster start

仮想IPアドレスリソース用にマルチゾーンRHEL HAアドオンクラスターを準備する

以下の手順に従って、仮想 IP アドレスリソース用のマルチゾーン RHEL HA アドオンクラスターを準備します。

オペレーティングシステムの要件を確認する

NetworkManager-config-server パッケージがインストールされていることを確認してください。

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

dnf list NetworkManager-config-server

出力例:

# dnf list NetworkManager-config-server
Installed Packages
NetworkManager-config-server.noarch                                    1:1.42.2-16.el9_2                                     @rhel-9-for-ppc64le-baseos-e4s-rpms

NetworkManager no-auto-default 構成変数が * に設定されていることを確認してください。

NetworkManager --print-config | grep "no-auto-default="

出力例:

# NetworkManager --print-config | grep "no-auto-default="
no-auto-default=*

no-auto-default* 以外の値を表示している場合は、 /etc/NetworkManager/conf.d/00-server.conf ファイルを編集し、必要に応じて変数を変更してください。

powervs-subnetリソースエージェントのインストール

現在、 powervs-subnet リソースエージェントは、 ClusterLabs GitHub リソースエージェントリポジトリで入手可能です。

https://github.com/ClusterLabs/resource-agents/blob/main/heartbeat/powervs-subnet.in からリソースエージェントをダウンロードし、両方のノードの /tmp ディレクトリにコピーを配置します。

両方のノードで、スクリプトを OCF リソースエージェントの heartbeat ディレクトリにインストールし、その権限を設定します。

sed -e 's|#!@PYTHON@|#!/usr/bin/python3|' /tmp/powervs-subnet.in \
     > /usr/lib/ocf/resource.d/heartbeat/powervs-subnet
chmod 755 /usr/lib/ocf/resource.d/heartbeat/powervs-subnet

次のコマンドを使用して、インストールを確認し、リソースエージェントの簡単な説明を表示します。

pcs resource describe powervs-subnet

powervs-subnet リソースエージェント用のサービスIDの作成

IBM Cloud の「カスタムロール、サービスID、およびAPIキーの作成 」の手順に従って、 powervs-subnet リソースエージェント用の Service IDAPI key を作成します。

結論

これで、クラスタの基本的な実装と、 powervs-subnet クラスタリソースを作成するための必要な準備が完了しました。 powervs-subnet クラスタリソース自体は、特定の高可用性シナリオの構成中に作成されます。

これで、計画した高可用性シナリオの具体的な手順に進むことができます。