SUSE Linux Enterprise Server の高可用性クラスタの構築

SUSE High Availability Extension（HAE）を使用する SUSE Linux® Enterprise（SLE）クラスタを実装するには、以下の情報と手順に従ってください。 このクラスタでは、 IBM® Power® Virtual Server のインスタンスがクラスタノードとして使用されます。

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

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

この情報は、 Power Virtual Server 上で SAP アプリケーションの高可用性環境の導入を計画している建築家および専門家を対象としています。 これは、既存の SAP または SUSE のドキュメントに代わるものではありません。

開始前に

作業を開始する前に、 IBM の「 SAP アプリケーションの高可用性の実装」 Power Virtual Server に記載されている、一般的な要件、製品ドキュメント、サポート記事、および SAP の注意事項を確認してください。

この構成では、SBDフェンシングとハードウェアウォッチドッグタイマーを組み合わせて使用しています。 プロファイル内の Power10 マシンタイプのいずれかを使用して仮想サーバーインスタンスを作成し、ハードウェアウォッチドッグのサポートを有効にしてください。

クラスタ用の仮想サーバーインスタンスを作成する

「 SAP HANA システム向けの Power Virtual Server インスタンスのデプロイ 」および「 SAP NetWeaver 向けの Power Virtual Server インスタンスのデプロイ 」に記載されている手順に従って、クラスタノードとして使用する仮想サーバーインスタンスを作成してください。

SLE 高可用性拡張機能のインストールに向けたノードの準備

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

各クラスタノードにrootユーザーとしてログインしてください。

hosts ファイルへのクラスタノードエントリの追加

両方のノードで、すべてのクラスタノードのIPアドレスを、完全修飾ホスト名および短縮ホスト名とともに、 /etc/hosts ファイルに追加してください。

詳細については、 SUSE Linux エンタープライズ高可用性管理ガイド の「 システム要件と推奨環境 」セクションにある「 ホスト名とIPアドレス 」を参照してください。

環境変数の設定

セットアップの手順を簡略化するために、root ユーザー用の環境変数をいくつか設定しておきましょう。 これらの環境変数は、この情報に記載されている後のオペレーティングシステムコマンドで使用されます。

両方のノードで、以下の環境変数が記載されたファイルを作成し、ご自身の環境に合わせて更新してください。

# General settings
export CLUSTERNAME="SAP_CLUSTER"         # Cluster name
# Virtual server instance 1
export NODE1=<HOSTNAME_1>                # Virtual server instance hostname
# Virtual server instance 2
export NODE2=<HOSTNAME_2>                # Virtual server instance hostname

SLE HAクラスタのインストールと設定

2ノードのクラスタを設定するには、以下の手順に従ってください。

この手順は、 SUSE のドキュメントおよび IBM Power Virtual Server 上の SAP アプリケーションに対する高可用性の実装　参考資料 に掲載されている記事に基づいています。

一部の手順は両方のノードで実行する必要がありますが、その他の手順は NODE1 または NODE2 のいずれかで実行可能です。

SUSE HAE ソフトウェアのインストール

以下の手順に従って、 SUSE のHAEリポジトリが利用可能であることを再確認し、必要なソフトウェアパッケージをインストールしてください。

SUSE のHAEリポジトリを確認する

  1. 両方のノードで次のコマンドを実行し、「 SUSE 」および「 Linux (R) Enterprise High Availability Extension」のリポジトリが有効になっていることを確認してください。

    zypper repos --show-enabled-only | grep High

    出力に「Pool」と「Updates」の両方のSLE HAEリポジトリが含まれている場合は、以下の手順をスキップしてください。 例 :

    • SUSE_Linux_Enterprise_High_Availability_Extension_ppc64le:SLE-Product-HA15-SP6-Pool
    • SUSE_Linux_Enterprise_High_Availability_Extension_ppc64le:SLE-Product-HA15-SP6-Updates

  2. HAE リポジトリが一覧に表示されていない場合は、 yast2 を実行して有効にしてください。

    • ソフトウェア
    • 追加製品
    • 追加
    • 登録サーバーからの拡張機能とモジュール
      • Yast2 「 Pool 」と「 Updates 」の両方のリポジトリをループ処理します
      • 両方のリポジトリを追加する
    • yast2 アプリケーションを終了する

  3. 完了したら、両方のノードで同じコマンドをもう一度実行してみてください。

    zypper repos --show-enabled-only | grep High

