Dynamische Bandbreitenbeschränkungen
Funktion und Architektur
Motivation
- Transfervolumen 3000 GByte/Monat (jetzt 6000)
- jährlich 550.000 DM
- nächste Kategorie 200.000 DM teurer
- bei Überschreitung Mahnungen und Bandbreitenbeschränkung
- Idee: Traffic-Limit für Nutzer
- bei Überschreitung erst Verwarnung, dann Sperrung
- Probleme bei notwendigen größeren Datenmengen
- Ausnutzung des Limits bei Ablauf der Gültigkeitsfrist
- "unfreundlicher Akt" und Beschneidung der persönlichen Freiheit
- Ausweg: "schleichende Abschaltung" des Netzzuganges
Prinzipielle Funktionsweise
- Nutzer nach Trafficmenge in Klassen eingeteilt
- mehr Traffic -> schlechtere Klasse mit weniger Bandbreite
- schrittweise wieder besserer Klasse zugewiesen
- Vorteil: geringerer Verwaltungsaufwand
- keine Verwarnungen/Sperrungen mehr
- Parameter der Klassen über Webinterface einstellbar
- automatische Regelung der Bandbreiten
- Ausnahmeregelungen: WWW- und FTP-Server der TU, News
- Webinterface für Nutzer
- E-Mail bei Einordnung in schlechtere Klasse
Verwendete Technologien
Quality of Service
- Quality of Service (QoS)
- Unterscheidung von verschiedenen Verkehrsklassen und Services sowie deren unterschiedliche Behandlung
Quality- bestimmte qualitative Parameter eingehalten bzw. garantiert
- verlässliche Datenlieferung
- garantierte Bandbreiten
- minimale Verzögerung
- bevorzugte Behandlung von Management-Daten
Service- verschiedene Arten von Anwendungen bzw. Protokollen: Classes of Service (CoS)
- E-Mail, WWW, Chat
- TCP, IP, IPX
- Klassifikation anhand Protokoll, Quell-/Zieladresse, Port
Warum XML-RPC?
- Remote-Procedure-Call-Protokoll
- Übertragungsprotokoll HTTP, Payload XML
- einfach zu verstehen und einfach zu implementieren
- Sprachunabhängigkeit
- strukturierte Daten (einfache Datentypen + Felder und Tupel)
- Daten zentral verwaltbar
- Programme verteilbar
Einsatz im CSN
Auswertung des Datenmaterials
- Januar bis März 2001, 1561 Rechner
Einordnung in eine Klasse
| Klasse | Ab Menge | Bandbreite | Tage | Begrenzung | Sofort |
|---|
| 1 | 50 MByte/Tag | 20 MBit/s | 2 | - | - |
| 2 | 100 MByte/Tag | 10 MBit/s | 5 | X | - |
| 3 | 200 MByte/Tag | 4 MBit/s | 7 | X | - |
| 4 | 300 MByte/Tag | 500 KBit/s | 10 | X | - |
| 5 | 500 MByte/Tag | 100 KBit/s | 14 | X | X |
- erstmaliges Überschreiten: Einordnung in entsprechende Klasse n
- weitere Überschreitungen (während in einer Klasse): Einordnung in Klasse n+1
- relativ faire Aufteilung
Test 1: Benutzung der vorhandenen Daten
- verwendete alte Daten
- keine Begrenzungsregeln aktiv
- Verhalten des Systems bei realen Daten
- keine Auswirkungen auf erzeugten Traffic
- keine Voraussagen über verändertes Nutzerverhalten
- Bandbreite pro Nutzer in Klasse 5: 19 KBit/s (26 Nutzer)
- Summe des erzeugbaren Traffics: 67 GByte/Tag
- Bearbeitungszeit: ca. 20s pro ausgewertetem Tag
Test 1: Anzahl der Nutzer in den Klassen
Test 2: Test auf dem CSN-Server
- ohne aktive Begrenzung
- Verhalten des Systems unter realen Bedingungen
- Werte deutlich unter denen von Test 1 (Semesterferien)
- Bandbreiten bis zum Maximum nach oben korrigiert
- Monatstraffic: 572 GByte
- durch Einsatz des DynShapers Netz evtl. besser genutzt
Aktueller Einsatz
- seit August 2001 Testbetrieb, zufriedenstellend
- ab 03.09.2001 zeitweise mit aktiven Begrenzungsregeln
- ab 23.10.2001 offizieller Testbetrieb
- Wegfall der 250MByte-Limits
- Behebung einiger Bugs & Features
- Traffic Uni-CSN zu 50% eingerechnet (Tunneling)
- wieder aufgehoben, da Behinderung zu groß
Geplant für die nähere Zukunft
- gleitende Zählung (letzte 14 Tage) -> Peaks geglättet
- Klasseneinordnung jeden Tag neu
- keine Verweildauer
- Einordnung nicht nach Klassenlimits
- Nutzer prozentual in Klassen eingeteilt
- reines Regelsystem
- Misstrauen -> Open Source
- Renaming von "Klasse" in "Gruppe"
- Klasse 0 wird Gruppe 1 etc.
- evtl. Gruppe gar nicht mehr aufführen
- bessere Akzeptanz?
Vielen Dank für Ihre Aufmerksamkeit :-)
