Unentbehrliches Netzwerk-Know-how (tecCHANNEL COMPACT)
Katastrophenszenarien bei Active Directory - Teil 3
Im dritten Teil unserer Serie rund um Active-Directory-Katastrophenszenarien zeigen wir, wie Sie den Ausfall einer zentralen Komponente abfedern können. Zusätzlich beschreiben wir in einem Workshop die Sicherung der Datenbank.
Auf dieser SeiteActive Directory ist auf eine Reihe von Diensten und Features angewiesen, um korrekt funktionieren zu können. Wenn einer dieser Dienste ausfällt, erleben Sie ungewöhnliches oder unkontrollierbares Verhalten. Unsere fünfteilige Serie stellt Ihnen die häufigsten Szenarien samt Lösung vor. Verlust zentraler ReplikationskomponentenWenn ein Domänencontroller ausfällt, dann merken seine Replikationspartner, dass er nicht mehr auf Update-Anfragen antwortet. Die Partner benachrichtigen den KCC-Dienst, der sich an die Arbeit macht und Verbindungsobjekte erzeugt, die den ausgefallenen Domain Controller umgehen, ganz wie die gelben Umleitungsschilder bei Straßensperrungen. Wird der ausgefallene Domänencontroller wieder verfügbar, merken dies seine Replikationspartner und informieren ihren KCC-Dienst. Der KCC stellt die Verbindungsobjekte zum Domänencontroller wieder her und entfernt die Umleitung. Das kann ein Weilchen dauern, verlieren Sie also nicht die Geduld. Sie sollten zum Schluss einen Eintrag im Ereignisprotokoll sehen, dass der KCC die Verbindungsobjekte erstellen und der DRA die Namenskontexte synchronisieren konnte. Die Situation wird etwas komplizierter, wenn der ausgefallene Domänencontroller spezielle Inter-Site-Replikationsaufgaben hatte. Damit sind Brückenkopfserver und ISTGs gemeint. Neuen bevorzugten Brückenkopfserver auswählenDie Replikation zwischen Sites erfolgt über ausgewählte Domänencontroller, die Brückenköpfe heißen. Normalerweise kümmert sich der KCC selbst um den Ausfall eines Brückenkopfservers, ohne dass Sie als Administrator eingreifen müssten. Er sortiert die vorhandenen Domänencontroller nach ihrer GUID und nimmt dann den Server mit der höchsten GUID. Sie könnten aber vorziehen, dass der KCC die Brückenköpfe aus einer bestimmten Gruppe von Servern auswählt. Beispielsweise sollte nach Möglichkeit ein GC-Server als Brückenkopf dienen, damit partielle Namenskontexte ohne Zwischenstation zum nächsten Standort repliziert werden. Deswegen lohnt es sich, die Kandidatenliste auf GC-Server zu beschränken. Um einen Domänencontroller als bevorzugten Brückenkopfserver auszuweisen, verwenden Sie die Servereigenschaften in ACTIVE DIRECTORY-STANDORTE UND -DIENSTE (siehe Bild 1).  Bild 1: Eigenschaften eines Servers in Active Directory-Standorte und -Dienste, der als bevorzugter Brückenkopf für IP-Kommunikation ausgewählt wurde. Weisen Sie stets mindestens zwei bevorzugte Brückenkopfserver aus. Wenn Sie nur einen auswählen und dieser dann ausfällt, unterbricht die Replikation, bis Sie einen neuen wählen. Wenn der letzte verfügbare Brückenkopfserver ausfällt, müssen Sie so schnell wie möglich einen neuen bevorzugten Brückenkopfserver festlegen, damit die Replikation wieder anfangen kann. ISTG auswählenDer Ausfall eines ISTG stellt kein unmittelbares Problem dar. Die einzig echte Aufgabe des ISTG ist die Erstellung von Verbindungen zwischen Brückenkopfservern. Das geschieht nicht sehr häufig, was aber nicht heißen soll, dass Sie einen Ausfall ignorieren dürfen. ISTG informiert seine Replikationspartner über seine Präsenz, indem er ein Attribut in seinem Objekt alle 30 Minuten aktualisiert. Wenn eine Stunde ohne Update verstreicht, merkt der KCC auf den anderen Domänencontrollern des Standorts, dass ISTG nicht mehr verfügbar ist, und sie suchen sich aus ihrer Mitte einen neuen aus. ISTG kann mit dem Eigenschaftenfenster des Objekts NTDS SITE SETTINGS in ACTIVE DIRECTORY-STANDORTE UND -DIENSTE (Bild 2) identifiziert werden.  Bild 2: Eigenschaften von NTDS Site Settings mit dem ISTG-Server des Standorts. Der KCC verwendet für die Wahl des neuen ISTG denselben Algorithmus wie für die Wahl eines neuen Brückenkopfs. Er nimmt den Domänencontroller mit der höchsten GUID am Standort. Im Fall von ISTG gibt es aber keine Möglichkeit, einen bevorzugten Domänencontroller auszuweisen. Repliken mit Dsastat prüfenWenn die Replikation erst einmal läuft, kann es nicht schaden, wenn Sie sich davon überzeugen, dass die Repliken auf den verschiedenen Domänencontrollern identisch sind. Am einfachsten geht das mit dem Utility Dsastat, das Teil der Support-Tools ist. Öffnen Sie eine Kommandozeile und geben Sie dsastat -loglevel:info ein. Je nach Geschwindigkeit der Anbindungen zu den Replikationspartnern kann es fünf bis 15 Minuten dauern, bis das Utility fertig ist. Am Ende erhalten Sie eine Liste aller Objekte in den Repliken samt deren Größen, sodass Sie Zahl und Größe der Objekte vergleichen können. Ausfall einer WAN-LeitungWenn eine WAN-Leitung zusammenbricht, merken die Brückenköpfe auf beiden Seiten, dass sie keine Replikation mehr vom Partner ziehen können. Wenn eine alternative Verbindung (mit höheren Kosten) zum anderen Standort existiert, verwendet der DRA-Agent auf den Brückenköpfen diese Verbindung automatisch. Der DRA informiert auch den ISTG, der dann versucht, neue Verbindungen zu den anderen Brückenköpfen herzustellen. Sie sollten sich nicht in den Betrieb von DRA und ISTG einmischen. Wenn es ihnen nicht gelingt, einen brauchbaren Replikationspfad zu finden, dann müssen Sie ohne Replikation leben, bis die Leitung wieder funktioniert. Sicherung von Active DirectoryIn der guten alten Zeit konnte man in einer kleinen NT-Domäne die gesamte Registry auf eine einzige Notfalldiskette kopieren oder aber mit Rdisk -S auf die Festplatte, wenn der SAM zu groß für eine Diskette war. Lang ist’s her. Heute existiert das Tool Rdisk nicht einmal mehr.  Bild 3: Ntbackup mit den Dateien des Systemstatus. Active Directory-Operationen benötigen die Registry und zahlreiche andere Systemdateien, sodass Sie weite Teile des Systemverzeichnisses sichern und wiederherstellen müssen. Microsoft bezeichnet diese Dateien als Systemstatus. Abbildung 10.4 zeigt die Liste der Systemstatus-Dateien, wie sie in Ntbackup angezeigt werden. Zu ihnen gehören:
Diese Sicherungsstrategie erhält zwar die Konsistenz zwischen den verschiedenen Datenspeichern. Wenn Sie aber auch nur einen kleinen Fehler machen (der jedoch einen nicht wiederherstellbaren Teil der Registry betrifft), dann müssen Sie möglicherweise alle Systemstatusdateien wiederherstellen – einschließlich des Verzeichnisses! Hier wird beschrieben, wie Sie die Systemstatus-Dateien mit Ntbackup sichern und wieder einspielen können. Ntbackup ist eine funktionsmäßig beschränkte Version von Veritas Backup Exec. Fremdanbieter haben Backup-Produkte im Portfolio, die dieselben Funktionen bieten. Dazu gehört die Vollversion von Backup Exec, Computer Associates ArcServe, Legato Networker, Tivoli Storage Manager, BEI Corporation UltraBac, CommVault Galaxy u.a. Alle diese Hersteller bieten 2003-kompatible Backup-Utilitys an. Achten Sie genau auf die Version, denn ein Windows 2000-Backup-Utility könnte nicht voll kompatibel zu Server 2003 sein. Warum Active Directory-Backups unerlässlich sindMöglicherweise fragen Sie sich, wozu AD-Backups überhaupt notwendig sind. Schließlich sollten Sie in jeder Domäne mindestens drei Domänencontroller betreiben, die jeweils über eine Komplettkopie von Active Directory verfügen. Wenn einer dieser Server ausfällt oder sogar zwei kaputtgehen, so bleibt Ihnen immer noch der Dritte als Ersatz. Sie können schnell einen anderen Windows-Mitgliedsserver zum Domänencontroller befördern und die Fehlertoleranz wieder herstellen. Die nahe liegendste Antwort zu „warum Active-Directory-Backups unerlässlich sind“ lautet, dass Mr. Murphy es merkt, wenn Sie keine Backups machen, und dann das Universum so manipuliert, dass Sie Ihre drei Domänencontroller gleichzeitig verlieren. Ein Feuer könnte Ihren Serverraum komplett zerstören, und dann müssten Sie Active Directory an einem entfernten Standort wiederherstellen. Sie sollten niemals ohne volles Backup leben, damit sich die Sterne niemals in einer Konstellation einfinden, die nicht Ihren Interessen entspricht. Doch die wahrscheinlichere Katastrophenvariante ist ein Fehler auf Seiten des Administrators; das wird früher oder später jedem einmal passieren. Sie sind müde oder abgelenkt, löschen oder ändern das falsche Objekt und schon entwickelt sich die ganze Angelegenheit zur Katastrophe. Wenn Sie versehentlich eine ganze OU mit mehreren tausend Benutzern, Computern und Gruppenobjekten löschen, werden die anderen Domänencontroller davon umgehend per Replikation informiert. Sie bekommen diese OU nur noch von Band zurück. Sie müssen nicht all ihre Domänencontroller sichern. Suchen Sie sich zwei oder drei in Ihrer Domäne aus und sichern Sie den Systemstatus dieser Rechner. Lassen Sie auf Domänencontrollern keine Applikationen laufen, die es erfordern würden, dass sie von lokalen Administratoren gesichert werden. Systemstatus-Backup durchführenEin Systemstatus-Backup wird stets im laufenden Betrieb durchgeführt, d.h. der Rechner hängt am Netz und verrichtet seinen normalen Dienst. Der PnP-Manager sollte Ihr Bandlaufwerk erkennen und die passenden Treiber installieren. Unter Umständen müssen Sie den Wechselmedien-Manager verwenden, um mit Ihren Medienpools zu jonglieren. In Kapitel 20 können Sie mehr dazu nachlesen. Gehen Sie zur Sicherung des Systemstatus mit Ntbackup wie folgt vor:
Systemstatus-Backup, Teil 2
Gehen Sie die Dateiliste im Protokoll durch. Sie werden feststellen, dass die Verzeichnisdateien selbst im Protokoll nicht auftauchen, aber keine Sorge, sie sind trotzdem gesichert. Sie sehen das an dem einen Eintrag, der angibt, dass Active Directory gesichert wurde. Auch die Registry-Dateien sind gesichert, allerdings in Form eines speziellen Ordners namens \Registry und nicht unter ihrem tatsächlichen Standort, \Windows\System32\Config. Dieser Ordner \Registry ist ein flüchtiger temporärer Ordner, in dem ein Schnappschuss der Registry zu Sicherungszwecken abgelegt wird. Dadurch wird die Sperrung der Registry-Dateien vermieden, die den Zugriff auf die Registry während der Sicherung unterbrechen würde. AusblickIm vierten und vorletzten Teil unsere Serie geht es um die Pflege des Active Directories. Neben der Defragmentierung beschreiben wir auch die beiden Wege, eine Datenbank wiederherzustellen. Im nächsten Teil der Artikelserie geht es um den Ausfall von zentralen Replikationskomponenten und den entsprechenden Gegenmaßnahmen.
|
In diesem Beitrag
|
