Wie Redundanz für Uploadserver realisieren?

ww

Well-Known Member
Hallo zusammen,

ich würde gerne Redundanz bei einem Uploadserver realisieren, d.h. der Ausfall eines Servers würde einen zweiten den Uploadjob übernehmen lassen.

CARP ist folglich keine Lösung (wäre sie bei einem reinen Download- oder Webserver), weil ich praktisch einen "Realtime Mirror" brauche. Lösungen wir rsync/cron kommen nicht in Betracht. Was ich brauche, ist eine Art RAID 1 über zwei komplette Maschinen.

Geht so etwas mit Bordmitteln?
 
Warum ist CARP keine Loesung? Eine TCP-Session wirst du kaum von einen zum anderen Server transferiert bekommen, jedenfalls ist mir nichts derartiges bekannt.

Fuer alles andere sollte man mit CARP und GMIRROR was bauen koennen.
 
moin,
drbd kann einen solchen realtime mirror erstellen, wobei drbd imo nur unter linux rennt.

gruß
thorben
 
@MrFixit: Wenn ich das richtig verstanden habe, kann CARP nahtlos auf einen zweiten Server wechseln, wenn der erste down ist. CARP (wie auch heartbeat) hat aber nichts mit dem syncen der beiden Server zu tun. Es ist also gut geeignet für Rechner, deren Daten sich eher selten ändern (z.B. Webserver). Für das syncen muß man aber mit einem zusätzlichen Tools (wie rsync) sorgen. Korrigiere mich, wenn ich falsch liege.

@thorben: drdb gibt es nicht in den Ports...

EDIT: Auch so etwas wie freevrrpd ist imho keine Lösung des Uploadproblems. Ich suche eine Lösung, bei der *immer* auf zwei Boxen parallel uploaded wird.
 
Last edited:
ww said:
@MrFixit: Wenn ich das richtig verstanden habe, kann CARP nahtlos auf einen zweiten Server wechseln, wenn der erste down ist. CARP (wie auch heartbeat) hat aber nichts mit dem syncen der beiden Server zu tun. Es ist also gut geeignet für Rechner, deren Daten sich eher selten ändern (z.B. Webserver). Für das syncen muß man aber mit einem zusätzlichen Tools (wie rsync) sorgen. Korrigiere mich, wenn ich falsch liege.

Ja das stimmt, die Synchronisation der Datenpartition kann aber zB mittels gmirror+ggate realisiert werden. Man sollte da aber wissen was man tut, da man aufpassen muss, dass der Mirror "clean" bleibt und was man ueberhaupt vom FS halten soll, wenn der Master gerade beim Schreiben abgenippelt ist. bgfsck koennte hier noch gute Dienste leisten. Ein Backup ersetzt das aber nicht.

Oder du packst die Daten wieder zentral auf einen NFS Server.
 
Ich haette eine sehr alltagstaugliche und ausgereifte Loesung zu der Aufgabenstellung, wenn es nur um serverseitige Ausfallsicherheit geht. ;-)

Nimm folgende Zutaten:

* ordentliche Hardware (inkl. erprobte Chipsets, gute Festplatten,...)
* Raidcontroller des Vertrauens mit Moeglichkeit zum Auslesen des Status
* Skripte zum Feststellen von Problemen wie Plattenueberlaeufe, etc
* Zeit zum ordentlichem Konfigurieren
* Scheu beim Verteilen von Rootrechten

Die Wahrscheinlichkeit ist _sehr_ hoch, dass man mit einem solchen System komplexere Systeme in Sachen Ausfallsicherheit uebertrifft...
 
Nach meinem Verständnis dürfte dein Szenario mit CARP in Verbindung mit rsync nicht umsetzbar sein. Es würde lediglich zur Folge haben, dass die bereits übertragenen Daten nach der synchronisation auf beiden Servern vorhanden sind.
Wenn ich dich richtig verstehe ist es aber dein Ziel, dass bereits während des Uploadprozesses zwei FTP(?)-Server gleichzeitig die Daten entgegen nehmen. Bei Ausfall des Server 1 während des Uploads stehen dann die Daten auf dem Server 2 zur Verfügung und der Upload wird nicht unterbrochen.

Eine Übernahme durch den Server 2 beim Ausfall des Server 1 während des Upload-Prozesses kann nicht funktionieren da dies zu inkonsistenten Daten führen würde (Der erste Teil des Datenstroms liegt auf Server 1 und der Rest auf Server 2 - keiner erhielt die gesamten Daten). Wahrscheinlich würde die Übertragung hierbei sogar von der Clientseite unterbrochen.

Vielleicht funktioniert es mit CARP wenn der Zielpfad ein Virtuelles Laufwerk ist welches auf einen Fileserver-Cluster verweist. Ob das allerdings mit den gängigen FTP-Servern funktioniert wage ich zu bezweifeln. Ich könnte mir eher vorstellen,dass Webdav damit umgehen kann.
 
Back
Top