[über] [Word-Doku] [Pegasus Mail] [WWW und HTML]
(Mai 2001, September 2002)
Skript
Links
Zurück zur Kurs-Seite.
Die Informationen sind, neben den unten angegebenen Internet-Quellen vor allem dem folgenden Buch entnommen: Administering NDS (Nancy Cadjan und Jeffrey L. Harris) New York 1999. Das Buch ist allerdings recht teuer (ca. 50 €), auf Englisch und zumindest bei Amazon nicht mehr erhältlich. Das behandelte Thema finden Sie dort in Kapitel zwei ab Seite 38.
Dieses Skript ist entstanden anläßlich meines Kurses bei den Eckert-Schulen im Rahmen von "Betriebssysteme 2"
Zeit ist (sehr oberflächlich definiert) eine Größe, mit der wir Ordnung in die Abfolge von Ereignissen bringen, indem wir sie in Beziehung zu anderen, periodisch ablaufenden Ereignissen wie der Erddrehung bringen. Computer kennen keine Zeit, sie können nur über die eingebaute RealTimeClock (RTC) einen Zahlenwert auslesen, der mit der realen Zeit in eine semantische Übereinstimmung gebracht wurde. Außerdem kann man natürlich von einem Computer die "Zeit" des anderen auslesen und so beide Rechnerzeiten synchronisieren. Nur wenn extra dazu gesagt, bedeutet "Zeit" hier auch echte, reale Zeit, ansonsten geht es hier um die Zeit des Computers, die er aus einer Uhr erfährt.
Wenn in einem Netzwerk die Daten in einer zentralen Datenbank wie den NDS (Novell) oder Active Directories (das Produkt von Microsoft) abgelegt werden, und nicht wie bei Windows NT auf jedem Server einzeln Daten wie Benutzer/Paßwort etc. gespeichert sind (Bindery), muß man diese Daten eindeutig halten. Dazu ist es wichtig festzulegen, welche Änderung vor einer anderen abzuarbeiten ist. Wird diese Reihenfolge durcheinander gebracht, führt das zu Inkonsistenz der Datenbank.
Um die Reihenfolge der Änderungen festzustellen, wird die Zeit eines Befehls jeder Änderungsmitteilung als Zeitstempel beigefügt.
Es ist klar, dass für ein Netzwerk nicht unbedingt die wirkliche Zeit benötigt wird. Es reicht zunächst aus, dass alle Server mit der gleichen Zeit arbeiten. Lediglich aus praktischen Gründen wird man natürlich trotzdem meistens eine reale Zeit verwenden wollen. Aber unbedingt erforderlich ist das nicht.
Es wäre eventuell denkbar, eine eindeutige Zeit dadurch sicherzustellen, dass absolut jeder Rechner im Netzwerk an eine eigene genaue Zeitquelle (Funkuhr oder gar eine Atomuhr) angeschlossen wird; denn wenn die Uhren ausreichend genau gehen, bedarf es keiner Synchronisierung. Dieses Vorgehen ist aber schon aus Kostengründen nicht machbar.
Die Synchronisierung der Zeit findet nur in bestimmten Abständen statt. In der Zwischenzeit verwenden die Server die Zeit, die ihnen die eingebaute RealTimeClock (geeicht durch eines der hier vorgestellten Verfahren) zur Verfügung stellt. Das übliche Intervall der Aktualisierung beträgt etwa 10 Minuten.
Früher bei Novell und auch heute noch bei Microsoft wird eine andere Methode verwendet, um irgendwelche Änderungen im Netzwerk eindeutig und der Reihenfolge nach zu kennzeichnen. Dabei wird jeweils von jedem Server eine fortlaufende Versionsnummer für jede Änderung vergeben.
Dies System funktioniert bei bis zu zwei Servern (oder mehr bei Bindery-Netzwerken ohne zentrale Datenbank): Entweder wird die Änderung gleich auf dem ändernden Server auch in die Datenbank aufgenommen, dann benötigt man eigentlich gar keinen Zeitstempel. Oder die Änderung geht mit fortlaufender Nummer an den anderen Server. Da der nur vom ersten Server Änderungsmeldungen erhält, ist die Reihenfolge der Änderungen immer ersichtlich.
Es ist klar, dass dieses System schon ab drei Servern an seine Grenzen kommt. Bei Windows NT wird noch dazu immer der gesamte User-Datensatz neu geschrieben, auch wenn z.B. nur ein Paßwort geändert wurde, es wird nicht etwa nur das Paßwort neu gesetzt. Dadurch ergeben sich potentiell sehr viele Überschneidungen, die ohne wirksame Bestimmung der Reihenfolge schon bei unterschiedlichen Laufzeiten der Meldungen im Netzwerk zu Inkonsistenzen führen.
Die NDS (Netware Directory Systems, auch eDirectory) sind bloß eine Datenbank für Netzwerkobjekte (Nutzer, Server, aber auch einzelne Dateien auf einem Netzwerklaufwerk). Es ist daher nötig, ein darunter liegendes Netzwerk-Betriebssystem zu verwenden (NOS, Network Operating System). Sinnvoller Weise wird man die Zeitsynchronisierung als Teil des NOS einbauen, nicht in den NDS, da diese ja erst auf die Technik aufsetzen sollen, die vom NOS zugänglich gemacht wird.
Als Quelle für das Zeitsignal fungiert entweder eine Atomuhr, eine Funkuhr (z.B. DCF 77), ein Server im Internet oder eine Verbindung über Modem. Wenn keine dieser Quellen zur Verfügung steht, kann man als Notlösung auch die interne Uhr eines Servers verwenden.
Mit dem Befehl ping können Sie die Signal-Laufzeit zu einem beliebigen Rechner im Internet testen. Dabei werden Sie feststellen, dass diese größer Null ist und zusätzlich leicht variiert. Daraus ergibt sich ein grundsätzliches Problem für die Zeitsynchonisierung.
Lösung: statistische Methode, Rundlauf --> als Zeit für den Weg von Server A zu Server B wird die Hälfte der Zeit angenommen, die ein Signal von A zu B und wieder nach A zurück benötigt
Probleme neben der potentiellen Ungenauigkeit: erhöhte Netzwerklast, Zeitkonsument muß als Server arbeiten.
Auswahl nach der Größe des Netzwerks
Die Server, die als Zeitserver dienen, lassen sich nach ihrer Stellung wie folgt beschreiben:
Trivialfall
o o
o o
Problem bleibt ungelöst (Anarchie - Chaos - Untergang :-) ).
[Single Reference]
|
|
-----------
| |
[Secondary] [Secondary]
Vorteil: keine besondere Strategie für die Synchronisierung nötig
Nachteile: Netzwerklast (besonders im WAN); keine Redundanz / Ausfallsicherheit
[Primary] [Primary] [Primary] ---> bestimmen voted time unter sich
|
|
--------------------------
| | |
[Secondary] [Secondary] [Secondary]
Redundanz / Ausfallsicherheit werden gewährleistet, durch geschickte Verteilung der Primary-Server kann die Netzwerklast gering gehalten werden.
Aber (in diesem Modell, das nur zur Anschauung dient, aber so nicht realisiert werden wird) kein Abgleich mit der wahren Zeit. Es fragt sich, wie man mit der wahren Zeit abgleicht, vor allem, welcher der Primary Server mit der wahren Zeit abgeglichen wird.
Die Lösung für das eben erwähnte Problem bietet eine Time-Provider Group:
Funkuhr--[Reference] [Primary] [Primary]
|
--------------------------------
| | |
[Secondary] [Secondary] [Secondary]
Hier ist ein "Adliger" sozusagen der wichtigere, weil er an die Funkuhr angeschlossen ist und eine Sonderrolle bei der Zeitabstimmung spielt: Während die Primary Server ihre eigene Zeit dem Abstimmungsergebnis anpassen, bleibt der Reference Server intern bei seiner Zeit (nach außen gibt er das jeweilige Abstimmungsergebnis weiter, um keine Abweichungen zu provozieren).
Durch diesen einzig "standhaften" tendiert die Netzwerkzeit (das Abstimmungsergebnis) dahin, immer in Richtung auf die Zeit des Reference Servers zu wandern. Dauerhaft wird aber nie eine Übereinstimmung erreicht.
Dieser Nachteil der Ungenauigkeit wird dadurch ausgeglichen, dass erstens die Netzwerklast auf mehrere Server verteilt wird und zweitens ein Ausfall des Reference Servers kein Problem darstellt. Während dieser Zeit stimmen sich einfach die Primary Server untereinander ab und ermitteln so die Netzwerkzeit.
Man sollte etwa zwischen zwei und sieben Primary Server einsetzen.
Standard-Strategie von Netware ist der Single Reference Server (der erste im Netzwerk installierte Server), wobei alle anderen Server Secondary Server werden. Dies funktioniert laut Handbuch bis ca. 30 Server, wenn keine WAN-Verbindung zu überbrücken ist.
Ansonsten sollte man zur Time Provider Group übergehen.
In WANs kann es unter Umständen zu sehr die Netzwerklast erhöhen, wenn man eine Time Provider Group für das gesamte Netzwerk einsetzt. Dann kann es sinnvoll sein, stattdessen dezentral mehrere Funkuhren (jeweils mit einem Server, der das Zeitsignal im Netzwerk bereitstellt) zu installieren. Zwar läßt sich wegen der Genauigkeit der Funkuhren immer die Einheitlichkeit der Zeit garantieren (siehe aber dazu sogleich), eine Ausfallsicherheit ist dann aber nicht gegeben; es bedarf daher eines Mechanismus', um zu klären, welche Uhr (eventuell ein 2. Atomuhrempfänger, z.B. DCF77 und GPS kombiniert) dann jeweils bei Ausfall der Standard-Uhr zu verwenden ist.
Die Funkuhren sind immer an einem Primary oder Single Reference Server angeschlossen. Der Reference Server arbeitet wie bei der "Time Provider Group" unter 4. mit mehreren Primary Servern im LAN zusammen und stellt die Zeit den Secondary Servern im LAN zu Verfügung. Der Single Reference Server bedient entweder einen oder mehrere Secondary Server im LAN oder er ist der einzige Server im LAN.
Weil eine Abstimmung der Zeitsignale zwischen den Funkuhren nicht stattfindet, wird das Netzwerk entlastet.
Ein solches dezentralisiertes System sieht faktisch genauso aus, wie mehrere unabhängige Systeme. Eine Koordination der jeweiligen Systemzeit erfolgt nur über die Ankoppelung an die echte Zeit der Atomuhr. Damit ergeben sich theoretisch Abweichungen beim Einsatz einer Time Provider Group in einem der Subsysteme, die ja nicht die echte Zeit liefert, sondern eine voted time.
Atomuhr
/|\ (per Funk)
/ | \
Funkuhr Funkuhr Funkuhr
| | |
[Reference] [Single Reference] [Single Reference]
| |
(Time -------------
Provider | |
Group) [Secondary] [Secondary]
Variante: Statt der Verwendung von Funkuhren kann man auch auf Atomuhren per Internet zugreifen.
Wie paßt sich nun ein Secondary bzw. Primary Server der voted time an? Es gibt drei Möglichkeiten: Der Server wird gleich auf die richtige Zeit eingestellt. Wenn er vorgeht, wird er so lange angehalten, bis die Zeit wieder übereinstimmt. Oder die Zeit wird verlangsamt bzw. beschleunigt, um die Netzwerkzeit wieder zu erreichen.
Zur Frage der Vor- und Nachteile dieser Strategien hier ein paar Beispiele. Links immer die Zeiten des Secondary, rechts die voted time (diese bleibt hier immer unverändert mit Ausnahme des normalen Zeitflusses).
alt: 12:05 12:00 neu: 12:01 12:01
Folge: vor der Änderung abgeschickte Datenpakete tragen einen neueren Zeitstempel als später abgeschickte Pakete --> Fehler!
Unproblematisch ist diese Methode aber natürlich dann, wenn die Uhr des Servers gegenüber der voted time nachgeht.
(Nur, wenn der Secondary vorgeht.)
alt: 12:05 12:00 neu: 12:05 12:05
Folge: Zwar dreht sich nicht die Reihenfolge der Pakete, aber viele Pakete tragen den identischen Zeitstempel (im Beispiel 12:05 Uhr) --> welches Paket muß nun zuerst verarbeitet werden? Das funktioniert also auch nicht.
alt: 12:00 12:05 neu: 12:06 12:06
Problem gelöst, ohne dabei verschiedene Varianten berücksichtigen zu müssen. Nachteil: Zeitdifferenz wird kurzfristig aufrecht erhalten, wenn der Secondary vorgeht. Praktisch wird daher die Uhr eines Secondary Servers so eingestellt, dass sie eher etwas nachgeht, denn dann läßt sich ja unproblematisch die unter 1. dargestellte Methode verwenden.
Sehr problematisch wäre es, wenn (etwa durch eine fehlerhafte Einstellung der Uhr) der Secondary sehr weit vorgehen würde, etwa um einige Jahre. Dann kann die Konsistenz des Directory-Systems stark gefährdet sein. Diesen Zustand sollte man daher unbedingt vermeiden.
Die Verteilung von Reference, Primary und Secondary hängt immer von der physischen Ausgestaltung des Netzwerks ab.
Am Hub des Netzwerks (z.B. Firmenzentrale) findet sich der Reference Server, außerdem noch einige Primary Server und Secondary Server. In großen Filialen bauen Sie einen oder mehrere Primary Server und ansonsten Secondary Server ein. Kleinste Außenposten (mit z.B. nur einem Server) können Sie auch mit nur einem Secondary ausstatten.
Bedenken Sie dabei: Wenn die Verbindung zur Zentrale abreißt (Bagger zerstört Kabel), muß die Zeitsynchronisierung noch funktionieren. Wenn Secondarys immer erst in der Zentrale nach der Zeit fragen müssen, kann das eine sehr hohe Netzwerklast erzeugen.
Definiert durch RFC 1305
Referenzzeit außerhalb der Computer: Londoner Zeit (UTC) in Sekunden seit dem 1. Januar 1990.
Bei Windows XP können Sie übrigens NTP-Server verwenden, um die Systemuhr zu synchronisieren: Klicken Sie auf die Uhr in der Tasklist und wählen Sie dann die Rubrik "Internetzeit".
Wenn ein falsches Zeitsignal ins Netzwerk eingeschmuggelt wird, kann dies zur Vorbereitung eines Hacks dienen. Gegenmaßnahme: Signierung der Signale. Nachteil: hoher Rechenaufwand.
Unter Netware gibt es ein NLM für die Netware-Zeitsynchronisierung und für NTP: timesync.nlm.
Hier ein Screenshot mit einem Auszug aus einer Log-Datei. Ein Server geht um eine volle Sekunde nach (FH-Saturn1):
Zurück zur Kursseite.