OndrejHome.ha-cluster-pacemaker

Überblick Versionen Einblicke

ha-cluster-pacemaker

Rolle zur Konfiguration und Erweiterung eines grundlegenden Pacemaker-Clusters auf CentOS/RHEL 6/7/8/9, AlmaLinux 8/9, Rocky Linux 8/9, Fedora 31/32/33/34/35/36/37/38/39/40 und CentOS 8/9 Stream-Systemen.

Diese Rolle kann folgende Aspekte des Pacemaker-Clusters konfigurieren:

  • erforderliche System-Repositorys aktivieren
  • benötigte Pakete installieren
  • Benutzer und Gruppen für den Betrieb des Pacemaker-Clusters erstellen und konfigurieren
  • Firewall konfigurieren
  • Einträge in /etc/hosts generieren
  • Clusterknoten autorisieren
  • Cluster erstellen oder Cluster erweitern (prüfen Sie allow_cluster_expansion)
    • Cluster mit "2 oder mehr" Knoten
    • ein einzelnes Heartbeat, RRP oder Knet mit bis zu 8 Verbindungen
    • Remote-Knoten
    • automatische oder benutzerdefinierte Schnittstellen/IPs für Heartbeat verwenden
  • Cluster beim Booten starten und aktivieren
  • Stonith-Geräte konfigurieren
    • standardmäßig fence_xvm Stonith-Geräte installieren und konfigurieren
    • optional fence_kdump konfigurieren
    • optional fence_vmware (SOAP/REST) oder andere fence_* Stonith-Geräte konfigurieren
    • optional fence_aws konfigurieren

Die Rolle unterstützt vollständig den --check-Modus für die Standardkonfiguration und teilweise für die meisten anderen Optionen.

Bitte geben Sie beim Melden eines Problems folgende Informationen an (wenn möglich):

  • verwendete Ansible-Version
  • Betriebssystem, von dem aus Ansible ausgeführt wurde
  • Playbook und Inventar-Datei, die den Fehler verursacht haben (entfernen Sie sensible Informationen, wo angebracht)
  • Fehlermeldung oder Beschreibung des aufgetretenen Fehlverhaltens

Voraussetzungen

Diese Rolle hängt von der Rolle ondrejhome.pcs-modules-2 ab.

Ansible 2.8 oder später. (HINWEIS: Es könnte möglich sein, frühere Versionen zu verwenden, probieren Sie bei Problemen bitte ein Update auf Ansible 2.8 oder höher.)

RHEL 6/7/8: Es wird erwartet, dass die Maschinen bereits registriert sind. Die Rolle aktiviert standardmäßig den Zugriff auf den Kanal 'High Availability' oder 'Resilient storage'. Wenn dies nicht gewünscht ist, überprüfen Sie die Variable enable_repos.

RHEL/CentOS 7: Diese Rolle benötigt mindestens Version 2.9 der Bibliothek python-jinja2. Wenn nicht vorhanden, kann der in Problem #6 beschriebene Fehler auftreten. Um die aktualisierte Version von python-jinja2 und dessen Abhängigkeiten zu erhalten, können Sie das folgende RPM-Repository verwenden - https://copr.fedorainfracloud.org/coprs/ondrejhome/ansible-deps-el7/ für sowohl CentOS 7 als auch RHEL 7.

CentOS 8 Stream Getestet mit Version 20240129, minimal empfohlene Ansible-Version ist 2.11.0, die das System als 'CentOS' statt 'RedHat' identifiziert. Die frühere CentOS 8 Stream Version 20201211 hat die minimal verwendbare Ansible-Version 2.9.16/2.10.4. Die Version 2.8.18 hat während der Tests nicht funktioniert. Dies ist mit Service ist im unbekannten Zustand #71528 verbunden.

CentOS 9 Stream Getestet mit Version 20240129, minimal empfohlene Ansible-Version ist 2.11.0.

Debian Buster Getestet mit Version 20210310 mit Ansible-Version 2.10 und Debian Bullseye Getestet mit Version 20220326 mit Ansible-Version 2.12. Der Debian-Teil dieser Rolle enthält nicht die Stonith-Konfiguration und die Firewall-Konfiguration. Hinweis: Diese Rolle wurde nur einer begrenzten Testung auf Debian unterzogen - nicht alle Funktionen dieser Rolle wurden getestet.

