LANline, Ausgabe 01/2007

Replikation á la P2P

Über den Tellerrand geblickt

Um effizient Daten und Programme auf eine Vielzahl von Rechnern zu verteilen, bedienen sich beispielsweise File-Sharing-Netze der dezentralen Peer-to-Peer (P2P)-Technik. In kommerziellen Anwendungen hingegen, wie etwa bei System-Management-Software, findet dieses Prinzip bislang kaum Anwendung – trotz aller Vorteile hinsichtlich Geschwindigkeit, Vermeidung von Flaschenhälsen und Bandbreitenentlastung.

Wie kann ein Unternehmen sicherstellen, dass alle Mitarbeiter stets die gleichen Dokumentenvorlagen nutzen, die aktuellsten Berechungsmodelle für Angebote und Verträge verwenden und die neuesten Softwareversionen, Patches und Fixes installiert haben – ganz gleich, ob sie in der Firmenzentrale sind, in einer entfernten Niederlassung sitzen oder mobil im Außendienst, Home-Office oder vor Ort beim Kunden arbeiten? Die effizienteste und sicherste Variante dies zu tun, besteht in der Replikation der entsprechenden Daten auf die Rechner aller Mitarbeiter. In der Regel erfolgt das nach dem Pull-Prinzip, bei dem die Client-Systeme die zu replizierenden Daten von einer Quelle anfordern.

„Wasserfall“-Replikation: hierarchisch und zentralisiert

Das am weitesten verbreitete Replikationsverfahren verläuft wie ein Wasserfall, bei dem die Daten kaskadisch auf alle Client-Rechner kopiert werden. Hierfür greift diese Technik auf eine stark hierarchisch strukturierte Netzwerkinfrastruktur mit zahlreichen leistungsfähigen File-Servern zurück. Diese Fileserver sind wiederum für die Rechner einer Niederlassung oder eines Netzwerksegmentes zuständig.

Um Daten oder ganze Verzeichnisstrukturen auf die Clients im Netzwerk zu replizieren, versendet der System-Management-Server zunächst eine Nachricht mit den entsprechenden Auftragsdaten an die File-Server. In dieser Auftragsdatei sind das Quellverzeichnis und der Zeitpunkt der Ausführung beschrieben. Über LAN-Manager-Funktionen beziehungsweise Netzwerkfreigaben verbinden sich die Dateiserver dann mit der Quelle und kopieren die entsprechenden Dateien.

Sobald die entsprechenden Daten auf den File-Servern zur Verfügung stehen, erhalten die Clients eine Auftragsdatei vom Server, die den freigegebenen Verzeichnispfad mit den entsprechenden Daten auf den zugehörigen Dateiservern enthält. Die Clients verbinden sich daraufhin mit dem angegebenen File-Server, um die Dateien von dort zu replizieren. Pro Datei werden dann zunächst Informationen zwischen Quelle und Ziel ausgetauscht, wie beispielsweise der Dateiname, der Verzeichnispfad und die Datei-Attribute. Das kann jedoch bereits vor der eigentlichen Datenübertragung zu einem nicht unwesentlichen Traffic im Netzwerk führen.

Diese Wasserfall-artige Vorgehensweise ermöglicht dem Administrator eine einfache und zentrale Kontrolle über den gesamten Replikationsvorgang und dessen erfolgreichen Abschluss. Die hierfür notwendigen Informationen können aus einem angebundenen, zentralisierten Reporting ausgelesen werden und gegebenenfalls so auch die Fehlersuche erleichtern. Allerdings ist diese stark zentralisierte Replikationstechnik auch relativ störanfällig, da Flaschenhälse bei dem Quell-Rechner und den File-Servern entstehen. Wenn diese Quellen durch die zahllosen gleichzeitigen Anfragen überlastet sind oder gar ausfallen, beeinträchtigt dies den zeitnahen Erfolg einer Replikation. Dies kann auch den gesamten IT-Betrieb empfindlich stören. Eine entfernte Firmenniederlassung kann damit leicht im Nachteil sein. Insbesondere bei zeitkritischen Hotfixes oder dringlichen Datenänderungen ist dies schnell problematisch.

„Spinnennetz“-Replikation: dezentral und autonom

