Office 365 Network Assessment -Kurzfassung

Ein Network Assessment besteht aus einer Analyse und ggfls. Messungen, um die Fähigkeit des LAN/WAN abzuschätzen eine zukünftige Belastung im Rahmen der Anforderungen zu bedienen. Dazu muss man die geplanten Applikationen und deren Last-Profil ermitteln und vorhandene und geplante Netzwerk-Topologien dagegen stellen. Ein Assessment ist daher erst einmal Ergebnisoffen aber sollte ein Ziel vor Augen haben. Das kann Cloud/Office 365 sein aber auch eine VoIP-Einführung oder jede andere Datenübertragung fokussieren.

Diese Seite befasst sich mit den Optionen zu Messung von Office 365 Performance Werten und mit der Simulation von Last vor einer Office 365 Einführung. Wer Dienste in Office 365 nutzt, belegt damit auf jeden Fall einen Teil seiner Internet-Bandbreite und die ist nicht nur an ihrem Anschlusspunkt zum Provider beschränkt sondern auch der Weg durch das Internet kann steinig und mit Umwegen verbunden sein. Sie tun gut daran, wenn Sie daher die Leistung Richtung Office 365 regelmäßig bezüglich Erreichbarkeit und Performance (Latenz) überwachen.

Sie möchten wissen, wie gut ihr Netzwerk für die veränderten Anforderungen aufgestellt ist?
Mit einem Netzwerk Assessment erarbeiten Sie einen individuellen Maßnahmenplan
https://www.rimscout.com/de/netzwerk-assessment/

Was und wie messen?

Meine Überlegungen starteten damit, dass ich für einen Kunden die Leitung zu Office 365 auf ihre "Leistung" bewerten sollte. Wenn 1000 Anwender mit Outlook und ca. 8 Kilobit/Benutzer/Sek arbeiten, dann kommen das 8 Megabit/Sek als "Grundlast" auf die Leitung dazu. Wenn der Kunde noch kein Office 365 hat, dann würde ich schon mal gerne einfach diese Leistung gegenüber Office 365 abrufen wollen und damit zum einem die Gesamtleistung messen aber ebenso der Internet-Anbindung eben diese Bandbreite wegnehmen. Solange es nur "Test-Daten" sind, können diese schnell wieder abgeschaltet werden, wenn andere produktive Dienste darunter leiden.

Nun hilft es mir natürlich nicht, wenn ich jede Sekunde eine 8kByte-Datei übertrage und die Werte an eine Monitoring-Lösung übertragen. Es muss also eine Vorverarbeitung her, die aus den Daten einige Werte konsolidiert, so dass z.B. eine Meldung pro Minute oder alle 5 Minuten an das Monitoring-System geht, die natürlich Werte mittelt aber dennoch die Ausreißer und Probleme erkennbar macht. Folgende Werte habe ich daher als Rückgabe für ein Messintervall vorgesehen:

  • Durchschnittliche Abrufzeit
    Zuerst bilde ich natürlich einen Mittelwert über die letzten Messungen. Hier erwarte ich Werte um 200-400ms. Viel kürzere Werte deuten auf einen lokalen Proxy oder Cache hin und größere Werte sollten Sie hellhörig machen. Aber einen Mittelwert könnte man auch klassisch mit einer Messung pro Minute erhalten.
  • Anzahl "langsamer Abrufe"
    Durch die Dauermessung fallen sehr zuverlässig auch Anfragen auf, die "zu lange" unterwegs sind, was auch verlorene Pakete einschließt. Ein Paket, was z.B. über eine Sekunde länger als der Mittelwert unterwegs ist, würde ich als "melderelevant" ansehen. Ich würde einfach die Anzahl dieser Pakete pro Messintervall erfassen.
  • Anzahl der Bursts
    Schlimmer als ein einzelner überlanger Request sind mehrere langsame Übertragungen nacheinander. Als Burst würde ich bezeichnen, wenn der Mittelwert der letzten 10 Pakete in Folge sehr hoch ist. Das müssen Anwender noch nicht merken aber ist in Indikator, dass es längere Überlastsituationen gibt. Es ist quasi ein Mittelwert über die letzten 5 Pakete.

