Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Warum überhaupt Verteilung und wohin mit den Daten?


08.06.1990 - 

Gefragt sind leistungsfähige Alternativen für die Verteilung

Die Frage, wie man die immer leistungsfähigeren PCs im Verbund mit einem Großrechner am besten betreiben könnte, gewinnt immer mehr an Bedeutung. Die verteilte Datenverarbeitung bietet sich in diesem Zusammenhang als zukunftsträchtige Lösung an.

Die bis heute intensiv geführte Diskussion über geeignete Verteilungskonzepte darf dabei jedoch nicht vergessen werden.

Das seit langem diskutierte, auf dem Two-Phase-Commit basierende Konzept durchgängig synchroner Operationen auf allen Knoten eines Rechnernetzes wirft in der Praxis eine Reihe von Problemen auf. Mit der asynchronen Verarbeitung auf Basis des Master-Slave-Prinzips bietet sich eine leistungsfähige, praxisgerechte Alternative als Einstieg an.

Die Entwicklung der PC-Technik wird in einem atemberaubenden Tempo vorangetrieben. Mittlerweile bietet sich auch in professionellen Umgebungen die Möglichkeit, dem einzelnen Benutzer an seinem Arbeitsplatz unter einer benutzerfreundlichen Oberfläche eine erstaunliche Rechnerleistung bereitzustellen. Die Idee der verteilten Datenverarbeitung in einem heterogenen Netz von Rechnern unterschiedlicher Größe gewinnt dadurch noch mehr Reiz.

Strikte Trennung von Daten und Anwendungen

Doch wie können die Vorteile dieser Rechner mit denen der Großrechner verbunden werden? Eine abstrakt geführte Diskussion wird wohl am besten die Perspektiven aufzeigen können, die eine angemessene Antwort auf die Frage "Wohin mit den Daten im PC-Host-Verbund" geben können.

Warum sollen die Daten überhaupt verteilt werden? Reichte es nicht aus, die Daten auf einem zentralen Rechner zu belassen und die Anwendungen auf die Arbeitsplatzrechner zu legen, von wo aus sie auf den zentralen Datenbestand zugreifen können? Eine solche strikte Trennung von Daten und Anwendungen liegt den meisten heute propagierten Vorstellungen von einer Client-Server-Architektur zugrunde, die in der Diskussion zunehmend an Bedeutung gewinnt. Aus verschiedenen Gründen sollte diese Trennung jedoch aufgehoben werden. Die Stichworte sind "Verfügbarkeit" und "Antwortzeit".

Es ist nicht einzusehen, warum die einzelnen Rechner auf den Netzknoten mit ihrem hohen eigenen Leistungspotential von dem Betriebsstatus eines zentralen Rechners oder der Verfügbarkeit der entsprechenden Datenleitungen abhängig gemacht werden sollen. Letzteres gilt besonders bei Wide Area Networks, doch auch in LANs steigt mit zunehmender Komplexität des Netzwerkes die Gefahr von Netzausfällen.

Insbesondere in Fernnetzen lassen sich die notwendigen Leitungsgeschwindigkeiten auf längere Zeit nicht verwirklichen. Selbst für heutige Verhältnisse schnelle Fernleitungen mit einer Übertragungsrate von 64 000 Baud brauchen für einfache Übertragungen eine verhältnismäßig lange Zeit (siehe Kasten Rechenexempel). Das Problem vergrößert sich noch, wenn die Komplexität der Transaktionen und Paketvermittlungsdienste mit in Rechnung gestellt wird. Die für eine bestimmte Aufgabe notwendigen Daten sollten daher von vornherein am Arbeitsplatz vorIiegen.

Es kann sinnvoll sein, die auf dem logischen Niveau einheitliche Datenbasis physisch nach Feldinhalten auf die Rechner zu verteilen und zu partitionieren, zum Beispiel Hamburger Kunden auf den Rechner in Hamburg, Münchner Kunden auf den Rechner in München, oder zu replizieren, also bestimmte Daten aus Gründen der Performance und Verfügbarkeit bewußt mehrfach zu halten, zum Beispiel Hamburger Artikel Sowohl in Hamburg als auch in der Zentrale in München.

Beträchtlicher Aufwand für die ideale Verteilung

Als geeignete Technologie, dieses Ziel zu erreichen, hat sich in der bisherigen Diskussion die verteilte Datenverarbeitung auf Basis des Two-Phase-Commit herauskristallisiert. Dynamik und Reiz gewinnt dieses Konzept vor allem daraus, daß es zugleich der logisch nächste Schritt in der Entwicklung der Datenbanktechnologie ist. Nachdem den Anwendungen bereits die physische Datenunabhängigkeit auf einem Rechner beschert worden war und Datenkonsistenz sowie -integrität durch das DBMS gesichert wurden, könnte jetzt eine völlig transparente Verarbeitung der Daten auch unabhängig von ihrer physischen Verteilung über die einzelnen Rechner erreicht werden.

