Clustering und Hochverfügbarkeit

[posi]

Hallo root's!

Habe gerade mal ein wenig nach Beiträgen zum Thema Hochverfügbarkeit, Clustering und Load-Balancing gestöbert und gesehen das es ja schon ein paar Leute gibt die sich damit auseinandersetzen oder es mal getan haben. Bisher habe ich aber mehr abschreckendes gelesen als Erfolgsmeldungen :-) Deshalb wollte ich ein paar von meinen Erfahrungen teilen - ich "spiele" gerade mit 2 root Server herum und versuche diverse Ideen zum Thema in dieser Umgebung umzusetzen....

Berufliche arbeite ich bei einem ISP, wir haben alle "customer facing systems" redundant and teilweise mit load-balacing laufen, privat sind die Mittel naturgemäss für solche Projekte nahezu null und so versuche ich das Beste für wenig Geld zu erreichen. Nach meinen bisherigen Erfahrungen würde ich auf jedenfall erstmal raten sich nur mit ausreichender Erfahrung an das Thema zu wagen wenn er produktiven Einsatz überhaupt anstrebt :) Beim Lesen bitte ich zu beachten das mir schon klar was für "richtige" HA/HP System nötig ist - vorhanden sind aber nur Standardrootserver, also sind Begriffe wie Clustering, Hochverfügbarkeit oder Load-Balacing immer als "best-efford" Technik zu sehen.

Die aktuellen root Server für diese Projekt sind 1Ghz P-III Kisten mit nem halbe Gig Speicher und einer 40GB Platte. Ziel ist es, mit diesen Systemen eine möglichst hohe Verfügbarkeit von Standardservices zu bieten, d.h. DNS/HTTP/FTP/SMTP/IMAP/POP/DB (incl. den "secure" Varianten) zu erreichen, später dann ggf. noch "load balancing". Als kleines Extra konnten die Server jeweils mit einer zusätzliche Netzwerkkarte ausgestattet werden, mit einem crossover Kabel haben die beiden Rechner hier einen eigenen/zusätzlichen Link. Darüber läuft ein tinc VPN.

Der Traffic für beide Server soll natürlich auch optimal ausgenutzt werden, wenn möglich. Jeder Server hat 4 IP's. Was natürlich/leider nicht möglich ist ist die Benutzung der IP's eines Servers auf dem Anderen. Aber auch hier gibt es eine Lösung.

Auf Kosten von etwas Performance habe ich mich entschieden die Dienste selber in User Mode Linux zu kapseln. Dadurch werden aber einige wesentlich einfach... Die beiden Server dienen in erster Linie dazu eine Basisinfrastruktur für die UML Boxen zu bilden. Dazu zählt DNS, Firewall, das Routen der IP's, syslog. Die Dienste selber sind auf je 2 UML's verteilt, einmal "Web", einmal "Mail". Jedes UML hat neben 2G System- eine 10G Datenpartition. Ingesamt existieren also 6 Systeme (bzw. die weitere System sind Supportsystem oder Testrechner). Syslog der UML's ist auf die beiden realen Boxen umgeleitet, das hilft ungemein beim Problemlösen wenn alle Rechner in einer Datei sind und selbst wenn ein realer Host ausfällt sind trotzdem alle Logs einsehbar.

Die 10G Datenpartitionen enthalten die komplette Konfiguration der Host-unabhängigen Systeme - alles Host-spezifische liegt normal auf der Partitions des UML's. Ã?ber DRBD werden die Datenpartitionen zwischen den beiden Partner auf dem aktuellen Stand gehalten, Network-RAID-1 wir der Author es schön verglichen hat... :) Nur ein Node (der aktive) hat diese Partition aktuell gemountet, der andere Node ist secondary bis er die Resource übernimmt. Da wirft ein Problem auf für die spätere Lastverteilung, wenn der 2. Knoten z.b. auch Requests beantworten soll - ihm aber die Daten fehlen.

