検索

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

download PDF

ha_cluster システムロールを使用すると、Pacemaker の高可用性クラスターリソースマネージャーを使用する高可用性クラスターを設定し、管理できます。

11.1. ha_cluster RHEL システムロールの変数

ha_cluster システムロール Playbook では、クラスターデプロイメントの要件に従って、高可用性クラスターの変数を定義します。

ha_cluster システムロールに設定できる変数は次のとおりです。

ha_cluster_enable_repos
ha_cluster システムロールで必要なパッケージを含むリポジトリーを有効にするブール値フラグ。この変数がデフォルト値の true に設定されている場合、クラスターメンバーとして使用するシステムに RHEL および RHEL High Availability Add-On の有効なサブスクリプションが必要です。サブスクリプションがない場合、システムロールは失敗します。
ha_cluster_enable_repos_resilient_storage
(RHEL 9.4 以降) dlmgfs2 などの耐障害性ストレージパッケージを含むリポジトリーを有効にするブールフラグ。このオプションを有効にするには、ha_cluster_enable_repostrue に設定する必要があります。この変数のデフォルト値は false です。
ha_cluster_manage_firewall

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

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

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

ha_cluster_manage_selinux

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

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

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

ha_cluster_cluster_present

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

ha_cluster_cluster_presentfalse に設定すると、すべての 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 9.3 以降) クォーラムデバイスの 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 システムロールが新しいキーを生成する場合は、鍵をノードのハイパーバイザーにコピーして、フェンシングが機能するようにする必要があります。

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

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

ha_cluster_pcsd_public_key_srcrha_cluster_pcsd_private_key_src

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

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

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

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

ha_cluster_pcsd_certificates

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

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

  • ha_cluster_pcsd_certificates 変数を設定します。ha_cluster_pcsd_certificates 変数を設定すると、certificate システムロールが内部的に使用され、定義どおりに pcsd の秘密鍵と証明書が作成されます。
  • ha_cluster_pcsd_public_key_srcha_cluster_pcsd_private_key_src、または ha_cluster_pcsd_certificates 変数を設定しないでください。これらの変数をいずれも設定しなかった場合、ha_cluster システムロールが pcsd 自体を使用して pcsd 証明書を作成します。ha_cluster_pcsd_certificates の値は、certificate システムロールで指定された変数 certificate_requests の値に設定されます。certificate システムのロールの詳細は、RHEL システムロールを使用した証明書の要求 を参照してください。

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

  • IPA を使用しており、システムを IPA ドメインに参加させていない限り、certificate システムロールによって自己署名証明書が作成されます。この場合、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 が無視されます。

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

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

ha_cluster_regenerate_keys
true に設定すると、事前共有キーと TLS 証明書が再生成されることを決定するブール型フラグ。キーおよび証明書が再生成されるタイミングの詳細は、ha_cluster_corosync_key_srcha_cluster_pacemaker_key_srcha_cluster_fence_virt_key_srcha_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 9.1 以降) クラスターのトランスポート方式を設定します。この変数を使用して設定するアイテムは以下のとおりです。

  • type (オプション) - トランスポートタイプ: knetudp、または udpuudp および udpu トランスポートタイプは、1 つのリンクのみをサポートします。udpudpu の暗号化は常に無効になっています。指定しない場合、デフォルトで 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 システムロール Playbook の例については、高可用性クラスターでの Corosync 値の設定 を参照してください。

ha_cluster_totem

(RHEL 9.1 以降) 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 値の設定 を参照してください。

