Realisierung verteilter Anwendungen: Teil 11 zBeim vorigen Mal: Bezahlung im Internet zInhalt heute yVerteilte Multimediasysteme yQuality of Service (QoS) Prinzipien zLernziele: yKennenlernen von Dienstleistungen (in verteilten Systemen), die bestimmte Anforderungen erfüllen müssen yFallstudie: Architektur eines Multimediaservers Ralf Möller, FH-Wedel

Literatur Kapitel 15 aus: Die Graphiken dieser Vorlesung sind aus diesem Buch entnommen

Ein verteiltes Multimediasystem

Multimediasysteme: Charakteristiken zGenerierung und Konsumierung von kontinuierlichen Datenströmen in Realzeit zGroße Menge von Audio-, Video-, und anderen zeitbasierten Datenelementen zZeitlich rechtzeitige Anlieferung von Datenelementen (audio samples and video frames) und deren zeitgerechte Verarbeitung ist essentiell zZu spät ankommende Datenelemente sind wertlos zSpezifikation/Aushandlung der notwendigen Dienstleistungsqualität (QoS)

Realzeitsysteme: Vergleich der Charakteristiken zFlugüberwachung, Herstellungsprozesse, Telekommunikation yKleine Datenmengen, harte Anforderungen (deadlines) yWorst-Case-Anforderungen müssen eingehalten werden zMultimediasysteme yGroße Datenmengen, starke Verteilung yweichere Anforderungen ydynamische Anforderungen an Ressourcen yQuality of Service-Spezifikation (QoS)

QoS-Management-Systeme zVerwaltung der Berechnungs- und Kommunikationsressourcen und deren Zuweisung z"Ressourcenbandbreite" yNetzwerkbandbreite, Speicherbandbreite, Prozessorzyklen, Speicher/Pufferkapazitäten zOffenheit (open distributed multimedia system) yAnwendungen können ohne vorherige Übereinkünfte gestartet werden yDienste werden dynamisch in Anspruch genommen zAushandlung von QoS-Garantien

Anforderungen zKurze Latenzzeiten zur Gewährleistung der Interaktivität zSynchronisation verschiedener Medien zExterne Synchronisation (z.B. mit Darstellungsgeräten)

Heute: Best-Effort-Prinzip zWeb-basierte Multimedia-Anwendungen zTelefonkonferenzen zVideo-on-Demand-Dienste

Das Fenster der Knappheit für Berechnungs- und Kommunikationsressourcen

Charakteristiken von typischen Multimediaströmen Data rate (approximate) Sample or frame size frequency Telephone speech64 kbps8 bits8000/sec CD-quality sound1.4 Mbps16 bits44,000/sec Standard TV video (uncompressed) 120 Mbpsup to 640x 480 pixelsx 16 bits 24/sec Standard TV video (MPEG-1 compressed) 1.5 Mbpsvariable24/sec HDTV video (uncompressed) 1000–3000 Mbpsup to 1920x 1080 pixelsx 24 bits 24–60/sec HDTV video (MPEG-2 compressed) 10–30 Mbpsvariable24–60/sec

Typische Komponenten in Multimedia-Infrastrukturen

QoS-Spezifikationen für Komponenten ComponentBandwidthLatencyLoss rateResources required Camera Out:10 frames/sec, raw video 640x480x16 bits Zero ACodecIn: Out: 10 frames/sec, raw video MPEG-1 stream InteractiveLow10 ms CPU each 100 ms; 10 Mbytes RAM BMixerIn: Out: 2 44 kbps audio 1 44 kbps audio InteractiveVery low1 ms CPU each 100 ms; 1 Mbytes RAM HWindow system In: Out: various 50 frame/sec framebuffer InteractiveLow5 ms CPU each 100 ms; 5 Mbytes RAM KNetwork connection In/Out:MPEG-1 stream, approx. 1.5 Mbps InteractiveLow1.5 Mbps, low-loss stream protocol LNetwork connection In/Out:Audio 44 kbpsInteractiveVery low44 kbps, very low-loss stream protocol

Quality of Service-Manager zQoS-Verhandlung (negotiation) yBandbreite yLatenzangabe (Jitter, erste Ableitung) yVerlustrate (z.B. 1%) xweniger bedeutsam: Bitfehler xwichtiger: Pufferüberlauf, zu spätes Eintreffen yNotwendige Ressourcen (z.B. CPU) zQoS-Zutritts/Zugriffskontrolle (admission control)

Die Aufgabe eines QoS-Managers

Angabe von QoS-Parametern zBandbreite y"Spitzen" / Traffic Patterns xBeispiel : 3 Ströme mit 1Mbps: Strom mit 1Mbit-Frame jede Sekunde Strom mit computergenerierten Animationen asynchron mit 1Mbps Strom mit 100-bit Sound-Sample jede Mikrosekunde yBurstiness: xMaximale Zahl der Medienelemente die zu früh kommen dürfen xMaximalzahl von Nachrichten in einem Zeitintervall t: P= Rt + B R = Frame Rate, B = Große der Spitze (Burst) zLatenz zVerlustrate

Traffic Shaping-Algorithmen zVerwendung von Puffern, um "Spitzen" abzumildern zToken Bucket: maximal Rt + B Daten im System

Die RFC 1363 Flußspezifikation Protocol version Maximum transmission unit Token bucket rate Token bucket size Maximum transmission rate Minimum delay noticed Maximum delay variation Loss sensitivity Burst loss sensitivity Loss interval Quality of guarantee Bandwidth: Delay: Loss: zSammlung von QoS-Parametern

Verhandlungsprozeduren: Sender-initiiert (1) zEinfacher Ansatz: yVerfolge den Fluß der Daten durchs Netz (den Verlauf des Stromes) von der Quelle zum Ziel yVersendung von Flußspezifikationen von Zwischenknoten zu Zwischenknoten yJeder Zwischenknoten prüft lokal, ob die Anforderungen erfüllt werden können... y... und reicht die Anfrage dann weiter yAm Schluß wird das Ergebnis vom Ziel- zum Startknoten zurückübermittelt

Verhandlungsprozeduren: Sender-initiiert (2) zStatt Absolutwerte lieber Min/Max-Angaben zAber: Interaktion der Parameter yZwei angeben, den dritten optimieren lassen zBei Verzweigungen (multiple Ziele) können Worst- Case-Werte zurückübermittelt werden zIn diesem Fall: besser Empfänger-initiiertes QoS-Management

Zugriffskontrolle zReservierung von Bandbreiten yAggregierung von Max-Bandbreiten führt zu Verschwendung von Ressourcen zStatistisches Multiplexing mit "Überbuchung" yGarantien nur mit einer bestimmten Wahrscheinlichkeit gültig yBasiert auf der Annahme, daß nicht alle Teilnehmer ihre Maximalangaben zur gleichen Zeit abfordern

Ressourcenmanagement zPrioritäten zFair scheduling zReal-time scheduling

Stromadaption zSkalierung yKernidee: Wenn im Netz ein Flaschenhals entsteht, wird an der Quelle der "Zustrom" herabgesetzt yEs werden z.B. weniger Frames eingespeist yMeist angewendet, wenn Daten direkt generiert werden ySchwieriger beim "Abspielen" gespeicherter Multimediadaten (Dekodierung, Aufbereitung und Neukodierung notwendig)

Skalierung zTemporale Skalierung (Abtastung) zRäumliche Skalierung (Subsampling) zFrequenzskalierung (Qualitätsminderung bei der Kompression) zFarbraumskalierung

Filterung Source Targets High bandwidth Medium bandwidth Low bandwidth zSkalierung in Zwischenknoten zKodierung von Information in Unterströmen

Realisierung von Systemen mit QoS-Anforderungen zWas muß man bei der Konstruktion beachten? zWie kann man z.B. Fehlertoleranz bzw. niedrige Verlustraten erzielen?

Eine Fallstudie: Der Video-Fileserver "Tiger" zVideo-on-Demand für eine große Zahl von Kunden yGroße Bibliotek (aber: vermutlich neue Filme sehr populär) yErste Frames in wenigen Sekunden yOperationen: Pause, Schnelles Vor- und Zurückspulen zQoS: konstante Rate, minimale Puffergröße bei Kunden, sehr kleine Verlustrate zVerteiltheit und Skalierbarkeit (bis zu Kunden) zLow-cost-Hardware zFehlertoleranz bei Ausfall einzelner Server bzw. Disks

Die Hardwarekonfiguration des "Tiger" Video-Fileservers Controller Cub 0Cub 1Cub 2Cub 3Cub n ATM switching network video distribution to clients Start/Stop requests from clients low-bandwidth network high-bandwidth 0n+11n+2 2 n+3n+4n2n+13

