Leseprobe zu "Windows Server 2008 R2 (eBook)" von Ulrich B. Boddenberg
20 Hochverfügbarkeit (S. 1217-1218)
In den Anfangszeiten der PC-basierten Server war ein (zeitlich begrenzter) Ausfall letztendlich zu verschmerzen. Die Systeme waren halt gemeinsame Festplatten und konnten den gemeinsamen Drucker bedienen, und darauf konnte man auch schon einmal ein paar Stunden verzichten. Mittlerweile sind die Windows Server in den meisten Unternehmen das Rückgrat der IT-Landschaft, so dass ein Ausfall irgendwo zwischen »sehr ärgerlich« und »katastrophal« rangiert. Es ist daher sehr verständlich, dass IT-Verantwortliche bestrebt sind, alle Server möglichst ausfallsicher auszulegen. Bei den wichtigsten Servern wird dazu auch gern ein wenig tiefer in die »Trickkiste« gegriffen. Wenn es darum geht, eine verbesserte Verfügbarkeit eines Servers (oder besser: des darauf laufenden Diensts) zu realisieren, gibt es verschiedene Ansätze:
- Beim Stichwort Hochverfügbarkeit denken die meisten Leser vermutlich an den »klassischen Cluster«, bei dem mehrere Knoten einen gemeinsamen Datenbereich (Shared Storage) nutzen, was auch als Failover-Cluster bekannt ist. Typische Anwendungsfälle sind beispielsweise Dateidienste oder Datenbankserver.
- Die Hochverfügbarkeit kann auch in der Netzwerkschicht realisiert werden: Sind mehrere gleichartige Server vorhanden, werden die Anforderungen der Clients beim Ausfall eines Servers einfach an den oder die verbliebenen Systeme geleitet. Ein typisches Beispiel sind Webserver, die nicht geclustert werden, sondern über Network Load Balancing (NLB) redundant gemacht werden.
- Etliche Funktionen werden allein schon dadurch redundant, dass diese auf mehreren Servern vorhanden sind. Die Paradebeispiele dafür sind das Active Directory oder DNS. Sind mehrere Domänencontroller vorhanden, replizieren diese die Daten. Fällt ein Domänencontroller aus, finden die Clients automatisch einen der anderen DCs.
- Es gibt Applikationsserver, die Hochverfügbarkeit mit ihren Bordmitteln, also ohne Mithilfe des Betriebssystems, realisieren. Ein typisches Beispiel dafür ist die Datenbankspiegelung von SQL Server 2005/2008.
20.1 Vorüberlegungen
Bevor es »so richtig« losgeht, möchte ich Ihnen einige grundlegende Gedanken nahebringen, die mit der technischen Umsetzung eines Hochverfügbarkeitsszenarios zunächst (noch) nichts zu tun haben. »Hochverfügbarkeit« ist zwar als Begriff in aller Munde, dennoch erscheint es mir wichtig, zu prüfen, was ein Unternehmen oder eine Organisation wirklich benötigt und wie viel Geld dafür ausgegeben werden kann. Natürlich können Sie ein System aufbauen, das auch zur Planung und Durchführung der bemannten Mondlandung geeignet wäre. Wenn diese Anforderungen allerdings nicht bestehen, wäre es Geldverschwendung, trotzdem dementsprechend zu investieren.
Anders gesagt: Sie könnten das Geld in wesentlich sinnvollere IT-Projekte investieren, als eine Verfügbarkeit aufzubauen, die vom Business nicht benötigt wird. Ich habe übrigens auch deutlich mehr als einen Fall erlebt, in dem die Geschäftsleitung »Hochverfügbarkeit « bestellt hat und als dann die ersten Kostenschätzungen über 250.000 EUR ins Haus flatterten, war doch alles nicht mehr so wichtig. Die Schlussfolgerung ist nicht, dass man, wenn man nicht gerade die Bank von England ist, lieber gleich die Finger von Hochverfügbarkeitsprojekten lässt, sondern dass man sehr genau prüfen sollte, welchen Wert eine bessere Verfügbarkeit der Systeme für das Business hat, und dementsprechende Vorschläge ausarbeitet.
Wenn das Hochverfügbarkeitsprojekt die geldbringenden Geschäftsprozesse betrifft, ist zumindest in mittleren und größeren Unternehmen auch eine Investition von einer halben Million Euro (und mehr) sicherlich kein Problem. Ist nur ein »Nebensystem« betroffen, dessen Ausfall keine signifikanten Auswirkungen auf das Business hat, werden Sie vermutlich keine 5.000 EUR dafür bekommen.
