Aktuelle Entwicklungen des DynShapers


Bisheriges System

Motivation

Mit Einführung des neuen Tarifierungsmodells beim Deutschen Forschungsnetz (DFN) erfolgte eine mengenmäßige Erfassung und Einschränkung des verursachten Datenvolumens der am DFN angeschlossenen Einrichtungen. Der TU Chemnitz wurde beispielsweise eine Datenmenge von 3000 GByte pro Monat zugestanden (mittlerweile sind es 6000 GByte), wofür jährlich 550.000 DM entrichtet werden mussten. Die nächste Kategorie wäre um 200.000 DM teurer gewesen, hätte aber außerdem mit dem Zweck für Forschung und Lehre begründet werden müssen. Bei einer Überschreitung der monatlichen Grenze hätte die TU mit Mahnungen und letztendlich einer Bandbreitenbeschränkung rechnen müssen.

Der erste Ansatz war nun, dieses "Traffic-Limit" auf die Nutzer des Chemnitzer Studentennetzes (CSN) umzulegen, die einen nicht unerheblichen Teil des monatlichen Gesamtvolumens der von der TU verursachten Datenmenge ausmachen. Der tägliche Traffic wurde gemessen, bei einer Überschreitung der festgelegten Grenze von 250 MByte/Tag wurde der Nutzer erst verwarnt und im Wiederholungsfall für 2 Wochen gesperrt.

Probleme gab es dabei, wenn man doch einmal eine größere Datenmenge benötigte. Ein weiteres Problem war die Ausnutzung des Limits bei Ablauf der Gültigkeitsfrist, so dass die 250 MByte am Ende des Tages noch schnell "voll gemacht" wurden. Außerdem ist die Verwarnung und Sperrung von Nutzern weder für diese noch die CSN-Mitarbeiter angenehm. Deswegen wurde als Ausweg ein intelligenteres Bandbreiten-Management gesucht und im Rahmen einer Diplomarbeit in Angriff genommen.

Prinzipielle Funktionsweise

Die Nutzer werden jetzt abhängig von ihrer verursachten Datenmenge in Gruppen mit unterschiedlicher Bandbreite eingeteilt. Je höher das Datenvolumen, desto weniger Bandbreite steht dem betreffenden Nutzer zur Verfügung. Nach und nach wird dieser Nutzer wieder einer Gruppe mit höherer Bandbreite zugewiesen.

GruppeAb MengeBandbreiteTageBegrenzungSofort
1100 MByte/Tag 10 MBit/s 2--
2200 MByte/Tag 5 MBit/s 4X-
3300 MByte/Tag 3 MBit/s 6X-
4400 MByte/Tag500 KBit/s 8X-
5500 MByte/Tag100 KBit/s10XX

Als Vorteil ist auch der geringere Verwaltungsaufwand zu nennen, es müssen jetzt keine Verwarnungen oder Sperrungen mehr vorgenommen werden.

Die Parameter der Gruppen sind über ein Web-Interface einstellbar, ebenso die Ausnahmeregelungen für WWW- und FTP-Server, um Anreize zu schaffen, diese internen Ressourcen stärker zu nutzen. Auch für die Nutzer steht ein Web-Interface zur Verfügung, über das sie ihre aktuellen Daten wie Gruppe und Datenmenge erfahren können. Bei Einordnung in Gruppe 5 erhält der betreffende Nutzer außerdem noch eine Benachrichtigung per E-Mail.

Um die dem CSN monatlich zugestandene Datenmenge möglichst optimal auszunutzen, jedoch ohne sie zu überschreiten, erfolgt eine automatische Regelung der Bandbreiten für die einzelnen Gruppen. Dazu wird das bisher erzeugte Datenvolumen auf den Monat hochgerechnet und mit dem Monatslimit verglichen. Liegt die Hochrechnung darüber, werden die Bandbreiten gesenkt, ansonsten erhöht. Ist die Bandbreite einer Gruppe höher als ein festgelegter Schwellenwert, wird sie temporär vom Shaping ausgenommen.

Architektur des Systems

