Network Assessment: Belastungssimulation

Für den nächsten Schritt gehen wir davon aus, dass das Netzwerk angeblich "fertig" ist und die Benutzer theoretisch migriert werden könnten und dann mit dem neuen Zielsystem arbeiten können. Ehe wir aber nun die echten Anwender zum Versuchskaninchen erklären, wollen wir mit eigenen Test erst einmal das aktuelle Setup überprüfen. Genau genommen wird man so einen Check auch nicht erst kurz vor der Migration machen sondern früher und vielleicht sogar mehrfach wiederholen, wenn das Netzwerk anhand der Informationen verändert worden ist.

Aber dieser synthetische Test hat das Ziel einmal zu zeigen, dass die erwartete Workload wirklich auch bedient werden kann aber vor allem auch, dass durch den zusätzlichen Verkehr andere Dienste dennoch weiter abreiten können. Wir haben nichts gewonnen, wenn z.B. Office 365 perfekt funktioniert aber eine andere Anwendung darunter leidet.

Auswahl der Standorte

Mit den Daten aus den Personas, den Standorten und den Verkehrswegen können wir nun einige Standorte ermitteln, die einer Belastungssimulation unterzogen werden sollen. Auch hier gilt es speziell in größeren Firmen eine Vorauswahl nach "repräsentativen" Standorten zu treffen. Es macht keinen Sinn, jeden Standorte komplett zu vermessen. Die Kosten und der Aufwand wären nicht zu rechtfertigen und das Projekt würde verzögert werden. Aus meiner Erfahren hat eine Firma immer einige Standorte, die sehr ähnlich sind, weil Sie die gleiche WAN-Anbindung haben und meist sogar vergleichbare Mitarbeiterzahlen und Verteilung der Personas. Für ein Netzwerk Assessment kann ein Standort im Test reichen um die Werte auf alle gleichartigen Standorte hochzurechnen.

Testaufbau

Im nächsten Schritt müssen Sie natürlich "etwas" nutzen, was in den ausgewählten Standorten auch die Belastung generieren kann. Wenn wir ein Assessment Richtung Office 365 initiieren sollen, dann geht das nicht ohne eine oder sogar mehrerer aktiver Komponenten in den geplanten Standorten. Wenn es primär um ein internes Assessment mit einer überwiegend sternförmigen symmetrischen Simulation geht, dann reicht vielleicht ein System in der Zentrale, welches im einfachsten Fall entsprechende ICMP-Pakete an Router oder andere IP-Geräte in den Standorten sendet, die diese dann wieder zurück senden. Dann verliert man natürlich Funktionen wie unidirektionale Messungen oder asymmetrische Lasten.

Zudem gibt es je nach Software zur Simulation und Messung ebenfalls unterschiedliche Ansätze. Die eine Software kann nur ICMP-Pings während eine andere Software entsprechende Agenten zur Installation von vorhandenen Windows Clients mitbringt. Wieder andere Produkte haben eigene "Hardware-Probes", die erst vor Ort versandt und angeschlossen werden müssen. Ich habe sogar schon Raspberry-Systeme und ESP8266-Wifi-Geräte als "Node" gesehen, wobei man hier bedenken muss, dass diese Kleinrechner schneller an Bandbreitengrenzen und eine Verarbeitung stoßen. Sie sind also eher für Qualitätsmessungen geeignet.

Der zweite Schritt besteht darin die geplanten Belastungen und Verkehrsströme entsprechende zu parametrisieren, damit diese im späteren Testlauf auch angewendet werden. Auch dieses Aufgabe kann ziemlich komplex werden. Oft ist es eben nicht damit getan, die aus den Personas abgeleiteten Datenmengen stumpf auf die Leitung zu legen, sondern Sie müssen speziell in geografisch verteilten Firmen auch die Tageszeit einbeziehen. Zudem haben wir ja kein "leeres" Netzwerk vor uns. Wer ein VoIP-Assessment macht,. muss überlegen, welche andere VoIP-Daten der vielleicht bestehenden Plattform schon die Leitung nutzen und später in der Produktion ersetzt würden. Entsprechend niedriger müssen Sie die simulierte Last wählen. Dazu gehört natürlich auch die entsprechende Kennzeichnung der Testpakete per DSCP/QoS und Behandlung der Pakete auf Routern. Diese Konfiguration kostet oft mehr Zeit als ursprünglich veranschlagt.

Der dritte Faktor ist die Zeit. Ein sollte mindestens eine komplette Woche dauern, um möglichst alle zyklischen Einflüsse zu erfassen. Die Erfahrung zeigt, dass längere Tests die Ergebnisse nicht mehr signifikant verändern. Wichtiger ist, das Sie diese "Woche" passend auswählen. Es ist verständlich, dass Weihnachten, Osterwoche und andere Feiertage keine guten Testzeiträume sind. Aber beachten Sie auch Zeiten, in denen andere Prozesse das Netzwerk temporär besonders belasten. Dazu gehören z.B. grö0ere Rollouts von Updates oder Clients,