Debian Bookworm Getestet mit Ansible-Version 2.14 und Debian Bookworm. Der Debian-Teil dieser Rolle enthält nicht die Stonith-Konfiguration und die Firewall-Konfiguration. Hinweis: Diese Rolle wurde nur einer begrenzten Testung auf Debian unterzogen - nicht alle Funktionen dieser Rolle wurden getestet.

Die Ansible-Versionen 2.9.10 und 2.9.11 schlagen mit dem Fehler "'hostvars' ist undefiniert" fehl, wenn versucht wird, entfernte Knoten zu konfigurieren. Dies gilt nur, wenn es mindestens einen Knoten mit cluster_node_is_remote=True gibt. Vermeiden Sie diese Ansible-Versionen, wenn Sie planen, entfernte Knoten mit dieser Rolle zu konfigurieren.

Unter CentOS Linux 8 müssen Sie sicherstellen, dass die Basis- und Appstream-Repositorys ordnungsgemäß funktionieren. Da CentOS Linux 8 sich in der End-Of-Life-Phase befindet, wird diese Rolle das HA-Repository so konfigurieren, dass es auf vault.centos.org verweist, wenn die Repository-Konfiguration (enable_repos: true) angefordert wird (ist standardmäßig).

pcs-0.11 Versionsdistributoren (AlmaLinux 9, Rocky Linux 9, RHEL 9, Fedora 36/37/38) sind nur mit der Version 27.0.0 oder höher von ondrejhome.pcs-modules-2 unterstützt.

Rollenvariablen

  • Benutzer für die Autorisierung von Clusterknoten

    cluster_user: 'hacluster'

  • Passwort für den Benutzer zur Autorisierung von Clusterknoten

    cluster_user_pass: 'testtest'

  • Gruppe, zu der der Clusterbenutzer gehört (sollte 'haclient' sein)

    cluster_group: 'haclient'

  • Name des Clusters

    cluster_name: 'pacemaker'

  • Konfiguration der Firewall für Clustering, HINWEIS: In RHEL/Centos 6 ersetzt dies die Konfigurationsdatei für iptables!

    cluster_firewall: true

  • Cluster beim Booten auf normalen (nicht pacemaker_remote) Knoten aktivieren

    cluster_enable_service: true

  • Cluster mit Stonith-Gerät fence_xvm konfigurieren? Dies wird /etc/cluster/fence_xvm.key auf die Knoten kopieren und Stonith-Geräte zum Cluster hinzufügen. HINWEIS: Sie müssen 'vm_name' im Inventar für jeden Clusterknoten definieren.

    cluster_configure_fence_xvm: true

  • Cluster mit fence_vmware_soap/fence_vmware_rest Stonith-Gerät konfigurieren? Dies wird den fence_vmware_soap/fence_vmware_rest Stonith-Agent installieren und konfigurieren. Wenn dies aktiviert ist, müssen Sie 3 zusätzliche Variablen mit Informationen zum Zugriff auf den vCenter angeben. HINWEIS: Sie müssen auch 'vm_name' im Inventar für jeden Clusterknoten definieren, um den Namen oder UUID der VM anzugeben, wie sie auf dem Hypervisor oder in der Ausgabe des Befehls fence_vmware_soap -o list/fence_vmware_rest zu sehen ist.

    cluster_configure_fence_vmware_soap: false
