´╗┐ Network Assessment: ├ťberlegungen

Network Assessment: Überlegungen

Auf der Seite Network Assessment:Warum habe ich versucht "nicht technisch" die Argumentation für ein Assessment zu führen. Auf dieser Seite möchte ich einfach mal eine Fragestellung eines Administrators bei einem Kunden und die technische Erklärung der Herausforderungen beschreiben.

Wie definiert sich ein "Network Assessment"

Bei einem Network Assessment geht es darum ein bestehendes Netzwerk auf seine Leistungsfähigkeit hinsichtlich einer geplanten Produkteinführung oder Änderung des Netzwerks zu bewerten. Es ist quasi vergleichbar mit der Testfahrt in einem Auto oder der Probelauf einer Maschine. Man versucht möglichst realistisch etwas zu simulieren und zu testen ohne allzu große Risiken einzugehen. Vor allem arbeitet man nicht mit produktiven Daten und man kann jederzeit den Lauf abbrechen, wenn es zu Störungen kommt.

Es gibt aber nicht "das eine Assessment". Ein Assessment ist immer an dem Ziel auszurichten. So habe ich in der Vergangenheit sehr unterschiedliche Assessments begleitet, z.B.

  • UC Assessment
    Hierbei ging es in der Vergangenheit immer darum zu klären, ob ein Netzwerk "Ready für Unified Communication" ist. In der Regel ging es um die Einführung von Lync oder Skype for Business. Hierbei kommen VoIP und Audio/Video-Echtzeitdaten auf ein Datennetzwerk mit 1:1 Verbindungen zwischen Clients oder 1:n Verbindungen bei Konferenzen. Die Belastung des Netzwerks unterscheidet sich grundlegend von dem klassischen Serverbetrieb.
  • Office 365 Assessment
    Durch den Erfolg der Cloud stellen sich hier auch wieder neue Herausforderungen. Es geht hier mehr um Datenmenge und TCP-Sessions, Bandbreite und Performance auf dem Übertragungsweg im Internet und meist ändert sich hier auch das komplette Netzwerkdesgin von einem zentralen Internetausgang zu dezentralen Übergängen und einer Entlastung von internen Leitungen wenn die Server "draußen" stehen

Das sind zwei einfache Beispiele, warum es bei einem Netzwerk Assessment nicht damit getan ist, eine Software zu installieren und "GO" zu drücken. Ich möchte das an ein paar Beispielen verdeutlichen.

So fängt es an

Wir gehen davon aus, dass der Kunde heute natürlich schon ein Netzwerk samt Internet-Anbindung hat und z.B. ein HTTP-Proxy den Zugang zum Internet bereit stellt. Das Bild sieht aktuell so aus:

Nun werden ihre Mitarbeiter sicher nicht die ganze Zeit bei Twitter, Facebook, NetFlix und YouTube unterwegs sein. Das sind ja auch nur "Beispiele" und welche Dienste ihre Anwender wir intensiv nutzen, können Sie ja selbst ermitteln. Die meisten Firewalls klassifizieren die Zugriffe anhand der Ziel-IP oder Namen im TLS-Handshake. Ich habe hier aber schon mal exemplarisch vier unterschiedliche Kommunikationsarten aufgezeigt.

  • Mail (SMTP) Bidirektionale nicht interaktive Kommunikation
    Der Anwender merkt nicht direkt, wenn die Verbindung "langsamer" ist oder eine Zustellung eine kurze Zeit verzögert wird. Es werden größere Datenmengen empfangen aber auch gesendet.
  • WebSurfen
    Anwender senden in der Regel geringe Anfragen nach extern und bekommen mehr oder minder umfangreiche Webseiten (eher Kilobyte statt Megabyte) zurück, die Sie dann lesen. Die Last ist also eher stoßweise je User aber bei vielen Benutzern verteilt sich das zu einem gleichmäßigen Level. Dennoch sollte die Antwortzeit (Latenz) gering sein, da der Anwender im Browser direkt sieht, wie "schnell" die Antwort ist. Immer mehr Webseiten nutzen intensiv clientseitiges JavaScript, um Eingaben und Bedienung fast wie eine normale Desktopapplikation wirken zu lassen. Auch hier sind sollten die Antworten auf Anfragen nicht zu lange unterwegs sein. Das ist zwar keine Realtime-Kommunikation im Bereich von 10-200Millisekunden aber Sekunden sind gefühlt schon lange.
  • WebDownload
    Downloads von Dateien sind viel asymmetrischer, d.h. der Request zur Seite ist klein aber die heruntergeladene Datenmenge deutlich größer. Das können auch Megabytes und Gigabytes sein. Der Anwender ist es aber gewohnt, dass der Download nicht mit 1GBit erfolgt und der Download auch etwas länger dauern kann. Er darf natürlich nur zu langsam erscheinen, da der Anwender den Durchsatz immer im Blick hat und eine Erwartungshaltung hat. Allerdings merkt er nicht, wenn in temporären Überlastsituationen andere Datenpakete priorisiert würden und der Download gedrosselt wird. Allerdings kann technisch der Download nicht direkt sondern nur indirekt über verzögerte TCP-ACK-Pakete kontrolliert werden.
    Eine "besondere" Klasse an Webdownloads sind Systemdienste im Hintergrund wie z.B. Windows Update und Antivirenprodukte (Patternfiles), die auch viel Bandbreite belegen aber zumindest für Teile auch in die Nachtstunden verlagert werden können.
  • Streaming
    NetFlix und Internetradio sind vermutlich eher etwas für den Heimbereich aber Streaming-Daten kommen auch in Firmen vor. Immer mehr Informationen werden über externe Schulungsportale aber auch YouTube bereit gestellt und konsumiert. Anders als bei einem Download werden die beim Streaming übertragenen Daten nur bis zur Wiedergabe gepuffert. Wenn mehrere Personen die gleiche Information nutzen, wird sie mehrfach übertragen. Allerdings erlaubt der Puffer auch, die Daten temporär für wenige Sekunden auszubremsen ohne dass der Anwender dies direkt merkt.

Die Aufzählung ist bei weitem nicht vollständig. So sind VPN-Clients, VPNs zu anderen Standorten, Mobile Benutzer per ActiveSync und OWA von außen und viele andere Workloads noch gar nicht aufgeführt worden. Schon in diesem Umfeld gibt es also Herausforderungen ein faires und harmonisches Nebeneinander der Dienste zu erreichen. Doch wie erreicht man das ?

Priorisierung, Drosselung, Reglementierung

