Realisierung verteilter Anwendungen: Teil 11
Beim vorigen Mal: Bezahlung im Internet
Inhalt 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 Video
server Digital TV/radio
server Video camera
and mike
Local network Local network
Multimediasysteme: Charakteristiken
Generierung und Konsumierung von kontinuierlichen Datenströmen in Realzeit
Große Menge von Audio-, Video-, und anderen zeitbasierten Datenelementen
Zeitlich rechtzeitige Anlieferung von
Datenelementen (audio samples and video frames) und deren zeitgerechte Verarbeitung ist essentiell
Zu spät ankommende Datenelemente sind wertlos
Spezifikation/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 werden
Multimediasysteme
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äten
Offenheit (open distributed multimedia system)
Anwendungen können ohne vorherige Übereinkünfte gestartet werden
Dienste werden dynamisch in Anspruch genommen
Aushandlung von QoS-Garantien
Anforderungen
Kurze Latenzzeiten zur Gewährleistung der Interaktivität
Synchronisation verschiedener Medien
Externe Synchronisation (z.B. mit
Darstellungsgeräten)
Heute: Best-Effort-Prinzip
Web-basierte Multimedia-Anwendungen
Telefonkonferenzen
Video-on-Demand-Dienste
Das Fenster der Knappheit für Berechnungs- und Kommunikationsressourcen
1980 1990
remote login network file access high-quality audio
interactive video
insufficient
resources scarce resources
abundant resources
2000
Charakteristiken von typischen Multimediaströmen
Data rate
(approximate) Sample or frame size frequency
Telephone speech 64 kbps 8 bits 8000/sec
CD-quality sound 1.4 Mbps 16 bits 44,000/sec Standard TV video
(uncompressed) 120 Mbps up to 640 x 480
pixels 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 1080
pixels 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 Codec D
B
Mixer
PC/workstation PC/workstation
C Video
store Network
connections K
L
M
: multimedia stream Codec
A G
Codec
H Window 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 video
640x480x16 bits Zero
A Codec In:
Out:
10 frames/sec, raw video MPEG-1 stream
Interactive Low 10 ms CPU each 100 ms;
10 Mbytes RAM
B Mixer In:
Out:
2 44 kbps audio 1 44 kbps audio
Interactive Very low 1 ms CPU each 100 ms;
1 Mbytes RAM H Window
system In:
Out:
various
50 frame/sec framebuffer
Interactive Low 5 ms CPU each 100 ms;
5 Mbytes RAM K Network
connection In/Out: MPEG-1 stream, approx.
1.5 Mbps Interactive Low 1.5 Mbps, low-loss stream protocol L Network
connection In/Out: Audio 44 kbps Interactive Very low 44 kbps, very low-loss stream 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 requirements against 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 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:
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-Angaben
Aber: Interaktion der Parameter
Zwei angeben, den dritten optimieren lassen
Bei Verzweigungen (multiple Ziele) können Worst- Case-Werte zurückübermittelt werden
In diesem Fall: besser Empfänger-initiiertes
QoS-Management
Zugriffskontrolle
Reservierung von Bandbreiten
Aggregierung von Max-Bandbreiten führt zu Verschwendung von Ressourcen
Statistisches 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äten
Fair scheduling
Real-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
Source
Targets High bandwidth
Medium bandwidth Low 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 clients
Start/Stop
requests from clients low-bandwidth network
high-bandwidth
0 n+1 1 n+2 2 n+3 3 n+4 n 2n+1
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 verteilt
Spiegelung (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
0 1
2
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 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 1994
5 133MHz Pentium PCs
je 48 Mbytes RAM
je 2 Bbytes SCSI Laufwerke
ATM Controller, Windows NT
68 Kunden perfekt
0.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
Maybe
At-least-once
At-most-once
Exactly-once
Fehlerfreier
Ablauf 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
