QoS beim Disaster Recovery
Rettungsanker
Veröffentlicht in Ausgabe 12/2025 - PRAXIS
Nach katastrophalen Ausfällen der IT-Infrastruktur – seien es Zerstörungen an Unterseekabeln, von Wetterkapriolen verursachte Beschädigungen oder Angriffe durch Kupferdiebe – kann die Wiederherstellung der vollständigen Bandbreite zwischen den einzelnen Punkten eines Netzwerks Tage oder Wochen in Anspruch nehmen.
Die Qualität der Nutzererfahrung während eines derartigen Notbetriebs ist davon abhängig, wie schnell Applikationen und Kerndienste auf Anfragen reagieren. Tools wie LibreQoS helfen dabei, knappe Ressourcen gezielt zu verteilen und latenzkritische Dienste zu bevorzugen. Das effiziente Management von Bandbreite und Latenz ist deshalb sehr wichtig für die Disaster-Recovery-Strategie (DR) eines Unternehmens.
QoS priorisiert Datenströme nach Latenzbedarf
Nicht jedes Paket ist aus Sicht der Benutzererfahrung gleich wichtig: Während erhöhte Latenz bei einem Windows-Update oder beim Upload eines Objekt-Storage-BLOBs nicht sonderlich kritisch ist, wirken sich 100 ms Verzögerung bei Sprach- oder Videoverbindungen störend aus.
Nach katastrophalen Ausfällen der IT-Infrastruktur – seien es Zerstörungen an Unterseekabeln, von Wetterkapriolen verursachte Beschädigungen oder Angriffe durch Kupferdiebe – kann die Wiederherstellung der vollständigen Bandbreite zwischen den einzelnen Punkten eines Netzwerks Tage oder Wochen in Anspruch nehmen.
Die Qualität der Nutzererfahrung während eines derartigen Notbetriebs ist davon abhängig, wie schnell Applikationen und Kerndienste auf Anfragen reagieren. Tools wie LibreQoS helfen dabei, knappe Ressourcen gezielt zu verteilen und latenzkritische Dienste zu bevorzugen. Das effiziente Management von Bandbreite und Latenz ist deshalb sehr wichtig für die Disaster-Recovery-Strategie (DR) eines Unternehmens.
QoS priorisiert Datenströme nach Latenzbedarf
Nicht jedes Paket ist aus Sicht der Benutzererfahrung gleich wichtig: Während erhöhte Latenz bei einem Windows-Update oder beim Upload eines Objekt-Storage-BLOBs nicht sonderlich kritisch ist, wirken sich 100 ms Verzögerung bei Sprach- oder Videoverbindungen störend aus.
QoS-Systeme befinden sich – wie in Bild 1 gezeigt – zwischen dem lokalen und dem globalen Netzwerk. Passierende Pakete unterlaufen eine Klassifizierung und werden dann anhand verschiedener Algorithmen priorisiert oder zurückgehalten. Wichtig ist, dass QoS-Systeme nicht mit Intranetzwerkpaketen interagieren – die Priorisierung der Verbindung zwischen zwei im gleichen Netzwerk positionierten Stationen ist ausgeschlossen.
Die in den Priorisierungsalgorithmen implementierten Vorgehensweisen sind von Anbieter zu Anbieter unterschiedlich. Prinzipiell gilt, dass mit CAKE und FQ-CoDel zwei Algorithmenfamilien zur Verfügung stehen. CAKE – Common Applications Kept Enhanced – ist der modernere der beiden.
Für ein besseres Verständnis wollen wir jedoch mit dem Algorithmus "Controlled Delay" (CoDel) beginnen. Er ist im RFC 8289 [1] spezifiziert und analysiert erstmals die einzelnen Paketwarteschlangen. Ist die Wartezeit in einer der Schlangen zu lang, droppt er Pakete, um die Wartezeit zu reduzieren. Ein intelligenter Sender erkennt diese Paketverluste und reduziert seine Senderate.
Der in RFC 8290 [2] spezifizierte "Flow Queue CoDel" priorisiert kurze Verbindungen, um eine schnellere Abarbeitung zu ermöglichen und das Verstopfen der Infrastruktur durch große Pakete oder lang laufende Kommunikationsprozesse einzuschränken. CAKE – derzeit nur unter [3] dokumentiert – ergänzt das System um einen Traffic-Shaper und einen verbesserten Hash-Algorithmus. Allgemein gilt, dass CAKE einen leicht höheren CPU-Verbrauch und wesentlich größere Arbeitsspeicheranforderungen aufweist. LibreQoS geht von einem siebenfachen RAM-Bedarf aus gegenüber FQ-CoDel. Auf der Haben-Seite steht, dass ein damit arbeitendes QoS-System eine geringere Latenz erreicht.
Praktisch gilt, dass die genauen technischen Unterschiede zwischen den verschiedenen QoS-Verfahren eine untergeordnete Rolle spielen. Wichtig ist vor allem der Sprung von chaotischer Lastverteilung zu irgendeiner Form von QoS.
DPI vs. Header-Analyse
Um die Dringlichkeit von Netzwerkpaketen bewerten zu können, muss ein QoS-System ihre Latenzempfindlichkeit kennen. Dafür gibt es zwei Ansätze: Deep Packet Inspection (DPI) analysiert den Inhalt der Pakete selbst, während Header-basierte Verfahren ausschließlich Metadaten wie TCP- oder IP-Felder auswerten.
DPI-basierte Methoden ermöglichen eine sehr feingranulare Steuerung. So lassen sich beispielsweise WhatsApp- und FaceTime-Anrufe unterscheiden und unterschiedlich priorisieren. Sie haben jedoch zwei Nachteile:
- Rechtliche Aspekte: In der EU kann DPI problematisch sein, weil es potenziell gegen Vorgaben zur Netzneutralität verstößt.
- Hohe Systemlast: Die Analyse der Paketinhalte erfordert deutlich mehr Rechenleistung und kann QoS-Systeme belasten.
Header-basierte Verfahren sind einfacher und ressourcenschonender. Sie nutzen Metadaten wie das im IPv4-Differentiated-Services-Feld hinterlegte Prioritätsbit (RFC 2474) oder andere TCP/IP-Header-Felder, um Pakete automatisch in Prioritätsklassen einzuordnen. Bei CAKE gibt es beispielsweise die in der Tabelle aufgeführten vier Klassen.
| Priorität | Klassenname | Beschreibung |
|---|---|---|
| 1 | Voice | VoIP, NTP, Live-Datenübertragungen hoher Priorität |
| 2 | Video | Daten mit höherer Priorität |
| 3 | Best Effort | Gutteil der zu übertragenden Daten |
| 4 | Bulk | BitTorrent und ähnliche Trafficarten geringer Priorität |
Vom Branchenriesen bis Open Source
Die auf dem Markt befindlichen QoS-Systeme lassen sich sowohl anhand der verwendeten Algorithmen als auch anhand der Lizenzierungsweise unterscheiden. Zwei Anbieter mit langer Tradition sind die in den USA ansässige SandVine und die von Ex-SandVine-Mitarbeitern in Kanada gegründete Preseem. Beide bieten ihre Software ausschließlich unter kommerziellen Lizenzen an. Technisch unterscheiden sich die Offerten insofern, als dass SandVine auf DPI setzt und einen eigenen Algorithmus verwendet. Preseem nutzt CAKE und verzichtet auf DPI. Das Produkt richtet sich an kleinere ISPs, während SandVine vor allem auf die Bedürfnisse von Tier-1-ISPs Rücksicht nimmt.
Die in Spanien ansässige Bequant setzt auf DPI und nutzt FQ-CoDel zur Priorisierung der Pakete. Das Unternehmen fällt durch zwei Besonderheiten auf: Erstens bietet es auf der Webseite einen Preisrechner [4] an, der in Abhängigkeit der IP-Adresse sofort eine Kostenkalkulation ausgibt. Für ein 200-MBits/s-Netzwerk etwa fallen für einen europäischen Kunden einmalig rund 2100 Euro an Lizenzkosten an; mit steigender Transfergeschwindigkeit erhöhen sich diese.
Die zweite Besonderheit ist, dass Bequant die hauseigene Engine an Drittunternehmen lizenziert. Die in Nordamerika ansässige Cambium Networks etwa nutzt die Technologie für ein eigenes Produkt. In Asien spielt auch Paraqum Technologies eine Rolle. Die in Sri Lanka ansässige Firma entstand als Ausgründung einer Universität und kombiniert CAKE mit Deep Packet Inspection.
Das einzige quelloffene System ist Libre-QoS [5]. Es nutzt den Algorithmus CAKE, die Basisversion steht ohne Gebühren zur Verfügung. Ausgaben entstehen erst, wenn das Statistikmodul eingesetzt oder Kundensupport in Anspruch genommen wird. Während die Kosten für den Support verhandelbar sind, werden für das Statistikmodul in kleineren Deployments 0,30 US-Dollar pro Nutzer und Monat berechnet.
Praxisszenario: QoS beim Kabelausfall
Nach diesen Überlegungen zur Technologie und deren Anbietern wollen wir uns reale Einsatzszenarien für QoS ansehen. Als erstes praktisches Beispiel dient der Ausfall einer Glasfaserleitung, die ein Unternehmen mit dem Internet verbindet. Reparaturen der Fiber-Leitung können erfahrungsgemäß mehrere Wochen in Anspruch nehmen.
Erste Handlung des ISPs ist deshalb normalerweise die Einrichtung einer vorübergehenden Verbindung, beispielsweise auf Richtfunkbasis. Das Vorhalten eines StarLink-Transceivers kann eine vernünftige Vorgehensweise zur Sicherstellung der Konnektivität darstellen. Solche Verbindungen haben naturgemäß eine höhere Latenz und weniger Bandbreite.
Dienste wie VoIP oder die Übertragung von E-Mails sind nun wichtiger als etwa das schnellstmögliche Updaten von Visual Studio. Selbst in einem Netzwerk, das normalerweise ohne QoS auskommt, führt diese Einschränkung zu akutem Bedarf an QoS: Nur durch striktes Wirtschaften lässt sich eine für die Mehrheit der User akzeptable Situation wiederherstellen.
So kein extremes Missverhältnis zwischen Nutzerzahl und Bandbreite (3 bis 10 MBit/s pro Person reichen in der Regel aus) besteht, genügt die Bereitstellung eines QoS-Systems mit Standardeinstellungen. Hierzu bietet sich das Bereithalten eines dedizierten Servers an, der im Zweifelsfall wie in Bild 1 gezeigt in die Verbindung eingeschleift wird.
In Situationen mit extrem geringer Bandbreite bietet sich die manuelle Allokation auf Zielsysteme oder Dienste an. Im Fall von LibreQoS erfolgt dies entweder unter Verwendung eines grafischen Benutzerinterfaces oder durch Erzeugen einer CSV-Datei mit Einstellungen. Die praktische Erfahrung lehrt, dass in Disaster-Recovery-Situationen die manuelle Konfiguration vernünftiger ist, da CRM-Systeme et cetera im Allgemeinen erst spät zur Verfügung stehen.
Als Beispielkonfiguration dient das im Kasten abgedruckte CSV-Snippet aus einer produktiven Konfiguration eines ISPs. Auffällig ist, dass die erste Zeile Informationen über die Feldinhalte enthält. Über die Min- und Max-Felder lässt sich dann festlegen, wie viel Bandbreite für die verschiedenen Systeme zur Verfügung stehen soll. Hiermit lässt sich beispielsweise der Router einer empfindlichen Abteilung priorisieren – Ausfälle beim Sales-Team sind normalerweise kritischer als Verzögerungen bei Softwareupdates.
QoS ungeeignet für Wiederherstellungsreihenfolge
Die gezielte Zuweisung von Bandbreite an einzelne Konsumenten lässt auf den ersten Blick vermuten, dass sich QoS auch zur Sequenzierung der Wiederherstellung einsetzen ließe: Wenn beispielsweise die Availability-Zone A nur minimale Bandbreite erhält, könnte Zone B ihre Regeneration theoretisch schneller abschließen.
In der Praxis erweist sich dieser Ansatz jedoch als kaum vorteilhaft. Die Reihenfolge der Wiederherstellung von Availability-Zones oder logischen Funktionsblöcken sollte auf einer höheren Ebene definiert werden. Grund dafür ist, dass eine Sequenzierung auf Basis von Systemabhängigkeiten eine klarere und reproduzierbarere Regeneration ermöglicht.
Die Erfahrung zeigt zudem, dass sich die zur Wiederherstellung eines Systems erforderlichen Datenmengen stark unterscheiden und vorab nur schwer exakt abschätzen lassen. Disaster-Recovery-Prozesse verlaufen meist in Phasen hoher Instabilität. Deshalb empfiehlt es sich, potenziell undefiniertes Verhalten zu vermeiden und die Steuerung der Wiederherstellung explizit außerhalb der QoS-Konfiguration vorzunehmen.
Anomalieerkennung und KI-gestützte Analyse
In Zeiten zunehmender Bedrohungen durch Zero-Day-Exploits und gezielte Angriffe spielt die Anomalieerkennung eine entscheidende Rolle. Wie in der Elektronik oder Softwareentwicklung gilt auch hier: Frühes Erkennen reduziert potenzielle Schäden.
QoS-Systeme stellen im Backend häufig grafische Übersichten bereit, die die Zusammensetzung des gesamten durchgeleiteten Traffics visualisieren. Anhand dieser Daten lassen sich verdächtige Muster identifizieren – etwa die Exfiltration großer Datenmengen an ungewöhnliche Ziele. Ein einfacher Ansatz besteht darin, diese Diagramme manuell auszuwerten. Auffällige Muster wie massive Datenübertragungen von den USA nach Russland können auf Exfiltrationsversuche oder Ransomware-Attacken hindeuten. Ebenso kritisch sind ungewöhnliche Zugriffe auf sensible Systeme: Wird in der Übersicht beispielsweise ein SSH-Zugriff aus Vietnam auf einen europäischen Router sichtbar, liegt ein möglicher Angriff nahe.
Die Anbieter von QoS-Systemen gehen inzwischen einen Schritt weiter: Large Language Models (LLMs) werden zunehmend in die Analyse integriert, um Anomalien automatisch zu erkennen und handlungsrelevante Hinweise bereitzustellen. Bei LibreQoS befindet sich ein entsprechendes Modul aktuell im geschlossenen Alphatest; vergleichbare Entwicklungen sind auch bei anderen Herstellern zu erwarten.
Darüber hinaus unterstützen QoS-Systeme nicht nur beim Disaster Recovery, sondern auch bei laufenden Optimierungsaufgaben, insbesondere bei ISPs. Da viele Anbieter auf eine breite Datenbasis aus produktiven Installationen zurückgreifen, können deren Systeme häufige Konfigurationsprobleme automatisch erkennen und Optimierungsvorschläge generieren. Schließlich sind QoS-Systeme in der Lage, kritische Betriebszustände proaktiv zu identifizieren – sowohl durch klassische Anomalieerkennung als auch durch die Auswertung der Wissensbasis. Diese Hinweise können optional automatisch Alerts auslösen.
LibreQoS-Appliance vorbereiten
Angesichts der beschriebenen Vorteile kann es sinnvoll sein, eine LibreQoS-Instanz bereits im Vorfeld als Teil der DR-Strategie bereitzuhalten. Besonders geeignet sind dafür kompakte Appliance-Systeme. Eine von den Entwicklern empfohlene Option ist das "MinisForum MS-01": ein kompakter Mini-PC, der zwei 2,5-GBit/s-Ethernetports und zwei 10-GBit/s-Schnittstellen bietet. Trotz der hohen Anschlussdichte bleibt der Ressourcenbedarf recht moderat. 4 GByte RAM reichen für etwa 1000 Nutzer aus.
LibreQoS lässt sich grundsätzlich auch auf anderer Hardware oder in einer virtuellen Maschine betreiben. In der Praxis gibt es jedoch Einschränkungen, denn die Software interagiert sehr eng mit den Netzwerkkarten. Nicht unterstützte NICs – siehe die LibreQoS-Dokumentation [5] – lassen sich zwar nutzen, jedoch auf eigene Verantwortung und ohne Support. Bei virtuellen Maschinen sind zwingend NIC-Passthrough und deutlich mehr Rechenleistung erforderlich, was die Administration komplexer macht.
CSV-Beispieldatei mit LibreQoS-Einstellungen
Circuit ID,Circuit Name,Device ID,Device Name,Parent Node,MAC,IPv4,IPv6,Download Min Mbps,Upload Min Mbps,Download Max Mbps,Upload Max Mbps,Comment
1,"968 Circle St., Gurnee, IL 60031",1,Device 1,AP_A,,"100.64.0.1, 100.64.0.14",fdd7:b724:0:100::/56,1,1,155,20,
2,"31 Marconi Street, Lake In The Hills, IL 60156",2,Device 2,AP_A,,100.64.0.2,fdd7:b724:0:200::/56,0.5,0.5,2.5,1,
3,"255 NW. Newport Ave., Jamestown, NY 14701",3,Device 3,AP_9,,100.64.0.3,fdd7:b724:0:300::/56,1.25,0.75,10.5,5.25,
4,"8493 Campfire Street, Peabody, MA 01960",4,Device 4,AP_9,,100.64.0.4,fdd7:b724:0:400::/56,25.5,12.5,100.5,50.25,
2794,"6 Littleton Drive, Ringgold, GA 30736",5,Device 5,AP_11,,100.64.0.5,fdd7:b724:0:500::/56,1,1,105,18,
2794,"6 Littleton Drive, Ringgold, GA 30736",6,Device 6,AP_11,,100.64.0.6,fdd7:b724:0:600::/56,1,1,105,18,
5,"93 Oklahoma Ave., Parsippany, NJ 07054",7,Device 7,AP_1,,100.64.0.7,fdd7:b724:0:700::/56,2,2,25,10,
. . .
Netzwerkbrücke konfigurieren
Als Hostbetriebssystem setzt LibreQoS auf Ubuntu Server 24.04. Nach der Installation ist die Einrichtung einer Netzwerkbrücke für Upstream- und Downstream-Interfaces erforderlich. Standardmäßig kommt dafür NetPlan zum Einsatz. Die Struktur der Bridge lässt sich der Dokumentation entnehmen. Die Konfiguration der Datei "/etc/netplan/libreqos.yaml" bei den Interfacenamen ens19 und ens20 könnte so aussehen:
network:
ethernets:
ens19:
dhcp4: no
dhcp6: no
ens20:
dhcp4: no
dhcp6: no
bridges:
br0:
interfaces:
- ens19
- ens20
version: 2
Das Setzen der dhcp*-Attribute auf "no" sorgt dafür, dass die Interfaces beim Systemstart automatisch aktiv sind – auch ohne zugewiesene IP-Adresse. Die Konfiguration übernehmen Sie so:
sudo chmod 600 /etc/netplan/ libreqos.yaml
sudo netplan apply
LibreQoS installieren und konfigurieren
Für die eigentliche Installation steht ein DEB-Paket bereit. Dieses laden Sie wie folgt herunter, entpacken und installieren es:
wget https://libreqos.io/wp-content/uploads/2025/03/libreqos_1.5-BETA10_amd64.zip
sudo apt-get install unzip
unzip libreqos_1.5-BETA10_amd64.zip
sudo apt install ./libreqos_1.5- BETA10_amd64.deb
Im Anschluss sind Anpassungen an der Konfigurationsdatei "/etc/lqos.conf" erforderlich. Besonders wichtig ist die Sektion "[bridge]", die die Interfaces für lokale und externe Kommunikation definiert. Nach dem Speichern der Änderungen aktivieren Sie das System durch einen Neustart oder den Befehl
sudo systemctl restart lqosd
Der Pflegeaufwand für eine LibreQoS-Appliance ist gering. Neben den üblichen Aktualisierungen des Hostbetriebssystems werden auch regelmäßig Updates der LibreQoS-Software veröffentlicht. Erfahrungsgemäß ist etwa alle fünf bis sieben Monate mit einer neuen Version zu rechnen.
Fazit
Disaster Recovery erfordert eine ganzheitliche Strategie, um Systeme und Dienste möglichst schnell wieder in einen funktionsfähigen Zustand zu versetzen. In Szenarien mit stark reduzierter Bandbreite leisten QoS-Systeme dabei einen entscheidenden Beitrag: Sie ermöglichen eine gezielte Priorisierung kritischer Dienste, verbessern die Nutzererfahrung und helfen kontinuierlich dabei, die Produktivität aufrechtzuerhalten.
(ln)
Links
[1] RFC 8289 – CoDel: https://datatracker.ietf.org/doc/html/rfc8289
[2] RFC 8290 – Flow Queue CoDel: https://datatracker.ietf.org/doc/rfc8290/
[3] CAKE: https://arxiv.org/abs/1804.07617
[4] Bequant Preisrechner: https://it-a.eu/paz14
[5] LibreQoS: https://libreqos.io/
[6] Dokumentation LibreQoS: https://libreqos.readthedocs.io/en/latest/