第11章 RHEL システムロールを使用した高可用性クラスターの設定

(RHEL 9.2 以降) ha_cluster システムロールがファイアウォールを管理するかどうかを決定するブール値フラグ。ha_cluster_manage_firewall が true に設定されている場合、ファイアウォールの高可用性サービスと fence-virt ポートが有効になります。ha_cluster_manage_firewall が false に設定されている場合、ha_cluster システムロールはファイアウォールを管理しません。システムが firewalld サービスを実行している場合は、Playbook でパラメーターを true に設定する必要があります。

ha_cluster_manage_firewall パラメーターを使用してポートを追加することはできますが、このパラメーターを使用してポートを削除することはできません。ポートを削除するには、firewall システムロールを直接使用します。

RHEL 8.8 以降、ファイアウォールはデフォルトでは設定されなくなりました。これは、ファイアウォールが設定されるのは、ha_cluster_manage_firewall が true に設定されている場合のみであるためです。

(RHEL 9.2 以降) ha_cluster システムロールが selinux システムロールを使用してファイアウォール高可用性サービスに属するポートを管理するかどうかを決定するブール値フラグ。ha_cluster_manage_selinux が true に設定されている場合、ファイアウォール高可用性サービスに属するポートは、SELinux ポートタイプ cluster_port_t に関連付けられます。ha_cluster_manage_selinux が false に設定されている場合、ha_cluster システムロールは SELinux を管理しません。

システムが selinux サービスを実行している場合は、Playbook でこのパラメーターを true に設定する必要があります。ファイアウォール設定は、SELinux を管理するための前提条件です。ファイアウォールがインストールされていない場合、SELinux ポリシーの管理はスキップされます。

ha_cluster_manage_selinux パラメーターを使用してポリシーを追加することはできますが、このパラメーターを使用してポリシーを削除することはできません。ポリシーを削除するには、selinux システムロールを直接使用します。

true に設定すると、ロールに渡された変数に従って HA クラスターがホスト上で設定されることを決定するブール型フラグ。ロールで指定されておらず、ロールによってサポートされないクラスター設定は失われます。

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_fence_agent_packages は、フェンスエージェントの指定に使用する推奨されるロール変数であるため、デフォルト値が上書きされます。

Corosync authkey ファイルへのパス。これは、Corosync 通信の認証および暗号鍵です。各クラスターに一意の authkey 値を指定することが強く推奨されます。キーは、ランダムなデータの 256 バイトでなければなりません。

この変数の鍵を指定する場合は、Ansible Vault を使用したコンテンツの暗号化 で説明されているように、鍵を vault 暗号化することが推奨されます。

鍵が指定されていない場合は、ノードにすでに存在するキーが使用されます。ノードに同じ鍵がない場合、あるノードの鍵が他のノードに分散され、すべてのノードが同じキーを持つようにします。ノードに鍵がない場合は、新しい鍵が生成され、ノードに分散されます。

この変数が設定されている場合は、このキーで ha_cluster_regenerate_keys が無視されます。

この変数のデフォルト値は null です。

Pacemaker の authkey ファイルへのパスです。これは、Pacemaker 通信の認証および暗号鍵です。各クラスターに一意の authkey 値を指定することが強く推奨されます。キーは、ランダムなデータの 256 バイトでなければなりません。

この変数の鍵を指定する場合は、Ansible Vault を使用したコンテンツの暗号化 で説明されているように、鍵を vault 暗号化することが推奨されます。

鍵が指定されていない場合は、ノードにすでに存在するキーが使用されます。ノードに同じ鍵がない場合、あるノードの鍵が他のノードに分散され、すべてのノードが同じキーを持つようにします。ノードに鍵がない場合は、新しい鍵が生成され、ノードに分散されます。

この変数が設定されている場合は、このキーで ha_cluster_regenerate_keys が無視されます。

この変数のデフォルト値は null です。

fence-virt または fence-xvm の事前共有鍵ファイルへのパス。これは、fence-virt または fence-xvm フェンスエージェントの認証キーの場所になります。

この変数の鍵を指定する場合は、Ansible Vault を使用したコンテンツの暗号化 で説明されているように、鍵を vault 暗号化することが推奨されます。

鍵が指定されていない場合は、ノードにすでに存在するキーが使用されます。ノードに同じ鍵がない場合、あるノードの鍵が他のノードに分散され、すべてのノードが同じキーを持つようにします。ノードに鍵がない場合は、新しい鍵が生成され、ノードに分散されます。この方法で ha_cluster システムロールが新しいキーを生成する場合は、鍵をノードのハイパーバイザーにコピーして、フェンシングが機能するようにする必要があります。

この変数が設定されている場合は、このキーで ha_cluster_regenerate_keys が無視されます。

この変数のデフォルト値は null です。

pcsd TLS 証明書および秘密鍵へのパス。これが指定されていない場合は、ノード上にすでに証明書キーのペアが使用されます。証明書キーペアが存在しない場合は、無作為に新しいキーが生成されます。

