PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Infrasturktur um Hochverfügbarkeit zu gewährleisten?



Kaimane
07.01.11, 10:43
Hallo zusammen!

Ich befasse mich seit einiger Zeit bzgl. Hochverfügbarkeit mit der Frage, welche Lösung für uns die Sinnvollste ist.
Wir haben derzeit mehrere Root-Server, die alle unabhängig voneinander arbeiten (Web, Mail, SQL, DNS, ...).
Jedoch sind sie ein wenig in die Jahre gekommen und eine vernünftige Struktur gibt es ebenfalls nicht mehr.

Nun ist der Gedanke einen ganz neuen Weg zu gehen, mit einem leistungsstarken Server, der ebenfalls alle Aufgaben abdeckt. Jedoch ist es ganz wichtig, dass er - bei einem Ausfall - sofort durch einen anderen Server ersetzt werden kann (failover Prinzip).

Momentan schweben mir zwei Ideen vor:


Internet -> IP-Loadbalancer -> (2x Root-Server)
Der IP-Loadbalancer (soll nur als FailOver dienen) überwacht die dahinter liegenden Server.
Die beiden Root-Server werden ständig über DRBD miteinander synchronisiert, sodass zu jeder Zeit auf beiden Maschinen der gleiche Datenbestand vorhanden ist.
Internet -> Verwaltungsserver (kleine Cloud)
Internet -> IP-Loadbalancer -> (2x Root-Server) -> NAS / SAN
In diesen Fall ist es so, dass es neben den beiden Root-Servern einen kleine Cloud / MiniRoot gibt, die lediglich als DNS-Server eingesetzt wird. Zudem soll auf dieser Cloud Plesk laufen, um die Server zu verwalten.
Die beiden Server werden in diesem Fall nicht miteinander synchronisiert, da der Datenbestand hinter den Servern liegt und zwar auf einem redundanten NAS / SAN.


Nun meine Frage an euch:


In wie weit ist es möglich Idee 1 umzusetzen?
Die Frage bezieht sich speziell auf die Synchronisation der mySQL DB und vor allem wie regelt man das, die beiden Server durch Plesk verwaltet werden?
Was haltet ihr von Idee 2?
In meinen Augen eine sinnvollere Lösung aufgrund dessen, dass die Synchronisierung wegfällt. Einzige Überlegung ist, ob es funktioniert Plesk auf einer kleinen Cloud (die nur der Verwaltung dienen soll) laufen zu lassen und damit die beiden Server zu "steuern" (eMail-Accounts verwalten, Webs anlegen, ...).
Oder müsste Plesk auf den beiden Servern laufen? Aber wie verhält es sich dann mit den Datenbeständen?


Was haltet ihr davon? Würdet ihr mir zustimmen oder könnte es in euren Augen Probleme geben?
Wie habt ihr eure Hochverfügbarkeit aufgebaut?

Wichtig in diesem Fall ist, dass Plesk nicht durch andere Panels ersetzt werden darf. Plesk ist zur Verwaltung Voraussetzung.

Würde mich über rege Beteiligung an diesem Thread freuen!
Vielen Dank schon mal im Voraus!

bla!zilla
07.01.11, 11:25
Hallo. Im Fall 1 ist dein Loadbalancer der SPoF, da kann man nicht von Hochverfügbarkeit reden. DRDB ist wunderbar geeignet um MySQL Datenbanken und Webserver zu spiegeln (unidirektional). DNS sollte auch über Bordmittel, sprich Zonentransfer, kein Problem sein.

Fall 2 ist deutlich komplexer. Bist du sicher, dass den Begriff "Cloud" richtig einordnest? Zudem bringt die ein gespiegeltes Storagesystem in einem SAN erst einmal nicht viel. Zudem musst du einen Hoster finden, der dir sowas bezahlbar anbietet.

Kaimane
07.01.11, 12:09
Hallo bla!zilla,

vielen Dank für deine schnelle Antwort.