2 UML's bilden einen Webcluster. Erstes Ziel war "Hochverfügbarkeit". Deshalb läuft je ein UML auf einem realen System, und zwar ist im Normalfall der Webserver auf dem ersten realen System und der Mailserver auf dem zweiten System. Fällt ein reales System (oder auch nur das "andere" dieses Services) übernimmt der andere Knoten. Alle Dienste laufen dann auf einem Rechner, nur in verschiedenen UML's. Für's monitoring der UML und den fail-over läuft natürlich heartbeart.

IMHO das größte Problem für eine HA Lösung auf root Servern ist das fehlen von IP-Migration - der ganze Cluster wäre etwas einfach zu bauen: falls ein Rechner ausfällt übernimmt der andere einfach IP + Dienste und macht weiter. Da das nicht vorhanden ist benutze ich für den "poor mans failover" die dynDNS Features von bind9.

Das sieht etwa so aus:
DNS: http://www.domain =CNAME=> web1.dyn.domain =CNAME=> (aktueller Node, A record)

Die dyn.domain ist aus Sicherheitsgründen zwischengeschaltet und nur diese akzeptiert dynamische Updates mit nsupate. Im Zweifel kloppt mir jemand diese Domain kaputt, der Rest der Domain bleibt aber ok - DNSsec ist natürlich Pflicht.... Wenn heartbeat den Ausfall des anderen Nodes erkennt und die Resourcen übernimmt, sendet es als erstes ein nsupdate mit dem neuen Ziel für den Webserver. Die TTL für diesen einen CNAME Eintrag in der dyn.domain bestimmt die Zeit, die für den fail-over Prozess notwendig ist (plus eine fixe Zeitspanne) - hier muss man abwägen: setze ich die TTL sehr niedrig an, z.B. 15s erhöht sich der DNS Traffic entsprechend und auch auf die Seitenperformance sind Auswirkung zu erwarten. Setze ich eine hohe TTL ist meine Seite länger nicht erreichbar... meine Experimente runter bis 30s TTL funktionieren bei bisherigen über alle möglichen Provider hinweg sehr gut (Umschaltzeit/Ausfallzeit ~ 30-40s).

Ja, das ist erstmal mehr geworden als ich eigentlich wollte... primär wollte ich eigentlich gerne Erfahrungen über erfolgreich angewandte Techniken anfragen. Natürlich gibt in obriger Konstruktion immer noch einige kritische Punkte und nicht alles interessante ist erklärt - ich überlasse es Euch nachzuhaken :)

Danke für's Lesen + Gruss
Posi

[dodolin]

Sehr interessanter Bericht, danke!

Was mich etwas stört ist:
Du schreibst, du möchtest das Szenario mit "Standardrootservern" aufbauen, sprichst dann aber von einer zusätzlichen NIC mit Crossoverkabel. Ich glaube kaum, dass man das bei einem "Standardrootserver" bekommt. Dazu muss man wohl in den allermeisten Fällen wieder gleich zu teureren Housingangeboten greifen, bei denen man die eigene Hardware unterstellen darf. Wenn man aber eh schon eigene HW platzieren muss, könnte man das ganze aber auch gleich noch etwas besser gestalten...

Das waren nur meine ersten Gedanken dazu.

[fritz]

Danke für's Lesen + Gruss
Posi

Hi Posi, danke für's Schreiben
Ja, Dodolins Einwand ging mir auch durch den Kopf. Aber wer nicht seine schon vorhandenen 'Rootserver' bei einem der Massenanbieter umbauen will, sondern die Sache jetzt neu plant, findet in der Preisklasse inzwischen viele 'kleinere' Anbieter, die günstige Server vermieten und trotzdem so flexibel sind, Erweiterungen und Crossoverkabel zu ergänzen. (hatte ich schon - aber nur für 'simples' Backup)
Wobei ich auch Lösungen interessant fände, bei denen 1 Server bei Anbieter A und der andere bei Anbieter B in einem anderen RZ steht. Dann hätte man auch bei Ausfall eines Subnetzes, eines Routers usw die Erreichbarkeit seiner Dienste noch verbessert. Bei den heutigen Inklusivtrafficmengen und Preisen für Gigabytes könnte Daten-abgleich, -austausch, -verteilung auch dort noch wirtschaftlich sein.
Ich habe mangels Bedarf keinerlei Erfahrung mit Hochverfügbarkeitslösungen, werde aber Dein Projekt neugierig verfolgen, da ja auch die Punkte wie Trennung der Dienste durch UMLs, Load-Balancing usw interessant sind.
Gruss Fritz

