Network Assessment für Skype for Business

Diese Seite basiert auf verschiedenen Vorträgen von Microsoft zum Thema Network Assessment in Verbindung mit Lync und Skype for Business On Prem. Viele Dinge davon können auch für Office 365 genutzt werden.

Nach mehreren Projekten mit Kunden schlage ich eine etwas veränderte Vorgehensweise für Office 365 (Siehe Network Assessment: Office 365) vor.

Übrigens: Genaugenommen ist so ein Assessment nicht für Lync und Skype for Business erforderlich sondern auch für viele andere Dienste sinnvoll. Allerdings merken Anwender ein schlechtes Netzwerk mit Audio und Video sehr viel schneller als bei reinem Datenverkehr, der dann einfach etwas langsamer ist.

Vorbemerkung

Auch wenn Microsoft und andere Hersteller quasi eine Anleitung vorgeben, so ist Network Assessment ist immer eine sehr individuell auf Kundenanforderungen angepasste Aufgabenstellung, die kaum zu verallgemeinern ist. Ich geben hier mit meinem Worten dir Herangehensweise von Microsoft wieder. Auf der anderen Seite sehe ich auch, dass der klassische Mittelstand oft ein "Downsizing" braucht. Entsprechend habe ich auf der Seite "Basic Network Assessment" eine vereinfachte Version beschrieben.

Das klassische Assessment geht nämlich davon aus, dass es noch nichts gibt, Skype for Business neu dazu kommt und es vor dem Deployment durchgeführt wird. Die Realität ist aber eine andere. Wer Lync nicht nur im gleichen Standort nutzen will, muss WAN-Verbindungen, Bandbreiten, Belastungen etc. erheben, planen, umsetzen und validieren. Unabhängig davon, ob sie nun Audio, Video oder nur IM/Presence umsetzen wollen, muss ihr Netzwerk für die Last geeignet sein. Sie müssen die erwartete Last bestimmen, die Kapazitäten erfassen und letztlich ggfls. Änderungen umsetzen. Microsoft bezeichnet ihre strukturierte Herangehensweise als "Lync Network Readiness Assessment". Diese Seite basiert auf meinen eigenen Erfahrungen und Vorgehensweisen als auch aus Informationen des Lync Ignite 2013 in Prag, Microsoft Channel9 und Microsoft Virtual Academy-Vorträgen.

Genau genommen sollten sie ein Netzwerk Assessment für jede neu einzuführende Anwendung und Netzwerklast machen um zum einen die Funktionalität der eigenen Anwendung sicher zustellen aber auch die Auswirklungen auf andere Nutzer der Infrastruktur zu bestimmen. Im LAN lassen sich viele Dinge natürlich einfach durch "genug Bandbreite" erschlagen und sehr datenintensive Transfers (DAG-Replikation, Backup, VM-Migration) finden auf bekannten Teilstecken statt.

Network Assessments sind keine einmalige Aktion vor der Einführung einer Lösung, sondern eine permanente Aufgabe.

Die Besonderheit bei Lync oder VoIP allgemein ist die "Echtzeitkomponente" in Bezug auf Laufzeiten und Packet-Loss. Bei normalen Datenverbindungen ist die Bandbreite wichtiger aber nicht, ob das Paket nun eine Sekunde länger braucht oder ein Paket verloren geht und durch den TCP-Stack erneut übertragen wird. Daher fallen Probleme im LAN/WAN bei der Nutzung mit Audio/Video viel deutlicher auf als bei einem reinen Datenverkehr, bei dem gelegentliche Verzögerung im Sekundenbereich gar nicht bemerkt werden.

Phasen

Wer eine Skype for Business Umgebung und deren Bandbreiten dimensionieren will, muss Daten erfassen. Das beginnt nun gar nicht beim müssen oder gar Ausprobieren, wie ich auf Traffic Simulation beschrieben habe, sondern beginnt vorher. Die Simulation ist erst nach der Bestimmung der erforderlichen Bandbreiten dran. Ein Projektablauf könnte z.B. wie folgt aussehen:

Von dieser Vorgehensweise kann natürlich abgewichen werden.

  • Vorarbeiten
    Sobald mein Kunde den "Auftrag" für ein Assessment erteilt hat, müssen umgehend die erforderlichen Werkzeuge bestellt werden. Gerade bei WAN-Verbindungen kann die Verteilung von Probes durchaus etwas dauern. (Postlaufzeit, Abstimmung mit lokalem Admin, Bestellprozess).
  • Analyse
    In der Zwischenzeit werden bei einem Kickoff-Meeting alle beteiligten Personen informiert und die Aufgaben verteilt. So müssen die Netzwerker einen aktuellen Netzwerkplan und die Auslastung beisteuern. Dabei interessiert nicht nur die Brutto-Bandbreite sondern auch die historische Entwicklung über mehrere Tage/Wochen aber auch die Verteilung über die Tageszeit. Ebenso interessant sind die Verteilung der Protokolle bzw. QoS-Klassen und deren Belegung und in naher Zukunft geplante Veränderungen
    Aus dem Client-Management sollte versucht werden, die Arbeitsweisen der Mitarbeiter zu ermitteln, d.h. den Bedarf an Konferenzen etc. Und das TK-Team kann Daten zur den aktuellen Audioverbindungen (Busy Hour Traffic, Konferenzminuten, etc.) ermitteln, sofern die bisherige TK-Technik oder die verwendete Konferenzplattform liefern kann.
  • Modellierung
    Dann geht es darum mit den Daten und dem Bandwidth Calculator die zu erwartende Bandbreite auf den verschiedenen WAN-Links zu definieren und basierend darauf die Simulation zu planen
  • Simulation
    Erst dann werden die Motoren gestartet, die überprüfen, ob die durch den Bandwidth Calculator ermittelte Bandbreite auch in der erforderlichen Qualität bereitgestellt werden kann.
  • Auswertung
    Abschließend werden die Daten aufbereitet und dem Kunden präsentiert.

Die Phasen im Einzelnen:

Analyse (Discovery)

