Server Redundanz herstellen...

  • Thread starter Thread starter gummel
  • Start date Start date
G

gummel

Guest
Angenommen:

Ich habe einen VServer und ich habe einen zweiten. Wie kann ich es hinbekommen, das, wenn ein Server ausfällt, z.B. Server 1 der der Hauptserver ist, automatisch Server 2 genutzt wird?

Ich möchte eine Serverredundanz schaffen. Die Probleme sind mir klar, z.B. müssen dann die Änderungen abgeglichen werden etc. Das gibt sicherlich böses Blut, aber immernoch besser, als eine Ausfallzeit von meheren Stunden.

Gibt es da einen Möglichkeit, z.B. über Nameservereinträge (Sämtliche Domains liegen NICHT auf den VServern sondern werden durch Nameserver-Einträge auf diese umgeleitet).

Vielleicht gibt es da ja etwas.

Viele Grüße

Lars
 
Die Nameservereinträge werden von den meisten ISPs zwischengespeichert so das einige Besucher sofort auf die neue IP kommen, andere erst Stunden (Tage?) nach der Umstellung. Sobald die Besucher irgendwas auf deinem Server ändern (Forum, Wiki, Gästebuch, Webshop) ist das fast unmöglich sauber zu verarbeiten.
Für den Preis von 2 VServern mit jeweils 99% Ausfallsicherheit bekommst du schon fast einen richtigen Server mit 99,9 oder noch mehr Ausfallsicherheit und hast mehr Leistung/Service und deutlich weniger Arbeit.
 
HornOx said:
Für den Preis von 2 VServern mit jeweils 99% Ausfallsicherheit bekommst du schon fast einen richtigen Server mit 99,9 oder noch mehr Ausfallsicherheit und hast mehr Leistung/Service und deutlich weniger Arbeit.
Click to expand...
Das mag ich nicht so stehen lassen, denn ein root-Server ist nicht automatisch ausfallsicherer. Ganz im Gegenteil: Bei Hardware-Schäden ist der Ausfall garantiert länger und heftiger als bei einem vServer.

Aber mal zum Thema:
Redundante Server kann man verschiedenartig aufbauen:
1.)
Wie Du es vorhast. Aber dann brauchst Du noch einen eigenen Nameserver (3.Server), der sofort reagiert wenn der Primary nicht mehr da ist. Um die Übergangszeit zu verkürzen kann man dort die TTL der Domain entsprechend klein halten.
2.)
Ähnlich wie 1.: Auf beiden Servern läuft ein NS und die verweisen jeweils bei der Domainauflösung auf sich selbst. Im Domain-Reg stehen diese NS als ns1.deinedomain.de und ns2.deinedomain.de.
3.)
Du arbeitest mit einem Loadbalacer. (evtl. 3.Server geht aber auch nur mit 2)
Damit wird auch keine Server-Resourcen verschwendet, da beide Server regelmässig genutzt werden.

Bei der ersten Lösung reicht ein Mirror-System zum Spiegeln der Daten.
Bei 2. und 3. brauchst Du ein Sync-System, welches z.B. die Datenbanken in beide Richtungen replizieren kann. Dies kann z.B. Oracle, aber jedenfalls (noch) nicht mysql ohne entsprechende Zusatztools.

huschi.
 
Danke für die Anworten. Ich werde jetzt daran Arbeiten und die geeignete Lösung ausfindig zu machen.

Das mit dem "richtigen" Server hatte ich schon... Lohnt einfach nicht. Er war zwar nett und schnell, aber nicht zwingend sicherer. Grundsätzlich sind mir die VServer schon ganz recht, aber etwas mehr Sicherheit wäre nicht übel.

Das versuche ich halt jetzt irgendwie selbst hinzubekommen.

Viele Grüße

Lars
 
1. sollten die zwei vServer nicht beim gleichen Hoster sein, denn wenn der Probleme hat, erwischt es sicherlich beide.
2. DnyDNS & Co bieten solche DNS-Services mit DNS-Änderung per Script und kurzer TTL, da läßt sich sicherlich leicht was basteln
3. mit einem 3. vServer als DNS oder Load-Balancer wäre es wohl kaum getan, der kann ja auch ausfallen, müßten also 4 her (2 LBs)
4. zum Preis eines vServers oder auch nur einen simplen Root-Servers läßt sich kaum eine 99,98% HA Lösung herstellen, die schließlich anderswo etliche 10k Euro kostet
 
