[Talk-de] ?Unterstützung für die(?) Server

AK-Palme ak-palme at ak-palme.de
Mo Sep 24 21:17:30 UTC 2007


Hallo alle zusammen,
ich möchte mich kurz vorstellen: Ich heisse Christian und bin der, auf 
den fuesika vor einigen Tagen angespielt hat, also der, der den Server 
administriert.

Zum Thema: Ich habe mich eben erst auf der Liste eingeschrieben, konnte 
daher nicht die ganze Diskussion verfolgen. Ich halte sehr viel von dem 
Projekt und denke dass wir viel erreichen werden :)
Ich selber habe einige theoretische und praktische Erfahrung mit den 
Load-Balancing und Clustering-Thema. Jedoch ist es einige Zeit her, dass 
ich das mit MySQL gemacht habe und es hat sich sicher einiges geändert.

Wenn ich mich für ein Szenario entscheiden müsste, würde ich, ohne die 
finanzielle Lage zu kennen, ein 5-Server-Cluster empfehlen. Dabei gibt 
es 2 Frontend-Server, auf denen der Webserver läuft, und 2 
Backend-Server die die Datenbank beherbergen. Der 5te Server wäre ein 
Fileserver. Die Webserver greifen per NFS auf den Fileserver zu und 
holen die Daten von dort. Dabei besitzen die Webserver einen Disk-Cache, 
damit die Daten vom Fileserver nur mittels rsync partiell übertragen 
werden müssen. Die Backend-Server bestehen aus einem MySQL-Cluster die 
sich selbstständig abgleichen, indem sie die binären MySQL-Logs 
übertragen. So werden die Daten nach wenigen (Milli-) Sekunden 
abgeglichen sein und man kann auf beide Server gleichermassen zugreifen.
Die Webserver würden in einer LoadBalancing-Farm laufen, wobei der 
Server der eine Anfage annimmt aus der IP des Clienten und der Zahl der 
aktiven Server errechnet wird. So passiert es nicht dass Sessions 
ungültig werden, weil der zuständige Server andauernd wechselt. 
Webserver A greift hauptsächtlich auf DB-Server A zu, dazu analog Server 
B. Wenn einer der DB-Server den Geist aufgibt, wird der Webserver das 
binnen Sekunden merken und auf den anderen Server zugreifen. Wenn der 
andere DB-Server wieder da ist, würde MySQL die Daten wieder vom anderen 
Server abgleichen.
Wenn ein Webserver abstürzt, merkt das der andere Server am fehlenden 
Heartbeat und berechnet die Formel der Zuständigkeit neu, und übernimmt 
die gesamte Arbeit.
Diese Architektur hat den Vorteil, dass sie nach oben Problemlos 
erweiterbar ist und dass nicht wirklich 5 Server benutzt werden müssen. 
Z.b. kann der Fileserver auch einer der Webserver sein, oder andere 
Variationen.
Nachteil ist, dass das nichts für "Ich habe einen Server frei" ist, wo 
man mal schnell einen Server für 3 Wochen dazustellt. Besonders, weil 
die Netzwerkkabel zwischen den Servern gekreuzt sind, also jeder ein 
Kabel zu jedem anderen. Es müssten wohl alle in einem Serverschrank stehen.

Zu der Sache, dass man Server schnell auf einen anderen Rechner schiebt 
("Ich habe einen Server frei"), gibt es auch Möglichkeiten die wohl auf 
Xen o. ä. basieren würden. Xen kann Server durch die ganze Welt 
schieben, wobei die Ausfallzeit unter 100ms bleibt.

Zu mir: Theoretisch (und auch praktisch) könnte ich ein Konzept wie 
dieses realisieren. Praktisch bin ich momentan Ausbildungssuchend und 
hoffe, dass ich baldigst etwas finden werde. Es wurde gefordert, dass 
sich da wirklich jemand drum kümmern muss, wozu ich aus dem oben 
genannten Grund keine Zeit habe. Ich pflichte dem jedoch bei, eine 
solche Aufstellung erfordert hohes Know-How und sehr viel Zeit. 
Besonders im Anfangsstatium wird man da viel schrauben müssen. Ich halte 
es leider für relativ unwahrscheinlich, dass jemand diese Zeit 
aufbringen kann, der das wenigstens die ersten 2-3 Jahre nicht als 
Fulltime-Job macht.

Zu den Posts in der dev-Liste: Der root, der dieses Konzept erledigt, 
wird ohne, dass _alles_ mit ihm abgesprochen wird durchdrehen. Die 
Server müssen wirklich syncron bleiben, sonst klappt es nicht.. Ggf. 
sogar netboot-Maschinen die das Betriebssystem vom Fileserver holen. Es 
darf wenn sowas durchgeführt wird, nichts ohne Absprachen gemacht 
werden, und es sollte dringenst 2 roots geben, wobei einer die 
Entscheidungskraft hat und beide so arbeiten wie Programmierer beim 
Extreme-Programming. Soviel zur Theorie, es ist nicht einfach.

Es spricht aber weniger dagegen, wenn, wie sicher auch schon vorher 
erwähnt, wenn untergeordnete Mirrors verwendet werden, die als Read-Only 
nur die Karte anzeigen. Problem hier ist, dass die nicht komplett 
syncron gehalten werden können, da sie optimalerweise in 
Ballungsgebieten aufgestellt würden und von dort die Anbindung nach 
London schlechter ist.

Aber das wichtigste: Alle roots und Entwickler müssen gut miteinander 
klarkommen und nicht irgendsoeinen Quatsch wie z.b. bei den 
Debian-Development-Lists anfangen.

Liebe Grüsse,
Christian

Frederik Ramm wrote:
> Hallo,
>
>   
>>> Also, wenn einer von Euch der Top-MySQL-Mann ist (der also auch genau
>>> weiss, wie sich verschiedene Replikationseinstellung und Netzwerk-
>>> Latenz auf die Performance sehr grosser Datenbanken auswirkt, mit
>>> teils InnoDB und teils MyISAM und so weiter und so weiter - bitte
>>> kein "ich hab mal gehoert, dies und das geht vielleicht...") - direkt
>>> bei Tom Hughes melden. (Nicht Nick Hill, der macht nichts mehr!)
>>>       
>> Hm, hat eigentlich mal jemand offiziell bei mysql AB angefragt?
>>
>> Menschen wie z.B. Kristian Köhntopp könnten da bestimmt passende
>> Tipps geben :)
>>     
>
> Naja, ideal waere jemand, der dann auch beim Projekt mitarbeitet und
> nicht bloss Tips gibt, sondern die auch selber umsetzt ;-) Tip-Geber
> haben wir eine ganze Menge; der haeufigste Tip ist: "Warum nehmt ihr
> nicht PostGIS, da ist das, was ihr braucht, doch alles schon einge-
> baut, und es ist eh alles viel besser und ausserdem ist MySQL doch
> jetzt boese!"
>
> Was alles durchaus sein kann, bloss hat bislang nie jemand den ganzen
> Schmodder nach PostGIS portiert, und so bleibt es bei Spekulation.
>
> Bye
> Frederik
>
>   





Mehr Informationen über die Mailingliste Talk-de