Hallo. Im Fall 1 ist dein Loadbalancer der SPoF, da kann man nicht von Hochverfügbarkeit reden.
Der Loadbalancer ist ein SW-Loadbalancer und wird vom Hoster zur Verfügung gestellt. Zudem fungiert er aber auch als FailOver. Er prüft im Sekundentakt, ob der Master da ist, falls nicht, schickt er die Anfrage zu Server 2. Loadbalancing kann auch deaktiviert werden.



DRDB ist wunderbar geeignet um MySQL Datenbanken und Webserver zu spiegeln (unidirektional). DNS sollte auch über Bordmittel, sprich Zonentransfer, kein Problem sein.

Das heißt eine Master / Slave Verbindung.
Was würde denn passieren, wenn der Master für zwei Tage ausfällt (HW defekt) und währenddessen Änderungen auf dem Slave gemacht wurden.
Wird sich der Master (nachdem er wieder on ist) mit dem Slave Synchronisieren, also zieht sich den aktuellen Stand vom Slave?



Fall 2 ist deutlich komplexer. Bist du sicher, dass den Begriff "Cloud" richtig einordnest?
Mit Cloud war eigentlich nur ein leistungsschwacher Root-Server gemeint, der lediglich das DNS verwaltet sowie Plesk bereitstellt.
Bezüglich Plesk ist die Frage, ob das so funktionert, wie ich mir das vorstelle. Man müsste wahrscheinlich im Prinzip "nur" Web-, Mail- und SQL-Verzeichnis vom NAS mounten (wie auch auf den anderen beiden Servern).



Zudem bringt die ein gespiegeltes Storagesystem in einem SAN erst einmal nicht viel. Zudem musst du einen Hoster finden, der dir sowas bezahlbar anbietet.
Der Gedanke ist, ein NAS (HW Raid1, halbstündliches Snapshot zum Backup-Server) hinter die zwei (bzw. drei) Server zu hängen und alle gleichzeitig darauf zugreifen zu lassen.
Auf dem NAS befindet sich ein ClusterFS, wodurch der gleichzeitige Zugriff / das gleichzeitige Mounten gewährleistet wird.

Ist da bei mir ein Denkfehler, oder könnte das so (Fall 2) funktionieren?

Vielen Dank noch mal für eure Unterstützung!

bla!zilla
07.01.11, 12:26
Der Loadbalancer ist ein SW-Loadbalancer und wird vom Hoster zur Verfügung gestellt. Zudem fungiert er aber auch als FailOver. Er prüft im Sekundentakt, ob der Master da ist, falls nicht, schickt er die Anfrage zu Server 2. Loadbalancing kann auch deaktiviert werden.

Trotzdem ein SPoF, solange der nicht redundant ist.



Das heißt eine Master / Slave Verbindung.
Was würde denn passieren, wenn der Master für zwei Tage ausfällt (HW defekt) und währenddessen Änderungen auf dem Slave gemacht wurden.
Wird sich der Master (nachdem er wieder on ist) mit dem Slave Synchronisieren, also zieht sich den aktuellen Stand vom Slave?


Natürlich kann man das so einrichten. Mann kann natürlich auch den Slave solange weiterlaufen lassen, bis dieser auf einen Fehler läuft ein ein Failover passiert.




Der Gedanke ist, ein NAS (HW Raid1, halbstündliches Snapshot zum Backup-Server) hinter die zwei (bzw. drei) Server zu hängen und alle gleichzeitig darauf zugreifen zu lassen.
Auf dem NAS befindet sich ein ClusterFS, wodurch der gleichzeitige Zugriff / das gleichzeitige Mounten gewährleistet wird.


Das mag für Webinhalte funktionieren, aber nicht für Datenbanken.

Kaimane
07.01.11, 13:23
Trotzdem ein SPoF, solange der nicht redundant ist.
Die Redundanz ist gegeben.



Das mag für Webinhalte funktionieren, aber nicht für Datenbanken.

Wie würde das ganze denn mit der Datenbank von statten gehen? Wie wird soetwas eingerichtet, damit alle auf den selben DB-Bestand zugreifen können? Es muss ja iwie kontrolliert werden, dass die Schreibzugriffe auf die DB nacheinander erfolgen.