Wenn man "genug" Bandbreite" hat, dann kann man sich um andere dringlichere Dinge kümmern bis diese Baustelle dann etwas später wieder aufbricht. Sie sollten aber trotzdem mal ein paar Gedanken darauf verschwenden.

  • Netzneutralität - Alle sind gleich
    Das ist die Standardeinstellung, die vermutlich bei den meisten Firmen immer noch aktiv ist. Die Pakete werden ausgehend in einem FIFO-Prinzip über die Leitung übertragen und auch eingehend sendet der Provider die Antworten zurück. Das Problem dabei ist offensichtlich: Wenn ein Dienst viele Pakete sendet, dann belegt er auch viel mehr Bandbreite. Solange genug Platz da ist, werden alle anderen Pakete vielleicht etwas verzögert aber das ist kaum merklich. Es wird aber immer deutlicher spürbar, je voller es auf der Leitung wird. Sie können also nicht warten, bis die Auslastung bei 99% ist und dann noch darauf verweisen, dass ja immer noch 1% Luft wäre. Das Warten auf die nächste freie Lücke dauert dann doch zu lange. Vergleichen Sie es einfach mit einer Autobahn. Der "Stau" beginnt schon viel früher.
  • Drosseln auf der Senderichtung
    Für moderne Firewalls und Router ist es kein Problem, die Paket auf dem Versand gemäß ihrer Priorität einzuordnen und zu übertragen. Voraussetzung ist natürlich ein passendes Bandbreitenkonzept, welches die Prioritäten vorgibt.
  • Prioritäten und Obergrenzen
    Es reicht nicht, die Pakete unterschiedlich zu priorisieren. Sie müssen auch Obergrenzen definieren, da sonst die höher priorisierten Pakete bei entsprechender Menge alle anderen Pakete quasi verdrängen. Insofern ist eine Obergrenze erforderlich, ab der diese Pakete eben nicht mehr priorisiert oder sogar gar nicht mehr (DROP) übertragen werden. Bei VoIP ist es besser die überzähligen Pakete einfach zu verwerfen. Die Endpunkte "merken" das und werden damit gezwungen ggfls. durch einen Wechsel des Audio-Codecs oder der Video-Auflösung weniger Bandbreite zu verwenden. Allerdings sollte ihr Lösung nun nicht einfach UDP-Pakete verwerfen sondern sollte schon versuchen die verschiedenen Streams fair zu behandeln. Über entsprechende Ports und Codec-Definitionen können Audio und Video unterschieden werden. Für TCP-Verbindungen ist ein Drop von Paketen natürlich kontraproduktiv, da diese dann die Pakete einfach erneut senden und damit unter Strich durch Retransmit und ACK sogar mehr Daten produzieren.
  • Statische Grenzen sind nicht gut
    Jede statische Grenze hat wieder das Problem, dass Sie vielleicht Bandbreite ungenutzt lassen. Was hilft ihnen eine 100 Megabit-Leitung, auf der Audio priorisiert wird aber zum Schutz der anderen Verbindungen eine Obergrenze von 10MBit hinterlegt ist? Es wird der Fall eintreten, dass Audio die 10 Megabit erreicht aber niemand anderes die 90MBit aufbraucht. Dann wäre es doch blöde Pakete aufgrund dieser statischen Grenze zu verwerfen. Sie müssen also überlegen, ob sie die Pakete über dem Limit dann auf die Restbandbreite aufteilen oder einfach nach "Best Effort" übertragen.
  • Eingehende Verkehr per "Late ACK"
    Wenn Sie keine Kontrolle über die andere Seite ihrer Leitung haben, dann könne sie dort keine Priorisierung vornehmen. Vielleicht kann ihr Provider hier unterstützen aber ohne entsprechende Vorgaben wird es schwer hier eine Lösung zu finden. RTP-Pakete (Audio/Video) aus dem Internet und Office 365 werden nicht über entsprechende QoS-Tags verfügen. Sie können aber zumindest die TCP-Verbindungen indirekt steuern. Jede TCP-Verbindung arbeitet mit Quittungen und wenn ein großer Download ihre eingehende Leitung überlastet, dann sollte ihre lokale Gegenstelle einfach die TCP-ACK-Pakete verzögern. Damit können Sie indirekt der Gegenseite signalisieren, dass er zu schnell sendet. Das ist ein gängiges Verfahren da es auch im Internet langsamere und schnellere Zwischenstrecken gibt. Es ist allemal besser als eingehende TCP-Pakete zu verwerfen. Wir simulieren damit quasi, dass ihre Leitung für diese Übertragungen kleiner ist, also sie tatsächlich ist. Do bleibt Platz für die anderen wichtigen Pakete.
  • Minimalbandbreite und Over-Subscription
    Wenn Sie alle Forderungen nach "garantierter Bandbreite" aufaddieren, könnten es sein, dass Sie mehr Bandbreite reservieren als zu verteilen ist. Hier ist also abzuwägen, wie viel Bandbreite tatsächlich gleichzeitig genutzt wird. Sie können nämlich auch versuchen einen Korridor zu definieren, d.h. eine Anwendung bekommt eine garantierte Mindestbandbreite, damit Sie ausreichend gut funktioniert und alles drüber unterliegt dann dem freien Verteilungskampf. Vermeiden Sie aber auch hier die Situation, dass die Minimalbandbreite "fre gehalten" wird. Dann verschenken Sie etwas.
  • Unerwünschte Verbindungen unterbinden
    Ein wichtiger Faktor bei einer Bandbreitenplanung ist die Blockade von überflüssigen Verbindungen. Wer kein Dropbox in der Firma nutzen will, kann diese Ziele komplett blocken. Aber auch Windows Updates und Office Updates sind hier ein großer Brocken. Natürlich können ihre Clients sich die Office-Updates (Word, Excel etc.) aus der Cloud beziehen. Aber bitte nur, wenn Sie "draußen" sind. Im internen Netzwerk gibt es dazu interne Verteilpunkte. Auch Windows Updates muss ein Client oder Server nicht direkt aus dem Internet beziehen, wenn es intern einen WSUS-Server gibt. Vergessen Sie aber nicht den WSUS-Server hier als Ausnahme zu definieren. Wenn Sie diese Ziele nicht komplett sperren wollen, dann sollten Sie zumindest mit niedrigster Qualität definiert sein.
  • Überwachen
    Ob Sie alles richtig eingerichtet haben, sollten Sie mit einer passenden Überwachung der Datenverkehre abrunden. Ideal ist, wenn Sie z.B.: per NetFlow / sFlow / IPFix die verschiedenen Prioritätsklassen erfassen und so gezielt sehen, das ihr Regelwerk greift.

