3 Organisation einer dynamischen globalen Namensverwaltung

In Kapitel 2 wurden verschiedene Arten von Namen und Möglichkeiten, diese in lokalen Namensräumen zu repräsentieren und zu verwalten, vorgestellt. Das folgende Kapitel identifiziert zunächst, welche strukturellen Komponenten in globalen Namensverwaltungen existieren, und beschreibt anschließend die funktionalen Komponenten von Namensverwaltern in globalen Namensverwaltungen.

Die Organisation einer globalen Namensverwaltung wird maßgeblich beeinflußt durch

• die strukturellen Komponenten der Namensverwaltung,

• den funktionalen Komponenten der einzelnen Namensverwalter

• der Netzwerktopologie und den Netzwerkeigenschaften.

Die Struktur einer globalen Namensverwaltung ist von der Kommunikationsinfrastruktur des zugrundeliegenden Netzwerks abhängig. Daher diskutiert der letzte Abschnitt des Kapitels verschiedene Aspekte der Verteilung und Kooperation von Namensverwaltern im Netzwerk und präsentiert eine Methode zur selbständigen Konfigurierung von Namensverwaltern.

3.1 Strukturelle Komponenten globaler Namensverwaltungen

Den strukturellen Komponenten einer Namensverwaltung liegen verschiedene Modelle der verteilten Verarbeitung von Aufträgen zugrunde. Diese verschiedenen Modelle und ihre Eignung für eine dynamische globale Namensverwaltung sind Gegenstand der weiteren Betrachtungen in diesem Abschnitt.

3.1.1 Globale Namensverwaltung im Client-Server-Modell

Ein verbreitetes Paradigma zur verteilten Verarbeitung repräsentiert das sog. Client-Server-Modell. Zahlreiche Namensverwaltungen wurden nach diesem Modell entworfen (z.B. DNS, [Mockapetris, 84a] und X.500, [CCITT, 89]). Die Namensverwaltung besteht dann einerseits aus Klienten, die die Dienste der Namensverwaltung in Anspruch nehmen, und andererseits aus Namensverwaltern, die Namenseinträge ausschließlich verwalten (vgl. Abbildung 3.1).

Im Client-Server-System greifen Anwendungen in Klienten über eine Anwendungsschnittstelle (Naming API) auf die Dienste der Namensverwaltung zu. Diese Schnittstelle zur Namensverwaltung wird der Anwendung von einem Naming Agenten auf dem Klienten-Rechner offeriert. Der Naming Agent muß auf jedem Knoten verfügbar sein, der die Dienste der Namensverwaltung in Anspruch nehmen will. Der Naming Agent übernimmt in der Regel selbst keine Verwaltungsfunktionen. Er repräsentiert lediglich einen Vermittler zwischen dem Namensverwalter und der Anwendung. Entsprechend gibt der Naming Agent Anfragen über das Netzwerk an Namensverwalter weiter und liefert Anfrageergebisse an die Anwendung zurück. Der Naming Agent realisiert somit das Protokoll zur Kommunikation mit dem Namensverwalter (Agenten-Protokoll), so daß eine Applikation, die die Dienste der Namensverwaltung in Anspruch nimmt, von den Kommunikationsaufgaben entbunden wird. Die Klienten richten ihre Anfragen direkt an den lokalen Naming Agenten, so daß die verteile Struktur der Namensverwaltung transparent bleibt. Lediglich die Agenten besitzen Kenntnisse über den Namensraum und die existierenden Namensverwalter.

Abbildung 3.1: Das Client-Server-Modell in der Namensverwaltung

Naming Agenten in Klientenrechnern können entweder mehrere Anwendungen gleichzeitig bedienen, oder sie stehen jeweils nur einer Anwendung zur Verfügung. Während gemeinsam genutzte Agenten meist als Teil des Betriebssystems realisiert sind und über Systemaufrufe angesprochen werden, wird ein einfacher Agent i.d.R. in Form von Bibliotheksroutinen zur Anwendung hinzugebunden.

Abbildung 3.2: Strukturelle Komponenten einer Namensverwaltung nach dem Client-Server-Prinzip

Ein Namensverwalter (Name Server) ist eine Instanz der Namensverwaltung, die für die Erfassung, Verwaltung, Speicherung und Weitergabe von Namen zuständig ist. Namensverwalter können in verteilten Systemen als zentraler dedizierter Namensverwalter (z.B. in CSNET), als mehrere dedizierte Namensverwalter (z.B. in Grapevine), oder zusammen mit anderen Diensten (z.B. in Cronus oder im V-system) in Knoten vorhanden sein. Namensverwalter verwalten detaillierte Kenntnisse über den Namensraum und über weitere existierende Namensverwalter. Die für die Verwaltung des Namensraums notwendige Kommunikation zwischen den Namensverwaltern wird durch sog. Namensverwalter-Protokolle realisiert. Klienten der Namensverwaltung treten über Naming Agents mit Namensverwaltern in Kontakt. Hierbei wird in der Regel die Ortstransparenz für den Klienten gewahrt, so daß die Applikation keine Kenntnisse darüber besitzt, welcher Namensverwalter bestimmte Namenseinträge administriert (vgl. Abbildung 3.2). Werden Namenseinträge über mehrere Namensverwalter verteilt verwaltet, so sorgen die Namensverwalter untereinander für die transparente Auflösung einer Klientenanfrage.

Zur Kommunikation zwischen Namensverwaltern wurde beispielsweise in X.500 [CCITT/ISO, 88] ein sogenanntes Directory System Protocol (DSP) definiert. Die Kommunikation einer Anwendung mit der Namensverwaltung erfolgt über das sogenannte Directory Access Protocol (DAP). In der Terminologie des X.500-Standards werden Namensverwalter als Directory System Agents (DSAs) und Klienten als Directory User Agents (DUAs) bezeichnet.

Das Namensverwalter-Protokoll umfaßt Funktionen zur Auflösung und in verschiedenen Systemen auch zur Registrierung von Namen. Um die Ausfallsicherheit von Namensverwaltungen zu steigern und durch Kommunikation entstehende Verzögerungen zu reduzieren, können die Namenseinträge auf mehreren Namensverwaltern repliziert sein. In diesem Fall muß das Namensverwalter-Protokoll Funktionen zum Abgleich replizierter Einträge umfassen. Derjenige Namensverwalter, der den für ein Objekt maßgeblichen Namenseintrag enthält, d.h. bei dem der Eintrag ursprünglich registriert wurde, wird als primärer Namensverwalter oder auch Naming Authority bezeichnet.

Die Vor- und Nachteile des Client-Server-Modells für die Realisierung einer dynamischen globalen Namensverwaltung lassen sich wie folgt zusammenfassen:

+ Das Client-Server-Modell sorgt für eine klare Aufteilung der Zuständigkeiten innerhalb der Namensverwaltung.

+ Ein Client-Server-Modell für die globale Namensverwaltung ist besonders dann geeignet, wenn sich Agenten in Namensverwaltungen auf wenige Operationen beschränken. Das Agenten-Protokoll besitzt dann im Vergleich zum Namensverwalter-Protokoll eine reduzierte Funktionalität, wodurch der Umfang der Agenten-Software für den Zugang zur Namensverwaltung und der Agenten-Schnittstelle reduziert wird.

- Die Unterscheidung in Agenten- und Namensverwalter-Protokolle beschränkt in vielen Fällen die administrativen Möglichkeiten des Klienten. Insbesondere wird die Registrierung neuer Einträge durch das Agenten-Protokoll häufig nicht unterstützt. Unterschiedliche Agenten- und Namensverwalter-Schnittstellen erhöhen nicht zuletzt auch die Komplexität des Gesamtsystems.

- Das Client-Server-Modell eignet sich lediglich für gleichmäßig verteilte Namenseinträge. Aus Gründen der Sicherheit und Aktualität ist es jedoch wünschenswert, bestimmte Namenseinträge lokal im Klienten zu verwalten und nicht global zu verteilen. Somit treten unterschiedliche Verteilungsgrade im System auf, wobei lokale Einträge in Klienten und globale Einträge durch Namensverwalter verwaltet werden. Das Client-Server-Modell ist daher mit der angestrebten Integration lokaler und globaler Namensverwaltungen nicht vereinbar.

Um die aufgezeigten Nachteile eines Client-Server-Modells zu vermeiden, wird in der dynamischen globalen Namensverwaltung auch in Klienten die volle Funktionalität eines Namensverwalters bereitgestellt, wie dies im folgenden vorgeschlagen wird.

3.1.2 Architekturmodell der dynamischen globalen Namensverwaltung

Ziel der dynamischen globalen Namensverwaltung ist es, u.a. lokale und globale Namensräume zu integrieren. Dabei stößt das Client-Server-Modell schnell an seine Grenzen, da zur Realisierung eines einheitlichen Namensraums auch Klienten die volle Funktionalität eines Namensverwalters bieten müssen.

Im Architekturmodell für die dynamische globale Namensverwaltung ist in jedem Knoten ein funktional gleicher Namensverwalter vorgesehen, der Namenseinträge mit lokaler oder auch globaler Signifikanz verwaltet (vgl. Abbildung 3.3). Der in dieser Arbeit verfolgte Ansatz kennt keine Unterscheidung in Server und Klienten, es wird lediglich in Anlehnung an den Gültigkeitsbereich der verwalteten Namenseinträge eine Unterscheidung zwischen lokalen und globalen Namensverwaltern getroffen. Durch die fehlende Unterscheidung zwischen Klienten und Server wird eine Integration der lokalen und globalen Namensverwaltung und die Realisierung eines einheitlichen Namensraums für lokale und globale Objekte möglich.

Lokale Namensverwalter in der dynamischen globalen Namensverwaltung besitzen die volle Funktionalität globaler Namensverwalter, verwalten jedoch lediglich lokale Namen und weisen Registrierungsaufträge für globale Namen zurück. Da keine globalen Namen auf lokalen Namensverwaltern registriert werden, ist es nicht notwendig, diese permanent verfügbar zu halten oder zu replizieren. Wenn lokale Namenseinträge nicht verfügbar sind, dann sind auch die zugehörigen Objekte selbst nicht verfügbar.

Globale Namensverwalter administrieren sowohl lokale als auch globale Namen, d.h. sie nehmen Registrierungsaufträge für globale Namenseinträge entgegen. Als Konsequenz ist eine ständige Verfügbarkeit dieser Namensverwalter zu gewährleisten. Insbesondere sind aus Gründen der Ausfallsicherheit die globalen Einträge globaler Namensverwalter zu replizieren. Global verfügbare Namen sind außer in globalen Namensverwaltern auch beim (globalen oder lokalen) Namensverwalter desjenigen Knotens registriert, der das zugehörige Objekt verwaltet.

Namensverwalter unterscheiden sich ferner durch den Grad ihrer Verfügbarkeit. Sind sie ständig verfügbar, so werden sie als permanente Namensverwalter bezeichnet und können zur Verwaltung globaler Namenseinträge genutzt werden. Namensverwalter, deren permanente Verfügbarkeit nicht garantiert werden kann, werden als temporäre Namensverwalter bezeichnet. Sie können lediglich lokale Namenseinträge verwalten. Die Verwaltung globaler Namenseinträge ist wegen der temporären Verfügbarkeit nicht vorgesehen.

Abbildung 3.3: Architekturmodell der dynamischen globalen Namensverwaltung

Ein Namensverwalter, der eine Aktion initiiert, wird aktiver Namensverwalter genannt, ein Namensverwalter, an den eine Anfrage gerichtet ist, heißt passiver Namensverwalter. Jeder Knoten kann für einen bestimmten Teilbereich eines Namensraums zuständig sein. Namenseinträge werden vom Namensverwalter immer zunächst lokal erzeugt, registriert und aufgelöst. Die Protokolle zwischen lokalen und globalen Namensverwaltern sind identisch (vgl. Abbildung 3.3).

Als primärer Namensverwalter eines Namens wird derjenige Namensverwalter bezeichnet, in dem der Name durch die Anwendung registriert wurde, so daß er den primären Namenseintrag mit der Bindung an den Objekt-Bezeichner enthält. Dabei ist der primäre Namensverwalter häufig mit dem Verwalter des gebundenen Objekts identisch.

Der administrative Namensverwalter eines Namenseintrags ist derjenige Namensverwalter, der den globalen Namenseintrag für einen Namen verwaltet. Dieser administrative Namenseintrag enthält eine Referenz (Navigationsinformation) auf den Namensverwalter des primären Namenseintrags. Unter Umständen können der primäre und der administrative Namensverwalter identisch sein.

Nachdem der vorangegangene Abschnitt die strukturellen Komponenten der dynamischen globalen Namensverwaltung identifiziert hat, beschreibt der folgende Abschnitt die möglichen Wechselwirkungen der Namensverwaltung mit anderen Komponenten des Betriebssystems.[AL1]

3.1.3 Wechselwirkungen mit anderen Betriebssystemkomponenten

Namensverwaltungen wurden in Betriebssystemen in der Vergangenheit vielfach in andere Betriebssystemkomponenten integriert. Namensräume wurden für spezielle Zwecke, wie Verzeichnisse für Dateisysteme, konzipiert. In modernen verteilten Betriebssystemen ist die Namensverwaltung i.d.R. als separater Dienst realisiert. Hierfür sprechen insbesondere folgende Gründe:

Modularisierung: Moderne Betriebssystemkonzepte streben einen modularen Systemaufbau an. Die Funktionalität des Gesamtsystems ergibt sich dabei aus der Kooperation unabhängiger Module, die über einen minimalen Kern kommunizieren. Speicher-, Objekt- und Geräteverwaltung, Authentisierung, Scheduler, Netzwerkdienste und nicht zuletzt die Namensverwaltung sind als eigenständige Dienste etabliert.

Unifizierung: Namen treten in verteilten Betriebssystemen dienstübergreifend auf. Das gleiche Namensschema findet für unterschiedliche Dienste Verwendung. So wird z.B. über Dateinamen in NFS [SUN, 89] transparent auf Dateien zugegriffen, unabhängig davon, ob es sich um lokale oder entfernte Dateien handelt. Weitere Beispiele hierfür sind Devices oder Named Pipes.

Integration: Im Laufe der Zeit können unterschiedliche Namensräume zusammenwachsen oder sich auftrennen. Die Änderung an einer Stelle ist dann einfacher. Allerdings können nicht nur doppelte Namen vorkommen, sondern auch unterschiedliche Namenskonventionen gelten.