Wer jedoch verteilte Datenverarbeitung will, muß VorstelIungen entwickeln, wie die lntegrität der Daten sicherzustellen ist. Das Optimum, das mit dem Konzept des Two-Phase-Commit erreicht werden kann, ist, daß sämtliche Änderungen der Daten synchron auf allen Knoten durchgeführt werden. Die auf die Knoten replizierten Daten dürfen also zu keinem Zeitpunkt divergieren. Dies bedarf aber eines beträchtlichen Aufwandes.

Kein Zugriff auf lokale Datenbanken

Zum Beispiel sind spezielle Verfahren nötig, wenn eine oder mehrere Kopien auf den verteilten Rechnerknoten nicht verfügbar sind. Bei den strengen Anforderungen an die Synchronisation kann darüber hinaus noch nicht einmal diejenige Kopie gelesen werden, die zeitweilig keine Verbindung zum übrigen Netzwerk hat.

Außerdem muß auf alle teilnehmenden Knoten gewartet werden, bis sie entweder das Ende der Transaktion melden (ET beziehungsweise Commit) oder bis ermittelt ist, daß einige Knoten zeitweilig nicht angeschlossen sind. Während dieser Zeit wird nicht nur die Abarbeitung des aufrufenden Programms verzögert, sondern alle Datensperren müssen aufrechterhalten werden, und die anderen Ressourcen bleiben gebunden. Wird ein ausgefallener Knoten wieder ans Netz angeschlossen, muß ein spezielles Resynchronisationsverfahren ablaufen, währenddessen kein Benutzerzugriff auf die lokale Datenbank erlaubt ist.

Two-Phase-Commit: Lohnt sich der Aufwand?

Es hat sich mittlerweile gezeigt, daß dieser Overhead an Ressourcen für den Two-Phase-Commit und die damit zusammenhängenden Performance-Schwierigkeiten lange Zeit unterschätzt worden sind. Mittlerweile mehren sich daher die Stimmen, die fragen, ob die meisten Anwender diese reine verteilte Datenverarbeitung mit dem sekundengleichen Update auf sämtliche Knoten tatsächlich benötigen.

Oder anders gefragt: Welchen Preis will man für das technisch Machbare zahlen? Eine Frage, die dem Puristen zuwider sein mag, die aber in der Realität kommerzieller Datenverarbeitung durchaus praktisch entschieden wird, zumal die Systeme häufig ohnehin schon die Grenze ihrer Belastbarkeit erreicht haben. Von großen Fluggesellschaften zum Beispiel ist bekannt, daß ihre Buchungssysteme ohne Transaktionsverarbeitung laufen. Im Zweifel wird eher einer Doppelbelegung durch organisatorische Maßnahmen vorgebaut oder sie billigend in Kauf genommen, statt durch den Einsatz von TP-Monitoren mit Two-Level-Lock-Protokollen aus Antwortzeiten Lieferzeiten werden zu lassen.

Nicht immer identische Daten in Kauf genommen

Ähnlich praktisch sollte man auch die Frage der verteilten Datenverarbeitung angehen. Welche Alternative kann nun demjenigen Anwender geboten werden, der nicht auf eine sekundengenaue Aktualisierung, also auf die absolut synchrone Behandlung der Daten bei allen Rechnerknoten angewiesen ist oder aus Kostengründen beziehungsweise aufgrund der vorhandenen Ressourcen darauf verzichten will? Ein asynchrones Verfahren bietet sich hier an, welches bewußt in Kauf nimmt, daß zu einem bestimmten Zeitpunkt nicht alle Rechner erreichbar und somit auch die auf die verschiedenen Knoten replizierten Daten nicht immer identisch sind.

Solch ein leistungsfähiges, asynchrones Verfahren verteilter Datenverarbeitung sollte nach dem Master-Slave-Prinzip implementiert werden. Grundlage dafür ist eine DV-Umgebung, die nach einem logischen Zentralprinzip arbeitet.

Die zentrale Master-DB hält dabei eine oder mehrere Dateien und stellt diese ganz oder teilweise als Replikate den einzelnen Knoten zur Verfügung. So kann schon hier im Vorfeld je nach den organisatorischen und fachlichen Anforderungen sowie den Datenschutzauflagen entsprechend geregelt werden, auf welche Daten des Unternehmens der einzelne Knoten überhaupt Zugriff haben darf.