Die Analyse ist vermutlich der umfangreichste Part eines Network Assessment, da hier quasi möglichst Lückenlos alle Daten erfasst werden müssen. Teilweise werden aber Daten gar nicht vorhanden sein, weil sie noch nicht erhoben wurden, teilweise sind vorhandene Dokumentationen nicht mehr aktuell.

  • Netzwerk Struktur
    Versuchen Sie nicht nur den aktuellen Stand des Netzwerks anhand der Bandbreiten zu ermitteln, sondern auch die Auslastung anhand historischer und geplanter Daten und QoS-Konfigurationen. Auch die Komponenten des Netzwerks, z.B. Router, Switch, Loadbalancer, WAN-Optimizer, Firewalls, NAT-Übergänge sind zu erfassen. Es ist immer eine gute Idee diese Daten als Bild festzuhalten, wenn es noch keine entsprechenden Pläne gibt. Die Betriebsdaten sollten keine Stichprobe von wenigen Stunden sein, sondern über mehrere Tage oder Wochen erfasst worden sein, damit auch temporäre Lasten (Backup, VM-Replikation, Software/Patch-Verteilung etc.) mit einbezogen wurden. Je länger die Daten aufgezeichnet wurden, desto eher können auch Trends wie ein Wachstum erkannt werden.
    Wenn aktuell noch kein RTC auf dem LAN übertragen wird, dann sollten Sie die "Busy Hour" der Bestandsdaten finden und prüfen, ob die zusätzliche erwartete RTC-Last noch übertragen werden kann.
    Wenn Daten nicht zu erhalten sind, dann sollten Sie Annahmen mit dem Betreiber festlegen. Sie werden in der Phase mit unterschiedlichen Teams zu tun haben und überprüfen Sie die Daten auf Plausibilität. Überlegen Sie, ob sich nicht einige Stichproben selbst vornehmen oder vorschlagen, bestimmte Daten zu erheben. Dies ist aber nicht der Zeitpunkt die Daten zu bewerten oder schon ein urteil zu bilden.
  • Clients
    Zu den Client zählen neben dem Lync Client auch Telefone aber auch Konferenzsysteme. Bei Migrationen ist zu prüfen, ob die Geräte mit Lync kompatibel sind. Beim Netzwerk stellt sich die Frage nach PoE. Sind Telefone mit PoE vorgesehen, dann müssen die Switches auch PoE liefern und vielleicht per uSV abgesichert werden. für Lync müssen aber auch analoge Geräte, d.h. Fax, Portomaschine, Aufzugstelefone, Alarmgeber etc. berücksichtig werden.
  • Blockaden erkennen
    Die Bandbreite ist nicht alleine. Gerade Firewalls und NAT-Umsetzungen können die RTC-Kommunikation später unmöglich machen und ungünstige Wege über den TURN-Server erzwingen. Auch VPN-Tunnel haben eine Einfluss auf die RTC-Nutzung, z.B. durch mehr Overhead durch die Verschlüsselung, eventuell erforderliche Umwege durch Tunnel und den Verlust von QoS-Tags. Auch die Effizienz von WAN Optimierern ist mit RTC differenziert zu beachten. Bei ADSL-Leitungen sollten Sie nur die langsame Seite betrachten.
  • Transport Reliability IP Probe Tool
    Diese Tool ist ideal für Firmen, deren Clients Dienste in der Cloud nutzen. Ein Programm auf dem Client spricht mit einem Microsoft Datacenter und "misst" die Netzwerkleistung. Man startet ein Java-Applet in einer Webseite. Allerdings eignet sich dieses Tool nur bedingt für interne Netzwerke.
  • Key Health Indikatoren für Server, Client, Netzwerk
    Sofern schon Lync Server installiert sind, können Sie natürlich die Daten dieser Umgebung ermitteln.
  • Monitoring
    Ansonsten sollten Sie alle Quellen anzapfen, die sie erreichen können um ihre Datenbasis möglichst breit und fundiert aufzubauen. Das kann auch ein Netzwerkmitschnitt mit Netmon/Message Analyszer sein, um die Verteilung der Protokolle als Stichprobe zu ermitteln.

Modelling

Nachdem die Analyse (Discovery) abgeschlossen ist, können Sie mit den Daten in die Modellierung einsteigen. Es geht dabei darum, Annahmen zu definieren, mit denen das zukünftige Lastverhalten von Lync auf dem Netzwerk ermittelt und in der nächsten Phase simuliert werden kann.

Dazu kommen zwei Modellierungsfaktoren ins Spiel:

  • Anwender (Usage Model)
    Also wie intensiv die Anwender das System nutzen, also wie viel Zeit sie am "Telefon" verbringen oder in einem Meeting teilnehmen.
  • Verkehr (Traffic)
    Wie sich die verschiedenen Verbindungen in dem Netzwerk auswirken. Eine P2P Verbindung nutzt andere Wege als eine Konferenz.

Mit diesen Daten wird dann die erforderliche Bandbreite ermittelt (Lync Bandwidth Calculator) Dazu sind natürlich Daten erforderlich, z.B.:

Kennzahl Erledigt

Wie viele Standorte gibt es

 

Wie sind diese angebunden (Bandbreite gesamt, Bandbreite "frei", Technologie)

 

Anzahl der Anwender in jeder Site und zukünftige Entwicklung

 

Anzahl der Anwender "außerhalb" (remote)

 

Erwartetes Wachstum für den Einsatz.

 

Anzahl der Gesprächsminuten pro Trunk und Busy Hour traffic

 

Das sind nur ein paar Zahlen und je größer eine Umgebung ist, desto ausführlicher muss die Aufstellung sein.

Usage Models

Microsoft legt im "Lync Bandwidth Calculator" einige Schlüsselwerte fest, die als Basis für den Kalkulator dienen.

