HADES. Ein hochverfügbares, verteiltes Main-Memory-Datenmanagementsystem. Vom Fachbereich Informatik der Technischen Universität Darmstadt genehmigte

Größe: px
Ab Seite anzeigen:

Download "HADES. Ein hochverfügbares, verteiltes Main-Memory-Datenmanagementsystem. Vom Fachbereich Informatik der Technischen Universität Darmstadt genehmigte"

Transkript

1 HADES Ein hochverfügbares, verteiltes Main-Memory-Datenmanagementsystem Vom Fachbereich Informatik der Technischen Universität Darmstadt genehmigte Dissertation zur Erlangung des akademischen Grades eines Doktor-Ingenieurs (Dr.-Ing.) von Diplom-Informatiker Matthias Meixner aus Fulda Referenten: Prof. Alejandro Buchmann, Ph. D. Prof. Dr.-Ing. Felix Gärtner Tag der Einreichung: 4. Mai 2004 Tag der mündlichen Prüfung: 17. Dezember 2004 Darmstädter Dissertationen D17

2

3 Inhaltsverzeichnis 1 Einführung Publish/Subscribe IP-Übernahmemechanismen Ziele und Ergebnisse dieser Arbeit Überblick über die Arbeit Annahmen über die Systemumgebung Grundlagen der Fehlertoleranz Fehlermodelle Fehlerabdeckung Fehlertoleranz, Redundanz und Hochverfügbarkeit Verteilte Systeme und Fehlertoleranz Die HADES-Systemumgebung HADES-Fehlermodell Hardwareplattform Speicherressourcen Netzwerkressourcen Zusammenfassung i

4 ii INHALTSVERZEICHNIS 3 Überblick: Aufbau von HADES Fehlertolerante Kommunikationsschicht HADES-API HADES-DB Beispiel Fehlertolerante Kommunikationsschicht Überblick über die Implementierung Designentscheidungen Aufbau der Kommunikationsschicht Client-Programmierschnittstelle Verwaltung der Rechner im Cluster Hinzufügen von Clusterknoten Entfernen von Clusterknoten Abfragen der Clusterknoten Ausfallerkennung Versenden von Nachrichten und Antworten Signale Zusammenfassung HADES-Konzepte Management globaler Daten Datenverteilung und Adressierung Zweistufige Adressierung Berechnung der Servertabelle Zusammenfassung

5 INHALTSVERZEICHNIS iii 6 Verteiltes Datenmanagementsystem Client-Programmierschnittstelle Datenoperationen Konsistenzeigenschaften Verteilung der Servertabelle Absicherung von Änderungen an globalen Daten Datentabellen anlegen und löschen Servertabelle auslesen Adressierung Daten schreiben Daten Lesen Daten Löschen Selektieren und Sortieren Erweiterbarkeit Umkopieren für Redundanz oder Lastverteilung Transaktionen Arbeiten ohne Transaktionen Arbeiten mit Transaktionen Inter-Cluster-Transaktionen Audit-Logging und Backup Audit-Logging Backup Zusammenfassung

6 iv INHALTSVERZEICHNIS 7 Leistungsmessung Testumgebung Testablauf Benchmark Lesen und Schreiben von Daten außerhalb von Transaktionen Lesen und Schreiben von Daten innerhalb von Transaktionen Vergleich zwischen writepage/readpage und writepageset/read- PageSet Transaktionen Verteilte Transaktionen Selektieren Auswirkung der Slice-Anzahl Operationen während einer Datenneuverteilung Auswirkungen der Prozessorleistung Vergleich mit PostgreSQL Berkeley DB Zusammenfassung Vergleich mit anderen Systemen Bestehende Datenbanksysteme Konventionelle Datenbanksysteme Main-Memory-Datenbanksysteme PRISMA/DB TimesTen Distributed Hash-Tables

7 INHALTSVERZEICHNIS v 8.3 LH* Schema Scalable Distributed Data Structure LH* LH*m LH*s LH*g und LH*RS Distributed Shared Memory Shared Virtual Memory Fehlertolerantes DSM Checkpointing mit Parity Distributed Reliable Cache Middleware Mediated Transactions und X 2 TS Active Disks ISIS Toolkit Zusammenfassung Zusammenfassung und Ausblick Anforderungen und Ergebnisse Weitere Arbeiten und Verbesserungen Sensornetze A Grundlagen von Speichertechnologien 163 A.1 Festplatten A.2 RAID A.2.1 RAID-Level A.2.2 RAID-Level A.2.3 RAID-Level A.2.4 RAID-Fazit A.3 Solid State Disks A.4 Zusammenfassung

8 vi INHALTSVERZEICHNIS B Algorithmen 171 B.1 Gesamtalgorithmus zur Erkennung ausgefallener Knoten B.2 Berechnung der Servertabelle C Schnittstellenkurzreferenz 175 C.1 Programmierschnittstelle zur Kommunikationsschicht C.2 HADES Programmierschnittstelle Literaturverzeichnis 181

9 Kapitel 1 Einführung In den letzten Jahren haben sich durch den Fortschritt die technischen Voraussetzungen dramatisch geändert: Hauptspeicher ist billiger geworden und kostet heute soviel wie vergleichbarer Plattenplatz vor 10 Jahren. Die Festplattenkapazität ist um den Faktor 100 gestiegen, während der Durchsatz nur um den Faktor 10 gesteigert werden konnte und die Zugriffszeit noch weiter zurückblieb. Damit verschlechtert sich das Verhältnis aus Festplattenkapazität und Durchsatz bzw. Zugriffszeit alle 10 Jahre um den Faktor 10 [GS00]. Gleichzeitig ist die verfügbare Rechenleistung dramatisch angestiegen und die Schere zwischen Rechenleistung und Zugriffszeiten geht immer weiter auseinander. Für viele Anwendungen stellt nicht mehr die Rechenleistung einen Flaschenhals dar, sondern die hohe Zugriffszeit von Festplatten. Deshalb ist es notwendig alternative Speichersysteme zu untersuchen, wenn man insgesamt zu schnelleren Systemen kommen möchte. Konventionelle Speichersysteme sind der Flaschenhals, müssen also neu überdacht werden. Diese Arbeit entwickelt daher ein Speichersystem, das diesen Flaschenhals nicht besitzt und darüberhinaus weitere interessante Eigenschaften aufweist. In den folgenden Abschnitten möchte ich zunächst an ausgewählten Beispielen die Probleme aufzeigen und im weiteren Verlauf dieser Arbeit eine Lösung erarbeiten. 1.1 Publish/Subscribe Publish/Subscribe-Systeme gehören zu den eventbasierten Systemen. Diese werden verwendet, um größere verteilte Systeme aufzubauen, die die Eigenschaft haben, daß 1

10 2 KAPITEL 1. EINFÜHRUNG Client Event Broker F1 F2 F3 F1 F2 DB F1 Event Notification System F2 DB F1 F1 F2 F3 F2 F3 F1 F2 DB Abbildung 1.1: Eventbasiertes System die beteiligten Komponenten nur relativ lose miteinander gekoppelt sind [CNRW98]: Eine Komponente benötigt kein Wissen darüber, welche anderen Komponenten im System existieren, sie braucht nur die Formate und Strukturen der Events zu kennen, die für sie interessant sind. Man kann Komponenten hinzufügen und entfernen, ohne daß die anderen Komponenten direkt davon betroffen sind. Die verschiedenen Komponenten kommunizieren über Notifications (Benachrichtigungen), die das Auftreten eines bestimmten Ereignisses signalisieren. Abbildung 1.1 zeigt ein Beispiel für ein solches System. Das Event Notification System übernimmt dabei die Aufgabe, Benachrichtigungen, die von Produzenten erzeugt und publiziert werden, an Konsumenten weiterzuleiten. Da ein Produzent auch gleichzeitig Konsument für eine andere Art von Benachrichtigungen sein kann, werden Produzenten und Konsumenten in der Abbildung gleichermaßen als Client bezeichnet. Innerhalb des Event Notification Systems übernehmen Event-Broker die Aufgabe, Benachrich-

11 1.1. PUBLISH/SUBSCRIBE 3 tigungen weiterzuleiten und dabei mit Filtern bereits so zu filtern, daß Benachrichtigungen nur an die Stellen weitergeleitet werden, an denen es auch Konsumenten für diese Benachrichtigungen gibt. Damit dies möglich ist, geben Konsumenten dem Event Notification System per Subscription bekannt, für welche Ereignisse sie sich interessieren. Der Name Publish/Subscribe leitet sich aus eben dieser Funktionsweise von Publizieren und Abonnieren von Nachrichten ab. Eine weitere wichtige Möglichkeit die Datenmenge zu reduzieren und nur benötigte Informationen weiterzuleiten, besteht darin, Events zu aggregieren, d.h. mehrere Events auszuwerten und zusammenzufassen [BBC + 04]. Im Unterschied zu einfachen Filtern ist hierfür aber die Speicherung von Zustandsinformationen notwendig: Es müssen mehrere Benachrichtigungen angesammelt und gespeichert werden, bevor sie aggregiert werden können. Das Publish/Subscribe Prinzip wurde bereits in mehreren Systemen umgesetzt. Beispiele sind: Rebecca [Müh02], Jedi [CNF01], Siena [CRW01], Gryphon [Cen], und Hermes [PB02] Unterschiede zwischen den Systemen liegen in der Art der Subscription (channel based, topic based, content based), im Event-Dispatching (zentral, verteilt, broadcast) sowie den eingesetzten Filter- und Routingverfahren. Der interne Aufbau dieser Systeme sowie deren Unterschiede spielen in der weiteren Betrachtung aber keine Rolle. Produzent Filter1 Filter2 Filter3 Konsument Abbildung 1.2: Datenfluß in einem eventbasierten System Abbildung 1.2 zeigt ein Beispiel für den Datenfluß von einem Produzenten zu einem Konsumenten. Dabei werden jeweils nur die aktiven, für diesen Datenfluß relevanten Filter gezeigt. Da man die Aggregation von Events ebenfalls als Filter auffassen kann, z.b. das Zusammenfassen mehrerer zeitlich aufeinanderfolgender Events als Filtern im Zeitbereich, möchte ich im folgenden beliebige Transformationen von Benachrichtigungen als Filter bezeichnen und nicht zwischen den verschiedenen Möglichkeiten, Daten zu bearbeiten, unterscheiden. In dieser einfachen Ausführung kann keine Garantie gegeben werden, ob bzw. wie oft Benachrichtigungen ausgeliefert werden. Falls z.b. ein Filter ausfällt, gehen alle Benachrichtigungen verloren, die von diesem Filter empfangen aber noch nicht weitergeleitet wurden. Es ist auch möglich, daß Benachrichtigungen vervielfältigt werden, wenn Empfangsquittungen für Benachrichtigung verloren gehen und Benachrichtigungen deshalb wiederholt werden. Im Unterschied zu verbindungsorientierten Protokollen wie z.b. TCP ist keine Ende-zu-Ende Fehlerkorrektur möglich, da die Identität der beteiligten Komponenten und noch nicht

12 4 KAPITEL 1. EINFÜHRUNG einmal deren Anzahl bekannt sind. Eine Fehlerkorrektur kann jeweils nur während der Übertragung einer Benachrichtigung zwischen zwei benachbarten Komponenten eingesetzt werden. Dieses Verhalten ist für Anwendungen nicht tolerabel, die davon abhängen, daß Benachrichtigungen exakt einmal übertragen werden, wie z.b. Anwendungen, die das Auftreten von Ereignissen zählen. Besonders wichtig wird die Eigenschaft, daß Benachrichtigungen exakt einmal übertragen werden, sobald Aggregate eingesetzt werden, da ein einzelnes Aggregat sehr viele einzelne Benachrichtigungen repräsentieren und so ein Verlust dementsprechend eine große Auswirkung haben kann. Produzent Filter1 Filter2 Filter3 Konsument DB1 DB2 DB3 verteilte Transaktion einfache Transaktion Abbildung 1.3: Transaktionelle Nachrichten Dieses Problem läßt sich durch den Einsatz von Transaktionen und persistenter Speicherung also z.b. durch den Einsatz von Datenbankmechanismen lösen (Abbildung 1.3). Wichtige Benachrichtigungen werden weitergegeben, indem sie innerhalb einer (verteilten) Transaktion aus einer Datenbank bzw. Tabelle gelöscht werden und in die nächste eingefügt werden. Da Transaktionen immer komplett oder gar nicht ausgeführt werden, wird so sichergestellt, daß Benachrichtigungen immer exakt einmal weitergegeben werden. Auch beim Ausfall eines Knotens bleiben Nachrichten sicher gespeichert und stehen nach einem Neustart des Knotens wieder zur Verfügung. Je nach Fall werden sowohl einfache als auch verteilte Transaktionen eingesetzt. In diesem Aufbau vereinfachen sich auch die Anforderungen an die eingesetzten Filter: Da alle Zustandsinformationen in den Datenbanken gehalten werden, brauchen die Filter selbst keine Zustandsinformation mehr speichern und werden somit zustandslos. Dies betrifft auch die Speicherung der Events, die für eine Aggregation benötigt werden. Auf diese Weise vereinfacht sich der Aufbau der Filter: Eine aufwendige Zustandsspeicherung, Fehlererkennung und Behandlung ist nicht notwen-

13 1.1. PUBLISH/SUBSCRIBE 5 dig, bei einem Ausfall kann ein Filter einfach neu gestartet werden. Der Einsatz von Transaktionen verhindert, daß Daten mehrfach bearbeitet werden. Somit können auch mehrere identische Filter parallel gestartet werden, um auf diese Weise sehr einfach Fehlertoleranz zu erreichen: Wenn ein Filter ausfällt, wird dessen Arbeit automatisch von einem identischen anderen Filter erledigt; eine eventuell vor dem Ausfall begonnene Transaktion wird automatisch abgebrochen. Dieses Vorgehen ist sehr ähnlich zu der Funktionsweise von Middleware Mediated Transactions, wie sie z.b. von X 2 TS zur Verfügung gestellt werden [LMB00, LT01]. Allerdings beschränken sich diese Systeme darauf Transaktionen zur Verfügung zu stellen, während sie den Aspekt der persistenten Speicherung an angeschlossene Datenbanken auslagern. Durch dieses Vorgehen ergeben sich jedoch auch Probleme: Die Zeit, die für ein Commit benötigt wird, limitiert die Ende-zu-Ende Laufzeit, da der nächste Filter Daten erst dann lesen kann, wenn das Commit des vorangegangenen Filters abgeschlossen ist. Auch der Einsatz von optimistischen Verfahren bringt nur teilweise eine Verbesserung: Zwar könnte der Lesezugriff bereits früher stattfinden, aber auch in diesem Fall kann ein Commit erst dann abgeschlossen werden, wenn alle vorangegangenen Transaktionen erfolgreich mit Commit beendet werden konnten, denn falls ein Commit fehlschlägt darf auch das Commit der nächsten Filterstufe nicht durchgeführt werden, da diese dann ungültige Daten gelesen hat. Somit wird das Problem nur bis zum nächsten Commit aufgeschoben, aber nicht gelöst. Aus diesen Gründen wird ein Datenmanagementsystem benötigt, das ein Commit möglichst schnell abschließen kann. Fällt das Datenmanagementsystem aus, so gehen zwar keine Benachrichtigungen verloren, aber der Datenfluß ist unterbrochen und auf gespeicherte Benachrichtigungen kann bis zum Neustart nicht zugegriffen werden. Um dies zu vermeiden wird ein Datenmanagementsystem benötigt, das eine hohe Verfügbarkeit und Zuverlässigkeit bereitstellt, so daß auch bei einem Ausfall von einzelnen Komponenten oder Rechnern weiterhin ein gesicherter Betrieb ohne Unterbrechung gewährleistet ist. Steht ein solches Datenmanagementsystem zur Verfügung, so bietet es aber auch für andere Anwendungen innerhalb von eventbasierten Systemen Vorteile. Ein Beispiel hierfür ist mobile Publish/Subscribe [CFC + 03]: Viele eventbasierte Applikationen zeichnen sich dadurch aus, daß sie eine Initialisierungsphase benötigen, in der sie Notifikationen beobachten, um in einen konsistenten Zustand zu gelangen. In mobilen Szenarios wird diese Phase hauptsächlich benötigt, um die Applikation an die aktuellen Kontextinformationen anzupassen, die nur lokal verfügbar sind. Diese Phase läßt sich beschleunigen, wenn die benötigten Informationen von den Brokern