Die Peer-to-Peer-Technik nutzt die Vernetzung der Rechner untereinander für den Datenaustausch. Das Charakteristische dabei: Jeder Client besitzt zugleich auch Serverfunktionen und vermindert so die Anforderungen an die Leistungsfähigkeit und Anzahl von notwendigen Fileservern. Somit bezieht eine Workstation die benötigten Daten auch von anderen, benachbarten Rechnern – und nicht (nur) von einem zentralen Server. Die Identifikation und Überprüfung der Dateien bzw. Dateifragmente erfolgt dabei mittels Checksummen.

Angewandt auf die Datenreplikation, kann das P2P-Prinzip bei einer System-Management-Lösung beispielsweise wie folgt aussehen: Für die Replikation eines bestimmten Verzeichnisses erteilt der System-Management-Server dem Quellrechner den Auftrag, einen Katalog von dem entsprechenden Verzeichnis anzufertigen. Diese Katalogdatei enthält dabei die gesamte Verzeichnisstruktur, Namen, Attribute und die Prüfsummen aller Dateien. Der Quellrechner bildet von der Katalogdatei wiederum die Checksumme und überträgt diesen unmanipulierbaren Fingerabdruck an den Server. Zusammen mit dem entsprechenden Jobnamen sendet der verwaltende Server diese Prüfsumme via UDP an die Client-Agenten.

Aufgrund des angegebenen Releasezeitpunktes der Katalogdatei und der sich daraus ergebenden hohen Priorität fragen die Agenten dieses Objekt anhand der Prüfsumme bei der Quelle sehr schnell an. Hat ein Client-Agent den Katalog erhalten, bildet er über sein betreffendes lokales Verzeichnis ebenfalls einen Checksummenkatalog und führt einen Soll-Ist-Vergleich durch. Fehlen auf dem Client einige Dateien, so fragt der Agent diese Daten anhand der zugehörigen Prüfsumme zunächst in seinem Subnetz via Broadcast bei den benachbarten Rechnern an. Mit den Rechnern, die zuerst auf seinen Broadcast geantwortet haben, baut der Agent dann eine TCP-Verbindung auf und repliziert von dort die fehlenden Dateien. Dabei speichern die Agenten auf den anderen Rechnern im Subnetz, welche Datei-Checksummen bereits mittels Broadcast von welchem Rechner gesucht wurden und fragen deshalb nur noch die bei ihnen zusätzlich fehlenden Daten an. Auf diese Weise treten die Agenten eines Subnetzes auch nach außen als Einheit auf, um doppelte Anfragen aus dem gleichen Subnetz zu vermeiden.

Wird ein Agent in seinem eigenen Subnetz nicht fündig, sendet er einen Request mit der entsprechenden Checksumme an einen Rechner im benachbarten Subnetz. Auf diese Weise fragt sich der Agent gegebenenfalls bis zur Quelle durch. Sobald er alle Daten vollständig auf seinem Rechner in das entsprechende Verzeichnis repliziert hat, gibt er gegebenenfalls den anderen Agenten in seinem Subnetz Bescheid, die dann die ihnen noch fehlenden Dateien von ihm kopieren können.

Der Hauptvorteil dieser Vorgehensweise besteht in der Vermeidung von Flaschenhälsen. Durch die dezentrale Struktur stellt die Überlastung bzw. der Ausfall eines Rechners für den Replikationsablauf kein Problem dar. Gerade bei remote Replikation ist dies von entscheidender Bedeutung. Da bei der beschriebenen P2P-Replikation ein Soll-Ist-Abgleich mit eindeutigen Prüfsummen vor einer Datenübertragung stattfindet, lässt sich die mehrfache Übertragung identischer Dateien vermeiden und so die Netzwerklast gering halten. Die Schonung der verfügbaren Bandbreite wird auch dadurch erreicht, dass jede zu replizierende Datei nur einmal in jedes Subnetz übertragen wird und dort sich nach dem P2P-Prinzip selbst weiter verteilt.