Die Daten basieren wohl auf den Erfahrungen von Microsoft Intern bzw. deren Consultants. Sie können diese Vorgaben einfach übernehmen aber die können auch eigene Profile hinterlegen, wenn ihre Analyse dies nahelegt. Bedenken Sie z.B.:

  • In den USA finden tendenziell mehr Konferenzen als in Europa statt
  • Asiatische Standorte nutzen in der Regel viel mehr IM
    Das zeigen meine eigenen Messungen bei Kunden
  • Die Menge der Konferenzen nimmt global deutlich zu
    Vor allem wenn es dank Lync einfacher wird. Planen Sie hier also auf Zuwachs
  • Parallel Call erhöhen den Bedarf an PSTN-Trunks
    Anwender können Lync-Telefonate sehr einfach auch am Mobiltelefon klingeln lassen.
    Andererseits umgehen Mobiletelefone mit Datentarif/WiFI und Lync Client wieder den PSTN-Trunk
  • 10-20% "am Telefon" ist eine gute Annahme für Firmen.
    Callcenter haben natürlich viel mehr Telefonzeiten. Hier können Daten aus der bisherigen Telefonanlage helfen.
  • Planen für die Zukunft. !
    Auch wenn es schwer fällt, sollten Sie mit einem Wachstum gerade bei Konferenzen rechnen. Bei der reinen Telefonie wird es deutlich weniger Steigerungen geben.

Aber auch hier sollten Sie nicht zu genau sein, denn letztlich bleibt immer eine Unsicherheit vorhanden. Es lohnt sich nicht, tagelang genauere Daten zu ermitteln, wenn es letztlich nur um ein paar Prozent geht.

Personas

"Personas" sind ein Konzept um virtuelle Personen zu definieren, die möglichst nahe die Arbeit von echten Personen nachbilden. Sie sind in der Regel nicht ans Standorte gebunden, d.h. eine Persona "Vertriebler" kann das gleiche Nutzungsverhalten in verschiedenen Kontinenten haben. Es kann aber auch gerade sein, dass z.B. der Vertrieb in Europa und Asien komplett andere Arbeitsweisen an den Tag legen. für jede Persona müssen sie ein paar Kriterien festlegen:

  • Einstufung der Modalities in None, Low, Medium, High
    Ausgehend von den Funktionen von Lync (IM/Presence, Audio, Video, Konferenz etc.) müssen Sie festlegen, wie intensiv das Persona diese nutzt.
  • Explizite Verbote
    Eine Persona kann z.B. Audio sehr intensiv nutzen aber per Richtlinie ist Video verboten. Das muss entsprechend repräsentiert werden.
  • Remotearbeit
    Wer von zuhause arbeitet, belegt selbst keine Bandbreite auf dem internen Firmennetzwerk, zumindest solange man den Edge Server kommt., der dem eigenen Pool lokal verbunden ist. Aber auch das hat zwei Seiten, denn der Gesprächspartner kann natürlich intern sein. Und die Bandbreite auf dem Internet-Link ist natürlich nicht zu unterschätzen.
  • Andere Faktoren

Das könnte dann so aussehen:

Persona IM/Presence Audio Video AppSharing Remote

Vertrieb

High

85% am Telefon

10%

 

40%

Azubi

High (Jung)

0% Telefon (Deaktiviert)

nur intern/lokal

nur intern/lokal

Deaktiviert

Helpdesk

High (Responsegroup)

80% Tel

0%

60%

0%

Produktion

 

20%

5%

5%

0%

Fax/Telefon

Keine

10%

0%

0%

0%

Auch hier ist weniger wieder mehr. Das Lync Bandwidth Tool erlaubt bis zu 10 Personas aber meist kommen sie mit 5 oder weniger aus. Auch gilt es zu prüfen, welche Last mehr oder weniger relevant sind.

Achtung: Konferenz Audio braucht mit G.722 mehr Bandbreite als P2P Audio. Man plant mit "typical", denn der Wert bei "Maximum" bedeutet, dass z.B. ECC aktiv ist. Das passiert nur, wenn die Leitungen nicht ausreichend sind, was ein gutes Design gerade vermeiden sollte.

