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.

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

Motivation für Fehlertoleranz in VS Fehlermodelle Erreichen von Fehlertoleranz. Verteilte Systeme. 7. Fehlertoleranz

Motivation für Fehlertoleranz in VS Fehlermodelle Erreichen von Fehlertoleranz. Verteilte Systeme. 7. Fehlertoleranz 7-2 Überblick Verteilte Systeme 7. Fehlertoleranz Sommersemester 2011 Motivation für Fehlertoleranz in VS Fehlermodelle Erreichen von Fehlertoleranz Ausfallsicherheit von Prozessen Zuverlässiger Remote

Mehr

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

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

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

Enterprise Computing Einführung in das Betriebssystem z/os. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/2013. WebSphere MQ Teil 3

Enterprise Computing Einführung in das Betriebssystem z/os. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/2013. WebSphere MQ Teil 3 UNIVERSITÄT LEIPZIG Enterprise Computing Einführung in das Betriebssystem z/os Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/2013 WebSphere MQ Teil 3 Trigger el0100 Copyright W. G. Spruth,

Mehr

Zuverlässige Systeme Fehlertoleranz

Zuverlässige Systeme Fehlertoleranz Zuverlässige Systeme Fehlertoleranz frank@upb.de Inhalt Übersicht und Namenskonventionen Was ist Fehlertoleranz Eine Anleitung in 4 Phase Redundanz und Vielfältigkeit Hardwareseitige Fehlertoleranz Softwareseitige

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

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

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

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

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

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

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

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

Kapitel 6 Anfragebearbeitung

Kapitel 6 Anfragebearbeitung LUDWIG- MAXIMILIANS- UNIVERSITY MUNICH DEPARTMENT INSTITUTE FOR INFORMATICS DATABASE Skript zur Vorlesung: Datenbanksysteme II Sommersemester 2014 Kapitel 6 Anfragebearbeitung Vorlesung: PD Dr. Peer Kröger

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

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

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

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

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

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

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

STORAGE. Martin Schmidt Berufsschule Obernburg

STORAGE. Martin Schmidt Berufsschule Obernburg STORAGE Martin Schmidt Berufsschule Obernburg Storage Begriffserklärung Storage ist die Bezeichnung für eine große Menge zusammenhängenden Speicherplatz in einem Netzwerk. Storage heißen auch die große

Mehr

Synchronisation des Temperatur-Loggers

Synchronisation des Temperatur-Loggers Synchronisation des Temperaturloggers Juni 10, 2010 1 / 7 Synchronisation des Temperatur-Loggers Einführung Zwei oder mehr Installationen der Temperaturlogger-Software können so zusammen geschaltet werden,

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

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

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

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

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

StorageCraft ImageManager ist eine voll ausgereifte Ergänzung zu

StorageCraft ImageManager ist eine voll ausgereifte Ergänzung zu Produktszenarien Was kann das Produkt für Sie tun? ist eine voll ausgereifte Ergänzung zu StorageCraft ShadowProtect, mit deren Hilfe Sie von einer einfachen Backup- und Wiederherstellungslösung zu einer

Mehr

Teil VI. Datenbanken

Teil VI. Datenbanken Teil VI Datenbanken Überblick 1 Grundlegende Begriffe Motivation 2 Relationale Datenbanksysteme Das Relationale Datenmodell SQL 3 Entwurf von Datenbanken Das Enity Relationship (ER) Modell Abbildung von

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

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

3 Programmiermodelle für parallele und verteilte Systeme

3 Programmiermodelle für parallele und verteilte Systeme 3 Programmiermodelle für parallele und verteilte Systeme Das vorherrschende Programmiermodell für parallele und verteilte Systeme ist das Client Server Modell. Das Client Server Modell ist unabhängig von

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

Kommunikation. Sitzung 01 04./11. Dezember 2015

Kommunikation. Sitzung 01 04./11. Dezember 2015 Kommunikation Sitzung 01 04./11. Dezember 2015 Unser Vorhaben Kommunikationsmodell Überblick über Netzwerk-Topologien Server-Client-Modell Internet Was ist Informatik eigentlich? Kunstwort aus Information

