Nameserver, Redundanz und Caching

[Andreas Korthaus]

Hallo Philipp!

Zu den Nameserver-Sachen kann ich nicht wirklich viel sagen, aber vielleicht zu der Hochverfügbarkeits-Geschichte:

Wie würdet Ihr vorgehen, wenn ein System mehrfach redundant ausgelegt
werden soll (ungeachtet der Datensynchronisation)? - Mehrere Server,
die auf denselben Hostnamen (virtual host) hören und falls einer
abrauscht, einfach die IP im NS geändert wird (so, dass sie auf einen
Rechner zeigt, der eben nicht offline ist). Das Problem sehe ich hier
schlicht in der Synchronisationszeit der NS-Server (insbesondere
die cachenden nichtautoritiven Nameserver zwischen Client und meinem
Nameserver).

Es gibt sicher viele Wege dies zu realisieren, die beiden Ansätze die mir am besten gefallen sind die folgenden:

1. Du kaufst Dir einen schönen teuren Loadbalancer (z.B. bei Deinem netten Cisco-Händler von nebenan ;-)), hinter dem dann X identische Server (Slaves) stehen. Allerdings musst Du dann dafür Sorge tragen, dass auf den einzelnen Servern kein "Zustand" zwischen den Requests behalten wird, denn es ist nicht gesagt dass der nächste Request auf demselben Slave landet (ich weiß dass manche Loadbalancer das sicherstellen können, es macht die ganze Geschichte allerdings deutlich unflexibler). Das heißt, so Sachen wie Datenbank, Sessions oder lokale Dateien müssen ausgelagert werden. Dann kann ruhig mal ein Server ausfallen, ohne dass man das von außen mitbekommt. Der Loadbalancer hat halt die einzige nach außen öffentliche IP, über den dann alle Requests laufen, die dann nach einem bestimmten Verfahren auf die Slaves verteilt werden.

2. Du hast 2 Server, von denen aber nur einer die tatsächliche Arbeit macht (Master) und der andere (Slave) diesen produktiven Server per Heartbeat überwacht. Sobald der Slave feststellt, dass der Master nicht mehr arbeitet, nimmt er per ARP dessen IP an, so dass neue Requests vom Switch auf den Slave geleitet werden, und dieser somit in kürzester Zeit zum Master wird. Das geht sehr schnell, und dauert nicht Stunden wie beim DNS, da es ja nur an dem Switch umgestellt werden muss, mit dem die beiden Server verbunden sind. Natürlich müssen die Daten auf beiden Maschinen synchronisiert sein. Allerdings ist sowas bei mietbaren Root-Servern normalerweise nicht möglich, da die Übernahme einer fremden IP aus Sicherheitsgründen zu einer automatischen Sperrung des entsprechenden Rechners führt. Das heißt man braucht in dem Netzwerk schon entsprechende Einflussmöglichkeiten.

Die 2. Methode eignet sich sehr gut, um z.B. im 1. Szenario einen dedizierten Datenbank-Server gegen Ausfall abzusichern. Sollte der Master-DB Server mal ausfallen, übernimmt der Slave-DB Server (auf den natürlich ständig die Daten gespiegelt wurden) die IP und Aufgabe des Masters. Natürlich kann man auch hier einen Load-Balancer einsetzen, allerdings nicht so effektiv, da vor allem Schreibzugriffe transaktionssicher synchronisiert werden müssen, aber man könnte z.B. Schreib-Zugriffe von Lese-Zugriffen trennen, und somit die Heartbeat-Methode nur für den einen Master-Server für Schreibzugriffe verwenden, und eine Farm von Slaves per Load-Balancer für Lese-Zugriffe zur Verfügung stellen, oder sogar auf jedem Web-Slave einen DB-Server für Lese-Zugriff installieren. Oder man verwendet entsprechende DB-Cluster aus dem Hause Oracle, IBM & Co. Es gibt zwar auch inzwischen Cluster-Lösungen für MySQL, allerdings habe ich davon noch nicht allzuviel gutes gehört ;-) Cluster haben aber immer den Nachteil, dass Schreibzugriffe ständig im gesamten Cluster synchronisiert werden müssen, was einen nicht zu unterschätzenden Overhead mit sich bringt. Allerdings muss man hier auch unterscheiden zwischen Ausfallsicherheit und Performance.

Es gibt viele größere PHP-Anwendungen die auf diese Weise funktionieren, teilweise mit >100 Slaves...

Siehe z.B. auch http://shiflett.org/archive/46 und http://talks.php.net/show/lt2004-lamp

Viele Grüße
Andreas