12 Fehlertoleranz. Begriffe

Größe: px
Ab Seite anzeigen:

Download "12 Fehlertoleranz. Begriffe"

Transkript

1 12 Fehlertoleranz ein verteiltes System beinhaltet viele Abstraktionsebenen, die stark voneinander abhängen. - z.b. hängt der Klient von seinem Server ab, der wiederum von seinen Diensten, etc. - die Kette der Abhängigkeiten setzt sich durch die Softwareebenen bis zur Hardware fort. Fehlertoleranz bedeutet, dass das Gesamtsystem einen Fehler einer Komponente in den Abhängigkeitsrelationen maskiert. das Fehlverhalten einer Komponente wird vom Gesamtsystem ausgeglichen. Michael Weber, Verteilte Systeme, Wintersemester 2000/2001, Kapitel 12, Seite 1 Begriffe Failure das System verhält sich nicht wie spezifiziert. Error Teil eines Systemzustands, der verantwortlich für eine zukünftige Failure ist, falls keine entsprechenden Maßnahmen getroffen werden. Fault die Ursache eines Errors. da ein Error Teil des Systemzustandes ist, lässt sich dieser beobachten und evaluieren. eine Failure (d.h. Fehlverhalten) ist nicht leicht observierbar. - sie muss mit speziellen Mechanismen aus einem Error abgeleitet werden. - wenn nicht jeder Systemzustand erfasst wird, kann Fehlverhalten entstehen, ohne dass es bemerkt wird. ein (verteiltes) System ist fehlertolerant (engl.: fault tolerant), wenn es in der Lage ist, sich trotz des Auftretens von Faults spezifikationskonsistent zu verhalten. Redundanz wird als Schlüsselverfahren auf drei Ebenen eingesetzt. - bei Hardwareredundanz werden Hardwarekomponenten zusätzlich im System hinzugefügt. - bei Softwareredundanz werden Softwarekomponenten oder Codesegmente mehrfach bereitgehalten und ausgeführt. - bei Zeitredundanz wird zusätzliche Ausführungszeit für die vorgenannten Techniken spendiert. Michael Weber, Verteilte Systeme, Wintersemester 2000/2001, Kapitel 12, Seite 2

2 Phasen eines fehlertoleranten Systems Fehlererkennung (engl.: error detection) - ein Fehler wird im Zustand bemerkt (error) und daraus auf einen Fehler (fault) in einem Teil des Systems geschlossen. - Man nimmt an, dass dann ein Fehlverhalten (failure) der betroffenen Komponente des Systems auftritt. Schadensermittlung (engl.: damage confinement) - welcher Schaden ist bis zum Zeitpunkt der Erkennung aufgetreten. - die Auswirkungen sollten auf einen bekannten und beschränkten Bereich eingegrenzt werden können. Fehlerrecovery (engl.: error recovery) - der aufgetretene fehlerhafte Zustand wird behoben. - das System wird in einen korrekten Zustand gebracht. Fehlerbehandlung und Weiterführen des Systems (engl.: fault treatment and continued system service) - das fehlertolerante System soll spezifikationskonform weiter arbeiten - die fehlerhafte Komponente wird umgangen oder - in einer anderen Konfiguration verwendet. Michael Weber, Verteilte Systeme, Wintersemester 2000/2001, Kapitel 12, Seite 3 in sicherheitskritischen Systemen wird Fehlertoleranz oft durch redundante Auslegung der Hardware realisiert. - z.b. drei identische Hardwarekomponenten (engl.: triple modular redundancy, TMR), die mit den gleichen Eingaben im gleichen Takt arbeiten. - aus den drei Ergebnissen entscheidet die Majorität. - dadurch ist das System gegenüber dem Ausfall und der Fehlfunktion einer Komponente tolerant. - bei nur zwei Replikaten könnte nur der Ausfall einer Komponente maskiert werden. Michael Weber, Verteilte Systeme, Wintersemester 2000/2001, Kapitel 12, Seite 4

3 Ebenen und Bausteine fehlertoleranter Software Bausteine Fail-Stop Prozessoren beenden ihre Tätigkeit bei einem entdeckten Fehler und arbeiten nicht fehlerhaft im System weiter. in stabilem Speicher sind Daten auch nach dem Auftreten eines Fehlers fehlerfrei verfügbar. durch zuverlässige Kommunikation werden Nachrichten sicher und in der richtigen Reihenfolge zugestellt. auf den Basiselementen kann zuverlässige und atomare Broadcastkommunikation aufgebaut werden. unter Verwendung der Bausteine lassen sich unterschiedlich tolerante Dienste entwickeln. Michael Weber, Verteilte Systeme, Wintersemester 2000/2001, Kapitel 12, Seite 5 Fehlertoleranz- Dienste Bausteine fehlertolerante Software Prozeß-Zuverlässigkeit (Process-Resilience) Daten-Zuverlässigkeit (Data-Resilience) atomare Aktionen konsistente Zustands-Recovery zuverlässiger und atomarer Broadcast Fail-Stop Prozessoren, stabiler Speicher, zuverlässige Kommunikation verteiltes System fortgesetzter Dienst bei Designfehlern fortgesetzter Dienst bei Knotenfehlern Konsistenz bei Knotenfehlern Bild 12.1: Ebenen in einem fehlertoleranten verteilten System Michael Weber, Verteilte Systeme, Wintersemester 2000/2001, Kapitel 12, Seite 6

