Re: high availability FreeBSD

On Thu, Nov 15, 2001 at 12:01:08AM +0100, universe wrote:
> Bernd Walter wrote:
> > Ein Device für die Aufgabe übers Netzwerk zu verteilen hört sich für
> > mich nach einer Kranken Idee an.
> > 1. Hast du auf zweiten Maschine ein ungeprüftes Filesystem
>
> sorry, ich vergass zu erwaehnen, dass auf allen festplatten ein
> journaling filesystem (reiserfs, xfs) eingesetzt wird.

Das Filesystem weis denoch nichts von seinem Glück.

> > 2. Ist der Rückweg in den Normalbetrieb ist umständlich.
>
> stimmt nicht. der rueckweg ist denkbar einfach: defekte
> hardware-komponenten auf der live node austauschen, live node
> aktivieren, nach erfolgreichem boot-vorgang meldet sich DRBD wieder
> und die neu geschriebenen daten - also diejenigen, die seit dem
> ausfall von live dazugekommen sind - werden jetzt im hintergrund
> automatisch synchronisiert. sobald dieser vorgang beendet ist, kann
> die live node wieder die ip-adresse(n) uebernehmen und die dienste
> starten - fertig.

Sowas funktioniert nicht auf »nur device« Ebene.
Wenn das mit DRBD funktioniert, dann ist das eindeutig mehr, als nur
ein gespiegeltes Device wie deine Urspgrüngliche Mail aussagte.

> > Besser ist es das auf Filesystemebene zu machen.
> > FreeBSD hat fürs Netzwerk NFS und für eine lokale Platte UFS.
> > Jetzt geht man auf "live" hin und mountet »beides« mittels eines
> > Stackable Filessystems zusammen!
> > Man hat dabei ein Filesystem dazwischen, welches dafür sorgt, das
> > Aktualisierungen auf beide darunterliegende Filesysteme gemacht werden.
> >
> > Vorteile:
> > 1. Man ist nicht auf Partitionsboundaries angewiesen.
> > 2. Man hat auf "back" ein immer gültiges Filesystem
> > 3. Man kann den Rückweg per rsync differentiel machen.
> > 4. Du kannst auch differentiell "back" nachsyncronisieren.
>
> bis auf 1. gibt es nicht wirklich einen relevanten unterschied zu
> DRBD. 2. faellt weg. ausserdem fehlt hier natuerlich noch die
> automatische failover-funktionalitaet, also ip-adresse uebernehmen
> etc.

Das fehlt in beiden Fällen und ist natürlich auch nicht einfach.
Z.B. was passiert, wenn beide Server oben sind, aber die Verbindung
einfach nur weggebrochen ist.
Auch hier - ohne Filesystemkooperation nur auf Deviceebene läuft da
gar nichts.

> > Das verstehe ich nicht.
> > Du musst auf beide Platten schreiben.
> > Ohne Schreibcache sind IDE Platten aber gerade dort extrem langsam.
> > Mit Schreibcache hast du keinen Überblick darüber welche Bereiche auf
> > der Platte gerade syncron sind.
> >
> > Abgesehen davon sehe ich dabei das Problem das solche Bastellösungen
> > für mehr Totalausfälle sorgen, als eine Einzelmaschine aleine.
> > Wenn du über solche Preisgünstigen Lösungen nachdenkst bist du mit
> > einer Qualitativ guten Einzelmaschine und Hardware Raid auf SCSI
> > wesentlich besser und vermutlich günstiger bedient.
> > Schneller wirds auch sein, weil du über performatere Kanäle spiegelst.
>
> die geschwindigkeit spielt bei der DRBD-variante keine grosse rolle,
> ob ich jetzt mit 12.5 mb/s (100 mbit/s, theoretisch) die
> synchronisation durchfuehre, mit 25 mb/s oder 80 mb/s ist mir egal. es
> handelt sich ja nur um die synchronisation, und nicht um
> lese/schreibzugriffe die sich fuer den benutzer bemerkbar machen.
> natuerlich spricht ausser den kosten nichts dagegen statt den
> ide-platten scsi fuer bessere performance einzusetzen.

Schau dir mal die MTBF Daten der Hersteller an.
Du steckst jede Menge Arbeit und Geld um etwas mehr Zuverlässigkeit zu
bekommen.
Es macht keinen Sinn dann an günstigerer Ausfallsicherheit zu sparen.
Ebenso verhält es sich bei Raid.
Eine einfache Regel besagt je näher ein Fehler an seiner Ursache
abgefangen werden kann, je einfacher und damit meist auch zuverlässiger
funktioniert die Behandlung.

> das ich bei einer einzelmachine mit guter ausstattung und scsi-raid
> besser dastehe, bezweifle ich. ich kann zwar einen ausfall der
> festplatten dank raid mit grosser warscheinlichkeit ausschliessen,
> aber bei defektem ram, ausfall des netzteils (man kann nicht immer 2
> netzteile einsetzen, z.b. in 1 HE-servern kaum moeglichkeiten), und
> und und, hilft mir nur eine high availability-loesung weiter. :)

Das Platzargument ist eine Nullnummer:
Wenn du 2 1HE Maschinen einsetzen kannst ist auch eine 2HE Dual
Netzteilkiste nicht größer.
Ich halte viele der 1HE Maschinen wegen der Kühlungsproblematik eh
für Ausfallträchtiger.

Ausserdem fehlt bei deiner Betrachtung wie Fehlerträchtig das Failover
selber ist - unterschätze das nicht.

Nicht zu vergessen: für RAM gibt es ECC.
OK einige RAM defekte kann auch ECC nicht beheben - ist aber denoch
wichtig.

Bleibt lediglich CPU und Board, sowie ein geringeres Restrisiko beim
RAM, sowie dem Raidcontroller sofern kein Softwareraid.
Mit guter Qualität ist hier ein Ausfall extrem unwahrscheinlich.
Das Fehlerrisiko von Failoverlösungen halte ich bei den verfügbaren
freien Lösungen für größer.
Es macht aber Sinn die Einzelkomponenten wie Board, usw als Ersatzteil
vorzuhalten.

-- 
B.Walter              COSMO-Project         http://www.cosmo-project.de
ticso(at)cicely.de         Usergroup           info(at)cosmo-project.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message