Datenreplikation à la Peer-to-Peer
Über den Tellerrand geblickt
Um Daten und Programme effizient auf eine Vielzahl von Rechnern zu verteilen, bedienen sich beispielsweise File-Sharing-Netze dezentraler Peer-to-Peer (P2P)-Verfahren. In kommerziellen Anwendungen hingegen, zum Beispiel bei Systemmanagementsoftware, findet dieses Prinzip bislang kaum Anwendung - trotz diverser 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 Methode für diese
Aufgabenstellung besteht in der Replikation der entsprechenden Daten auf die Rechner aller
Mitarbeiter. In der Regel erfolgt dies nach dem Pull-Prinzip, bei dem die Client-Systeme die zu
replizierenden Daten von einer Quelle anfordern.
"Wasserfall"-Replikation
Das am weitesten verbreitete Replikationsverfahren verläuft wie ein Wasserfall: Die Daten werden
in Kaskaden auf alle Client-Rechner kopiert. Dabei greift diese Technik auf eine stark hierarchisch
strukturierte Netzwerkinfrastruktur mit zahlreichen leistungsfähigen Fileservern zurück. Die
Fileserver sind wiederum für die Rechner einer Niederlassung oder eines Netzwerk-segments
zuständig.
Um Daten oder ganze Verzeichnisstrukturen auf die Clients im Netz zu replizieren, ver-sendet der
Systemmanagementserver zunächst eine Nachricht mit den entsprechenden Auftragsdaten an die
Fileserver. In dieser Auftragsdatei sind das Quellverzeichnis und der Zeitpunkt der Ausführung
beschrieben. Über LAN-Managerfunktionen beziehungsweise Netzwerkfreigaben verbinden sich die
Fileserver dann mit der Quelle und kopieren die entsprechenden Dateien.
Sobald die Daten auf den Fileservern zur Verfügung stehen, erhalten die Clients eine
Auftragsdatei vom Server, die den freigegebenen Verzeichnispfad auf den zugehörigen Servern
enthält. Die Clients verbinden sich daraufhin mit dem angegebenen Fileserver, um die Dateien von
dort zu replizieren. Pro Datei werden dann zunächst Informationen zwischen Quelle und Ziel
ausgetauscht, beispielsweise der Dateiname, der Verzeichnispfad und die Dateiattribute. Dies kann
jedoch bereits vor der eigentlichen Datenübertragung zu einem nicht unwesentlichen Datenverkehr im
Netzwerk führen.
Diese wasserfallartige Vorgehensweise ermöglicht dem Administrator eine einfache und zentrale
Kontrolle über den gesamten Replikationsvorgang und dessen erfolgreichen Abschluss. Die notwendigen
Informationen kann er aus einem angebundenen, zentralisierten Reporting auslesen, was
gegebenenfalls die Fehlersuche erleichtert. Allerdings ist diese stark zentralisierte
Replikationstechnik auch recht störanfällig, da Flaschenhälse beim Quellrechner und den Fileservern
entstehen. Wenn diese Quellen durch zahlreiche gleichzeitige Anfragen überlastet sind oder gar
ausfallen, beeinträchtigt dies den zeitnahen Erfolg einer Replikation. Dies kann auch den gesamten
IT-Betrieb empfindlich stören. Hier kann eine entfernte Unternehmensniederlassung damit leicht im
Nachteil sein. Insbesondere bei zeitkritischen Hotfixes oder dringlichen Datenänderungen treten
somit schnell Probleme auf.
"Spinnennetz"- Replikation
Das P2P-Verfahren (Peer-to-Peer) 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 die Anzahl notwendiger
Fileserver. So 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 oder Dateifragmente erfolgt dabei mittels Prüfsummen (Checksums).
Angewandt auf die Datenreplikation kann das P2P-Prinzip bei einer Systemmanagementlösung
beispielsweise wie folgt aussehen: Für die Replikation eines bestimmten Verzeichnisses erteilt der
Systemmanagementserver dem Quellrechner den Auftrag, einen Katalog vom entsprechenden Verzeichnis
anzufertigen. Diese Katalogdatei enthält die gesamte Verzeichnisstruktur, Namen, Attribute sowie
Prüfsummen aller Dateien. Der Quellrechner bildet von der Katalogdatei wiederum die Prüfsumme und
überträgt diesen Fingerabdruck an den Server. Zusammen mit dem Jobnamen sendet der verwaltende
Server die Prüfsumme via UDP an die Client-Agenten.
Aufgrund des angegebenen Release-Zeitpunkts 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 Prüfsummenkatalog und führt einen Soll-Ist-Vergleich durch. Fehlen auf dem Client
Dateien, so fragt der Agent diese 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-Prüfsummen bereits mittels Broadcast von welchem Rechner gesucht wurden. So fragen sie 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 Prüfsumme an einen Rechner im benachbarten Subnetz. So fragt sich der Agent
gegebenenfalls bis zur Quelle durch. Hat er alle Daten vollständig auf seinem Rechner in das
entsprechende Verzeichnis repliziert, gibt er gegebenenfalls den anderen Agenten in seinem Subnetz
Bescheid. Diese können dann die fehlenden Dateien von dem Rechner kopieren.
Bottlenecks vermeiden
Der Hauptvorteil der P2P-Vorgehensweise besteht in der Vermeidung von Flaschenhälsen: Durch die
dezentrale Struktur stellt die Überlastung oder der Ausfall eines Rechners für den
Replikationsablauf kein Problem dar. Gerade bei Remote-Replikation ist dies von entscheidender
Bedeutung: Da bei der P2P-Replikation ein Soll-Ist-Abgleich mit eindeutigen Prüfsummen vor einer
Datenübertragung stattfindet, lässt sich die Mehrfachübertragung identischer Dateien vermeiden und
so die Netzwerklast gering halten. Zur Schonung der verfügbaren Bandbreite trägt auch bei, dass
jede zu replizierende Datei nur einmal in jedes Subnetz übertragen wird und sich dort nach dem
P2P-Prinzip selbst weiter verteilt.
Allerdings basiert dieses P2P-Verfahren auf einer agentenbasierten Systemmanagementlösung;
agentenlos lässt es sich eher schwer implementieren. Die Kontrolle und Dokumentation dezentral
ablaufender Replikationsvorgänge ist etwas schwieriger zu realisieren als bei einer linearen,
zentralistischen Vorgehensweise. In der Systemmanagementlösung muss ein entsprechendes Reporting
dann auf andere Weise implementiert sein. Eine stets aktuelle Übersicht über den
Replikationsfortschritt lässt sich hier durch kontinuierliche Statusmeldungen von allen Clients an
eine zentrale Stelle erreichen. Die 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 die zentral gesammelten Daten in Echtzeit vor und lassen sie sich mithilfe einer Datenbank
übersichtlich auswerten, erhält der Administrator Aufschluss über die aktuelle Menge gesendeter und
empfangener Suchanfragen, die Zahl der Verbindungen, die Übertragungsgeschwindigkeit, die Zahl
gesendeter und empfangener Dateien sowie die bisher übertragene Datenmenge.
Unabhängig davon, nach welcher Methode die Daten repliziert wurden, sollte die Managementlösung
im Anschluss sicherstellen, dass Anwender die Dateien nicht manipulieren können. Dies erfolgt
üblicherweise durch die Überwachung des entsprechenden Verzeichnisses auf den Client-Systemen.
Dafür kann sich der Systemmanagementagent beispielsweise vom Betriebssystem informieren lassen,
wenn in den betroffenen Verzeichnissen Änderungen erfolgen. Wurde eine Änderung bemerkt, kann der
Agent den Sollzustand umgehend wiederherstellen, indem er auf Cache-Algorithmen zurückgreift, die
analog zur Technik der Windows-Schattenkopie funktioniert: Dafür muss er nur den Hard Link zwischen
physikalischem und virtuellem Speicherort wieder neu setzen. So 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 Prüfsummen und schickt diese Information an den Server. Der Server erstellt dann einen
neuen Auftrag und der Replikationsvorgang beginnt von vorn.
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-Managerfreigaben beruht. Sie ist aber im Vergleich zum P2P-Modell unter Umständen auch
langsamer, in jedem Fall aber wesentlich ressourcenintensiver und störanfälliger.
Die historisch gewachsene Orientierung am Serverfokus hat angesichts heutiger leistungsfähiger
Client-PCs ausgedient. Auf P2P-Basis ist ein sich selbst steuerndes und nahezu wartungsfreies
Replikationsverfahren implementierbar.
Lesen Sie mehr zum Thema
