DE69635469T2

DE69635469T2 - Synchronisierung zwischen verschiedenen Computeranbieterumgebungen

Info

Publication number: DE69635469T2
Application number: DE69635469T
Authority: DE
Inventors: Richard C. Round Rock Foltz; Sy Long Austin Lin; John Vincent Austin Meegan; Syed Abdul Austin Wadood
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1995-09-25
Filing date: 1996-09-20
Publication date: 2006-07-27
Anticipated expiration: 2016-09-21
Also published as: DE69635469D1; EP0765062B1; JPH09198294A; JP4222642B2; US5978813A; EP0765062A3; EP0765062A2

Description

Die vorliegende Erfindung bezieht sich im Allgemeinen auf ein Serversystem für den Gebrauch mit einer Vielzahl von Recheneinrichtungen und insbesondere auf ein Serversystem, das für das Synchronisieren zwischen verschiedenartigen Serverumgebungen für Rechner sorgt. Ganz besonders bezieht sich die vorliegende Erfindung auf ein Synchronisiersystem, wie es in einem lokalen Netzwerk benutzt wird, das einer verteilten Rechenumgebung angepasst ist.
Kopierbare Änderungen an Datenbanken sind beispielsweise aus US-Patentschrift 5 261 094 A bekannt.
Datenverarbeitung und Rechnersysteme sind allgemein bekannt. Insbesondere ist der Gebrauch von mehreren Verarbeitungssystemen, die miteinander verbunden sind, so dass sie ein Lokales Netzwerk (LAN) bilden, ebenfalls allgemein bekannt. Eine erweiterte Anwendung von LANs ist als verteilte Rechenumgebung (DCE) bekannt und ist in der Lage, mit einer größeren Anzahl von Rechnersystemen innerhalb des Serversystems umzugehen, als es üblicherweise in einem LAN-Serversystem der Fall ist.
Wenn ein Geschäft oder ein Unternehmen anfängt, sich zu entwickeln, ist es üblicherweise klein und erfordert entweder nur einen Rechner oder lediglich ein paar Rechner, um alle Bedürfnisse nach Datenverarbeitung in diesem bestimmten Unternehmen zu erfüllen. Wenn das Unternehmen wächst, werden zusätzliche Datenverarbeitungssysteme hinzugefügt, und letztendlich wird ein LAN mit einem LAN-Server hinzugefügt, der dafür verwendet wird, Systemsicherheit zu bieten und für das Synchronisieren des Datenaustausches zwischen den verschiedenen Rechnern auf dem LAN zu sorgen. Wenn das Unternehmen noch größer wird, sind die Fähigkeiten des LAN-Server überfordert, und das Unternehmen ist reif für eine verteilte Rechenumgebung (DCE). Der Sicherheitsaufbau einer DCE unterscheidet sich üblicherweise stark von dem für einen LAN-Server, und der Synchronisiervorgang ist aufgrund der hinzugefügten Betriebsmittel und der Fähigkeiten, wie sie vom DCE-Server gefordert werden, außerdem komplexer.
Der DCE-Sicherheitsserver besteht üblicherweise aus den folgenden Diensten: Registerdienst, Echtheitsdienst, Bevorrechtigungsdienst und Liste für die Zugriffssteuerung. Ein Registerdienst wird bereitgestellt, um die Registerdatenbank zu pflegen, die aus einer kopierten Datenbank von Auftraggebern, Gruppen, Organisationen, Buchhaltungs- und Verwaltungsregeln besteht. Ein Echtheitsdienst wickelt die Benutzerberechtigungsüberprüfung oder den Vorgang zur Überprüfung ab, dass Auftraggeber korrekt erkannt werden. Der Echtheitsdienst gibt auch Berechtigungen heraus, die ein Auftraggeber benutzt, um auf entfernte Dienste zuzugreifen. Die Berechtigung enthält Daten, die vom Auftraggeber vorgelegt werden, wenn er den Dienst des Auftraggebers anfordert, der den Dienst bereitstellt. Der Bevorrechtigungsdienst liefert die Bevorrechtigungs-Attribute des Benutzers, die dafür benutzt werden sicherzustellen, dass ein Auftraggeber die Rechte hat, die angeforderten Vorgänge auszuführen. Die Einrichtung der Liste der Zugriffssteuerung (ACL) ermittelt die Zugriffsrechte auf ein Objekt auf der Grundlage der Zugriffsfreigaben des Objektes.
Die DCE-Sicherheit enthält weiterhin eine DCE-Hauptrechner-Hintergrundroutine (DCED), die als Sicherheits-Client agiert. Die Dienste für Registrierung, Echtheit und Bevorrechtigung werden als einzelne Hintergrundroutine eingerichtet, die üblicherweise als Sicherheitsserver bezeichnet wird. Die tatsächliche Gewährung von Zugriffsrechten zu einem Objekt wird durch die ACL-Einrichtung bewerkstelligt; das ACL-Aufbereitungswerkzeug richtet für ein Objekt die Zugriffsgenehmigungen ein. Der Echtheitsdienst besteht aus einer Registerdatenbank, Sicherheitsservern und Sicherheits-Clients. Ein Sicherheits-Client tauscht Daten mit einem Sicherheitsserver aus, um Informationen und Vorgänge anzufordern. Der Sicherheitsserver greift auf die Registerdatenbank zu, um Anfragen und Aktualisierungen durchzuführen und die Anmeldungen der Benutzer zu überprüfen. Um Zugriff auf die Registerdatenbank zu erhalten, muss sich der Echtheitsdienst beim Registerdienst melden.
1 zeigt eine Übersichtsdarstellung der Beziehungen zwischen den Sicherheit-Clients 11, den Servers 13 und einer Registerdatenbank 15. Sie ist auch ein Beispiel für die Clients des Sicherheitsserver, die einen Datenbankvorgang anfordern.
Die Registerdatenbank 15 enthält Informationen, die denen gleichen, wie sie in einer UNIX-Gruppe und Passwortdateien zu finden sind. Sie enthält die folgenden Dinge: Auftraggeber, Gruppen, Organisationen und Dateneinträge der Zugangsrechte von Teilnehmern (accounts). Auftraggeber gehören dazu, und sie sind die Benutzer des Systems. Auftraggeber können im Dialog arbeitende Auftraggeber wie etwa menschliche Benutzer oder ohne Dialog arbeitende wie etwa Server, Maschinen und Zellen sein. Auftraggeber können mit Zugriffsgenehmigungen verbunden sein. Gruppen sind eine Ansammlung von Auftraggebern, die durch einen Gruppennamen gekennzeichnet werden. Gruppen können mit Zugriffsgenehmigungen verbunden sein. Organisationen bestehen aus einer Ansammlung von Auftraggebern; diese Auftraggeber sind durch einen Organisationsnamen gekennzeichnet. Organisationen definieren die mit den Auftraggebern in den Registern verbundenen Verfahrensweisen. Organisationen können nicht mit Zugriffsgenehmigungen verbunden werden. Accounts enthalten die Passwörter und die Account-Informationen, die Auftraggebern den berechtigten Zugriff zu Objekten innerhalb der Zelle gestatten.
Die Registerdatenbank 15 enthält auch Informationen über Verfahrensweisen und Eigenschaften für das Register als Ganzes und für Organisationen. Verfahrensweisen und Eigenschaften regeln, z.B. Passwortlänge, Format und bestimmte Echtheit von Anforderungen.
Die Ansammlung von Auftraggebern, Gruppen, Organisationen und Accounts, die von einer Registerdatenbank gesteuert werden, besteht aus einer Einheit, die als Zelle bezeichnet wird. Berechtigter Datenaustausch ist zwischen Zellen nur möglich, wenn diese Zellen bestimmte Accounts in der Registerdatenbank an der Zelle haben, mit der sie zu kommunizieren wünschen. Diese speziellen Accounts richten eine Überkreuz-Berechtigung der Zellen ein, die Auftraggebern einer Zelle den berechtigten Zugriff auf eine andere Zelle gestatten.
Das Hinzufügen von Servers des LAN-Server zum DCE-System oder von DCE-Systemservers zum LAN-Server kann für das Unternehmen kompliziert und mühsam sein, um aber ein derartiges Trauma gering zu halten, ist es ziemlich üblich, schrittweise von einer LAN-Server- zu einer DCE-Serverumgebung überzugehen, wobei das LAN- und das DCE-System sich überdeckende Fähigkeiten und sich überlappende Funktionen Betrieb haben. Zusätzlich kann der LAN-Server lediglich eine Untermenge der DCE-Umgebung sein. In beiden Fällen ist es hilfreich, zwischen den zwei Systemen eine gegenseitige Verträglichkeit zu haben, so dass Kosten minimiert und die Unvereinbarkeit der Systeme vermieden werden.
Ein Beispiel eines LAN-Server ist der OS/2-LAN-Server 4.0, der von Internation Business Machines Corporation vertrieben wird. Der LAN-Server 4.0 bietet dem Unternehmen die Funktionen eines großen Netzwerkes. Das derzeitige LAN-Server-Grundgerüst kann weiterbestehen und sich als getrenntes Produkt entfalten, um für kleine bis mittlere Arbeitsgruppen gemeinsam genutzte Dienste für Dateien und zum Drucken bereitzustellen. Der LAN-Server gestattet auch, die Grundfunktionen auf große Unternehmen auszudehnen, indem er das Basisverzeichnis des LAN-Server und die Sicherheitsstruktur durch die gleichwertigen DCE-Dienste ersetzt. Dies sorgt für einen Übergang vom Arbeitsgruppen kleiner bis mittlerer Größe zu den großen Umgebungen vom DCE-Typ.
Eine Einschränkung des Überganges vom System des OS/2-LAN-Server 4.0 zu einem robusteren DCE-Unternehmensserver besteht darin, dass der Synchronisiervorgang mit dem DCE-Sicherheitsserver des Systems vollständig verträglich sein muss. Unglücklicherweise gibt es bei derzeitigen DCE- Sicherheitsservers Unverträglichkeiten mit früheren LAN-Serversystemen, die es nicht gestatten, die beiden Systeme lediglich zu verknüpfen, um für die beiden Umgebungen zu einem gemeinsamen System zu kommen. Insbesondere pflegt der Sicherheitsserver der DCE zu jeder Zeit eine Arbeitskopie der Registerdatenbank. Die Registerdatenbank kann innerhalb ihrer Zelle kopiert werden.
Jede Instanz eines Sicherheitsserver in einer Zelle pflegt eine Arbeitskopie der Datenbank. Die Verknüpfung eines Sicherheitsserver mit seinen Daten, der Registerdatenbank, wird als „Datenbankbereichskopie" bezeichnet. Üblicherweise erzeugt der Sicherheitsserver in einer Zelle mehrere Datenbankbereichskopien, um das Leistungsvermögen und die Zuverlässigkeit zu verbessern. Die Aufgabe, die Datenbankbereichskopien der Zelle deckungsgleich zu halten, wird durch die Sicherheitsserver automatisch erledigt. Jegliche an den Daten vorgenommenen Änderungen werden automatisch in allen Datenbankbereichskopien abgebildet, innerhalb der Datenbankbereichskopien gibt es eine Rangfolge mit einer Master-Datenbankbereichskopie oder ersten Datenbankbereichskopie und mehreren zweiten Datenbankbereichskopien.
In einem DCE-Unternehmen, das einen LAN-Server enthält, müssen zwei getrennte Systeme so aufrechterhalten werden, dass eine Domänensteuerung eingerichtet wird, weil der Vorgang des Synchronisierens des Registers (RSP) nicht an der gleichen Maschine laufen kann, in welcher der Sicherheitsserver der DCE eingerichtet wurde. Das RSP innerhalb des LAN-Server wird dann eine modifizierte Version des zweiten Sicherheitsserver in dem DCE-Unternehmen. Dieses RSP registriert sich selbst als zweite Datenbankbereichskopie zu dem Zweck, dass es von der ersten Datenbankbereichskopie rechtzeitig Aktualisierungen empfängt. Da es der Sicherheitsaufbau der DCE nicht gestattet, dass mehr als eine Datenbankbereichskopie an der gleichen Maschine läuft, kann die aktuelle Version des RSP nicht an einer Maschine laufen, an der eine erste oder eine zweite Datenbankbereichskopie installiert ist. Aufgrund dessen gibt es einen Bedarf nach einer Lösung, die es sowohl dem LAN-Server-RSP als auch dem DCE-Sicherheitsserver gestatten, in einem System miteinander vorhanden zu sein, ohne dass sie bei ihrer Erzeugung von Datenbankbereichskopien und beim Synchronisieren der Register gegenseitig miteinander in Konflikt kommen.
Es ist daher ein Ziel der vorliegenden Erfindung, ein Serversystem zum Gebrauch mit einer Vielzahl von Rechengeräten bereitzustellen und insbesondere ein Serversystem bereitzustellen, das für das Synchronisieren zwischen einander nicht ähnlichen Serverumgebungen von Rechnern sorgt.
Nach einem ersten Aspekt der Erfindung wird ein Synchronisiersystem für Datenbanken zum Synchronisieren einer Vielzahl von lokalen Datenbanken in einer Vielzahl von verteilten Rechensystemen bereitgestellt, die eine verteilte Rechnerumgebung (DCE) bilden, das Folgendes umfasst: einen DCE-Systemserver; eine DCE-Registerdatenbank, die mit dem DCE-Systemserver verbunden ist; einen Synchronisierserver für ein Lokales Netzwerk (LAN), der mit dem DCE-Systemserver verbunden ist, um damit von einer der lokalen Datenbanken Aktualisierungen an einen LAN-Server zu übertragen, der mit dem Synchronisierserver des lokalen LAN verbunden ist; eine Synchronisationsbibliothek des LAN-Server, die mit dem DCE- Systemserver verbunden ist; wobei der LAN-Server, der mit dem Synchronisierserver des LAN und ausgewählten aus der Vielzahl von verteilten Rechensystemen verbunden ist, die ein LAN bilden, wobei die Synchronisationsbibliothek des LAN-Server so aufgebaut ist, dass sie alle lokalen Datenbanken synchronisiert, die durch Registerveränderungen in der Registerdatenbank der DCE betroffen sind.
Nach einem zweiten Aspekt wird ein Synchronisiersystem zum Gebrauch in einer verteilten Rechenumgebung (DCE) bereitgestellt, das Folgendes umfasst: eine Registerdatenbank, die mit jeder aus der Vielzahl von lokalen Datenbanken innerhalb jedes Rechensystems innerhalb der DCE verbunden ist; eine mit der Registerdatenbank verbundene erste Datenbankbereichskopie, die jede lokale Datenbank innerhalb der DCE mit der Registerdatenbank synchronisiert; und eine mit der ersten Datenbankbereichskopie verbundene zweite Datenbankbereichskopie, die mindestens einen Server eines Lokalen Netzwerkes (LAN) synchronisiert, der ausgewählte aus der Vielzahl von Rechensystemen und ihre jeweiligen Datenbanken mit der Registerdatenbank synchronisiert.
Die erste Datenbankbereichskopie des Synchronisiersystems nach dem zweiten Aspekt umfasst vorzugsweise Registersynchronisations-Aufrufe, damit ein bestimmter LAN-Server synchronisiert wird.
Der LAN-Server des Synchronisiersystems nach dem zweiten Aspekt umfasst vorzugsweise einen LAN-Synchronisierserver, der mit der ersten Datenbankbereichskopie verbunden ist, und eine Synchronisationsbibliothek für den LAN-Server, die mit dem LAN-Synchronisierserver verbunden ist, wobei Registerveränderungen in der Registerdatenbank, die eine lokale Datenbank oder eine Gruppendatenbank innerhalb der DCE betreffen, die Synchronisationsbibliothek des LAN-Server auffordern, die betroffene Datenbank zu synchronisieren.
Ein bevorzugtes System umfasst Mittel zum Feststellen, ob die Synchronisationsbibliothek des LAN vorhanden und aktiv ist. Die Bibliothek dient vorzugsweise als Filter und Warteschlange für Aktualisierungen für den Synchronisierserver des LAN.
Nach einem dritten Aspekt der Erfindung wird in einer Vielzahl von verteilten Rechensystemen, von denen jedes eine lokale Datenbank hat, die eine verteilte Rechenumgebung bilden (DCE), ein Verfahren zum Synchronisieren der Vielzahl von lokalen Datenbanken bereitgestellt, das Folgendes umfasst: Bereitstellung des ersten Datenaustausches von einem Rechensystem zu einem anderen Rechensystem und mit einer Registerdatenbank innerhalb der DCE; Einrichten eines Server zum zweiten Datenaustausch für ein lokales Netzwerk (LAN) des Rechensystems, das aus der Vielzahl von Rechensystemen in der DCE ausgewählt wurde; Einrichten einer Synchronisationsbibliothek des LAN-Server; Ermitteln, ob Registerveränderungen in der Registerdatenbank mindestens eine aus der Vielzahl der lokalen Datenbanken innerhalb des LAN betreffen; und Aufrufen der Synchronisationsbibliothek des LAN-Server, damit die betroffene Datenbank synchronisiert wird.
Der Schritt des Einrichtens der Synchronisationsbibliothek des LAN-Server enthält weiterhin vorzugsweise den Schritt des Ermittelns, ob die Synchronisationsbibliothek des LAN vorhanden und aktiv ist.
In einem bevorzugten Verfahren führt die Synchronisationsbibliothek des LAN den Schritt des Filterns und Einreihens in eine Warteschlange der Aktualisierungen zum Synchronisieren zwischen der Registerdatenbank und der lokalen LAN-Datenbank durch.
Der Schritt zum Ermitteln, ob Registerveränderungen erforderlich sind, enthält vorzugsweise die folgenden weiteren Schritte: Empfangen von Ereignisbenachrichtigungen einer Aktualisierung, sie zu verarbeiten, und Überwachen von Aktualisierungsübermittlungen von der Registerdatenbank an die lokalen Datenbanken.
Das Verfahren umfasst vorzugsweise auch den Schritt des Pflegens einer Liste von lokalen Datenbanken des LAN, denen es gestattet ist, sich beim Systemserver registrieren zu lassen. Weiterhin umfasst der Schritt des Aufrufens vorzugsweise das Abrufen der sämtlicher Benutzer- und Gruppeninformationen aus jeder lokalen Datenbank, die zu dem damit verbundenen Netzwerk innerhalb der verteilten Rechenumgebung gehört, und das Synchronisieren der lokalen Datenbanken des LAN in jedem Register innerhalb der DCE mit den Benutzer- und Gruppeninformationen. Der Synchronisierschritt des LAN umfasst vorzugsweise weiterhin das Auslösen eines Rufes, Aktualisierungen zu den lokalen Registerdatenbanken innerhalb der DCE bereitzustellen.
In einem bevorzugten Verfahren umfasst der Schritt des Bereitstellens einer ersten Kommunikation das Erzeugen gemeinsam genutzter Speicherobjekte zum Datenaustausch mit dem zweiten Kommunikations-Server.
In einem alternativen Verfahren umfasst der Schritt des Einrichtens des zweiten Kommunikations-Server Folgendes: Einrichten des zweiten Kommunikations-Server als zweite Datenbankbereichskopie; Empfangen der vollständigen Registerdatenbank der DCE von einer ersten Datenbankbereichskopie; und Einrichten einer Weiterleitungswarteschlange, die eine erste Weiterleitung zuteilt, die eine gegebene Reihenfolgenummer hat, wobei zusätzliche Weiterleitungen jeweils um eins für jede nachfolgende Weiterleitung zur Aktualisierung von Registern erhöht werden.
Nach einem vierten Aspekt der Erfindung wird ein Verfahren zum Synchronisieren einer verteilten Rechenumgebung (DCE) bereitgestellt, das Folgendes umfasst: Einrichten einer Registerdatenbank, die mit jeder aus der Vielzahl der lokalen Datenbanken innerhalb jedes Rechensystems in der DCE verbunden ist; Einrichten einer ersten Datenbankbereichskopie, die jede lokale Datenbank innerhalb der DCE mit der Registerdatenbank synchronisiert; und Einrichten einer zweiten Datenbankbereichskopie, die mindestens einen Server eines Lokalen Netzwerkes (LAN), der ausgewählte aus der Vielzahl der Rechensysteme und ihre jeweiligen Datenbanken umfasst, mit der Registerdatenbank synchronisiert. Der Schritt des Einrichtens der ersten Datenbankbereichskopie umfasst vorzugsweise das Erzeugen von Rufen zum Synchronisieren der Register für einen bestimmten LAN-Server, der synchronisiert werden soll.
Nach einem fünften Aspekt der Erfindung wird ein Rechner-Programmprodukt zum Gebrauch in einer Vielzahl von verteilten Rechensystemen bereitgestellt, von denen jedes eine lokale Datenbank hat, die eine verteilte Rechenumgebung (DCE) bilden, wobei das Produkt zum Synchronisieren der Vielzahl von lokalen Datenbanken Folgendes umfasst: ein rechnernutzbares Codemittel zum Bewerkstelligen eines ersten Datenaustauschs von einem Rechensystem zu einem anderen Rechensystem und mit einer Registerdatenbank innerhalb der DCE; ein rechnernutzbares Codemittel zum Einrichten eines zweiten Kommunikations-Server für ein lokales Netzwerk (LAN) von Rechensystemen, die aus einer Vielzahl von Rechensystemen in der DCE ausgewählt worden sind; ein rechnernutzbares Codemittel zum Einrichten einer Synchronisationsbibliothek des LAN-Server; ein rechnernutzbares Codemittel zum Feststellen, ob Registerveränderungen in der Registerdatenbank mindestens eine aus der Vielzahl der lokalen Datenbanken innerhalb des LAN betreffen; ein rechnernutzbares Codemittel zum Aufrufen der Synchronisationsbibliothek des LAN-Server, um die betroffene Datenbank zu synchronisieren.
Nach einem sechsten Aspekt der Erfindung wird ein Rechner-Programmprodukt zum Synchronisieren einer verteilten Rechenumgebung (DCE) bereitgestellt, das Folgendes umfasst: ein rechnernutzbares Codemittel zum Einrichten einer Registerdatenbank, die mit jeder aus der Vielzahl von lokalen Datenbanken innerhalb jedes Rechensystems in der DCE verbunden ist; ein rechnernutzbares Codemittel zum Einrichten einer ersten Datenbankbereichskopie, die jede lokale Datenbank innerhalb der DCE mit der Registerdatenbank synchronisiert; und ein rechnernutzbares Codemittel zum Einrichten einer zweiten Datenbankbereichskopie, die mindestens einen Server eines lokales Netzwerkes (LAN), der ausgewählte aus der Vielzahl von Rechensystemen und ihre jeweiligen Datenbanken umfasst, mit der Registerdatenbank synchronisiert.
Ein veranschaulichende Ausführungsform der Erfindung wird nun unter Bezugnahme auf die zugehörigen Zeichnungen dargelegt, in denen:
1 eine Übersichtsdarstellung eines DCE-Sicherheitsserver nach Stand der Technik ist;
2 eine bildliche Darstellung eines verteilten Datenverarbeitungssystems nach der vorliegenden Erfindung ist;
3 eine Übersichtsdarstellung der DCE-Zelle mit einem Sicherheitsserver nach der vorliegenden Erfindung ist;
4 ein Flussbild der Initialisierung des Synchronisierserver beschreibt;
5 ein Flussbild ist, das die Registersynchronisation nach einem Ruf zur Registeraktualisierung beschreibt; und
6 eine Übersichtsdarstellung einer Datenbankbereichshauptkopie nach 3 ist.
Unter Bezugnahme auf die Figuren und insbesondere unter Bezugnahme auf 2 wird hier nun eine bildliche Darstellung eines verteilten Datenverarbeitungssystems 8 oder einer verteilten Rechenumgebung (DCE) beschrieben, die dafür benutzt werden kann, das Verfahren und System der vorliegenden Erfindung zu realisieren. Wie zu sehen ist, kann das verteilte Datenverarbeitungssystem 8 eine Vielzahl von Netzwerken wie etwa die lokalen Netzwerke (LAN) 10 und 32 enthalten, von denen jedes vorzugsweise eine Vielzahl von einzelnen Rechnern 12 beziehungsweise 30 enthält. Natürlich ist dem Fachmann klar, dass eine Vielzahl von intelligenten Arbeitsplatzrechner (IWS), die mit einem Hostprozessor verbunden sind, für jedes derartige Netzwerk benutzt werden kann.
Wie in derartigen Datenverarbeitungssystemen üblich kann jeder einzelne Rechner mit einer Speichereinheit 14 und/oder einem Drucker/einer Ausgabeeinheit 16 verbunden sein. Eine oder mehrere derartige Speichereinheiten 14 können nach dem Verfahren der vorliegenden Erfindung dafür benutzt werden, die verschiedenen Datenobjekte oder Dokumente zu speichern, auf die von einem Benutzer innerhalb des verteilten Datenverarbeitungssystems 8 nach dem Verfahren und System der vorliegenden Erfindung periodisch zugegriffen wird und die periodisch von ihm verarbeitet werden. Auf eine dem Fachmann bestens bekannte Weise kann jeder derartige Verarbeitungsvorgang oder jedes Dokument innerhalb einer Speichereinheit 14 gespeichert werden, die mit einem Betriebsmittelverwalter oder Bibliotheksdienst verbunden ist, der für das Pflegen und Aktualisieren aller zugehörigen Betriebsmittelobjekte verantwortlich ist.
Noch unter Bezugnahme auf 2 ist zu erkennen, dass das verteilte Datenverarbeitungssystem 8 auch mehrere Hauptrechner wie etwa den Hauptrechner 18 enthalten kann, der vorzugsweise mit Hilfe der Übertragungsverbindung 22 mit dem lokalen Netzwerk (LAN) 10 verbunden ist. Der Hauptrechner 18 kann auch mit einer Speichereinheit 20 verbunden sein, die als Fernspeicher für das lokale Netzwerk (LAN) 10 dienen kann. Ein zweites lokales Netzwerk (LAN) 32 kann mit dem lokalen Netzwerk (LAN) 10 über die Übertragungssteuerung 26 und die Übertragungsverbindung 34 mit einem Netzverbindungsserver 28 verbunden sein. Der Netzverbindungsserver 28 ist vorzugsweise ein Einzelrechner oder ein intelligenter Arbeitsplatzrechner (IWS), der dazu dient, das lokale Netzwerk (LAN) 32 mit dem lokalen Netzwerk (LAN) 10 zu verbinden.
Wie vorstehend im Hinblick auf das lokale Netzwerk (LAN) 32 und das lokale Netzwerk (LAN) 10 erörtert wurde, kann eine Vielzahl von Datenverarbeitungsvorgängen oder Dokumenten innerhalb der Speichereinheit 20 gespeichert und durch Hauptrechner 18 gesteuert werden, der Betriebsmittelverwalter oder Bibliotheksdienst für die so gespeicherten Datenverarbeitungsvorgänge und Dokumente ist.
Natürlich ist dem Fachmann klar, dass der Hauptrechner 18 sich in einer großen geografischen Entfernung zum lokalen Netzwerk (LAN) 10 befinden kann und dass gleichermaßen das lokale Netzwerk (LAN) 10 mit einer beträchtlichen Entfernung zum lokalen Netzwerk (LAN) 32 angeordnet sein kann. Das heißt, das lokale Netzwerk (LAN) 32 kann sich in Kalifornien befinden, während das lokale Netzwerk (LAN) 10 in Texas liegt und sich der Hauptrechner 18 in New York befindet.
Wie unter Bezugnahme auf das Vorstehende verständlich ist, ist es für Benutzer innerhalb eines Teilbereiches des verteilten Datenverarbeitungsnetzwerkes 8 oftmals wünschenswert, auf ein Datenobjekt oder Dokument zuzugreifen, das in einem anderen Teilbereich des Datenverarbeitungsnetzwerkes 8 gespeichert ist. Um den Anschein einer Reihenfolge innerhalb der im Datenverarbeitungsnetzwerk 8 gespeicherten Dokumente aufrechtzuerhalten, ist es oft wünschenswert, ein einseitiges Zugriffssteuerprogramm einzurichten. Dies wird im Allgemeinen dadurch bewerkstelligt, dass diejenigen Benutzer aufgelistet werden, die gemäß der Berechtigungsstufe, die jeder Benutzer im Hinblick auf ein Dokument innerhalb eines Betriebsmittelverwalters oder Bibliotheksdienstes besitzen darf, zum Zugriff auf jedes einzelne Datenobjekt oder Dokument berechtigt sind. Auf diese Weise kann von eingetragenen Benutzern innerhalb des verteilten Datenverarbeitungssystems 8 auf die Datenverarbeitungsvorgänge und Dokumente zugegriffen werden und diese können periodisch „verriegelt" werden, um den Zugriff durch andere Benutzer zu verhindern. Es ist der Systemadministrator, der üblicherweise den Zugriff steuert und aus Sicherheitsgründen Veränderungen vornimmt. Aus genau diesem Grund besteht ein Bedarf nach einem verbesserten DCE-Server, der Fähigkeiten als LAN-Server hat, so dass er in der Lage ist, die Synchronisation von Datenregistern und die Folgerichtigkeit aufrechtzuerhalten.
Die DCE von 2 enthält weiterhin einen Sicherheitsserver. Ein Beispiel einer Anordnung eines Sicherheitsserver wird in der Darstellung der 3 veranschaulicht. Der Sicherheitsserver 40 pflegt im virtuellen Speicher 42 eine Arbeitskopie der Registerdatenbank und auf der Festplatte 44 eine dauerhafte Kopie. Alle diese Aktualisierungen werden an der gleichen Kopie vorgenommen, die sich im virtuellen Speicher befindet. Der Server benutzt die Kopie, die sich auf der Platte befindet, um dann, wenn der Server hochläuft, die Kopie im virtuellen Speicher zu initialisieren. Ein geschlossenes Aktualisierungsprotokoll wird dafür benutzt, im Falle eines Versagens des Server den Status der Datenbank zu aufrecht zu erhalten. Der Sicherheitsserver sichert periodisch seine gesamte Datenbank vom virtuellen Speicher auf einer Festplatte.
Die Registerdatenbank kann innerhalb ihrer Zelle bereichsweise kopiert werden. Jede Instanz eines Sicherheitsserver in einer Zelle pflegt eine Arbeitskopie der Datenbank. Die Kombination eines Sicherheitsserver und seiner Registerdatenbank wird als Datenbankbereichskopie bezeichnet. Innerhalb einer Zelle gibt es eine erste Datenbankbereichskopie, die nur Lesevorgänge von Clients akzeptiert, und mehrere zweite Datenbankbereichskopien, die nur Lesevorgänge von Clients akzeptieren.
In DCE-Sicherheitsserversystemen könnte an einer bestimmten Maschine innerhalb einer DCE-Zelle nur eine Datenbankbereichskopie gepflegt werden. In einer früheren Version des LAN-Server mit eingeschränkten Fähigkeiten als DCE-Server registriert sich der RSP zu dem Zwecke selbst als zweite Datenbankbereichskopie, damit er von der ersten Datenbankbereichskopie rechtzeitige Aktualisierungen empfängt. Da der DCE-Sicherheitsaufbau es nicht zulässt, dass mehr als eine Datenbankbereichskopie auf der gleichen Maschine läuft, kann die derzeitige Version des RSP nicht an einer Maschine laufen, an der zu dem Zeitpunkt eine erste oder eine zweite Datenbankbereichkopie installiert ist. Das Folgende erklärt, warum zwei Sicherheits-Datenbankbereichskopien nicht an derselben Maschine laufen können.
Die erste und die zweite Datenbankbereichkopie registrieren die gleiche Gruppe von Schnittstellen. Wenn zwischen der ersten und der zweiten Datenbankbereichskopie ein entfernter Vorgangsaufruf (RPC) vorgenommen wird, wird sowohl für die erste als auch für die zweite Datenbankbereichskopie die gleiche universelle eindeutige Objekt-Kennung (UUID) oder die gleiche im Aufbau definierte Sicherheitsserver-UIID benutzt, um sie der RPC-Kennung zuzuordnen. Die erste Datenbankbereichskopie erzeugt diese Objekt-UUID und all die zweiten Datenbankbereichskopien erhalten die Objekt-UUID von der ersten Datenbankbereichskopie. Es wird angenommen, dass die zweite Datenbankbereichskopie den RPC-Ruf „rpc_ep_register_no_replace()" benutzt, um ihre Schnittstellen zu registrieren, so dass er den Eintrag des Endpunktabbildes nicht ersetzt, der von der ersten Datenbankbereichskopie für die gleiche Schnittstelle erzeugt worden ist. Wenn die erste und die zweite Datenbankbereichskopie auf der gleichen Maschine laufen und die erste Datenbankbereichskopie bei der zweiten Datenbankbereichskopie einen RPC-Ruf vornimmt, löst die lokale Endpunkt-Abbildungseinheit die RPC-Bindung zur RPC-Routine der ersten und nicht der zweiten Datenbankbereichskopie. Dieses Problem tritt auf, weil die Schnittstellen-ID, die Objekt-UIID und die Netzwerkadresse für die beiden Einträge identisch sind. Das Folgende ist ein Beispiel der beiden Einträge, die im Endpunktabbild für die gleiche Schnittstelle vorhanden sind, die von der ersten und der zweiten Datenbankbereichskopie registriert worden sind, die auf der gleichen Maschine laufen:
(von der ersten Datenbankbereichskopie registrierte Schnittstelle)
<object> 53a7c2c0-3149-11ce-bc2f=10005a8d1971
<interface id> 4c878280-5000-0000-0d00-028714000000,1.0
<string binding>ncacn_ip_tcp:129.35.68.105∧[2254]
<annotation> DCE-Benutzerregister
(von der zweiten Datenbankbereichskopie registrierte Schnittstelle)
<object> 53a7c2c0-3149-11cd-bc2f=10005a8d1971
<interface id> 4c878280-5000-0000-0d00-028714000000,1.0
<string binding>ncacn_ip_tcp:129.35.68.105[2307]
<annotation> DCE-Benutzerregister
Der Zellensicherheits-ID „53a7c2c0-3149-11ce-bc2f-10005a8d1971" ist die Objekt-UIID, die von beiden Schnittstellen benutzt wird.
Um dieses Problem zu überwinden, stellt eine Hintergrundroutine eines DCE-Sicherheitsserver (secd.exe) eine Ruffunktion zur Unterstützung der Funktion der Registersynchronisation bereit, die vom LAN-Server 62 gefordert wird. Die Registersynchronisier-DLL 60 sorgt für die Rufe, wie sie vom LAN-Serverunternehmen gefordert werden. Der DCE-Sicherheitsserver 58 enthält Rufe an die Registersynchronisier-DLL 60, die den Benutzer des LAN-Server und Gruppendatenbank 66 mit dem DCE-Register 44 synchron hält. Diese Rufe oder Anwendungsprogrammierschnittstellen (APIs) werden in einer getrennten dynamisch verknüpften Bibliothek (DLL) aufgebaut. Der DCE-Sicherheitsserver 58 ruft diese APIs nur dann, wenn die Registersynchronisier-DLL 60 installiert ist und wenn die Registersynchronisierung aktiviert ist.
Die Ruffunktion führt eine Prüfung auf Vorhandensein einer Registersynchronisier-DLL 60 des LAN-Server durch. Wenn eine gefunden wird, werden Eintragspunkte oder Rufe für jede Art der Registeränderung aufgerufen. Wenn die Registeränderung einen LAN-Serverbenutzer oder eine -benutzergruppe betrifft, wird die Registeraktualisierung mit der Datenbank des lokalen LAN-Server (LS) 66 synchronisiert. Der gleiche Sicherheitsserver kann entweder in einer gleichförmigen DCE-Umgebung oder ebenso in einer LS-Umgebung installiert werden.
3 veranschaulicht weiterhin eine Übersichtsdarstellung eines oder zweier Rechnersysteme innerhalb einer DCE-Zelle 50. Das Rechnersystem 52 ist der DCE-Sicherheitsserver, der Fähigkeiten zur Registersynchronisierung hat, während Rechnersystem 54 eine Domänensteuerung eines LAN-Serverunternehmens (LS E) ist, auf der ein LS-Synchronisations-Client oder LS-Sync-Client 56 installiert ist.
Das System 52 enthält den DCE-Sicherheitsserver 58, die Registersynchronisier-DLL 60 und den LS-Synchronisierserver oder LS-Sync-Server 62. Das System 54 enthält weiterhin die LS-Datenbank-Dateien 66. Bei der DCE-Zelle 50 kann das System 52 auch als LS-E-Domänensteuerung arbeiten, indem der LS-Synchronisier-Client 56 in das System 52 eingeschlossen und mit dem LS-Synchronisierserver 62 verbunden wird.
Der Sicherheitsserver 58 überprüft das Vorhandensein einer DLL zur LS-Registersynchronisation 60. Wenn er eine findet, werden für jede Art von Registeränderungen Eintragspunkte aufgerufen. Wenn die Registeraktualisierung einen gültigen Namen eines LAN-Server oder Informationen des LAN-Servermodells betrifft, wird sie über eine gemeinsam genutzte Warteschlange 68 an eine andere Verarbeitung weitergeleitet, die ein weiterer LS-Sync-Server ist. Die Verarbeitung am LS-Sync-Server 62 überträgt unter Verwendung der RPC-Leitung 46 Aktualisierungen an alle Domänensteuerungen (oder LS-Sync-Clients 56), die am LS-Sync-Server 62 registriert sind. Der LS-Sync-Server 62 benutzt berechtigte RPCs, um an die LS-Sync-Clients 56 auf der Aktualisierungs-RPC-Leitung 48 Aktualisierungen zu übertragen.
In einer einzelnen Zelle können ein oder mehrere LS-Sync-Server 62 installiert sein, und eine beliebige Anzahl von LS-Domänensteuerungen, üblicherweise eine für jedes System innerhalb der DCE 8 von 2, kann an einem einzelnen LS-Sync-Servervorgang registriert sein, um Aktualisierungen zu LS-Benutzer-/-Benutzergruppeninformationen im Register 44 zu empfangen.
Der DCE-Sicherheitsserver 58, der sowohl als erste als auch als zweite Datenbankbereichskopie installiert sein kann, führt Rufe zur Synchronisations-DLL des LS-Registers durch, diese filtert Aktualisierungen, die auf gültigen LS-Namen beruhen, und reiht die Aktualisierungen für die Verarbeitung am LS-Synchronisierserver 62 in eine Warteschlange ein. Die Registersynchronisations-DLL 60 und die LS-Synchronisierserververarbeitung 62 müssen an der gleichen Maschine wie der DCE-Sicherheitsserver 58 installiert sein.
Der LS-Synchronisierserver 62, der von der Registersynchronisations-DLL Benachrichtigungen über Ereignisse entgegennimmt, verwaltet Übertragungen an die Domänensteuerungen der Clients. Der LS-Synchronisierserver 62 kann auf jeglicher Art von LS-Systemrechner installiert werden, ob er nun mit LS-Aufrufen arbeitet oder ein LS-Server ist. Der LS-Synchronisierserver 62 pflegt im Register eine Liste von LS-Clients, denen es gestattet ist, sich bei ihm zu registrieren.
Der LS-Synchronisier-Client 56 oder der „lsesync"-Dienst empfängt über RPC-Rufe Benachrichtigungen vom Synchronisierserver 62 und benutzt zum Aktualisieren der lokalen Datenbank 66 LS-API-Rufe. Wenn dieser Vorgang das erste Mal beginnt, ruft er vom Register alle zu seiner Domäne gehörenden Benutzer- und Gruppeninformationen ab und synchronisiert die lokale Datenbank 66. Wahlweise kann er auch beim Neustart eine volle Synchronisation durchführen. Der LS-Synchronisier-Client 56 muss in einer LS-Domänensteuerung 54 installiert sein. Diese kann auf dem gleichen System 52 installiert sein, in dem der LS-Synchronisierserver 62 installiert ist. Der LS-Synchronisier-Client 56 ist ein LAN-Serverdienst, der, wenn er zum Installieren konfiguriert ist, automatisch mit dem Anforderungsdienst gestartet wird. Wenn der Anforderungsdienst beendet wird, endet der „lsesync"-Dienst ebenfalls.
Damit der „lsesync"-Dienst eine LAN-Server-Datenbank aktualisieren kann, muss zumindest ein LAN-Server-Anforderungsdienst gestartet werden. Wenn es sich bei der Domänensteuerung des Unternehmens um einen technisch aktuellen Server handelt, z.B. ein Server 386 für Hochleistungsdateisysteme (HPFS), und die lokale Sicherheit installiert ist, startet der „lsesync"-Dienst als bevorrechtigtes Programm, indem er den Dienst von einer bevorzugten Befehlsdatei aufruft.
Der Sicherheitsserver 58 benutzt für die gleiche Art von Registeraktualisierung zwei unterschiedliche RPC-Schnittstellenvorgänge. Ein RPC-Vorgang wird aufgerufen, wenn der Sicherheitsserver als erste Datenbankbereichskopie läuft, und der andere wird aufgerufen, wenn der Sicherheitsserver als zweite Datenbankbereichskopie läuft. Sobald der Sicherheitsserver das System initialisiert hat, ist es verfügbar, um Aktualisierungen zum Register anzunehmen.
Wenn die Sicherheitsserver-Hintergrundroutine wie im Flussbild von 4 gezeigt gestartet wird, überprüft das System im Betrieb zum Zeitpunkt der Initialisierung, ob die Synchronisations-DLL des Registers auf der lokalen Maschine (Block 410) installiert worden ist. Wenn dies der Fall ist und wenn die Registersynchronisierung aktiviert ist (Block 416), wird in Block 424 eine globale Markierung gesetzt, mit der angezeigt wird, dass die Datenbank des LAN-Server synchronisiert werden muss; andernfalls ruft das System die Ruf-APIs nicht auf, die von der Registersynchronisations-DLL der (Block 414) bereitgestellt werden.
Wenn die LS-Datenbank synchronisiert werden muss, lädt der Sicherheitsserver die DLL, welche die Rufroutinen (Block 418) enthält. Andernfalls wird in Block 420 keine Synchronisierung durchgeführt. Um zu vermeiden, eine API zu rufen, welche die Adresse einer Rufroutine immer dann aufruft, wenn eine Aktualisierung erfolgt, wird in Block 422 eine Tabelle aller Rufroutinen initialisiert. Der Server setzt dann in Block 424 die globale Markierung.
Wenn das Synchronisieren des Registers erforderlich ist, ruft der Sicherheitsserver 58 (SECD) zur LS-Initialisierung die anfängliche Ruf-API während der Initialisierung des DCE-Sicherheitsserver 58 zur LS-Initialisierung auf. Die Initialisier-API des LS beginnt den Synchronisierservervorgang als Hintergrundvorgang und erzeugt zum Datenaustausch mit dem LS-Synchronisierserver gemeinsam genutzte Speicherobjekte. Die Ruf-APIs fügen zur gemeinsam genutzten Aktualisierungswarteschlange Aktualisierungen hinzu, und die Aktualisierungsübertragungs-Task des LS-Synchronisierservervorganges liest Aktualisierungen aus der Übertragungswarteschlange und überträgt sie an die LS-Synchronisier-Clients. Sobald der Synchronisierservervorgang begonnen hat, wird er erst beendet, wenn der DCE-Sicherheitsserver geschlossen wird. Wenn der DCE-Sicherheitsserver seinen Betrieb beendet, ruft er eine Löschruf-API auf, den Synchronisierdienstvorgang zu beenden.
5 veranschaulicht in einem Flussbild, wie das lokale DCE-Register synchronisiert wird, wenn eine Benutzeranwendung eine DCE-Sicherheits-API ruft, um das Register zu aktualisieren. In Block 510 ruft die Benutzeranwendung die DCE-Sicherheits-API. Als Nächstes aktualisiert in Block 512 die API die Registerdatenbank. In Block 514 ermittelt das System, ob das Synchronisieren des Registers erforderlich ist, und wenn dies nicht der Fall ist, springt es in Block 516 zurück, um den nächsten Sicherheitsvorgang zu überwachen. Andernfalls, wenn in Block 518 die Aktualisierung einen gültigen LAN-Serverbenutzer- oder -gruppennamen betrifft, wird in Block 520 der passende Aktualisierungsruf aufgerufen, der die Aktualisierung für den LS-Synchronisierserver in die Warteschlange einreiht.
Wenn der DCE-Sicherheitsserver 58 als erste Datenbankbereichskopie läuft, beginnt das erste Registerobjekt, das der „Rest"-Datenbank hinzugefügt wird, mit der Reihenfolgenummer „100". Die Reihenfolgenummer der nächsten Registeraktualisierung ist um eins größer als die vorhergehende Aktualisierung. Eine 64-Bit-Zahl wird für die Speicherung der Reihenfolgenummer benutzt. Eine Registeraktualisierung ist der ersten Datenbankbereichskopie und allen deren zweiten Datenbankbereichskopien mit der gleichen Reihenfolgenummer bekannt.
Wenn der DCE-Sicherheitsservervorgang angehalten ist, wird die Reihenfolgenummer der letzten Aktualisierung in einer Aktualisierungs-Protokolldatei gesichert, die vom DCE-Sicherheitsserver aufrechterhalten wird. Diese Reihenfolgenummer wird verwendet, wenn der DCE-Sicherheitsserver erneut gestartet wird. Wenn beispielsweise eine Reihenfolgenummer von „971" die Reihenfolgenummer der letzten Aktualisierung war, als der Sicherheitsserver angehalten worden ist, wird die Reihenfolgenummer der ersten Aktualisierung nach dem erneuten Start des Sicherheitsserver „972" sein.
Wenn der Sicherheitsserver 58 ausgewählt worden ist, um als zweite Datenbankbereichskopie zu laufen, empfängt er, wenn er das erste Mal nach dem Installieren gestartet wird, das vollständige Register. Das vollständige Register wird von der ersten Datenbankbereichskopie als eine Reihe von Registeraktualisierungen empfangen. Die erste Aktualisierung dieser Übertragung von der ersten Datenbankbereichskopie hat eine Reihenfolgenummer 100. Die Reihenfolgenummer der ersten Aktualisierung, welche die zweite Datenbankbereichskopie nach der Übertragung empfängt, ist um eins größer als die Reihenfolgenummer der letzten Registeraktualisierung der Haupt- oder ersten Datenbankbereichskopie vor Beginn der Übertragung. Wenn beispielsweise die Reihenfolge der Hauptkopie der letzten Registeraktualisierung bei Beginn der Übertragung an eine zweite Datenbankbereichskopie „2578" war, dann wird die erste Aktualisierung, welche die zweite Datenbankbereichskopie nach der Übertragung empfangen wird, „2579" sein.
Wenn eine zweite Datenbankbereichskopie angehalten und erneut gestartet worden ist, wird in den meisten Fällen die erste Datenbankbereichskopie die Übertragung an die zweite Datenbankbereichskopie so wieder aufnehmen, dass sie von der nächsten Aktualisierung nach der letzten Aktualisierung aus beginnt, die vor ihrem Anhalten von der zweiten Datenbankbereichskopie empfangen worden ist. Wenn die erste Datenbankbereichskopie nicht alle Aktualisierungen besitzt, die eine zweite Datenbankbereichskopie benötigt, übermittelt sie der zweiten Datenbankbereichskopie, dass sie sich selbst „erneut initialisiert". Diese erneute Initialisierung veranlasst die Haupt-Datenbankbereichskopie, ihre vollständige Datenbank in einer Massenübertragung an die zweite Datenbankbereichskopie zu senden.
Die zweite Datenbankbereichskopie kann nach ihrem Anhalten oder während ihres Betriebes erneut initialisiert werden. Wenn eine zweite Datenbankbereichskopie erneut initialisiert wird, sendet die Hauptkopie ihre vollständige Datenbank, und zwar beginnend mit der Reihenfolgenummer 100.
Die Registersynchronisations-DLL 60 sorgt für die Rufe an den Sicherheitsserver 58, um mit dem LS-Synchronisierserver 62 einen Datenaustausch vorzunehmen. Wenn eine Registeränderung einen Benutzer, eine Gruppe oder eine Registerverfahrensweise eines LAN-Server betrifft, ruft der Sicherheitsserver 58 diese Rufe auf, falls eine Registersynchronisierung erforderlich ist. Die LS-Synchronisations-DLL 60 bewahrt ihren Zustand in einer globalen Variablen und besitzt die folgenden Zustände: Registersynchronisierung aktiv: Wenn sich die LS-Synchronisations-DLL 60 in diesem Zustand befindet, fügen die Ruf-APIs der Protokolldatei Aktualisierungen hinzu und aktualisieren die Warteschlange.
Initialisierung der Registersynchronisierung: Die Registersynchronisations-DLL 60 ist in diesem Zustand, wenn sich der Sicherheitsserver, der als zweite Datenbankbereichskopie läuft, innerhalb eines Empfangsvorganges der „Massen"-Datenübertragung von Aktualisierungen von der ersten Datenbankbereichskopie befindet. Wenn dieser Zustand vorhanden ist, verarbeiten die Rufe keine Aktualisierungen, d.h. alle „Massen"-Übertragungsaktualisierungen werden von den Rufen der Registersynchronisations-DLL ignoriert.
Registersynchronisations-DLL 60 hält in einer Aktualisierungs-Protokalldatei, auch als Registeraktualisierungs-Protokolldatei 61 bekannt, eine dauerhafte Kopie aller gültigen LAN-Serveraktualisierungen aufrecht, die sie vom Sicherheitsserver 58 empfängt. Jede Aktualisierung des LAN-Server wird zuerst in der Protokolldatei aufgezeichnet, ehe sie der Aktualisierungswarteschlange 69 hinzugefügt wird. Wenn der Sicherheitsserver 58 seinen Betrieb einstellt, ohne alle Aktualisierungen in der Aktualisierungswarteschlange zu übertragen, wird die Protokolldatei dafür genutzt, die Aktualisierungswarteschlange aufzubauen, wenn der Sicherheitsserver 58 erneut gestartet wird. Eine aktive Bestimmungs-Task für den Synchronisierserver synchronisiert periodisch die Aktualisierungswarteschlange mit der Aktualisierungs-Protokolldatei, und sie löscht alle Aktualisierungen, die in der Aktualisierungswarteschlange nicht vorhanden sind, aus der Protokolldatei. Das Format der Aktualisierungs-Protokolldatei ist das gleiche wie das Format der Protokolldatei des DCE-Sicherheitsserver.
Anfänglich wird die Aktualisierungs-Protokolldatei durch den Ruf der LS-Initialisierung erzeugt. Die APIs für die Aktualisierungsrufe fügen der Protokolldatei Aktualisierungen hinzu, und die aktive Bestimmungs-Task zur Serversynchronisierung synchronisiert die Protokolldatei periodisch mit der Aktualisierungswarteschlange. Der LS-Synchronisierserver 62 hat keine Kenntnis der Aktualisierungs-Protokolldatei.
Die folgenden Rufe werden von der Registersynchronisations-DLL bereitgestellt:
Vom Sicherheitsserver 58 wird während der Initialisierung des Sicherheitsserver 58 der LS-Initialisierruf gerufen, er ist vorstehend beschrieben worden und wird auch nachstehend ausführlicher dargelegt.
Der Löschruf wird gerufen, wenn der Sicherheitsserver 58 seinen Betrieb beendet.
Die LS-Drucknachricht wird vom Sicherheitsserver 58 gerufen, damit die Registersynchronisations-DLL 60 ihre eigene Nachricht anzeigen kann.
Der Ruf zur PGO-Hinzufügung wird vom Sicherheitsserver 58 gerufen, wenn zum lokalen Register ein neuer Auftraggeber, eine neue Gruppe oder Organisation hinzugefügt wird.
Der LS-Ruf zum PGO-Löschen wird vom Sicherheitsserver 58 gerufen, wenn ein Auftraggeber, eine Gruppe oder Organisation aus dem lokalen Register gelöscht wird.
Der LS-Ruf zum PGO-Ersatz wird vom Sicherheitsserver gerufen, wenn ein Auftraggeber, eine Gruppe oder Organisation im lokalen Register geändert wird.
Der LS-Ruf zur PGO-Umbenennung wird vom Sicherheitsserver 58 gerufen, wenn ein Auftraggeber, eine Gruppe oder Organisation im lokalen Register umbenannt wird.
Der LS-Ruf zum Hinzufügen eines PGO-Gliedes wird vom Sicherheitsserver 58 gerufen, wenn einer Gruppe oder Organisation im lokalen Register ein Auftraggeber hinzugefügt wird.
Ein LS-Ruf zum Löschen eines PGO-Gliedes wird vom Sicherheitsserver 58 gerufen, wenn aus einer Gruppe oder Organisation im lokalen Register ein Auftraggeber gelöscht wird.
Ein LS-Ruf zum Hinzufügen eines Account wird vom Sicherheitsserver 58 gerufen, wenn im lokalen Register ein neuer Account geschaffen wird.
Ein LS-Ruf zum Löschen eines Account wird vom Sicherheitsserver 58 gerufen, wenn ein vorhandener Account aus dem lokalen Register gelöscht wird.
Ein LS-Ruf zum Ersetzen eines Account wird vom Sicherheitsserver 58 gerufen, wenn ein vorhandener Account im lokalen Register verändert wird.
Ein LS-Ruf zum Umbenennen eines Account wird vom Sicherheitsserver 58 gerufen, wenn ein vorhandener Account im lokalen Register umbenannt wird.
Ein LS-Ruf zur Attributaktualisierung wird vom Sicherheitsserver 58 gerufen, wenn ein erweitertes Registerattribut (ERA) im lokalen Register aktualisiert wird.
Ein LS-Ruf zur Aktualisierung einer Verfahrensweise wird vom Sicherheitsserver gerufen, wenn die Verfahrensweise des Registers als Ganzes im lokalen Register aktualisiert wird.
Ein LS-Ruf zum Beginn der erneuten Initialisierung wird vom Sicherheitsserver 58 am Beginn der „Massen"-Übertragung vom ersten Sicherheitsserver gerufen.
Ein LS-Ruf zum Ende der erneuten Initialisierung wird vom Sicherheitsserver 58 am Ende der „Massen"-Übertragung vom ersten Sicherheitsserver gerufen.
Die aktive Bestimmungstask für den Synchronisierserver wird durch die API des LS-Initialisierungsrufes nach dem erfolgreichen Starten des LS-Synchronisierserver 58 erzeugt. Diese Task wird erzeugt, um den Synchronisierserver 62 zu überwachen und ihn erneut zu starten, wenn er seinen Betrieb nicht planmäßig beendet. Normalerweise beendet der Synchronisierserver 62 seinen Betrieb durch den LS-Löschruf dann, wenn der Sicherheitsserver 58 seinen Betrieb beendet. Diese Task synchronisiert auch die Warteschlange 69 mit der Protokolldatei der Aktualisierungen 61. Der LS-Synchronisierserver 62 stellt sicher, dass Aktualisierungen, die erfolgreich an alle LS-Clients übertragen worden sind, aus der Protokolldatei der Aktualisierungen gelöscht werden.
Der LS-Synchronisierserver 62 empfängt vom Sicherheitsserver 58 über die Ruf-APIs Aktualisierungen und übermittelt die Aktualisierungen an die Liste der LS-Synchronisierclients, die bei ihm registriert sind. LS-Synchronisierserver 62 wird durch die API des LS-Initialisierrufes gestartet, wenn der Sicherheitsserver 58 startet, und er endet normalerweise, wenn der Sicherheitsserver 58 seinen Betrieb einstellt. Der LS-Synchronisierserver 62 läuft als Auftraggeber des Registers, er hat den Hauptrechnernamen des Rechnersystems 52, an dem LS-Synchronisierserver 62 läuft.
Ein mehrwertiges ERA, das die Liste der LS-Clients enthält, die sich am LS-Synchronisierserver 62 registrieren lassen dürfen, ist am Auftraggeber des LS-Synchronisierserver angehängt. Der LS-Synchronisierserver 62 hält eine flüchtige (im Speicher) und eine dauerhafte (auf der Festplatte) Liste der Clients für die Registersynchronisierung aufrecht, an die Aktualisierungen übertragen werden. Es wird dieser Liste immer dann ein Client-Eintrag hinzugefügt, wenn ein LS-Client am Synchronisierserver erfolgreich registriert worden ist. Er hält auch eine dauerhafte Protokolldatei der Aktualisierungen aufrecht, die übertragen werden müssen, wenn der LS-Synchronisierserver 62 erneut gestartet wird. Wenn der Synchronisierserver 62 seinen Dienst normal einstellt, enthält er die Protokolldatei Aktualisierungen, die nicht an alle LS-Clients erfolgreich übertragen worden sind. Der LS-Synchronisierserver 62 benutzt berechtigte RPCs, um Aktualisierungen an die LS-Synchronisierclients zu übertragen.
Wenn LS-Synchronisierserver 62 erneut gestartet wird oder wenn der Sicherheitsserver 58 neu gestartet wird, baut der LS-Synchronisierserver 62 aus der dauerhaften Liste die flüchtige Liste der LS-Synchronisierclients auf. Aus der dauerhaften Protokolldatei baut er auch die Warteschlange auf. Wenn die Liste der Clients beim erneuten Starten nicht leer ist, sendet der LS-Synchronisierserver 62 eine „Neuverbindungs"-RPC an alle Clients. Der Synchronisierservervorgang unterstützt keine „Massen"-Übertragung (Übertragung der gesamten Registerdatenbank) an die LS-Synchronisierclients, wenn er von einer zweiten Datenbankbereichskopie gesteuert wird. Die LS-Synchronisierclients sind für die anfängliche Synchronisation verantwortlich, ehe sie sich am Synchronisierservervorgang registrieren lassen.
Die Registersynchronisations-DLL 60 und der Synchronisierserver 62 nutzen bestimmte Speicherobjekte gemeinsam. Das erste Speicherobjekt ist die Aktualisierungswarteschlange. Die API für den LS-Initialisierungsruf erzeugt die gemeinsam genutzte Aktualisierungswarteschlange, die Registeraktualisierungen enthält, die an LS-Clients übertragen werden müssen. Die Aktualisierungswarteschlange ist eine „verknüpfte Liste", bei der jeder Eintrag eine bestimmte Art von Registeraktualisierung enthält.
Die API für den LS-Initialisierungsruf erzeugt für die Aktualisierungswarteschlange einen großen Block eines „neutralen" gemeinsam genutzten Speichers. Es wird Speicher zugeordnet und dynamisch festgelegt, wenn der Aktualisierungswarteschlange eine neue Aktualisierung hinzugefügt wird. Es wird dann Speicher freigegeben, wenn aus der Aktualisierungswarteschlange eine Aktualisierung gelöscht wird. Wenn die Protokolldatei der Aktualisierungen nicht vorhanden ist oder wenn sie leer ist, wird der Aktualisierungswarteschlange eine fiktive Aktualisierung mit der Reihenfolgenummer „100" zugefügt. Wenn die Protokolldatei für die Aktualisierungen nicht leer ist, liest die API für den LS-Initialisierungsruf die Aktualisierungen aus der Protokolldatei und fügt sie der Aktualisierungswarteschlange hinzu.
Die Aktualisierungsruf-APIs fügen der Aktualisierungswarteschlange Aktualisierungen hinzu, wenn der Zustand der Registersynchronisations-DLL aktiv ist (Registersynchronisierung in Betrieb) und wenn es in der Clientliste mindestens einen LS-Client gibt.
Der LS-Synchronisierserver 62 überträgt Aktualisierungen und löscht periodisch Aktualisierungen aus der Aktualisierungswarteschlange, die an alle LS-Clients erfolgreich übertragen worden sind.
Wenn die zweite Datenbankbereichskopie, die den Synchronisierserver steuert, erneut initialisiert wird, löscht die API für den Beginn des LS-Initialisierungsrufes alle Einträge aus der Aktualisierungswarteschlange und fügt die „fiktive" leere Aktualisierung der leeren Warteschlange hinzu.
Mit Ausnahme dieser erneuten Initialisierung durch den Ruf für den Beginn der erneuten LS-Initialisierung werden die Aktualisierungen in der Warteschlange nur durch die Auffrischungs-Task für die Warteschlange gelöscht.
Die Adresse am Beginn der Aktualisierungswarteschlange, die im gemeinsam genutzten Zustandsblock gespeichert ist, wird anfänglich durch die API für den LS-Initialisierungsruf eingerichtet. Die Adresse für den Übertragungsbeginn wird nur von der Auffrischungs-Task für die Warteschlange und die API für den Beginn des erneuten LS-Initialisierungsruf verändert.
Die Adresse der letzten Aktualisierung, die der Aktualisierungswarteschlange hinzugefügt worden ist, oder die Adresse des Übertragungsendes werden anfänglich von der API des LS-Initialisierungsrufes eingerichtet. Die Adressen des Endes der Übertragungswarteschlange wird durch die APIs des Aktualisierungsrufes und den Ruf zum Beginn der erneuten LS-Initialisierung verändert. Die Task zum Auffrischen der Warteschlange verändert die Adresse für das Ende der Übertragungswarteschlange nicht. wenn der Warteschlange eine Registeraktualisierung hinzugefügt werden muss, wird der neuen Aktualisierung Speicher zugewiesen, der nächste Eintrag nach dem Ende der Übertragungswarteschlange wird auf den zugeordneten Speicher eingestellt, und die Adresse für das Ende der Übertragungswarteschlange wird so verändert, dass sie auf die neue Aktualisierung zeigt.
Der Sync-Server 62 hält eine flüchtige Liste im Speicher und eine dauerhafte Liste (als Plattendatei) der LS-Clients aufrecht, die derzeit bei ihm registriert sind. Die dauerhafte Liste wird in der Listendatei der LS-Clients gespeichert, und die flüchtige Liste wird als einzelne verknüpfte Liste aufrechterhalten.
Jeder Eintrag in der dauerhaften Liste der Clients wird durch die folgende Datenstruktur dargestellt:
Jeder Eintrag in die flüchtige Liste der Clients wird durch die folgende Datenstruktur dargestellt:

– client_name: Dies ist der „Rechnername" der Maschine, auf welcher der Client-Vorgang läuft. Der LS-Sync-Server benutzt diesen Namen als Auftraggebernamen für die Berechtigung des Client zur RPC-Abwicklung.
– client_uuid: Dies ist die Instanz-UUID des LS-Client. Der Client verbindet diese UUID mit den Schnittstellen, er trägt sich beim Endpunktabbild ein. Der LS-Sync-Server verbindet die UUID mit dem Client-Bindungs-Handle ,client_handle'.
– realm_name: Dies ist der Bereichsname des Bereiches, der mit der Domänensteuerung des LS-Client verbunden ist. Dieses Feld wird zum Filtern von Aktualisierungen auf der Grundlage eines Bereiches benutzt.
– client_state: Der aktuelle Übertragungszustand des Client. Die Task „prop_udates" überträgt Aktualisierungen an einen Client nur dann, wenn dieser Zustand „in_service" ist. Der Client kann sich in einem der folgenden Zustände befinden:

Initialisierung: Der Client befindet sich im Vorgang des Synchronsierens seiner gesamten Datenbank vom Register.
in_service: Der Client ist aktiv und in Betrieb, und es können an den Client Aktualisierungen übertragen werden.
sync_error: Eine Synchronisierung mit einer an den Client übertragenen Registeraktualisierung ist misslungen. Die Task „resume_prop" verändert diesen Zustand alle 10 Minuten in „in_service".
comm_error: Der Client ist nicht aktiv oder nicht in der Lage, Aktualisierungen zu empfangen. Wenn sich ein Client in diesem Zustand befindet, überträgt der LS-Sync-Server keine Aktualisierungen an den Client.

