Upload
marta-lorenz
View
216
Download
0
Embed Size (px)
Citation preview
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