Zum NDS Design gibt es eine Grundsatzaussage: Es gibt keine Musterlösungen für die optimale NDS Struktur.

· Sammlung der notwendigen Informationen

· Bestimmung der Directory Tree Größe

· Aufbau der Struktur

Um die NDS leicht verwaltbar und für die Benutzer leichter zugänglich zu machen, sollte sie nach Arbeitsgruppen unterteilt werden. Die Unterteilungen können nach Abteilungen oder Lokationen aufgebaut sein. Standardmäßig spricht Novell von der Unterteilung nach der Location.

Bei der Aufteilung muß berücksichtigt werden das nur 256 Zeichen für den Objektnamen (CN) und seinem Context zur Verfügung stehen.

In einem relativ kleinem Netzwerk bedarf es keine Unterteilung, so das eigentlich das Container Objekt ausreicht. Der Aufbau kann relativ einfach mit der Simple Installation Option bei der Installation von NetWare 4.11 realisiert werden.

Bei der Zentralisierten Verwaltung der NDS verwalten ein oder mehrere Administratoren das gesamte Netzwerk, also die komplette NDS. Dies ist die Sandart Verwaltungsart.

Verteilte Verwaltung bedeutet, daß der ADMIN den Grundaufbau der NDS erstellt, dann aber die Container Verwaltung an einen User abgibt. Dieses ist bei mehreren Zweigstellen sinvoll, da hierbei schneller auf die Bedürfnisse der Benutzer eingegangen werden kann.

· Container Administration

· Exklusive Container Administration

Darunter versteht man, daß einen Benutzer mit den nötigen Rechten ausgestattet wird um seinen Container dann Administriert. Sollen mehrere Benutzer diesen Container Administrieren, so regelt man das über eine Organisatorische Funktion.

