9.3. pacemaker_remote サービス

pacemaker_remote サービスを使用すると、corosync を実行していないノードをクラスターに統合し、それらのノードのリソースはクラスターによって実際のクラスターノードと同様に管理されます。
pacemaker_remote サービスが提供する機能には以下が含まれます。
  • pacemaker_remote サービスは corosync の 16 ノード制限を超えた拡張を可能にします。
  • pacemaker_remote サービスを使用すると、仮想環境をクラスターリソースとして管理でき、さらに仮想環境内の個別のサービスをクラスターリソースとして管理できます。
pacemaker_remote サービスは以下の用語を使用して記述されます。
  • cluster node: 高可用性サービスを実行しているノード (pacemaker および corosync)。
  • remote node: corosync クラスターメンバーシップを必要としないクラスターにリモートで統合するために pacemaker_remote を実行しているノード。リモートノードは、ocf:pacemaker:remote リソースエージェントを使用するクラスターリソースとして設定されます。
  • guest node: pacemaker_remote サービスを実行している仮想ゲストノード。ゲストノードは、ocf:pacemaker:VirtualDomain などのリソースエージェントの remote-node メタデータオプションを使用して設定されます。仮想ゲストリソースはクラスターによって管理されます。仮想ゲストリソースはクラスターによって開始され、リモートノードとしてクラスターに統合されます。
  • pacemaker_remote: Pacemaker クラスター環境のリモートノードおよびゲストノード (KVM および LXC) 内でリモートアプリケーション管理を実行できるサービスデーモン。このサービスは、corosync を実行していないノード上でリソースをリモートで管理できる Pacemaker のローカルリソース管理デーモン (LRMD) の強化バージョンです。
  • LXClibvirt-lxc Linux コンテナードライバーで定義される Linux Container
pacemaker_remote サービスを実行している Pacemaker クラスターには次のような特徴があります。
  • リモートノードおよびゲストノードは pacemaker_remote サービスを実行します (仮想マシン側で必要な設定はほとんどありません)。
  • クラスターノードで実行しているクラスタースタック (pacemaker および corosync) はリモートノード上で pacemaker_remote サービスに接続するため、クラスターに統合することができます。
  • クラスターノードで実行しているクラスタースタック (pacemaker および corosync) はゲストノードを開始し、ゲストノード上で pacemaker_remote サービスに即座に接続するため、クラスターに統合することができます。
クラスターノードと、クラスターノードが管理するリモートおよびゲストノードの主な違いは、リモートおよびゲストノードはクラスタースタックを実行しないことです。そのため、リモートおよびゲストノードには以下の制限があります。
  • クォーラムで実行されません
  • フェンスデバイスのアクションを実行しません
  • クラスターの指定コントローラー (DC) にはなれません
  • pcs コマンドのすべてを実行できません
その一方で、リモートノードおよびゲストノードはクラスタースタックに関連するスケーラビリティーの制限に拘束されません。
前述の制限以外では、リモートノードはリソース管理に関してクラスターノードと同様に動作し、リモートおよびゲストノード自体をフェンシングできます。クラスターは、各リモートノードおよびゲストノードのリソースを完全に管理および監視できます。これらのノードに制約を作成したり、これらのノードをスタンバイ状態にすることができます。また、pcs コマンドを使用してクラスターノードでその他のアクションを実行することもできます。リモートおよびゲストノードは、クラスターノードと同様にクラスター状態の出力に表示されます。

9.3.1. ホストとゲストの認証

クラスターノードと pacemaker_remote 間の接続は TLS (Transport Layer Security) が使用され、PSK (Pre-Shared Key) の暗号化と TCP 上の認証 (デフォルトでポート 3121 を使用) でセキュア化されます。そのため、pacemaker_remote を実行しているクラスターノードおよびノードは同じプライベートキーを共有する必要があります。デフォルトでは、クラスターノードとリモートノードの両方でこのキーを /etc/pacemaker/authkey に格納する必要があります。

9.3.2. ゲストノードリソースのオプション

