Überblick Wintersemester 2014/2015

Transkript

1 Ü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 Seite: 1

2 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. Seite: 2

3 Überblick 1. Grundlagen zum Message Passing 2. Fallstudie JMS 3. Cloud-Ansätze Seite: 3

4 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 Prof. Dr. Peter Mandl Verteilte Systeme Seite: 4

5 Meldungsorientierte, eng gekoppelte Kommunikation Varianten meldungsorientierer Kommunikation - Datagrammstil - Rendezvous Enge Kopplung zwischen den Partnern Datagramm Rendezvous Partner 1 Partner 2 Partner 1 Partner 2 send receive send receive Empfänger blockiert, Sender nicht Blockierung Synchronisierung, da auch Sender blockiert bis Quittung da ist Seite: 5

6 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 Puffer Empfänger Seite: 6

7 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 1 Subscriber 1 Publisher 2 Publisher n Topic Subscriber 2 Subscriber m Seite: 7

8 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 1 Sender 2 Sender n Queue Empfänger 1 Empfänger 2 Empfänger m Seite: 8

9 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? Persistente Queue Sender Empfänger Seite: 9

10 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 Seite: 10

11 Queued Transactions Persistentes Message-Queuing-System notwendig Praktisch erprobt Entkopplung der Systeme ACID-Eigenschaften? Anwendung 1 Anwendung 3 Queue 1... Queue 2 Message-Queuing-System Anwendung 2 Praktischer Ansatz: Simulation über DB-Tabellen möglich Seite: 11

12 Aufbau eines Message-Queueing-Systems mit Routing Sender A C Applikation Empfangs- Warte- Schlange Applikation Nachricht R2 Sende- Warteschlange D R3 Applikation R1 Applikation Router Empfänger B Seite: 12

13 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 Buchungen/Umsätze Kontoführung Seite: 13

14 Überblick 1. Grundlagen zum Message Passing 2. Fallstudie JMS 3. Cloud-Ansätze Seite: 14

15 JMS-Architekturüberblick: Session-Modell (1) Connection und Session als Basis für Kommunikation - Sessions sind unabhängig voneinander - Jede Anwendung baut eine Session mit dem JMS- Provider auf Anwendung 1 Anwendung 2 JMS-Consumer Session Connection zum Provider JMS-Interfaces JMS-Provider Connection zum Provider JMS-Interfaces Session Seite: 15

16 JMS-Architekturüberblick: Session-Modell (2) Connection: Kommunikationskanal zum JMS-Provider Session repräsentiert einen Kontext für Sender, Empfänger und Nachrichten JMS- Clientanwendung JMS- Clientanwendung JMS-SAP (JMS-Interface) Session JMS Connection JMS-Provider (JMS-Server, MOM-Server) Session JMS Connection Schicht 5-7 TSAP (Socketzugriff) Unabhängige Verbindungen TSAP TSAP Transportsystem (TCP) Schicht 1-4 Seite: 16

17 JMS-Architekturüberblick: Point-to-Point-Modell Provider verwaltet Queues und Topics (administrative Objekte) Anwendung 1 Anwendung 2 JMS-Consumer Destinations Baut Session auf JMS-Interfaces JMS-Provider Baut Session auf JMS-Interfaces Queues Topic Topic Queues Provider-Produkte: JBoss MQ, Websphere Message Queue (MQ), Apache ActiveMQ, TIBCO EMS, Oracle Advanced Queueing, Oracle BEA WebLogic, Seite: 17

18 JMS-Kommunikation Producer-Anwendung ConnectionFactory besorgen Destination besorgen JNDI Consumer-Anwendung ConnectionFactory besorgen Destination besorgen Connection erzeugen Connection erzeugen Session erzeugen MessageProducer erzeugen Message erzeugen JMS Provider Session erzeugen MessageConsumer erzeugen Message empfangen Message senden... Close Session und Connection Queue/Topic einrichten Topic oder Auftragsqueue Administrator Message bearbeiten... Close Session und Connection onmessage()-methode als Callback implementieren Seite: 18

19 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( ) - Header JMS-Message- Headerfelder Vordefinierte JMSX-Properties Frei definierte Properties Message-Body Seite: 19

20 JMS: Message-Header-Felder JMS-Message-Header-Felder können gelesen und gesetzt werden (get/set-methoden) 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 JMSRedelivered Zeitpunkt der Übergabe an den JMS- Provider) Hinweis, dass möglicherweise schon ausgeliefert wurde Implizit beim Senden 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 JMSType Destination (Topic, Queue), zu der die Antwort geschickt werden soll Frei vergebener Typ der Nachricht (Client vergibt) JMS-Client JMS-Client Seite: 20

21 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 Seite: 21

22 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 Seite: 22