4 12.1 Fehlersemantik Fehlersemantik beschreibt das Verhalten von Systemkomponenten und des gesamten Systems im Fehlerfall. Je nach Art des Fehlers wird das Fehlverhalten in verschiedene Klassen eingeteilt [Cri91] - Dienstverweigerung (engl.: omission failure bzw. denial of service) - eine Komponente reagiert nicht mit einer Antwort auf einen Auftrag. z.b. durch verlorengehende Nachrichten im Kommunikationsdienst. - fehlerhafte Antwort - eine Komponente antwortet falsch auf einen Auftrag (engl.: response failure). - falsche Werte werden übermittelt (engl.: value failure) - intern finden falsche Zustandsübergänge statt (engl.: state transition failure) und es entstehen lokal falsche Werte. - Zeitfehler (engl.: timing failure) - eine Komponente antwortet richtig, jedoch zum falschen Zeitpunkt. - meist kommen die Antworten zu spät z.b. durch einen überlasteten Server oder schlechte Netzverbindung. - Antworten können auch zu früh ankommen. z.b. in Echtzeitsystemen oder Multimediasystemen. Michael Weber, Verteilte Systeme, Wintersemester 2000/2001, Kapitel 12, Seite 7 - Serverabsturz (engl.: crash failure) - ein Server verweigert kontinuierlich seinen Dienst. - er wird von Klienten als abgestürzt vermutet. - weitere Unterscheidung je nach Zustand der Serverdaten nach Wiederanlaufen: - Amnesie-Crash: der Server startet im Initialzustand. er verliert jegliche Datenzustände zum Zeitpunkt des Absturzes. - Pause-Crash: der Server startet in dem Zustand, den er vor dem Absturz hatte. - Halte-Crash: die fehlerhafte Komponente steht nach dem Fehler und wird nicht erneut gestartet. - Byzantinische Fehler - eine Komponente verhält sich beliebig. - es können beliebige Kombinationen der anderen Klassen vorkommen. - oft sind Hardwarefehler dieursache von byzantinischen Fehlern. z.b. ein defekter Timerbaustein zerstört die Ordnung von Nachrichten. Michael Weber, Verteilte Systeme, Wintersemester 2000/2001, Kapitel 12, Seite 8

5 die Fehlersemantik beschreibt das Verhalten des Systems im Fehlerfall. d.h. ein fehlertolerantes System muss dies maskieren. - z.b. muss ein Service mit Omission-Semantik zur Fehlertoleranz so erweitert werden, dass verlorengehende Aufträge automatisch vom Klienten wiederholt werden. je mehr Fehlersemantiken tolerant begegnet werden soll, um so aufwendiger wird die Programmierung. die starke Schichtung eines Systems aus Mechanismen und Diensten bedingt eine hohe Abhängigkeit der Komponenten. Fehler werden von unteren Schichten in die höheren propagiert. dabei können sich Fehlerklassen ändern und sehr komplexe Phänomene auftreten. Michael Weber, Verteilte Systeme, Wintersemester 2000/2001, Kapitel 12, Seite 9 Maskierung von Fehlern Hierarchische Maskierung - Fehler von Diensten oder Komponenten niedrigerer Ebene werden von den sie nutzenden Komponenten höherer Ebene maskiert. - ist eine Maskierung auf einer unteren Ebene nicht möglich, wird eine Ausnahme (engl.: exception) auf höherer Ebene ausgelöst, um dann dort maskiert zu werden. - einfaches Beispiel: - Abfrage auf Division durch Null, wenn die Divisionshardware dies nicht selbst melden kann. IF Nenner <> 0 THEN Teile... ELSE Fehlerbehandlung... - Wenn auf allen Ebenen die Maskierung unmöglich ist, muss letztlich der Benutzer über die Ausnahme informiert werden. Maskierung durch Gruppenbildung - der Fehler einer einzelnen Komponente wird durch die Replikation der Funktionalität in einer Gruppe verborgen. - eine Gruppe heisst k-fehlertolerant, wenn sie den gleichzeitigen Ausfall von k Mitgliedern maskieren kann. - es genügen k+1 Gruppenmitglieder, um das Fehlverhalten von k Komponenten zu maskieren. - für byzantinische Fehler werden 3k+1 Mitglieder benötigt, da eine Mehrheitsentscheidung notwendig ist. Michael Weber, Verteilte Systeme, Wintersemester 2000/2001, Kapitel 12, Seite 10

6 12.2 Passive Redundanz Passive Redundanz kann durch den Primary-Backup-Ansatz erreicht werden. es existieren k Replikate von Prozessen oder Daten, wobei ein Replikat als Primärserver fungiert. die restlichen Replikate arbeiten als Backup. Anfragen werden immer an den Primärserver gestellt. ist der Primärserver fehlerhaft oder antwortet nicht, wird er durch einen Backupserver ersetzt. Michael Weber, Verteilte Systeme, Wintersemester 2000/2001, Kapitel 12, Seite 11 Aktualisierung der Backupserver: - Hot-Standby - die Backupserver laufen synchron mit dem Primärserver mit. - alle Anfragen gehen an alle Server. - die Antwort wird nur vom Primärserver erbracht. - beim Ausfall des Primärservers ist sofort ein Backupserver verfügbar. - Warm-Standby - Aufträge werden beim Primärserver gespeichert und periodisch den Backupservern übermittelt. - die Backupserver werden dadurch nachgezogen. - nach einem Ausfall muss der letzte Backupblock noch bearbeitet werden. - ein Backupserver steht nach kurzer Zeit zur Verfügung. - Cold-Standby - alle Aufträge und Datenveränderungen werden beim Primärserver stabil gespeichert. - fällt der Primärserver aus, muss anhand dieser Daten ein Backupserver vollständig nachgezogen werden. - die Verzögerung für das Fortsetzen des Dienstes ist unter Umständen recht lang. Michael Weber, Verteilte Systeme, Wintersemester 2000/2001, Kapitel 12, Seite 12

7 damit Lebendigkeit und Verfügbarkeit des Primärservers überwacht werden kann, sendet dieser meist periodisch ALIVE-Nachrichten an seine Backupserver. werden eine bestimmte Zeit keine ALIVE-Nachrichten empfangen, vermuten die Backupserver, dass der Primärserver nicht mehr verfügbar ist. die Backupserver wählen unter sich einen neuen Primärserver. Passive Redundanz kann einen Knotenfehler, d.h. omission, des Primärservers maskieren. Passive Redundanz wird auch als lose Synchronisation bezeichnet. Michael Weber, Verteilte Systeme, Wintersemester 2000/2001, Kapitel 12, Seite Aktive Redundanz alle beteiligten Komponenten bzw. Server sind als Zustandsmaschinen mit identischen Übergangsfunktionen implementiert. Anfragen und Kommandos von außen verändern die Zustände aller Server synchron. wenn die Zustandsmaschinen im gleichen initialen Zustand beginnen und Kommandos in der gleichen Reihenfolge bearbeiten, befinden sich alle Maschinen immer im gleichen Zustand und erzeugen identische Ausgaben. aktive Redundanz bezeichnet man auch als enge Synchronisation. fällt eine Komponente aus, kann dies zu jedem Zeitpunkt maskiert werden. Die Maskierung eines Fehlers erfordert Übereinkunft (engl.: agreement) und Ordnung (engl.: order). - Übereinkunft: - jede nicht-fehlerhafte Zustandsmaschine empfängt alle Kommandos und weiss welche anderen nicht-fehlerhaft sind. - Ordnung: - die empfangenen Kommandos werden bei allen Servern in der gleichen Reihenfolge ausgeführt. Michael Weber, Verteilte Systeme, Wintersemester 2000/2001, Kapitel 12, Seite 14