Mittelwerte kann man gut errechnen, wenn man sich alle Werte speichert und dann durchrechnet. Es geht aber auch einfacher, weil bei 5 Minuten a 60 Sekunden insgesamt 300 Messwerte zusammenkommen. Jeder einzelne Messwert hat also nur die Bedeutung von 1/300. Ich teile einfach jeden Messwert durch 300 und addiere ihn zum aktuellen Mittelwert, von dem dem ich 299/300 rechne. Beim ersten Start setzt ich den Mittelwert willkürlich auf 300ms, damit er eben nicht bei 0ms anfängt und die Verfälschung höher ist. nach einem Messintervall ist der Fehler quasi heraus gerechnet.

Simulation der Zielbelastung

Unsere Messung mit der Latenz steht aber irgendwie bin ich meinem anfangs genannten Ziel einer generierten Last noch nicht näher gekommen. Ich kann nun die Laufzeit messen und Engpässe vielleicht erkennen. Aber wie bekomme ich die Leitung zwischen meinem Hausnetzwerk und den Office 365-Diensten schon vor dem Produktivbetrieb auf die gleiche Auslastung, wie sie später prognostiziert wurde?

Eine solche Simulation kenne ich schon seit Jahren aus dem Skype for Business Bereich. Dort läuft dies als "Network Readyness Test" und hat das Ziel, möglichst die erwartete Last schon vor der Umstellung zu generieren. Solch eine Simulation kann zwei Dinge lösen:

  • Ist die Anbindung aktuell ausreichend ?
    Es wäre schon unangenehm, wenn Sie gerade die Migration durchführen und plötzlich pausieren oder sogar zurückdrehen müssten, weil die Anbindung die Last nicht bedienen kann. Änderungen und Erweiterungen an Netzwerkstrukturen sind nicht mal eben so schnell gemacht wie eine Servererweiterung durch Disks und andere Hardware. Letzteres kann in Wochen passieren. Eine Änderung einer MPLS-Anbindung oder gar ein anderes Design des Netzwerks mit neuen Internet Ausgängen, neuen Anschlüssen mitsamt Firewalls und Proxies ist eher eine Projekt über Monate.
  • Wie beeinflusst die Last andere Dienste ?
    Aber selbst wenn die Anbindung die neue Last "aushält", so ist es zusätzlicher Verkehr, der andere Übertragungen beeinflussen wird. Gerade eine Priorisierung von Audio kann andere "interaktive" Daten (ICA, RDP, SAP-Gui, Telnet etc.) durchaus beeinflussen

Solange sie simulieren, können Sie die Simulation im Problem- oder Fehlerfall sehr schnell abbrechen. Wenn sie schon mitten in der Migration stecken, dann ist dies nicht mehr möglich.

Sie müssen also zuerst einmal abschätzen, welche Datenmengen anfallen werden und dabei auch berücksichtigen, dass vielleicht andere Datenübertragungen später entfallen. Wer heute Exchange On-Premises mit lokalem Spamfilter nutzt und mobile Client einbindet, kann den SMTP-Traffic, Spams, Viren und die Zugriffe der externen Clients auf den lokalen Exchange Server per OWA, ActiveSync und VPN abziehen. Dafür müssen aber heute intern übertragene Mails und "Scan to Mail" und "Faxserver" natürlich wieder dazu gerechnet werden.

Wenn Sie dann aber ein Mengengerüst ermittelt haben, sollten Sie diese Last auch simulieren. Das Wie ist dann die Frage und hängt sehr stark von ihrer geplanten Zielumgebung ab. Natürlich könnten Sie z.B. in einem Postfach und einer SharePoint-Site eine Testdatei ablegen und diese immer wieder per WGET oder PowerShell abrufen. Allerdings haben alle Microsoft Dienste ein "Throttling". Es wird ihnen nicht einfach gelingen, einen Outlook/Exchange Zugriff von 1000 Menschen mit 8 Megabit dauerhaft mit einem Benutzer zu simulieren. Hier sind ggfls. mehrere Testkonten anzulegen.

