wie umsetzen: ausfallsicherer HA und LB Cluster für Apache und MySQL ?

[jugfullasun]

Hallo Forengemeinde,

ich wende mich ans Forum, da bei mir noch etwas Unklarheit besteht.

Problem: Ich soll eine Hochverfügbarkeitslösung für einen Cluster bestehend aus Apache Webservern und MySQL DB-Servern erarbeiten. Wobei die Apache-Server (Kunden-Webpräsenzen) für z.B. Webcontent auf die MySQL-Server zugreifen, beide Server (Apache, MySQL) sollen natürlich redundant mit identischen Diensten/ Datenbestand vorhanden sein für die Ausfallsicherheit.

In etwa in diese Richtung soll es gehen:

http://www.howtoforge.com/setting-up-a-high-availability-load-balancer-with-haproxy-keepalived-on-debian-lenny

Wichtig ist, dass sowohl bei einem Komplettausfall einer Maschine, als auch beim Ausfall einzelner relevanten Dienste/ Deamons (z.B. Apache) ein erfolgreicher Failover zur redundanten Maschine stattfindet. Sprich - auch dann, wenn ein Rechner zwar noch im Netz ist aber trotzdem der wichtige Serverdienst "tot" ist. Das ganze soll natürlich mit Debian realisiert werden.

Gehen wir in einem einfachen Szenario von 2 Apachen und 2 MySQL-Servern aus, die jeweils redundant sind. Eventuell später noch mit Loadbalancer.

Für die MySQL-Server habe ich mit einer Master-Master-Replikation bereits eine ganz passable Lösung gefunden. Zum IP-Failover habe ich bereits VRRPD und UCARP getestet, welche beide gut funktionieren (UCARP hat einige Vorteile), aber "nur" den IP-Failover abdecken. Beim Apache herrscht noch Unklarheit.

Am Liebsten wäre mir eine Lösung aus einem Guss (auch wenns die wahrscheinlich nicht gibt) mit zentraler Konfiguration und Monitoring-Funktionen.

Bei Recherchen bin ich weiterhin auf die folgenden mehr oder weniger etablierten Lösungen/ Konzepte/ Projekte gestoßen:

- Heartbeat - http://www.linux-ha.org/ (erscheint mir veraltet)
- Ultra Monkey - http://www.ultramonkey.org (erscheint mir veraltet)
- LVS / Linux Virtual Server / ipvs - http://www.linuxvirtualserver.org/
- keepalived - http://www.keepalived.org/ (sieht mit am aktivsten aus)
- DRBD - http://www.drbd.org/
- HAProxy - http://haproxy.1wt.eu/
- pound - http://www.apsis.ch/pound/
- weiterhin gibt es noch einige Module für den Apache

Falko Timme hat auf www.howtoforge.de auch eine Reihe Turorials für hochverfügbare Apache Cluster veröfentlicht, die teilweise jedoch leider veraltet sind.

Welche Lösung könnt Ihr empfehlen? Vielleicht stand der eine oder andere bereits vor einer ähnlichen Problematik und hat eventuell praktische Erfahrungen. Hinweise und Anregungen sind willkommen.

Danke

Grüße

[marce]

die meisten Lösungen mit Heartbeat und DRBD (und die meisten anderen SW-Apps) sind mehr oder weniger nicht für Produktivbetrieb geeignet - hängt aber auch von den Anforderungen ab.

SW-Lösungen skalieren meist nicht besonders gut und kommen oft bei den maximal beteiligten Hosts recht schnell an ihre Grenzen.

Modern ist zur Zeit, das über Virtualisierung zu lösen, traditionell verwendet man einen HW-Loadablancer (F5, Cisco, ...) - oder eben auch beides.

Verfügbarkeit kostet - und je mehr 9er hinter dem Komma stehen, desto teuerer wird's. Abzuklären war auch, wie synchron die System denn sein müssen - z.B. ist DRBD (oder ähnliches) für Webserver meist völlig oversized, wenn man entsprechende Deploy-Prozesse und angepasste Umgebungen hat.

[bla!zilla]

Die Apaches sind recht einfach über Heartbeat hochverfügbar zu machen. Produktiv würde ich das aber nicht unbedingt nutzen wollen, da würde ich auch den Weg eines Loadbalancers gehen. Wenn es gar nicht anders geht, tut es auch mod_proxy. Dem würde ich noch mehr vertrauen als Heartbeat.

Bezüglich MySQL würde ich mich eher auf MySQL eigene Tools zur Replikation verlassen, als auf DRBD. Da gibt es ab und an mal lustige Effekte was den Failover angeht, zudem funktioniert das AFAIK nur bei Active/Passive sauber. Active/Active soll zwar gehen, dem würde ich auch aber auch nicht trauen.

Sollen die MySQL Server denn Active/Active laufen, also beide IO liefern, oder reicht dir beim DB Backend Active/Passive?

[marce]

http://www.unixboard.de/vb3/showthread.php?t=43148

[jugfullasun]