Ein Blick auf die vier Modalities zeigt, dass der Einfluss durchaus unterschiedlich ist:

Modality Einfluss auf Personas RTC Verkehr ?

IM/Presence

Niedrig

kein RTC

Audio

Relevant

RTC

Video

Relevant

RTC

AppSharing/Desktop-Sharing

Sehr Relevant

Kein RTC

Insofern sind unterschiede in der Nutzung von IM/Presence nicht unbedingt eine Persona zu trennen. Deskop-Sharing/Appsharing aber sehr wohl und Audio/Video muss zumindest bei der Netzwerkplanung bezüglich Realtime-Traffic (RTC) berücksichtigen.

All diese Daten sollten Sie sich natürlich nicht einfach ausdenken, sondern idealerweise aus bestehenden Reports ermitteln

Sites, Links und Users

Für Lync und Skype for Business "On Prem" laufen die meisten Verbindungen über interne Netzwerke und Verbindungen. Als Firma haben Sie hier nicht den Vorteil von Office 365, dass Sie mit lokalen Internet-Ausgängen diese Last von ihrem eigenen WAN weghalten können. Entsprechend müssen Sie eine "Landkarte" ihrer Netzwerke und Verbindungen erstellen.

Wenn ihre "Netzwerk-Truppe" auf Zack ist, dann gibt es eine Liste der Subnetze mit den Standorten und eine Liste der Verbindungen zwischen den Standorten. Diese Informationen sind auch später für CAC - Call Admission Control erforderlich. Die Realität zeigt aber immer wieder, dass es oft noch Nachbesserungsbedarf gibt.

Pro Site müssen sie dann die "Total WAN-Bandbreite" bestimmen. Das bedeutet aber nicht, dass diese Bandbreite dann auch für Skype for Business genutzt werden kann. Gerade bei MPLS aber auch anderen Netzwerken darf der RTP-Anteil nicht höher als 30% sein. Auch ohne Office 365 sind dennoch die Übergänge zum Internet zu erfassen. Mit einer geschickten Konfiguration könnten Sie für ausgewählte Standorte durchaus das "Internet" als Bypass nutzen. Zudem sollten Sie noch "Reserven" einplanen, da die Nutzung der Anwender durchaus höher sein kann. Gerade mit der "Audio-Konferenz-Funktion" von Skype for Business haben wir oft gemerkt, dass Anwender viel häufiger diese nutzen, als zu Zeiten des "alten Telefons"

Simulation

Nach all den Vorarbeiten geht es nun an die Simulation. In größeren Umgebungen ist es natürlich utopisch die komplette Belastung realistisch zu simulieren. Wenn der Kunde heute schon eine VoIP-Lösung über die gleiche Verbindung einsetzt, dann macht es gar keinen Sinn die erwartete Skype for Business-Last noch zusätzlich auf die Leitung zu legen. Das gefährdet die bestehende Nutzung und die gemessenen Ergebnisse sind auch verfälscht. Hier muss man die sowieso schon vorhandene Last abziehen, so dass in der Summe die Ergebnisse wieder hin kommen. Das ist aber alles andere als einfach weil sie ja nicht vorhersehen können, wie die bisherige VoIP-Lösung in dem Probenzeitraum gerade arbeiten. Eine Unschärfe bleibt.

Es wird auch ziemlich knifflig die Übertragungen im LAN zu simulieren und zu messen. Es müssen schon sehr große Firmen sein, die so viel Verkehr produzieren dass letztlich der Gigabit-Link eines Server saturiert wird. Schon vom Sizing her werden sowieso mehr Server und dickere Links aufgebaut.

Relevant sind daher wirklich nur die WAN-Leitungen und bei den meisten Firmen gibt es Standorte, die alle ziemlich gleich hinsichtlich der Datennutzung sind. Hier ist des dann sinnvoll einen Standort exemplarisch zu nutzen und die Ergebnisse auch für die anderen Standorte anzunehmen.