SLE HAEのリポジトリが2つとも掲載されています。

SLE HAE ソフトウェアパッケージのインストール

必要なソフトウェアパッケージをインストールするには、次のコマンドを実行してください。

両方のノードで、次のコマンドを実行してください。

zypper install -t pattern ha_sles

SLE 高可用性クラスタの設定

以下の情報に基づいて、SLEの高可用性クラスタを設定してください。

ハードウェア要件の確認

SLE 高可用性クラスタを構成するには、以下のハードウェア要件を参照してください。

詳細なハードウェア要件については、『 SUSE Linux Enterprise High Availability』のドキュメントにある「 インストールとセットアップのクイックスタート 」を参照してください。

  • クラスタノードとして機能する2つの仮想サーバーまたは論理パーティション。
  • Corosync用の2つ目のネットワーク通信チャネル、またはボンディングされたネットワークインターフェース。
  • STONITHブロックデバイス（SBD）として使用される共有ボリューム。
  • 信頼性の高いノードフェンシングを実現するハードウェアウォッチドッグタイマー。

共有ストレージボリュームの作成

IBM Cloud （ PowerVS ）のWebインターフェースを使用して、SBDデバイスとして使用する共有ボリュームを1つまたは3つ作成します。 SUSE 冗長性を確保するため、3つのボリュームを作成することを推奨します。 この情報は、単一のSBDディスクの作成について引き続き説明します。

複数のディスクを使用する場合は、必要に応じて各ボリュームについて以下の手順を繰り返してください。

  1. 「 Power Virtual Server 」の「ストレージボリューム」 ページに移動します。

  2. **「ボリュームの作成 (Create volume)」**をクリックします。

  3. 「 ストレージボリュームの作成 」フォームで、以下の情報を入力してください。

    • ボリュームの名前を入力してください。
    • 「 サイズ（GB） 」を 1 に設定します（デフォルト）。
    • 「 共有可能 」をオンに切り替えます。
    • 該当するチェックボックスにチェックを入れて、 _利用規約_に同意してください。

  4. 「 ボリュームの作成 」をクリックして完了させてください。

    次に、両方のクラスタノードにボリュームをマウントする必要があります。

  5. 最初のクラスタノードの論理パーティションを変更します。

  6. [ 既存のボリュームをアタッチ ] をクリックして、以前に作成した共有ボリュームをこのノードにアタッチします。

  7. 2番目のクラスタノードについても、同じ手順を繰り返します。

  8. 任意のノードで、次のコマンドを実行して、1 Gボリュームのデバイス名を特定します。

    multipath -l | grep -B1 'size=1G'

    multipath -l コマンドの出力が以下のようである場合：

    36005076813810264e800000000006f10 dm-0 IBM,2145
size=1G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw

  9. 共有ボリュームに関連付けられているデバイス名を確認するには、次のコマンドを実行してください。

    ls /dev/disk/by-id/wwn-0x6005076813810264e800000000006f10

    SBDデバイスは、クラスタが正常に動作するようにするため、すべてのクラスタノードで同じデバイス名である必要があります。

    今後の手順を簡略化するため、SBDデバイスのパスを環境変数としてエクスポートし、クラスタの初期化時に使用できるようにします。

    export SBD_DEVICE=/dev/disk/by-id/wwn-0x6005076813810264e800000000006f10

ハードウェアウォッチドッグの設定

Power10 の論理パーティションでは、ハードウェアウォッチドッグタイマーはデフォルトで有効になっています。 利用可能かどうかを確認するには、次のコマンドを実行してください。 

ls /dev/watchdog*

出力には、 /dev/watchdog と /dev/watchdog0 の 2 つのデバイスが表示されます。

ウォッチドッグデバイスが一覧にない場合は、次のコマンドを実行して、プロセッサの互換モードが Power10 に設定されていることを確認してください。

LD_SHOW_AUXV=1 /bin/true | grep _PLATFORM

出力結果の中から、以下のフィールドを探してください。

  • AT_BASE_PLATFORM – 実際のプロセッサの種類を表示します。
  • AT_PLATFORM – プロセッサの互換モードを表示します。

プロセッサの互換モードは、 Power10 に設定する必要があります。 以前のバージョンに設定されている場合、ハイパーバイザーのウォッチドッグは利用できません。

仲裁人