[captaincrunch]

Gerade was HA angeht, finde ich Xen eine höchst interessante Sache. Der große Vorteil gegenüber UML dabei ist die "live migration" einer virtuellen Maschine auf eine andere. Mit ein wenig Handarbeit funktioniert das sogar noch über die Layer 2-Grenze hinweg.

Ansonsten: siehe dodolin. ;)

[posi]

Hallo nochmal!

@dodolin:
Im Prinzip hast Du Recht, aber die zusätzliche Netzwerkkarte ist eher ein zusätzliches Sahnehäubchen, keine Notwenigkeit! Wie beschrieben besteht eh eni VPN zwischen den beiden Servern, ob es nun über den cross-over Link geht oder über den Switch des Anbieters ist für das Funktionsprinzip unwichtig. Die Server sind übrigens normale "Billig"rootserver für etwas mehr als 30 Euro das Stück. Für eine semiprofessionelle Lösung würde ich gerne mal n ganzes Rack mit eigenem Switch habe, Hetzner hat da z.B. n IMHO attraktives Angebot.... Mit ganz eigener Hardware sind und vollem Zugriff auf die unmittelbar vorgeschaltete Netzwerkhardware wäre natürlich eine ganz andere Sache :-)

@Fritz:
Wäre sehr an diesen kleinen und flexiblen Anbietern interessiert, ggf. via Mail um das hier nicht zu ner Anbieterwerbung verkommen zu lassen :) Ich fand es nicht einfach einen preiswerten Hoster zu finden der auf meine Extrawünsche eingeht. Ich war heilfroh die 2. NIC zu kriegen -- eine IP auf beiden Server zu nutzen wäre IMHO das geilste Feature, aber das wollte keiner bisher...

Ã?ber eine Trennung der Server in unterschiedliche Rechenzentren habe ich auch nachgedacht, aber wegen DRBD dann doch gelassen... nach meinen bisherigen Erfahrungen war die Netzanbindung nie das zentrale Thema, eher die Stabilität eines Servers. Ich kann den Traffic den DRBD verursacht noch nicht zuverlässig einschätzen, im Zweifelsfall, sollte eine komplette Synchronisation nötig sein, gehe locker 10G Nutzdaten + unbekannter Overhead durch die Leitung. Je nach Freitraffic kann das ja kritisch sein. Technisch sehe ich aber kein Problem das so zu machen - ich packe das mal auf meine ToDo-Liste in die Sektion "Experimente". Versuche in den nächsten Wochen mal einen weiteren 1&1 Server mit in den Cluster zu packen.

@CaptainCrunch:
XEN steht auch auf meiner ToDo Liste unter "Unbedingt bald testen!". Virtualisierungtechniken wie vmware, UML oder XEN finde ich extrem interessant! Ich denke das hier die Zukunft liegt. Bei XEN hatte ich den Eindruck das ein Zugang zur Konsole muss ist und so für einen root Server nicht unbedingt erste Wahl ist - stimmt das? Die Möglichkeiten auf dem Host selber Komponenten zu installieren finde auch sehr attraktiv, geht das in XEN? Speziell Live-Migration finde ich ziemlich sexy aber das geht wohl kaum wenn ich einen Knoten einfach ausknipse, oder?

Eine Frage zum Abschluss...
Im ersten Posting habe ich kurz die Problematik erwähnt die Daten auf der DRBD Partition mehr als einem Node zur Verfügung zu stellen. Ich wollte dafür NFS benutzen. Im Prinzip auch kein Problem, bis ich an folgendes Problem gestossen bin: Auf zwei Nodes laufen zwei NFS Server. Jeder Server hat ein Datenpartition, die via DRBD auf den anderen Node gespiegelt werden. Jeweils eine Partition pro Node ist aktiv und über NFS erreichbar, die andere ist als secondary im standby. Fällt nun ein Node aus soll der andere Node BEIDE Partitionen über NFS bedienen. Problem sind die Daten in /var/lib/nfs - die Clients sollen ohne Ausfall und neu mounten von einem Failover nichts mitbekommen. Dazu müsste man die Daten von z.B. statd der beiden Server zu einem gemeinsamen Datensatz mergen. Falls es hier Lösungsansätze oder Ideen gibt -> her damit! ;))

