Realisierung verteilter Anwendungen: Teil 11 zBeim vorigen Mal: Bezahlung im Internet zInhalt heute...

Realisierung verteilter Anwendungen: Teil 11

Beim vorigen Mal: Bezahlung im InternetInhalt heute

Verteilte Multimediasysteme Quality of Service (QoS) Prinzipien

Lernziele: Kennenlernen von Dienstleistungen (in verteilten

Systemen), die bestimmte Anforderungen erfüllen müssen

Fallstudie: Architektur eines Multimediaservers

Ralf Möller, FH-Wedel

Literatur

Kapitel 15 aus:

Die Graphiken dieser Vorlesung sind aus diesem Buch entnommen

Ein verteiltes Multimediasystem

Wide area gateway Videoserver

DigitalTV/radioserver

Video cameraand mike

Local network Local network

Multimediasysteme: CharakteristikenGenerierung und Konsumierung von

kontinuierlichen Datenströmen in RealzeitGroße Menge von Audio-, Video-, und anderen

zeitbasierten DatenelementenZeitlich rechtzeitige Anlieferung von

Datenelementen (audio samples and video frames) und deren zeitgerechte Verarbeitung ist essentiell

Zu spät ankommende Datenelemente sind wertlosSpezifikation/Aushandlung der notwendigen

Dienstleistungsqualität (QoS)

Realzeitsysteme: Vergleich der Charakteristiken

Flugüberwachung, Herstellungsprozesse, Telekommunikation Kleine Datenmengen,

harte Anforderungen (deadlines) Worst-Case-Anforderungen müssen eingehalten

werdenMultimediasysteme

Große Datenmengen, starke Verteilung weichere Anforderungen dynamische Anforderungen an Ressourcen Quality of Service-Spezifikation (QoS)

QoS-Management-Systeme

Verwaltung der Berechnungs- und Kommunikationsressourcen und deren Zuweisung

"Ressourcenbandbreite" Netzwerkbandbreite, Speicherbandbreite,

Prozessorzyklen, Speicher/PufferkapazitätenOffenheit (open distributed multimedia system)

Anwendungen können ohne vorherige Übereinkünfte gestartet werden

Dienste werden dynamisch in Anspruch genommenAushandlung von QoS-Garantien

Anforderungen

Kurze Latenzzeiten zur Gewährleistung der Interaktivität

Synchronisation verschiedener MedienExterne Synchronisation (z.B. mit

Darstellungsgeräten)

Heute: Best-Effort-Prinzip

Web-basierte Multimedia-AnwendungenTelefonkonferenzenVideo-on-Demand-Dienste

Das Fenster der Knappheit für Berechnungs- und Kommunikationsressourcen

1980 1990

remotelogin

networkfile access

high-qualityaudio

interactivevideo

insufficientresources

scarceresources

abundantresources

2000

Charakteristiken von typischen Multimediaströmen

Data rate(approximate)

Sample or frame size frequency

Telephone speech 64 kbps 8 bits 8000/secCD-quality sound 1.4 Mbps 16 bits 44,000/secStandard TV video(uncompressed)

120 Mbps up to 640 x 480pixels x 16 bits

24/sec

Standard TV video (MPEG-1 compressed)

1.5 Mbps variable 24/sec

HDTV video(uncompressed)

1000–3000 Mbps up to 1920 x 1080pixels x 24 bits

24–60/sec

HDTV video(MPEG-2 compressed)

10–30 Mbps variable 24–60/sec

Typische Komponenten in Multimedia-Infrastrukturen

Microphones

Camera

Screen

Window system

CodecD

BMixer

PC/workstation PC/workstation

C Videostore

Networkconnections

K

L

M

: multimedia stream

CodecA G

Codec

HWindow system

White boxes represent media processing components, many of which are implemented in software, including:codec: coding/decoding filter

mixer: sound-mixing component

Video file system

QoS-Spezifikationen für Komponenten

Component Bandwidth Latency Loss rate Resources required

Camera Out: 10 frames/sec, raw video640x480x16 bits

Zero

A Codec In:Out:

10 frames/sec, raw videoMPEG-1 stream

Interactive Low 10 ms CPU each 100 ms;10 Mbytes RAM

B Mixer In:Out:

2 44 kbps audio1 44 kbps audio

Interactive Very low 1 ms CPU each 100 ms;1 Mbytes RAM

H Windowsystem

In:Out:

various50 frame/sec framebuffer

Interactive Low 5 ms CPU each 100 ms; 5 Mbytes RAM

K Networkconnection

In/Out: MPEG-1 stream, approx.1.5 Mbps

Interactive Low 1.5 Mbps, low-lossstream protocol

L Networkconnection

In/Out: Audio 44 kbps Interactive Very low 44 kbps, very low-lossstream protocol

Quality of Service-Manager

QoS-Verhandlung (negotiation) Bandbreite Latenzangabe (Jitter, erste Ableitung) Verlustrate (z.B. 1%)

weniger bedeutsam: Bitfehler wichtiger: Pufferüberlauf, zu spätes Eintreffen

Notwendige Ressourcen (z.B. CPU)QoS-Zutritts/Zugriffskontrolle (admission

control)

Die Aufgabe eines QoS-Managers

Application components specify their QoS requirements to QoS manager

Yes No

Yes No

Flow spec.

Resource contract

Admission control QoS negotiation

QoS manager evaluates new requirementsagainst the available resources.

Sufficient?

Reserve the requested resources

Allow application to proceed

Application runs with resources as per resource contract

Negotiate reduced resource provision with application.Agreement?

Do not allow application to proceed

Application notifies QoS manager of increased resource requirements

Angabe von QoS-Parametern Bandbreite

"Spitzen" / Traffic Patterns Beispiel : 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

Burstiness: Maximale Zahl der Medienelemente die zu früh kommen dürfen Maximalzahl von Nachrichten in einem Zeitintervall t: P= Rt + B

R = Frame Rate, B = Große der Spitze (Burst) Latenz Verlustrate

Traffic Shaping-Algorithmen

Token generator

(a) Leaky bucket (b) Token bucket

Verwendung von Puffern, um "Spitzen" abzumildern

Token Bucket: maximal Rt + B Daten im System

Die RFC 1363 Flußspezifikation

Protocol versionMaximum transmission unit

Token bucket rateToken bucket size

Maximum transmission rateMinimum delay noticed

Maximum delay variationLoss sensitivity

Burst loss sensitivityLoss interval

Quality of guarantee

Bandwidth:

Delay:

Loss:

Sammlung von QoS-Parametern

Verhandlungsprozeduren: Sender-initiiert (1)

Einfacher Ansatz: Verfolge den Fluß der Daten durchs Netz (den

Verlauf des Stromes) von der Quelle zum Ziel Versendung von Flußspezifikationen von

Zwischenknoten zu Zwischenknoten Jeder Zwischenknoten prüft lokal, ob die

Anforderungen erfüllt werden können ... ... und reicht die Anfrage dann weiter Am Schluß wird das Ergebnis vom Ziel- zum

Startknoten zurückübermittelt

Verhandlungsprozeduren: Sender-initiiert (2)

Statt Absolutwerte lieber Min/Max-AngabenAber: Interaktion der Parameter

Zwei angeben, den dritten optimieren lassenBei Verzweigungen (multiple Ziele) können

Worst-Case-Werte zurückübermittelt werdenIn diesem Fall: besser Empfänger-initiiertes

QoS-Management

Zugriffskontrolle

Reservierung von Bandbreiten Aggregierung von Max-Bandbreiten führt zu

Verschwendung von RessourcenStatistisches Multiplexing mit "Überbuchung"

Garantien nur mit einer bestimmten Wahrscheinlichkeit gültig

Basiert auf der Annahme, daß nicht alle Teilnehmer ihre Maximalangaben zur gleichen Zeit abfordern

Ressourcenmanagement

PrioritätenFair schedulingReal-time scheduling

Stromadaption

Skalierung Kernidee: Wenn im Netz ein Flaschenhals entsteht,

wird an der Quelle der "Zustrom" herabgesetzt Es werden z.B. weniger Frames eingespeist Meist angewendet, wenn Daten direkt generiert

werden Schwieriger beim "Abspielen" gespeicherter

Multimediadaten (Dekodierung, Aufbereitung und Neukodierung notwendig)

Skalierung

Temporale Skalierung (Abtastung)Räumliche Skalierung (Subsampling)Frequenzskalierung (Qualitätsminderung bei

der Kompression)Farbraumskalierung

Filterung

SourceTargets

High bandwidth

Medium bandwidthLow bandwidth

Skalierung in Zwischenknoten

Kodierung von Information in Unterströmen

Realisierung von Systemen mit QoS-Anforderungen

Was muß man bei der Konstruktion beachten?Wie kann man z.B. Fehlertoleranz bzw.

niedrige Verlustraten erzielen?

Eine Fallstudie: Der Video-Fileserver "Tiger"

Video-on-Demand für eine große Zahl von Kunden Große Bibliotek (aber: vermutlich neue Filme sehr populär) Erste Frames in wenigen Sekunden Operationen: Pause, Schnelles Vor- und Zurückspulen

QoS: konstante Rate, minimale Puffergröße bei Kunden, sehr kleine Verlustrate

Verteiltheit und Skalierbarkeit (bis zu 10000 Kunden)

Low-cost-Hardware Fehlertoleranz bei Ausfall einzelner Server bzw.

Disks

Die Hardwarekonfiguration des "Tiger" Video-Fileservers

Controller

Cub 0 Cub 1 Cub 2 Cub 3 Cub n

ATM switching network

video distribution to clientsStart/Stop

requests from clients

low-bandwidth network

high-bandwidth

0 n+1 1 n+2 2 n+3 n+4 n 2n+13

Speicherorganisation

Verteilung der Videodaten über die Laufwerke, die den einzelnen Servern (cubs) zugeordnet sind

Striping (daher wohl der Name: Tiger) Film wird in Blöcke eingeteilt (ca. 1 sec mit 1.5 Mbyte) Blöcke (ca. 7000 pro Film) werden auf Laufwerke im

Round-Robin-Verfahren verteiltSpiegelung (mirroring)

Aufteilung eines Blocks in mehrere Portionen (Doubletten, secondaries), die redundant gespeichert werden

Speicherorganisation

d = Anzahl der Partitionen pro Block (ca. 4-8) Partitionen für Block auf Laufwerk i auf Laufwerk i+1

bis i+d Mit einem Partitionierungsfaktor von 8 steht ungefähr

7/8 der Kapazität und Bandbreite im fehlerfreien Fall zur Verfügung

Die restlichen 1/8 der Leistung reichen im Fehlerfall Bei Ausfall eines Servers/Laufwerks geht ggf. ein

Block verloren (für jeden Film), dann übernehmen andere Server/Laufwerke die Arbeit

Ablaufplanung Planung der Aufgaben der Einzelstationen Plan ist in Slots aufgeteilt Jeder Slot beschreibt die Arbeit, die für einen Block

eines Films notwendig ist (vom Laufwerk bis zum ATM-Netzwerk)

Information pro Slot (viewer state) Adresse des Kundencomputers Identität der abgespielten Datei Position in der Datei (der nächste Block) Play sequence number (zur Berechnung der Lieferzeit) Buchführungsinformation

Ablaufplanung Blockabspielzeit T (Zeit für's Anzeigen eines Blocks beim

Kunden, ca. 1 sec) T muß eingehalten werden, mit geringer Abweichung

Aufgaben pro Block Lesen des Blocks vom Laufwerk in den Speicher Einpacken des Blocks und Zuführung zum ATM-Controller Aktualisierung des "viewer state" Weiterleitung des aktualisierten Slots an den nächsten Server (cub)

Aktion darf höchstens einen best. Zeitraum dauern (Blockbedienzeit t)

Blockbedienzeit substantiell kleiner als Blockabspielzeit T/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 Tblock service

time t

state state state state state

Fehlertoleranz

Gegeben durch Spiegelung und der damit verbundenen redundanten Speicherung

Netzwerkunterstützung

QoS für ATMs Sequenzeinhaltung der gesendeten Pakete

Kundenrechner brauchen Puffer für zwei Blöcke

Performanz und Skalierbarkeit

Ursprüngliche Konfiguration 19945 133MHz Pentium PCsje 48 Mbytes RAMje 2 Bbytes SCSI LaufwerkeATM Controller, Windows NT68 Kunden perfekt0.02% Verlustrate bei Ausfall eines Servers

(cubs)

QoS-Angaben bei der verteilten OOP?

Verlust der Auftragsnachricht (1)Verlust der Ergebnisnachricht (2)Ausfall des Servers (3)Ausfall des Klienten (4)

Klient

Server

(1) (2)

(4)

(3)

Fehlerbehebung und Probleme

Client wartet und versucht...... nach Timeout ein erneutes Senden,kann aber nicht zwischen verschiedenen

Fehlersituationen unterscheiden.Erneutes Senden führt zur erneuten Ausführung.Client antizipiert eventuell neuen Zustand nicht.

Transaktionskonzept erforderlich (teuer!)

Festlegung von Dienstgüte-Kriterien

Fehlerbehandlungsstrategien

MaybeAt-least-onceAt-most-onceExactly-once

FehlerfreierAblauf

Nachrichten-verluste

Server-ausfall

A: 1 E: 1

A: 1 E: 1

A: 1 E: 1

A: 1 E: 1

A: 0/1 E: 0/1

A: ≥ 1 E: ≥ 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

Ressourcen-Management QoS-Management, Verhandlung,

Zugriffkontrolle Planung über den Einsatz der Ressourcen Pufferung zur Vermeidung von

Leistungsspitzen (Traffic Shaping) Fallstudie: Video-Fileserver Tiger

Beim nächsten Mal...

Services als neue Abstraktion in verteilten Systemen

SOAP, WSDL, UDDIDAML-S, OWL-S