ha_cluster_quorum

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

  • options (オプション) - クォーラムを設定する名前と値のディクショナリーのリスト。許可されるオプションは、auto_tie_breakerlast_man_standinglast_man_standing_window、および wait_for_all です。クォーラムオプションの詳細は、votequorum(5) の man ページを参照してください。
  • device (オプション) - (RHEL 9.2 以降) クォーラムデバイスを使用するようにクラスターを設定します。デフォルトでは、クォーラムデバイスは使用されません。

    • model (必須) - クォーラムデバイスモデルを指定します。net のみがサポートされています。
    • model_options (オプション) - 指定されたクォーラムデバイスモデルを設定する名前と値のディクショナリーのリスト。モデル net の場合、host および algorithm オプションを指定する必要があります。

      pcs-address オプションを使用して、qnetd ホストに接続するためのカスタム pcsd アドレスとポートを設定します。このオプションを指定しない場合、ロールは host 上のデフォルトの pcsd ポートに接続します。

    • generic_options (オプション) - モデル固有ではないクォーラムデバイスオプションを設定する名前と値のディクショナリーのリスト。
    • heuristics_options (オプション) - クォーラムデバイスのヒューリスティックを設定する名前と値のディクショナリーのリスト。

      クォーラムデバイスオプションの詳細は、corosync-qdevice(8) の man ページを参照してください。一般的なオプションは sync_timeouttimeout です。モデル 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 システムロール Playbook の例については、高可用性クラスターでの Corosync 値の設定 を参照してください。クォーラムデバイスを使用してクラスターを設定する ha_cluster システムロール Playbook の例については、クォーラムデバイスを使用した高可用性クラスターの設定 を参照してください。

ha_cluster_sbd_enabled

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

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

ha_cluster_sbd_options

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

  • delay-start - デフォルトは no
  • startmode - デフォルトは always
  • timeout-action - デフォルトは flush,reboot
  • watchdog-timeout - デフォルトは 5

    これらのオプションの詳細は、sbd(8) man ページの Configuration via environment セクションを参照してください。

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 は、node1node2 で構成されるクラスターを設定し、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 ノード属性を定義するノードの名前
  • 属性 (オプション) - ノードの 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 システムロール Playbook の例は、ノード属性を使用した高可用性クラスターの設定 を参照してください。

ha_cluster_resource_primitives

この変数は、フェンシングリソースを含む、システムロールによって設定される 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 9.3 以降) リソースエージェントは通常、特定のエージェント向けに最適化された、intervaltimeout などのリソース操作のデフォルト設定を定義します。この変数が true に設定されている場合、それらの設定がリソース設定にコピーされます。そうでない場合、クラスター全体のデフォルトがリソースに適用されます。ha_cluster_resource_operation_defaults ロール変数を使用してリソースのリソース操作のデフォルトも定義する場合は、これを false に設定できます。この変数のデフォルト値は true です。
  • operations (任意): リソースの操作のリスト。

    • action (必須): pacemaker と、リソースまたはフェンスエージェントで定義されている操作アクション。
    • attrs (必須): 少なくとも 1 つのオプションを指定する必要があります。

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

ha_cluster_resource_groups

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

  • id (必須): グループの ID。
  • resources (必須): グループのリソースのリスト。各リソースは ID によって参照され、リソースは ha_cluster_resource_primitives 変数に定義する必要があります。1 つ以上のリソースをリスト表示する必要があります。
  • meta_attrs (オプション): グループのメタ属性のセットのリスト。現在、1 つのセットのみがサポートされています。

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

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 システムロールで設定するリソースクローン定義の構造は次のとおりです。

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

ha_cluster_resource_defaults

(RHEL 9.3 以降) この変数は、リソースのデフォルトのセットを定義します。複数のデフォルトのセットを定義し、ルールを使用してそれらを特定のエージェントのリソースに適用できます。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 システムロール Playbook の例については、リソースおよびリソース操作のデフォルトを使用した高可用性クラスターの設定 を参照してください。

ha_cluster_resource_operation_defaults

(RHEL 9.3 以降) この変数は、リソース操作のデフォルトのセットを定義します。複数のデフォルトのセットを定義し、ルールを使用してそれらを特定のエージェントのリソースおよび特定のリソース操作に適用できます。ha_cluster_resource_operation_defaults 変数で指定したデフォルトは、独自に定義した値で当該デフォルトをオーバーライドするリソース操作には適用されません。デフォルトでは、ha_cluster システムロールは、リソース操作用の独自の値を定義するようにリソースを設定します。これらのデフォルトを ha_cluster_resource_operations_defaults 変数でオーバーライドする方法については、ha_cluster_resource_primitivescopy_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 システムロールで設定するフェンシングレベル定義の構造は次のとおりです。

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