Gruss,
Posi

PS: War wohl schon etwas müde gestern - sooo viele Fehler - Sorry :))

[posi]

Gerade was HA angeht, finde ich Xen eine höchst interessante Sache. Der große Vorteil gegenüber UML dabei ist die "live migration" einer virtuellen Maschine auf eine andere. Mit ein wenig Handarbeit funktioniert das sogar noch über die Layer 2-Grenze hinweg.

Ich habe mich gerade nochmal (theoretisch) mit Xen beschäftigt und würde gerne wissen wie bei einer Livemigration denn die Netzwerkkonfiguration weiter funktionieren soll solange der Hoster nicht zulässt die IP auf mehreren Server zu nutzen??

Gruss,
Posi

[Joe User]

Kurzer Einwand: Wäre in diesem Anwendungsfall nicht ein Proxy sinnvoll, um das IP-Problem zu umgehen?

[posi]

Kurzer Einwand: Wäre in diesem Anwendungsfall nicht ein Proxy sinnvoll, um das IP-Problem zu umgehen?

Das ist dann ja leider wieder ein "single point of faiure" -- damit ist nichts gewonnen...

Gruss.
Posi

[Joe User]

Wenn der Proxy auf dem UML-Host läuft ist es doch egal, da wenn der UML-Host ausfällt automatisch auch die UML-Guests ausfallen, oder habe ich etwas übersehen?

[posi]

Wenn der Proxy auf dem UML-Host läuft ist es doch egal, da wenn der UML-Host ausfällt automatisch auch die UML-Guests ausfallen, oder habe ich etwas übersehen?

Also erstmal sollte man davon ausgehen das einer der realen Server immer ausfallen kann - d.h. auch die IP (oder IPs) dieses Hosts sind nicht mehr verfügbar. Normalerweise kann ich die IP(s) des aufgefallenen Hosts mit ip-aliasing einfach "rüber" auf eine andere Maschine holen. Würde ich das m.W. bei z.B. 1&1 machen macht der Switch sofort dicht für den Port. Ich muss aber für bestmögliche Verfügbarkeit in der Lage sein den Dienst auf beiden Servern betreiben zu können - inkl. Erreichbarkeit.

Für den Fall das "nur" das UML mit einem Dienst ausfällt und beide Hosts noch da sind kann ich die IP doch auf Beiden benutzen. Dazu muss Host1 ggf. die IP nicht zum eigenen UML leiten sondern über den Host2 zu einem anderen UML. Ausser den DNS Eintrag des Dienstes zu ändern ist mir keine andere Möglichkeit bekannt einen Dienst in root Server Umgebungen umzuschalten.

Gruss,
Posi

[thrawn1024]

AFAIK kann man auch bei diversen rootserver anbietern die ip's seiner rootserver nach belieben austauschen.. (sofern die server im selben subnetz untergebracht sind)

das ganze mit einer 2. netzwerkkarte + heartbeat sollte die ganze konfiguration schon wesentlich erleichtern, oder? (wobei damit natürlich auch nur der ausfall eines hosts, und nicht der des gesamten subnetzes abgesichert ist..)

gruß,
thrawn

[Joe User]

Theoretisch sollte sich http://httpd.apache.org/docs-2.0/mod/mod_proxy.html (Reverse-Proxy) auch auf andere Dienste beziehungsweise komplette UML-Guests adaptieren lassen. Es ist zwar nur ein Workaround im Workaround...

[posi]

AFAIK kann man auch bei diversen rootserver anbietern die ip's seiner rootserver nach belieben austauschen.. (sofern die server im selben subnetz untergebracht sind)

Das habe ich versucht aber bei der IP Sache bin ich überall auf taube Ohren gestossen. Ã?berall wo ich akzeptable Rahmenbediengungen gefunden habe... An Tipps welche Anbieter das explizit machen bin ich natürlich weiterhin hochinteressiert!

