Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort
1 Warum eine neue Server-Version?
2 Editionen und Lizenzen
3 Hardware und Dimensionierung
4 Protokolle
5 Was ist .NET?
6 Installation
7 Die Core-Installationsoption
8 Active Directory-Domänendienste
9 Netzwerkdienste im AD-Umfeld
10 Active Directory Lightweight Directory Services (AD LDS)
11 Active Directory-Verbunddienste (Federation Services)
12 Active Directory-Zertifikatdienste
13 Active Directory-Rechteverwaltungsdienste (AD RMS)
14 »Innere Sicherheit«
15 Dateisystem und Dateidienste
16 Drucken
17 Webserver (IIS)
18 SharePoint Foundation und SharePoint Server
19 Remotedesktopdienste (Terminaldienste)
20 Hochverfügbarkeit
21 Datensicherung
22 Servervirtualisierung mit Hyper-V
23 Windows PowerShell
Stichwort

Jetzt Buch bestellen
Ihre Meinung?

Spacer
Windows Server 2012 R2 von Ulrich B. Boddenberg
Das umfassende Handbuch
Buch: Windows Server 2012 R2

Windows Server 2012 R2
Rheinwerk Computing
1392 S., 4., aktualisierte Auflage 2014, geb.
59,90 Euro, ISBN 978-3-8362-2013-2
Pfeil 20 Hochverfügbarkeit
Pfeil 20.1 Vorüberlegungen
Pfeil 20.1.1 Allgemeines
Pfeil 20.1.2 Hardware und Konfiguration
Pfeil 20.2 Failover-Cluster
Pfeil 20.2.1 Aktiv vs. Passiv und n+1
Pfeil 20.2.2 Installation
Pfeil 20.2.3 Anwendungen hinzufügen
Pfeil 20.2.4 Cluster schwenken
Pfeil 20.2.5 Feinkonfiguration des Clusters und weitere Vorgehensweise
Pfeil 20.2.6 Clusterfähiges Aktualisieren
Pfeil 20.2.7 SQL Server 2012 installieren
Pfeil 20.3 Network Load Balancing
Pfeil 20.3.1 Funktionsweise des Network Load Balancing
Pfeil 20.3.2 Installation und Konfiguration
Pfeil 20.3.3 Ein paar Hintergründe
Pfeil 20.3.4 Webserver, Kerberos und NLB
Pfeil 20.3.5 NLB-Troubleshooting allgemein

20HochverfügbarkeitZur nächsten Überschrift

Gegen Kalchas zuerst mit drohendem Blicke begann er:
Unglücksseher, der nie auch ein heilsames Wort mir geredet!
Immerdar nur Böses erfreut dein Herz zu verkünden!
Gutes hast du noch nimmer geweissagt, oder vollendet!
Jetzt auch meldest du hier als Götterspruch den Achaiern

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, sodass 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, auch als Failover -Cluster bekannt. 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, sondern über Network Load Balancing (NLB) redundant gemacht werden.
  • Etliche Funktionen werden allein schon dadurch redundant, dass sie 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.

Rheinwerk Computing - Zum Seitenanfang