Existiert die Namensverwaltung im Betriebssystem als eigenständiger Dienst, so sind beim Zugriff eines Anwenderprozesses über Namen auf entfernte Objekte mehrere Dienste beteiligt (vgl. Abbildung 3.4). Der Anwenderprozeß wendet sich mit dem Namen eines Objekts an den Objektverwalter. Dieser kontaktiert die Namensverwaltung, um den mit dem Namen assoziierten Objekt-Bezeichner zu bestimmen. In Besitz der Identifikation wendet sich der Objektverwalter an das Netzwerk. Dieses ermittelt aus der Identifikation die Netzwerkadresse des objekt-verwaltenden Knotens und überträgt den Aufruf an den Objektverwalter der Gegenseite. Unter Zuhilfenahme des Authentisierungsdienstes prüft der Objektverwalter die Zugriffsberechtigung und führt den Aufruf letztendlich aus.

Abbildung 3.4: Wechselwirkungen der Betriebssystemkomponenten beim Zugriff über Namen

Wie Abbildung 3.4 verdeutlicht, ist der Zugriff auf Objekte stets mit einer Autorisierung verbunden. Jedoch nicht nur der Objektzugriff, sondern auch der Zugriff auf Namenseinträge selbst muß autorisiert erfolgen, um unberechtigte Manipulationen von Namenseinträgen und das unerwünschte Sammeln sensibler Informationen zu unterbinden. Zusammen mit den Namen sind von der Namensverwaltung somit Zugangsinformationen bereitzustellen. Diese werden dem Authentisierungsdienst für die Beschränkung des Zugriffs auf Namenseinträge zur Verfügung gestellt. Globale Namensverwaltungen interagieren somit direkt mit dem Authentisierungsdienst des Betriebssystems. Interaktionen mit weiteren Betriebssystemdiensten sind als sekundär zu betrachten und betreffen die Funktionalität und Struktur der Namensverwaltung selbst nicht.

Die Transparenz der Namensauflösung muß für die Anwendung jedoch nicht notwendigerweise gegeben sein. Die Namensverwaltung wird beim Objektzugriff mittels Namen entweder, wie in Abbildung 3.4 dargestellt, indirekt durch die objekt-verwaltenden Instanzen involviert, oder die Anwendung ruft die Namensverwaltung direkt, um den Objekt-Bezeichner zu einem gegebenen Namen zu ermitteln (vgl. Abbildung 3.5). In Besitz der Objekt-Identifikation wendet sich die Anwendung anschließend an den Objektverwalter, um Zugang zum Objekt zu erhalten.

Abbildung 3.5: Direkte und indirekte Interaktion der Applikation mit der Namensverwaltung[AL2]

Aus der Etablierung der Namensverwaltung als eigenständiger Dienst in modularen Betriebssystemen erwachsen auch Anforderungen an die übrigen Dienste. Die Namensverwaltung erbringt nicht alle zur Verwaltung von Namenseinträgen notwendigen Funktionen selbst. Sie greift ihrerseits insbesondere auf die Dienste der Objektverwaltung, des Netzwerks und der Autorisierung zurück.

Wie der vorangegangene Abschnitt gezeigt hat, motivieren moderne Betriebssystemkonzepte autonome Namensverwaltungen. Diese benennen alle für den Anwender relevanten Objekte und stellen die für den Zugriff erforderlichen Informationen bereit.

Erst die Loslösung vom Client-Server-Modell für globale Namensverwaltungen ermöglicht die Integration lokaler und globaler Namensverwaltungen und die Realisierung eines einheitlichen, dynamisch administrierten globalen Namensraums. Die Modularisierung verteilter Betriebssysteme und die Forderung nach Universalität etablierten globale Namensverwaltungen als eigenständigen Dienst.

3.2 Funktionales Modell eines globalen Namensverwalters

Für Systeme, in denen die Namensverwaltung konsequent genutzt wird, ist die Implementierung effizienter Namensverwalter mit extrem hoher Verfügbarkeit unerläßlich. Namensverwalter sind dann elementarer Bestandteil eines Betriebssystems und auf einem dementsprechend niedrigen Niveau der Betriebssystemhierarchie angesiedelt. Implementierungen sind dabei im Kern von Betriebssystemen [Cheriton, 88] ebenso anzutreffen wie in der Kernschale [Schröder, 88]. Die Verwaltung des Namensraums erfolgt ausschließlich hauptspeicherbasiert mit effizienten Zugriffsmechanismen, z.B. Hash-Tabellen [Morris, 68] oder B-Bäumen [Bayer, 77], und klientenseitigen Namen-Caches, um den Kommunikationsaufwand niedrig zu halten.

3.2.1 Das Modell eines Namensverwalters nach Terry

Ein häufig gebrauchtes Referenzmodell für Namensverwalter wurde von Terry [Terry, 85] vorgestellt. Terry identifiziert in seiner Arbeit folgende funktionalen Komponenten, die ein Namensverwalter aufweisen sollte:

· Operationen des Namensdienstes

· Auflösung strukturierter Namen (Namensauflösung)

· Verwaltung replizierter Daten (Replikationsverwaltung)

· Speicherung von Namensinformationen in einer Datenbank (Datenbank)

· Kommunikationsmodul (Kommunikation)

Das zugehörige funktionale Modell gliedert sich in Schichten, wie in Abbildung 3.6 gezeigt wird. Die Komponenten der oberen Schichten nehmen dabei zur Erfüllung ihrer Aufgaben die Dienste der darunterliegenden Schichten in Anspruch.

Abbildung 3.6: Funktionales Modell eines Namensverwalters nach Terry

In Terry’s Modell eines Namensverwalters dienen die Namensoperationen der obersten Schicht des Namensverwalters ausschließlich dazu, Administrationsaufgaben zu verrichten. Klienten hingegen greifen nicht über diese Administrationsschnittstelle, sondern ausschließlich über Kommunikationskanäle auf Namensverwalter zu.

Zur Steigerung der Effizienz der Namensauflösung wurde der Namensverwalter mit einer Replikationsverwaltung für Namenseinträge versehen. Die Konsistenzerhaltung der replizierten Namenseinträge wird durch Read-any/Write-all-Verfahren oder durch gewichtete Votierungsverfahren [Gifford, 79] gewährleistet. Ohne sich auf eine Methode der Replikationsverwaltung festzulegen, schlägt Terry in seinem Modell [Terry, 85] vor, in Namensverwaltern ein Modul zu Verwaltung replizierter Einträge vorzusehen, das nahezu dieselbe Schnittstelle wie die lokale Namensdatenbank besitzt. Lediglich ein zusätzlicher Parameter spezifiziert den Speicherort eines Eintrags. Um die Replikate zu verwalten, stützt sich das Modul auf die Funktionen der lokalen Datenbank und der Kommunikationsebene.

Globale Namensverwaltungen erbringen ihren Dienst durch die Kooperation verteilter Namensverwalter. Dazu benötigen diese Zugang zu den Kommunikationsdiensten des Betriebssystems. Die Kommunikation zwischen Namensverwaltern kann sowohl verbindungsorientiert als auch verbindungslos erfolgen. Verschiedene Kommunikationsmedien offerieren lediglich einen verbindungsorientierten Dienst. Meist ist der Aufbau gesicherter Verbindungen jedoch nicht erforderlich, da die Menge der übertragenen Daten gering ist und ein Nachrichtenverlust durch die Namensverwaltung selbst erkannt und behoben werden kann. Verbindungslose Protokolle eignen sich besonders dann, wenn zustandslose Namensverwalter gefordert sind.

Vielfach ist die Übertragung der Ausführung von einem Namensverwalter auf einen anderen erforderlich. Die Bereitstellung von Remote Procedure Call-Diensten (RPC) durch die Netzwerkschicht ist zwar hilfreich, jedoch nicht notwendigerweise Voraussetzung. Der begrenzte Umfang an netzwerkübergreifenden Funktionen und die limitierte Parametermenge erlauben durchaus eine nachrichtenbasierte Behandlung von Anfragen durch die Namensverwaltung.

Die in Namensverwaltern administrierten Namenseinträge, die sog. Namensbasis, werden in einer Datenbank abgelegt. Im allgemeinen sind Namensdatenbanken von kleiner und mittlerer Größe. Kleinere Datenbanken mit Namenseinträgen werden, vorausgesetzt sie sind einfach in ihrer Struktur, als simple Textdateien realisiert. Sind die Datenbanken umfangreicher, werden sie durch eigene Schemata realisiert, die eine eigens entworfene Datenrepräsentation auf Dateien und spezielle Operationen für den Zugriff und die Modifikation der Datensätze beinhalten.

Eine einfache und effiziente Technik, um derartige Namensdatenbanken zu implementieren, wird in [Birrel, 87] beschrieben. Hierbei wird die Existenz eines sehr großen virtuellen und ausreichend großen physikalischen Speichers vorausgesetzt. Die Datenbank wird als streng typisierte Datenstruktur im virtuellen Speicher realisiert, wobei Änderungen anhand eines Änderungsprotokolls inkrementell auf das physikalische Medium übertragen werden. Gelegentlich werden Aufsetzpunkte (Checkpoints) der gesamten Datenbank angelegt, so daß bei Ausfällen beim letzten Checkpoint aufgesetzt und der aktuelle Zustand durch Nachvollziehen des Änderungsprotokolls wiederhergestellt werden kann.

Bestandteil vieler verteilter Betriebssysteme ist eine Objektverwaltung. Bietet diese die notwendige Funktionalität, so kann sie von der Namensverwaltung zur Speicherung von Namenseinträgen genutzt werden. Die einzige bekannte Namensverwaltung, die ein allgemeines Datenbank Management System verwendet, um Namenseinträge zu speichern, ist der COSINE Name Server [Barker, 91]. Die Gründe, die gegen einen Einsatz von allgemeinen Datenbanksystemen zur Speicherung von Namenseinträgen sprechen, sind zahlreich, in erster Linie sind hier jedoch die geringe Geschwindigkeit und die Komplexität der Datenbankabfragesprachen anzuführen.

Trotz der hohen Funktionalität fehlen Terry’s Modell eines Namensverwalters Instanzen, die das Netz von Namensverwaltern konfigurieren und globale Namenseinträge auf die jeweils zuständigen Namensverwalter verteilen. Gerade diesen Aufgaben ist beim Entwurf globaler Namensverwaltungen jedoch besondere Aufmerksamkeit zu schenken.

3.2.2 Namensverwaltermodell der dynamischen globalen Namensverwaltung

Der vorliegende Entwurf der dynamischen globalen Namensverwaltung sieht vor, den Namensverwalter in der Kernschale eines Betriebssystems (Midware) zu realisieren. Die Gründe hierfür liegen in dem Bestreben, modulare Systeme basierend auf Micro-Kernel zu forcieren und außerhalb des minimalen Kerns dynamische Bindeoperationen für Objekte anzuwenden. An der Kernschnittstelle treten lediglich Objekt-Bezeichner, jedoch keine Namen auf. Durch eine minimale Schnittstelle zum Kern bleibt die Portierbarkeit des Systems auf diverse Hardwareplattformen und die Substitutionsoption für die Namensverwaltung erhalten.

Das funktionale Modell der dynamischen globalen Namensverwaltung offeriert verschiedene Schnittstellen. Über die Anwendungsschnittstelle greifen Anwendungen und weitere Systemkomponenten ortstransparent auf die Funktionen der Namensverwaltung zu. Zur Ausführung der Verwaltungsoperationen auf dem verteilten Namensraum nimmt die Namensverwaltung ihrerseits über die Kernschnittstelle die Kommunikations- und Objektverwaltungsfunktionen des Kerns in Anspruch (vgl. Abbildung 3.7).

Abbildung 3.7: Funktionales Modell eines Namensverwalters der dynamischen globalen Namensverwaltung

Das funktionale Modell der dynamischen globalen Namensverwaltung läßt sich grob unterteilen in global und lokal wirksame Namensoperationen. Die Zugriffstransparenz der dynamischen globalen Namensverwaltung an der Anwendungsschnittstelle wird vom Modul zur Behandlung attributierter und synonymer Namen (vgl. Abbildung 3.7) realisiert.

3.2.2.1 Schnittstellen der dynamischen globalen Namensverwaltung

Die dynamische globale Namensverwaltung besitzt Schnittstellen zur Anwendung und zum Betriebssystem. Die Interaktionen mit der Anwendung erfolgen über die Anwendungsschnittstelle. Über die entsprechenden Kernschnittstellen interagiert die Namensverwaltung mit den Kommunikationsprotokollen und der Objektverwaltung des Betriebssystems.

Über die Anwendungsschnittstelle der dynamischen globalen Namensverwaltung stehen dem Anwender die Namensoperationen zur Verfügung. Diese bieten dem Anwender weitgehende Ortstransparenz, die Namensverwaltung kann jedoch vom Anwender mit Angaben über den Gültigkeitsbereich der Namen versorgt werden. Die Funktionen an der Anwendungsschnittstelle umfassen Aufrufe zur Registrierung, Auflösung und zum Löschen von implizit und explizit im Namensraum repräsentierten Namen und Attributen. Zudem werden Funktionen für die Verwaltung von Synonymen und das Modifizieren von Namenseinträgen bereitgestellt. Die Aufrufe der Anwendungsschnittstelle werden synchron abgearbeitet, so daß die Anwendung so lange blockiert, bis die Anfrage beantwortet oder ein Zeitlimit überschritten wurde. Eine asynchrone Auflösung von Namen hat keine Vorteile, da die Ausführung i.d.R. nicht fortfahren kann, bevor der Name aufgelöst ist.

Die Namensverwalter der dynamischen globalen Namensverwaltung kommunizieren untereinander über die Kommunikationsschnittstelle des Betriebssystemkerns. Die notwendige Funktionalität diese Schittstelle beschränkt sich auf das gesicherte Versenden und Empfangen von Nachrichten über das zugrundeliegende Netzwerk. Nachrichten der Namensverwaltung müssen vom Netzwerk anhand der übergebenen, routingfähigen Netzwerkadresse (z.B. IP-Adresse) selbständig zum jeweiligen Namensverwalter geleitet werden. Steht an der Kommunikationsschnittstelle eine Broadcast-Option zur Verfügung, so kann diese genutzt werden, um die Ausfallsicherheit der Namensverwaltung zu erhöhen. Die Kommunikationsstrategien der dynamischen globalen Namensverwaltung bestehen jedoch nicht auf der Mehrpunkt-Fähigkeit des zugrundeliegenden Kommunikationsmediums. Besonders in globalen Netzwerken sind in der Regel lediglich Punkt-zu-Punkt-Verbindungen verfügbar. Da die Kommunikation zwischen globalen Namensverwaltern gerichtet verläuft, verursacht das Fehlen der Rundspruchfähigkeit in globalen Netzwerken keine Probleme.