14 6 KAPITEL 1. EINFÜHRUNG in einem Cache auf Vorrat zwischengespeichert werden, von wo sie bei einer Subscription abgerufen werden können, um so die Initialisierungsphase zu beschleunigen. Werden diese Daten in einem hochverfügbaren Datenmanagementsystem gehalten, so läßt sich die Qualität dieser Daten gegenüber einem System verbessern, das bei einem Ausfall diese Daten verliert. Mit einem Ähnlichen Problem beschäftigt sich [Spi00]: Möchte man nicht nur aktuell auftretende Ereignisse betrachten, sondern wie sie sich über die Zeit verändern, wie sie zusammenhängen und voneinander abhängen so wird eine Historie der Ereignisse benötigt. Wird diese Historie im eventbasierten System gespeichert, so kann sie allen interessierten Clients zur Verfügung gestellt werden, ohne daß jeder Client eine eigene Historie verwalten müßte. 1.2 IP-Übernahmemechanismen Client Request IP Adresse IP Adresse Server Server Abbildung 1.4: IP-Übernahme bei zustandslosen Diensten Wird für Dienste eine hohe Verfügbarkeit benötigt, so ist es erforderlich diese redundant auszulegen. IP-Übernahmemechanismen stellen eine weit verbreitete Möglichkeit dar, dies zu realisieren [FHS03]. Ein Dienst wird in diesem Ansatz durch eine IP-Adresse (und Portnummer) repräsentiert. Clients verwenden diese Adresse, um mit dem Dienst via UDP oder TCP zu kommunizieren. Fällt der Dienst aus, so übernimmt ein anderer identischer Dienst die IP-Adresse. Zusammen mit der Eigenschaft, daß viele Clients eine Verbindung wieder aufbauen wenn sie unterbrochen wurde, um auf diese Weise Kommunikationsunterbrechungen im WAN auszugleichen, kann der Ausfall des Dienstes maskiert werden. Ganz so einfach funktioniert

15 1.2. IP-ÜBERNAHMEMECHANISMEN 7 Client Request IP Adresse IP Adresse Server Server zuverlässiges Datenmanagement system Abbildung 1.5: Auslagerung der Zustandsinformation das aber nur mit zustandslosen Diensten, die keine Informationen zu einer Client- Verbindung speichern (Abbildung 1.4). Einfache Webserver sind ein Beispiel für diesen Fall. Viele Dienste benötigen jedoch Zustandsinformationen, um Anfragen korrekt beantworten zu können. Fällt ein Server aus, so geht diese Information verloren. Um dies zu vermeiden kann der Dienst so modifiziert werden, daß der Zustand auf ein zuverlässiges, ausfallsicheres Speichersystem ausgelagert wird, womit der eigentliche Dienst zustandslos wird (Abbildung 1.5). Die Antwortzeit dieses Systems hängt ganz entscheidend vom eingesetzten Speichersystem ab, da jede Operation, die den Zustand ändert, der einem Client zugeordnet ist, zunächst abgespeichert werden muß, bevor eine Antwort an den Client gesendet werden kann, damit nach einem Serverausfall ein anderer Server nahtlos an der gleichen Stelle die Arbeit wieder aufnehmen kann. Damit dies möglich ist, muß von mehreren Rechnern auf das Speichersystem zugegriffen werden können. Von besonderer Wichtigkeit ist die Verfügbarkeit des Speichersystems, da die Verfügbarkeit des Gesamtsystems nicht besser als die Verfügbarkeit des Speichersystems sein kann.

16 8 KAPITEL 1. EINFÜHRUNG Insgesamt wird für diesen Anwendungszweck also ein sehr schnelles, ausfallsicheres Speichersystem benötigt. 1.3 Ziele und Ergebnisse dieser Arbeit Die soeben vorgestellten Anwendungsgebiete stellen sehr ähnliche Anforderungen an das Datenmanagementsystem: Die Menge der zu speichernden Daten ist nicht besonders groß (weit weniger als ein Gigabyte). Gleichzeitig haben die Daten nur eine geringe Lebensdauer und werden sehr oft geändert. In Publish/Subscribe-Systemen zum Beispiel brauchen sie nur solange gespeichert werden, bis sie erfolgreich an den oder die nächsten Broker weitergereicht werden konnten. Allen gemeinsam ist auch, daß die geforderten Eigenschaften nur unzureichend von festplattenbasierten Speichersystemen erfüllt werden können (vgl. Anhang A). Ein Einsatz von Festplatten in Publish/Subscribe-Systemen oder in hochverfügbaren Systemen, die stateless-server mit zusätzlichem hochverfügbarem Speicher für Zustandsinformationen einsetzen, führt aufgrund der hohen Zugriffszeiten von Festplatten zu hohen Ende-zu-Ende Verzögerungen bzw. zu langen Antwortzeiten. Den Flaschenhals stellt hierbei der Schreibzugriff auf die Festplatte dar. Erst nachdem dieser abgeschlossen ist, sind die Daten persistent gespeichert. Damit muß als Teil der Speicherung der Daten mindestens auf einen Schreibzugriff gewartet werden, was die hohe Zugriffszeit verursacht. Dabei spielt es keine Rolle, welche Mechanismen eingesetzt werden, also ob z.b. ein DBMS zur Verwaltung der Daten verwendet wird oder ob die Daten direkt von der Anwendung verwaltet werden. Die Zeit für diesen Schreibzugriff dominiert die insgesamt benötigte Zeit. Selbst bei den derzeit schnellsten Platten (IBM Ultrastar, U/min) fallen durchschnittlich 3, 4ms Positionierzeit und 2ms Latenz (rotational delay) an [IBM]. RAID-Systeme, die in anderen Fällen zur Steigerung der Leistung verwendet werden, helfen hier nicht weiter, da sie zwar den Durchsatz erhöhen und die Verfügbarkeit verbessern können, aber keine Vorteile beim Schreiben für die Zugriffszeit bringen. Bei RAID-Level 5 steigt sie sogar an, da zur Berechnung der neuen Parity-Prüfsumme vor dem Schreiben der Daten zusätzlich die alten Daten und Parity-Prüfsumme gelesen werden müssen. Mit Solid State Disks (SSD) gibt es zwar alternative Speichertechnologien, die niedrigere Zugriffszeiten bieten, jedoch sind diese entweder wenig geeignet oder sehr teuer: Flash-ROM basierte SSDs sind vergleichsweise billig, aber der darin verwendete Flash-Speicher kann nicht beliebig oft beschrieben werden. Typische Werte liegen bei Lösch-Schreib-Zyklen, z.b. für StrataFlash Memory (J3) [Int]. Auf eine

17 1.3. ZIELE UND ERGEBNISSE DIESER ARBEIT 9 Log-Datei finden im normalen Betrieb aber viele Schreibzugriffe statt (mind. ein Zugriff pro Transaktion), so daß diese Zahl innerhalb weniger Tage erreicht werden kann. Somit sind Flash-ROM SSDs für diesen Einsatz ungeeignet. DRAM-basierte SSDs unterliegen keiner Limitierung der Schreib-Lösch-Zyklen, sind aber um zwei Größenordnungen teurer als herkömmliche Festplatten. Für den Preis einer Athena-2 plus SSD mit 800MBytes bekommt man etwa 8 komplette Rechner mit insgesamt 8GBytes Hauptspeicher, wobei für ein hochverfügbares System mindestens zwei Platten notwendig sind. Ziel dieser Arbeit war es deshalb, ein hochverfügbares Datenmanagementsystem zu entwickeln, das auf den Einsatz von Festplatten zur sicheren Speicherung verzichten kann. HADES (Highly available distributed main-memory data management system) basiert daher auf der Idee, Persistenz nicht durch den Einsatz von externen Speichermedien, sondern durch den Einsatz von Redundanz zu erreichen. Daten werden im Hauptspeicher von mehreren Knoten eines Clusters gespeichert. Bei einem Rechnerausfall existiert somit noch eine Kopie und es kann weiterhin ohne Unterbrechung auf die Daten zugegriffen werden. Dies verspricht insgesamt niedrige Zugriffszeiten und eine hohe Verfügbarkeit. Da als Speichermedium keine externen Speichermedien eingesetzt werden, besteht keine Einschränkung auf blockorientierte Schreib- und Lesezugriffe, sondern es können beliebige Operationen mit beliebiger Datengranularität implementiert werden. Darüberhinaus bietet die Verteilung auf mehrere Rechner Möglichkeiten zur Parallelisierung. Auf diese Weise können als Nebeneffekt weitere Optimierungen eingesetzt werden, um die Bearbeitung von Daten weiter zu beschleunigen. In dieser Arbeit entwickle ich ein hochverfügbares Datenmanagementsystem, wie es von den vorgestellten Anwendungen benötigt wird. Im einzelnen enthält diese Arbeit folgende Beiträge: Beschreibung einer neuen Lösung (HADES). Beschreibung einer Implementierung auf Standard-Hardware. Evaluation eines Prototypen. Vergleich mit anderen Arbeiten. HADES stellt erstmals ein Datenmanagementsystem zur Verfügung, das Daten verteilt im Hauptspeicher eines Clusters ablegt, Persistenz durch Fehlertoleranz garantiert und dabei für niedrige Zugriffszeiten optimiert wurde. HADES benötigt keine spezielle Hardware, sondern kommt mit preiswerter Standard-Hardware aus. Die