この変数に秘密鍵の値を指定した場合は、Ansible Vault を使用したコンテンツの暗号化 で説明されているように、鍵を暗号化することが推奨されます。

これらの変数が設定されている場合は、この証明書と鍵のペアで ha_cluster_regenerate_keys は無視されます。

これらの変数のデフォルト値は null です。

(RHEL 9.2 以降) certificate システムロールを使用して pcsd 秘密鍵と証明書を作成します。

システムに pcsd 秘密鍵と証明書が設定されていない場合は、次の 2 つの方法のいずれかで作成できます。

ha_cluster_pcsd_certificate 変数の使用には、次の運用上の考慮事項が適用されます。

この変数のデフォルト値は [] です。

高可用性クラスターで TLS 証明書とキーファイルを作成する ha_cluster システムロール Playbook の例については、高可用性クラスターの pcsd TLS 証明書とキーファイルの作成 を参照してください。

pcsd を使用してクラスターを管理するパーミッションを設定します。この変数を使用して設定するアイテムは以下のとおりです。

ha_cluster_pcs_permission_list 変数の構造とデフォルト値は以下のとおりです。

ha_cluster_pcs_permission_list:
  - type: group
    name: hacluster
    allow_list:
      - grant
      - read
      - write

(RHEL 8.7 以降) クラスター転送方法を設定します。この変数を使用して設定するアイテムは以下のとおりです。

許可されているオプションのリストについては、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 システムロール Playbook の例については、高可用性クラスターでの Corosync 値の設定 を参照してください。

