[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