3. mit einem 3. vServer als DNS oder Load-Balancer wäre es wohl kaum getan, der kann ja auch ausfallen, müßten also 4 her (2 LBs)
Click to expand...

Nein. Das ist so unlogisch.
2 Loadbalancer um auf 2 Server zu verteilen macht keinen Sinn.
Wenn nun Loadbalancer 1 Loadbalancer 2 redundant spiegelt macht, braucht man noch einen, und noch einen, ...

Option 2 von Huschi mit rsync dürfte am einfachsten sein.
Diesen Artikel dazu finde ich sehr gut:
http://www.heinlein-support.de/web/wissen/rsync-backup/
 
brummfondel said:
3. mit einem 3. vServer als DNS oder Load-Balancer wäre es wohl kaum getan, der kann ja auch ausfallen, müßten also 4 her (2 LBs)
Click to expand...
Irgendwo in einer c't oder iX wurde mal eine Lösung eines Loadbalancers beschrieben der lediglich auf dem ersten Server installiert war. Und ich hab damals mit einem Admin gesprochen, der das System auch in die realität umgesetzt hatte. Ich erinnere mich nur nicht mehr, wie es ging, wenn der Server1 ausviel... Aber das war der eigendliche Trick bei der Sache. Und dabei ging es u.a. auch um geschickte DNS-Einträge.

huschi
 
Huschi said:
Irgendwo in einer c't oder iX wurde mal eine Lösung eines Loadbalancers beschrieben der lediglich auf dem ersten Server installiert war. Und ich hab damals mit einem Admin gesprochen, der das System auch in die realität umgesetzt hatte. Ich erinnere mich nur nicht mehr, wie es ging, wenn der Server1 ausviel... Aber das war der eigendliche Trick bei der Sache. Und dabei ging es u.a. auch um geschickte DNS-Einträge.
Click to expand...

Der einfachste Weg ist ein IP-Switching. So arbeiten auch richtige Load-Balancer aus 2 Systemen. Das ist natürlich bei vServers keine so leichte Sache. Auch kommerzielle Cluster arbeiten so: jeder Node hat eine IP und der Cluster hat auch noch eine. Der aktive Node hat dadurch 2 IPs, fällt er auch, bekommt der 2. diese. Per ARP wird dann noch der Switch oder Router darüber informiert, daß die IP jetzt einer anderen MAC-Adresse gehört und das war dann.
 
Ansgar Berhorn said:
Nein. Das ist so unlogisch.
2 Loadbalancer um auf 2 Server zu verteilen macht keinen Sinn.
Wenn nun Loadbalancer 1 Loadbalancer 2 redundant spiegelt macht, braucht man noch einen, und noch einen, ...
Click to expand...

Ich glaube, du kennst die Bedeutung eines Load-Balancers nicht. Sie dich mal bei f5-Networks um (www.f5.com). Der BigIP, den u.a. auch Heise einsetzt - und vielen anderen; hab sowas auch mal administriert, besteht aus 2 Kisten, die sich gegenseitig überwachen. Einer davon ist aber nur aktiv (per Default). Fällt der aus, übernimmt sofort der andere. Fällt dieser dann auch aus, ist natürlich schluß. Aber das ist bei allen 2-Node-Clustern so. Aber unter normalen Umständen erreicht man so fast 99,9% Verfügbarkeit. Wer auf 99,98% steht, sollte sich natürlich eine komplette Standby-Anlage aufbauen, die nur auf diesen schlimmsten Fall des Ausfalls beider aktiv-Systeme wartet.

Der große deutsche Elektrokonzern, wo ich gerade als Consultant bin, bietet solche Systeme für Telcos an.

Man hat also 2 LBs (aka 1 LB bestehend aus 2 Systemen) und dahinter mehrere Nodes, die rechnen. Außerdem für Standby nochmal 2 LBs und noch mehr Nodes. Natürlich davor entsprechend redundante Router, Netzwerke und Brandzonen.

Aber für Deine Frage reichen 2 vServer die als Cluster arbeiten, entweder dann per IP-Switching (geht aber vermutlich bei vServer nicht) oder per DNS-Switching (ist aber nicht so schnell).

