Überblick wintersemester 2014/2015 prof. dr. peter mandl
Post on 13-Jun-2022
4 Views
Preview:
TRANSCRIPT
Prof. Dr. Peter Mandl Seite: 1 Verteilte Systeme
Überblick Wintersemester 2014/2015
Prof. Dr. Peter Mandl
Verteilte Systeme
Einführung und Überblick
Zeitsynchronisation
Wahl und Übereinstimmung
RPC, verteilte Objekte und Dienste
Verteilte Transaktionen
Message Passing
Middlewareplattformen
Verteilte Architekturen
Gruppenkommunikation
Replikation
Wechselseitiger Ausschluss
Prof. Dr. Peter Mandl Seite: 2 Verteilte Systeme
Zielsetzung
Zielsetzung der Vorlesung ist es,
- den Message-Passing-Ansatz zu verstehen und nutzen zu
können,
- Message-Queueing-Systeme einordnen können und
- entscheiden zu können, wann man diese Technik benötigt.
Prof. Dr. Peter Mandl Seite: 3 Verteilte Systeme
Überblick
1. Grundlagen zum Message Passing
2. Fallstudie JMS
3. Cloud-Ansätze
Prof. Dr. Peter Mandl
Einführung
In verschiedenen Anwendungsszenarien sind nicht nur entfernte Aufrufe, sondern auch andere Kommunikationsbeziehungen möglich:
- Gleichberechtige Kommunikationspartner (symmetrische Rollenverteilung) P2P-Kommunikation
- Producer-Consumer-Problemstellungen
- Ereignisgesteuerte Bearbeitung
- Empfänger ist nicht immer verfügbar
Dazu benötigt man neben Remote Procedure Calls und deren Ableitungen noch andere Kommunikationstechniken
Verteilte Systeme Seite: 4
Prof. Dr. Peter Mandl Seite: 5 Verteilte Systeme
Meldungsorientierte, eng gekoppelte Kommunikation
Varianten meldungsorientierer Kommunikation
- Datagrammstil
- Rendezvous
Enge Kopplung zwischen den Partnern
Partner 2
sendreceive send
Blockierung
receive
Datagramm Rendezvous
Empfänger blockiert, Sender nicht
Synchronisierung, da auch Sender blockiert bis Quittung da ist
Partner 1 Partner 2Partner 1
Prof. Dr. Peter Mandl Seite: 6 Verteilte Systeme
Entkoppelte Kommunikation
Wenn die Partner nicht immer verfügbar sind,
- müssen Nachrichten ggf. zwischengepuffert werden,
- der Sender muss weiterarbeiten können und
- die Nachrichten können dann später vom Empfänger abgeholt werden
Transiente oder persistente Speicherung der Nachrichten?
Verarbeitung: in der Regel nach FIFO
Sender Empfänger Puffer
Prof. Dr. Peter Mandl Seite: 7 Verteilte Systeme
Entkoppelte Kommunikation Publish-Subscribe-Modell
Themenbezogene Ordnung: Topics
Ein Subscriber registriert sich für ein oder mehrere Topics
Subscriber können zur Laufzeit hinzukommen
Topics können transient oder persistent sein
Publisher 2 Topic
Subscriber 1
Subscriber m
…
Publisher 1
Publisher n
Subscriber 2
…
Prof. Dr. Peter Mandl Seite: 8 Verteilte Systeme
Entkoppelte Kommunikation Point-to-Point-Modell mit Queues
Warteschlangen-Modell: Queues
Subscriber können zur Laufzeit hinzukommen
Queues können transient oder persistent sein
Sender 2
Empfänger 1
Empfänger m
…
Sender 1
Sender n
Empfänger 2
…
Queue
Prof. Dr. Peter Mandl Seite: 9 Verteilte Systeme
Persistente versus transiente Speicherung
Transient gespeicherte Nachrichten in Topics oder Queues werden im Fehlerfall verworfen
Persistente Speicherung ist auch möglich, Nachrichten überleben Fehlerfall
Welche Fehler sind verkraftbar?
Sender Empfänger
Persistente Queue
Prof. Dr. Peter Mandl Seite: 10 Verteilte Systeme Verteilte Systeme
Transaktionssicherheit
Was bedeutet Transaktionssicherheit im Message Passing?
Einstellen und Entnehmen von Nachrichten in/aus Queue bzw. Topic in einer ACID-Transaktion
Provider muss entsprechende Vorkehrungen für die Sicherung der Logs und Daten vornehmen
Aber keine Ende-zu-Ende-Transaktionssicherheit
Das würde dem Entkoppelungsgedanken widersprechen
Transaktionssicherheit nur für das Einstellen von Nachrichten in die Queue oder in das Topic und separat für das Auslesen
Prof. Dr. Peter Mandl Seite: 11 Verteilte Systeme
Persistentes Message-Queuing-System notwendig
Praktisch erprobt
Entkopplung der Systeme
ACID-Eigenschaften?
Praktischer Ansatz: Simulation über DB-Tabellen möglich
Anwendung 1
Queue 1
Message-Queuing-System
Queue 2
Anwendung 2
Anwendung 3
...
Queued Transactions
Prof. Dr. Peter Mandl Seite: 12 Verteilte Systeme
Aufbau eines Message-Queueing-Systems mit Routing
Applikation
Applikation
Applikation
Applikation
R2
R1
Router
Empfänger B
Sender A
Nachricht
Sende-
Warteschlange
Empfangs-
Warte-
Schlange
C
D
R3
Prof. Dr. Peter Mandl Seite: 13 Verteilte Systeme
Anwendungsszenario: Online-Banking
Kontobuchungen über Online-Banking müssen in ein zentrales Kontoführungssystem übertragen werden
Mögliche Varianten für die Umsetzung:
- Dateiübertragung
- Direkte Diensteschnittstelle (etwa über RPC oder Webservices) des Kontoführungssystems nutzen
- Message-Passing
Online- Banking
Konto- führung
Buchungen/Umsätze
Prof. Dr. Peter Mandl Seite: 14 Verteilte Systeme
Überblick
1. Grundlagen zum Message Passing
2. Fallstudie JMS
3. Cloud-Ansätze
Prof. Dr. Peter Mandl Seite: 15 Verteilte Systeme
JMS-Architekturüberblick: Session-Modell (1)
Anwendung 1 Anwendung 2
JMS-Provider
JMS-Interfaces JMS-Interfaces
JMS-Consumer
Session Session
Connection
zum Provider
Connection
zum Provider
Connection und Session als Basis für Kommunikation
- Sessions sind unabhängig voneinander
- Jede Anwendung baut eine Session mit dem JMS-
Provider auf
Prof. Dr. Peter Mandl Seite: 16 Verteilte Systeme
JMS-Architekturüberblick: Session-Modell (2)
JMS-
Clientanwendung
JMS-
Clientanwendung
JMS-Provider
(JMS-Server,
MOM-Server)
JMS-SAP
(JMS-Interface)
Session
JMS
Connection
Session
JMS
Connection
Transportsystem (TCP)
Unabhängige
Verbindungen
Schicht 5-7
Schicht 1-4
TSAP
(Socketzugriff) TSAP TSAP
Connection: Kommunikationskanal zum JMS-Provider
Session repräsentiert einen Kontext für Sender, Empfänger und Nachrichten
Prof. Dr. Peter Mandl Seite: 17 Verteilte Systeme
JMS-Architekturüberblick: Point-to-Point-Modell
Anwendung 1 Anwendung 2
JMS-Provider
Queues Queues
JMS-Interfaces JMS-Interfaces
JMS-Consumer
Baut Session auf
TopicTopic
Baut Session auf
Provider-Produkte: JBoss MQ, Websphere Message Queue (MQ), Apache ActiveMQ,
TIBCO EMS, Oracle Advanced Queueing, Oracle BEA WebLogic, …
Provider verwaltet Queues und Topics (administrative Objekte)
Destinations
Prof. Dr. Peter Mandl Verteilte Systeme Seite: 18
JMS-Kommunikation
Producer-Anwendung
ConnectionFactory besorgen
Destination besorgen
JMS Provider
Consumer-Anwendung
Queue/Topic einrichten
Connection erzeugen
Session erzeugen
MessageProducer erzeugen
Message erzeugen
Message senden
JNDIConnectionFactory besorgen
Destination besorgen
Connection erzeugen
Session erzeugen
MessageConsumer erzeugen
Message empfangen
Message bearbeiten
Administrator
...Topic oder Auftragsqueue
Close Session und Connection Close Session und Connection
...
onMessage()-Methode als Callback implementieren
Prof. Dr. Peter Mandl Seite: 19 Verteilte Systeme
JMS: Message-Aufbau
JMS-Message-Header und JMS-Properties
Message-Body
- Unterschiedliche Typen: TextMessage, ByteMessage, ObjectMessage,...
Properties
- JMSX-Properties : vordefiniert (siehe JMS-Spezifikation)
- Individuell: (name, value), verschiedene Typen möglich (boolean, byte, long,
String,…, Objects)
Interface Message
- getPropertyNames() liefert alle Properties
- clearBody() löscht ganzen Body
- clearProperties() löscht alle Properties einer Nachricht
- getJMSPriority(), setJMSProperty(…)
- getStringProperty(), setStringProperty(…)
- …
Message-Body
JMS-Message- Headerfelder
Vordefinierte JMSX-Properties
Frei definierte Properties
Header
Prof. Dr. Peter Mandl Seite: 20 Verteilte Systeme
JMS: Message-Header-Felder
Header-Feld Bedeutung Wird belegt
JMSDestination Ziel-Topic oder -Queue Implizit beim Senden
JMSDeliveryMode nicht-persistenter und persistenten Mode Implizit beim Senden
JMSMessageID Eindeutige Nachrichten-ID (String) Implizit beim Senden
JMSTimeStamp Zeitpunkt der Übergabe an den JMS-Provider)
Implizit beim Senden
JMSRedelivered Hinweis, dass möglicherweise schon ausgeliefert wurde
JMS-Provider
JMSExpiration Angabe, wie lange eine Nachricht leben soll Implizit beim Senden
JMSPriority Prioritäten, 0-4 = normal, 5-9 = hoch Implizit beim Senden
JMSCorrelationID Verlinken von Nachrichten möglich JMS-Client
JMSReplyTo Destination (Topic, Queue), zu der die Antwort geschickt werden soll
JMS-Client
JMSType Frei vergebener Typ der Nachricht (Client vergibt)
JMS-Client
JMS-Message-Header-Felder können gelesen und gesetzt werden
(get/set-Methoden)
Prof. Dr. Peter Mandl Seite: 21 Verteilte Systeme
JMS: JMSX-Properties
JMSX-Properties sind vordefinierte Properties, die in der JMS-Spezifikation vorgegeben sind:
- JMSXUserid: Eindeutiger String zur Identifikation eines JMS-Clients,
wird vom Provider beim Senden gesetzt
- JMSXApplId: Identifiziert die Anwendung, wird vom Provider beim Senden gesetzt
- …
Nutzung in Message-Selektoren möglich
Prof. Dr. Peter Mandl Seite: 22 Verteilte Systeme
JMS-Einstellmöglichkeiten (1)
Delivery-Modus: (regelt Providerausfall)
- Persistent: Nachrichten werden dauerhaft in einen Speicher
gelegt, auch bei JMS-Providerausfall werden Nachrichten
zugestellt
- Nicht-persistent: Nachrichten werden nach einen JMS-Provider-
Ausfall nicht mehr zugestellt
Abonnement-Modus: (regelt Konsumentenausfall)
- Dauerhaft: Nachrichten an nicht verfügbare Konsumenten
werden zu einem späteren Zeitpunkt zugestellt
- Nicht-dauerhaft: Keine Zustellung für nicht verfügbare
Konsumenten
Prof. Dr. Peter Mandl Seite: 23 Verteilte Systeme
JMS-Einstellmöglichkeiten (2)
Acknowledgement-Modus: (bezieht sich auf die Bestätigung
einer Nachricht):
- Auto_Ack: Automatische Bestätigung nachdem die Nachricht
angekommen ist und verarbeitet wurde
Einmalige Lieferung und keine Duplikate garantiert (at-
most-once)
- Dups_Ok_Ack: Empfangsbestätigung automatisch nach dem
Empfang und der Verarbeitung von n Nachrichten, wobei n vom
JMS Provider abhängt
keine Duplikatsprüfung (nur at-least-once).
- Client_Ack: Keine automatische Bestätigung, sondern explizit
durch JMS-Empfänger-Anwendung, über Methode acknowledge()
Angabe bei der Session-Erzeugung: createSession(false, Session.Auto_Ack); false no transaction
Prof. Dr. Peter Mandl Seite: 24 Verteilte Systeme
JMS-Beispielnutzung: Durable Subscriber
JMS-Subscriber JMS-Publisher
JMS-Provider
Session.
createDurableSubscriber(…)
Topic
Session
Topic
SessionTopic
Session
Session.
createProducer(…)
Abo-Modus: Dauerhaftes Abo überlebt auch ein Abmelden
eines Subscribers, Nachrichten bleiben erhalten
Identifikation bei erneuter Anmeldung über:
- Gleiche Connection
- Gleiche Destination und Subscription
- Gleicher Message Selector
Prof. Dr. Peter Mandl Seite: 25 Verteilte Systeme
JMS-Beispielnutzung: Filterungsmöglichkeiten (1)
Wie kann man Nachrichten für Topics filtern?
- Beispiel hier mit Topics
- Mehrere Topics
- Filter setzen im Client mit Message-Selektoren
Publisher
Topic1
Topic2
Topic3
Subscriber 1
Subscriber 2
Subscriber 3
Subscriber 4
Subscriber 5
Subscriber 6
Publisher Topic
Subscriber 1
Subscriber 2
Subscriber 3
Subscriber 4
Subscriber 5
Subscriber 6
Ein Topic + weiteren Filtermechanismus (Selektor in SQL93-ähnlicher Notation)
Filterung nur über Topics
Prof. Dr. Peter Mandl Seite: 26 Verteilte Systeme
JMS-Beispielnutzung: Filterungsmöglichkeiten (2)
Beispiel
- Eigenes Message-Property für die Selektion nutzen
Quelle: JMS-Spezifikation
String stockData; /* Stock information as a String */ TextMessage message; /* Set the message’s text to be the stockData string */ message = session.createTextMessage(); message.setText(stockData); /* Set the message property ‘StockSector’ */ message.setStringProperty("StockSector", "Technology");
Producer
String selector; selector = new String("(StockSector = ’Technology’)"); /* This string is specified when the MessageConsumer is created*/ MessageConsumer receiver; receiver = session.createConsumer(stockQueue, selector);
Consumer
Prof. Dr. Peter Mandl Seite: 27 Verteilte Systeme
Message Driven Bean: Ein asynchroner Mechanismus in JEE App Servern
EJB-Container
6: Delegiert die JMS-Nachricht an
eine Bean-Instanz, die einer
Queue oder einem Topic
zugeordnet ist.
Container erzeugt Bean-Instanz
selbstständig
JMS
Provider
2: Registriert sich als
Listener für Queue/Topic
5: Sendet JMS-Nachricht an Queue/Topic
1. Topic/Queue wird angelegt
(administrativer Vorgang)
JNDI Naming
Service
Client
Applikationsserver
JNDI
3: Holt Referenz
auf Queue/Topic
4: Liefert Referenz
auf Queue/Topic
Bean-
Instanz
onMessage()
Prof. Dr. Peter Mandl Seite: 28 Verteilte Systeme
Fallbeispiel für JMS-Topics: Chat-Programm
DataAccessService
Chat
ClientAdmin
WebClient
Admin
.NETClient
Monitoring
Client
Chat-Kernel
IDataAccessService
IChatClient
IAdminClient
IChatMessage
IMessageSender
IChatSystem
IMonitoringClient
IClient
JBoss
Application
Server
Raum
Topic
Update
TopicMonitoring
Topic
BusinessLogic
AdminClient
WS
Database (MySQL)Category
ChatRoomChatUser Role
ChatUser
LoggedIn
Unterstützte Interfaces:
Chat-Anwendung mit EJB und JMS realisiert
Architekturübersicht: Topics zum Verteilen der Chat-Nachrichten
JBoss EJB
JBoss MQ
3 Topics
Prof. Dr. Peter Mandl Seite: 29 Verteilte Systeme
Einschub: Interoperabilität von JMS-Providern
JMS ist keine Protokollspezifikation, sondern eine API-
Spezifikation
Weiterer (mittlerweile) OASIS-Standard
- Advanced Message Queuing Protocol (AMQP) der AMQP-Working-
Group als Protokollstandard für Message-Queuing-Systeme (http://amqp.org/, Stand: September 2013)
Anwendung 1 Anwendung 2
JBOSS
MQ
JMS-Interfaces JMS-Interfaces
JMS-Consumer
Session
Connection
zum Provider
Connection
zum Provider
Websphere
MQ
SessionProtokoll?
Prof. Dr. Peter Mandl Seite: 30 Verteilte Systeme
JMS 2.0 in Java EE 7 und SE
Erstes JMS-Release 1998, letzte Änderung JMS 1.1 war in 2003
JSR 343 JMS 2.0: Finally released im Mai 2013
Im Wesentlichen Vereinfachungen:
Vereinfachte API: JMSContext als zusammengefasstes Objekt
für Connection und Session
...
„Classic API“ (JMS 1.1) bleibt bestehen
Prof. Dr. Peter Mandl Seite: 31 Verteilte Systeme
Message Passing Diskussion
Message Passing als Alternative zu Client-Server, aber auch als
Ergänzung denkbar
JMS ist heute ein verbreiteter Standard, aber es gibt viele
proprietäre Ansätze
Message Driven Beans dienen der Einbettung von Message
Passing in die EJB-Umgebung
Diskussion:
- Persistenz in Queues – sichere Sache oder doch besser
Datenbanken nutzen?
- Wird ein Standardprotokoll wirklich genutzt?
Prof. Dr. Peter Mandl Seite: 32 Verteilte Systeme
Überblick
1. Grundlagen zum Message Passing
2. Fallstudie JMS
3. Cloud-Ansätze
Prof. Dr. Peter Mandl Seite: 33 Verteilte Systeme
Queuing-Dienste aus der Cloud: Überblick
Message-Queuing-Dienste kann man heute auch
schon aus der Cloud beziehen
Beispiele:
Windows Azure Queue
Amazon Simple Queue Service (SQS)
Linxter Internet Service Bus (Out of Service seit Okt. 2012)
Prof. Dr. Peter Mandl Seite: 34
Windows Azure Queue: Überblick
Modelle: Queues und Publish-Subscribe
Auslieferungsgarantie: At-least-once
Keine Ordnungsgarantie, auch kein FIFO
Maximale Nachrichtenlänge: 64 KB
REST API für Zugriff
Quelle: Martina Kerndl Studienarbeit: Untersuchung der Cloud-basierten Messaging-Lösung Mircosoft Azure Queue und Erprobung anhand eines Szenarios , Wintersemester 12/13, Hochschule München; Grafiken übernommen aus: http://msdn.microsoft.com/en-us/library/ff803372.aspx (letzter Zugriff am 23.08.2013)
Verteilte Systeme
Prof. Dr. Peter Mandl Seite: 35
Amazon SQS: Überblick
Modell: Queues, kein Publish-Subscribe
Auslieferungsgarantie: At-least-once
Einfache Java-API und auch andere Sprachen, siehe Amazon
Simple Queue Service, Developer Guide
Maximale Nachrichtenlänge: 64 KB
Löschen der Nachrichten bei Nichtabholen nach standardmäßig
14 Tagen, ganze Queues nach 30 Tagen
Quelle: Simon Effenberg: Studienarbeit: Amazon Simple Queue Service Benchmark, Wintersemester 12/13, Hochschule München
Verteilte Systeme
Prof. Dr. Peter Mandl Seite: 36
Amazon SQS: Speicherung der Nachrichten
Redundante Speicherung der Nachrichten, nach
Zufallsalgorithmus
Keine FIFO-Garantie
Quelle: Stefan Burgmair: Studienarbeit: Untersuchung der Cloud-basierten Messaging-Lösung Amazon Simple Queue Service bezüglich der Architektur, Zuverlässigkeit, Transaktionsfähigkeit und Skalierbarkeit, Wintersemester 12/13, Hochschule München; Grafik übernommen aus Amazon Simple Queue Service, Developer Guide
Verteilte Systeme
Prof. Dr. Peter Mandl Seite: 37
Amazon SQS: Besonderheit: Visibility
Nach dem Abholen einer Nachricht wird nicht automatisch gelöscht,
sondern die Nachricht wird zunächst unsichtbar für andere gemacht
Wenn innerhalb einer Zeitspanne (Visibility-Timeout) kein Löschen
erfolgt, wird die Nachricht wieder für andere sichtbar
Timeout-Einstellung (Sichtbarkeit) kann je Queue und/oder je
Nachricht erfolgen
Folgen: Kein garantiertes FIFO und evtl. doppelte Bearbeitung, aber
Fehlersemantik At-mostly-once
Übernommen aus: Amazon Simple Queue Service, Developer Guide
Verteilte Systeme
Prof. Dr. Peter Mandl Seite: 38
Amazon SQS: Eigene Benchmarks (1)
Eigene Benchmarks wurden durchgeführt
Resümee: Noch Vorsicht bei großer Last!
Quelle: Simon Effenberg: Studienarbeit: Amazon Simple Queue Service Benchmark, Wintersemester 12/13, Hochschule München
Betriebssystem RAM (GB) CPU Internet
Windows 8 Pro
(64-Bit)
4 GB Intel Core 2
Quad CPU -
2,5 GHz
Ethernet:
Telekom
V-DSL 50
Betriebssystem RAM (GB) CPU Internet
Windows 7 8 GB Intel i5 3,3
GHz
Ethernet:
Telekom
V-DSL 50 Rechner B - Server
Verteilte Systeme
Prof. Dr. Peter Mandl Seite: 39
Amazon SQS: Eigene Benchmarks (2)
Konfiguration an der AWS Console SQS
Weitgehend Standardeinstellungen verwendet
Quelle: Simon Effenberg: Studienarbeit: Amazon Simple Queue Service Benchmark, Wintersemester 12/13, Hochschule München
https://console.aws.amazon.com/sqs/
Verteilte Systeme
Prof. Dr. Peter Mandl
Amazon SQS: Eigene Benchmarks (3)
Seite: 40
Quelle: Simon Effenberg: Studienarbeit: Amazon Simple Queue Service Benchmark, Wintersemester 12/13, Hochschule München
Kommunikationsszenario
Verteilte Systeme
Prof. Dr. Peter Mandl
Amazon SQS: Eigene Benchmarks (4): Variation der Anzahl Clients
Seite: 41
Quelle: Simon Effenberg: Studienarbeit: Amazon Simple Queue Service Benchmark, Wintersemester 12/13, Hochschule München
Verteilte Systeme
Prof. Dr. Peter Mandl
Amazon SQS: Eigene Benchmarks (5): Variation der Nachrichtenlänge
Seite: 42
Quelle: Simon Effenberg: Studienarbeit: Amazon Simple Queue Service Benchmark, Wintersemester 12/13, Hochschule München
Verteilte Systeme
Prof. Dr. Peter Mandl Seite: 43 Verteilte Systeme
Vergleich aktueller Cloud-Messaging-Dienste
Amazon
SQS
Windows
Azure Queue
Linxter (Basic)
Preismodell Nutzungsabhängig Nutzungsabhängig Monatlicher Festpreis
Maximale Größe der Nachrichten (in KB)
64 64 1024
(+1024 KB je Anhang)
Maximale Lebensdauer der Nachrichten (in Tagen)
14 7 4
Zustellungssemantik At-Least-Once At-Least-Once Exactly-Once
Kommunikation (APIs) - SDK’s
- REST
- SDK‘s
- REST
- SDK‘s
Garantiertes FIFO Nein Nein Ja
Nachrichtenformat Textbasiert
Stand: 12/12
Prof. Dr. Peter Mandl Seite: 44 Verteilte Systeme
Zusammenfassung
Fragen?
Grundlagen zum Message Passing
Fallstudie JMS
Cloud-Ansätze
top related