18 10 KAPITEL 1. EINFÜHRUNG niedrigen Zugriffszeiten werden ausschließlich durch Kommunikations- und Datenmanagementstrategien erreicht, die dafür sorgen, daß möglichst direkt mit wenigen Netzwerkzugriffen auf die Daten zugegriffen werden kann. Mit dem erstellten Prototypen wurden mehrere Meßreihen durchgeführt, die die Vorteile von HADES aufzeigen. U.a. konnte damit belegt werden, daß die Zugriffszeiten etwa eine Größenordnung unter den Zugriffszeiten von schnellen Festplatten liegen. Es gibt verschiedene Systeme, die auf den ersten Blick eine große Ähnlichkeit zu HADES zu haben scheinen, die aber im Detail große Unterschiede aufweisen, die dazu führen, daß sie für Anwendungen ungeeignet sind, die niedrige Zugriffszeiten benötigen. 1.4 Überblick über die Arbeit Kapitel 2 gibt eine kurze Einführung in die Grundlagen der Fehlertoleranz, leitet daraus die Anforderungen an die Hardware ab und legt fest, welche Fehler vom System toleriert werden können. Kapitel 3 gibt einen Überblick über den Aufbau von HADES und die eingesetzten Komponenten. Kapitel 4 beschreibt die in HADES eingesetzte Kommunikationsschicht, die die Kommunikation im Cluster steuert, den Cluster verwaltet sowie dessen Konten überwacht. Kapitel 5 beschäftigt sich damit, wie die Daten im Cluster verteilt werden und welche Probleme bei der Verteilung gelöst werden mußten. Kapitel 6 stellt die Implementierung des Prototypen vor und beschreibt die zur Verfügung stehenden Operationen. In Kapitel 7 werden die Ergebnisse vorgestellt, die bei der Evaluation des Prototypen gewonnen wurden. Den Vergleich mit anderen Systemen und Arbeiten gibt Kapitel 8. Kapitel 9 schließt die Arbeit mit einer kurzen Zusammenfassung und gibt einen Ausblick auf weitere Themen. Anhang A gibt einen ausführlichen Überblick über Zugriffslatenzen und wie sie sich nicht vermeiden lassen. Der Pseudocode der in der Arbeit vorgestellten Algorithmen findet sich in Anhang B. Eine Kurzreferenz in Anhang C stellt die wichtigsten zur Verfügung stehenden Methoden der Programmierschnittstelle von HADES vor.

19 Kapitel 2 Annahmen über die Systemumgebung Bevor man beginnt ein System zu implementieren, muß nicht nur festgelegt werden, was das System leisten können soll, sondern es müssen auch verschiedene Annahmen über die Randbedingungen gemacht werden. Im Falle von HADES sind die zwei wichtigsten: Mit welchen Fehlern muß HADES umgehen können? Welche Hardware kann/soll eingesetzt werden? Diese beiden Punkte sind nicht unabhängig, sondern sie beeinflussen sich stark gegenseitig. Die gewünschte Fehlertoleranz bestimmt, welche Hardware-Umgebung eingesetzt werden muß, und umgekehrt limitieren die Kosten der Hardware welche Fehlertoleranz erreicht werden kann. Darüberhinaus wird von diesen beiden Punkten auch die Leistungsfähigkeit des Gesamtsystems mitbestimmt, so daß hier ein Kompromiß zwischen Leistungsfähigkeit, Fehlertoleranz und Kosten gefunden werden muß. In diesem Kapitel möchte ich daher erläutern, welcher Kompromiß für HADES gewählt wurde und auf welchen Grundlagen er basiert. 2.1 Grundlagen der Fehlertoleranz Fehlertoleranz ist die Eigenschaft eines Systems, auch beim Auftreten von Fehlern noch korrekt zu funktionieren. Genauer unterscheidet man dabei zwischen dem Defekt (fault) und dem von diesem Defekt verursachte Fehler (error), der dann zum 11

20 12 KAPITEL 2. ANNAHMEN ÜBER DIE SYSTEMUMGEBUNG Ausfall (failure) eines Systems führen kann [Gär01, Lap92]. Fehlertolerante Systeme können zwar keine Defekte verhindern, jedoch können sie die Auswirkungen von Defekten begrenzen, so daß ein Ausfall des Systems verhindert werden kann. Ein fehlertolerantes System kann allerdings nicht beliebige Fehler tolerieren, es gibt immer Fehler die schlimmer in ihrer Auswirkung sind als alle Fehler, die man beim Entwurf des Systems berücksichtigt hat. Gleichzeitig kann es aber einen erheblichen Mehraufwand bedeuten, wenn man einen zusätzlichen Fehler tolerieren können möchte. Daher muß ein Kompromiß gefunden werden, der einerseits hinreichend viele Fehler abdeckt, die in der Realität auftreten können, andererseits aber nur Fehler berücksichtigt, die mit vertretbarem Aufwand abgefangen werden können. Voraussetzung dafür, daß ein Fehler abgefangen werden kann, ist, daß nicht das komplette System ausfällt, sondern nur Teile davon, so daß die verbliebenen Komponenten die Aufgaben weiterhin erfüllen können. Während dieser Fall bei einzelnen Rechnern nur in Sonderfällen vorkommt, da Rechner nach einem Defekt normalerweise komplett ausfallen, ist dies in verteilten Systemen die Regel. In verteilten Systemen ist es unwahrscheinlich, daß alle Rechner gleichzeitig ausfallen. Normalerweise ist nur ein Teil der Komponenten betroffen, während der andere Teil weiterhin funktioniert. Diese inhärente Redundanz in verteilten Systemen kann daher gut ausgenutzt werden, um fehlertolerante Systeme zu bauen Fehlermodelle Bevor man sich mit Fehlertoleranz beschäftigen kann, gilt es zunächst einmal zu klären: Was ist ein Fehler? [Gär01, S. 34f] gibt hierfür eine nützliche Klassifikation von formalisierten Fehlermodellen: Fail-Stop: Prozesse können anhalten und senden danach nur noch Fehlermeldungen als Antwort. Dies ist z.b. der Fall falls ein einzelner Prozeß auf einem Rechner abstürzt. Für alle folgenden Versuche mit diesem Prozeß zu kommunizieren, wird vom Betriebssystem eine Fehlermeldung generiert (vgl. hierzu auch [SS83]). Crash: Prozesse können abstürzen (crash) und antworten danach nicht mehr. Im Unterschied zum vorangegangenen Fall werden keine Fehlermeldungen als Antwort generiert. Dies passiert z.b. wenn ein kompletter Rechner abstürzt. General Omission: Zusätzlich zu Crash können beliebig viele Nachrichten auf den Kommunikationsverbindungen z.b. durch Störungen verloren gehen.

RAID. Name: Artur Neumann

RAID. Name: Artur Neumann Name: Inhaltsverzeichnis 1 Was ist RAID 3 1.1 RAID-Level... 3 2 Wozu RAID 3 3 Wie werden RAID Gruppen verwaltet 3 3.1 Software RAID... 3 3.2 Hardware RAID... 4 4 Die Verschiedenen RAID-Level 4 4.1 RAID

Mehr

Die allerwichtigsten Raid Systeme

Die allerwichtigsten Raid Systeme Die allerwichtigsten Raid Systeme Michael Dienert 4. Mai 2009 Vorbemerkung Dieser Artikel gibt eine knappe Übersicht über die wichtigsten RAID Systeme. Inhaltsverzeichnis 1 Die Abkürzung RAID 2 1.1 Fehlerraten

Mehr

2. Braunschweiger Linux-Tage. Vortrag über RAID. von. Thomas King. http://www.t-king.de/linux/raid1.html. 2. Braunschweiger Linux-Tage Seite 1/16

2. Braunschweiger Linux-Tage. Vortrag über RAID. von. Thomas King. http://www.t-king.de/linux/raid1.html. 2. Braunschweiger Linux-Tage Seite 1/16 2. Braunschweiger Linux-Tage Vortrag über RAID von Thomas King http://www.t-king.de/linux/raid1.html 2. Braunschweiger Linux-Tage Seite 1/16 Übersicht: 1. Was ist RAID? 1.1. Wo wurde RAID entwickelt? 1.2.

Mehr

Hardware- und Software-Anforderungen IBeeS.ERP

Hardware- und Software-Anforderungen IBeeS.ERP Hardware- und Software-Anforderungen IBeeS.ERP IBeeS GmbH Stand 08.2015 www.ibees.de Seite 1 von 8 Inhalt 1 Hardware-Anforderungen für eine IBeeS.ERP - Applikation... 3 1.1 Server... 3 1.1.1 Allgemeines

Mehr

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Institut für Informatik Prof. Dr. Bernhard Bauer Stephan Roser Viviane Schöbel Wintersemester 07/08 Übungsblatt 5 08.01.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1:

Mehr

In-Memory Analytics. Marcel Poltermann. Fachhochschule Erfurt. Informationsmanagement

In-Memory Analytics. Marcel Poltermann. Fachhochschule Erfurt. Informationsmanagement Marcel Poltermann Fachhochschule Erfurt Informationsmanagement Inhaltsverzeichnis Glossar...III Abbildungsverzeichnis...III 1 Erläuterung:... 2 2 Technische Grundlagen... 2 2.1 Zugriff physische Datenträger:...