RSync ist dabei was ganz anderes, das ist ja für den Datenabgleich beider Systeme - das ist aber auch nicht ganz trivial, zumindest bei Datenbanken. Aber generell sind dynamische Daten, die ständig geändert werden nicht leicht synchron zu halten - außer mit so tollen Sachen wie Oracle-Cluster. Nein, mysql hat bisher noch keine richtige Cluster-Lösung, man kann nur lesen von mehrere Hosts, schreiben nur auf einem - aber daran wird wohl z.Z. gearbeitet.
 
Ich glaube, du kennst die Bedeutung eines Load-Balancers nicht.
Click to expand...
Sicherlich kann ich nicht 100% vom derzeit verfügbaren Wissen über Loadbalancer vorweisen.
Mir ging es eher drum, dass man an irgendeiner Stelle aufhören sollte, weitere Redundanzen einzufügen (mal davon ausgegangen, dass es nicht 99,99% Ausfallsicherheit sein sollen).


RSync ist dabei was ganz anderes, das ist ja für den Datenabgleich beider Systeme - das ist aber auch nicht ganz trivial, zumindest bei Datenbanken.
Click to expand...
Datenabgleich ist hier doch notwendig?
Daher versteh ich nicht, warum das "was ganz anderes" sein soll.
Gut, bei Loadbalancern wird sonst vielleicht ein hochverfügbares NFS-Volume von beiden Systemen beschrieben und daher stellt sich die Frage des Datenabgleiches nicht.
Das mit rsync sollte eine Idee sein, mehr nicht. Das hab ich vielleicht nicht deutlich genug geschrieben.

Gruß,
Ansgar
 
Ansgar Berhorn said:
Datenabgleich ist hier doch notwendig?
Daher versteh ich nicht, warum das "was ganz anderes" sein soll.
Gut, bei Loadbalancern wird sonst vielleicht ein hochverfügbares NFS-Volume von beiden Systemen beschrieben und daher stellt sich die Frage des Datenabgleiches nicht.
Das mit rsync sollte eine Idee sein, mehr nicht. Das hab ich vielleicht nicht deutlich genug geschrieben.
Click to expand...

Nunja, bei einem Filesystem sollte rsync kein Problem sein, sofern auch die Rücksynchonisierung sauber läuft:

System A ist aktiv und rsync'ed zu System B, A fällt aus, B übernimmt. Nun ändern sich Daten bei B, die wieder zu A müssen. A ist aber erstmal weg und kommt dann vielleicht nach einigen Stunden wieder. Jetzt darf A auf keinen Fall aktiv werden und auch nicht zu B synchen, sonst ist da alles was bisher geschah weg. Statt dessen muß jetzt B zu A synchen. Genau da fangen die Probleme an, das muß wirklich narrensicher laufen, sonst kommt es zum Datenverlust oder gar zu Totalausfällen, wenn Daten kaputt gehen (was ja eigendlich durch die 2-System-Lösung vermieden werden soll). Den Fall, daß aus irgend einem Grund B aktiv geht, obwohl A noch lebt und fleißig noch laufende Transaktionen beendet, die B aber nicht bekommen hat, somit A aktueller ist als B obwohl B aktiv ist, lassen wir mal weg. NFS wäre da natürlich einfacher - kann aber auch zu Datenkorruption führen und bräuchte natürlich auch einen NFS-Server.

Das ist aber nur bei Filesystemen so einfach. Bei Datenbanken geht das nicht mehr über rsync. Andererseits kann man da die geänderten Datensätze leichter finden und abgleichen - dazu muß die Datenbank aber sowas können und sie muß als Aktiv-Aktiv System laufen können, denn es soll ja möglichst auf beiden Hosts in die DB geschrieben werden können. Ein Aktiv-Standby-System müßte man erst irgendwie umschalten und das vielleicht sogar noch den Applikationen mitteilen. Sowas geht immer irgendwo schief.

Kurz gesagt: sobald dynamische Daten ins Spiel kommen, wirds fummelig. Und je häufiger diese verändert werden, desto größer die Gefahr von Datenverlust oder Datenkorruption (also dem übleren Fall, daß irgendwie noch was geht, aber mit falschen Daten). Wenn Du aber nur "statische" Daten hast (die ruhig dynmisch in Echtzeit aus anderen statischen Daten erzeugt werden könne, z.B. ein CMS), sind aber 2 vServer ausreichend. Wenn dann auch nur Redakteure Inhalte ändern können (z.B. über ein CMS), ist da auch keine große Gefahr. Vielleicht lassen sich Änderungen auch getriggert übertragen (dank des CMS), wenn sie wirklich anfallen. Dann sollte ein einfacher DNS-Switch für dich reichen. Die 2 Systeme überwachen sich dann selbst und könnten z.B. bei DynDNS die IP-Adresse des DNS-Eintrags bei Bedarf anpassen. Aber wie gesagt, die 2 Systeme sollten bei verschiedenen vServer-Anbietern sein. Solltest Du außerdem eine Cluster-Fähige Datenbank haben (kann PostgreSQL sowas?), ist das auch hilfreich und wenn dann im Filesystem keine Änderungen gemacht werden, braucht auch kein kompliziertes Sync.
 
brummfondel said:
Nunja, bei einem Filesystem sollte rsync kein Problem sein, sofern auch die Rücksynchonisierung sauber läuft:
Click to expand...
Das ist bei rsync kein Problem. Das Poblem ist dabei, daß es keine Löschdaten hat. D.h. das Löschen einer Datei ist nicht trivial.

Solltest Du außerdem eine Cluster-Fähige Datenbank haben (kann PostgreSQL sowas?)..
Click to expand...
Angeblich leichter als mit MySQL. Aber mit MySQL 5 soll sich auch dabei wieder was ändern.
Bei Oracle ist es übrigends lediglich eine minimale Einstellung... ;)

huschi.
 
Huschi said:
Das ist bei rsync kein Problem. Das Poblem ist dabei, daß es keine Löschdaten hat. D.h. das Löschen einer Datei ist nicht trivial.
Click to expand...
Wenn es sich um statische Daten handelt, die von Anwendern gepflegt werden, bietet sich immer CVS an. Damit hat man leichzeitig ein Backup von älteren Versionsständen und der Sync ist asynchron möglich (sofern es einen eigenen CVS-Server gibt, naja, ok...).

Angeblich leichter als mit MySQL. Aber mit MySQL 5 soll sich auch dabei wieder was ändern.
Bei Oracle ist es übrigends lediglich eine minimale Einstellung... ;)
Click to expand...

Nun möchte ich mir Oracle nicht auch einem vServer vorstellen.

Allen Lösungen gemeinsam ist jedoch noch das Problem der sicheren Synchronisierung - sicher im Sinne von Schutz vor Einbruch. RSync und CVS lassen sich über SSH leiten, kann also nicht abgehört werden. Aber die Datenbanken haben ihre eigenen Ports. Klar kann man die über SSH tunneln, solange das TCP ist, aber das wird alles nicht einfacher. Ein VPN wäre die beste Lösung, aber das geht ja bei vServer bisher wohl nicht oder nur auf wenigen. (Übrigens wäre ein SSH-Tunnel eine Anwendung für NAT, genauer Destination NAT, das geht aber auch nicht, weil man es ja nicht braucht. Ok geht auch ohne, aber nicht bei allen Anwendungen wie z.B. Sendmail.)
 
Warum kompliziert wenn es auch leichter geht?
Und solange man auf vServern bleibt muß man eh selber Hand anlegen, wenn man einen Datenbank-Sync laufen lassen will.
Und alle Kommunikationen zwischen zwei sich (syncron/asyncron) abgleichenden Datenbanken kann man z.B. in ein SSL-Protokoll mit eigenen Zertifikaten einbetten. Hier ist die Frage der Datenmenge. Bei syncronen Abgleich werden nur wenige Daten übermittelt. Hier wäre ein SSL-Handshake etwas überdimensioniert und eine Datenverschlüsselung (z.B. mit Blowfish) eher angesagt. Bei asyncronen Übertragungen ist hingegen ein SSL etwas schneller implementiert.

Aber wir reden glaub ich eh über Dinge, die evtl. keinen sonst hier interessieren... ;)

huschi.
 
Huschi said:
Warum kompliziert wenn es auch leichter geht?
Und solange man auf vServern bleibt muß man eh selber Hand anlegen, wenn man einen Datenbank-Sync laufen lassen will.
Und alle Kommunikationen zwischen zwei sich (syncron/asyncron) abgleichenden Datenbanken kann man z.B. in ein SSL-Protokoll mit eigenen Zertifikaten einbetten. Hier ist die Frage der Datenmenge. Bei syncronen Abgleich werden nur wenige Daten übermittelt. Hier wäre ein SSL-Handshake etwas überdimensioniert und eine Datenverschlüsselung (z.B. mit Blowfish) eher angesagt. Bei asyncronen Übertragungen ist hingegen ein SSL etwas schneller implementiert.
Click to expand...

