HAProxy und Pacemaker

HAProxy und Pacemaker

Mit dieser Anleitung wird ein Hochverfügbarer Loadbalancer mit HAProxy und Pacemaker aufgebaut.
Dieser Loadbalancer wir im Aktive-Aktive Modus arbeiten und die Anfragen aufteilen.

HAProxy und Pacemaker Cluster

Die einfachste Konfiguration ist die Aktive-Standby Konfiguration.
Bei dieser Konfiguration läuft die VIP nur auf der Aktiven HAProxy Node und wird im Fehlerfall auf die Standby Node verschoben.

Eine erweiterte Konfiguration ist das System im Aktive-Standby Standby-Aktive Modus zu betreiben.
Diese Konfiguration kann man nutzen wen man auf dem Loadbalancer zwei oder mehr Farmen mit jeweils eigener VIP eingerichtet hat. Der Vorteil hierbei ist das beide Geräte jeweils eine Farm verwalten und im Fehlerfall auf die andere Node wechseln können. Hierbei kann es natürlich zu Performance Einbusen kommen, aber lieber etwas langsamer als gar nicht mehr zu erreichen.

Die dritte Möglichkeit ist die Aktive-Aktive Konfiguration mit einer oder mehreren VIPs.
Bei dieser Konfiguration werden die ankommenden anfragen pro VIP auf beide HAProxy Nodes verteilt und von dieser Node an die dahinter liegenden Server verteilt. Jetzt kommt natürlich die Frage auf wie das funktionieren soll, da es die IP der VIP ja dann zweimal im Netz geben würde, und somit ein IP Adressen Konflikt entsteht. Das dies nicht passiert wird Pacemaker eine Magische iptables CLUSTERIP Regel automatisch erstellen.

Pacemaker Installation

Der Pacemaker Cluster Service sorgt dafür das die benötigten Ressourcen auf dem Servern vorhanden sind und laufen.
Installation auf beiden Node
[stextbox id=“bash“]apt-get install pacemaker[/stextbox]

Ccorosync authkey erstellen um eine verschlüsselte Cluster Verbindung zu haben.
Dies muss nur auf einer Node gemacht werden. Der Key wird dann auf die andere Node kopiert.
[stextbox id=“bash“]corosync-keygen[/stextbox]

[stextbox id=“info“]Corosync Cluster Engine Authentication key generator.
Gathering 1024 bits for key from /dev/random.
Press keys on your keyboard to generate entropy.
Press keys on your keyboard to generate entropy (bits = 712).
Press keys on your keyboard to generate entropy (bits = 760).
Press keys on your keyboard to generate entropy (bits = 808).
Press keys on your keyboard to generate entropy (bits = 856).
Press keys on your keyboard to generate entropy (bits = 904).
Press keys on your keyboard to generate entropy (bits = 952).
Press keys on your keyboard to generate entropy (bits = 1000).[/stextbox]

Bei einer VM kann es vorkommen das nicht genug entropy erzeugt wird. Dies lässt sich aber mit einer zweiten shell und diesem Befehl beheben.
[stextbox id=“bash“]while /bin/true; do dd if=/dev/urandom of=/tmp/100 bs=1024 count=100000; for i in {1..10}; do cp /tmp/100 /tmp/tmp_$i_$RANDOM; done; rm -f /tmp/tmp_* /tmp/100; done[/stextbox]

Key auf die andere Node kopieren
[stextbox id=“bash“]scp /etc/corosync/authkey haproxy02.dmz-home:/etc/corosync/[/stextbox]

Auf beiden Nodes die Berechtigungen setzen
[stextbox id=“bash“]chown root:root /etc/corosync/authkey
chmod 400 /etc/corosync/authkey[/stextbox]

Auf beiden Nodes das Starten von Corosync erlauben [stextbox id=“bash“]nano /etc/default/corosync[/stextbox]
Hier den wert von no auf yes setzen

Jetzt können wir uns um die Konfiguration von Corosync kümmern. Hier muss eigentlich nicht viel geändert werden aber es ist darauf zu achten das die Konfiguration auf beiden Nodes Identisch ist.
[stextbox id=“bash“]nano /etc/corosync/corosync.conf[/stextbox]

# Please read the openais.conf.5 manual page

