Red Hat Training
A Red Hat training course is available for Red Hat Enterprise Linux
High Availability Add-On リファレンス
High Availability Add-On の設定および管理のためのリファレンスガイド
概要
第1章 Red Hat High Availability Add-On 設定および管理リファレンスの概要
1.1. 新機能と変更点
1.1.1. Red Hat Enterprise Linux 7.1 の新機能および変更された機能
- Red Hat Enterprise Linux 7.1 以降では、pcs acl コマンドを使用してローカルユーザーのパーミッションを設定し、アクセス制御リスト (ACL) を使用してクラスター設定への読み取り専用または読み書きアクセスを許可できます。ACL の詳細は、「ユーザーのパーミッション設定」 を参照してください。
- 「順序付けされたリソースセット」 および 「リソースのコロケーション」 が大幅に更新および明確化されました。
- 「クォーラムオプションの設定」 に、クォーラムの確立時にクラスターがすべてのノードを待たないようにする cluster quorum unblock 機能の説明が追加されました。
- 「リソースの作成」 に、リソースグループの順序付けを設定するために使用できる
pcs resource create
コマンドのbefore
および after パラメーターの説明が追加されました。 - Red Hat Enterprise Linux 7.1 リリース以降ではクラスター設定を tarball にバックアップし、pcs config コマンドで
backup
およびrestore
オプションを使用してバックアップからすべてのノードのクラスター設定ファイルを復元できるようになりました。この機能の詳細は 「クラスター設定のバックアップおよび復元」 を参照してください。 - 内容を明確にするため本書全体に小変更が加えられました。
1.1.2. Red Hat Enterprise Linux 7.2 の新機能および変更された機能
- pcs resource relocate run コマンドを使用して、現在のクラスター状態、制約、リソースの場所、およびその他の設定によって決定される優先ノードにリソースを移動できるようになりました。このコマンドの詳細は、「リソースの優先ノードへの移動」 を参照してください。
- 外部プログラムを実行してクラスター通知の処理を判断するために
ClusterMon
リソースを設定する方法をより明確に説明するため、「モニターリングのリソースを使ったイベント通知」 が変更および拡大されました。 - 冗長な電源供給用のフェンスを設定する場合に各デバイスを 1 度のみ設定する必要があり、ノードのフェンシングには両方のデバイスが必要になることを指定する必要があります。冗長な電源供給にフェンスを設定する方法の詳細は、「冗長電源のフェンシング設定」 を参照してください。
- このドキュメントの 「クラスターノードの追加」 に、ノードを既存のクラスターに追加する手順が追加されました。
- 表7.1「簡単な場所の制約オプション」 の説明にあるように、新しい
resource-discovery
の場所の制約オプションにより、Pacemaker が指定されたリソースのノード上でリソースの検索を実行すべきかどうかを指定できるようになりました。 - ドキュメント全体にわたり、記載内容の明確化を図り、若干の修正を加えました。
1.1.3. Red Hat Enterprise Linux 7.3 の新機能および変更された機能
- このバージョンでは、「pacemaker_remote サービス」 全体が書き直されました。
- アラートエージェントを使用して Pacemaker アラートを設定できます。アラートエージェントは、リソース設定と操作を処理するためにクラスター呼び出しのリソースエージェントと同様にクラスターが呼び出す外部プログラムです。Pacemaker アラートエージェントの説明は 「Pacemaker アラートエージェント (Red Hat Enterprise Linux 7.3 以降)」 を参照してください。
- 本リリースでは新しいクォーラム管理コマンドがサポートされ、クォーラムの状態を表示し、
expected_votes
パラメーターを変更することができます。これらのコマンドの説明は 「クォーラム管理コマンド (Red Hat Enterprise Linux 7.3 以降)」 を参照してください。 - 「クォーラムオプションの変更 (Red Hat Enterprise Linux 7.3 以降)」 の説明に従って、pcs quorum update コマンドを使用してクラスターの一般的なクォーラムオプションを変更できるようになりました。
- クラスターのサードパーティー判別デバイスとして動作する個別のクォーラムデバイスを設定できます。この機能は主に、標準のクォーラムルールが許可するよりも多くのノード障害をクラスターで維持できるようにするために使用されます。この機能はテクニカルリビューとしてのみ提供されます。クォーラムデバイスの説明は 「クォーラムデバイス」 を参照してください。
- Red Hat Enterprise Linux 7.3 には、Booth クラスターチケットマネージャーを使用して複数のサイトにまたがる高可用性クラスターを設定する機能が提供されます。この機能はテクニカルリビューとしてのみ提供されます。Booth クラスターチケットマネージャーの説明は 14章Pacemaker を用いたマルチサイトクラスターの設定 を参照してください。
pacemaker_remote
サービスを実行している KVM ゲストノードを設定する場合、グループにゲストノードを含めることができます。これにより、ストレージデバイス、ファイルシステムおよび VM をグループ化できます。KVM ゲストノードの設定に関する詳細は 「設定の概要: KVM ゲストノード」 を参照してください。
1.1.4. Red Hat Enterprise Linux 7.4 の新機能および変更された機能
- Red Hat Enterprise Linux 7.4 には、Booth クラスターチケットマネージャーを使用して複数のサイトにまたがる高可用性クラスターを設定する機能が完全に提供されます。Booth クラスターチケットマネージャーの説明は 14章Pacemaker を用いたマルチサイトクラスターの設定 を参照してください。
- Red Hat Enterprise Linux 7.4 は、個別のクォーラムを設定する機能に完全に対応しています。この機能は主に、標準のクォーラムルールが許可するよりも多くのノード障害をクラスターで維持できるようにするために使用されます。クォーラムデバイスの説明は 「クォーラムデバイス」 を参照してください。
- ノード名で適用した正規表現と、ノード属性とその値によってフェンシングトポロジーでノードを指定できるようになりました。フェンシングレベルの説明は、「フェンスレベルの設定」 を参照してください。
- Red Hat Enterprise Linux 7.4 は、
NodeUtilization
リソースエージェントに対応しています。これは、利用可能な CPU、ホストメモリーの可用性、ハイパーバイザーメモリーの可用性に関するシステムパラメーターを検出し、これらのパラメーターを CIB に追加します。このリソースエージェントの詳細は、「NodeUtilization リソースエージェント (Red Hat Enterprise Linux 7.4 以降)」 を参照してください。 - Red Hat Enterprise Linux 7.4 では、cluster node add-guest と cluster node remove-guest コマンドは、remote-node add と cluster remote-node remove コマンドに代わります。pcs cluster node add-guest コマンドは、ゲストノードの
authkey
を設定し、pcs cluster node add-remote は、リモートノードのauthkey
を設定します。更新したゲストとリモートノード設定手順は、「リソースとしての仮想ドメインの設定」 を参照してください。 - Red Hat Enterprise Linux 7.4 は
systemd
resource-agents-deps
ターゲットに対応しています。これにより、「Pacemaker で管理されていないリソースの依存関係の起動順の設定 (Red Hat Enterprise Linux 7.4 以降)」 で説明しているように、クラスターにより管理されない依存関係を持つリソースを含むクラスターに適切な起動順序を設定できるようになります。 - マスター/スレーブクローンとしてリソースを作成するコマンドの形式は、このリリースで変更されています。マスター/スレーブクローンの作成の説明は、「多状態のリソース: 複数モードのリソース」 を参照してください。
1.1.5. Red Hat Enterprise Linux 7.5 の新機能および変更された機能
- Red Hat Enterprise Linux 7.5 では、
pcs_snmp_agent
デーモンを使用して、SNMP でデータについて Pacemaker クラスターを照会できます。SNMP でのクラスター照会は、「SNMP での Pacemaker クラスターを照会 (Red Hat Enterprise Linux 7.5 以降)」 を参照してください。
1.1.6. Red Hat Enterprise Linux 7.8 の新機能および変更された機能
- Red Hat Enterprise Linux 7.8 以降では、ノードが正常にシャットダウンすると、ノードに接続されているリソースがノードにロックされ、シャットダウンしたノードがクラスターに再度参加するときに再び起動するまで、他の場所で起動できないように、Pacemaker を設定できます。これにより、ノードのリソースをクラスター内の他のノードにフェールオーバーせずに、サービスの停止が許容できるメンテナンスウィンドウ中にノードの電源を切ることができます。ノードの正常なシャットダウン時に停止したままになるようにリソースを設定する方法は、「 クリーンノードのシャットダウンで停止するようにリソースを設定 (Red Hat Enterprise Linux 7.8 以降) 」 を参照してください。
1.2. Pacemaker 設定ツールのインストール
# yum install pcs pacemaker fence-agents-all
# 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
...
lvm2-cluster
と gfs2-utils
のパッケージは ResilientStorage チャンネルの一部になります。必要に応じて次のコマンドでインストールを行ってください。
# yum install lvm2-cluster gfs2-utils
1.3. ファイアウォールでクラスターコンポーネントを許可する iptables 設定
#firewall-cmd --permanent --add-service=high-availability
#firewall-cmd --add-service=high-availability
表1.1 High Availability Add-On で有効にするポート
ポート | 必要になる場合 |
---|---|
TCP 2224
|
すべてのノードで必須 (pcsd Web UI で必要となり、ノード間通信に必須)
任意のノードの pcs が、それ自体も含め、クラスター内のすべてのノードに通信できる方法でポート 2224 を開くことは重要です。Booth クラスターチケットマネージャーまたはクォーラムデバイスを使用する場合は、Booth Arbiter、クォーラムデバイスなどのすべての関連ホストで、ポート 2224 を開く必要があります。
|
TCP 3121
|
クラスターに Pacemaker リモートノードがある場合に、すべてのノードで必須です。
完全なクラスターノード上の Pacemaker の
cmd デーモンは、ポート 3121 で Pacemaker リモートノードの pacemaker_remoted デーモンに通信できます。クラスター通信に別のインターフェイスを使用する場合は、そのインターフェイスでポートを開くことのみが必要になります。少なくとも、ポートは、Pacemaker リモートノードの全クラスターノードに対して開いている必要があります。ユーザーは完全なノードとリモートノード間でホストを変換する可能性があるか、またはホストのネットワークを使用してコンテナー内でリモートノードを実行する可能性があるため、すべてのノードに対してポートを開くことは役に立ちます。ノード以外のホストにポートを開く必要はありません。
|
TCP 5403
| corosync-qnetd で、クォーラムデバイスを使用するクォーラムデバイスホストで必須です。デフォルト値は、corosync-qnetd コマンドの -p オプションで変更できます。
|
UDP 5404
| corosync がマルチキャスト UDP に設定されている場合は、corosync ノードで必須
|
UDP 5405
|
すべての corosync ノードで必須 (
corosync で必要)
|
TCP 21064
|
DLM を必要とするリソースがクラスターに含まれる場合は、すべてのノードで必須です (例:
clvm または GFS2 )。
|
TCP 9929、UDP 9929
|
Booth チケットマネージャーを使用してマルチサイトクラスターを確立するときに、すべてのクラスターノード、および同じノードのいずれかからの接続に対して Booth arbitrator ノードで開いている必要があります。
|
1.4. クラスターと Pacemaker の設定ファイル
corosync.conf
および cib.xml
です。
corosync.conf
は、Pacemaker が構築されているクラスターマネージャーの corosync
によって使用されるクラスターパラメーターを与えます。一般的に、corosync.conf
は直接編集せずに、pcs または pcsd インターフェイスを使用してください。ただし、このファイルを直接編集する必要のある状況も考えられます。corosync.conf
ファイルの編集は、Editing the corosync.conf file in Red Hat Enterprise Linux 7を参照してください。
cib.xml
ファイルは、クラスターの設定、およびクラスターの全リソースの現在の状態を表す XML ファイルです。このファイルは Pacemaker のクラスター情報ベース (CIB) により使用されます。CIB の内容は、自動的にクラスター全体に同期されます。cib.xml
ファイルは直接編集せず、代わりに pcs または pcsd インターフェイスを使用してください。
1.5. クラスター設定の注意事項
- RHEL 7.7 以降、Red Hat はノード数が 32 個を超えるクラスターデプロイメントをサポートしていません。しかし、
pacemaker_remote
サービスを実行しているリモートノードを使用すると、この制限を超えた拡張が可能になります。pacemaker_remote
サービスの説明は 「pacemaker_remote サービス」 を参照してください。 - DHCP (Dynamic Host Configuration Protocol) を使用して
corosync
デーモンによって使用されるネットワークインターフェイスで IP アドレスを取得することはサポートされません。アドレスの更新中、DHCP クライアントは割り当てられたインターフェイスに対して定期的に IP アドレスを削除および再追加することができます。これにより、corosync
によって接続障害が検出され、クラスターの他のノードからのフェンシングアクティビティーによってハートビート接続性にcorosync
が使用されます。
1.6. Red Hat Enterprise Linux High Availability クラスターの更新
- ローリング更新 - サービスからノードを、一度に 1 つずつ削除し、そのソフトウェアを更新してから、そのノードをクラスターに戻します。これにより、各ノードの更新中も、クラスターがサービスの提供とリソースの管理を継続できます。
- クラスター全体の更新 - クラスター全体を停止し、更新をすべてのノードに適用してから、クラスターのバックアップを開始します。
1.7. RHEL クラスターでの VM のライブ移行についての問題
- 移行する仮想マシンで実行しているリソースやソフトウェアの停止または移動を行う前に準備を行う必要がある場合は、以下の手順を実行します。
- 管理リソースを VM から移動します。リソースの割り当てに関する特定の要件や条件がある場合は、正しいノードにリソースを配置するための新しい場所の制約を作成することを考慮してください。
- VM をスタンバイモードにして、サービスで考慮されていないことや、残りのリソースが別の場所に再配置され、停止されるようにします。
#
pcs cluster standby VM
- 仮想マシンで以下のコマンドを実行して、仮想マシン上のクラスターソフトウェアを停止します。
#
pcs cluster stop
- 仮想マシンのライブマイグレーションを実行します。
- 仮想マシンでクラスターサービスを起動します。
#
pcs cluster start
- VM をスタンバイモードから解除します。
#
pcs cluster unstandby VM
- VM をスタンバイモードにする前に一時的な場所の制約を作成した場合、これらの制約を調整または削除して、リソースが通常の優先場所に戻れるようにします。
第2章 pcsd Web UI
2.1. pcsd Web UI の設定
- 「Pacemaker 設定ツールのインストール」 の説明に従って Pacemaker 設定ツールをインストールします。
- クラスターの一部である各ノードで、passwd コマンドを使用してユーザー
hacluster
のパスワードを設定します。各ノードに同じパスワードを使用してください。 - 各ノードの pcsd デーモンを開始し、有効にします。
#
systemctl start pcsd.service
#systemctl enable pcsd.service
- クラスターの 1 つのノードで、以下のコマンドを使用してクラスターを設定するノードを認証します。このコマンドを実行すると、
Username
とPassword
を指定するよう要求されます。Username
にはhacluster
を指定してください。#
pcs cluster auth node1 node2 ... nodeN
- いずれかのシステムで、以下の URL をブラウザーで開き、承認したノードの 1 つを指定します (
https
プロトコルを使用することに注意してください)。指定すると pcsd Web UI のログイン画面が表示されます。https://nodename:2224
図2.1 クラスターの管理ページ
[D]
2.2. pcsd Web UI を用いたクラスターの作成
- クラスターを作成するには、 Create New をクリックし、作成するクラスターとクラスターを設定するノードの名前を入力します。また、この画面では 「高度なクラスター設定オプション」 に記載されているクラスター通信のトランスポートメカニズムなどの高度なクラスターオプションを設定することもできます。クラスター情報の入力後、Create Cluster をクリックします。
- 既存のクラスターを Web UI に追加するには、Add Existing をクリックし、Web UI で管理したいクラスターのノードのホスト名または IP アドレスを入力します。
tooltip
表示としてそのオプションの詳細を表示することができます。
2.2.1. 高度なクラスター設定オプション
図2.2 クラスターページの作成

[D]
2.2.2. クラスター管理パーミッションの設定
- Web UI を使用してクラスターを管理するためのパーミッション。ネットワーク経由でノードに接続する pcs コマンドを実行するパーミッションも付与されます。本セクションでは、Web UI でこのパーミッションを設定する方法を説明します。
- ACL を使用し、クラスター設定への読み取り専用アクセスまたは読み書きアクセスをローカルユーザーに許可するパーミッション。Web UI で ACL を設定する方法は、「ACL の設定」 を参照してください。
haclient
にユーザーを追加することで、ユーザー hacluster
以外の特定のユーザーにパーミッションを付与し、Web UI でクラスターを管理し、ネットワーク経由でノードに接続する pcs コマンドを実行できます。次に、Manage Clusters ページの Permissions タブをクリックし、表示された画面でパーミッションを設定することで、グループ haclient
の個別のメンバーにパーミッションセットを設定できます。この画面では、グループのパーミッションを設定することもできます。
- 読み取りパーミッション (クラスター設定の表示)
- 書き込みパーミッション (パーミッションおよび ACL を除くクラスター設定の変更)
- 付与パーミッション (クラスターパーミッションおよび ACL の変更)
- フルパーミッション (ノードの追加や削除などのクラスターへの無制限アクセス、およびキーや証明書へのアクセス)
2.3. クラスターコンポーネントの設定
- Nodes (「クラスターノード」 を参照)
- Resources (「クラスターリソース」 を参照)
- Fence Devices (「フェンスデバイス」 を参照)
- ACL (「ACL の設定」 を参照)
- Cluster Properties (「クラスターのプロパティー」 を参照)
図2.3 クラスターコンポーネントのメニュー