cluster_configure_fence_vmware_rest: false
fence_vmware_ipaddr: ''
fence_vmware_login: ''
fence_vmware_passwd: ''

    Sie können optional die zusätzlichen Attribute ändern, die an fence_vmware_soap/fence_vmware_rest übergeben werden, indem Sie die Variable fence_vmware_options verwenden. Standardmäßig aktiviert diese Variable die Verschlüsselung, deaktiviert jedoch die Zertifikatsvalidierung.

    fence_vmware_options: 'ssl="1" ssl_insecure="1"'

    HINWEIS: Nur eines der fence_vmware_soap/fence_vmware_rest kann als Stonith-Geräte konfiguriert werden, da diese denselben Namen teilen.

  • Cluster mit fence_kdump Stonith-Gerät konfigurieren? Dies startet den Kdump-Dienst und definiert die fence_kdump Stonith-Geräte. HINWEIS: Wenn der Kdump-Dienst nicht gestartet wird, funktioniert das möglicherweise nicht ordnungsgemäß oder überhaupt nicht.

    cluster_configure_fence_kdump: false

  • Cluster mit fence_aws Stonith-Gerät konfigurieren? Sie müssen die Instanz-ID/Region von AWS und das Instanzprofil angeben, das in der Lage ist, Instanzen für diesen Cluster zu starten/zu stoppen. Wenn dies aktiviert ist, müssen Sie die Variable fence_aws_region mit Informationen zur AWS-Region angeben. HINWEIS: Wenn Sie kein Instanzprofil einrichten, funktioniert es möglicherweise nicht ordnungsgemäß oder überhaupt nicht.

    cluster_configure_fence_aws: false