ha_cluster_constraints_location

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

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

  • resource (必須) - 制約が適用されるリソースの仕様。
  • node (必須) - リソースが優先または回避する必要があるノードの名前。
  • id (オプション) - 制約の ID。指定しない場合、自動生成されます。
  • options (オプション) - 名前と値のディクショナリーリスト。

    • score - 制約の重みを設定します。

      • 正の score 値は、リソースがノードでの実行を優先することを意味します。
      • 負の score 値は、リソースがノードで実行されないようにする必要があることを意味します。
      • -INFINITYscore 値は、リソースがノードで実行されないようにする必要があることを意味します。
      • 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 (オプション) - 制約が制限されるリソースのロール。StartedUnpromotedPromoted
  • 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 システムロール Playbook の例は、リソースに制約のある高可用性クラスターの設定 を参照してください。

ha_cluster_constraints_colocation

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

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

  • resource_follower (必須) - resource_leader に関連して配置する必要があるリソース。

    • id (必須) - リソース ID。
    • role (オプション) - 制約が制限されるリソースのロール。StartedUnpromotedPromoted
  • resource_leader (必須) - クラスターは、最初にこのリソースを配置する場所を決定してから、resource_follower を配置する場所を決定します。

    • id (必須) - リソース ID。
    • role (オプション) - 制約が制限されるリソースのロール。StartedUnpromotedPromoted
  • id (オプション) - 制約の ID。指定しない場合、自動生成されます。
  • options (オプション) - 名前と値のディクショナリーリスト。

    • score - 制約の重みを設定します。

      • 正の score 値は、リソースが同じノードで実行される必要があることを示します。
      • 負の score 値は、リソースが異なるノードで実行される必要があることを示します。
      • + INFINITYscore 値は、リソースが同じノードで実行される必要があることを示します。
      • -INFINITYscore 値は、リソースが異なるノードで実行される必要があることを示します。
      • 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 システムロール Playbook の例は、リソースに制約のある高可用性クラスターの設定 を参照してください。

ha_cluster_constraints_order

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

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

  • resource_first (必須) - resource_then リソースが依存するリソース。

    • id (必須) - リソース ID。
    • action (オプション) - resource_then リソースに対してアクションを開始する前に完了する必要のあるアクション。許可される値: startstoppromotedemode
  • resource_then (必須) - 依存リソース。

    • id (必須) - リソース ID。
    • action (オプション) - resource_first リソースに対するアクションが完了した後にのみリソースが実行できるアクション。許可される値: startstoppromotedemode
  • 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 システムロール Playbook の例は、リソースに制約のある高可用性クラスターの設定 を参照してください。

ha_cluster_constraints_ticket

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

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

  • resource (必須) - 制約が適用されるリソースの仕様。

    • id (必須) - リソース ID。
    • role (オプション) - 制約が制限されるリソースのロール。StartedUnpromotedPromoted
  • 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 システムロール Playbook の例は、リソースに制約のある高可用性クラスターの設定 を参照してください。

ha_cluster_qnetd

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

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

  • present (オプション) - true の場合、ホスト上に qnetd インスタンスを設定します。false の場合、ホストから qnetd 設定を削除します。デフォルト値は false です。これを true に設定する場合は、ha_cluster_cluster_presentfalse に設定する必要があります。
  • start_on_boot (オプション) - ブート時に qnetd インスタンスを自動的に開始するかどうかを設定します。デフォルト値は true です。
  • regenerate_keys (オプション) - qnetd TLS 証明書を再生成するには、この変数を true に設定します。証明書を再生成する場合は、各クラスターのロールを再実行して qnetd ホストに再度接続するか、手動で pcs を実行する必要があります。

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

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

関連情報

  • /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md ファイル
  • /usr/share/doc/rhel-system-roles/ha_cluster/ ディレクトリー
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.