Bei Novells Verzeichnisdienst NDS ist das Thema des Designs von Verzeichnisbäumen besonders komplex. Zum einen sind viele NDS-Bäume bereits vor etlichen Jahren und mit einem anderen Anforderungsprofil als heute gültig entstanden. Zum anderen gibt es eine Reihe von Anwendungen auf Basis der NDS, die spezifische Anforderungen an das Design des Baums stellen.
Nicht zu unterschätzen ist auch die Problematik, die sich beim Einsatz unterschiedlicher NDS-Versionen innerhalb eines NDS-Baums ergibt. Denn erst mit NDS 8 wurde die Skalierbarkeit des Verzeichnisdienstes signifikant gesteigert - die Beschränkungen werden aber faktisch immer von der ältesten auf einem Server eingesetzten Version determiniert.
Auf der anderen Seite ist gerade diese verbesserte Skalierbarkeit aber auch ein positiver Faktor. Denn innerhalb von Verzeichnisbäumen lassen sich nun wesentlich grössere Einheiten bilden. Hinzu kommt, dass gerade das NDS eDirectory auch eine relativ grosse Rolle bei E-Business-Verzeichnisdiensten spielt. Dort wird aber oftmals nur mit einem Server und nicht in einer verteilten Struktur gearbeitet. Damit werden aber viele Planungsprobleme, die sich aus den Replikationsprozessen der NDS in WAN-Umgebungen ergeben, hinfällig.
Die NDS orientiert sich am X.500-Modell. Sie unterstützt daher eine hierarchische Strukturierung von Verzeichniseinträgen. Der NDS-Baum kann in die normalerweise nicht genutzten Country-Container und darunter in Organisationen und organisatorische Einheiten aufgeteilt werden. Diese Objekte werden als Container bezeichnet, in denen dann Blattobjekte (leaf objects) angelegt werden können. Beispiele dafür sind Benutzer und Benutzergruppen. Im Laufe der Jahre wurde diese Struktur etwas erweitert, da beispielsweise mit ZENworks und anderen Anwendungen weitere Container-Objekte eingeführt worden sind.
Mit Hilfe dieser Struktur wird das logische Design der NDS entwickelt. Dieses ist aber keineswegs unabhängig von der Kommunikation zwischen Verzeichnisservern.
Die physische Speicherung der Informationen in der NDS erfolgt in sogenannten Partitionen. Eine Partition kann dabei die gesamte NDS-Datenbank oder einen Teil davon umfassen. Alle NDS-Server in einer Partition tauschen wiederum die Änderungen untereinander aus. Faktisch steuert also die logische Struktur der NDS die physische Struktur und diese wiederum die Kommunikation zwischen verschiedenen NDS-Servern und damit die Last im Netzwerk. Von besonderer Bedeutung sind diese Überlegungen, wenn sich ein Netzwerk über mehrere Segmente erstreckt, die durch schmalbandige Leitungen miteinander verbunden sind. In diesem Fall hat das Design der NDS erheblichen Einfluss auf die Bandbreitennutzung und je nach Tarifmodell für die Verbindungen auch auf die Leitungskosten. Das Problem ist zwar in einer Zeit zunehmend günstigerer Leitungen und von Tunneling-Technologien unter Nutzung des Internet nicht mehr von so grosser Bedeutung wie noch vor zwei oder drei Jahren - es darf aber auch nicht vernachlässigt werden.
Typischerweise wird in grösseren Netzwerken immer mit mehreren Partitionen gearbeitet werden. Die Partition root wird automatisch bei der Einrichtung des ersten NDS-Servers angelegt. Darunter können dann weitere angelegt werden. Eine solche Partition umfasst jeweils den gesamten NDS-Baum unterhalb des Containers, bei dem die Partitionierung erfolgt. Allerdings können Partitionen auch wieder weiter untergliedert werden.
Partitionen können repliziert werden. Sobald es in einem NDS-Baum zumindest zwei NDS-Server gibt, erfolgt ohnehin eine solche Replikation. Solange es nur eine Partition gibt, werden einfach alle Informationen in der NDS auf alle Server repliziert. Spannend wird es, sobald mehrere Partitionen vorhanden sind. Dann muss der Administrator definieren, welche Partition auf welche Server repliziert wird.
In diese Überlegung sind drei Aspekte einzubeziehen:
• Es macht Sinn, Informationen der NDS lokal vorzuhalten, um schnell darauf zugreifen zu können. Das NDS eDirectory ab der Version 8 erlaubt zwar durch eine signifikant verbesserte Index-Technologie auch einen relativ schnellen Zugriff auf nicht lokal vorhandene Informationen, was aber nach wie vor langsamer ist als lokale Zugriffe und zudem das Problem birgt, dass über die typischerweise schmalbandige WAN-Verbindung gearbeitet werden muss.
• Das zweite Argument ist die höhere Fehlertoleranz. Die Informationen stehen bei Verwendung der Replikation zumindest immer zwei auf Servern zur Verfügung. Es ist daher auch unbedingt empfehlenswert, von jeder Partition zumindest zwei Replika zu erstellen.
• Die richtige Replikation von Informationen verhindert schliesslich auch Zugriffe über WAN-Verbindungen. In fast allen Fällen ist es effizienter, eine Änderung in einem Verzeichnis einmal zu replizieren statt sie wiederholt abzufragen.
Die NDS unterstützt mehrere Formen von Replika. Es gibt die Master-Replik, die bei der Erstellung der Partition erzeugt wird. Daneben gibt es noch die Nur-Lese-Replik und die Schreib-/Lese-Replik. Die untergeordnete Referenz-Replik (subordinate reference replica) wird nur systemintern verwendet und wird nicht näher betrachtet. Im Regelfall wird mit der Schreib-/Lese-Replik gearbeitet. Nur-Lese-Replika haben den Nachteil, dass bei Anmeldungen von Benutzern beispielsweise die Information über die letzte Anmeldung verändert werden müssen. Damit muss dann weiterhin auf einen anderen Server zugegriffen werden.
Die Last im Netzwerk ist allerdings nicht das einzige Kriterium, an dem sich die Planung der NDS orientieren muss. Verzeichnisdienste sind heute nicht mehr nur ein Werkzeug für die Verwaltung von Anwendern im LAN, sondern zentrale Bausteine von E-Business-Applikationen. Wenn aber Anwendungen wie ein Who's Who auf einem solchen Verzeichnis aufsetzen sollen, funktioniert das nur, wenn sich der Aufbau des Verzeichnisdienstes auch an der organisatorischen Struktur des Unternehmens orientiert.
Während also unter dem Aspekt der Netzlast eine Orientierung an den Standorten in einem Unternehmen sinnvoll ist, weil primär Informationen über Anwender und andere Objekte am lokalen Standort abgefragt werden, stellt sich das mit Blick insbesondere auf die zukünftige Nutzung doch deutlich anders dar.
Die Planungsüberlegungen müssen Faktoren wie die Fehlertoleranz, die Anzahl der Replikas einer Partition, die Grösse der Partitionen und die Verbindungen, über die repliziert wird, einbeziehen und in Einklang mit den Gestaltungsanforderungen an den Verzeichnisdienst bringen. Dabei gibt es keine optimalen Lösungen, die allen Anforderungen gleichermassen gerecht werden. Eine auf die Netzstruktur ausgerichtete NDS-Struktur führt zu Problemen mit Anwendungen, die auf Informationen in der NDS zugreifen, weil dann hierarchische Informationen nachträglich bearbeitet werden müssen. Eine rein an der Organisation orientierte Lösung kann zu erheblichen Problemen mit der Netzlast führen. Zwischenlösungen, bei denen auf unteren Ebenen dann Partitionen definiert werden, führen dazu, dass relativ viele Partitionen und Replika verwaltet werden müssen.
In Anbetracht der Bedeutung von Verzeichnisdiensten als Basis von Anwendungen im Intranet und der sinkenden Kosten für WAN-Verbindungen spricht mittlerweile aber vieles dafür, im Zweifel der organisatorischen Struktur mehr Gewicht zuzuweisen als der Netzlast.
Aber nicht nur die standardmässigen Verhaltensweisen der NDS, sondern auch Produkte, die auf der NDS aufsetzen, können erheblichen Einfluss auf die Planungsüberlegungen haben. Zwei Beispiele dafür sind ZENworks for Desktops und ZENworks for Servers.
ZENworks für Desktops führt eine ganze Reihe von neuen Objekten ein. Dazu gehören verschiedene Anwendungsobjekte, Anwendungsordner-Objekte, Objekte für Policy Packages, Arbeitsstations-Objekte (nicht mit den bekannten Computer-Objekten zu verwechseln) und Arbeitsstationsgruppen-Objekte. Insgesamt sind es rund 50 Objekt-Klassen, die in diesen Gruppen definiert werden. Wie viele Objekte sich daraus ergeben, hängt aber später vom Nutzungsgrad von ZENworks auf der einen Seite und von der Anzahl verwalteter Anwendungen und Arbeitsstationen auf der anderen Seite ab.
Auf diese Objekte wird teilweise von Anwendungen, teilweise aber auch von Benutzern zugegriffen. Daher muss gut überlegt werden, wo sie definiert werden. Die kritischsten Objekte sind dabei die Arbeitsstations-Objekte. Von diesen fallen in etwa so viele Instanzen an wie Benutzer, wenn man davon ausgeht, dass jeder Mitarbeiter einen Computer besitzt. Im Idealfall werden diese Objekte im gleichen Ordner wie die Benutzer abgelegt. Das macht das Design der NDS einfach und hält es flexibel. Alternativ könnte aber auch ein spezieller Ordner für diesen Zweck erstellt werden. Bei der Planung dieser Strukturen ist zu berücksichtigen, dass diese Objekte nicht von Benutzern, sondern direkt von der Client-Software genutzt werden. Die Geschwindigkeit des Zugriffs hängt von der Nähe zwischen Client und Partition ab. Das spricht grundsätzlich für den ersten Ansatz, da auch die Partitionen mit den Benutzer-Objekten typischerweise lokal plaziert sind. Ähnlich sollten auch die Policy Packages nah bei den Benutzern plaziert werden, um einen schnellen und effizienten Zugriff zu gewährleisten.
Bei älteren Versionen der NDS kann zudem noch das Problem entstehen, dass bei Verwendung von ZENworks die Grenze der sinnvollen Partitionsgrösse erreicht wird. Der Maximalwert für die Anzahl der Objekte in einer Partition liegt zwischen 3000 bei NetWare-4.11-Servern vor dem IntranetWare Service Pack 5b und mit einer Version des Directory Service vor 5.99a, 65'000 bei einer NetWare 5-Installation und einer fast unbegrenzten Zahl mit dem NDS eDirectory 8. Die Konsequenz kann sein, dass zusätzliche Partitionen für die Arbeitsstations-Objekte angelegt werden müssen.
Bei ZENworks for Servers liegt die Problematik ebenfalls in der Positionierung der Objekte, die für diesen Dienst angelegt werden. Auch hier kann es zu suboptimalen Strukturen kommen. Um das zu vermeiden, kann es erforderlich werden, eigene Organisationseinheiten für ZENworks for Servers aufzubauen und dort die verschiedenen Objekte abzulegen.
Auch bei eingerichteten NDS-Bäumen steht aber noch viel administrative Arbeit an. Die NDS sind das Herz des Netzwerks. Wenn es Probleme mit der NDS gibt, resultieren daraus auch Probleme bei vielen Netzwerkfunktionen - sei es bei der Anmeldung oder in einzelnen Anwendungen, die auf den NDS aufbauen. Da die Bedeutung der NDS, vor allem im Zusammenhang mit LDAP-Diensten, noch zunimmt und gleichzeitig in E-Business-Anwendungen die Verfügbarkeitsanforderungen steigen, wird es in Zukunft noch wichtiger als bisher sein, die NDS kontinuierlich zu pflegen und potentiellen Problemen dadurch zu begegnen, dass man sie überhaupt nicht entstehen lässt. Dafür ist eine regelmässige, proaktive Analyse der NDS erforderlich.
Zu einer wirklich gründlichen und konsequenten Überwachung des Systems gehört eine ganze Reihe von Einzelmassnahmen. Die verschiedenen Massnahmen lassen sich in drei Gruppen einteilen: die Analyse von Baum, Partitionen und Servern. Dabei wird Top-Down vorgegangen, also vom Baum zum Server.
Innerhalb der drei Gruppen lassen sich dann eine Reihe von Einzelmassnahmen unterscheiden, die teilweise auch in unterschiedlicher Frequenz ausgeführt werden sollten. Der Rhythmus, in dem eine proaktive Analyse der NDS durchgeführt wird, ist von mehreren Faktoren abhängig. Das ist zum einen die Häufigkeit struktureller Änderungen. Wenn sich eine NDS im Umbruch befindet, weil beispielsweise noch Systeme von einer älteren NetWare-Version zu einer neueren migriert werden, sollten die Zyklen für die Überprüfung sehr kurz gewählt werden. Denn in solchen Phasen ist die Gefahr von Fehlern grösser als bei einem eher statischen NDS-Baum, bei dem es kaum Änderungen gibt. Auch wenn Anwendungen hinzugefügt werden und dabei der NDS-Baum verändert wird, wie es in grösserem Umfang typisch beispielsweise bei ZENworks der Fall ist, sollte der Rhythmus der Überprüfung verkürzt werden.
Der zweite Faktor sind die Anforderungen an die Verfügbarkeit. Bei NDS, an die sehr hohe Anforderungen bezüglich der Verfügbarkeit gestellt werden, müssen häufigere Überprüfungen erfolgen. Wenn eine Downtime oder teilweise Nicht-Verfügbarkeit von einigen Stunden akzeptabel ist, ist eine andere Situation gegeben als bei E-Business-Szenarien, die 7 mal 24 Stunden verfügbar sein müssen und bei denen Ausfallzeiten von maximal wenig Minuten akzeptiert werden (99,9% und mehr Verfügbarkeit).
Ein weiterer Faktor ist die Grösse der NDS. In grossen Umgebungen ist das Risiko von Fehlern tendenziell ebenfalls höher. Ausserdem können sich Probleme hier sehr viel stärker auswirken, wenn es eine grössere Zahl von Repliken einer Partition gibt. Deshalb macht auch hier eine häufigere Analyse Sinn.
Nicht zu unterschätzen ist schliesslich der personelle Aufwand, den eine konsequente, proaktive Pflege einer NDS benötigt. Letztlich macht es mehr Sinn, etwas seltener eine gründliche Analyse durchzuführen als zu versuchen, oft Überprüfungen durchzuführen und an dieser Aufgabe dann zu scheitern.
Zur Pflege des Baums gehören eine Reihe einzelner Massnahmen. Zielsetzung ist immer sicherzustellen, dass Funktionen, die den gesamten NDS-Baum betreffen, in korrekter Weise ausgeführt werden. Dazu gehören Massnahmen wie die Kontrolle der Zeitsynchronisation. Diese ist bei der NDS aufgrund des verwendeten Replikationsmechanismus unbedingt erforderlich. Um Replikationsprobleme zu vermeiden, sollte daher das Replikationsverhalten regelmässig analysiert werden. Ebenso gilt es zu überprüfen, ob die Versionen der NDS auf einem einheitlichen und aktuellen Stand sind.
Schliesslich muss auch analysiert werden, ob es weitere NDS-Bäume gibt. Wie wichtig dieser Analysebereich ist, hängt letztlich davon ab, wie streng die Regeln für die Administration des Netzwerks sind. Generell gilt es aber, das Vorkommen weiterer Bäume zu analysieren, um sowohl Probleme für Anwender als auch ein unkoordiniertes Wachstum des Netzwerks zu vermeiden.
Ein weiterer wichtiger Bereich der Analyse ist die Kontrolle der Gesamtstruktur des NDS-Baums mit dem Fokus darauf, dass es jeweils ausreichend - aber nicht zu viele - Repliken gibt, dass eine überwiegend lokale Replikation erfolgt und dass der Replikationsprozess innerhalb von 30 Minuten abgeschlossen werden kann. Letzteres ist für ein korrektes Verhalten der Replikation zwingend.
Auch das Schema sollte ebenfalls regelmässig überprüft werden. Ausserdem macht eine Dokumentation des Schemas Sinn. Dieser Schritt wird immer wichtiger, da eine Anpassung des Schemas durch immer mehr Anwendungen durchgeführt wird.
Die Vielzahl einzelner Massnahmen, die erforderlich sind, macht bereits deutlich, dass die Pflege der NDS kein triviales Unterfangen ist. Gleichzeitig wird, beispielsweise im Zusammenhang mit der Kontinuität, auch schon der enge Zusammenhang zwischen einem optimalen Funktionieren der NDS auf der einen Seite und der Konzeption und Administration des Verzeichnisses auf der anderen Seite deutlich.
Die Pflege von Partitionen beschäftigt sich vor allem mit der Analyse des Replikationsverhaltens, aber auch mit einer sauberen Vorgehensweise bei der Administration von Partitionen und Repliken. Bei der Analyse geht es vor allem um die Kontrolle daraufhin, ob es zu Replikationsfehlern gekommen ist. Ist das der Fall, müssen diese weiter ergründet werden. Ausserdem gehört hierzu auch die Analyse der Container-Grösse im NDS-Baum, um - je nach eingesetzter NDS-Version - zu grosse Einheiten zu vermeiden.
Im Bereich der Administration ist es zur proaktiven Vermeidung von Problemen zudem sinnvoll, vor Änderungen an NDS-Strukturen beispielsweise durch Einrichtung neuer Partitionen oder neuer Repliken vorab Analysen des Status durchzuführen und diese immer in genau definierten Abläufen auszuführen.
Last but not least gilt es auch noch, die einzelnen Server regelmässig zu kontrollieren. Auch hier spielen klare Regeln für den Umgang mit Servern - beispielsweise für das Hinzufügen und Entfernen - eine wichtige Rolle. Es gibt aber auch eine Reihe von Einzelmassnahmen, die regelmässig durchgeführt werden sollten. Dazu gehören die Sicherung der NDS-Datenbank, die Analyse der Backlinks und externen Referenzen, des Obituaries, je nach NetWare-Version auch des TTS (Transaction Tracking System), die Analyse auf unbekannte Objekte und die Überprüfung entfernter Server sowie die Kontrolle einstellbarer NDS-Parameter.
Es stehen eine Reihe von Werkzeugen zur Verfügung, mit denen die Pflege der NDS und die Administration erfolgen kann. Die wichtigsten Anwendungen sind dsrepair.nlm und dstrace.nlm sowie die Administrationsprogramme für die NDS wie die ConsoleOne. Auch dsdiag.nlm kann eine wichtige Rolle spielen. Während die zuerst genannten Anwendungen zum Standardlieferumfang von NetWare gehören, muss dsdiag.nlm gesondert besorgt werden. Es kann über das Dokument TID 2944552 der Knowledge Base von Novell geladen werden.