Speicherorganisation zVerteilung der Videodaten über die Laufwerke, die den einzelnen Servern (cubs) zugeordnet sind zStriping (daher wohl der Name: Tiger) yFilm wird in Blöcke eingeteilt (ca. 1 sec mit 1.5 Mbyte) yBlöcke (ca pro Film) werden auf Laufwerke im Round-Robin-Verfahren verteilt zSpiegelung (mirroring) yAufteilung eines Blocks in mehrere Portionen (Doubletten, secondaries), die redundant gespeichert werden

Speicherorganisation zd = Anzahl der Partitionen pro Block (ca. 4-8) zPartitionen für Block auf Laufwerk i auf Laufwerk i+1 bis i+d zMit einem Partitionierungsfaktor von 8 steht ungefähr 7/8 der Kapazität und Bandbreite im fehlerfreien Fall zur Verfügung zDie restlichen 1/8 der Leistung reichen im Fehlerfall zBei Ausfall eines Servers/Laufwerks geht ggf. ein Block verloren (für jeden Film), dann übernehmen andere Server/Laufwerke die Arbeit

Ablaufplanung zPlanung der Aufgaben der Einzelstationen zPlan ist in Slots aufgeteilt zJeder Slot beschreibt die Arbeit, die für einen Block eines Films notwendig ist (vom Laufwerk bis zum ATM- Netzwerk) zInformation pro Slot (viewer state) yAdresse des Kundencomputers yIdentität der abgespielten Datei yPosition in der Datei (der nächste Block) yPlay sequence number (zur Berechnung der Lieferzeit) yBuchführungsinformation

Ablaufplanung zBlockabspielzeit T (Zeit für's Anzeigen eines Blocks beim Kunden, ca. 1 sec) yT muß eingehalten werden, mit geringer Abweichung zAufgaben pro Block yLesen des Blocks vom Laufwerk in den Speicher yEinpacken des Blocks und Zuführung zum ATM-Controller yAktualisierung des "viewer state" yWeiterleitung des aktualisierten Slots an den nächsten Server (cub) zAktion darf höchstens einen best. Zeitraum dauern (Blockbedienzeit t) zBlockbedienzeit substantiell kleiner als Blockabspielzeit yT/t > 4 für ein Laufwerk, 5 Server mit je 3 Laufwerke -> 70 Ströme

Ablaufplanung 012 slot 0 viewer 4 slot 1 free slot 2 free slot 3 viewer 0 slot 4 viewer 3 slot 5 viewer 2 slot 6 free slot 7 viewer 1 block play time T block service time t state

Fehlertoleranz zGegeben durch Spiegelung und der damit verbundenen redundanten Speicherung

Netzwerkunterstützung zQoS für ATMs ySequenzeinhaltung der gesendeten Pakete zKundenrechner brauchen Puffer für zwei Blöcke

Performanz und Skalierbarkeit zUrsprüngliche Konfiguration 1994 z5 133MHz Pentium PCs zje 48 Mbytes RAM zje 2 Bbytes SCSI Laufwerke zATM Controller, Windows NT z68 Kunden perfekt z0.02% Verlustrate bei Ausfall eines Servers (cubs)

QoS-Angaben bei der verteilten OOP? zVerlust der Auftragsnachricht (1) zVerlust der Ergebnisnachricht (2) zAusfall des Servers (3) zAusfall des Klienten (4) Klient Server (1)(2) (4) (3)

Fehlerbehebung und Probleme zClient wartet und versucht... z... nach Timeout ein erneutes Senden, zkann aber nicht zwischen verschiedenen Fehlersituationen unterscheiden. zErneutes Senden führt zur erneuten Ausführung. zClient antizipiert eventuell neuen Zustand nicht. Transaktionskonzept erforderlich (teuer!) Festlegung von Dienstgüte-Kriterien

Fehlerbehandlungsstrategien zMaybe zAt-least-once zAt-most-once zExactly-once Fehlerfreier Ablauf Nachrichten- verluste Server- ausfall A: 1 E: 1 A: 0/1 E: 0/1 A: ≥ 1 E: ≥ 1 A: 1 E: 1 A: 0/1 E: 0/1 A: ≥ 0 E: ≥ 0 A: 0/1 E: 0/1 A: 1 E: 1 A: Ausführung, E: Ergebnis

Zusammenfassung: Multimediasysteme zRessourcen-Management zQoS-Management, Verhandlung, Zugriffkontrolle zPlanung über den Einsatz der Ressourcen zPufferung zur Vermeidung von Leistungsspitzen (Traffic Shaping) zFallstudie: Video-Fileserver Tiger

Beim nächsten Mal... zServices als neue Abstraktion in verteilten Systemen zSOAP, WSDL, UDDI zDAML-S, OWL-S