Hochverfügbarer Cluster - allgemeine Infos

[danibert]

Hallo zusammen,

ich überschütte Euch mal wieder mit Fragen und hoffe, daß ich ein paar Infos sammeln kann:
Da mein derzeitiger managed Server Ende des Jahres ausläuft, habe ich mich entschlossen, dann auf einen eigenen Server in einer Colocation umzusteigen. Ich habe mir also ein Testsystem zum Üben angeschafft und arbeite mich nun langsam in die Server-Administration unter Linux ein.

Der zukünftige Server:
Auf dem Server, der Ende des Jahres online gehen soll, wird folgendes laufen:
Debian, Apache, mod_ssl, Mysql, Perl, Php, Postfix, Vsftpd, Python, Qpopper, Bind 9, Webalizer, SpamAssassin, Openssh
Als Admin-Tool ist VHCS geplant (steht aber noch nicht fest).
Weiter laufen mehrere IPs auf die Maschine, die für einen SSL-Proxy und mehrere unabhängige SSL Zertifikate genutzt werden sollen.

Das Problem:
Ich habe auf dem Server einen Kunden liegen, der eine möglichst hoch verfügbare Lösung für seine Webseite braucht. Also habe ich mir überlegt, das System als hochverfügbaren HA-Cluster (also kein Load-Balancing etc.) auszulegen.

Hardware (Stimmt´s oder stimmt´s nicht?):
Ich plane vorerst einen Aktiv/Passiv-Cluster aus 2 Hardware Nodes. Entsprechend meiner bisherigen Infos, würde ich das System so zusammenstellen:
2 gleiche Rechner mit je 2 LAN-Anschlüssen und ein Switch. Die Rechner werden jeweils an den Switch angeschlossen und noch untereinander verbunden. Ist das soweit richtig?

Wie ist das mit dem Switch, wenn der ausfällt? Ist doch theoretisch ein single point of failure, oder?
Theoretisch müsste ich immer einen Ersatz-Switch vor Ort haben, und im Notfall alle LAN-Kabel umstecken. Kann ich das Problem noch anders umgehen? Gibt es eine Lösung, die hier ohne Ausfallzeit funktioniert?

Software:
Was brauche ich an Software für das Cluster-Management?
Bisher habe ich Wackamole, Heartbeat, DRBD, Veritas Cluster Manager gesehen, aber mich noch nicht näher damit auseinandergesetzt. Habt Ihr hier Erfahrungen oder könnt Ihr mir ein bestimmtes Programm empfehlen, das meinen Anforderungen entspricht?

Wie läuft das mit den mehreren IP-Adressen? Wie wird das auf die einzelnen Hardware-Nodes verteilt?

Wichtig wäre mir, daß das Ganze auch mit zwei hardwareseitig unterschiedlichen Rechnern funktioniert, damit bei Bedarf eine Aufrüstung der Hardware im laufenden Betrieb möglich ist.

Danke im Voraus
Danibert

 

[pillul]

Ganz grundlegend,

ich würd die 2 Server nicht im gleichen Netz betreiben.

ICh würde sogar 2 vollkommen unterschiedliche Carrier wählen.

Hatt den Vorteil das bei Netz/Routing Problemen trotzdem eine Erreichbarkeit garantiert ist.

mfg

Andreas

 

[mkr]

Wie ist das mit dem Switch, wenn der ausfällt? Ist doch theoretisch ein single point of failure, oder?
Theoretisch müsste ich immer einen Ersatz-Switch vor Ort haben, und im Notfall alle LAN-Kabel umstecken. Kann ich das Problem noch anders umgehen? Gibt es eine Lösung, die hier ohne Ausfallzeit funktioniert?

Ja: zwei Switches. Der zweite muss fähig sein zu erkennen, ob der erste läuft. Falls ja, darf er keine Pakete weiterleiten, sonst wären sie doppelt.

Der nächste Single Point of Failure ist dann die Firewall (falls Du eine hast). Aber auch die kann man redundant auslegen...

Kostengünstiger ist es, wenn Du eine Maschine als Loadbalancer einsetzt. Die ist dann natürlich der SPoF, aber die Ausfallwahrscheinlichkeit ist relativ gering. Festplattenfehler fallen beispielsweise weg, weil die darauf laufende Software die Platten nach dem Start nicht mehr braucht. (Müssen auch keine Festplatten sein, man könnte auch eine CF-Karte verwenden.)

Als Software dafür eignet sich pound.

Was brauche ich an Software für das Cluster-Management?
Bisher habe ich Wackamole, Heartbeat, DRBD, Veritas Cluster Manager gesehen, aber mich noch nicht näher damit auseinandergesetzt. Habt Ihr hier Erfahrungen oder könnt Ihr mir ein bestimmtes Programm empfehlen, das meinen Anforderungen entspricht?

Für die Datenspeicherung wäre ein SAN natürlich ideal (aber teuer). Ein RAID1 über jeweils eine lokale Partition und ein über DRBD vom anderen Server gemountetes Volume würde aber auch gehen. Eine Anleitung dazu findest Du auf Setting Up A Highly Available NFS Server | HowtoForge - Linux Howtos and Tutorials.

Wie läuft das mit den mehreren IP-Adressen? Wie wird das auf die einzelnen Hardware-Nodes verteilt?

Bei Clustern hat man meist eine IP für den Cluster. Sie "gehört" dem aktiven Server. Wenn der ausfällt, merkt das der andere Server (zB. über Heartbeat oder Diensteüberwachung) und übernimmt die IP.