Von einer Exklusiven Container Administration spricht man wenn nur ein Benutzer alle Rechte (also [SBCDR] auf seinen Container bekommt. Dieser wäre dann sogar in der Lage dem ADMIN den Zugriff auf diesen Container zu Verwehren.

Übersicht über mögliche administrative Rollen

Die Komplette NDS Datenbank wird per Default auf jedem Server im Netzwerk eingerichtet.

Die besteht aus:

· BLOCKS.NDS

· ENTRY.NDS

· PARTITIO.NDS

· VALUE.NDS

Und befindet sich im Hidden Directory SYS:_NETWARE.

Änderungen innerhalb der NDS werden sofort auf allen Server Übertragen (Synchronisation). Bei einem Ausfall eines Servers kann ein Benutzer sich problemlos in das Netzwerk einloggen. Der NDS Zugang ist durch die komplette Replizierung der NDS auf allen Servern ständig gesichert.

Die erste Partition wird standardmäßig bei der Installation von NetWare 4 auf dem ersten Server erstellt.

Jede Partition besteht aus einem Container, allen darin enthaltenen Objekten und den Daten zu diesen Objekten. Partitionen enthalten KEINE Informationen zum Dateisystem oder den darin enthaltenen Verzeichnissen und Dateien. Das [ROOT] Objekt ist in der ersten Partition enthalten.

· Parent Partition -Partition, die oberhalb anderer Partitionen sitzt.

· Child Partition -Partition, die unterhalb einer anderen Partition angelegt wurde.

Eine Replilation stellt eine Kopie einer Partition dar. Eine Partition kann auf mehreren Server Verfügbar gemacht werden, dieses nennt man dann Replication.

NetWare 4 kennt vier verschiedene Replikas:

Partitionen erstellen Sie mit dem NDS Manager, der in der 32 Bit Version im Verzeichnis SYS:PUBLIC/WIN95 als NDSMGR32.EXE zu finden ist. Die 16 Bit Version ist die Datei NDSMGR16.EXE im Verzeichnis SYS:PUBLIC.

· Partitions sollten entlang der Grenzen von Arbeitsgruppen erstellt werden.

· Replicas sollten physikalisch nahe beieinander liegen.

· Eine Partition sollte normalerweise weniger als 1500 Objekte, aber auf keinen Fall mehr als 5000 Objekte enthalten.

· Die Anzahl der Subordinate References sollte unter 15 liegen (absolute Höchstgrenze 40)

· Wird im Netzwerk Bindery Service verlangt, sollte vom Bidery Context Container Partitionen und Replicas erstellt werden.

· Eine Replica der [ROOT] muß aus Sicherheitsgründen immer vorhanden sein.

· Unnötiges Erstellen von Partitionen sollte vermieden werden.

· Die Anzahl der Replicas der [ROOT] und anderer Parent Partitions sollte minimiert werden.

· Auf dem Top Level des Trees sollten weniger, auf unterem Level des Trees sollten mehr Partitionen erstellt werden.

· Es kann nur eine Master Replica einer Partition existieren.

· Wenn Sie zwei getrennt aufgebaute Trees miteinander verbinden wollen [DSMERGE], dann gelten folgende Regeln.

Ø Die Server des QUELL TREES, die eine Replica der ALTEN [ROOT] enthalten, bekommen nun eine Read/Write Replica der NEUEN [ROOT]. Gleichzeitig erhalten sie Subordinate References der Root Child Partitions.

Ø Die Server im ZIEL TREE, die eine Replica der [ROOT] enthalten bekommen nun Subordinate References des QUELL TREES.

· Ein NetWare 3 Server, der auf NetWare 4 Upgegraded wurde, bekommt eine Read/Write Replica aller Partitionen mit Bindery Context.

· Ein Server sollte nach der Partitionierung und Replizierung nicht sofort downgefahren werden. Die Synchronisation einer NDS kann bis zu 24 Std. dauern.

· Mindestens 3 Replicas einer Partition anlegen.

· Empfohlen sind 10 oder weniger Replicas.

· Maximal 7 - 10 Replicas pro Server.

· Bei mehreren Standorten sollte 1 Replica außerhalb dieses vorhanden sein.

· Partitions Änderungen nur an der Hauptrepruduktion durchführen.

· Die Hauptrepruduktion sollte nahe bei Verwalter sein.

Ist wichtig für eine korrekte Reihenfolge aller Ereignisse.

Der erste Server im Netz wird automatisch Singel Reference Server. Er kann NICHT zusammen mit einem Primary oder Reference Server koexistieren. Der Singel Reference Server gibt seine eit an Secondary Server weiter und bezieht seine Zeit von seiner Hardware.

Er bekommt seine Zeit vom Reference Server. Er pollt alle Zeitquellen in gewissen Zeitabständen und korrigiert seine Zeit jeweils um 50%. Ist kein Reference Server vorhanden muß mindestens ein anderer Primary Server existieren. Mit diesem kompensiert er dann Fehler in der Zeitabstimmung.

Wenn ein Reference Server eingerichtet werden soll, muß mindestens ein Primary existieren. Der Reference Server bekommt seine Uhrzeit von seiner Hardware. Er gibt seine Zeit an Secondary und Primary Server weiter.

Der Secondary Server synchronisiert sich zu 100 % pro Polling Intervall mit seiner Zeitquelle.

Bei mehr als 8 Std. Differenz sollte am Secondary Server per Hand die Zeitdifferenz mit dem SET TIME Parameter verkürzt werden.

Es gibt zwei Methoden, mit Hilfe derer die Zeit Server die Zeit untereinander abgleichen.

Mit dem Service Advertising Protokoll werden neben Server Informationen auch die Zeitinformationen ausgetauscht. Diese Methode hat den Vorteil, daß keinerlei Konfiguration notwendig ist, da SAP per Default implementiert ist. Nachteilig wirkt sich der Zeitabgleich über SAP bei WAN-Links aus, da das Senden von SAP-Messages (jede Minute) kostenintensiv sein kann.

Über eine Liste kann der Administrator definieren, welche Server als Zeitquellen für den eigenen Server genutzt werden soll. Damit wird ausgeschlossen, daß der eigene Server auf die SAP Zeitinformationen der anderen Rechner hört und selber keine Zeiten über SAP sendet.

Von jeder Partition sollten mindestens 3 Replicas existieren.

· Um eine Partition zu erstellen, benötigen sie das [S] auf den jeweiligen Container b.z.w. das [S] Recht auf die übergeordnete Partition.

· Wichtig ist, die NDS mit SBACKUP oder anderen Tools regelmäßig oder vor großen Änderungen zu sichern.

· Achten Sie darauf das das Volume SYS: nie zu klein wird. Das SYS: Volume beinhaltet die NDS im HIDDEN Directory _NETWARE, das auch mit dem NDIR Command nicht sichbar ist. Wenn das SYS: Volume voll ist, schließen sowohl TTS als auch die NDS. Veränderungen werden dann nicht mehr übernommen. Um dies zu verhindern, sollten folgende Richtlinien eingehalten werden:

· Minimum Space Requirements sollten definiert werden, damit bei eventuellen Platzproblem eine Warnung erfolgt.

· Queues sollten NICHT auf SYS: abgelegt werden.

· User Files sollten nicht auf SYS: abgelegt werden.

· Replicas sollten nicht auf Servern abgelegt werden, die ein Plattenplatzproblem haben.

· SET AUTO TTS BACKOUT FLAG = ON sollte gesetzt werden, um Inkonsistenzen in der NDS zu vermeiden. TTS muß auf allen Servern mit einer aktiven Replica laufen.

Sie sollten gewährleisten, daß auf allen Servern die neuste NDS Version (DS.NLM) existiert. Diese können Sie vom NetWare Web Server (http:\\support.novell.com) herrunterladen.

Eine NDS Datenbank ist dann inkonsistent, wenn die Replica einer Partition nicht synchronisiert werden kann.

Vorgehensweise:

1. Identifikation der Inkonsistenz

2. Nutzung der NDS Dokumentationshilfe, um eine Strategie zur Lösung des Problems zu finden

3. Korrekturen, die das Problem beseitigen, durchführen

Der Administrator sollte erst nach 24 Stunden eingreifen. Grundsätzlich sollten Sie dem System einige Stunden Zeit geben und auf keinem Fall die betroffenen Server herunter fahren. Führen Sie Repair Aktionen nur dann durch, wenn Sie in der Fehlermeldung dazu aufgefordert werden.

Die sauberste Art, einen Server aus der NDS zu entfernen, ist diese bei ihm zu deinstallieren.

Über den Menüpunkt [Directory Option][Remove Directory Services from this Server] im INSTALL.NLM

Ab NetWare 4.1 ist es möglich, mehrere Bindery Contexte zu definieren (bis zu 16). Wird ein NetWare 4 Server in einen Directory Tree eingebungen, wird automatisch in diesem Context ein Bindery Context erstellt.

Dieser Parameter muß in die AUTOEXEC.NCF übernommen werden, wenn der Bindery Context permanent gesetzt sein soll.

NetWare 4 bietet die Möglichkeit, einen existierenden NetWare 3 Server über das Utility NWADMIN mit zu verwalten. NETSYNC ist das NetWare Loadable Module, das die Bindery Informationen auf eine NetWare 4 NDS portiert, indem es die Bindery in einen NetWare 4 Container kopiert. NETSYNC kopiert alle User und Gruppen einer NetWare 3 Bindery (bis zu 12 Server) in den ersten definierten Bindery Context.

NetWare 4 unterstützt Backup und Restore Funktionalität durch das Storage Management Services (SMS).

Auditcon ist ein DOS Utilitie das Container oder Volumes bezogen arbeitet und jegliche Aktionen innerhalb des Netzwerkes mittrackt. In der aktuellen Version ist dies nicht mehr Password geschützt.

In NetWare wird die Funktion des Seitenwechsels verwendet. Eine Seite ist ein 4 KB RAM Block. Im System können physikalisch nicht zusammenhängende Speicherseiten einem logisch zusammenhängenden Bereich zugewiesen werden.

Ein besonderer Augenmerk ist auf den „Langzeit Cache Treffer“ zu richten. Sinkt dieser Wert unter 90% so indiziert dieses zu wenig Speicher, zur kurzfristigen Lösung DOS mit dem Befehl „REMOVE DOS“ aus dem Speicher entfernt werden. Auf langer Sicht gesehen sollte aber mehr Arbeitsspeicher in den Server installiert werden.

Wenn von Netzwerkbenutzern häufig viele kleine Schreibanforderungen vergenommen werden.

Wenn Ihr Server nur langsam auf Leseanforderungen reagiert.

Die Einstellung kann nur in der STARTUP.NCF gemacht werden.

ARCnet kann kein LIP.

Die maximale Anzahl der Paketempfangspuffer. Standard einstellung ist 100 ist häufig zu niedrig für stark ausgelastete Server. Eine Einstellung zwischen 300 und 500 ist für solche Server ideal.

Die minimale Anzahl der Packetempfangspuffer die beim Systemstart zu Verfügung steht. Der Server kann den Packetempfangspuffer bis zum Maximum Packet Receive Buffers steigern. Der Standard Wert ist 50, sollte Ihr Server sofort nach dem Start langsam reagieren, müssen sie hier einen höheren Wert wählen. Dieser kann nur in der STARTUP.NCF eingestellt werden.

Bei Maximum Service Processes handelt es sich um einen verknüpften Parameter. Wenn die Anzahl der Aktuell zugeordneten Service Verfahren (MONITOR.NLM), bereits den Maximal Wert erreicht hat können Sie hier mit den Wert erhöhen. Beachten Sie aber den erhöhten Speicher bedarf der erst bei einem Neustart des Server wieder frei gegeben wird. Der Standard Wert ist 50, es können Werte zwischen 10 und 1000 eingestellt werden.

Mit dem Parameter wird die kleinste Anzahl der in einer Gruppe verarbeiteten Service Verfahren festgelegt. Werden Verfahren von sehr vielen Benutzern angefordert, so kann diese Zahl erhöht werden, um die Anforderung schneller zu verarbeiten.

Die meisten Netzwerkkartentreiber können 15 verschiedene Statistiken aufstellen, darunter allgemeine Fehlereinträge und die Gesamtzahl gesendeter und empfangener Pakete. Die Zahl für „ECB nicht verfügbar“ gibt die Anzahl der Packete an, die wegen nicht verfügbarer Paketempfangspuffer (EVENT CONTROL BLOCKS) nicht übertragen wurden.

Die Software die die Schnittstelle zu einem HBA (Host Busadapter) oder Festplatten Controller darstellt.

Zur optimalen Speichernutzung werden in NetWare 4, Blöcke in Bereiche von jeweils 512 Byte unterteilt.

Die Teilblockzuordnung wird bei der Installation von NetWare 4.11 standardmäßig aktiviert. Während einer angepaßten Installation kann sie deaktiviert und dann zu einem späteren Zeitpunkt aktiviert werden. Wenn die Teilblockzuordnung einmal aktiviert ist, kann sie nicht wieder deaktiviert werden, ohne das Volume neu zu erstellen.

Eine Arbeitsstation kann durch eine einzige Dateilese oder Schreibanforderung bis zu 64 KB an Daten empfangen, ohne eine weitere Anforderung abschicken zu müssen. In NetWare 4 ist das Paket Burst Protokoll automatisch sowohl auf der Arbeitsstation als auch auf dem Server aktiviert. Auf der Arbeitsstation wird automatisch das Paket Burst Protokoll verwendet, wenn von einer Anwendung ein Lese- oder Schreibvorgang ausgeht, der mehr als 512 Byte Daten umfaßt. Anwendungen müssen dazu nicht speziell für die Paket Burst Protokoll eingerichtet werden. Es kann NICHT auf dem Server deaktiviert werden, auf der Client Seite ist dieses aber möglich.

LIP ist auf der Arbeitsstation und auf dem Server automatisch aktiviert. Dieses führt dazu das der Server während der Verhandlung über die Paketgröße keine Suche nach Routern durchführt. Der Router muß dann für eine Paketgröße größer als 512 Byte konfiguriert werden.

Bei ARCnet ist die Verwendung von LIP nicht möglich da hier Topologie bedingt nur eine maximale Paketgröße von 512 Byte vorgesehen ist.

NetWare Router mußen mit dem SET Befehl:

Konfiguriert werden. Der Standard Wert ist 4202 Byte.