Können denn die typischen freien Datenbanken sowas? Weiß ja noch nicht mal, ob Mysql zum Client (mysql Prompt, PHP, ...) hin verschlüsseln kann. PostgreSQL? Wobei ich da irgendwas in Erinnerung habe, daß sowas neu gehen soll oder sowas. Habs aber eh nicht vor und die Verbindungen zu meinem vServer laufen eh alle über SSH-Tunnel (Monitoring, Backup und so).

Aber wir reden glaub ich eh über Dinge, die evtl. keinen sonst hier interessieren... ;)
Click to expand...

Wohl wahr. Aber das zeigt, worüber man sich alles Gedanken machen muß, wenn man ein redundandes System haben will und daß es mal eben mit einfach 2 Systeme aufstellen selten getan ist.
 
juhu,

ist zwar schon älter, aber ich hab ne echt gute lösung die "superbillig" gemacht ist, aber funktioniert.

die domain ist bei einem domainanbieter, dann habe ich noch 2 vserver bei unterschiedlichen hostern.
sobald meine website offline ist, bekomme ich eine mail (oder SMS), dann mache ich beim domainanbieter einen A record zum 2 server (der immer synchron gehalten wird) und schon steht die seite auf der zweiten kiste.
die datenbank wird per cronjob immer automatisch auf mehrere kisten verteilt.

ich meine, warum sollte ich so unendlich viel zeit investieren, sicherheitsmaßnahmen zu schaffen, wenn der eintrag per hand selbst nur wenige sekunden dauert ,-)

ist zwar keine 100% lösung, weil das datenbankbackup alle 15 minuten läuft, aber wer auf 15 minuten an daten verzichten kann, für den ist die lösung doch okay. es sei denn ihr habt unendlich traffic und performance, dann macht ihr immer schön jede minute ein backup per cronjob (wers braucht...)

so oft fallen die kisten ja auch nicht aus ...
just my 2 cents
 
Das Umschalten funktioniert allerdings nur dann einigermaßen schnell, wenn Du die TTL beim DNS-Server entsprechend kurz eingestellt hast. Normalerweise haben die DNS-Daten eine Gültigkeit von 2 Tagen, damit die allgemeine Last im DNS-Netz in verträglichen Maßen gehalten wird. Daher dauert es dann u.U. bis zu zwei Tage, bis die Änderungen sichtbar werden...

Viele Grüße,
LinuxAdmin
 
Davon mal abgesehen, dass das ganze am Anfang auch schon erwähnt wurde und dass auch gesagt wurde, warum das ganze nicht so richtig funktioniert wie man sich das denkt.
 
Normalerweise haben die DNS-Daten eine Gültigkeit von 2 Tagen, damit die allgemeine Last im DNS-Netz in verträglichen Maßen gehalten wird. Daher dauert es dann u.U. bis zu zwei Tage, bis die Änderungen sichtbar werden...
Click to expand...

Dann könnte man noch als Alternative die dns-server auf die vhosts legen.

ns1.vserver1.de
ns2.vserver2.de.

Wenn der Erste (aktiv-aktiv) ausfällt dann kommt doch die Anfrage automatisch an den Zweiten dns und der wiederum liefert die Antwort er sei selbst der richtige Ansprechpartner (vorrausgesetzt man hat mit einem Script die DNS abfragen bereits abgeändert als man merkte, dass ns1 /v1 tot ist).

hmm ... Ich glaube ich übersehe irgendwas, denn das kommt mir zu leicht vor :rolleyes:
 
Du übersiehst, daß Nameserver nicht zwangsweise eine Reihenfolge haben.
Ausserdem kann der eine mal etwas langsam mit der Antwort sein und schon ist antwortet der zweite mit der falschen IP.
Dazu kommen noch die DNS-Caches und Proxy-Server die sich nicht wirklich an die eingestellte TTL halten. (Z.B. T-Online)

Für eine Naja-ich-möchte-gerne-eine-billige-Redundanz-Lösung reicht es schon.
Aber ein ernsthafter Vorschlag zum Nachbauen ist das nicht.
Vor allem weil man echte Redundanz mit nur recht wenig mehr Aufwand bilden kann.

huschi.
 
You must log in or register to reply here.
Back
Top