das ganze mit einer 2. netzwerkkarte + heartbeat sollte die ganze konfiguration schon wesentlich erleichtern, oder? (wobei damit natürlich auch nur der ausfall eines hosts, und nicht der des gesamten subnetzes abgesichert ist..)

Ja, das wäre meine Traumkombi... :) Damit liesse sich schon was halbwegs seriöses hinbekommen... Dann würde ich es aber ohne die UML's auf dem puren Host machen. Weniger flexibel aber ne Spur solider...

Gruss,
Posi

[felixs]

Interessantes Thema, daher hänge ich mich hier einfach mal mit an...

Ich habe derzeit ähnliche Ã?berlegungen, wobei es bei mir nur um SMTP, IMAP/POP3, Mails (Filesystem) sowie eine Webanwendung geht.

Hauptziel soll die Ausfallsicherung sein, d.h. Vermeidung von Supportanfragen. Das ganze natürlich mit Standard-Rootservern und zur Umgehung von Netzwerkausfällen mögl. auch in zwei getrennten Rechenzentren/Hostern.

Bisher hatte ich mir folgendes überlegt:
Die Mails kann ich per rsync oder etwas Handgestricktem synchronisieren, kein Problem.

SMTP: mehrere MX-Records.

IMAP/POP3: Etwas kniffliger. Hier könnten vielleicht mehrere A-Records die Lösung sein? Hauptziel ist: Client-Mailprogramm erreicht einen Server nicht und soll dann den anderen probieren.

Ein Problem ist bei mir auch noch MySQL (Benutzerdaten, DSPAM). Die Benutzerdaten ändern sich eher selten und wenn nur über das Webinterface, so dass ich hier eine manuelle Synchronisierung einbauen kann.

Außerdem wird DSPAM als Spamfilter eingesetzt, woraus sich natürlich das Problem ergibt, dass DSPAM sehr oft in die MySQL-Datenbank schreibt. Als Lösung habe ich angedacht, dass false negatives nur auf einem Server trainiert werden (das geht, da SPAM ausgefiltert wird und so die Originalmail mit allen Headern auf beiden Rechnern zur Verfügung steht). Ein entsprechender Trainingmode (TOE, TUM) sollte die Schreibzugriffe auf die DB einschränken und 1x pro Tag wird dann ein dump eines Servers auf den anderen gespielt.

Schwieriger wird es sein, false positives zu trainieren, da DSPAM hierbei die Tokens in der DB speichert. Diese müssen halt per Script aus der anderen DB entnommen und in die Master-DB eingespielt werden.


Insgesamt also keine Cluster-Lösung, sondern eine sehr stark auf meine Bedürfnisse zugeschnittene Architektur mit manueller Synchronisation, was die MySQL-Daten betrifft.

Comments? Insbesondere würde mich interessieren, ob es Erfahrungen gibt, was bestimmte Mailclients machen, wenn sie mehrere A-Records bekommen und eine IP nicht erreichbar ist.

fs

[schani]

Die einfachste Möglichkeit für eine Erhöhung der Ausfallsicherheit wäre doch das DNS seitige automatische Umschalten der IP Adresse auf den 2. Server.

Die Dateien sind ausreichend Zeitnah abgleichbar über rsync. Die andere Sache ist sicher mySQL was aber in eine Richtung per Replikation funktioniert.Fällt jetzt Server1 aus müsste man nur automatisch auf Server2 umschalten können. Dann würde alles weiterlaufen und die Daten könnten auch auf Server2 in die Datenbank geschrieben werden. Der Aufwand ist etwas größer um die Daten nach dem reparieren von Server1 wieder zurückzuschreiben, da auch die mySQL Daten nicht vergessen werden dürfen. Die Emails können auch wieder per imapsync abgeglichen werden (naja, nicht gerade schön).

Gut, ist dann nur noch zu klären wie man den DNS dzu bringt umzuschalten. 2 IPs eintragen bringt nur round robin. Aber ist es möglich einen A Eintrag und für den 2. Server einen CNAME Eintrag anzulegen ?

Welche Lösung gäbe es noch ?

Christian