Das ganze Thema können Sie unter dem Arbeitstitel "Bandbreite Konzept" führen. Es beschränkt sich nämlich nicht nur auf die Anbindung zum Internet zur Office 365 sondern gilt genauso im LAN und internen WAN

Gamechanger Office 365

Mit Office 365 ändern sich die Regeln dahingehend, dass die Anwender natürlich die gleiche Qualität erwarten, wie sie bisher mit der Arbeit der On-Premises-Server gewohnt waren. Das bedeutet für Sie direkt, dass alle Anwender, die bislang mit Exchange vor Ort gearbeitet haben, nun mit Exchange Online arbeiten. Schauen Sie sich doch mal die Datenströme vorher und nachher allein in Bezug auf Exchange Online an.

Ihr Exchange Server steht im Mittelpunkt und wird von allen Seiten angesprochen. Mit dem Umzug nach Office 365, bei dem ich die Migration der Inhalte unter den Tisch fallen lassen, ändert sich der Verkehr grundlegend.

Lokale Verbindung zum Backup-Server und Domaincontroller entfallen. Auch der Mailfluss per SMTP zu und von anderen Services im Internet entfällt. Je nach Spamfilter-Lösung entlasten Sie ihre Internet-Anbindung und auch die externen Clients können bei passender Konfiguration des VPN direkt mit der Cloud sprechen. Dafür kommt zu vernachlässigender Authentifizierungs- und AADConnect-Traffic dazu. Der große Batzen ist aber der Client-Traffic der der internen Anwender, die nun natürlich mit der Cloud kommunizieren müssen. Das betrifft den Regelverkehr neuer Mails aber auch die Synchronisation von OST-Dateien. Natürlich ist MAPI erst einmal unkritisch im Bezug auf die Latenzzeit. Email ist kein Echtzeitmedium, auch wenn viele Anwender das gerne anders verstehen. Aber sie kommen natürlich schon in Argumentationsnöte, wenn eine Mail zwischen zwei Schreibtischen im gleichen Büro mehrere Minuten unterwegs ist.

Hier ist es also wichtig für Outlook eine Mindestbandbreite vorzusehen, damit die Funktion auf jeden Fall sichergestellt ist. Für andere Kommunikationen, z.B. Microsoft Teams, gelten wieder andere Grenzen. Diese Betrachtung ist für jede Anwendung gesondert durchzuführen.

Der dicke "Office 365 Stream" besteht aus einer Summe von Diensten, an die unterschiedliche Anforderungen gestellt werden und die ihrerseits höchst unterschiedliche Anforderungen an die Übertragungsleistung stellen.

Wir müssen reden!

Mit Office 365 wird die Baustelle "Internetanbindung" auf jeden Fall aufbrechen, denn hier nimmt die Datenmenge während der Migration aber auch im späteren Betrieb dauerhaft zu. Wir brauchen also ein Bandbreitenkonzept, welches ...

  • ...die verschiedenen Datenverkehre zusammenfasst und klassifiziert
  • ... für jede Gruppe eine Mindestbandbreite und Priorisierung vorsieht
  • ... Pakete drüber raus nicht weiter priorisiert
  • ... die erwarteten Anforderungen vorab anhand der bestehenden Server und vermuteten Anwendungen schätzt
  • ... die erwarteten Lasten simuliert

Und damit sind wir komplett im Thema "Planen einer Office 365 Netzwerkinfrastruktur". Ein Bestandteil davon ist das Netzwerk Assessment.

Weitere Links