totem {
        version: 2

        # How long before declaring a token lost (ms)
        token: 3000

        # How many token retransmits before forming a new configuration
        token_retransmits_before_loss_const: 10

        # How long to wait for join messages in the membership protocol (ms)
        join: 60

        # How long to wait for consensus to be achieved before starting a new round of membership configuration (ms)
        consensus: 3600

        # Turn off the virtual synchrony filter
        vsftype: none

        # Number of messages that may be sent by one processor on receipt of the token
        max_messages: 20

        # Limit generated nodeids to 31-bits (positive signed integers)
        clear_node_high_bit: yes

        # Disable encryption
        secauth: on

        # How many threads to use for encryption/decryption
        threads: 0

        # Optionally assign a fixed node id (integer)
        #nodeid: 1234

        # This specifies the mode of redundant ring, which may be none, active, or passive.
        rrp_mode: none

        interface {
                # The following values need to be set based on your environment
                ringnumber: 0
                bindnetaddr: 192.168.254.21
                mcastaddr: 226.94.1.1
                mcastport: 5405
        }
}

amf {
        mode: disabled
}

service {
        # Load the Pacemaker Cluster Resource Manager
        ver:       0
        name:      pacemaker
}

aisexec {
        user:   root
        group:  root
}

logging {
        fileline: off
        to_stderr: yes
        to_logfile: yes
        to_syslog: yes
        syslog_facility: daemon
        debug: off
        timestamp: on
        logger_subsys {
                subsys: AMF
                debug: off
                tags: enter|leave|trace1|trace2|trace3|trace4|trace6
        }
}

In dieser Konfiguration wurden secauth: Off nach on angepasst da wir ja eine Verschlüsselte Kommunikation haben wollen.
Des weiteren haben wir das Interface angegeben, über die die Kommunikation laufen soll. bindnetaddr: 192.168.254.21
Und das logging auf Syslog eingestellt. to_logfile: yes


Wen einem das Logging ins Syslog nicht gefällt, und man lieber das ganze in ein eigenes Logfile schreiben will, ändert man das ganze so ab.

        logfile: /var/log/corosync/corosync.log
#       syslog_facility: daemon

 

Jetzt sollte einem Start nichts im Wege stehen.

Auf beiden Nodes
[stextbox id=“bash“]/etc/init.d/corosync start[/stextbox]

Und mit diesem Befehl können wir das ganze überprüfen ob sich die beiden Nodes gefunden haben.
[stextbox id=“bash“]crm_mon -1fV[/stextbox]
[stextbox id=“info“]crm_mon[7655]: 2014/03/28_20:51:43 ERROR: unpack_resources: Resource start-up disabled since no STONITH resources have been defined
crm_mon[7655]: 2014/03/28_20:51:43 ERROR: unpack_resources: Either configure some or disable STONITH with the stonith-enabled option
crm_mon[7655]: 2014/03/28_20:51:43 ERROR: unpack_resources: NOTE: Clusters with shared data need STONITH to ensure data integrity
============
Last updated: Fri Mar 28 20:51:43 2014
Last change: Fri Mar 28 20:46:54 2014 via crmd on haproxy01
Stack: openais
Current DC: haproxy01 – partition with quorum
Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff
2 Nodes configured, 2 expected votes
0 Resources configured.
============

Online: [ haproxy01 haproxy02 ]

Migration summary:
* Node haproxy02:
* Node haproxy01:
[/stextbox]

Hier können wir sehen das es oben drei Errors gibt. Diese sind normal da wir jetzt noch keine STONITH Ressource konfiguriert haben.
Da ich in diesem Beispiel keine STONITH Ressource habe, werden wir die Konfiguration gleich dementsprechend anpassen.
[stextbox id=“bash“]crm configure property no-quorum-policy=“ignore“ stonith-enabled=“false“[/stextbox]

Jetzt sollte der Befehl crm_mon -1fV dies ausgeben
[stextbox id=“info“]============
Last updated: Fri Mar 28 20:58:41 2014
Last change: Fri Mar 28 20:57:37 2014 via cibadmin on haproxy01
Stack: openais
Current DC: haproxy01 – partition with quorum
Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff
2 Nodes configured, 2 expected votes
0 Resources configured.
============

Online: [ haproxy01 haproxy02 ]

Migration summary:
* Node haproxy02:
* Node haproxy01:[/stextbox]

HAProxy Installation und Konfiguration

Jetzt kommen wir erst mal zum HAProxy. Die Konfiguration der VIP bzw. VIPs machen wir später.
Da unser HAProxy sich auch schon auf eine IP Binden soll die eventuell noch nicht auf der Node aktive ist müssen wir das unserem System mitteilen.

