2 Root-Webserver Synchronisieren

[chr.raible]

Hallo,

ich brauche dringen eure Hilfe.

Hab von meinem Chef die Aufgabe bekommen unsere Webserver neu zu installieren und einzurichten, da wir zur Zeit immer beide parallel pflegen und warten müssen!


Voraussetzungen:

2x Baugleiche Debian-Etch Server

Apache 2
MySQL 5
PHP5



Jetzt will er folgende Konstellation:

Server 1 ist der Primäre Webserver.
Server 2 ist der sekundäre Webserver und wird nur verwendet wenn Server 1 ausfällt.

Es soll alle 15 Minuten ein Backup / eine Synchronisation vom Server 1 auf Server 2 geschrieben werden. Dieses Backup soll so aussehen, dass wenn Server 1 ausfällt und heruntergefahren wird / werden muss, beim 2. Server nur die IP-Adresse zu ändern ist und Server 2 zwei als "Server 1" dann läuft. Also als redundantes System.

Noch ein bisschen anders beschrieben wie zwei PLatten die als Raid angeschlossen sind!


Habt ihr da Ideen wie man das realisieren kann?

Wäre für jede Hilfe sehr dankbar.


Mfg
Chr.Raible

[snowball]

Um Dateien auf Beiden Servern gleich zu halten, drängt sich rsync förmlich auf.

Wenn auch noch Datenbanken syncronisiert werden sollen, heißt das Zauberwort "Replikation". Hier wird es allerdings auch schon ein kleines Bisschen komplizierter, bzw. es gibt mehr zu beachten.

[Roger Wilco]

Eigentlich schreit das geradezu nach dem Gespann heartbeat + drbd. Benutz die beiden mal als Suchbegriffe für $suchmaschine, da findest du einige Artikel. Die MySQL-Datenbanken können separat repliziert werden.

[chr.raible]

Das mit dem Replizieren hat mir ein bekannter grad auch gesagt, nur habe ich bis jetzt noch nicht rausgfunden, ob dies auch zeitgesteuert funktioniert!

Also das "nur" alle 15 minuten die DB repliziert wird?!


Was rsync angeht, hab ich leider bis jetzt kein passendes Tutorial oder Howto gefunden, kennt von euch da zufällig jemand eins? Werd aber selbstverständlich weitersuchen und melden sobald ich was hab ;)!

Mfg
Chr.Raible

[aubergine]

Eigentlich schreit das geradezu nach dem Gespann heartbeat + drbd. Benutz die beiden mal als Suchbegriffe für $suchmaschine, da findest du einige Artikel. Die MySQL-Datenbanken können separat repliziert werden.

100% ack

[chr.raible]

Hey Jungs,

das mit RSYNC hab ich jetzt per Cron hinbekommen!

Nur blick ichs einfach nicht mit der DB Synchronisation nicht! Hab jetzt einige Documents durchgelesen aber hab irgendwie keinen Schimmer!



Was die Sache mit drbd angeht wäre das für mich die Optimalste lösung nur gibt es hiervon auch keine gescheite Doku. Nur immer mit Suse! Ich selber verwende aber Debian 4.0


Sollte jemand was haben! Bitte melden! Wäre echt super von euch!

Mfg
Rattlesnake!

PS.: Wenn ich alle Sachen erfolgreich geschafft hab, werde ich meinen Lösungsweg auch allen anderen zur Verfügung stellen!

[Joe User]

Normalerweise sollte es ausreichen, den MySQLd auf den zweiten Server auszulagern und per TCP/IP darauf zuzugreifen. So muss beim Wechsel zwischen den Servern keine Rekonfiguration der Applikationen erfolgen und zudem spart man sich das Replizieren. Eine gescheite Backuplösung für den zweiten Server setze ich mal voraus...

[Joe User]

Ein (MySQL-)Cluster mit nur zwei Nodes ist auch nicht empfehlenswerter, als meine Lösung. Bei lediglich zwei Nodes nimmt man MySQL-Replication, kein MySQL-Cluster und die Replikation erfolgt in meinem Beispiel auf das (hoffentlich vorhandene) Backupsystem. Ich schrieb nicht ohne Grund:

Eine gescheite Backuplösung für den zweiten Server setze ich mal voraus...

[Joe User]

Nachtrag: Wenn man die SuFu mit Keyword=cluster und User=isotopp füttert, stolpert man über http://www.rootforum.org/forum/viewtopi ... 152#248152 und http://www.rootforum.org/forum/viewtopic.php?t=45003 welche sehr lesenswert sind und zum Teil die Nachteile von MySQL-Cluster aufzeigen.

[Joe User]

Wie könnte Deiner Meinung nach ein vernünftiges Backup / Restore aussehen, was einen derart schnellen ausgleich ermöglicht?

Ich kenne den Umfang der Db des Threaderstellers nicht. Bei unseren Datenbanken z.B. kommt es schon vor, dass diese 3-4 GB gross sind.
Ein export dann wiederum betriebschonend ablaufen soll, dauert seine Zeit und auf jeden fall länger als 15 Minuten.

isotopp hat alles Wichtige zu diesem Thema in http://www.rootforum.org/forum/viewtopic.php?t=39481 zusammengefasst.

[Joe User]

Mir ist das Recovery zu dürftig umschrieben. Insbesondere geht er kaum auf die Replizierung, der Verteilung der Daten ein um möglichst sicher und schnell den Regelbetrieb aufrecht zu erhalten.

Genau davon handelt sein Post, eventuell denkst Du nur zu kompliziert.

Die geschilderten Methoden sind mir im täglichen Ablauf nicht zietnah genug.

2. Falls /export/data und /export/log verloren sind, muß man beide Verzeichnisse wieder herstellen und kann nur bis zum Zeitpunkt des letzten inkrementellen Backups wieder voran rollen. Daher wäre es schön, wenn man das Binlog nicht nur auf einer lokalen Platte sichern könnte, sondern auch noch einen Mechanismus hätte, der das Binlog "live" absaugt und woanders abspeichert.

Dieser Mechanismus ist genau ein Replication Slave.

Wenn Dir "live" nicht zeitnah genug ist, hast Du ein grösseres Problem.

Im Regelfall eine Netzwerkkarte ein Raid 1 HDD Verbund.
Das Risiko, dass bei einem Schaden 1. viel Zeit vergeht, um an die Daten direkt vor dem Crash zu kommen, bzw. das bei einem entsprechenden Plattencrash (ohne Raid) die Daten bis zum letzten gesicherten Backups einfach weg sind, sehr hoch.

Richtig, deshalb sind einfache/einzelne RootServer auch nicht zur Ablage kritischer Daten geeignet. Dafür muss man etwas mehr Geld und Hirnschmalz investieren, aber das ist ein anderes Thema.

Auf einem unserer produktiven Rootservern ging eine Netzwerkkarte flöten.
Da bei dem einen Provider leider alles nur mit austausch von dem kompletten Server geschieht, eine ausnahme leider nicht gemacht wird, wäre in dem Fall der komplette Datenstamm weg gewesen.
Zumindest bis zum letzten Backup stand.

Mit einem MySQL-Slave auf einem zweiten Server wären nur die ungesicherten nicht-DB-Daten verloren, was je nach Applikation zwar ärgerlich aber abgesehen von Mails eher unkritisch ist.

Mit unseren Applikationen unterstüzen wir jedoch eine redundante Datenhaltung über mehrere Datenbanken. Quasi eine "Clusterlösung" auf Applikationsebene.

Auch bei solchen Applikationen kann ein (oder mehrere) Slave nicht schaden, ist aber nicht zwingend nötig.

Im Falle eines technischen defketes haben wir mit mehrere Provider schlechte Erfahrungen sammeln könne / dürfen.

Auch ich durfte schon mehrere Komplett-Austausch-Faxe schicken, aber dank eines für meine Bedürfnisse ausreichendem Notfallplanes bin ich nur vom Zeitpunkt des Ausfalls und vom DNS abhängig.