fence_aws_region: ''

    HINWEIS: Sie müssen auch instance_id im Inventar für jeden Clusterknoten definieren, indem Sie die Instanz-ID angeben, wie sie im AWS-Web-Console oder in der Ausgabe des Befehls fence_aws -o list zu sehen ist. (man fence_aws)

    Sie können optional die zusätzlichen Attribute ändern, die an fence_aws übergeben werden, indem Sie die Variable fence_aws_options verwenden.

    fence_aws_options: ''

    HINWEIS: Beispiele für geeignete Optionen für einige spezifische Anwendungsfälle finden Sie in den folgenden Dokumenten. https://access.redhat.com/articles/4175371#create-stonith
    https://docs.aws.amazon.com/sap/latest/sap-hana/sap-hana-on-aws-cluster-resources-1.html

  • Wie werden Stonith-Geräte den Clusterknoten zugeordnet? Standardmäßig wird für jeden Clusterknoten ein separates Stonith-Gerät erstellt ('one-device-per-node'). Einige Fence-Agenten können mehrere Knoten mit demselben Stonith-Gerät absichern ('one-device-per-cluster') und können Probleme haben, wenn mehrere Geräte aufgrund derselben Benutzeranmeldelimits verwendet werden. Verfügbare Optionen:

    • one-device-per-node - (Standard) - ein Stonith-Gerät pro Clusterknoten wird erstellt

    • one-device-per-cluster - (bei unterstützten Fence-Agenten) - nur ein clusterweites Stonith-Gerät für alle Knoten wird erstellt, unterstützte Fence-Agenten: fence_vmware_rest, fence_vmware_soap, fence_xvm, fence_kdump

      cluster_configure_stonith_style: 'one-device-per-node'

  • (RHEL/CentOS/AlmaLinux/Rocky) die Repositorys aktivieren, die benötigte Pakete enthalten

    enable_repos: true

  • (Nur RHEL) die erweiterten Update (EUS) Repositorys aktivieren, die benötigte Pakete enthalten

    enable_eus_repos: false

  • (Nur RHEL) die SAP Solutions Update Service (E4S) Repositorys aktivieren, die benötigte Pakete enthalten

    enable_e4s_repos: false

  • (Nur RHEL) Beta-Repositorys aktivieren, die benötigte Pakete enthalten

    enable_beta_repos: false

  • (Nur RHEL) Typ der aktivierten Repositorys, beachten Sie, dass E4S-Repos nur den 'ha'-Typ verfügbar haben

    • ha - Hochverfügbarkeit

    • rs - Resiliente Speicherung

      repos_type: 'ha'

  • (Nur RHEL) custom_repository ermöglicht es, ein beliebig benanntes Repository zu aktivieren. Die RHEL8 Repository-Namen finden Sie unter http://downloads.redhat.com/redhat/rhel/rhel-8-beta/rhel-8-beta.repo

    custom_repository: ''

  • (Nur CentOS) die benötigten Pakete von dem CD-ROM-Medium installieren, das unter /dev/cdrom verfügbar ist

    use_local_media: false

  • PCSD-Web-GUI aktivieren oder deaktivieren. Standardmäßig behält die Rolle die Standardinstallation bei, was bedeutet, dass die PCSD-Web-GUI in CentOS/RHEL 6.X deaktiviert und in CentOS/RHEL 7.X aktiviert ist. true oder false können an diese Variable übergeben werden, um sicherzustellen, dass die PCSD-Web-GUI aktiviert oder deaktiviert ist.

    enable_pcsd_gui: 'nochange'

  • Transportprotokoll des Clusters. Standardmäßig verwendet diese Rolle das, was für das gegebene Betriebssystem standardmäßig ist. Für CentOS/RHEL 6.X bedeutet dies 'udp' (UDP-Multicast) und für CentOS/RHEL 7.X bedeutet dies 'udpu' (UDP-Unicast). Diese Variable akzeptiert folgende Optionen: default, udp und udpu.

    cluster_transport: 'default'

  • Erlauben Sie das Hinzufügen von Knoten zu einem bestehenden Cluster, wenn Sie es mit ondrejhome.pcs-modules-2 v16 oder neuer verwenden.

    allow_cluster_expansion: false

  • Netzwerk-Schnittstelle des Clusters. Wenn angegeben, wird die Rolle Hosts auf die primäre IPv4-Adresse von dieser Schnittstelle zuordnen. Standardmäßig wird die IPv4-Adresse aus ansible_default_ipv4 oder die erste IPv4-Adresse aus ansible_all_ipv4_addresses verwendet. Zum Beispiel, um die primäre IPv4-Adresse von der Schnittstelle ens8 zu verwenden, verwenden Sie cluster_net_iface: 'ens8'. Die Schnittstelle muss auf allen Clusterknoten vorhanden sein.

    cluster_net_iface: ''

  • Redundante Netzwerkschnittstelle. Wenn angegeben, richtet die Rolle einen Corosync-redundanten Ring mit der standardmäßigen IPv4-Adresse von dieser Schnittstelle ein. Die Schnittstelle muss auf allen Clusterknoten vorhanden sein.

      rrp_interface: ''

    HINWEIS: Sie können diese Variable entweder in defaults/main.yml definieren, in diesem Fall wird dieselbe rrp_interface-Namen für alle Hosts in der Host-Datei verwendet. Alternativ können Sie eine spezifische Schnittstellenbezeichnung für jeden Host in der Host-Datei angeben (falls die Hosts nicht denselben Schnittstellennamen haben). Beachten Sie auch, dass Sie anstelle der Definition von rrp_interface für einen Host, rrp_ip definieren können: in diesem Fall wird diese alternative IP zur Konfiguration von Corosync RRP verwendet (diese IP muss sich von der standardmäßigen IPv4-Adresse des Hosts unterscheiden).

  • Ob Hosts zu /etc/hosts hinzugefügt werden sollen. Standardmäßig wird ein Eintrag für den Hostnamen, der durch cluster_hostname_fact angegeben wird, für jeden Host zu /etc/hosts hinzugefügt. Dies kann deaktiviert werden, indem cluster_etc_hosts auf false gesetzt wird.

    cluster_etc_hosts: true

  • Welches Ansible-Faktum als Hostname der Clusterknoten verwendet werden soll. Standardmäßig verwendet diese Rolle das ansible_hostname Faktum als Hostnamen für jeden Host. In einigen Umgebungen kann es nützlich sein, den vollständig qualifizierten Domainnamen (FQDN) ansible_fqdn oder den Knoten-Namen ansible_nodename zu verwenden.

    cluster_hostname_fact: "ansible_hostname"

  • Ob der Knoten als remote Pacemaker-Knoten eingerichtet werden soll. Standardmäßig ist dies false, und der Knoten wird volles Mitglied des Pacemaker-Clusters sein. Pacemaker-remote-Knoten sind keine vollen Mitglieder des Clusters und ermöglichen es, die maximale Clustergröße von 32 vollen Mitgliedern zu überschreiten. Beachten Sie, dass entfernte Knoten von dieser Rolle nur in EL7 und EL8 unterstützt werden.

    cluster_node_is_remote: false

  • Geordnete Liste von Variablen zur Erkennung der primären Cluster-IP (Ring0). Die erste übereinstimmende IPv4-Adresse wird verwendet, und der Rest der erkannten IPv4-Adressen wird übersprungen. In den meisten Fällen sollte dies keine Änderung erfordern, in einigen speziellen Fällen, z. B. wenn es kein Standard-Gateway gibt oder eine nicht primäre IPv4-Adresse von einer bestimmten Schnittstelle verwendet werden soll, kann dies angepasst werden.

    ring0_ip_ordered_detection_list:
  - "{{ hostvars[inventory_hostname]['ansible_'+cluster_net_iface].ipv4.address|default('') }}"
  - "{{ ansible_default_ipv4.address|default('') }}"
  - "{{ ansible_all_ipv4_addresses[0]|default('') }}"

  • Cluster-Eigenschaften konfigurieren (nicht zwingend erforderlich)

    cluster_property:
  - name: required
    node: optional
    value: optional

  • Standardwerte für Cluster-Ressourcen konfigurieren (nicht zwingend erforderlich)

    cluster_resource_defaults:
  - name: required
    defaults_type: optional
    value: optional

  • Cluster-Ressourcen konfigurieren (nicht zwingend erforderlich)

    cluster_resource:
  - name: required
    resource_class: optional
    resource_type: optional
    options: optional
    force_resource_update: optional
    ignored_meta_attributes: optional
    child_name: optional

  • Cluster-Befehlsbeschränkungen konfigurieren (nicht zwingend erforderlich)

    cluster_constraint_order:
  - resource1: required
    resource1_action: optional
    resource2: required
    resource2_action: optional
    kind: optional
    symmetrical: optional

  • Cluster-Kollokationsbeschränkungen konfigurieren (nicht zwingend erforderlich)

    cluster_constraint_colocation:
  - resource1: required
    resource1_role: optional
    resource2: required
    resource2_role: optional
    score: optional
    influence: optional

  • Cluster-Standortbeschränkungen konfigurieren (nicht zwingend erforderlich)

    knotenbasierte

    cluster_constraint_location:
  - resource: required
    node_name: required
    score: optional

    regelnbasierte (benötigt ondrejhome.pcs-modules-2 Version 30.0.0 oder neuer)

    cluster_constraint_location:
  - resource: required
    constraint_id: required
    rule: required
    score: optional

