Novell hat sich in den letzten Jahren konsequent neu ausgerichtet. Noch vor zwei Jahren war das Unternehmen praktisch ausschliesslich auf Lösungen für LANs fokussiert - heute ist es ein Anbieter von E-Business-Lösungen, mit denen sichere und skalierbare Infrastrukturen aufgebaut werden können. Im Kern dieser von Novell als Net Services bezeichneten Produktpalette steht das NDS eDirectory.
Gerade am eDirectory lässt sich auch gut erkennen, wieviel Aufwand Novell in den Schritt vom Netzwerkbetriebssystem hin zu einer E-Business-Plattform gesteckt hat. Nachdem mit NetWare 5 erstmals eine einigermassen brauchbare LDAP-Server-Implementierung, noch auf Basis der NDS-Versionen 7.xx, auf den Markt kam, wurde schon wenig später NDS 8 vorgestellt, mittlerweile als NDS eDirectory bezeichnet. NDS 7.xx, das auch heute noch ausgeliefert wird, ist dabei eine kontinuierliche Weiterentwicklung der ersten NDS-Versionen. Die Basisarchitektur unterscheidet sich nicht wesentlich von den ersten stabilen NDS-Ausführungen. Das wurde erst mit NDS 8 geändert, das eine völlig neue interne Architektur bietet. Bei NDS 8 steht LDAP (Lightweight Directory Access Protocol) als Zugriffsprotokoll auch gleichberechtigt neben den proprietären Novell-APIs für den NDS-Zugriff.
Novell hat damit auf zwei Herausforderungen reagiert. Zum einen muss ein Verzeichnisdienst heute LDAP unterstützen, weil es das Standardprotokoll für den Zugriff auf solche Dienste ist. Das gilt umso mehr, wenn nicht mehr nur interne Anforderungen bedient werden sollen, sondern der Verzeichnisdienst auch Benutzerinformationen, Kundendaten oder andere Objekte von E-Business-Anwendungen speichern soll.
Auf der anderen Seite erfordert der Einsatz mit solchen Anwendungen auch eine hohe Skalierbarkeit. Die NDS haben die Anforderungen von LANs schon früher erfüllen können. Die Skalierbarkeit des Systems wurde kontinuierlich gesteigert, so dass mit NetWare 5 und den NDS 7.xx in einer Partition durchaus bis zu 100'000 Objekte verwaltet werden können. Das ist für den Einsatz in klassischen LANs auch ausreichend, da grössere Netzwerke ohnehin in eine Reihe von logischen Einheiten aufgeteilt werden, die in der NDS auch durch getrennte physische Datenbanken, die Partitionen, abgebildet werden können.
Für E-Business-Anwendungen reicht das aber nicht annähernd aus. Ein Verzeichnisdienst, der beispielsweise die registrierten Kunden einer grösseren Site im B2C-Bereich verwaltet, muss gegebenenfalls Hunderttausende oder mehr von Kundenobjekten speichern können - und er muss einen performanten Zugriff auf diese Objekte garantieren. Auch im CRM-Bereich, also dem Beziehungsmanagement zu Kunden unter Nutzung von Internettechnologien, gibt es genug Fälle, in denen sehr hohe Kundenzahlen zu verwalten sind, die alle durch ein oder typischerweise mehrere Objekte im Verzeichnisdienst repräsentiert werden. Das gilt nicht nur für Banken oder Telekommunikationsunternehmen, sondern auch für den Einzelhandel, Automobilhersteller und viele weitere Bereiche.
Die NDS 8.x und insbesondere die NDS 8.5 sind die Antwort von Novell auf diese Herausforderungen. Mit der neuen Architektur und einer nativen LDAP-Unterstützung können diese Anforderungen erfüllt werden. Damit ist das NDS eDirectory eine wichtige Basis für E-Business-Anwendungen. Hinzukommt, dass Novell mit seinen Net Services mittlerweile ein umfassendes Anwendungsportfolio rund um das NDS eDirectory aufgebaut hat, das insbesondere auf Bereiche wie die Authentifizierung ausgerichtet ist. Novell erarbeitet sich hier mehr und mehr Alleinstellungsmerkmale als Anbieter von sicheren Infrastrukturlösungen für das E-Business.
Das NDS eDirectory 8.5 kann als zweite Version der NDS 8 betrachtet werden. Davor gab es zwar viele kleine Zwischenschritte, die aber mehr dem Bugfixing gedient haben. In der NDS 8.5 finden sich dagegen auch zahlreiche grössere Veränderungen. Viele dieser Neuerungen haben das Ziel, eine bessere Plattform für E-Business-Lösungen zu bieten. Das beginnt schon damit, dass die NDS 8.5 die Basis für Novells DirXML ist. DirXML ist ein Meta-Directory-Dienst, mit dem Informationen zwischen verschiedenen Verzeichnisdiensten, Datenbanken und ERP-Systemen ausgetauscht werden können.
DirXML verwendet das NDS eDirectory als zentrales Repository. E-Business-Anwendungen, die Informationen aus verschiedenen Systemen benötigen, können auf das NDS eDirectory aufsetzen, in das DirXML die benötigten Informationen repliziert.
Mit NDS 8.5 wurde auch ICE (Import Export Conversion) als Utility eingeführt. Mit Hilfe von ICE lassen sich Daten im LDIF-Format (Lightweight Data Interchange Format) und in anderen Formaten einfach in die NDS importieren und aus der NDS wiederum in Dateien schreiben. Das ist insbesondere für das erstmalige Füllen des Verzeichnisses mit Informationen von grosser Bedeutung. Das ICE-Utility lässt sich sowohl über einen Assistenten als auch über Skripts und ein etwas weniger komfortables Tool steuern.
Am wichtigsten für den Einsatz als Verzeichnisdienst für E-Business-Anwendungen sind aber die Erweiterungen in der Cache-Konfiguration und bei der Steuerung von Indizes für den LDAP-Dienst.
Der Cache hat eine zentrale Bedeutung, weil er letztlich darüber entscheidet, mit welcher Performance das NDS eDirectory Anforderungen - seien sie über LDAP oder über die NDS-APIs - bearbeiten kann. Der NDS-Cache wird dabei gesondert von den Puffern von NetWare behandelt, was auch Sinn macht, da die NDS mittlerweile ja auf einer breiten Palette von Betriebssystemen zur Verfügung steht.
Novell empfiehlt, bis zu 80 Prozent des verfügbaren Hauptspeichers dem NDS-Cache zuzuordnen. Ab NDS 8.5 kann der Cache sowohl in absoluten Werten als auch in prozentualen Werten angegeben werden. Dabei sind auch Festlegungen möglich, die beispielsweise 75 Prozent des Hauptspeichers als Cache verwenden, solange noch 48 MB Hauptspeicher für andere Anwendungen zur Verfügung stehen. Eine solche Einstellung würde über dstrace mit !mDYN,%:75,MIN:48000000 definiert. Wichtig ist, dass man bei der Konfiguration der Cache-Einstellungen genau analysiert, welchen Speicherbedarf andere Anwendungen haben. Denn einige Anwendungen reagieren ausgesprochen intolerant, wenn sie nicht ausreichend Speicher belegen können. Die Probleme können dabei bis hin zum Absturz von NetWare-Servern gehen. Beim Einsatz auf anderen Betriebssystemen als NetWare gibt es vergleichbare Parameter, die aber jeweils im Zusammenhang mit den Spezifika dieser Systeme betrachtet werden müssen.
Indizes wiederum steuern, über welche Attribute besonders effizient gesucht werden kann. Standardmässig werden eine Reihe von Attributen wie der Name (common name, CN) der Objekte indiziert. Es kann aber Situationen geben, in denen weitere Attribute in den Index aufgenommen werden müssen. Wenn beispielsweise in einer Who's-Who-Anwendung im Internet über die Telefonnummer gesucht werden kann, macht es Sinn, diese auch zu indizieren. Die Aufnahme von Attributen in den Index ist dabei immer Abwägungssache. Auf der einen Seite führt ein Index zu einer deutlich besseren Performance bei der Suche. Das gilt insbesondere dann, wenn sehr viele Informationen im NDS eDirectory gehalten werden. Auf der anderen Seite benötigt jeder Index Speicherplatz und muss verwaltet werden. Je mehr Indizes es gibt, desto mehr Aufwand entsteht daher auch bei Änderungen im eDirectory.
Indizes werden ab der Version 8.5 des NDS eDirectory als Eigenschaften von Servern gespeichert und können zwischen Servern kopiert werden. Die Konfiguration pro Server ist sinnvoll, da damit für Server mit spezifischen Aufgaben auch spezielle Indizes konfiguriert werden können und nicht alle anderen Server damit belastet werden. Die Indizes werden über das Register Indizes bei den Eigenschaften des Servers festgelegt, wo sie sich auch deaktivieren lassen.
LDAP ist mittlerweile eine Standardfunktion des NDS eDirectory. Bei NDS 7.x war LDAP noch ein Add-on-Dienst, der zusätzlich installiert werden musste. Bei NDS 8 wird LDAP dagegen automatisch eingerichtet. Die erforderlichen NDS-Objekte werden auch automatisch erzeugt. Die NDS arbeiten mit zwei Objekten für LDAP. Das LDAP-Server-Objekt speichert spezifische Konfigurationseinstellungen pro Server. Hier können Festlegungen wie die Port-Nummern, das SSL-Zertifikat und Begrenzungen für die Zeit, die eine Suche in LDAP maximal dauern darf, konfiguriert werden. Das LDAP-Group-Objekt enthält dagegen Festlegungen für eine Gruppe von LDAP-Servern. Das sind Einstellungen, die typischerweise für eine grössere Zahl oder alle Server identisch sind und die daher sinnvollerweise nicht pro Server konfiguriert werden. Dazu sind Einstellungen über das Suchverhalten wie auch zu Schema Mappings möglich.
Schema Mappings bilden zwei Schemata aufeinander ab. Das NDS eDirectory arbeitet mit einem Schema, das zwar aufgrund seiner Orientierung am X.500-Schema viele Ähnlichkeiten mit dem LDAP-Standardschema hat. Aber auch die gemeinsamen Wurzeln - LDAP stammt ebenfalls von X.500 ab - haben nicht verhindert, dass es doch einige Unterschiede gibt. Das beginnt bei den Schreibweisen von Attributnamen, die bei LDAP immer mit einem Kleinbuchstaben, in den NDS aber typischerweise mit einem Grossbuchstaben beginnen, und geht hin bis zur Verwendung des gleichen Attributnamens für unterschiedliche Attribute.
Beim NDS eDirectory ist ein Standard-Mapping vorkonfiguriert, das für viele Einsatzbereiche ausreicht. Sobald aber Erweiterungen des NDS-Schemas vorgenommen werden, um beispielsweise anwendungsspezifische Attribute zu unterstützen, muss das auch im Schema-Mapping abgebildet werden.
Novell hat in Ergänzung zur Definition des LDAP-Standard-Schemas im RFC 2251 einen Internet-Draft für NDS-spezifische Erweiterungen publiziert. Dieses Dokument kann sehr wichtig werden, wenn man bestehende LDAP-Anwendungen auf das NDS eDirectory zugreifen lassen möchte. Hier sind viele spezifische Verhaltensweisen des NDS eDirectory erläutert.
Zu beachten ist auch, dass nicht alle LDIF-Dateien reibungslos mit NDS zusammenarbeiten. Die Problematik entsteht hier dadurch, dass im NDS eDirectory die Regeln der referenziellen Integrität beachtet werden. Das gilt bei LDAP standardmässig nicht. Im eDirectory können beispielsweise keine Objektklassen mit noch nicht existenten Attributtypen definiert werden. Das bedeutet faktisch, dass bei LDIF-Dateien die Reihenfolge der Erstellung und Löschung von Elementen im Schema genau beachtet werden muss.
Insgesamt lässt sich das NDS eDirectory aber mit etwas Übung gut in den Griff bekommen. Wie jedes System hat es seine Besonderheiten, aber auch seine besonderen Stärken.
Mit dem NDS eDirectory stellt Novell ein exzellentes Backend für E-Business-Anwendungen bereit. Das System ist extrem gut skalierbar - die Novell-Demonstrationen mit mehreren Hundert Millionen Objekten im Verzeichnis sind nur ein Beispiel dafür. Darüber hinaus ist es eine Plattform, die ihre Praxistauglichkeit und Stabilität bereits über Jahre bewiesen hat. Und, was man nicht unterschätzen sollte, das NDS eDirectory unterstützt Strukturen, bei denen Informationen in effizienter Weise auf verschiedene Server verteilt werden. Hinzu kommt mit DirXML eine der führenden Meta-Directory-Lösungen und mit Diensten wie Novell iChain und dem NMAS (Novell Modular Authentication Services) auch starke Angebote im Bereich der Sicherheit. Den Schritt von einem LAN-Anbieter hin zu einem Infrastruktur-Anbieter für das E-Business hat Novell zumindest von der technischen Perspektive bewerkstelligt. Die Schwächen liegen heute wohl mehr im Marketing.