– client_ver_num: Dies wird vom LS-Sync-Server dafür benutzt, untergeordnete Clients zu erkennen.
– client_last_segno: Dies ist die Reihenfolgenummer der letzten Aktualisierung, die erfolgreich an den Client übertragen worden ist. Wenn der Client sich zum ersten Mal registrieren lässt, wird diese Reihenfolgenummer auf die Reihenfolgenummer der letzten Aktualisierung (S_end_of_ropq) gesetzt, die der Aktualisierungswarteschlange hinzugefügt wurde.
– client_handle: Dies ist das RPC-Bindungs-Handle für den LS-Client. Der LS-Sync-Server baut dieses Handle aus dem Client-Bindungs-Handle auf, die von der Registrier-RPC empfangen worden ist.
– last_state_time: Dies ist der Zeitpunkt, zu dem der Client in den Zustand „comm_error" oder „initializing" eingetreten ist. Der LS-Sync-Server streicht diesen Client von seiner Client-Liste, wenn sich ein Client für lange Zeit im Zustand „comm_error" oder „initializing" befindet. Dieser Zeitpunkt wird vernachlässigt, wenn sich ein Client im Zustand „in_service" befindet.
– client_last_update: Dies ist die Adresse der letzten Aktualisierung (in der Aktualisierungswarteschlange), die erfolgreich an den Client übertragen worden ist. Wenn sich der Client das erste Mal ins Register einträgt, wird diese Adresse auf die Adresse der letzten Aktualisierung (S_end_of_ropq) eingestellt, die zur Warteschlange hinzugefügt worden ist. Wenn die flüchtige Liste aus der dauerhaften Liste aufgebaut wird, wird diese Adresse auf die Adresse der Aktualisierung mit der Reihenfolgenummer „client_last_seqno" eingestellt.
– next_client: Dies ist der Zeiger auf den nächsten Eintrag in der Clientliste.