Dazu fügen wir net.ipv4.ip_nonlocal_bind=1 auf beiden Nodes in die /etc/sysctl.conf hinzu und laden diese Änderung.
[stextbox id=“bash“]echo „net.ipv4.ip_nonlocal_bind=1“ >> /etc/sysctl.conf
sysctl -p[/stextbox]

Da bei Debian derzeit nur unter den Wheezy-Backports die Version 1.4.24 von HAProxy verfügbar ist, und der experimental Zweig nun ja experimentell ist hab ich hier noch eine Webseite gefunden die ich derzeit auch benutzte. http://www.roedie.nl leider sind hier die Debian Pakete auch nicht immer auf den Aktuell stand der Dinge. Aber die Version 1.5-dev19 läuft bei mir Stabil unter Debian Wheezy.

Alternative kann man natürlich auch das ganze von den Sourcen übersetzten, wir nutzen jetzt hier die 1.5-dev19.

[stextbox id=“bash“]wget http://www.roedie.nl/downloads/haproxy/haproxy-1.5-dev19/haproxy_1.5.0-1~dev19-1_amd64.deb
dpkg -i dev19-1_amd64.deb
[/stextbox]

Auf beiden Nodes das Starten von HAProxy einstellen

[stextbox id=“bash“]nano /etc/default/haproxy[/stextbox]

# Set ENABLED to 1 if you want the init script to start haproxy.
ENABLED=1
# Add extra flags here.
#EXTRAOPTS="-de -m 16"

Die Konfiguration von HAProxy findet man unter /etc/haproxy/haproxy.cfg. Diese Beispiel Konfiguration sollte man sich erst mal anschauen und sichern.

[stextbox id=“bash“]cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg_org[/stextbox]

Als erstes löschen wir die Config und legen eine Test Konfiguration mit folgenden Inhalt an.
[stextbox id=“bash“]rm /etc/haproxy/haproxy.cfg
nano /etc/haproxy/haproxy.cfg[/stextbox]

global
        log 127.0.0.1 local0
        log 127.0.0.1 local1 notice
        stats socket /var/run/haproxy.stat mode 0777 level admin
        maxconn 32000
        ulimit-n 65536
        chroot /var/chroot/haproxy
        user haproxy
        group haproxy
        daemon
        #debug
        #quiet

defaults
        log             global
        mode            http
        option          tcplog
        option          dontlognull
        retries         3
        option          redispatch
        maxconn         2000

        # Timeouts One hour is 3600s = 3600000 ms.
        timeout connect 50000ms # 50s
        timeout client  50000ms # 50s
        timeout server  50000ms # 50s

frontend stats-front
        bind *:8080
        mode http
        default_backend stats-back

backend stats-back
        mode http
        balance roundrobin
        stats uri /
        stats refresh 2s
#       stats auth pxcstats:secret

Noch das chroot Verzeichnis erstellen

[stextbox id=“bash“]mkdir /var/chroot/haproxy -p[/stextbox]

Und HAProxy Starten

[stextbox id=“bash“]/etc/init.d/haproxy start[/stextbox]

Das Status Webinterface sollte jetzt unter der Server IP mit Port 8080 erreichbar sein.
Hier kann man lediglich den Status / Stats vom HAProxy anschauen.
Wenn man das Interface nur mit User Authentifizierung erreichen will, aktiviert man dies stats auth pxcstats:secret.
Und nur auf einer IP lauschen soll dann zb. bind 192.168.254.21:8080

Da wir die Config später nur auf die zweite Node Kopieren sollte man für das Bind beide IPs eintragen.
Dies macht man dann einfach so.

frontend stats-front
        bind 192.168.254.21:8080
        bind 192.168.254.22:8080

Das Interface sieht dann im Browser so aus
HAProxy Stats Webseite

Die Dokumentation zu HAProxy findet man übrigens hier.
Für dieses Beispiel legen wir eine Webfarm mit zwei Webservern an.

[stextbox id=“bash“]nano /etc/haproxy/haproxy.cfg[/stextbox]

########################################
# Peer Sync der Verbindungs infos
########################################
peers loadbalancer_replication
        peer haproxy01 192.168.254.21:7778
        peer haproxy02 192.168.254.22:7778