Beim Szenario mit dem Load Balancer hätten beide Rechner eine andere IP. Von aussen greift man nur auf die IP des Loadbalancers aus.

Wichtig wäre mir, daß das Ganze auch mit zwei hardwareseitig unterschiedlichen Rechnern funktioniert, damit bei Bedarf eine Aufrüstung der Hardware im laufenden Betrieb möglich ist.

Das ist kein Problem. Auf dem Load Balancer kannst Du auch einen Server vorübergehend auf inaktiv setzen, wenn Du ihn zwecks Hardware-Upgrade ausschalten willst.

 

[Thorsten]

Hallo!
Mir fehlt unter dem Punkt Hardware noch eine Komponente: Gemeinsamer Storeage. Optimaler Weise über einen Fibre Channel Switch angebunden.

mfG
Thorsten

 

[amnesie]

Ich habe auf dem Server einen Kunden liegen, der eine möglichst hoch verfügbare Lösung für seine Webseite braucht. Also habe ich mir überlegt, das System als hochverfügbaren HA-Cluster (also kein Load-Balancing etc.) auszulegen.

Bitte nochmals einen Schritt zurückgehen. Was bedeutet "hochverfügbar" in deinem Fall? Was würde dein Kunde sagen, wenn du den Server zweimal im Monat am frühen Sonntag morgen 2 Stunden runterfahren kannst zu Wartungszwecken? Wenn das drin ist, dann brauchst du keinen Cluster. Ein Cluster bringt nur was, wenn die Anforderungen wirklich 99,99% Verfügbarkeit sind. 99% kriegt man noch recht gut mit einer Maschine hin, insbesondere wenn es Serverhardware ist (also hot-swap Festplatten, im Betriebb tauschbare Lüfter usw).

Und wovor willst du dich absichern? Hardware-Ausfälle? Dann würde ich für den Server entsprechende Wartungsverträge abschliessen, damit du fehlerhafte Hardware innerhalb von 4h getauscht bekommst. Kostet zwar Geld, aber ist billiger als ein HA-Cluster.

Warum ich in diesem Fall gegen Cluster bin: Ich habe selbst ein paar Cluster unter den Fingern und das Zeugs ist ziemlich fragil. Kollegen berichten, daß sie mit Cluster eine niedrigere Verfügbarkeit hatten als ohne, weil die Clustersoftware (bzw die beteiligten Betriebssystem-Komponenten) buggy war. Und da habe ich den finanziellen Aspekt erstmal noch aussenvor gelassen, ein hochverfügbares shared-storage inklusive entsprechender FC-Infrastruktur ist nicht billig.

Also schau bitte erstmal zu, daß du gute Hardware hinstellst, bevor du einen Cluster aufbaust.

 

[orth-it.de]

Wenn du selbst noch keine Erfahrung mit Clustern hast, kannst du dich vielleicht besser an entsprechende Unternehmen wenden, die Cluster betreuen. Ein Ansprechpartner könnte da Host Europe sein.

Zunächst solltest du dir aber bewusst werden, wie hoch dein Budget ist, wie hoch die Verfügbarkeit tatsächlich sein soll und welche Anwendungen auf dem Cluster laufen werden.

 

[stefan44]

Eine recht einfache Möglichkeit, mit sehr geringem Aufwand Redundanz zu erzeugen, ist das in OpenBSD und FreeBSD integrierte CARP.

Prinzip:
2 Server haben nach außen hin die gleiche IP-Adresse und überprüfen sich intern über eine zweite NIC (Crossoverkabel genügt). Geht einer down, übernimmt der andere die Funktion; auch ein primitives Load Balancing ist realisierbar, aber ja nicht Dein Anliegen. Den Content könnte man per rsync identisch halten.

Wenn man die beiden Rechner an unterschiedliche Stromkreise und Switches hängt, vermeidet man die üblichen SPF.

Ich selbst habe das bei zwei FTP-Servern realisiert und fand das Setup ziemlich simpel.

 

[amnesie]

Das Problem ist ja nicht das HA der Rechner und der Verbindungen zu ihnen an sich, sondern das HA der einzelnen Komponenten. Und rsync ist kein Mittel, um Content in einem Cluster zu synchronisieren... Schon gar nicht, wenn auf beiden Hälften Änderungen durchgeführt werden.

 

[stefan44]

Das Problem ist ja nicht das HA der Rechner und der Verbindungen zu ihnen an sich, sondern das HA der einzelnen Komponenten. Und rsync ist kein Mittel, um Content in einem Cluster zu synchronisieren... Schon gar nicht, wenn auf beiden Hälften Änderungen durchgeführt werden.

Wenn ich den Threaderöffner richtig verstanden habe, geht es darum, einem Kunden eine sehr hohe Verfügbarkeit zu zusichern. Sollte die Zuverlässigkeit eines Einzelrechners nicht ausreichen, bietet sich beispielsweise an, via CARP einen zweiten "hot spare" einzubinden.

Dabei werden gerade nicht an zwei Rechnern gleichzeitig Änderungen durchgeführt, weil immer nur einer online ist.

Natürlich kann man die Redundanz in jede beliebige Höhe treiben, was aber hier nicht das Thema zu sein scheint.

 

[amnesie]

Ja, allerdings nur an einem Rechner die Änderungen durchzuführen ist ja auch unsinnig, du brauchst eine Synchronisation. Und rsync ist dafür denkbar ungeeignet ... Dann eher schon drbd.