Namensverwalter der dynamischen globalen Namensverwaltung speichern lokale Namenseinträge mithilfe der in vielen modernen Betriebssystemen vorhandenen Objektverwaltung. Der Zugriff auf lokale Namenseinträge erfolgt von der Namensverwaltung aus über die Objektverwalterschnittstelle. Diese sollte Grundoperationen zum Hinzufügen, Suchen, Auflisten und Löschen von Objekten anbieten. Um die Unabhängigkeit der Namensverwaltung vom Objektverwalter zu wahren, sollte dieser in der Lage sein, beliebige Objekte zu verwalten. Eine wichtige Forderung an den Objektverwalter ist weiterhin, daß die auf Namenseinträgen ausgeführten Operationen atomar verlaufen und Namensdaten persistent gespeichert werden. Auf Funktionen zur Freigabe von Namenseinträgen kann bei Vorhandensein einer Garbage Collection im System verzichtet werden. Komplexere Suchfunktionen auf der Namensbasis werden von den untersten Modulen der Namensverwaltung bereitgestellt.

3.2.2.2 Komponenten der dynamischen globalen Namensverwaltung

Die Funktionen der dynamischen globalen Namensverwaltung lassen sich grob in primitive und zusammengesetzte Operationen untergliedern. Die primitiven Funktionen verwalten nur einfache Namen in der lokalen Namensbasis. Zusammengesetzte Funktionen, d.h. Verwaltungsfunktionen, die sich ihrerseits aus primitiven Funktionen zusammensetzen, verwalten hierarchische, attributierte und globale Namen sowie Synonyme. Eine alternative Kategorisierung der Namensfunktionen ist die Einteilung in ortstransparente und ortsabhängige Funktionen.

Die Interpretation attributierter und synonymer Namen findet im obersten Modul des Namensverwalters statt und ist inhärent mit einer Überprüfung der Namenssyntax verbunden. Die Funktionen dieses Moduls sind ortstransparent, d.h. sie besitzen keine Kenntnis des Speicherortes der mit einem gegebenen Namen verbundenen Namenseinträge. Attributierte und synonyme Namen erfahren in diesem Modul eine Zerlegung in orthogonale, hierarchische Namensbestandteile. Während explizite Attribute im graphförmigen Namensraum repräsentiert werden, sind implizite Attribute in den Namenseinträgen an den Blättern des hierarchischen Namensraums abgelegt.

Die globale Namensauflösung und -registrierung verwaltet Namenseinträge über Knotengrenzen hinweg und bietet den darüberliegenden Modulen Ortstransparenz. Alle verteilungsabhängigen Funktionen zur Auflösung und Registrierung globaler Namen sind in diesem separaten Modul zusammengefaßt. Dieses Modul basiert auf den Funktionen des Moduls Hierarchische Namen und den kommunikationsbezogenen Modulen, wie der Replikationsverwaltung und der Konfigurationsverwaltung.

Bevor die globale Namensauflösung angestoßen wird, prüft dieses Modul unter Miteinbeziehung des Moduls Hierarchische Namen, ob lokale oder vorgehaltene Entsprechungen für gesuchte Namen vorhanden sind. Erst wenn dies nicht der Fall ist, wird eine knotenübergreifende Auflösung angestoßen. Partielle Ergebnisse von Anfragen werden der Replikationsverwaltung zugeführt und von dieser mit Hilfe des Moduls Hierarchische Namen verwaltet. Die Konfigurationsverwaltung bestimmt den zu konsultierenden globalen Namensverwalter und übernimmt das Konfigurieren kooperierender Namensverwalter.

Völlig lokal und verteilungsunabhängig findet die Interpretation eines hierarchischen Namens im Modul Hierarchische Namen statt. Neben lokalen hierarchischen Namen verwaltet dieses Modul auch Replikationen und Originale entfernter Namenseinträge und stellt diese der Replikationsverwaltung zur Verfügung. In der Verwaltung entfernter, lokaler, vorgehaltener und replizierter hierarchischer Namen bestehen innerhalb dieses Moduls keinerlei Unterschiede. Hierarchische Namen werden in eine Folge primitiver Namen zerlegt, die im Modul Primitive Namen behandelt werden. Auch die Funktionen zur Verwaltung primitiver Namen sind völlig lokal und besitzen keine Kenntnis über die Verteilung von Einträgen.

Namensverwalter der dynamischen globalen Namensverwaltung enthalten eine Konfigurationsverwaltung für den Aufbau und die Verwaltung des globalen Verwalternetzes.

3.3 Topologie und Organisation des Verwalternetzes

Die Ausdehnung der Namensverwaltung auf globale Netzwerke erfordert die Kooperation von Namensverwaltern. Dazu werden sie in globalen Namensverwaltungen zu einem Verwalternetz verbunden. Dieses legt fest, wie die Namensverwalter miteinander in Verbindung stehen.

In heute verbreiteten globalen Namensverwaltungen wie DNS [Mockapetris, 87a] und X.500 [CCITT, 89] wird das Verwalternetz manuell konfiguriert. Bevor in Abschnitt 3.4 die selbständige Konfigurierung des Verwalternetzes in der dynamischen globalen Namensverwaltung beschrieben wird, zeigt der folgende Abschnitt Möglichkeiten zur Kopplung und Organisation von Namensverwaltern unter Berücksichtigung der Eigenschaften und Topologie des zugrundeliegenden Netzwerks auf.

3.3.1 Netzwerktopologie und Kopplungsgrad der Namensverwalter

Die mit den Eigenschaften eines Netzwerks verbundene Qualität des Kommunikationsdienstes hat wesentlichen Einfluß auf die Struktur einer globalen Namensverwaltung. So trägt die Verfügbarkeit von Mehrpunktverbindungen (Multicast und Broadcast) im lokalen Netzwerkbereich wesentlich zur Steigerung der Effizienz und Ausfallsicherheit von Namensverwaltungen bei [Cheriton, 89]. Globale Netze offerieren diese Eigenschaften i.a. nicht, so daß globalen Namensverwaltungen lediglich Punkt-zu-Punkt-Verbindungen zur Verfügung stehen. Dieser Umstand wirkt sich erheblich auf die Mechanismen globaler Namensverwaltungen aus. Die wesentlichen Einflußfaktoren für die Struktur eines Verwalternetzes sind:

Netzwerkeigenschaft	Einfluß auf das Verwalternetz
Die Durchsatzleistung der Netzwerkverbindungen und der Grad der Kopplung von Namensverwaltern	Je enger Namensverwalter gekoppelt sind und je höher die Durchsatzleistung zwischen Namensverwaltern ist, desto enger können Namensverwalter im Verwalternetz kooperieren. Speichergekoppelte Namensverwalter können eine gemeinsame Namensbasis verwalten.
Die mittlere Verzögerung der Netzwerkverbindungen	Je geringer die Verzögerung der Kommunikation zwischen Namensverwaltern ist, desto enger kooperieren diese im Verwalternetz. Zwischen Namensverwaltern mit großer Verzögerung empfiehlt sich das Vorhalten von Namen.
Die Distanz der Namensverwalter	Die Distanz der Namensverwalter gemessen in der Anzahl der zu überwindenden Netzwerkübergänge zwischen den Namensverwaltern entscheidet über die Beziehungen der Namensverwalter zueinander und ihre Position im Verwalternetz.
Die Verfügbarkeit und Ausfallsicherheit der Netzwerkverbindungen	Kommunizieren Namensverwalter über temporär verfügbare Netzwerkverbindungen, so empfiehlt sich die gegenseitige Replikation von Namensverwaltern im Verwalternetz.
Die Semantik der Kommunikation	Je nachdem, ob Punkt-zu-Punkt-, Multicast- oder Broadcast-Verbindungen für die Kommunikation zwischen Namensverwaltern zur Verfügung stehen, können diese unterschiedlich zueinander in Beziehung gesetzt werden.
Die Topologie des Netzwerks	Die Topologie des Netzwerks entscheidet über die Struktur des Verwalternetzes und die gegenseitigen Beziehungen der Namensverwalter.

Tabelle 3.1: Netzwerkeigenschaften und ihr Einfluß auf das Verwalternetz

Die in dieser Arbeit vorgestellte dynamische globale Namensverwaltung ist weitgehend unabhängig von der zugrundeliegenden Netzwerktopologie. Sowohl Punkt-zu-Punkt- als auch Mehrpunktverbindungen und die Möglichkeit zur Speicherkopplung werden vom Namensdienst effektiv unterstützt. Dazu werden Namensverwalter zu Bereichen zusammengefaßt, in welchen Mehrpunktverbindungen und gemeinsame Speicherbereiche genutzt werden. Zwischen diesen Bereichen erfolgt die Kommunikation über Punkt-zu-Punkt-Verbindungen.

3.3.1.1 Enge Kopplung durch gemeinsamen verteilten Speicher

Eine sehr enge Kopplung von Namensverwaltern wird durch die Verwendung eines gemeinsamen verteilten Speichers (Distributed Shared Memory, DSM) zur Ablage der Namensbasis erreicht [Lupper, 94]. Eine Namensverwaltung im DSM-System benötigt keine explizite Kommunikation, um eine verteilte Namensbasis zu realisieren. Das in [Traub, 96] vorgestellte DSM-Modell gliedert sich in drei Abstraktionsebenen mit unterschiedlichen Sichten des Systems:

Namenseinträge werden auf der Objektebene ortstransparent als DSM-Objekte abgelegt. Objekte dieser Ebene werden auf zusammenhängende Speicherblöcke des virtuellen verteilten Speichers projiziert. Der ein Objekt repräsentierende Speicherbereich dieser Ebene ist durch eine logische Adresse, die innerhalb einer Gruppe von Knoten eindeutig ist, und durch die Größe des Speicherblocks bestimmt. Speicherbereiche dieser Ebene werden transparent auf den physikalischen Speicher eines oder mehrerer Knoten abgebildet, d.h. ein Objekt ist physikalisch u.U. auf mehreren Knoten existent (vgl. Abbildung 3.8). Große Objekte können sich dabei auch über den physikalischen Speicher mehrerer Knoten erstrecken. Objekte können somit auf Knoten partitioniert und auch repliziert sein. Die Zuordnung von Speicher zu Objekt und den schematischen Aufbau der Schichten des DSM-Systems zeigt Abbildung 3.8:

Abbildung 3.8: Die Ebenen des DSM-Modells

Abbildung 3.8 läßt zudem erkennen, daß zwischen den einzelnen Schichten und ihren Abstraktionsebenen jeweils Abbildungen notwendig sind, um den physikalischen Speicherort eines Objekts zu ermitteln. Die physikalische Repräsentation eines Objekts ermittelt das Memory Management. Wie obige Abbildung ebenso verdeutlicht, können Objekte im physikalischen Speicher auf Knoten repliziert (A, A’) und über Knoten verteilt (B, B*) gespeichert sein, so daß die Abbildung zwischen logischen und physikalischen Adressen nicht notwendigerweise eindeutig ist.

Der gemeinsame verteilte Speicher kann im lokalen Bereich genutzt werden, um Namenseinträge [Lupper, 94] transparent verteilt zu verwalten. Zwischen den Namensverwaltern ist dann für die Verwaltung einer verteilten Namensbasis keine explizite Kommunikation notwendig. Alle Namenseinträge werden wie lokale behandelt, da alle Namensverwalter auf eine gemeinsame Namensbasis im verteilten Speicher zugreifen.

3.3.1.2 Broadcast- und Mehrpunktverbindungen

Ein hoher Kopplungsgrad der Namensverwalter ist ebenfalls gegeben, wenn der zugrundeliegende Kommunikationsdienst innerhalb eines Netzwerkbereichs Mehrpunkteigenschaften besitzt. Multicast-Nachrichten sind gleichermaßen für die Verteilung und das Auffinden von Informationen nützlich, haben allerdings den Nachteil, daß sie effizient nur in lokalen Netzwerken eingesetzt werden können, da sie eine starke Belastung aller angesprochenen Knoten und eine hohe Netzlast verursachen (Broadcast-Stürme).

Aus diesem Grund unterstützt das im Internet aktuell verwendete Internet Protokoll IPv4 nur Unicast. Zwar ist in den benutzten Netzwerken, zum Beispiel in Ethernet, meist Multicast möglich, aber die IP-Router unterstützen Multicast nicht. Insbesondere die Router müßten aber Pakete replizieren, um auf mehrere Subnetze verteilte Mitglieder der Multicast-Gruppe zu erreichen. Zu diesem Zweck wurde IP-Multicast und das Multicast Backbone Netzwerk (MBONE) [Deering, 89] entwickelt. Für IP-Multicast wird ein spezieller Bereich von IP-Nummern, die Class-D Adressen, als Multicast-Adressen benutzt. Class-D Adressen haben die Form En.nn.nn.nn (hex 224.0.0.0 bis hex 239.255.255.255). In einem lokalen Netzwerk gibt es Maschinen, die Multicast-Unterstützung haben, und solche, in deren IP-Implementierung kein Multicast-Empfang vorgesehen ist.

Abbildung 3.9: Broadcast-Bereiche und deren Verbindungen

Die Multicast -Fähigkeit eines Netzwerkbereichs kann verwendet werden, um neue Einträge gleichzeitig an mehrere Namensverwalter zu propagieren und dort vollständig zu replizieren, so daß jeder Namensverwalter dieselbe Namensbasis besitzt. Diese Vorgehensweise empfiehlt sich dann, wenn Namen sehr viel häufiger aufgelöst als geändert werden. Andernfalls ist es effektiver, wenn jeder Namensverwalter nur die Namen seiner lokalen Objekte verwaltet und bei der Namensauflösung alle Namensverwalter durch Broadcast-Nachrichten kontaktiert^[1]. Hierdurch ist stets die Aktualität der Einträge gewährleistet und es kann garantiert werden, daß, sofern das zugehörige Objekt verfügbar ist, auch der Name aufgelöst werden kann. Bei Ausfall übergeordneter Namensverwalter oder bei Netzwerkpartitionierung ist durch die Broadcast-Eigenschaft gewährleistet, daß zumindest Namen von Objekten im Broadcast-Bereich aufgelöst werden können. Somit erhöht die Mehrpunktfähigkeit eines Teilnetzes die Ausfallsicherheit und Autonomie der lokalen Installationen (vgl. Kapitel 5).