########################################
# FRONTEND Web Farm
########################################
frontend Frontend_Web_Farm_HTTP
        bind 192.168.254.20:80
        mode http
        option http-server-close

        default_backend Backend_Web_Farm

########################################
# BACKEDND Web Farm
########################################
backend Backend_Web_Farm
        mode http
        option http-server-close

        #Peer Sync
        stick-table type ip size 200k peers loadbalancer_replication expire 1ms
        stick on src

        # The load balancing method to use
        balance roundrobin
        #balance source
        #balance leastconn

        # insert a cookie to record the real server
        #cookie SRVID insert indirect nocache

        option nolinger
        fullconn 20000
        option  forwardfor

        default-server inter 10s downinter 5s fastinter 1s rise 2 fall 2 slowstart 10s maxqueue 1024
        server web01 192.168.254.81:80 check weight 100
        server web02 192.168.254.82:80 check weight 100

Die Option peers loadbalancer_replication ist dafür da das sich die Loadbalancer gegenseitig Ihre Session Tabelle zuschicken und sich damit Synchronisieren.

Im Backend unter # Peer Sync ist konfiguriert, wie die Session Tabelle aufgebaut werden soll, wohin sie geschickt werden soll, und wann die Einträge darin verfallen sollen. Das expire hab ich auf eine milli Sekunde gestellt, damit die dahinter liegenden Webserver gleichmäßig per Roundrobin versorgt werden.

Jetzt noch die neue Config laden

[stextbox id=“bash“]/etc/init.d/haproxy reload[/stextbox]

Jetzt sollte das so ausschauen. Wenn beide Webserver erreichbar sind.

HAProxy Stats Webseite mit Web Farm

Jetzt würde der HAProxy die eingehenden anfragen schon auf die zwei Webserver verteilen allerdings fehlt und noch die VIP der Webserver Farm, diese wird dann per Pacemaker auf der HAProxy Node´s verwaltet.

Jetzt stellt sich noch die frage wie man die Konfiguration der HAProxy Nodes synchronisieren kann?
Hierzu gibt es mehre Möglichkeiten:

  • Ein bash script was die Config kopieren und einen reload macht
  • GlusterFS + monit
  • NFS mount und eine Verlinkung der haproxy.cfg (nicht meine Empfehlung) + monit

Hier würde ich sagen es kommt auf die Umgebung und auf die verlieben des Admins an.
Ich nutze eine Kombination aus GlusterFS und monit. Meine GlusterFS Anleitung.

Für dies HowTo reicht aber ein Copy und Reload Script.

Bei einer fehlerhaften Konfiguration wird nicht kopiert und kein reload gemacht.
[stextbox id=“bash“]nano /etc/haproxy/copy_and_reload_haproxy.sh[/stextbox]

#!/bin/bash

# Konfiguration pruefen
haproxy -c -f /etc/haproxy/haproxy.cfg

# Ergebniss pruefen
if [ $? -eq 0 ];
then
        sleep 1

        # Local Reload
        /etc/init.d/haproxy reload

        sleep 1
        # Copy Config und Reload
        scp /etc/haproxy/haproxy.cfg 192.168.254.22:/etc/haproxy/
        ssh 192.168.254.22 /etc/init.d/haproxy reload
else
        echo ""
        echo "#####"
        echo "##### Konfiguration hat einen fehler Siehe Oben"
        echo "#####"
        echo ""
fi

Hier sollte man auf den Nodes noch einen SSH Key hinterlegen und diesen für die Synchronisierung nutzen. Damit spart man sich die Passwort Eingabe.

Pacemaker VIP Konfiguration

 

Aktive-Standby VIP

Die VIP Konfiguration für ein Aktive-Standby System wird so hinzugefügt.

[stextbox id=“bash“]crm configure primitive resVIP1 ocf:heartbeat:IPaddr2 params ip=“192.168.254.20″ nic=“eth0″ cidr_netmask=“24″ op monitor interval=“10s“[/stextbox]

Mit watch -n1 „crm_mon -1nfV“ können wir uns anschauen auf welcher Node die resVIP1 gestartet wurde.
[stextbox id=“bash“]watch -n1 „crm_mon -1nfV“[/stextbox]

[stextbox id=“info“]============
Last updated: Fri Mar 28 22:08:01 2014
Last change: Fri Mar 28 22:08:01 2014 via cibadmin on haproxy01
Stack: openais
Current DC: haproxy02 – partition with quorum
Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff
2 Nodes configured, 2 expected votes
1 Resources configured.
============

