close

Anmelden

Neues Passwort anfordern?

Anmeldung mit OpenID

Literatur Wozu überhaupt Fehlertoleranz? Was ist ein Fehler - CS 4

EinbettenHerunterladen
1 Fault-Tolerant CORBA Grundlagen
1 Fault-Tolerant CORBA Grundlagen
Literatur
Wozu u¨berhaupt Fehlertoleranz?
Object Management Group
CORBA/IIOP Specification (Chapter 23, Fault Tolerant CORBA)
OMG Technical Committee Document formal/04-03-21, 2004.
Hardwarefehler
Softwarefehler
Pascal Felber, Priya Narasimhan
Experiences, Strategies, and Challenges in Building
Fault-Tolerant CORBA Systems
IEEE Transactions on Computers, vol. 53, no. 5, pp. 497-511, 2004
st¨andige Verf¨
ugbarkeit
Luftfahrt, Medizin, Anlagensteuerung, etc.
R. Baldoni, C. Marchetti, R. Panella, L. Verde
Handling FT-CORBA Compliant Interoperable Object Group References
WORDS ’02: Proceedings of the The Seventh IEEE International Workshop
on Object-Oriented Real-Time Dependable Systems, 2002
Kosten bei Ausfall
Ziel
Priya Narasimhan
Fault-Tolerant CORBA: From Specification to Reality
Computer , vol. 40, no. 1, pp.110-112, Jan. 2007
c R¨
udiger Kapitza
WS 09/10
MW
No single point of failure
F 1-1
c R¨
udiger Kapitza
1 Fault-Tolerant CORBA Grundlagen
WS 09/10
MW
F 1-2
1 Fault-Tolerant CORBA Grundlagen
Was ist ein Fehler?
Klassifikation von Fehlern
Fault (Fehlerusache)
Gutm¨
utige Fehler (benign faults)
Crash Stop: Ein Knoten f¨allt komplett aus
Fail Stop: Jeder korrekte Knoten erf¨ahrt innerhalb endlicher Zeit vom
Ausfall eines Knoten
Fail Silent: Keine perfekte Ausfallerkennung m¨oglich (asynchrones
oder partiell synchrones Modell)
unerw¨
unschter Zustand, der zu einem Fehler f¨
uhren kann
Error (Fehler)
Systemzustand, der nicht den Spezifikationen entspricht
Crash Recovery: Ein korrekter Knoten kann endlich oft ausfallen und
wiederanlaufen
Failure (Funktionsausfall)
Diensterbrinung ist nicht mehr m¨
oglich
B¨osartige Fehler (malicious faults)
H¨aufig als byzantinische Fehler bezeichnet
Fehlerhafte Prozesse k¨onnen beliebige Aktionen ausf¨
uhren, und dabei
auch untereinander kooperieren
Singal/Shivaratri
An error is a manifestation of a fault in a system,
which could lead to system failure.
FT-CORBA betrachtet fail stop Fehler
Viele realen Systeme gehen von ausschließlich gutm¨
utigen Fehlern
aus. Dies ist aber nicht immer realistisch!
c R¨
udiger Kapitza
WS 09/10
MW
F 1-3
c R¨
udiger Kapitza
WS 09/10
MW
F 1-4
1 Fault-Tolerant CORBA Grundlagen
1 Fault-Tolerant CORBA Grundlagen
Fehlertoleranz durch Replikation
CORBA und FT-CORBA
CORBA
CORBA spezifiziert keine Mechanismen f¨
ur Redundanz
Redundanz
Zuverl¨assige Verbindungen basierend auf TCP/IP erm¨oglichen
beschr¨ankte Erkennung von Ausf¨allen
erzeugen und verwalten von Kopien/Replikaten eines Objektes
Erkennen von Fehlern
Ziele von FT-CORBA
erkennen das ein Prozeß oder Objekt ausgefallen ist
Minimale Modifikation von Applikationen (sowohl auf Client- wie
auch auf Serverseite)
Recovery
Unterst¨
utzung f¨
ur Fehlertoleranz
ausgefallene Instanz ersetzen
verschiedene Fehlertoleranzanforderungen
verschiedene Applikationen
verschiedene Mechanismen zur Fehlererkennung und -behandlung
c R¨
udiger Kapitza
WS 09/10
MW
F 1-5
c R¨
udiger Kapitza
1 Fault-Tolerant CORBA Grundlagen
WS 09/10
MW
F 1-6
1 Fault-Tolerant CORBA Grundlagen
Was muss eine Fehlertoleranzinfrastruktur leisten?
Grundlagen
Replikation von Objekten
Erkennung von Ausf¨allen
Logging von Anfragen und Zustandssicherung von Objektzust¨anden
Zustandstransfer zur Initialisierung und Reinitialisierung von Objekten
Redundanz
Objekte bilden die Einheit der Replikation
Starke Konsistenz
Transparente Verschattung von Ausf¨allen
Alle Replikate haben den gleichen Zustand
Erm¨oglicht einfache Anwendungsentwicklung
Client interagiert mit Objekten
Stellt hohe Anforderungen an die Mechanismen der Infrastruktur
Alle Mechanismen zur Fehlertoleranz werden durch die Middleware
bereitgestellt
c R¨
udiger Kapitza
WS 09/10
MW
F 1-7
c R¨
udiger Kapitza
WS 09/10
MW
F 1-8
1 Fault-Tolerant CORBA Grundlagen
1 Fault-Tolerant CORBA Grundlagen
Grundlagen
Grundlagen
Objektgruppe
Zustand
Zustand bildet die Menge an Informationen die zur Erhaltung von
konsistenten Replikaten n¨otig ist
Menge aller Replikate eines Objektes bilden eine Objektgruppe
Jede Gruppe verf¨
ugt u
¨ber eine Object Group Reference (IOR)
Zielsetzung
Zustand ergibt sich durch das replizierte Objekt und die Infrastruktur
(POA und ORB)
Replikationstransparenz
Fehlertransparenz
Identit¨at
CORBA-Objekte werden durch ihren Ausf¨
uhrungsort identifiziert
Server
Zustand
schwache Form von Identit¨at
Sevant
FT-CORBA ben¨
otigt eindeutige und ortsunabh¨angige Identifikation
POA
Objektgruppen werden durch FTDomainId und ObjectGroupId
identifiziert
einzelne Replikate durch FTDomainId, ObjectGroupId und Ort
c R¨
udiger Kapitza
WS 09/10
MW
ORB Core
F 1-9
c R¨
udiger Kapitza
1 Fault-Tolerant CORBA Grundlagen
WS 09/10
Grundlagen
Determinismus
Replikationsart
Active Replication
F 1 - 10
Replikate bearbeiten alle Anforderungen
Replikation von Objekten erfordert deterministisches Verhalten
Passive Replication
Aufrufe werden an alle Replikate in gleicher Reihenfolge zugestellt
Ausgehend von identischen Ausgangszust¨anden werden identische
Endzust¨ande erreicht
Objekt entspricht somit einem Zustandsautomat
Es gibt ein aktives Replikat (master ) welches Aufrufe bearbeitet
Alle anderen Replikate sind in Wartestellung
Anwendungen besitzen unterschiedliche Fehlertoleranzanforderungen
Active Replication
Problemf¨alle
objektexterne Informationen
z.B. Zeit, Zufallszahlen oder Aufruf an externen Informationsquellen
Koordinierung wenn parallel mehrere Threads ein Objekt ver¨andern
Sehr kurze Verz¨ogerungen im Fehlerfall
Hoher Aufwand unter anderem durch die erforderliche
Gruppenkommunikation
Passive Replication
z.B. Anforderung von Locks
WS 09/10
MW
1 Fault-Tolerant CORBA Grundlagen
Grundlagen
c R¨
udiger Kapitza
Skeleton
L¨angere Verz¨ogerung bei Ausf¨allen
Geringer Aufwand zur Laufzeit
Schnellere Antwortzeit im Normalbetrieb
MW
F 1 - 11
c R¨
udiger Kapitza
WS 09/10
MW
F 1 - 12
1 Fault-Tolerant CORBA Grundlagen
1 Fault-Tolerant CORBA Grundlagen
Grundlagen
Grundlagen
Zust¨andigkeiten Serverseite
Zust¨andigkeiten Clientseite
Failover
Objektreplikation
Falls ein Server nicht antwortet wird es entweder erneut versucht oder
ein anderer Server wird kontaktiert
Aufrufe werden nur einmal durch das replizierte Objekt ausgef¨
uhrt
(muss durch die Serverseite unterst¨
utzt werden)
Verwaltung der System- und Fehlertoleranzanforderungen pro
Objektgruppe
Property Manager-Schnittstelle
Adressierung
Erzeugen von replizierten Objekten
Veraltete Referenzen werden in Kooperation mit dem Server ersetzt
Generic Factory-Schnittstelle
Replication Manager-Schnittstelle
Zustandstransfer
Server liefert aktuelle Version
Ausfall der Verbindung
z. B. kein Replikat ist erreichbar
Anwendung wird benachrichtig
Erkennung von Ausf¨allen
c R¨
udiger Kapitza
WS 09/10
MW
F 1 - 13
c R¨
udiger Kapitza
1 Fault-Tolerant CORBA Grundlagen
WS 09/10
Grundlagen
Kontrolle und Verwaltung
Infrastruktur kontrolliert Fehlertoleranz
Fault Tolerance Domain
Automatische Erzeugung von Replikaten
Automatische Erhaltung der Konsistenz
Menge von Rechnern zur Bereitstellung von fehlertoleranten
Applikationen
Applikation kontrolliert Fehlertoleranz
Zentrale Komponente bildet der Replication Manager
Applikation lenkt die Erzeugung und Platzierung von Replikaten
Applikation gew¨ahrleistet die Konsistenz
Achtung: Nur in Spezialf¨allen n¨otig!
WS 09/10
F 1 - 14
1 Fault-Tolerant CORBA Grundlagen
Grundlagen
c R¨
udiger Kapitza
MW
MW
steuert Erzeugung und Platzierung von Replikaten
F 1 - 15
c R¨
udiger Kapitza
WS 09/10
MW
F 1 - 16
1 Fault-Tolerant CORBA Grundlagen
2 Mechanismen
Limitationen des FT-CORBA Standards
Architektur¨ubersicht
Determinismus bleibt Aufgabe des Anwendungsentwicklers
Keine explizite Unterst¨
utzung f¨
ur
Behandlung von Netzwerkpartitionierungen
b¨
osartige Fehler
Softwarefehler und Designfehler
Interoperabilit¨at
Alle Replikate eines replizierten Objektes m¨
ussen die gleiche
Infrastruktur n¨
utzen
Es ist Aufgabe der Hersteller hier individuelle L¨osungen anzubieten!
c R¨
udiger Kapitza
WS 09/10
MW
F 1 - 17
c R¨
udiger Kapitza
WS 09/10
2 Mechanismen
MW
F 2-1
2 Mechanismen
Adressierung
Adressierung
Interoperable Object Group Reference (IOGR)
Interoperable Object Group Reference (IOGR)
Eine IGOR besitzt mehrere IOR Profile
Jedes Profil enth¨alt Informationen zur Identit¨at des Objektes
Type Id Num. of Profiles
FTDomainId identifiziert die Dom¨ane
ObjectGroupId identifiziert das replizierte Objekt
(innerhalb der Dom¨ane)
ObjectGroupRefVersion legt die Version der Referenz fest
TAG_
INTERNET_IOP
IIOP Profile
IIOP Profile IIOP Profile
Multiple
Component Profile
Body
IIPO Version Host Port Obj. Key Components
Maximal ein Profil enth¨alt die Komponente TAG PRIMARY zur
Identifikation des prim¨aren Replikats.
Achtung, muss nicht aktuell sein!
Num. of
Components
Was wird adressiert?
tag_
group_version
direkte Addresssieung der Replikate
TAG_GROUP
Component
ft_domain_id
TAG_PRIMARY
Component
object_
group_id
Other Comp.
object_group_
version
Addessierung von Gateways
c R¨
udiger Kapitza
WS 09/10
MW
F 2-2
c R¨
udiger Kapitza
WS 09/10
MW
F 2-3
2 Mechanismen
2 Mechanismen
Adressierung
Adressierung
Aktualit¨at von IOGRs
Problem
Aktualit¨at von IOGRs
L¨osung (Fortsetzung)
Objektreferenzen k¨onnen veralten, da sich die referenzierte
Objektgruppe ver¨andert
Server entnimmt Anfragen die Versionsinformation
einzelne Replikate fallen aus, es kommen neue Replikate hinzu
Ist die Version des Clients aktuell wird die Anfrage verarbeitet
Ist die Version des Clients veraltet wird eine LOCATE FORWARD PERM
Exception erzeugt
L¨osung
Version der Client-Referenz wird bei Anfragen an den Server
u
¨bertragen
Ist die Version des Servers (anscheinend) veraltet wird der
Replication Manager nach der aktuellen Referenz gefragt
Versionsinformation aus der Referenz wird als
GROUP VERSION Service Context der Anfrage beigef¨
ugt
c R¨
udiger Kapitza
WS 09/10
MW
F 2-4
c R¨
udiger Kapitza
WS 09/10
2 Mechanismen
MW
F 2-5
2 Mechanismen
Verhalten bei Ausf¨allen
Verhalten bei Ausf¨allen
Wiederholung von Aufrufen bei Ausf¨allen von Replikaten
Problem
Auf ORB-Transportebene gibt es eine der folgenden Exceptions
Es kommt zu einem Serverausfall oder Verbindungsproblem w¨ahrend
eines Aufrufs
Die TCP/IP Verbindung wird nicht ordnungsgem¨aß beendet und der
Client bekommt den Abbruch deshalb nicht mit
COMM FAILURE, TRANSIENT, NO RESPONSE, OBJ ADAPTER
Status ist COMPLETED MAYBE
Problem
Ohne weitere Maßnahmen kann eine Verletzung der at-most-once
Semantik vorliegen
L¨osung
Periodische Testaufrufe (heartbeat messages)
Client fragt diese via Policy pro Verbindung an und spezifiziert
L¨osung
Eindeutige Identifizierung von Anfragen durch REQUEST Service
Context
Aufruffrequenz
Timeout
Client Id, identifiziert den Client
Retention Id, identifiziert den Aufruf
Expiration Time, legt fest wie lange Aufrufergebnisse aufbewahrt
werden
Client-ORB ruft FT HB() beim Server-ORB auf
Operation wird vom Skeleton bereitgestellt
Server-ORB muss dies explizit erlauben
Server ORB erkennt so die Wiederholungen von Anfragen und sendet
das bereits ermittelte Ergebnis
c R¨
udiger Kapitza
WS 09/10
MW
F 2-6
Kontrolle von erzeugtem Netzwerkverkehr
c R¨
udiger Kapitza
WS 09/10
MW
F 2-7
3 Einstellung von Fehlertoleranzeigenschaften
3 Einstellung von Fehlertoleranzeigenschaften
Einstellung von Fehlertoleranzeigenschaften
Replikation
Stateless
statische Daten und nur lesender Zugriff
Konfigurierbare Eigenschaften
Cold Passive Replication
Replikation
Recovery wird durch Sicherungspunkt und Protokollierung von
Aufrufen erreicht
⇒ langsame Kompensation von Ausf¨allen
Mitgliedschaft
Konsistenz
Monitoring
Warm Passive Replication
Intervall und Timeout
Aktueller Zustand des prim¨aren Replikats wird periodisch an alle
anderen Replikate u
¨bertragen
Protokollierung von Aufrufen
⇒ schnelleres Recovery im Vergleich zu cold passive
Konfiguration von Factories
Replikatanzahl
initiale Anzahl beim Start eines Dienstes
minimale Anzahl
Sicherungspunktintervall
Active Replication
alle Replikate bearbeiten Aufrufe
⇒ sehr geringe Verz¨ogerung bei Ausf¨allen
c R¨
udiger Kapitza
WS 09/10
MW
F 3-1
3 Einstellung von Fehlertoleranzeigenschaften
c R¨
udiger Kapitza
WS 09/10
MW
F 3-2
3 Einstellung von Fehlertoleranzeigenschaften
Active Replication
Active Replication
Unterdr¨
uckung von duplizierten Ergebnissen
Normalbetrieb
repliziertes Objekt
Wenn replizierte Objekte von anderen replizierten Objekten aufgerufen
werden m¨
ussen duplizierte Aufrufe und Antworten unterdr¨
uckt werden
Behandlung von Ausf¨allen
Infrastruktur verschattet Ausf¨alle transparent da mindestens ein
Replikat auf Anfragen antwortet
Client
Servant
Servant
ORB
ORB
ORB
Behandlung von Beitritten
Zustandstransfer zur Integration eines neuen oder tempor¨ar
ausgefallenen Replikats n¨
otig
c R¨
udiger Kapitza
WS 09/10
MW
Antwort wird
unterdrückt!
F 3-3
c R¨
udiger Kapitza
WS 09/10
MW
F 3-4
3 Einstellung von Fehlertoleranzeigenschaften
3 Einstellung von Fehlertoleranzeigenschaften
Active Replication
Passive Replication
Normalbetrieb
Unterdr¨
uckung von duplizierten Aufrufen
periodischer Zustandstransfer zu allen Replikaten (nur bei warm
passive n¨otig)
N¨otig wenn ein repliziertes Objekt andere Objekte aufruft
repliziertes Objekt
Logging von Aufrufen und Sicherungspunkten
Behandlung von Ausf¨allen
Servant
Servant
Servant
ORB
ORB
ORB
Ausfall des prim¨aren Replikats erfordern die Wahl eines neuen
Replikats
Initialisierung des neuen prim¨aren Replikats (Zustandstransfer bei cold
passive Replication)
Erkennung von dublizieren Anfragen
Anfrage wird
unterdrückt!
c R¨
udiger Kapitza
WS 09/10
Behandlung von Beitritten
Zustandstransfer zu neuem oder wiederhergestelltem Replikat bei
warm passive Replication
MW
F 3-5
3 Einstellung von Fehlertoleranzeigenschaften
c R¨
udiger Kapitza
WS 09/10
MW
F 3-6
3 Einstellung von Fehlertoleranzeigenschaften
Passive Replication
Vergleich der Replikationsformen
Unterdr¨
uckung von Anfragen und Zustandstransfer
Passive Replication
repliziertes Objekt
Geringerer Ressourcenbedarf (z.B. Speicher und CPU)
Langsame Erholung von Ausf¨allen
Client
Primäres
Replikat
Servant
Servant
ORB
ORB
ORB
ORB
Active Replication
Hoher Ressourcenbedarf
Ausf¨
uhrung von Anfragen durch alle Replikaten
Schnelle Kompensation von Ausf¨allen
Zustandstransfer
c R¨
udiger Kapitza
WS 09/10
MW
Beide Ans¨atze erfordern die gleichen Mechanismen!
F 3-7
c R¨
udiger Kapitza
WS 09/10
MW
F 3-8
3 Einstellung von Fehlertoleranzeigenschaften
3 Einstellung von Fehlertoleranzeigenschaften
Mitgliedschaft
Mitgliedschaft
Infrastruktur kontrolliert Replikaterzeugung
Anwendung ruft create object()-Methode des Replication Managers auf
Replication
Replication
Replication
Manager
Manager
Manager
Infrastruktur kontrolliert Replikaterzeugung
Infrastruktur erzeugt Replikate und platziert diese im Kontext der
Dom¨ane
IOGR:<Profile,Profile>
Anwendung kontrolliert Replikaterzeugung
Anwendung erzeugt und platziert Replikate entsprechend ihrer
Erfordernisse
Application
create_object()
Servant
Servant
Skeleton
Skeleton
Fault
Detector
Factory
CORBA
Recovery
Mechanism
Fault
Detector
Factory
ORB
CORBA
Logging
Mechanism
ORB
Recovery
Mechanism
Logging
Mechanism
create_object()
c R¨
udiger Kapitza
WS 09/10
MW
F 3-9
3 Einstellung von Fehlertoleranzeigenschaften
c R¨
udiger Kapitza
WS 09/10
MW
3 Einstellung von Fehlertoleranzeigenschaften
Mitgliedschaft
Mitgliedschaft
Anwendung kontrolliert Replikaterzeugung
Anwendung kontrolliert Replikaterzeugung
Anwendung beauftragt den Replication Manager zur Erzeugung einzelner
Replikate
Replication
Replication
Replication
Manager
Manager
Manager
Anwendung erzeugt Replikate eigenst¨andig und nutzt den Replication
Manager zur Verwaltung
Replication
Replication
Replication
Manager
Manager
Manager
IOGR:<Profile,Profile>
create_member()
Application
IOGR:<Profile,Profile>
add_member()
Application
Servant
Servant
Servant
Servant
Skeleton
Skeleton
Skeleton
Skeleton
Fault
Detector
Factory
CORBA
Recovery
Mechanism
ORB
Logging
Mechanism
Factory
CORBA
Recovery
Mechanism
Fault
Detector
Factory
ORB
Fault
Detector
CORBA
Logging
Mechanism
Recovery
Mechanism
ORB
WS 09/10
Factory
CORBA
Logging
Mechanism
Recovery
Mechanism
Fault
Detector
ORB
Logging
Mechanism
create_object()
create_object()
c R¨
udiger Kapitza
F 3 - 10
MW
F 3 - 11
c R¨
udiger Kapitza
WS 09/10
MW
F 3 - 12
3 Einstellung von Fehlertoleranzeigenschaften
3 Einstellung von Fehlertoleranzeigenschaften
Konsistenz
Monitoring
Granularit¨at der Beobachtung
Infrastruktur kontrolliert Konsistenz
Infrastruktur erh¨alt die Konsistenz durch Mechanismen wie Logging,
Zustandssicherung und Recovery
Es wird jedes Mitglied einer Objektgruppe beobachtet
Ort
Aktive Replication
Nach jedem Aufruf haben alle Replikate den gleichen Zustand
Erfordert eine Gruppenkommunikation und total geordnete Zustellung
von Nachrichten
Passive Replication
Nach jedem Zustandstransfer haben alle Replikate den gleichen Zustand
Anwendung kontrolliert Konsistenz
Anwendung stellte alle Mechanismen zur Konsistenzerhaltung bereit
c R¨
udiger Kapitza
Mitglieder
WS 09/10
MW
F 3 - 13
Es wird ein Objekt als Repr¨asentant f¨
ur den Ort beobachtet
Wird das beobachtete Replikat beendet wird ein anderes Objekt
ausgew¨ahlt
F¨allt das Objekt aus wird der Rechner als ausgefallen betrachtet
Ort und Typ
Es wird ein Objekt pro Ort und Typ kontrolliert.
Wird das beobachtete Replikat beendet wird ein anderes Objekt vom
gleichen Typ ausgew¨ahlt
F¨allt das Objekt aus werden alle Objekte des Typs an diesem Ort als
ausgefallen betrachtet
c R¨
udiger Kapitza
3 Einstellung von Fehlertoleranzeigenschaften
WS 09/10
MW
F 3 - 14
4 Verwaltung von Replikaten
Factories
Verwaltung von Replikaten
Sequenz von FactoryInfo Strukturen
Aufgaben des Replication Manager
Verwaltung von Objektgruppen und ihren Eigenschaften
Erzeugung von replizierten Objekten wird durch eine Sequenz von
FactoryInfo Strukturen konfiguriert
Replikationsart
Mitgliedschaft
Konsistenz
usw.
Aufbau der FactoryInfo Struktur
Referenz auf Fabrik
Ort der Fabrik
Information zur Konfiguration der Fabrik (Criteria)
c R¨
udiger Kapitza
WS 09/10
MW
F 3 - 15
c R¨
udiger Kapitza
WS 09/10
MW
F 4-1
4 Verwaltung von Replikaten
4 Verwaltung von Replikaten
Schnittstelle des Replication Manager
Property Manager Schnittstelle
Erm¨oglicht konfigurieren von Eigenschaften
Methoden zur Benachrichtigung von Ausf¨allen
f¨
ur alle Objektgruppen
register fault notifier()
get fault notifier()
f¨
ur alle replizierten Objekte eines bestimmten Typs
f¨
ur ein bestimmtes repliziertes Objekt zum Zeitpunkt der Erzeugung
Erbt von
Property Manager – Management von Fehlertoleranzeigenschaften
Object Group Manager – Verwaltung von Objektgruppen
Generic Factory – Erzeugung von replizierten Objekten
c R¨
udiger Kapitza
WS 09/10
MW
F 4-2
f¨
ur ein bestimmtes repliziertes Objekt zu Lauftzeit
Spezifischere Definitionen haben h¨ohere Priorit¨at
c R¨
udiger Kapitza
4 Verwaltung von Replikaten
WS 09/10
MW
F 4-3
4 Verwaltung von Replikaten
Property Manager Schnittstelle
Zeitpunkt der Konfiguration
Setzen/Ermitteln der Standardwerte f¨
ur alle replizierten Objekte
set default properties()
get default properties()
remove default properties()
Setzen/Ermitteln der Werte f¨
ur alle replizierten Objekte eines Typs
set type properties()
get type properties()
remove type properties()
Setzen/Ermitteln der Werte f¨
ur ein bestimmtes repliziertes Objekt
set properties dynamically()
get properties()
c R¨
udiger Kapitza
WS 09/10
MW
F 4-4
Eigenschaften
Replikation
Mitgliedschaft
Konsistenz
Monitoring
Granularit¨at
Fabriken
Initiale Replikatanzahl
Minimale Replikatanzahl
c R¨
udiger Kapitza
Standard
X
X
X
X
X
X
X
WS 09/10
Typ
X
X
X
X
X
X
X
X
MW
Erzeugung
X
X
Dynamisch
X
X
X
X
X
X
X
F 4-5
4 Verwaltung von Replikaten
4 Verwaltung von Replikaten
Generic Factory Schnittstelle
Object Group Manager
Wird vom Replication Manager und von Fabriken implementiert zum
Erzeugen von replizierten Objekten
t y p e d e f Object O b j e c t G r o u p ;
t y p e d e f any F a c t o r y C r e a t i o n I d ;
Object c r e a t e o b j e c t (
in TypeIdtype id ,
in C r i t e r i a t h e c r i t e r i a ,
out F a c t o r y C r e a t i o n I d f a c t o r y c r e a t i o n i d )
r a i s e s ( NoFactory , O b j e c t N o t C r e a t e d , I n v a l i d C r i t e r i a ,
InvalidProperty , CannotMeetCriteria ) ;
Operationen der Object Group Manager Schnittstelle:
create member()
add member()
set primary member()
remove member()
locations of members()
get object group ref()
get object group id()
get member ref()
void d e l e t e o b j e c t (
in F a c t o r y C r e a t i o n I d f a c t o r y c r e a t i o n i d )
r a i s e s ( ObjectNotFound ) ;
c R¨
udiger Kapitza
WS 09/10
MW
F 4-6
c R¨
udiger Kapitza
4 Verwaltung von Replikaten
WS 09/10
MW
F 4-7
5 Fehlermanagement
Object Group Manager
Fehlermanagement
Wichtige Operation create member und add member
Fault Detector
ObjectGroup create member (
in ObjectGroup object group ,
i n L o c a t i o n t h e l o c a t i o n , i n T y p e Id t y p e i d ,
in C r i t e r i a t h e c r i t e r i a )
r a i s e s ( ObjectGroupNotFound , M e m b e r A l r e a d y P r e s e n t ,
NoFactory , O b j e c t N o t C r e a t e d , I n v a l i d C r i t e r i a
,...);
Erkennt Fehler und erzeugt Fehlerberichte
Fault Notifier
Sammelt und verarbeitet Fehlerberichte von Fault Detectors und
Fault Analyzers
Bildet eine Art Datenbank f¨
ur alle Fehlerberichte
Fault Analyzer
O b j e c t G r o u p add member (
in ObjectGroup object group ,
i n L o c a t i o n t h e l o c a t i o n , i n Object member )
r a i s e s ( ObjectGroupNotFound , M e m b e r A l r e a d y P r e s e n t ,
ObjectNotAdded ) ;
c R¨
udiger Kapitza
WS 09/10
MW
Spezifisch f¨
ur jede Anwendung
Verarbeitet Fehlerberichte und fasst abh¨angige Fehler zusammen
F 4-8
c R¨
udiger Kapitza
WS 09/10
MW
F 5-1
5 Fehlermanagement
5 Fehlermanagement
Fehlermanagement
Fehlermanagement
Fehlerweitergabe durch Fault Detectors
Replication Manager
einzelne Fehlerreporte (CosNotification::StructuredEvent)
Fault
StructuredPushConsumer
Sammelreport (CosNotification::EventBatch)
Fehlertyp: (ObjectCrashFault)
Analyzer
SequencePushConsumer
push_structured_event()
push_sequence_event()
Domain name - FT CORBA
Type name - ObjectCrashFault
Location - host/process
TypeId - IDL:Library:1.0
ObjectGroupId - 4711
Fault
Notifier
push_structured_fault()
push_sequence_fault()
Servant
is_alive()
PullMonitorable
c R¨
udiger Kapitza
Sind alle Objekte eines Ortes ausgefallen wird TypeId und
ObjektGroupId nicht im Fehlerreport vermerkt
Fault
Detector
WS 09/10
MW
Sind alle Objekte eines Types ausgefallen wird die ObjektGroupId
weggelassen
F 5-2
c R¨
udiger Kapitza
5 Fehlermanagement
WS 09/10
MW
F 5-3
5 Fehlermanagement
Fehlermanagement
Fehlermanagement
Fehlerverarbeitung
Schnittstelle des Fault Notifier
Fehlerberichte werden durch Fault Detectors erzeugt und via push an
den Fault Notifier weitergeleitet
void p u s h s t r u c t u r e d f a u l t (
in CosNotification : : StructuredEvent event ) ;
Beliebige Konsumenten registrieren sich beim Fault Notifier und
werden u
¨ber Fehler benachrichtigt
CosNotifyFilter :: Filter create subscription filter (
in string constraint grammer )
r a i s e s ( C o s N o t i f y F i l t e r : : InvalidGrammer ) ;
Filter reduzieren das Nachrichtenaufkommen
ConsumerId c o n n e c t s t r u c t u r e d f a u l t c o n s u m e r (
i n CosNotifyComm : : S t r u c t u r e d P u s h C o n s u m e r c o n s u m e r ,
in C o s N o t i f y F i l t e r : : F i l t e r f i l t e r ) ;
c R¨
udiger Kapitza
WS 09/10
MW
F 5-4
c R¨
udiger Kapitza
WS 09/10
MW
F 5-5
6 Recoverymanagement
6 Recoverymanagement
Logging und Recovery
Logging und Recovery
Schnittstelle zum Erzeugen Sicherungspunkten
interface Checkpointable {
State get state ()
raises ( NoStateAvailable );
void s e t s t a t e ( in State s )
raises ( InvalidState );
};
Beispiel: Active Replication
Client
Servant
Servant
Skeleton
Skeleton
Fault
Detector
Factory
CORBA
ORB
Logging
Mechanism
CORBA
Recovery
Mechanism
c R¨
udiger Kapitza
WS 09/10
ORB
Logging
Mechanism
Schnittstelle zum Erzeugen von partiellen Sicherungspunkten
Fault
Detector
Factory
CORBA
Recovery
Mechanism
ORB
interface Updateable : Checkpointable {
State get update ()
raises ( NoUpdateAvailable ) ;
void s e t u p d a t e ( in State s )
raises ( InvalidUpdate );
};
Logging
Mechanism
MW
F 6-1
c R¨
udiger Kapitza
WS 09/10
6 Recoverymanagement
MW
6 Recoverymanagement
Logging und Recovery
Logging und Recovery
Beispiel: Cold Passive Replication — Normalbetrieb
Beispiel: Cold Passive Replication — Recovery
Client
Servant
Servant
Skeleton
Skeleton
Client
Servant
Servant
Skeleton
Skeleton
get_state()
Factory
CORBA
ORB
Logging
Mechanism
c R¨
udiger Kapitza
CORBA
Recovery
Mechanism
WS 09/10
F 6-2
set_state()
Fault
Detector
ORB
Logging
Mechanism
MW
Factory
CORBA
Recovery
Mechanism
Fault
Detector
Factory
ORB
CORBA
Logging
Mechanism
ORB
Logging
Mechanism
F 6-3
c R¨
udiger Kapitza
CORBA
Recovery
Mechanism
WS 09/10
Fault
Detector
ORB
Logging
Mechanism
MW
Factory
CORBA
Recovery
Mechanism
Fault
Detector
ORB
Logging
Mechanism
F 6-4
7 Implementierung
7 Implementierung
Implementierungsvarianten
Integrativer Ansatz
ORB wird durch eine Gruppenkommunikation erg¨anzt
IIOP wird durch ein propriet¨ares Protokoll ausgetauscht
Integrativer Ansatz
Application Object
Unterst¨
utzung f¨
ur replizierte Dienste wird direkt durch den ORB
realisiert
Modified CORBA ORB
Dienst-Ansatz
Adaptor Objects
Unterst¨
utzung f¨
ur replizierte Dienste wird als CORBA Service
angeboten
Reliable Multicast
Interceptor-Ansatz
Operating System
Aufrufe werden durch Interceptoren (unterhalb des ORBs) abgefangen
Nachteil: Aufwendige Implementierung
Vorteil: Effizient und transparent f¨
ur die Applikation und kann
FT-CORBA kompatible sein
c R¨
udiger Kapitza
WS 09/10
MW
F 7-1
c R¨
udiger Kapitza
7 Implementierung
WS 09/10
MW
F 7-2
7 Implementierung
Dienst-Ansatz
Interceptor-Ansatz
Anwendung kommuniziert u
¨ber lokale Dienste mit dem replizierten
Objekt
Application Object
Interceptoren fangen Aufrufe ab und vermitteln sie weiter an das
replizierte Objekt
Object Group Service
Application Object
CORBA ORB
DII / DSI
IIOP Interception
CORBA ORB
Reliable Multicast
Operating System
Operating System
Nachteil: Indirektion u
¨ber den ORB
Nachteil: Nicht transparent f¨
ur die Anwendung und nicht kompatible
Vorteil: Keine Ver¨anderung des ORBs n¨
otig und damit portable
c R¨
udiger Kapitza
WS 09/10
MW
F 7-3
Nachteil: Interceptoren sind oft spezifisch f¨
ur ein Betriebssystem
Vorteil: Transparent f¨
ur die Anwendung
c R¨
udiger Kapitza
WS 09/10
MW
F 7-4
7 Implementierung
7 Implementierung
Kommunikation
Kommunikation
Beispiel: JGroups (http://www.jgroups.org)
Java basierte Gruppenkommunikation
Vorraussetzung f¨
ur aktive (und teilweise passive) Replikation ist in der
Regel ein total geordneter Multicast (abcast)
Es gibt auf allen Nachrichten eine globale Reihenfolge
Gruppenkommunikation nach dem Virtual Synchrony Modell
Einigungsalgorithmen (z.B. PAXOS von Lamport)
WS 09/10
MW
Protokolle werden pro Applikation konfiguriert
Beispielkonfiguration f¨
ur aktive Replikation
TCP – Nachrichten werden via TCP u
¨bertragen
FD – Heartbeat Nachrichten zur Detektion von Ausf¨allen
UNICAST – Nachrichten an einzelne Mitglieder
NAKACK – Nachrichten an alle Mitglieder
utzung f¨
ur Zustandstransfer
STATE TRANSFER – Unterst¨
¨
GMS – Nachrichten zu Anderungen
der Kommunikationsgruppe
STABLE – Garbage Collection von Nachrichten
TOTAL – Unterst¨
utzung f¨
ur globale Reihenfolge von Nachrichten
M¨ogliche Realisierungen
c R¨
udiger Kapitza
realisiert Virtual Synchrony Modell
F 7-5
c R¨
udiger Kapitza
7 Implementierung
WS 09/10
MW
F 7-6
7 Implementierung
Kommunikation
Zustandstransfer
Beispiel: JGroups TOTAL
Fester Knoten (Sequencer) bestimmt Nachrichtenreihenfolge
Sequencer vergibt kontinuierliche Sequenznummer
Vorraussetzungen
Objekt muss die Checkpointable-Schnittstelle implementieren
Erfordert den gesamten Objektzustand als Bytearray bereitzustellen
UB: Sender an Sequencer, Sequencer an alle
BB: Sender an alle, Sequencer an alle
UUB: Sender an Sequencer, Sequencer an Sender, Sender an alle
Aufgabe des Entwicklers!
Empf¨anger puffert Nachrichten und liefert an Anwendung aus, falls
seqNR(erwartet)==seqNr(Nachricht)
Sequenzerausfall: View-Wechsel: Knoten auf gleichen Stand bzgl.
alter View bringen, Neubeginn mit neuer View
Sicherungspunkt kann erstellt werden wenn sich das Objekt in einem
konsistenten Zustand befindet
alle laufenden Aufrufe werden beendet
neue Aufrufe werden blockiert
Andere Beispiele: Spread, Ensemble, Rampart (byzantinisch)
c R¨
udiger Kapitza
WS 09/10
MW
F 7-7
c R¨
udiger Kapitza
WS 09/10
MW
F 7-8
7 Implementierung
7 Implementierung
Zustandstransfer
Determinismus bei mehrf¨adiger Ausf¨uhrung
Beispiel: Protokoll eines nicht-blockierenden Zustandstransfers
New node
Replica 1
Replica 2
Nicht-replizierte objektbasierte Applikationen sind in der Regel
mehrf¨adig implementiert
1. take_snapshot
2. start queueing
3. make copy of state
¨
Zielsetzung: Uberf¨
uhrung zu replizierten Diensten ohne Ver¨anderung
der Anwendung
4. return copy of state
Problem: Fehlertolerante Infrastrukturen gestatten meist nur
einf¨adige Ausf¨
uhrung um Determinismus zu garantieren
4. get_state
5. set state; stop queuing;
deliver queued msgs
6. GC
7. destroy copy of state
c R¨
udiger Kapitza
WS 09/10
MW
F 7-9
c R¨
udiger Kapitza
WS 09/10
7 Implementierung
MW
F 7 - 10
7 Implementierung
Determinismus bei mehrf¨adiger Ausf¨uhrung
Determinismus bei mehrf¨adiger Ausf¨uhrung
Determinismus ist zwingend f¨
ur aktive Replikation
Multithreading ist eine Quelle f¨
ur Nichtdeterminismus
class Simple {
double state =0;
void clear () { synchronized(this) { state=0; }
void inc () {
synchronized(this) { state++; }
}
}
}
Ansatz der meisten Systeme:
abcast + sequentielle Aus¨
uhrung von Aufrufen
Probleme:
Nichtdeterminimus: C1 ruft clear() auf, C2 ruft inc() auf
clear()
T1
T2
T1
clear()
1: Deadlocks
T2
inc()
inc()
2:
A
3:
1:
c R¨
udiger Kapitza
WS 09/10
A
2:
2':
B
1':
1:
(a) circular
replica 1
B
(b) mutual
replica 2
MW
F 7 - 11
c R¨
udiger Kapitza
WS 09/10
MW
F 7 - 12
7 Implementierung
7 Implementierung
Determinismus bei mehrf¨adiger Ausf¨uhrung
Determinismus bei mehrf¨adiger Ausf¨uhrung
Probleme:
Probleme:
2: Keine Unterst¨
utzung f¨
ur Konditionvariablen
3: Leerlauf bei verschachtelten Aufrufen
Object A
1:wait
2:notify
Object B
Object A
request mA1
A
request mA2
Object B
request mA1
request mA2
nested invocation mB
→
reply mA1
nested invocation mB
reply mA2
reply mA1
reply mA2
c R¨
udiger Kapitza
WS 09/10
MW
F 7 - 13
c R¨
udiger Kapitza
7 Implementierung
WS 09/10
MW
F 7 - 14
7 Implementierung
Status quo: Existierende L¨osungen
ADETS-SAT: Interception durch Codetransformation
Ansatz der meisten Systeme:
abcast + sequentielle Aus¨
uhrung von Aufrufen
Interception der Java Synchronisationsanweisungen durch einen Scheduler
public class Queue extends ... {
public synchronized
String remove()
{
while(data. size ()==0)
wait();
return data.remove(0);
}
Existierende L¨osungen
Eternal (Narasimhan’99): einzelner logischer Thread
(L¨
osung f¨
ur Problem 1a: zirkul¨are Deadlocks)
Jimenez-Peris, Eternal (Zhao’05): ein aktiver Thread
(L¨
osung f¨
ur Problem 1+3: Deadlocks und des Leerlaufs bei verschachtelten
Aufrufen)
⇒
Aspectix DEterministic Thread Scheduler–Single Active Threads
(ADETS-SAT), ein aktiver Thread + Unerst¨
utzung f¨
ur
Konditionvariablen und des nativen Java Koordinierungsmodels
public synchronized
void append(String x)
{
data.add(x);
notify();
}
synchronized statements, wait(), wait(timeout ), notify(),
notifyAll()
J¨
org Domaschka, Franz J. Hauck, Hans P. Reiser, R¨
udiger Kapitza
Deterministic Multithreading for Java-based Replicated Objects
PDCS 2006 (Dallas, TX, USA, Nov 13-15, 2006); pp. 516-521
c R¨
udiger Kapitza
WS 09/10
MW
}
F 7 - 15
c R¨
udiger Kapitza
WS 09/10
public class Queue extends ... {
public String remove() {
scheduler().lock(this);
try {
while(data. size ()==0)
scheduler().mtwait(this);
return data.remove(0);
} finally {
scheduler().unlock(this);
}
}
public void append(String x) {
scheduler().lock(this);
try {
data.add(x);
scheduler().mtnotify(this);
} finally {
scheduler().unlock(this);
}
} }
MW
F 7 - 16
7 Implementierung
7 Implementierung
ADETS-SAT: Annahmen
ADETS-SAT: Basiskonzepte
Runnable
Thread
Active
Primary
Korrekte Koordinierung
Zustand wird nur dann ver¨andert wenn das entsprechende Lock
angefordert ist
Keine implizite (atomare Variablen) oder wait-free Synchronisation
Keine anderen Quellen f¨
ur Nichtdeterminismus wie Zufallszahlen etc.
Suspended Threads
Threads in
CondWaitMap
Threads in
MutexWaitMap
only active primary
can acquire locks
suspended threads waiting
for local unlock / notification
Threads waiting
for nested invoc.
waiting for reply of
nested invocation
Es gibt immer genau einen aktiven Thread
Eine Reihe von blockierten Threads
blockierte Threads
wartende Threads
durch externe Aufrufe blockierte Threads
c R¨
udiger Kapitza
WS 09/10
MW
F 7 - 17
c R¨
udiger Kapitza
7 Implementierung
WS 09/10
MW
7 Implementierung
ADETS-SAT: Interne Zust¨ande
ADETS-SAT: Interne Zust¨ande
triggers schedule()
triggers schedule()
Runnable
Thread
Active
Thread
Suspended Threads
wait()
lock()
Threads in
CondWaitMap
Threads in
MutexWaitMap
F 7 - 18
nested
invocation
Runnable
Thread
Active
Thread
Threads waiting
for nested invoc.
Suspended Threads
wait()
lock()
Threads in
CondWaitMap
Threads in
MutexWaitMap
nested
invocation
Threads waiting
for nested invoc.
notify() by active thread
¨
Ubergang
auf den n¨achsten lauff¨ahigen Thread durch den Aufruf von
lock(), wait() oder einer entfernten Methode
c R¨
udiger Kapitza
WS 09/10
MW
F 7 - 19
Wartende Threads werden durch notify() in die MutexWaitMap
verschoben
c R¨
udiger Kapitza
WS 09/10
MW
F 7 - 20
7 Implementierung
7 Implementierung
ADETS-SAT: Interne Zust¨ande
ADETS-SAT: Interne Zust¨ande
triggers schedule()
triggers schedule()
Runnable
Thread
Active
Thread
wait()
lock()
Threads in
CondWaitMap
Threads in
MutexWaitMap
schedule() [1]
Runnable
Thread
nested
invocation
Suspended Threads
Threads in
CondWaitMap
Threads in
MutexWaitMap
schedule() [1]
notify() by active thread
wait()
lock()
Active
Thread
Threads waiting
for nested invoc.
WS 09/10
MW
F 7 - 21
Threads waiting
for nested invoc.
new thread
notify() by active thread
inQueue
schedule() [2]:
process nest message
Schedule macht den ersten Thread aus der MutexWaitMap zum neuen
aktiven Thread
c R¨
udiger Kapitza
nested
invocation
Suspended Threads
c R¨
udiger Kapitza
WS 09/10
7 Implementierung
MW
F 7 - 22
7 Implementierung
ADETS-SAT: Timeouts
ADETS-SAT: Timeouts
wait()-Zeitschranken k¨
onnen ablaufen
wait(n) Ablauf einer Zeitschranke nach n ms
class Buffer {
// [...]
Object getItem() throws OperationTimeoutExcpetion {
synchronized(data) {
if (data.isEmpty())
data. wait (100);
if (! data.isEmpty()) return data.getNext();
throw new OperationTimeoutException();
}
}
void putItem(Object obj) {
synchronized(data) {
data.append(obj);
data. notify ();
}
}
}
c R¨
udiger Kapitza
WS 09/10
MW
Problem explizite Benachrichtigung und Ablauf der Zeitschranke
k¨onnen konkurrieren
T1
T2
notify()
Timeout
replica 1
F 7 - 23
c R¨
udiger Kapitza
T2
wait(100ms)
wait(100ms)
Timeout
T1
notify()
replica 2
WS 09/10
MW
F 7 - 24
7 Implementierung
8 Zusammenfassung
ADETS-SAT: Timeouts
Zusammenfassung
L¨
osung
Timeout erzeugt einen eigenen Thread
Notify-Thread oder Timeout-Thread erh¨alt deterministisch das
entsprechende Lock
T2
T1
FT-CORBA bildet einen Standard zu Entwicklung fehlertoleranter
Infrastrukturen und Anwendungen
TO
Durch Middlewaremechanismen und starke Konsistenz sind replizierte
Objekte weitgehend transparent f¨
ur Anwendungen
Objektimplementierungen m¨
ussen angepasst werden
wait(100ms)
Determinismus
Zustandstransfer
Timeout: send
TO message
notify()
c R¨
udiger Kapitza
WS 09/10
MW
F 7 - 25
8 Zusammenfassung
Zusammenfassung
Kritikpunkte
Einheit der Replikation: Objekt vs. Prozess
Nichtdeterminismus muss durch den Anwendungsentwickler behandelt
werden
Zustand: Objekt + Infrastruktur – Zustand der Infrastruktur ist
schwer zu ermitteln
Konfiguration ist kompliziert
Konsistente Replikation erfordert aufwendige Gruppenkommunikation
c R¨
udiger Kapitza
WS 09/10
MW
F 8-2
c R¨
udiger Kapitza
WS 09/10
MW
F 8-1
Document
Kategorie
Technik
Seitenansichten
5
Dateigröße
861 KB
Tags
1/--Seiten
melden