ゲストノードとして動作するよう仮想マシンまたは LXC リソースを設定する場合、仮想マシンを管理する VirtualDomain リソースを作成します。VirtualDomain リソースに設定できるオプションの説明を表示するには、次のコマンドを実行します。
# pcs resource describe VirtualDomain
VirtualDomain リソースオプションの他にも、メタデータオプションを設定してリソースをゲストノードとして有効にし、接続パラメーターを定義することができます。メタデータオプションの説明は 表9.3「KVM/LXC リソースをリモートノードとして設定するメタデータオプション」 を参照してください。

表9.3 KVM/LXC リソースをリモートノードとして設定するメタデータオプション

フィールドデフォルト説明
remote-node
<none>
このリソースが定義するゲストノードの名前。リソースをゲストノードとして有効にし、ゲストノードの識別に使用される一意名を定義します。 警告: この値はリソースやノードの ID と重複してはなりません。
remote-port
3121
pacemaker_remote へのゲスト接続に使用するカスタムのポートを設定
remote-addr
ホスト名として使用される remote-node
リモートノードの名前がゲストのホスト名ではない場合に接続する IP アドレスまたはホスト名
remote-connect-timeout
60s
保留中のゲスト接続がタイムアウトするまでの時間

9.3.3. リモートノードリソースのオプション

リモートノードをクラスターリソースとして設定するには、pcs resource create コマンドを使用し、ocf:pacemaker:remote をリソースタイプとして指定します。remote リソースに設定できるリソースオプションの説明は 表9.4「リモートノードのリソースオプション」 を参照してください。

表9.4 リモートノードのリソースオプション

フィールドデフォルト説明
reconnect_interval
0
リモートノードへのアクティブな接続が切断された後、リモートノードへの再接続を試みる前に待機する時間 (秒単位)。待機期間は繰り返されます。待機期間の後に再接続に失敗した場合、さらなる待機期間の後に再接続を試みます。このオプションが使用されると、Pacemaker は待機期間の後に無限にリモートノードへ接続を試みます。
server
接続するサーバーの場所。IP アドレスまたはホスト名を指定できます。
port
接続する TCP ポート。

9.3.4. デフォルトの pacemaker_remote オプションの変更

デフォルトのポートまたは Pacemaker や pacemaker_remote いずれかの authkey の場所を変更する必要がある場合は、両方のデーモンに反映させることができる環境変数を設定することができます。以下のように /etc/sysconfig/pacemaker ファイルに配置するとこの環境変数を有効にすることができます。
#==#==# Pacemaker Remote
# Use a custom directory for finding the authkey.
PCMK_authkey_location=/etc/pacemaker/authkey
#
# Specify a custom port for Pacemaker Remote connections
PCMK_remote_port=3121
特定ノード (クラスターノード、ゲストノード、またはリモートノード) でのデフォルトのキーの場所を変更すると、そのノードの PCMK_authkey_location を設定できることに注意してください (またその場所にキーを格納できます)。すべてのノードで場所を同じにする必要はありませんが、同じにした方が管理が楽になります。
特定のゲストノードまたはリモートノードによって使用されるデフォルトのポートを変更する場合、PCMK_remote_port 変数をそのノードの /etc/sysconfig/pacemaker ファイルに設定する必要があります。また、ゲストノードまたはリモートノードの接続を作成するクラスターリソースを同じポート番号で設定する必要もあります (ゲストノードの場合は remote-port メタデータオプション、リモートノードの場合は port オプションを使用します)。

9.3.5. 設定の概要: KVM ゲストノード