Sie sehen also, dass es hier keine Blaupause gibt, sondern die Erfahrung des durchführenden Unternehmens erforderlich ist und die verwendete Software richtig ausgewählt und eingesetzt werden muss.

Testlauf

Dann ist der große Moment gekommen, dass Sie die geplante Belastung auch simulieren. Alle beteiligten Personen sollten die entsprechender Aufmerksamkeit darauf richten und sich ausreichend Zeit für die Mitarbeit reservieren. Relevant sind hierbei:

  • Helpdesk
    Sie sollten für den Belastungstest sensibilisiert werden, so dass "Probleme", die mit Bandbreite zusammen hängen könnte, zügig an das Team geleitet werden
  • Netzwerk/Monitoring
    Die Last durch das Assessment wird sich auf im Regelmonitoring wiederspielen. Ansonsten wäre das Assessment gar nicht erforderlich gewesen. Hier ist eine Rückmeldung bezüglich deren Beobachtungen aber auch bei Alarmen notwendig. Das Netzwerkteam kann diese definierte Last natürlich auch nutzen, um ihr eigenes Monitoring und Accounting zu überprüfen.
  • Assessment Team
    Diese Personen sollten die ganze Zeit zumindest erreichbar sein. Der wichtigste Punkt ist hier nämlich der "Not-Aus", wenn das Assessment tatsächlich den produktiven Betrieb stören sollte und das Assessment abgebrochen werden muss. Aber auch während des Assessment sollte regelmäßig überprüft werde, dass die Belastungen wie erwartete generiert werden und wie sich die Zwischenergebnisse diesbezüglich verhalten

Im Idealfall "merkt" niemand das Assessment, wenn das Netzwerk ausreichend Reserven hat und natürlich die Priorisierung korrekt umgesetzt wurde.

Auswertung

Die schnellste Art der Auswertung ist ein Abbruch des Assessment aufgrund der direkten Auswirkungen auf den Betrieb. Das ist dann in etwas so wie ein nicht bestandener TÜV beim Auto und Sie müssen zurück zur Werkstatt. Sie sollten dann nicht traurig sein sondern eher froh, dass Sie das nicht ausreichende Netzwerk anhand der Testdaten schon erkannt haben und nicht erst, wenn Sie die ersten produktiven Benutzer mit ihren Daten auf Cloud-Dienste umgestellt haben.

Aber auch wenn die Simulation die kompletten 7 Tage oder mehr durchgelaufen ist, ist das ja noch keine Garantie auf "Bestanden". Auf der einen Seite können Sie natürlich sagen, dass die anderen Nutzer sich zumindest nicht ausreichend laut beschwert haben, als dass es bei ihnen angekommen wäre. Das kann aber auch nur Hinweis darauf sein, dass die Priorisierung im Netzwerk dafür gesorgt hat, dass die anderen Dienste ausreichend schnell bedient wurden.

Nun ist erst recht eine Analyse der Simulationsergebnisse erforderlich. Hier ist zu prüfen, welche Datenmengen tatsächlich in welcher Qualität übertragen wurden, d.h. ob die erforderlichen Belastungen erreicht wurden. Im nächsten Schritt ist auszuwerten, ob die real übertragenen Daten auch in der erforderlichen Qualität transportiert wurden. Schließlich wollen wir ja sicher sein, dass die spätere Nutzlast wie erwartet möglich ist.

Letztlich gibt es am Ende nur die Frage, ob das "Network Assessment" bestanden wurde oder nicht. Wenn ja, dann kann es weiter gehen und wenn nein, dann reicht es nicht die Messung immer und immer wieder zu wiederholen, bis sie einmal bestanden wird. Das wäre vergleichbar mit dem Wiederholen des TÜV bis sie mal einen gnädigeren oder weniger peniblen Prüfer finden. Aber genauso wenig, wie sie sich mit so einem "durchgerutschten" Fahrzeug wohlfühlen, sollten Sie ein Office 365 Projekt weiter führen.

Abschluss aber kein Ende

Selbst mit "bestandener" Prüfung bleibt das Thema Überwachung in Form einer Grundlastmessung erhalten. Sie sollten nicht darauf vertrauen, dass ihre Anwender als "Sensoren" agieren und die Qualität der Verbindung unvoreingenommen melden. Allerdings wird die Messung nicht mehr mit voller Last erfolgen, da nun die echten Daten schon einen Großteil der Bandbreite auffressen. Aber sie müssen natürlich auch Veränderungen im Benutzerverhalten kontinuierlich im Blick haben und ggfls. nachsteuern. Aber das sollte ein guter Netzwerkbetreiber heute ja auch schon machen und ist keine Office 365 Besonderheit.

Weitere Links