Die Management- und Informations-Schnittstellen sind per HTTP/HTML plattformunabhängig realisiert. Für die internen Management-Schnittstellen findet XML-RPC Verwendung, ein RPC-Protokoll auf der Basis von XML und HTTP. XML-RPC ist ein sehr einfaches Protokoll, d.h. es ist einfach zu verstehen und einfach zu implementieren. Der große Vorteil ist seine Sprachunabhängigkeit, so dass Daten zwischen Applikationen in verschiedenen Programmiersprachen ausgetauscht werden können.

 

 

Der Manager dient zur Verwaltung des DynShapers. Er legt die Parameter für die verwendeten Interfaces, Pfadnamen zu Programmen und eine Monatsobergrenze fest, stellt die Werte für die einzelnen Gruppen ein und definiert Ausnahmeregelungen.

Mit dem Watcher ist es den einzelnen Nutzern möglich, ihre aktuellen Werte wie die verursachte Datenmenge, die Gruppe, der sie momentan zugeordnet sind sowie deren Parameter abzufragen.

Durch den Configurator erfolgt die Konfiguration des DynShapers. Er verwaltet die Konfigurationsdaten und beantwortet XML-RPC-Anfragen, die Konfigurationsoptionen lesen oder schreiben wollen.

Der Evaluator wertet das Verkehrsaufkommen der Nutzer aus und ordnet die Nutzer bei Bedarf einer anderen Gruppe zu. Dazu führt er einmal pro Stunde eine Abfrage der aktuellen Werte durch. Weiterhin dient der Evaluator zur automatischen Regelung der Bandbreiten für die Gruppen, damit die festgelegte Monatsobergrenze nicht überschritten werden kann.

Der DynShaper dient zur eigentlichen Begrenzung des Verkehrs. Er wertet die vom Configurator erzeugte Konfiguration aus und legt Queuing Disciplines, Verkehrsklassen und Filterregeln fest:

 

Einsatzerfahrungen

Seit August 2001 befand sich das System im Testbetrieb, der zufriedenstellend verlief, so dass es am 23.10.2001 offiziell in Betrieb genommen wurde. Damit verbunden war der Wegfall der alten 250-MByte-Limits. Im Laufe des Einsatzes wurden noch diverse Bugs und Features entdeckt, die korrigiert werden mussten. Weiterhin gab es anfangs einige Akzeptanzprobleme, die zum Teil auf eine ungünstige Begriffswahl zurückzuführen waren.

Einige Nutzer aus Gruppe 5 fanden sehr schnell heraus, dass die verfügbare Bandbreite fair auf offene Verbindungen und nicht auf Nutzer verteilt wird. Durch viele offene Verbindungen war es ihnen deshalb möglich, unverhältnismäßig viel Bandbreite zu bekommen und die anderen Nutzer dieser Gruppe stark zu behindern. Mit der Queuing Discipline HTB statt CBQ ist es aber möglich, für jeden Nutzer in einer Gruppe eine eigene Verkehrsklasse anzulegen, so dass sich die Bandbreite jetzt auf die Nutzer verteilt.

Ein weiteres Problem ist, dass gedroppte TCP-Pakete nochmal gesendet werden müssen und dadurch zum einen mehrfach gezählt werden und zum anderen auch für eine höhere Netzlast sorgen. Allerdings sorgt die Flusskontrolle von TCP dafür, dass die Datenrate gedrosselt wird und der Effekt nicht so stark in Erscheinung tritt.

Die Anzahl der Verkehrsklassen hat keinen Einfluss auf den Durchsatz, bei sehr vielen Filterregeln sinkt er jedoch. Das liegt an dem linearen Durchlauf dieser Regeln. Abhilfe kann zum Beispiel durch Hashing Filters geschaffen werden.

Aktuelle Entwicklungen

Neue Auswertung