Mehr

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH Complex Hosting Autor.: Monika Olschewski Whitepaper Version: 1.0 Erstellt am: 14.07.2010 ADACOR Hosting GmbH Kaiserleistrasse 51 63067 Offenbach am Main info@adacor.com www.adacor.com Complex Hosting

Mehr

TAV Übung 3. Übung 3: Verteilte Datenhaltung

TAV Übung 3. Übung 3: Verteilte Datenhaltung Übung 3: Verteilte Datenhaltung 1. Serialisierung Konstruieren Sie Historien aus drei Transaktionen T1, T2 und T3, die folgende Merkmale aufweisen: 1. Die serielle Reihenfolge ist T1 vor T2 vor T3. 2.

Mehr

Online Help StruxureWare Data Center Expert

Online Help StruxureWare Data Center Expert Online Help StruxureWare Data Center Expert Version 7.2.7 Virtuelle StruxureWare Data Center Expert-Appliance Der StruxureWare Data Center Expert-7.2-Server ist als virtuelle Appliance verfügbar, die auf

Mehr

Die wichtigsten Vorteile von SEPPmail auf einen Blick

Die wichtigsten Vorteile von SEPPmail auf einen Blick Die wichtigsten Vorteile von SEPPmail auf einen Blick August 2008 Inhalt Die wichtigsten Vorteile von SEPPmail auf einen Blick... 3 Enhanced WebMail Technologie... 3 Domain Encryption... 5 Queue-less Betrieb...

Mehr

Implementierung von Dateisystemen

Implementierung von Dateisystemen Implementierung von Dateisystemen Teil 2 Prof. Dr. Margarita Esponda WS 2011/2012 44 Effizienz und Leistungssteigerung Festplatten sind eine wichtige Komponente in jedem Rechnersystem und gleichzeitig

Mehr

Red Hat Cluster Suite

Red Hat Cluster Suite Red Hat Cluster Suite Building high-available Applications Thomas Grazer Linuxtage 2008 Outline 1 Clusterarten 2 3 Architektur Konfiguration 4 Clusterarten Was ist eigentlich ein Cluster? Wozu braucht

Mehr

56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen. Client Client Client Client Client. Public Network. aktiv. Private Network.

56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen. Client Client Client Client Client. Public Network. aktiv. Private Network. 56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen aktiv inaktiv Node 1 ( Aktiv ) Node 2 ( Passiv ) Private Network aktiv inaktiv (exklusiver Zugriff) Abbildung 3.1: Schematische Darstellung

Mehr

RAC auf Sun Cluster 3.0

RAC auf Sun Cluster 3.0 RAC auf Sun Cluster 3.0 Schlüsselworte RAC, OPS, Sun Cluster, Performance, Availability Zusammenfassung Oracle hat mit dem Real Application Cluster (RAC) aus einer Hochverfügbarkeitslösung eine Höchstverfügbarkeitslösung

Mehr

Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich

Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich Seit Microsoft Exchange Server 2010 bieten sich für Unternehmen gleich zwei mögliche Szenarien an, um eine rechtskonforme Archivierung

Mehr

Mailbox Cluster Konzepte

Mailbox Cluster Konzepte Ideen für grosse Mailstores Mailbox Cluster Konzepte Felix J. Ogris (fjo@dts.de) Version 1.0 2008-05-25 Inhaltsverzeichnis Inhaltsverzeichnis Inhaltsverzeichnis 1 Schema 4 2 Storage 5 2.1 Mailbox- und

Mehr

Hochverfügbares Ethernet MRP - Media Redundancy Protocol

Hochverfügbares Ethernet MRP - Media Redundancy Protocol Hochverfügbares Ethernet MRP - Media Redundancy Protocol Hirschmann Automation and Control GmbH Dipl.- Ing. Dirk Mohl 1 25.01.07 - ITG Automation Übersicht Netzwerke und Redundanztypen Rapid Spanning Tree

Mehr

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz Hochverfügbar und Skalierung mit und ohne RAC Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC Alexander Scholz Copyright its-people Alexander Scholz 1 Einleitung Hochverfügbarkeit

Mehr

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit 1 Hochverfügbarkeit Lernziele: Network Load Balancing (NLB) Failover-Servercluster Verwalten der Failover Cluster Rolle Arbeiten mit virtuellen Maschinen Prüfungsanforderungen von Microsoft: Configure

Mehr

Betriebssysteme K_Kap11C: Diskquota, Raid

Betriebssysteme K_Kap11C: Diskquota, Raid Betriebssysteme K_Kap11C: Diskquota, Raid 1 Diskquota Mehrbenutzer-BS brauchen einen Mechanismus zur Einhaltung der Plattenkontingente (disk quotas) Quota-Tabelle enthält Kontingenteinträge aller Benutzer

Mehr

Hard & Software Raid

Hard & Software Raid Hard & Software Raid Werner von Siemens Schule Präsentation Inhaltsverzeichnis Hardware Raid Raid 0 Raid 1 Parity Raid 0+1 & 2 Raid 3 & 4 Raid 5 & 6 Raid 7 Software Raid Fragen, Schlusswort 2 Hardware

Mehr

Technische Übersicht über den Netzwerklastenausgl eich (Network Load Balancing) Einführung

Technische Übersicht über den Netzwerklastenausgl eich (Network Load Balancing) Einführung Technische Übersicht über den Netzwerklastenausgl eich (Network Load Balancing) Einführung - Dienst wird in den Betriebssystemen Windows 2000 Advanced Server und Windows 2000 Datacenter Server bereitgestellt.

Mehr

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 5 26.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: Erläutern

Mehr

TCP/UDP. Transport Layer

TCP/UDP. Transport Layer TCP/UDP Transport Layer Lernziele 1. Wozu dient die Transportschicht? 2. Was passiert in der Transportschicht? 3. Was sind die wichtigsten Protkolle der Transportschicht? 4. Wofür wird TCP eingesetzt?

Mehr

Prof. Dr.-Ing. Dagmar Meyer Architekturen verteilter SW-Systeme 5 SYNCHRONISATION

Prof. Dr.-Ing. Dagmar Meyer Architekturen verteilter SW-Systeme 5 SYNCHRONISATION Prof. Dr.-Ing. Dagmar Meyer 5 SYNCHRONISATION Warum braucht man Synchronisation? Ausgangssituation Prozesse müssen sich koordinieren / synchronisieren, z. B. beim Zugriff auf gemeinsame Ressourcen. Alle

Mehr

Lokales Storage Teil 1

Lokales Storage Teil 1 Lokales Storage Teil 1 Zinching Dang 08. Juli 2015 1 Lokales Storage im Allgemeinen Lokales Storage im Allgemeinen Datenträger, die direkt am Host angeschlossen sind Anbindung über verschiedene Bus-Systeme

Mehr

Dunkel Cloud Storage. Der sichere Cloud-Speicher für Unternehmen

Dunkel Cloud Storage. Der sichere Cloud-Speicher für Unternehmen Dunkel Cloud Storage Der sichere Cloud-Speicher für Unternehmen Was ist Dunkel Cloud Storage? Dunkel Cloud Storage (DCS) stellt Ihnen Speicherplatz nach Bedarf zur Verfügung, auf den Sie jederzeit über

Mehr

Musterlösung Klausur SS 2004

Musterlösung Klausur SS 2004 Musterlösung Klausur SS 2004 Fachrichtung: Informatik Lehrveranstaltung: Verteilte Systeme Dozent: Prof. G. Bengel Tag: 15.6.04 Bearbeitungszeit: 90 Minuten Name:... Matr.Nr.:... Punkte:... Note:... Hilfsmittel:

Mehr

Marathon everrun TM Was kommt nach den Clustern? Abschätzung geschäftlicher Auswirkungen Die wahren Ausfallkosten

Marathon everrun TM Was kommt nach den Clustern? Abschätzung geschäftlicher Auswirkungen Die wahren Ausfallkosten Abschätzung geschäftlicher Auswirkungen Die wahren Ausfallkosten Produktivität Anzahl betroffener Mitarbeiter x Ausfalldauer x Arbeitsplatzkosten Produktionsstörungen Erträge Direkte Verluste Entschädigungszahlungen

Mehr

Vorlesung "Verteilte Systeme" Sommersemester 1999. Verteilte Systeme. 13. Fehlertoleranz. Verteilte Systeme, Sommersemester 1999 Folie 13.

Vorlesung Verteilte Systeme Sommersemester 1999. Verteilte Systeme. 13. Fehlertoleranz. Verteilte Systeme, Sommersemester 1999 Folie 13. Verteilte Systeme 13. Fehlertoleranz Motivation Kunde () Verteiltes System = Redundanz Rechnern Kommunikationsnetzen Grundidee Einzelne Komponente k fällt mit einer Wahrscheinlichkeit p aus Ausfallwahrscheinlichkeit