Da aber letztlich alle Office 365 Dienste über das MGN - Microsoft Global Network laufen, sehe ich es als legitim an, wenn eine eigens aufgesetzte Azure-VM im gleichen Datacenter als Gegenstelle genutzt werden kann. Hier gibt es zwar auch Kontrollen seitens Microsoft  bezüglich Throttling. Dies sind aber deutlich höher angesetzt. Das mag natürlich auch daran liegen, dass ihre AzureVM ja auch nach Volumen zu bezahlen ist.

Wer also 10MBit Dauerlast anlegen will, muss für 24h (86400 Sek) mit ca. 84 TB pro Tag rechnen. bei 7,3ct/GB sind das dann 74€/TB oder 6216€/Tag. Hier sollte man also schon die Simulation optimieren. Nur gut dass solche "Volumenpreise" nur für Azure VMs gelten und nicht für Outlook, SharePoint etc. Daher sollten Sie zum einen Nutzungsprofile z.B. für die Zeit zwischen 06:00-20:00 definieren und nachts das Volumen drosseln oder den Test pausieren. Aktuell kostet aber nur der "Download" und nicht der Upload von Daten.

In der Regel wird man daher schon eine kurze Zeit einmal schauen, was die Anbindung wirklich bringt aber in der Folge sich auf eine geringere Grundlast mit einer dauerhaften Überwachung der Latenzzeit Beschränkung und nur kurze "Volllast"-Simulationen fahren.

Auch dem Testclient müssen Sie das richtige Arbeitsmittel nutzen. So nutzt "invoke-webrequest" immer nur nur eine IP-Connection (Pooling). Da die meisten Office 365 Protokolle über "443/HTTPS" laufen, muss natürlich auch ihr Proxy Server mit überwacht werden. Ein großer SharePoint-Download hat andere Auswirkungen auf eine Audio-Verbindung mit 50 VoIP-Paketen a 160 Byte

Überlegungen

Ich habe mir daher eine abgewandelte Überprüfung überlegt, die sehr oft eine kleine anonym abrufbare Information von dem Exchange Zugangspunkten abfragt und die Zeit hierfür misst. Es geht nicht um Megabit sondern eher um Kilobit und die Zeit hierzu. Analog zu den anderen End2End-Checks fordert ein PowerShell-Dauerläufer immer wieder Daten an und ermittelt Mittelwerte, Maximal und Minimalwerte. Die über einen Zeitraum gesammelten Daten werden dann zur Auswertung z.B.: in eine CSV-Datei geschrieben oder an PRTG per HTTPPush-Sensor zur Anzeige übermittelt. Als Probe-Endpunkte habe ich folgende URLs bislang genutzt:

URL Größe Statuscode Beschreibung

https://outlook.office365.com/favicon.ico

7886 Bytes

200

Jeder Browser "fragt" nach dieser Datei, um in der Adresszeile ein nettes Icon anzuzeigen

https://outlook.office365.com/mapi/healthcheck.htm

50 Bytes

200

Auf diese Healtchcheck-Anfrage liefert Exchange meist einfach ein "OK"

Die Idee dahinter ist wie bei VoIP-Check, dass die kontinuierliche Überprüfung zum einen "normale Werte" als Vergleichswerte liefert aber auch Verschlechterungen aufgrund übermäßiger Belastungen ebenso sichtbar werden. Wenn ich mag kann ich ja immer noch mal für einige Minuten einen Download von einem SharePoint, OneDrive, Office Groups starten, um die Leitung etwas zu belasten.

Die Abfrage nach der Datei "favicon.ico" habe ich übrigens schon in mehreren Trace-Dateien von Produkten in Form eines "HTTP-Ping"-Check gefunden. Anscheinend ist dies ein durchaus geläufiger Weg Daten von einem WebServer abzurufen ohne aufzufallen.

Verifikation

Ehe ich nun natürlich gleich ins Codieren einsteige, habe ich mir einen kleinen Testpiloten gebaut, der die Abfragen vereinfacht erstellt und erst einmal als CSV-Datei ablegt