Die Auflösung und Registrierung von Namen wird nur über den lokalen oder den Broadcast-Bereich hinaus ausgedehnt, wenn dies notwendig ist^[2]. Konnte ein Name im Broadcast-Bereich nicht aufgelöst werden, so besitzt ein Namensverwalter im Broadcast-Bereich einen Verweis auf einen übergeordneten Namensverwalter, der die Auflösung des Namens auf den globalen Bereich ausdehnen kann. Es genügt, wenn ein Namensverwalter im Broadcast-Bereich die Adresse eines übergeordneten Namensverwalters besitzt.

3.3.1.3 Lose Kopplung durch permanente, langsame WAN-Verbindungen

Mit der Ausdehnung von Netzwerken wird die Möglichkeit, Mehrpunktverbindungen für die Kommunikation zwischen Namensverwaltern einzusetzen, zunehmend eingeschränkt. Im WAN-Bereich sind Broadcast-Verfahren für die Verteilung und Lokalisierung von Namenseinträgen nicht einsetzbar, da dies eine hohe Belastung des Netzwerks durch Broadcast-Nachrichten bedeuten würde und außerdem jeder Namensverwalter, der eine derartige Broadcast- Nachrichten erhält, die Anfrage bearbeiten muß, unabhängig davon, ob er zur Auflösung eines Namens beitragen kann oder nicht.

Existieren im WAN-Bereich permanente physikalische Verbindungen, die eine lose Kopplung zwischen einzelnen global verteilten Netzwerkknoten herstellen^[3], dann muß sich der Netzwerkverkehr auf logische Punkt-zu-Punkt-Verbindungen beschränken. Für die Kommunikation der Namensverwalter untereinander bedeutet dieser Umstand, daß nur gezielte Interaktionen zwischen den Namensverwaltern stattfinden. Eine Konsequenz der eingeschränkten Kommunikationsfähigkeit globaler Netzwerke ist die Konzentration der Namensinformationen auf wenige bekannte Namensverwalter. Eine weit gestreute Verteilung der Informationen durch einzelne Punkt-zu-Punkt-Verbindungen wäre sehr zeitaufwendig.

Werden für die Kommunikation zwischen Namensverwaltern keine logischen Verbindungen, sondern Datagramme eingesetzt, so entfällt die Zeit für den Verbindungsaufbau. Die Sicherung des Kanals vor Nachrichtenverlusten ist in diesem Fall durch die Protokolle der globalen Namensverwaltung zu realisieren. WAN-Verbindungen besitzen eine im Vergleich zu LANs niedrige Datenrate, eine hohe Fehlerrate und eine geringe Ausfallsicherheit. Zur Beschleunigung der Zugriffs und zur Erhöhung der Verfügbarkeit ist es daher angebracht, Namenseinträge zwischen Netzwerkbereichen zu replizieren (vgl. Kapitel 5).

3.3.1.4 Temporäre Verfügbarkeit physikalischer Netzwerkverbindungen

Eine flächendeckende Vernetzung wird mittelfristig nur mit drahtgebundenen oder drahtlosen Wählverbindungen realisierbar sein. Diese besitzen gegenüber permanenten physikalischen Netzwerkverbindungen folgende Nachteile:

• Ein expliziter Aufbau der physikalischen Netzwerkverbindung ist notwendig^[4], der im Vergleich zum Aufbau logischer Netzwerkverbindungen verhältnismäßig viel Zeit in Anspruch nimmt und Verbindungskosten verursacht.

• Die Kommunikation verläuft gerichtet, d.h. es stehen stets nur Punkt-zu-Punkt-Verbindungen zwischen Namensverwaltern zur Verfügung. Ein Namensverwalter kann gleichzeitig immer nur eine begrenzte Anzahl von Wählverbindung unterhalten.

• Wählverbindungen bestehen nur temporär. Besteht eine Verbindung, so wird der Anschluß eines Namensverwalters monopolisiert. Die Gefahr der Monopolisierung erzwingt daher kurze Verbindungszeiten, die sich wiederum nachteilig auf die Effizienz auswirken.

• Die besondere Kostenstruktur von Wählverbindungen erzwingt kurze Verbindungszeiten und eine Reduzierung der notwendigen Wählverbindungen.

Eine globale Namensverwaltung muß auch dann ihre Arbeit verrichten, wenn keine Mehrpunktfähigkeit gegeben ist, sondern nur temporäre physikalische Punkt-zu-Punkt-Verbindungen zur Verfügung stehen. Obige Nachteile von Punkt-zu-Punkt-Verbindungen sind daher bei der Konfigurierung einer dynamischen globalen Namensverwaltung zu berücksichtigen, um eine effiziente Verwaltung von Namen über Wählverbindungen zu realisieren [Lupper, 90].

Gegenwärtig ist über Wählverbindungen bereits eine flächendeckende Anbindung an globale Netzwerke realisiert^[5]. In naher Zukunft ist dabei mit einer zunehmenden Anzahl mobiler, drahtlos angebundener Netzwerkknoten zu rechnen (vgl. Abbildung 3.10). Damit besteht keine feste Netzwerkstruktur mehr, woran sich die Struktur von Namensräumen orientieren könnte. Namen sollten daher nach logischen Gesichtspunkten vergeben werden und sich nicht an physikalischen Gegebenheiten orientieren.

In zellulären Funknetzen wäre denkbar, Broadcast-Bereiche einzurichten und nur die Kommunikation zwischen den Zellen über Punkt-zu-Punkt-Verbindungen^[6] abzuwickeln (wie z.B. in WaveLAN von AT&T). Für die Übermittlung von Nachrichten der Namensverwaltung könnte ein separater Signalisierungskanal (analog dem D-Kanal in ISDN) verwendet werden, der in der Lage ist, ohne expliziten Aufbau einer Verbindung Nachrichten zu überstellen. Die Wahrscheinlichkeit jedoch, daß zwei mobile Teilnehmer, die miteinander kommunizieren, sich in derselben Zelle befinden, ist relativ gering. Zwar wird sich die Anzahl der mobilen Netzwerkteilnehmer weiter erhöhen, gleichzeitig wird sich jedoch die Zellgröße mobiler Netze verringern, um mehr Teilnehmer bedienen zu können. Da die Anzahl der Mobilstationen in einer Zelle konstant bleibt, ist keine bessere Effektivität einer Broadcast-Option zu erwarten.

Abbildung 3.10: Drahtgebundene und drahtlose Wählverbindungen

Die Präsenz von Wählverbindungen in einer ansonsten statischen Konfiguration (z.B. Mobilstationen und Basisstationen) hat eine Änderung der Semantik der Kommunikation zwischen den Namensverwaltern zu Folge. Während Namensverwalter in lokalen Netzwerken die Broadcast-Option nutzen konnten, um Anfragen direkt an den zuständigen Namensverwalter und gleichzeitig an einen übergeordneten Namensverwalter zu übermitteln, kann im Falle von Wählverbindungen die Anfrage nur gezielt an den übergeordneten Namensverwalter gerichtet werden. Weitere lokale Namensverwalter können nicht erreicht werden.

Physikalische Wählverbindungen bleiben während einer Anfrage nicht bestehen, da andernfalls Ergebnisse einer Anfrage vom zuständigen Namensverwalter nur über dieselbe Verbindung vom übergeordneten Namensverwalter zum lokalen Namensverwalter zurückgegeben werden könnten. Eine direkte Rückantwort vom zuständigen Namensverwalter, wie sie insbesondere wünschenswert ist, wenn auch übergeordnete Namensverwalter über Wählverbindungen kommunizieren, wäre damit ausgeschlossen. Namensverwalter müssen daher berücksichtigen, daß Verbindungen temporär nicht verfügbar sein können.

Eine eingehende Betrachtung verschiedener Aspekte der Namensverwaltung in Präsenz von Wählverbindungen findet der interessierte Leser in [Lupper, 90].

3.3.2 Organisationsstrukturen von Verwalternetzen

Prinzipiell existieren verschiedene Möglichkeiten, Namensverwalter in einem Verwalternetz zu organisieren und Namenseinträge über Namensverwalter zu verteilen. Die Struktur des Verwalternetzes und die Verteilung der Namenseinträge auf Namensverwalter sind dabei eng miteinander verbunden. Hierbei sind verschiedene Grade von Replikation und Verteilung von Namenseinträgen denkbar (vgl. Abbildung 3.11).

Abbildung 3.11: Grad der Verteilung und der Replikation

Legt man als Kriterium zur Beurteilung des Grades der Verteilung den Aufwand zugrunde, der zu betreiben ist, um eine bestimmte Information zu erhalten, so ist der Fall, in dem jeder Knoten nur Namenseinträge für lokale Objekte verwaltet, als der höchste Grad der Verteilung zu betrachten. Konträr zu diesem Kriterium kann zur Beurteilung der Verteilung auch der Grad der Verbreitung von Information herangezogen werden. Werden Namenseinträge in allen Knoten repliziert, so sind sie jederzeit und überall verfügbar, jedoch ist ihre Verteilung entsprechend aufwendig.

Folgende Organisationsschemata für die Namensverwaltung in verteilten Systemen und die Verteilung von Namenseinträgen wurden von Terry [Terry, 84] und Goscinski [Goscinski, 89] identifiziert:

· zentrale Namensverwaltung

· vollständig replizierte Namensverwaltung

· dezentrale Namensverwaltung

· verteilte Namensverwaltung

· hierarchische Namensverwaltung

Welches Organisationsschema für die globale Namensverwaltung geeignet ist, hängt u.a. von folgenden Faktoren ab:

· der Leistungsfähigkeit (Speicher, Rechenleistung) und Verfügbarkeit der Namensverwalter.

· der Semantik der verwendeten Kommunikationsprotokolle und der Topologie des zugrundeliegenden Netzwerks.

· der Struktur des verwalteten Namensraums.

Im folgenden wird unter Berücksichtigung obiger Faktoren die Verwendbarkeit der einzelnen Organisationsschemata für die dynamische globale Namensverwaltung untersucht.

3.3.2.1 Zentrale Namensverwaltung

Die konzeptionell einfachste Organisationsform ist zweifelsohne die zentralisierte Namensverwaltung. Sie ist gekennzeichnet durch einen einzigen Namensverwalter, der eine zentrale Tabelle oder Datenbank mit allen verfügbaren Namenseinträgen in der verteilten Umgebung unterhält. Ein Beispiel für einen zentralen Namensverwalter ist der NIC Name Server [Pickens, 79]. Zentralisierte Namensverwaltungen verwalten häufig flache oder attributierte Namensräume, seltener werden sie auch für hierarchische Namensräume verwendet .

Abbildung 3.12: Modell einer zentralisierten Namensverwaltung

Unter netzwerktopologischen Aspekten ist die zentrale Namensverwaltung besonders dann geeignet, wenn dem System ein sternförmiges Netzwerk zugrunde liegt. Insbesondere für Wählverbindungen ohne Broadcast-Option kann in räumlich begrenzten Systemen die zentrale Namensverwaltung durchaus eine effektive Alternative zur verteilten Namensverwaltung darstellen. Die Kosten einer Namensauflösung entsprechen den Kosten, den zentralen Namensverwalter vom entferntesten Knoten im System aus zu kontaktieren.

Eine Organisation mit nur einem zentralen Namensverwalter ist relativ unkompliziert. In kleinen verteilten Umgebungen ist ein zentraler Namensverwalter, der alle Namen eines Namensraums enthält, gewöhnlich in der Lage, Anfragen ohne große Leistungseinbußen und Speicheranforderungen zu erfüllen. Das Erzeugen eindeutiger Namen läßt sich in einem kleinen System mit geringem Aufwand realisieren. Ein weiterer Vorteil ist die Vermeidung jeglicher Konsistenzprobleme, wie sie in Systemen mit mehr als einem Namensverwalter auftreten können.

Nicht zu vernachlässigen sind jedoch die Nachteile eines zentralen Namensverwalters. Insbesondere durch die inhärente Abhängigkeit des Systems von der Zuverlässigkeit und Verfügbarkeit des zentralen Namensverwalters und die starke Belastung dieser Instanz kommt ein Ausfall faktisch einem Ausfall des Gesamtsystems gleich.

Als weiterer Nachteil kommt hinzu, daß in der Regel der gewünschte Dienst nicht vom selben Rechner wie der Namensdienst erbracht wird. Durch die Indirektion beim Zugriff auf Dienste können sich lange Verzögerungen zwischen dem Zugriff auf den Namensverwalter und dem Beginn der dienstorientierten Übertragung ergeben. Insbesondere bei Wählverbindungen wird hierdurch ein zeitraubender und kostenintensiver Verbindungswechsel notwendig. Im Zusammenhang mit zentralen Namensverwaltern und Wählverbindungen besteht auch die Gefahr der Monopolisierung [Lupper, 90]. Die Reduzierung der Verbindungszeiten kann die Monopolisierungsgefahr lediglich minimieren, jedoch nicht gänzlich ausschließen.

3.3.2.2 Replizierte Namensverwaltung

Zur Steigerung der Verfügbarkeit einer Namensverwaltung kann die Verwaltung des Namensraums ganz oder teilweise mehreren Namensverwaltern k₁…k_n übertragen werden. Dabei wird jedoch nicht die Funktionalität eines Namensverwalters verteilt, sondern jeder Verwalter arbeitet autonom. Als Beispiel für ein derartiges System sei hier der Pub Name Service[AL3] erwähnt.

Im Extremfall kann der gesamte Namensraum auf allen Namensverwaltern vollständig repliziert sein. Diese Replikationsform wird häufig bei flachen Namensräumen verwendet, um die Ausfallsicherheit der Namensverwaltung zu erhöhen und die Zugriffszeit zu reduzieren. Da jeder Klient den für ihn nächstgelegenen Namensverwalter kontaktieren kann, reduzieren sich die Kommunikationskosten gegenüber einem zentralen System. Ist der lokale Namensverwalter an der replizierten Namensverwaltung beteiligt, so können Namen lokal aufgelöst werden, ohne andere Namensverwalter kontaktieren zu müssen.

Solange die Anzahl globaler Namen nicht überhandnimmt, ist die vollständige Replikation der Namenseinträge auf allen Namensverwaltern vorteilhaft. Die Namensverwalter tauschen jeweils wechselseitig mit den ihnen bekannten Instanzen Namensinformationen aus und erhalten so eine einheitliche Sicht aller globalen Namen im Netz. Im DEC Global Name Service [Lampson, 86] sind replizierte Namensverwalter ringförmig verkettet.

