Page tree
Skip to end of metadata
Go to start of metadata

Beschreibung

Die folgende Dokumentation beschreibt die Installation eines Load Balancers unter CentOS 6.4 mit Apache 2.2 und dem Modul mod_proxy_balancer. Der Load Balancer wird als Cluster mit Hochverfügbarkeit über eine Failover IP mit Corosync und Pacemaker betrieben. Die Anfragen werden gleichmäßig auf 4 Application Server verteilt.

Die Architektur sieht wie folgt aus:

Folgende IP's werden verwendet:

10.4.12.220 cluster // Im produktiven Aufbau wird hier eine öffentliche IP verwendet

10.4.12.151 node1
10.4.12.153 node2

10.4.12.112 appserver1
10.4.12.113 appserver2
10.4.12.114 appserver3
10.4.12.115 appserver4

Corosync und Pacemaker

Installation

Software installieren:

node[1|2] # yum -y install corosync pacemaker

Key erzeugen:

node1 # corosync-keygen
node1 # scp /etc/corosync/authkey root@node2:/etc/corosync/

Firewall anpassen:

node[1|2] # vi /etc/sysconfig/iptables

-A INPUT -m state --state NEW -m udp -p udp --dport 5404 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 5405 -j ACCEPT

node[1|2] # /etc/init.d/iptables restart

Konfiguration erstellen und Cluster starten:

node[1|2] # cp /etc/corosync/corosync.conf.example /etc/corosync/corosync.conf
node[1|2] # vi /etc/corosync/corosync.conf

compatibility: whitetank
totem {
        version: 2
        secauth: off
        threads: 0
        interface {
                ringnumber: 0
                bindnetaddr: 10.4.12.1
                mcastaddr: 226.94.1.1
                mcastport: 5405
                ttl: 1
        }
}
quorum {
           provider: corosync_votequorum
           expected_votes: 2
}
logging {
        fileline: off
        to_stderr: no
        to_logfile: yes
        to_syslog: yes
        logfile: /var/log/cluster/corosync.log
        debug: off
        timestamp: on
        logger_subsys {
                subsys: AMF
                debug: off
        }
}
amf {
        mode: disabled
}
service {
        name: pacemaker
        ver: 1
}

node[1|2] # /etc/init.d/corosync start
node[1|2] # chkconfig corosync on
node[1|2] # /etc/init.d/pacemaker start
node[1|2] # chkconfig pacemaker on

Installation prüfen:

# corosync-quorumtool -l
Nodeid     Votes  Name
2534147082     1  10.4.12.151
2567701514     1  10.4.12.153

# corosync-cfgtool -s
Printing ring status.
Local node ID -1727265782
RING ID 0
    id    = 10.4.12.153
    status    = ring 0 active with no faults

# crm_mon -1
Last updated: Thu Apr 11 20:02:52 2013
Last change: Thu Apr 11 19:58:49 2013 via crmd on node4.localdomain
Stack: classic openais (with plugin)
Current DC: node4.localdomain - partition with quorum
Version: 1.1.8-7.el6-394e906
2 Nodes configured, 2 expected votes
0 Resources configured.
Online: [ node3.localdomain node4.localdomain ]

Konfiguration

Bevor man mit der Konfiguration von Ressourcen starten kann, muss in CentOS 6.4 das Tool "crm" manuell installiert werden, da es im Paket "pacemaker-cli" nicht mehr vorhanden ist:

node[1|2] # yum install wget python-dateutil redhat-rpm-config
node[1|2] # wget http://download.opensuse.org/repositories/network:/ha-clustering/RedHat_RHEL-6/x86_64/pssh-2.3.1-15.1.x86_64.rpm
node[1|2] # rpm -i pssh-2.3.1-15.1.x86_64.rpm
node[1|2] # wget http://download.opensuse.org/repositories/network:/ha-clustering/RedHat_RHEL-6/x86_64/crmsh-1.2.5-55.3.x86_64.rpm
node[1|2] # rpm -i crmsh-1.2.5-55.3.x86_64.rpm

Jetzt kann man das Tool testen:

node1 # crm configure show
node node1.localdomain
node node2.localdomain
property $id="cib-bootstrap-options" \
    dc-version="1.1.8-7.el6-394e906" \
    cluster-infrastructure="classic openais (with plugin)" \
    expected-quorum-votes="2"

Im ersten Schritt deaktiviert man Stonith:

node1 # crm configure property stonith-enabled=false

Dann konfiguriert man eine Failover IP:

node1 # crm configure primitive failover-ip ocf:heartbeat:IPaddr params ip=10.4.12.220 op monitor interval=10s

Apache

Als Load Balancer kommt Apache in Version 2.2 mit mod_proxy_balancer zum Einsatz.

Installation

Im ersten Schritt installiert man auf beiden Nodes den Apache Webserver:

node[1|2] # yum install httpd

Der Zugriff auf den Apache Webserver wird über iptables auf die Failover IP eingeschränkt:

node[1|2] # vi /etc/sysconfig/iptables

-A INPUT -m state --state NEW -m tcp -p tcp --destination 10.4.12.220 --dport 80 -j ACCEPT

node[1|2] # /etc/init.d/iptables restart

Konfiguration

Im nächsten Schritt konfiguriert man den Apache Webserver als Load Balancer auf die gewünschten Applicationserver:

node[1|2] # rm /etc/httpd/conf.d/welcome.conf
node[1|2] # vi /etc/httpd/conf.d/balancer.conf

<Proxy balancer://appserver>
BalancerMember http://10.4.12.112:8080/
BalancerMember http://10.4.12.113:8080/
BalancerMember http://10.4.12.114:8080/
BalancerMember http://10.4.12.115:8080/
</Proxy>
ProxyPass / balancer://appserver

node[1|2] # /etc/init.d/httpd start
node[1|2] # chkconfig httpd on

Damit werden alle Anfragen gleichmäßig auf die 4 Application Server verteilt.

Alternativ dazu kann man die Anfragen auch nach anderen Kriterien verteilen. Weitere Infos findet man hier:

Betrieb

Failover IP

Möchte man nun die Failover IP auf den Node 2 schwenken, hilft folgender Befehl:

node1 # crm resource list
 failover-ip    (ocf::heartbeat:IPaddr):    Started
node1 # crm resource migrate failover-ip node2.localdomain

Load Balancer

In diesem Aufbau muss beachtet werden, dass vor der Wartung eines Application Server dieser aus dem Load Balancing entfernt werden muss:

node[1|2] # vi /etc/httpd/conf.d/balancer.conf

#BalancerMember http://10.4.12.115:8080/

node[1|2] # /etc/init.d/httpd reload

Links