Node haproxy01: online
Node haproxy02: online
resVIP1 (ocf::heartbeat:IPaddr2) Started

Migration summary:
* Node haproxy02:
* Node haproxy01:[/stextbox]

 

Aktive-Standby Standby-Aktive VIP

Die VIP Konfiguration für ein Aktive-Standby Standby-Aktive System sieht dann so aus.

[stextbox id=“bash“]crm configure primitive resVIP1 ocf:heartbeat:IPaddr2 params ip=“192.168.254.20″ nic=“eth0″ cidr_netmask=“24″ op monitor interval=“10s“
crm configure primitive resVIP2 ocf:heartbeat:IPaddr2 params ip=“192.168.254.19″ nic=“eth0″ cidr_netmask=“24″ op monitor interval=“10s“ [/stextbox]

Der Pacemaker sorgt automatisch dafür das die Ressource resVIP1 und resVIP2 auf den Cluster verteilt wird. Solange kein Ausfall entsteht werden die beiden VIPs nicht auf der gleichen Node laufen. Daher bekommt jede HAProxy Instanz nur den Traffic der jeweiligen VIP.

Mit watch -n1 „crm_mon -1nfV“ lässt sich das auch gut beobachten.
[stextbox id=“bash“]watch -n1 „crm_mon -1nfV“[/stextbox]

VIPs verteilt auf beide Nodes

[stextbox id=“info“]============
Last updated: Fri Mar 28 23:31:40 2014
Last change: Fri Mar 28 23:31:17 2014 via cibadmin on haproxy01
Stack: openais
Current DC: haproxy02 – partition with quorum
Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff
2 Nodes configured, 2 expected votes
1 Resources configured.
============

Node haproxy01: online
resVIP1 (ocf::heartbeat:IPaddr2) Started
Node haproxy02: online

Migration summary:
* Node haproxy02:
* Node haproxy01:[/stextbox]

Corosync auf einer Node abschalten und somit einen Takeover zu provozieren.
[stextbox id=“bash“]/etc/init.d/corosync stop[/stextbox]

VIPs auf einer Node da die andere Offline ist

[stextbox id=“info“]============
Last updated: Fri Mar 28 21:55:41 2014
Last change: Fri Mar 28 21:48:38 2014 via cibadmin on haproxy01
Stack: openais
Current DC: haproxy02 – partition WITHOUT quorum
Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff
2 Nodes configured, 2 expected votes
2 Resources configured.
============

Node haproxy01: OFFLINE
Node haproxy02: online
resVIP1 (ocf::heartbeat:IPaddr2) Started
resVIP2 (ocf::heartbeat:IPaddr2) Started

Migration summary:
* Node haproxy02:[/stextbox]

 

Aktive-Aktive VIP

Für eine Aktive-Aktive Umgebung müssen mindestens drei Node´s vorhanden sein.
Hier gilt die Regel wie beim RAID5 (N+1) wobei N die Anzahl der Aktiven Nodes entspricht die die VIP haben sollen.

Die Konfiguration schaut dann so aus.

[stextbox id=“bash“]crm configure primitive resVIP1 ocf:heartbeat:IPaddr2 params ip=“192.168.254.20″ nic=“eth0″ cidr_netmask=“24″ clusterip_hash=“sourceip-sourceport“ op monitor interval=“10s“ meta resource-stickiness=“0″
crm configure clone cloneVIP1 resVIP1 meta globally-unique=“true“ clone-max=“2″ clone-node-max=“1″ start-delay=“10s“[/stextbox]

Wenn man diese VIP auf mehr als zwei Nodes laufen lassen will gibt man dies mit clone-max an.
Es muss immer noch eine Backup Node vorhanden sein (clone-max Nodes + min. 1).

Das clone-node-max sollte bei dem VIP Clone immer auf eins belassen werden. Da eine IP pro System nur einmal vorkommen kann.

Der clusterip_hash gibt dem System die Infos wie die Verteilung des Traffic im Cluster vorgenommen werden soll.
Weiter Möglichkeiten für die Verteilung des Traffic ist:

  • sourceip
  • sourceip-sourceport
  • sourceip-sourceport-destport

Es ist wichtig zu wissen, wenn noch eine weiter Node ausfällt, ein teil des Traffics verloren geht.
Nur der Traffic der bereits auf die übriggebliebene Node läuft kann weiterverarbeitet werden, der restliche Traffic geht verloren.