2ノードのクラスタの場合、仲裁役として3つ目のLPARを設定することを推奨します。 アービトレーターは、クラスターの一部ではない論理パーティションです。 これは、スプリットブレインのシナリオにおいてクラスタのクォーラムを特定できるようにするため、3つ目のインスタンスとしてQNetdサーバーをホストしています。 クラスタノードの数が偶数の場合、アービトレータはクォーラムにインスタンスを追加する役割を果たすため、不可欠です。

詳細については、 SUSE のドキュメント 「QDevice」および「QNetd 」を参照してください。

仲裁者は通常、クラスタが稼働し始めてから設定されます。 SUSE のドキュメントに記載されている「 crm cluster init qdevice 」のアプローチを使用してください。

時刻同期の設定

両方のクラスタノードは、正常な動作を確保するために時刻同期が必要です。 PowerVS, 上で論理パーティションが実行される場合、時刻の同期は Hardware Management Console （HMC）を通じて自動的に処理されます。 この設定では、chrony デーモンは必要ありません。

最初のクラスタノードの設定

SUSE Linux の「Enterprise High Availability Extension」インストールスクリプトは、クラスタ環境の多くの主要コンポーネントを自動的に設定します。

sudo crm cluster init --name "$CLUSTERNAME" --sbd-device "$SBD_DEVICE"

Enter キーを押してデフォルト値をそのまま使用するか、プロンプトが表示されたら「 y 」と入力して Enter キーを押してください。

INFO: Loading "default" profile from /etc/crm/profiles.yml
WARNING: chronyd.service is not configured to start at system boot.
Do you want to continue anyway (y/n)? y
INFO: The user 'hacluster' will have the login shell configuration changed to /bin/bash
Continue (y/n)? y
INFO: A new ssh keypair is generated for user hacluster.
INFO: Configuring csync2
INFO: Starting csync2.socket service on ths-3
INFO: BEGIN csync2 checking files
INFO: END csync2 checking files
INFO: Configure Corosync (unicast):
  This will configure the cluster messaging layer.  You will need
  to specify a network address over which to communicate (default
  is eth0's network, but you can use the network address of any
  active interface).
Address for ring0 [10.51.0.84]
Port for ring0 [5405]
INFO: Initializing SBD
INFO: Hawk cluster interface is now running. To see cluster status, open:
INFO:   https://10.51.0.84:7630/
INFO: Log in with username 'hacluster', password 'linux'
WARNING: You should change the hacluster password to something more secure!
INFO: Starting pacemaker.service on ths-3
INFO: BEGIN Waiting for cluster
...........                                                                     INFO: END Waiting for cluster
INFO: Loading initial cluster configuration
WARNING: "stonith-enabled" in crm_config is set to true, it was false
INFO: Configure Administration IP Address:
  Optionally configure an administration virtual IP
  address. The purpose of this IP address is to
  provide a single IP that can be used to interact
  with the cluster, rather than using the IP address
  of any specific cluster node.
Do you wish to configure a virtual IP address (y/n)? y
Virtual IP []10.51.0.12
INFO: BEGIN Configuring virtual IP (10.51.0.12)
.                                                                               INFO: END Configuring virtual IP (10.51.0.12)
INFO: Configure Qdevice/Qnetd:
  QDevice participates in quorum decisions. With the assistance of
  a third-party arbitrator Qnetd, it provides votes so that a cluster
  is able to sustain more node failures than standard quorum rules
  allow. It is recommended for clusters with an even number of nodes
  and highly recommended for 2 node clusters.
Do you want to configure QDevice (y/n)? n
INFO: Done (log saved to /var/log/crmsh/crmsh.log on ths-3)

クラスタは現在、1つのノードで稼働しています。

2番目のクラスタノードの設定

以下の情報を参照して、2番目のクラスタノードを設定してください。

  1. 2番目のクラスタノードにログインします。

  2. このノードを既存のクラスタに統合するには、ha-cluster-join コマンドを使用します。 このコマンドを実行するには、ユーザー アカウントと、クラスタの最初のノードのホスト名が必要です。

    sudo crm cluster join -u root -c $NODE1

  3. Enter キーを押してデフォルト値を確定するか、プロンプトが表示されたら「 y 」と入力して Enter キーを押してください。

    WARNING: chronyd.service is not configured to start at system boot.
