Re: high availability FreeBSD

On Thu, Nov 15, 2001 at 01:22:34AM +0100, universe wrote:
> Bernd Walter wrote:
> > Das Filesystem weis denoch nichts von seinem Glück.
>
> wie, was? da ein journaling filesystem eingesetzt wird, fallen fsck's
> weg und das filesystem ist permanent clean. wo ist das problem?

Ein Mirror auf Device Ebene weiss nichts vom Journaling und weiss
deshalb auch nicht was zu syncronisieren ist.
Das Journaling-FS weiss wiederrum nichts vom Mirror und weiss nicht
das was überhaupt was zu syncronisieren ist.
Vom Verlust der Incoredaten mal ganz abgesehen.

> > 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.
>
> DRBD sorgt dafuer, dass die daten synchronisiert bleiben. wie ich in
> der ersten mail geschrieben habe, wird fuer die
> failover-funktionalitaet (ip uebernehmen, dienste starten) ein utility
> wie z.b. linux failsafe oder heartbeat eingesetzt.

Du hast zuerst geschrieben, das DRBD auf Device Ebene syncronisiert,
also ohne Einbeziehung des Filesystems.
Das ist eindeutig was anderes als du als Eigenschaften beschreibst!

> > 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.
>
> keine nullnummer. wie du unten selber schreibst, gibt es bis auf das
> netzteil noch genuegend andere komponenten die ausfallen koennen.
> daher macht es kein sinn 2x 2 HE zu verwenden. 2x 1 HE kommt uns um
> einiges guenstiger - jede HE im schrank kostet teuer geld und
> verbraucht unnoetig platz.

Lies den Abschnitt noch mal und du solltest erkennen worauf sich das
bezog.

> > Ausserdem fehlt bei deiner Betrachtung wie Fehlerträchtig das Failover
> > selber ist - unterschätze das nicht.
>
> stimmt, das sollte man nicht vergessen. wie sich das teil in der
> praxis bewaehrt muss man abwarten. aber auch wenn es ab und zu damit
> probleme geben sollte, ist dies immer noch die zuverlaessigste loesung
> von allen high availability (low-cost) varianten, imo.
>
> > 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.
>
> "lediglich" ist gut. das ist ja fast der komplette rechner. wieso
> sollte man nicht alle moeglichen "single points of failure"
> ausgrenzen, wenn man es doch kann?

Du erkaufst dir das mit Nachteilen.
Nämlich dadurch, das du daran sparst wahrscheinlichere Fehler wie
Festplattendefekte oder Ausfall einer Stromebene mit geringer
Komplexität abzufangen.
Die Rechner/Netzteile hängen doch nicht etwa am selben Stromkreis,
oder gar an der selben USV?
 
Single-Point-of-Failure ist auch wenn du dich auf ein Softwaresystem
verlässt:
Das Failover funktioniert nicht.
Oder ein Softwarebug tritt auf beiden Systemen gleichzeitig auf.
Z.B. der Filesystemcode hat einen Bug und schreddert beide Maschinen.

> > Das Fehlerrisiko von Failoverlösungen halte ich bei den verfügbaren
> > freien Lösungen für größer.
>
> ich nicht.

Ich habe bei Qualitativ guter Hardware noch keinen Ausfall der
kritischen Komponenten erlebt.
Und ich habe etliche Server konfiguriert.
Dafür habe ich aber jede Menge Versuche von anderen Failoversysteme zu
betreiben.
Oft war bereits der erste nicht simulierte Ausfall mit einem langen
Ausfall durch nicht ereichen des »wissenden« Technikers in Kombination
mit der »plötzlich« doch notwendigen Handarbeit verbunden.

Das krankt meist daran das die Begeisterung für eine toll klingende
Lösung das Erkennen von praktikablen und teilweise viel bedeutenderen
Punkten vernebelt.

Und wenns doch 2 Rechner sein müssen solltest du die Aufgabe des
Servers überdenken und versuchen die Aufgabe in ein Load-Balancing-
Konzept zu bringen.
Load-Balancer sind wesentlich einfacher gebaut als Failover Systeme
und damit nicht annähernd so Fehlerträchtig.
Leider ist das nicht mit jeder Aufgabenstellung vereinbar.

-- 
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