Mehr

ONLINE BACKUP STORAGE REGIONALES DATENBACKUP MIT BIS ZU 100 TB SPEICHERPLATZ. Irgendwo Speicherplatz mieten ist kein Problem.

ONLINE BACKUP STORAGE REGIONALES DATENBACKUP MIT BIS ZU 100 TB SPEICHERPLATZ. Irgendwo Speicherplatz mieten ist kein Problem. ONLINE BACKUP STORAGE REGIONALES DATENBACKUP MIT BIS ZU 100 TB SPEICHERPLATZ Irgendwo Speicherplatz mieten ist kein Problem. Doch wie kommen Sie schnell und sicher wieder an Ihre Daten heran? Wir haben

Mehr

Verfügbarkeit von Applikationen und Failover Szenarien. Winfried Wojtenek. wojtenek@mac.com

Verfügbarkeit von Applikationen und Failover Szenarien. Winfried Wojtenek. wojtenek@mac.com Verfügbarkeit von Applikationen und Failover Szenarien Winfried Wojtenek wojtenek@mac.com Verfügbarkeit % Tage Stunden Minuten 99.000 3 16 36 99.500 1 20 48 99.900 0 9 46 99.990 0 0 53 99.999 0 0 5 Tabelle

Mehr

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann Blatt Nr. 11 Übung zur Vorlesung Einsatz und Realisierung von Datenbanksystemen im SoSe15 Moritz Kaufmann (moritz.kaufmann@tum.de)

Mehr

Hochverfügbare Server-Hardware: Eine Fallstudie (Logistik-Zentrum)

Hochverfügbare Server-Hardware: Eine Fallstudie (Logistik-Zentrum) Hochverfügbare Server-Hardware: Eine Fallstudie (Logistik-Zentrum) Anforderungen aus heutiger Sicht Wesentliche Merkmale der Anwendung Leistungsbestimmende Komponenten Zuverlässigkeitsbestimmende Komponenten

Mehr

IT Storage Cluster Lösung

IT Storage Cluster Lösung @ EDV - Solution IT Storage Cluster Lösung Leistbar, Hochverfügbar, erprobtes System, Hersteller unabhängig @ EDV - Solution Kontakt Tel.: +43 (0)7612 / 62208-0 Fax: +43 (0)7612 / 62208-15 4810 Gmunden

Mehr

Dieses Dokument beschreibt, wie mit FreeFileSync eine einfache Daten-Synchronisation auf gemanagten Geräten eingerichtet wird.

Dieses Dokument beschreibt, wie mit FreeFileSync eine einfache Daten-Synchronisation auf gemanagten Geräten eingerichtet wird. IT Services Support Werftestrasse 4, Postfach 2969, CH-6002 Luzern T +41 41 228 42 42, F +41 41 228 42 43 www.hslu.ch Luzern, 5. August 2015 Seite 1/8 Kurzbeschrieb: Dieses Dokument beschreibt, wie mit

Mehr

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem 1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem Management, Access Management a. Event Management b. Service Desk c. Facilities Management d. Change Management e. Request Fulfilment

Mehr

ND.Zip & Notes/Domino 6

ND.Zip & Notes/Domino 6 ND.Zip for Notes Version 1.1 ND.Zip & Notes/Domino 6 Stand: 9.5.2003 Inhaltsverzeichnis 1 Inhaltsverzeichnis 2 ND.Zip: ein Muss auch für Notes/Domino 6! 3 LZ1 erzielt keinen Mehrwert, 4 Sofortiger und

Mehr

RAID-Konfigurations-Tool

RAID-Konfigurations-Tool RAID-Konfigurations-Tool Benutzerhandbuch Version: 1.1 SecureGUARD GmbH, 2011 Inhalt: 1. Der Begriff RAID... 3 1.1. RAID-Level... 3 2. RAID erstellen... 5 3. RAID löschen... 8 4. Fehlerbehebung... 10 4.1.

Mehr

Technischer Anhang. Version 1.2

Technischer Anhang. Version 1.2 Technischer Anhang zum Vertrag über die Zulassung als IP-Netz-Provider im electronic cash-system der deutschen Kreditwirtschaft Version 1.2 30.05.2011 Inhaltsverzeichnis 1 Einleitung... 3 2 Anforderungen

Mehr

Referat über Streamer, DAT und Datensicherung

Referat über Streamer, DAT und Datensicherung %DOWKDVDU1HXPDQQ7HFKQLNXP )DFKVFKXO I 7HFKQLN Modul 7 Klasse: ITZ99 Lehrer: Herr Beford Referat über Streamer, DAT und Datensicherung Verfasser: Thomas Hartz Erklärung: 2. Februar 2000 Hiermit erkläre

Mehr

IRF2000, IF1000 Application Note Network Mapping mit 1:1 NAT

IRF2000, IF1000 Application Note Network Mapping mit 1:1 NAT Version 2.1 Original-Application Note ads-tec GmbH IRF2000, IF1000 Application Note Network Mapping mit 1:1 NAT Stand: 28.10.2014 ads-tec GmbH 2014 Big-LinX 2 Inhaltsverzeichnis 1 Einführung... 3 1.1 NAT

Mehr

Zero Effort Backup (ZEB) automatische Datensicherung über das Internet

Zero Effort Backup (ZEB) automatische Datensicherung über das Internet Ralph Lehmann. Computerservice und IT-Beratung. Kochstraße 34. 04275 Leipzig Ralph Lehmann Computerservice und IT-Beratung Kochstraße 34 04275 Leipzig Ralph Lehmann Computerservice und IT-Beratung Tel.:

Mehr

Mindtime Online Backup

Mindtime Online Backup Mindtime Online Backup S e r v i c e L e v e l A g r e e m e n t Inhaltsangabe Service Definition... 3 1) Datenverschlüsselung... 3 2) Gesicherte Internetverbindung... 3 3) Datencenter... 4 4) Co- Standort...

Mehr

PowerBridge MSSQL Beta

PowerBridge MSSQL Beta SoftENGINE PowerBridge MSSQL Beta Dokumentation Thomas Jakob 17.04.2011 Inhalt Einrichtung der SQL Umgebung... 3 SQL-Server Installieren... 3 BüroWARE Installieren... 3 PowerBridge-SQL Modus einrichten...

Mehr

Vorlesung Datenbanksysteme Univ.-Prof. Dr. Günther Specht. Universität Innsbruck Institut für Informatik Datenbanken und Informationssysteme (DBIS)

Vorlesung Datenbanksysteme Univ.-Prof. Dr. Günther Specht. Universität Innsbruck Institut für Informatik Datenbanken und Informationssysteme (DBIS) Verteilte DB-Systeme Kapitel XIII Vorlesung Datenbanksysteme Univ.-Prof. Dr. Günther Specht Universität Innsbruck Institut für Informatik Datenbanken und Informationssysteme (DBIS) Vorlesungsinhalt 13.

Mehr

DIE GRUNDLAGEN DER FERNÜBERWACHUNG

DIE GRUNDLAGEN DER FERNÜBERWACHUNG DIE GRUNDLAGEN DER FERNÜBERWACHUNG Verbraucherleitfaden Version 1.0 Deutsch Einleitung Derzeit sind am Markt zahlreiche Videoüberwachungssysteme erhältlich, die einen digitalen Zugriff über Netzwerkverbindungen

Mehr

Verteilte Systeme - 5. Übung

Verteilte Systeme - 5. Übung Verteilte Systeme - 5. Übung Dr. Jens Brandt Sommersemester 2011 Transaktionen a) Erläutere was Transaktionen sind und wofür diese benötigt werden. Folge von Operationen mit bestimmten Eigenschaften: Atomicity

Mehr

Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten

Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten Prof. Dr. P. Tran-Gia Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten 4. Würzburger Workshop IP Netzmanagement, IP Netzplanung und Optimierung Robert Henjes, Dr. Kurt Tutschku

Mehr

Konzept für eine Highperformance- und Hochverfügbarkeitslösung für. einen Anbieter von Krankenhaus Abrechnungen

Konzept für eine Highperformance- und Hochverfügbarkeitslösung für. einen Anbieter von Krankenhaus Abrechnungen Konzept für eine Highperformance- und Hochverfügbarkeitslösung für Anforderungen : einen Anbieter von Krankenhaus Abrechnungen Es soll eine Cluster Lösung umgesetzt werden, welche folgende Kriterien erfüllt:

Mehr

RAID Redundant Array of Independent [Inexpensive] Disks

RAID Redundant Array of Independent [Inexpensive] Disks RAID Redundant Array of Independent [Inexpensive] Disks Stefan Wexel Proseminar Algorithms and Data Structures im WS 2011/2012 Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik

Mehr

sedex-client Varianten für den Betrieb in einer hoch verfügbaren

sedex-client Varianten für den Betrieb in einer hoch verfügbaren Département fédéral de l'intérieur DFI Office fédéral de la statistique OFS Division Registres Team sedex 29.07.2014, version 1.0 sedex-client Varianten für den Betrieb in einer hoch verfügbaren Umgebung

Mehr

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr

NAS 251 Einführung in RAID

NAS 251 Einführung in RAID NAS 251 Einführung in RAID Ein Speicher-Volume mit RAID einrichten A S U S T O R - K o l l e g Kursziele Nach Abschluss dieses Kurses sollten Sie: 1. Ü ber ein grundlegendes Verständnis von RAID und seinen

Mehr

Entwicklung eines Mac OS X Treibers für eine PCI-VME Interface Karte

Entwicklung eines Mac OS X Treibers für eine PCI-VME Interface Karte Entwicklung eines Mac OS X Treibers für eine PCI-VME Interface Karte Matthias Lange Informatikstudent, TU-Dresden 27. September 2005 http://www.matze-lange.de Warum entwickelt jemand einen Treiber für

Mehr

Band M, Kapitel 5: Server

Band M, Kapitel 5: Server Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 22899 9582-0 E-Mail: Hochverfuegbarkeit@bsi.bund.de Internet: https://www.bsi.bund.de Bundesamt für Sicherheit

Mehr

Managed Cloud Services

Managed Cloud Services Managed Cloud Services Autor.: Monika Olschewski Whitepaper Version: 1.0 Erstellt am: 14.07.2010 ADACOR Hosting GmbH Kaiserleistrasse 51 63067 Offenbach am Main info@adacor.com www.adacor.com Cloud Services

Mehr

Wiederherstellung (Recovery)

Wiederherstellung (Recovery) Fragestellungen Aufgaben der Komponenten für das Recovery: Sicherstellung der Dauerhaftigkeit der gespeicherten Daten, d.h. Daten, die in einer Transaktion einmal bestätigt wurden (commit), bleiben auch

Mehr

SSDs als Cache für HDDs

SSDs als Cache für HDDs SSDs als Cache für HDDs CacheCade vs. BCache Dirk Geschke Linux User Group Erding 23. Oktober 2013 Dirk Geschke (LUG-Erding) SSD-Cache 23. Oktober 2013 1 / 71 Gliederung 1 Einleitunng 2 HDD Hard-Disk-Drive

Mehr

25.09.2014. Zeit bedeutet eine Abwägung von Skalierbarkeit und Konsistenz

25.09.2014. Zeit bedeutet eine Abwägung von Skalierbarkeit und Konsistenz 1 2 Dies ist ein Vortrag über Zeit in verteilten Anwendungen Wir betrachten die diskrete "Anwendungszeit" in der nebenläufige Aktivitäten auftreten Aktivitäten in einer hochgradig skalierbaren (verteilten)

Mehr

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1)

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) 1 FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) In dieser Kurseinheit geht es um verteilte Anwendungen, bei denen wir sowohl ein Client- als auch ein

Mehr

dsmisi Storage Lars Henningsen General Storage

dsmisi Storage Lars Henningsen General Storage dsmisi Storage dsmisi MAGS Lars Henningsen General Storage dsmisi Storage Netzwerk Zugang C Zugang B Zugang A Scale-Out File System dsmisi Storage Netzwerk Zugang C Zugang B Zugang A benötigt NFS oder

Mehr

Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06

Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06 Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06 Block Verteilte Systeme und Middleware 1. Beschreiben Sie die Entwicklung verteilter Systeme von einer Zentralisierung bis zu Peer-to-Peer. Nicht

Mehr

Leitfaden Datensicherung und Datenrücksicherung

Leitfaden Datensicherung und Datenrücksicherung Leitfaden Datensicherung und Datenrücksicherung Inhaltsverzeichnis 1. Einführung - Das Datenbankverzeichnis von Advolux... 2 2. Die Datensicherung... 2 2.1 Advolux im lokalen Modus... 2 2.1.1 Manuelles

Mehr

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen Mit der aktuellen Version hält eine komplett neu konzipierte webbasierte Anwendung Einzug, die sich neben innovativer Technik auch durch ein modernes Design und eine intuitive Bedienung auszeichnet. Angefangen

Mehr

4 Planung von Anwendungsund

4 Planung von Anwendungsund Einführung 4 Planung von Anwendungsund Datenbereitstellung Prüfungsanforderungen von Microsoft: Planning Application and Data Provisioning o Provision applications o Provision data Lernziele: Anwendungen

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Kap. 6 Message-Oriented Middleware (MOM)

Kap. 6 Message-Oriented Middleware (MOM) Kap. 6 Message-Oriented Middleware (MOM) G 6.1Asynchrone Prozedur- bzw. Methodenaufrufe Lose Kopplung von Komponenten G 6.2Queued Transactions Entkopplung von Client/Server-Transaktionen G 6.3Publish/Subscribe-Techniken

Mehr

Projektphasen und Technische Vorbereitung eines NX Refiles mit dem PLMJobManager

Projektphasen und Technische Vorbereitung eines NX Refiles mit dem PLMJobManager Projektphasen und Technische Vorbereitung eines NX Refiles mit dem PLMJobManager Dieses Dokument dient zur Information über die Organisation der Projektphasen und der technischen Vorbereitung eines Refile

Mehr

Proseminar Technische Informatik A survey of virtualization technologies

Proseminar Technische Informatik A survey of virtualization technologies Proseminar Technische Informatik A survey of virtualization technologies Referent: Martin Weigelt Proseminar Technische Informatik - A survey of virtualization technologies 1 Übersicht 1. Definition 2.

Mehr

OSL Unified Virtualization Server

OSL Unified Virtualization Server OSL Aktuell OSL Unified Virtualization Server 24. April 2013 Schöneiche / Berlin Grundlegende Prinzipien Konsequente Vereinfachungen Infrastruktur und Administration 1.) Virtual Machines (not clustered)

Mehr

Mit Clustertechnik zu mehr Verfügbarkeit:

Mit Clustertechnik zu mehr Verfügbarkeit: Mit Clustertechnik zu mehr Verfügbarkeit: Überraschend kostengünstig umgesetzt mit Open Source Werner Fischer, Thomas-Krenn.AG Perspektive Open Source Systems 2006 25. Oktober 2006 Folie 1/20 Agenda 1.

Mehr

Netzwerksicherheit. Teil 5: Virtualisierung und Ausfallsicherheit. Martin Mauve, Björn Scheuermann und Philipp Hagemeister

Netzwerksicherheit. Teil 5: Virtualisierung und Ausfallsicherheit. Martin Mauve, Björn Scheuermann und Philipp Hagemeister Netzwerksicherheit Teil 5: Virtualisierung und Ausfallsicherheit Martin Mauve, Björn Scheuermann und Philipp Hagemeister Sommersemester 2015 Heinrich-Heine-Universität Düsseldorf Netzwerksicherheit Virtualisierung

Mehr

Ihr Partner für Software im Bereich CNC-Maschinen. DNC über Ethernet

Ihr Partner für Software im Bereich CNC-Maschinen. DNC über Ethernet Ihr Partner für Software im Bereich CNC-Maschinen DNC über Ethernet NCP NC-Technik AG Juch 10 CH-5622 Waltenschwil. Tel.+41 56 621 88 66 Fax +41 56 621 88 04 Internet: http//www.ncp.ch E-Mail: info@ncp.ch

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Ausfallsicherheit maßgeschneidert

Ausfallsicherheit maßgeschneidert Wir unternehmen IT. Ausfallsicherheit maßgeschneidert Bringen Sie Kosten und Nutzen in Einklang! Henning von Kielpinski Head of Business Development Henning.von.Kielpinski@consol.de Hochverfügbarkeit Risiken

Mehr

Betriebssysteme Kap A: Grundlagen

Betriebssysteme Kap A: Grundlagen Betriebssysteme Kap A: Grundlagen 1 Betriebssystem Definition DIN 44300 Die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften dieser Rechenanlage die Basis der möglichen Betriebsarten

Mehr

IT-Kompaktkurs. Datenbanken Skript zur Folge 10. Prof. Dr. Dieter Rummler Fachhochschule Deggendorf

IT-Kompaktkurs. Datenbanken Skript zur Folge 10. Prof. Dr. Dieter Rummler Fachhochschule Deggendorf IT-Kompaktkurs Skript zur Folge 10 Prof. Dr. Dieter Rummler Fachhochschule Deggendorf Client Server Architektur Zunächst zur grundsätzlichen Unterscheidung zwischen File-Server Datenbank und Server-Datenbank

Mehr

Secure Mail Specials. Wir denken weiter. The Secure Mail Company