Was wäre, wenn man aus Fall 1 und Fall 2 einen Fall 3 schafft?!

Loadbalancer / FailOver
Verwaltungsserver / DNS
2x Root-Server


Verwaltungsserver bleibt wie gedacht, DNS und Plesk.
Die beiden Roots laufen über DRBD Master / Slave Modus.
Der Loadbalancer wird so eingestellt, dass immer nur ein Server die Anfragen bekommt (reine failover Lösung).

Vorgehensweise / Konfiguration:
Auf dem Master müssen die entsprechenden Verzeichnisse für Web und Mail über NFS freigegeben werden, sodass der Verwaltungsserver (sprich Plesk) diese mounten kann.
Sobald Plesk geschrieben hat (bspw. neues Web angelegt) werden die Änderungen via DRBD vom Master auf den Slave automatisch syncronisiert.

Für die Datenbankzugriffe vom Verwaltungsserver auf den Master muss hier der Zugriff von Aussen erlaubt werden (beschränkt auf die IP des Verwaltungsservers).
Über welchen Dienst gleicht der Master den DB-Bestand mit dem Slave ab? Wie wird das eingerichtet? Läuft das auch über DRBD, spezieller DB-Modus?

Die Verbindungen zwischen Verwaltungsserver und Master laufen in einem VLan ab, sprich über lokale IPs. Das bedeutet, ich kann nicht die öffentliche IP-Adresse (die "vor" dem Loadbalancer geschaltet ist) benutzen. Daher muss eine Lösung gefunden werden, dass sich der Slave automatisch die lokale IP des Masters zieht, sobald dieser off ist. Dadurch soll gewährleistet werden, dass der Verwaltungsserver weiterhin mit dem Root-Server kommunizieren kann.
Wird sowas über Heartbeat gelöst?

Denkfehler oder würde Fall 3 gut funktionieren?
Worauf muss ich achten?
Wie geht man vor?

bla!zilla
09.01.11, 11:40
Wie würde das ganze denn mit der Datenbank von statten gehen? Wie wird soetwas eingerichtet, damit alle auf den selben DB-Bestand zugreifen können? Es muss ja iwie kontrolliert werden, dass die Schreibzugriffe auf die DB nacheinander erfolgen.

Oracle RAC kann sowas. MySQL kann sowas mittlerweile auch, da werden aber AFAIK Replikationsmechanismen eingesetzt. Es ist nicht eine Datenbankinstanz, so wie beim RAC.



Was wäre, wenn man aus Fall 1 und Fall 2 einen Fall 3 schafft?!

Loadbalancer / FailOver
Verwaltungsserver / DNS
2x Root-Server


Verwaltungsserver bleibt wie gedacht, DNS und Plesk.
Die beiden Roots laufen über DRBD Master / Slave Modus.
Der Loadbalancer wird so eingestellt, dass immer nur ein Server die Anfragen bekommt (reine failover Lösung).


Wozu überhaupt Plesk?! Kann man dem Ding überhaupt sagen, dass es einen anderen Server konfigurieren soll, als den, auf dem es installiert ist? HA heißt auch oft - keep it small and simple. Daraus folgt IMHO: Plesk entsorgen.



Vorgehensweise / Konfiguration:
Auf dem Master müssen die entsprechenden Verzeichnisse für Web und Mail über NFS freigegeben werden, sodass der Verwaltungsserver (sprich Plesk) diese mounten kann.
Sobald Plesk geschrieben hat (bspw. neues Web angelegt) werden die Änderungen via DRBD vom Master auf den Slave automatisch syncronisiert.


IMHO ein Denkfehler drin: Du synchronisierst per DRDB die Daten. Was ist mit der Config? Kann Plesk die Config auf beiden Servern schreiben? /etc kannst du schlecht per DRDB synchronisieren.



Für die Datenbankzugriffe vom Verwaltungsserver auf den Master muss hier der Zugriff von Aussen erlaubt werden (beschränkt auf die IP des Verwaltungsservers).


Kann Plesk das??



