第4章 Pacemaker を使用した Red Hat High Availability クラスターの作成

以下の手順では、pcs を使用して、2 ノードの Red Hat High Availability クラスターを作成します。

この例では、クラスターを設定するために、システムに以下のコンポーネントを追加する必要があります。

  • クラスターを作成するのに使用する 2 つのノード。この例では、使用されるノードは z1.example.com および z2.example.com です。
  • プライベートネットワーク用のネットワークスイッチ。クラスターノード同士の通信、およびその他のクラスターハードウェア (ネットワーク電源スイッチやファイバーチャネルスイッチなど) との通信にプライベートネットワークを使用することが推奨されますが、必須ではありません。
  • クラスターの各ノード用のフェンスデバイス。この例では、APC 電源スイッチの 2 ポートを使用します。ホスト名は zapc.example.com です。

4.1. クラスターソフトウェアのインストール

以下の手順では、クラスターソフトウェアをインストールし、システムでクラスターの作成を構成するように設定します。

  1. クラスターの各ノードに、Red Hat High Availability Add-On ソフトウェアパッケージと、使用可能なすべてのフェンスエージェントを、High Availability チャンネルからインストールします。

    # yum install pcs pacemaker fence-agents-all

    または、次のコマンドを実行して、Red Hat High Availability Add-On ソフトウェアパッケージと、必要なフェンスエージェントのみをインストールすることもできます。

    # yum install pcs pacemaker fence-agents-model

    次のコマンドは、利用できるフェンスエージェントの一覧を表示します。

    # rpm -q -a | grep fence
    fence-agents-rhevm-4.0.2-3.el7.x86_64
    fence-agents-ilo-mp-4.0.2-3.el7.x86_64
    fence-agents-ipmilan-4.0.2-3.el7.x86_64
    ...
    警告

    Red Hat High Availability Add-On パッケージをインストールしたら、自動的に何もインストールされないように、ソフトウェア更新設定を行う必要があります。実行中のクラスターにインストールすると、予期しない動作が発生する可能性があります。詳細は「RHEL 高可用性またはレジリエントストレージクラスターにソフトウェアアップデートを適用するのに推奨されるプラクティス」を参照してください。

  2. firewalld デーモンを実行している場合は、次のコマンドを実行して、Red Hat High Availability Add-On で必要なポートを有効にします。

    注記

    firewalld デーモンがシステムにインストールされているかどうかを確認する場合は、rpm -q firewalld コマンドを実行します。firewalld デーモンがインストールされている場合は、firewall-cmd --state コマンドで、実行しているかどうかを確認できます。

    # firewall-cmd --permanent --add-service=high-availability
    # firewall-cmd --add-service=high-availability
    注記

    クラスターコンポーネントの理想的なファイアウォール設定は、ローカル環境によって異なります。ここでは、ノードに複数のネットワークインターフェースがあるかどうか、またはオフホストのファイアウォールがあるかどうかを検討しないといけない場合があります。この例では、Pacemaker クラスターで通常必要となるポートを開きますが、ローカル条件に合わせて変更する必要があります。「High Availability Add-On のポートの有効化」では、Red Hat High Availability Add-On で有効にするポートと、各ポートの使用目的を説明します。

  3. pcs を使用してクラスターの設定やノード間の通信を行うため、pcs の管理アカウントとなるユーザー ID hacluster のパスワードを各ノードに設定する必要があります。hacluster ユーザーのパスワードは、各ノードで同じにすることが推奨されます。

    # passwd hacluster
    Changing password for user hacluster.
    New password:
    Retype new password:
    passwd: all authentication tokens updated successfully.
  4. クラスターを設定する前に、各ノードで、システムの起動時に pcsd デーモンを起動できるように、デーモンを起動して有効にしておく必要があります。このデーモンは、pcs コマンドで動作し、クラスターのノード全体で設定を管理します。

    クラスターの各ノードで次のコマンドを実行して、システムの起動時に pcsd サービスが起動し、pcsd が有効になるように設定します。

    # systemctl start pcsd.service
    # systemctl enable pcsd.service

4.2. pcp-zeroconf パッケージのインストール (推奨)

クラスターを設定する際に、PCP (Performance Co-Pilot) ツールの pcp-zeroconf パッケージをインストールすることが推奨されます。PCP は、RHEL システムに推奨される Red Hat の resource-monitoring ツールです。pcp-zeroconf パッケージをインストールすると、PCP を実行してパフォーマンス監視データを収集して、フェンシング、リソース障害、およびクラスターを中断するその他のイベントの調査に役立てることができます。