本セクションでは、libvirt と KVM 仮想ゲストを使用して、Pacemaker で仮想マシンを起動し、そのマシンをゲストノードとして統合する方法の概要を説明します。
  1. 仮想化ソフトウェアをインストールし、クラスターノード上で libvirtd サービスを有効にした後、すべてのクラスターノードと仮想マシンの /etc/pacemaker/authkey に同じ暗号化キーを保存します。これにより、通信と認証がセキュア化されます。
    すべてのノードで以下のコマンドセットを実行し、セキュアなパーミッションを持つ authkey ディレクトリーを作成します。
    # mkdir -p --mode=0750 /etc/pacemaker
    # chgrp haclient /etc/pacemaker
    以下のコマンドは、暗号化キーを作成する方法の 1 つを示しています。キーは 1 度だけ作成し、すべてのノードにコピーする必要があります。
    # dd if=/dev/urandom of=/etc/pacemaker/authkey bs=4096 count=1
  2. 各仮想マシンに pacemaker_remote パッケージをインストールし、pacemaker_remote サービスを開始します。pacemaker_remote が起動時に実行されるよう設定し、ファイアウォールを介して TCP のポート 3121 を許可します。
    # yum install pacemaker-remote resource-agents
    # systemctl start pacemaker_remote.service
    # systemctl enable pacemaker_remote.service
    # firewall-cmd --add-port 3121/tcp --permanent
    # firewall-cmd --reload
  3. すべてのノードが認識できる静的ネットワークアドレスと一意なホスト名を各仮想マシンに割り当てます。ゲスト仮想マシンに静的 IP アドレスを設定する方法については、『仮想化の導入および管理ガイド』を参照してください。
  4. 仮想マシンを管理するために VirtualDomain リソースエージェントを作成する場合、Pacemaker は仮想マシンの xml 設定ファイルをディスクのファイルにダンプすることを必要とします。たとえば、guest1 という名前の仮想マシンを作成し、ホストにあるファイルに xml をダンプします。好きなファイル名を使用できますが、この例では /etc/pacemaker/guest1.xml を使用します。
    # virsh dumpxml guest1 > /etc/pacemaker/guest1.xml
  5. ゲストノードが実行されている場合はシャットダウンします。そのノードがクラスターで設定されると Pacemaker によって開始されます。
  6. VirtualDomain リソースを作成し、 remote-note リソースメタオプションを設定して仮想マシンはリソースの実行が可能なゲストノードであることを示します。
    以下の例では、このリソースはクラスターに統合可能で、ホスト名が guest1 のゲストノードであることを remote-node=guest1 メタ属性が Pacemaker に伝えます。クラスターは開始後、ホスト名 guest1 で仮想マシンの pacemaker_remote サービスに通信しようとします。
    クラスターノードから以下のコマンドを入力します。
    # pcs resource create vm-guest1 VirtualDomain hypervisor="qemu:///system" config="/virtual_machines/vm-guest1.xml" meta remote-node=guest1
  7. VirtualDomain リソースの作成後、ゲストノードをクラスターの他のノードと同じように扱うことができます。たとえば、以下のコマンドをクラスターノードから実行すると、作成したリソースに対してリソース制約が作成され、ゲストノードで実行されるようになります。Red Hat Enterprise Linux 7.3 時点では、ゲストノードをグループで含むことができ、ストレージデバイス、ファイルシステム、および VM をグループ化できます。
    # pcs resource create webserver apache configfile=/etc/httpd/conf/httpd.conf op monitor interval=30s
    # pcs constraint location webserver prefers guest1

9.3.6. 設定の概要: リモートノード

