AW: LAMP: ansatz korrekt?

[Johannes Walch <j.walch@xxxxxx>]

Markus Hochholding schrieb:
> Am Montag, 17. November 2008 19:16 schrieb Markus Bucher:
> > ich habe mir folgendes Szenario ausgedacht und moechte gerne eure
> > Meinung dazu hoeren.
> > Ich habe zwei Server, Server 1 und Server 2. Beide zusammen
> > beherbergen eine TYPO3-Installation und teilen sich die Arbeit. Einer
> > haelt den Apache (Server 1), der andere die MySQL-DB(Server 2).
> > Server 1 ist MySQL-Slave von Server 2 und haelt einen identischen
> > DB-Stamm per Replikation.
> > Server 2 gleicht per rsync alle x Minuten das Dateiverzeichnis mit
> > Server 1 ab.
> 
> dieses Setup ist nur bei folgenden Bedingungen sinnvoll:
> * Die Server stehen sehr nahe beieinander (z.B. mit einem Netzwerkkabel
> direkt
>   miteinander verbunden).
> * Die Last ist wirklich so hoch, dass ein Server alleine die Anfragen
> nicht
>   schnell genug bearbeiten kann.

Das stimmt nicht unbedingt. Klar ist eine Lastverteilung nur sinnvoll wenn man auch Last hat, allerdings die Replikation klappt auch gut ueber WAN Strecken, SQL macht nicht so viel traffic wenn ich nur Textdaten habe (keine riesigen blobs) und rsync uebertraegt ja ziemlich intelligent nur deltas. 
 
> > Ziel ist es, einerseits performant Seiten auszuliefern, andererseits
> > aber ein fallback-Szenario zu entwerfen, wenn einer der beiden Server
> > ausfaellt. So kann beim Ausfall von Server 1 der abgeglichene
> Datensatz
> > von Server 2 und die ohnehin auf Server 2 vorhandene Live-DB das
> > Webumfeld darstellen, waehrend beim Ausfall von Server 2 die
> > replizierte Backup-Datenbank auf Server 1 aktiviert wird und
> einspringt.
> > Wenn der jeweils ausgefallene Server wieder seinen Dienst tut, muessen
> > die Dateien wieder manuell abgeglichen werden bzw. die DB
> > zurueckrepliziert werden.
> > Was haltet ihr generell von diesem Teil der Umsetzung? Gibt es
> Fallstricke?
> 
> Egal ob das ganze verteilt oder auf einem Server laeuft, beim Ausfall
> des Hauptservers ist bei diesem Setup mit Datenverlust zu rechnen! Zum
> einen kann es sein, dass die MySQL-Replikation nicht fertig ist, wenn
> der Master ausfaellt und zum anderen koennen Dateien zwischen den rsync-
> Laeufen veraendert worden sein. Wenn man damit leben kann ist das Setup
> OK.

Den Status der MySQL Replikation kann man checken, da gibt es beim slave ein "seconds behind".
Bei normalen Verhaeltnissen ist das oft 0, d.h man verliert maximal den letzten eingefuegten Datensatz.
Das ist oft einem Komplettausfall des Systems vorzuziehen (gerade bei einem typo3 Server).

> In diesem Fall wird es darauf hinauslaufen dass es ein Master Server
> und ein Slave Server gibt, welcher bei Ausfall des Master manuell aktiv
> (DNS) geschalten werden kann. Dabei werden Ausfaelle im Stunden-Bereich
> akzeptiert.

Master/Slave ueber DNS halte ich nicht fuer sinnvoll. Ich wuerde lieber eine virtuelle IP nehmen und die dann per heartbeat oder keepalived zwischen den Servern hin und her schalten. Das setzt natuerlich einen Betrieb im selben Ethernet vorraus. Dafuer ist dann aber innerhalb weniger Sekunden umgeschaltet. Die o.g Programme bieten auch die Moeglichkeit im Umschalten dann gleich die notwendigen Schritte vorzunehmen (z.B MySQL von Slave nach Master umbauen).

> Somit gilt es drei Dinge zwischen Master und Slave moeglichst syncron zu
> halten:
> * MySQL-Datenbank mit Master-Slave-Replikation.
> * DocumentRoot mit rsync alle 5 Minuten.
> * Das restliche System von Hand bzw. manuell.

Ja. Fuer das System bietet sich csync2 an, damit kann man bequem die configs gleich halten. Alternativ zum rsync kann man auch mit drbd und gfs arbeiten. Ist aber bei einem Webserver nicht unbedingt sinnvoll, ist ein komplexes Setup, da reicht der rsync eventuell, der ist weniger stoeranfaellig. Gibt es eigentlich sowas wie einen "kontinuierlichen" rsync? D.h ein prozess ueberwacht ein Verz. auf Aenderungen und synct immer dann wenn sich etwas aendert?

> > Mein zweiter Teil betrifft den Nameserver. Ich dachte mir, Server 1
> > als primary und Server 2 als secondary nameserver laufen zu lassen.
> > Im Normalfall beantwortet Server 1 die Anfrage und liefert die IP von
> > Server 1 aus.
> > Im Falle des Ausfalls von Server 1 wuerden dann Anfragen an domain.tld
> > an Server 2 geleitet, der seine eigene IP als Ziel zurueckgibt und
> > damit dann den eigenen Apache anstoesst.
> > Auch hier die Frage, wo mein Ansatz Luecken, Schwachstellen oder auch
> > Fehler hat. Ich freue mich ueber jede Art von Feedback.
> 
> Bei DNS aus Client-Sicht gibt es kein Primary und Secondary. Jeder
> Nameserver antwortet gleichberechtigt auf Anfragen.
> Um bei einem Ausfall ueber DNS zu reagieren erfordert es ein
> umkonfigurieren der entsprechenden DNS-Zone. Am einfachsten man nimmt
> ein DNS-Namen, welchen man schnell aendern kann (niedrige TTL und
> Nameserver unter guter Kontrolle), und setzt alle VirtualHost mit CNAME
> im DNS darauf. Damit muss man nur ein DNS-Eintraeg aendern, wenn man auf
> den Slave umschalten will.
> 
> Damit kann man innerhalb endlicher Zeit auf einen zweiten Server
> ausweichen.

Wie gesagt, auf DNS Umschaltungen wuerde ich hier ganz verzichten. Auch wuerde ich den Betrieb der zonen nicht unbedingt noch auf die Server mit draufpacken, das bieten die meisten domainhoster eh mit an, kostet kaum was und kann man dann schonmal abhaken.

> Wichtig ist bei so einem Setup, dass man beim Administrieren selbst
> nicht durcheinander kommt und ausversehen (z.B. nach dem Umschalten auf
> den Slave) in die falsche Richtung synchronisiert. Um hierbei groessere
> Desaster zu verhindern ist natuerlich ein taegliches Backup sehr wichtig.
> Ausserdem muss man z.B. Apache-Log-Dateien nach einem Umschalten
> zusammenfuegen um korrekte Webauswertungen zu bekommen.

Eine gute Ueberwachung bietet sich bei sowas natuerlich an, genau wie ein schriftlicher desaster recovery Plan.
Apache-Log zusammenfuegen gibt es ein merge tool. Oder man loggt gleich in die MySQL.

Gruss,
Johannes
--
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: http://wiki.uugrn.org/wiki/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/