Die Messung selbst erfolgt in der Regel mit an den Standorten installierte "Probes", die Verkehr erzeugen und die Werte messen. Dabei geht es meist um folgende fünf Werte:

  • Laufzeit der Pakete in einer Richtung
  • Jitter  (Mittelwert und Max)
  • Packet-Loss (Mittelwert und Burst)

Dabei sollten sinnvolle Endpunkte für eine realistische Simulation ausgewählt werden.

  • Central Site sollte immer dabei sein
    Hier steht der Pool, der Edge Server und ein Gateway und "remote Sites" nutzen diese Central Site als zentrale Stelle. Um eine beliebige Leitung zu müssen, muss die Central Site mit drin sein
  • Beschränkung ist erforderlich
    Sie können in der Simulation nie die komplette Umgebung ausmessen. Microsoft selbst simuliert ca. 10-20 Sizes.
  • Keine Simulation auf nicht ausgebauten Leitungen
    Es macht keinen Sinn eine Simulation auf eine Verbindung zu legen, die wissentlich zu schwach oder QoS nicht eingerichtet ist und dies erst später geändert wird.
  • Simulation auf "kritischen Strecken
    Sinnvoll ist die Simulation auf Verbindungen, die quasi "fertig" sind und Probleme die Anwender wirklich
  • Nicht alles sind "Fehler"
    ein 300ms Latenz von Europa nach Indien hört sich nach "viel" an, aber aufgrund der Entfernung zu erwarten.
  • Erkennen von Überlastmuster
    Das ist wichtig, wenn die Bandbreite z.B. immer wieder zu bestimmten Zeiten nicht garantiert ist. Da können Dateitransfers, Backups, SoftwareUpdates o.ä. sein, die in den Mittelwerten der Analyse nicht erkannt werden konnten. Erst durch die Simulation wird so etwas sichtbar.
  • Prüfe QoS Tagging
    Ein Tool kann normal nicht erkennen, ob die QoS-Pakete wirklich priorisiert wurden. Aber es kann erkennen, ob die Markierungen bis zur Gegenstelle vorhanden bleibt. Wird das QoS-Tag auf dem Weg entfernt, dann ist die Kette unterbrochen.

Für die Simulation gibt es natürlich verschiedene Tools und Programme. Microsoft selbst hat auch in 2013 das Tool "Lync Server Stress and Performance Tool (LSS)" veröffentlicht.

Lync Server 2013 Stress and Performance Tool
https://www.microsoft.com/en-us/download/details.aspx?id=36819

Voraussetzung für den Einsatz ist aber ein funktionsfähiger Lync Server. das Tool legt nämlich User an und generiert die Last mit entsprechenden Agenten. Ein Test in einem produktiven Topologie ist nicht ratsam. Insofern ist das nicht mein Tool der ersten Wahl

Da sind einige kommerzielle Werkzeuge oder selbst Freeware und eigene Skripte aus meiner Sicht besser geeignet. Wie so oft ist das Problem aber nicht allein durch die richtige Software zu lösen. Der Mensch, der hier erfasst, plant, durchführt und auswertet ist ein wichtiger Faktor.

Empfehlung (Recommendation)

Das ganze Prozedere muss natürlich in einem Abschlussgespräch und einen Abschlussdokument münden. Die Ergebnisse der Messung sollten so aufschlussreich sein, dass Sie genau wissen, welche Änderungen noch erforderlich sind. Hierbei kommen dann alle Themen noch mal auf den Tisch:

  • Vorgegebene Bandbreiten und reichen diese aus
  • Optionen die Datenverkehre über andere Wege zu leiten
  • Optionen um RTP zu priorisieren (QoS-Tagging)
  • Optionen RTP zu beschränken (CAC)

Und was sonst noch für eine erfolgreiche Einführung von Skype for Business mit Audio/Video erforderlich ist.

Weitere Links

Lync Ignite 2013: Lync Network Assessment Methodologies
http://channel9.msdn.com/Series/Lync-2013-Ignite/Lync-Network-Assessment-Methodologies

Channel 9: Lync Network Readiness Assessment
http://channel9.msdn.com/Series/Lync-Network-Readiness-Assessment