Re: Fallback Server

Hallo

Falls du nicht so viele INSERT, UPDATE Querys hast kannst du diese doch
direkt
auch auf dem zweiten Server durchführen. Somit bleibt die Datenbank immer
aktuell.

Am besten stellst du doch den zweiten Server auf der anderen Seite der
Erdkugel
auf, damit auch Provider-Ausfälle abgefangen werden.

Auf einem Server legst du ein Script ab, dass alle paar Minuten den Server
überprüft. Falls es dieser als down empfindet wird ein weiteres Script auf
einem
anderem Server gestartet. Das letzte ändert dann die DNS-Einträge.
Dadurch wird verhindert, dass bei einem Leitungsausfall gerade der Backup-
Server eingeschaltet wird.

- domi

----- Original Message -----
From: "Clemens Hermann" <haribeau(at)gmx.de>
To: <de-bsd-questions(at)de.freebsd.org>
Sent: Donnerstag, 22. März 2001 10:08
Subject: Re: Fallback Server

> 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.
>
> > 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?
>
> > 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.
>
> > 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.
>
> > 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.
>
> > 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.
>
> Grüße
>
> /ch
>
>
> To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
> with "unsubscribe de-bsd-questions" in the body of the message
>
>

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:49:56 CET