[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AW: LAMP: ansatz korrekt?

Hi,

Am Sonntag, 18. Januar 2009 22:25 schrieb Johannes Walch:
> Markus Hochholding schrieb:
> > Am Montag, 17. November 2008 19:16 schrieb Markus Bucher:
> > * 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.

prinzipiell stimmt das, dass MySQL ziemlich gut und schnell die Replikation 
durchfuehrt. Wenn man aber keine Kontrolle ueber das Netzwerk zwischen Master 
und Slave hat baut man sich hier eine Sollbruchstelle ein.
Noch eine interessante Information zu Typo3: Typo3 liest viel mehr Daten aus 
der Datenbank als geschrieben werden!


[..]
> > 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).

Trotzdem kann man das NICHT als "Es gehen keine Daten verloren." verkaufen!


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

Virtuelle IP ist antuerlich was feines, ist aber auch ein erheblicher Aufwand 
wenn man das Rechenzentrumsuebergreifend machen will und im schlimmsten Fall 
macht der Hoster das garnicht mit.


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

Ich denke wie das System konsistent gehalten wird ist im prinzip jedem Admin 
selbst ueberlassen. Ein zu komplexes System birgt halt Fehler in der 
Bedienung. Zu einfache Systeme sind evtl. nicht flexibel genug.
drbd und gfs Rechenzentrumsuebergreifend zu machen halte ich fuer nicht so 
optimal. Vorallem was die Performance angeht ist drbd und gfs eher fuer lokale 
Netzwerke geeignet. Ausserdem ist es auch komplexer einzurichten und die zwei 
Server sind viel mehr aneinandergekettet.


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

Alternativen zur DNS-Umschaltung? Eine IP Rechenzentrumsuebergreifend zu 
transportieren ist keine billige und triviale Aufgabe.
Der Betrieb der DNS-Server soll natuerlich NICHT auf denselben Servern statt 
finden! Das sehe ich so wie Du: Die meisten Domainhoster bieten ein 
(Web-)Interface fuer die Zonen-Verwaltung an. Wenn das nicht ausreicht kann 
man sich noch immer ueberlegen ob man den Primary betreibt oder evtl. einen 
Hidden Primary, um der Gefahr des Internets zu entgehen ;-)


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

Volle Zustimmung. Wobei das loggen in die MySQL wuerde eine hoehere Last auf der 
MySQL erzeugen was wiederum negativ fuer die Performance des Typo3 sein 
koennte. Ich bevorzuge zmergelog bzw. mergelog um Apache-Log-Dateien 
zusammenzufuehren.


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