Re: LAMP: ansatz korrekt?

[Markus Hochholdinger <Markus@xxxxxxxxxxxxxxxxx>]

Hallo,

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.


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

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


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

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.

Noch eine Idee ist, sollte der ausgefallene Server noch mit einem laufenden 
System (z.B. Rescue-System) arbeiten, dass man auch eine direkte 
TCP/IP-Umleitung (Port 80) auf den zweiten Server einrichten kann um so z.B. 
Latenzen durch das DNS entgegenzuwirken.


-- 
Gruss
                                                          \|/
       eMHa                                              (o o)
------------------------------------------------------oOO--U--OOo--
 Markus Hochholdinger
 e-mail  mailto:Markus@xxxxxxxxxxxxxxxxx             .oooO
 www     http://www.hochholdinger.net                (   )   Oooo.
------------------------------------------------------\ (----(   )-
Ich will die Welt veraendern,                           \_)    ) /
aber Gott gibt mir den Quelltext nicht!                      (_/



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