8 Übereinkunft kann durch ein byzantinisches Übereinkunftsprotokoll für byzantinische Fehler oder durch einen zuverlässigen Broadcast bei Fail-Stop-Verhalten realisiert werden. Ordnung kann man durch eindeutige Identifikatoren aller Nachrichten und eine totale Ordnung über diese Identifikatoren erreichen. theoretisch lässt sich in verteilten Systemen bei asynchronen Prozessen und unbeschränkter Nachrichtenlaufzeit Übereinkunft nicht erzielen [FLP85]. daher ist immer eine Restwahrscheinlichkeit gegeben, dass das fehlertolerante System Fehlverhalten zeigt. Michael Weber, Verteilte Systeme, Wintersemester 2000/2001, Kapitel 12, Seite 15 Byzantinisches Generalsproblem auf den Hügeln um Byzanz stehen die Truppen einiger römischer Generäle. um den Angriff zu koordinieren, melden sich die Generäle gegenseitig ihre Truppenstärken. keiner der Generäle kann sicher sein, dass nicht ein anderer General bestochen wurde und falsche Angaben macht, bzw. dass Nachrichten während der Übermittlung verfälscht werden. Beispiel X Y 4 Bild 12.2 Byzantinisches Generalsproblem 3 Z 4 4 Michael Weber, Verteilte Systeme, Wintersemester 2000/2001, Kapitel 12, Seite 16

9 Übereinkunftsprotokoll von Lamport, Shostak und Pease 1982: - die Generäle teilen sich ihre Truppenstärken mit und erhalten folgende Information: 1: (1,2,X,4)2: (1,2,Y,4)3: (1,2,3,4)4: (1,2,Z,4) - die Generäle tauschen die gesammelten Informationen untereinander aus und haben danach folgende Entscheidungsgrundlage: 1: (1,2,Y,4)2: (1,2,X,4)3: (1,2,X,4)4: (1,2,X,4) (a,b,c,d) (e,f,g,h) (1,2,Y,4) (1,2,Y,4) (1,2,Z,4) (1,2,Z,4) (1,2,Z,4) (i,j,k,l) - jeder General kann selbst eine Majoritätsentscheidung durchführen. z.b. ist für General 1 klar, dass die Werte an den Positionen 1, 2 und 4 korrekt sind und der dritte General ein Fehlverhalten aufweist. mit dem Algorithmus können 3k+1 Komponenten k fehlerhaft arbeitende Komponenten maskieren. für die Mehrheitsentscheidung sind 2k+1 funktionstüchtige Komponenten notwendig (mehr als zwei Drittel). Michael Weber, Verteilte Systeme, Wintersemester 2000/2001, Kapitel 12, Seite 17 Beispiel: 2k+1 Komponenten reichen nicht aus (hier: k=1). - in beiden Szenarien weiss A nicht, welcher der beiden anderen Knoten fehlerhaft ist, da er jeweils die gleichen Nachrichteninhalte empfängt. B 1 1 B 1 0 fehlerhaft A 0 C fehlerhaft A 0 C Bild 12.3 Byzantinische Übereinkunft ist mit 2k+1 Komponenten unmöglich Michael Weber, Verteilte Systeme, Wintersemester 2000/2001, Kapitel 12, Seite 18

10 12.4 Zuverlässigkeit bei Softwaredesignfehlern Problem: - verwendet man für die Redundanz identische Software, wird ein Programmierfehler in allen Replikaten zum Tragen kommen. N-Versionen-Programmierung ein Problem wird von N verschiedenen Entwicklungsteams oder in N Varianten unabhängig voneinander bearbeitet. es entstehen N verschiedene Designs, welche die gleiche Funktionalität und identische Schnittstellen bieten. mit sehr hoher Wahrscheinlichkeit haben die einzelnen Versionen unterschiedliche Fehler, so dass sie gegenseitig die Fehler einzelner maskieren können. alle Programme laufen gleichzeitig aktiv redundant mit den gleichen Eingaben. die mehrfache Ausgabe wird durch einen Mehrheitsentscheid in eine einzige Ausgabe überführt. es muss beachtet werden, dass unter Umständen nicht auf exakte Gleichheit geprüft werden kann (engl.: consistent comparison problem). - eine Berechnung mit Gleitkommazahlen kann mit unterschiedlicher Rechenreihenfolge unterschiedliche Rundungsfehler erzeugen. weiteres Problem: die Laufzeit wird immer von der langsamsten Komponente bestimmt. Michael Weber, Verteilte Systeme, Wintersemester 2000/2001, Kapitel 12, Seite 19 Recoveryblock in einer Komponente werden kritische Kodepassagen in mehreren Versionen implementiert. die Komponente führt zuerst die Primärversion aus und prüft das Ergebnis durch einen Akzeptanztest gegen die Spezifikation. ist ein Fehler aufgetreten, wird der ursprüngliche Zustand wiederhergestellt und die nächste alternative Version benutzt. die Alternativen lassen sich schachteln. Beispiel: ensure <acceptance test> by <primary module> else by <alternate module 1>... else by <alternate module n> else error ein Akzeptanztest ist kein vollständiger, erschöpfender Test aller Systemanforderungen, sondern eher eine Stichprobe. er ist dazu so flexibel zu halten, dass mehrere leicht unterschiedliche Ausgaben der zu testenden Module zulässig sein können. Michael Weber, Verteilte Systeme, Wintersemester 2000/2001, Kapitel 12, Seite 20