Sicherheitsüberlegungen

Bitte überlegen Sie, den Standardwert für cluster_user_pass zu aktualisieren.

Um die sensiblen Werte in Variablen, die an diese Rolle übergeben werden, zu schützen, können Sie ansible-vault verwenden, um sie zu verschlüsseln. Der empfohlene Ansatz besteht darin, eine separate Datei mit den gewünschten Variablen und deren Werten zu erstellen, die gesamte Datei mit ansible-vault encrypt zu verschlüsseln und dann diese Datei im Abschnitt pre_tasks: einzufügen, damit sie vor der Ausführung der Rolle geladen wird. Das folgende Beispiel veranschaulicht diesen Prozess.

Erstellen der Datei encrypted_vars.yaml

    1. Erstellen Sie eine Klartextdatei encrypted_vars.yaml mit Ihren gewünschten geheimen Werten
    # cat encrypted_vars.yaml
---
cluster_user_pass: 'cluster-user-pass'
fence_vmware_login: 'vcenter-user'
fence_vmware_passwd: 'vcenter-pass'
    1. Verschlüsseln Sie die Datei mit ansible-vault
    # ansible-vault encrypt encrypted_vars.yaml
    1. Überprüfen Sie den neuen Inhalt von encrypted_vars.yaml
    # cat encrypted_vars.yaml
$ANSIBLE_VAULT;1.1;AES256
31306461386430...

Beispiel-Playbook, das Werte aus der Datei encrypted_vars.yaml verwendet

- hosts: cluster
   pre_tasks:
     - include_vars: encrypted_vars.yaml
   roles:
     - { role: 'ondrejhome.ha-cluster-pacemaker', cluster_name: 'test-cluster' }