20.1 Vorüberlegungen Zur nächsten ÜberschriftZur vorigen Überschrift

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 € 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 Geld bringenden Geschäftsprozesse betrifft, ist zumindest in mittleren und größeren Unternehmen auch eine Investition von 500.000 € (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 € dafür bekommen.


Rheinwerk Computing - Zum Seitenanfang

20.1.1 AllgemeinesZur nächsten ÜberschriftZur vorigen Überschrift

Eine wesentliche Anforderung an eine moderne IT-Umgebung ist die Verfügbarkeit derselben. Zunächst muss man sich allerdings darüber klar werden, was nun genau unter »Verfügbarkeit« zu verstehen ist.

ITIL subsumiert unter »Availability« diese Aspekte:

  • Zuverlässigkeit
  • Wartbarkeit
  • Servicefähigkeit
  • IT-Sicherheit

Betrachtet man diese Anforderungen von einem etwas technischeren und serverbezogenen Standpunkt, kann man folgende Punkte nennen:

  • Die Systeme müssen stabil laufen.
  • Im Fall eines eventuellen Ausfalls muss eine möglichst schnelle Wiederherstellung gewährleistet sein.
  • Geplante Ausfälle durch Wartungsarbeiten müssen so kurz wie möglich sein.
  • Es dürfen keine Daten verloren gehen.

Die Anforderungen erscheinen zunächst so trivial wie selbstverständlich. An den im Folgenden beschriebenen Szenarien werden Sie allerdings erkennen, dass die Realisierung alles andere als einfach ist.

Der Worst-Case-Fall

Bei den Betrachtungen zur Verfügbarkeit müssen wir stets vom schlimmsten Störfall, also dem Worst Case, ausgehen. Ein Konzept, das nicht diesen ungünstigsten Fall zugrunde legt, hat letztendlich keinen Wert.

Der Worst Case ist nun nicht zwangsläufig die Landung einer Boeing 747 im Serverraum – vermutlich hätte ein Unternehmen dann ohnehin andere Probleme. Der Worst Case ist im Fall eines Servers beispielsweise ein Ausfall des RAID-Controllers, was zu einem Verlust der gespeicherten Daten führt. Das heißt, die Daten liegen zwar noch auf den Platten, können aber nicht gelesen werden.

Wiederherstellungszeit

Zunächst betrachten wir das Szenario der Wiederherstellung eines Servers, dessen lokale Plattensysteme so ausgefallen sind, dass ein Restore der Daten notwendig wird. Dies könnte beispielsweise im Fall eines RAID-Controller-Defekts vorkommen. Wir gehen von einem Fileserver mit einer Nutzkapazität von 300 GByte aus.

In Abbildung 20.1 ist der Vorgang auf einem Zeitstrahl dargestellt:

  • Um 10:00 fällt das System aus.
  • Kurz danach werden die ersten Störmeldungen eingehen. Bis die Ursache des Problems »Ich kann keine Dokumente mehr speichern« klar ist und die notwendigen Schritte eingeleitet worden sind, vergeht mit Sicherheit eine Stunde. Schließlich ist nicht ständig ein IT-Mitarbeiter in Wartestellung, und wahrscheinlich wird zunächst eine Behebung des Fehlers versucht werden etc.

    Ausfallzeit bis hierhin: 1 Stunde

  • Sofern ein Servicevertrag für die Instandsetzung der Hardware vorliegt, wird diese nach sechs Stunden wieder funktionsbereit sein. Eine Wiederherstellungszeit von sechs Stunden ist der schnellste »Standard-Service-Level«, der gemeinhin von Herstellern und Systemhäusern angeboten wird. (Ein Servicevertrag, der eine Reaktionszeit von vier Stunden garantiert, ist weniger wert als einer mit sechs Stunden Wiederherstellungszeit .)
    Ausfallzeit bis hierhin: 7 Stunden
  • Ist die Hardware wieder funktionsbereit, wird ein gewisser Zeitraum, sagen wir eine Stunde, vergehen, bis tatsächlich mit der Rücksicherung begonnen werden kann. Schließlich muss die Backup-Software betriebsbereit gemacht werden, wahrscheinlich müssen Bänder herausgesucht werden – kurzum: Einige Vorbereitungen müssen getroffen werden.

    Ausfallzeit bis hierhin: 8 Stunden

    Abbildung

    Abbildung 20.1 Wiederherstellung eines Systems

  • Nun beginnt die eigentliche Rücksicherung. Eine Restore-Geschwindigkeit von 300 MByte/min ist eine realistische Annahme (wenn Sie nicht gerade die komplette Backup-Hardware erneuert haben), woraus sich ergibt:

    (300 GByte × 1.024) ÷ 300 MByte = 1.024 min = 17,07 Stunden

    Es muss also von einer Restore-Zeit von ungefähr 17 Stunden ausgegangen werden.
    Ausfallzeit bis hierhin: 25 Stunden

  • Nach Abschluss des Restore-Vorgangs müssen sicherlich noch einige »Nacharbeiten« vorgenommen werden. Dies wird bei einem Fileserver nicht sehr umfangreich sein, daher ist eine Stunde ein realistischer Schätzwert.

    Ausfallzeit bis hierhin: 26 Stunden

Dieses einfache Beispiel zeigt recht eindrucksvoll, welche enormen Risiken in den IT-Systemen stecken: Ein Ausfall eines kritischen Systems von mehr als 24 Stunden kann für viele Firmen akut existenzbedrohend sein, zumindest dürfte er als massive Störung angesehen werden.

Letztendlich ist der zuvor geschilderte Ablauf noch recht optimistisch gewesen. Wenn während des Vorgangs – bei welchem Arbeitsschritt auch immer – Probleme auftreten, verlängert das die Restore-Zeiten eventuell deutlich.

Wenn Sie Optimierungspotenzial suchen, finden sich zwei Ansätze:

  • die Beschleunigung der Hardwarewiederherstellung
  • die Beschleunigung der Rücksicherung

Ersteres lässt sich eventuell mit im Unternehmen gelagerter Ersatzhardware erreichen. Es stellt sich hierbei allerdings die Frage, ob jederzeit ein Mitarbeiter zur Verfügung steht, der Hardwareprobleme eines Servers erkennen und beheben kann.

Die Beschleunigung der Rücksicherung ist natürlich ebenfalls möglich. Schnellere Backup-Hardware und sehr performante Serversysteme ermöglichen zwar höhere Restore-Geschwindigkeiten, dennoch bleibt eine Rücksicherung größerer Datenmengen eine zeitaufwendige Angelegenheit.

Folgende Schlussfolgerung ergibt sich aus dieser Betrachtung für den Worst-Case-Fall:

  • Sofern ein Server bzw. dessen Applikationen nicht länger als beispielsweise vier oder sechs Stunden ausfallen dürfen, ist dies mit einem »normalen« Backup/Restore-Szenario nicht zu schaffen.
  • Vielleicht wird – entweder aus finanziellen Gründen oder weil die Verfügbarkeit für bestimmte Systeme lediglich eine untergeordnete Rolle spielt – entschieden, keine erweiterten Maßnahmen zu ergreifen. In diesem Fall sollte unbedingt schriftlich festgestellt und kommuniziert werden, dass es im Worst-Case-Fall zu längeren Ausfällen kommen kann.

Um das Szenario eines längeren Ausfalls ein wenig anschaulicher zu gestalten, hier ein Beispiel: Ich habe, sozusagen als externer Beobachter, einen zweitägigen Ausfall eines Exchange-Systems in einem Unternehmen erlebt. Dies führte nicht nur dazu, dass ca. 1.500 Benutzer keine Mails mehr schreiben und empfangen konnten. Viel wesentlicher war, dass die Kalenderinformationen nicht mehr zur Verfügung standen. Zu internen Meetings oder Kundenterminen erschienen nur noch diejenigen Mitarbeiter, die ihre Daten regelmäßig auf ein Smartphone repliziert hatten.

Datenverlustzeit

In vielen mittelständischen Unternehmen wird die Wiederherstellung der Systeme nicht mit so hoher Wichtigkeit belegt. Viel entscheidender ist es häufig, sicherzustellen, dass keine Daten verloren gehen.

Betrachten wir ein Szenario auf dem Zeitstrahl (Abbildung 20.2):

  • Die Datensicherung ist um 6 Uhr abgeschlossen.
  • Um 8 Uhr nehmen die Benutzer die Arbeit auf und verändern die Daten.

    Abbildung

    Abbildung 20.2 Die Datenverlustzeit

  • Am Nachmittag um 16 Uhr tritt ein Störfall auf. Dieser fällt in die Kategorie »Worst Case«, es werden also beispielsweise die Festplattensysteme »verloren« (d. h., die Daten sind zumindest nicht mehr zu lesen).
  • Wenn keine zusätzlichen Sicherungsmaßnahmen getroffen werden, bedeutet dies, dass die in diesen acht Stunden produzierten Daten verloren sind (von 8 bis 16 Uhr).

Bei der Betrachtung des Datenverlusts sind zwei Fälle zu beachten:

  • reproduzierbare Daten
  • nicht reproduzierbare Daten

Beispiele für reproduzierbare Daten wären Buchungen von Eingangsrechnungen (die Papierrechnungen liegen ja noch vor und werden nochmals eingebucht) oder eine CAD-Zeichnung, die natürlich auch ein zweites Mal angefertigt werden kann.

Nicht reproduzierbar sind beispielsweise empfangene Mails (wenn man nicht zufällig kurz vor dem Ausfall des Systems seinen Posteingang eingesehen hat, weiß man ja nicht, wer geschrieben hat, und kann daher nicht nachfragen) oder die Auftragseingangsdaten eines Webshops.

Wenn die Anforderung an die IT-Abteilung herangetragen wird, dass ein Verlust von Daten auf einigen oder sogar allen Systemen nicht tragbar ist, müssen weitergehende Maßnahmen ergriffen werden; ein normales Backup/Restore-Konzept ist eindeutig nicht ausreichend.

Man sollte sich nicht von der scheinbaren Sicherheit täuschen lassen, die redundant ausgelegte Server oder mit RAID-Leveln konfigurierte Plattensysteme vorspiegeln: Wir sprechen bei den Überlegungen zur Verfügbarkeit grundsätzlich vom Worst Case, und dieser könnte so aussehen, dass das gesamte Festplattensystem irreparabel beschädigt wird.

Probleme durch logische Fehler

Die zuvor beschriebenen Szenarien basierten jeweils auf einem Hardwareausfall. Natürlich ist auch ein Ausfall wegen eines Problems des Softwaresystems denkbar, beispielsweise eines Konsistenzproblems der Datenbank. Für diesen Fall müssen natürlich ebenfalls planerische Vorkehrungen getroffen werden.

Letztendlich gelten hier die gleichen Fragen, nämlich innerhalb welches Zeitraums die Funktion des Systems wiederhergestellt werden muss und ob ein Verlust von Daten tolerierbar ist.

Bei der Besprechung logischer Fehler denkt man zunächst an Inkonsistenzen in der Datenbank, fehlerbehaftete Software oder versehentlich durch den Benutzer gelöschte Dateien. Zu berücksichtigen ist natürlich auch der Fall eines Vireneinbruchs, bei dem ein komplettes Filesystem innerhalb von wenigen Minuten irreparabel »verseucht« werden kann.

Sie sehen, dass es vielerlei »Gefahren« für die Verfügbarkeit eines IT-Systems gibt, die berücksichtigt werden müssen.

Bewertung der Systeme

Zumeist werden die höchsten Verfügbarkeitsanforderungen nicht an alle Serversysteme gestellt werden. Um die IT-Kosten zumindest einigermaßen im Griff zu behalten, wird man die Systeme unterschiedlichen Kategorien zuordnen, innerhalb deren eine bestimmte Verfügbarkeitsstufe definiert ist:

  • Die »beste« Stufe könnte beispielsweise sowohl eine Wiederherstellungs- als auch eine Datenverlustzeit von maximal zwei Stunden definieren. Hier würde man beispielsweise Server für das ERP-System, die Lagerverwaltung und die Kommunikation (Exchange) definieren – Letzteres, weil die Collaboration-Systeme in einem modernen Unternehmen zunehmend in die Prozesse integriert sind und diese darüber hinaus ein wesentliches Werkzeug für die Kommunikation mit Kunden geworden sind.
  • Eine mittlere Verfügbarkeitsstufe, beispielsweise eine Wiederherstellungs- und Datenverlustzeit von maximal acht Stunden, käme für ein SharePoint-System, einen Fileserver oder diverse Datenbankanwendungen wie etwa ein Angebotssystem in Betracht. Ein Ausfall dieser Systeme ist zwar für ein Unternehmen unangenehm, aber nicht direkt existenzgefährdend.
  • Eine vergleichsweise geringe Verfügbarkeit könnte man für Systeme wie den Zeiterfassungsserver oder ein Softwareverteilungssystem ansetzen. Moderne Zeiterfassungssysteme (Terminals) können für eine gewisse Zeit die erfassten Daten zwischenspeichern. Das Softwareverteilungssystem ist unkritisch, weil im ungünstigen Fall ein oder zwei Tage keine neuen Softwarepakete verteilt werden können, was zumeist kein Problem darstellen sollte. Die Wiederherstellungs- und Datenverlustzeit könnte man mit 24 bis 48 Stunden beziffern.

Je nach den Anforderungen Ihres Unternehmens werden Sie die Verfügbarkeiten der genannten Dienste vielleicht anders bewerten. Die Beispiele zeigen aber in jedem Fall, wie differenziert unterschiedliche Systeme bewertet werden müssen.

Störfall vs. Notfall

Wenn Sie individuell für Ihr Unternehmen planen, welche Verfügbarkeit für welche von Servern bereitgestellte Funktion benötigt wird, werden Sie auf den Unterschied zwischen Störfall und Notfall treffen:

  • Ein Störfall ist ein begrenztes, auf einen Server bezogenes Problem. Der Ausfall eines Netzteils, des gesamten Plattensubsystems oder auch des ganzen Servers mit unbekanntem Grund ist ein Störfall.
  • Unter einem Notfall verstehen wir ein wesentlich umfangreicheres Problem, wie einen Brand oder Hochwasser am Hauptsitz der Firma, in dem auch die IT-Systeme untergebracht sind. Für ein Unternehmen mit mehreren Niederlassungen wird es von Interesse sein, zusätzlich zu dem »Problem« mit der Zentrale nicht auch noch die eventuell deutschland-, europa- oder gar weltweit verteilten Niederlassungen vollkommen lahmzulegen, weil die EDV nicht mehr arbeitet. Ein Notfallkonzept, das möglichst schnell die wesentlichen Dienste wieder bereitstellt, ist also dringend notwendig. Allerdings wird man hier vermutlich die Wiederherstellungs- und Datenverlustzeit anders definieren als bei einem Störfall, bei dem nur ein einzelnes System betroffen ist.

Wenn Sie bei einem kleinen Unternehmen tätig sind, bei dem alle Mitarbeiter an einem Standort sitzen, werden Sie sicherlich nun denken, dass Sie ganz andere Sorgen als die Verfügbarkeit der Daten haben, wenn Ihr Büro durch ein Feuer eliminiert wird. Auf den ersten Blick mag diese Einschätzung richtig sein, auf den zweiten Blick werden Sie feststellen, dass zumindest einige grundlegende Vorkehrungen für den Notfall getroffen werden müssen: Irgendwann wird die Firma wieder arbeitsfähig sein. Wenn dann überhaupt keine Daten mehr zur Verfügung stehen, weil auch sämtliche Datensicherungen ein Raub der Flammen geworden sind, wird es für die Firma unter Umständen unmöglich sein, den Geschäftsbetrieb wieder aufzunehmen. Auch die Hausbank wird sich beispielsweise bei der Vergabe eines Kredits dafür interessieren, ob Vorkehrungen für den Notfall getroffen worden sind: Wenn die Versicherung zwar die Sachwerte ersetzt, der Geschäftsbetrieb aber mangels Unternehmensdaten nicht mehr aufgenommen werden kann, wird die Firma auch nicht mehr in der Lage sein, die Kredite zu bedienen.

Im mittelständischen Bereich werden die Anforderungen für den Notfall sicherlich niemals die Qualität der Service-Level erreichen, die für den Störfall definiert sind. In einem Szenario für eine Firma mit mehreren Außenstandorten könnte man definieren, dass grundlegende IT-Funktionen nach drei oder vier Tagen wieder zur Verfügung stehen sollen; der wichtigste Punkt ist, dass eine möglichst aktuelle ausgelagerte Datensicherung existiert. Die Datenverlustzeit wird letztendlich darüber definiert, wie oft diese ausgelagerte Datensicherung aktualisiert wird.

Auch für einen Kleinbetrieb ist es von entscheidender Notwendigkeit, dass die Datenbestände regelmäßig auf extern aufbewahrte Medien geschrieben werden. Das »kleinste Notfallkonzept der Welt« könnte so aussehen, dass der Geschäftsführer täglich das Band mit der Datensicherung mit nach Hause nimmt; auf diese Weise kann zumindest innerhalb weniger Tage auf einem relativ aktuellen Informationsstand weitergearbeitet werden.


Rheinwerk Computing - Zum Seitenanfang

20.1.2 Hardware und KonfigurationZur vorigen Überschrift

Der vorherige Abschnitt vermittelt vielleicht etwas zu sehr den Eindruck, dass die Vorsorgemaßnahmen vor allem auf Katastrophen aller Art abzielen – vom Großbrand bis zum Flugzeugabsturz.

Die meisten Verfügbarkeitsprobleme werden allerdings von wesentlich weniger spektakulären Ereignissen ausgelöst, z. B. durch Probleme mit der Hardware.

Um es einmal ganz drastisch und unfreundlich zu sagen: Wer Billighardware beschafft, braucht sich nicht zu wundern, wenn die Ergebnisse (d. h. die Stabilität der Systeme) unbefriedigend sind. Auch NT4, das von der Codequalität bei Weitem nicht so gut war wie Windows Server 2008, läuft auf stabiler Hardware mehrere Jahre am Stück – mir sind diverse Beispiele bekannt. Mir sind aber ebenfalls Fälle bekannt, in denen der »Server« aus einzelnen Komponenten im Eigenbau zusammengebastelt wurde und sich dann alle wunderten, dass es ständig Bluescreens gab.

Fakt ist: Ein Serverbetriebssystem gehört auf vernünftige Hardware. Wer beim Kauf der Server auf die »großen vier« Hersteller (HP, Dell, IBM, Fujitsu Siemens) setzt, wird deutlich bessere Ergebnisse erzielen als mit B-Marken oder Selbstbausystemen. Ja, ich weiß, der Preis ist auch nicht zu vernachlässigen. Allerdings ist ein instabiler Server auch das vermeintlich »gesparte« Geld nicht wert!

Einige weitere Aspekte zum Thema »Verfügbarkeit und Hardware«:

  • Überwachung der Hardware: Häufig lassen sich aufkommende Störungen bereits frühzeitig erkennen. Ein Beispiel: Moderne Festplatten können einem Management-System mitteilen, wenn in absehbarer Zeit ein Ausfall zu erwarten ist (Abbildung 20.3). Wer solche Meldungen nicht auswertet, handelt grob fahrlässig!
  • Halten Sie Ersatzhardware vor: Was passiert, wenn Sie bei einem Hardwareausfall einfach keine Ersatzhardware haben oder kurzfristig bekommen können, brauche ich wohl nicht weiter auszuführen, oder?

    Abbildung

    Abbildung 20.3 Eine Serverplatte meldet einen vermutlich bald auftretenden Fehler. Wer solche Meldungen ignoriert, handelt grob fahrlässig und gefährdet die Verfügbarkeit des Systems!

  • Sorgen Sie für ein optimales Sizing der Server: Systeme, die ständig am Rand des Performanceabgrunds stehen, sind erfahrungsgemäß nicht sonderlich stabil. Da neben der Stabilität auch das Antwortverhalten und generell die Geschwindigkeit (aus Sicht der Benutzer) in die Bewertung eingehen, sollten Sie derlei Aspekte ebenfalls bedenken – und kontrollieren!

Ebenso wichtig wie die Hardware des Servers ist die Konfiguration. Hier gilt nach wie vor die alte Weisheit: Trennen Sie die Dienste.

Es ist wirklich keine neue Erkenntnis, aber man kann es nicht oft genug wiederholen: Die Systeme werden nicht stabiler, wenn Sie täglich einen Praxistest durchführen, um festzustellen, wie viele unterschiedliche Applikationsserver auf einer Betriebssysteminstallation ausgeführt werden können. Neben dem Aspekt der »Stabilität« sind bei solchen Systemen auch Administration, Pflege und Wiederherstellung vergleichsweise kompliziert!

Das Designziel »ein Dienst – ein Server« muss heute nicht mehr in einer gnadenlosen Materialschlacht enden. Durch Virtualisierung ist es möglich, mehrere Instanzen des Betriebssystems auf einer Hardware auszuführen – und dabei noch Verbesserungen bei der Wiederherstellungszeit zu erreichen (siehe den nächsten Abschnitt).

Einige weitere Hinweise:

  • Überwachung der Betriebssysteme und Applikationsserver: Sie überwachen die Hardware. Gut! Sie sollten allerdings auch die darauf laufenden Betriebssysteme und Applikationsserver überwachen. Wenn diese unbemerkt in einen »unglücklichen Betriebszustand« laufen, steuern Sie recht zielsicher den nächsten Ausfall an – und der ist sicherlich nicht nur für das gute Aussehen Ihrer Serververfügbarkeitsstatistik ungünstig.

    Systeme wie der Microsoft System Center Operations Manager können hier wertvolle Hilfe leisten (Abbildung 20.4).

  • Halten Sie Datenträger, Seriennummern und Patchdateien griffbereit: Wenn Sie trotz aller Vorsorgemaßnahmen einen Ausfall haben und mit der Wiederherstellung beginnen möchten, wäre das ein sehr unpassender Moment, um mit dem Aufräumen des »Gerümpelschranks« zu beginnen – und schließlich stellt sich noch heraus, dass der Open-Datenträger nebst Seriennummern gar nicht im Hause ist, weil der Praktikant vor zwei Monaten zu Hause etwas installieren wollte.

    Auch aus dem Internet bezogene Patches sollten lokal verfügbar sein, um schnell und ohne großartiges Suchen mit der Wiederherstellung beginnen zu können.

Abbildung

Abbildung 20.4 Ein professionelles Monitoring der Systeme auf Betriebssystem- und Applikationsserver-Level ist ohne ein entsprechendes Werkzeug nicht möglich. Das Bild zeigt die Operatorkonsole des Microsoft Operations Manager.

Zuletzt wären noch einige Sicherheitsaspekte zu nennen: Hierbei sind grundsätzlich Datenklau und Sabotage zu berücksichtigen. Sabotage hat natürlich unmittelbare Auswirkungen auf die Verfügbarkeit der Systeme. Eine mangelhafte Verfügbarkeit resultiert eben nicht nur aus dem Ausfall von Hardware, sondern ebenso aus Sicherheitsproblemen. Hier wären unter anderem Viren und Trojaner zu nennen. Denken Sie beispielsweise an den SQL-Slammer, der massenhaft SQL Server lahmgelegt hat.



Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

<< zurück




Copyright © Rheinwerk Verlag GmbH, Bonn 2014
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern


  Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Windows Server 2012 R2






Windows Server 2012 R2
Jetzt Buch bestellen


 Ihre Meinung?
Wie hat Ihnen das Openbook gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Rheinwerk-Shop: Office 365






 Office 365


Zum Rheinwerk-Shop: Microsoft Hyper-V






 Microsoft Hyper-V


Zum Rheinwerk-Shop: Linux-Server






 Linux-Server


Zum Rheinwerk-Shop: Vmware vSphere 5






 Vmware vSphere 5


Zum Rheinwerk-Shop: Windows 8 für Administratoren






 Windows 8 für
 Administratoren


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo