Re: LAMP: ansatz korrekt?

Autor: Markus Hochholdinger <Markus_at_hochholdinger.net>
Datum: Sun, 18 Jan 2009 18:14:53 +0100
Hallo,

Am Montag, 17. November 2008 19:16 schrieb Markus Bucher:
> ich habe mir folgendes Szenario ausgedacht und möchte gerne eure Meinung
> dazu hören.
> Ich habe zwei Server, Server 1 und Server 2. Beide zusammen beherbergen
> eine TYPO3-Installation und teilen sich die Arbeit. Einer hält den
> Apache (Server 1), der andere die MySQL-DB(Server 2).
> Server 1 ist MySQL-Slave von Server 2 und hält 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
> ausfällt. 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, während 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, müssen
> die Dateien wieder manuell abgeglichen werden bzw. die DB
> zurückrepliziert werden.
> Was haltet ihr generell von diesem Teil der Umsetzung? Gibt es Fallstricke?

Egal ob das ganze verteilt oder auf einem Server läuft, 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 
ausfällt und zum anderen können Dateien zwischen den rsync-Läufen verändert 
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 Ausfälle im Stunden-Bereich akzeptiert. 
Somit gilt es drei Dinge zwischen Master und Slave möglichst 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 würden dann Anfragen an domain.tld an
> Server 2 geleitet, der seine eigene IP als Ziel zurückgibt und damit
> dann den eigenen Apache anstößt.
> Auch hier die Frage, wo mein Ansatz Lücken, Schwachstellen oder auch
> Fehler hat. Ich freue mich über 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 über DNS zu reagieren erfordert es ein umkonfigurieren 
der entsprechenden DNS-Zone. Am einfachsten man nimmt ein DNS-Namen, welchen 
man schnell ändern kann (niedrige TTL und Nameserver unter guter Kontrolle), 
und setzt alle VirtualHost mit CNAME im DNS darauf. Damit muss man nur ein 
DNS-Einträg ändern, 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 größere Desaster zu 
verhindern ist natürlich ein tägliches Backup sehr wichtig.
Außerdem muss man z.B. Apache-Log-Dateien nach einem Umschalten zusammenfügen 
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.


-- 
Gruß
                                                          \|/
       eMHa                                              (o o)
------------------------------------------------------oOO--U--OOo--
 Markus Hochholdinger
 e-mail  mailto:Markus_at_Hochholdinger.net             .oooO
 www     http://www.hochholdinger.net                (   )   Oooo.
------------------------------------------------------\ (----(   )-
Ich will die Welt verändern,                           \_)    ) /
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/

Empfangen am 18.01.2009

Dieses Archiv wurde generiert von hypermail 2.2.0 : 18.01.2009 CET