Danke für Eure Antworten!


Sollen die MySQL Server denn Active/Active laufen, also beide IO liefern, oder reicht dir beim DB Backend Active/Passive?
Ich denke, dass Active/Passive auch reichen würde.

[bla!zilla]

Dann kann man das über DRBD machen, ist aber heikel. Da habe ich viel Huddel erlebt.

[jugfullasun]

.... und Heartbeat?

[marce]

wobei eine Master-Slave oder Master-Master-Konfiguration eigentlich problemlos ist - da würde ich mich auf DRBD-Spielchen gar nicht erst einlassen...

[bla!zilla]

.... und Heartbeat?

Ja, DRBD und Heartbeat. Heartbeat läuft an und für sich ganz zuverlässig, aber DRBD zickt gerne mal rum.

[jugfullasun]

So,

habe mir die letzten zwei Tage das wohl einzige Buch zum Thema Heartbeat v2 zu Gemüte geführt.
"Clusterbau mit Linux-HA Version 2" von Michael Schwartzkopff, O'Reilly 2008.

Buch -> Amazon (http://www.amazon.de/Clusterbau-mit-Linux-HA-Version-2/dp/3897217791/ref=sr_11_1/278-2058596-0074015?ie=UTF8&qid=1245914035&sr=11-1)

reinlesen bei google books (http://books.google.de/books?id=1PEqrGYcGBgC&pg=PP1&dq=Clusterbau+mit+Linux-HA+Version+2)

siehe Seite 28 - 31 des google books für den schematischen Aufbau (Grafik).

Das Buch ist zwar recht dünn, aber dennoch ganz ordentlich, auch mit Beispiel-Szenarien / Setups. Leider ist das darin gegebene Beispiel-Setup für einen Apache-Cluster gleich wieder mit Loadbalancer via LVS und damit (für) mich zum Anfang bissl zu komplex.

Was mir auffällt - die Konfiguration der CIB (Cluster Information Base) im xml-Stil ist sicherlich fortschrittlicher als die im klassischen Unix-Textdatein-Stil, wie bei Heartbeat v1, aber erscheint mir erstmal ziemlich komplex. Ich denke, ich werde dennoch versuchen, "meinen" Apache-Cluster gleich mit Heartbeat v2 aufzuziehen. Natürlich ist v1 einfacher zu konfigurieren, aber früher oder später müsste dann eh wieder auf Heartbeat v2 migriert werden.

Was meint Ihr?

Hier noch mal ein Auszug (S. 28) aus dem Buch (verstößt hoffentlich nicht gegen die Foren-Regeln)

http://h1603121.stratoserver.net/aufbau-heartbeat2.png
Quelle: Michael Schwartzkopff: Clusterbau mit Linux-HA Version 2

MfG

[bla!zilla]

Sorry, aber gerade die XML Geschichte ist eine Pest! Nicht mehr sauber lesbar, ich fand Heartbeat v1 sehr, sehr viel einfacher und transparenter. Aber was macht man nicht alles fuer eine haessliche GUI...

[jugfullasun]

Sorry, aber gerade die XML Geschichte ist eine Pest! Nicht mehr sauber lesbar, ich fand Heartbeat v1 sehr, sehr viel einfacher und transparenter. Aber was macht man nicharbeitsamt dresdent alles fuer eine haessliche GUI...

... ja, ist schon eine Umstellung, wenn man die Konfiguration im klassischen Unix-Stil über Textdateien gewöhnt ist.

Vor allem da z.B. neue Ressourcen nicht mal eben schnell einfach in die xml eingetragen werden kann, sonder immer über die CLI-Befehle

also erst eine Textdatei mit dem Abschnitt der Ressource anlegen (zb. resource_apache.xml) und dann die neue Ressource mit

# cibadmin -C -o resources -x resource_apache.xml

einlesen.

das Elend ...

hier mal eine "minimalistische" /var/lib/heartbeat/crm/cib.xml für einen Cluster mit 2 Nodes

über den Befehl

# cibadmin -Q

abgerufen. alles klar? :)

<cib admin_epoch="0" have_quorum="true" ignore_dtd="false" num_peers="1" cib_feature_revision="2.0" generated="true" epoch="15" num_updates="10" cib-last-written="Wed Jul 1 04:09:39 2009" ccm_transition="1" dc_uuid="b6b1fe9d-4766-4a16-8cea-551e2cc2ab32">
<configuration>
<crm_config>
<cluster_property_set id="cib-bootstrap-options">
<attributes>
<nvpair id="cib-bootstrap-options-dc-version" name="dc-version" value="2.1.3-node: 552305612591183b1628baa5bc6e903e0f1e26a3"/>
</attributes>
</cluster_property_set>
</crm_config>
<nodes>
<node id="b6b1fe9d-4766-4a16-8cea-551e2cc2ab32" uname="debian1" type="normal"/>
<node id="e3eaa776-8ca9-42c4-b4e1-48810e3b78f6" uname="debian2" type="normal"/>
</nodes>
<resources>
<primitive class="ocf" type="IPaddr2" provider="heartbeat" id="resource_IP">
<instance_attributes id="resource_IP_instance_attrs">
<attributes>
<nvpair name="ip" id="res_IP_IP" value="192.168.50.240"/>
<nvpair name="nic" id="res_IP_nic" value="eth0"/>
<nvpair name="cidr_netmask" id="res_IP_mask" value="24"/>
</attributes>
</instance_attributes>
</primitive>
</resources>
<constraints/>
</configuration>
<status>
<node_state id="b6b1fe9d-4766-4a16-8cea-551e2cc2ab32" uname="debian1" crmd="online" crm-debug-origin="do_update_resource" shutdown="0" in_ccm="true" ha="active" join="member" expected="member">
<transient_attributes id="b6b1fe9d-4766-4a16-8cea-551e2cc2ab32">
<instance_attributes id="status-b6b1fe9d-4766-4a16-8cea-551e2cc2ab32">
<attributes>
<nvpair id="status-b6b1fe9d-4766-4a16-8cea-551e2cc2ab32-pingd" name="pingd" value="0"/>
<nvpair id="status-b6b1fe9d-4766-4a16-8cea-551e2cc2ab32-probe_complete" name="probe_complete" value="true"/>
</attributes>
</instance_attributes>
</transient_attributes>
<lrm id="b6b1fe9d-4766-4a16-8cea-551e2cc2ab32">
<lrm_resources>
<lrm_resource id="resource_IP" type="IPaddr2" class="ocf" provider="heartbeat">
<lrm_rsc_op id="resource_IP_monitor_0" operation="monitor" crm-debug-origin="do_update_resource" transition_key="3:0:c3d87286-16e4-4740-acf1-9f8c8a9b1590" transition_magic="0:7;3:0:c3d87286-16e4-4740-acf1-9f8c8a9b1590" call_id="2" crm_feature_set="2.0" rc_code="7" op_status="0" interval="0" op_digest="a6cdeebf16b79086952f4165c776cd3c"/>
<lrm_rsc_op id="resource_IP_start_0" operation="start" crm-debug-origin="do_update_resource" transition_key="5:0:c3d87286-16e4-4740-acf1-9f8c8a9b1590" transition_magic="0:0;5:0:c3d87286-16e4-4740-acf1-9f8c8a9b1590" call_id="3" crm_feature_set="2.0" rc_code="0" op_status="0" interval="0" op_digest="a6cdeebf16b79086952f4165c776cd3c"/>
</lrm_resource>
</lrm_resources>
</lrm>
</node_state>
</status>
</cib>


@ bla!zilla

Hast Du es schon erfolgreich hinbekommen, den Apache2 mit Heartbeat2 via "Resource Agent" d.h. über LSB-Script, besser noch über OCF-Skript starten/ stoppen zu lassen? Also nicht mehr über /etc/init.d/apache2 start/stop.

Habe dies noch nicht hinbekommen:(. IP-Failover klappt jedoch (siehe xml oben) Soll da nicht auch ein bug in einem der Skripte bei Debian sein?

Obwohl, Du bist ja eher SUSE-User ....

[bla!zilla]

Hast Du es schon erfolgreich hinbekommen, den Apache2 mit Heartbeat2 via "Resource Agent" d.h. über LSB-Script, besser noch über OCF-Skript starten/ stoppen zu lassen? Also nicht mehr über /etc/init.d/apache2 start/stop.

Neee, habe ich noch nicht versucht.



Obwohl, Du bist ja eher SUSE-User ....

Was eine Beleidigung... :eek: Mein Server zu Hause lief mit Debian, mein Rootie läuft mit Debian, aber im Prinzip ist es mir auch egal. Linux ist Linux.

[jugfullasun]

Was eine Beleidigung... :eek: Mein Server zu Hause lief mit Debian, mein Rootie läuft mit Debian, aber im Prinzip ist es mir auch egal. Linux ist Linux.
Nee. Sorry!!! so war das überhaupt nicht gemeint, es kann doch auch jeder die Distri seiner Wahl verwenden (meiner Meinung nach) prinzipell geht doch alles (naja fast alles) analog von Debian auf andere Distributionen zu übertragen

aber im Prinzip ist es mir auch egal. Linux ist Linux.
eben!
warum lief Dein Server? Läuft nicht mehr oder irgendwo gehostet?

Nochmals, hab mich etwas in der Wortwahl vergriffen, war keine Absicht

[bla!zilla]

Schon okay, hab ich mir schon gedacht, dass es unglücklich formuliert war. ;)

Ich hoste nicht mehr zu Hause, sondern lasse hosten.

[jugfullasun]

Ich hoste nicht mehr zu Hause, sondern lasse hosten.
ist bei mir auch so, habe einen vserver bei strato, bin nur leider noch nicht dazu gekommen, mich ernsthaft mit ihm zu beschäftigen (z.B. blog/homepage/fotogalerie etc.)