Abbildung 3.13: Propagieren von Namen bei vollständiger Replikation der Namensverwalter

Durch die vollständige Replikation von Namenverwaltern entstehen bei großer Anzahl von Namen in allen beteiligten Namensverwaltern hohe Speicheranforderungen zur Verwaltung der redundant gespeicherten Namenseinträge. Um den Speicheraufwand zu reduzieren, können Namenseinträge zunächst verteilt und anschließend wieder entfernt werden, sofern sie lokal nicht benutzt werden.

Die vollständige Replikation von Namensverwaltern verschärft zudem das Konsistenzproblem und erhöht den Aufwand für das Propagieren von Änderungen. Aufgrund des bidirektionalen Informationsflußes müssen alle Namensverwalter jede Veränderung im gesamten Bereich propagieren. In der Regel werden bei vollständiger Replikation Änderungen über teure Broadcast-Mechanismen propagiert. Das bietet sich insbesondere dann an, wenn Änderungen im Namensraum im Vergleich zu Anfragen sehr selten sind.

Bei organisatorisch oder physikalisch partitionierten Namensräumen bieten sich Replikationsformen an, die Partitionen des Namensraums über mehrere Namensverwalter verteilen und replizieren. Auch hier besteht das Konsistenzproblem bei multiple copy updates, jedoch nicht in dem Maße, wie bei vollständig replizierten Namensbasen, da nicht alle Namensverwalter von Änderungen betroffen sind.

3.3.2.3 Dezentrale Namensverwaltung

Der hohe Speicherplatzbedarf vollständig replizierter und die Belastung zentraler Namensverwalter kann reduziert werden, indem der Namensraum partitioniert und auf mehrere Namensverwalter verteilt wird. Eine derartig dezentralisierte Namensverwaltung besteht aus Namensverwaltern, die jeweils genau festgelegte Partitionen des Namensraums verwalten.

Um einen Namensraum zu partitionieren und auf Namenverwalter zu verteilen, existieren verschiedene Ansätze:

a) Physikalische (geographische) Partitionierung: In jedem Netzwerkbereich wird ein Namensverwalter unterhalten, der für die Verwaltung der Namen dieses Bereich zuständig ist. Der Name des zuständigen Namensverwalters ist Teil des globalen Namensraums.

b) Organisatorische (funktionale) Partitionierung: Die einzelnen Namensverwalter sind Organisationen zugeordnet. Die Partitionierung des Namensraums und die Verteilung der Namen auf Namensverwalter erfolgt aufgrund der Zugehörigkeit der benannten Objekte zu Organisationen.

c) Typ-orientierte Partitionierung: Namenseinträge werden anhand des Typs der benannten Objekte auf Namensverwalter verteilt. Jeder Namensverwalter ist für einen bestimmten Typ von Objekten zuständig.

d) Logische Partitionierung: Namen werden anhand der Semantik der Namensteile auf Namensverwalter verteilt ohne direkten Bezug zu einer physikalischen Lokation oder organisatorischen Einheit.

e) Willkürliche Partitionierung: Die Verteilung der Namenseinträge auf die einzelnen Namensverwalter geschieht zufällig und ist nicht deterministisch.

Um den für eine Partition zuständigen Namensverwalter zu bezeichnen, kann für physikalisch partitionierte Namensräume beispielsweise folgende Namenskonvention verwendet werden:

Name@Namensverwalter

Dabei bezeichnet der rechte Teilname „Namensverwalter“ den zuständigen Namensverwalter und der linke Teilname „Name“ identifiziert eindeutig das Objekt im Kontext des Namensverwalters. Der Name „Name.Namensverwalter“ ist global eindeutig, vorausgesetzt die Namensverwalter sind eindeutig benannt.

In physikalisch partitionierten Namensräumen besteht eine Eins-zu-eins-Beziehung zwischen den Partitionen des Namensraums und den Namensverwaltern. Eine derartige Partitionierung verlangt zwei Schritte, um auf ein benanntes Objekt zuzugreifen, einen Schritt, um den zuständigen Namensverwalter zu ermitteln, und einen, um die Informationen von diesem zu erhalten. Handelt es sich bei dem zuerst kontaktierten Namensverwalter bereits um den zuständigen Namensverwalter, so ist nur ein Schritt erforderlich (vgl. Abbildung 3.16). Um eine effektive Verwaltung eines physikalisch partitionierten Namensraums zu ermöglichen, sollte jeder Klient den für eine bestimmte Partition des Namensraums zuständigen Namensverwalter kennen.

Abbildung 3.14: Modell einer dezentralisierten Namensverwaltung

In organisatorisch partitionierten Namensverwaltungen korrespondieren die Partitionen des Namensraums mit Organisationen und nicht mit einzelnen Namensverwaltern. Ein Namensverwalter kann für eine oder mehrere Organisationen aber auch für Teile einer Organisation zuständig sein. In diesem Falle kann die Namensverwaltung einfach restrukturiert werden, da die Namen nicht direkt abhängig von der Zuordnung des zuständigen Namensverwalters sind. Bei organisatorischer Partitionierung geht die Zuständigkeit eines Namensverwalters für Namen nur indirekt aus dem Namen hervor:

Name.Organisation

Zur Ermittlung der Zugriffskosten sei zunächst angenommen, daß jeder Namensverwalter die Namen genau einer Organisation verwaltet, wie es der physikalischen Partitionierung entspricht. Um einen effizienten Zugriff auf Namensinformationen zu gewährleisten, sollte jeder Namensverwalter Kenntnis davon besitzen, welche Instanzen für eine Organisation zuständig sind. Unter diesen Voraussetzungen können Namensanfragen wie in physikalisch partitionierten Namensräumen in zwei Schritten aufgelöst werden.

Einer der Hauptvorteile der organisatorischen Partitionierung ist, daß auf einfache Weise replizierte Namensinformationen in die Namensauflösung miteinbezogen werden können. Die Unterstützung von Replikationen in organisatorisch partitionierten Namensräumen bedeutet, daß anstatt eines einzigen Namensverwalters mehrere Namensverwalter für eine Organisation zuständig sind. Zur Namensauflösung sollte daher jeder Namensverwalter alle zuständigen Namensverwalter für jede Organisation kennen. Als Beispiel für eine Namensverwaltung, die auf diesem Ansatz beruht, kann Grapevine [Birell, 82] angeführt werden.[V4]

Weiter besteht die Möglichkeit, einen Namensraum anhand des Typs des benannten Objekts zu partitionieren und auf Namensverwalter zu verteilen. Bei der Namensauflösung muß dann jeder Namensverwalter wissen, wo die Namen eines bestimmten Objekttyps verwaltet werden. Hierfür gelten ähnliche Überlegungen wie bei der organisatorischen Partitionierung.

Im Rahmen der Partitionierung von Namensräumen ist auch eine willkürliche Verteilung von Namenseinträgen auf Namensverwalter denkbar. In diesem Fall ist die Auflösung von Namen sehr aufwendig, da im Durchschnitt die Hälfte aller Namensverwalter kontaktiert werden muß, um einen Namen aufzulösen. Der Einsatz von Broadcast- oder Hash-Verfahren zur Lokalisierung von Namenseinträgen in Namensverwaltern kann die Zugriffszeit unter Umständen reduzieren. Broadcast-Methoden sind jedoch in globalen Netzwerken i.d.R. nicht einsetzbar und Hashing bereitet Probleme beim Löschen von Namenseinträgen [Morris, 68].

3.3.2.4 Vollständig verteilte Namensverwaltung

Bei der vollständig verteilten Namenverwaltung werden Namen nur in den Knoten verwaltet, in denen die zugehörigen Objekte abgelegt sind. Objektverwalter und Namensverwalter befinden sich somit auf demselben Rechner. Ein Vorteil dieser Vorgehensweise ist, daß bei Ausfall eines Namensverwalters über Namen nur lokale Objekte nicht verfügbar sind. Durch die Verwaltung der Namen im selben Knoten wie die gebundenen Objekte ist ferner gewährleistet, daß stets auf die aktuellen Namensinformationen zugegriffen wird.

Die vollständige Verteilung von Namenseinträgen erhöht den Aufwand für die Registrierung und Auflösung globaler Namen. Da a priori nicht bekannt ist, welcher Namensverwalter einen Namenseintrag verwaltet, muß bei Namensanfragen und beim Prüfen der Eindeutigkeit neuer Namen bei allen Namensverwaltern nachgefragt werden, ob der gesuchte Namen bereits vorhanden ist. Dies kann geschehen, indem jeder bekannte Namensverwalter nacheinander iterativ, rekursiv oder transitiv^[7] kontaktiert wird (vgl. Kapitel 4), bis der gesuchte Name ermittelt ist. Diese Vorgehensweise ist allerdings äußerst zeitaufwendig. Zeitlich unkritischer ist die Prüfung der Eindeutigkeit und die Lokalisierung vollständig verteilter Namenseinträgen durch Broadcast-Nachrichten (vgl. Abbildung 3.15), wobei oben genannte Gründe den Einsatz in globalen Netzwerken verbieten.

Abbildung 3.15: Vollständig verteilte Verwaltung von Namen

Ein Problem der vollständigen Verteilung von Namen sind konkurrierende Registrierungen desselben Namens. Dazu wird der neue Namen immer zuerst lokal registriert und anschließend propagiert. Wird innerhalb einer bestimmten Zeit nach der Registrierung eines Namens ein Konflikt mit einer konkurrierenden Registrierung erkannt, so wird diese zurückgenommen. Eine weitere Methode zur Auflösung von Konflikten bei der Registrierung von Namen bieten abstimmungsgesteuerte Verfahren (sog. verteilte Algorithmen), die bei Vorliegen gleichberechtigter Kopien die Sequentialisierung von Anfragen übernehmen.

Änderungen von vollständig replizierten Namenseinträgen werfen zusätzliche Probleme auf, wenn sie für denselben Namenseintrag an verschiedene Namensverwalter gerichtet werden. Eine Möglichkeit diese Konflikte aufzulösen besteht in der Einführung eines primären Eintrags (Masterkopie), den stets derjenige Namensverwalter hält, bei dem der Eintrag zuerst registriert wurde. Alle Änderungswünsche werden dabei zunächst an den Eigentümer des primären Eintrags gerichtet, der konkurrierende Änderungen sequentialisiert und propagiert.

3.3.2.5 Hierarchische Namensverwaltung

Keine der bisher in diesem Abschnitt diskutierten Organisationsformen für Namensverwalter ist adäquat für globale Systeme. Die Situation kann jedoch entscheidend verbessert werden, wenn die Namenverwalter hierarchisch organisiert werden und zusätzlich der verwaltete Namensraum eine hierarchische Struktur besitzt. Der Namensraum kann dann hierarchisch partitioniert werden und die Partitionen können nach dem „divide and conquer“-Prinzip auf die hierarchisch organisierten Namensverwalter verteilt werden. Jeder Namensverwalter zeichnet für die Verwaltung einer Teilhierarchie des Namensraums verantwortlich. Die hieraus resultierende, hierarchisch organisierte Namensverwaltung ist eine Erweiterung der dezentralisierten Namensverwaltung. Sie ist besonders effektiv, falls die Verwalterhierarchie an den Namensraum angepaßt ist.

Abbildung 3.16: Konfigurations- und Navigationsinformation hierarchisch organisierter Namensverwalter

Durch die hierarchische Organisation der Namensverwaltung genügt es, wenn jeder Namensverwalter die Lokation des ihm in der Hierarchie direkt übergeordneten Namensverwalters und der direkt nachfolgenden Namensverwalter kennt (vgl. Abbildung 3.16). Damit Aufträge nicht nur vom Namensverwalter an der Wurzel der Verwalterhierarchie entgegengenommen werden können, ist es notwendig, jeden Namensverwalter mit Konfigurationsinformation zu versehen, die den Weg zum Namensverwalter an der Wurzel der Verwalterhierarchie beschreibt. Die Lokation der Wurzel der Verwalterhierarchie kann aus dieser Information gewonnen werden. Diese Konfigurationsinformation bildet das Verwalternetz und wird nur geändert, wenn ein Namensverwalter zum Verwalternetz hinzukommt oder entfernt wird.

Für die verteilte Auflösung von Namen muß in den Namensverwaltern zusätzlich Information vorhanden sein, welcher Namensverwalter welchen Teil des Namensraums verwaltet. Da die verteilte Auflösung von Namen als Navigation im Verwalternetz betrachtet werden kann, wird diese Information als Navigationsinformation bezeichnet. Ein Namensverwalter in der Hierarchie des Verwalternetzes muß lediglich Navigationsinformation für die Teilbäume des Namensraums besitzen, die sich in von ihm verwalteten Kontexten befinden (vgl. hierzu Kapitel 4). Die Navigationsinformation in Namensverwaltern kann sich durch die Registrierung und das Löschen von Namenseinträgen ändern.

3.3.3 Die Verwalterstruktur der dynamischen globalen Namensverwaltung

Unter den in Abschnitt 3.3.2 vorgestellten Organisationsformen für Namensverwalter gilt es nun die für die dynamische Verwaltung globaler Namensräume geeignete zu bestimmen. Für ein hierarchisches Verwalternetz zur globalen Namensverwaltung sprechen folgende Gründe:

· Eine hierarchische Verwalterstruktur kann der physikalischen oder organisatorischen Partitionierung des Namensraums angepaßt werden.

· Durch die hierarchische Verteilung der Zuständigkeiten haben lokale Änderungen im Namensraum keine globalen Auswirkungen auf Namensverwalter.

· Für die Verwaltung eines Namensraums durch hierarchisch organisierte Namensverwalter ist lediglich eine geringe Anzahl von Verbindungen und Nachrichten erforderlich.

· Die Kommunikation zwischen hierarchisch organisierten Namensverwaltern verläuft gerichtet und kann über Punkt-zu-Punkt-Verbindungen erfolgen.

Die dynamische globale Namensverwaltung verwaltet einen hierarchischen Namensraum, der nicht nach physikalischen oder organisatorischen, sondern nach logischen Gesichtspunkten partitioniert wird. Außerdem sollte die Struktur der dynamischen globalen Namensverwaltung verschiedene Netzwerktopologien berücksichtigen.