注記

PCP が有効になっているクラスターデプロイメントには、/var/log/pcp/ を含むファイルシステムで PCPが取得したデータ用に十分な領域が必要です。PCP による一般的な領域使用はデプロイメントごとに異なりますが、通常 pcp-zeroconf のデフォルト設定を使用する場合は 10Gb で十分であり、環境によっては必要な量が少なくなることがあります。一般的なアクティビティーの 14 日間におけるこのディレクトリーの使用状況を監視すると、より正確な使用状況の概算値が得られます。

pcp-zeroconf パッケージをインストールするには、次のコマンドを実行します。

# yum install pcp-zeroconf

このパッケージは pmcd を有効にし、10 秒間隔でデータキャプチャーを設定します。

PCP データを確認する方法は、Red Hat カスタマーポータルの「Why did a RHEL High Availability cluster node reboot - how can I prevent it again」を参照してください。

4.3. 高可用性クラスターの作成

この手順では、z1.example.com ノードおよび z2.example.com ノードで構成される Red Hat High Availability Add-On クラスターを作成します。

  1. pcs を実行するノードで、クラスター内の各ノードに対して、pcs ユーザー hacluster を認証します。

    次のコマンドは、z1.example.comz2.example.com で構成される 2 ノードクラスターの両ノードに対して、z1.example.comhacluster ユーザーを認証します。

    [root@z1 ~]# pcs host auth z1.example.com z2.example.com
    Username: hacluster
    Password:
    z1.example.com: Authorized
    z2.example.com: Authorized
  2. z1.example.com で以下のコマンドを実行し、2 つのノード z1.example.comz2.example.com で構成される 2 ノードクラスター my_cluster を作成します。これにより、クラスター設定ファイルが、クラスターの両ノードに伝搬されます。このコマンドには --start オプションが含まれます。このオプションを使用すると、クラスターの両ノードでクラスターサービスが起動します。

    [root@z1 ~]# pcs cluster setup my_cluster --start z1.example.com z2.example.com
  3. クラスターサービスを有効にし、ノードの起動時にクラスターの各ノードでクラスターサービスが実行するようにします。

    注記

    使用している環境でクラスターサービスを無効のままにしておきたい場合などは、この手順を省略できます。この手順を行うことで、ノードがダウンした場合にクラスターやリソース関連の問題をすべて解決してから、そのノードをクラスターに戻すことができます。クラスターサービスを無効にしている場合は、ノードを再起動する時に、ノードで pcs cluster start コマンドを実行し、サービスを手動で起動する必要があります。

    [root@z1 ~]# pcs cluster enable --all

pcs cluster status コマンドを使用すると、クラスターの現在のステータスを表示できます。pcs cluster setup コマンドで --start オプションを使用してクラスターサービスを起動した場合は、クラスターが稼働するのに時間が少しかかる可能性があるため、クラスターとその設定で後続の動作を実行する前に、クラスターが稼働していることを確認する必要があります。

[root@z1 ~]# pcs cluster status
Cluster Status:
 Stack: corosync
 Current DC: z2.example.com (version 2.0.0-10.el8-b67d8d0de9) - partition with quorum
 Last updated: Thu Oct 11 16:11:18 2018
 Last change: Thu Oct 11 16:11:00 2018 by hacluster via crmd on z2.example.com
 2 Nodes configured
 0 Resources configured

...

4.4. 複数のリンクを使用した高可用性クラスターの作成

pcs cluster setup コマンドを使用して、各ノードにリンクをすべて指定することで、複数のリンクを持つ Red Hat High Availability クラスターを作成できます。

2 つのリンクを持つ 2 ノードクラスターを作成するコマンドの形式は、以下のとおりです。

pcs cluster setup cluster_name node1_name addr=node1_link0_address addr=node1_link1_address node2_name addr=node2_link0_address addr=node2_link1_address

複数のリンクを持つクラスタを作成する場合は、次に示す内容を検討してください。

  • addr=address パラメーターの順番は重要です。ノード名の後に指定する最初のアドレスは link0 に使用され、2 番目以降のアドレスは link1 以降に順に使用されます。
  • デフォルトのトランスポートプロトコルである knet トランスポートプロトコルを使用して、リンクを 8 つまで指定できます。
  • addr= パラメーターの数は、すべてのノードで同じでなければなりません。
  • RHEL 8.1 より、pcs cluster link add コマンド、pcs cluster link remove コマンド、pcs cluster link delete コマンド、および pcs cluster link update コマンドを使用して、既存クラスターのリンクを追加、削除、および変更できます。
  • シングルリンククラスターと同様、1 つのリンクで IPv4 アドレスと IPv6 アドレスを混在させないでください。ただし、1 つのリンクで IPv4 を実行し、別のリンクで IPv6 を実行することはできます。
  • シングルリンククラスターと同様、1 つのリンクで IPv4 アドレスと IPv6 アドレスが混在しない IPv4 アドレスまたは IPv6 アドレスで名前が解決される限り、アドレスを IP アドレスまたは名前として指定できます。