本セクションでは、Pacemaker リモートノードを設定し、そのノードを既存の Pacemaker クラスター環境に統合する手順の概要を説明します。
  1. リモートノードを設定するノードで、ローカルファイアウォールを介してクラスター関連のサービスを許可します。
    # firewall-cmd --permanent --add-service=high-availability
    success
    # firewall-cmd --reload
    success

    注記

    iptables を直接使用する場合または firewalld 以外のファイアウォールソリューションを使用する場合は、さまざまなクラスタリングコンポーネントによって使用される TCP ポート 2224、3121、21064、および UDP ポート 5405 を開きます。
  2. リモートノードで pacemaker_remote デーモンをインストールします。
    # yum install -y pacemaker-remote resource-agents pcs
  3. 適切に通信するには、すべてのノード (クラスターノードとリモートノードの両方) に同じ認証キーがインストールされている必要があります。既存ノードにすでにキーがある場合、そのキーを使用してリモートノードにコピーします。それ以外の場合はリモートノードで新しいキーを作成します。
    リモートノードで以下のコマンドを実行し、セキュアなパーミッションを持つ認証キーのディレクトリーを作成します。
    # mkdir -p --mode=0750 /etc/pacemaker
    # chgrp haclient /etc/pacemaker
    以下のコマンドは、リモートノードで暗号化キーを作成する方法の 1 つを示しています。
    # dd if=/dev/urandom of=/etc/pacemaker/authkey bs=4096 count=1
  4. リモートノードで pacemaker_remote デーモンを開始し、有効にします。
    # systemctl enable pacemaker_remote.service
    # systemctl start pacemaker_remote.service
  5. クラスターノードにて、リモートノードの認証キーと同じパスを持つ共有された認証キーの保存場所を作成し、そのディレクトリーにキーをコピーします。この例では、キーが作成されたリモートノードからキーがコピーされます。
    # mkdir -p --mode=0750 /etc/pacemaker
    # chgrp haclient /etc/pacemaker
    # scp remote1:/etc/pacemaker/authkey /etc/pacemaker/authkey
  6. クラスターノードから以下のコマンドを実行し、remote リソースを作成します。この例では、リモートノードは remote1 になります。
    # pcs resource create remote1 ocf:pacemaker:remote
  7. remote リソースの作成後、リモートノードをクラスターの他のノードと同じように扱うことができます。たとえば、以下のコマンドをクラスターノードから実行すると、作成したリソースに対してリソース制約が作成され、リモートノードで実行されるようになります。
    # pcs resource create webserver apache configfile=/etc/httpd/conf/httpd.conf op monitor interval=30s
    # pcs constraint location webserver prefers remote1

    警告

    リソースグループ、コロケーション制約、または順序制約でノード接続リソースを利用しないでください。
  8. リモートノードのフェンスリソースを設定します。リモートノードは、クラスターノードと同様にフェンスされます。クラスターノードと同様に、リモートノードと使用するフェンスリソースを設定します。リモートノードはフェンスアクションを開始してはならないことに注意してください。他のノードに対してフェンス操作を実行できるのはクラスターノードのみです。

9.3.7. システムアップグレードおよび pacemaker_remote

Red Hat Enterprise Linux 7.3 より、アクティブな Pacemaker リモートノードで pacemaker_remote サービスが停止した場合にノードの停止前にクラスターがノードをリソースから正常に移行するようになりました。これにより、クラスターからノードを削除せずに、ソフトウェアのアップグレードやその他の定期的なメンテナンスを実行できるようになりました。pacemaker_remote がシャットダウンするとクラスターは即座に再接続を試みます。リソースのモニタータイムアウトが発生する前に pacemaker_remote が再起動されないと、クラスターは監視操作が失敗したと判断します。
アクティブな Pacemaker リモートノードで pacemaker_remote サービスが停止したときに監視が失敗しないようにするには、以下の手順にしたがって、pacemaker_remote を停止する可能性があるシステム管理を実行する前にノードをクラスターから削除します。

警告

Red Hat Enterprise Linux 7.2 以前のリリースでは、現在クラスターに統合されているノード上で pacemaker_remote が停止するとクラスターはそのノードをフェンスします。yum update のプロセスの一部として自動的に停止した場合、システムが不安定な状態になることがあります (特に pacemaker_remote と同時にカーネルもアップグレードされる場合)。Red Hat Enterprise Linux 7.2 以前のリリースでは、以下の手順にしたがって、pacemaker_remote を停止する可能性があるシステム管理を実行する前にノードをクラスターから除去する必要があります。
  1. ノードからすべてのサービスを除去する pcs resource disable resourcename コマンドを使用して、ノードの接続リソースを停止します。ゲストノードでは VM も停止されるため、VM をクラスターの外部で起動して (virsh などを使用) メンテナンスを実行する必要があります。
  2. 必要なメンテナンスを実行します。
  3. ノードをクラスターに戻す準備ができたら、pcs resource enable でリソース再度有効にします。

9.3.8. VM リソースのゲストノードへの変換

以下のコマンドを使用して既存の VirtualDomain リソースをゲストノードに変換します。リソースが最初からゲストノードとして作成された場合、このコマンドを実行する必要はありません。
pcs cluster remote-node add hostname resource_id [options]
以下のコマンドを使用して、指定のノードでゲストノードとして設定されたリソースを無効にします。
pcs cluster remote-node remove hostname