Strom sparender Computereinsatz hilft nicht zuletzt auch Kosten zu senken. ADMIN 02/2011 geht der Frage nach, was Administratoren tun können, damit ihre ... (mehr)

Performance-Vergleiche

Wie in der oberen Hälfte von Tabelle 3 zu sehen ist, erreicht das Skript »trafficcontrol-inetgw« mit HTB als QDisc und »linklay atm« kürzere Reaktionszeiten bei leicht höherer Bandbreite als der Wondershaper. Die Messungen liefen mit 100 Ping-Paketen bei einem Paket pro Sekunde zu einem möglichst nahen Router im Internet. Deutlich weicht die erzielte Nutzdatenbandbreite von der erlaubten Rohdatenbandbreite ab.

Bei separaten Up- oder Downloads leidet der Wondershaper noch nicht an der fehlenden Overhead-Berechnung, da die durch Shaping begrenzte Bandbreite eine ausreichende Lücke zur Rohbandbreite lässt. Die Differenz entspricht dem Overhead. Die kleinen ACK-Pakete lasten die andere Übertragungsrichtung nicht aus. Gleichzeitige Up- und Downloads machen jedoch den Vorteil einer dynamischen Overhead-Berechnung deutlich. Jetzt kommt der prozentual sehr große Overhead der ACK-Pakete zum Tragen. Ohne dynamische Berechnung des Overheads will das Gateway mehr Daten übertragen, als der Anschluss bewältigen kann, und es bilden sich Warteschlangen.

Die untere Hälfte von Tabelle 3 zeigt das Ergebnis für einen anderen Internetzugang. Dort ist zu sehen, dass einige ADSL-Zugänge empfindlich auf gleichzeitige Up- und Downloads reagieren und stark schwankende Ergebnisse liefern. Leider hat der Linux-Kernel keine Möglichkeit, sich diesem Verhalten anzupassen.

Die Zeilen 61 bis 101 von Listing 1 richten Egress-Shaping für den Upload ein. Initial berechnet der Algorithmus ab Zeile 61 ein minimales Quantum für die HTB-Klassen. HTB-Klassen leihen sich gegenseitig Bandbreite, wenn eine Klasse weniger benötigt, als ihr »rate« zuweist, und eine andere gerade Bedarf hat. Quantum gibt dabei die minimale Anzahl auf einmal verleihbarer Bytes an. Es muss größer als die MTU sein, aber so klein wie möglich. Leider berechnet HTB bei den kleinen Upstream-Bandbreiten einiger ADSL-Anschlüsse ein zu kleines Quantum. Das führt zu einer Fehleinschätzung der genutzten Rohdatenbandbreite und damit zu einer Warteschlange im Modem.

Listing 1

trafficcontrol-inetgw

 

Zeile 76 legt die Root-HTB-Klasse an. Sie hat die Aufgabe, die genutze Upstream-Rohdatenbandbreite per »rate« und »ceil« auf das vom Administrator konfigurierte Maß zu beschränken. Die Zeilen 82 bis 95 legen drei priorisierte HTB-Klassen für die einzelnen Verbindungstypen an. Die Klasse 1:10 "Low Latency" hat die höchste Priorität und 1:12 "Second-Order Bandwidth" die niedrigste. Der Parameter »ceil« bestimmt dabei die Bandbreite, die eine Klasse maximal nutzen darf. Dagegen beschreibt »rate« die für sie reservierte Bandbreite.

Jede Klasse darf immer so viel Bandbreite nutzen, wie ihr »rate« beschreibt. Benötigt sie mehr, kann sie bis zu »ceil« Bandbreite von anderen Klassen leihen – vorausgesetzt dort sind Kapazitäten frei. Wollen mehrere Klassen Bandbreite leihen, erfährt die mit der niedrigeren Priorität eine Bevorzugung.

Ab Zeile 97 legen »tc« -Aufrufe in jeder der drei HTB-Klassen eine Stochastic Fairness Qdisc (SFQ) an [11], was die verschiedenen Verbindungen innerhalb einer Klasse gleichberechtigt behandelt – normalweise sind Verbindungen mit hohem Bandbreitenbedarf nämlich implizit bevorzugt.

Feingranulare Filter

Die nun folgende Filter-Sektion weist ausgehenden Pakete einer der drei HTB-Klassen zu. Klasse 1:10 "Low Latency" erhält alle, die eine niedrige Latenz benötigen und voraussichtlich wenig Bandbreite belegen. Das sind kleine TCP-ACK- und alle ICMP-Pakete (Zeilen 106 und 129). Dazu kommen solche, deren IP-Header im TOS-Feld das "Low Latency"-Bit enthält (Zeile 113) oder denen IPtables »10« als Marke verpasst hat (Zeile 117).

Die »u8« - und »u16« -Filterausdrücke ab Zeile 109 prüfen, ob bestimmte Bits im IP-Header gesetzt sind [12]. Das erfasst alle Pakete mit weniger als 64 Bytes, in der Regel ACK-Pakete. Da sich die bis zu 80 Bytes großen SACK-Pakete nur aufwändig herausfiltern ließen, erhalten sie in Listing 2 ab Zeile 22 einfach die Marke »10« aufgedrückt. Die Klasse 1:11 "Bulk and Default" ist für Datenpakete gedacht, die entweder keine besonders niedrige Antwortzeit benötigen oder für "Low Latency" zu viel Bandbreite verbrauchen. HTTP-Pakete, die beim interaktiven Surfen entstehen, gehören hierhin. Zeile 133 erfasst alle Pakete, auf die kein anderer Filter angesprochen hat.

Listing 2

iptables-egress

 

Für Pakete, die ruhig ein paar Millisekunden warten dürfen, gibt es die Klasse 1:12 "Second-Order Bandwidth", die Zeile 125 erfasst. Die Klasse für Pakete mit der Marke »12« ist vor allem für große Uploads gedacht, die nicht den oft knappen Upstream verstopfen sollen. Um große Uploads vom Surfen zu unterscheiden, markiert Listing 2 ab Zeile 15 Pakete der Typen HTTP und FTP genau dann mit »12« , wenn sie zu einer Verbindung gehören, die schon mehr als 10 MByte Nutzdaten transportiert hat.

In Listing 2 kann der Administrator weitere Protokolle einer der drei HTB-Klassen zuweisen. Wie das Beispiel der großen Uploads zeigt, geht die Granularität von IPtables dabei weit über die von »tc filter« hinaus. Zu beachten ist, dass beim Markieren im IPtables-Skript die letzte Regel greift, während bei »tc filter« in Listing 1 die erste Regel signifikant ist.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019