23 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 (atmost-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 Seite: 23

24 JMS-Beispielnutzung: Durable Subscriber 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 JMS-Subscriber JMS-Publisher Topic Session Session. createdurablesubscriber( ) JMS-Provider Topic Session Topic Session Session. createproducer( ) Seite: 24

25 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 Subscriber 1 Subscriber 1 Subscriber 2 Subscriber 2 Topic1 Subscriber 3 Subscriber 3 Publisher Topic Subscriber 4 Publisher Topic2 Subscriber 4 Topic3 Subscriber 5 Subscriber 5 Ein Topic + weiteren Filtermechanismus (Selektor in SQL93-ähnlicher Notation) Subscriber 6 Filterung nur über Topics Subscriber 6 Seite: 25

26 JMS-Beispielnutzung: Filterungsmöglichkeiten (2) Beispiel - Eigenes Message-Property für die Selektion nutzen Producer 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"); Consumer String selector; selector = new String("(StockSector = Technology )"); /* This string is specified when the MessageConsumer is created*/ MessageConsumer receiver; receiver = session.createconsumer(stockqueue, selector); Quelle: JMS-Spezifikation Seite: 26

27 Message Driven Bean: Ein asynchroner Mechanismus in JEE App Servern 1. Topic/Queue wird angelegt (administrativer Vorgang) JNDI JNDI Naming Service 4: Liefert Referenz auf Queue/Topic 5: Sendet JMS-Nachricht an Queue/Topic JMS Provider 2: Registriert sich als Listener für Queue/Topic 3: Holt Referenz auf Queue/Topic Client Container erzeugt Bean-Instanz selbstständig 6: Delegiert die JMS-Nachricht an eine Bean-Instanz, die einer Queue oder einem Topic zugeordnet ist. onmessage() Bean- Instanz EJB-Container Applikationsserver Seite: 27

28 Fallbeispiel für JMS-Topics: Chat-Programm Chat-Anwendung mit EJB und JMS realisiert Architekturübersicht: Topics zum Verteilen der Chat-Nachrichten Chat Client Monitoring Client Admin WebClient Admin.NETClient JBoss EJB JBoss MQ 3 Topics Raum Topic Update Topic Monitoring Topic AdminClient WS Chat-Kernel Unterstützte Interfaces: IClient IChatClient IChatMessage IMessageSender IAdminClient IChatSystem IMonitoringClient BusinessLogic IDataAccessService DataAccessService JBoss Application Server Category ChatRoom ChatUser LoggedIn ChatUser Database (MySQL) Role Seite: 28

29 Einschub: Interoperabilität von JMS-Providern JMS ist keine Protokollspezifikation, sondern eine API- Spezifikation Anwendung 1 Anwendung 2 JMS-Consumer Connection zum Provider JMS-Interfaces Connection zum Provider JMS-Interfaces Session JBOSS MQ Protokoll? Session Websphere MQ Weiterer (mittlerweile) OASIS-Standard - Advanced Message Queuing Protocol (AMQP) der AMQP-Working- Group als Protokollstandard für Message-Queuing-Systeme ( Stand: September 2013) Seite: 29

30 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 Seite: 30

31 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? Seite: 31

32 Überblick 1. Grundlagen zum Message Passing 2. Fallstudie JMS 3. Cloud-Ansätze Seite: 32

33 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) Seite: 33

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: (letzter Zugriff am ) Seite: 34

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 Seite: 35

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 Seite: 36

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 Seite: 37

38 Amazon SQS: Eigene Benchmarks (1) Eigene Benchmarks wurden durchgeführt Resümee: Noch Vorsicht bei großer Last! 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 Rechner B - Server Betriebssystem RAM (GB) CPU Internet Windows 7 8 GB Intel i5 3,3 GHz Ethernet: Telekom V-DSL 50 Quelle: Simon Effenberg: Studienarbeit: Amazon Simple Queue Service Benchmark, Wintersemester 12/13, Hochschule München Seite: 38

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 Seite: 39

40 Amazon SQS: Eigene Benchmarks (3) Kommunikationsszenario Quelle: Simon Effenberg: Studienarbeit: Amazon Simple Queue Service Benchmark, Wintersemester 12/13, Hochschule München Prof. Dr. Peter Mandl Verteilte Systeme Seite: 40

41 Amazon SQS: Eigene Benchmarks (4): Variation der Anzahl Clients Quelle: Simon Effenberg: Studienarbeit: Amazon Simple Queue Service Benchmark, Wintersemester 12/13, Hochschule München Prof. Dr. Peter Mandl Verteilte Systeme Seite: 41

42 Amazon SQS: Eigene Benchmarks (5): Variation der Nachrichtenlänge Quelle: Simon Effenberg: Studienarbeit: Amazon Simple Queue Service Benchmark, Wintersemester 12/13, Hochschule München Prof. Dr. Peter Mandl Verteilte Systeme Seite: 42

43 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) (+1024 KB je Anhang) Maximale Lebensdauer der Nachrichten (in Tagen) Zustellungssemantik At-Least-Once At-Least-Once Exactly-Once Kommunikation (APIs) - SDK s - REST - SDK s - REST Garantiertes FIFO Nein Nein Ja Nachrichtenformat Stand: 12/12 Textbasiert - SDK s Seite: 43

44 Zusammenfassung Grundlagen zum Message Passing Fallstudie JMS Cloud-Ansätze Fragen? Seite: 44