Secure Mail Specials. Wir denken weiter. The Secure Mail Company Secure Mail Specials. Wir denken weiter. The Secure Mail Company Secure Mail Specials 2 Secure Mail Specials Für jedes Unternehmen die perfekt passende Lösung. Lösungen Secure Mail ist als 1:1-Funktion

Mehr

Fehlertolerante und Selbstheilende Systeme.

Fehlertolerante und Selbstheilende Systeme. Fehlertolerante und Selbstheilende Systeme. Inhalt 1. 2. Fehlermodelle 3. Fehlertoleranztechniken 4. DCE (Dual Core Execution) 5. Fehlertoleranz 6. Zusammenfassung 2/29 Motivation Computer Aufgaben immer

Mehr

Heterogenes Speichermanagement mit V:DRIVE

Heterogenes Speichermanagement mit V:DRIVE Heterogenes Speichermanagement mit V:DRIVE V:DRIVE - Grundlage eines effizienten Speichermanagements Die Datenexplosion verlangt nach innovativem Speichermanagement Moderne Businessprozesse verlangen auf

Mehr

bintec elmeg Filialisten Lösungen mit WLAN Controllern IP Access WLAN ITK VoIP / VoVPN IT Security UC Unified Teldat Group Company

bintec elmeg Filialisten Lösungen mit WLAN Controllern IP Access WLAN ITK VoIP / VoVPN IT Security UC Unified Teldat Group Company Filialisten Lösungen mit WLAN Controllern Autor: Hans-Dieter Wahl, Produktmanager bei Teldat GmbH IP Access WLAN ITK VoIP / Vo IT Security UC Unified Communications WLAN Netzwerke findet man inzwischen

Mehr

Permanente Datenverfügbarkeit ist überlebensnotwendig!

Permanente Datenverfügbarkeit ist überlebensnotwendig! : Lösungsbeschreibung Permanente Datenverfügbarkeit ist überlebensnotwendig! Das Erreichen kürzerer Backup-Zeiten und eine schnellere Datenwiederherstellung sind laut einer Studie* zwei der wichtigsten

Mehr

D5 GmbH AnycastDNS SCHNELL, STABIL UND AUSFALLSICHER

D5 GmbH AnycastDNS SCHNELL, STABIL UND AUSFALLSICHER D5 GmbH AnycastDNS SCHNELL, STABIL UND AUSFALLSICHER Hochverfügbare Nameserver-Infrastruktur zum Schutz vor DoS-Attacken und für optimale Erreichbarkeit weltweit und jederzeit 1 AnycastDNS von D5 Höchste

Mehr

Kap. 6 Message-Oriented Middleware (MOM)

Kap. 6 Message-Oriented Middleware (MOM) Kap. 6 Message-Oriented Middleware (MOM) 6.1Asynchrone Prozedur- bzw. Methodenaufrufe Lose Kopplung von Komponenten 6.2Queued Transactions Entkopplung von Client/Server-Transaktionen 6.3Publish/Subscribe-Techniken

Mehr

Eine hochverfügbare Firewall mit Linux-HA, iptables und fwbuilder

Eine hochverfügbare Firewall mit Linux-HA, iptables und fwbuilder Eine hochverfügbare Firewall mit Linux-HA, iptables und fwbuilder FROSCON, 23.8.2009 Dr. Michael Schwartzkopff HA Firewall mit fwbuilder, Seite 1 Eine einfache Firewall Eine einfache Firewall mit Linux

Mehr

OSEKtime - Time-Triggered OSEK/OS

OSEKtime - Time-Triggered OSEK/OS OSEKtime - Time-Triggered OSEK/OS Gregor Kaleta gregor.kaleta@udo.edu PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Einleitung OSEKtime Task-Zustandsmodell, Scheduling-Verfahren Interrupt-Verarbeitung

Mehr

Problembehandlung bei Windows2000- Netzwerkdiensten

Problembehandlung bei Windows2000- Netzwerkdiensten Unterrichtseinheit 15: Problembehandlung bei Windows2000- Netzwerkdiensten Die Windows2000-Netzwerkinfrastruktur besteht aus vielen verschiedenen Komponenten und Verbindungen, in denen Netzwerkprobleme

Mehr

Die angegebenen Versionsnummern beziehen sich jeweils auf die Datei DbbLxGui.exe.

Die angegebenen Versionsnummern beziehen sich jeweils auf die Datei DbbLxGui.exe. Change Log: DBB/LX Die angegebenen Versionsnummern beziehen sich jeweils auf die Datei DbbLxGui.exe. 1. Version 4.5.0.1243 1. AF: Das Tool Datenbank neu aufbauen wurde ergänzt. Damit können Datenbanken,

Mehr

Perzentile mit Hadoop ermitteln

Perzentile mit Hadoop ermitteln Perzentile mit Hadoop ermitteln Ausgangspunkt Ziel dieses Projektes war, einen Hadoop Job zu entwickeln, der mit Hilfe gegebener Parameter Simulationen durchführt und aus den Ergebnissen die Perzentile

Mehr

Alles Spricht von RAID-Verband

Alles Spricht von RAID-Verband Alles Spricht von RAID-Verband Der Begriff "RAID" fiel in der Vergangenheit lediglich in dem Zusammenhang von Server-PC's. Doch heutzutage, wo die PC-Hardware immer günstiger werden und das Interesse an

Mehr

KURZANLEITUNG CLOUD BLOCK STORAGE

KURZANLEITUNG CLOUD BLOCK STORAGE KURZANLEITUNG CLOUD BLOCK STORAGE Version 1.12 01.07.2014 SEITE _ 2 INHALTSVERZEICHNIS 1. Einleitung......Seite 03 2. Anlegen eines dauerhaften Block Storage...Seite 04 3. Hinzufügen von Block Storage

Mehr

BICsuite!focus Parallelisierung von Prozessen mit der BICsuite Dynamic Submit Funktion

BICsuite!focus Parallelisierung von Prozessen mit der BICsuite Dynamic Submit Funktion independit Integrative Technologies GmbH Bergstraße 6 D 86529 Schrobenhausen BICsuite!focus Parallelisierung von Prozessen mit der BICsuite Dynamic Submit Funktion Dieter Stubler Ronald Jeninga July 30,

Mehr

Clustering und Failover mit Linux

Clustering und Failover mit Linux Grazer Linux-Tage 2003 25. April Markus Oswald Worum geht es? Load-Balanced Cluster Failover Cluster Shared Storage Computational Cluster Beowulf Distributed Computing Worum es nicht

Mehr

Software RAID oder LVM auf einem Suse Linux System aufsetzen

Software RAID oder LVM auf einem Suse Linux System aufsetzen Software RAID oder LVM auf einem Suse Linux System aufsetzen Das Software RAID Wir gehen hier nun von einer Neuinstallation aus. Hierbei haben wir zwei Festplatten im System, die ausschließlich nur für

Mehr

The Unbreakable Database System

The Unbreakable Database System The Unbreakable Database System Real Application Cluster Unterföhring, 04.2005 M. Kühn 1 Comparisson HA - HA Ziele, DataGuard, HA Oracle, RAC RAC Features - Cache Fusion, TAF, Load Balancing RAC on Solaris

Mehr

ParkingManagementSystem. Videobasiertes ParkraumManagementSystem INNENBEREICH und AUSSENBEREICH Beschreibung

ParkingManagementSystem. Videobasiertes ParkraumManagementSystem INNENBEREICH und AUSSENBEREICH Beschreibung ParkingManagementSystem Videobasiertes ParkraumManagementSystem INNENBEREICH und AUSSENBEREICH Beschreibung Stand 2014 Videobasierendes Parkraum Management System INNENBEREICH und AUSSENBEREICH STEUERUNG

Mehr

Handbuch zum Mensurenprogramm

Handbuch zum Mensurenprogramm Handbuch zum Mensurenprogramm Von Reiner Janke March-Buchheim (bei Freiburg) Reiner Janke 1996 Was kann das Programm? Das Programm schreibt Mensurlisten (Weiten-, Längen-, Aufschnittmensuren etc.) von

Mehr

TECHNISCHE PRODUKTINFORMATION CARUSO

TECHNISCHE PRODUKTINFORMATION CARUSO 1111 TECHNISCHE PRODUKTINFORMATION CARUSO TECHNISCHE PRODUKTINFORMATION Seite 0/7 Inhalt 1 Systemdefinition............2 2 Technische Details für den Betrieb von CARUSO......2 2.1 Webserver... 2 2.2 Java

Mehr

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015 Abstrakt zum Vortrag im Oberseminar Graphdatenbanken Gero Kraus HTWK Leipzig 14. Juli 2015 1 Motivation Zur Darstellung komplexer Beziehungen bzw. Graphen sind sowohl relationale als auch NoSQL-Datenbanken

Mehr