Mehr

PIWIN II. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II. Vorlesung 2 SWS SS 08

PIWIN II. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II. Vorlesung 2 SWS SS 08 PIWIN II Kap. 3: Verteilte Systeme & Rechnernetze 1 PIWIN II Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II Vorlesung 2 SWS SS 08 Fakultät für Informatik Technische

Mehr

CSMA/CD: - keine Fehlerkorrektur, nur Fehlererkennung - Fehlererkennung durch CRC, (Jabber) Oversized/Undersized

CSMA/CD: - keine Fehlerkorrektur, nur Fehlererkennung - Fehlererkennung durch CRC, (Jabber) Oversized/Undersized 1.1.: MAC-Adressen für CSMA/CD und TokenRing bestehen jeweils aus 48 Bits (6 Bytes). Warum betrachtet man diese Adressräume als ausreichend? (im Gegensatz zu IP) - größer als IP-Adressen (48 Bits 32 Bits)

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

Fragenkatalog zum Kurs 1666 (Datenbanken in Rechnernetzen) Kurstext von SS 96

Fragenkatalog zum Kurs 1666 (Datenbanken in Rechnernetzen) Kurstext von SS 96 Fragenkatalog zum Kurs 1666 (Datenbanken in Rechnernetzen) Kurstext von SS 96 Dieser Fragenkatalog wurde aufgrund das Basistextes und zum Teil aus den Prüfungsprotokollen erstellt, um sich auf mögliche

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

GeoShop Netzwerkhandbuch

GeoShop Netzwerkhandbuch Technoparkstrasse 1 8005 Zürich Tel.: 044 / 350 10 10 Fax.: 044 / 350 10 19 GeoShop Netzwerkhandbuch Zusammenfassung Diese Dokumentation beschreibt die Einbindung des GeoShop in bestehende Netzwerkumgebungen.

Mehr

Grundlagen von Datenbanken

Grundlagen von Datenbanken Grundlagen von Datenbanken Aufgabenzettel 1 Grundlagen Datenbanken: Kurzer historischer Überblick (1) Anwendung 1 Anwendung 2 Datei 1 Datei 2 Datei 3 Zugriff auf Dateien ohne spezielle Verwaltung 2 Exkurs:

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

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

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

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

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

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

Verteilte Systeme. Einführung. Prof. Dr. Oliver Haase

Verteilte Systeme. Einführung. Prof. Dr. Oliver Haase Verteilte Systeme Einführung Prof. Dr. Oliver Haase 1 Definition A distributed system is a collection of independent computers that appears to its users as a single coherent system. - Andrew Tanenbaum

Mehr

Man unterscheidet zwischen LAN (Local Area Network) und WAN (Wide Area Network), auch Internet genannt.

Man unterscheidet zwischen LAN (Local Area Network) und WAN (Wide Area Network), auch Internet genannt. Netzwerk Ein Netzwerk wird gebildet, wenn mehrere Geräte an einem Switch mit Netzwerkkabeln angeschlossen werden. Dabei können die einzelnen Geräte miteinander kommunizieren und über ein Netzwerkprotokoll

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

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

So erreichen Sie uns:

So erreichen Sie uns: für Das I Ho chp hre in Clus t d erf orm ividu ersy e s ll ant, sic en Be tem dü her und rfnis pre se. isw ert. So erreichen Sie uns: Contabo GmbH Aschauer Straße 32 a 81549 München +49 (0) 89 / 212 683

Mehr

B-Bäume I. Algorithmen und Datenstrukturen 220 DATABASE SYSTEMS GROUP

B-Bäume I. Algorithmen und Datenstrukturen 220 DATABASE SYSTEMS GROUP B-Bäume I Annahme: Sei die Anzahl der Objekte und damit der Datensätze. Das Datenvolumen ist zu groß, um im Hauptspeicher gehalten zu werden, z.b. 10. Datensätze auf externen Speicher auslagern, z.b. Festplatte

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

So erreichen Sie uns:

So erreichen Sie uns: für Das I Ho chp hre in Clus t d erf orm ividu ersy e s ll ant, sic en Be tem dü her und rfnis pre se. isw ert. So erreichen Sie uns: Giga-Hosting GmbH Aschauer Straße 32 a 81549 München +49 (0) 89 / 212

Mehr

Kapitel 14 Verteilte DBMS

Kapitel 14 Verteilte DBMS Kapitel 14 Verteilte DBMS 14 Verteilte DBMS 14 Verteilte DBMS...1 14.1 Begriff, Architektur und Ziele verteilter Datenbanksysteme...2 14.2 Verteilungsarten...5 14.2.1 Verteilung der Daten...5 14.2.2 Verteilung

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

VMware Schutz mit NovaBACKUP BE Virtual

VMware Schutz mit NovaBACKUP BE Virtual VMware Schutz mit NovaBACKUP BE Virtual Anforderungen, Konfiguration und Restore-Anleitung Ein Leitfaden (September 2011) Inhalt Inhalt... 1 Einleitung... 2 Zusammenfassung... 3 Konfiguration von NovaBACKUP...

Mehr

Root-Server für anspruchsvolle Lösungen

Root-Server für anspruchsvolle Lösungen Root-Server für anspruchsvolle Lösungen I Produktbeschreibung serverloft Internes Netzwerk / VPN Internes Netzwerk Mit dem Produkt Internes Netzwerk bietet serverloft seinen Kunden eine Möglichkeit, beliebig

Mehr

Astaro Mail Archiving Service Version 1.0

Astaro Mail Archiving Service Version 1.0 Astaro Mail Archiving Service Version 1.0 Verfahrensdokumentation Inhaltsverzeichnis 1. Einleitung... 2 2. Übersicht... 2 2.1 Production-Cloud... 3 2.2 Backup-Cloud... 3 2.3 Control-Cloud... 3 2.4 Zugangsschutz...

Mehr

Überblick. Multi-Cloud Computing Motivation Redundant Array of Cloud Storage (RACS) Zusammenfassung. c td MWCC (WS14/15) Multi-Cloud Computing 13 1

Überblick. Multi-Cloud Computing Motivation Redundant Array of Cloud Storage (RACS) Zusammenfassung. c td MWCC (WS14/15) Multi-Cloud Computing 13 1 Überblick Multi-Cloud Computing Motivation Redundant Array of Cloud Storage (RACS) Zusammenfassung c td MWCC (WS14/15) Multi-Cloud Computing 13 1 Vendor Lock-In -Problem Typische Vorgehensweise bei der

Mehr

Protected User-Level DMA in SCI Shared Memory Umgebungen

Protected User-Level DMA in SCI Shared Memory Umgebungen Protected User-Level DMA in SCI Shared Memory Umgebungen Mario Trams University of Technology Chemnitz, Chair of Computer Architecture 6. Halle Chemnitz Seminar zu Parallelverarbeitung und Programmiersprachen

Mehr

SMS versenden mit ewon über Mail Gateway Am Beispiel von dem Freemail Anbieter GMX wird diese Applikation erklärt

SMS versenden mit ewon über Mail Gateway Am Beispiel von dem Freemail Anbieter GMX wird diese Applikation erklärt ewon - Technical Note Nr. 014 Version 1.2 SMS versenden mit ewon über Mail Gateway Am Beispiel von dem Freemail Anbieter GMX wird diese Applikation erklärt Übersicht 1. Thema 2. Benötigte Komponenten 3.

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

mywms Vorlage Seite 1/5 mywms Datenhaltung von Haug Bürger

mywms Vorlage Seite 1/5 mywms Datenhaltung von Haug Bürger mywms Vorlage Seite 1/5 mywms Datenhaltung von Haug Bürger Grundlegendes Oracle9i PostgreSQL Prevayler Memory mywms bietet umfangreiche Konfigurationsmöglichkeiten um die Daten dauerhaft zu speichern.

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

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

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

VoIPcom Supportpakete