Über welchen Dienst gleicht der Master den DB-Bestand mit dem Slave ab? Wie wird das eingerichtet? Läuft das auch über DRBD, spezieller DB-Modus?


http://www.drbd.org/



Die Verbindungen zwischen Verwaltungsserver und Master laufen in einem VLan ab, sprich über lokale IPs. Das bedeutet, ich kann nicht die öffentliche IP-Adresse (die "vor" dem Loadbalancer geschaltet ist) benutzen. Daher muss eine Lösung gefunden werden, dass sich der Slave automatisch die lokale IP des Masters zieht, sobald dieser off ist. Dadurch soll gewährleistet werden, dass der Verwaltungsserver weiterhin mit dem Root-Server kommunizieren kann.
Wird sowas über Heartbeat gelöst?


Ja.



Denkfehler oder würde Fall 3 gut funktionieren?
Worauf muss ich achten?
Wie geht man vor?

Ganz ehrlich: Du stellst soviele Fragen und es sind noch soviele Fragen offen - ich würde sagen nein.

OliverH
10.01.11, 22:00
Hallo,

ich denke eine Lösung mit Virtualisierung auf Basis von XEN oder KVM mit DRBD als Storage darunter ist die sauberste Lösung für das was du vor hast.
Dann ist das Setup gegenüber deinem Plesk transparent, da es einfach im Gastsystem läuft. Dabei benötigst du auch keinen Loadbalancer.

2x Rootserver als KVM/XEN Hosts mit beispielsweise CentOS (läuft meiner Erfahrung nach sehr zuverlässig, Debian 5 machte Probleme, mit SuSE habe ich keine Erfahrung) und Replikation des Gastpartitionen / Storagefiles via DRBD. Mittels Pacemaker (Clustermanager) kannst du dann einen HA-Cluster aufbauen und dafür sorgen, dass jede Virtuelle Maschine auf genau einem der Hosts läuft und im Fehlerfall ein automatisch ein Failover durchgeführt wird.

Das ganze ist jedoch so komplex, dass ich dir nicht empfehlen würde sowas kurzerhand mal eben aufzusetzen und produktiv (d.h. kommerziell) zu nutzen. Ich betreue mehrere solcher Setups für Kunden. Setup und Wartung sind alles andere als trivial. Insbesondere sollte so ein Cluster bevor er produktiv benutzt wird ausgiebig getestet und dokumentiert werden!

Viele Grüße

Oliver

bla!zilla
10.01.11, 22:33
Guter Ansatz, auf die Idee bin ich so ad hoc gar nicht gekommen. Vom KISS Ansatz her sicherlich die beste Lösung hier im Thread. Vorteil: Man spart sich das NAS im Hintergrund und viel Bastelei. Wobei sich mir immer noch die Frage stellt: Ist Plesk wirklich notwendig? Was machen, wenn die VM selber einen Knacks hat, logische Fehler werden ja brav per DRDB synchronisiert.

trequ
12.01.11, 10:47
Hallo.

ich stehe vor einem ähnlichen Problem und auch ich denke über KVM nach.
Nur mit dem Unterschied, dass ich zwei richtige NetApp Fileserver anstelle des DRBD einplane.


Was machen, wenn die VM selber einen Knacks hat, logische Fehler werden ja brav per DRDB synchronisiert.
Das wird in meinem Konzept damit aufgefangen, dass der Filer alle 4 Stunden einen Snapshot von dem Share erzeugt.
Stirbt etwas, kann man die Daten der VM aus dem Snapshot zurückholen.

DRBD kann sowas glaube ich nicht, aber ich denke, hier könnte das Tool rsnapshot eine Möglichkeit sein, hab sowas allerdings noch nicht gebraucht.

mfg
trequ

bla!zilla
12.01.11, 12:52
Das wird in meinem Konzept damit aufgefangen, dass der Filer alle 4 Stunden einen Snapshot von dem Share erzeugt.
Stirbt etwas, kann man die Daten der VM aus dem Snapshot zurückholen.


Die VM aus dem Snapshot ist aber in einem crash state. Dabei kann die VM, die Daten in der VM, Datenbanken in der VM etc, einen Knacks bekommen. Sauber wäre das nur, wenn du die VM stoppst und dann den Snap machst.