(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 システムロール Playbook の例については､高可用性クラスターでの Corosync 値の設定 を参照してください。

(RHEL 8.7 以降) クラスタークォーラムを設定します。クラスタークォーラムには、次の項目を設定できます。

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 システムロール Playbook の例については､高可用性クラスターでの Corosync 値の設定 を参照してください。クォーラムデバイスを使用してクラスターを設定する ha_cluster システムロール Playbook の例については、クォーラムデバイスを使用した高可用性クラスターの設定 を参照してください。

(RHEL 8.7 以降) クラスターが SBD ノードフェンシングメカニズムを使用できるかどうかを決定するブールフラグ。この変数のデフォルト値は false です。

SBD を有効にする ha_cluster システムロール Playbook の例については、SBD ノードフェンシングを使用した高可用性クラスターの設定 を参照してください。

(RHEL 8.7 以降) SBD オプションを指定する名前と値の辞書のリスト。サポートされているオプションは次のとおりです。

SBD オプションを設定する ha_cluster システムロール Playbook の例については、SBD ノードフェンシングを使用した高可用性クラスターの設定を 参照してください。

SBD を使用する場合、オプションで、インベントリー内のノードごとにウォッチドッグと SBD デバイスを設定できます。インベントリーファイルでウォッチドッグおよび SBD デバイスを設定する方法の詳細は、ha_cluster システムロールのインベントリーの指定 を参照してください。

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

(RHEL 8.10 以降) この変数は、クラスターノードごとに異なるさまざまな設定を定義します。指定されたノードのオプションを設定しますが、どのノードがクラスターを形成するかは指定しません。インベントリーまたは Playbook の hosts パラメーターを使用して、クラスターを設定するノードを指定します。

この変数を使用して設定するアイテムは以下のとおりです。

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 システムロール Playbook の例は、ノード属性を使用した高可用性クラスターの設定 を参照してください。

この変数は、フェンシングリソースを含む、システムロールによって設定される Pacemaker リソースを定義します。リソースごとに次の項目を設定できます。

ha_cluster システムロールで設定するリソース定義の構造は次のとおりです。

  - 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 システムロール Playbook の例は、フェンシングおよびリソースを使用した高可用性クラスターの設定 を参照してください。

この変数は、システムロールによって設定される Pacemaker リソースグループを定義します。リソースグループごとに次の項目を設定できます。

ha_cluster システムロールで設定するリソースグループ定義の構造は次のとおりです。

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 システムロール Playbook の例は、フェンシングおよびリソースを使用した高可用性クラスターの設定 を参照してください。

この変数は、システムロールによって設定された Pacemaker リソースクローンを定義します。リソースクローンに対して次の項目を設定できます。

ha_cluster システムロールで設定するリソースクローン定義の構造は次のとおりです。

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 システムロール Playbook の例は、フェンシングおよびリソースを使用した高可用性クラスターの設定 を参照してください。

(RHEL 8.9 以降) この変数は、リソースのデフォルトのセットを定義します。複数のデフォルトのセットを定義し、ルールを使用してそれらを特定のエージェントのリソースに適用できます。ha_cluster_resource_defaults 変数で指定したデフォルトは、独自に定義した値で当該デフォルトをオーバーライドするリソースには適用されません。

デフォルトとして指定できるのはメタ属性のみです。

デフォルトセットごとに次の項目を設定できます。

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 システムロール Playbook の例については、リソースおよびリソース操作のデフォルトを使用した高可用性クラスターの設定 を参照してください。

(RHEL 8.9 以降) この変数は、リソース操作のデフォルトのセットを定義します。複数のデフォルトのセットを定義し、ルールを使用してそれらを特定のエージェントのリソースおよび特定のリソース操作に適用できます。ha_cluster_resource_operation_defaults 変数で指定したデフォルトは、独自に定義した値で当該デフォルトをオーバーライドするリソース操作には適用されません。デフォルトでは、ha_cluster システムロールは、リソース操作用の独自の値を定義するようにリソースを設定します。これらのデフォルトを 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 セクションを参照してください。

(RHEL 9.4 以降) この変数は、フェンシングトポロジーとも呼ばれる STONITH レベルを定義します。フェンシングレベルは、複数のデバイスを使用してノードをフェンスするようにクラスターを設定します。1 つのデバイスに障害が発生した場合に備えて代替デバイスを定義し、ノードが正常にフェンスされたと見なすために複数のデバイスをすべて正常に実行することを要求できます。フェンシングレベルの詳細は、高可用性クラスターの設定と管理 の フェンシングレベルの設定 を参照してください。

フェンシングレベルを定義するときに、次の項目を設定できます。

ha_cluster システムロールで設定するフェンシングレベル定義の構造は次のとおりです。

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 システムロール Playbook の例は、フェンシングレベルを使用した高可用性クラスターの設定 を参照してください。

この変数は、リソースの場所の制約を定義します。リソースの場所の制約は、リソースを実行できるノードを示します。複数のリソースに一致する可能性のあるリソース ID またはパターンで指定されたリソースを指定できます。ノード名またはルールでノードを指定できます。

リソースの場所の制約に対して次の項目を設定できます。

デフォルトでは、リソースの場所の制約は定義されていません。

リソース 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 を指定するリソースの場所の制約に対して設定する項目と同じです。ただし、リソース仕様そのものは除きます。リソース仕様に指定する項目は次のとおりです。

リソースパターンとノード名を指定するリソースの場所に対する制約の構造は次のとおりです。

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 とルールを指定するリソースの場所の制約に対して、次の項目を設定できます。

リソース 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 とルールを指定するリソースの場所の制約に対して設定する項目と同じです。ただし、リソース仕様そのものは除きます。リソース仕様に指定する項目は次のとおりです。

リソースパターンとルールを指定するリソースの場所に対する制約の構造は次のとおりです。

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 システムロール Playbook の例は、リソースに制約のある高可用性クラスターの設定 を参照してください。

この変数は、リソースコロケーションの制約を定義します。リソースコロケーションの制約は、あるリソースの場所が別のリソースの場所に依存することを示しています。コロケーション制約には、2 つのリソースに対する単純なコロケーション制約と、複数のリソースに対するセットコロケーション制約の 2 種類があります。

単純なリソースコロケーション制約に対して次の項目を設定できます。

デフォルトでは、リソースコロケーション制約は定義されていません。

単純なリソースコロケーション制約の構造は次のとおりです。

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

リソースセットのコロケーション制約に対して次の項目を設定できます。

リソースセットに対するコロケーション制約の構造は次のとおりです。

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 システムロール Playbook の例は、リソースに制約のある高可用性クラスターの設定 を参照してください。

この変数は、リソースの順序に対する制約を定義します。リソース順序の制約は、特定のリソースアクションが発生する順序を示します。リソース順序の制約には、2 つのリソースに対する単純な順序制約と、複数のリソースに対するセット順序制約の 2 種類があります。

単純なリソース順序制約に対して次の項目を設定できます。

デフォルトでは、リソース順序の制約は定義されていません。

単純なリソース順序の制約の構造は次のとおりです。

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

リソースセットの順序制約に対して次の項目を設定できます。

リソースセットの順序制約の構造は次のとおりです。

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 システムロール Playbook の例は、リソースに制約のある高可用性クラスターの設定 を参照してください。

この変数は、リソースチケットの制約を定義します。リソースチケットの制約は、特定のチケットに依存するリソースを示します。リソースチケット制約には、1 つのリソースに対する単純なチケット制約と、複数のリソースに対するチケット順序の制約の 2 種類があります。

単純なリソースチケット制約に対して次の項目を設定できます。

デフォルトでは、リソースチケットの制約は定義されていません。

単純なリソースチケット制約の構造は次のとおりです。

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

リソースセットチケット制約に対して次の項目を設定できます。

リソースセットのチケット制約の構造は次のとおりです。

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 システムロール Playbook の例は、リソースに制約のある高可用性クラスターの設定 を参照してください。

(RHEL 8.8 以降) この変数は、クラスターの外部クォーラムデバイスとして機能できる qnetd ホストを設定します。

qnetd ホストに対して次の項目を設定できます。

フェンシングにより qnetd 操作が中断されるため、クラスターノード上で qnetd を実行することはできません。

クォーラムデバイスを使用してクラスターを設定する ha_cluster システムロール Playbook の例については、クォーラムデバイスを使用したクラスターの設定 を参照してください。