Als Verwalterstruktur der dynamischen globalen Namensverwaltung wurde daher ein hierarchisches Verwalternetz gewählt, das zusätzlich replizierte, vollständig verteilte und zentrale Namensverwalter enthält. Welche Art der Namensverwaltung in Teilen des Verwalternetzes der dynamischen globalen Namensverwaltung konkret verwendet wird, ist abhängig von der Netzwerktopologie und der Semantik der Netzwerkkommunikation:

Hierarchische Namensverwaltung:

· Die Namensverwalter der dynamischen globalen Namensverwaltung bilden eine hierarchische Verwalterstruktur, um globale Namen zu verwalten.

Verteilte Namensverwaltung:

· Lokale Namen besitzen nur lokale Signifikanz und werden daher nur in den objekt-verwaltenden Netzwerkknoten gehalten.

· Verbundweite Namen werden ebenso in den objekt-verwaltenden Netzwerkknoten gehalten. Zusätzlich müssen sie jedoch im Verbund eindeutig sein.

Replizierte Namensverwaltung:

· Zur Steigerung der Effizienz und der Ausfallsicherheit werden globale Namenseinträge auf Namensverwalter innerhalb desselben Netzwerkbereichs repliziert (aktive Replikation).

· Namensverwalter halten häufig verwendete globale Namen in ihrer lokalen Namensbasis (vgl. Kapitel 5) vor (passive Replikation).

Zentrale Namensverwaltung:

· Stehen der Namensverwaltung zur Kommunikation lediglich Punkt-zu-Punkt-Verbindungen zur Verfügung, so werden alle nicht-lokalen Namen in für den Netzwerkbereich zuständigen zentralen Namensverwaltern gehalten. Diese können wiederum Teil hierarchischer Verwalternetze sein.

Diese hybride Verwalterstruktur bietet in eine bessere Verteilung der Zuständigkeiten. Die effiziente Auflösung globaler Namen wird durch das hierarchische Verwalternetz ermöglicht. Besonders wichtig bei der dynamischen Namensverwaltung ist, daß lokale Änderungen keine globalen Auswirkungen haben und die Aktualität der Namenseinträge gegeben ist. Durch die verteilte Namensverwaltung im lokalen Netzwerkbereich wird erreicht, daß die Registrierung und Auflösung lokaler oder verbundweiter Namen keinen globalen Netzwerkverkehr verursacht. Ferner werden, wo immer möglich, zentrale Instanzen, deren Ausfall die Funktion der gesamten Namensverwaltung beeinträchtigt, vermieden. Jeder permanent verfügbare Namensverwalter kann in die globale Namensverwaltung miteinbezogen werden, wodurch eine höhere Ausfallsicherheit durch strukturelle Redundanz erreicht wird.

Wie ein geeignetes Verwalternetz für die dynamische globale Namensverwaltung automatisch konfiguriert und verwaltet wird, beschreibt der nächste Abschnitt. Der Problematik der adäquaten Partitionierung von Namensräumen und der Verteilung von Namens- und Navigationsinformationen im Verwalternetz, um eine effiziente und sichere Auflösung zu gewährleisten, widmet sich Kapitel 4.

Das Verwalternetz der dynamischen globalen Namensverwaltung ist hierarchisch organisiert, enthält jedoch zusätzlich replizierte, vollständig verteilte und zentrale Namensverwalter.

3.4 Konfigurierung hierarchischer Verwalternetze

Für den Aufbau globaler Verwalternetze muß in Namensverwaltern Information über benachbarte Namensverwalter vorhanden sein. Der folgende Abschnitt beschreibt zunächst diese Verwalterinformation und nimmt eine Differenzierung vor. Anschließend werden verschiedene Formen der manuellen Konfigurierung eines hierarchischen Verwalternetzes diskutiert und ein neuartiges Verfahren vorgestellt, um hierarchische Verwalternetze selbständig und dynamisch zu konfigurieren.

3.4.1 Verwalterinformationen in hierarchischen Verwalternetzen

Namensverwalter in hierarchischen Verwalternetzen verwalten neben Namenseinträgen auch Informationen über in der Hierarchie benachbarte Namensverwalter. Diese Verwalterinformationen können wie folgt kategorisiert werden:

· Konfigurationsinformationen bilden das hierarchische Verwalternetz und verweisen auf

· in der Hierarchie direkt übergeordneten Namensverwalter, um die globale Auflösung von Namen in der Verwalterhierarchie nach oben zur Wurzel zu leiten (vgl. Kapitel 4).

· in der Hierarchie direkt untergeordneten Namensverwalter, um das Einfügen und Entfernen von Namensverwaltern im Verwalternetz zu ermöglichen (vgl. Abschnitt 3.4.3.3).

· den Namensverwalter an der Wurzel der Verwalterhierarchie, auch wenn dies nur aus Effizienzgründen und nicht aus operationellen Gründen notwendig ist.

· Replikationsinformationen geben an, welche weiteren Namensverwalter die Namensbasis eines bestimmten Namensverwalters replizieren.

· Navigationsinformationen geben an, welcher Namensverwalter eine Partition des globalen hierarchischen Namensraums verwaltet, und leiten die Auflösung und Registrierung globaler Namen an die für einen Namen zuständigen (untergeordneten) Namensverwalter.

Abbildung 3.17 zeigt die unterschiedlichen Beziehungen eines Namensverwalters im hierarchischen Verwalternetz zu benachbarten Namensverwaltern, die durch die Verwalterinformationen definiert werden.

Abbildung 3.17: Verwalterinformationen in hierarchisch organisierten Namensverwaltern

Konfigurationsinformationen, die auf übergeordnete und untergeordnete Namensverwalter verweisen, aber auch Navigations- und Replikationsinformationen haben bestimmte Konsistenzbedingungen zu erfüllen. Die Konfigurationsinformation in den Namensverwaltern eines hierarchischen Verwalternetzes muß folgende Konsistenzbedingungen erfüllen:

· Existenz eines obersten Verwalters: In der Verwalterhierarchie existiert mindestens ein Namensverwalter k₀, der keinen übergeordneten Namensverwalter besitzt.

· Existenz eines übergeordneten Verwalters: Jeder Namensverwalter k_i mit i¹0 muß (mindestens) einen ihm übergeordneten Namensverwalter k_i-1 besitzen.

· Kenntnis eines obersten Verwalters: Jeder Namensverwalter k_i muß den/die obersten Namensverwalter k₀ der Verwalterhierarchie kennen.

· Kenntnis eines übergeordneten Verwalters: Jeder Namensverwalter k_i mit i¹0 muß (mindestens) einen ihm übergeordneten Namensverwalter k_i-1 kennen.

· Kenntnis untergeordneter Verwalter: Jeder Namensverwalter k_i muß seine ihm untergeordneten Namensverwalter k_i+1 kennen, sofern diese existieren.

· Symmetrie der Konfigurationsinformation: Falls k_i+1 ein untergeordneter Namensverwalter von k_i ist, so ist k_i auch ein übergeordneter Namensverwalter von k_i+1.

Diese Konsistenzbedingungen für die Konfigurationsinformation können nur verletzt werden, wenn Namensverwalter hinzugefügt oder aus der Verwalterhierarchie entfernt werden. Es ist daher darauf zu achten, daß diese Operationen einen atomaren Verlauf nehmen. Zusätzlich kann der Ausfall eines Namensverwalters diese Konsistenzbedingungen verletzen (vgl. hierzu Kapitel 5). In herkömmlichen Namensverwaltungen ist die Bereitstellung der Konfigurationsinformation mit einem hohen administrativen Aufwand verbunden und erfordert detaillierte Kenntnisse über die Arbeitsweise der Namensverwaltung. Die in dieser Arbeit beschriebene dynamische globale Namensverwaltung erstellt die Konfigurationsinformation selbständig und legt sie in der Namensbasis des Namensverwalters als spezielle Namenseinträge ab.

Namensverwalter werden repliziert, um die Auflösung globaler Namen zu beschleunigen und die Ausfallsicherheit der Namensverwaltung zu erhöhen. Die Replikationsinformation in Namensverwaltern kann sowohl Verweise auf replizierte Namensverwalter im lokalen als auch im globalen Netzwerkbereich umfassen. Die Replikation kann ganze Namensverwalter umfassen oder sich auf einzelne Teile der Namensbasis beschränken. Innerhalb lokaler Netzwerke mit Broadcast-Eigenschaft beschränkt sich die Replikation auf globale Namen, da verbundweite Namen durch Broadcast-Nachrichten aufgelöst werden können. Zwischen unzuverlässigen und langsamen globalen Kommunikationsverbindungen werden Namenseinträge aus Gründen der Effizienz und Verfügbarkeit repliziert. Die Replikationsinformation in Namensverwaltern kann symmetrisch oder einseitig sein, je nachdem ob Namensverwalter wechselseitig repliziert werden oder ein primärer Namensverwalter existiert.

Die Navigationsinformation in hierarchisch organisierten Namensverwaltern hat ebenfalls gewisse Konsistenzbedingungen zu erfüllen, wie in Kapitel 4 noch eingehend dargelegt wird. Navigationsinformationen verweisen auf untergeordnete Namensverwalter, die die Zuständigkeit für eine bestimmte Partition des Namensraums besitzen. Die Bereitstellung von Navigationsinformation, die für die globale Auflösung von Namen unentbehrlich ist, erfolgt in herkömmlichen Namensverwaltungen durch Administration. Die dynamische globale Namensverwaltung hingegen generiert diese Navigationsinformation in Namensverwaltern selbständig (vgl. Kapitel 4).

3.4.2 Manuelle Konfigurierung hierarchischer Verwalternetze

Die Struktur des Verwalternetzes korrespondiert vielfach mit der Struktur des verwalteten Namensraums. Hierarchische Namensräume werden auf eine Hierarchie von Namensverwaltern verteilt, indem jedem Namensverwalter die Verantwortung für einen Unterbaum des Namensraums übertragen wird. Diese Zuordnung und die Konfigurierung des entsprechenden hierarchischen Verwalternetzes geschieht bisher weitgehend manuell und erfordert einen erheblichen administrativen Aufwand und detaillierte Kenntnisse von der Arbeitsweise der Namensverwaltung. Um hierarchische Namensverwalter zu organisieren, gibt es zwei grundlegende Ansätze, eine feste und eine variable Anzahl von Hierarchiestufen des Verwalternetzes.

3.4.2.1 Feste Anzahl von Hierarchiestufen des Verwalternetzes

Feste hierarchische Verwalterstrukturen findet man in der Regel dann vor, wenn das Wachstum von Namensräumen auf die horizontale Ebene begrenzt ist (vgl. Grapevine und Clearinghouse in Anhang B.2). Dem horizontalen Wachstum des Namensraums kann bei festen Hierarchiestufen des Verwalternetzes durch das Hinzufügen von Namensverwaltern auf einer Hierarchieebene begegnet werden.

Ein Beispiel für einen dreistufigen Namensraum liefert die Benennung der Mitarbeiter einer Universität. Sie können durch die Kontexte Fakultät und Abteilung und durch den Nachnamen der Mitarbeiter (Fakultät.Abteilung.Nachname) vollständig charakterisiert werden. Die konstante Anzahl organisatorischer Ebenen in diesem Namensraum kann auf eine feste Hierarchie von Namensverwaltern abgebildet werden. So werden die Fakultäten von einem oder mehreren Namensverwaltern der obersten Ebene verwaltet, die Abteilungen von Namensverwaltern der darunterliegenden Ebene und die Mitarbeiter auf der untersten Ebene (vgl. Abbildung 3.18).

Abbildung 3.18: Hierarchische Verwalterorganisation mit fester Anzahl von Verwalterebenen

Bisher wurde ein Namensraum mit konstanter Anzahl von Hierarchiestufen zugrundegelegt. Um die Skalierbarkeit eines Namensraums zu gewährleisten, muß jedoch nicht nur ein horizontales, sondern auch ein vertikales Wachstum möglich sein. Wird ein Namensraum mit beliebiger Verschachtelung von Kontexten verwendet, so hat bei konstanter Anzahl von Hierarchieebenen des Verwalternetz ein Namensverwalter eine variable Anzahl von Kontexten zu verwalten. Die Hierarchie von Namensverwaltern bleibt unverändert, während die Anzahl der Hierarchiestufen des Namensraums variiert.

Als Beispiel hierfür kann ein verteiltes Dateisystem mit Namen der Form /usr/src/file.c und beliebig vielen Stufen von Dateiverzeichnissen dienen. Im Gegensatz zu obigem Beispiel eines relativ festen Namensraums mit Kontexten für Fakultäten, Abteilungen und Mitarbeiter ist hier die Einführung eines neuen Kontextes auf einer existierenden Hierarchiestufe oder die Definition einer gesamten neuen Hierarchiestufe in Form von Dateiverzeichnissen eine häufige Operation. Dabei kann keinesfalls jeweils ein neuer Namensverwalter bzw. Dateiserver installiert werden. Vielmehr muß bei der Definition eines neuen Kontextes festgelegt werden, welcher existierende Verwalter dafür zuständig ist. Voreingestellt kann dies der Verwalter des übergeordneten Kontextes sein. Zum Beispiel könnte ein Verwalter für alle Kontexte unterhalb von /usr, also etwa usr/src, /usr/src/c, /usr/src/pascal, /usr/bin usw. zuständig sein.

3.4.2.2 Variable Anzahl von Hierarchiestufen des Verwalternetzes

Um das vertikale Wachstum hierarchischer Namensräume durch eine Verteilung der Zuständigkeiten effektiv unterstützen zu können, muß die Hierarchie der Namensverwalter auch vertikal wachsen können. Die Flexibilisierung der Anzahl von Hierarchiestufen im Namensraum erfordert eine variable Anzahl von Hierarchieebenen im Verwalternetz (vgl. Abbildung 3.19).

Eine vertikale Ausdehnung der Verwalterhierarchie ermöglicht bei vertikalem Wachstum des Namensraums eine gleichmäßige Verteilung der Last auf Namensverwalter. Die Möglichkeit zur Unterhaltung eigenständiger Namensverwalter gewährleistet die Autonomie organisatorischer Einheiten, sowohl im operationellen als auch im administrativen Bereich.

Abbildung 3.19: Hierarchische Verwalterorganisation mit variabler Anzahl von Verwalterebenen

Dem horizontalen Wachstum des Namensraums kann nun durch das Hinzufügen von Namensverwaltern auf einer Hierarchieebenen begegnet werden, während das vertikale Wachstum des Namensraums durch die vertikale Ausdehnung der Verwalterhierarchie erleichtert wird. Vielfach korreliert die Verwalterstruktur mit der Struktur des Namensraums, dies ist jedoch keine notwendige Bedingung.