DrunkenFreak
12.01.11, 19:54
Hallo,
2x Rootserver als KVM/XEN Hosts mit beispielsweise CentOS (läuft meiner Erfahrung nach sehr zuverlässig, Debian 5 machte Probleme, mit SuSE habe ich keine Erfahrung) und Replikation des Gastpartitionen / Storagefiles via DRBD. Mittels Pacemaker (Clustermanager) kannst du dann einen HA-Cluster aufbauen und dafür sorgen, dass jede Virtuelle Maschine auf genau einem der Hosts läuft und im Fehlerfall ein automatisch ein Failover durchgeführt wird.

Fügt man dem noch eine SAN hinzu, kann man sich Synchronisieren sparen. Damit ist dann zumindest der Ausfall der Serverhardware auf recht einfache Weise gesichert.

bla!zilla
13.01.11, 08:27
Egal ob ich Spiegel (DRBD, Storagesystem in SAN), oder Snapshots mache: So richtig schützt mich beides nicht. Im ersten Fall kann ich logische Fehler übertragen, im zweiten Fall kann meine VM einen Knack bekommen, wenn ich den Snapshot erstelle. Dem sollte man sich nur bewusst sein.

marce
13.01.11, 08:57
bei uns läuft das noch "Old-School-mässig" ab: red. ded. HW-Loadbalancer und ded. Server im Pool dahinter. Deployment läuft manuell / halbautomatisch auf jede einzelne Maschine, DBs sind repliziert.

So kann ich bei Updates für jedes System ded. Tests fahren und kann mir nicht durch Automatismen "auf einen Schlag" den kompletten Pool lahmlegen - im Web-Bereich funktioniert das sehr gut.

(klar, für Fileserver z.B. geht das Prinzip nicht, da ich andere Konsistenz- und Datenaktualitätsanforderungen habe)

(( -> "wie Hochverfügbarkeit" hängt auch immer davon ab, was denn hochverfügbar sein soll und welche Daten dort gehalten werden ))

OliverH
13.01.11, 11:18
Egal ob ich Spiegel (DRBD, Storagesystem in SAN), oder Snapshots mache: So richtig schützt mich beides nicht. Im ersten Fall kann ich logische Fehler übertragen, im zweiten Fall kann meine VM einen Knack bekommen, wenn ich den Snapshot erstelle. Dem sollte man sich nur bewusst sein.

Nunja, bis auf diverse Datenbanken dürfte das mit einem Snapshot kein ersthaftes Problem darstellen (sofern denn Journaling Dateisysteme verwendet werden).

Wir fahren unsere Backups alle im laufenden Betrieb mittels Snapshot (LVM), auch die unserer Datenbanken (MySQL mit InnoDB). Funktioniert super.

Man könnte die Snapshots auch mit DRBD machen indem man nicht Partitionen zwischen den Hosts synchronisiert, sondern Logical Volumes und von eben diesen Snapshots erzeugt (manuell, oder per Cron).

Oli

bla!zilla
13.01.11, 14:59
Nunja, bis auf diverse Datenbanken dürfte das mit einem Snapshot kein ersthaftes Problem darstellen (sofern denn Journaling Dateisysteme verwendet werden).

Datenbanken die Transaktionslogs schreiben sind davon nicht betroffen. Nur sofern sie das nicht tun, kann der Stand inkonsistent sein.

trequ
17.01.11, 14:52
Hier eine Anleitung zu Snapshots mit KVM selbst:
http://qemu-buch.de/de/index.php/QEMU-KVM-Buch/_Speichermedien/_VM-Snapshots

Hat jemand schon Erfahrung damit gesammelt?

Huhn Hur Tu
17.01.11, 19:07
Pacemaker, Heartbeat, DRBD und MySQL im Master/Master Replikationsbetrieb, sollte das alles tun.
MySQL Master Master ist gut um eine Seite abzuhaengen zum Backup machen, dann stoert sich das Backup auch nicht mehr an den Locks und co.


Gruss Stefan