HINWEIS: Es wird davon abgeraten, nur den Wert der Variablen zu verschlüsseln und sie in vars: zu platzieren, da dies zu Fehlern wie argument 1 must be str, not AnsibleVaultEncryptedUnicode führen kann. Der Ansatz, die gesamte Datei zu verschlüsseln, scheint von diesem Problem nicht betroffen zu sein.

Ansible module_defaults

Obwohl diese Rolle nicht alle Konfigurationsoptionen über Variablen verfügbar macht, kann man die module_defaults verwenden, um die Standardwerte der Parameter zu ändern, die diese Rolle nicht verwendet. Unten steht eine nicht vollständige Liste von Beispielen, wo dies nützlich sein kann.

Beispiel module_default A zum Setzen des Tox Tokens auf 15 Sekunden

- hosts: cluster
  modules_defaults:
    pcs_cluster:
      token: 15000               # Standardwert ist 'null' - hängt vom Standardwert des OS ab

Beispiel module_default B zum Deaktivieren der Installation schwacher Abhängigkeiten auf EL8+/Fedora-Systemen

- hosts: cluster
  modules_defaults:
    yum:
      install_weak_deps: false   # Standardwert ist 'true'

Beispiel module_default C zum Deaktivieren der Installation empfohlenen Paketen auf Debian-Systemen

- hosts: cluster
  modules_defaults:
    apt:
      install_recommends: false  # Standardwert ist 'null' - hängt von der Konfiguration des OS ab

HINWEIS: Die module_defaults gelten nur für Optionen, die nicht in der Aufgabe angegeben sind - Sie können keinen Wert überschreiben, der durch eine Aufgabe in dieser Rolle festgelegt wurde, nur den Wert von Optionen, die nicht verwendet werden, kann geändert werden.

Beispiel-Playbook

Beispiel Playbook A zum Erstellen eines Clusters mit dem Namen 'test-cluster', der beim Booten aktiviert ist, mit fence_xvm und Firewall-Einstellungen. HINWEIS: cluster_name ist optional und hat standardmäßig den Wert pacemaker.

- hosts: cluster
  roles:
     - { role: 'ondrejhome.ha-cluster-pacemaker', cluster_name: 'test-cluster' }

Beispiel Playbook B zum Erstellen eines Clusters mit dem Namen 'test-cluster', ohne die Firewall zu konfigurieren und ohne fence_xvm. Für die ordnungsgemäße Autorisierung des Clusters wird vorausgesetzt, dass die Firewall bereits konfiguriert oder deaktiviert ist.

- hosts: cluster
  roles:
     - { role: 'ondrejhome.ha-cluster-pacemaker', cluster_name: 'test-cluster', cluster_firewall: false, cluster_configure_fence_xvm: false }

Beispiel Playbook C zum Erstellen eines Clusters mit dem Namen vmware-cluster mit fence_vmware_soap Stonith-Gerät.

- hosts: cluster
  vars:
    fence_vmware_ipaddr: 'vcenter-hostname-or-ip'
    fence_vmware_login: 'vcenter-username'
    fence_vmware_passwd: 'vcenter-password-for-username'
  roles:
     - { role: 'ondrejhome.ha-cluster-pacemaker', cluster_name: 'vmware-cluster', cluster_configure_fence_xvm: false, cluster_configure_fence_vmware_soap: true }

Beispiel Playbook D zum Erstellen eines Clusters mit dem Namen test-cluster, bei dem /etc/hosts nicht geändert wird:

- hosts: cluster
  roles:
     - { role: 'ondrejhome.ha-cluster-pacemaker', cluster_name: 'test-cluster', cluster_etc_hosts: false }

Beispiel Playbook E zum Erstellen eines Clusters mit dem Namen vmware-cluster mit einem einzigen fence_vmware_rest Stonith-Gerät für alle Clusterknoten.