3.4.3 Dynamische Konfigurierung des hierarchischen Verwalternetzes

Ziel der dynamischen globalen Namensverwaltung ist u.a. die Bereitstellung der für den Aufbau eines hierarchischen Verwalternetzes notwendigen Verwalterinformationen möglichst ohne jegliche Administration. Die einzige Information, die für den Aufbau des Verwalternetzes a priori vorhanden sein muß, ist die Lokation des Namensverwalters in der obersten Hierarchieebene.

Der Aufbau der Verwalterhierarchie in der dynamischen globalen Namensverwaltung kann sich nicht, wie in anderen Systemen (z.B. DNS), an der Struktur des Namensraums orientieren, da dessen Struktur nicht a priori bekannt ist und sich dynamisch verändert.

Im vorliegenden Entwurf einer dynamischen globalen Namensverwaltung sind für das Integrieren eines neuen Namensverwalters k_new in das Verwalternetz folgende Schritte erforderlich:

1. Ermitteln des obersten Namensverwalters k₀.

2. Ermitteln übergeordneter Namensverwalter {k_i,1,…,k_i,n} zu k_new beim obersten Namensverwalter k₀.

3. Kontaktieren der übergeordneten Namensverwalter {k_i,1,…,k_i,n} und bestimmen nachfolgender Namensverwalter {k_i+1,1,…,k_i+1,m}.

4. Einfügen des neuen Namensverwalters in die Verwalterhierarchie an der ermittelten Position zwischen den Namensverwaltern {k_i,1,…,k_i,n} und {k_i+1,1,…,k_i+1,m}.

Die aufgezeigten Schritte werden im folgenden im Detail diskutiert. Zusätzlich muß eine Metrik eingeführt werden, um die Position des neuen Namensverwalters im Verwalternetz bestimmen zu können. An dieser Stelle sein noch angemerkt, daß jedem Namensverwalter mehrere Namensverwalter untergeordnet bzw. übergeordnet sein können und in das Verwalternetz nur permanent verfügbare Namensverwalter integriert werden.

3.4.3.1 Ermitteln des obersten Namensverwalters der Verwalterhierarchie

Bei der Konfigurierung einer hierarchischen globalen Namensverwaltung muß vor allen anderen Namensverwaltern der oberste Namensverwalter k₀ des Verwalternetzes aktiv sein. Die Positionierung des obersten Namensverwalters k₀ im Netzwerk ist ein anspruchsvoller administrativer Vorgang, da hiervon die Funktionsfähigkeit und Leistung der gesamten globalen Namensverwaltung abhängt. Die Position von k₀ im globalen Netzwerk sollte so gewählt werden, daß die kürzesten Netzwerkpfade zu den entlegendsten Netzwerkbereichen in etwa gleich lang sind, d.h. k₀ in der Mitte eines minimalen Spannbaums liegt.

Äußerst wichtig für die Funktion das Gesamtsystems ist auch die Ausfallsicherheit des obersten Namensverwalters k₀. Um die Verfügbarkeit des Gesamtsystems zu erhöhen, wird k₀ durch weitere Namensverwalter im selben Netzwerkbereich repliziert. Ferner können die Namenseinträge des obersten Namensverwalters k₀ auf der darunterliegenden Verwalterebene repliziert werden, sofern die Netzwerkeigenschaften und die Verfügbarkeit dieses begründen.

Nachdem der oberste Namensverwalter aktiviert ist, können weitere Namensverwalter in das Verwalternetz integriert werden. Bei der Aktivierung eines neuen Namensverwalters k_new muß zunächst der oberste Namensverwalter der Verwalterhierarchie ermittelt werden. Hierbei kommen der Reihe nach folgende Methoden zur Anwendung:

1. Die Lokation des obersten Namensverwalters k₀ der Verwalterhierarchie wird zusammen mit den Namenseinträgen der Namensbasis persistent gespeichert und steht somit bei jeder Reinitialisierung eines Namensverwalters zur Verfügung.

2. Sind in der persistent verwalteten Namensbasis keine Hinweise auf den obersten Namensverwalter k₀ der Verwalterhierarchie zu finden, so versucht der neu hinzukommende Namensverwalter über Broadcast-Nachrichten einen Namensverwalter zu ermitteln, der in Kenntnis der Lokation des obersten Namensverwalters k₀ ist.

3. Gelingt es nach einer bestimmten Zeit nicht, den obersten Namensverwalter k₀ zu ermitteln, so muß der oberste Namensverwalter durch den Administrator identifiziert werden.

Nachdem der Namensverwalter an der Wurzel der Verwalterhierarchie bestimmt ist, muß zur Plazierung des neuen Namensverwalters in der Verwalterhierarchie zunächst die absolute Position des neuen Namensverwalters im Verwalternetz ermittelt werden. Hieraus wird schließlich die Position relativ zu den anderen Namensverwaltern im Verwalternetz festgelegt. Eine geeignete Metrik zur Positionsbestimmung stellt der nächste Abschnitt vor.

3.4.3.2 Die Metrik zur Plazierung von Namensverwaltern im Verwalternetz

Ausschlaggebend für die Position eines Namensverwalters im Verwalternetz sind die Eigenschaften der Kommunikationsverbindungen zu den benachbarten Namensverwaltern (vgl. Tabelle 3.1). Zur Positionsbestimmung von Namensverwaltern könnte beispielsweise die mittlere Verzögerung der Kommunikationsverbindung zum obersten Namensverwalter herangezogen werden. Diese variiert jedoch sehr stark in Abhängigkeit von der Netzwerklast und sagt zudem nichts über die Struktur des Netzwerks und den Netzwerkbereich aus, in dem sich der neue Namensverwalter befindet.

Eine geeignete Metrik zur Positionsbestimmung eines Namensverwalters im hierarchischen Verwalternetz ist die Distanz (D) eines Namensverwalters zur Wurzel der Verwalterhierarchie. Diese Distanz ist definiert als die Anzahl der Netzwerkübergänge, die auf dem kürzesten Weg zum obersten Namensverwalter k₀ zu überwinden sind. Jedem Namensverwalter ist ferner ein Netzwerkpfad zugeordnet, der als Folge von Netzwerkübergängen definiert ist, die Nachrichten von diesem Namensverwalter auf dem kürzesten Weg zum obersten Namensverwalter k₀ überwinden müssen. Zur Positionsbestimmung werden nur Namensverwalter zueinander in Beziehung gesetzt, deren Netzwerkpfade teilweise übereinstimmen (Inklusion). Die Vergleichsrelationen zwischen diesen Netzwerkpfaden sind wie in Tabelle 3.2 definiert:

Relation	Bedeutung
D(k1)= D(k2)	Nachrichten von k1 und k2 haben dieselben Netzwerkübergänge auf dem Netzwerkpfad zu k0 zu überwinden, d.h. k1 und k2 liegen im selben Netzwerkbereich.
D(k1)>D(k2)	Nachrichten von k1 haben im Vergleich zu Nachrichten von k2, zusätzliche Netzwerkübergänge auf dem Netzwerkpfad zu k0 zu überwinden, d.h. k1 liegt in entfernteren Bereichen des Netzwerks.
D(k1)< D(k2)	Nachrichten von k1 haben auf dem Netzwerkpfad zu k0 nur einen Teil der Netzwerkübergänge zu überwinden, die Nachrichten von k2 zu überwinden haben, d.h. k2 liegt in Bereichen des Netzwerks.
D(k1)≠ D(k2)	Nachrichten von k1 und k2 haben (teilweise) unterschiedliche Netzwerkübergänge auf dem Netzwerkpfad zu k0 zu überwinden, d.h. k1 und k2 liegen in unterschiedlichen Bereichen des Netzwerks.

Tabelle 3.2: Vergleichsrelationen zur Positionierung von Namensverwaltern

Obige Vergleichsrelationen definieren eine Teilordnung über den Namensverwaltern, da nur Namensverwalter auf demselben Netzwerkpfad zu k₀ miteinander in Beziehung gesetzt werden.

3.4.3.3 Ermitteln der Position in der Verwalterhierarchie

Sobald der oberste Namensverwalter k₀ ermittelt ist, wird er durch den neu zu registrierenden Namensverwalter k_new kontaktiert, um auf dem Netzwerkpfad von k_new zu k₀ übergeordnete Namensverwalter {k_i,1,…,k_i,n} mit D(k_new)>D(k_i) zu ermitteln (vgl. Abbildung 3.20). Der oberste Namensverwalter k₀ enthält dabei nur Verweise auf direkt untergeordnete Namensverwalter.

Abbildung 3.20: Positionierung eines neuen Namensverwalters

Wird ein übergeordneter Namensverwalter k_i mit D(k_new)>D(k_i) lokalisiert, so richtet sich der neue Namensverwalter k_new an k_i, um weitere Namensverwalter {k_i+1,1,…,k_i+1,m} mit D(k_new)>D(k_i+1)> D(k_i) zu ermitteln. Dieses Vorgehen wird wiederholt, bis

1. Namensverwalter {k_i+1,1,…,k_i+1,m} mit der Eigenschaft D(k_new)=D(k_i+1)>D(k_i) existieren. Dann wird die Namensbasis der Namensverwalter {k_i+1,1,…,k_i+1,m} in k_new repliziert und k_new wird als untergeordneter Namensverwalter von k_i festgehalten.

2. Namensverwalter {k_i+1,1,…,k_i+1,m} mit D(k_i+1)>D(k_new)>D(k_i) ermittelt werden. Dann repräsentieren{k_i+1,1,…,k_i+1,m} untergeordnete Namensverwalter, die in k_new als solche registriert werden. k_new wird als Sukzessor von k_i festgehalten, und die Verwaltungsinformationen der beiden Namensverwalter werden gemäß ihrer Position im Verwalternetz abgeglichen.

3. kein weiterer Namensverwalter k_i+1 in k_i existiert mit D(k_new)>D(k_i+1)>D(k_i). k_new wird als untergeordneter Namensverwalter von k_i festgehalten.

Anhand des Beispiels in Abbildung 3.21 wird dieser Vorgang nochmals verdeutlicht. Hier wird ein Netzwerk gezeigt, dessen einzelne Netzwerkbereiche an den Netzwerkübergängen über Kopplungselemente miteinander verbunden sind (die runden Elemente stellen die Netzwerkübergänge dar). Die Netzwerkübergänge bestehen sowohl aus permanenten als auch aus temporären Verbindungen. Oft handelt es sich in globalen Netzwerken um langsame und unzuverlässige Punkt-zu-Punkt-Verbindungen.

Abbildung 3.21: Verteilung von Namensverwaltern über verschiedene Netzwerkbereiche

Der Namensverwalter in der Mitte von Abbildung 3.21 repräsentiert den obersten Namensverwalter k₀ der Verwalterhierarchie. Die Distanz der einzelnen Namensverwalter zu k₀ dient zur Positionsbestimmung bei der dynamischen Konfigurierung der Verwalterhierarchie. Im vorliegenden Beispiel wird die Distanz anhand der zu überwindenden Netzwerkübergänge auf dem Netzwerkpfad zu k₀ bestimmt. Die Distanzen der Namensverwalter auf den Netzwerkpfaden zu k₀ bilden eine Teilordnung, da nur Namensverwalter zueinander in Beziehung gesetzt werden, wenn die Netzwerkpfade auf dem kürzesten Weg zum obersten Namensverwalter zumindest teilweise übereinstimmen. Typischerweise sind Netzwerke nicht baumförmig organisiert, sondern enthalten Zyklen, die erkannt und eliminiert werden müssen. Allerdings ist es zur Steigerung der Ausfallsicherheit durchaus sinnvoll, alternative Netzwerkpfade für den Weg zum obersten Namensverwalter anzugeben.

Namensverwalter	Distanz	Netzwerkpfad	Namensverwalter	Distanz	Netzwerkpfad
knew	1	4	k6	1	6
k1	2	4,1	k7	1	7
k2	2	4,2	k8	1	7
k3	2	4,2	k9	2	6,8; 7,9
k4	1	5	k10	2	6,8; 7,9
k5	2	5,3	k11	2	7, 10

Tabelle 3.3: Namensverwalter und ihre Netzwerkpfade zum obersten Namensverwalter

In Tabelle 3.3 sind die Distanzen gemessen in Netzwerkübergängen und die Netzwerkpfade der einzelnen Namensverwalter aus Abbildung 3.21 zum obersten Namensverwalter k₀ des Verwalternetzes aufgeführt. Diese Tabelle existiert allerdings nicht wirklich in k₀, sondern die enthaltene Information ist verteilt über alle Namensverwalter. Der oberste Namensverwalter k₀ hält aus Gründen der Speicherökonomie nur Verweise auf die jeweils direkt untergeordenten Namensverwalter eines jeden Netzwerkpfads. Bei der Positionierung eines neuen Namensverwalters k_new im Verwalternetz werden lediglich diejenigen Namensverwalter zueinander in Beziehung gesetzt, die über denselben Netzwerkpfad zu erreichen sind. Daher ergibt sich, wie in Abbildung 3.22 dargestellt, eine Teilordnung auf den Namensverwaltern.

Abbildung 3.22: Aus der in Abbildung 5.24 generierte Hierarchie von Namensverwaltern

Die in Abbildung 3.22 dargestellte Hierarchie von Namensverwaltern gleicht einem Spannbaum (Spanning Tree) [Kruskal, 56]. Allerdings erzeugt das hier beschriebene Verfahren keinen vollständigen Spannbaum, da dies zur Plazierung eines Namensverwalters im Verwalternetz nicht notwendig ist und einen zu hohen Nachrichtenaufwand erfordert[AL5] .

Befinden sich Namensverwalter innerhalb desselben Netzwerkbereichs und sind sie nicht durch Netzwerkübergänge getrennt, so kann die Namensbasis durch Broadcast-Nachrichten zwischen diesen Namensverwaltern entweder vollständig repliziert oder verteilt verwaltet werden.[AL6] [AL7]

3.4.3.4 Dynamische Anpassung der Verwalterinformation

Sobald die Position eines neuen Namensverwalters im Verwalternetz ermittelt ist, gleicht dieser seine Verwalterinformationen mit den direkt übergeordneten bzw. untergeordneten Namensverwaltern ab. Dabei sind folgende Anpassungen in den Namensverwaltern vorzunehmen:

· Änderung der Navigationsinformation direkt übergeordneter Namensverwalter {k_i,1,…,k_i,n} und des neuen Namensverwalters k_new.