Do you want to continue anyway (y/n)? y
INFO: The user 'hacluster' will have the login shell configuration changed to /bin/bash
Continue (y/n)? y
INFO: A new ssh keypair is generated for user hacluster.
INFO: Configuring csync2
INFO: Starting csync2.socket service
INFO: BEGIN csync2 syncing files in cluster
INFO: END csync2 syncing files in cluster
INFO: Merging known_hosts
Warning: Permanently added 'ths-4' (ED25519) to the list of known hosts.
INFO: BEGIN Probing for new partitions
INFO: END Probing for new partitions
Address for ring0 [10.51.0.230]
INFO: Got SBD configuration
INFO: Hawk cluster interface is now running. To see cluster status, open:
INFO:   https://10.51.0.230:7630/
INFO: Log in with username 'hacluster', password 'linux'
WARNING: You should change the hacluster password to something more secure!
INFO: Starting pacemaker.service on ths-4
INFO: BEGIN Waiting for cluster
..                                                                              INFO: END Waiting for cluster
INFO: BEGIN Adjusting sbd related timeout values
WARNING: "stonith-timeout" in crm_config is set to 83, it was 43
INFO: END Adjusting sbd related timeout values
INFO: Set property "priority" in rsc_defaults to 1
WARNING: "priority-fencing-delay" in crm_config is set to 60, it was 0
INFO: BEGIN Reloading cluster configuration
INFO: END Reloading cluster configuration
INFO: Done (log saved to /var/log/crmsh/crmsh.log on ths-4)

  4. SLE クラスタが実行中であることを確認するには、次のコマンドを実行してください。

    sudo crm status

    エラーが発生しなかった場合、出力の「 Node List 」セクションには両方のノードが表示され、「 Online 」としてリストされます。

    Node List:
  * Online: [ ths-3 ths-4 ]

    「 リソース 」セクションには、「 Started 」状態にある2つのリソースが一覧表示されています。これは、それらがアクティブであり、正常に動作していることを示しています。

    Full List of Resources:
  * stonith-sbd	(stonith:external/sbd):	 Started ths-3
  * admin-ip	(ocf::heartbeat:IPaddr2):	 Started ths-3

hacluster ユーザー ID のパスワードの設定

両方のノードで、以下のコマンドを実行して、hacluster ユーザー アカウントのパスワードを設定してください。

passwd hacluster

SBDの状態の確認

以下の情報を参照して、SBD_DEVICE 変数が設定されていることを確認してください。

クラスタノードのいずれかからSBDスロットの状態を確認するには、次のコマンドを実行してください。

sbd -d $SBD_DEVICE list

出力には両方のクラスタノードがリストされており、それぞれのステータスは「 clean 」となっています。これは、SBDメカニズムが正しく機能しており、保留中のフェンシング処理がないことを示しています。

フェンシングアクションの設定

デフォルトでは、フェンシングイベントが発生した後、フェンシング対象のノードは自動的に再起動されます。

ただし、別の方法として、ノードの電源を切り、障害の根本原因を調査した後に手動で起動するという方法もあります。

ノードを手動で起動することには、いくつかの利点があります。

  • これにより、根本的な問題が解消されない場合に発生しうる、不必要なフェンシングループを防ぐことができます。
  • これにより、各フェンシングイベントが確実に検知・対処され、クラスタの安定性と信頼性が向上します。

ノードの電源を切るようにフェンシングアクションを設定するには、次のコマンドを使用します。

sudo crm configure property stonith-action="off"

次のコマンドを使用して、現在のクラスタ構成を確認してください。

sudo crm configure show

フェンシング作業の試験

STONITHの設定をテストするには、いずれかのノードでフェンシング操作を手動で実行する必要があります。

  1. NODE2 を手動でフェンスするには、次のコマンドを実行してください。

    crm node fence ${NODE2}

  2. y と入力し、次のメッセージが表示されたら Enter キーを押して続行すると、処理が停止します。 NODE2:

    Fencing ths-4 will shut down the node and migrate any resources that are running on it! Do you want to fence ths-4  (y/n)? y

  3. NODE2 を起動し、クラスタへの再参加を待ってから、反対方向からのフェンシングをテストしてください。

    NODE2 で、次のコマンドを実行してください。

    crm status

  4. クラスタのステータスで両方のノードが「 Online 」と表示されたら、安定性を確保するため、約1分間待機してください。 次に、 NODE2 から、 NODE1 に対してフェンシング操作を開始します。以下のコマンドを実行すると、停止します。 NODE1:

    crm node fence ${NODE1}

  5. NODE1 を有効にし、ノード上でクラスタサービスを起動します。