Open Source im professionellen Einsatz

Load Balancer

Eine Webserver-Farm mit Hunderten einzelner Server ließe sich allerdings kaum mit einem Failover-Cluster absichern - und das ist auch gar nicht nötig. Weiß der vorgeschaltete Load Balancer (Abbildung 4) nämlich, dass er einen bestimmten Knoten nicht mehr mit Aufträgen versorgen soll, ist eigentlich alles erledigt. Die Masse der restlichen Server in der Farm fängt den Ausfall ab und der Admin kann das Gerät später ersetzen.

Abbildung 3: Ein ausgebauter Failover-Cluster – beispielsweise mit Linux-HA, Version 2, oder einer kommerziellen Software – bedient ein Dutzend Knoten oder mehr und verteilt ausgefallene Services im Cluster auf der Grundlage eines Regelwerks neu.

Abbildung 3: Ein ausgebauter Failover-Cluster – beispielsweise mit Linux-HA, Version 2, oder einer kommerziellen Software – bedient ein Dutzend Knoten oder mehr und verteilt ausgefallene Services im Cluster auf der Grundlage eines Regelwerks neu.

Die klassische Linux-Software für ein solches Szenario ist der Linux Virtual Server (LVS, [11]). Er beherrscht eine ganze Palette an Verteilstrategien auf den OSI-Layern 3 und 4 und bietet auch persistente Verbindungen. Ein recht einfaches Load Balancing lässt sich alternativ bereits durch eine geschickte DNS-Konfiguration erreichen: Ordnet der Admin hier einem Namen mehrere IP-Adressen zu (Resource Record Set) erhält er eine gleichmäßige Lastverteilung.

Wer dagegen von den Vorteilen der Layer-7-Lastverteilung profitieren möchte, die beispielsweise spezialisierte Webserver für Skripte, statische Seiten oder Bilder möglich macht, der greift zu Produkten wie Pound [12] oder XLB [13], die allerdings deutlich mehr Rechenpower verschlingen. Der große Vorteil der letztgenannten HA-Lösungen besteht darin, dass die hohe Verfügbarkeit quasi ein Seiteneffekt des in diesem Fall ohnehin nötigen Load Balancing ist.

Fazit

So oder so nützt es im Ernstfall freilich wenig, wenn zwar der Webserver geclustert ist, andere Infrastruktur-Komponenten aber Single Points of Failure darstellen - etwa Router, Switches oder die Internetanbindung. Andererseits: Ein Szenario, das fehlertolerant die meisten denkbaren Ausfälle abfängt, ist zwar möglich, aber auch sehr teuer. In der Regel diktiert hier das Primat der Ökonomie die Lösung des Problems: Die Versicherung sollte keinesfalls teurer sein als der im schlimmsten Fall eintretende Schaden.

Infos

[1] GPFS: [http://www-03.ibm.com/systems/clusters/software/gpfs/index.html]

[2] OCFS: [http://oss.oracle.com/projects/ocfs/]

[3] DRDB: [http://www.drbd.org]

[4] Bonding Driver Howto: [http://www.cyberciti.biz/howto/question/static/linux-ethernet-bonding-driver-howto.php]

[5] Linux-HA 2: [http://www.linux-ha.org]

[6] Pacemaker: [http://www.clusterlabs.org/wiki/Main_Page]

[7] Open AIS: [http://www.openais.org/doku.php]

[8] GFS: [http://sources.redhat.com/cluster/gfs/]

[9] Veritas Cluster Server: [http://www.symantec.com/business/cluster-server]

[10] Lifekeeper: [http://www.steeleye.com/downloads/resource/linux/lifekeeper-for-linux.pdf]

[11] Linux Virtual Server: [http://www.linuxvirtualserver.org]

[12] Pound:[http://www.apsis.ch/pound/index_html]

[13] XLB: [http://sourceforge.net/projects/xlb/]

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 3 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Als digitales Abo

Als PDF im Abo bestellen

comments powered by Disqus

Ausgabe 07/2013

Preis € 6,40

Insecurity Bulletin

Insecurity Bulletin

Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...

Linux-Magazin auf Facebook