Re: Fallback Server

Clemens Hermann schrieb:
>
> Hallo Oliver,
>
> erstmal vielen dank für Deine ausführliche Antwort.
>
> > das mit der automatischen Umschaltung ist das weitaus größere Problem:
> > Woran stellst Du fest, daß ein Rechner nicht mehr geht? Eine Reaktion auf
> > ping ist kein sicheres Zeichen, ob ein Webserver mit DB geht.
>
> hmmmm stimmt, aber man könnte ja per Script auch noch ein paar weitergehende
> Tests machen. Alles recht seicht, weiss schon, aber immerhin kann ich
> (selbst mit dem Ping-Test) alle Fehler feststellen, bei denen der Rechner
> als ganzes den Geist aufgibt (Hardwarefehler, Verklemmungen etc.). Dass mir
> der Ausfall einzelner Dienste durch die Lappen geht muss ich so natürlich
> akzeptieren.

Was hindert Dich daran, beide Server gleichzeitig zu betreiben und
beiden (per DNS-Round-Robin) die haelfte der Last zuzuweisen?

> > Wie teilst Du Deinem Switch mit, daß die IP-Adresse jetzt zu einer
> > anderen MAC-Adresse gehört?
>
> Das müßte ich wohl mit meinem Provider abklären. Sollte ein Switch das nicht
> in dem Moment merken, wenn der Fallback-Rechner das erste Paket schickt?

Im DNS-Round_Robin verfahren merkt der Switch, dass eine von beiden
Kisten down ist. OK, mag seltsame Effekte geben wenn wirklich einer der
beiden Server dwon ist, aber es sollte reichen.

> > Letztlich wirst Du in einem "kleinen" Setup
> > immer wieder einen Single Point of Failure produzieren. Und je
> > zeitkritischer der Fallback ist, desto schlimmer wird es. Wenn Du einen
> > längeren Ausfall an einigen Ecken des Netzes verknusen kannst, dann ist
> > zum Beispiel die einfachste Methode im Falle von Fehlern einfach den
> > DNS-Eintrag umzusetzen auf den anderen Rechner - Du mußt nur die Expires
> > kurz genug setzen (aber so, daß es keinen Ärger vom DENIC gibt ;-))
>
> welchen Wert würdest Du mir denn konkret empfehlen?
> Steigert das denn den DNS-Load signifikant (100 Domains).
>
> > Nochas: erster Schritt wäre einen Mechanismus zu bauen, der die Integrität
> > der daten feststellt, bevor repliziert wird. Es hlft Dir nix, wenn Du eine
> > zerranzte Tabelle replizierst...
>
> Was ich momentan eigentlich "nur" abdecken möchte ist ein HW-Ausfall.
> Irgendwelche SW- oder Integritätsprobleme auf dem Hauptrechner möchte ich
> noch garnicht abfangen.
> Gehe ich recht in der Annahme, dass ich die MySQL Datenbank vor dem Dump
> herunterfahren sollte (sehr unschön)? Ansonsten würde ich doch relativ
> leicht eine "zerranzte" Tabelle auf den Fallback bekommen, selbst wenn auf
> dem Hauptrechner noch alles passt.

Du kannst auch per SQL (dump database, dump table) den inhalt der
Tabellen auf den anderen rechner ziehen. Allerdings ist eventuell in der
Datenbank abgelegte Status-Information danach nicht konsistent.

> > Also mein Tip: Der Aufwand ist sehr hoch. Mach mal eine Abschätzung, ob
> > sich das überhaupt lohnt.
>
> um ehrlich zu sein, mit ein Grund ist, dass ich sowas auch mal gerne machen
> würde. Außerdem bin ich momentan alleine, sollte also im Fall des Falles
> recht schnell greifbar sein. Da der/die Server aber zeitweise 200 Km von mir
> entfernt sind, könnte das ein Problem werden. Geld für eine richtige Lösung
> ist natürlich auch keines da.

Da duerfte Dir der DNS-Round Robin weiterhelfen. Wenn eine Kiste
ausfällt, muss nur der Nameserver aktualisiert werden, oder ein port
redirect auf der kaputten Kiste leitet die anfragen an die
funktionierende weiter.

> > Wir haben unser Setup hier in der Firma so, daß
> > wir täglich den Webserver auf eine zwite Platte replizieren, die als
> > Bootplatte in den gleichen Rechner reingeschoben werden kann.
>
> die Möglichkeit fällt fast flach, weil ich dazu anwesend sein müßte und es
> eher schlecht remote geht ;-). Außerdem kann es recht problematisch sein,
> wenn die Datenbankeinträge eines ganzen Tages fehlen.

Noch ein Argument für den Parallelbetrieb zweier Server...

> > Das macht einen manuellen Eingriff nötig und führt im Falle eines Falles
> > zu einem mehrstündigen Ausfall,
>
> der mehjrstündige Ausfall ist nicht das Problem, sollte ja nicht gerade
> wöchentlich passieren, da der Server einigermaßen gut ist. Das ganze sollte
> halt remote möglich sein und grobe Schnitzer (Totalausfall des
> Hauptrechners) selbständig abfangen können.

Also ist im Worst Case deine Wenigkeit mehrere Stunden vom rettenden
Remote-Zugriff entfernt? Auch hier hilft ein "halb" funktionierender
Server eher weiter als ein ganz kaputter.

Just my EUR .02
-Christoph Sold

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 22 Mar 2001 - 11:56:09 CET