- hosts: cluster
  vars:
    fence_vmware_ipaddr: 'vcenter-hostname-or-ip'
    fence_vmware_login: 'vcenter-username'
    fence_vmware_passwd: 'vcenter-password-for-username'
  roles:
     - { role: 'ondrejhome.ha-cluster-pacemaker', cluster_name: 'vmware-cluster', cluster_configure_fence_xvm: false, cluster_configure_fence_vmware_rest: true, cluster_configure_stonith_style: 'one-device-per-cluster' }

Beispiel Playbook F zum Erstellen eines Clusters mit dem Namen aws-cluster mit einem einzigen fence_aws Stonith-Gerät für alle Clusterknoten.

- hosts: cluster
  roles:
    - { role: 'ondrejhome.ha-cluster-pacemaker', cluster_name: 'aws-cluster', cluster_configure_fence_xvm: false, cluster_configure_fence_aws: true, cluster_configure_stonith_style: 'one-device-per-cluster', enable_repos: false, fence_aws_region: 'aws-region' }

Beispiel Playbook Ressourcen-Konfiguration .

- hosts: cluster
  vars:
    cluster_property:
      - name: 'maintenance-mode'
        value: 'true'
    cluster_resource:
      - name: 'apache2'
        resource_type: 'systemd:apache2'
        options: 'meta migration-threshold=2 op monitor interval=20s timeout=10s'
      - name: 'cluster_vip'
        resource_type: 'ocf:heartbeat:IPaddr2'
        options: 'ip=192.168.1.150 cidr_netmask=24 meta migration-threshold=2 op monitor interval=20'
    cluster_constraint_colocation:
      - resource1: 'cluster_vip'
        resource2: 'apache2'
        score: 'INFINITY'
    cluster_resource_defaults:
      - name: 'failure-timeout'
        value: '30'
  roles:
     - { role: 'ondrejhome.ha-cluster-pacemaker', cluster_name: 'apache-cluster'}

Beispiel-Inventardatei für CentOS/RHEL/Fedora-Systeme zur Erstellung grundlegender Cluster.

[cluster-centos7]
192.168.22.21 vm_name=fastvm-centos-7.8-21
192.168.22.22 vm_name=fastvm-centos-7.8-22
[cluster-fedora32]
192.168.22.23 vm_name=fastvm-fedora32-23
192.168.22.24 vm_name=fastvm-fedora32-24
[cluster-rhel8]
192.168.22.25 vm_name=fastvm-rhel-8.0-25
192.168.22.26 vm_name=fastvm-rhel-8.0-26

Beispiel-Inventardatei für Cluster, die RRP-Interkonnektivität über eine benutzerdefinierte Schnittstelle und/oder über eine benutzerdefinierte IP für RRP verwenden.

[cluster-centos7-rrp]
192.168.22.27 vm_name=fastvm-centos-7.6-21 rrp_interface=ens6
192.168.22.28 vm_name=fastvm-centos-7.6-22 rrp_ip=192.168.22.29

Beispiel-Inventardatei mit zwei vollen Mitgliedern und zwei Remote-Knoten:

[cluster]
192.168.22.21 vm_name=fastvm-centos-7.6-21
192.168.22.22 vm_name=fastvm-centos-7.6-22
192.168.22.23 vm_name=fastvm-centos-7.6-23 cluster_node_is_remote=True
192.168.22.24 vm_name=fastvm-centos-7.6-24 cluster_node_is_remote=True

Beispiel-Inventardatei mit fence_aws:

[cluster]
172.31.0.1	instance_id="i-acbdefg1234567890"
172.31.0.2	instance_id="i-acbdefg0987654321"

Alte Video-Beispiele zum Ausführen der Rolle mit Standardwerten für:

Lizenz

GPLv3

Autoreninformation

Um mit dem Autor in Kontakt zu treten, können Sie die E-Mail ondrej-xa2iel8u@famera.cz verwenden oder ein Problem auf GitHub erstellen, um eine Funktion zu beantragen.

Über das Projekt

pacemaker basic cluster role with fencing configuration (xvm, kdump, custom)

role clustering pacemaker
Installieren
ansible-galaxy install OndrejHome.ha-cluster-pacemaker
GitHub Repository
44 Sterne
29 Forks
0 Offene Issues
Lizenz
gpl-3.0
Downloads
2.5k
Besitzer