Hauptseminar Informatik – SS2002
Sicherheit für Informationssysteme
Thema : Replikation, Spiegelung, Verteilung
Betreuung : Dirk Nitsche
Bearbeitung : Alexander Koch, Jan-Gregor Fischer
Stand : Sonntag, 19. Mai 2002
Inhalt:
1 MOTIVATION ... 3
2 SPIEGELUNG/ REPLIKATION ALLGEMEIN ... 3
2.1 REPLIKATION IM WWW... 4
2.2 RAID DAS „STRIPTEASE“ KONZEPT... 4
3 SICHERHEITSASPEKTE IN DATENBANKSYSTEMEN... 9
3.1 EINFÜHRUNG: ... 9
3.2 ZUGRIFFSKONTROLLE IN SQL... 11
4 VERTEILTE DATENBANKS YSTEME... 12
4.1 WAS IST EIN VERTEILTES DATENBANKSYSTEM? ... 12
4.2 DATENBANKREPLIKATION... 13
4.2.1 Replikationsstrategien... 14
4.2.1.1 Funktionaler Ablauf des Replikationsprotokolls ... 15
4.2.1.2 Abstrahierung von Kommunikationsmodellen ... 16
4.2.1.3 Aktiv... 17
4.2.1.4 Passiv/Primary Copy... 18
4.2.1.5 Semi- Aktiv/ Semi-Passiv ... 19
4.2.1.6 Eager Primary Copy... 20
4.2.1.7 Eager Update Everywhere... 20
4.2.1.7.1 With Distributed Locking ... 20
4.2.1.7.2 Based On Atomic Broadcast ... 21
4.2.1.8 Lazy Primary Copy und Lazy Update Everywhere ... 22
4.2.1.9 Certification Based ... 22
4.2.1.10 Voting- Verfahren ... 23
4.2.1.10.1 Majority Voting... 23
4.2.1.10.2 Gewichtetes Voting (Quorum consensus)... 23
4.2.1.11 Schwächere Formen der Datenreplikation... 24
4.2.1.11.1 Alternativen eines „Refreshs“... 24
4.2.1.11.2 Schnappschuß-Replikation... 25
4.2.1.11.3 Katastrophen-Recovery ... 25
4.2.1.11.4 Merge-Replikation ... 26
5 AUSBLICK UND ZUSAMMENFASSUNG... 27
6 GLOSSAR ... 28
7 ABBILDUNGSVERZEICHNIS ... 28
8 LITERATURVERZEICHNIS ... 29
1 Motivation
Lady, you are the cruel'st she alive, If you will lead these graces to the grave and leave the world no copy.
Shakespeare: Twelfth-Night
2 Spiegelung/ Replikation Allgemein
Definition der Spiegelung:
Eine Spiegelung einer Relation R ist eine identische Abbildung von R auf einen oder mehr Knoten eines Informationssystems, auf die durch Leseoperationen zugegriffen werden kann. Die dadurch auftretende Datenredundanz ist das Hauptkriterium einer Spiegelung, die somit der Mächtigkeit einer Sicherheitskopie mindestens ebenbürtig ist.
Beispiele hierfür sind u.a. gespiegelte Festplatten (RAID1-Systeme) oder gespiegelte FTP Archive Sites zur Verbesserung der lokalen Erreichbarkeit durch Lastreduzierung der einzelnen Datenspeicherinstanzen.
Definition der Replikation nach Prof. A. Kemper, Ph. D.:
Man spricht von der Replikation einer Relation R, falls eine Kopie der Relation R an zwei oder mehr Knoten eines Netzwerks gespeichert ist. Im extremsten Fall wird bei der vollen Replikation eine Kopie der Relation auf jedem Knoten des Systems gespeichert.
Diese Definition ist aus unserer Sicht nicht vollständig, sie entspricht nach einer Erweiterung der Bedingung, dass eine Kopie von R an mindestens zwei Knoten eines Netzwerks gespeichert ist, durch die Vorgabe, dass nach der Replikation R an mindestens zwei Knoten eines Informationssystems gespeichert ist, der Definition der Spiegelung.
Durch die folgende Definition schränken wir die Begriffsbestimmung einer Replikation erweitert ein:
Durch diese Erweiterung der Definition durch Kemper kann ein Unterschied zu dem Begriff der Spiegelung gebildet werden. Im Folgenden werden die maßgebenden Vor- und Nachteile einer Replikation vorgestellt:
Verfügbarkeit:
Beim Ausfall einer Replikation ist es weiterhin möglich, Anfragen an eine Replikation zu stellen, die auf einem anderen Knoten des Informationssystems gespeichert ist. Das System kann somit im Fehlerfalle eine gerade laufende Transaktion an eine andere Replikation transparent weiterleiten. Dies ist besonders interessant für Unternehmen, z.B. Banken, die einen Systemabsturz, oder einen Datenbankausfall, zum Beispiel durch einen Festplattencrash, Feuer, Überschwemmung oder Erdbeben, vermeiden müssen, und hierfür das Mittel der Replikation zur Sicherung der Datenverfügbarkeit auf Rechnern einsetzen, die meist weit entfernt von einander stehen.
Erhöhte Parallelität:
Je mehr Replikate von Daten existieren, um so umfangreicher können Leseoperationen transparent auf räumlich nahe gelegene Rechner verteilt werden, was die Bearbeitungsgeschwindigkeit von Anfragen erhöht.
Großer Kommunikationsaufwand bei Updates:
Die Datenkonsistenz (siehe Glossar) aller Replikate muss erhalten bleiben, ansonsten können fehlerhafte Anfragen auftreten. Somit ist es notwenig, alle Updates an einer Kopie an alle restlichen Replikate zu propagieren, was einen stark erhöhten Kommunikationsaufwand vor allem bei Mehrbenutzersynchronisation zur Folge hat.
Wir können zusammenfassen, dass die Methodik der Replikation zur erhöhten Verfügbarkeit von Daten beiträgt, und weiterhin einerseits die Leistung von Leseoperationen unter Umständen erheblich erhöht, jedoch Schreiboperationen durch die unumgängliche Synchronisation der Replikationen abbremst. Da im Durchschnitt jedoch die meisten Anfragen lediglich durch reinen Lesezugriff bearbeitet werden, kann man durch Datenreplikation meist eine verbesserte Performance erreichen. Dies stellt den klassischen Kompromiss zwischen Datenkonsistenz (siehe Glossar), Änderungsaufwand, sowie Verfügbarkeit dar.
2.1 Replikation im WWW
Spiegelung:
Durch die ständig steigende Anzahl von Internetbenutzern ist es nötig geworden, sehr häufig benutzte Daten auf den Webservern zu replizieren, um die Netzlast zu verteilen.
Diese Replikate werden als Spiegelungen (=“Mirrors“) bezeichnet. Sie müssen sich nicht unbedingt am selben Ort befinden. Bei weltweit populären Applikationen, die zum Download angeboten werden, befinden sich solche Spiegelungen zumeist auf mehreren Kontinenten, wie Amerika, Asien und Europa.
Nachteile von „Mirrors“ sind, die nicht selbstständige „Update“-Fähigkeit des Ursprungsservers, da sich darum ein Ad ministrator kümmern muss, sowie eine Verletzung der Transparenz. Anders formuliert, ein Benutzer muss die IP-Adresse des gespiegelten Servers kennen.
Squid Cache:
Eine weitere Form der Replikation im WWW sind Caches (Proxies). Die Idee von Squid Cache ist, mehrere Caches zu einem Verbund zusammenzufassen. Diese Verbände sind hängen meistens eng mit einer örtlichen bzw. geographischen Lage zusammen. Man kann sich das so vorstellen, greift ein Benutzer aus Europa auf Webseiten aus den USA zu, werden diese Daten zwischengespeichert, so dass einem nachfolgenden Benutzer der Datentransfer aus den USA erspart bleibt.
Das Konzept, welches dahinter steckt, versteht sich als dynamische Verbindungstopologie mit „Neighbors“ und „Parents“ (Graphentheorie). Bei einem „C ache Miss“ werden
„Neighbors“ gefragt, ob sie das gewollte Datenobjekt haben. Erst nach Ablauf einer Zeitbegrenzung, oder wenn keine „Neighbors“ dieses Objekt besitzen, wird der „Parent“
kontaktiert.
2.2 RAID das „Striptease“ Konzept
Definition:
RAID steht für Redundant Array of Inexpensive Disks. Ein RAID-System - auch „Disk Array" genannt - besteht aus einer Anzahl von Festplatten und der für den Anschluss an einen Host-Computer notwendigen Hard-, Soft- und Firmware. Von der Gesamtkapazität des RAID-Systems wird ein Teil für das Speichern redundanter Information verwendet.
Diese Informationen ermöglichen das Wiederherstellen der Daten bei Ausfall einer der
Festplatten oder deren Datenpfad. RAID ist die sinnvollste und effektivste Technologie, um Festplattenstapel abzusichern, deren Daten Online- verfügbar sein müssen.
Des weiteren erfüllt das System die notwendige Datensicherung, wie auch durch Backup- Medien. Bei großen Datenbanken ist festzustellen, dass die Zeit für ein sofortiges komplettes Restore unmöglich aufgebracht werden kann. So bauen sich die verlorenen Daten eines Disk Arrays im Hintergrund wieder auf, um die Daten der anderen Festplatten weiterhin verfügbar zu machen. Somit ist die Redundanz (also das Speichern der redundanten Daten) die wichtigste Eigenschaft eines Disk Arrays. Je größer die Anzahl der Festplatten eines Systems, desto größer wird die statistische und tatsächliche Ausfallgefahr einer der Platten. Daher gibt es unterschiedliche logische Aufbauten eines Disk Arrays, genannt RAID- Level, die wir hier im Einzelnen darstellen, wobei RAID Level höherer numerischer Ordnung diese Ausfallgefahr verringern können. Weiterhin ist zu vermerken, dass bei vielen RAID Ansätzen die Leistung durch parallele Transferoperationen unter Umständen erheblich gesteigert werden kann. Zur Geschichte des RAID Konzepts, sowie der Vergleich Hardware-Software RAID, verweisen wir auf die Ausarbeitung 2 (Vortrag Gebäudetechnik für Rechenzentren).
Die RAID-Levels:
RAID-Systeme sind Zusammenschlüsse von mehreren Festplatten, die über einen RAID- Controller angesteuert werden. In allen Bereichen, in denen ein hoher Anspruch auf Leistung und Datensicherheit gestellt wird, kommt das Verfahren zum Tragen.
Unterschieden wird RAID nach verschiedenen Stufen (=Levels), die seine Funktionsweise beschreiben.
RAID 0 – nicht redundantes Data Striping:
Die Datenblöcke werden entsprechend der eingestellten Streifengröße und der vorhandenen Festplatten in Streifen (=Stripes) aufgeteilt, wobei jeder Streifen eines Datenblocks auf einer separaten Festplatte gespeichert wird. Dadurch wird beim sequenziellen Schreiben und Lesen von großen Dateien ein höherer Datendurchsatz um den Faktor „Anzahl der RAID 0 Platten mal Datendurchsatz der langsamsten Festplatte“
erreicht. RAID 0 bietet keinerlei Redundanz. Beim Ausfall einer Festplatte sind die Daten des gesamten RAID 0 Verbandes verloren. Zusätzlich ist zu bemerken, dass die Anzahl der Streifen von der Festplatte abhängt, die die geringste Speicherkapazität aufweist.
Abbildung 1 : RAID 0
RAID 1 - Spiegeln (=Mirroring):
RAID 1 ist auch unter dem Namen „Disk Mirroring“ oder Festplattenspiegelung bekannt.
Voraussetzung für RAID 1 ist eine gerade Anzahl von Festplatten. Die Daten werden jeweils auf zwei Festplatten gespeichert. Beim Ausfall einer Platte sind die Daten identisch auf der zweiten Festplatte vorhanden. Beim Spiegeln von Festplatten an einem Kanal spricht man von „Disk Mirroring“, beim Spiegeln an unabhängigen Kanälen von
„Disk Duplexing“ (zusätzliche Sicherheit). RAID 1 ist eine einfache Lösung zur
Datensicherheit und Datenverfügbarkeit mit dem Nachteil, dass lediglich die Hälfte der Gesamtkapazität als nutzbarer Bereich zur Verfügung steht.
Abbildung 2: RAID 1
Erst ab RAID-Level 2 werden Fehlererkennungs- und Korrekturcodes auf zusätzlichen Paritätsplatten verwendet. Diese werden im weiteren Verlauf vorgestellt:
RAID 2 – Bitweise Datenverteilung mit (mehreren) Parity Platten:
RAID 2 ist ein Verfahren, das sparsamer mit dem Speicherplatz umgeht. Hierbei werden die Daten über mehrere Laufwerke verteilt, und zusätzliche Laufwerke für Paritätsdaten verwendet. Die Daten werden dabei Bitweise auf die Laufwerke verteilt. D.h. auf jedes Laufwerk einer Gruppe wird jeweils ein einziges Bit geschrieben, und zum Schluss ein Checkbit bzw. Paritätsbit auf die Paritätsplatte(n). Diese haben die Form von Fehlerkennungs- und Korrekturcodes. So kann man sich die Paritätsinformationen als eine Art Checksumme vorstellen, mit der man überprüft, ob die verwendeten Daten noch korrekt sind, und ob eine Korrigierung der Fehler durchgeführt werden muss.
Die Fehlerkorrektur mittels Paritätsinformation geschieht nun wie folgt (beschrieben nach Kemper und Eickler, Kapitel 7.2)1: „Man speichert zu N Datenbereichen, die auf unterschiedlichen Platten liegen, zusätzlich deren Prüfsumme auf einer anderen Platte ab.
Wenn nur einer dieser N Datenbereiche (bzw. deren Platte) defekt ist, kann man den Wert dieses Datenbereichs aus der Prüfsumme minus der Summe der noch intakten N-1 Datenbereiche wiederherstellen“. Als Nachteil dieses Verfahrens ist zu nennen, dass in der Regel bei hoher Plattenanzahl nach Erfahrungsberichten mindestens 30 % der Speicherkapazität für Checkdaten zu verwenden sind.
Abbildung 3: RAID 2
RAID 3 – Bit- oder byteweises Striping mit einer Parity Platte:
Die Daten werden im Gegensatz zu RAID 2 bit- oder byteweise über die verschiedenen Laufwerke verteilt abgespeichert und eine Check- bzw. Parityinformation zur Datensicherung auf einem indizierten Laufwerk für die Paritätsdaten abgelegt. Eine solche Paritätsinformation enthält „Wissen“ zur Fehlererkennung und Rekonstruktion eines gesamten Streifens, und wird wie auch bei RAID 4 durch eine exklusive Oder- Verknüpfung der bit- bzw. byteweise gestreiften Daten zusammengesetzt. Kann nun auf der Platte ein Byte nicht mehr gelesen werden, so lässt es sich einfach aus den Kontrolldaten ergänzen. Der Nachteil von RAID 3 liegt im Wesentlichen darin, dass nach jeglicher Schreiboperation die Check- bzw. Parityinformation neu eingetragen werden muss. Hierdurch wird die Datendurchsatzrate erheblich reduziert, weil paralleler Datenzugriff nicht möglich ist. Beim Lesen hingegen wird nur im Fehlerfall auf die Paritätsplatte zugegriffen.
Abbildung 4: RAID 3 RAID 4 - Blockweises Striping mit einer Parity Platte:
Wie bei RAID 0 werden die Daten Blockweise auf den Festplatten verteilt. Dabei ist ein Block üblicherweise vier bis 128 Kilobyte groß. Durch die Blockverteilung kann RAID 4 effizienter mit kleinen Leseanforderungen als RAID 3 umgehen. Allerdings zu Lasten von Schreiboperationen, da der Inhalt des Daten- und des Paritätsblocks gelesen und daraufhin geschrieben werden muss. Wiederum werden Paritätsdaten auf einem Sicherheitslaufwerk abgelegt. Durch diese Parität stehen bei einem Ausfall einer Festplatte alle Daten weiterhin zur Verfügung. Lediglich die Kapazität einer Festplatte geht für die Redundanz verloren.
Abbildung 5: RAID 4 RAID 5 - Blockweises Striping mit verteilter Parity:
Die Nachteile der RAID-Levels 2, 3 und 4 wurden erst mit der fünften Generation von RAID-Levels ausgeglichen. In der RAID-Ebene 5 wurde ein Verfahren entwickelt, das auf ein eigenes Laufwerk oder eigene Laufwerke für Prüfdaten verzichtet. Die Daten für die Fehlerkorrektur sind dabei über alle Festplatten verteilt. Da nun nach einer Schreiboperation nicht auf ein und dasselbe Laufwerk für die Fehlerkorrekturdaten zugegriffen werden muss, lässt sich die Fähigkeit der Plattenarrays, auf alle Laufwerke gleichzeitig zuzugreifen, effizienter nützen. Die Problematik des Prüfdatenzugriffs ist insofern entschärft, als für eine Schreiboperation nur in besonderen Fällen eine parallele Durchführung nicht mehr möglich ist.
Abbildung 6: RAID 5
RAID 6 – P+Q Redundanz:
Zur Wiederholung: Parität ist eine Art Redundanz Code zur Fehlerkorrektur, welcher in der Lage ist, jeden einzelnen Fehler, der vom System erkannt wird, zu korrigieren. Bei der Verwendung von „Disk Arrays“ ist es wünschenswert eine bessere Fehlerkorrektur zu besitzen, die mehrere Plattenfehler tolerieren kann. Tritt ein Plattenabsturz in einem Parität geschützten „Disk Array“ auf, so muss das System die Möglichkeit haben die Inhalte aller nicht abgestürzten Platten zu lesen, um die defekte Platte wiederherzustellen.
Die Wahrscheinlichkeit, dass ein nicht korrigierbarer Fehler während der Wiederherstellung auftritt, ist demnach nicht zu vernachlässigen. Um eine noch höhere Datenintegrität zu gewährleisten, wurde somit ein neues RAID Schema eingeführt.
Dieses Schema, welches man als P+Q Redundanz oder auch als RAID 6 bezeichnet, verwendet Reed-Solomon Fehlerkorrektur-Codes (siehe Glossar) um sich gegen bis zu zwei Plattenausfälle zu wappnen. Von der Struktur und von den Operationen betrachtet, ist die RAID 6 Ebene ähnlich wie RAID 5. Sie führt „kleine“ Schreiboperationen mit der Verwendung einer Lese-Modifizier-Schreib-Prozedur aus, wie auch bei RAID 5, mit dem Unterschied, dass anstatt vier Schreibzugriffen sechs an der Zahl durchgeführt werden.
Dies ist Notwendig, da sowohl die „P“, als auch die „Q“ Informationen zusätzlich geupdatet werden müssen. Die Rekonstruktion der Daten erfolgt aus der Checksumme bzw. Paritätsinformation einer der beiden Paritäten P oder Q.
Abbildung 7: RAID 6 RAID 7 – „der Alleskönner“:
Auch RAID 7 ist ähnlich wie RAID 5 aufgebaut. In der RAID-Steuereinheit wird bei RAID 7 aber zusätzlich ein lokales Echtzeitbetriebssystem eingesetzt. RAID 7 benutzt schnelle Datenbusse und mehrere größere Pufferspeicher. Die Daten in den Pufferspeichern und auf den Laufwerken sind von der Datenübertragung auf dem Bus abgekoppelt (asynchron). So werden alle Vorgänge gege nüber den anderen Verfahren erheblich beschleunigt. Ähnlich wie bei RAID 6 kann die Paritätsinformation für eines oder mehrere Laufwerke generiert werden. Es lassen sich gleichzeitig unterschiedliche RAID-Level nutzen.
Weitere RAID Ebenen, alles Kombinationen bisheriger Ebenen, die hier aus Gründen der Vollständigkeit aufgeführt werden:
RAID 1 0:
Eigentlich handelt es sich bei RAID 1 0 nicht um einen eigenen RAID- Level, sondern lediglich um die Kombination von RAID 1 mit RAID 0. Damit werden die Eigenschaften der beiden Ebenen Sicherheit und sequentielle Performance vereinigt.
Bei RAID 1 0 werden üblicherweise vier Festplatten verwendet, denn dieses System verlangt nach zwei Paaren gespiegelter Arrays, die dann zu einem RAID-0-Array zusammengefasst werden. RAID 1 0 eignet sich insbesondere zur redundanten Speicherung von großen Dateien. Da hierbei keine Parität berechnet werden muss, sind die Schreibzugriffe mit RAID 1 0 sehr schnell. RAID 1 0 gilt übrigens auch als zusätzlich gestreifte Version von RAID 1.
RAID 3 0:
RAID 3 0 wird eingesetzt, wenn große Dateien sequentiell übertragen werden sollen. Es handelt sich auch um eine zusätzlich gestreifte Version von RAID 3. Diese Version wurde von AMI (American Megatrends) entwickelt. Sie bietet Datensicherheit und sehr hohen
Durchsatz. RAID 3 0 ist komplexer als niedrigere RAID- Level und benötigt mehr Platten.
AMI verwendet RAID 3 0 mit sechs Festplatten.
RAID 5 0:
Werden sowohl große Datensicherheit wie auch schnelle Zugriffszeiten und hohe Datentransfer-Raten benötigt, empfiehlt sich RAID 5 0. Auch diese Version stammt von AMI. Sie ist ebenfalls komplexer als niedrigere RAID- Level und benötigt ebenfalls sechs Festplatten. RAID 5 0 ist die gestreifte Version von RAID 5.
Neben den oben genannten Kombination gibt es noch eine Vielzahl weiterer. Meistens handelt es sich dabei um maßgeschneiderte Lösungen in Betrieben. Da aber keine wirklich neuen Konzepte vorgestellt werden, entfällt die Beschreibung dieser.
3 Sicherheitsaspekte in Datenbanksystemen
3.1 Einführung:
Dieser Abschnitt gibt eine Einführung in die grundlegenden Sicherheitsaspekte einer Datenbank. Dabei wird unter anderem ein kurzer Überblick über die absichtliche Schädigung und Enthüllug von sensitiven Daten, Kategorien von Schutzmechanismen, sowie die Zugriffskontrolle in SQL behandelt.
Eine detailliertere Beschreibung, sowie Sicherheitsstrategien wird in einem der kommenden Vorträge „sichere Betriebssysteme, sichere Datenbanksysteme“ behandelt. Im folgenden werden die einzelnen Sicherheitskategorien und einige Sicherheitsstrategien („Policies“) kurz beschrieben:
Identifikation und Authentisierung:
Wie bereits ausführlichst in anderen Vorträgen und Ausarbeitungen erläutert, muss sich der Benutzer um sich Zugang zu einem Datenbanksystem zu schaffen, zunächst einmal identifizieren. Dies kann beispielsweise durch Eingabe des Benutzernamens erfolgen. Die Authentisierung überprüft daraufhin, ob es sich bei den Benutzern auch wirklich um die Person handelt, für die sie sich ausgibt. Normalerweise werden hierzu Paßwörter verwendet.
Autorisierung und Zugriffskontrolle:
Eine Autorisierung besteht aus Regeln, die die erlaubten Arten des Zugriffs auf Sicherheitsobjekte durch Sicherheitssubjekte definieren. Ein Sicherheitsobjekt ist eine passive Entität, die Informationen beinhaltet, wie z.B. ein Tupel oder ein Attribut. Ein Sicherheitssubjekt ist eine aktive Entität, die einen Informationsfluß bewirkt.
Sicherheitssubjekte können Benutzer, Gruppen, Datenbankprozesse bzw.
Anwendungsprogramme sein.
Die Autorisierung stellt sicher, dass alle direkten Zugriffe zu den System Objekten gemäss der Privilegien und deren Zugriffsrichtlinien erfolgen. Man unterscheidet hierbei zwischen
„Mandatory- “ und „Discretionary Access Control“ (kurz: MAC, DAC). Die
„Discretionary“ Zugriffsrichtlinien spezifizieren die Benutzerrechte auf unterschiedliche Systemressourcen und beinhalten ausserdem die Möglichkeit eines Benutzers, seine Rechte weiter zu geben. Man spricht von der „Mandatory“ Zugriffskontrolle, wenn Objekten des Systems sogenannte Sicherheitsmarken („security labels“) zugewiesen
werden, die einen Zugriff einschränken können. Letztere findet in Multi- Level Datenbanken Verwendung. Näheres dazu in Vortrag 9.
Zuverlässigkeit und Auditing:
Dienen dazu über alle Zugriffe einer Datenbank Buch zu führen, um deren physische Integrität zu wahren, und eine Analyse des Zugriffsprofils durchführen zu können.
Schäden können somit rechtzeitig erkannt und beseitigt werden.
Inferenz:
Bezeichnet das sich Erschliessen von Daten, aufgrund von öffentlicher Informationsverbreitung. Dieses Wissen über Daten muss nicht unbedingt aus einer Datenbank stammen. Die Inferenz Richtlinie legt somit fest, wie man klassifizierte Informationen vor der Enthüllung oder Verbreitung schützt, falls diese indirekt veröffentlicht werden.
Konsistenz:
Sie umfasst die betriebliche, semantische, und physische Integrität einer Datenbank und bestimmt, ob sich diese in einem gültigen bzw. korrekten Zustand befindet.
Die betriebliche Integrität gewährleistet die logische Konsistenz der Daten in einer Datenbank während der Ausführung verteilter Transaktionen. Die semantische Integrität beschreibt die logische Konsistenz von veränderten Daten, indem sie mit Hilfe von Kontrolldatenwerten die inhaltliche Vollständigkeit und Fehlerfreiheit sicherstellt. Die physische Integrität zielt darauf, die Datenbank immun oder reparierbar gegen physische Bedrohungen, z.B. Stromausfälle, zu machen.
Abbildung 8 : „Späßle“
Um seine Daten zu schützen, d.h. gegen unbefugten Zugriff abzusichern, müssen die Schwachstellen eines Systems bekannt sein und konsequent versucht werden, diese auszumerzen. Folgende Angriffspunkte sind vorstellbar:
Mißbrauch von Autorität:
Diebstahl, Veränderung oder Zerstörung von Daten oder Programmen.
Inferenz und Aggregation:
Inferenz siehe oben. Unter Aggregation versteht man, dass einzelne Daten öffentlich zugänglich und nicht sicherheitsrelevant sind. Eine Vielzahl von Daten zusammen genommen unter Umständen aber schon. Ein Beispiel für Inferenz ist der Informationsgewinn der Note eines Studenten, falls diese zusammen mit der Matrikelnummer veröffentlicht ist, und der Name des betroffenen Studenten beispielsweise zusammen mit seiner Matrikelnummer auf einer beliebigen Liste (z.B.:
Anwesenheitsliste, Matrikelnummer mit Unterschrift) erfaßt ist. Ein Angriffspunkt mittels Aggregation beschreibt beispielsweise den Informationsschluß über den statistischen
Alkoholgenuß einer einzelnen Person durch häufige Beobachtung des Trinkverhaltens die ser Person. Man bezeichnet dies als Aggregation, und nicht als Inferenz, da die Beobachtung eines einzelnen Zeitpunktes, an dem die Person Alkohol drinkt, nicht den Schluß zuläßt, daß ein Alkoholproblem vorliegt. Prost!
Maskierung:
Unautorisierter Zugriff auf Daten durch eine Person, die sich als ein autorisierter Benutzer ausgibt. Dabei erfolgt eine Umgehung der Zugriffskontrolle. Dies ist durch ausspionieren eines Passwortes möglich, oder die Ausnutzung von Sicherheitslücken im Betriebssystemcode oder in Anwendungsprogrammen.
Browsing:
Sicherheitsrelevante Informationen können zum Teil in Dateinamen oder Verzeichnisstrukturen enthalten sein. Dies bietet dem Angreifer weiterhin die Möglichkeit, seine Angriffe gezielt durchzuführen.
Trojanische Pferde & Versteckte Kanäle:
Wurden bereits in vergangenen Vorträgen erörtert.
3.2 Zugriffskontrolle in SQL
Im SQL-92 Standard existieren zwei Befehle zur Zugriffskontrolle. Einer um Rechte zu vergeben (grant), und einer um Rechte zu entziehen (revoke). Normen für Authe ntisierung und Protokollierung werden nicht aufgestellt. Diese erwähnten Befehle sind in das oben beschriebene DAC-Modell einzuordnen. Die Untestützung von MAC findet aber trotzdem Verwendung in kommerziellen Datenbanksystemen. Wir verweisen dazu auf den nachfolgenden Vortrag „Implementierungen“.
Beispiel (grant, revoke):
• grant select on employee to username;
• revoke select on employee from username cascade;
Die Verwaltung einer Datenbank ist dem DB- Administrator überlassen. Mit einer speziellen Systemkennung hat er Zugriff auf alle Daten und Funktionen der Datenbank.
Somit ist er auch verantwortlich für die Zugriffskontrolle bzw. Rechtevergabe. Da der DB- Administrator praktisch über alle Rechte einer Datenbank verfügt, kann ein Missbrauch seinerseits etwa über eine Protokollierung seiner Aktivitäten erfolgen, oder eine Überwachung durch eine gleichwertige oder höhere Instanz, sofern der Datenbankadministrator dem Systemadministrator bzgl. der Benutzerrechte untergestellt ist. Modelle hierzu wurden bereits in vorherigen Vorträgen erläutert.
Identifikation und Authentisierung:
Das Konzept der Identifikation und Authentisierung wurde bereits ausgiebig beschrieben.
Ein Benutzer identifiziert sich über einen Login und authentifiziert sich über sein Passwort.
Beispiel (Benutzer hinzufügen):
• create user username identified externally;
Autorisierung und Zugriffskontrolle:
Eine Autorisierung erfolgt mit dem grant-Kommando. Außer select existieren in SQL noch die Standardprivilegien delete, insert, update und references. Mit der Autorisierung über die Rechte insert, update und references ist es Möglich den Zugriff auf bestimmte Attribute einer Relation zu gewährleisen und/ oder einzuschränken. Das references- Privileg erlaubt Benutzern, Fremdschlüssel auf ein bestimmtes Attribut anzulegen. Somit kann ein Benutzer, aufgrund der referentiellen Integrität, daran gehindert werden, Datentupel aus einer Relation zu entfernen.
Sichten:
Mit Hilfe von Sichten ist man in der Lage, Daten vor nicht autorisierten Benutzern zu verschleiern. Dies geschieht, indem man auf eine Relation eine Sicht mit einer bestimmten Bedingung erzeugt. Man stelle sich beispielsweise eine Firma vor, in der nur Mitarbeiter einer Abteilung Zugriff auf öffentliche Daten von Mitarbeiter derselben Abteilung haben:
Beispiel:
• create view employee123 as select * from employee where department=123;
Weiterhin können aggregierte Sichten zur Informationsenthaltung nicht autorisierter Benutzer dienen, da sie keine exakten Datentupel, sondern statistische (aggregierte) Daten enthalten. Es ist aber hierbei auf den Informationsgehalt zu achten, da ansonsten wieder die Gefahr von Inferenz (siehe oben) besteht.
Auditing:
Der SQL-92 Standard beinhaltet keine Protokollierbefehle eines Datenbanksystems. In IBM-DB2 jedoch, wie auch in den meisten anderen DBS, wird der Befehl audit zur Protokollierung verwendet. Es können beispielsweise fehlgeschlagende Zugriffe protokolliert werden, um den eventuellen Angriff nachzuverfolgen.
Beispiel:
• db2audit configure scope objmaint, secmaint status failure (Protokollierung aller fehlgeschlagenen Operationen)
Nicht zu vernachlässigen ist der mit dem Auditing verbundene Zusatzaufwand für das Datenbanksystem. Deshalb sollte man sich genau überlegen, welche Protokolldaten überhaupt notwendig oder von Interesse sind.
4 Verteilte Datenbanksysteme
4.1 Was ist ein verteiltes Datenbanksystem?
Definition (nach Ceri und Pelagatti 1984 aus Datenbanksysteme, Eine Einführung1):
„Eine verteilte Datenbank besteht aus einer Sammlung von Informationseinheiten, die auf mehreren über ein Kommunikationsnetz∗ miteinander verbundenen Rechnern verteilt ist.
Jede Station des Netzwerks kann autonom lokal verfügbare Daten verarbeiten und somit lokale Anwendungen, ohne Einbeziehung anderer Stationen, ausführen. Jede Station des verteilten Datenbanksystems (VDBS) nimmt aber zusätzlich an mindestens einer globalen Aufgabe teil, die über das Kommunikationsnetz abgewickelt wird.“
∗ LAN, WAN, Telefonverbindungen
Kommunikations- netz DB 4DB 4
DB 3DB 3
DB 2DB 2 DB 1DB 1
Station 3 Station 3
Station 2 Station 2 Station 4
Station 4
Station 1 Station 1
Kommunikations- netz DB 4DB 4
DB 3DB 3
DB 2DB 2 DB 1DB 1
Station 3 Station 3
Station 2 Station 2 Station 4
Station 4
Station 1 Station 1
Abbildung 9 : Verteiltes Datenbanksystem (Beispiel mit 4 Stationen)
Mit dem idealenverteilten Datenbanksystem können Datenbestände, welche auf beliebig vielen verschiedenen Rechnern, die unterschiedliche Betriebssysteme verwenden, über verschiedene Protokolle kommunizieren, und in heterogenen lokalen Datenbanksystemen gespeichert werden, so dass jedes beliebige Anwendungsprogramm beziehungsweise jeder Anwender den Eindruck hat, die Daten würden an einem Ort, in einem Datenbanksystem verwaltet werden (Verteilungstransparenz).
Das verteilte Datenbanksystem hat dafür zu sorgen, dass bei Änderungsoperationen die erforderlichen Modifikationen an allen Stellen in konsistenter Weise durchgeführt werden.
Fehlersituationen wie etwa Ausfälle von Knoten, Kommunikationsverbindungen etc.
werden soweit wie möglich von den Anwendungsprogrammen bzw. Anwendern verborgen gehalten.
4.2 Datenbankreplikation
Definition der Replikation bei Verteilten Datenbanksystemen nach der Übersetzung aus den im Englischen aufgestellten Oracle8i Concepts Release 8.1.52:
Replikation ist der Prozess des Kopierens und Instandhaltens von Datenbankobjekten in Mehrrechnerdatenbanken, die ein verteiltes Datenbanksystem bilden. Änderungen, die an einem Replikat ausgeführt werden sollen, werden erfasst und lokal gespeichert, bevor sie zu jeder der entfernten Informationsknoten weitergeleitet und angewendet werden. Die Replikation stellt dem Benutzer einen schnellen lokalen Zugriff zu gemeinsamen Daten zur Verfügung, und schützt die Verfügbarkeit von Applikationen, da alternative Datenzugriffsoptionen existieren. Selbst wenn ein Replikat nicht mehr verfügbar ist, können die Benutzer weiterhin Anfragen oder sogar Änderungen bei den verbleibenden Replikaten durchführen.
Abbildung 10 : Allgemeines Replikationsmodell
Abbildung 11 gibt einen Überblick über die im Verlaufe näher erläuterten Replikationsstrategien. Es sei an dieser Stelle erwähnt, dass die Begriffe Replikationsstrategie und Replikationsmodell synonym verwendet werden.
4.2.1 Replikationsstrategien
Replikationsstrategien:
Replikationsstrategien:
strenge Konsistenz
strenge Konsistenz schwache Konsistenzschwache Konsistenz
synchron (eager)
synchron (eager) asynchron (lazy)asynchron (lazy) asynchron (lazy)asynchron (lazy)
nn 11 nn 11
•ROWA
•Voting
•Primary Copy (mit lesen aktueller Daten)
•Merge- Replikation („Update Anywhere“)
•Primary Copy mit Lesen veralteter Daten
•Schnappschuss - Replikation
•Standby- Replikation Korrektheitsziel
Refresh-Zeitpunkt Anzahl der Änderer pro Objekt
Beispiel-Strategien
Replikationsstrategien:
Replikationsstrategien:
strenge Konsistenz
strenge Konsistenz schwache Konsistenzschwache Konsistenz
synchron (eager)
synchron (eager) asynchron (lazy)asynchron (lazy) asynchron (lazy)asynchron (lazy)
nn 11 nn 11
•ROWA
•Voting
•Primary Copy (mit lesen aktueller Daten)
•Merge- Replikation („Update Anywhere“)
•Primary Copy mit Lesen veralteter Daten
•Schnappschuss - Replikation
•Standby- Replikation Korrektheitsziel
Refresh-Zeitpunkt Anzahl der Änderer pro Objekt
Beispiel-Strategien
Abbildung 11: Überblick Replikationsstrategien bei verteilten Datenbanksystemen
Die nachfolgend aufgeführten Differenzierungen von Replikationsmodellen wurden der wissenschaftlichen Ausarbeitung „Understanding Replication in Databases and Distributed Systems“3 entnommen. Hiernach unterteilen wir Replikationen im Folgenden nach zwei Kriterien:
Vorgehensweise des Propagierens von Änderungen (Refresh Zeitpunkt):
Man unterscheidet hier zwischen Eager Replication, wobei bei Änderungen alle Instanzen innerhalb der selben Transaktion synchron in den neuen Zustand versetzt werden, und Lazy Replication, die nach einer Änderungen das Update durch einzelne Transaktionen asynchron an die verbleibenden Instanzen weiter propagiert.
Besitzrechte an einem replizierten Objekt:
Weiterhin differenzieren wir zwischen Group Replication und Master Replication:
Die Group Replication erlaubt jedem Informationsknoten mit replizierten Daten, diese zu updaten. Bei der Master Replication haben alle Replikate einen Master Knoten, der als einzige Instanz ein Update durchführen kann. Auf die übrigen Replikate ist nur ein
Lesezugriff gestattet. Um auch hier das Update durchzuführen, muss der Master Knoten dazu aufgefordert werden.
4.2.1.1 Funktionaler Ablauf des Replikationsprotokolls
Der Ablauf einer Anfrage eines Client Rechners an eine (oder mehrere) replizierte Datenbanken verläuft in fünf Schritten. Die Modelle in den nachfolgenden Unterabschnitten verwenden jedoch nicht immer alle Phasen, durchlaufen diese in unterschiedlicher Anordnung, iterieren über die einzelnen Schritte, oder fassen unterschiedlich Phasen zu einer komplexeren Struktur zusammen. Im allgemeinen Modell stellt der Client Rechner einen Request an eine (oder mehrere) Replikate, woraufhin die Replikationsserver untereinander kommunizieren, um die Anfrage des Client Rechners zu synchronisieren. Diesen Vorgang nennt man Server Coordination. Nach der Execution, also der Ausführung der Anfrage auf den Replikationsservern, muss jedes einzelne Replikat dem Ergebnis der Ausführung zustimmen, um die Atomarität der Anfrageausführung zu wahren (Agreement Coordination). Letztendlich erfolgt der Response, das Anfrageergebnis wird zum Client Rechner übertragen. Die einzelnen Phasen des Replikationsprotokolls werden im Folgenden näher erläutert.
Request: Der Client kann eine Anfrage an das System entweder direkt an alle Replikate stellen (aktives Replikationsmodell), oder lediglich an eine Einzige, die diese während der Server Coordination Phase an alle anderen Replikate propagiert (passives Replikationsmodell). Da bei Datenbanksystemen im Allgemeinen die Replikation transparent gegenüber dem Client Rechner dargestellt sein soll – es ist sehr unwahrscheinlich, dass der Client die Zugriffsinformation aller Replikate kennt – wird hier das aktive Replikationsmodell nicht verwendet, vollständigkeitshalber ist es im nachfolgenden Abschnitt jedoch vorgestellt.
Server Coordination: Während dieser Phase erstellen die Replikate einen synchronisierten Ausführungsablauf nach Datenabhängigkeiten der einzelnen Operationen einer Client Anfrage (sequentielle Datenkonsistenz). Bei Datenbanksystemen muss weiterhin auf Linearisierbarkeit geachtet werden. Die Linearisierbarkeit unterscheidet sich von der sequentiellen Datenkonsistenz in dem Punkt, dass Datenabhängigkeiten in Echtzeit aufgelöst werden müssen, wohingegen die sequentielle Datenkonsistenz unter Umständen erlaubt, veraltete Werte zu lesen, da hierbei nicht auf die zeitliche Synchronisation, sondern lediglich die Anordnung der Operationen berücksichtigt wird (siehe Atomic Broadcast 4.2.1.2). Die in dieser Ausarbeitung erläuterten Replikationsmodelle bei verteilten Datenbanksystemen beachten die Forderung der Linearisierbarkeit mittels einem Vergleich aller Anfrageergebnisse in der Agreement Coordination Phase beziehungsweise durch die Verwendung von View Synchronous Broadcast (siehe 4.2.1.2).
Execution: In der Ausführungsphase werden die sync hronisierten Operationen angewendet, bevor das Ausführungsergebnis in der Agreement Coordination Phase validiert wird.
Agreement Coordination: In diesem Schritt kommunizieren die Replikate miteinander, ob die ausgeführten Operationen während der Execution Phase bei jeder einzelnen Instanz das gleiche Ergebnis aufzeigt. Dies gleicht dem Two Phase Commit Protocol (2PC), während dem entschieden wird, ob die Anfragebearbeitung durch ein Commit oder Rollback abgeschlossen wird, und ist bei Datenbanksystemen notwenig, um die Forderung der Linearisierbarkeit zu erfüllen, die alleine durch eine Abstimmung der Reihenfolge von Operationen einer Anfrage während der Server Coordination Phase nicht gewährleistet ist.
Durch Berücksichtigung der Linearisierbarkeit ist weiterhin noch nicht sicher gestellt, dass nach dem Abschluss der Anfragebearbeitung die Datenkonsistenz über alle Instanzen gewahrt ist, da Sekundärfehler, wie Konflikte mit systeminternen Operationen oder Hardwarefehler auftreten können. Erst nachdem alle Replikate einem Commit zustimmen wird das Ergebnis in der Client Response Phase zurückgeliefert. Diese Vorgehensweise bei Datenbanken unterscheidet sich vollkommen von der im allgemeinen Konzept verteilter Systeme, bei dem bereits nach der Server Coordination Phase die sequentielle Datenkonsistenz durch Erfüllung der Anforderung der Linearität sichergestellt ist, was den Abschluss des kompletten Anfragevorgangs mit dem Client Response zur Folge hat.
Client Response: Die zeitliche Einordnung dieser Phase ist genau der Zeitpunkt, zu dem der Client eine Antwort vom System erhält. Man unterscheidet hier zwei Konzepte: Falls der Client Response vor der eigentlichen Ausführung der Einzeloperationen vorgenommen wird, spricht man bei Datenbanken von einem lazy oder asynchronen Replikationsmodell.
Wird die Antwort erst vom System gegeben, nachdem alle Replikate die Operationen bearbeitet haben, so bezeichnet man das Replikationsmodell als eager oder synchron. Im allgemeinen Verteilungsmodell wird der Client Response direkt nach der Server Coordination Phase vorgenommen. Das asynchrone Modell hat vor allem bei mobilen Client Rechnern den Vorteil, dass der Benutzer nicht auf die teilweise länger dauernde
„eager“ Anfragebearbeitung warten muss, vor allem, wenn eine Verbindung zum System durch Ortswechsel öfter unterbrochen ist.
4.2.1.2 Abstrahierung von Kommunikationsmodellen
Um die Replikationsmodelle im kommenden Abschnitt ausführlich erklären zu können, führen wir als Abstrahierung von Kommunikationsmodellen die Begriffe Atomic Broadcast und View Synchronous Broadcast ein, die auf alle verteilten Systeme angewendet werden.
Ein verteiltes System ist abstrakt gesehen eine Modell von Diensten, die von Server Prozessen zur Verfügung gestellt werden. Um durch Aufrufe den lokalen Status eines dieser Prozesse atomar, das heißt, nicht teilweise, sondern wenn, dann nur komplett, zu ändern, bedient man sich verschiedenen Techniken, die konkurrierende verteilte Operationen gegenseitig isolieren. Dies ist meist Aufgabe des Serversystems, und wird mittels lokaler Synchronisationsmechanismen umgesetzt. Um die Dienste vor den Client Rechnern und somit den Benutzern transparent zu kapseln, bedient man sich verschiedener Client-Server Kommunikationstechniken, die als lokale Adressierungsmechanismen verwendet werden, und die die Komplexität der Konsistenzerhaltung (siehe Glossar) vor dem Client verbergen. Die zwei wichtigsten Techniken werden im Folgenden näher erläutert.
Atomic Broadcast (ABCAST)
Ein Kommunikationssystem basiert auf Atomic Broadcast, wenn es Atomarität und vollständige Sortierung implementiert. Seien m1 und m2 zwei Nachrichten, die einen ABCAST der gleichen Gruppe g von Elementen darstellen. Die Eigenschaft der Atomarität besagt, dass, falls ein Element in der Gruppe m1 oder m2 ve rschickt, alle restlichen (nicht ausgefallenen) Elemente diese Nachricht auch verschicken müssen. Falls zwei Elemente in g jeweils m1 und m2 versenden, werden diese Nachrichten wegen der Bedingung der vollständigen Sortierung beide Male in der gleichen Reihenfolge gesendet.
View Synchronous Broadcast (VSCAST)
Hierbei ist eine Sequenz von Sichten (Views) v0(g), v1(g), . . . , vi(g), . . . bezüglich einer Gruppe g definiert, deren Inhalte eine Zusammenstellung von g zu einer bestimmten Zeit aufzeigen. Ein Beispiel einer Sicht vj(g) ist die Darstellung der Gruppenelemente, von denen angenommen wird, dass sie zur Zeit t(vj(g)) fehlerfrei sind. Eine Änderung der Beziehungen innerhalb einer derartigen Gruppe wird durch die Erstellung einer neuen Sicht vi+1(g) angezeigt, und wird immer dann vorgenommen, wenn angenommen wird, dass ein Element e1 in der Sicht vi(g) ausgefallen ist, oder ein Element e2 neu in g aufgenommen werden soll. Ein VSCAST einer Nachricht m durch ein Gruppenelement von g in vi(g) erfüllt die folgende Bedingung. Falls ein Element e in vi(g) m versendet, bevor vi+ 1(g) angelegt wurde, legt kein Prozess diese Sicht an, ohne vorher m gesendet zu haben.
Mit der Hilfe dieser Techniken, können in den folgenden Abschnitten die wichtigsten Replikationsmodelle ausführlich vorgestellt werden.
4.2.1.3 Aktiv
Abbildung 12 : Übersicht aktive Replikation
Das aktive Replikationsmodell ist eine nicht zentralisierte Replikationsmethode und wird auch der „deterministische Automatenansatz“ genannt, da die Konsistent der Replikate gewahrt wird. Das Hauptkriterium hierfür ist die Übergabe und Bearbeitung exakt der gleichen Benutzeranfragen bei allen Replikationen, die auf die selbe Eingabe jeweils die selbe Ausgabe produzieren. Client Rechner stellen ihre Anfragen immer an Gruppen von Servern, wobei durch atomare Anfragepropagierung (s.o. Atomic Broadcast) sichergestellt werden kann, dass alle Server innerhalb der Gruppe die gleichen Eingaben in der gleichen Reihenfolge erhalten, siehe Abbildung 12.
Die Hauptkriterien des aktiven Replikationsmodells sind die Fehlertransparenz, da andere Replikate bei dem Ausfall von einer Kopie die Anfrage weiterhin bearbeiten können, und die einfache Implementierung durch identische Verfahrens- und Vorgehensweisen auf allen Replikaten. Abbildung 13 veranschaulicht das aktive Replikationsmodell, wobei hier als Kommunikationsdirektive der Atomic Broadcast verwendet wird. Man beachte, dass die Request und Server Coordination Phase zusammengeführt, und die Agreement Coordination Phase bei der aktiven Replikation ausgelassen wird.
Phase 1:
Client Request Phase 1:
Client Request
Phase 2:
Server Coordination
Phase 3:
Execution Phase 3:
Execution Phase 4:
Agreement- Coordination Phase 4:
Agreement- Coordination
Phase 5:
Client Response Phase 5:
Client Response
Replikat 1
Replikat 2
Replikat 3 Client Client
Client Client Atomic
Broadcast Atomic Broadcast
Update Update
Update Update
Update Update Phase 1:
Client Request Phase 1:
Client Request
Phase 2:
Server Coordination
Phase 3:
Execution Phase 3:
Execution Phase 4:
Agreement- Coordination Phase 4:
Agreement- Coordination
Phase 5:
Client Response Phase 5:
Client Response
Replikat 1 Replikat 1
Replikat 2 Replikat 2
Replikat 3 Replikat 3 Client Client
Client Client Atomic
Broadcast Atomic Broadcast
Update Update
Update Update
Update Update
Abbildung 13 : Aktives Replikationsmodell
Abbildung 13 stellt die Reihenfolge der einzelnen Ausführungsphasen dar. Im ersten Schritt stellt der Client mittels ABCAST die Anfrage an die Server. Darauf folgt die Server Coordination unter der Bedingung der totalen Ordnung des Atomic Broadcasts. In der dritten Phase führen die Replikate die Anfrage in der Reihenfolge aus, die durch die Server Coordination festgelegt wurde. Da alle Replikate auf die gleiche Anfrage immer auch das gleiche Ergebnis liefern, entfällt die Agreement Coordination bei dem aktiven Replikationsmodell, somit wird Phase vier übersprungen. In der fünften Phase liefert jede Replikation ihr Ergebnis an den Client zurück, wobei dieser lediglich auf die erste Antwort wartet.
4.2.1.4 Passiv/Primary Copy
Bei dem passiven Replikationsmodell, auch Primary Copy Modell genannt, werden Client Anfragen immer an einen Primary Server gestellt, der lediglich Updates an die untergeordneten Replikate (Backup Replikate) propagiert (vergleiche Abbildung 14). Um bei der Kommunikation zwischen Primary Server und den Backup Kopien sicher zu stellen, dass Updates in der gleichen Reihenfolge auf allen Backups ausgeführt werden, wird in der Praxis meist VSCAST eingesetzt. Beim Ausfall des Primary Servers während einer Update Aufforderung an die Backup Replikate übernimmt ein anderer Server aus dem Pool die Rolle des Primary, wobei VSCAST sicher stellt, dass bei einer neuen Update Anfrage vorher alle Backup Kopien die ursprünglichen Aufträge des ausgefallenen Primary Servers in der gleichen Reihenfolge synchronisiert ausführen, bevor das neue Update angewendet wird.
Abbildung 14 : Übersicht passive Replikation
Sieht man von der Rekonfiguration ab, der beim Ausfall des Primary Servers anfällt, erfordert das passive Replikationsmodell in der Praxis den geringsten Rechenaufwand.
Die fünf Phasen des Replikationsprotokolls bei der passiven Replikation werden in Abbildung 15 aufgezeigt. Schritt eins repräsentiert wieder die Anfrage des Clients, jedoch diesmal direkt an den Primary Server. Phase zwei entfällt, da hier nur ein Server verwendet wird, der Client Requests entgegennimmt. In der dritten Stufe führt der Primary Server das Update lokal aus, und koordiniert unter Verwendung von View Synchronous Broadcast in Phase vier die Propagierung des Updates an die Backup Replikate. Zum Schluss erfolgt die Antwort des Primary Servers an den Client.
Phase 1:
Client Request Phase 1:
Client Request
Phase 2:
Server Coordination Phase 2:
Server Coordination
Phase 3:
Execution Phase 3:
Execution Phase 4:
Agreement- Coordination Phase 4:
Agreement- Coordination
Phase 5:
Client Response Phase 5:
Client Response
Replikat 1
Replikat 2
Replikat 3 Client
Client VS CastVS Cast ClientClient
Update Update
Apply Apply
Apply Apply Phase 1:
Client Request Phase 1:
Client Request
Phase 2:
Server Coordination Phase 2:
Server Coordination
Phase 3:
Execution Phase 3:
Execution Phase 4:
Agreement- Coordination Phase 4:
Agreement- Coordination
Phase 5:
Client Response Phase 5:
Client Response
Replikat 1 Replikat 1
Replikat 2 Replikat 2
Replikat 3 Replikat 3 Client
Client VS CastVS Cast ClientClient
Update Update
Apply Apply
Apply Apply
Abbildung 15: Passives Replikationsmodell
4.2.1.5 Semi-Aktiv/ Semi-Passiv
Dieses Replikationsmodell ist ein Hybridverfahren zwischen der aktiven und passiven Replikationstechnik, und lässt nichtdeterministische Ausführungen bei den Replikationen zu. Im Gegensatz zum aktiven Modell entscheidet ein sogenannter Leader in Phase drei über das nichtdeterministische Update und propagiert dieses an die übrigen Replikate weiter. Mittels VSCAST erfolgt im 4. Schritt die Agreement Coordination analog zum passiven Modell.
Phase 1:
Client Request Phase 1:
Client Request
Phase 2:
Server Coordination Phase 2:
Server Coordination
Phase 3:
Execution Phase 3:
Execution Phase 4:
Agreement- Coordination Phase 4:
Agreement- Coordination
Phase 5:
Client Response Phase 5:
Client Response
Replikat 1
Replikat 2
Replikat 3 Client Client
Client Client Atomic
Broadcast Atomic Broadcast
Update Update
Update Update
Update Update
VS Cast VS Cast
Apply Apply
Apply Apply Nicht
determini- stischer Punkt Phase 1:
Client Request Phase 1:
Client Request
Phase 2:
Server Coordination Phase 2:
Server Coordination
Phase 3:
Execution Phase 3:
Execution Phase 4:
Agreement- Coordination Phase 4:
Agreement- Coordination
Phase 5:
Client Response Phase 5:
Client Response
Replikat 1 Replikat 1
Replikat 2 Replikat 2
Replikat 3 Replikat 3 Client Client
Client Client Atomic
Broadcast Atomic Broadcast
Update Update
Update Update
Update Update
VS Cast VS Cast
Apply Apply
Apply Apply Nicht
determini- stischer Punkt
Abbildung 16 : Semi -Aktives Replikationsmodell
Neben dem semi-aktiven existiert noch das semi-passive Modell, das die Server Coordination und die Agreement Coordination Phasen zu einem Koordinationsschritt zusammenfasst. Da dieses Replikationsmodell jedoch bei verteilten Datenbanksystemen keine Anwendung findet, wird es in diesem Dokument nicht weiter erläutert.
4.2.1.6 Eager Primary Copy
Die Eager Primary Copy Strategie verläuft bis auf die Agreement Coordination Phase analog zum passiven Modell. Im vierten Schritt propagiert der Primary Server das Update an alle übrigen Replikate, und wartet erst auf deren Commit Statements, bevor er selber das Commit ausführt und die Antwort an den Client zurückgibt. Da hier auf zwei Ebenen Commits angewendet werden, nennt man dies den Two Phase Commit (2PC). Falls bei dieser synchronen Kommunikation ein Fehler auftritt, stellt der Primary Replication Server den Konflikt fest, und löst ihn auf, wobei sich die Sekundärkopien unterordnen.
Danach wird dem Client der Rückgabewert übermittelt.
Phase 1:
Client Request Phase 1:
Client Request
Phase 2:
Server Coordination Phase 2:
Server Coordination
Phase 3:
Execution Phase 3:
Execution Phase 4:
Agreement- Coordination Phase 4:
Agreement- Coordination
Phase 5:
Client Response Phase 5:
Client Response
Replikat 1
Replikat 2
Replikat 3 Client
Client ClientClient
Update Update
Apply Apply
Apply Apply
2 PhasenCommit
Phase 1:
Client Request Phase 1:
Client Request
Phase 2:
Server Coordination Phase 2:
Server Coordination
Phase 3:
Execution Phase 3:
Execution Phase 4:
Agreement- Coordination Phase 4:
Agreement- Coordination
Phase 5:
Client Response Phase 5:
Client Response
Replikat 1 Replikat 1
Replikat 2 Replikat 2
Replikat 3 Replikat 3 Client
Client ClientClient
Update Update
Apply Apply
Apply Apply
2 PhasenCommit
Abbildung 17: Eager Primary Copy
4.2.1.7 Eager Update Everywhere
Im Gegensatz zur Primary Copy Lösung, bei der der Client Rechner Anfragen lediglich an den Primary Server senden kann, erlaubt der Update Everywhere Ansatz Anfragen bei jedem Replikat. Wird zusätzlich bei reinen Lesezugriffen immer das lokal nächstgelegenste Replikat angesprochen, nennt man dies auch das ROWA (Read- Once/Write-All) Verfahren. Hierbei kann es zu Konflikten kommen, falls mehrere Aktualisierungen des gleichen Objekts bei verschiedenen Replikationen eintreffen. Um diese Konflikte bei verteilten Updates auf den einzelnen Kopien zu vermeiden, betrachten wir neben dem ABCAST Replikationsprotokoll die Technik des gegenseitigen Ausschlusses durch verteiltes Sperren (distributed locking).
4.2.1.7.1 With Distributed Locking
Bei der Verwendung von distributed locking kann ein Objekt erst verwendet und aktualisiert werden, wenn es vorher auf allen Replikationen gesperrt wurde. Führt man eine Transaktion durch, die lediglich eine Operation ausführt, so verhält sich der Kontrollfluss analog zu Abbildung 18. Der Client Rechner sendet in Phase eins eine Update- Anfrage an einen lokalen Datenbankserver, der im zweiten Schritt, der Server Coordination Phase, zuerst einen sogenannten “Lock Request” an alle Replikate sendet, bei dem überprüft wird, ob das Objekt kurzfristig global für andere Anfragen gesperrt werden kann. Bei einer negativen Antwort wird dieser Schritt zeitlich versetzt wiederholt,
bis alle Replikate der Sperrung des Objekts zustimmen. Ist dies der Fall, so erfolgt in Phase drei jeweils ein lokales Update bei allen Replikaten. Während der Agreement Coordination wird das Two Phase Commit Protokoll verwendet, um festzustellen, ob alle Replikate das Update erfolgreich ausgeführt haben. Wird daraufhin das globale Commit erteilt, erhält der Client Rechner in der letzten Phase eine positive Antwort auf die Update- Anfrage. Im Fehlerfall muss das Update bei jeder einzelnen Replikation rückgängig gemacht werden.
Phase 1:
Client Request Phase 1:
Client Request
Phase 2:
Server Coordination Phase 2:
Server Coordination
Phase 3:
Execution Phase 3:
Execution Phase 4:
Agreement- Coordination Phase 4:
Agreement- Coordination
Phase 5:
Client Response Phase 5:
Client Response
Replikat 1
Replikat 2
Replikat 3 Client
Client ClientClient
Update
Update Commit 2 Phasen
Update Update
Update Update Phase 1:
Client Request Phase 1:
Client Request
Phase 2:
Server Coordination Phase 2:
Server Coordination
Phase 3:
Execution Phase 3:
Execution Phase 4:
Agreement- Coordination Phase 4:
Agreement- Coordination
Phase 5:
Client Response Phase 5:
Client Response
Replikat 1 Replikat 1
Replikat 2 Replikat 2
Replikat 3 Replikat 3 Client
Client ClientClient
Update
Update Commit 2 Phasen
Update Update
Update Update
Abbildung 18 : Eager Update Everywhere With Distributed Locking
Soll eine Transaktion ausgeführt werden, muss für jede einzelne Operation die Server Coordination und Execution Phase wiederholt werden.
4.2.1.7.2 Based On Atomic Broadcast
Verwendet man anstelle von distributed locking (siehe Abbildung 18) die ABCAST Protokolltechnik, so wird durch die Bedingung der totalen Ordnung sicher gestellt, dass konkurrierende Operationen, die möglicherweise Konflikte auslösen, auf allen Replikaten in der gleichen Reihenfolge ausgeführt werden. Da auf Grund dieser Vorbedingung die Agreement Coordination Phase unnötig ist, erhält der Client Rechner bereits nach der Ausführung die Antwort.
Phase 1:
Client Request Phase 1:
Client Request
Phase 2:
Server Coordination Phase 2:
Server Coordination
Phase 3:
Execution Phase 3:
Execution Phase 4:
Agreement- Coordination Phase 4:
Agreement- Coordination
Phase 5:
Client Response Phase 5:
Client Response
Replikat 1
Replikat 2
Replikat 3 Client Client
Client Client Atomic
Broadcast Atomic Broadcast
Update Update
Update Update
Update Update Phase 1:
Client Request Phase 1:
Client Request
Phase 2:
Server Coordination Phase 2:
Server Coordination
Phase 3:
Execution Phase 3:
Execution Phase 4:
Agreement- Coordination Phase 4:
Agreement- Coordination
Phase 5:
Client Response Phase 5:
Client Response
Replikat 1
Replikat 2
Replikat 3 Client Client
Client Client Atomic
Broadcast Atomic Broadcast
Update Update
Update Update
Update Update
Abbildung 19 Eager Update Everywhere Based On Atomic Broadcast
