第11章 RHEL システムロールを使用した高可用性クラスターの設定
ha_cluster
システムロールを使用すると、Pacemaker の高可用性クラスターリソースマネージャーを使用する高可用性クラスターを設定し、管理できます。
11.1. ha_cluster
RHEL システムロールの変数
ha_cluster
システムロール Playbook では、クラスターデプロイメントの要件に従って、高可用性クラスターの変数を定義します。
ha_cluster
RHEL システムロールに設定できる変数は次のとおりです。
ha_cluster_enable_repos
-
ha_cluster
RHEL システムロールに必要なパッケージを含むリポジトリーを有効にするブール値フラグ。この変数がデフォルト値のtrue
に設定されている場合、クラスターメンバーとして使用するシステムに RHEL および RHEL High Availability Add-On の有効なサブスクリプションが必要です。サブスクリプションがない場合、システムロールは失敗します。 ha_cluster_enable_repos_resilient_storage
-
(RHEL 9.4 以降)
dlm
やgfs2
などの耐障害性ストレージパッケージを含むリポジトリーを有効にするブールフラグ。このオプションを有効にするには、ha_cluster_enable_repos
をtrue
に設定する必要があります。この変数のデフォルト値はfalse
です。 ha_cluster_manage_firewall
(RHEL 9.2 以降)
ha_cluster
RHEL システムロールがファイアウォールを管理するかどうかを決定するブール値フラグ。ha_cluster_manage_firewall
がtrue
に設定されている場合、ファイアウォールの高可用性サービスとfence-virt
ポートが有効になります。ha_cluster_manage_firewall
がfalse
に設定されている場合、ha_cluster
RHEL システムロールはファイアウォールを管理しません。システムがfirewalld
サービスを実行している場合は、Playbook でパラメーターをtrue
に設定する必要があります。ha_cluster_manage_firewall
パラメーターを使用してポートを追加することはできますが、このパラメーターを使用してポートを削除することはできません。ポートを削除するには、firewall
システムロールを直接使用します。RHEL 8.8 以降、ファイアウォールはデフォルトでは設定されなくなりました。これは、ファイアウォールが設定されるのは、
ha_cluster_manage_firewall
がtrue
に設定されている場合のみであるためです。ha_cluster_manage_selinux
(RHEL 9.2 以降)
ha_cluster
RHEL システムロールがselinux
RHEL システムロールを使用してファイアウォール高可用性サービスに属するポートを管理するかどうかを決定するブール値フラグ。ha_cluster_manage_selinux
がtrue
に設定されている場合、ファイアウォール高可用性サービスに属するポートは、SELinux ポートタイプcluster_port_t
に関連付けられます。ha_cluster_manage_selinux
がfalse
に設定されている場合、ha_cluster
RHEL システムロールは SELinux を管理しません。システムが
selinux
サービスを実行している場合は、Playbook でこのパラメーターをtrue
に設定する必要があります。ファイアウォール設定は、SELinux を管理するための前提条件です。ファイアウォールがインストールされていない場合、SELinux ポリシーの管理はスキップされます。ha_cluster_manage_selinux
パラメーターを使用してポリシーを追加することはできますが、このパラメーターを使用してポリシーを削除することはできません。ポリシーを削除するには、selinux
RHEL システムロールを直接使用します。ha_cluster_cluster_present
true
に設定すると、ロールに渡された変数に従って HA クラスターがホスト上で設定されることを決定するブール型フラグ。Playbook に指定されておらず、ロールでサポートされていないクラスター設定は失われます。ha_cluster_cluster_present
をfalse
に設定すると、すべての HA クラスター設定がターゲットホストから削除されます。この変数のデフォルト値は
true
です。以下の Playbook の例では、
node1
およびnode2
のすべてのクラスター設定を削除します。- hosts: node1 node2 vars: ha_cluster_cluster_present: false roles: - rhel-system-roles.ha_cluster
ha_cluster_start_on_boot
-
起動時にクラスターサービスが起動するように設定されるかどうかを決定するブール値フラグ。この変数のデフォルト値は
true
です。 ha_cluster_fence_agent_packages
-
インストールするフェンスエージェントパッケージのリストこの変数のデフォルト値は
fence-agents-all
,fence-virt
です。 ha_cluster_extra_packages
インストールする追加パッケージのリストこの変数のデフォルト値はパッケージではありません。
この変数は、ロールによって自動的にインストールされていない追加パッケージをインストールするために使用できます (例: カスタムリソースエージェント)。
フェンスエージェントをこのリストのメンバーとして追加できます。ただし、
ha_cluster_fence_agent_packages
は、フェンスエージェントの指定に使用する推奨されるロール変数であるため、デフォルト値が上書きされます。ha_cluster_hacluster_password
-
hacluster
ユーザーのパスワードを指定する文字列の値。hacluster
ユーザーには、クラスターへのフルアクセス権が付与されます。機密データを保護するには、Encrypting content with Ansible Vault で説明されているように、パスワードを vault で暗号化します。デフォルトのパスワード値がないため、この変数を指定する必要があります。 ha_cluster_hacluster_qdevice_password
-
(RHEL 8.9 以降) クォーラムデバイスの
hacluster
ユーザーのパスワードを指定する文字列の値。このパラメーターが必要になるのは、ha_cluster_quorum
パラメーターがタイプnet
のクォーラムデバイスを使用するように設定されており、クォーラムデバイス上のhacluster
ユーザーのパスワードがha_cluster_hacluster_password
パラメーターで指定されたhacluster
ユーザーのパスワードと異なる場合のみです。hacluster
ユーザーには、クラスターへのフルアクセス権が付与されます。機密データを保護するには、Encrypting content with Ansible Vault で説明されているように、パスワードを vault で暗号化します。このパスワードにデフォルト値はありません。 ha_cluster_corosync_key_src
Corosync
authkey
ファイルへのパス。これは、Corosync 通信の認証および暗号鍵です。各クラスターに一意のauthkey
値を指定することが強く推奨されます。キーは、ランダムなデータの 256 バイトでなければなりません。この変数の鍵を指定する場合は、Ansible Vault を使用したコンテンツの暗号化 で説明されているように、鍵を vault 暗号化することが推奨されます。
鍵が指定されていない場合は、ノードにすでに存在するキーが使用されます。ノードに同じ鍵がない場合、あるノードの鍵が他のノードに分散され、すべてのノードが同じキーを持つようにします。ノードに鍵がない場合は、新しい鍵が生成され、ノードに分散されます。
この変数が設定されている場合は、このキーで
ha_cluster_regenerate_keys
が無視されます。この変数のデフォルト値は null です。
ha_cluster_pacemaker_key_src
Pacemaker の
authkey
ファイルへのパスです。これは、Pacemaker 通信の認証および暗号鍵です。各クラスターに一意のauthkey
値を指定することが強く推奨されます。キーは、ランダムなデータの 256 バイトでなければなりません。この変数の鍵を指定する場合は、Ansible Vault を使用したコンテンツの暗号化 で説明されているように、鍵を vault 暗号化することが推奨されます。
鍵が指定されていない場合は、ノードにすでに存在するキーが使用されます。ノードに同じ鍵がない場合、あるノードの鍵が他のノードに分散され、すべてのノードが同じキーを持つようにします。ノードに鍵がない場合は、新しい鍵が生成され、ノードに分散されます。
この変数が設定されている場合は、このキーで
ha_cluster_regenerate_keys
が無視されます。この変数のデフォルト値は null です。
ha_cluster_fence_virt_key_src
fence-virt
またはfence-xvm
の事前共有鍵ファイルへのパス。これは、fence-virt
またはfence-xvm
フェンスエージェントの認証キーの場所になります。この変数の鍵を指定する場合は、Ansible Vault を使用したコンテンツの暗号化 で説明されているように、鍵を vault 暗号化することが推奨されます。
鍵が指定されていない場合は、ノードにすでに存在するキーが使用されます。ノードに同じ鍵がない場合、あるノードの鍵が他のノードに分散され、すべてのノードが同じキーを持つようにします。ノードに鍵がない場合は、新しい鍵が生成され、ノードに分散されます。この方法で
ha_cluster
RHEL システムロールが新しい鍵を生成する場合は、鍵をノードのハイパーバイザーにコピーして、フェンシングが機能するようにする必要があります。この変数が設定されている場合は、このキーで
ha_cluster_regenerate_keys
が無視されます。この変数のデフォルト値は null です。
ha_cluster_pcsd_public_key_srcr
、ha_cluster_pcsd_private_key_src
pcsd
TLS 証明書および秘密鍵へのパス。これが指定されていない場合は、ノード上にすでに証明書キーのペアが使用されます。証明書キーペアが存在しない場合は、無作為に新しいキーが生成されます。この変数に秘密鍵の値を指定した場合は、Ansible Vault を使用したコンテンツの暗号化 で説明されているように、鍵を暗号化することが推奨されます。
これらの変数が設定されている場合は、この証明書と鍵のペアで
ha_cluster_regenerate_keys
は無視されます。これらの変数のデフォルト値は null です。
ha_cluster_pcsd_certificates
(RHEL 9.2 以降)
certificate
RHEL システムロールを使用してpcsd
秘密鍵と証明書を作成します。システムに
pcsd
秘密鍵と証明書が設定されていない場合は、次の 2 つの方法のいずれかで作成できます。-
ha_cluster_pcsd_certificates
変数を設定します。ha_cluster_pcsd_certificates
変数を設定すると、certificate
RHEL システムロールが内部的に使用され、定義どおりにpcsd
の秘密鍵と証明書が作成されます。 -
ha_cluster_pcsd_public_key_src
、ha_cluster_pcsd_private_key_src
、またはha_cluster_pcsd_certificates
変数を設定しないでください。これらの変数をいずれも設定しなかった場合、ha_cluster
RHEL システムロールがpcsd
自体を使用してpcsd
証明書を作成します。ha_cluster_pcsd_certificates
の値は、certificate
RHEL システムロールで指定された変数certificate_requests
の値に設定されます。certificate RHEL システムロールの詳細は、RHEL システムロールを使用した証明書の要求 を参照してください。
-
ha_cluster_pcsd_certificate
変数の使用には、次の運用上の考慮事項が適用されます。-
IPA を使用しており、システムを IPA ドメインに参加させていない限り、
certificate
RHEL システムロールによって自己署名証明書が作成されます。この場合、RHEL システムロールのコンテキスト外で信頼設定を明示的に設定する必要があります。システムロールは、信頼設定をサポートしていません。 -
ha_cluster_pcsd_certificates
変数を設定する場合は、ha_cluster_pcsd_public_key_src
変数とha_cluster_pcsd_private_key_src
変数を設定しないでください。 -
ha_cluster_pcsd_certificates
変数を設定すると、この証明書とキーのペアではha_cluster_regenerate_keys
が無視されます。
-
IPA を使用しており、システムを IPA ドメインに参加させていない限り、
この変数のデフォルト値は
[]
です。高可用性クラスターで TLS 証明書とキーファイルを作成する
ha_cluster
RHEL システムロール Playbook の例については、高可用性クラスターの pcsd TLS 証明書とキーファイルの作成 を参照してください。ha_cluster_regenerate_keys
-
true
に設定すると、事前共有キーと TLS 証明書が再生成されることを決定するブール型フラグ。キーおよび証明書が再生成されるタイミングの詳細は、ha_cluster_corosync_key_src
、ha_cluster_pacemaker_key_src
、ha_cluster_fence_virt_key_src
、ha_cluster_pcsd_public_key_src
、およびha_cluster_pcsd_private_key_src
変数の説明を参照してください。 -
この変数のデフォルト値は
false
です。 ha_cluster_pcs_permission_list
pcsd
を使用してクラスターを管理するパーミッションを設定します。この変数を使用して設定するアイテムは以下のとおりです。-
type
-user
またはgroup
-
name
- ユーザーまたはグループの名前 allow_list
- 指定されたユーザーまたはグループの許可されるアクション:-
read
- クラスターのステータスおよび設定の表示 -
write
- パーミッションおよび ACL を除くクラスター設定の変更 -
grant
- クラスターパーミッションおよび ACL の変更 -
full
- ノードの追加および削除、キーおよび証明書へのアクセスなど、クラスターへの無制限アクセス
-
-
ha_cluster_pcs_permission_list
変数の構造とデフォルト値は以下のとおりです。ha_cluster_pcs_permission_list: - type: group name: hacluster allow_list: - grant - read - write
ha_cluster_cluster_name
-
クラスターの名前。これは、デフォルトが
my-cluster
の文字列値です。 ha_cluster_transport
(RHEL 8.7 以降) クラスター転送方法を設定します。この変数を使用して設定するアイテムは以下のとおりです。
-
type
(オプション) - トランスポートタイプ:knet
、udp
、またはudpu
。udp
およびudpu
トランスポートタイプは、1 つのリンクのみをサポートします。udp
とudpu
の暗号化は常に無効になっています。指定しない場合、デフォルトでknet
になります。 -
options
(オプション) - トランスポートオプションを含む名前と値のディクショナリーのリスト。 -
links
(オプション) - 名前と値のディクショナリーのリスト。名前値ディクショナリーの各リストには、1 つの Corosync リンクのオプションが含まれています。リンクごとにlinknumber
値を設定することを推奨します。それ以外の場合、ディクショナリーの最初のリストはデフォルトで最初のリンクに割り当てられ、2 番目のリストは 2 番目のリンクに割り当てられます。 -
compression
(オプション) - トランスポート圧縮を設定する名前と値のディクショナリーのリスト。knet
トランスポートタイプでのみサポートされます。 -
crypto
(オプション) - トランスポートの暗号化を設定する名前と値のディクショナリーのリスト。デフォルトでは、暗号化は有効になっています。knet
トランスポートタイプでのみサポートされます。
-
許可されているオプションのリストについては、
pcs -h cluster setup
のヘルプページ、またはpcs
(8) man ページのcluster
セクションにあるsetup
の説明を参照してください。詳細な説明については、corosync.conf
(5) の man ページを参照してください。ha_cluster_transport
変数の構造は次のとおりです。ha_cluster_transport: type: knet options: - name: option1_name value: option1_value - name: option2_name value: option2_value links: - - name: option1_name value: option1_value - name: option2_name value: option2_value - - name: option1_name value: option1_value - name: option2_name value: option2_value compression: - name: option1_name value: option1_value - name: option2_name value: option2_value crypto: - name: option1_name value: option1_value - name: option2_name value: option2_value
トランスポート方式を設定する
ha_cluster
RHEL システムロール Playbook の例については、高可用性クラスターでの Corosync 値の設定 を参照してください。ha_cluster_totem
(RHEL 8.7 以降) Corosync トーテムを設定します。許可されているオプションのリストについては、
pcs -h cluster setup
のヘルプページ、またはpcs
(8) man ページのcluster
セクションにあるsetup
の説明を参照してください。詳細な説明については、corosync.conf
(5) の man ページを参照してください。ha_cluster_totem
変数の構造は次のとおりです。ha_cluster_totem: options: - name: option1_name value: option1_value - name: option2_name value: option2_value
Corosync トーテムを設定する
ha_cluster
RHEL システムロール Playbook の例については、高可用性クラスターでの Corosync 値の設定 を参照してください。ha_cluster_quorum
(RHEL 8.7 以降) クラスタークォーラムを設定します。クラスタークォーラムには、次の項目を設定できます。
-
options
(オプション) - クォーラムを設定する名前と値のディクショナリーのリスト。許可されるオプションは、auto_tie_breaker
、last_man_standing
、last_man_standing_window
、およびwait_for_all
です。クォーラムオプションの詳細は、votequorum
(5) の man ページを参照してください。 device
(オプション) - (RHEL 8.8 以降) クォーラムデバイスを使用するようにクラスターを設定します。デフォルトでは、クォーラムデバイスは使用されません。-
model
(必須) - クォーラムデバイスモデルを指定します。net
のみがサポートされています。 model_options
(オプション) - 指定されたクォーラムデバイスモデルを設定する名前と値のディクショナリーのリスト。モデルnet
の場合、host
およびalgorithm
オプションを指定する必要があります。pcs-address
オプションを使用して、qnetd
ホストに接続するためのカスタムpcsd
アドレスとポートを設定します。このオプションを指定しない場合、ロールはhost
上のデフォルトのpcsd
ポートに接続します。-
generic_options
(オプション) - モデル固有ではないクォーラムデバイスオプションを設定する名前と値のディクショナリーのリスト。 heuristics_options
(オプション) - クォーラムデバイスのヒューリスティックを設定する名前と値のディクショナリーのリスト。クォーラムデバイスオプションの詳細は、
corosync-qdevice
(8) の man ページを参照してください。一般的なオプションはsync_timeout
とtimeout
です。モデルnet
オプションについては、quorum.device.net
セクションを参照してください。ヒューリスティックオプションについては、quorum.device.heuristics
セクションを参照してください。クォーラムデバイスの TLS 証明書を再生成するには、
ha_cluster_regenerate_keys
変数をtrue
に設定します。
-
-
ha_cluster_quorum
変数の構造は次のとおりです。ha_cluster_quorum: options: - name: option1_name value: option1_value - name: option2_name value: option2_value device: model: string model_options: - name: option1_name value: option1_value - name: option2_name value: option2_value generic_options: - name: option1_name value: option1_value - name: option2_name value: option2_value heuristics_options: - name: option1_name value: option1_value - name: option2_name value: option2_value
クラスタークォーラムを設定する
ha_cluster
RHEL システムロール Playbook の例については、高可用性クラスターでの Corosync 値の設定 を参照してください。クォーラムデバイスを使用してクラスターを設定する ha_cluster RHEL システムロール Playbook の例については、クォーラムデバイスを使用した高可用性クラスターの設定 を参照してください。ha_cluster_sbd_enabled
(RHEL 8.7 以降) クラスターが SBD ノードフェンシングメカニズムを使用できるかどうかを決定するブールフラグ。この変数のデフォルト値は
false
です。SBD を有効にする
ha_cluster
システムロール Playbook の例については、SBD ノードフェンシングを使用した高可用性クラスターの設定 を参照してください。ha_cluster_sbd_options
(RHEL 8.7 以降) SBD オプションを指定する名前と値の辞書のリスト。これらのオプションの詳細は、
sbd
(8) man ページのConfiguration via environment
セクションを参照してください。サポートされているオプションは次のとおりです。
-
delay-start
- デフォルトはfalse
。SBD_DELAY_START
としてドキュメントに記載されています。 -
startmode
- デフォルトはalways
。SBD_START_MODE
としてドキュメントに記載されています。 -
timeout-action
- デフォルトはflush,reboot
。SBD_TIMEOUT_ACTION
としてドキュメントに記載されています。 -
watchdog-timeout
- デフォルトは5
。SBD_WATCHDOG_TIMEOUT
としてドキュメントに記載されています。
-
SBD オプションを設定する
ha_cluster
システムロール Playbook の例については、SBD ノードフェンシングを使用した高可用性クラスターの設定 を参照してください。SBD を使用する場合、オプションで、インベントリー内のノードごとにウォッチドッグと SBD デバイスを設定できます。インベントリーファイルでウォッチドッグおよび SBD デバイスを設定する方法の詳細は、ha_cluster システムロールのインベントリーの指定 を参照してください。
ha_cluster_cluster_properties
Pacemaker クラスター全体の設定のクラスタープロパティーのセットのリスト。クラスタープロパティーのセットは 1 つだけサポートされます。
クラスタープロパティーのセットの構造は次のとおりです。
ha_cluster_cluster_properties: - attrs: - name: property1_name value: property1_value - name: property2_name value: property2_value
デフォルトでは、プロパティーは設定されません。
次のサンプル Playbook は、
node1
とnode2
で構成されるクラスターを設定し、stonith-enabled
およびno-quorum-policy
クラスタープロパティーを設定します。- hosts: node1 node2 vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: password ha_cluster_cluster_properties: - attrs: - name: stonith-enabled value: 'true' - name: no-quorum-policy value: stop roles: - rhel-system-roles.ha_cluster
ha_cluster_node_options
(RHEL 9.4 以降) この変数は、クラスターノードごとに異なる設定を定義します。指定されたノードのオプションを設定しますが、どのノードがクラスターを形成するかは指定しません。インベントリーまたは Playbook の
hosts
パラメーターを使用して、クラスターを設定するノードを指定します。この変数を使用して設定するアイテムは以下のとおりです。
-
node_name
(必須) - Pacemaker ノード属性を定義するノードの名前。ノードに定義された名前と一致する必要があります。 -
attributes
(任意) - ノードの Pacemaker ノード属性セットのリスト。現在、1 つのセットのみがサポートされています。最初のセットが使用され、残りは無視されます。
-
ha_cluster_node_options
変数の構造は次のとおりです。ha_cluster_node_options: - node_name: node1 attributes: - attrs: - name: attribute1 value: value1_node1 - name: attribute2 value: value2_node1 - node_name: node2 attributes: - attrs: - name: attribute1 value: value1_node2 - name: attribute2 value: value2_node2
デフォルトでは、ノードオプションは定義されていません。
ノードオプション設定を含む
ha_cluster
RHEL システムロール Playbook の例は、ノード属性を使用した高可用性クラスターの設定 を参照してください。ha_cluster_resource_primitives
この変数は、フェンシングリソースを含む、RHEL システムロールによって設定される Pacemaker リソースを定義します。リソースごとに次の項目を設定できます。
-
id
(必須) - リソースの ID。 -
agent
(必須) - リソースまたはフェンスエージェントの名前 (例:ocf:pacemaker:Dummy
またはstonith:fence_xvm
)。STONITH エージェントには、stonith:
を指定する必要があります。リソースエージェントの場合は、ocf:pacemaker:Dummy
ではなく、Dummy
などの短縮名を使用することができます。ただし、同じ名前の複数のエージェントがインストールされていると、使用するエージェントを決定できないため、ロールは失敗します。そのため、リソースエージェントを指定する場合はフルネームを使用することが推奨されます。 -
instance_attrs
(オプション): リソースのインスタンス属性のセットのリスト。現在、1 つのセットのみがサポートされています。属性の名前と値、必須かどうか、およびリソースまたはフェンスエージェントによって異なります。 -
meta_attrs
(オプション): リソースのメタ属性のセットのリスト。現在、1 つのセットのみがサポートされています。 -
copy_operations_from_agent
(オプション) - (RHEL 8.9 以降) リソースエージェントは通常、特定のエージェント向けに最適化された、interval
やtimeout
などのリソース操作のデフォルト設定を定義します。この変数がtrue
に設定されている場合、それらの設定がリソース設定にコピーされます。そうでない場合、クラスター全体のデフォルトがリソースに適用されます。ha_cluster_resource_operation_defaults
ロール変数を使用してリソースのリソース操作のデフォルトも定義する場合は、これをfalse
に設定できます。この変数のデフォルト値はtrue
です。 operations
(任意): リソースの操作のリスト。-
action
(必須): pacemaker と、リソースまたはフェンスエージェントで定義されている操作アクション。 -
attrs
(必須): 少なくとも 1 つのオプションを指定する必要があります。
-
-
ha_cluster
RHEL システムロールで設定するリソース定義の構造は次のとおりです。- id: resource-id agent: resource-agent instance_attrs: - attrs: - name: attribute1_name value: attribute1_value - name: attribute2_name value: attribute2_value meta_attrs: - attrs: - name: meta_attribute1_name value: meta_attribute1_value - name: meta_attribute2_name value: meta_attribute2_value copy_operations_from_agent: bool operations: - action: operation1-action attrs: - name: operation1_attribute1_name value: operation1_attribute1_value - name: operation1_attribute2_name value: operation1_attribute2_value - action: operation2-action attrs: - name: operation2_attribute1_name value: operation2_attribute1_value - name: operation2_attribute2_name value: operation2_attribute2_value
デフォルトでは、リソースは定義されません。
リソース設定を含む
ha_cluster
RHEL システムロール Playbook の例は、フェンシングおよびリソースを使用した高可用性クラスターの設定 を参照してください。ha_cluster_resource_groups
この変数は、システムロールによって設定される Pacemaker リソースグループを定義します。リソースグループごとに次の項目を設定できます。
-
id
(必須): グループの ID。 -
resources
(必須): グループのリソースのリスト。各リソースは ID によって参照され、リソースはha_cluster_resource_primitives
変数に定義する必要があります。1 つ以上のリソースをリスト表示する必要があります。 -
meta_attrs
(オプション): グループのメタ属性のセットのリスト。現在、1 つのセットのみがサポートされています。
-
ha_cluster
RHEL システムロールで設定するリソースグループ定義の構造は次のとおりです。ha_cluster_resource_groups: - id: group-id resource_ids: - resource1-id - resource2-id meta_attrs: - attrs: - name: group_meta_attribute1_name value: group_meta_attribute1_value - name: group_meta_attribute2_name value: group_meta_attribute2_value
デフォルトでは、リソースグループが定義されていません。
リソースグループ設定を含む
ha_cluster
RHEL システムロール Playbook の例は、フェンシングおよびリソースを使用した高可用性クラスターの設定 を参照してください。ha_cluster_resource_clones
この変数は、システムロールによって設定された Pacemaker リソースクローンを定義します。リソースクローンに対して次の項目を設定できます。
-
resource_id
(必須): クローンを作成するリソース。リソースはha_cluster_resource_primitives
変数またはha_cluster_resource_groups
変数に定義する必要があります。 -
promotable
(オプション): 作成するリソースクローンが昇格可能なクローンであるかどうかを示します。これは、true
またはfalse
と示されます。 -
id
(任意): クローンのカスタム ID。ID が指定されていない場合は、生成されます。このオプションがクラスターでサポートされない場合は、警告が表示されます。 -
meta_attrs
(任意): クローンのメタ属性のセットのリスト。現在、1 つのセットのみがサポートされています。
-
ha_cluster
RHEL システムロールで設定するリソースクローン定義の構造は次のとおりです。ha_cluster_resource_clones: - resource_id: resource-to-be-cloned promotable: true id: custom-clone-id meta_attrs: - attrs: - name: clone_meta_attribute1_name value: clone_meta_attribute1_value - name: clone_meta_attribute2_name value: clone_meta_attribute2_value
デフォルトでは、リソースのクローンが定義されていません。
リソースクローン設定を含む
ha_cluster
RHEL システムロール Playbook の例は、フェンシングおよびリソースを使用した高可用性クラスターの設定 を参照してください。ha_cluster_resource_defaults
(RHEL 8.9 以降) この変数は、リソースのデフォルトのセットを定義します。複数のデフォルトのセットを定義し、ルールを使用してそれらを特定のエージェントのリソースに適用できます。
ha_cluster_resource_defaults
変数で指定したデフォルトは、独自に定義した値で当該デフォルトをオーバーライドするリソースには適用されません。デフォルトとして指定できるのはメタ属性のみです。
デフォルトセットごとに次の項目を設定できます。
-
id
(オプション) - デフォルトセットの ID。指定しない場合は自動生成されます。 -
rule
(オプション) - いつ、どのリソースにセットを適用するかを定義するpcs
構文を使用して記述されたルール。ルールの指定については、pcs(8)
man ページのresource defaults set create
セクションを参照してください。 -
score
(オプション) - デフォルトセットの重み。 -
attrs
(オプション) - デフォルトとしてリソースに適用されるメタ属性。
-
ha_cluster_resource_defaults
変数の構造は次のとおりです。ha_cluster_resource_defaults: meta_attrs: - id: defaults-set-1-id rule: rule-string score: score-value attrs: - name: meta_attribute1_name value: meta_attribute1_value - name: meta_attribute2_name value: meta_attribute2_value - id: defaults-set-2-id rule: rule-string score: score-value attrs: - name: meta_attribute3_name value: meta_attribute3_value - name: meta_attribute4_name value: meta_attribute4_value
リソースのデフォルトを設定する
ha_cluster
RHEL システムロール Playbook の例については、リソースおよびリソース操作のデフォルトを使用した高可用性クラスターの設定 を参照してください。ha_cluster_resource_operation_defaults
(RHEL 8.9 以降) この変数は、リソース操作のデフォルトのセットを定義します。複数のデフォルトのセットを定義し、ルールを使用してそれらを特定のエージェントのリソースおよび特定のリソース操作に適用できます。
ha_cluster_resource_operation_defaults
変数で指定したデフォルトは、独自に定義した値で当該デフォルトをオーバーライドするリソース操作には適用されません。デフォルトでは、ha_cluster
RHEL システムロールは、リソース操作用の独自の値を定義するようにリソースを設定します。これらのデフォルトをha_cluster_resource_operations_defaults
変数でオーバーライドする方法については、ha_cluster_resource_primitives
のcopy_operations_from_agent
の項目の説明を参照してください。デフォルトとして指定できるのはメタ属性のみです。
ha_cluster_resource_operations_defaults
変数の構造は、ルールの指定方法を除き、ha_cluster_resource_defaults
変数の構造と同じです。セットが適用されるリソース操作を記述するルールの指定については、pcs(8)
man ページのresource op defaults set create
セクションを参照してください。ha_cluster_stonith_levels
(RHEL 9.4 以降) この変数は、フェンシングトポロジーとも呼ばれる STONITH レベルを定義します。フェンシングレベルは、複数のデバイスを使用してノードをフェンスするようにクラスターを設定します。1 つのデバイスに障害が発生した場合に備えて代替デバイスを定義し、ノードが正常にフェンスされたと見なすために複数のデバイスをすべて正常に実行することを要求できます。フェンシングレベルの詳細は、高可用性クラスターの設定と管理 の フェンシングレベルの設定 を参照してください。
フェンシングレベルを定義するときに、次の項目を設定できます。
-
level
(必須) - フェンシングレベルを試行する順序。Pacemaker は、成功するまでレベルを昇順に試します。 -
target
(オプション) - このレベルが適用されるノードの名前。 次の 3 つの選択肢のいずれかを指定する必要があります。
-
target_pattern
- このレベルが適用されるノードの名前に一致する POSIX 拡張正規表現。 -
target_attribute
- このレベルが適用されるノードに設定されているノード属性の名前。 -
target_attribute
およびtarget_value
- このレベルが適用されるノードに設定されているノード属性の名前と値。
-
resouce_ids
(必須) - このレベルで試行する必要があるフェンシングリソースのリスト。デフォルトでは、フェンシングレベルは定義されていません。
-
ha_cluster
RHEL システムロールで設定するフェンシングレベル定義の構造は次のとおりです。ha_cluster_stonith_levels: - level: 1..9 target: node_name target_pattern: node_name_regular_expression target_attribute: node_attribute_name target_value: node_attribute_value resource_ids: - fence_device_1 - fence_device_2 - level: 1..9 target: node_name target_pattern: node_name_regular_expression target_attribute: node_attribute_name target_value: node_attribute_value resource_ids: - fence_device_1 - fence_device_2
フェンシングのデフォルトを設定する
ha_cluster
RHEL システムロール Playbook の例は、フェンシングレベルを使用した高可用性クラスターの設定 を参照してください。ha_cluster_constraints_location
この変数は、リソースの場所の制約を定義します。リソースの場所の制約は、リソースを実行できるノードを示します。複数のリソースに一致する可能性のあるリソース ID またはパターンで指定されたリソースを指定できます。ノード名またはルールでノードを指定できます。
リソースの場所の制約に対して次の項目を設定できます。
-
resource
(必須) - 制約が適用されるリソースの仕様。 -
node
(必須) - リソースが優先または回避する必要があるノードの名前。 -
id
(オプション) - 制約の ID。指定しない場合、自動生成されます。 options
(オプション) - 名前と値のディクショナリーリスト。score
- 制約の重みを設定します。-
正の
score
値は、リソースがノードでの実行を優先することを意味します。 -
負の
score
値は、リソースがノードで実行されないようにする必要があることを意味します。 -
-INFINITY
のscore
値は、リソースがノードで実行されないようにする必要があることを意味します。 -
score
が指定されていない場合、スコア値はデフォルトでINFINITY
になります。
-
正の
-
デフォルトでは、リソースの場所の制約は定義されていません。
リソース ID とノード名を指定するリソースの場所に対する制約の構造は次のとおりです。
ha_cluster_constraints_location: - resource: id: resource-id node: node-name id: constraint-id options: - name: score value: score-value - name: option-name value: option-value
リソースパターンを指定するリソースの場所の制約に対して設定する項目は、リソース ID を指定するリソースの場所の制約に対して設定する項目と同じです。ただし、リソース仕様そのものは除きます。リソース仕様に指定する項目は次のとおりです。
-
pattern
(必須) - POSIX 拡張正規表現リソース ID が照合されます。
-
リソースパターンとノード名を指定するリソースの場所に対する制約の構造は次のとおりです。
ha_cluster_constraints_location: - resource: pattern: resource-pattern node: node-name id: constraint-id options: - name: score value: score-value - name: resource-discovery value: resource-discovery-value
リソース ID とルールを指定するリソースの場所の制約に対して、次の項目を設定できます。
resource
(必須) - 制約が適用されるリソースの仕様。-
id
(必須) - リソース ID。 -
role
(オプション) - 制約が制限されるリソースのロール。Started
、Unpromoted
、Promoted
。
-
-
rule
(必須) -pcs
構文を使用して記述された制約ルール。詳細は、pcs
(8) の man ページでconstraint location
セクションを参照してください。 - 指定するその他の項目は、ルールを指定しないリソース制約と同じ意味を持ちます。
リソース ID とルールを指定するリソースの場所に対する制約の構造は次のとおりです。
ha_cluster_constraints_location: - resource: id: resource-id role: resource-role rule: rule-string id: constraint-id options: - name: score value: score-value - name: resource-discovery value: resource-discovery-value
リソースパターンとルールを指定するリソースの場所の制約に対して設定する項目は、リソース ID とルールを指定するリソースの場所の制約に対して設定する項目と同じです。ただし、リソース仕様そのものは除きます。リソース仕様に指定する項目は次のとおりです。
-
pattern
(必須) - POSIX 拡張正規表現リソース ID が照合されます。
-
リソースパターンとルールを指定するリソースの場所に対する制約の構造は次のとおりです。
ha_cluster_constraints_location: - resource: pattern: resource-pattern role: resource-role rule: rule-string id: constraint-id options: - name: score value: score-value - name: resource-discovery value: resource-discovery-value
リソースに制約のあるクラスターを作成する
ha_cluster
RHEL システムロール Playbook の例は、リソースに制約のある高可用性クラスターの設定 を参照してください。ha_cluster_constraints_colocation
この変数は、リソースコロケーションの制約を定義します。リソースコロケーションの制約は、あるリソースの場所が別のリソースの場所に依存することを示しています。コロケーション制約には、2 つのリソースに対する単純なコロケーション制約と、複数のリソースに対するセットコロケーション制約の 2 種類があります。
単純なリソースコロケーション制約に対して次の項目を設定できます。
resource_follower
(必須) -resource_leader
に関連して配置する必要があるリソース。-
id
(必須) - リソース ID。 -
role
(オプション) - 制約が制限されるリソースのロール。Started
、Unpromoted
、Promoted
。
-
resource_leader
(必須) - クラスターは、最初にこのリソースを配置する場所を決定してから、resource_follower
を配置する場所を決定します。-
id
(必須) - リソース ID。 -
role
(オプション) - 制約が制限されるリソースのロール。Started
、Unpromoted
、Promoted
。
-
-
id
(オプション) - 制約の ID。指定しない場合、自動生成されます。 options
(オプション) - 名前と値のディクショナリーリスト。score
- 制約の重みを設定します。-
正の
score
値は、リソースが同じノードで実行される必要があることを示します。 -
負の
score
値は、リソースが異なるノードで実行される必要があることを示します。 -
+ INFINITY
のscore
値は、リソースが同じノードで実行される必要があることを示します。 -
-INFINITY
のscore
値は、リソースが異なるノードで実行される必要があることを示します。 -
score
が指定されていない場合、スコア値はデフォルトでINFINITY
になります。
-
正の
デフォルトでは、リソースコロケーション制約は定義されていません。
単純なリソースコロケーション制約の構造は次のとおりです。
ha_cluster_constraints_colocation: - resource_follower: id: resource-id1 role: resource-role1 resource_leader: id: resource-id2 role: resource-role2 id: constraint-id options: - name: score value: score-value - name: option-name value: option-value
リソースセットのコロケーション制約に対して次の項目を設定できます。
resource_sets
(必須) - リソースセットのリスト。-
resource_ids
(必須) - セット内のリソースのリスト。 -
options
(オプション) - セット内のリソースが制約によってどのように扱われるかを微調整する名前と値のディクショナリーリスト。
-
-
id
(オプション) - 単純なコロケーション制約の場合と同じ値。 -
options
(オプション) - 単純なコロケーション制約の場合と同じ値。
リソースセットに対するコロケーション制約の構造は次のとおりです。
ha_cluster_constraints_colocation: - resource_sets: - resource_ids: - resource-id1 - resource-id2 options: - name: option-name value: option-value id: constraint-id options: - name: score value: score-value - name: option-name value: option-value
リソースに制約のあるクラスターを作成する
ha_cluster
RHEL システムロール Playbook の例は、リソースに制約のある高可用性クラスターの設定 を参照してください。ha_cluster_constraints_order
この変数は、リソースの順序に対する制約を定義します。リソース順序の制約は、特定のリソースアクションが発生する順序を示します。リソース順序の制約には、2 つのリソースに対する単純な順序制約と、複数のリソースに対するセット順序制約の 2 種類があります。
単純なリソース順序制約に対して次の項目を設定できます。
resource_first
(必須) -resource_then
リソースが依存するリソース。-
id
(必須) - リソース ID。 -
action
(オプション) -resource_then
リソースに対してアクションを開始する前に完了する必要のあるアクション。許可される値:start
、stop
、promote
、demote
。
-
resource_then
(必須) - 依存リソース。-
id
(必須) - リソース ID。 -
action
(オプション) -resource_first
リソースに対するアクションが完了した後にのみリソースが実行できるアクション。許可される値:start
、stop
、promote
、demote
。
-
-
id
(オプション) - 制約の ID。指定しない場合、自動生成されます。 -
options
(オプション) - 名前と値のディクショナリーリスト。
デフォルトでは、リソース順序の制約は定義されていません。
単純なリソース順序の制約の構造は次のとおりです。
ha_cluster_constraints_order: - resource_first: id: resource-id1 action: resource-action1 resource_then: id: resource-id2 action: resource-action2 id: constraint-id options: - name: score value: score-value - name: option-name value: option-value
リソースセットの順序制約に対して次の項目を設定できます。
resource_sets
(必須) - リソースセットのリスト。-
resource_ids
(必須) - セット内のリソースのリスト。 -
options
(オプション) - セット内のリソースが制約によってどのように扱われるかを微調整する名前と値のディクショナリーリスト。
-
-
id
(オプション) - 単純な順序制約の場合と同じ値。 -
options
(オプション) - 単純な順序制約の場合と同じ値。
リソースセットの順序制約の構造は次のとおりです。
ha_cluster_constraints_order: - resource_sets: - resource_ids: - resource-id1 - resource-id2 options: - name: option-name value: option-value id: constraint-id options: - name: score value: score-value - name: option-name value: option-value
リソースに制約のあるクラスターを作成する
ha_cluster
RHEL システムロール Playbook の例は、リソースに制約のある高可用性クラスターの設定 を参照してください。ha_cluster_constraints_ticket
この変数は、リソースチケットの制約を定義します。リソースチケットの制約は、特定のチケットに依存するリソースを示します。リソースチケット制約には、1 つのリソースに対する単純なチケット制約と、複数のリソースに対するチケット順序の制約の 2 種類があります。
単純なリソースチケット制約に対して次の項目を設定できます。
resource
(必須) - 制約が適用されるリソースの仕様。-
id
(必須) - リソース ID。 -
role
(オプション) - 制約が制限されるリソースのロール。Started
、Unpromoted
、Promoted
。
-
-
ticket
(必須) - リソースが依存するチケットの名前。 -
id
(オプション) - 制約の ID。指定しない場合、自動生成されます。 options
(オプション) - 名前と値のディクショナリーリスト。-
loss-policy
(オプション) - チケットが取り消された場合にリソースに対して実行するアクション。
-
デフォルトでは、リソースチケットの制約は定義されていません。
単純なリソースチケット制約の構造は次のとおりです。
ha_cluster_constraints_ticket: - resource: id: resource-id role: resource-role ticket: ticket-name id: constraint-id options: - name: loss-policy value: loss-policy-value - name: option-name value: option-value
リソースセットチケット制約に対して次の項目を設定できます。
resource_sets
(必須) - リソースセットのリスト。-
resource_ids
(必須) - セット内のリソースのリスト。 -
options
(オプション) - セット内のリソースが制約によってどのように扱われるかを微調整する名前と値のディクショナリーリスト。
-
-
ticket
(必須) - 単純なチケット制約の場合と同じ値。 -
id
(オプション) - 単純なチケット制約の場合と同じ値。 -
options
(オプション) - 単純なチケット制約の場合と同じ値。
リソースセットのチケット制約の構造は次のとおりです。
ha_cluster_constraints_ticket: - resource_sets: - resource_ids: - resource-id1 - resource-id2 options: - name: option-name value: option-value ticket: ticket-name id: constraint-id options: - name: option-name value: option-value
リソースに制約のあるクラスターを作成する
ha_cluster
RHEL システムロール Playbook の例は、リソースに制約のある高可用性クラスターの設定 を参照してください。ha_cluster_qnetd
(RHEL 8.8 以降) この変数は、クラスターの外部クォーラムデバイスとして機能できる
qnetd
ホストを設定します。qnetd
ホストに対して次の項目を設定できます。-
present
(オプション) -true
の場合、ホスト上にqnetd
インスタンスを設定します。false
の場合、ホストからqnetd
設定を削除します。デフォルト値はfalse
です。これをtrue
に設定する場合は、ha_cluster_cluster_present
をfalse
に設定する必要があります。 -
start_on_boot
(オプション) - ブート時にqnetd
インスタンスを自動的に開始するかどうかを設定します。デフォルト値はtrue
です。 -
regenerate_keys
(オプション) -qnetd
TLS 証明書を再生成するには、この変数をtrue
に設定します。証明書を再生成する場合は、各クラスターのロールを再実行してqnetd
ホストに再度接続するか、手動でpcs
を実行する必要があります。
-
フェンシングにより
qnetd
操作が中断されるため、クラスターノード上でqnetd
を実行することはできません。クォーラムデバイスを使用してクラスターを設定する
ha_cluster
RHEL システムロール Playbook の例については、クォーラムデバイスを使用したクラスターの設定 を参照してください。
関連情報
-
/usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md
ファイル -
/usr/share/doc/rhel-system-roles/ha_cluster/
ディレクトリー