11 man kann dynamisch durch verschiedene Akzeptanztests auch unterschiedliches Verhalten des Systems ermöglichen. - wenn der erste Akzeptanztest nicht erfolgreich ist, führt man einen abgeschwächten Test mit geringeren Anforderungen durch. - wird dies wiederholt vorgenommen, kann ein adaptives System mit automatisch angepasster reduzierter Funktionalität realisiert werden (engl.: graceful degradation). Michael Weber, Verteilte Systeme, Wintersemester 2000/2001, Kapitel 12, Seite 21

Verteilte Systeme F. Fehlertoleranz

Verteilte Systeme F. Fehlertoleranz Verteilte Systeme F. Fehlertoleranz Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.1 Fehlertoleranz Abhängigkeiten in einem verteilten System: Client! Server! Dienste! Software!

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

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

Fehlertoleranzmechanismen in hochverfügbaren Clustersystemen

Fehlertoleranzmechanismen in hochverfügbaren Clustersystemen Holger Sattel Seminar Rechnerarchitektur WS 2003/04 Universität Mannheim Lehrstuhl Rechnerarchitektur Prof. Dr. U. Brüning Inhaltsverzeichnis Grundlagen / Begriffe Fehlertoleranz Fehlertoleranz in (Rechen-)Clustern

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

Hochverfügbarkeits-Szenarien

Hochverfügbarkeits-Szenarien Series Hochverfügbarkeits-Szenarien Mehrere Telefonanlagen können redundant aufgebaut werden. Dabei sind alle Anlagen aktiv geschaltet und teilen sich die Last (Anrufe, Telefonkonferenzen, usw.) gleichmässig

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

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

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

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

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

Inhaltsverzeichnis. Vorwort 13. Kapitel 1 Einleitung 17. Kapitel 2 Architekturen 51. Kapitel 3 Prozesse 91

Inhaltsverzeichnis. Vorwort 13. Kapitel 1 Einleitung 17. Kapitel 2 Architekturen 51. Kapitel 3 Prozesse 91 Inhaltsverzeichnis Vorwort 13 Kapitel 1 Einleitung 17 1.1 Definition eines verteilten Systems................................ 19 1.2 Ziele........................................................ 20 1.2.1

Mehr

Verteilte Systeme. Synchronisation I. Prof. Dr. Oliver Haase

Verteilte Systeme. Synchronisation I. Prof. Dr. Oliver Haase Verteilte Systeme Synchronisation I Prof. Dr. Oliver Haase 1 Überblick Synchronisation 1 Zeit in verteilten Systemen Verfahren zum gegenseitigen Ausschluss Synchronisation 2 Globale Zustände Wahlalgorithmen

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

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

Zeit- und ereignisgesteuerte Echtzeitsysteme

Zeit- und ereignisgesteuerte Echtzeitsysteme Zeit- und ereignisgesteuerte Echtzeitsysteme Stephan Braun Stephan.Braun.Hagen@t-online.de PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Echtzeitsystemmodell Einführung Ereignis- und zeitgesteuerte

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

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

Alle Metadaten werden in Dateien gehalten

Alle Metadaten werden in Dateien gehalten 6 Beispiel: Windows NT (NTFS) 6.3 Metadaten 6.3 Metadaten Alle Metadaten werden in Dateien gehalten Indexnummer 0 1 2 3 4 5 6 7 8 16 17 MFT MFT Kopie (teilweise) Log File Volume Information Attributtabelle

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

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

Seminarvortrag: Hardware-Fehlertoleranz mit Hochverfügbarkeit

Seminarvortrag: Hardware-Fehlertoleranz mit Hochverfügbarkeit Seminarvortrag: Hardware-Fehlertoleranz mit Hochverfügbarkeit Agenda Motivation Hardware-Fehlertoleranz Checkpointing and Rollback Recovery Systemverfügbarkeit VM-basierte Systeme Remus Architektur Sicherung

Mehr

Stefan Lucks Krypto und Mediensicherheit (2009) 4: Stromchiffren

Stefan Lucks Krypto und Mediensicherheit (2009) 4: Stromchiffren 4: Stromchiffren Zwei Grundbausteine der symmetrischen Kryptographie: Stromchiffren Verschlüsseln beliebig langer Klartexte, interner Zustand Blockchiffren Verschlüsseln von Blocks einer festen Größe,

Mehr

Überblick. 2 Bestandsaufnahme 2.1 Beispiele von verteilten Systemen 2.2 Anwendungsszenarien 2.3 Vorteile 2.4 Problembereiche

Überblick. 2 Bestandsaufnahme 2.1 Beispiele von verteilten Systemen 2.2 Anwendungsszenarien 2.3 Vorteile 2.4 Problembereiche Überblick 2 Bestandsaufnahme 2.1 Beispiele von verteilten Systemen 2.2 Anwendungsszenarien 2.3 Vorteile 2.4 Problembereiche c rk,wosch,jk VS (SS 2015) 2 Bestandsaufnahme 2 1 Prozessorfarm @Google c rk,wosch,jk

Mehr

Replikation. Überblick. Referenzierung von Diensten. Aktive Replikation von Diensten. Varianten Aktive Replikation ( Replikation

Replikation. Überblick. Referenzierung von Diensten. Aktive Replikation von Diensten. Varianten Aktive Replikation ( Replikation Überblick Grundlagen der JGroups Varianten Aktive ( Hot Standby ) Alle Replikate bearbeiten alle Anfragen Vorteil: Schnelles Tolerieren von Ausfällen möglich Nachteil: Vergleichsweise hoher Ressourcenverbrauch

Mehr

Empfänger. Sender. Fehlererkennung und ggf. Fehlerkorrektur durch redundante Informationen. Längssicherung durch Paritätsbildung (Blockweise)

Empfänger. Sender. Fehlererkennung und ggf. Fehlerkorrektur durch redundante Informationen. Längssicherung durch Paritätsbildung (Blockweise) Datensicherung Bei der digitalen Signalübertragung kann es durch verschiedene Einflüsse, wie induktive und kapazitive Einkopplung oder wechselnde Potentialdifferenzen zwischen Sender und Empfänger zu einer

Mehr

Datenübernahme easyjob 3.0 zu easyjob 4.0

Datenübernahme easyjob 3.0 zu easyjob 4.0 Datenübernahme easyjob 3.0 zu easyjob 4.0 Einführung...3 Systemanforderung easyjob 4.0...3 Vorgehensweise zur Umstellung zu easyjob 4.0...4 Installation easyjob 4.0 auf dem Server und Arbeitsstationen...4

Mehr

Some Software Engineering Principles

Some Software Engineering Principles David L. Parnas: Some Software Engineering Principles Marco Oppel 30.06.2004 Seminar Software-Architektur Institut für Informatik Humboldt Universität zu Berlin 1 Problemstellung Software Engineering Multi-Personen

Mehr

Fault-Konzepte Fehlermana Fehl gement in ermana Rechnernetzen Rechne Christian Stroh

Fault-Konzepte Fehlermana Fehl gement in ermana Rechnernetzen Rechne Christian Stroh Fault-Konzepte Fehlermanagement in Rechnernetzen Übersicht 1. Rückblick auf FCAPS (Netzwerkmanagement) und SNMP (Netzwerkprotokoll) 2. Fehlermanagement (Definition, Struktur) 3. Fehlerbehandlung -Fehlererkennung

Mehr

9 Verteilte Verklemmungserkennung

9 Verteilte Verklemmungserkennung 9 Verteilte Verklemmungserkennung 9.1 Grundlagen Für die Existenz einer Verklemmung notwendige Bedingungen Exklusive Betriebsmittelbelegung Betriebsmittel können nachgefordert werden Betriebsmittel können

Mehr

CosmosMonitoring Server von CosmosNet

CosmosMonitoring Server von CosmosNet Network Services without limitation. Cosmos Server von CosmosNet Cosmos Cosmos Server [CMS] Der Cosmos Server, erhältlich als zertifizierte Hardware Box, virtuelle Maschine oder Softwarelösung, ist eine

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

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2 Inhaltsverzeichnis 1 Einführung 2 1.1 Warum Softwaretests?.................................... 2 2 Durchgeführte Tests 2 2.1 Test: allgemeine Funktionalität............................... 2 2.1.1 Beschreibung.....................................

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

Erster Bug: eine Motte

Erster Bug: eine Motte SOFTWAREFEHLER Der erste Bug Erster Bug: eine Motte Der Begriff Bug (deutsch: Motte) stammt aus dem Jahre 1945, als Ingenieure in einem Schaltrelais eines Computers (Harvard Mark II-System) eine Motte

Mehr

Folge 19 - Bäume. 19.1 Binärbäume - Allgemeines. Grundlagen: Ulrich Helmich: Informatik 2 mit BlueJ - Ein Kurs für die Stufe 12

Folge 19 - Bäume. 19.1 Binärbäume - Allgemeines. Grundlagen: Ulrich Helmich: Informatik 2 mit BlueJ - Ein Kurs für die Stufe 12 Grundlagen: Folge 19 - Bäume 19.1 Binärbäume - Allgemeines Unter Bäumen versteht man in der Informatik Datenstrukturen, bei denen jedes Element mindestens zwei Nachfolger hat. Bereits in der Folge 17 haben

Mehr

6 Systematisches Testen von Programmen

6 Systematisches Testen von Programmen 6 Systematisches Testen von Programmen Testen Untersuchung des Source-Codes nach Fehlern und Anomalien Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 6 p.1/24 Untersuchung des Source-Codes

Mehr

Die Einführung kann auch Nachteile mit sich ziehen:

Die Einführung kann auch Nachteile mit sich ziehen: 6. Maximize Human Participation Die Vorgehensweise MAXIMIZE HUMAN PARTICIPATION ist genau das Gegenteil von MINIMIZE HUMAN INTERVENTATION und beschreibt das Vorgehen wie man erfahrene Benutzer ins System

Mehr

Verträge für die funktionale Programmierung Design und Implementierung

Verträge für die funktionale Programmierung Design und Implementierung 1 Verträge für die funktionale Programmierung Design und Implementierung RALF HINZE Institut für Informatik III, Universität Bonn Römerstraße 164, 53117 Bonn, Germany Email: ralf@informatik.uni-bonn.de

Mehr

Hochverfügbarkeit von TransConnect 2.2

Hochverfügbarkeit von TransConnect 2.2 Hochverfügbarkeit von TransConnect 2.2 und Ausblick Torsten Uhr - SQL Projekt AG Stand September 2012 Inhalt Teil 1 Backup & Restore Virtualisierung Hot-Standby / Fail-Over Teil 2 Ausblick auf zukünftige

Mehr

Manuelles Testen großer industrieller Systeme Dr. Uwe Doetzkies Informatik für die Industrie Berlin

Manuelles Testen großer industrieller Systeme Dr. Uwe Doetzkies Informatik für die Industrie Berlin Manuelles Testen großer industrieller Systeme Dr. Uwe Doetzkies Informatik für die Industrie Berlin In Kürze Nichtfunktionale Anforderungen an große Softwaresysteme lassen sich in der Regel noch nicht

Mehr

Software Engineering I Prof. Dr. Martin Glinz. Fallstudie: Ariane Flug 501. Universität Zürich Institut für Informatik

Software Engineering I Prof. Dr. Martin Glinz. Fallstudie: Ariane Flug 501. Universität Zürich Institut für Informatik Software Engineering I Prof. Dr. Martin Glinz Fallstudie: Ariane Flug 501 Universität Zürich Institut für Informatik Was geschah mit Flug 501? So hätte es aussehen sollen......und so sah es tatsächlich

Mehr

Wie lese ich mein Zertifikat in dakota.le 6.0 ein?

Wie lese ich mein Zertifikat in dakota.le 6.0 ein? Wie lese ich mein Zertifikat in dakota.le 6.0 ein? Seite 1 von 15 Inhaltsverzeichnis 1 Allgemeines zum Zertifikat 3 1.1 Sie haben verschiedene Möglichkeiten Ihr Zertifikat einzulesen 3 1.2 Gründe, warum

Mehr

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim Test- Grundsätzliches - - - Ablauf von Tests Grundsätzliche Test- -Tests Äquivalenzklassenbildung Randwertanalyse -Tests Man unterscheidet verschiedene Überdeckungsgrade: Statement Coverage Decision Coverage,

Mehr

Vorschriften und Probleme... Das Problem der Wüstenposten. - Reisende dürfen die Wüste nur "kontrolliert" (bei einem "wachen" Posten) betreten

Vorschriften und Probleme... Das Problem der Wüstenposten. - Reisende dürfen die Wüste nur kontrolliert (bei einem wachen Posten) betreten Das Problem der Wüstenposten Vorschriften und Probleme... - Reisende dürfen die Wüste nur "kontrolliert" (bei einem "wachen" Posten) betreten - Nur ein wacher Posten lässt Personen in die Wüste einreisen

Mehr

Unterrichtseinheit 13

Unterrichtseinheit 13 Unterrichtseinheit 13 Konfigurieren einer unterbrechungsfreien Stromversorgung Die Konfiguration erfolgt unter : Start Einstellungen Systemsteuerung Energieoptionen USV Implementieren von Fehlertoleranz

Mehr

Session Storage im Zend Server Cluster Manager

Session Storage im Zend Server Cluster Manager Session Storage im Zend Server Cluster Manager Jan Burkl System Engineer, Zend Technologies Agenda Einführung in Zend Server und ZSCM Überblick über PHP Sessions Zend Session Clustering Session Hochverfügbarkeit

Mehr

OSEK / COM. Inhaltsverzeichnis. Abbildungsverzeichnis. Florian Hohnsbehn. PG AutoLab Seminarwochenende 21.-23. Oktober 2007

OSEK / COM. Inhaltsverzeichnis. Abbildungsverzeichnis. Florian Hohnsbehn. PG AutoLab Seminarwochenende 21.-23. Oktober 2007 OSEK / COM Florian Hohnsbehn PG AutoLab Seminarwochenende 21.-23. Oktober 2007 Inhaltsverzeichnis Abbildungsverzeichnis 1 1 Einführung 1.1 Was ist OSEK COM? OSEK COM ist eine vom OSEK-VDX-Konsortium entwickelte

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

Reaktive Systeme und synchrones Paradigma

Reaktive Systeme und synchrones Paradigma Sascha Kretzschmann Freie Universität Berlin Reaktive Systeme und synchrones Paradigma Einführung in das Seminar über synchrone Programmiersprachen Worum geht es? INHALT 2 Inhalt 1. Einleitung - Wo befinden

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

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

Klausur zur Vorlesung Verteilte Systeme im SS 2007 Prof. Dr. Odej Kao 24. Juli 2007

Klausur zur Vorlesung Verteilte Systeme im SS 2007 Prof. Dr. Odej Kao 24. Juli 2007 Klausur zur Vorlesung Verteilte Systeme im SS 2007 Prof. Dr. Odej Kao 24. Juli 2007 Name: Vorname: Matrikelnummer: Studiengang: E-Mail: Schreiben Sie zunächst sofort Ihren Namen und Matrikelnummer auf

Mehr

Projektmanagement. Vorlesung von Thomas Patzelt 9. Vorlesung

Projektmanagement. Vorlesung von Thomas Patzelt 9. Vorlesung Projektmanagement Vorlesung von Thomas Patzelt 9. Vorlesung 1 Pläne Kein Plan überlebt die erste Feindberührung - Feldmarschall Helmuth von Moltke Prognosen sind schwierig, besonders wenn sie die Zukunft

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

Kap. 2: Fail-Stop Unterschriften

Kap. 2: Fail-Stop Unterschriften Stefan Lucks 2: Fail-Stop Unterschriften 17 Digital Unterschreiben und Bezahlen Kap. 2: Fail-Stop Unterschriften Digitale Unterschriften (Synomym: Digitale Signaturen ): Fälschen mutmaßlich hart (RSA-Wurzeln,

Mehr

Datensicherheit und Hochverfügbarkeit

Datensicherheit und Hochverfügbarkeit Datensicherheit und Hochverfügbarkeit 1. Instanzfehler Aussage: Instanzfehler werden durch Crash Recovery vom DBS automatisch behandelt. Recovery Zeiten? Ausfall von Speichersubsystem, Rechner,...? Ausfall

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

Automotive Software Engineering

Automotive Software Engineering Jorg Schauffele Thomas Zurawka Automotive Software Engineering Grundlagen, Prozesse, Methoden und Werkzeuge Mit 278 Abbildungen ATZ-MTZ-Fachbuch vieweg Inhaltsverzeichnis 1 Einfiihrung und Uberblick 1

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

Spezifikation der zulässigen Parameter. Bemerkungen: Bemerkungen: (2) Design by Contract:

Spezifikation der zulässigen Parameter. Bemerkungen: Bemerkungen: (2) Design by Contract: Spezifikation der zulässigen Parameter Bemerkungen: Bei jeder (partiellen) Funktion muss man sich überlegen und dokumentieren, welche aktuellen Parameter bei einer Anwendung zulässig sein sollen. Der Anwender

Mehr

Whitebox-Tests: Allgemeines

Whitebox-Tests: Allgemeines -Tests: Allgemeines Andere Bezeichnungen Logic driven, Strukturelles Der Tester entwickelt Testfälle aus einer Betrachtung der Ablauflogik des Programms unter Berücksichtigung der Spezifikation Intuitiv

Mehr

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Ottostr. 15 96047 Bamberg Tel. +49/951/98046200 Fax +49/951/98046150 email: info@softcondev.de www: softcondev.de INHALT Vorwort Diese

Mehr

Entwicklung eines COW auf Basis einer SGE

Entwicklung eines COW auf Basis einer SGE Entwicklung eines COW auf Basis einer SGE B. Sc. Michael Schmidt HTWK Leipzig 14. Juni 2011 Inhalt 1 Einführung 2 Masterarbeit 3 Schluss Überblick 1 Einführung 2 Masterarbeit 3 Schluss Definition Cluster

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

Business Process Execution Language. Christian Vollmer Oliver Garbe

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu> Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?

Mehr

Software Requirements Specification

Software Requirements Specification Software Requirements Specification Identifikation von Sehenswürdigkeiten basierend auf Bildinhalten Iterationsschritt: 3 Abgabedatum: 08.06.2010 Gruppe 37: Matthias Hochsteger 0627568 Josef Kemetmüller

Mehr

NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND

NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND init.at informationstechnologie GmbH - Tannhäuserplatz 2 - A-1150 Wien - www.init.at Dieses Dokument und alle Teile von ihm bilden ein geistiges Eigentum

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

4 LCN VCN 0 1 2 3 4 5 6 7 LCN 107 108 109 110 131 132 133 134. Extents werden außerhalb der MFT gespeichert

4 LCN VCN 0 1 2 3 4 5 6 7 LCN 107 108 109 110 131 132 133 134. Extents werden außerhalb der MFT gespeichert 3 Master File Table Eintrag für eine kurze Datei Standardinfo Dateiname Zugriffsrechte Daten leer Vorspann Eintrag für eine längere Datei Virtual Cluster Number (VCN) 0 LCN 107 131 VCN 0 1 2 3 5 6 7 LCN

Mehr

Reaktive Programmierung Vorlesung 16 vom 14.07.2015: Theorie der Nebenläufigkeit

Reaktive Programmierung Vorlesung 16 vom 14.07.2015: Theorie der Nebenläufigkeit 18:13:55 2015-07-14 1 [16] Reaktive Programmierung Vorlesung 16 vom 14.07.2015: Theorie der Nebenläufigkeit Christoph Lüth & Martin Ring Universität Bremen Sommersemester 2015 2 [16] Organisatorisches

Mehr

Egon Börger (Pisa) S-BPM. Über den praktischen Gewinn. einer wissenschaftlichen Fundierung

Egon Börger (Pisa) S-BPM. Über den praktischen Gewinn. einer wissenschaftlichen Fundierung Egon Börger (Pisa) S-BPM Über den praktischen Gewinn einer wissenschaftlichen Fundierung Dipartimento di Informatica, Università di Pisa, Pisa (Italia) boerger@di.unipi.it Copyright c Egon Börger, Dipartimento

Mehr

(früher: Double-Take Backup)

(früher: Double-Take Backup) (früher: Double-Take Backup) Eine minutengenaue Kopie aller Daten am Standort: Damit ein schlimmer Tag nicht noch schlimmer wird Double-Take RecoverNow für Windows (früher: Double-Take Backup) sichert

Mehr

4. Optional: zusätzliche externe Speicherung der Daten in unserem Rechenzentrum

4. Optional: zusätzliche externe Speicherung der Daten in unserem Rechenzentrum KMU Backup Ausgangslage Eine KMU taugliche Backup-Lösung sollte kostengünstig sein und so automatisiert wie möglich ablaufen. Dennoch muss es alle Anforderungen die an ein modernes Backup-System gestellt

Mehr

Rhapsody in J Modellierung von Echtzeitsystemen

Rhapsody in J Modellierung von Echtzeitsystemen Rhapsody in J Modellierung von Echtzeitsystemen Tobias Schumacher tobe@uni-paderborn.de Rhapsody in J - Modellierung von Echtzeitsystemen p.1/17 Anspruch des Tools Einsatzbereiche/Features Modellierung

Mehr

Prinzipien Objektorientierter Programmierung

Prinzipien Objektorientierter Programmierung Prinzipien Objektorientierter Programmierung Valerian Wintner Inhaltsverzeichnis 1 Vorwort 1 2 Kapselung 1 3 Polymorphie 2 3.1 Dynamische Polymorphie...................... 2 3.2 Statische Polymorphie........................

Mehr

Lokales Storage Teil 1

Lokales Storage Teil 1 Lokales Storage Teil 1 Linux-Kurs der Unix-AG Zinching Dang 08. Juli 2015 Lokales Storage im Allgemeinen Datenträger, die direkt am Host angeschlossen sind Anbindung über verschiedene Bus-Systeme möglich,

Mehr

Band M, Kapitel 7: IT-Dienste

Band M, Kapitel 7: IT-Dienste 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

Einführung in das Robot Operating System (ROS)

Einführung in das Robot Operating System (ROS) Einführung in das Robot Operating System (ROS) Raum: BC414, Tel.: 0203-379 - 3583, E-Mail: michael.korn@uni-due.de Motivation Ziele des Vortrags Robot Operating System (ROS) Nachteile von ERSP und Windows

Mehr

PIWIN 1 Übung Blatt 5

PIWIN 1 Übung Blatt 5 Fakultät für Informatik Wintersemester 2008 André Gronemeier, LS 2, OH 14 Raum 307, andre.gronemeier@cs.uni-dortmund.de PIWIN 1 Übung Blatt 5 Ausgabedatum: 19.12.2008 Übungen: 12.1.2009-22.1.2009 Abgabe:

Mehr

Server-Eye. Stand 30.07.2013 WWW.REDDOXX.COM

Server-Eye. Stand 30.07.2013 WWW.REDDOXX.COM Server-Eye Stand 30.07.2013 Copyright 2012 by REDDOXX GmbH REDDOXX GmbH Neue Weilheimer Str. 14 D-73230 Kirchheim Fon: +49 (0)7021 92846-0 Fax: +49 (0)7021 92846-99 E-Mail: info@reddoxx.com Internet: http://www.reddoxx.com

Mehr

Verteilte Systeme Prof. Dr. Stefan Fischer. Überblick. Sinn der Replikation. TU Braunschweig Institut für Betriebssysteme und Rechnerverbund

Verteilte Systeme Prof. Dr. Stefan Fischer. Überblick. Sinn der Replikation. TU Braunschweig Institut für Betriebssysteme und Rechnerverbund TU Braunschweig Institut für Betriebssysteme und Rechnerverbund Kapitel 11: Konsistenz, Replikation und Fehlertoleranz Überblick Motivation: warum Replikation? warum ein Konsistenzproblem? Konsistenzmodelle

Mehr

Hochverfügbarkeit eines Server-Systems Dr. Stephan Pettinger 7-it 1 Hochverfügbarkeit Theorie Definition Hochverfügbarkeit Kopplung von Systemen Single Point of Failure Hochverfügbarkeitscluster Linux-HA-Architektur

Mehr

PROLAG WORLD 2.0 PRODUKTBESCHREIBUNG SERVERSYSTEM, CLUSTERSYSTEME FÜR PROLAG WORLD

PROLAG WORLD 2.0 PRODUKTBESCHREIBUNG SERVERSYSTEM, CLUSTERSYSTEME FÜR PROLAG WORLD PROLAG WORLD 2.0 PRODUKTBESCHREIBUNG SERVERSYSTEM, CLUSTERSYSTEME FÜR PROLAG WORLD Inhaltsverzeichnis 1. ZUSAMMENSTELLUNG VON SERVERN...3 1.1. ANFORDERUNGSPROFIL...3 1.2. 1.3. SERVER MODELLE...3 TECHNISCHE

Mehr

opensuse 13.2 / SUSE Linux Enterprise 12 Klaus Schmidt Systembetreuer 1. Ausgabe, April 2015 ISBN: 978-3-86249-420-0 LI13XS

opensuse 13.2 / SUSE Linux Enterprise 12 Klaus Schmidt Systembetreuer 1. Ausgabe, April 2015 ISBN: 978-3-86249-420-0 LI13XS Klaus Schmidt 1. Ausgabe, April 2015 opensuse 13.2 / SUSE Linux Enterprise 12 Systembetreuer ISBN: 978-3-86249-420-0 LI13XS 6 opensuse 13.2 / SUSE Linux Enterprise 12 - Systembetreuer 6 YaST bedienen In

Mehr

OSL UVE auf der Bühne

OSL UVE auf der Bühne Live-Demonstration zum OSL Unified Virtualisation Environment OSL UVE auf der Bühne OSL Aktuell 2014 Schöneiche, 14. Mai 2014 Die Vorführkonfiguration Zwei Unified Virtualisation Server Interner, über

Mehr

Vgl. Oestereich Kap 2.6 Seiten 127-133

Vgl. Oestereich Kap 2.6 Seiten 127-133 Vgl. Oestereich Kap 2.6 Seiten 127-133 4. Zustände 1 Aktivitäts- und Zustands-Diagramm werden oft verwechselt. Es ist darum wichtig zu unterscheiden, dass im Aktivitätsdiagramm die Aktionen im Zentrum

Mehr

Softwarequalitätssicherung

Softwarequalitätssicherung Softwarequalitätssicherung Dipl. Inf. Andrea Meyer Medieninformatik (Bachelor), Wahlpflichtmodul: Softwareprojekt II, Dipl. Inf. Andrea Meyer Warum Softwarequalitätssicherung? 2 Fatale Softwarefehler Ariane

Mehr

In Tabelle 2.1 sehen Sie das Ergebnis beider Ausführungen auf meiner Maschine.

In Tabelle 2.1 sehen Sie das Ergebnis beider Ausführungen auf meiner Maschine. Kapitel 2 Datenverwaltung durch SQL Server Wir wollen das obige Skript zwei Mal laufen lassen, einmal mit und einmal ohne eingeschalteten Schreibcache der Festplatte. Für eine lokale Festplatte können

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

Prozesseinheit. Beschaffung

Prozesseinheit. Beschaffung Prozesseinheit Beschaffung Ascom Network Testing AG Einkauf/Lager 12. März 1. April 2010 Lernender.ch Inhaltsverzeichnis Kurzbericht... - 3 - Bedarf... Fehler! Textmarke nicht definiert. Offerte notwendig?...

Mehr

Überblick über Oracle Technologie im Bereich Hochverfügbarkeit. Tage der Datenbanken FH Köln Campus Gummersbach 20. Juni 2013 Dierk Lenz

Überblick über Oracle Technologie im Bereich Hochverfügbarkeit. Tage der Datenbanken FH Köln Campus Gummersbach 20. Juni 2013 Dierk Lenz Überblick über Oracle Technologie im Bereich Hochverfügbarkeit Tage der Datenbanken FH Köln Campus Gummersbach 20. Juni 2013 Dierk Lenz Herrmann & Lenz Services GmbH Erfolgreich seit 1996 am Markt Firmensitz:

Mehr

Virtualisierung in der Automatisierungstechnik

Virtualisierung in der Automatisierungstechnik Virtualisierung in der Automatisierungstechnik Ihr Referent Jürgen Flütter on/off engineering gmbh Niels-Bohr-Str. 6 31515 Wunstorf Tel.: 05031 9686-70 E-Mail: juergen.fluetter@onoff-group.de 2 Virtualisierung

Mehr

Verfügbarkeit von RZ-Infrastrukturen Wie viel benötigt die Mittelgroß GmbH?

Verfügbarkeit von RZ-Infrastrukturen Wie viel benötigt die Mittelgroß GmbH? 1 I P R Ä S E N T A T I O N I Verfügbarkeit von RZ-Infrastrukturen Wie viel benötigt die Mittelgroß GmbH? Dipl. Ing. (FH) Stefan ghof Geschäftsführer Wiesenweg 6 75045 Walzbachtal Tel: 07203/9133-51 Fax:

Mehr

TimeSafe Leistungserfassung

TimeSafe Leistungserfassung Keep your time safe. TimeSafe Leistungserfassung Adressimport 1/8 Inhaltsverzeichnis Inhaltsverzeichnis... 2 1 Allgemeines... 3 1.1 Adressen in der TimeSafe Leistungserfassung... 3 1.2 Organisationen und/oder

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

Uberlegungen Einsatzgebiete Virtualisierungslosungen Fazit Hardwarevirtualisierung. Virtualisierung. Christian Voshage. 11.

Uberlegungen Einsatzgebiete Virtualisierungslosungen Fazit Hardwarevirtualisierung. Virtualisierung. Christian Voshage. 11. slosungen 11. Mai 2009 Inhaltsverzeichnis Uberlegungen slosungen 1 Uberlegungen Grunduberlegungen Vorteile Hardware-Emulation Nachteile 2 Servervirtualisierung Clientvirtualisierung 3 slosungen 4 5 Uberlegungen

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

LM2. WAHRSCHEINLICHKEITSRECHNUNG/STATISTIK

LM2. WAHRSCHEINLICHKEITSRECHNUNG/STATISTIK LM2. WAHRSCHEINLICHKEITSRECHNUNG/STATISTIK III. In einer Region haben 60 % der Haushalte einen Internetanschluss. Das Diagramm veranschaulicht die Anteile der Zugangsgeschwindigkeiten unter den Haushalten

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