Der LS-Sync-Server stellt den LS-Sync-Clients die folgenden RPCs zur Verfügung.
Registrier-RPC: Ein LS-Client ruft diesen RPC, um sich am LS-Sync-Server registrieren zu lassen. Die Registrierung wird zurückgewiesen, wenn der Client in der ERA-Liste des Auftraggebers des Sync-Server nicht vorhanden ist. Der Client schickt seine Zustandsinformationen über den Registrier-RPC. Wenn der Zustand des Client „initializing" ist, fügt der Sync-Server den Client zu seiner Liste hinzu und markiert den Zustand des Client als „initializing". Nachdem der Client seine Datenbank (net.acc und DCDB) erfolgreich vom Register initialisiert hat, sendet er erneut den Registrier-RPC, wobei der Zustand auf „in_service" eingestellt ist. Wenn der Sync-Server die Anforderung zur Registrierung „in_service" erhält, ändert er den Zustand des Client in „in_service".
Der Client ruft auch den Registrier-RPC mit einem Zustand „re-start", um den Sync-Server aufzufordern, die Übertragung an den Client wieder aufzunehmen. Wenn der Zustand „re-start" ist, muss der Client die Reihenfolgenummer und die Zeitmarkierung der letzten Aktualisierung senden, die erfolgreich synchronisiert worden ist. Der Sync-Server benutzt diese Informationen, um festzustellen, ob er die Übertragung an einen Client wieder aufnehmen kann oder ob der Client erneut initialisiert werden muss. Wenn ein Client feststellt, dass sein Sync-Server den Betrieb eingestellt hat, kann er versuchen, durch Ausgabe eines Registrier-RPC „re-start" an einen neuen Sync-Server mit anderen Sync-Servers in der Zelle in Verbindung zu kommen. Wenn der Zustand des Registrier-RPC nicht „re-start" ist, lässt der Sync-Server die Reihenfolgenummer und die Zeitmarkierung der letzten Aktualisierung außer Acht.
Wenn der Zustand „unregister" ist, löscht der Sync-Server den Client von seiner Clientliste.
Wenn der Zustand „out_of_service" ist, ändert der Sync-Server den Zustand des Client auf „comm_error", um damit anzuzeigen, dass der Client seinen Betrieb eingestellt hat.
Der LS-Client sendet die folgenden Informationen über den Registrier-RPC:

– „client_name," „client_uuid," „realm_name," und „client_ver_num" der Datenstruktur „lse_clientp_list".
– Zustand des Client: Dies ist einer der folgenden Zustände:
– initializing
– in_service
– re_start
– unregister
– out_of_service

Wenn dieser Zustand sich bei „initializing" oder „in_service" befindet, wird „client_state-2 des Client in der Clientliste auf diesen Zustand eingestellt.

– Die Reihenfolgenummer und Zeitmarkierung der letzten Aktualisierung, die durch den Client erfolgreich synchronisiert wurde. Dies ist nur für den Zustand „re-start" gültig.

Die LS-Clients rufen häufig die RPC-API „rpc_mgmt_is_server_listening", um herauszufinden ob der Sync-Server aktiv ist. Wenn ein Client einen anderen Rücksendecode als rpc_s_ok bekommt, nimmt er an, dass der Sync-Server heruntergefahren wurde und versucht, mit einem anderen Sync-Server in Kontakt zu kommen. Ein Sync-Server exportiert seine Bindungsinformationen an das CDS-Objekt /.:/subsys/realms/rgysync/(sevobj:name>, dessen sevobj_name der letzte Namen der Maschine ist, in welcher der Sync-Server installiert worden ist.
Ein LS-Client ruft einen RPC des Abschlusses der Synchronisierung (sync_complete), nachdem der Client das Synchronisieren der letzten Menge von Aktualisierungen beendet hat, die er über den RPC „lse_sync_updates" vom Sync-Server erhalten hat. Der Sync-Client schickt die Reihenfolgenummer der letzten Aktualisierung, die erfolgreich synchronisiert worden ist, und einen Rücksendecode, mit dem angezeigt wird, ob alle Aktualisierungen erfolgreich synchronisiert worden sind. Wenn der Sync-Server diesen RPC erhält, aktualisiert er die „client_last_segno" des Client in der Clientliste und ändert den Zustand des Client „client_state" in Abhängigkeit vom Wert des Rücksendecode, den er vom Client empfängt. Der Rücksendecode, der vom Client gesendet wird, kann die folgenden Werte haben:

– rpc_s_ok: Der Client hat erfolgreich alle Aktualisierungen synchronisiert, die im letzten Ruf an ihn übertragen worden sind.
– update_error: Dem Client ist es nicht gelungen, eine oder mehrere Aktualisierungen aus dem letzten Ruf erfolgreich zu synchronisieren.
– lse_seqno_error: Der Client hat die Aktualisierungen, die im letzten Ruf an ihn übermittelt worden sind, nicht erwartet. Die Reihenfolgenummer der ersten Aktualisierung war niedriger als die Reihenfolgenummer der letzten Aktualisierung, die vom Client schon synchronisiert wurde.

Der Sync-Servervorgang beginnt die folgenden Tasks.
Die Task „prop_updates" übermittelt Aktualisierungen aus der Aktualisierungswarteschlange an die Liste der LS-Sync-Clients, die derzeitig am Sync-Server registriert sind. Diese Task wird aktiv, wenn einer leeren Übertragungswarteschlange eine Aktualisierung hinzugefügt wird. Jeder Client-Eintrag in der Clientliste enthält die Adresse der letzten Aktualisierung (client_last_update), die erfolgreich an diesen Client übertragen worden ist. Die Übertragungswarteschlange enthält Aktualisierungen in einer bestimmten Reihenfolge; die früheste Aktualisierung in der Warteschlange hat die niedrigste Reihenfolgenummer, und die neueste Aktualisierung hat die höchste Reihenfolgenummer. Immer dann, wenn die Task prop_update abläuft, übermittelt sie Aktualisierungen an einen LS-Sync-Client, beginnend mit der nächsten Aktualisierung in der Warteschlange nach der letzten „client_last_update" des Client. Wenn „client_last_update" des Client die gleiche ist wie die der Warteschlange hinzugefügte letzte Aktualisierung, gibt es nichts, was an diesen Client übermittelt werden muss. Aktualisierungen, die an alle Register-Clients erfolgreich übertragen worden sind, werden durch die Task „queue_refresh" aus der Übertragungswarteschlange gelöscht. Die Task „prop_updates" steuert auch die Größe der Übertragungswarteschlange. Sie verhindert, dass die Übertragungswarteschlange sehr stark anwächst, indem sie Aktualisierungen entfernt, die für einen langen Zeitraum noch nicht an einen beliebigen Client übertragen worden sind.
Die Datenstruktur, die in der Programmiersprache C geschrieben ist, wie es für alle Programmcodes der Fall ist, die für das Übertragen mehrfacher Aktualisierungen benutzt werden und die vorstehend zitiert sind, wird wie folgt definiert:

– upd_reclen ist die Länge der Aktualisierungsaufzeichnung in Byte, dabei ist die Größe von „lse_log_hdr_t" eingeschlossen.
– upd_module ist eins der folgenden Aktualisierungsmodule: #define RS_LOG_MODULE_ACCT 0 #define RS_LOG_MODULE_PGO 1 #define RS_LOG_MODULE_ATTR 2 #define RS_LOG_MODULE_PLCY 3
– upd_op kennzeichnet eine bestimmte Registeraktualisierung des durch „upd_module" definierten Moduls. Beispielsweise ist, wenn „upd_module" aus RS_LOG_MODULE_ACCT besteht, „upd_op" eines der folgenden: #define rs_log_acct_add_op 0 #define rs_log_acct_delete_op 1 #define rs_log_acct_replace_op 2 #define rs_log_acct_rename_op 3

Jeder Wert von „upd_op" für ein Modul entspricht einer bestimmten Registeraktualisierung für dieses Modul.

– upd_seqno ist die Reihenfolgenummer der Registeraktualisierung
– upd_ts ist die Zeitmarkierung der Registeraktualisierung
– upd_data ist die Adresse der Daten mit variabler Länge der Registeraktualisierung, wie sie von „upd_module" und „upd_op" definiert werden.

Die Task „queue_refresh" löscht aus der Übertragungswarteschlange alle Einträge, die an alle Sync-Clients erfolgreich übertragen worden sind. Sie löscht auch alle Clients, die sich für einen langen Zeitraum (einen Tag) im Zustand „initializing" oder „comm_error" befunden haben. Sie synchronisiert die dauerhafte Clientliste mit der flüchtigen Clientliste. Insbesondere wird die „client_last_update" jedes Client in der Clientliste mit den aktuellen Informationen in der flüchtigen Clientliste aktualisiert. Die Task zum Auffrischen der Warteschlange läuft periodisch ab, üblicherweise einmal pro Stunde, und auch dann, wenn der Vorgang „syncsrvr" abgeschlossen wird.
Die Task zur Wiederaufnahme der Übertragung läuft häufig und verändert alle Clients, die sich im Zustand „sync_error" befinden, in den Zustand „in_service". Ein Client geht in den Zustand „sync_error" über, wenn er eine Registeraktualisierung nicht erfolgreich synchronisieren kann, und er schickt „sync_error" an den Sync-Server zurück. Diese Task ist dafür geschaffen worden, den Verkehr im Netzwerk zu vermindern, wenn sich ein oder mehrere Clients im Zustand „sync_error" befinden. Der LS-Sync-Server überträgt Aktualisierungen nur an Clients, die sich im Zustand „in_service" befinden.
Der LS-Sync-Servervorgang protokolliert alle Aktivitäten, die für den Administrator von Interesse sein können. Die folgenden Ereignisse werden in der Datei „syncsrv.aud" protokolliert:

– Registrieren eines neuen LS-Client
– Entfernen eines LS-Client aus dem Register
– von einem LS-Client empfangener Neustart
– Senden eines RPC „re-init" an LS-Clients.

Der LS-Clientvorgang ist ein LAN-Serverdienst (lsesync), der in einer LSE-E-Domänensteuerung installiert ist. Wenn der Dienst „lsesync" an einer LSE-E-Domänensteuerung konfiguriert wird, wird er mit dem Anforderungsdienst gestartet und wird angehalten, wenn der Anforderungsdienst angehalten wird. Er läuft als Auftraggeber „ibm/ibmlan/rgysync/<computername_rgyclient" und stellt zum Empfangen von Aktualisierungen vom LS-Sync-Servervorgang berechtigte RPCs bereit. Das LS-Installations- und -konfigurierprogramm fügt den Auftraggeber „lsesync" zur Gruppe „acct-admin" hinzu, um den Dienst in die Lage zu versetzen, aus dem Register alle Benutzer- und Gruppeninformationen abzurufen.
Der LS-Clientvorgang registriert sich mit seinem ersten LS-Sync-Servervorgang (syncsrvr), der in der Datei der LAN-Server-Konfiguration vorgegeben ist. Er hält eine dauerhafte Zustandsdatei (lsesync.st) aufrecht, die seine Zustandsinformationen und die Reihenfolgenummer und Zeitmarkierung der letzten Aktualisierung enthält, die erfolgreich synchronisiert worden ist.
Wenn der Dienst lsesync das erste Mal gestartet wird, ruft er aus dem Register die gesamten Benutzer- und Gruppeninformationen ab, die zu seinem Bereich gehören, und er synchronisiert die lokalen Dateien net.acc und DCDB. Eine erneute Synchronisierung kann auch durch den Administrator erzwungen werden, indem er den Wert des Parameters „reinit_required" in der Konfigurationsdatei auf „ja" setzt. Im Standardfall ist „reinit_required" auf „nein" eingestellt. Der Dienst „lsesync" kann nicht angehalten oder fortgesetzt werden.
Wenn aus irgendeinem Grund der LS-Sync-Client angehalten werden muss, werden in der Zustandsdatei „lsesync.st" die Reihenfolgenummer und Zeitmarkierung der letzten Aktualisierung gesichert, die erfolgreich synchronisiert worden ist. Die Reihenfolgenummer und Zeitmarkierung der letzten Aktualisierung werden auch durch die „Ortungs"-Task alle 10 Minuten in der Zustandsdatei aufgezeichnet. Wenn der lsesync-Vorgang erneut gestartet wird, liest er die Reihenfolgenummer und Zeitmarkierung der letzten Aktualisierung aus der Zustandsdatei und sendet an den LS-Sync-Server einen „re-start"-Registrier-RPC.
Eine Routine zur erneuten Datenbanksynchronisierung 67 in 3 synchronisiert alle Benutzer- und Gruppeninformationen, die zum Bereich des LS-Client im Hauptregister gehören, mit der Datenbank des LS-Client (net.acc und DCDB). Wenn ein LS-Client das erste Mal gestartet wird, ehe er sich an seinem ersten Sync-Server registrieren lässt, ruft der Client diese Routine auf, um seine net.acc und DCDB mit dem Hauptregister zu synchronisieren.
Der LS-Sync-Client registriert die folgenden RPCs, damit er vom LS-Sync-Server Aktualisierungen erhält.
Der LS-Sync-Client stellt der Task „prop_updates" des LS-sync-Server einen Aktualisierungs-RPC bereit. Der Sync-Server überträgt eine oder mehrere Registeraktualisierungen (bis zu 10 Aktualisierungen) gleichzeitig. Der Aktualisierungs-RPC kopiert die Registeraktualisierungen in einen lokalen Zwischenspeicher, weckt die Task „process_updates" und schickt „rpc_s_ok" zurück.
Wenn der Sync-Server vom Aktualisierungs-RPC „rpc_s_ok" empfängt, ändert er den Zustand des LS-Client in der Clientliste auf „updates_in_progress". Die Task „prop_updates" des Sync-Servervorgangs hält die Übertragung von Aktualisierungen an den Client an, bis der Sync-Server vom LS-Client die RPC „sync_complete" empfängt.
Der LS-Sync-Server sendet an einen LS-Client einen RPC Re-init, wenn er möchte, dass der Client erneut initialisiert wird. Wenn beispielsweise die Übertragungswarteschlange des Sync-Server mit den Aktualisierungen des Sicherheitsserver aus der Synchronisation fällt, wird sie einen RPC „re-init" senden, um allen Clients mitzuteilen, sich erneut zu initialisieren. Wenn ein LS-Client diesen RPC empfängt, synchronisiert er seine net.acc und DCDB (Datenbankdateien) vom Register erneut und lässt sich wieder am LS-Sync-Server registrieren.
Der LS-Sync-Server ruft einen Abschalt-RPC, um den Client wissen zu lassen, dass der „syncsrvr"-Vorgang zu Ende geht. Wenn der Client diesen RPC empfängt, sendet er eine Alarmnachricht und protokolliert in der Fehlerprotokolldatei eine Warnnachricht. Der Client ändert den Zustand des LS-Client auf „out_of_service", was die Ortungs-Task davon benachrichtigt, mit einem anderen Sync-Server in Verbindung zu treten.
Wenn er erneut gestartet wird, sendet der LS-Sync-Server an jeden Client in seiner Liste einen erneuten Verbindungs-RPC. Wenn ein LS-Client diesen RPC empfängt, schickt er immer einen „rpc_s_ok" an den Sync-Server. Wenn der LS-Client noch keinen Kontakt mit einem anderen Sync-Server aufgenommen hat, wird er sich wieder mit diesem Sync-Server verbinden.
Der LS-Client-Vorgang startet die folgenden Tasks.
Es läuft häufig, etwa alle 10 Minuten, eine Ortungstask und führt eine Prüfung durch, um festzustellen, ob der LS-Sync-Server aktiv ist, an dem der Client derzeit registriert ist. Sie ruft die RPC-API „rpc_mgmt_is_server_listening", die einen „rpc_s_ok" zurückschickt, wenn der Sync-Server aktiv ist. Wenn der LS-Sync-Client irgendetwas Anderes als „rpc_s_ok" von der RPC-API zurückgeschickt bekommt, nimmt der Client an, dass der Server abgeschaltet ist, und er versucht, mit „ibm/ibmlan/rgysync", mit einem anderen Sync-Server von der Liste der Sync-Server-Auftraggeber Kontakt aufzunehmen. Der Client gibt an den neuen Sync-Server, mit dem er in Verbindung treten möchte, den Registrier-RPC „re-start" aus.
Die Ortungs-Task zeichnet die Reihenfolgenummer und Zeitmarkierung der letzten Aktualisierung auf, die erfolgreich mit der Zustandsdatei synchronisiert worden ist.
Eine Task zur erneuten Initialisierung, die durch den RPC „lse_reinit_lsdb" geweckt wird, wenn die lokale Datenbank des LS-Client erneut mit dem Register synchronisiert werden muss.
Eine Task „process_update" verarbeitet Aktualisierungen, die vom Sync-Servervorgang empfangen worden sind. Der RPC „lse_sync_udate" weckt diese Task, wenn eine oder mehrere Aktualisierungen vom LS-Sync-Servervorgang übertragen wurden. Nachdem die Aktualisierungen verarbeitet worden sind, gibt sie den RPC „sync_complete" an den Sync-Server aus, der den Sync-Server dazu bringt, die Übertragung an diesen Client wieder aufzunehmen. Sie sendet die Reihenfolgenummer der letzten Aktualisierung, die mit der Datenbank des lokalen Client erfolgreich synchronisiert worden ist.
Die Task „process_update" sendet einen der folgenden Rückmeldecodes an den RPC „sync_complete":
– rpc_s_ok
Alle Aktualisierungen wurden erfolgreich synchronisiert. Der Vorgang des LS-Sync-Server aktualisiert die „client_last_seqno" des Client in seiner Client-Liste mit der Reihenfolgenummer, die mit dem RPC „sync_complete" gesendet worden ist.
– update_error
Dem Client ist das Synchronisieren einer oder mehrerer Aktualisierungen misslungen. Der Server ändert die „client_last_seqno" aktualisieren und den Zustand des Client in „sync_error".
– lse_seqno_error
Der Sync-Server hat eine Aktualisierung mit einer Reihenfolgenummer übertragen, die niedriger ist als die letzte Reihenfolgenummer.
6 veranschaulicht den Vorgange der Aktualisierung der Hauptkopie des Datenbankbereiches, der dafür benutzt wird, die Registerdatenbank aufrechtzuerhalten. Wiederum ist innerhalb der Zelle nur eine Hauptkopie des Datenbankbereiches erlaubt, die auch als erste Datenbankbereichskopie bezeichnet wird. Der Hauptsicherheitsserver 70 richtet eine Haupt- oder erste Datenbankbereichskopie ein und nimmt von Clients Aktualisierungen zu seiner Registerdatenbank 72 entgegen. Andere Datenbankbereichskopien, die üblicherweise als Neben- oder zweite Datenbankbereichskopien bezeichnet werden, nehmen von Clients nur Lesevorgänge entgegen. Die Hauptkopie des Datenbankbereiches überträgt alle Aktualisierungen an die untergeordneten Datenbankbereichskopien. Beispielsweise kann jede erste oder zweite Datenbankbereichskopie einem Client-Programm Account-Informationen bereitstellen. Wenn jedoch gewünscht wird, einen Account hinzuzufügen oder Passwortinformationen zu ändern, können solche Aktualisierungen nur von der Haupt-Datenbankbereichskopie vorgenommen werden. Die Sicherheitswerkzeuge, die auf die Datenbankbereichskopien zugreifen, binden sich automatisch an die Art von Datenbankbereichskopie, die für den Vorgang erforderlich ist, den sie durchführen.
Wenn die erste Datenbankbereichskopie (Hauptsicherheitsserver 70) eine Aktualisierung empfängt, in diesem Beispiel eine Aktualisierung einer Datenbank, nimmt sie die Aktualisierungen an ihrer Datenbank im virtuellen Speicher 74 vor und speichert eine Kopie jeder Aktualisierung in einer Protokolldatei 76, die auf der Festplatte gespeichert wird. Aktualisierungen werden in der Protokolldatei 76 in einer Reihe aufeinanderfolgender Zahlen gesammelt. Wenn ein Server unerwartet erneut startet, stellt die Protokolldatei sicher, dass keine Aktualisierungen verloren gehen. Periodisch zeichnet die Datenbankbereichskopie die Datenbank im virtuellen Speicher 74 auf der Festplatte 72 auf, wobei damit die Plattenkopie auf den neusten Stand gebracht wird. Dann löscht die Datenbankbereichskopie, wenn sie eine zweite Datenbankbereichskopie ist, die Protokolldatei aller Aktualisierungen. Wenn die Datenbankbereichskopie die Hauptkopie ist, löscht sie die Protokolldatei aller Aktualisierungen, die an Nebenkopien verschickt worden sind. Aktualisierungen, die nicht an die zweiten Datenbankbereichskopien übertragen worden sind, werden zurückgehalten und dafür benutzt, wenn erforderlich, die Übertragungswarteschlange erneut aufzubauen. Für jede Datenbankbereichskopie in der Zelle enthält die Liste der Datenbankbereichskopien 78 die Netzwerkadresse und die ID, den zellenbezogenen Namen und die Reihenfolgenummer der letzten Aktualisierung der Datenbankbereichskopie. Weiterhin speichert der Server 70 eine Kopie jeder Aktualisierung in der Protokolldatei 76. Diese Datei wird im Falle eines erneuten Starts des Server dafür benutzt, ausstehende Aktualisierungen an der Festplattenkopie der Datenbank vorzunehmen und eine Übertragungswarteschlange 80 neu zu erzeugen. Der Server nimmt die Aktualisierung auch an der Datenbank im virtuellen Speicher und an deren Übertragungswarteschlange 80 vor. Periodisch zeichnet der Server 70 die Datenbank im virtuellen Speicher 74 auf der Festplatte 72 auf. Die Haupt-Datenbankbereichskopie benutzt ihre Übertragungswarteschlange 80, um an zweite Datenbankbereichskopien Aktualisierungen zu übertragen. Wenn die Haupt-Datenbankbereichskopie erneut startet, stellt sie die Übertragungswarteschlange 60 aus der Protokolldatei 76 wieder her.
Nur die Haupt-Datenbankbereichskopie hält eine Warteschlange 80 aufrecht, die dafür benutzt wird, Veränderungen festzuhalten, die an die zweiten Datenbankbereichskopien übertragen werden sollen. Wenn die Haupt-Datenbankbereichskopie eine Aktualisierung empfängt, fügt sie diese zur Übertragungswarteschlange 80 zusätzliche zu ihrer virtuellen Speicherdatenbank 74 und ihrer Protokolldatei 76 hinzu. Jede Aktualisierung in einer Übertragungswarteschlange 80 wird durch eine Reihenfolgenummer und Zeitmarkierung gekennzeichnet. Die Reihenfolgenummer wird intern dafür benutzt, die Übertragung von Aktualisierungen an zweite Datenbankbereichskopien zu steuern. Die Zeitmarkierung wird dafür bereitgestellt, Benutzern Datum und Zeitpunkt von Aktualisierungen zu zeigen.
Wenn eine Haupt- oder zweite Datenbankbereichskopie startet, initialisiert sie ihre Datenbank im virtuellen Speicher 74 und nimmt dann alle anstehenden Aktualisierungen in der Protokolldatei 76 an ihrer Datenbank 72 vor. Wenn die Datenbankbereichskopie die Hauptkopie ist, erzeugt sie aus Protokolldatei 76 auch die Übertragungswarteschlange 80 neu, so dass alle ausstehenden zweiten Aktualisierungen übertragen werden können. Dieser Mechanismus stellt sicher, dass beim Abschalten eines Server keine Aktualisierungen verloren gehen. Genau für diese Vorgänge ist das Synchronisieren von Bedeutung.
Damit ist eine Datenbank-Synchronisiersystem zum Synchronisieren einer Vielzahl von lokalen Datenbanken in einer Vielzahl von verteilten Rechensystemen dargelegt und beschrieben worden. Die Vielzahl von verteilten Rechensystemen bilden eine verteilte Rechenumgebung (DCE). Das Synchronisiersystem enthält einen Systemserver, eine Registerdatenbank, die mit dem Systemserver verbunden ist, einen Synchronisierserver für ein lokales Netzwerk (LAN), der mit dem Systemserver verbunden ist, eine Synchronisationsbibliothek für den LAN-Server, die mit dem Systemserver verbunden ist, und einen LAN-Server, der mit dem LAN-Synchronisierserver und ausgewählten aus der Vielzahl verteilter Rechensysteme verbunden ist, die ein LAN bilden. Das Synchronisieren zwischen dem LAN und dem DCE-Register erfolgt, wenn die Registerdatenbank, in der Registeränderungen vorgenommen werden, die mindestens eine aus der Vielzahl der lokalen LAN-Datenbanken betreffen, die Synchronisationsbibliothek des LAN-Server aufruft, die betroffene Datenbank zu synchronisieren.
Das Synchronisiersystem benutzt eine Registerdatenbank, die mit jeder der lokalen Datenbanken verbunden ist. Eine erste Datenbankbereichskopie ist mit der Registerdatenbank verbunden, die jede lokale Datenbank innerhalb des DCE mit der Registerdatenbank synchronisiert. Eine zweite Datenbankbereichskopie wird dann mit der ersten Datenbankbereichskopie verbunden, die mindestens einen Server eines lokalen Netzwerkes (LAN) synchronisiert, der ausgewählte aus der Vielzahl der Rechensysteme und deren jeweilige Datenbanken mit der Registerdatenbank synchronisiert.
Obwohl die Erfindung insbesondere unter Bezugnahme auf eine bevorzugte Ausführungsform gezeigt und dargelegt worden ist, versteht es sich für den Fachmann, dass verschiedene Änderungen an Form und Einzelheiten darin vorgenommen werden können, ohne dass vom Umfang der Erfindung abgewichen wird.