以下の例では、rh80-node1rh80-node2 で構成される my_twolink_cluster という名前の 2 ノードクラスターを作成します。rh80-node1 には、IP アドレス 192.168.122.201 を link0、192.168.123.201 を link1 としたインターフェースが 2 つあります。rh80-node2 には、IP アドレス 192.168.122.202 を link0、192.168.123.202 を link1 としたインターフェースが 2 つあります。

# pcs cluster setup my_twolink_cluster rh80-node1 addr=192.168.122.201 addr=192.168.123.201 rh80-node2 addr=192.168.122.202 addr=192.168.123.202

複数のリンクを持つ既存クラスターにノードを追加する方法は、「複数リンクを持つクラスターへのノードの追加」を参照してください。

複数のリンクを持つ既存クラスターのリンクを変更する方法は、「既存クラスターのリンクの追加および修正」を参照してください。

4.5. フェンシングの設定

クラスターの各ノードにフェンスデバイスを設定する必要があります。フェンスの設定コマンドおよびオプションに関する情報は「Red Hat High Availability クラスターでのフェンシングの設定」を参照してください。

フェンシングの概要と、Red Hat High Availability クラスターにおけるフェンシングの重要性は「RHEL 高可用性クラスターでフェンシングが重要なのはなぜですか?」を参照してください。

注記

フェンスデバイスを設定する場合は、そのデバイスが、クラスター内のノードまたはデバイスと電源を共有しているかどうかに注意する必要があります。ノードとそのフェンスデバイスが電源を共有していると、その電源をフェンスできず、フェンスデバイスが失われた場合は、クラスターがそのノードをフェンスできない可能性があります。このようなクラスターには、フェンスデバイスおよびノードに冗長電源を提供するか、または電源を共有しない冗長フェンスデバイスが存在する必要があります。SBD やストレージフェンシングなど、その他のフェンシング方法でも、分離した電源供給の停止時に冗長性を得られます。

ここでは、ホスト名が zapc.example.com の APC 電源スイッチを使用してノードをフェンスし、fence_apc_snmp フェンスエージェントを使用します。どちらのノードも同じフェンスエージェントでフェンシングされるため、pcmk_host_map オプションを使用して、両方のフェンスデバイスを 1 つのリソースとして設定できます。

pcs stonith create コマンドを使用して、stonith リソースとしてデバイスを設定し、フェンスデバイスを作成します。以下のコマンドは、z1.example.com ノードおよび z2.example.com ノードの fence_apc_snmp フェンスエージェントを使用する、stonith リソース myapc を設定します。pcmk_host_map オプションにより、z1.example.com がポート 1 にマップされ、z2.example.com がポート 2 にマップされます。APC デバイスのログイン値とパスワードはいずれも apc です。デフォルトでは、このデバイスは各ノードに対して、60 秒間隔で監視を行います。

また、ノードのホスト名を指定する際に、IP アドレスを使用できます。

[root@z1 ~]# pcs stonith create myapc fence_apc_snmp \
ipaddr="zapc.example.com" \
pcmk_host_map="z1.example.com:1;z2.example.com:2" \
login="apc" passwd="apc"

次のコマンドは、既存の STONITH デバイスのパラメーターを表示します。

[root@rh7-1 ~]# pcs stonith config myapc
 Resource: myapc (class=stonith type=fence_apc_snmp)
  Attributes: ipaddr=zapc.example.com pcmk_host_map=z1.example.com:1;z2.example.com:2 login=apc passwd=apc
  Operations: monitor interval=60s (myapc-monitor-interval-60s)

フェンスデバイスの設定後に、デバイスをテストする必要があります。フェンスデバイスをテストする方法は「フェンスデバイスのテスト」を参照してください。

注記

ネットワークインターフェースを無効にしてフェンスデバイスのテストを実行しないでください。フェンシングが適切にテストされなくなります。

注記