[D]
2.3.1. クラスターノード
ノード
オプションを選択すると、現在設定されているノードと、現在選択されているノードの状態 (ノードで実行しているリソースや、リソースの場所設定など) が表示されます。このページは、Manage Clusters 画面でクラスターを選択すると表示されるデフォルトページです。
Configure Fencing
を選択することで、「フェンスデバイス」 で説明されているように、このページで直接フェンスデバイスを設定することもできます。
2.3.2. クラスターリソース
2.3.3. フェンスデバイス
2.3.4. ACL の設定
ACL
オプションを選択すると、ローカルユーザーのパーミッションを設定できる画面が表示され、アクセス制御リスト (ACL) を使用して、クラスター設定への読み取り専用アクセスまたは読み書きアクセスが可能になります。
2.3.5. クラスターのプロパティー
クラスターのプロパティー
オプションを選択するとクラスタープロパティーが表示され、そのプロパティーの値をデフォルト値から変更できます。Pacemaker クラスタープロパティーの詳細は 12章Pacemaker クラスターのプロパティー を参照してください。
2.4. 高可用性 pcsd Web UI の設定
pcsd
Web UI を使用すると、クラスターのノードのいずれかに接続して、クラスター管理ページを表示できます。接続先のノードがダウンするか、使用できなくなった場合は、クラスターの別のノードを指定する URL でブラウザーを開くと、クラスターに再接続できます。ただし、pcsd Web UI 自体を高可用性向けに設定することもできます。この場合、新しい URL を入力することなく継続してクラスターを管理できます。
pcsd
Web UI を設定するには、以下の手順を実行します。
/etc/sysconfig/pcsd
設定ファイルでPCSD_SSL_CERT_SYNC_ENABLED
がtrue
に設定されていることを確認します。これは、RHEL 7 でのデフォルト値です。証明書の同期を有効にすると、クラスターセットアップコマンドおよびノード追加コマンド用のpcsd
証明書の同期が、pcsd
によって実行されます。pcsd
Web UI への接続に使用するフローティング IP アドレスであるIPaddr2
クラスターリソースを作成します。物理ノードに関連付けられている IP アドレスは使用できません。IPaddr2
リソースの NIC デバイスを指定していない場合は、そのノードに静的に割り当てられている IP アドレスの 1 つと同じネットワークにフローティング IP が存在していないと、フローティング IP アドレスを割り当てる NIC デバイスが適切に検出されません。pcsd
を使用するためにカスタムの SSL 証明書を作成し、pcsd
Web UI への接続に使用するノードのアドレスに対して有効であることを確認します。- カスタムの SSL 証明書を作成するには、ワイルドカード証明書を使用するか、SAN (Subject Alternative Name: サブジェクトの別名) 証明書の延長を使用できます。Red Hat 証明書システムに関する詳細は、Red Hat Certificate System Administration Guideを参照してください。
- pcs pcsd certkey コマンドを使用して、
pcsd
用のカスタム証明書をインストールします。 - pcs pcsd sync-certificates コマンドを使用して、
pcsd
証明書をクラスター内の全ノードと同期させます。
- クラスターリソースとして設定したフローティング IP アドレスを使用して、
pcsd
Web UI に接続します。
pcsd
Web UI を設定している場合でも、ユーザーが接続しているノードがダウンすると、再びログインするように求められます。
第3章 pcs コマンドラインインターフェイス
corosync.conf
および cib.xml
ファイルに提供し、corosync
と Pacemaker を制御および設定します。
pcs [-f file] [-h] [commands]...
3.1. pcs コマンド
cluster
クラスターオプションおよびノードの設定を行います。pcs cluster コマンドの詳細は 4章クラスターの作成と管理 を参照してください。resource
stonith
Pacemaker との使用に備えてフェンスデバイスを設定します。pcs stonith コマンドの詳細は、5章フェンス機能: STONITH の設定 を参照してください。constraint
リソースの制約を管理します。pcs constraint コマンドの詳細は、7章リソースの制約 を参照してください。プロパティー
Pacemaker のプロパティーを設定します。pcs property コマンドでプロパティーを設定する方法については 12章Pacemaker クラスターのプロパティー を参照してください。status
現在のクラスターとリソースの状態を表示します。pcs status コマンドの詳細は 「状態の表示」 を参照してください。config
ユーザーが理解できる形式でクラスターの全設定を表示します。pcs config コマンドの詳細は 「全クラスター設定の表示」 を参照してください。
3.2. pcs の使用に関するヘルプ表示
-h
オプションを使用すると pcs のパラメーターとその詳細を表示させることができます。例えば、次のコマンドでは pcs resource コマンドのパラメーターが表示されます。出力の一部だけが表示されます。
# pcs resource -h
Usage: pcs resource [commands]...
Manage pacemaker resources
Commands:
show [resource id] [--all]
Show all currently configured resources or if a resource is specified
show the options for the configured resource. If --all is specified
resource options will be displayed
start <resource id>
Start resource specified by resource_id
...
3.3. raw クラスター設定の表示
3.4. 設定の変更をファイルに保存
-f
オプションを使うとアクティブの CIB に影響を与えずに設定変更をファイルに保存することができます。
pcs cluster cib filename
testfile
という名前のファイルに、未編集の CIB の xml ファイルが保存されます。
# pcs cluster cib testfile
testfile
ファイル内にリソースをひとつ作成しています。ただし、そのリソースは現在実行中のクラスター設定には追加されません。
# pcs -f testfile resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.120 cidr_netmask=24 op monitor interval=30s
testfile
の現在のコンテンツを CIB にプッシュします。
# pcs cluster cib-push testfile
3.5. 状態の表示
pcs status commands
resources
、groups
、cluster
、nodes
、pcsd
などを指定すると特定のクラスターコンポーネントの状態のみを表示させることができます。
3.6. 全クラスター設定の表示
pcs config
3.7. 現在の pcs バージョンの表示
pcs --version
3.8. クラスター設定のバックアップおよび復元
pcs config backup filename
--local
オプションは、現在のノードにあるファイルだけを復元します。
pcs config restore [--local] [filename]
第4章 クラスターの作成と管理
4.1. クラスターの作成
- クラスターの各ノードで pcsd を開始します。
- クラスターを設定するノードを認証します。
- クラスターノードの設定と同期を行います。
- クラスターノードでクラスターサービスを起動します。
4.1.1. pcsd デーモンの開始
pcsd
サービスを開始し、システムの起動時に pcsd
を有効にします。これらのコマンドはクラスターの各ノードで実行する必要があります。
#systemctl start pcsd.service
#systemctl enable pcsd.service
4.1.2. クラスターノードの認証
pcs
デーモンに対して pcs
の認証を行います。
- すべてのノードで
pcs
管理者のユーザー名をhacluster
にする必要があります。hacluster
ユーザーのパスワードは、各ノードで同じにすることが推奨されます。 username
やpassword
を指定しないと、コマンドの実行時にノードごとにこれらのパラメーターを入力するよう要求されます。- ノードを指定しないと、前回実行した pcs cluster setup コマンドで指定されているノードの
pcs
を認証することになります。
pcs cluster auth [node] [...] [-u username] [-p password]
z1.example.com
と z2.example.com
の両方で設定されるクラスターのノード両方に対して z1.example.com
のユーザー hacluster
を認証します。このコマンドは、クラスターノードのユーザー hacluster
に対するパスワードを要求します。
root@z1 ~]# pcs cluster auth z1.example.com z2.example.com
Username: hacluster
Password:
z1.example.com: Authorized
z2.example.com: Authorized
~/.pcs/tokens
(または /var/lib/pcsd/tokens
) ファイルに格納されます。
4.1.3. クラスターノードの設定と起動
--start
オプションを使用すると指定ノードでクラスターサービスが起動されます。必要に応じて、別途 pcs cluster start コマンドを使ってクラスターサービスを起動させることもできます。pcs cluster setup --start コマンドでクラスターを作成する場合、または pcs cluster start コマンドでクラスターサービスを開始する場合、クラスターが稼働するまでに若干の遅延が発生することがあります。クラスターおよび設定の作業を続行する前に、pcs cluster status コマンドを使用してクラスターが稼働していることを確認することが推奨されます。--local
オプションを使用するとローカルノードでのみ変更を実行します。
pcs cluster setup [--start] [--local] --name cluster_ name node1 [node2] [...]
--all
オプションを使用すると全ノードでクラスターサービスを起動します。- ノードを指定しないとクラスターサービスはローカルのノードでしか起動されません。
pcs cluster start [--all] [node] [...]
4.2. クラスターのタイムアウト値の設定
表4.1 タイムアウトオプション
オプション | 説明 |
---|---|
--token timeout | トークンを受信しなかった後にトークンの損失が宣言されるまでの時間をミリ秒単位で設定します (デフォルトは 1000 ms です)。 |
--join timeout | join メッセージの待ち時間をミリ秒単位で設定します (デフォルトは 50 ms です)。 |
--consensus timeout | 新しいメンバーシップの設定を開始する前に合意が得られるまでの待ち時間をミリ秒単位で設定します (デフォルトは 1200 ms です)。 |
--miss_count_const count | 再送信が行われる前に、トークンの受信時に再送信のメッセージがチェックされる最大回数を設定します。デフォルトは 5 (5 つのメッセージ) です。 |
--fail_recv_const failures | 新しい設定の設定前に、受信しなければならないメッセージが発生する可能性がある場合、メッセージを受信せずにトークンをローテーションする回数を指定します (デフォルトの失敗数は 2500 です)。 |
new_cluster
というクラスターを作成し、トークンのタイムアウト値を 10000 ミリ秒 (10 秒)、join タイムアウト値を 100 ミリ秒に設定します。
# pcs cluster setup --name new_cluster nodeA nodeB --token 10000 --join 100
4.3. 冗長リングプロトコル (RRP) の設定
my_rrp_clusterM
というクラスターを設定します。ノード B には nodeA-0
と nodeA-1
の 2 つのインターフェイスがあります。ノード A には nodeB-0
と nodeB-1
の 2 つのインターフェイスがあります。RRP を使用してこれらのノードをクラスターとして設定するには、以下のコマンドを実行します。
# pcs cluster setup --name my_rrp_cluster nodeA-0,nodeA-1 nodeB-0,nodeB-1
udp
トランスポートを使用するクラスターに RRP を設定する場合の詳細は、pcs cluster setup コマンドのヘルプスクリーンを参照してください。
4.4. クラスターノードの管理
4.4.1. クラスターサービスの停止
--all
オプションを使うと全ノードのクラスターサービスが停止されます。ノードを指定しない場合はローカルノードのクラスターサービスのみが停止されます。
pcs cluster stop [--all] [node] [...]
pcs cluster kill
4.4.2. クラスターサービスの有効化および無効化
--all
オプションを使用すると、全ノードでクラスターサービスが有効になります。- ノードを指定しないと、ローカルノードでのみクラスターサービスが有効になります。
pcs cluster enable [--all] [node] [...]
--all
オプションを指定すると、全ノードでクラスターサービスが無効になります。- ノードを指定しないと、ローカルノードでのみクラスターサービスが無効になります。
pcs cluster disable [--all] [node] [...]
4.4.3. クラスターノードの追加
clusternode-01.example.com
、clusternode-02.example.com
、および clusternode-03.example.com
が既存のクラスターノードになります。新たに追加するノードは newnode.example.com
になります。
- クラスターパッケージをインストールします。クラスターで SBD、Booth チケットマネージャー、またはクォーラムデバイスを使用する場合は、対応するパッケージ (
sbd
、booth-site
、corosync-qdevice
) を、新しいノードにも手動でインストールする必要があります。[root@newnode ~]#
yum install -y pcs fence-agents-all
- firewalld デーモンを実行している場合は、以下のコマンドを実行して Red Hat High Availability Add-On が必要とするポートを有効にします。
#
firewall-cmd --permanent --add-service=high-availability
#firewall-cmd --add-service=high-availability
- ユーザー ID
hacluster
のパスワードを設定します。クラスターの各ノードで、同じパスワードを使用することが推奨されます。[root@newnode ~]#
passwd hacluster
Changing password for user hacluster. New password: Retype new password: passwd: all authentication tokens updated successfully. - 次のコマンドを実行して
pcsd
サービスを開始し、システムの起動時にpcsd
が有効になるようにします。#
systemctl start pcsd.service
#systemctl enable pcsd.service
- 新しいクラスターノードで
hacluster
ユーザーを認証します。[root@clusternode-01 ~]#
pcs cluster auth newnode.example.com
Username: hacluster Password: newnode.example.com: Authorized - 新しいノードを既存のクラスターに追加します。さらに、このコマンドは
corosync.conf
クラスター設定ファイルをクラスターのすべてのノード (追加する新しいノードを含む) に対して同期します。[root@clusternode-01 ~]#
pcs cluster node add newnode.example.com
- 新しいノードで、クラスターサービスを開始して有効にします。
[root@newnode ~]#
pcs cluster start
Starting Cluster... [root@newnode ~]#pcs cluster enable
- 新しいクラスターノードに対して、フェンシングデバイスを設定してテストします。フェンスデバイスの設定は 5章フェンス機能: STONITH の設定 を参照してください。
4.4.4. クラスターノードの削除
corosync.conf
クラスター設定ファイルから指定のノードを削除します。クラスターに関するすべての情報をクラスターノード全体で削除し、クラスターを完全に破棄する方法については、「クラスター設定の削除」 を参照してください。
pcs cluster node remove node
4.4.5. スタンバイモード
--all
を指定すると、このコマンドはすべてのノードをスタンバイモードにします。
pcs cluster standby node | --all
--all
を指定すると、このコマンドはすべてのノードをスタンバイモードから外します。
pcs cluster unstandby node | --all
4.5. ユーザーのパーミッション設定
hacluster
以外の特定のユーザーにもクラスターを管理するパーミッションを付与できます。個々のユーザーに付与できるパーミッションには、以下の 2 つのセットがあります。
- 「ネットワーク上でのノードアクセスのパーミッション設定」 で説明しているように、個別のユーザーが Web UI からクラスターを管理でき、ネットワークからノードに接続できる pcs コマンドを実行可能なパーミッション。ネットワーク経由でノードに接続するコマンドには、クラスターを設定するコマンド、またはクラスターからノードを追加または削除するためのコマンドが含まれます。
- 「ACL を使用したローカルパーミッションの設定」 で説明しているように、クラスター設定への読み込み専用または書き込み専用アクセスをローカルユーザーに許可するパーミッション。ネットワーク経由で接続する必要のないコマンドには、リソースの作成や制約の設定など、クラスター設定を編集するコマンドが含まれます。
4.5.1. ネットワーク上でのノードアクセスのパーミッション設定
haclient
に追加します。「クラスター管理パーミッションの設定」 で説明しているように、Web UI を使用することで、これらのユーザーにパーミッションを付与することができます。
4.5.2. ACL を使用したローカルパーミッションの設定
haclient
グループのメンバーのユーザーは、クラスター設定への完全なローカル読み込み/書き込みアクセスを持ちます。
- pcs acl role create... コマンドを実行して role を作成しそのロールのパーミッションを定義します。
- pcs acl user create コマンドで作成したロールをユーザーに割り当てます。
rouser
という名前のローカルユーザーに、クラスター設定に対する読み取り専用アクセスを提供します。
- この手順では、
rouser
ユーザーがローカルシステムに存在し、rouser
ユーザーがhaclient
グループのメンバーであることが必要です。#
adduser rouser
#usermod -a -G haclient rouser
enable-acl
クラスタープロパティーを使って Pacemaker ACL を有効にします。#
pcs property set enable-acl=true --force
- cib に対して読み取り専用のパーミッションが付与されている
read-only
という名前のロールを作成します。#
pcs acl role create read-only description="Read access to cluster" read xpath /cib
- pcs ACL システムで
rouser
ユーザーを作成し、そのユーザーにread-only
ロールを割り当てます。#
pcs acl user create rouser read-only
- 現在の ACL を表示します。
#
pcs acl
User: rouser Roles: read-only Role: read-only Description: Read access to cluster Permission: read xpath /cib (read-only-read)
wuser
と言うローカルユーザーにクラスター設定に対する書き込みアクセスを与えています。
- この手順では、
wuser
ユーザーがローカルシステムに存在し、wuser
ユーザーがhaclient
グループのメンバーである必要があります。#
adduser wuser
#usermod -a -G haclient wuser
enable-acl
クラスタープロパティーを使って Pacemaker ACL を有効にします。#
pcs property set enable-acl=true --force
- cib に対して書き込みパーミッションを持つ
write-access
という名前のロールを作成します。#
pcs acl role create write-access description="Full access" write xpath /cib
- pcs ACL システム内に
wuser
というユーザーを作成し、write-access
ロールを割り当てます。#
pcs acl user create wuser write-access
- 現在の ACL を表示します。
#
pcs acl
User: rouser Roles: read-only User: wuser Roles: write-access Role: read-only Description: Read access to cluster Permission: read xpath /cib (read-only-read) Role: write-access Description: Full Access Permission: write xpath /cib (write-access-write)
4.6. クラスター設定の削除
pcs cluster destroy
4.7. クラスターの状態表示
pcs status
pcs cluster status
pcs status resources
4.8. クラスターメンテナンス
- クラスターの別のノードでサービスが継続的に実行している状態で、クラスター内のノードを停止する必要がある場合は、そのクラスターノードをスタンバイモードにすることができます。スタンバイノードのノードは、リソースをホストすることができなくなります。ノードで現在アクティブなリソースは、別のノードに移行するか、(他のノードがそのリソースを実行できない場合は) 停止します。スタンバイモードの詳細は、「スタンバイモード」 を参照してください。
- リソースを停止せずに、実行しているノードから個別のリソースを移行する必要がある場合、pcs resource move コマンドを使用してリソースを別のノードに移行できます。pcs resource move コマンドの詳細は、「リソースを手作業で移動する」 を参照してください。pcs resource move コマンドを実行すると、現在実行しているノードでそれが実行されないように、制約がリソースに追加されます。リソースを戻す準備ができたら、pcs resource clear または pcs constraint delete コマンドを実行すると、制約を削除できます。ただし、このコマンドを実行しても、リソースが必ずしも元のノードに戻る訳ではありません。その時点でリソースが実行できる場所は、リソースを最初に設定した方法によって異なるためです。「現在のノードからリソースを移動」 で説明しているように、pcs resource relocate run コマンドを実行すると、リソースを指定のノードに移動できます。
- 完全にリソースの実行を停止して、クラスターが再び起動しないようにするには、pcs resource disable コマンドを使用します。pcs resource disable コマンドの詳細は、「クラスターリソースの有効化、無効化、および禁止」 を参照してください。
- Pacemaker がリソースに対するアクションを実行するのを防ぐ必要がある場合 (たとえば、リソースに対するメンテナンスの実行中に復元アクションを無効にする必要がある場合や、
/etc/sysconfig/pacemaker
設定をリロードする必要がある場合)、「管理リソース」 で説明しているように pcs resource unmanage コマンドを使用します。Pacemaker Remote 接続リソースは、非管理モードにしないでください。 - クラスターを、サービスの開始や停止が行われない状態にする必要がある場合は、
maintenance-mode
クラスタープロパティーを設定できます。クラスターをメンテナンスモードにすると、すべてのリソースが自動的に非管理モードになります。クラスターのプロパティーの詳細は 表12.1「クラスターのプロパティー」 を参照してください。 - Pacemaker リモートノードでメンテナンスを実行する必要がある場合、「システムアップグレードおよび pacemaker_remote」 で説明しているように、リモートノードリソースを無効にすることで、ノードをクラスターから削除できます。
第5章 フェンス機能: STONITH の設定
5.1. STONITH (フェンス) エージェント
pcs stonith list [filter]
5.2. フェンスデバイスの一般的なプロパティー
- フェンスデバイスは、pcs stonith disable stonith_id コマンドを実行して無効にできます。これにより、ノードがそのデバイスを使用できないようにすることができます。
- 特定のノードがフェンスデバイスを使用できないようにするには、pcs constraint location … avoids コマンドで、フェンスリソースの場所制約を設定できます。
stonith-enabled=false
を設定すると、フェンシングがすべて無効になります。ただし、実稼働環境でフェンシングを無効にすることは適していないため、フェンシングが無効になっている場合は、Red Hat ではクラスターがサポートされないことに注意してください。
表5.1 フェンスデバイスの一般的なプロパティー
フィールド | タイプ | デフォルト | 説明 |
---|---|---|---|
pcmk_host_map | 文字列 | ホスト名を、ホスト名に対応していないデバイスのポート番号へマッピングします。たとえば、node1:1;node2:2,3 の場合は、node1 にはポート 1 を使用し、node2 にはポート 2 と 3 を使用するようにクラスターに指示します。 | |
pcmk_host_list | 文字列 | このデバイスで制御するマシンの一覧です (pcmk_host_check=static-list 以外は任意)。 | |
pcmk_host_check | 文字列 | dynamic-list | デバイスで制御するマシンを指定します。使用できる値は、dynamic-list (デバイスへの問い合わせ)、static-list (pcmk_host_list 属性の確認)、なし (すべてのデバイスで全マシンのフェンスが可能と見なされる) です。 |
5.3. デバイス固有のフェンスオプションの表示
pcs stonith describe stonith_agent
# pcs stonith describe fence_apc
Stonith options for: fence_apc
ipaddr (required): IP Address or Hostname
login (required): Login Name
passwd: Login password or passphrase
passwd_script: Script to retrieve password
cmd_prompt: Force command prompt
secure: SSH connection
port (required): Physical plug number or name of virtual machine
identity_file: Identity file for ssh
switch: Physical switch number on device
inet4_only: Forces agent to use IPv4 addresses only
inet6_only: Forces agent to use IPv6 addresses only
ipport: TCP port to use for connection with device
action (required): Fencing Action
verbose: Verbose mode
debug: Write debug information to given file
version: Display version information and exit
help: Display help and exit
separator: Separator for CSV created by operation list
power_timeout: Test X seconds for status change after ON/OFF
shell_timeout: Wait X seconds for cmd prompt after issuing command
login_timeout: Wait X seconds for cmd prompt after login
power_wait: Wait X seconds after issuing ON/OFF
delay: Wait X seconds before fencing is started
retry_on: Count of attempts to retry power on
method
オプションを提供するフェンスエージェントでは cycle
がサポートされず、データの破損が生じる可能性があるため、この値は指定できません。
5.4. フェンスデバイスの作成
pcs stonith create stonith_id stonith_device_type [stonith_device_options]
# pcs stonith create MyStonith fence_virt pcmk_host_list=f1 op monitor interval=30s
- フェンスデバイスの中には、フェンスできるノードを自動的に判断できるものがあります。
- フェンスデバイスの作成時に
pcmk_host_list
パラメーターを使用すると、フェンスデバイスで制御されるすべてのマシンを指定できます。 - フェンスデバイスによっては、フェンスデバイスが理解する仕様へのホスト名のマッピングが必要となるものがあります。フェンスデバイスの作成時に、
pcmk_host_map
パラメーターを使用して、ホスト名をマッピングできます。
5.5. フェンスデバイスの表示
--full
オプションが指定されていると、設定された stonith のオプションがすべて表示されます。
pcs stonith show [stonith_id] [--full]
5.6. フェンスデバイスの修正と削除
pcs stonith update stonith_id [stonith_device_options]
pcs stonith delete stonith_id
5.7. フェンスデバイスが接続されているノードの管理
--off
を指定すると、stonith に API コールの off
を使用し、ノードをオフにします (再起動はしません)。
pcs stonith fence node [--off]
pcs stonith confirm node
5.8. その他のフェンス設定オプション
表5.2 フェンスデバイスの高度なプロパティー
フィールド | タイプ | デフォルト | 説明 |
---|---|---|---|
pcmk_host_argument | 文字列 | port | port の代替パラメーターです。デバイスによっては、標準の port パラメーターに対応していない場合や、そのデバイス固有のパラメーターも提供している場合があります。このパラメーターを使用して、フェンスするマシンを示すデバイス固有の代替パラメーターを指定します。クラスターが追加パラメーターを提供しないようにする場合は、none 値を使用します。 |
pcmk_reboot_action | 文字列 | reboot | reboot の代替コマンドです。標準的なコマンドに対応していないデバイスや、別のコマンドを提供しているデバイスがあります。このパラメーターを使用して、再起動を実行するデバイス固有の代替コマンドを指定します。 |
pcmk_reboot_timeout | 時間 | 60s | stonith-timeout の代替コマンドで、再起動にタイムアウトを指定します。再起動が完了するまでに通常より長い時間を要するデバイスもあれば、通常より短い時間で完了するデバイスもあります。このパラメーターを使用して、再起動にデバイス固有のタイムアウトを指定します。 |
pcmk_reboot_retries | 整数 | 2 | タイムアウト期間内に、reboot コマンドを再試行する回数の上限です。複数の接続に対応していないデバイスもあります。デバイスが別のタスクでビジー状態になると操作が失敗する場合があるため、タイムアウトに達していなければ、Pacemaker が操作を自動的に再試行します。Pacemaker による再起動の動作の再試行回数を変更する場合に使用します。 |
pcmk_off_action | 文字列 | off | off の代替コマンドです。標準的なコマンドに対応していないデバイスや、別のコマンドを提供しているデバイスがあります。このような場合は、このパラメーターを使用して、オフ操作を実行するデバイス固有のコマンドを指定します。 |
pcmk_off_timeout | 時間 | 60s | stonith-timeout の代替コマンドで、オフ操作にタイムアウトを指定します。デバイスによって、この操作が完了するのにかかる時間が、通常と大きく異なる場合があります。このパラメーターを使用して、オフ操作にデバイス固有のタイムアウトを指定します。 |
pcmk_off_retries | 整数 | 2 | タイムアウト期間内に、off コマンドを再試行する回数の上限です。複数の接続に対応していないデバイスもあります。デバイスが別のタスクでビジー状態になると操作が失敗する場合があるため、タイムアウトに達していなければ、Pacemaker が操作を自動的に再試行します。Pacemaker によるオフ動作の再試行回数を変更する場合に使用します。 |
pcmk_list_action | 文字列 | list | list の代替コマンドです。標準的なコマンドに対応していないデバイスや、別のコマンドを提供しているデバイスがあります。このような場合は、このパラメーターを使用して、list 操作を実行するデバイス固有のコマンドを指定します。 |
pcmk_list_timeout | 時間 | 60s | stonith-timeout の代わりに list の動作に対して使用する代替タイムアウトです。デバイスによって、この操作が完了するのにかかる時間が、通常と大きく異なる場合があります。このパラメーターを使用して、list 操作にデバイス固有のタイムアウトを指定します。 |
pcmk_list_retries | 整数 | 2 | タイムアウト期間内に、list コマンドを再試行する回数の上限です。複数の接続に対応していないデバイスもあります。デバイスが別のタスクでビジー状態になると操作が失敗する場合があるため、タイムアウトに達していなければ、Pacemaker が操作を自動的に再試行します。Pacemaker による list 動作の再試行回数を変更する場合に使用します。 |
pcmk_monitor_action | 文字列 | monitor | monitor の代替コマンドです。標準的なコマンドに対応していないデバイスや、別のコマンドを提供しているデバイスがあります。このような場合は、このパラメーターを使用して、監視操作を実行するデバイス固有のコマンドを指定します。 |
pcmk_monitor_timeout | 時間 | 60s | stonith-timeout の代替コマンドで、監視にタイムアウトを指定します。デバイスによって、この操作が完了するのにかかる時間が、通常と大きく異なる場合があります。このパラメーターを使用して、監視操作にデバイス固有のタイムアウトを指定します。 |
pcmk_monitor_retries | 整数 | 2 | タイムアウト期間内に、monitor コマンドを再試行する回数の上限です。複数の接続に対応していないデバイスもあります。デバイスが別のタスクでビジー状態になると操作が失敗する場合があるため、タイムアウトに達していなければ、Pacemaker が操作を自動的に再試行します。Pacemaker による監視操作の再試行回数を変更する場合に使用します。 |
pcmk_status_action | 文字列 | status | status の代替コマンドです。標準的なコマンドに対応していないデバイスや、別のコマンドを提供しているデバイスがあります。このような場合は、このパラメーターを使用して、status 操作を実行するデバイス固有のコマンドを指定します。 |
pcmk_status_timeout | 時間 | 60s | stonith-timeout の代替コマンドで、status 操作にタイムアウトを指定します。デバイスによって、この操作が完了するのにかかる時間が、通常と大きく異なる場合があります。このパラメーターを使用して、status 操作にデバイス固有のタイムアウトを指定します。 |
pcmk_status_retries | 整数 | 2 | タイムアウト期間内に、status コマンドを再試行する回数の上限です。複数の接続に対応していないデバイスもあります。デバイスが別のタスクでビジー状態になると操作が失敗する場合があるため、タイムアウトに達していなければ、Pacemaker が操作を自動的に再試行します。Pacemaker による status 動作の再試行回数を変更する場合に使用します。 |
pcmk_delay_base | 時間 | 0s |
stonith 操作のベース遅延を有効にし、ベース遅延の値を指定します。ノードの数が偶数になるクラスターでは、遅延を設定すると、均等の分割時に同時にノードが互いにフェンシングするのを回避できます。ランダムな遅延は、すべてのノードに同じフェンスデバイスが使用されている場合に役に立つことがあります。また、静的遅延を変更すると、各ノードで異なるデバイスが使用される場合に各フェンシングデバイスで役に立つことがあります。全体の遅延は、合計が最大遅延を下回るように、ランダムな遅延値に静的遅延を加算します。
pcmk_delay_base を設定し、pcmk_delay_max を設定しない場合は、遅延にランダムなコンポーネントはなく、pcmk_delay_base の値となります。
各フェンスエージェントには delay パラメーターが実装されています。これは、
pcmk_delay_* プロパティーで設定された遅延の影響は受けません。この遅延の両方が設定されている場合は、その両方が一緒に追加されるため、通常は併用されません。
|
pcmk_delay_max | 時間 | 0s |
stonith 動作のランダムな遅延を有効にし、ランダムな遅延の最大値を指定します。ノードの数が偶数になるクラスターでは、遅延を設定すると、均等の分割時に同時にノードが互いにフェンシングするのを回避できます。ランダムな遅延は、すべてのノードに同じフェンスデバイスが使用されている場合に役に立つことがあります。また、静的遅延を変更すると、各ノードで異なるデバイスが使用される場合に各フェンシングデバイスで役に立つことがあります。全体の遅延は、合計が最大遅延を下回るように、このランダムな遅延値に静的遅延を加算します。
pcmk_delay_max を設定し、pcmk_delay_base を設定しない場合は、静的なコンポーネントが遅延に含まれません。
各フェンスエージェントには delay パラメーターが実装されています。これは、
pcmk_delay_* プロパティーで設定された遅延の影響は受けません。この遅延の両方が設定されている場合は、その両方が一緒に追加されるため、通常は併用されません。
|
pcmk_action_limit | 整数 | 1 | このデバイスで並行して実行できる操作の上限です。最初に、クラスタープロパティーの concurrent-fencing=true を設定する必要があります。値を -1 にすると無制限になります。 |
pcmk_on_action | 文字列 | on | 高度な使用のみ - on の代替コマンドです。標準的なコマンドに対応していないデバイスや、別のコマンドを提供しているデバイスがあります。このような場合は、このパラメーターを使用して、on 操作を実行するデバイス固有のコマンドを指定します。 |
pcmk_on_timeout | 時間 | 60s | 高度な使用のみ - stonith-timeout の代替コマンドで、on 操作にタイムアウトを指定します。デバイスによって、この操作が完了するのにかかる時間が、通常と大きく異なる場合があります。このパラメーターを使用して、on 操作にデバイス固有のタイムアウトを指定します。 |
pcmk_on_retries | 整数 | 2 | 高度な使用のみ - タイムアウト期間内に、on コマンドを再試行する回数の上限です。複数の接続に対応していないデバイスもあります。デバイスが別のタスクでビジー状態になると操作が失敗する場合があるため、タイムアウトに達していなければ、Pacemaker が操作を自動的に再試行します。Pacemaker による on 動作の再試行回数を変更する場合に使用します。 |
fence-reaction
クラスタープロパティーを設定することにより、独自のフェンシングの通知を受信した場合にクラスターノードがどのように反応するかを決定できます。クラスターノードは、フェンシングの設定が間違っている場合に独自のフェンシングの通知を受信するか、またはファブリックフェンシングがクラスター通信を遮断しない状態である可能性があります。このプロパティーのデフォルト値は stop
(Pacemaker をただちに停止して停止状態を維持しようと試みる) ですが、この値に対する最も安全な選択肢は panic
(ローカルノードをただちに再起動しようと試みる) です。停止動作を希望する場合は、おそらくファブリックフェンシングと併用する場合は、明示的に指定することが推奨されます。
5.9. フェンスレベルの設定
- レベルは、1 から昇順で試行されていきます。
- デバイスに障害が発生すると、現在のレベルの処理が終了します。同レベルのデバイスには試行されず、次のレベルが試行されます。
- すべてのデバイスのフェンシングが正常に完了すると、そのレベルが継承され、他のレベルは試行されなくなります。
- いずれかのレベルで成功するか、すべてのレベルが試行され失敗すると、操作は終了します。
pcs stonith level add level node devices
pcs stonith level
rh7-2
に、2 つのフェンスデバイス (il0 フェンスデバイス my_ilo
と、apc フェンスデバイス my_apc
) が設定されています。このコマンドはフェンスレベルを設定し、デバイス my_ilo
に障害が発生し、ノードがフェンスできない場合に、Pacemaker がデバイス my_apc
の使用を試行できるようにします。この例では、レベル設定後の pcs stonith level
コマンドの出力も表示されています。
#pcs stonith level add 1 rh7-2 my_ilo
#pcs stonith level add 2 rh7-2 my_apc
#pcs stonith level
Node: rh7-2 Level 1 - my_ilo Level 2 - my_apc
pcs stonith level remove level [node_id] [stonith_id] ... [stonith_id]
pcs stonith level clear [node|stonith_id(s)]
# pcs stonith level clear dev_a,dev_b
pcs stonith level verify
node1
、node2
、および `node3
で、フェンスデバイス apc1
および `apc2
を使用するように設定し、ノード `node4
、`node5
、および `node6
には、フェンスデバイス apc3
および `apc4
を使用するように設定します。
pcs stonith level add 1 "regexp%node[1-3]" apc1,apc2 pcs stonith level add 1 "regexp%node[4-6]" apc3,apc4
pcs node attribute node1 rack=1 pcs node attribute node2 rack=1 pcs node attribute node3 rack=1 pcs node attribute node4 rack=2 pcs node attribute node5 rack=2 pcs node attribute node6 rack=2 pcs stonith level add 1 attrib%rack=1 apc1,apc2 pcs stonith level add 1 attrib%rack=2 apc3,apc4
5.10. 冗長電源のフェンシング設定
#pcs stonith create apc1 fence_apc_snmp ipaddr=apc1.example.com login=user passwd='7a4D#1j!pz864' pcmk_host_map="node1.example.com:1;node2.example.com:2"
#pcs stonith create apc2 fence_apc_snmp ipaddr=apc2.example.com login=user passwd='7a4D#1j!pz864' pcmk_host_map="node1.example.com:1;node2.example.com:2"
#pcs stonith level add 1 node1.example.com apc1,apc2
#pcs stonith level add 1 node2.example.com apc1,apc2
5.11. 統合フェンスデバイスで使用する ACPI の設定
- ACPI Soft-Off を無効にする場合は、BIOS 設定を instant-off、またはこれに類似する設定に変更することが推奨されます。これにより、「BIOS で ACPI Soft-Off を無効化」 で説明しているように、ノードは遅延なくオフになります。
- 「logind.conf ファイルで ACPI Soft-Off の無効化」 で説明しているように、
HandlePowerKey=ignore
を/etc/systemd/logind.conf
ファイルに設定し、ノードがフェンシングされるとすぐにオフになることを確認します。これが、ACPI Soft-Off を無効にする 1 つ目の代替方法です。 - 「GRUB 2 ファイルでの ACPI の完全な無効化」 で説明しているように、カーネル起動コマンドラインに
acpi=off
を追加します。これは、ACPI Soft-Off を無効にする 2 つ目の代替方法です。この方法の使用が推奨される場合、または 1 つ目の代替方法が利用できない場合に使用してください。重要この方法は、ACPI を完全に無効にします。コンピューターの中には、ACPI が完全が無効になってるとシステムが正しく起動しないものもあります。お使いのクラスターに適した方法が他にない場合に 限り、この方法を使用してください。
5.11.1. BIOS で ACPI Soft-Off を無効化
- ノードを再起動して BIOS CMOS Setup Utility プログラムを起動します。
- 電源メニュー (または同等の電源管理メニュー) に移動します。
- 電源メニューで、Soft-Off by PWR-BTTN 機能 (または同等) を Instant-Off (または、遅延なく電源ボタンでノードをオフにする同等の設定) に設定します。例5.1「BIOS CMOS Setup Utility: Soft-Off by PWR-BTTN を to Instant-Off に設定」 は、ACPI Function が Enabled に設定され、Soft-Off by PWR-BTTN が Instant-Off に設定されている 電源 メニューを示しています。注記ACPI Function、Soft-Off by PWR-BTTN、Instant-Off と同等の機能は、コンピューターによって異なることがあります。ただし、この手順の目的は、電源ボタンを使用して遅延なしにコンピューターをオフにするように BIOS を設定することです。
- BIOS CMOS Setup Utility プラグラムを終了します。BIOS 設定が保存されます。
- ノードがフェンシングされるとすぐにオフになることを確認します。フェンスデバイスのテストの詳細は 「フェンスデバイスのテスト」 を参照してください。
例5.1 BIOS CMOS Setup Utility: Soft-Off by PWR-BTTN を to Instant-Off に設定
+---------------------------------------------|-------------------+ | ACPI Function [Enabled] | Item Help | | ACPI Suspend Type [S1(POS)] |-------------------| | x Run VGABIOS if S3 Resume Auto | Menu Level * | | Suspend Mode [Disabled] | | | HDD Power Down [Disabled] | | | Soft-Off by PWR-BTTN [Instant-Off | | | CPU THRM-Throttling [50.0%] | | | Wake-Up by PCI card [Enabled] | | | Power On by Ring [Enabled] | | | Wake Up On LAN [Enabled] | | | x USB KB Wake-Up From S3 Disabled | | | Resume by Alarm [Disabled] | | | x Date(of Month) Alarm 0 | | | x Time(hh:mm:ss) Alarm 0 : 0 : | | | POWER ON Function [BUTTON ONLY | | | x KB Power ON Password Enter | | | x Hot Key Power ON Ctrl-F1 | | | | | | | | +---------------------------------------------|-------------------+
5.11.2. logind.conf ファイルで ACPI Soft-Off の無効化
/etc/systemd/logind.conf
ファイルで電源キーの処理を無効にするには、以下の手順を行います。
/etc/systemd/logind.conf
ファイルに、以下の設定を定義します。HandlePowerKey=ignore
systemd
設定をリロードします。#
systemctl daemon-reload
- ノードがフェンシングされるとすぐにオフになることを確認します。フェンスデバイスのテストの詳細は 「フェンスデバイスのテスト」 を参照してください。
5.11.3. GRUB 2 ファイルでの ACPI の完全な無効化
acpi=off
を追加して無効にできます。
- 以下のように、grubby ツールで、
--args
オプションと--update-kernel
オプションを使用して、各クラスターノードのgrub.cfg
ファイルを変更します。#
grubby --args=acpi=off --update-kernel=ALL
GRUB 2 の概要は、 システム管理者のガイド のGRUB 2 での作業を参照してください。 - ノードを再起動します。
- ノードがフェンシングされるとすぐにオフになることを確認します。フェンスデバイスのテストの詳細は 「フェンスデバイスのテスト」 を参照してください。
5.12. フェンスデバイスのテスト
- デバイスへの接続に使用する ssh、telnet、HTTP などのリモートプロトコルを使用して、手動でログインしてフェンスデバイスをテストしたり、出力される内容を確認します。たとえば、IPMI 対応デバイスのフェンシングを設定する場合は、ipmitool を使用してリモートでのログインを試行します。手動でログインする際に使用するオプションに注意してください。これらのオプションは、フェンスエージェントを使用する際に必要になる場合があります。フェンスデバイスにログインできない場合は、そのデバイスが ping 可能であること、ファイアウォール設定フェンスデバイスへのアクセスを妨げていないこと、フェンスエージェントでリモートアクセスが有効になっていること、認証情報が正しいことなどを確認します。
- フェンスエージェントスクリプトを使用して、フェンスエージェントを手動で実行します。フェンスエージェントを実行するのに、クラスターサービスが実行している必要はないため、デバイスをクラスターに設定する前にこのステップを完了できます。これにより、先に進む前に、フェンスデバイスが適切に応答することを確認できます。注記本セクションの例では、iLO デバイスの fence_ilo フェンスエージェントスクリプトを使用します。実際に使用するフェンスエージェントと、そのエージェントを呼び出すコマンドは、お使いのサーバーハードウェアによって異なります。指定するオプションを確認するには、フェンスエージェントの man ページを参照してください。通常は、フェンスデバイスのログイン、パスワードなどの情報と、その他のフェンスデバイスに関する情報を把握しておく必要があります。以下の例は、
-o status
パラメーターを指定して fence_ilo フェンスエージェントスクリプトを実行する場合に使用する形式になります。ノードの再起動を試行する前にデバイスをテストして、動作させることができます。このコマンドを実行する際に、iLO デバイスの電源をオン/オフにするパーミッションを持つ iLO ユーザーの名前およびパスワードを指定します。#
fence_ilo -a ipaddress -l username -p password -o status
以下の例は、-o reboot
パラメーターを指定して fence_ilo フェンスエージェントスクリプトを実行するために使用する形式になります。このコマンドをノードで実行すると、フェンスエージェントを設定した別のノードが再起動します。#
fence_ilo -a ipaddress -l username -p password -o reboot
フェンスエージェントがステータス、オフ、オン、または再起動の動作を適切に実行しない場合は、ハードウェア、フェンスデバイスの設定、およびコマンドの構文を確認する必要があります。さらに、デバッグ出力を有効にした状態で、フェンスエージェントスクリプトを実行できます。デバッグ出力は、一部のフェンスエージェントで、フェンスデバイスにログインする際に、フェンスエージェントスクリプトに問題が発生しているイベントシーケンスの場所を確認するのに役に立ちます。#
fence_ilo -a ipaddress -l username -p password -o status -D /tmp/$(hostname)-fence_agent.debug
発生した障害を診断する際に、フェンスデバイスに手動でログインする際に指定したオプションが、フェンスエージェントスクリプトでフェンスエージェントに渡した内容と同一であることを確認する必要があります。フェンスエージェントが、暗号化した接続に対応する場合は、証明書の検証で障害が生じているためにエラーが出力される場合があり、ホストを信頼することや、フェンスエージェントのssl-insecure
パラメーターを使用することが求められます。同様に、ターゲットデバイスで SSL/TLS を無効にした場合は、フェンスエージェントに SSL パラメーターを設定する際に、これを考慮しないといけない場合があります。注記テストしているフェンスエージェントが fence_drac または fence_ilo の場合、もしくはその他の、継続して失敗しているシステム管理デバイスのフェンスエージェントの場合は、フォールバックして fence_ipmilan を試行します。大半のシステム管理カードは IPMI リモートログインに対応しており、フェンスエージェントとしては fence_ipmilan だけに対応しています。 - フェンスデバイスを、手動で機能したオプションと同じオプションでクラスターに設定し、クラスターを起動したら、以下の例にあるように、任意のノードから pcs stonith fence コマンドを実行してフェンシングをテストします (または複数のノードから複数回実行します)。pcs stonith fence コマンドは m クラスター設定を CIB から読み取り、フェンス動作を実行するように設定したフェンスエージェントを呼び出します。これにより、クラスター設定が正確であることが確認できます。
#
pcs stonith fence node_name
pcs stonith fence コマンドに成功した場合は、フェンスイベントの発生時に、クラスターのフェンシング設定が機能します。このコマンドが失敗すると、クラスター管理が取得した設定でフェンスデバイスを起動することができません。以下の問題を確認し、必要に応じてクラスター設定を更新します。- フェンス設定を確認します。たとえば、ホストマップを使用したことがある場合は、指定したホスト名を使用して、システムがノードを見つけられるようにする必要があります。
- デバイスのパスワードおよびユーザー名に、bash シェルが誤って解釈する可能性がある特殊文字が含まれるかどうかを確認します。パスワードとユーザー名を引用符で囲んで入力すると、この問題に対処できます。
- pcs stonith コマンドで IP アドレスまたはホスト名を使用してデバイスに接続できるかどうかを確認してください。たとえば、stonith コマンドでホスト名を指定し、IP アドレスを使用して行ったテストは有効ではありません。
- お使いのフェンスデバイスが使用するプロトコルにアクセスできる場合は、そのプロトコルを使用してデバイスへの接続を試行します。たとえば、多くのエージェントが ssh または telnet を使用します。デバイスへの接続は、デバイスの設定時に指定した認証情報を使用して試行する必要があります。これにより、有効なプロンプトを取得し、そのデバイスにログインできるかどうかを確認できます。
すべてのパラメーターが適切であることが確認できたものの、フェンスデバイスには接続できない時に、フェンスデバイスでログ機能が使用できる場合は、ログを確認できます。これにより、ユーザーが接続したかどうかと、ユーザーが実行したコマンドが表示されます。/var/log/messages
ファイルで stonith やエラーを確認すれば、発生している問題のヒントが得られる可能性もあります。また、エージェントによっては、より詳細な情報が得られる場合があります。 - フェンスデバイステストに成功し、クラスターが稼働したら、実際の障害をテストします。このテストでは、クラスターで、トークンの損失を生じさせる動作を実行します。
- ネットワークを停止します。ネットワークの利用方法は、設定により異なります。ただし、多くの場合は、ネットワークケーブルまたは電源ケーブルをホストから物理的に抜くことができます。注記ネットワークや電源ケーブルを物理的に切断せずに、ローカルホストのネットワークインターフェイスを無効にすることは、フェンシングのテストとしては推奨されません。実際に発生する障害を正確にシミュレートしていないためです。
- ローカルのファイアウォールを使用して、corosync の受信トラフィックおよび送信トラフィックをブロックします。以下の例では corosync をブロックします。ここでは、デフォルトの corosync ポートと、ローカルのファイアウォールとして
firewalld
が使用されていることと、corosync が使用するネットワークインターフェイスがデフォルトのファイアウォールゾーンにあることが前提となっています。#
firewall-cmd --direct --add-rule ipv4 filter OUTPUT 2 -p udp --dport=5405 -j DROP
#firewall-cmd --add-rich-rule='rule family="ipv4" port port="5405" protocol="udp" drop'
sysrq-trigger
でクラッシュをシミュレートし、マシンをクラッシュします。ただし、カーネルパニックを発生させると、データが損失する可能性があることに注意してください。クラッシュする前に、クラスターリソースを無効にすることが推奨されます。#
echo c > /proc/sysrq-trigger
第6章 クラスターリソースの設定
6.1. リソースの作成
pcs resource create resource_id [standard:[provider:]]type [resource_options] [op operation_action operation_options [operation_action operation options]...] [meta meta_options...] [clone [clone_options] | master [master_options] | --group group_name [--before resource_id | --after resource_id] | [bundle bundle_id] [--disabled] [--wait[=n]]
--group
オプションを指定すると、名前付きのリソースグループにリソースが追加されます。グループが存在しない場合は作成され、そのグループにリソースが追加されます。リソースグループの詳細は 「リソースグループ」 を参照してください。
--before
および --after
オプションは、リソースグループに含まれるリソースを基準にして、追加するリソースの位置を指定します。
--disabled
オプションは、リソースが自動的に起動しないことを示しています。
ocf
、プロバイダー heartbeat
、およびタイプ IPaddr2
で、リソース VirtualIP
を作成します。このリソースのフローティングアドレスは 192.168.0.120 で、システムはリソースが 30 秒毎に実行されるかどうかをチェックします。
# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.120 cidr_netmask=24 op monitor interval=30s
ocf
と heartbeat
にデフォルト設定されます。
# pcs resource create VirtualIP IPaddr2 ip=192.168.0.120 cidr_netmask=24 op monitor interval=30s
pcs resource delete resource_id
VirtualIP
というリソース ID の既存リソースを削除しています。
# pcs resource delete VirtualIP
- pcs resource create コマンドのフィールド resource_id、standard、provider、type については 「リソースのプロパティー」 を参照してください。
- リソースごとにパラメーターを指定する方法は 「リソース固有のパラメーター」 を参照してください。
- リソースの動作をクラスターが決定する場合に使用するリソースのメタオプションを定義する方法は 「リソースのメタオプション」 を参照してください。
- リソースで行う動作を定義する方法は 「リソースの動作」 を参照してください。
clone
オプションを指定すると、クローンリソースが作成されます。master
オプションを指定すると、クローンリソースが作成されます。リソースのクローンや、複数モードのリソースに関する詳細は 9章高度な設定 を参照してください。
6.2. リソースのプロパティー
表6.1 リソースのプロパティー
表6.2 リソースプロパティーを表示させるコマンド
pcs 表示コマンド | 出力 |
---|---|
pcs resource list | 利用できる全リソースの一覧を表示 |
pcs resource standards | 利用できるリソースエージェントの標準を表示 |
pcs resource providers | 利用できるリソースエージェントのプロバイダーを表示 |
pcs resource list string | 利用できるリソースを指定文字列でフィルターした一覧を表示。仕様名、プロバイダー名、タイプ名などでフィルターを指定して、リソースを表示できます。 |
6.3. リソース固有のパラメーター
# pcs resource describe standard:provider:type|type
LVM
のリソースに設定できるパラメーターを表示します。
# pcs resource describe LVM
Resource options for: LVM
volgrpname (required): The name of volume group.
exclusive: If set, the volume group will be activated exclusively.
partial_activation: If set, the volume group will be activated even
only partial of the physical volumes available. It helps to set to
true, when you are using mirroring logical volumes.
6.4. リソースのメタオプション
表6.3 リソースのメタオプション
フィールド | デフォルト | 説明 |
---|---|---|
priority
| 0
| |
target-role
| Started
|
クラスターが維持するリソースのステータスです。使用できる値は以下のようになります。
* Stopped - リソースの強制停止
* Started - リソースの起動を許可 (多状態リソースの場合マスターには昇格されません)
|
is-managed
| true
| |
resource-stickiness
|
0
| |
requires
|
Calculated
|
リソースを起動できる条件を示します。
以下の条件を除き、
fencing がデフォルトに設定されます。以下の値が使用できます。
*
nothing - クラスターは常にリソースを開始できます。
*
quorum - クラスターは、設定されているノードの過半数がアクティブな場合に限りこのリソースを起動できます。stonith-enabled が false に設定されている場合、またはリソースの standard が stonith の場合は、このオプションがデフォルト値となります。
*
fencing -設定されているノードの過半数がアクティブで 且つ 障害が発生しているノードや不明なノードの電源がすべてオフになっている場合にのみ、クラスターによるこのリソースの起動を許可
|
migration-threshold
| INFINITY
|
指定したリソースが任意のノードで失敗した回数です。この回数を超えると、そのノードには、このリソースのホストとして不適格とするマークが付けられます。値を 0 にするとこの機能は無効になり、ノードに不適格マークが付けられることはありません。
INFINITY (デフォルト) に設定すると、クラスターは、これを非常に大きい有限数として扱います。このオプションは、失敗した操作に on-fail=restart (デフォルト) が設定されていて、かつ失敗した起動操作のクラスタープロパティー start-failure-is-fatal が false に設定されている場合に限り有効です。migration-threshold オプションの設定の詳細は、「障害発生によるリソースの移動」 を参照してください。start-failure-is-fatal オプションの詳細は、表12.1「クラスターのプロパティー」 を参照してください。
|
failure-timeout
| 0 (無効)
| migration-threshold オプションと併用されます。障害が発生していないかのように動作し、障害が発生したノードにリソースを戻せるようになるまで待機する秒数を示します。タイムベースのアクションと同様、これが、cluster-recheck-interval クラスターパラメーターの値よりも頻繁に確認される保証はありません。failure-timeout オプションの詳細は、「障害発生によるリソースの移動」 を参照してください。
|
multiple-active
| stop_start
|
リソースが複数のノードでアクティブであることが検出された場合に、クラスターが実行する動作です。使用できる値は以下のようになります。
*
block - リソースに unmanaged のマークを付けます。
*
stop_only - 実行中のインスタンスをすべて停止し、以降の動作は行いません。
*
stop_start - 実行中のインスタンスをすべて停止してから、リソースを 1 カ所でのみ起動します。
|
pcs resource defaults options
resource-stickiness
のデフォルト値を 100 にリセットします。
# pcs resource defaults resource-stickiness=100
resource-stickiness
のデフォルト値を 100 にリセットした後のコマンド出力を示しています。
# pcs resource defaults
resource-stickiness:100
pcs resource create
コマンドの形式です。
pcs resource create resource_id standard:provider:type|type [resource options] [meta meta_options...]
resource-stickiness
の値を 50 に設定したリソースを作成します。
# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.120 cidr_netmask=24 meta resource-stickiness=50
pcs resource meta resource_id | group_id | clone_id | master_id meta_options
dummy_resource
という名前の既存リソースがあります。このコマンドは、failure-timeout
メタオプションの値を 20 秒に設定します。これにより 20 秒でリソースが同じノード上で再起動を試行できるようになります。
# pcs resource meta dummy_resource failure-timeout=20s
failure-timeout=20s
が設定されているか確認するためリソースの値を表示させることができます。
# pcs resource show dummy_resource
Resource: dummy_resource (class=ocf provider=heartbeat type=Dummy)
Meta Attrs: failure-timeout=20s
Operations: start interval=0s timeout=20 (dummy_resource-start-timeout-20)
stop interval=0s timeout=20 (dummy_resource-stop-timeout-20)
monitor interval=10 timeout=20 (dummy_resource-monitor-interval-10)
6.5. リソースグループ
pcs resource group add group_name resource_id [resource_id] ... [resource_id] [--before resource_id | --after resource_id]
--before
オプションおよび --after
オプションを使用して、追加するリソースの位置を、そのグループにすでに含まれるリソースを基準にして指定できます。
pcs resource create resource_id standard:provider:type|type [resource_options] [op operation_action operation_options] --group group_name
pcs resource group remove group_name resource_id...
pcs resource group list
IPaddr
と Email
が含まれるリソースグループ shortcut
が作成されます。
# pcs resource group add shortcut IPaddr Email
- リソースは指定された順序で起動されます (この例では、最初に
IPaddr
が起動された後、Email
が起動されます)。 - リソースは、指定した順序と逆の順序で停止します。(
email
first:IPaddr
)
IPaddr
を実行できない場合は、Email
も実行できません。Email
を実行できなくても、IPaddr
には影響ありません。
6.5.1. グループオプション
priority
オプション、target-role
オプション、および is-managed
オプションを継承します。リソースオプションの詳細は、表6.3「リソースのメタオプション」 を参照してください。
6.5.2. グループの Stickiness (粘着性)
resource-stickiness
のデフォルト値が 100 で、グループに 7 つのメンバーがあり、そのメンバーの 5 つがアクティブな場合は、グループ全体でスコアが 500 の現在の場所が優先されます。
6.6. リソースの動作
表6.4 動作のプロパティー
6.6.1. リソース操作の設定
pcs resource create resource_id standard:provider:type|type [resource_options] [op operation_action operation_options [operation_type operation_options]...]
IPaddr2
リソースを作成します。新しいリソースには VirtualIP
という名前が付けられ、eth2
で IP アドレス 192.168.0.99、ネットマスク 24 になります。監視操作は、30 秒ごとに実施されます。
# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.99 cidr_netmask=24 nic=eth2 op monitor interval=30s
pcs resource op add resource_id operation_action [operation_properties]
pcs resource op remove resource_id operation_name operation_properties
VirtualIP
を作成できます。
# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.99 cidr_netmask=24 nic=eth2
Operations: start interval=0s timeout=20s (VirtualIP-start-timeout-20s) stop interval=0s timeout=20s (VirtualIP-stop-timeout-20s) monitor interval=10s timeout=20s (VirtualIP-monitor-interval-10s)
#pcs resource update VirtualIP op stop interval=0s timeout=40s
#pcs resource show VirtualIP
Resource: VirtualIP (class=ocf provider=heartbeat type=IPaddr2) Attributes: ip=192.168.0.99 cidr_netmask=24 nic=eth2 Operations: start interval=0s timeout=20s (VirtualIP-start-timeout-20s) monitor interval=10s timeout=20s (VirtualIP-monitor-interval-10s) stop interval=0s timeout=40s (VirtualIP-name-stop-interval-0s-timeout-40s)
6.6.2. グローバルリソース操作のデフォルトの設定
pcs resource op defaults [options]
timeout
値のグローバルデフォルトを 240 秒に設定します。
# pcs resource op defaults timeout=240s
timeout
値が 240 秒に設定されています。
# pcs resource op defaults
timeout: 240s
timeout
オプションを定義します。グローバル操作のタイムアウト値を有効にするには、timeout
オプションを明示的に指定せずにクラスターリソースを作成するか、次のコマンドのように、クラスターリソースを更新して timeout
オプションを削除する必要があります。
# pcs resource update VirtualIP op monitor interval=10s
timeout
値 240 秒を設定し、クラスターリソース VirtualIP
を更新して、monitor
操作のタイムアウト値を削除すると、リソース VirtualIP
には、start
、stop
、および monitor
の操作のタイムアウト値が、それぞれ 20 秒、40 秒、240 秒に設定されます。タイムアウト操作のグローバルなデフォルト値は、ここでは monitor
にのみ適用されます。ここでは、前のコマンドにより、デフォルトの timeout
オプションが削除されています。
# pcs resource show VirtualIP
Resource: VirtualIP (class=ocf provider=heartbeat type=IPaddr2)
Attributes: ip=192.168.0.99 cidr_netmask=24 nic=eth2
Operations: start interval=0s timeout=20s (VirtualIP-start-timeout-20s)
monitor interval=10s (VirtualIP-monitor-interval-10s)
stop interval=0s timeout=40s (VirtualIP-name-stop-interval-0s-timeout-40s)
6.7. 設定されているリソースの表示
pcs resource show
VirtualIP
と言う名前のリソースと WebSite
という名前のリソースでシステムを設定していた場合、pcs resource show コマンドを実行すると次のような出力が得られます。
# pcs resource show
VirtualIP (ocf::heartbeat:IPaddr2): Started
WebSite (ocf::heartbeat:apache): Started
pcs resource show resource_id
VirtualIP
のパラメーターを表示します。
# pcs resource show VirtualIP
Resource: VirtualIP (type=IPaddr2 class=ocf provider=heartbeat)
Attributes: ip=192.168.0.120 cidr_netmask=24
Operations: monitor interval=30s
6.8. リソースパラメーターの変更
pcs resource update resource_id [resource_options]
VirtualIP
リソースに設定したパラメーターの初期値、ip
パラメーターの値を変更するコマンド、変更されたパラメーター値を示しています。
#pcs resource show VirtualIP
Resource: VirtualIP (type=IPaddr2 class=ocf provider=heartbeat) Attributes: ip=192.168.0.120 cidr_netmask=24 Operations: monitor interval=30s #pcs resource update VirtualIP ip=192.169.0.120
#pcs resource show VirtualIP
Resource: VirtualIP (type=IPaddr2 class=ocf provider=heartbeat) Attributes: ip=192.169.0.120 cidr_netmask=24 Operations: monitor interval=30s
6.9. 複数のモニターリング動作
OCF_CHECK_LEVEL=n
オプションを追加します。
IPaddr2
リソースを設定すると、デフォルトでは 10 秒間隔でタイムアウト値が 20 秒の監視操作が作成されます。
# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.99 cidr_netmask=24 nic=eth2
# pcs resource op add VirtualIP monitor interval=60s OCF_CHECK_LEVEL=10
6.10. クラスターリソースの有効化と無効化
resource_id
で指定されているリソースを有効にします。
pcs resource enable resource_id
resource_id
で指定されているリソースを有効にします。
pcs resource disable resource_id
6.11. クラスターリソースのクリーンアップ
failcount
をリセットし、リソースの動作履歴を消去して現在の状態を再検出するようにクラスターに指示します。
pcs resource cleanup resource_id
failcount
をリセットします。
pcs resource refresh
pcs resource refresh --full
第7章 リソースの制約
場所
の制約 - この制約は、リソースを実行するノードを指定します。場所の制約については 「場所の制約」 で説明しています。order
制約 — 順序の制約はリソースが実行される順序を決めます。順序の制約については 「順序の制約」 で説明しています。コロケーション
の制約 - この制約は、他のリソースとの対比でリソースの配置先を決定します。コロケーションの制約については 「リソースのコロケーション」 で説明しています。
7.1. 場所の制約
resource-stickiness
値に影響されます。これは、リソースが現在実行しているノードに留まることをどの程度優先するかを決定します。resource-stickiness
値の設定に関する詳細は、「現在のノードを優先させるリソースの設定」 を参照してください。
7.1.1. 基本的な場所の制約
score
値を使用して、制約の相対的な優先度を指定できます。
pcs constraint location rsc prefers node[=score] [node[=score]] ...
pcs constraint location rsc avoids node[=score] [node[=score]] ...
表7.1 簡単な場所の制約オプション
フィールド | 説明 |
---|---|
rsc
|
リソース名
|
node
|
ノード名
|
score
|
リソースを特定ノードで優先的に実行するか、または実行を回避するかを示す正の整数値。
INFINITY は、リソースの場所制約のデフォルト score 値です。
pcs contraint location rsc prefers コマンドで score の値を INFINITY にすると、そのノードが利用可能な場合は、リソースがそのノードで優先的に実行します。ただし、そのノードが利用できない場合に、別のノードでそのリソースを実行しないようにする訳ではありません。
pcs contraint location rsc avoids コマンドで score に INFINITY を指定すると、その他のノードが利用できない場合でも、そのリソースはそのノードでは実行されないことを示します。これは、-INFINITY のスコアで pcs constraint location add コマンドを設定するのと同じです。
|
Webserver
リソースが、node1
ノードで優先的に実行するように指定する場所の制約を作成します。
# pcs constraint location Webserver prefers node1
dummy0
から dummy9
までのリソースの実行が node1
に優先されるように指定する場所の制約を作成します。
# pcs constraint location 'regexp%dummy[0-9]' prefers node1
# pcs constraint location 'regexp%dummy[[:digit:]]' prefers node1
7.1.2. 高度な場所の制約
resource-discovery
オプションを指定して、指定したリソースに対して、Pacemaker がこのノードでリソース検出を実行するかどうかの優先度を指定できます。物理的にリソースが稼働可能なノードのサブセットでリソース検出を制限すると、ノードが大量に存在する場合にパフォーマンスを大幅に改善できます。pacemaker_remote
を使用して、ノード数を 100 単位で拡大する場合は、このオプションの使用を検討してください。
resource-discovery
オプションを指定する場合の形式を示しています。id は制約 id であることに注意してください。rsc、node、score の意味は 表7.1「簡単な場所の制約オプション」 で説明しています。このコマンドでは、基本的な場所の制約に対応します。score を正の値にすると、リソースが特定のノードで優先的に実行するように設定されます。score を負の値にすると、リソースがノードを回避するように設定されます。基本的な場所の制約と同様に、制約にリソースの正規表現を使用することもできます。
pcs constraint location add id rsc node score [resource-discovery=option]
resource-discovery
オプションに指定できる値を説明しています。
表7.2 リソース検出の値
値 | 説明 |
---|---|
always
|
このノードに指定したリソースで、リソース検出を常に実行します。これは、リソースの場所の制約の
resource-discovery のデフォルト値です。
|
never
|
このノードで指定ししたリソースでのリソース検出は実行しません。
|
exclusive
|
このノード (および
exclusive と同様のマークが付いている他のノード) に指定したリソースに限定してリソース検出を行います。複数のノードで同じリソースの exclusive 検出を使用する複数の場所制約により、resource-discovery が排他的であるノードのサブセットが作成されます。1 つまたは複数のノードで、リソースが exclusive 検出用にマーク付けされている場合、そのリソースは、ノードのサブセット内にのみ配置できます。
|
resource-discovery
オプションを never
または exclusive
に設定すると、クラスターが認識しなくても、該当する場所でリソースがアクティブになる可能性があります。この場合は、(systemd
または管理者による起動などの) クラスターが制御できる範囲外でサービスが起動すると、複数の場所でリソースがアクティブになる可能性があります。また、クラスターの一部がダウンしたりスプリットブレインが発生しているときに resource-discovery
プロパティーが変更した場合や、ノードでリソースがアクティブなときにそのリソースやノードに対して resource-discovery
プロパティーが変更した場合にも、複数の場所でリソースがアクティブになる可能性があります。そのため、ノードの数が 9 以上で、特定の場所しかリソースを実行できない場合 (必要なソフトウェアが他の場所にインストールされていない場合など) に限り、このオプションは適しています。
7.1.3. ルールを使用したリソースの場所の確定
score
を省略すると、デフォルトの INFINITY に設定されます。resource-discovery
を省略すると、デフォルトの always
に設定されます。resource-discovery
オプションの詳細は、「高度な場所の制約」 を参照してください。基本的な場所の制約と同様に、制約にリソースの正規表現を使用することもできます。
score
を正または負の値にすることができます。正の値は prefers を示し、負の値は avoids を示します。
pcs constraint location rsc rule [resource-discovery=option] [role=master|slave] [score=score | score-attribute=attribute] expression
defined|not_defined attribute
attribute lt|gt|lte|gte|eq|ne [string|integer|version] value
date gt|lt date
date in-range date to date
date in-range date to duration duration_options ...
date-spec date_spec_options
expression and|or expression
(expression)
# pcs constraint location Webserver rule score=INFINITY date-spec years=2018
# pcs constraint location Webserver rule score=INFINITY date-spec hours="9-16" weekdays="1-5"
# pcs constraint location Webserver rule date-spec weekdays=5 monthdays=13 moon=4
7.1.4. 場所の制約ストラテジー
- オプトインクラスター - デフォルトでは、すべてのリソースを、どのノードでも実行できません。そして、特定のリソースに対してノードを選択的に許可できるようにクラスターを設定します。オプトインクラスターの設定方法は 「オプトインクラスターの設定」 で説明しています。
- オプトアウトクラスター - デフォルトでは、すべてのリソースをどのノードでも実行できるクラスターを設定してから、リソースを特定のノードで実行しないように、場所の制約を作成します。オプトアウトクラスターの設定方法は 「オプトアウトクラスターの設定」 で説明しています。これは、デフォルトの Pacemaker ストラテジーです。
7.1.4.1. オプトインクラスターの設定
symmetric-cluster
を false
に設定し、デフォルトでは、いずれのノードでもリソースの実行を許可しないようにします。
# pcs property set symmetric-cluster=false
Webserver
リソースでは example-1
ノードが優先され、Database
リソースでは example-2
ノードが優先されるようにし、いずれのリソースも優先ノードに障害が発生した場合は example-3
ノードにフェールオーバーできるようにします。オプトインクラスターに場所の制約を設定する場合は、スコアをゼロに設定すると、リソースに対してノードの優先や回避を指定せずに、リソースをノードで実行できます。
#pcs constraint location Webserver prefers example-1=200
#pcs constraint location Webserver prefers example-3=0
#pcs constraint location Database prefers example-2=200
#pcs constraint location Database prefers example-3=0
7.1.4.2. オプトアウトクラスターの設定
symmetric-cluster
を true
に設定し、デフォルトで、すべてのノードでリソースの実行を許可します。
# pcs property set symmetric-cluster=true
example-3
ノードにフェールオーバーできます。
#pcs constraint location Webserver prefers example-1=200
#pcs constraint location Webserver avoids example-2=INFINITY
#pcs constraint location Database avoids example-1=INFINITY
#pcs constraint location Database prefers example-2=200
7.1.5. 現在のノードを優先させるリソースの設定
resource-stickiness
値があります。resource-stickiness
値は、現在実行しているノード上にリソースが残す量を決定します。Pacemaker は、他の設定 (場所の制約の score 値など) とともに resource-stickiness
値を考慮して、リソースを別のノードに移動するか、そのまま残すかを決定します。
resource-stickiness
の値が 0 の状態でリソースが作成されます。resource-stickiness
が 0 に設定され、場所の制約がない Pacemaker のデフォルト動作では、クラスターノード間で均等に分散されるようにリソースを移動します。この設定では、正常なリソースの移動頻度が想定よりも増える可能性があります。この動作を防ぐには、デフォルトの resource-stickiness
の値を 1 に設定します。このデフォルトはクラスター内のすべてのリソースに適用されます。この小さい値は、作成する他の制約で簡単に上書きできますが、Pacemaker がクラスター全体で正常なリソースを不必要に移動しないようにするには十分です。
# pcs resource defaults resource-stickiness=1
resource-stickiness
の値が設定されている場合は、リソースが新たに追加されたノードに移動しません。この時点でリソースバランスが必要な場合は、resource-stickiness
の値を一時的に 0 に設定できます。
7.2. 順序の制約
pcs constraint order [action] resource_id then [action] resource_id [options]
表7.3 順序の制約のプロパティー
フィールド | 説明 |
---|---|
resource_id
|
動作を行うリソースの名前。
|
action
|
リソースで実行する動作。action プロパティーでは、以下の値が使用できます。
*
start - リソースを起動する
*
stop - リソースを停止する
*
promote - スレーブリソースからマスターリソースにリソースの昇格を行う
*
demote - マスターリソースからスレーブリソースにリソースの降格を行う
動作を指定しない場合のデフォルトの動作は
start です。マスターリソースとスレーブリソースについての詳細は 「多状態のリソース: 複数モードのリソース」 を参照してください。
|
kind オプション
|
制約の実施方法。
kind オプションでは、以下の値が使用できます。
*
Optional - 両方のリソースが指定の動作を実行する場合のみ適用されます。オプションの順序は 「勧告的な順序付け」 を参照してください。
*
Mandatory - 常に実施 (デフォルト値) します。1 番目に指定したリソースが停止している場合や起動できない場合は、2 番目に指定したリソースが停止します。必須の順序の詳細は、「強制的な順序付け」 を参照してください。
*
Serialize - リソースセットに対して 2 種類の動作、停止と起動が同時に発生しないようにする
|
symmetrical オプション
|
7.2.1. 強制的な順序付け
kind
オプションのデフォルトです。デフォルト値のままにしておくと 1 番目に指定しているリソースの状態が変化した場合、2 番目に指定したリソー スが必ず反応するようになります。
- 1 番目に指定している実行中のリソースを停止すると、2 番目に指定しているリソースも停止されます (実行している場合)。
- 1 番目に指定している実行中のリソースが実行しておらず起動できない場合には、指定したリソースは (実行していれば) 停止します。
- 2 番目に指定しているリソースの実行中に 1 番目に指定しているリソースが再起動されると、2 番目に指定しているリソースが停止され再起動されます。
7.2.2. 勧告的な順序付け
kind=Optional
オプションが指定された場合、制約は任意として考慮され、両方のリソースが指定のアクションを実行する場合のみ適用されます。1 番目に指定しているリソースの状態を変更しても、2 番目に指定しているリソースには影響しません。
VirtualIP
と dummy_resource
という名前のリソースに、勧告的な順序の制約を設定します。
# pcs constraint order VirtualIP then dummy_resource kind=Optional
7.2.3. 順序付けされたリソースセット
- リソースを順番に起動するように設定する必要があるものの、リソースは必ずしも同じ場所に配置しない場合
- リソース C の前にリソース A または B のいずれかが起動する必要があるものの、A と B の間には関係が設定されていない場合
- リソース C およびリソース D の前にリソース A およびリソース B の両方が起動している必要があるものの、A と B、または C と D の間には関係が設定されていない場合
sequential
- リソースセットに順序を付ける必要があるかどうかを指定します。true
またはfalse
に設定できます。sequential
をfalse
に設定すると、セットのメンバーに順序を設定せず、順序の制約にあるセット間で順序付けできます。そのため、このオプションは、制約に複数のセットが登録されている場合に限り有効です。それ以外の場合は、制約を設定しても効果がありません。require-all
- 続行する前にセットの全リソースがアクティブである必要があるかどうかを指定します。true
またはfalse
に設定できます。require-all
をfalse
に設定すると、次のセットに進む前に、セットの 1 つのリソースのみを開始する必要があります。require-all
をfalse
に設定しても、sequential
がfalse
に設定されている順序なしセットと併用しない限り、効果はありません。
setoptions
パラメーターの後に、リソースのセットに対する以下の制約オプションを設定できます。
id
- 定義する制約の名前を指定します。score
- 制約の優先度を示します。このオプションの詳細は 表7.4「コロケーション制約のプロパティー」 を参照してください。
pcs constraint order set resource1 resource2 [resourceN]... [options] [set resourceX resourceY ... [options]] [setoptions [constraint_options]]
D1
、D2
、D3
という 3 つのリソースがある場合は、次のコマンドを実行すると、この 3 つのリソースを、順序を指定したリソースセットとして設定します。
# pcs constraint order set D1 D2 D3
7.2.4. 順序の制約からリソースを削除
pcs constraint order remove resource1 [resourceN]...
7.3. リソースのコロケーション
pcs constraint colocation add [master|slave] source_resource with [master|slave] target_resource [score] [options]
表7.4 コロケーション制約のプロパティー
フィールド | 説明 |
---|---|
source_resource
|
コロケーションソース。制約の条件を満たさない場合、クラスターではこのリソースの実行を許可しないことを決定する可能性があります。
|
target_resource
|
コロケーションターゲット。クラスターは、このリソースの配置先を決定してから、ソースリソースの配置先を決定します。
|
score
|
正の値を指定するとリソースが同じノードで実行します。負の値を指定すると同じノードで実行しなくなります。デフォルト値である +
INFINITY を指定すると、source_resource は必ず target_resource と同じノードで実行します。-INFINITY は、source_resource を target_resource と同じノードで実行してはならないことを示しています。
|
7.3.1. 強制的な配置
+INFINITY
または -INFINITY
の場合は常に強制的な配置が発生します。制約条件が満たされないと source_resource の実行が許可されません。score=INFINITY
の場合、target_resource がアクティブではないケースが含まれます。
myresource1
を、常に myresource2
と同じマシンで実行する必要がある場合は、次のような制約を追加します。
# pcs constraint colocation add myresource1 with myresource2 score=INFINITY
INFINITY
を使用しているため、(何らかの理由で) myresource2
がクラスターのいずれのノードでも実行できない場合は、myresource1
の実行が許可されません。
myresource1
が myresource2
と同じマシンでは実行されないようにクラスターを設定することもできます。この場合は score=-INFINITY
を使用します。
# pcs constraint colocation add myresource1 with myresource2 score=-INFINITY
-INFINITY
を指定することで、制約は結合しています。このため、実行できる場所として残っているノードで myresource2
がすでに実行されている場合は、いずれのノードでも myresource1
を実行できなくなります。
7.3.2. 勧告的な配置
-INFINITY
より大きく、INFINITY
より小さい場合、クラスターは希望の設定に対応しようとしますが、クラスターリソースの一部を停止するという選択肢がある場合には、その設定が無視される場合があります。勧告的なコロケーション制約と設定の他の要素を組み合わせると、強制的であるように動作させることができます。
7.3.3. 複数リソースのコロケート
- リソースのセットにコロケーションを設定する必要があるものの、リソースが必ずしも順番に起動する必要がない場合
- リソース A または B のいずれかに対してコロケーションを設定する必要があるリソース C が起動したものの、A と B の間に関係が設定されていない場合。
- リソース C およびリソース D を、リソース A およびリソース B の両方に対してコロケーションを設定する必要があるものの、A と B の間、または C と D の間に関係が設定されていない場合
sequential
- セットのメンバーで相互のコロケーションが必要であるかどうかを指定します。true
またはfalse
に設定できます。sequential
をfalse
に設定すると、このセットのメンバーがアクティブであるかどうかに関係なく、このセットのメンバーを、制約の中で、このセットの後にリストされている他のセットに対してコロケーションを設定できます。そのため、このオプションは制約でこのセットの後に他のセットが指定されている場合に限り有効です。他のセットが指定されていない場合は、制約の効果がありません。
setoptions
パラメーターの後に、リソースのセットに対する以下の制約オプションを設定できます。
kind
: 制約の実行方法を示します。このオプションの詳細は 表7.3「順序の制約のプロパティー」 を参照してください。symmetrical
: リソースを停止する順序を示します。デフォルトの true に設定されていると逆順でリソースの停止を行ないます。デフォルト値:true
id
- 定義する制約の名前を指定します。
pcs constraint colocation set resource1 resource2 [resourceN]... [options] [set resourceX resourceY ... [options]] [setoptions [constraint_options]]
7.3.4. コロケーション制約の削除
pcs constraint colocation remove source_resource target_resource
7.4. 制約の表示
pcs constraint list|show
resources
を指定すると、リソース別に場所の制約が表示されます。これはデフォルトの動作です。nodes
を指定すると、ノード別に場所の制約が表示されます。- 特定のリソースまたはノードを指定すると、そのリソースまたはノードの情報のみが表示されます。
pcs constraint location [show resources|nodes [specific nodes|resources]] [--full]
--full
オプションを指定すると、制約の内部 ID が表示されます。
pcs constraint order show [--full]
--full
オプションを指定すると、制約の内部 ID が表示されます。
pcs constraint colocation show [--full]
pcs constraint ref resource ...
第8章 クラスターリソースの管理
8.1. リソースを手作業で移動する
- ノードがメンテナンスで、そのノードで実行中の全リソースを別のノードに移行する必要がある
- 個別に指定したリソースを移行する必要がある
- 「現在のノードからリソースを移動」 の説明に従って、pcs resource move コマンドを使用して現在稼働しているノードからリソースを移動します。
- pcs resource relocate run コマンドを使用して、現在のクラスター状態、制約、リソースの場所、およびその他の設定によって決定される優先ノードへリソースを移動します。このコマンドの詳細は、「リソースの優先ノードへの移動」 を参照してください。
8.1.1. 現在のノードからリソースを移動
destination_node
を使用します。
pcs resource move resource_id [destination_node] [--master] [lifetime=lifetime]
--master
パラメーターを指定すると、制約の範囲がマスターロールに限定され、resource_id の代わりに master_id を指定する必要があります。
pcs resource move
コマンドの lifetime
パラメーターを設定すると、制限が維持される期間を指定できます。lifetime
パラメーターの単位は、ISO 8601 に定義されている形式に従って指定します。ISO 8601 では、Y (年)、M (月)、W (週)、D (日)、H (時)、M (分)、S (秒) のように、単位を大文字で指定する必要があります。
lifetime
パラメーターが 5M の場合は 5 カ月の間隔を示し、lifetime
パラメーターが PT5M の場合は 5 分の間隔を示します。
lifetime
パラメーターは、cluster-recheck-interval
クラスタープロパティーに定義した間隔で確認されます。デフォルト値は 15 分です。このパラメーターをより頻繁に確認する必要がある場合は、次のコマンドを実行して、この値をリセットできます。
pcs property set cluster-recheck-interval=value
pcs resource move
コマンドに --wait[=n]
パラメーターを設定し、移行先のノードでリソースが起動するまでの待機時間 (秒単位) を指定できます。待機時間がこの値を超えると、リソースが起動した場合に 0 が返され、リソースが起動しなかった場合は 1 が返されます。n の値を指定しないと、デフォルトのリソースのタイムアウト値が使用されます。
resource1
リソースを example-node2
ノードへ移動し、1 時間 30 分は元のノードへ戻らないようにします。
pcs resource move resource1 example-node2 lifetime=PT1H30M
resource1
リソースを example-node2
ノードへ移行し、30 分は元のノードへ戻らないようにします。
pcs resource move resource1 example-node2 lifetime=PT30M
8.1.2. リソースの優先ノードへの移動
pcs resource relocate run [resource1] [resource2] ...
8.2. 障害発生によるリソースの移動
migration-threshold
オプションを設定し、定義した回数だけ障害が発生した場合にリソースが新しいノードに移動されるように設定できます。このしきい値に一度到達すると、このノードでは、以下が行われるまで、障害が発生したリソースを実行できなくなります。
- 管理者は pcs resource failcount コマンドを使用して手作業でリソースの
failcount
をリセットします。 - リソースの
failure-timeout
値に達する
migration-threshold
の値が INFINITY
に設定されています。INFINITY
は、内部的に非常に大きな有限数として定義されます。0 にすると、migration-threshold
機能が無効になります。
migration-threshold
を設定するのと、リソースの状態を維持しながら別の場所に移動させるようにリソースの移動を設定するのは同じではありません。
dummy_resource
リソースに、移行しきい値 10 を追加します。この場合は、障害が 10 回発生すると、そのリソースが新しいノードに移動します。
# pcs resource meta dummy_resource migration-threshold=10
# pcs resource defaults migration-threshold=10
start-failure-is-fatal
が true
に設定された場合 (デフォルト) は、起動の失敗により failcount
が INFINITY
に設定され、リソースが常に即座に移動するようになります。start-failure-is-fatal
オプションの詳細は、表12.1「クラスターのプロパティー」 を参照してください。
8.3. 接続状態変更によるリソースの移動
ping
リソースをクラスターに追加します。ping
リソースは、同じ名前のシステムユーティリティーを使用して、マシン (DNS ホスト名または IPv4/IPv6 アドレスによって指定される一覧) にアクセス可能であるかをテストし、その結果を使用してpingd
と呼ばれるノード属性を維持します。- 接続が失われたときに別のノードにリソースを移動させる、リソース場所制約を設定します。
ping
リソースに設定できるプロパティーを示します。
表8.1 ping リソースのプロパティー
フィールド | 説明 |
---|---|
dampen
| |
multiplier
| |
host_list
|
gateway.example.com
への接続を検証する ping
リソースを作成します。実際には、ネットワークゲートウェイやルーターへの接続を検証します。リソースがすべてのクラスターノードで実行されるように、ping
リソースをクローンとして設定します。
# pcs resource create ping ocf:pacemaker:ping dampen=5s multiplier=1000 host_list=gateway.example.com clone
Webserver
に場所制約ルールを設定します。これにより、Webserver
リソースが現在実行しているホストが gateway.example.com
へ ping できない場合に、Webserver リソースを gateway.example.com
へ ping できるホストに移動します。
# pcs constraint location Webserver rule score=-INFINITY pingd lt 1 or not_defined pingd
8.4. クラスターリソースの有効化、無効化、および禁止
--wait
オプションを指定すると、pcs はリソースが停止するまで n 秒間待機します。その後、リソースが停止した場合は 0 を返し、リソースが停止しなかった場合は 1 を返します。n を指定しないと、デフォルトの 60 分に設定されます。
pcs resource disable resource_id [--wait[=n]]
--wait
オプションを指定すると、pcs はリソースが開始するまで最長で n 秒間待機します。その後、リソースが開始した場合には 0、リソースが開始しなかった場合には 1 を返します。n を指定しないと、デフォルトの 60 分に設定されます。
pcs resource enable resource_id [--wait[=n]]
pcs resource ban resource_id [node] [--master] [lifetime=lifetime] [--wait[=n]]
--master
パラメーターを指定すると、制約の範囲がマスターロールに限定され、resource_id の代わりに master_id を指定する必要があります。
pcs resource ban
コマンドに lifetime
パラメーターを設定し、制約が持続する期間を指定できます。lifetime
パラメーターの単位や、lifetime
パラメーターがチェックされる間隔を指定する方法については、「リソースを手作業で移動する」 を参照してください。
pcs resource ban
コマンドに --wait[=n]
パラメーターを設定し、移行先のノードでリソースが起動するまでの待機時間 (秒単位) できます。待機時間がこの値を超えると、リソースが起動した場合に 0 が返され、リソースが起動しなかった場合は 1 が返されます。n の値を指定しないと、デフォルトのリソースのタイムアウト値が使用されます。
pcs resource debug-start resource_id
8.5. モニター操作の無効化
enabled="false"
を操作の定義に追加します。モニターリング操作を再度有効にするには、enabled="true"
を操作の定義に設定します。
#pcs resource update resourceXZY op monitor enabled=false
#pcs resource update resourceXZY op monitor enabled=true
# pcs resource update resourceXZY op monitor timeout=600 enabled=true
8.6. 管理リソース
unmanaged
モードに設定できます。このモードでは、リソースは設定に維持されますが Pacemaker はリソースを管理しません。
非管理
モードに設定します。
pcs resource unmanage resource1 [resource2] ...
管理
モードに設定します。
pcs resource manage resource1 [resource2] ...
管理
または 非管理
モードに設定し、グループに含まれるリソースを個別に管理できます。
第9章 高度な設定
9.1. リソースのクローン
ext4
などの非クラスター化ファイルシステムをマウントする Filesystem
リソースのクローンは作成しないでください。ext4
パーティションはクラスターを認識しないため、同時に複数のノードから繰り返し行われる読み取りや書き込みの操作には適していません。
9.1.1. クローンリソースの作成と削除
pcs resource create resource_id standard:provider:type|type [resource options] \ clone [meta clone_options]
resource_id-clone
になります。
pcs resource clone resource_id | group_name [clone_options]...
resource_id-clone
または group_name-clone
になります。
-clone
を付けた名前になります。次のコマンドは、タイプが apache
のリソース webfarm
と、そのクローンとなるリソース webfarm-clone
を作成します。
# pcs resource create webfarm apache clone
interleave=true
オプションを設定する必要があります。これにより、依存されているクローンが同じノードで停止または開始した時に、依存しているクローンのコピーを停止または開始できるようになります。このオプションを設定しない場合は、次のようになります。クローンリソース B がクローンリソース A に依存していると、ノードがクラスターから離れてから戻ってきてから、そのノードでリソース A が起動すると、リソース B の全コピーが、全ノードで再起動します。これは、依存しているクローンリソースに interleave
オプションが設定されていない場合は、そのリソースの全インスタンスが、そのリソースが依存しているリソースの実行インスタンスに依存するためです。
pcs resource unclone resource_id | group_name
表9.1 リソースのクローンオプション
フィールド | 説明 |
---|---|
priority, target-role, is-managed
|
表6.3「リソースのメタオプション」 に従って、クローンされたリソースから継承されるオプション。
|
clone-max
| |
clone-node-max
| |
notify
| |
globally-unique
|
クローンの各コピーで異なる機能を実行させるかどうか。使用できる値は
false および true です。
このオプションの値を
false にすると、リソースが実行しているすべてのノードで同じ動作を行うため、1 台のマシンごとに実行できるクローンのコピーは 1 つです。
このオプションの値を
true にすると、任意のマシンで実行中のクローンのコピーが、別のインスタンスが別のノードまたは同じノードで実行されているかに関係なく、そのインスタンスと同等ではありません。clone-node-max の値が 1 より大きい場合にはデフォルト値が true になり、小さい場合は false がデフォルト値になります。
|
ordered
| |
interleave
| |
clone-min
|
このフィールドに値を指定した場合は、
interleave オプションが true に設定されていても、元のクローンの後に順序付けされたクローンは、元のクローンに指定された数だけインスタンスが実行するまで、起動できません。
|
9.1.2. 制約のクローン作成
clone-max
には、そのクラスター内のノード合計より小さい数を設定できます。この場合は、リソースの場所の制約を使用して、クラスターが優先的にコピーを割り当てるノードを指定できます。クローンの ID を使用する点以外、制約は通常のリソースの場合と全く変わらずクローンに記述されます。
webfarm-clone
を node1
に優先的に割り当てる場所の制約を作成します。
# pcs constraint location webfarm-clone prefers node1
interleave
クローンオプションをデフォルトの false
のままにしているため、起動する必要がある webfarm-clone
のすべてのインスタンスが起動するまで、webfarm-stats
のインスタンスは起動しません。webfarm-clone
のコピーを 1 つも起動できない場合にのみ、webfarm-stats
がアクティブになりません。さらに、webfarm-stats
が停止するまで待機してから、webfarm-clone
が停止します。
# pcs constraint order start webfarm-clone then webfarm-stats
webfarm-stats
リソースが webfarm-clone
のアクティブなコピーと同じノードで実行するようにします。
# pcs constraint colocation add webfarm-stats with webfarm-clone
9.1.3. 粘着性のクローン作成
resource-stickiness
の値を指定しないと、クローンが使用する値は 1 となります。値を小さくすることで他のリソースのスコア計算への阻害を最小限に抑えながら、Pacemaker によるクラスター内の不要なコピーの移動を阻止することができます。
9.2. 多状態のリソース: 複数モードのリソース
Master
および Slave
のいずれかにできます。モードの名前には特別な意味はありませんが、インスタンスの起動時に、Slave
状態で起動する必要があるという制限があります。
pcs resource create resource_id standard:provider:type|type [resource options] master [master_options]
resource_id-master
になります。
pcs resource create resource_id standard:provider:type|type [resource options] --master [meta master_options]
resource_id-master
または group_name-master
になります。
pcs resource master master/slave_name resource_id|group_name [master_options]
表9.2 多状態リソースのプロパティー
フィールド | 説明 |
---|---|
id
|
多状態リソースに付ける名前
|
priority 、target-role 、is-managed
|
表6.3「リソースのメタオプション」を参照してください。
|
clone-max 、clone-node-max 、notify 、globally-unique 、ordered 、interleave
|
表9.1「リソースのクローンオプション」を参照してください。
|
master-max
| |
master-node-max
|
9.2.1. 多状態リソースの監視
ms_resource
のマスターリソースに 11 秒間隔の監視操作を設定します。この監視操作は、10 秒間隔で行われるデフォルトの監視操作とは別に追加されます。
# pcs resource op add ms_resource interval=11s role=Master
9.2.2. 多状態制約
pcs constraint colocation add [master|slave] source_resource with [master|slave] target_resource [score] [options]
promote
です。さらに、demote
を指定するとリソースをマスターからスレーブに降格できます。
pcs constraint order [action] resource_id then [action] resource_id [options]
9.2.3. 多状態の粘着性 (Stickiness)
9.3. リソースとしての仮想ドメインの設定
VirtualDomain
をリソースタイプとして指定して、libvirt
仮想化フレームワークにより管理される仮想ドメインを設定できます。
- 仮想ドメインは、クラスターリソースとして設定する前に停止する必要があります。
- 仮想ドメインをクラスターリソースにすると、クラスターツールを使用しない限り、起動、停止、または移行を行うことができません。
- クラスターリソースとして設定した仮想ドメインを、ホストの起動時に起動するように設定することはできません。
- すべてのノードは、それぞれの管理される仮想ドメインの必要な設定ファイルおよびストレージデバイスにアクセスできる必要があります。
VirtualDomain
リソースに設定できるリソースオプションを説明します。
表9.3 仮想ドメインリソースのリソースオプション
フィールド | デフォルト | 説明 |
---|---|---|
config
| |
(必須) この仮想ドメインの
libvirt 設定ファイルへの絶対パス。
|
hypervisor
|
システムに依存
|
接続先のハイパーバイザーの URI。virsh --quiet uri コマンドを実行してシステムのデフォルト URI を判別できます。
|
force_stop
| 0
|
停止時にドメインを常に強制的にシャットダウン (破棄) します。デフォルト動作では、正常なシャットダウンの試行に失敗した後でのみ、強制シャットダウンを実行します。仮想ドメイン (または仮想化バックエンド) が正常なシャットダウンに対応していない場合に限り、これを
true に設定する必要があります。
|
migration_transport
|
システムに依存
|
移行中にリモートハイパーバイザーに接続するのに使用されるトランスポート。このパラメーターを省略すると、リソースは
libvirt のデフォルトトランスポートを使用して、リモートハイパーバイザーに接続します。
|
migration_network_suffix
| |
専用の移行ネットワークを使用します。移行 URI は、このパラメーターの値をノード名の末尾に追加することにより設定されます。ノード名が完全修飾ドメイン名 (FQDN) の場合は、FQDN の最初のピリオド (.) の直前に接尾辞を挿入します。この設定されたホスト名がローカルで解決可能であり、関連する IP アドレスが優先ネットワークを介して到達可能であることを確認してください。
|
monitor_scripts
| |
仮想ドメイン内でサービスの監視を追加で実行する場合は、監視するスクリプトの一覧とともに、このパラメーターを追加します。注記: 監視スクリプトを使用する場合、
start および migrate_from の操作は、すべての監視スクリプトが正常に完了した場合にのみ完了します。この遅延に対応できるように、この操作のタイムアウトを必ず設定してください。
|
autoset_utilization_cpu
| true
| true に設定すると、監視の実行時に、エージェントが virsh から domainU の vCPU 数を検出し、これをリソースの CPU 使用率に組み込みます。
|
autoset_utilization_hv_memory
| true
|
true に設定すると、監視の実行時に、エージェントが
virsh から Max memor 数を検出し、これをリソースの hv_memory の使用率に組み込みます。
|
migrateport
|
ランダムハイポート
|
このポートは、
qemu 移行 URI で使用されます。これを設定しないと、ポートにはランダムハイポートが使用されます。
|
snapshot
| |
仮想マシンイメージが保存されるスナップショットディレクトリーへのパス。このパラメーターが設定されている場合、仮想マシンの RAM 状態は、停止時にスナップショットディレクトリーのファイルに保存されます。起動時にドメインのステータスファイルが存在すると、ドメインは、最後に停止する直前の状態に復元されます。このオプションは、
force_stop オプションと互換性がありません。
|
VirtualDomain
リソースオプションに加えて、allow-migrate
メタデータオプションを設定して、リソースの別のノードへのライブ移行を許可できます。このオプションを true
に設定すると、状態を失うことなくリソースを移行できます。このオプションがデフォルトの状態である false
に設定されていると、仮想ドメインは、ノード間で移行される際に、最初のノードでシャットダウンしてから、2 番目のノードで再起動します。
VirtualDomain
リソースを作成します。
- 仮想マシンを管理するために
VirtualDomain
リソースエージェントを作成する場合、Pacemaker は仮想マシンの xml 設定ファイルをディスクのファイルにダンプすることを必要とします。たとえば、guest1
という名前の仮想マシンを作成し、ホストにあるファイルに xml をダンプします。好きなファイル名を使用できますが、この例では/etc/pacemaker/guest1.xml
を使用します。#
virsh dumpxml guest1 > /etc/pacemaker/guest1.xml
- ゲストノードが実行している場合はシャットダウンします。Pacemaker は、クラスターで設定されているノードを起動します。
VirtualDoman
リソースを pcs resource create コマンドを使用して設定します。たとえば、以下のコマンドは、VM
という名前のVirtualDomain
リソースを設定します。allow-migrate
オプションはtrue
に設定されるため、pcs resource move VM nodeX
コマンドはライブ移行として実行されます。# pcs resource create VM VirtualDomain config=.../vm.xml \ migration_transport=ssh meta allow-migrate=true
9.4. pacemaker_remote サービス
pacemaker_remote
サービスを使用すると、corosync
を実行していないノードをクラスターに統合し、そのリソースが実際のクラスターノードであるかのように、クラスターがリソースを管理できます。
pacemaker_remote
サービスが提供する機能には以下が含まれます。
pacemaker_remote
サービスは、RHEL 7.7 の Red Hat サポート制限である 32 ノードを超えた拡張を可能にします。pacemaker_remote
サービスを使用すると、仮想環境をクラスターリソースとして管理でき、さらに仮想環境内の個別のサービスをクラスターリソースとして管理できます。
pacemaker_remote
サービスは、以下の用語を使用して記述されます。
- クラスターノード - 高可用性サービスを実行しているノード (
pacemaker
およびcorosync
)。 - リモートノード -
pacemaker_remote
を実行して、corosync
クラスターメンバーシップを必要としないクラスターにリモートで統合するノード。リモートノードは、ocf:pacemaker:remote
リソースエージェントを使用するクラスターリソースとして設定されます。 - ゲストノード -
pacemaker_remote
サービスを実行する仮想ゲストノード。仮想ゲストリソースはクラスターにより管理されます。クラスターにより起動し、リモートノードとしてクラスターに統合されます。 - pacemaker_remote: Pacemaker クラスター環境のリモートノードおよびゲストノード (KVM および LXC) 内でリモートアプリケーション管理を実行できるサービスデーモン。このサービスは、corosync を実行していないノード上でリソースをリモートで管理できる Pacemaker のローカルリソース管理デーモン (LRMD) の強化バージョンです。
- LXC —
libvirt-lxc
Linux コンテナードライバーで定義される Linux Container
pacemaker_remote
サービスを実行している Pacemaker クラスターには次のような特徴があります。
- リモートノードおよびゲストノードは、
pacemaker_remote
サービスを実行します (仮想マシン側で必要な設定はほとんどありません)。 - クラスターノードで実行しているクラスタースタック (
pacemaker
およびcorosync
) はリモートノードでpacemaker_remote
サービスに接続するため、クラスターに統合できます。 - クラスターノードで実行しているクラスタースタック (
pacemaker
およびcorosync
) はゲストノードを開始し、ゲストノードでpacemaker_remote
サービスに即座に接続するため、クラスターに統合できます。
- クォーラムでは実行されない
- フェンスデバイスのアクションを実行しません
- クラスターの指定コントローラー (DC) として機能できない
- pcs コマンドのすべてを実行できません
9.4.1. ホストとゲストの認証
pacemaker_remote
を実行しているノードは、同じ秘密鍵を共有する必要があります。デフォルトでは、クラスターノードとリモートノードの両方でこのキーを /etc/pacemaker/authkey
に格納する必要があります。
authkey
を、pcs cluster node add-remote コマンドでリモートノードの authkey
をセットアップできます。
9.4.2. ゲストノードリソースのオプション
VirtualDomain
リソースを作成します。VirtualDomain
リソースに設定できるオプションの説明は、表9.3「仮想ドメインリソースのリソースオプション」 を参照してください。
VirtualDomain
リソースオプションのほかにも、メタデータオプションはリソースをゲストノードとして定義し、接続パラメーターを定義します。Red Hat Enterprise Linux 7.4 では、 pcs cluster node add-guest コマンドを使用してこれらのリソースオプションを設定してください。7.4 以前のリリースでは、リソースを作成する際に、これらのオプションを設定できます。表9.4「KVM/LXC リソースをリモートノードとして設定するメタデータオプション」 では、このようなメタデータオプションについて説明します。
表9.4 KVM/LXC リソースをリモートノードとして設定するメタデータオプション
フィールド | デフォルト | 説明 |
---|---|---|
remote-node
|
<none>
|
このリソースが定義するゲストノードの名前。リソースをゲストノードとして有効にし、ゲストノードの識別に使用される一意名を定義します。警告: この値を、リソースやノードの ID と重複させることはできません。
|
remote-port
|
3121
| pacemaker_remote へのゲスト接続に使用するカスタムのポートを設定します。
|
remote-addr
|
ホスト名として使用される
remote-node 値
|
リモートノードの名前がゲストのホスト名ではない場合に接続する IP アドレスまたはホスト名
|
remote-connect-timeout
|
60s
|
保留中のゲスト接続がタイムアウトするまでの時間
|
9.4.3. リモートノードリソースのオプション
ocf:pacemaker:remote
がリソースエージェントとして指定された状態で、クラスターリソースとして定義されます。Red Hat Enterprise Linux 7.4 では、pcs cluster node add-remote コマンドを使用して、このリソースを作成してください。7.4 以前のリリースでは、pcs resource create コマンドを使用してこのリソースを作成できます。表9.5「リモートノードのリソースオプション」 は、remote
リソースに設定できるリソースオプションを説明します。
表9.5 リモートノードのリソースオプション
フィールド | デフォルト | 説明 |
---|---|---|
reconnect_interval
|
0
|
リモートノードへのアクティブな接続が切断された後、リモートノードへの再接続を試みる前に待機する時間 (秒単位)。この待機期間は繰り返し発生します。待機期間の後に再接続に失敗した場合、待機期間の後に、新しい再接続が試行されます。このオプションが使用されると、Pacemaker は待機期間の後に無限にリモートノードへ接続を試みます。
|
server
| |
接続するサーバーの場所。IP アドレスまたはホスト名を指定できます。
|
port
| |
接続する TCP ポート。
|
9.4.4. ポートのデフォルトの場所の変更
pacemaker_remote
のいずれかのポートのデフォルトの場所を変更する必要がある場合は、これらのデーモンのどちらにも影響を与える PCMK_remote_port
環境変数を設定できます。この環境変数は、以下のように /etc/sysconfig/pacemaker
に配置して有効にできます。
#==#==# Pacemaker Remote ... # # Specify a custom port for Pacemaker Remote connections PCMK_remote_port=3121
PCMK_remote_port
変数をそのノードの /etc/sysconfig/pacemaker
ファイルに設定する必要があります。また、ゲストノードまたはリモートノードの接続を作成するクラスターリソースを同じポート番号で設定する必要もあります (ゲストノードの場合は remote-port
メタデータオプション、リモートノードの場合は port
オプションを使用します)。
9.4.5. 設定の概要: KVM ゲストノード
libvirt
と KVM 仮想ゲストを使用して、Pacemaker で仮想マシンを起動し、そのマシンをゲストノードとして統合する方法の概要を説明します。
- 「リソースとしての仮想ドメインの設定」 で説明したように、
VirtualDomain
リソースを設定します。 - Red Hat Enterprise Linux 7.3 以前を使用しているシステムでは、以下の手順に従って、すべてのクラスターノードと仮想マシン上で、パス
/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
- Red Hat Enterprise Linux 7.4 では、すべての仮想マシンで以下のコマンドを実行し、
pacemaker_remote
パッケージをインストールし、pcsd
サービスを起動し、これを起動時に実行できるようにし、ファイアウォールを介して TCP のポート 3121 を許可します。#
yum install pacemaker-remote resource-agents pcs
#systemctl start pcsd.service
#systemctl enable pcsd.service
#firewall-cmd --add-port 3121/tcp --permanent
#firewall-cmd --add-port 2224/tcp --permanent
#firewall-cmd --reload
Red Hat Enterprise Linux 7.3 以前では、すべての仮想マシンで以下のコマンドを実行し、pacemaker_remote
パッケージをインストールして、pacemaker_remote
サービスを起動し、これを起動時に実行できるようにして、ファイアウォールを介して TCP のポート 3121 を許可します。#
yum install pacemaker-remote resource-agents pcs
#systemctl start pacemaker_remote.service
#systemctl enable pacemaker_remote.service
#firewall-cmd --add-port 3121/tcp --permanent
#firewall-cmd --add-port 2224/tcp --permanent
#firewall-cmd --reload
- 各仮想マシンに、すべてのノードが認識できる静的ネットワークアドレスと一意なホスト名を割り当てます。ゲスト仮想マシンに静的 IP アドレスを設定する方法については、『仮想化の導入および管理ガイド』を参照してください。
- Red Hat Enterprise Linux 7.4 以降では、以下のコマンドを使用して、既存の
VirtualDomain
リソースをゲストノードに変換します。このコマンドは、追加するゲストノードではなく、クラスターノードで実行する必要があります。リソースを変換する以外にも、このコマンドは/etc/pacemaker/authkey
をゲストノードにコピーし、ゲストノードでpacemaker_remote
デーモンを起動し、これを有効にします。pcs cluster node add-guest hostname resource_id [options]
Red Hat Linux 7.3 以前では、以下のコマンドを使用して既存のVirtualDomain
リソースをゲストノードに変換します。このコマンドは、追加するゲストノードではなく、クラスターノードで実行する必要があります。pcs cluster remote-node add hostname resource_id [options]
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.4.6. 設定概要: リモートノード (Red Hat Enterprise Linux 7.4)
- リモートノードを設定するノードで、ローカルファイアウォールを介してクラスター関連のサービスを許可します。
#
firewall-cmd --permanent --add-service=high-availability
success #firewall-cmd --reload
success注記iptables
を直接使用する場合や、firewalld
以外のファイアウォールソリューションを使用する場合は、単に TCP のポート 2224 および 3121 を開きます。 - リモートノードで pacemaker_remote デーモンをインストールします。
#
yum install -y pacemaker-remote resource-agents pcs
- リモートノードで、
pcsd
を開始し、有効にします。#
systemctl start pcsd.service
#systemctl enable pcsd.service
- リモートノードとして追加するノードに
pcs
を認証していない場合は、認証します。#
pcs cluster auth remote1
- 以下のコマンドを使用して、リモートノードリソースをクラスターに追加します。このコマンドは、関連するすべての設定ファイルを新規ノードに追加し、ノードを起動し、これをシステムの起動時に
pacemaker_remote
を開始するように設定することもできます。このコマンドは、追加するリモートノードではなく、クラスターノードで実行する必要があります。#
pcs cluster node add-remote remote1
remote
リソースをクラスターに追加した後、リモートノードを、クラスター内の他のノードを処理するのと同じように処理できます。たとえば、以下のコマンドをクラスターノードから実行すると、リソースを作成し、そのリソースにリソース制約を配置して、リモートノードで実行できます。#
pcs resource create webserver apache configfile=/etc/httpd/conf/httpd.conf op monitor interval=30s
#pcs constraint location webserver prefers remote1
警告リソースグループ、コロケーション制約、または順序制約でノード接続リソースを利用しないでください。- リモートノードのフェンスリソースを設定します。リモートノードは、クラスターノードと同じ方法でフェンスされます。クラスターノードと同様に、リモートノードで使用するフェンスリソースを設定します。リモートノードはフェンスアクションを開始できないことに注意してください。クラスターノードのみが、実際に別のノードに対してフェンシング操作を実行できます。
9.4.7. 設定概要: リモートノード (Red Hat Enterprise Linux 7.3 以前)
- リモートノードを設定するノードで、ローカルファイアウォールを介してクラスター関連のサービスを許可します。
#
firewall-cmd --permanent --add-service=high-availability
success #firewall-cmd --reload
success注記iptables
を直接使用する場合や、firewalld
以外のファイアウォールソリューションを使用する場合は、単に TCP のポート 2224 および 3121 を開きます。 - リモートノードで pacemaker_remote デーモンをインストールします。
#
yum install -y pacemaker-remote resource-agents pcs
- 適切に通信するには、すべてのノード (クラスターノードとリモートノードの両方) に同じ認証キーがインストールされている必要があります。既存ノードにすでにキーがある場合、そのキーを使用してリモートノードにコピーします。それ以外の場合はリモートノードで新しいキーを作成します。リモートノードで以下のコマンドを実行し、セキュアなパーミッションを持つ認証キーのディレクトリーを作成します。
#
mkdir -p --mode=0750 /etc/pacemaker
#chgrp haclient /etc/pacemaker
以下のコマンドは、リモートノードで暗号化キーを作成する方法の 1 つを示しています。#
dd if=/dev/urandom of=/etc/pacemaker/authkey bs=4096 count=1
- リモートノードで pacemaker_remote デーモンを開始し、有効にします。
#
systemctl enable pacemaker_remote.service
#systemctl start pacemaker_remote.service
- クラスターノードにて、リモートノードの認証キーと同じパスを持つ共有された認証キーの保存場所を作成し、そのディレクトリーにキーをコピーします。この例では、キーが作成されたリモートノードからキーがコピーされます。
#
mkdir -p --mode=0750 /etc/pacemaker
#chgrp haclient /etc/pacemaker
#scp remote1:/etc/pacemaker/authkey /etc/pacemaker/authkey
- クラスターノードから以下のコマンドを実行し、
remote
リソースを作成します。この例では、リモートノードはremote1
になります。#
pcs resource create remote1 ocf:pacemaker:remote
remote
リソースの作成後、リモートノードをクラスターの他のノードと同じように扱うことができます。たとえば、以下のコマンドをクラスターノードから実行すると、リソースを作成し、そのリソースにリソース制約を配置して、リモートノードで実行できます。#
pcs resource create webserver apache configfile=/etc/httpd/conf/httpd.conf op monitor interval=30s
#pcs constraint location webserver prefers remote1
警告リソースグループ、コロケーション制約、または順序制約でノード接続リソースを利用しないでください。- リモートノードのフェンスリソースを設定します。リモートノードは、クラスターノードと同じ方法でフェンスされます。クラスターノードと同様に、リモートノードで使用するフェンスリソースを設定します。リモートノードはフェンスアクションを開始できないことに注意してください。クラスターノードのみが、実際に別のノードに対してフェンシング操作を実行できます。
9.4.8. システムアップグレードおよび pacemaker_remote
pacemaker_remote
サービスが停止した場合にノードの停止前にクラスターがノードをリソースから正常に移行するようになりました。これにより、クラスターからノードを削除せずに、ソフトウェアのアップグレードやその他の定期的なメンテナンスを実行できるようになりました。ただし、pacemaker_remote
がシャットダウンすると、クラスターは即座に再接続を試みます。リソースのモニタータイムアウトが発生する前に pacemaker_remote
が再起動されないと、クラスターは監視操作が失敗したと判断します。
pacemaker_remote
サービスが停止したときに監視が失敗しないようにするには、以下の手順に従って、pacemaker_remote
を停止する可能性があるシステム管理を実行する前に、ノードをクラスターから削除します。
pacemaker_remote
が停止するとクラスターはそのノードをフェンスします。yum update のプロセスの一部として自動的に停止した場合、システムが不安定な状態になることがあります (特に pacemaker_remote
と同時にカーネルもアップグレードされる場合)。Red Hat Enterprise Linux 7.2 以前のリリースでは、以下の手順にしたがって、pacemaker_remote
を停止する可能性があるシステム管理を実行する前にノードをクラスターから除去する必要があります。
- ノードからすべてのサービスを除去する pcs resource disable resourcename コマンドを使用して、ノードの接続リソースを停止します。ゲストノードでは VM も停止されるため、VM をクラスターの外部で起動して (virsh などを使用) メンテナンスを実行する必要があります。
- 必要なメンテナンスを実行します。
- ノードをクラスターに戻す準備ができたら、pcs resource enable でリソース再度有効にします。
9.5. Docker コンテナーの Pacemaker サポート (テクノロジープレビュー)
- 「Pacemaker バンドルリソースの設定」 では、Pacemaker バンドルを作成するコマンドについて説明し、各バンドルパラメーターに定義できるパラメーターについてまとめた表が記載されています。
- 「バンドルでの Pacemaker リソースの設定」 では、Pacemaker バンドルに含まれているリソースの設定について説明しています。
- 「Pacemaker バンドルの制限」 では、Pacemaker バンドルの制限について説明しています。
- 「Pacemaker バンドル設定の例」 は、Pacemaker バンドルの設定例を説明しています。
9.5.1. Pacemaker バンドルリソースの設定
pcs resource bundle create bundle_id container docker [container_options] [network network_options] [port-map port_options]... [storage-map storage_options]... [meta meta_options] [--disabled] [--wait[=n]]
--disabled
オプションを指定すると、バンドルは自動的に起動されません。--wait
オプションを指定すると、Pacemaker は、バンドルが起動し、成功時に 0 を、エラー時に 1 を返すまで最大 n
秒待機します。n
を指定しないと、デフォルトの 60 分に設定されます。
9.5.1.1. Docker パラメーター
docker
コンテナーオプションを説明します。
docker
バンドルを設定する前に、Docker をインストールし、バンドルの実行が許可されている各ノード上に完全に設定した Docker イメージを展開します。
表9.6 Docker コンテナーのパラメーター
フィールド | デフォルト | 説明 |
---|---|---|
image
|
Docker イメージタグ (必須)
| |
replicas
|
正であれば
promoted-max の値。それ以外は 1。
|
起動するコンテナーインスタンスの数を指定する正の整数
|
replicas-per-host
|
1
|
単一ノードで起動できるコンテナーインスタンスの数を指定する正の整数
|
promoted-max
|
0
|
正であれば、非負の整数は、マスターロールにおいてサービスを実行できる多くのレプリカとともに、コンテナー化されたサービスが複数のサービスとして扱われる必要があることを示しています。
|
network
| |
これが指定されると、Docker コンテナーのネットワーク設定として docker run コマンドに渡されます。
|
run-command
| /usr/sbin/pacemaker_remoted バンドルがリソースを含む場合、それ以外はなし
|
このコマンドは、起動する際にコンテナー内で実行されます ("PID 1")。バンドルにリソースが含まれる場合、このコマンドは pacemaker_remoted デーモンを起動する必要があります (ただし、その他のタスクも実行するスクリプトでも問題ありません)。
|
options
| |
docker run コマンドに渡す、その他のコマンドラインオプション
|
9.5.1.2. (バンドルネットワークパラメーター
network
オプションを説明します。
表9.7 バンドルリソースネットワークパラメーター
フィールド | デフォルト | 説明 |
---|---|---|
add-host
|
TRUE
|
TRUE で
ip-range-start が使用される場合は、Pacemaker により自動的に、コンテナー内の /etc/hosts ファイルに、各レプリカ名と割り当てられている IP のエントリーが指定されるようにします。
|
ip-range-start
| |
これが指定されると、Pacemaker は、各コンテナーインスタンスに対して暗黙的な
ocf:heartbeat:IPaddr2 リソースを作成します。これは、この IP アドレスで始まり、Docker 要素の replicas として指定されている限りのシーケンシャルアドレスとして使用します。これらのアドレスは、ホストのネットワークから使用して、コンテナー内のサービスに到達できます。ただし、コンテナー自身の中では表示されません。現在サポートされているアドレスは、IPv4 のみです。
|
host-netmask
|
32
| ip-range-start が指定されると、IP アドレスがこの CIDR ネットマスクで (多数のビットとして) 作成されます。
|
host-interface
| | ip-range-start が指定されていると、IP アドレスがこのホストインターフェイスで作成されます (デフォルトでは、IP アドレスから決まります)。
|
control-port
|
3121
|
バンドルに Pacemaker リソースが含まれる場合、クラスターは、コンテナー内の Pacemaker Remote との通信に、この整数 の TCP ポートを使用します。コンテナーがデフォルトポートでリッスンできない場合は、このポートを変更すると便利です。これは、コンテナーが
ip-range-start (この場合 replicas-per-host は 1 である必要があります) ではなく、ホストのネットワークを使用しようとしているか、バンドルがデフォルトポートですでにリッスンしている Peacemaker Remote ノードを実行できる場合に起こります。ホストやコンテナーで設定されている PCMK_remote_port 環境変数は、バンドル接続に対しては無視されます。
Pacemaker バンドル設定が
control-port パラメーターを使用するときに、バンドルに独自の IP アドレスがある場合には、corosync を実行しているすべてのクラスターノード上およびそのクラスターノードから、その IP アドレスでポートを開く必要があります。あるいは、バンドルが network="host" コンテナーパラメーターを設定している場合には、すべてのクラスターノードから、それぞれのクラスターノードの IP アドレスでポートを開く必要があります。
|
httpd-bundle
というバンドル名により replicas=2
が設定されれば、 そのコンテナーの名前は httpd-bundle-0
と httpd-bundle-1
になります。
port-map
パラメーターを任意で指定できます。表9.8「バンドルリソースポートマップパラメーター」 では port-map
パラメーターを説明します。
表9.8 バンドルリソースポートマップパラメーター
フィールド | デフォルト | 説明 |
---|---|---|
id
| |
ポートマッピングの一意の名前 (必須)
|
port
| |
これが指定されると、ホストネットワーク上 ((
ip-range-start が指定されていル場合は、コンテナーの、割り当てられた IP アドレス上)) のこの TCP ポート番号に対する接続 がコンテナーネットワークに転送されます。port または range のいずれ 1 つがポートマッピングで指定される必要があります。
|
internal-port
| port の値
| port と internal-port が指定されている場合は、ホストネットワーク上の port に対する接続が、コンテナーネットワーク上のこのポートに転送されます。
|
range
| | range が指定されると、ホストネットワーク上 ((ip-range-start が指定されている場合は、コンテナーの、割り当てられた IP アドレス上)) のこれらの TCP ポート番号 (first_port-last_port) に対する接続 が、コンテナーネットワークの同じポートに転送されます。port または range のいずれ 1 つがポートマッピングで指定される必要があります。
|
control-port
をマッピングします。そのため、ポートマッピングでは、そのポートを指定する必要はありません。
9.5.1.3. バンドルストレージパラメーター
storage-map
パラメーターを設定することができます。表9.9「バンドルリソースストレージマッピングパラメーター」 では、これらのパラメーターを説明します。
表9.9 バンドルリソースストレージマッピングパラメーター
フィールド | デフォルト | 説明 |
---|---|---|
id
| |
ストレージマッピングの一意の名前 (必須)
|
source-dir
| |
コンテナーにマッピングされるホストファイルシステム上の絶対パス。
storage-map パラメーターを設定する際には、source-dir と source-dir-root のいずれかを指定する必要があります。
|
source-dir-root
| |
各コンテナーインスタンスのホスト上で異なるサブディレクトリーを使用した、コンテナーにマッピングされるホストのファイルシステム上のパスの開始。このサブディレクトリーには、バンドル名と同じ名前が付けられ、ダッシュと 0 から始まる整数カウンターも加えられます。
storage-map パラメーターを設定するときには、source-dir と source-dir-root のいずれかを完全に指定する必要があります。
|
target-dir
| |
ホストストレージがマッピングされるコンテナー内のパス名 (必須)
|
options
| |
ストレージをマッピングする際に使用するファイルシステムマウントオプション
|
source-dir-root
パラメーターで名前が付けられる仕組みの例として、source-dir-root=/path/to/my/directory
、target-dir=/srv/appdata
、バンドルに replicas=2
で mybundle
という名前が指定されている場合、クラスターは、mybundle-0
と mybundle-1
というホスト名で 2 つのコンテナーインスタンスを作成します。また、コンテナー /path/to/my/directory/mybundle-0
と /path/to/my/directory/mybundle-1
を実行しているホストで 2 つのディレクトリーを作成します。各コンテナーには、いずれかのディレクトリーが与えられ、そのコンテナー内で実行しているアプリケーションには、/srv/appdata
というディレクトリーが表示されます。
source-dir=/etc/pacemaker/authkey
target-dir=/etc/pacemaker/authkey
と source-dir-root=/var/log/pacemaker/bundles
target-dir=/var/log
と同等のものをコンテナーにマッピングします。そのため、storage-map
パラメーターを設定する際には、これらのパスを指定する必要はありません。
PCMK_authkey_location
環境変数は、クラスターのノード上の /etc/pacemaker/authkey
のデフォルト以外に設定することはできません。
9.5.2. バンドルでの Pacemaker リソースの設定
ip-range-start
または control-port
をバンドルで設定する必要があります。Pacemaker は、接続に対して暗黙的な ocf:pacemaker:remote
リソースを作成し、コンテナー内で Peacemaker Remote を起動して、Pacemaker Remote でリソースを監視・管理します。バンドルに 2 つ以上のコンテナーインスタンス (レプリカ) がある場合、Pacemaker リソースは暗黙的なクローンとして機能します。バンドルが promoted-max
オプションを、0 を超えるように設定した場合、これは多状態クローンになります。
bundle
パラメーター、リソースを含めるバンドル ID を指定して、pcs resource create コマンドで Pacemaker バンドルでリソースを作成します。リソースを含む Pacemaker バンドルの作成例は、「Pacemaker バンドル設定の例」 を参照してください。
docker
オプション --net=none
はリソースと合わせて使用しないでください。オプションの ip-range-start
は、リソースとは使うべきではありません。docker
オプション --net=host
が使用されている場合 (コンテナーがホストのネットワーク領域を共有している) 場合、バンドルごとに一意の control-port
パラメーターを指定する必要があります。ファイアウォールでは、control-port
にアクセスできるように設定を行う必要があります。
9.5.2.1. ノード属性とバンドルリソース
container-attribute-target
リソースメタデータ属性では、ユーザーは使用するアプローチを指定することができます。host
に設定されると、ユーザー定義型のノード属性は、基礎となるホストでチェックされます。その他の場合は、ローカルノード (この場合はバンドルノード) が使用されます。この動作は、ユーザー定義属性にのみ適用されます。クラスターは、#uname
などのクラスター定義型の属性に対してローカルノードを常にチェックします。
container-attribute-target
が host
に設定されると、クラスターは、追加の環境変数をリソースエージェノに渡します。これにより、ノード属性を正しく設定できるようになります。
9.5.2.2. メタデータ属性とバンドルリソース
priority
、target-role
、is-managed
などのオプションが含まれます。
9.5.3. Pacemaker バンドルの制限
- バンドルはグループに含まれていないことや、pcs コマンドで明示的にクローン化されていないことがあります。これには、バンドルが含むリソースや、バンドルに対して Pacemaker によって明示的に作成されたリソースが含まれます。ただし、バンドルの
replicas
の値が 1 未満で設定されると、バンドルはクローンであるかのように動作することに注意してください。 - バンドルが管理されていない場合や、クラスターがメンテナンスモードの際に Pacemaker を再起動すると、バンドルが不具合を起こすことがあります。
- バンドルには、インスタンス属性、使用率属性、または操作がありません。しかし、バンドルに含まれるリソースには、これらがあります。
- リソースを含むバンドルは、バンドルが、一意な異なる
control-port
を使用する場合にのみ、Pacemaker Remote ノードで実行できます。
9.5.4. Pacemaker バンドル設定の例
httpd-bundle
というバンドル ID で Pacemaker bundle
を作成します。これには、httpd
というリソース ID を持つ ocf:heartbeat:apache
が含まれます。
- Docker が、クラスターの各ノードでインストールされ有効化されている。
pcmktest:http
という既存の Docker イメージが存在する。- コンテナーイメージに、Pacemaker Remote デーモンが含まれている。
- コンテナーイメージに、設定済みの Apache Web サーバーが含まれている。
- クラスターの各ノードに、
/var/local/containers/httpd-bundle-0
、/var/local/containers/httpd-bundle-1
、/var/local/containers/httpd-bundle-2
というディレクトリーがあり、Web サーバーの root にindex.html
ファイルが含まれている。稼働中は、単一の共有ドキュメント root が対象となるが、この例では、この設定により、各ホスト上のindex.html
ファイルを別のものにすることが可能。そのため、Web サーバーに接続して、サービスされるindex.html
ファイルを確認することが可能。
- バンドル ID は
httpd-bundle
です。 - 以前設定した Docker コンテナーイメージは
pcmktest:http
です。 - この例は、3 コンテナーインスタンスを起動します。
- この例では、コマンドラインオプション
--log-driver=journald
を docker run コマンドに渡します。このパラメーターは必要ではありませんが、その他のオプションを docker コマンドに渡す方法を示すために追加しています。--log-driver=journald
の値は、コンテナー内のシステムログが基礎となるホストのsystemd
ジャーナルにログインされることを意味します。 - Pacemaker は、3 つの連続した暗黙的な
ocf:heartbeat:IPaddr2
リソースを作成します。これは、各コンテナーに対して 1 つ作成され、IP アドレス 192.168.122.131 で始まります。 - IP アドレスは、ホストインターフェイス eth0 で作成されます。
- IP アドレスは、CIDR ネットマスクが 24 で作成されます。
- この例では、
http-port
というポートマップ ID を作成します。コンテナーに割り当てられている IP アドレスのポート 80 に対する接続がコンテナーネットワークに転送されます。 - この例では、
httpd-root
というストレージマップ ID を作成します。このストレージマッピングについて以下で説明します。source-dir-root
の値は/var/local/containers
です。これは各コンテナーインスタンスに対して、ホスト上の異なるサブディレクトリーを使用し、コンテナーにマッピングされるホストのファイルシステム上のパスの開始を指定します。target-dir
の値は/var/www/html
で、ホストストレージがマッピングされるコンテナー内のパス名を指定します。- このファイルシステム
rw
マウントオプションは、ストレージのマッピングの際に使用されます。 - この例のコンテナーはリソースを含むため、Pacemaker は自動的に、コンテナーに
source-dir=/etc/pacemaker/authkey
と同等のものをマッピングします。このコンテナーでは、ストレージマッピングにそのパスを指定する必要はありません。
temp-cib.xml
という名前の一時ファイルに配置され、temp-cib.xml.deltasrc
にコピーされます。クラスター設定に対する設定のすべては、tmp-cib.xml
ファイルに対して行われます。udpates が完了すると、この手順では pcs cluster cib-push コマンドの diff-against
を使用して、設定ファイルの更新のみがアクティブな設定ファイルにプッシュされるようにします。
#pcs cluster cib tmp-cib.xml
#cp tmp-cib.xml tmp-cib.xml.deltasrc
#pcs -f tmp.cib.xml resource bundle create httpd-bundle
\container docker image=pcmktest:http replicas=3
\options=--log-driver=journald
\network ip-range-start=192.168.122.131 host-interface=eth0
\host-netmask=24 port-map id=httpd-port port=80
\storage-map id=httpd-root source-dir-root=/var/local/containers
\target-dir=/var/www/html options=rw
\ #pcs -f tmp-cib.xml resource create httpd ocf:heartbeat:apache
\statusurl=http://localhost/server-status bundle httpd-bundle
#pcs cluster cib-push tmp-cib.xml diff-against=tmp-cib.xml.deltasrc
9.6. 使用と配置ストラテジー
resource-stickiness
の設定、各ノードにおけるリソースの過去の障害履歴、各ノードの使用率などの要因の組み合わせから導出されます。
- 特定のノードの容量
- 特定のリソースが必要な容量
- リソースの配置の全体的なストラテジー
9.6.1. 使用率属性
cpu
を命名します。また、RAM 容量の使用率属性も設定して、属性 memory
を命名します。この例では、以下のように設定されています。
- ノード 1 は、CPU 容量 2 と、RAM 容量 2048 を指定するように定義されています。
- ノード 2 は、CPU 容量 4 と、RAM 容量 2048 を指定するように定義されています。
#pcs node utilization node1 cpu=2 memory=2048
#pcs node utilization node2 cpu=4 memory=2048
dummy-small
リソースには、CPU 容量 1 と、RAM 容量 1024 が必要です。dummy-medium
リソースには、CPU 容量 2 と、RAM 容量 2048 が必要です。dummy-large
リソースには、CPU 容量 1 と、RAM 容量 3072 が必要です。
#pcs resource utilization dummy-small cpu=1 memory=1024
#pcs resource utilization dummy-medium cpu=2 memory=2048
#pcs resource utilization dummy-large cpu=3 memory=3072
9.6.2. 配置ストラテジー
placement-strategy
クラスタープロパティーを設定する必要があります。これを設定しないと、容量を設定しても効果がありません。クラスターのプロパティーの詳細は 12章Pacemaker クラスターのプロパティー を参照してください。
placement-strategy
クラスタープロパティーには、4 つの値を使用できます。
default
- 使用率の値は全く考慮されません。リソースは、割り当てスコアに従って割り当てられます。スコアが同じであれば、リソースはノード間で均等に分散されます。utilization
- 使用率の値は、ノードが適格と見なされるかどうか (つまり、リソースの要件を満たすのに十分な空き容量があるかどうか) を決定する場合にのみ考慮されます。負荷分散は、ノードに割り当てられたリソースの数に基づいて行われます。balanced
- 使用率の値は、ノードがリソースを提供する資格があるかどうかを判断する際、および負荷分散する際に考慮されるため、リソースのパフォーマンスを最適化する方法でリソースを分散しようとします。minimal
- 使用率の値は、ノードがリソースを提供する資格があるかどうかを決定する場合に限り考慮されます。負荷分散は、できるだけ少ないノードにリソースを集中させて、残りのノードで電力を節約できるようにします。
placement-strategy
の値を balanced
に設定します。このコマンドを実行すると、Pacemaker は、複雑な一連のコロケーション制約を使用せずに、リソースからの負荷がクラスター全体に均等に分散されるようにします。
# pcs property set placement-strategy=balanced
9.6.3. リソースの割り当て
9.6.3.1. ノードの優先順位
- 重みが最も高いノードが最初に消費されます。ノードの重みは、ノードの状態を表すためにクラスターによって維持されるスコアです。
- ノードの重みが、複数のノードで同じ場合は、以下のようになります。
placement-strategy
クラスタープロパティーがdefault
またはutilization
の場合は、以下のようになります。- 割り当てられているリソースの数が最も少ないノードが最初に使用されます。
- 割り当てられているリソースの数が等しい場合は、CIB に登録されている最初の対象ノードが最初に使用されます。
placement-strategy
クラスタープロパティーがbalanced
である場合は、以下のようになります。- 空き容量が最も多いノードが最初に使用されます。
- ノードの空き容量が等しい場合は、割り当てられているリソースの数が最も少ないノードが最初に使用されます。
- ノードの空き容量が等しく、割り当てられているリソースの数が等しい場合は、CIB に最初に登録されている対象ノードが最初に使用されます。
placement-strategy
クラスタープロパティーがminimal
の場合は、CIB に登録されている最初の対象ノードが最初に使用されます。
9.6.3.2. ノードの容量
- 使用率属性が 1 種類だけ定義されている場合、空き容量は単純な数値比較となります。
- 定義されている使用属性の種類が複数になる場合は、ほとんどの属性タイプで数値が最も高いノードの空き容量が、最も大きくなります。以下に例を示します。
- NodeA の空き CPU が多く、NodeB の空きメモリーが多い場合は、互いの空き容量は等しくなります。
- NodeA の空き CPU が多く、NodeB の空きメモリーとストレージが多い場合、NodeB の方が空き容量が多くなります。
9.6.3.3. リソースの割り当て設定
- 優先度の最も高いリソースが最初に割り当てられます。リソースの優先度の設定は、表6.3「リソースのメタオプション」 を参照してください。
- リソースの優先度が等しい場合は、リソースのシャッフルを防ぐために、実行中のノードで最も高いスコアを持つリソースが最初に割り当てられます。
- リソースが実行しているノードのリソーススコアが等しい場合や、リソースが実行していない場合は、優先ノードで最もスコアが高いリソースが最初に割り当てられます。この場合、優先ノードのリソーススコアが等しい場合は、CIB に最初に登録されている実行可能なリソースが最初に割り当てられます。
9.6.4. リソース配置ストラテジーガイドライン
- 物理容量が十分にあることを確認します。ノードの物理容量が、通常の状態でほぼ最大に使用されているとすると、フェイルオーバーの際に問題が発生する可能性があります。使用率機能がなくても、タイムアウトや二次障害が発生する可能性があります。
- ノードに設定する容量にバッファーをいくつか構築します。物理的に存在するよりもわずかに多くのノードリソースが通知されます。ここでは、Pacemaker リソースが、設定した CPU、メモリーなどを常に 100% 使用しないことが想定されます。このような状況は、オーバーコミットと呼ばれることもあります。
- リソースの優先度を指定します。クラスターがサービスを犠牲にする場合、犠牲にするサービスは一番重要でないことが理想的です。最も重要なリソースが最初にスケジュールされるように、リソースの優先度が適切に設定されていることを確認してください。リソースの優先度の設定は、表6.3「リソースのメタオプション」 を参照してください。
9.6.5. NodeUtilization リソースエージェント (Red Hat Enterprise Linux 7.4 以降)
NodeUtilization
リソースエージェントに対応しています。NodeUtilization エージェントは、使用可能な CPU、ホストメモリーの可用性、およびハイパーバイザーのメモリーの可用性に関するシステムパラメーターを検出し、このようなパラメーターを CIB に追加します。エージェントをクローンリソースとして実行して、各ノードにこのようなパラメーターを自動的に入力することができます。
NodeUtilization
リソースエージェントと、このエージェントのリソースオプションの説明は、pcs resource describe NodeUtilization コマンドを実行してください。
9.7. Pacemaker で管理されていないリソースの依存関係の起動順の設定 (Red Hat Enterprise Linux 7.4 以降)
systemd
resource-agents-deps
ターゲットで、スタートアップ順を設定します。このターゲットに対して systemd
ドロップインユニットを作成すると、Pacemaker はこのターゲットに対して相対的な順序を適切に設定できます。
foo
に依存するリソースが含まれる場合は、以下を含むドロップインユニット /etc/systemd/system/resource-agents-deps.target.d/foo.conf
を作成できます。
[Unit] Requires=foo.service After=foo.service
/srv
にファイルをマウントする依存関係も考えられます。この場合、systemd
ドキュメンテーションに従って、systemd
ファイル srv.mount
を作成して、ここで説明しているように .conf
ファイルの srv.mount
foo.service
の代わりにドロップインユニットを作成します。
9.8. SNMP での Pacemaker クラスターを照会 (Red Hat Enterprise Linux 7.5 以降)
pcs_snmp_agent
デーモンを使用して、SNMP でデータについて Pacemaker クラスターを照会できます。pcs_snmp_agent
デーモンは、agentx
プロトコルでマスターエージェント (snmpd
) に接続する SNMP エージェントです。pcs_snmp_agent
エージェントは、マスターエージェントにデータを提供するのみなので、スタンドアローンとして動作しません。
- クラスターの各ノードに
pcs-snmp
パッケージをインストールします。これにより、snmp
を使うことのできるnet-snmp
パッケージもインストールされています。#
yum install pcs-snmp
/etc/snmp/snmpd.conf
設定ファイルに以下の行を追加して、master agentx
としてsnmpd
を設定します。master agentx
/etc/snmp/snmpd.conf
設定ファイルに以下の行を追加して、同じ SNMP 設定でpcs_snmp_agent
を有効にします。view systemview included .1.3.6.1.4.1.32723.100
pcs_snmp_agent
サービスを開始します。#
systemctl start pcs_snmp_agent.service
#systemctl enable pcs_snmp_agent.service
- 設定を確認するには、pcs status を使用してクラスターステータスを表示してから、SNMP からのデータの取得を試行し、出力と一致しているかどうかを見てください。SNMP を使用してデータを取得する際には、プリミティブなリソースのみが与えられることに注意してください。以下の例では、アクションに 1 回失敗した状態で実行しているクラスター上での pcs status コマンドの出力を示しています。
#
pcs status
Cluster name: rhel75-cluster Stack: corosync Current DC: rhel75-node2 (version 1.1.18-5.el7-1a4ef7d180) - partition with quorum Last updated: Wed Nov 15 16:07:44 2017 Last change: Wed Nov 15 16:06:40 2017 by hacluster via cibadmin on rhel75-node1 2 nodes configured 14 resources configured (1 DISABLED) Online: [ rhel75-node1 rhel75-node2 ] Full list of resources: fencing (stonith:fence_xvm): Started rhel75-node1 dummy5 (ocf::pacemaker:Dummy): Stopped (disabled) dummy6 (ocf::pacemaker:Dummy): Stopped dummy7 (ocf::pacemaker:Dummy): Started rhel75-node2 dummy8 (ocf::pacemaker:Dummy): Started rhel75-node1 dummy9 (ocf::pacemaker:Dummy): Started rhel75-node2 Resource Group: group1 dummy1 (ocf::pacemaker:Dummy): Started rhel75-node1 dummy10 (ocf::pacemaker:Dummy): Started rhel75-node1 Clone Set: group2-clone [group2] Started: [ rhel75-node1 rhel75-node2 ] Clone Set: dummy4-clone [dummy4] Started: [ rhel75-node1 rhel75-node2 ] Failed Actions: * dummy6_start_0 on rhel75-node1 'unknown error' (1): call=87, status=complete, exitreason='', last-rc-change='Wed Nov 15 16:05:55 2017', queued=0ms, exec=20ms#
snmpwalk -v 2c -c public localhost PACEMAKER-PCS-V1-MIB::pcmkPcsV1Cluster
PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterName.0 = STRING: "rhel75-cluster" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterQuorate.0 = INTEGER: 1 PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterNodesNum.0 = INTEGER: 2 PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterNodesNames.0 = STRING: "rhel75-node1" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterNodesNames.1 = STRING: "rhel75-node2" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterCorosyncNodesOnlineNum.0 = INTEGER: 2 PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterCorosyncNodesOnlineNames.0 = STRING: "rhel75-node1" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterCorosyncNodesOnlineNames.1 = STRING: "rhel75-node2" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterCorosyncNodesOfflineNum.0 = INTEGER: 0 PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterPcmkNodesOnlineNum.0 = INTEGER: 2 PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterPcmkNodesOnlineNames.0 = STRING: "rhel75-node1" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterPcmkNodesOnlineNames.1 = STRING: "rhel75-node2" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterPcmkNodesStandbyNum.0 = INTEGER: 0 PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterPcmkNodesOfflineNum.0 = INTEGER: 0 PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterAllResourcesNum.0 = INTEGER: 11 PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterAllResourcesIds.0 = STRING: "fencing" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterAllResourcesIds.1 = STRING: "dummy5" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterAllResourcesIds.2 = STRING: "dummy6" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterAllResourcesIds.3 = STRING: "dummy7" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterAllResourcesIds.4 = STRING: "dummy8" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterAllResourcesIds.5 = STRING: "dummy9" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterAllResourcesIds.6 = STRING: "dummy1" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterAllResourcesIds.7 = STRING: "dummy10" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterAllResourcesIds.8 = STRING: "dummy2" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterAllResourcesIds.9 = STRING: "dummy3" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterAllResourcesIds.10 = STRING: "dummy4" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterRunningResourcesNum.0 = INTEGER: 9 PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterRunningResourcesIds.0 = STRING: "fencing" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterRunningResourcesIds.1 = STRING: "dummy7" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterRunningResourcesIds.2 = STRING: "dummy8" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterRunningResourcesIds.3 = STRING: "dummy9" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterRunningResourcesIds.4 = STRING: "dummy1" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterRunningResourcesIds.5 = STRING: "dummy10" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterRunningResourcesIds.6 = STRING: "dummy2" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterRunningResourcesIds.7 = STRING: "dummy3" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterRunningResourcesIds.8 = STRING: "dummy4" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterStoppedResroucesNum.0 = INTEGER: 1 PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterStoppedResroucesIds.0 = STRING: "dummy5" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterFailedResourcesNum.0 = INTEGER: 1 PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterFailedResourcesIds.0 = STRING: "dummy6" PACEMAKER-PCS-V1-MIB::pcmkPcsV1ClusterFailedResourcesIds.0 = No more variables left in this MIB View (It is past the end of the MIB tree)
9.9. クリーンノードのシャットダウンで停止するようにリソースを設定 (Red Hat Enterprise Linux 7.8 以降)
9.9.1. クリーンノードシャットダウンで停止するようにリソースを設定するためのクラスタープロパティー
- shutdown-lock
- このクラスタープロパティーをデフォルト値の
false
に設定すると、クラスターは、ノードで適切にシャットダウンしているノードでアクティブなリソースを復旧します。このプロパティーをtrue
に設定すると、適切にシャットダウンしているノードでアクティブなリソースは、クラスターに再参加した後にノードで再起動するまで別の場所で起動できなくなります。shutdown-lock
プロパティーはクラスターノードまたはリモートノードのいずれかで機能しますが、ゲストノードは機能しません。shutdown-lock
をtrue
に設定すると、ノードがダウンした場合にクラスターリソースのロックを削除し、以下のコマンドを実行してノードで手動更新を実行してリソースを別の場所で起動できるようになります。pcs resource refresh resource --node node
リソースのロックが解除されると、クラスターはリソースを別の場所に移動できるようになることに注意してください。リソースのスティッキネスの値または場所の設定を使用することにより、これが発生する可能性を抑制できます。注記手動更新は、最初に次のコマンドを実行するとリモートノードで機能します。- リモートノードで systemctl stop pacemaker_remote コマンドを実行してノードを停止します。
- pcs resource disable remote-connection-resource コマンドを実行します。
その後、リモートノードで手動更新を実行できます。 - shutdown-lock-limit
- このクラスタープロパティーをデフォルト値の 0 以外の値に設定すると、シャットダウンを開始してから指定した時間内にノードが再参加しない場合に、他のノードの復旧にリソースが利用可能になります。ただし、この間隔は、
cluster-recheck-interval
クラスタープロパティーの値よりも頻繁に確認されないことに注意してください。注記shutdown-lock-limit
プロパティーは、以下のコマンドを最初に実行した場合に限りリモートノードで動作します。- リモートノードで systemctl stop pacemaker_remote コマンドを実行してノードを停止します。
- pcs resource disable remote-connection-resource コマンドを実行します。
このコマンドの実行後、shutdown-lock-limit
で指定した時間が経過すると、リモートノード上で実行しているリソースが他のノードの復旧に利用できます。
9.9.2. shutdown-lock クラスタープロパティーの設定
shutdown-lock
クラスタープロパティーを true
に設定し、ノードをシャットダウンして再起動したときの影響を示しています。この例のクラスターは、z1.example.com
、z2.example.com
、および z3.example.com
の 3 つのノードで設定されます。
shutdown-lock
プロパティーをtrue
に設定し、その値を確認します。この例では、shutdown-lock-limit
プロパティーはデフォルト値 0 を維持します。[root@z3.example.com ~]#
pcs property set shutdown-lock=true
[root@z3.example.com ~]#pcs property list --all | grep shutdown-lock
shutdown-lock: true shutdown-lock-limit: 0- クラスターのステータスを確認します。この例では、
3
番目と5
番目のリソースがz1.example.com
で実行しています。[root@z3.example.com ~]#
pcs status
... Full List of Resources: ... * first (ocf::pacemaker:Dummy): Started z3.example.com * second (ocf::pacemaker:Dummy): Started z2.example.com * third (ocf::pacemaker:Dummy): Started z1.example.com * fourth (ocf::pacemaker:Dummy): Started z2.example.com * fifth (ocf::pacemaker:Dummy): Started z1.example.com ... z1.example.com
をシャットダウンします。これにより、そのノードで実行中のリソースを停止します。[root@z3.example.com ~] #
pcs cluster stop z1.example.com
Stopping Cluster (pacemaker)... Stopping Cluster (corosync)...pcs status コマンドを実行すると、ノードのz1.example.com
がオフラインであることを示し、z1.example.com
で実行していたリソースは、ノードの停止時にLOCKED
になります。[root@z3.example.com ~]#
pcs status
... Node List: * Online: [ z2.example.com z3.example.com ] * OFFLINE: [ z1.example.com ] Full List of Resources: ... * first (ocf::pacemaker:Dummy): Started z3.example.com * second (ocf::pacemaker:Dummy): Started z2.example.com * third (ocf::pacemaker:Dummy): Stopped z1.example.com (LOCKED) * fourth (ocf::pacemaker:Dummy): Started z3.example.com * fifth (ocf::pacemaker:Dummy): Stopped z1.example.com (LOCKED) ...- クラスターサービスを
z1.example.com
で再度起動し、クラスターに再参加できるようにします。ロックされたリソースは、そのノードで開始する必要がありますが、いったん起動すると、必ずしも同じノードに留まるわけではありません。[root@z3.example.com ~]#
pcs cluster start z1.example.com
Starting Cluster...この例では、3 番目と 5 番目のリソースが z1.example.com ノードで復元されます。[root@z3.example.com ~]#
pcs status
... Node List: * Online: [ z1.example.com z2.example.com z3.example.com ] Full List of Resources: .. * first (ocf::pacemaker:Dummy): Started z3.example.com * second (ocf::pacemaker:Dummy): Started z2.example.com * third (ocf::pacemaker:Dummy): Started z1.example.com * fourth (ocf::pacemaker:Dummy): Started z3.example.com * fifth (ocf::pacemaker:Dummy): Started z1.example.com ...
第10章 クラスタークォーラム
votequorum
サービスをフェンシングと併用します。クラスターの各システムには多くの投票数が割り当てられ、過半数の票を取得しているものだけがクラスターの操作を継続できます。サービスは、すべてのノードに読み込むか、いずれのノードにも読み込まないようにする必要があります。サービスをクラスターノードのサブセットに読み込むと、結果が予想できなくなります。サービスがクラスターノードのサブセットにロードされると、結果が予想不可能になります。votequorum
サービスの設定および操作の詳細は、votequorum(5) の man ページを参照してください。
10.1. クォーラムオプションの設定
表10.1 クォーラムオプション
オプション | 説明 |
---|---|
--auto_tie_breaker |
これを有効にすると、クラスターは、決定論的に最大 50% のノードが同時に失敗しても存続されます。クラスターパーティションや、
auto_tie_breaker_node に設定された nodeid (設定されていない場合は最小の nodeid ) と通信したままのノードのセットは、クォーラムに達した状態を維持します。その他のノードはクォーラムに達しません。
auto_tie_breaker オプションを指定すると、均等の分割でクラスターが動作を継続できるようになるため、主に偶数個のノードがあるクラスターで使用されます。複数で不均等の分割などの、より複雑な障害は、「クォーラムデバイス」 で説明されているようにクォーラムデバイスを使用することが推奨されます。auto_tie_breaker オプションは、クォーラムデバイスと互換性がありません。
|
--wait_for_all |
有効にすると、最低 1 回、同時にすべてのノードが現れた後に、初回だけ、クラスターがクォーラムに達します。
wait_for_all オプションは、主にクォーラムデバイス lms (last man standing) アルゴリズムを使用する 2 ノードクラスター、および偶数のノードで設定されるクラスターに使用されます。
wait_for_all オプションは、クラスターに 2 つのノードがあり、クォーラムデバイスを使用せず、auto_tie_breaker が無効になっている場合に自動的に有効になります。wait_for_all を明示的に 0 に設定すると、このオプションをオーバーライドできます。
|
--last_man_standing | 有効にすると、クラスターは特定の状況で expected_votes とクォーラムを動的に再計算します。このオプションを有効にする場合は、wait_for_all を有効にする必要があります。last_man_standing オプションには、クォーラムデバイスとの互換性がありません。 |
--last_man_standing_window | クラスターのノードが失われた後の、expected_votes およびクォーラムを再計算するまでの待ち時間 (ミリ秒単位) です。 |
10.2. クォーラム管理コマンド (Red Hat Enterprise Linux 7.3 以降)
pcs quorum [config]
pcs quorum status
expected_votes
パラメーターの値を変更できます。これにより、クォーラムがない場合でも、クラスターは操作を継続できます。
wait_for_all
パラメーターが有効になっていることを確認してください。
expected_votes
の値は、設定ファイルの値にリセットされます。
pcs quorum expected-votes votes
10.3. クォーラムオプションの変更 (Red Hat Enterprise Linux 7.3 以降)
pcs quorum update [auto_tie_breaker=[0|1]] [last_man_standing=[0|1]] [last_man_standing_window=[time-in-ms] [wait_for_all=[0|1]]
wait_for_all
クォーラムオプションを変更し、このオプションの更新された状態を表示します。クラスターの稼働中はこのコマンドを実行できないことに注意してください。
[root@node1:~]#pcs quorum update wait_for_all=1
Checking corosync is not running on nodes... Error: node1: corosync is running Error: node2: corosync is running [root@node1:~]#pcs cluster stop --all
node2: Stopping Cluster (pacemaker)... node1: Stopping Cluster (pacemaker)... node1: Stopping Cluster (corosync)... node2: Stopping Cluster (corosync)... [root@node1:~]#pcs quorum update wait_for_all=1
Checking corosync is not running on nodes... node2: corosync is not running node1: corosync is not running Sending updated corosync.conf to nodes... node1: Succeeded node2: Succeeded [root@node1:~]#pcs quorum config
Options: wait_for_all: 1
10.4. クォーラムアンブロック (quorum unblock) コマンド
# pcs cluster quorum unblock
10.5. クォーラムデバイス
- クォーラムデバイスは、クォーラムデバイスを使用するクラスターと同じ場所にある別の物理ネットワークで実行することが推奨されます。理想としては、クォーラムデバイスホストを、メインクラスターとは別のラックに置くか、少なくとも別の PSU に置くようにします。corosync リングと同じネットワークセグメントには置かないようにしてください。
- 複数のクォーラムデバイスをクラスターで同時に使用することはできません。
- 複数のクォーラムデバイスをクラスターで同時に使用することはできません。ただし、複数のクラスターが 1 つのクォーラムデバイスを同時に使用することはできます。アルゴリズムやクォーラムオプションはクラスターノード自体に保存されるため、同じクォーラムデバイスを使用する各クラスターが、複数のアルゴリズムやクォーラムオプションを使用できます。たとえば、
ffsplit
((fifty/fifty split) アルゴリズムを使用するクラスターと、lms
(last man standing) アルゴリズムを使用する別のクラスターが、1 つのクォーラムデバイスを使用できます。 - クォーラムデバイスは、既存のクラスターノードで実行しないでください。
10.5.1. クォーラムデバイスパッケージのインストール
- 既存クラスターのノードで、
corosync-qdevice
をインストールします。[root@node1:~]#
yum install corosync-qdevice
[root@node2:~]#yum install corosync-qdevice
- クォーラムデバイスホストに、
pcs
およびcorosync-qnetd
をインストールします。[root@qdevice:~]#
yum install pcs corosync-qnetd
pcsd
サービスを起動し、システムの起動時にpcsd
がクォーラムデバイスホストで有効になるようにします。[root@qdevice:~]#
systemctl start pcsd.service
[root@qdevice:~]#systemctl enable pcsd.service
10.5.2. クォーラムデバイスの設定
- クォーラムデバイスに使用されるノードは
qdevice
です。 - クォーラムデバイスモデルは
net
で、これは現在対応している唯一のクォーラムデバイスモデルです。net
モデルは、以下のアルゴリズムに対応します。ffsplit
(fifty-fifty split) -これにより、アクティブなノードの数が最も多いパーティションに 1 票が提供されます。lms
(last-man-standing) -ノードがqnetd
サーバーを確認できるクラスター内に残っている唯一のノードである場合に、1 票が返されます。警告LMS アルゴリズムにより、ノードが 1 つしか残っていなくてもクラスターはクォーラムを維持できますが、number_of_nodes - 1 と同じであるため、クォーラムデバイスの投票力が大きいことを意味します。クォーラムデバイスとの接続が失われると、number_of_nodes - 1 の票が失われます。つまり、(クォーラムデバイスを無効にすることで) すべてのノードがアクティブなクラスターのみがクォーラムに達したままになります。他のクラスターは、クォーラムに達しなくなります。
これらのアルゴリズムの実装の詳細は、man ページのcorosync-qdevice
(8) を参照してください。 - クラスターノードは
node1
とnode2
です。
- クォーラムデバイスをホストするために使用するノードで以下のコマンドを使用し、クォーラムデバイスを設定します。このコマンドは、クォーラムデバイスモデルである
net
を設定および開始し、システムの起動時にデバイスが開始するように設定します。[root@qdevice:~]#
pcs qdevice setup model net --enable --start
Quorum device 'net' initialized quorum device enabled Starting quorum device... quorum device startedクォーラムデバイスの設定後、そのステータスを確認できます。corosync-qnetd
デーモンが実行中であり、この時点でクライアントが接続されていないことが分かります。--full
コマンドオプションを指定すると詳細が出力されます。[root@qdevice:~]#
pcs qdevice status net --full
QNetd address: *:5403 TLS: Supported (client certificate required) Connected clients: 0 Connected clusters: 0 Maximum send/receive size: 32768/32768 bytes - 以下のコマンドを実行して、
firewalld
でhigh-availability
サービスを有効にして、pcsd
デーモンおよびnet
クォーラムデバイスで必要なファイアウォールのポートを有効にします。[root@qdevice:~]#
firewall-cmd --permanent --add-service=high-availability
[root@qdevice:~]#firewall-cmd --add-service=high-availability
- 既存クラスターのいずれかのノードにより、クォーラムデバイスをホストしているノードで
hacluster
ユーザーを認証します。[root@node1:~] #
pcs cluster auth qdevice
Username: hacluster Password: qdevice: Authorized - クォーラムデバイスをクラスターに追加します。クォーラムデバイスを追加する前に、後で比較するために、クォーラムデバイスの現在の設定と状況を確認できます。このコマンドの出力は、クラスターがクォーラムデバイスを使用していないことを示しています。
[root@node1:~]#
pcs quorum config
Options:[root@node1:~]#
pcs quorum status
Quorum information ------------------ Date: Wed Jun 29 13:15:36 2016 Quorum provider: corosync_votequorum Nodes: 2 Node ID: 1 Ring ID: 1/8272 Quorate: Yes Votequorum information ---------------------- Expected votes: 2 Highest expected: 2 Total votes: 2 Quorum: 1 Flags: 2Node Quorate Membership information ---------------------- Nodeid Votes Qdevice Name 1 1 NR node1 (local) 2 1 NR node2以下のコマンドは、作成しておいたクォーラムデバイスをクラスターに追加します。複数のクォーラムデバイスをクラスターで同時に使用することはできません。ただし、複数のクラスターが 1 つのクォーラムデバイスを同時に使用することはできます。以下のコマンド例では、ffsplit
アルゴリズムを使用するようにクォーラムデバイスを設定します。クォーラムデバイスの設定オプションの詳細は、man ページのcorosync-qdevice
(8) を参照してください。[root@node1:~]#
pcs quorum device add model net host=qdevice algorithm=ffsplit
Setting up qdevice certificates on nodes... node2: Succeeded node1: Succeeded Enabling corosync-qdevice... node1: corosync-qdevice enabled node2: corosync-qdevice enabled Sending updated corosync.conf to nodes... node1: Succeeded node2: Succeeded Corosync configuration reloaded Starting corosync-qdevice... node1: corosync-qdevice started node2: corosync-qdevice started - クォーラムデバイスの設定状態をチェックします。クラスター側から以下のコマンドを実行すると、設定の変更内容を確認できます。pcs quorum config は設定されたクォーラムデバイスを表示します。
[root@node1:~]#
pcs quorum config
Options: Device: Model: net algorithm: ffsplit host: qdevicepcs quorum status コマンドは、使用中のクォーラムデバイスとクォーラムのランタイム状態を表示します。[root@node1:~]#
pcs quorum status
Quorum information ------------------ Date: Wed Jun 29 13:17:02 2016 Quorum provider: corosync_votequorum Nodes: 2 Node ID: 1 Ring ID: 1/8272 Quorate: Yes Votequorum information ---------------------- Expected votes: 3 Highest expected: 3 Total votes: 3 Quorum: 2 Flags: Quorate Qdevice Membership information ---------------------- Nodeid Votes Qdevice Name 1 1 A,V,NMW node1 (local) 2 1 A,V,NMW node2 0 1 Qdevicepcs quorum device status はクォーラムデバイスのランタイム状態を表示します。[root@node1:~]#
pcs quorum device status
Qdevice information ------------------- Model: Net Node ID: 1 Configured node list: 0 Node ID = 1 1 Node ID = 2 Membership node list: 1, 2 Qdevice-net information ---------------------- Cluster name: mycluster QNetd host: qdevice:5403 Algorithm: ffsplit Tie-breaker: Node with lowest node ID State: Connectedクォーラムデバイスから次のコマンドを実行して、corosync-qnetd
デーモンのステータスを表示できます。[root@qdevice:~]#
pcs qdevice status net --full
QNetd address: *:5403 TLS: Supported (client certificate required) Connected clients: 2 Connected clusters: 1 Maximum send/receive size: 32768/32768 bytes Cluster "mycluster": Algorithm: ffsplit Tie-breaker: Node with lowest node ID Node ID 2: Client address: ::ffff:192.168.122.122:50028 HB interval: 8000ms Configured node list: 1, 2 Ring ID: 1.2050 Membership node list: 1, 2 TLS active: Yes (client certificate verified) Vote: ACK (ACK) Node ID 1: Client address: ::ffff:192.168.122.121:48786 HB interval: 8000ms Configured node list: 1, 2 Ring ID: 1.2050 Membership node list: 1, 2 TLS active: Yes (client certificate verified) Vote: ACK (ACK)
10.5.3. クォーラムデバイスサービスの管理
corosync-qnetd
サービスにのみ影響することに注意してください。
[root@qdevice:~]#pcs qdevice start net
[root@qdevice:~]#pcs qdevice stop net
[root@qdevice:~]#pcs qdevice enable net
[root@qdevice:~]#pcs qdevice disable net
[root@qdevice:~]#pcs qdevice kill net
10.5.4. クラスターでのクォーラムデバイス設定の管理
10.5.4.1. クォーラムデバイス設定の変更
net
の host
オプションを変更するには、pcs quorum device remove および pcs quorum device add コマンドを使用し、設定プロパティーを設定します (変更前のホストと変更後のホストが同じマシンである場合を除く)。
lms
に変更します。
[root@node1:~]# pcs quorum device update model algorithm=lms
Sending updated corosync.conf to nodes...
node1: Succeeded
node2: Succeeded
Corosync configuration reloaded
Reloading qdevice configuration on nodes...
node1: corosync-qdevice stopped
node2: corosync-qdevice stopped
node1: corosync-qdevice started
node2: corosync-qdevice started
10.5.4.2. クォーラムデバイスの削除
[root@node1:~]# pcs quorum device remove
Sending updated corosync.conf to nodes...
node1: Succeeded
node2: Succeeded
Corosync configuration reloaded
Disabling corosync-qdevice...
node1: corosync-qdevice disabled
node2: corosync-qdevice disabled
Stopping corosync-qdevice...
node1: corosync-qdevice stopped
node2: corosync-qdevice stopped
Removing qdevice certificates from nodes...
node1: Succeeded
node2: Succeeded
[root@node1:~]# pcs quorum device status
Error: Unable to get quorum status: corosync-qdevice-tool: Can't connect to QDevice socket (is QDevice running?): No such file or directory
10.5.4.3. クォーラムデバイスの破棄
[root@qdevice:~]# pcs qdevice destroy net
Stopping quorum device...
quorum device stopped
quorum device disabled
Quorum device 'net' configuration files removed
第11章 Pacemaker ルール
boolean-op
フィールドに応じて処理され、最終的にそのルールが true
または false
どちらの評価になるかが確定されます。次の動作は、ルールが使用される状況に応じて異なります。
表11.1 ルールのプロパティー
フィールド | 説明 |
---|---|
role
| |
score
| |
score-attribute
| |
boolean-op
|
11.1. ノード属性の式
表11.2 式のプロパティー
フィールド | 説明 |
---|---|
attribute
| |
type
| |
operation
|
実行する比較動作。設定できる値は、
*
lt - ノード属性の値が value 未満の場合は True
*
gt - ノード属性の値が value を超える場合は True
*
lte - ノード属性の値が value 未満または同等になる場合は True
*
gte - ノード属性の値が value を超えるか、または同等になる場合は True
*
eq - ノード属性の値が value と同等になる場合に True
*
ne - ノード属性の値が value と同等にならない場合は True
*
defined - ノードに指定属性がある場合は True
|
value
|
表11.3 組み込みノード属性
名前 | 説明 |
---|---|
#uname
|
ノード名
|
#id
|
ノード ID
|
#kind
|
ノードタイプ。使用できる値は、
cluster 、remote 、および container です。kind の値は、ocf:pacemaker:remote リソースで作成された Pacemaker リモートノードの remote 、および Pacemaker リモートゲストノードおよびバンドルノードの container です。
|
#is_dc
|
このノードが指定コントローラー (DC) の場合は
true 、それ以外の場合は false
|
#cluster_name
| cluster-name クラスタープロパティーの値 (設定されている場合)。
|
#site_name
| site-name ノード属性の値 (設定されている場合)。それ以外は #cluster-name と同じ。
|
#role
|
関連する多状態リソースがこのノードで果たすロール。多状態リソースの場所の制約のルール内でのみ有効です。
|
11.2. 時刻と日付ベースの式
表11.4 日付の式のプロパティー
11.3. 日付の詳細
monthdays="1"
は各月の最初の日と一致し、hours="09-17"
は午前 9 時から午後 5 時まで (両時間を含む) の時間と一致します。ただし、weekdays="1,2"
または weekdays="1-2,5-6"
には複数の範囲が含まれるため、指定することはできません。
表11.5 日付詳細のプロパティー
フィールド | 説明 |
---|---|
id
| |
hours
| |
monthdays
| |
weekdays
| |
yeardays
| |
months
| |
weeks
| |
years
| |
weekyears
| |
moon
|
11.4. 期間
end
の値が与えられていない場合は期間を使ってその値を算出します。date_spec
オブジェクトと同じフィールドがありますが制限はありません (つまり 19 ヶ月の期間を持たせることが可能)。date_specs
同様、未入力のフィールドは無視されます。
11.5. pcs でのルールの設定
pcs constraint rule remove rule_id
第12章 Pacemaker クラスターのプロパティー
- 表12.1「クラスターのプロパティー」 では、クラスターのプロパティーオプションを説明します。
- 「クラスターのプロパティーの設定と削除」 では、クラスタープロパティーの設定方法を説明します。
- 「クラスタープロパティー設定のクエリー」 では、現在設定されているクラスタープロパティーを一覧表示する方法を説明しています。
12.1. クラスタープロパティーとオプションの要約
表12.1 クラスターのプロパティー
オプション | デフォルト | 説明 |
---|---|---|
batch-limit | 0 | |
migration-limit | -1 (無制限) | |
no-quorum-policy | stop |
* ignore - 全リソースの管理を続行する
* freeze - リソース管理は継続するが、影響を受けるパーティションに含まれないノードのリソースは復帰させない
* stop - 影響を受けるクラスターパーティション内の全リソースを停止する
* suicide - 影響を受けるクラスターパーティション内の全ノードをフェンスする
|
symmetric-cluster | true | |
stonith-enabled | true |
true または未設定の場合は、STONITH リソースが設定されていない限り、クラスターによりリソースの起動が拒否されます。
|
stonith-action | reboot | |
cluster-delay | 60s | |
stop-orphan-resources | true | |
stop-orphan-actions | true | |
start-failure-is-fatal | true |
特定のノードでリソースの起動に失敗した場合に、そのノードで開始試行を行わないようにするかを示します。
false に設定すると、リソースの現在の失敗数と移行しきい値を基にしてクラスターが同じノードの開始を再試行するかどうかを決定。リソースの migration-threshold オプションの設定は 「障害発生によるリソースの移動」 を参照してください。
start-failure-is-fatal を false に設定すると、リソースを起動できない障害があるノードが、すべての依存アクションを遅らせる可能性があるというリスクが発生します。これにより、start-failure-is-fatal のデフォルトは true となっています。start-failure-is-fatal=false を設定するリスクは、移行しきい値を低く設定することで軽減できます。これにより、何度も失敗してもその他のアクションを続行できます。
|
pe-error-series-max | -1 (すべて) | |
pe-warn-series-max | -1 (すべて) | |
pe-input-series-max | -1 (すべて) | |
cluster-infrastructure | ||
dc-version | ||
last-lrm-refresh | ||
cluster-recheck-interval | 15 分 | |
maintenance-mode | false | |
shutdown-escalation | 20min | |
stonith-timeout | 60s | |
stop-all-resources | false | |
enable-acl | false | |
placement-strategy | default |
クラスターノードでリソースの配置を決定する際に、クラスターが使用率属性を考慮にいれるかどうかと、どのように考慮するかを示します。使用率属性および配置ストラテジーの詳細は、「使用と配置ストラテジー」 を参照してください。
|
fence-reaction | stop |
12.2. クラスターのプロパティーの設定と削除
pcs property set property=value
symmetric-cluster
の値を false
に設定する場合は、次のコマンドを使用します。
# pcs property set symmetric-cluster=false
pcs property unset property
symmetric-cluster
プロパティーを false
に設定したことがある場合は、設定した値が次のコマンドにより削除され、symmetric-cluster
の値がデフォルト値の true
に戻されます。
# pcs property set symmetic-cluster=
12.3. クラスタープロパティー設定のクエリー
pcs property list
pcs property list --all
pcs property show property
cluster-infrastructure
プロパティーの現在の値を表示する場合は、次のコマンドを実行します。
# pcs property show cluster-infrastructure
Cluster Properties:
cluster-infrastructure: cman
pcs property [list|show] --defaults
第13章 クラスターイベントのスクリプトのトリガー
- Red Hat Enterprise Linux 7.3 より、アラートエージェントを使用して Pacemaker アラートを設定できるようになりました。アラートエージェントは、リソース設定と操作を処理するためにクラスター呼び出しのリソースエージェントと同様にクラスターが呼び出す外部プログラムです。Pacemaker アラートエージェントの説明は 「Pacemaker アラートエージェント (Red Hat Enterprise Linux 7.3 以降)」 を参照してください。
ocf:pacemaker:ClusterMon
リソースはクラスターの状態を監視でき、クラスターイベントごとにアラートをトリガーできます。このリソースは、標準の間隔で crm_mon コマンドをバックグランドで実行します。ClusterMon
リソースの詳細は 「モニターリングのリソースを使ったイベント通知」 を参照してください。
13.1. Pacemaker アラートエージェント (Red Hat Enterprise Linux 7.3 以降)
- Pacemaker は、デフォルトで
/usr/share/pacemaker/alerts
にインストールされるアラートエージェントのサンプルを複数提供します。これらのサンプルスクリプトは、コピーしてそのまま使用したり、目的に合わせて編集するテンプレートとして使用することもできます。対応する全属性は、サンプルエージェントのソースコードを参照してください。サンプルアラートエージェントを使用するアラートの基本的な設定手順の例は、「サンプルアラートエージェントの使用」 を参照してください。 - アラートエージェントの設定および管理に関する一般的な情報は、「アラートの作成」、「アラートの表示、編集、および削除」、「アラートの受信側」、「アラートメタオプション」、および 「アラート設定コマンドの例」 を参照してください。
- Pacemaker アラートの独自のアラートエージェントを作成することができます。アラートエージェントの作成に関する詳細は、「アラートエージェントの作成」 を参照してください。
13.1.1. サンプルアラートエージェントの使用
alert_file.sh.sample
スクリプトを alert_file.sh
としてインストールします。
# install --mode=0755 /usr/share/pacemaker/alerts/alert_file.sh.sample /var/lib/pacemaker/alert_file.sh
alert_file.sh
アラートエージェントを使用してイベントのログをファイルに記録するアラートを設定します。アラートエージェントは、最低限のパーミッションを持つ hacluster
ユーザーとして実行します。
pcmk_alert_file.log
を作成します。また、アラートエージェントを作成し、その受信先としてログファイルへのパスを追加します。
#touch /var/log/pcmk_alert_file.log
#chown hacluster:haclient /var/log/pcmk_alert_file.log
#chmod 600 /var/log/pcmk_alert_file.log
#pcs alert create id=alert_file description="Log events to a file." path=/var/lib/pacemaker/alert_file.sh
#pcs alert recipient add alert_file id=my-alert_logfile value=/var/log/pcmk_alert_file.log
alert_snmp.sh.sample
スクリプトを alert_snmp.sh
としてインストールし、インストールした alert_snmp.sh
アラートエージェントを使用してクラスターイベントを NSMP トラップとして送信するアラートを設定します。デフォルトでは、正常な監視呼び出し以外のすべてのイベントを SNMP サーバーに送信します。この例では、タイムスタンプの形式をメタオプションとして設定します。メタオプションの詳細は、「アラートメタオプション」 を参照してください。この例では、アラートの設定後にアラートの受信側が設定され、アラート設定が表示されます。
#install --mode=0755 /usr/share/pacemaker/alerts/alert_snmp.sh.sample /var/lib/pacemaker/alert_snmp.sh
#pcs alert create id=snmp_alert path=/var/lib/pacemaker/alert_snmp.sh meta timestamp-format="%Y-%m-%d,%H:%M:%S.%01N"
#pcs alert recipient add snmp_alert value=192.168.1.2
#pcs alert
Alerts: Alert: snmp_alert (path=/var/lib/pacemaker/alert_snmp.sh) Meta options: timestamp-format=%Y-%m-%d,%H:%M:%S.%01N. Recipients: Recipient: snmp_alert-recipient (value=192.168.1.2)
alert_smtp.sh
エージェントをインストールし、インストールしたアラートエージェントを使用するアラートを設定して、クラスターイベントを E メールメッセージとして送信します。この例では、アラートの設定後に受信側が設定され、アラート設定が表示されます。
#install --mode=0755 /usr/share/pacemaker/alerts/alert_smtp.sh.sample /var/lib/pacemaker/alert_smtp.sh
#pcs alert create id=smtp_alert path=/var/lib/pacemaker/alert_smtp.sh options email_sender=donotreply@example.com
#pcs alert recipient add smtp_alert value=admin@example.com
#pcs alert
Alerts: Alert: smtp_alert (path=/var/lib/pacemaker/alert_smtp.sh) Options: email_sender=donotreply@example.com Recipients: Recipient: smtp_alert-recipient (value=admin@example.com)
13.1.2. アラートの作成
id
の値を指定しないと、値が生成されます。アラートメタオプションの詳細は、「アラートメタオプション」 を参照してください。
pcs alert create path=path [id=alert-id] [description=description] [options [option=value]...] [meta [meta-option=value]...]
myscript.sh
を呼び出す簡単なアラートを作成します。
# pcs alert create id=my_alert path=/path/to/myscript.sh
13.1.3. アラートの表示、編集、および削除
pcs alert [config|show]
pcs alert update alert-id [path=path] [description=description] [options [option=value]...] [meta [meta-option=value]...]
pcs alert remove alert-id
13.1.4. アラートの受信側
pcs alert recipient add alert-id value=recipient-value [id=recipient-id] [description=description] [options [option=value]...] [meta [meta-option=value]...]
pcs alert recipient update recipient-id [value=recipient-value] [description=description] [options [option=value]...] [meta [meta-option=value]...]
pcs alert recipient remove recipient-id
my-recipient-id
のアラート受信側 my-alert-recipient
を、アラート my-alert
に追加します。これにより、クラスターが各イベントの my-alert
用に設定したアラートスクリプトを呼び出すように設定され、受信者 some-address
が環境変数として渡されます。
# pcs alert recipient add my-alert value=my-alert-recipient id=my-recipient-id options value=some-address
13.1.5. アラートメタオプション
表13.1 アラートメタオプション
メタ属性 | デフォルト | 説明 |
---|---|---|
timestamp-format
|
%H:%M:%S.%06N
|
イベントのタイムスタンプをエージェントに送信するときにクラスターが使用する形式です。この文字列は
date (1) コマンドで使用されます。
|
timeout
|
30s
|
アラートエージェントがこの時間内に完了しないと終了させられます。
|
myscript.sh
スクリプトを呼び出すアラートを設定し、2 つの受信側をアラートに追加します。最初の受信側の ID は my-alert-recipient1
で、2 つ目の受信側の ID は my-alert-recipient2
です。スクリプトは各イベントで 2 回呼び出され、呼び出しのタイムアウト値はそれぞれ 15 秒です。呼び出しの 1 つは受信側 someuser@example.com
に渡され、タイムスタンプの形式は %D %H:%M になります。もう 1 つの呼び出しは受信側 otheruser@example.com
へ渡され、タイムスタンプの形式は %c になります。
#pcs alert create id=my-alert path=/path/to/myscript.sh meta timeout=15s
#pcs alert recipient add my-alert value=someuser@example.com id=my-alert-recipient1 meta timestamp-format="%D %H:%M"
#pcs alert recipient add my-alert value=otheruser@example.com id=my-alert-recipient2 meta timestamp-format=%c
13.1.6. アラート設定コマンドの例
- アラート ID の値が指定されていないため、
alert
のアラート ID が作成されます。 - 最初の受信側作成コマンドは、
rec_value
の受信側を指定します。このコマンドには受信側 ID が指定されていないため、alert-recipient
の値が受信側 ID として使用されます。 - 2 番目の受信側作成コマンドは、
rec_value2
の受信側を指定します。このコマンドは、my-recipient
を受信側 ID として指定します。
#pcs alert create path=/my/path
#pcs alert recipient add alert value=rec_value
#pcs alert recipient add alert value=rec_value2 id=my-recipient
#pcs alert config
Alerts: Alert: alert (path=/my/path) Recipients: Recipient: alert-recipient (value=rec_value) Recipient: my-recipient (value=rec_value2)
my-alert
で、受信側の値は my-other-recipient
です。受信側 ID が指定されていないため、my-alert-recipient
が受信側 ID として使用されます。
#pcs alert create id=my-alert path=/path/to/script description=alert_description options option1=value1 opt=val meta timeout=50s timestamp-format="%H%B%S"
#pcs alert recipient add my-alert value=my-other-recipient
#pcs alert
Alerts: Alert: alert (path=/my/path) Recipients: Recipient: alert-recipient (value=rec_value) Recipient: my-recipient (value=rec_value2) Alert: my-alert (path=/path/to/script) Description: alert_description Options: opt=val option1=value1 Meta options: timestamp-format=%H%B%S timeout=50s Recipients: Recipient: my-alert-recipient (value=my-other-recipient)
my-alert
と受信側 my-alert-recipient
のアラート値を変更します。
#pcs alert update my-alert options option1=newvalue1 meta timestamp-format="%H%M%S"
#pcs alert recipient update my-alert-recipient options option1=new meta timeout=60s
#pcs alert
Alerts: Alert: alert (path=/my/path) Recipients: Recipient: alert-recipient (value=rec_value) Recipient: my-recipient (value=rec_value2) Alert: my-alert (path=/path/to/script) Description: alert_description Options: opt=val option1=newvalue1 Meta options: timestamp-format=%H%M%S timeout=50s Recipients: Recipient: my-alert-recipient (value=my-other-recipient) Options: option1=new Meta options: timeout=60s
my-alert-recipient
を alert
から削除します。
#pcs alert recipient remove my-recipient
#pcs alert
Alerts: Alert: alert (path=/my/path) Recipients: Recipient: alert-recipient (value=rec_value) Alert: my-alert (path=/path/to/script) Description: alert_description Meta options: timestamp-format="%M%B%S" timeout=50s Meta options: m=newval meta-option1=2 Recipients: Recipient: my-alert-recipient (value=my-other-recipient) Options: option1=new Meta options: timeout=60s
myalert
を削除します。
#pcs alert remove my-alert
#pcs alert
Alerts: Alert: alert (path=/my/path) Recipients: Recipient: alert-recipient (value=rec_value)
13.1.7. アラートエージェントの作成
表13.2 アラートエージェントに渡される環境変数
環境変数 | 説明 |
---|---|
CRM_alert_kind
|
アラートの種類 (ノード、フェンス、またはリソース)
|
CRM_alert_version
|
アラートを送信する Pacemaker のバージョン
|
CRM_alert_recipient
|
設定された送信側
|
CRM_alert_node_sequence
|
アラートがローカルノードで発行されるたびに増加するシーケンス番号。これは、Pacemaker によりアラートが発行された順序を参照するのに使用できます。後で発生したイベントのアラートは、先に発生したイベントのアラートよりもシーケンス番号が大きくなります。この番号は、クラスター全体を対象とする番号ではないことに注意してください。
|
CRM_alert_timestamp
| timestamp-format メタオプションで指定された形式で、エージェントの実行前に作成されたタイムスタンプ。これにより、エージェントは、エージェント自体が呼び出されたタイミング (システムの負荷やその他の状況により遅延する可能性があります) に関係なく、信頼できる高精度のイベント発生時間を使用できます。
|
CRM_alert_node
|
影響を受けるノードの名前
|
CRM_alert_desc
|
イベントの詳細。ノードアラートの場合は、ノードの現在の状態 (番号または lost) になります。フェンスアラートの場合は、フェンス操作の要求元、ターゲット、フェンス操作のエラーコードなどを含む要求されたフェンス操作の概要になります。リソースアラートの場合は、
CRM_alert_status と同等の読み取り可能な文字列になります。
|
CRM_alert_nodeid
|
状態が変更したノードの ID (ノードアラートの場合のみ提供)。
|
CRM_alert_task
|
要求されたフェンスまたはリソース操作 (フェンスおよびリソースアラートの場合のみ提供)。
|
CRM_alert_rc
|
フェンスまたはリソース操作の数値の戻りコード (フェンスおよびリソースアラートの場合のみ提供)。
|
CRM_alert_rsc
|
影響を受けるリソースの名前 (リソースアラートのみ)。
|
CRM_alert_interval
|
リソース操作の間隔 (リソースアラートのみ)
|
CRM_alert_target_rc
|
操作の予期される数値の戻りコード (リソースアラートのみ)。
|
CRM_alert_status
|
Pacemaker が、操作の結果を示すために使用する数値コード (リソースアラートのみ)。
|
- アラートエージェントは受信者なしで呼び出されることがあります (受信者が設定されていない場合)。したがって、エージェントは、このような状況では終了しかしない場合でも、この状態に対応できなければなりません。設定を段階的に変更し、後で受信側を追加することもできます。
- 1 つのアラートに複数の受信側が設定されると、アラートエージェントは受信側ごとに 1 回呼び出されます。エージェントが同時に実行できない場合は、受信側を 1 つのみ設定する必要があります。エージェントは、受信側をリストとして解釈することができます。
- クラスターイベントの発生時、すべてのアラートは別々のプロセスとして同時に発生します。設定されているアラートと受信者の数、およびアラートエージェント内で行われている内容に応じて、負荷が急激に増加する可能性があります。たとえば、リソースを大量に消費するアクションを直接実行するのではなく、別のインスタンスのキューに追加することで、これを考慮に入れるようにエージェントを作成できます。
- アラートエージェントは、最低限のパーミッションを持つ
hacluster
ユーザーで実行します。アラートエージェントに追加のパーミッションが必要な場合は、sudo を設定してアラートエージェントが適切な特権を持つ別ユーザーとして必要なコマンドを実行できるようにすることが推奨されます。 CRM_alert_timestamp
(このコンテンツはユーザー設定のtimestamp-format
によって指定)、CRM_alert_recipient
、すべてのアラートオプションなど、ユーザー設定のパラメーターを検証およびサニタイズする場合は十分注意してください。これは、設定エラーから保護するために必要です。また、クラスターノードへのhacluster
レベルのアクセスがなくても CIB を変更できるユーザーが存在する場合は、セキュリティーの問題が発生する可能性もあり、コードを挿入できないようにする必要があります。onfail
パラメーターがfence
に設定されている操作を持つリソースがクラスターに含まれる場合は、障害発生時に複数のフェンス通知 (このパラメーターが設定されているリソースごとに 1 つの通知と、追加の通知 1 つ) が送信されます。STONITH デーモンとcrmd
デーモンの両方が通知を送信します。この場合、送信される通知の数に関係なく、Pacemaker は 1 つのフェンス操作のみを実際に実行します。
ocf:pacemaker:ClusterMon
リソースで使用される外部スクリプトインターフェイスと後方互換性を維持するよう設計されています。この互換性を維持するには、先頭に CRM_notify_
および CRM_alert_
が付けいたアラートエージェントに渡される環境変数を使用できます。互換性の問題の 1 つは、アラートエージェントが hacluster
ユーザーで実行している最中に、ClusterMon
リソースが root ユーザーで外部スクリプトを実行したことです。ClusterMon
によってトリガーされるスクリプトの設定については、「モニターリングのリソースを使ったイベント通知」 を参照してください。
13.2. モニターリングのリソースを使ったイベント通知
ocf:pacemaker:ClusterMon
リソースはクラスターの状態を監視でき、クラスターイベントごとにアラートをトリガーできます。このリソースは、標準の間隔で crm_mon コマンドをバックグランドで実行します。
ClusterMon
リソース設定するときに、--watch-fencing
オプションをコマンドに指定します。crm_mon コマンドはメンバーシップの問題を監視しませんが、フェンスが開始され、そのノードに対して監視が開始されたときにメッセージが出力されます。これはメンバーがクラスターに参加したことを意味します。
リソース
は外部プログラムを実行して、extra_options
パラメーターでクラスター通知を行うものを判別できます。表13.3「外部監視プログラムへ渡される環境変数」 は、発生したクラスターイベントのタイプを記述する、プログラムに渡される環境変数を一覧表示します。
表13.3 外部監視プログラムへ渡される環境変数
環境変数 | 説明 |
---|---|
CRM_notify_recipient
|
リソース定義からの静的な外部受信側。
|
CRM_notify_node
|
状態が変更したノード。
|
CRM_notify_rsc
|
状態を変更したリソースの名前。
|
CRM_notify_task
|
状態が変更する原因となった操作。
|
CRM_notify_desc
|
状態が変更する原因となった操作 (該当の操作がある場合) のテキスト出力の関連エラーコード。
|
CRM_notify_rc
|
操作の戻りコード。
|
CRM_target_rc
|
操作の予期される戻りコード。
|
CRM_notify_status
|
操作の状態の数値表現。
|
ClusterMon
リソースを設定します。このプログラムは指定されたイベント通知をログに記録します。
crm_logger.sh
プログラムを作成します。
- クラスターのノードの 1 つで、イベント通知をログに記録するプログラムを作成します。
#
cat <<-END >/usr/local/bin/crm_logger.sh
#!/bin/sh
logger -t "ClusterMon-External" "${CRM_notify_node} ${CRM_notify_rsc}
\${CRM_notify_task} ${CRM_notify_desc} ${CRM_notify_rc}
\${CRM_notify_target_rc} ${CRM_notify_status} ${CRM_notify_recipient}";
exit;
END
- プログラムの所有者とパーミッションを設定します。
#
chmod 700 /usr/local/bin/crm_logger.sh
#chown root.root /usr/local/bin/crm_logger.sh
- scp コマンドを使用して crm_logger.sh プログラムをクラスターの他のノードにコピーし、これらのノードの同じ場所にプログラムを格納し、プログラムに同じ所有者とパーミッションを設定します。
/usr/local/bin/crm_logger.sh
プログラムを実行する ClusterMon-External
という名前の ClusterMon
リソースを設定します。ClusterMon
リソースは html
ファイル (この例の場合は /var/www/html/cluster_mon.html
) にクラスターの状態を出力します。pidfile
は ClusterMon
がすでに実行されているかどうかを検出します (この例では /var/run/crm_mon-external.pid
ファイル)。このリソースはクローンとして作成されるため、クラスターの各ノードで実行されます。watch-fencing
は、フェンスリソースの start/stop/monitor、start/monitor など、リソースイベントなどのフェンスイベントの監視を有効にするために指定されます。
#pcs resource create ClusterMon-External ClusterMon user=root
\update=10 extra_options="-E /usr/local/bin/crm_logger.sh --watch-fencing"
\htmlfile=/var/www/html/cluster_mon.html
\pidfile=/var/run/crm_mon-external.pid clone
#/usr/sbin/crm_mon -p /var/run/crm_mon-manual.pid -d -i 5
\-h /var/www/html/crm_mon-manual.html -E "/usr/local/bin/crm_logger.sh"
\--watch-fencing
Aug 7 11:31:32 rh6node1pcmk ClusterMon-External: rh6node2pcmk.examplerh.com ClusterIP st_notify_fence Operation st_notify_fence requested by rh6node1pcmk.examplerh.com for peer rh6node2pcmk.examplerh.com: OK (ref=b206b618-e532-42a5-92eb-44d363ac848e) 0 0 0 #177 Aug 7 11:31:32 rh6node1pcmk ClusterMon-External: rh6node1pcmk.examplerh.com ClusterIP start OK 0 0 0 Aug 7 11:31:32 rh6node1pcmk ClusterMon-External: rh6node1pcmk.examplerh.com ClusterIP monitor OK 0 0 0 Aug 7 11:33:59 rh6node1pcmk ClusterMon-External: rh6node1pcmk.examplerh.com fence_xvms monitor OK 0 0 0 Aug 7 11:33:59 rh6node1pcmk ClusterMon-External: rh6node1pcmk.examplerh.com ClusterIP monitor OK 0 0 0 Aug 7 11:33:59 rh6node1pcmk ClusterMon-External: rh6node1pcmk.examplerh.com ClusterMon-External start OK 0 0 0 Aug 7 11:33:59 rh6node1pcmk ClusterMon-External: rh6node1pcmk.examplerh.com fence_xvms start OK 0 0 0 Aug 7 11:33:59 rh6node1pcmk ClusterMon-External: rh6node1pcmk.examplerh.com ClusterIP start OK 0 0 0 Aug 7 11:33:59 rh6node1pcmk ClusterMon-External: rh6node1pcmk.examplerh.com ClusterMon-External monitor OK 0 0 0 Aug 7 11:34:00 rh6node1pcmk crmd[2887]: notice: te_rsc_command: Initiating action 8: monitor ClusterMon-External:1_monitor_0 on rh6node2pcmk.examplerh.com Aug 7 11:34:00 rh6node1pcmk crmd[2887]: notice: te_rsc_command: Initiating action 16: start ClusterMon-External:1_start_0 on rh6node2pcmk.examplerh.com Aug 7 11:34:00 rh6node1pcmk ClusterMon-External: rh6node1pcmk.examplerh.com ClusterIP stop OK 0 0 0 Aug 7 11:34:00 rh6node1pcmk crmd[2887]: notice: te_rsc_command: Initiating action 15: monitor ClusterMon-External_monitor_10000 on rh6node2pcmk.examplerh.com Aug 7 11:34:00 rh6node1pcmk ClusterMon-External: rh6node2pcmk.examplerh.com ClusterMon-External start OK 0 0 0 Aug 7 11:34:00 rh6node1pcmk ClusterMon-External: rh6node2pcmk.examplerh.com ClusterMon-External monitor OK 0 0 0 Aug 7 11:34:00 rh6node1pcmk ClusterMon-External: rh6node2pcmk.examplerh.com ClusterIP start OK 0 0 0 Aug 7 11:34:00 rh6node1pcmk ClusterMon-External: rh6node2pcmk.examplerh.com ClusterIP monitor OK 0 0 0
第14章 Pacemaker を用いたマルチサイトクラスターの設定
- Cluster 1 は、ノード
cluster1-node1
およびcluster1-node2
で設定されます。 - Cluster 1 に割り当てられたフローティング IP アドレスは 192.168.11.100 です。
- Cluster 2 は、
cluster2-node1
およびcluster2-node2
で設定されます。 - Cluster 2 に割り当てられたフローティング IP アドレスは 192.168.22.100 です。
- 仲裁ノードは
arbitrator-node
で、IP アドレスは 192.168.99.100 です。 - この設定が使用する Booth チケットの名前は
apacheticket
です。
apachegroup
リソースグループの一部として設定されていることを前提としています。各クラスターの Pacemaker インスタンスは独立しているため、このリソースのチケット制約を設定するために、各クラスターでリソースとリソースグループが同じである必要はありませんが、これはフェールオーバーの一般的な事例になります。
booth-site
Booth チケットマネージャーパッケージを、両方のクラスターの各ノードにインストールします。[root@cluster1-node1 ~]#
yum install -y booth-site
[root@cluster1-node2 ~]#yum install -y booth-site
[root@cluster2-node1 ~]#yum install -y booth-site
[root@cluster2-node2 ~]#yum install -y booth-site
pcs
パッケージ、booth-core
パッケージ、およびbooth-arbitrator
パッケージを仲裁ノードにインストールします。[root@arbitrator-node ~]#
yum install -y pcs booth-core booth-arbitrator
- 9929/tcp ポートと 9929/udp ポートがすべてのクラスターノードと仲裁ノードで解放されていることを確認します。たとえば、両方のクラスターのすべてのノードと仲裁ノードで次のコマンドを実行すると、そのノードの 9929/tcp ポートおよび 9929/udp ポートにアクセスできます。
#
firewall-cmd --add-port=9929/udp
#firewall-cmd --add-port=9929/tcp
#firewall-cmd --add-port=9929/udp --permanent
#firewall-cmd --add-port=9929/tcp --permanent
この手順自体により、任意のマシンがノード上の 9929 ポートにアクセスできることに注意してください。お使いのサイトで、ノードが必要なノードに対してのみ開いていることを確認する必要があります。 - 1 つのクラスターの 1 つのノードで Booth 設定を作成します。各クラスターおよび仲裁ノードに指定するアドレスは IP アドレスでなければなりません。各クラスターにはフローティング IP アドレスを指定します。
[cluster1-node1 ~] #
pcs booth setup sites 192.168.11.100 192.168.22.100 arbitrators 192.168.99.100
このコマンドを実行すると、/etc/booth/booth.conf
および/etc/booth/booth.key
設定ファイルがノード上に作成されます。 - Booth 設定のチケットを作成します。このチケットは、このチケットがクラスターに付与された場合のみリソースの実行を許可するリソース抑制を定義するのに使用します。このフェイルオーバー設定手順は基本的な手順で、チケットを 1 つだけ使用します。各チケットが別の 1 つ以上のリソースに関連付けられる、より複雑な事例では追加のチケットを作成します。
[cluster1-node1 ~] #
pcs booth ticket add apacheticket
- 現在のクラスターのすべてのノードに対して Booth 設定を同期します。
[cluster1-node1 ~] #
pcs booth sync
- 仲裁ノードから、Booth 設定を仲裁者へプルします。この作業をこれまで行ったことがない場合は、最初に、設定をプルするノードに
pcs
を認証する必要があります。[arbitrator-node ~] #
pcs cluster auth cluster1-node1
[arbitrator-node ~] #pcs booth pull cluster1-node1
- Booth 設定を別のクラスターにプルし、そのクラスターのすべてのノードを同期します。仲裁ノードでこの作業を行ったことがない場合は、最初に、設定をプルするノードに
pcs
を認証する必要があります。[cluster2-node1 ~] #
pcs cluster auth cluster1-node1
[cluster2-node1 ~] #pcs booth pull cluster1-node1
[cluster2-node1 ~] #pcs booth sync
- 仲裁ノードで Booth を開始して有効にします。注記Booth はクラスターで Pacemaker リソースとして実行するため、クラスターのノードで Booth を手動で開始したり有効にしたりしないでください。
[arbitrator-node ~] #
pcs booth start
[arbitrator-node ~] #pcs booth enable
- Booth を設定し、両方のクラスターサイトでクラスターリソースとして実行されるようにします。
booth-ip
およびbooth-service
をグループのメンバーとするリソースグループが作成されます。[cluster1-node1 ~] #
pcs booth create ip 192.168.11.100
[cluster2-node1 ~] #pcs booth create ip 192.168.22.100
- 各クラスターに定義したリソースグループにチケット制約を追加します。
[cluster1-node1 ~] #
pcs constraint ticket add apacheticket apachegroup
[cluster2-node1 ~] #pcs constraint ticket add apacheticket apachegroup
次のコマンドを実行すると、現在設定されているチケット制約を表示できます。pcs constraint ticket [show]
- この設定用に作成したチケットを最初のクラスターに付与します。チケットを付与する前にチケット抑制を定義する必要はありません。最初にチケットをクラスターに付与した後、 pcs booth ticket revoke コマンドで手動でオーバーライドしない限り、Booth はチケットの管理を引き継ぎます。pcs booth 管理コマンドの詳細は、pcs booth コマンドの PCS ヘルプ画面を参照してください。
[cluster1-node1 ~] #
pcs booth ticket grant apacheticket
付録A OCF 戻りコード
表A.1 クラスターが行う復旧タイプ
タイプ | 説明 | クラスターが行った操作 |
---|---|---|
軽度
|
一時的なエラーが発生しました。
|
リソースを再起動するか、新しい場所に移します。
|
重度
|
現在のノードに固有である可能性のある一時的ではないエラーが発生しました。
|
リソースを別の場所に移動し、現在のノードで再試行されないようにします。
|
致命的
|
すべてのクラスターノードに共有となる一時的でないエラーが発生しました (例: 指定された設定がよくありません)。
|
リソースを停止し、いかなるクラスターノードでも起動されないようにします。
|
OCF_SUCCESS
) を返すイベントアクションは、0 が、期待されている戻り値でない場合に、失敗とみなされます。
表A.2 OCF 戻りコード
戻りコード | OCF ラベル | 説明 | |||
---|---|---|---|---|---|
0
| OCF_SUCCESS
|
| |||
1
| OCF_ERR_GENERIC
|
| |||
2
| OCF_ERR_ARGS
|
| |||
3
| OCF_ERR_UNIMPLEMENTED
|
| |||
4
| OCF_ERR_PERM
|
| |||
5
| OCF_ERR_INSTALLED
|
| |||
6
| OCF_ERR_CONFIGURED
|
| |||
7
| OCF_NOT_RUNNING
|
| |||
8
| OCF_RUNNING_MASTER
|
| |||
9
| OCF_FAILED_MASTER
|
| |||
その他
|
該当なし
|
カスタムエラーコード
|
付録B Red Hat Enterprise Linux 6 および Red Hat Enterprise Linux 7 でのクラスターの作成
rgmanager
を用いて Red Hat Enterprise Linux 6 のクラスターを設定する場合とは異なる設定ツールと管理インターフェイスが必要になります。「クラスター作成 - rgmanager と Pacemaker」 では、さまざまなクラスターコンポーネント間の設定の違いをまとめています。
B.1. クラスター作成 - rgmanager と Pacemaker
rgmanager
を使用した場合と Red Hat Enterprise Linux 7 で Pacemaker を使用した場合のクラスターコンポーネントの設定方法を比較しています。
表B.1 gmanager と Pacemaker を使用した場合のクラスター設定に関する比較
設定コンポーネント | rgmanager | Pacemaker |
---|---|---|
クラスター設定ファイル
|
各ノード上のクラスター設定ファイルは、直接編集が可能な
cluster.conf ファイルです。あるいは、luci か ccs インターフェイスを使用して、クラスター設定を定義します。
|
クラスターおよび Pacemaker 設定ファイルは
corosync.conf および cib.xml です。cib.xml ファイルは直接編集しないでください。代わりに pcs または pcsd インターフェイスを使用して編集してください。
|
ネットワーク設定
|
クラスター設定前に IP アドレスおよび SSH を設定
|
クラスター設定前に IP アドレスおよび SSH を設定
|
クラスター設定ツール
|
luci、ccs コマンド、手作業で
cluster.conf ファイルを編集
|
pcs または pcsd
|
インストール
| rgmanager のインストール (ricci 、luci 、リソース、フェンスエージェントなどすべての依存パッケージをインストール)。必要な場合は lvm2-cluster および gfs2-utils をインストールします。
| pcs と必要なフェンスエージェントをインストールします。必要な場合は lvm2-cluster および gfs2-utils をインストールします。
|
クラスターサービスの起動
|
次の手順でクラスターサービスを起動、有効にする
または、ccs --start を実行してクラスターサービスを開始および有効化します。
|
次の手順でクラスターサービスを起動、有効にする
|
設定ツールへのアクセスの制御
|
luci の場合、root ユーザーまたは luci パーミッションを持つユーザーは luci にアクセスでき ます。すべてのアクセスには、ノードの
ricci パスワードが必要です。
|
pcsd GUI では、共通のシステムユーザーであるユーザー
hacluster として認証される必要があります。root ユーザーは hacluster のパスワードを設定できます。
|
クラスター作成
|
クラスターの命名、クラスターに含ませるノードの定義などは luci または ccs で行うか
cluster.conf ファイルを直接編集
|
pcs cluster setup コマンドまたは
pcsd Web UI を使用して、クラスターに名前を付け、ノードを含めます。pcs cluster node add コマンドまたは pcsd Web UI を使用すると、ノードを既存のクラスターに追加できます。
|
クラスター設定を全ノードに伝える
|
クラスターを luci で設定する場合は設定は自動です。ccs で、
--sync オプションを使用します。cman_tool version -r コマンドを使用することもできます。
|
クラスターおよび Pacemaker 設定ファイルである
corosync.conf および cib.xml は、クラスターの設定時やノードまたはリソースの追加時に自動的に伝播されます。
|
グローバルのクラスタープロパティー
|
以下の機能は、Red Hat Enterprise Linux 6 の
rgmanager によってサポートされます。
* クラスターネットワーク内での IP マルチキャスティングに使用するマルチキャストアドレスの選択をシステム側で行うよう設定することが可能
* IP マルチキャスティングが利用できない場合に UDP Unicast トランスポートメカニズムが使用可能
* RRP プロトコルを使用したクラスター設定が可能
|
Red Hat Enterprise Linux 7 の Pacemaker はクラスターに対して以下の機能をサポートします。
* クラスターに
no-quorum-policy を設定しクラスターが定足数を持たない場合のシステムの動作を指定できる
* 設定可能な追加のクラスタープロパティーについては、表12.1「クラスターのプロパティー」 を参照してください。
|
ロギング
|
グローバルおよびデーモン固有のログ記録設定が可能
|
ログ記録を手作業で設定する方法については
/etc/sysconfig/pacemaker ファイルを参照
|
クラスターの検証
|
luci および ccs ではクラスタースキーマを使った自動検証、クラスターは起動時に自動的に検証されるクラスターは起動時に自動的に検証されます。
|
クラスターは起動時に自動的に検証される、または pcs cluster verify を使っての検証も可
|
2 ノードクラスターのクォーラム
|
2 ノードのクラスターの場合、システムによるクォーラムの決定方法を設定できます。
* クォーラムディスクの設定
* ccs を使用するか
cluster.conf ファイルを編集して two_node=1 および expected_votes=1 を設定し、1 つのノードがクォーラムを維持できるようにします。
|
pcs は 2 ノードクラスターに必要なオプションを自動的に
corosync へ追加します。
|
クラスターの状態
|
luci では、クラスターの現在の状態がインターフェイスのさまざまなコンポーネントで表示されます。ccs コマンドの
--getconf オプションを使用して、現在の設定ファイルを確認できます。オプションを使用すると、現在の設定ファイルを確認できます。clustat コマンドを使用するとクラスターの状態を表示できます。
|
pcs status コマンドを使用して、現在のクラスターの状態を表示できます。
|
リソース
|
定義したタイプのリソースの追加およびリソース固有のプロパティーの設定は luci または ccs コマンドを使用して行うか
cluster.conf 設定ファイルを編集して行う
|
pcs resource create コマンドまたは
pcsd Web UI を使用して、定義されたタイプのリソースを追加し、リソース固有のプロパティーを設定します。Pacemaker を使用してクラスターリソースを設定する方法は、6章クラスターリソースの設定 を参照してください。
|
リソースの動作、グループ化、起動と停止の順序
|
リソースの通信方法の設定にクラスターの サービス を定義
|
Pacemaker では、同時に配置され、順番に開始および停止される必要があるリソースのセットを定義する簡単な方法としてリソースグループを使用します。さらに、以下の方法でリソースの動作および対話方法を定義できます。
* リソース動作の一部はリソースオプションとして設定
* 場所の制約を使ってリソースを実行させるノードを指定
* 順序の制約を使ってリソースの実行順序を指定
コロケーション制約を使って任意のリソースの場所が別のリソースの場所に依存することを指定
これらのトピックの詳細については 6章クラスターリソースの設定 および 7章リソースの制約 を参照してください。
|
リソース管理: リソースの移動、起動、停止
|
luci を使用すると、クラスター、個別のクラスターノード、およびクラスターサービスを管理できます。ccs コマンドを使用すると、クラスターを管理できます。clusvadm を使用してクラスターサービスを管理できます。
|
pcs cluster standby コマンドを使ってノードを一時的に無効にし、リソースをホストできないようにすることができます。これにより、リソースを移行することになります。pcs resource disable コマンドでリソースを停止できます。
|
クラスターの設定を完全に削除
|
luci では、削除してクラスターを完全に削除するために、クラスター内のすべてのノードを選択できます。クラスターの各ノードから
cluster.conf を削除することもできます。
|
pcs cluster destroy コマンドを使用するとクラスター設定を削除できます。
|
複数のノードで実行中のリソース、複数モードで複数のノード上で実行中のリソース
|
該当なし。
|
Pacemaker ではリソースのクローンを作成し複数のノードで実行させることが可能で、作成したリソースのクローンをマスターリソースとスレーブリソースとして定義し複数のモードで実行させることが可能です。クローン作成したリソースおよびマスター/スレーブリソースに関する情報は、9章高度な設定 を参照してください。
|
フェンス機能 -- 1 ノードにつき 1 フェンス
|
フェンスデバイスをグローバルに作成するか、またはローカルに作成し、ノードに追加します。
post-fail delay と post-join delay の値を全体として定義できます。
|
pcs stonith create または
pcsd Web UI を使用して各ノードにフェンスデバイスを作成します。複数のノードをフェンスできるデバイスでは、各ノードで個別に定義せずに 1 度に定義する必要があります。pcmk_host_map を定義して、1 つのコマンドで全ノードのフェンスデバイスを設定することもできます。pcmk_host_map の詳細は、表5.1「フェンスデバイスの一般的なプロパティー」 を参照してください。クラスターの stonith-timeout の値を全体として定義できます。
|
1 ノードごとに複数の (バックアップ) フェンスデバイス
|
バックアップデバイスの定義は luci または ccs コマンドを使用するか
cluster.conf ファイルを直接編集
|
フェンスレベルを設定
|
B.2. Red Hat Enterprise Linux 6 および Red Hat Enterprise Linux 7 での Pacemaker のインストール
[root@rhel6]#yum install pacemaker cman pcs
[root@rhel6]#chkconfig corosync off
[root@rhel6]#chkconfig cman off
hacluster
という名前の pcs 管理者アカウントのパスワードを設定し、pcsd サービスの起動と有効化を行います。
[root@rhel6]#passwd hacluster
[root@rhel6]#service pcsd start
[root@rhel6]#chkconfig pcsd on
[root@rhel6]# pcs cluster auth [node] [...] [-u username] [-p password]
hacluster
という名前の pcs 管理アカウントのパスワードを設定し、pcsd サービスの起動と有効化を行います。
[root@rhel7]#yum install pcs pacemaker fence-agents-all
[root@rhel7]#passwd hacluster
[root@rhel7]#systemctl start pcsd.service
[root@rhel7]#systemctl enable pcsd.service
[root@rhel7]# pcs cluster auth [node] [...] [-u username] [-p password]
付録C 更新履歴
改訂履歴 | |||
---|---|---|---|
改訂 8.1-1 | Fri Feb 28 2020 | Steven Levine | |
| |||
改訂 7.1-1 | Wed Aug 7 2019 | Steven Levine | |
| |||
改訂 6.1-1 | Thu Oct 4 2018 | Steven Levine | |
| |||
改訂 5.1-2 | Thu Mar 15 2018 | Steven Levine | |
| |||
改訂 5.1-0 | Thu Dec 14 2017 | Steven Levine | |
| |||
改訂 4.1-9 | Tue Oct 17 2017 | Steven Levine | |
| |||
改訂 4.1-5 | Wed Jul 19 2017 | Steven Levine | |
| |||
改訂 4.1-2 | Wed May 10 2017 | Steven Levine | |
| |||
改訂 3.1-10 | Tue May 2 2017 | Steven Levine | |
| |||
改訂 3.1-4 | Mon Oct 17 2016 | Steven Levine | |
| |||
改訂 3.1-3 | Wed Aug 17 2016 | Steven Levine | |
| |||
改訂 2.1-8 | Mon Nov 9 2015 | Steven Levine | |
| |||
改訂 2.1-5 | Mon Aug 24 2015 | Steven Levine | |
| |||
改訂 1.1-9 | Mon Feb 23 2015 | Steven Levine | |
| |||
改訂 1.1-7 | Thu Dec 11 2014 | Steven Levine | |
| |||
改訂 0.1-41 | Mon Jun 2 2014 | Steven Levine | |
| |||
改訂 0.1-2 | Thu May 16 2013 | Steven Levine | |
|
索引
シンボル
- アクション
- アクションプロパティー, リソースの動作
- オプション
- batch-limit, クラスタープロパティーとオプションの要約
- clone-max, クローンリソースの作成と削除
- clone-node-max, クローンリソースの作成と削除
- cluster-delay, クラスタープロパティーとオプションの要約
- cluster-infrastructure, クラスタープロパティーとオプションの要約
- cluster-recheck-interval, クラスタープロパティーとオプションの要約
- dampen, 接続状態変更によるリソースの移動
- dc-version, クラスタープロパティーとオプションの要約
- enable-acl, クラスタープロパティーとオプションの要約
- failure-timeout, リソースのメタオプション
- fence-reaction, クラスタープロパティーとオプションの要約
- globally-unique, クローンリソースの作成と削除
- host_list, 接続状態変更によるリソースの移動
- interleave, クローンリソースの作成と削除
- is-managed, リソースのメタオプション
- last-lrm-refresh, クラスタープロパティーとオプションの要約
- maintenance-mode, クラスタープロパティーとオプションの要約
- master-max, 多状態のリソース: 複数モードのリソース
- master-node-max, 多状態のリソース: 複数モードのリソース
- migration-limit, クラスタープロパティーとオプションの要約
- migration-threshold, リソースのメタオプション
- multiple-active, リソースのメタオプション
- multiplier, 接続状態変更によるリソースの移動
- no-quorum-policy, クラスタープロパティーとオプションの要約
- notify, クローンリソースの作成と削除
- ordered, クローンリソースの作成と削除
- pe-error-series-max, クラスタープロパティーとオプションの要約
- pe-input-series-max, クラスタープロパティーとオプションの要約
- pe-warn-series-max, クラスタープロパティーとオプションの要約
- placement-strategy, クラスタープロパティーとオプションの要約
- priority, リソースのメタオプション
- requires, リソースのメタオプション
- resource-stickiness, リソースのメタオプション
- shutdown-escalation, クラスタープロパティーとオプションの要約
- start-failure-is-fatal, クラスタープロパティーとオプションの要約
- stonith-action, クラスタープロパティーとオプションの要約
- stonith-enabled, クラスタープロパティーとオプションの要約
- stonith-timeout, クラスタープロパティーとオプションの要約
- stop-all-resources, クラスタープロパティーとオプションの要約
- stop-orphan-actions, クラスタープロパティーとオプションの要約
- stop-orphan-resources, クラスタープロパティーとオプションの要約
- symmetric-cluster, クラスタープロパティーとオプションの要約
- target-role, リソースのメタオプション
- オプションのクエリー, クラスタープロパティー設定のクエリー
- クエリー
- クラスターのプロパティー, クラスタープロパティー設定のクエリー
- クラスター
- オプション
- batch-limit, クラスタープロパティーとオプションの要約
- cluster-delay, クラスタープロパティーとオプションの要約
- cluster-infrastructure, クラスタープロパティーとオプションの要約
- cluster-recheck-interval, クラスタープロパティーとオプションの要約
- dc-version, クラスタープロパティーとオプションの要約
- enable-acl, クラスタープロパティーとオプションの要約
- fence-reaction, クラスタープロパティーとオプションの要約
- last-lrm-refresh, クラスタープロパティーとオプションの要約
- maintenance-mode, クラスタープロパティーとオプションの要約
- migration-limit, クラスタープロパティーとオプションの要約
- no-quorum-policy, クラスタープロパティーとオプションの要約
- pe-error-series-max, クラスタープロパティーとオプションの要約
- pe-input-series-max, クラスタープロパティーとオプションの要約
- pe-warn-series-max, クラスタープロパティーとオプションの要約
- placement-strategy, クラスタープロパティーとオプションの要約
- shutdown-escalation, クラスタープロパティーとオプションの要約
- start-failure-is-fatal, クラスタープロパティーとオプションの要約
- stonith-action, クラスタープロパティーとオプションの要約
- stonith-enabled, クラスタープロパティーとオプションの要約
- stonith-timeout, クラスタープロパティーとオプションの要約
- stop-all-resources, クラスタープロパティーとオプションの要約
- stop-orphan-actions, クラスタープロパティーとオプションの要約
- stop-orphan-resources, クラスタープロパティーとオプションの要約
- symmetric-cluster, クラスタープロパティーとオプションの要約
- プロパティーのクエリー, クラスタープロパティー設定のクエリー
- プロパティーの削除, クラスターのプロパティーの設定と削除
- プロパティーの設定, クラスターのプロパティーの設定と削除
- クラスターのステータス
- display, クラスターの状態表示
- クラスターのプロパティー, クラスターのプロパティーの設定と削除, クラスタープロパティー設定のクエリー
- クラスターオプション, クラスタープロパティーとオプションの要約
- クラスター管理
- ACPI の設定, 統合フェンスデバイスで使用する ACPI の設定
- クローン, リソースのクローン
- オプション
- clone-max, クローンリソースの作成と削除
- clone-node-max, クローンリソースの作成と削除
- globally-unique, クローンリソースの作成と削除
- interleave, クローンリソースの作成と削除
- notify, クローンリソースの作成と削除
- ordered, クローンリソースの作成と削除
- クローンオプション, クローンリソースの作成と削除
- グループ, リソースグループ, グループの Stickiness (粘着性)
- グループリソース, リソースグループ
- コロケーション, リソースのコロケーション
- プロパティー
- enabled, リソースの動作
- id, リソースのプロパティー, リソースの動作, 多状態のリソース: 複数モードのリソース
- interval, リソースの動作
- name, リソースの動作
- on-fail, リソースの動作
- provider, リソースのプロパティー
- standard, リソースのプロパティー
- timeout, リソースの動作
- type, リソースのプロパティー
- プロパティーの削除, クラスターのプロパティーの設定と削除
- プロパティーの設定, クラスターのプロパティーの設定と削除
- リソース, リソースのプロパティー, リソースを手作業で移動する
- cleanup, クラスターリソースのクリーンアップ
- オプション
- failure-timeout, リソースのメタオプション
- is-managed, リソースのメタオプション
- migration-threshold, リソースのメタオプション
- multiple-active, リソースのメタオプション
- priority, リソースのメタオプション
- requires, リソースのメタオプション
- resource-stickiness, リソースのメタオプション
- target-role, リソースのメタオプション
- クローン, リソースのクローン
- グループ, リソースグループ
- プロパティー
- id, リソースのプロパティー
- provider, リソースのプロパティー
- standard, リソースのプロパティー
- type, リソースのプロパティー
- 他のリソースに相対的となる場所, リソースのコロケーション
- 制約
- コロケーション, リソースのコロケーション
- ルール, Pacemaker ルール
- 属性式, ノード属性の式
- 日付/時刻の式, 時刻と日付ベースの式
- 日付の詳細, 日付の詳細
- 期間, 期間
- 順序, 順序の制約
- 場所
- ルールで確定, ルールを使用したリソースの場所の確定
- 多状態, 多状態のリソース: 複数モードのリソース
- 有効化, クラスターリソースの有効化と無効化
- 無効化, クラスターリソースの有効化と無効化
- 移動する, リソースを手作業で移動する
- 起動順序, 順序の制約
- リソースのクローン, リソースのクローン
- リソースの場所の確定, ルールを使用したリソースの場所の確定
- リソースオプション, リソースのメタオプション
- ルール, Pacemaker ルール
- boolean-op, Pacemaker ルール
- score, Pacemaker ルール
- score-attribute, Pacemaker ルール
- リソースの場所の確定, ルールを使用したリソースの場所の確定
- ロール, Pacemaker ルール
- ルールで確定, ルールを使用したリソースの場所の確定
- ロール, Pacemaker ルール
- 制約ルール, Pacemaker ルール
- 他のリソースに相対的となる場所, リソースのコロケーション
- 使用率属性, 使用と配置ストラテジー
- 制約
- コロケーション, リソースのコロケーション
- ルール, Pacemaker ルール
- boolean-op, Pacemaker ルール
- score, Pacemaker ルール
- score-attribute, Pacemaker ルール
- ロール, Pacemaker ルール
- 場所
- 属性式, ノード属性の式
- 日付/時刻の式, 時刻と日付ベースの式
- end, 時刻と日付ベースの式
- operation, 時刻と日付ベースの式
- start, 時刻と日付ベースの式
- 日付の詳細, 日付の詳細
- 期間, 期間
- 順序, 順序の制約
- 種類, 順序の制約
- 制約ルール, Pacemaker ルール
- 制約式, ノード属性の式, 時刻と日付ベースの式
- 削除中
- クラスターのプロパティー, クラスターのプロパティーの設定と削除
- 場所
- score, 基本的な場所の制約
- ルールで確定, ルールを使用したリソースの場所の確定
- 場所の制約, 基本的な場所の制約
- 多状態, 多状態のリソース: 複数モードのリソース, 多状態の粘着性 (Stickiness)
- 対称, 順序の制約
- 順序の制約, 順序の制約
- 属性式, ノード属性の式
- 新機能と変更点, 新機能と変更点
- 日付/時刻の式, 時刻と日付ベースの式
- end, 時刻と日付ベースの式
- operation, 時刻と日付ベースの式
- start, 時刻と日付ベースの式
- 日付の詳細, 日付の詳細
- 時間ベースの式, 時刻と日付ベースの式
- 有効化
- リソース, クラスターリソースの有効化と無効化
- 期間, 期間
- 概要
- 新機能と変更点, 新機能と変更点
- 無効化
- リソース, クラスターリソースの有効化と無効化
- 移動する, リソースを手作業で移動する
- リソース, リソースを手作業で移動する
- 種類, 順序の制約
- 順序の制約, 順序の制約
- 統合フェンスデバイス
- ACPI の設定, 統合フェンスデバイスで使用する ACPI の設定
- 設定
- クラスターのプロパティー, クラスターのプロパティーの設定と削除
- 起動順序, 順序の制約
- 配置ストラテジー, 使用と配置ストラテジー
- 順序
- 種類, 順序の制約
- 順序の制約, 順序の制約
- 対称, 順序の制約
- 順序付け, 順序の制約
- , クラスターの作成
B
- batch-limit, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
- boolean-op, Pacemaker ルール
- 制約ルール, Pacemaker ルール
C
- clone-max, クローンリソースの作成と削除
- クローンオプション, クローンリソースの作成と削除
- clone-node-max, クローンリソースの作成と削除
- クローンオプション, クローンリソースの作成と削除
- cluster-delay, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
- cluster-infrastructure, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
- cluster-recheck-interval, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
D
- dampen, 接続状態変更によるリソースの移動
- Ping リソースオプション, 接続状態変更によるリソースの移動
- dc-version, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
E
- enable-acl, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
- enabled, リソースの動作
- アクションプロパティー, リソースの動作
- end, 時刻と日付ベースの式
- 制約式, 時刻と日付ベースの式
F
- failure-timeout, リソースのメタオプション
- リソースオプション, リソースのメタオプション
- fence-reaction, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
G
- globally-unique, クローンリソースの作成と削除
- クローンオプション, クローンリソースの作成と削除
H
- host_list, 接続状態変更によるリソースの移動
- Ping リソースオプション, 接続状態変更によるリソースの移動
- hours, 日付の詳細
- 日付の詳細, 日付の詳細
I
- id, リソースのプロパティー, リソースの動作, 日付の詳細
- Multi-State プロパティー, 多状態のリソース: 複数モードのリソース
- アクションプロパティー, リソースの動作
- リソース, リソースのプロパティー
- 場所の制約, 基本的な場所の制約
- 日付の詳細, 日付の詳細
- interleave, クローンリソースの作成と削除
- クローンオプション, クローンリソースの作成と削除
- interval, リソースの動作
- アクションプロパティー, リソースの動作
- is-managed, リソースのメタオプション
- リソースオプション, リソースのメタオプション
L
- last-lrm-refresh, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
M
- maintenance-mode, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
- master-max, 多状態のリソース: 複数モードのリソース
- Multi-State オプション, 多状態のリソース: 複数モードのリソース
- master-node-max, 多状態のリソース: 複数モードのリソース
- Multi-State オプション, 多状態のリソース: 複数モードのリソース
- migration-limit, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
- migration-threshold, リソースのメタオプション
- リソースオプション, リソースのメタオプション
- monthdays, 日付の詳細
- 日付の詳細, 日付の詳細
- months, 日付の詳細
- 日付の詳細, 日付の詳細
- moon, 日付の詳細
- 日付の詳細, 日付の詳細
- Multi-State
- オプション
- master-max, 多状態のリソース: 複数モードのリソース
- master-node-max, 多状態のリソース: 複数モードのリソース
- プロパティー
- Multi-State オプション, 多状態のリソース: 複数モードのリソース
- Multi-State プロパティー, 多状態のリソース: 複数モードのリソース
- multiple-active, リソースのメタオプション
- リソースオプション, リソースのメタオプション
- multiplier, 接続状態変更によるリソースの移動
- Ping リソースオプション, 接続状態変更によるリソースの移動
N
- name, リソースの動作
- アクションプロパティー, リソースの動作
- no-quorum-policy, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
- notify, クローンリソースの作成と削除
- クローンオプション, クローンリソースの作成と削除
O
- OCF
- 戻りコード, OCF 戻りコード
- on-fail, リソースの動作
- アクションプロパティー, リソースの動作
- operation, ノード属性の式, 時刻と日付ベースの式
- 制約式, ノード属性の式, 時刻と日付ベースの式
- ordered, クローンリソースの作成と削除
- クローンオプション, クローンリソースの作成と削除
P
- pe-error-series-max, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
- pe-input-series-max, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
- pe-warn-series-max, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
- Ping リソース
- オプション
- dampen, 接続状態変更によるリソースの移動
- host_list, 接続状態変更によるリソースの移動
- multiplier, 接続状態変更によるリソースの移動
- Ping リソースオプション, 接続状態変更によるリソースの移動
- placement-strategy, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
- priority, リソースのメタオプション
- リソースオプション, リソースのメタオプション
- provider, リソースのプロパティー
- リソース, リソースのプロパティー
R
- requires, リソースのメタオプション
- resource-stickiness, リソースのメタオプション
- Multi-State, 多状態の粘着性 (Stickiness)
- グループ, グループの Stickiness (粘着性)
- リソースオプション, リソースのメタオプション
S
- score, 基本的な場所の制約, Pacemaker ルール
- 制約ルール, Pacemaker ルール
- 場所の制約, 基本的な場所の制約
- score-attribute, Pacemaker ルール
- 制約ルール, Pacemaker ルール
- shutdown-escalation, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
- standard, リソースのプロパティー
- リソース, リソースのプロパティー
- start, 時刻と日付ベースの式
- 制約式, 時刻と日付ベースの式
- start-failure-is-fatal, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
- status
- display, クラスターの状態表示
- stonith-action, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
- stonith-enabled, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
- stonith-timeout, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
- stop-all-resources, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
- stop-orphan-actions, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
- stop-orphan-resources, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
- symmetric-cluster, クラスタープロパティーとオプションの要約
- クラスターオプション, クラスタープロパティーとオプションの要約
T
- target-role, リソースのメタオプション
- リソースオプション, リソースのメタオプション
- timeout, リソースの動作
- アクションプロパティー, リソースの動作
- type, リソースのプロパティー, ノード属性の式
- リソース, リソースのプロパティー
- 制約式, ノード属性の式