· Änderung der Konfigurationsinformation direkt übergeordneter Namensverwalter {k_i,1,…,k_i,n}, direkt untergeordneter Namensverwalter {k_i+1,1,…,k_i+1,m} und des neuen Namensverwalters k_new.

Um die Konfigurations- und Navigationsinformation anzupassen, wendet sich der Namensverwalter k_new zunächst an die direkt übergeordneten Namensverwalter {k_i,1,…,k_i,n} und übernimmt die Namenseinträge ihrer Namensbasen zusammen mit der vorhandenen Navigationsinformation. Nun wird in {k_i,1,…,k_i,n} die Navigations- und Konfigurationsinformation, die bisher auf {k_i+1,1,…,k_i+1,m} verwiesen hat, so geändert, daß sie auf k_new verweist. Im zweiten Schritt kontaktiert der Namensverwalter k_new die Namensverwalter {k_i+1,1,…,k_i+1,m} (sofern vorhanden). Dort substituiert er die auf {k_i,1,…,k_i,n} verweisende Konfigurationsinformation durch Verweise auf k_new. Anschließend werden in der Konfigurationsinformation von k_new die Namensverwalter {k_i+1,1,…,k_i+1,m} als untergeordnete Namensverwalter und die Namensverwalter {k_i,1,…,k_i,n} als übergeordnete Namensverwalter eingetragen.

Abbildung 3.23: Die Phasen des Einfügens eines neuen Namensverwalters

Abbildung 3.23 zeigt die einzelnen Schritte der Adaption der Verwalterinformation. Die Reihenfolge, in der die untergeordneten bzw. übergeordneten Namensverwalter kontaktiert werden, ist signifikant, da k_new die Namensbasen der übergeordneten Namensverwalter {k_i,1,…,k_i,n} übernehmen muß, bevor sie verändert werden.

Falls zu einem Namensverwalter k_new mehrere übergeordnete Namensverwalter {k_i,1,…,k_i,n} existieren, so handelt es sich dabei in der Regel um replizierte Namensverwalter, die im selben Netzwerkbereich liegen und von k₀ über denselben Netzwerkpfad erreicht werden. Unter den replizierten übergeordneten Namensverwaltern wird derjenige als primärer übergeordneter Namensverwalter ausgewählt, der die geringste Nachrichtenverzögerung und das beste Antwortverhalten zeigt. Dieser primäre übergeordnete Namensverwalter wird bei der Auflösung und Registrierung von Namen bevorzugt kontaktiert. Existieren mehrere Netzwerkpfade mit derselben Distanz zum obersten Namensverwalter k₀ (vgl. Knoten 9 und 10 in Abbildung 3.22), so werden als direkt übergeordnete Namensverwalter {k_i,1,…,k_i,n} die Namensverwalter auf dem Netzwerkpfad gewählt, der die geringste Nachrichtenverzögerung zum obersten Namensverwalter k₀ aufweist.

3.4.3.5 Dynamisches Einbinden replizierter Namensverwalter

Die Verfügbarkeit einer Namensverwaltung muß auch dann gegeben sein, wenn Ausfälle von Netzwerkverbindungen und Namensverwaltern zu verzeichnen sind. Während der Ausfall einzelner Namensverwalter durch strukturelle Maßnahmen bei der Konfigurierung des Systems berücksichtigt werden kann, beeinträchtigt der Ausfall von Netzwerkverbindungen die Verfügbarkeit des Gesamtsystems in weit höherem Maße. Bei Netzwerkpartitionierung ist u.U. ein ganzer Teilbereich des Verwalternetzes und damit auch ein Teil des Namensraums nicht mehr erreichbar.

Sofern benannte Objekte nach der Netzwerkpartitionierung zugänglich sind, müssen sie auch über ihre Namen erreicht werden können. Bei statischer Verteilung von Namen über die Namensverwalter ist dies i.d.R. gewährleistet, da die zuständigen Namensverwalter i.a. im selben Netzwerkbereich oder Rechner plaziert sind, wie der Objektverwalter. Bei syntaxgesteuerter Plazierung von Namen besteht die Möglichkeit, daß Namen in Namensverwaltern und Objekte in Objektverwaltern in unterschiedlichen Netzwerkbereichen plaziert werden. Die Auflösung von Namen verfügbarer Objekte kann jedoch durch aktive Replikation bei der Registrierung von Namen und durch passive Replikation (Vorhalten, Caching) bei der Auflösung garantiert werden (vgl. hierzu Kapitel 5). Namenseinträge sind in dem Netzwerkbereich zu replizieren, in dem die zugehörigen Objekte verwaltet werden, so daß bei Netzwerkpartitionierung die lokale Funktion gewährleistet ist. Die Replikation einzelner Namenseinträge ist abhängig von den Zugriffsschemata sowie von der aktuellen Änderungs- und Zugriffshäufigkeit und kann daher zum Zeitpunkt der Initialisierung eines Namensverwalters nicht berücksichtigt werden.

Die Replikationsmaßnahmen in der Initialisierungsphase bleiben somit auf Namensverwalter beschränkt. Die Replikation von Namensverwaltern im Verwalternetz orientiert sich zum einen an den Eigenschaften der zugrundeliegenden Kommunikationsverbindungen und zum anderen an der Netzwerktopologie. Im einzelnen nehmen folgende Faktoren Einfluß auf die Replikation von Namensverwaltern:

Netzwerkeigenschaften	Einfluß auf die Replikation von Namensverwaltern
Die Verzögerung von Netzwerkverbindungen	Besteht eine hohe Verzögerung bei der Übermittlung von Nachrichten zwischen Netzwerkbereichen, so empfiehlt sich die Replikation von Namensverwaltern zwischen diesen Bereichen, um die Zugriffsgeschwindigkeit zu erhöhen.
Die Topologie des Netzwerks und die Anzahl der zu überwindenden Netzwerkübergänge zwischen Namensverwaltern	Abhängig vom Netzwerkbereich, in dem sich ein Namensverwalter befindet, wird er in der Verwalterhierarchie plaziert. Namensverwalter, die nicht durch Netzwerkübergänge getrennt sind, liegen im selben Netzwerkbereich und werden zur Erhöhung der lokalen Ausfallsicherheit repliziert.
Die Semantik der Kommunikation	Multicast- und Broadcast-Verbindungen zwischen Namensverwaltern können für das Propagieren von Änderungen der Namensbasis replizierter Namensverwalter verwendet werden.
Die Zuverlässigkeit und Verfügbarkeit einer Netzwerkverbindung	Kommunizieren Namensverwalter über temporär verfügbare Netzwerkverbindungen, so empfiehlt sich die gegenseitige Replikation von Namensverwaltern im Verwalternetz.
Namensverwaltereigenschaften	Einfluß auf die Replikation von Namensverwaltern
Die Verfügbarkeit der Namensverwalter	In das Verwalternetz werden nur permanent verfügbare Namensverwalter integriert. Die lokale Verfügbarkeit wird zusätzlich durch Replikation im lokalen Netzwerkbereich erhöht.
Das Antwortverhalten der Namensverwalter	Sind mehrere Namensverwalter im selben Netzwerkbereich vorhanden, so wird derjenige Namensverwalter ausgewählt, der das beste Antwortverhalten zeigt.
Die Speicherkapazität der Namensverwalter	Namensverwalter werden auszugsweise oder vollständig gegenseitig repliziert, je nachdem ob die Speicherkapazität der replizierenden Namensverwalter dies zuläßt.

Tabelle 3.4: Eigenschaften des Netzwerks und der Namensverwalter und ihr Einfluß auf die Replikation

Im folgenden bleibt zu klären, welchen Einfluß die zuvor angeführten Faktoren auf die Replikation von Namensverwaltern haben. Die Verzögerung und die Struktur des Netzwerks bestimmen die Position eines Namensverwalters im Verwalternetz. Sind im Netzwerkbereich der ermittelten Lokation bereits Namensverwalter {k_rep} vorhanden, so bietet es sich an, den neu hinzukommenden Namensverwalter k_new zu Replikationszwecken zu nutzen. Falls k_new=k_rep gilt, werden die Namenseinträge von k_new und k_rep repliziert. Diese lokal begrenzte Replikation von Namensverwaltern innerhalb eines Netzbereichs gewährleistet die Funktionsfähigkeit des Gesamtsystems bei Ausfall eines Namensverwalters im Netzwerkbereich.

Abbildung 3.24: Das Einfügen eines zu replizierenden Namensverwalters

Abbildung 3.24 zeigt den Abstimmungsvorgang mit einem zu replizierenden Namensverwalter. Nachdem in der Positionierungsphase zu replizierende Namensverwalter {k_rep} ermittelt wurden, wendet sich der neu hinzukommende Namensverwalter k_new zunächst an {k_rep}, um von diesen zu replizierende Namenseinträge mitsamt der enthaltenen Navigations- und Konfigurationsinformation zu erhalten. Anschließend wendet sich k_new an die direkt übergeordneten Namensverwalter {k_i,1,…,k_i,n} und ergänzt dort die Navigations- und Konfigurationsinformation, die auf {k_rep} verweist, um Verweise auf k_new. Außerdem kontaktiert k_new die Namensverwalter {k_i+1,1,…,k_i+1,m} (sofern vorhanden), um der auf {k_rep} verweisenden Konfigurationsinformation in {k_i+1,1,…,k_i+1,m} Einträge auf k_new hinzuzufügen.

Unzuverlässigen, temporären und langsamen Verbindungen wird häufig durch die globale Replikation von Namensverwaltern begegnet. In der dynamischen globalen Namensverwaltung ist diese Replikationsmaßnahme nicht sinnvoll, da dann u.U. Namen aufgelöst werden können, die zugehörigen Objekte jedoch trotzdem nicht zugänglich sind. Außerdem kann in diesem Fall ein Name zuvor partiell aufgelöst werden, der verbleibende Teil des Namens wird jedoch von Namensverwaltern gehalten, die nicht erreichbar sind. Um die Funktionsfähigkeit des Gesamtsystems durch replizierte Namensverwalter zu gewährleisten, wäre die wechselseitige Replikation aller Namensverwalter in Netzwerkbereichen erforderlich, die über temporäre oder langsame Verbindungen verbunden sind. Wesentliche Verbesserung bringt hier die Replikation einzelner Namenseinträge unter Berücksichtigung der Zugriffs- und Änderungsfrequenz und der Zugriffsmuster, wie sie in Kapitel 5 beschrieben wird.

3.4.3.6 Dynamisches Deaktivieren eines Namensverwalters

Im Rahmen der dynamischen Konfigurierung werden Namensverwalter im Verwalternetz nicht nur hinzugefügt, sondern auch wieder deaktiviert und entfernt. Um den Zusammenhang des Verwalternetzes zu gewährleisten, sind übergeordnete und untergeordnete Namensverwalter über das Ausscheiden eines Namensverwalters in Kenntnis zu setzen. Dabei ist wiederum eine Anpassung der Verwalterinformationen erforderlich. Den Vorgang des Deaktivierens eines nicht replizierten Namensverwalters zeigt Abbildung 3.25.

Abbildung 3.25: Die Phasen des Deaktivieren eines nicht replizierten Namensverwalters

Für die Deaktivierung eines Namensverwalters werden zunächst die von k_i verwalteten Namenseinträge und Navigationsinformationen an die übergeordneten Namensverwalter {k_i-1,1,…,k_i-1,l} übertragen und in deren Namensbasis integriert. Die übergeordneten Namensverwalter {k_i-1,1,…,k_i-1,l} entfernen dabei alle Verweise auf k_i aus ihrer Navigationsinformation. Ebenso werden alle Verweise auf k_i in der Konfigurationsinformation von {k_i-1,1,…,k_i-1,l} durch Verweise auf die untergeordneten Namensverwalter {k_i+1,1,…,k_i+1,m} ersetzt. Anschließend wird die auf übergeordnete Namensverwalter verweisende Konfigurationsinformation der untergeordneten Namensverwalter {k_i+1,1,…,k_i+1,m} so angepaßt, daß sie nicht länger auf k_i, sondern nunmehr auf {k_i-1,1,…,k_i-1,l} verweist.

Ist für einen zu deaktivierenden Namensverwalter k_i ein replizierter Namensverwalter k_rep vorhanden, so wird diesem die Verwaltung der betreffenden Einträge übertragen. Danach wird die Navigations- und Konfigurationsinformation der übergeordneten Namensverwalter {k_i-1,1,…,k_i-1,l} dahingehend modifiziert, daß sie nicht länger auf k_i, sondern nur noch auf k_rep verweist. Die Konfigurationsinformation der untergeordneten Namensverwalter {k_i+1,1,…,k_i+1,m} wird entsprechend angepaßt.

_{Nachdem dieses Kapitel aufgezeigt hat, wie ein Verwalternetz ohne Administrationsarbeit konfiguriert werden kann, diskutiert das folgende Kapitel zunächst Methoden zur Abbildung eines globalen Namensraums auf ein hierarchisches Verwalternetz. Schließlich wird ein Verfahren vorgestellt, um globale Namen selbständig und ohne Administration adäquat auf hierarchisch organisierte Namensverwalter zu verteilen.}

Die automatische Konfigurierung des Verwalternetzes unter Berücksichtigung der Netzwerktopologie und der Verbindungseigenschaften ermöglicht die Anpassung der Namensverwaltung an die Gegebenheiten des zugrundeliegenden Netzwerks und die Kompensation von Ausfällen.

---

^[1] Vgl. hierzu auch Kapitel 4.

^[2] Auch abhängig von der Anfrage: „Finde einen Drucker im Gebäude“ oder „Finde alle Drucker im Netzwerk“

^[3] Beispielsweise im Internet.

^[4] Außer bei Standleitungen.

^[5] Der Zugang zum Internet kann mit jedem Modem über PPP oder SLIP hergestellt werden.

^[6] Das mobile D-Netz besteht nur aus Punkt-zu-Punkt-Verbindungen.

^[7] Entspricht hier einer ringförmigen Verkettung von Namensverwaltern.

---

[AL1]Modell von Mattes?!

Namensverwalter

Katalogverwalter

[AL2] Sollte es in der Zeichung nicht besser Verwater heißen???

[AL3]Literatur??

[V4] Sollte man hier nicht noch was über die logische Partitionierung schreiben?

[AL5]Referenz

[AL6]Was passiert bei Änderungen der Netzwerkstruktur??

[AL7]Gleichbehandlung Netzwerkübergänge und Punkt-zu-Punkt-Verbindungen

Lokaler Knoten wird als Netzwerksegment gesehen