Office 365 Network Assessment

Ein Network Assessemt 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 Netzwerktopologien 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.

Projektphasen

Jede Änderung an der Nutzung von Office 365, d.h. sowohl eine Neueinführung aber auch eine Freischaltung weiterer Funktionen (z.B. Konferenzen, AzureVMs etc.) sollte immer mit folgenden Phasen seitens des Netzwerks begleitet werden:

  • Abschätzung der Nutzung (Datenmenge und Qualität/Latenz)
    Welche Datenmengen kommen dazu und welche entfallen. Die Differenz ist das, was dann zu simulieren ist.
  • Planung der Simulation
    Eine AudioVerbindung per 3478/UDP unterscheidet sich von einem Outlook MAPI/HTTP Zugriff und einem AzureVM. In der Regel wird das bestehende Netzwerk und Proxy-Server genutzt und erst wenn ersichtlich wird, dass es nicht reicht, entsprechend umgebaut.
  • Bestandsmonitoring anpassen
    Die meisten Kunden haben schon ein irgendwie geartetes Monitoring von Diensten und Verbindungen. Für Office 365 weitere Counter zu addieren bzw. für einen Umbau anzupassen.
  • Test-Plattform aufbauen
    Dann gilt es für die erforderlichen Tests die erforderlichen Systeme an die geeigneten Orts zu platzieren.
  • Test durchführen
    Starten Sie dann die geforderten Tests und beobachten Sie die Messwerte und immer mit der Hand auf dem "Not-Aus", wenn Sie durch die Tests doch die laufende Produktion behindern würden.
  • Ergebnisbesprechung
    Wenn die Simulation erfolgreich war, kann ihr Projekt diesbezüglich starten. Ansonsten gilt es die Hausaufgaben zu verteilen.

Auf dieser Seite versuche ich ihnen etwas die technischen Überlegungen näher zu bringen. Sie sollten selbst oder mit unserer Hilfe erarbeiten, wie umfangreich und genau Sie die Bandbreitenabschätzung und die Simulation und Überwachung gestalten können. 100% sind hier sowieso nicht zu erreichen. Das scheitert schon an der Ungenauigkeit das Verhalten der Benutzer speziell für neue Dienste vorherzusagen. Sie müssen aber doch ausreichend genau diese Schritte durchlaufen um später die Migration und den Betrieb selbst nicht zu gefährden und auch eine Kostenabschätzung für die Wirtschaftlichkeitsberechnung durchführen zu können. Es gibt durchaus Office 365 Projekte, die aufgrund der Anbindungen über viele Monate verzögert werden mussten.

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 Redesign 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-Prem" 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

Office 365 Client Performance Analyzer

Leider ist dies nicht so einfach, da man für einen "Traffic-Check" auch immer eine freundliche Gegenstelle braucht, die die Daten auch liefert und annimmt. Microsoft hat bis vor einiger Zeit dazu sogar einen Office 365 Client Performance Analyzer bereit gestellt.

Der ermittelt im Rahmen einer Momentaufnahme auch einige Performance Werte:

Allerdings ist wie nur eine Momentaufnahme und keine Dauerüberwachung.

Ich habe leider keine Information, welche Proben seitens Office 365 von Hause aus bereit gestellt werden. Es gibt verschiedene Tools, die aber alle nicht auf Dauerlast ausgelegt sind und ein Postfach in der Cloud kann kaum von einem Client mit mehreren Megabit beaufschlagt werden. Selbst der Betrieb einer eigenen Azure-VM ist kein Garant, da hier schon wieder andere Datacenter und Netzwerke involviert sein können.

Netzwerk Performance mit "Fast Track Network Analysis"

Zudem gibt es auch ein Java-basiertes Tool um etwas mehr zu messen. Das Backend ist dazu in drei Regionen gehostet.

Das ist schon mal ein ganz netter Test aber auch nur eine Momentaufnahme und keine Dauerüberwachung. Und der Einsatz ist gar nicht mal einfach, da es Java und ein AddOn braucht, welches zumindest auf meinem System erst eine Warnung verursacht und letztlich doch geblockt wird.

Lync Online Transport Reliability IP Probe - TRIPP (Obsolet)

In der Zeit von ca. 2013-2015 gab es eine weitere Testmöglichkeit, die primär auf Lync ausgerichtet war

Aber auch diese Webseiten sind mittlerweile einfach nicht mehr erreichbar. Microsoft hat nicht einmal eine Weiterleitungsseite auf Alternativen veröffentlicht.

Diese Seite auf TechNet führt zumindest aus, welche Tests durch TRIPP ausgeführt wurden:

  • Geschwindigkeit
    Indem es über 443/TCP Daten herunter und hoch lädt
  • Routing
    Per ICMP (PING) werden die Zwischenstationen abgefragt um z.B. den Leitweg über Provider und die Hops zu ermitteln
  • VoIP Qualität
    Über UDP/50021 und UDP/50022 wird ein G.722-Audio-Datenstrom mit 50 Paketen/Sek simuliert
  • Firewall-Checks
    Zudem prüft das Tool, ob durch die Firewall die Port 443, 3478/UDP (STUN/TURN), 5061/TCP (Federation) und die High-Port 50.000-59999 offen sind.

All das hilft aber nicht, wenn das Backend nicht mehr da ist. Hier der Vollständigkeit halber noch einige andere Links mit schönen Bildern, wie es ausgesehen hat. Eine Ähnlichkeit zum Office 365 Fast Track Network Analysis ist nicht zu verleugnen.

Skype for Business Online Network Assessment Test

Pünktlich zum Artikel hat Microsoft mit dem Skype for Business Online Network ein neues Tool heraus gebracht, welches zumindest die Skype for Business Online-Checks qualitativ einfacher messbar macht.

Mit diesem Tool können Sie Audio-Calls zu Office 365 Edge-Servern aufbauen und die Qualität messen.

Passend dazu habe ich mir einen PRTG-Sensor gebaut, der die Ausgaben dieses Werkzeugs visualisiert

Ü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