Allerdings basiert dieses Verfahren auf einer agentenbasierten System-Management-Lösung. Agentenlos lässt sich ein derartiges Verfahren eher schwer implementieren. Die Kontrolle und Dokumentation von dezentral ablaufenden Replikationsvorgängen ist etwas weniger leicht als bei einer linearen, zentralistischen Vorgehensweise zu realisieren. In einer System-Management-Lösung muss ein entsprechendes Reporting dann auf andere Weise implementiert sein. So kann eine stets aktuelle Übersicht über den Replikationsfortschritt durch kontinuierliche, kurze Statusmeldungen von allen Clients an eine zentrale Stelle erreicht werden. Diese Statusmeldungen von den Agenten liegen dabei in gekürzter Form vor: Sie enthalten beispielsweise die Anzahl der Dateien, die Datenmenge und die nächste Datei. Liegen diese zentral gesammelten Daten zudem möglichst in Echtzeit vor und lassen sie sich mit Hilfe einer Datenbank übersichtlich auswerten, kann der Administrator sehr schnell Aufschluss über die aktuelle Menge der gesendeten und empfangenen Suchanfragen, Zahl der Verbindungen, aktuelle Übertragungsgeschwindigkeit, Anzahl der gesendeten und empfangenen Dateien sowie die bisher übertragene Datenmenge gewinnen.

Nach der Replikation: Verzeichnisüberwachung

Ganz gleich, nach welcher Methode die Daten repliziert wurden, sollte im Anschluss sichergestellt werden, dass Anwender diese Dateien nicht manipulieren können. Dies erfolgt üblicherweise durch die Überwachung des entsprechenden Verzeichnisses auf den Client-Systemen. Dafür kann sich der System-Management-Agent beispielsweise vom Betriebssystem informieren lassen, wenn in den betroffenen Verzeichnissen Änderungen erfolgen. Wurde eine entsprechende Änderung bemerkt, kann der Agent den Soll-Zustand umgehend wiederherstellen, indem er auf Cache-Algorithmen zurückgreift, die analog zur Technik der Windows-Schattenkopie funktioniert: Hierfür muss er nur den Hardlink zwischen physikalischem und virtuellem Speicherort wieder neu setzen. Dadurch erübrigt sich eine erneute Replikation der betroffenen Dateien. Idealerweise wird auch der Administrator benachrichtigt, wenn sich diese Vorgänge bei einem Anwender häufen sollten.

Erfolgt hingegen eine Veränderung im überwachten Verzeichnis an der Quelle, so erstellt diese einen neuen Verzeichniskatalog mit den zugehörigen Checksummen und schickt diese Information an den Server. Der Server erstellt dann einen neuen Auftrag und der Replikationsvorgang setzt von vorn ein.

Fazit

Neben der hier beschriebenen Pull-Technik, wäre eine Datenreplikation auch nach dem Push-Modell denkbar: Hierbei würden nicht die Zielsysteme bei der Quelle nach den Daten anfragen, sondern die Quelle würde die Zielsysteme selbständig mit allen Dateien versorgen. Allerdings wird dieses Verfahren aufgrund seines immanenten starren Aufbaus und der damit einhergehenden aufwändigen Umsetzung von Ausnahmen und schwierigen Anbindung mobiler Geräte in der Praxis fast nur bei der Betriebssystemverteilung eingesetzt.

Bei der Pull-Methode weist eine Adaption des Peer-to-Peer-Prinzips erhebliche Vorteile gegenüber traditionell-zentralistisch geprägten Replikationsverfahren auf. Die herkömmliche Replikationstechnik ist gerade in Windows-Netzen einfacher zu realisieren, da sie auf LAN-Manager-Freigaben beruht. Sie ist aber im Vergleich zum P2P-Modell auch unter Umständen langsamer, in jedem Fall aber wesentlich ressourcenintensiver und störanfälliger. Die historisch gewachsene Orientierung am Server-Fokus hat angesichts der heute verfügbaren, preiswerten und leistungsfähigen Client-Rechner ausgedient. Auf Basis des P2P-Prinzips lässt sich hingegen ein sich selbst steuerndes und damit auch nahezu wartungsfreies Replikationsverfahren implementieren, bei dem das gesamte Netzwerk und alle angeschlossenen Rechner als Ressource effizient genutzt werden.

Autor: Volker Schröder, Gründer und Gesellschafter bei Xpedi GmbH & Co. KG, verantwortlich für die Produktentwicklung

Hier als PDF lesen