Vasyl - stock.adobe.com
Wichtige Faktoren für ein stabiles Active Directory
Das Active Directory ist eine der wichtigsten Säulen für den reibungslosen IT-Betrieb. Da lohnt sich ein wenig Konfigurationsaufwand, um mögliche Ausfälle weitgehend zu vermeiden.
Das Active Directory (AD) im Unternehmen ist weit mehr als nur eine einfache Aufgabe für einen der Server. In vielen Unternehmen wird die Technik als zentrale Single-Sign-On-Lösung für alle Anwendungen und Dienste im lokalen Rechenzentrum eingesetzt.
Die damit möglichen Zugangskontrollen decken in der Regel auch alle Workstation-Logins ab, werden aber zunehmend auf die Cloud und damit zusammenhängende Dienste ausgeweitet.
Weil die vom Active Directory bereitgestellten Dienste eine so große Rolle in den meisten Unternehmen spielen, ist es von größter Bedeutung, dass sie jederzeit verfügbar sind und dass sie äußerst widerstandsfähig sind und stabil laufen.
Microsoft hat dies vorausgesehen und dafür gesorgt, dass sich Active Directory auch als verteilte Plattform betreiben lässt, die selbst bei auftretenden technischen Schwierigkeiten ohne oder nur mit minimalen Unterbrechungen weiter funktionieren kann.
Das trifft sogar dann zu, wenn Teile des Systems nicht mehr erreichbar sind. Das war schon nützlich, als AD-Nodes noch rein physische Server waren, die oft über mehrere Racks oder Rechenzentren verteilt wurden, um Ausfallzeiten möglichst gering zu halten. Heutzutage stellt sich aber oft die Frage, wie die beste Methode aussieht, um ein virtuelles AD-Design aufzusetzen?
Active Directory ist im Kern eine verteilte Plattform. Das führt jedoch immer wieder dazu, dass eine Virtualisierung die eingebauten Funktionen zum verteilten Betrieb behindert. AD-Nodes können natürlich weiterhin auf unterschiedlichen Hosts platziert werden.
Außerdem sorgt moderne Failover-Software dafür, dass VMs (virtuelle Maschinen) neu gestartet werden, wenn sie abstürzen. Aber was geschieht, wenn Ihre primäre Storage-Umgebung nicht mehr erreichbar ist? Das ist ein durchaus mögliches Szenario, auf das Sie sich vorbereiten müssen.
Wenn Sie sich mit dem Design einer neuen AD-Umgebung in einer virtuellen Plattform beschäftigen, dann sollten Sie mehr Aspekte einbeziehen als nur den Ausfall der Hosts. Vor allem sind immer wieder auftretende Infrastrukturausfälle relevant, die Ihre kritischen Systeme betreffen können.
Einer der größten Vorteile von mehreren physischen Servern war ja eben der hohe Grad an Verlässlichkeit, der sich aus dieser Anordnung ergeben hatte. Fast niemand will heutzutage aber auf virtuelle Server verzichten. Trotzdem muss man ihre Grenzen und Beschränkungen genau kennen. Auch geht es um weitere Bereiche wie Management-Cluster, auf die Sie sich konzentrieren sollten.
Unter dem Begriff Management-Cluster versteht man low-tier Plattformen, die oft ebenfalls virtualisiert werden, die aber nur Management-Server sowie -Anwendungen und die dafür benötigte Infrastruktur enthalten. Hier sollten Sie auch zumindest ein paar Ihrer AD-Nodes platzieren, so dass sie sich außerhalb der produktiven Umgebung befinden, für deren Verwaltung sie zuständig sind.
Bei einem virtualisierten Management-Cluster bedeutet das aber auch, dass er sich nicht am selben physischen Ort wie die produktiven Systeme befinden darf. Dies würde den gewünschten Effekt der Aufgabentrennung unterlaufen. Sie können aber die meisten kostengünstigen Storage-Plattformen wie etwa virtuelle SANs (vSANs, Virtual Storage Area Networks) für geteilte Speicher oder sogar lokale Kapazitäten dafür nutzen.
Vergessen Sie nicht, dass es sich hierbei um Infrastruktur und nicht um Ihre produktive Kernumgebung handelt. Aspekte wie IOPS (Input/Output Operations Per Second) sind deshalb von weniger großer Bedeutung. Das Ziel ist hier vor allem Verlässlichkeit und nicht maximale Performance. Lokale Netzwerke und RAID-Gruppen reichen in der Regel also meist aus, um die benötigte Leistung zu erbringen.
Active Directory in virtuellen Umgebungen und der Zeitabgleich
Eines der potentiellen Probleme mit AD-Controllern in einer virtualisierten Umgebung ist die dadurch mögliche Zeitabweichung. Alle Computersysteme verfügen über Uhren. Eine ordnungsgemäße Zeiterfassung ist absolut kritisch, wenn es um die Performance und Sicherheit des gesamten Netzwerks geht. Die meisten Server und Workstations erhalten ihre Zeit vom AD. Dadurch laufen alle Systeme synchron und es kommt zu keinen Login-Fehlern bei der Nutzung von Kerberos.
Die so angeschlossenen AD-Server erhalten Informationen über die aktuelle Zeit entweder aus einer bestimmten Quelle, wenn sie physisch sind, oder von den Hosts, auf denen sie laufen. Die AD-Server verwenden dann die interne Uhr auf dem jeweiligen Computer, um mit Hilfe der CPU-Zyklen die Zeit synchron zu halten.
Wenn Sie jedoch einen Server virtualisieren, kann er nicht mehr direkt auf die CPU-Zyklen zugreifen, um seine eigene Zeiteinstellung darauf zu basieren. Dadurch kann es zu Abweichungen der Zeit kommen, bis der Server wieder auf eine externe Quelle zugreift, um seine Zeiteinstellung zu aktualisieren.
Diese Überprüfung wurde aber möglicherweise deaktiviert, da die Verschiebung meist nicht auffällt. Dadurch verschlimmert sich die Situation nach und nach. Die Zeitverschiebung befindet sich dann in einer lästigen Schleife, da die Virtualisierungs-Hosts ihre Zeit meist aus dem Active Directory erhalten.
Das bedeutet, dass Ihre Umgebung auf eine externe Quelle angewiesen ist, die unabhängig von der Virtualisierung ist. Sonst kann es zu den genannten Problemen kommen. Quellen aus dem Internet sind zunächst verlockend. Es ist aus Sicherheitsgründen aber nicht ideal, wenn Ihre Infrastruktur externe Ressourcen zum Abgleich der aktuellen Zeit kontaktiert.
Ein Core Switch oder ein anderes geeignetes zentrales Netzwerkgerät kann jedoch eine zuverlässige Quelle zur Synchronisierung der Zeit sein, dass aufgrund seiner internen Hardware-Uhr selbst in der Regel von keiner Abweichung der Zeit betroffen ist. Sie können diese Quelle dann als Basis für die Synchronisierung der Zeit sowohl auf Ihren Virtualisierungs-Hosts als auch für Ihr AD verwenden. Alle Systeme nutzen dann dieselbe Zeit, die auch wirklich von derselben Quelle stammt.
Manche IT-Profis beharren deshalb auch auf einem einzelnen physischen Server in ihrem virtualisierten Rechenzentrum, der diese Aufgabe erfüllen soll. Das ist durchaus auch eine sinnvolle Option, die aber nicht unbedingt benötigt wird. Virtualisierung ist kein Thema, das beim Design Ihres Active Directorys vermieden werden muss. Es erfordert jedoch einiges an Planung und rechtzeitig durchgeführten Überlegungen, um sicherzustellen, dass Ihre Infrastruktur die verwendete AD-Konfiguration auch stützt. Management-Cluster sind dabei der Schlüssel bei der Trennung von AD-Nodes und -Rollen.
Das bedeutet jedoch nicht, dass keine HA-Regeln (High Availability, Hochverfügbarkeit) für Hyper-V- oder VMWare-Umgebungen erforderlich sind. Sowohl die produktiv genutzten als auch die Managementumgebungen sollten über HA-Regeln verfügen, die verhindern, dass AD-Server auf denselben Hosts laufen.
Weitere Regeln sollten dafür sorgen, dass diese Server als erstes neustarten und dass sie über dediziert für sie reservierte Ressourcen verfügen, um ihre Aufgaben ordnungsgemäß erfüllen zu können. Anfangs noch intelligent aufgesetzte HA-Regeln werden nämlich schnell übersehen, wenn zusätzliche AD-Controller eingeführt werden und die zugrundeliegende Konfiguration der Regeln vergessen wird.
Active-Directory-Ausfälle vermeiden
Das Ziel muss immer sein, Ausfälle zu vermeiden. Leider ist das oft nicht möglich. Deswegen benötigen Sie ausreichend Kopien Ihrer AD-Server und -Rollen an den richtigen Stellen, so dass Ihre Nutzer eventuell auftretende Probleme gar nicht bemerken. Vermutlich werden Sie im Hintergrund etwas in Stress geraten, wenn eine Unterbrechung auftritt, aber das gehört zum Job. Das Wichtigste ist, dass die Kunden und Nutzer normal weiterarbeiten können, ohne es überhaupt mitzubekommen, was für Schwierigkeiten möglicherweise gerade im Hintergrund auftreten.
