Wie viel WAN-Bandbreite ist genug?

Alles, was man mmitel_world-cloudessen kann, kann verbessert werden. Aber in vielen Fällen ist das reine Hinzufügen von Bandbreite nicht genug.

Die Bestimmung der benötigten Bandbreite für eine bestimmte Anwendung oder einen Service ist nicht einfach. Noch komplizierter ist die Definition der realen Bandbreitenanforderungen von Unternehmen. Meist findet man keine einfachen Antworten und nur eine Unzahl sich widersprechender Meinungen und zahlreiche nutzlose Berechnungsprogramme. Die FCC definiert die Schwierigkeiten zur Beschreibung der Anforderungen an die Verkehrsflüsse wie folgt: Beim Internetverkehr müssen wir mit einer Vielzahl von Variablen umgehen. Die statistische Natur der Variablen und deren Variationen erschweren die Entwicklung eines realistischen mathematischen Modells, das den zu transportierenden Netzwerkverkehr voraussagen kann.

Die Hersteller von Netzkomponenten und Netzwerkdienstleister definieren jeweils ihre eigenen Bandbreitenempfehlungen. Bei genauer Betrachtung bemerkt man jedoch, diese Empfehlungen versagen in der Regel bei einer universellen Verkehrsmodellierung.

Die Diskussion um die richtige Verkehrsmodellierung dreht sich meist um einige wenige Anwendungen, die über ein WAN übermittelt werden. Bei der Übermittlung von Unified-Communications- (UC-)Strömen – bei der Sprache, Daten und Video gesendet werden — versagen die gängigen Empfehlungen.

Experten glauben, dass der Einsatz von Cloud-Business-Intelligence (BI) zur Verbesserung der Verkehrsmodellierung beitragen könnte. Der Umzug in die Cloud entscheidet bei vielen Unternehmen indirekt, über die Fähigkeit ihre Geschäfte auf einer höheren Ebene abwickeln zu können. Im Fall der Verwendung von Cloud-BI zur Verkehrsmodellierung führte ich vor kurzem eine Diskussion mit einem IT-Dienstleister über das Firewall-Monitoring aus der Cloud. Beim Firewall-Monitoring werden sämtliche Daten über den eingehenden und abgehenden Verkehr sowie der Gesamtdurchsatz gesammelt. Ein nächster Schritt könnte das Einrichten eines visuellen Dashboards sein, welches die WAN-Verbindungen und die Egress- und Ingress-Verkehre anzeigt. Es würde der tatsächliche Durchsatz und die prozentuale Nutzung jeder Verbindung dargestellt. Fügt man die vielen anderen Informationen über die verschiedensten Verkehrsarten und deren repräsentative Nutzung hinzu, könnte man schnell ein Bild der aktuell verbrauchten Bandbreite skizzieren.

Die Verbindungen zwischen den jeweiligen Kommunikationskomponenten, sei es zwischen Switch-Stacks, Servern, Routern oder ISPs, repräsentieren nur einen Teil des Gesamtbildes, das für die Verkehrsvorhersage benötigt wird. Dadurch weiß man zwar die aktuelle Ausnutzung der WAN-Verbindung. Aber dieses Wissen nützt wenig. Obwohl man nur 60 Prozent der verfügbaren Bandbreite nutzt, kann man trotzdem nicht davon ausgehen, dass man genügend Bandbreite hat. Die Grenzen sind fließend. Verringert man die Verzögerung, erhält man nicht immer unbedingt mehr WAN-Bandbreite. Das ist eine falsche Annahme, die Unternehmen immer wieder machen, wenn sie versuchen ein langsam arbeitendes Netzwerk zu reparieren.

In der Praxis gibt es eine Reihe von potenziellen Engpässen bzw. Ursachen für die Performance. Hierzu gehören:

  • Verarbeitungsverzögerungen der Server.
  • Verarbeitungsverzögerungen der Clients.
  • Bandbreitenengpässe.
  • Überlasten.
  • Paketverluste.
  • Flusskontrolle in der Empfangsrichtung (Window 0).
  • Das Window- und das Bandbreiten-Verzögerungsprodukt.
  • Geschwätzige Protokolle in Verbindung mit hohen Verzögerungen.
  • Flusskontrollen auf der Anwendungsebene (Application-Windowing).
  • Der Nagle-Algorithmus.
  • Der TCP-Slow-Start-Algorithmus.

Aus diesen Gründen müssen wir verstehen, was und wie wir unsere Daten erheben bzw. messen. Eine meiner Beobachtungen ist beispielsweise, dass die Performance des Betriebs am Schnittpunkt zwischen Geschäfts- und IT-Metriken ermittelt werden sollte. Da die Unternehmen gezwungen sind ihre Betriebs- bzw. Reparaturkosten zu reduzieren, wird in Monitoring-Systeme investiert, um dadurch die manuellen Tätigkeiten bei der Fehlerermittlung und der Lösung von Netzwerk-Fragen so weit wie möglich abzubauen.

Dies hat natürlich Auswirkungen auf die Netzwerk-Performance und das subjektive Empfinden der Nutzer in Sachen Leistung. Dies beantwortet jedoch nicht die Fragen der Bandbreite. Von beiden Seiten des lose definierten Abgrenzungspunktes wird die Beseitigung von Engpässen und die Reduzierung bzw. der Minimierung von Verzögerungen eine Rolle bei der Bandbreitenanforderung spielen. Vorhersagen der Verkehrsvolumen zu Spitzenzeiten bzw. der Spitzenbandbreitenanforderungen sind und bleiben auf Schätzungen angewiesen. Untersucht man nur die Auslastung eines WAN-Links, dann gibt dieser Wert nicht die notwendigen Hinweise. Man lernt daraus nicht, wie viel Bandbreite ma
n benötigt. Auch andere neuartige Lösungsansätze funktionieren mehr schlecht als recht.

Mathias Hein, Consultant, Buchautor, Redakteur
Mathias Hein, Consultant, Buchautor, Redakteur

Stattdessen sollte man sich auf den reinen Verkehrsfluss konzentrieren. Man reduziert am besten die Verzögerung und versucht die Konfigurationen zu optimieren, um sicherzustellen, dass der Verkehr über das Netzwerk effektiv und effizient übermittelt wird. Das Verlangen nach immer mehr Bandbreite ist ähnlich dem Verlangen nach immer mehr Spektrum. Die Alternative beider Parameter ist die Verbesserung der Effizienz. Alles, was messbar ist, kann verbessert werden. Aus diesem Grund sollte immer ein Blick auf die Datenflüsse und deren Auswirkungen auf die Performance geworfen werden, anstatt nur die Bandbreite zu erhöhen. (mh)