while ($true) {
	write-host "." -nonewline
	$starttime = get-date	
	$result = Invoke-WebRequest https://outlook.office365.com/favicon.ico
	$durationms =  ((get-date) -$starttime).TotalMilliseconds
	$bytes = $result.RawContentLength
	"" | Select-Object `
		@{Name="Date";Expression={$starttime.ToUniversalTime().tostring()}},`
		@{Name="durationms";Expression={[math]::round($durationms)}}, `
		@{Name="KBit/sec";Expression={[math]::round($bytes/$durationms*10)}}
	start-sleep -milliseconds ([math]::Max(1000-$durationms,0))
}

Beim Aufruf habe ich die Daten mit " | export-csv -notypeinformation" in eine Datei schreiben lassen und dann mit Power Bi ausgewertet. Hier ein Schnappschuss:

  • Verteilung der Dauer des Abrufs
    Hier zeigt sich fast die übliche Normalverteilung. Es gibt ganz links eine Grenze, die einfach nicht unterschritten werden kann, weil Entfernung und Router immer Millisekunden addieren.

    Und die meisten Requests sind zwischen 200-400ms unterwegs aber einige brauchen auch etwas länger. Nicht sichtbar ist der Ausschlag bei 10.000ms, wenn ein Request gar nicht ankommt.
  • Durchsatz mit Latenzzeit
    Neben der Anzahl der Pakete bezogen auf ihre Laufzeit ist natürlich eine Übersicht nach der Datenmenge interessant.

    Die auch hier ist gut zu sehen, dass die meiste Datenmenge zwischen 200-300ms Laufzeit übertragen werden.
  • Zeitliche Verteilung
    Ich habe den Pilot nur von 21:00 abends bis 08:00 morgens an meinem Home-DSL-Anschluss lassen. Insofern ist es noch nicht  repräsentativ aber erkennbar sind Peaks, bei denen die Anfrage sehr viel länger gedauert hat.

    Aber genauso bewegen sich die meisten Anfragen zwischen den bekannten 200-400ms.

Es gibt also durch diese Messwerte durchaus interessante Einblicke aber so sind die Daten natürlich noch sehr rudimentär. Gerade bei der die Anzeige über die Zeit gegen Aussetzer durch die Zusammenfassung einfach unter. Insofern sind hier Min/Max-Werte zusätzlich zu erfasst und als eigene Linie anzuzeigen. Die Probemessung hat mir aber auch gezeigt, dass aktuell Office 365 solche Daueranfragen nicht sanktioniert, d.h. meine IP-Adresse wurde weder gebockt noch wurde der Datendurchsatz gedrosselt. Vielleicht bin ich mit meinen 200kbit aber auch einfach nicht aufgefallen.

Auf der anderen Seite ist "Invoke-WebRequest" ausreichend, um mit wenig CPU-Last eine ausreichend schnelle Abfrage zu stellen. Ein ICMP-Ping schafft allein das Default Gateway auf meinem PC maximal 400kBit/Sek und ist deutlich weniger aussagekräftig. Und selbst mit einer TCP-Klasse die Daten abzurufen ist mir dann doch zu aufwändig.

Zukunft

Je mehr Firmen auf Office 365 setzen, desto wichtiger und auch kritischer ist eine entsprechend qualifizierte Anbindung. Microsoft tut viel mit seinem MGN - Microsoft Global Network, um die Wege vom Kunden zu Office 365 "kurz" zu halten und damit fremde Einflüsse zu reduzieren. Dennoch sollten Sie nicht einfach "drauf los legen", sondern zumindest die erwartete Bandbreite abschätzen und dann auch einmal simulieren. Die Erfassung der vitalen Betriebsdaten sollten die dann aber als Dauerüberwachung umsetzen, damit Sie auch später im laufenden Betrieb schnell erkennen können, ob sich die Leistung verschlechtert oder sogar Unterbrechungen vorlagen.

Wir helfen ihnen gerne bei der Analyse ihrer Office 365 Anforderungen, der Ermittlung von erforderlichen Bandbreiten und der Umsetzung entsprechender Messungen und Simulationen. Sprechen Sie uns einfach an: www.netatwork.de

Weitere Links