Claims

Synchronisiersystem für eine Datenbank zum Synchronisieren einer Vielzahl von lokalen Datenbanken in einer Vielzahl von verteilten Rechensystemen, die eine verteilte Rechnerumgebung (DCE) bilden, das Folgendes umfasst: einen DCE-Systemserver; eine DCE-Registerdatenbank, die mit dem DCE-Systemserver verbunden ist; einen Synchronisierserver für ein lokales Netzwerk (LAN), der mit dem DCE-Systemserver verbunden ist, um damit Aktualisierungen von einer der lokalen Datenbanken an einer LAN-Server zu übertragen, der mit dem Synchronisierserver für das lokale LAN-Netzwerk verbunden ist; eine Synchronisationsbibliothek für den LAN-Server, die mit dem DCE-Systemserver verbunden ist; wobei der LAN-Server, der mit dem LAN-Synchronisierserver und ausgewählten Systemen aus der Vielzahl der verteilten Rechensysteme verbunden ist, die ein LAN bilden, wobei die Synchronisationsbibliothek des LAN-Server so gestaltet ist, dass sie jegliche lokale Datenbank synchronisiert, die durch Registerveränderungen in der DCE-Registerdatenbank betroffen ist.
Synchronisiersystem für Datenbanken nach Anspruch 1, wobei der Systemserver weiterhin Mittel zum Feststellen umfasst, ob die Synchronisationsbibliothek des LAN vorhanden und aktiv ist.
Synchronisiersystem für Datenbanken nach Anspruch 1 oder Anspruch 2, wobei die Synchronisationsbibliothek für den LAN-Server so gestaltet ist, dass sie als Filter und Warteschlange für Aktualisierungen für den LAN-Server dient.
Synchronisiersystem für Datenbanken nach einem beliebigen vorhergehenden Anspruch, wobei der Synchronisierserver für das LAN so gestaltet ist, dass er vom DCE-Systemserver Benachrichtigungen über Ereignisse entgegennimmt und Übertragungen an die lokalen Datenbanken überwacht.
Synchronisiersystem für Datenbanken nach Anspruch 4, wobei der Synchronisierserver für das LAN so gestaltet ist, dass er eine Liste von lokalen LAN-Datenbanken aufrechterhält, denen es gestattet ist, sich beim DCE-Systemserver registrieren zu lassen.
Synchronisiersystem für Datenbanken nach einem beliebigen vorstehenden Anspruch, wobei der Synchronisierserver für das LAN so gestaltet ist, dass er von jeder lokalen Datenbank innerhalb der verteilten Rechnerumgebung alle Benutzer- und Gruppeninformationen abruft, die zu seinem mit ihm verbundenen LAN gehören, und er die lokalen Datenbanken in jedem Register innerhalb des DCE synchronisiert.
Synchronisiersystem für Datenbanken nach Anspruch 6, wobei der DCE-Systemserver weiterhin ein Rufmittel enthält, das aufgerufen wird, um den lokalen Registerdatenbanken innerhalb des DCE Aktualisierungen bereitzustellen.
Synchronisiersystem für Datenbanken nach einem beliebigen vorhergehenden Anspruch, wobei der DCE-Systemserver so gestaltet ist, dass er entweder als erste Datenbankbereichskopie oder als zweite Datenbankbereichskopie betrieben wird.
Synchronisiersystem für Datenbanken nach Anspruch 8, wobei der DCE-Systemserver weiterhin ein Initialisierungsmittel zum Erzeugen gemeinsam benutzter Speicherobjekte zum Datenaustausch mit dem Synchronisierserver des LAN umfasst.
Synchronisiersystem für Datenbanken nach Anspruch 8, wobei der DCE-Systemserver so gestaltet ist, dass er als erste Datenbankbereichskopie betrieben wird und ein erstes Registerobjekt innerhalb einer Restdatenbank untergebracht wird und ihm eine zugeordnete Reihenfolgenummer derart zugeteilt wird, dass die Reihenfolgenummer einer nächsten Registeraktualisierung um eins größer ist als die vorhergehende Aktualisierung.
Synchronisiersystem für Datenbanken nach Anspruch 8, wobei der DCE-Systemserver so gestaltet ist, dass er als zweite Datenbankbereichskopie läuft und die gesamte Registerdatenbank des DCE von einer ersten Datenbankbereichskopie empfängt und eine Übertragungswarteschlange einrichtet, die eine erste Übertragung zuordnet, die eine gegebene Reihenfolgenummer hat, wobei zusätzliche Übertragungen für jede nachfolgende Übertragung für Registeraktualisierungen jeweils um eins erhöht werden.
Synchronisiersystem für Datenbanken nach Anspruch 1, wobei die Synchronisationsbibliothek des LAN einen Status der Dienstbereitschaft enthält, damit Rufe zulässig sind, um einer Protokolldatei und einer Aktualisierungswarteschlange Aktualisierungen hinzuzufügen.
Synchronisiersystem für Datenbanken nach Anspruch 1, wobei die Synchronisationsbibliothek des LAN einen Initialisierungszustand enthält, wenn eine zweite Datenbankbereichskopie von einer ersten Datenbankbereichskopie eine Aktualisierung einer Massenübertragung empfängt, wobei die Synchronisationsbibliothek des LAN so gestaltet ist, dass sie während des Empfangszeitraumes keinerlei Aktualisierungen verarbeitet.
Synchronisiersystem für Datenbanken nach Anspruch 1, wobei die Synchronisationsbibliothek des LAN einen Fehlerzustand enthält, wenn es nicht gelingt, durch einen Ruf einer Protokolldatei oder einer Aktualisierungswarteschlange eine Aktualisierung hinzuzufügen.
Synchronisiersystem für Datenbanken nach Anspruch 1, wobei die Synchronisationsbibliothek des LAN so gestaltet ist, dass sie in einer Aktualisierungsprotokolldatei eine dauerhafte Kopie aller vom Systemserver empfangenen gültigen Aktualisierungen des LAN-Server aufrechterhält.