Alle einfachen Lesezugriffe auf die lokalen Daten können damit unabhängig vom Status des Netzwerkes durchgeführt werden. Alle ändernden Zugriffe (Update, Store, Delete) gehen dagegen nur auf die Master-Dateien und werden dann auf die Replikate nach einem individuellen Zeittakt, der im Sekundenbereich liegen kann, verteilt. Das ändernde Programm muß dabei lediglich darauf warten, daß der Master das ET (End of Transaction) gibt. Damit ist kein weiterer Overhead für den Two-Phase-Commit oder andere Verteilungsmechanismen nötig, während das Anwendungsprogramm läuft.

Um die Sicherheit bei der Transaktionsverarbeitung sowie die Integrität der Replikate sicherzustellen, müssen noch einige andere Vorkehrungen getroffen werden. Sämtliche auf der Master-Datei durchgeführten Änderungen sind zusammen mit einer Transaktionsnummer zu protokollieren. Dies geschieht in einer Protokolldatei, die in derselben Datenbank geführt wird, die auch die Master-Datei enthält. So läßt sich die Integrität von Master- und Protokolldatei automatisch herstellen.

Zudem sollte in dieser Datenbank noch ein Distribution File definiert werden, der die genauen Angaben zu den lokalen Replikaten enthält. In jeder lokalen Datenbank, die auf die Replikate zugreift, ist schließlich noch ein Confirmation-File zu definieren. Er wird benötigt, den Status der lokalen Kopie mit den notwendigen Transaktionen aus der Protokolldatei zur Deckung zu bringen. Zu diesem Zweck enthält der Confirmation File für jedes lokale Replikat den Zeitstempel der letzten erfolgreich durchgeführten Transaktion. Diese Information nutzt der asynchrone Treiber auf dem zentralen Rechner um festzustellen, welche Transaktionen bereits auf die einzelnen Knoten durchgereicht worden sind.

Datenschutz: Zentraler Rechner als beste Lösung

Dieses hier in seinen Grundzügen knapp dargestellte Verfahren eröffnet auch eine Perspektive für die praktische Arbeit im PC-Host-Verbund. Eine sichere Transaktionsverarbeitung ist möglich, und auch die entscheidenden Security-Probleme können gelöst werden. Das führt zur wichtigen Frage. wo und wie man hochsensible Daten am besten vor unberechtigtem Zugriff schützt. Ein zentraler Rechner ist hier nach wie vor die beste Lösung. Auf PCs jedenfalls gehören solche Daten nicht, wie immer neue Skandale zeigen.

Zum anderen geht es in diesem Zusammenhang um die Frage, wie die Daten vor Zerstörung geschützt werden können. Praxisgerechte Backup- und Recovery-Verfahren müssen gerade hier etabliert werden. Denn wenn es in einem Verbund verschiedene Datenbestände gibt, die zusammen erst den Gesamtdatenbestand ergeben, dann kann auf der Ebene der PCs kein vernünftiges Verfahren gedacht werden, das diese Anforderungen erfüllt. Denn im Ernstfall lassen sich die Sicherungskopien Hunderter von PCs nicht mehr rekonstruieren. In einem Master-Slave-Konzept jedoch reicht es, wenn einfach der Master gesichert wird. Nach erfolgreichem Recovery wird dann den Knoten der konsistente Datenbestand einfach überspielt.

Tragfähige Basis auf lange Sicht

Damit hat der Anwender, der bisher in der Regel in Umgebungen mit einfachem Filetransfer gelebt hat, auf lange Sicht eine tragfähige Basis für seine verteilte Datenverarbeitung. Und er hat sich nicht den Weg verbaut für Umgebungen, in denen auch die Anwendungen selbst verteilt werden und in denen mit der Entwicklung objektorientierter Datenbanksysteme eine ganz neue Klasse verteilter Datenverarbeitung möglich sein wird.

Rechenexempel

Ein einfaches Beispiel soll das Problem der Leitungsgeschwindigkeit verdeutlichen. Der Arbeitsplatzrechner eines Reisebüros fordert vom Datenbankserver eine Hotelliste an. Die dazu notwendige Eingabenachricht möge 100 Bytes lang sein. Die Ausgabeliste umfasse pro Hotel auch 100 Bytes, und im Durchschnitt müssen zwei Seiten < 20 Zeilen durchblättert werden. Das ergibt folgende Übertragungszeiten:

1) 9600 Baud-Leitung (Baud = Bits pro Sekunde): 9600 : 8 = 1200 Bytes pro Sekunde

4100 : 1200 = 3,4 Sekunden

2) 64 000-Baud-Leitung = 48 000 Baud Nutzdaten:

48000 : 8 = 6000 Bytes pro Sekunde

4100 : 6000 = 0,7 Sekunden