Die drei Säulen von SD-WAN-QoS und Fragen an Ihren Provider
Traffic Shaping, Path Control und Forward Error Correction sind die drei Hauptkomponenten von SD-WAN-QoS. Erfahren Sie, welche Fragen Sie Ihrem Anbieter hierzu stellen sollten.
Software-defined WAN (SD-WAN) vereint auf seinem Weg zum Software-defined Branch immer mehr traditionelle Sicherheitsfunktionen – und in einigen Fällen sogar WLAN-Fähigkeiten. Doch diese Zunahme an Funktionalität kann auch zu einer Zunahme der Komplexität führen.
Nehmen Sie beliebige SD-WAN- oder SD-Branch-Angebote, und Sie sehen sich einer verwirrenden Vielfalt von Features gegenüber. Darunter allerdings bleibt der Kern von SD-WAN gleich. Quality of Service (QoS) beruht auf drei Säulen, die dafür sorgen, dass die Struktur aufrechterhalten wird und Anwendungen reibungslos laufen. Bei diesen QoS-Säulen handelt es sich um Traffic Shaping, Path Control und Forward Error Correction – obwohl sich mitunter auch andere Bezeichnungen finden, für Path Control etwa Pathing oder Pfadkontrolle.
Durch die massive Ausweitung von SD-WAN und den Fokus auf erweiterte Funktionen wie Intent-based Networking (IBN) gerät leicht in Vergessenheit, dass diese Features nach wie vor auf Traffic basieren, der über ein häufig unzuverlässiges WAN läuft. Es dürfte somit kaum überraschen, dass Anbieter die Aufmerksamkeit von möglichen Kunden lieber auf das große Ganze lenken und vor den Details zurückschrecken. Oft ist es für Unternehmen sogar sehr schwierig, detaillierte Informationen über die technischen Grundlagen von SD-WAN-Optionen zu finden.
Sie sollten also vorbereitet sein, Ihren potenziellen Providern spezifische, detaillierte Fragen über SD-WAN-QoS zu stellen. Konzentrieren Sie sich auf das Wesentliche. Wenn ein Anbieter die Kerntechnologien seines Produkts nicht erklären kann oder will, lassen Sie sich auf einen Blindflug ein und können keinen geeigneten Testplan für eine Proof-of-Concept-Studie entwickeln.
Im Folgenden finden Sie für Ihre SD-WAN-Recherche einige Fragen zu jedem der drei QoS-Bereiche.
Traffic Shaping
Im Endeffekt geht es bei SD-WAN-QoS um die Zuteilung einer begrenzten Ressource. Ganz gleich, wie stark Sie Ihre Bandbreite aufrüsten, es wird garantiert Anwendungen geben, die sie auch verbrauchen. Traffic Shaping identifiziert und klassifiziert zunächst Traffic gemäß Ihren geschäftlichen Prioritäten. Dann reiht es diesen Traffic in eine Warteschlange ein. Auf diese Weise erhält der wichtigste Traffic ausreichende WAN-Ressourcen, um Ihre Service-Level-Anforderungen zu erfüllen.
Schritt eins. Am Anfang steht die Identifizierung des Traffics. Bitten Sie Ihren Anbieter um Details zum Identifizierungsprozess. Wie viele Anwendungen kann der Provider nur durch Überwachung Ihres Traffics dynamisch identifizieren? Fordern Sie eine spezifische Liste, und fragen Sie, wie granular diese Liste ist, beziehungsweise überprüfen Sie sie auf Granularität. Kann der Anbieter zum Beispiel Traffic von YouTube und Facebook Live voneinander unterscheiden? Oder wird beides unter Video-Stream subsumiert?
Schritt zwei. Wie erfolgt die Klassifizierung, nachdem der Traffic identifiziert ist? Dies ist der Schritt, der letztlich darüber entscheidet, wer welchen Anteil an der wertvollen Bandbreite bekommt. Welche Klassifizierungskriterien stehen zur Verfügung? Während VoIP insgesamt wichtiger sein dürfte als etwa ein Datei-Backup, werden nicht alle VoIP-Konversationen gleichermaßen wichtig sein. Führungskräfte, die VoIP nutzen, werden einen besseren Service benötigen und fordern als nachrangige Filial-zu-Filial-Kommunikation.
Schritt drei. Fragen Sie den Anbieter schließlich auch noch, wie er alle diese Informationen für Sie sichtbar macht. Netzwerke sind selten statisch. Fragen Sie also nach Analytics-Möglichkeiten. Wenn die Anwendungssuiten, die über Ihr Netzwerk laufen, zunehmen, empfehlen sich sowohl Echtzeit- als auch historische Analysen, so dass Sie Ihrem Netzwerk immer einen Schritt voraus sein können.
Path Control
Single-Link-Netzwerke sind für Unternehmen mit Service Level Agreements (SLA) im Business-Bereich einfach zu riskant. Daher bestehen die heutigen SD-WANs meist aus zwei oder mehr Links, die zur Lastverteilung und als Backup genutzt werden. Viele Netzwerke werden als Fallback sogar über Anbindungsmöglichkeiten per Mobilfunk verfügen, falls traditionelle drahtgebundene Links ausfallen. Dass Links verfügbar sind, sagt alleine natürlich nur sehr wenig aus. Entscheidend ist vielmehr die Softwareintelligenz. Sie entscheidet, wie der oder die zusätzlichen Links genutzt werden.
In der Regel denken wir bei Extra-Links an Backup-Ressourcen – und das sind sie auch. Doch Sitzungen beim Ausfall – beziehungsweise Blackout – der Hauptverbindung auf die Backup-Verbindung umzuschalten, ist noch ein vergleichsweise einfaches Szenario. Der Link fällt aus, und Sie migrieren die App.
Brownout-Szenarien stellen eine größere Herausforderung dar. Hierbei handelt es sich um Situationen, in denen der Link noch steht, aber wichtige Anwendungen nicht mit den gewünschten Service-Leveln bereitstellen kann. Möglicherweise gibt es starke Paketverluste, hohe Latenz oder viel Jitter. Vielleicht funktioniert auch der Link selbst aufgrund einer fehlerhaften Anschlusskomponente nicht richtig. Unabhängig von der Ursache muss Ihr Anbieter Ihnen mitteilen, welche speziellen Bedingungen seine Software erkennen kann und wie sie das Umschalten von Apps auf den sekundären Link bewerkstelligt.
Wenn ein Anbieter die Kerntechnologien seines Produkts nicht erklären kann oder will, lassen Sie sich auf einen Blindflug ein und können keinen geeigneten Testplan für eine Proof-of-Concept-Studie entwickeln.
Schritt eins. Fragen Sie Ihren potenziellen Provider, welche Bedingungen Sie festlegen können, um einen Transfer einer Anwendungssitzung auszulösen. Können Sie eine maximal tolerierbare Verzögerung angeben? Können Sie einen minimal tolerierbaren Durchsatz angeben? Können Sie bestimmte Schwellenwerte angeben? Können Sie konfigurieren, dass eine Link-Umschaltung nur dann erfolgt, wenn die Beeinträchtigungen eine bestimmte Zeit lang anhalten? Kurz gesagt: Wie viel Kontrolle haben Sie über diese Migration?
Schritt zwei. Was passiert, wenn die Bedingungen, die die Migration ausgelöst haben, nicht mehr gegeben sind? Eventuell ist der sekundäre Link langsamer als der primäre. Sie wollen, dass ihre Anwendungen wieder die schnellstmögliche Verbindung nutzen können.
Welche Aktion sieht der Anbieter standardmäßig vor, wenn es darum geht, Anwendungen wieder auf den Original-Link umzuschalten? Und gibt es Steuerungsmöglichkeiten, die Sie entsprechend festlegen können? Was ist, wenn die Hauptverbindung sporadisch Probleme aufweist? Sie wollen sicher nicht, dass wichtige Anwendungen zwischen den Links hin- und herspringen.
Schritt drei. Fragen Sie auch hier nach Analytics-Möglichkeiten. Welche Art von Sichtbarkeit in die von den Anwendungen genutzten Link-Pfade ermöglicht der Provider? Sie wollen und müssen Bescheid wissen, ob Ihre primären Links häufig Probleme haben, die ihre Anwendung dazu zwingt, Backup-Verbindungen zu verwenden.
Forward Error Correction
Selbst wenn Ihre Links problemlos funktionieren und Sie das Traffic Shaping wie erforderlich durchführen können, können Ereignisse jenseits Ihrer Kontrolle die Anwendungs-Performance beeinträchtigen. Eine schlechte Verbindung oder ein überlasteter Router irgendwo im Netzwerk kann dafür sorgen, dass ein oder mehrere Pakete Ihrer Anwendung verworfen werden – das heißt verloren gehen. Dies führt zu Verzögerungen oder sogar fehlgeschlagenen Sitzungen.
Forward Error Correction (FEC) ist ein proaktiver Ansatz, um sicherzustellen, dass die Pakete ankommen. Vereinfacht gesagt, werden mehrere Pakete über unterschiedliche Routen gesendet. Dem liegt die Annahme zugrunde, dass mindestens eines am anderen Ende ankommen wird. Sollten mehrere Kopien eintreffen, werden die zusätzlichen Pakete verworfen.
FEC löst ein Problem, was allerdings seinen Preis hat. Potenziell wird Bandbreite verschwendet, indem zusätzliche Kopien von Paketen übertragen werden, die das Ziel womöglich gar nicht benötigt, weil die Originalpakete ohne Probleme angekommen sind.
Schritt eins. Bitten Sie Ihren Anbieter um Einzelheiten. Was löst FEC aus? Wird es dynamisch als Reaktion auf erkannte Paketverluste scharfgeschaltet? Oder handelt es sich um eine statische Option, die entweder aktiviert oder deaktiviert ist? Können Sie FEC nur für bestimmte wichtige Anwendungen festlegen, oder müssen Sie es für alle Apps auswählen? Wegen des damit einhergehenden Overheads sollten Sie in der Lage sein zu kontrollieren, wie und wann diese Funktion zum Einsatz kommt.
Schritt zwei. Auch hier gilt wieder: Fragen Sie Ihren Anbieter nach Analytics-Optionen. Sie müssen imstande sein, Statistiken über die FEC-Nutzung einzusehen.
Dies kann auch Einblicke in die Qualität Ihrer Verbindungen und der Service-Provider-Links, die Ihr Traffic durchquert, ermöglichen. Idealerweise werden diese Service-Provider ausreichend Bandbreite zur Verfügung stellen, so dass keine User-Pakete verloren gehen. Die FEC-Statistiken können Ihnen dabei helfen, ein Problem zu lokalisieren, das behoben werden muss, anstatt es einfach nur zu patchen, indem man Extrapakete sendet.
SD-WAN-QoS: abschließende Überlegungen
Letztlich lässt sich die große Vision eines Anbieters von Application Delivery nur realisieren, wenn die Technologie im Kern solide und technisch ausgereift ist. Es gibt nur einen Weg, das herauszufinden: Sie müssen verstehen, wie die Technologie funktionieren soll, und dann in Ihrer Proof-of-Concept-Phase überprüfen, ob die Werbung hält was sie verspricht. Denken Sie immer an das alte Sprichwort Vertrauen ist gut, Kontrolle ist besser.