Es erfolgt eine gleitende Zählung (Durchschnitt über letzte 14 Tage) der Datenmenge, um Trafficspitzen, die durch einmalige Transferaktionen verursacht wurden, abzuschwächen und die Nutzer dafür nicht so hart zu "bestrafen", wenn sie sich sonst zurückhalten. Die Auswertung und die Einordnung in die Gruppen erfolgt stündlich neu, es gibt also auch keine Verweildauer in den Gruppen mehr. Die Nutzer werden anhand ihrer Datenmenge sortiert und so aufgeteilt, dass jede Gruppe in etwa die gleiche Datenmenge verursachen kann. Neben der Bandbreitenregelung hat man jetzt also auch noch die Nutzerverteilung als weitere Einflussmöglichkeit.

Die Gruppenanzahl wird auf 10 erhöht, um eine feinere Aufteilung der Nutzer zu ermöglichen. Bei einer Aulastung von 100% würden in Gruppe 10 für jeden Nutzer 24 KBit/s zur Verfügung stehen, die reale Auslastung liegt sogar nur bei ca. 80%. Die Initialbandbreite von Gruppe 10 wird so festgelegt, dass sie nur 1/10 des erlaubten Datenvolumens verursachen kann; Gruppe 1 erhält die Bandbreite des Interfaces. Die Bandbreiten der anderen Gruppen gestalten sich wie folgt:

GruppeBandbreiteNutzerAb MengeVorher Klasse
012345
1 98 MBit/s94955,4% 0 MByte/Tag92511 7 4 20
2 53 MBit/s22213,0% 17 MByte/Tag19318 7 2 11
3 29 MBit/s151 8,8% 29 MByte/Tag11323 5 8 11
4 15 MBit/s111 6,5% 40 MByte/Tag 532418 8 80
58400 KBit/s 82 4,8% 54 MByte/Tag 271233 6 31
64500 KBit/s 64 3,7% 69 MByte/Tag 5102511 85
72500 KBit/s 49 2,9% 92 MByte/Tag 4 41514 48
81300 KBit/s 39 2,3%114 MByte/Tag 0 0 916 95
9 720 KBit/s 30 1,8%150 MByte/Tag 1 1 414 55
10 390 KBit/s 16 0,9%223 MByte/Tag 0 0 1 2112

Die Datenmengengrenzen für die einzelnen Gruppen, die sich anhand von realen Daten so ergeben haben, liegen deutlich unter denen des alten Systems. Dabei darf aber nicht vergessen werden, dass es sich hier um Durchschnittswerte handelt. Als Verbesserung ist deutlich zu sehen, dass Nutzer, die bisher für einmalige Transfers zu stark bestraft wurden (oberhalb der Diagonale in der Gegenüberstellung alte Klasse - neue Gruppe), nun eine höhere Bandbreite zur Verfügung haben, während Nutzer, die die Grenzen immer nahezu ausgenutzt hatten (unterhalb der Diagonale) jetzt auch entsprechend behandelt werden.

Neue Regelung

Für die Regelung der Bandbreiten wird jetzt auch ein gleitender Durchschnitt eingesetzt, allerdings nur über 7 Tage, um schneller reagieren zu können. Durch den Durchschnitt können kurzzeitige Einflüsse wie am Wochenende abgefangen und ein "Schwingen" der Bandbreiten verhindert werden.

Um schnell reagieren zu können, wird das Verhältnis aus 7- und 14-Tage-Durchschnittstraffic des gesamten CSN herangezogen. Im Diagramm ist gut zu sehen, wie bei der Erhöhung des Datenaufkommens zum Semesterbeginn diese beiden Durchschnittswerte auseinanderlaufen, so dass der Abstand dazwischen als ein gutes Kriterium gelten kann, wann die Bandbreiten nachgeregelt werden müssen.

Ausblick

Für die Zukunft ist geplant, den DynShaper auch an anderen Hochschulen einzusetzen. Dazu muss er von lokalen Abhängigkeiten befreit werden. Außerdem sollen Einrichtungen unterstützt werden, bei denen es keine 1:1-Zuordnung zwischen Nutzer und IP-Adresse gibt. Die Installation müsste dann auch besser unterstützt werden, zur Zeit ist noch viel Handarbeit erforderlich. Eventuell könnte sogar ein eigener Trafficzähler mit Datenbank integriert werden, so dass man ein Komplettpaket zur Zählung und Behandlung von Netzverkehr erhält.

Jan Horbach, Fakultät für Informatik, April 2002