Cluster oder Replikation?

MSS-Software

Blog Benutzer
Hallo zusammen,
ich habe einen Debian Etch Rootserver.

Gestern war dieser leider den ganzen Tag nicht erreichbar, da er vom Provider aus dem Netz genommen wurde, wegen eines DDOS Angriffes.

Aus Fehlern lernt man ja und deswegen hab ich mir überlegt, mich dagegen "abzusichern".

Also das was ich im Grunde vorhabe ist, dass wenn Server A aus was für gründen auch immer ausfällt, sofort Server B einspringt.

Jetzt weiß ich nur nicht, was das richtige für mich ist. Cluster oder Replikation?

Ein Cluster dient ja eigentlich nur dazu, um die Last zu verteilen. Also würde ich jetzt mal sagen Replikation.

Aber wie mache ich das? Ich würde ungern jeden Tag irgendwie alles herunterladen müssen, auf den anderen Server kopieren usw.

Arbeite zur Verwaltung mit Confixx.

Hat da jemand ne Idee?

mfg

Matthias
 

Thorsten

SSF Facilitymanagement
Staff member
Hallo!
Weder das eine (Clustering) noch das andere (Replikation) wird dich vor einem technischen Problem (dDOS) bewahren. Insofern kann ich dir weder zu dem einem noch dem anderen raten.

Ein technisches Konzept zu einem Debian fail-over-cluster findest du unter Debian LAMP Failover cluster: Implementation - wildness. Dabei wird allerdings Confixx schon zur ersten Hürde.

mfG
Thorsten
 

dexter

New Member
Eigentlich ein Allgemeinplatz: Was Du verwenden kannst hängt davon ab, wie Deine Anforderungen aussehen. Und die hast Du bislang nicht wirklich beschrieben. Ich versuche trotzdem mal einen ersten Überblick:

Wenn Du Dich gegen Provider-Probleme absichern willst, kann Replikation Dir nur helfen wenn Du den Backup-Server bei einem anderen Provider stehen hast.

Damit fällt performantes Storagesharing zwischen den Servern allerdings flach, d.h. Du musst Dir überlegen wie oft Du welche Daten abgleichen willst. Auch ein MySQL-Slave bekommt über WAN schnell Probleme mitzuhalten wenn viele Datenbankoperationen vorkommen, vom zu bezahlenden Traffic mal ganz abgesehen.

Für den Datenabgleich ist in jedem Fall rsync sehr gut geeignet, wenn Du Wert auf Datensicherheit legst per ssh. Dank inkrementeller Updates und Kompression lässt sich mit rsync der Traffic in Grenzen halten.

Wenn Du schnell (!) vom Haupt- auf den Backupserver umschalten können musst, benötigst Du bei diesem Setup noch einen transparenten Proxyserver, dem die Netzadresse fest zugeordnet ist und der die Zugriffe an den gerade aktiven Server routet. Hierfür genügt bspw. der rinetd -- wenn's nur um HTTP(s) geht bietet Dir der Apache mit den Proxy-Modulen feinere Kontrolle. Die "sofortige" Umschaltung braucht dann noch ein kleines Shellscript auf dem Backupserver, das den Hauptserver (und einen Referenzserver) überwacht und im Fehlerfall den Proxy entsprechend umkonfiguriert. "sofort" ist hierbei allerdings relativ, auch sollte nicht unerwähnt bleiben daß im Falle eines Ausfalls des Proxyservers auch Schicht im Schacht ist.

Wenn eine langsamere Umschaltung reicht kannst Du auch den DNS-Eintrag des Hosts mit sehr kurzem Expire versehen und hoffen, daß das DNS-Netzwerk Deine Kunden schnell genug mit Updates versorgt. I.d.R. braucht ein Update 4-6h um die wichtigsten deutschen DNS zu erreichen.

Wenn Deine Kunden natürlich die Möglichkeit haben, einen von Dir betriebenen DNS-Server zu verwenden, brauchst Du Dir darum keine Gedanken zu machen. Den DNS-Server setzt Du dann am besten als Primary auf dem Backup- und als Secondary auf dem Hauptserver auf.

Wenn eine Aktualitätslücke beim Wechsel zum Backup-Server nicht akzeptabel ist kommst Du i.d.R. um eine engere Kopplung nicht herum, d.h. die beiden Server müssen dann doch beim selben Provider stehen. Hierbei hast Du je nach Provider auch die Möglichkeit, eine IP-Adresse zu bekommen die Du schnell von einem auf den anderen Server umschalten kannst, d.h. ein Proxy ist dann nicht nötig.

Shared Storage kannst Du dann auch schon per NFS realisieren, hierbei muss natürlich der Backup-Server den NFS-Server hosten.

Allgemein gilt bei so einem Setup, daß Du mit viel Traffic zwischen den beiden Servern rechnen musst, d.h. der Provider sollte Dir diesen "internen" Traffic nicht berechnen. Das ist leider keine Selbstverständlichkeit.

Damit schliesse ich den ersten Überblick mal ab. Der nächste Schritt sollte eine genaue Definition der Anforderungen sein.

Für "richtige" High-Availability-Lösungen empfehle ich einen Blick auf die sehr anschaulichen Beispiel-Cluster bei Host Europe... leider nix für den kleinen Geldbeutel.
 
Top