VoIPcom Supportpakete VoIPcom Supportpakete bietet drei verschiedene Supportpakete an. Anrecht auf das Supportpaket Silber haben grundsätzlich alle Kunden, welche eine VoIPcom Telefonanlage im Einsatz haben. Für Firmenkunden

Mehr

Installation des Zertifikats am Beispiel eines Exchange-Mail-Servers. Voraussetzungen. Zertifikate importieren. Outlook-Webaccess

Installation des Zertifikats am Beispiel eines Exchange-Mail-Servers. Voraussetzungen. Zertifikate importieren. Outlook-Webaccess HS-Anhalt (FH) Fachbereich EMW Seite 1 von 6 Stand 04.02.2008 Installation des Zertifikats am Beispiel eines Exchange-Mail-Servers Bedingt durch die verschiedenen Transportprotokolle und Zugriffsmethoden

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

Babeș-Bolyai Universität Cluj Napoca Fakultät für Mathematik und Informatik Grundlagen der Programmierung MLG5005. Paradigmen im Algorithmenentwurf

Babeș-Bolyai Universität Cluj Napoca Fakultät für Mathematik und Informatik Grundlagen der Programmierung MLG5005. Paradigmen im Algorithmenentwurf Babeș-Bolyai Universität Cluj Napoca Fakultät für Mathematik und Informatik Grundlagen der Programmierung MLG5005 Paradigmen im Algorithmenentwurf Problemlösen Problem definieren Algorithmus entwerfen

Mehr

VS3 Slide 1. Verteilte Systeme. Vorlesung 3 vom 22.04.2004 Dr. Sebastian Iwanowski FH Wedel

VS3 Slide 1. Verteilte Systeme. Vorlesung 3 vom 22.04.2004 Dr. Sebastian Iwanowski FH Wedel VS3 Slide 1 Verteilte Systeme Vorlesung 3 vom 22.04.2004 Dr. Sebastian Iwanowski FH Wedel Inhaltsverzeichnis für die Vorlesung Zur Motivation: 4 Beispiele aus der Praxis Allgemeine Anforderungen an Verteilte

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

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

Transaction Validation for XML Documents based on XPath

Transaction Validation for XML Documents based on XPath Transaction Validation for XML Documents based on XPath @ Informatik 2002, m-dbis Stefan Böttcher Adelhard Türling Universität Paderborn Überblick Transaktionen für XML - Daten & mobile Clients Motivation

Mehr

Einführung. Kapitel 1 2 / 508

Einführung. Kapitel 1 2 / 508 Kapitel 1 Einführung 2 / 508 Einführung Was ist ein Datenbanksystem (DBS)? Ein System zum Speichern und Verwalten von Daten. Warum kein herkömmliches Dateisystem verwenden? Ausfallsicherheit und Skalierbarkeit

Mehr

Multiuser Client/Server Systeme

Multiuser Client/Server Systeme Multiuser /Server Systeme Christoph Nießner Seminar: 3D im Web Universität Paderborn Wintersemester 02/03 Übersicht Was sind /Server Systeme Wie sehen Architekturen aus Verteilung der Anwendung Protokolle

Mehr

Fresh Minder 3-Server

Fresh Minder 3-Server Fresh Minder 3-Server Installation und Betrieb Fresh Minder-Vertrieb Rieslingweg 25 D - 74354 Besigheim support@freshminder.de www.freshminder.de ÜBERSICHT Die Standardversion (Einzelplatzversion) von

Mehr

ISCSI im Netzwerk und im Internet. Markus Sellner

ISCSI im Netzwerk und im Internet. Markus Sellner Vorwort Ursprung iscsi Theorie Anwendung Hardware Vor- und Nachteile Fazit Quellen und Informationen 2 Was ist iscsi? iscsi (internet Small Computer System Interface) ist eine Technologie, um Speichergeräte

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

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

VRRP. Bild 004482 zeigt die Adressangaben in einem IP-Paket bei dessen Übermittlung über die Grenze eines IP-Subnetzes hinweg.