Ich hab noch bei dem Clone das start-delay=10s auf 10 Sekunden gestellt, somit hat das System noch ein bisschen zeit bis die clone VIP gestartet wird.

Mit watch -n1 „crm_mon -1nfV“ lässt sich das auch gut beobachten.
[stextbox id=“bash“]watch -n1 „crm_mon -1nfV“[/stextbox]

Clone VIPs verteilt auf beide Nodes

[stextbox id=“info“]============
Last updated: Sun Mar 30 14:42:34 2014
Last change: Sun Mar 30 14:26:59 2014 via crmd on haproxy01
Stack: openais
Current DC: haproxy02 – partition with quorum
Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff
3 Nodes configured, 3 expected votes
2 Resources configured.
============

Node haproxy01: online
resVIP1:0 (ocf::heartbeat:IPaddr2) Started
Node haproxy02: online
resVIP1:1 (ocf::heartbeat:IPaddr2) Started
Node haproxy03: online

Migration summary:
* Node haproxy02:
* Node haproxy01:
* Node haproxy03:[/stextbox]

Corosync auf einer Node abschalten
[stextbox id=“bash“]/etc/init.d/corosync stop[/stextbox]

Clone VIP nur noch auf einer Node da die andere Offline ist

[stextbox id=“info“]============
Last updated: Sun Mar 30 14:43:14 2014
Last change: Sun Mar 30 14:26:59 2014 via crmd on haproxy01
Stack: openais
Current DC: haproxy02 – partition with quorum
Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff
3 Nodes configured, 3 expected votes
2 Resources configured.
============

Node haproxy01: OFFLINE
Node haproxy02: online
resVIP1:1 (ocf::heartbeat:IPaddr2) Started
Node haproxy03: online
resVIP1:0 (ocf::heartbeat:IPaddr2) Started

Migration summary:
* Node haproxy02:
* Node haproxy03:[/stextbox]

Corosync auf der ausgeschalteten Node einschalten
[stextbox id=“bash“]/etc/init.d/corosync start[/stextbox]

[stextbox id=“info“]============
Last updated: Sun Mar 30 14:44:26 2014
Last change: Sun Mar 30 14:26:59 2014 via crmd on haproxy01
Stack: openais
Current DC: haproxy02 – partition with quorum
Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff
3 Nodes configured, 3 expected votes
2 Resources configured.
============

Node haproxy01: online
Node haproxy02: online
resVIP1:1 (ocf::heartbeat:IPaddr2) Started
Node haproxy03: online
resVIP1:0 (ocf::heartbeat:IPaddr2) Started

Migration summary:
* Node haproxy02:
* Node haproxy01:
* Node haproxy03:[/stextbox]

 

Pacemaker Überwachung von HAProxy

Schlussendlich nehmen wir den HAProxy noch in Pacemaker auf und sorgen dafür das er immer auf jeder Node Gestartet wird

[stextbox id=“bash“]crm configure primitive resHAProxy lsb:haproxy op monitor interval=“5s“ failure-timeout=“60s“
crm configure clone cloneHAProxy resHAProxy meta globally-unique=“false“ failure-timeout=“60s“ clone-max=“2″ clone-node-max=“1″[/stextbox]

So das war es schon. :)
Nun haben wir einen HAProxy und Pacemaker Cluster.

Pacemaker sollte bei einem drei Node Aktive-Aktive Cluster ungefähr das ausgeben.

[stextbox id=“info“]============
Last updated: Sun Mar 30 17:25:15 2014
Last change: Sun Mar 30 17:14:11 2014 via cibadmin on haproxy01
Stack: openais
Current DC: haproxy02 – partition with quorum
Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff
3 Nodes configured, 3 expected votes
5 Resources configured.
============

Node haproxy01: online
resHAProxy:1 (lsb:haproxy) Started
Node haproxy02: online
resVIP1:0 (ocf::heartbeat:IPaddr2) Started
resHAProxy:0 (lsb:haproxy) Started
Node haproxy03: online
resVIP1:1 (ocf::heartbeat:IPaddr2) Started
resHAProxy:2 (lsb:haproxy) Started

Migration summary:
* Node haproxy02:
* Node haproxy01:
* Node haproxy03:[/stextbox]

Die drei HAProxy´s sollten am besten immer schon laufen bevor die Node die VIP bekommt, so können sie sich vorher schon synchronisieren und die Anfragen gleich übernehmen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

*