nicht angemeldet
Halihallo Andreas
- 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.
Das hatte ich schon seit jeher als langfristige Möglichkeit in
Betracht gezogen. Im Moment ist ein Loadbalancer jedoch nicht
aktuell. Für mich steht jedoch fest, dass dies die beste,
skalierbarste und variabelste Lösung wäre.
- 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 wäre also von der Vorgehensweise genau dasselbe wie eine NS-
Änderung aufgrund Failover-Erkennung (sobald ein Server ausfällt,
wird die IP zur Domain auf den Slave geändert). Nur, dass deine
Lösung natürlich nahezu Realtime ist (was natürlich sehr schön ist).
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.
Genau hier ist mein Problem, ansonsten würde ich nicht mit NS-
Konfigurationen rumbasteln :-)
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.
Gute Überlegungen. Ich hatte jedoch nicht im Sinne ein
hochverfügbares, verteiltes Informationssystem aufzubauen, sondern
einfach Ausfälle und Nichtverfügbarkeit der Server (falls dann mal
ein Server abrauscht) auf ein verträgliches Minimum zu reduzieren :-)
Also die Ausfälle zu reduzieren ist schwierig, denn Technik und
Hardware bleiben Technik und Hardware, aber durch Redundanzen (und
sei es nur eine zweifache) können Ausfallszeiten überbrückt werden.
Nur um mein Ziel noch etwas konkreter zu formulieren:
Es geht nicht darum gar keine Ausfallszeiten zu haben, sondern bei
einem Rechnerausfall, dessen Behebung mehrere Stunden oder Tage
in Anspruch nehmen kann, auf ein Zweit- oder Dritt-System welchseln
zu können. Für mich ist eine Unerreichbarkeit des Servers von 1
Stunde innerhalb akzeptabler Parameter. Über Änderung der NS-
Konfiguration liesse sich dies hoffentlich sicherstellen. Mehr dazu
kommt bestimmt noch in der Antwort zu Sven.
Viele Grüsse und Danke!
Philipp