VRRP. Bild 004482 zeigt die Adressangaben in einem IP-Paket bei dessen Übermittlung über die Grenze eines IP-Subnetzes hinweg. VRRP Virtual Router Redundancy Protocol Autor: Prof. Dr.-Ing. Anatol Badach Auszug aus dem Werk: Herausgeber: Heinz Schulte WEKA-Verlag ISBN 978-3824540662 Netzwerke auf Basis des Internet Protocol (IP)

Mehr

Rembo/mySHN. Version 2.0 Kurzanleitung. das selbstheilende Netzwerk. Stand: 01.05.2006. my selfhealing network

Rembo/mySHN. Version 2.0 Kurzanleitung. das selbstheilende Netzwerk. Stand: 01.05.2006. my selfhealing network Rembo/mySHN Version 2.0 Kurzanleitung das selbstheilende Netzwerk my selfhealing network Stand: 01.05.2006 Postanschrift: SBE network solutions GmbH Edisonstrasse 21 74076 Heilbronn IV Inhalt Kurzanleitung...i

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

Überwachung von WebSphere M

Überwachung von WebSphere M BMC User Forum 2011 Überwachung von WebSphere M Wozu brauche ich ein Monitoring? 2011 Hubert Kleinmanns Agenda Vorstellung Einführung in WebSphere MQ MQ hat ein Problem Monitoring von WMQ Zusammenfassung

Mehr

Ein einfaches Modell zur Fehlerfortpflanzung

Ein einfaches Modell zur Fehlerfortpflanzung Ein einfaches Modell zur Fehlerfortpflanzung Jens Chr. Lisner lisner@dc.uni-due.de ICB / Universität Duisburg-Essen AK Fehlertoleranz 11/2006 p. Problemstellung Üblich bei der Formalisierung von Systemen:

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

Fehlertolerante verteilte Systeme, Peer-To-Peer Netzwerke

Fehlertolerante verteilte Systeme, Peer-To-Peer Netzwerke Fehlertolerante verteilte Systeme, Peer-To-Peer Netzwerke Hauptseminar im SS 2002 Hans Reiser, Rüdiger Kapitza Lehrstuhl für Informatik 4 Verteilte Systeme und Betriebssysteme Universität Erlangen-Nürnberg

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

MySQL Community Server 5.6 Installationsbeispiel (Ab 5.5.29)

MySQL Community Server 5.6 Installationsbeispiel (Ab 5.5.29) MySQL Community Server 5.6 Installationsbeispiel (Ab 5.5.29) Dieses Dokument beschreibt das Herunterladen der Serversoftware, die Installation und Konfiguration der Software. Bevor mit der Migration der

Mehr

Datenträgerverwaltung

Datenträgerverwaltung Datenträgerverwaltung Datenträgerverwaltung 1/9 Datenträgerverwaltung Inhaltsverzeichnis Vorgangsweise...2 Umwandeln einer Basisfestplatte in eine Dynamische Festplatte... 2 Spiegelung erstellen... 4 Partitionen

Mehr

Systemvoraussetzungen und Installation

Systemvoraussetzungen und Installation Systemvoraussetzungen und Installation Inhaltsverzeichnis Inhaltsverzeichnis... 2 1. Einleitung... 2 2. Einzelarbeitsplatzinstallation... 3 3. Referenz: Client/Server-Installation... 5 3.1. Variante A:

Mehr

Verfahren zur Berechnung von Routen zur Gewährleistung von Ende-zu-Ende QoS

Verfahren zur Berechnung von Routen zur Gewährleistung von Ende-zu-Ende QoS Verfahren zur Berechnung von Routen zur Gewährleistung von Ende-zu-Ende QoS Dezember 007 Dipl.-Ing. Stefan Abu Salah Dipl.-Ing. Achim Marikar QoS (Quality of Service): Sicherstellung der Qualität Zeitkritische

Mehr

BRÜCKENTYPEN FUNKTION UND AUFGABE

BRÜCKENTYPEN FUNKTION UND AUFGABE Arbeitet auf der OSI-Schicht 2 Verbindet angeschlossene Collision-Domains mit verwandten Protokollen In jeder Collision-Domain kann gleichzeitig Kommunikation stattfinden Nur eine Verbindung über eine

Mehr