フェンシングを設定してクラスターが起動すると、タイムアウトに到達していなくても、ネットワークの再起動時に、ネットワークを再起動するノードのフェンシングが発生します。このため、ノードで意図しないフェンシングが発生しないように、クラスターサービスの実行中はネットワークサービスを再起動しないでください。

4.6. クラスター設定のバックアップおよび復元

次のコマンドを使用して、クラスター設定のバックアップを tarball に作成できます。ファイル名を指定しないと、標準出力が使用されます。

pcs config backup filename
注記

pcs config backup コマンドは、CIB に設定したようにクラスターの設定だけをバックアップします。リソースデーモンの設定は、このコマンドに含まれません。たとえば、クラスターで Apache リソースを設定すると、(CIB にある) リソース設定のバックアップが作成されますが、(/etc/httpd に設定したとおり) Apache デーモン設定と、そこで使用されるファイルのバックアップは作成されません。同様に、クラスターに設定されているデータベースリソースがある場合は、データベースそのもののバックアップが作成されません。ただし、データベースのリソース設定のバックアップ (CIB) は作成されます。

以下のコマンドを使用して、バックアップからすべてのノードのクラスター設定ファイルを復元します。ファイル名を指定しないと、標準入力が使用されます。--local オプションは、現在のノードにあるファイルだけを復元します。

pcs config restore [--local] [filename]

4.7. High Availability Add-On のポートの有効化

クラスターコンポーネントの理想的なファイアウォール設定は、ローカル環境によって異なります。ここでは、ノードに複数のネットワークインターフェースがあるかどうか、またはオフホストのファイアウォールがあるかどうかを検討しないといけない場合があります。

firewalld デーモンを実行している場合は、次のコマンドを実行して、Red Hat High Availability Add-On で必要なポートを有効にします。

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

ローカルの状況に合わせて開くポートを変更することが必要になる場合があります。

注記

firewalld デーモンがシステムにインストールされているかどうかを確認する場合は、rpm -q firewalld コマンドを実行します。firewalld デーモンをインストールしている場合は、firewall-cmd --state コマンドを使用して、そのデーモンが実行しているかどうかを確認できます。

表4.1「High Availability Add-On で有効にするポート」 では、Red Hat High Availability Add-On で有効にするポートを示し、ポートの使用目的を説明します。

表4.1 High Availability Add-On で有効にするポート

ポート必要になる場合

TCP 2224

すべてのノードに必要なデフォルトの pcsd ポートで必須 (pcsd Web UI で必要、ノード間通信で必須) です。/etc/sysconfig/pcsd ファイルの PCSD_PORT パラメーターを使用して pcsd を設定できます。

ポート 2224 を開いて、任意のノードの pcs が、それ自体も含め、クラスター内のすべてのノードに通信できるようにする必要があります。Booth クラスターチケットマネージャーまたはクォーラムデバイスを使用する場合は、Booth Arbiter、クォーラムデバイスなどのすべての関連ホストで、ポート 2224 を開く必要があります。

TCP 3121

クラスターに Pacemaker リモートノードがある場合に、すべてのノードで必須です。

完全なクラスターノードにある Pacemaker の pacemaker-based デーモンは、ポート 3121 で Pacemaker リモートノードの pacemaker_remoted デーモンへの通信を行います。クラスター通信に別のインターフェースを使用する場合は、そのインターフェースでポートを開くことのみが必要になります。少なくとも、ポートは、Pacemaker リモートノードの全クラスターノードに対して開いている必要があります。ユーザーは完全なノードとリモートノード間でホストを変換する可能性があるか、ホストのネットワークを使用してコンテナー内でリモートノードを実行する可能性があるため、すべてのノードにポートを開くと便利になる場合があります。ノード以外のホストにポートを開く必要はありません。

TCP 5403

corosync-qnetd で、クォーラムデバイスを使用するクォーラムデバイスホストで必須です。デフォルト値は、corosync-qnetd コマンドの -p オプションで変更できます。

UDP 5404-5412

ノード間の通信を容易にするために corosync ノードで必須です。ポート 5404-5412 を開いて、任意のノードの corosync が、それ自体も含め、すべてのノードと通信できるようにする必要があります。

TCP 21064

DLM が必要なリソースがクラスターに含まれる場合に、すべてのノードで必須です (例: GFS2)。

TCP 9929、UDP 9929

Booth チケットマネージャーを使用してマルチサイトクラスターを確立する場合に、同じノードから接続するために、すべてのクラスターノードと、Booth 仲裁ノードで開いている必要があります。


このページには機械翻訳が使用されている場合があります (詳細はこちら)。