Lync Sizing

Diese Seite kann sicher kein vollständiges Sizing einer Lync-Umgebung beschreiben, Ich versuche mich in der Darstellung wichtiger Parameter und eine Abschätzung für mittlere und kleinere unternehmen mit dem Ausblick auf Größeres. Ich bin aber auch auf ihre Mithilfe hier angewiesen. Teilen Sie ihre Erfahrungen und Sizings mit mir zum Wohle aller.

Wie bei OCS ist eine Dimensionierung von Lync von vielen Faktoren abhängig, die nicht einfach mal so schnell abgehandelt werden können. Andererseits hilft es ihnen als Leser ja nicht, wenn wie immer nur ein "Das müssen wir erst analysieren" hören. Schließlich gibt es auch für OCS und Lync "Erfahrungswerte". Natürlich können Sie einen Exchange Server auch nicht nur nach der Anzahl der Benutzer dimensionieren, sondern Werte wie die Postfachgrößen und die pro Zeiteinheit umgeschlagenen Mails sind viel wichtiger. Trotzdem möchte ich nach ein paar Vorbemerkungen ein paar Dimensionierungsvorschläge anstellen. Generell stehen Sie aber unter dem Vorbehalt, dass Anforderungen sich auch sehr schnell wieder ändern können, weil das neue Medium akzeptiert und intensiver genutzt wird, als vorhergesagt. Sie können sich also auch bei bester Planung nie sicher sein, dass die installierten Server wirklich Bestand haben. Das können die Exchange Administratoren aber auch aus der Zeit von 1990-2000, als sich das Mailvolumen innerhalb von Monaten verdoppelt hat. Auch hier gilt: Flexibel bleiben und notfalls weitere Server aufzubauen oder virtuelle Server mehr Ressourcen zuzuteilen.

Relevante Faktoren

Was bei Exchange die Postfachanzahl, die Mailboxgröße, die übertragenen Mails/Stunde und die Clientzugriffe per OWA, Outlook (Cached/online), ActiveSync oder Blackberry sind, sind für Lync-Consultants folgende Werte:

  • Anzahl der Benutzer
    Natürlich ist die Anzahl der Benutzer für die Dimensionierung relevant. Auch wenn dies in absoluten Zahlen erst bei größeren Mengen wichtig wird, so ist dies die Basis zur Ableitung anderer Parameter. Insbesondere die Last bei der morgendlichen Anmeldung von vielleicht 6.000 User von 08:00-09:00 kann mit 100 Anmeldungen/Min oder ca. 2/Sek schon Last auf den SQL-Server bringen.
  • Telefonverbindungen
    Eine dieser Ableitungen ist die Anzahl der parallel geführten Telefonate. Schließlich benötigen sie dazu ein Gateway zur TK-Welt bzw. einen entsprechend leistungsfähigen SIP-Trunk. Wer also 100 Benutzer hat, von denen jeder ca. 10% seiner Zeit telefoniert, benötigt schon mal 10 Leitungen. Wer dann noch etwas "Reserve" einplanen und Spitzenzeiten abdecken will, braucht mehr. Gut ist, wenn Sie von der aktuellen TK-Anlage solche Betriebsparameter ermitteln können. Ansonsten ist "schätzen" angesagt, damit die Anwender nicht durch ein "Gassenbesetzt" genervt werden. Selbst dann ist ein S2M Anschluss mit 30 Leitungen plötzlich nicht mehr genug.

Hinweis: Die Rechnung sieht anders aus, wenn die Lync "hinter" eine TK-Anlage betreiben. Hier müssen Sie im schlechtesten Fall davon ausgehen, das 50% der Anwender mit Lync und 50% mit der TK-Anlage arbeitet und wenn man nicht Teams migriert, dann sind die Hälfte Verbindungen die vorher "intern" waren. Wenn der Kopplung per SIP erfolgt, muss eventuell ein SBC die Codes anpassen. Selbst mit gleichen Codec funktioniert "Bypass" nicht immer.

  • Konferenzen
    Lync bietet die Funktion einer Dial-In/Dial-Out  Konferenz "einfach so" mit an, das kostet nichts extra und wird von den Anwendern sicher bald genutzt werden, wenn Sie nicht mehr einen externen Konferenzdienst beauftragen müssen. Auch das schlägt sich extern natürlich auf die Anzahl der Leitungen nieder. Interne Lync-Audiokonferenzen sind hingegen unkritischer zu sehen, auch wenn der Lync-Server hier als "Mixer" der Tonsignale dient. Audio ist oft nur 50-100kbit so dass schon einige Konferenzen zusammen kommen müssen, um entsprechende Bandbreite auf dem Lync-Server zu belegen. Etwas anders ist das natürlich wieder in Verbindung mit WAN-Leitungen oder Video.
    Eine „Annahmen“: 1000 User telefonieren pro Stunde im Schnitt 20 Min und sind davon zu 20% in einer Audiokonferenz. Also käme man auf 4000 Konferenzminuten/h oder 66 gleichzeitige Audiokonferenzteilnehmer.

Hinweis: Wenn sie gerade erst Lync einführen und viele Mitarbeiter noch ein Telefon als "Audiogerät" nutzen, dann müssen Sie deutlich mehr Kapazitäten für Konferenzteilnehmer per Telefon einplanen.

  • Bandbreiten LAN/WAN
    Bandbreiten werden auch stärker belastet, wenn neben Audio noch Video (und HD-Video) dazu kommen und Desktop-Sharing genutzt wird. Allerdings können seit Lync hier Obergrenzen definiert werden, die über eine WAN-Strecke belegt werden dürfen. Dennoch ist natürlich eine korrekte Konfiguration von QoS-Diensten auf den Routern ratsam. Es gibt ja auch noch andere Dienste, die stören können. Wenn ihnen das Netzwerk dann eine Bandbreite zusichert, dann sollten Sie mit CAC dafür sorgen, dass sich die Lync Clients auch daran halten.
  • Monitoring und Archiv-Funktionen
    Eher für das Backend (SQL-Storage) relevant sind die Anforderungen an eine Archivierung von Meldungen und Bewegungsdaten. Wobei auch hier gilt, dass die Informationen ja erst "abtelefoniert" und "eingetippt" werden müssen, ehe sie im Archiv und im Monitoring landen. Aber bei größeren Benutzerzahlen sind auch diese Datenmengen nicht mehr vernachlässigbar.
  • Externer Zugriff
    Mit Lync macht natürlich das Arbeiten von unterwegs, zuhause oder mit anderen Firmen gleich doppelt Spaß. Allerdings funktioniert das ohne VPN nur über einen Edge-Server und die Internet-Verbindung der Firma. Während im Heimbereich schon DSL 16000 und höher üblich ist, sind viele Mittelständler noch mit deutlich geringeren Bandbreiten, z.B. 2MBit, angebunden, die dann aber symmetrisch sind. Und das ist wichtig, da Lync-Clients bidirektional kommunizieren. Zuhause reicht ihnen auch ein DSL768 um mit einer 192kBit upstream mit Lync zu telefonieren. Wer aber viele Heimarbeiter an die Firma per DSL160000 anbindet, kommt bei der üblichen upstreamrate von 800-1024 Kbit schnell an die Grenzen. Und die müssen auch noch mit Internet (HTTP) und Mailverkehr (SMTP) und vielleicht VPN genutzt werden. Hier muss rechtzeitig dann eine passende Infrastruktur bereit gestellt werden, z.B. ein eigener Zugang für den Edge-Server.
  • Verfügbarkeit
    Fallen Telefonanlagen aus ?, auch auch aber selten und für Lync gilt mittlerweile, dass mit einem passenden SBA auch die Telefonie nicht mehr allein von einem Server abhängen muss. Aber für die anderen Funktionen muss der einzelne Standard Server verfügbar sein oder Sie bauen einen Pool mehrerer Frontend Server mit einem hochverfügbaren SQL-Backend auf. Technisch weniger ein Problem, da es alles "Standards" sind und auch die Lastverteilung  bis auf eine Ausnahme nicht mehr über Loadbalancer sondern per DNS erfolgen kann. Dennoch muss es mit eingeplant werden und verdoppelt in vielen Umgebungen einfach mal die Serveranzahl.

Ich hoffe Sie können so etwas verstehen, warum ein Sizing für Lync nicht gerade einfach ist. Die meisten dieser Faktoren betreffen aber die Serverhardware erst bei größeren Benutzerzahlen, z.B. bei 200 Benutzern und mehr.

Randparameter

Für die Dimensionierung der Server muss man sich andere Kriterien anschauen, die auf die Datenmenge und das Volumen abzielen.

  • Active Directory
    Lync erweitert nicht nur das Schema, sondern die neu gewonnenen Felder werden natürlich auch mit Inhalten gefüllt. Allerdings sind dies nur ein paar Felder, die pro Benutzer in der Regel wenige Kilobyte ausmachen und daher nur in sehr großen Umgebungen relevant sind. Werden Bilder (Siehe ADPhoto) genutzt, werden es natürlich schnell mehr. Aber auch dann sollte dies für Firmen mit weniger also ein paar tausend Benutzer nicht ins Gewicht fallen.
  • SQL-Datenbank
    Lync nutzt eine SQL-Datenbank für verschiedene Zwecke. Neuerdings ist dort auch die Konfiguration enthalten aber primäre sind dort die Benutzerdaten (also ihre Buddy-Liste und Volatile Einstellungen wie Weiterleitungen etc) enthalten. Eine zweite Datenbank enthält die dynamischen Zustände und Hinweise (Frei, Belegt, Abwesend, Standort, Bemerkung etc.) der Benutzer. Hier ist mehr "Bewegung" drin aber die Datenmenge ist überschaubar und kein Problem für den klassischen Mittelstand. Etwas anders Sieht es aus für die Datenbank, in die Lync Meldungen archivieren kann oder Betriebsdaten (Monitoring) speichert. Hierzu ist aber eh ein eigener (voller) SQL-Server erforderlich und es bietet sich an, einfach einen bestehenden Server zu nutzen, der SQL auch für andere Anwendungen bereit stellt. Das wäre im individuellen Fall zu ermitteln.
  • SIP-Traffic
    Haben Sie sich schon mal angeschaut, was rein als SIP-Traffic vom Server vermittelt wird ?. Das sind ganz wenige Datenmengen und aus meiner Sicht zu vernachlässigen. Sicher, wenn 1.000 Benutzer alle 5 Min ihren Status aktualisieren und jeder 20 Benutzer in seiner BuddyListe hat, dann werden das 1.000 * 21 = 21.000 Meldungen in 5 Min oder 70 Meldungen/Sekunde übertragen. Das sollte einem halbwegs aktuellen Server auch noch keine Probleme bereiten. Aber bei 10.000 Benutzern wird das schon eher interessant. Microsoft geht hier von 1.3 Kpbs/User aus. Bei 10.000 Benutzern sind das dann 13 Mbps. (Quelle Lync Server 2010 User Models. http://technet.microsoft.com/en-us/library/gg398811.aspx)
  • Audio / Video / Shareing / Konferenz / Meeting
    Bei einem "StandardServer" übernimmt dieser auch das Mixen der Datenströme bei Konferenz mit 3 oder mehr Teilnehmern. Das ist eigentlich die Schlüsselkomponente, die über das Sizing eines Servers entscheidend ist, da hier große Datenmengen und CPU Last zusammen kommen und Verzögerungen bei unterdimensionierung sich in der Qualität niederschlagen. Hier sollten Sie also ganz klar ihren Bedarf ermitteln und auch nach der Installation überwachen
  • Externer Zugriff
    Der Zugriff per Edge hingegen kann nur so viel Last machen, wie die Internetleitung übertragen kann. Hier ist der Engpass bei den mittleren und kleinen Firmen eher in der Anbindung nach Extern denn auf dem Server zu suchen.

Vielleicht erkennen Sie nun, dass die Anzahl der Anwender zwar wichtig aber nicht alleine maßgeblich für ein Sizing sein kann. Konferenzen und das Benutzerverhalten sind sogar wichtiger.

Vorbemerkung zum Sizing

Aber was macht nun jemand, der mit Lync starten will und eigentlich gar nicht weiß, was da auf ihn zukommt? Wir stehen quasi an der gleichen Stelle wie vor vielen Jahren, als mehr und mehr Firmen erste Mailserver installiert haben und sich verwundert die Augen gerieben haben, dass der gerade mühsam installierte Server in ein paar Monaten schon wieder aus allen Nähten platzt. Das ist bei OCS und  Lync oft identisch, da die Umgebung nach einiger Zeit einen solchen Zulauf erfährt, dass jedes frühere Sizing sich pulverisiert. Wenn Sie also noch gar nicht wisse, was auf sie zukommt, dann können Sie einfach nur mal "anfangen" und beobachten, wie sich die Nutzung entwickelt. Nur wenn Sie schon von Vorneherein belastbare Zahlen haben und z.B. mehr als 500 Anwender betreiben wollen, dann lohnt sich der Aufwand, eine Serverstruktur aufwändig zu dimensionieren. Das gleiche gilt, wenn Sie wirklich Lync von Anfang an als "Infrastruktur" einsetzen, die zugleich ihre TK-Anlage in weiten Bereichen ersetzt. Dann muss eine saubere Planung erfolgen, die ich aber hier auf einer Seite nie leisten kann.

Lync-Server mit dem Planning Tool

Ansonsten würde ich zuerst einfach einen Lync Standard Server anfangen und ein passendes modulares Gateway einsetzen, welches den vermuteten Bedarf für die Telefonie abdeckt. Und so eine einfache Umgebung  könnte wie folgt aussehen.

Lync Server 2013 Capacity Calculator
http://www.microsoft.com/en-us/download/details.aspx?id=36828
Leider nur Aussagen zu CPU, Bandbreite und Hauptspeicher aber nicht zu IOPS des Storage Systems

Microsoft Lync Server 2010 Capacity Calculator
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=6e8342a7-3238-4f37-9f95-7b056525dc1a&displaylang=en

Bandwidth Calculator
http://www.microsoft.com/en-us/download/details.aspx?id=19011

Lync 2013 Detailed Design Calculator
http://gallery.technet.microsoft.com/Lync-2013-Standard-Edition-324bf0f1

Lync Server 2010, Stress and Performance Tool
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=94b5f191-6d80-4dec-94c2-fca57995f8b7&displaylang=en

Microsoft Network Assessment für Unified Communications
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=186123aa-966c-44d0-8ad7-6d244886b9d0

Basierend auf dem Lync 2010 Planning Tool (RC) habe ich folgende einfache "nicht hochverfügbare" Umgebung mit Edge und 100% Telefonie aufgestellt:

Für diese Struktur benötigen wir erst mal nur zwei Server, einen Standard Server und den Edge Server. Die TK-Funktion wird direkt über das Gateway eingebunden. Wer natürlich noch Exchange UM und Monitoring einsetzen will, muss diese Server addieren und die DCs setze ich als "sind eh da"-Server voraus. Im Design gehe ich von einer Site aus, in der 100% mit Lync telefonieren. Diese Zahlen gelten für 5000 Benutzer

Server CPU RAM Disk Lan

Frondend

4 Cores 2 GHz

12GB

2x72GB 10k

2x Gigabit

Edge

4 Cores 2 GHz

12GB

2x72GB 10k

2x Gigabit

Exchange UM

Keine Aussage

2GB /Core

 

 

Nun würde ich natürlich nicht 5000 Benutzer auf dieser Hardware ohne Hochverfügbarkeit arbeiten lassen. Wenn ich die Zahlen aber auf 500 oder sogar 50 Benutzer herunter schraube, dann ändert der Lync Sizer überhaupt nichts an den Zahlen. Es scheint als wenn diese Hardware die "Mindestausstattung" ist. Natürlich können Sie Lync auch virtuell auf äquivalente VMs bereitstellen. Dennoch hilft und dieses Tool nicht weiter, wenn wir deutlich weniger Benutzer oder erst ein Testsystem installieren wollen.

Ihre individuellen Anforderungen müssen natürlich berücksichtigt werden. Ich würde vielleicht nicht 2000 User auf einem Standard Server betreiben, wenn sehr viele Konferenzen anstehen.

Lync-Server für KMU

Interessanter ist hier die Seite "Capacity Planning Requirements and Recommendations" auf http://technet.microsoft.com/en-us/library/gg425715.aspx. Sie geht schon etwas genauer auf die Anforderungen ein. Solange die Benutzeranzahl unter 5000 liegt, stellt sich die Frage nach mehreren Server für eine Funktion nur bei Anforderungen an die Verfügbarkeit. Laut Dokumentation kann ein Server mit 4 Cores (2,3 GHz), 16GB Ram und 2x 1 Gbit LANs bis zu 226 gleichzeitige Gespräche abwickeln. Aber was sind praktische Werte ?

Ich habe einfach mal die Server von Net at Work heran gezogen, die virtuell unter Hyper-V arbeiten. Vielleicht melden Sie mir ja ihre Erfahrungen und Sizings. Hier die bislang bekannten Auslastungsdaten

Firma Profil
User/Telefonie/Leitungen		 Frontend
Ram/Disk/CPU		 Edge
Ram/Disk/CPU		 Gateway Ansprechpartner
Bemerkung

Net at Work

40/40/30

CPU: 2x2,6GHz
Ram 16GB
Disk 30GB

CPU: 1x 2GHz
Ram 1GB
Disk 12GB
Hyper-V

M1000
1xS2M

Frank Carius
Sicher sind die 4 GB für den Standard Server etwas "knapp" bemessen, da er schon 3,5 GB davon nutzt. Aber mit 6 -8 GB sollte ein Lync-Server für bis zu 50 Benutzer durchaus zufrieden sein. Der Edge ist noch deutlich sparsamer

Ihre Firma

Ihre Daten

Ihre Daten

Ihre Daten

Ihre Daten

Ihre Daten

 

 

 

 

 

 

Bitte helfen Sie mit und senden Sie mir ihre aktuelle Konfiguration und Erfahrungen, damit wir diese Liste etwas Ausbauen können. Einfach Mail an

Leider bietet Lync "hosted" im Rahmen von Office365 noch keine Telefonfunktion an, weswegen ein "Hosted-Lync" in dem Zuge noch keine Option ist. Mich würde aber nicht wundern, wenn einige Stadtwerke so etwas vielleicht "lokal" bereit stellen. Auf Cityhosting hatte ich sowas für Exchange schon beschrieben und es gibt ja schon "gehostete TK-Strukturen" für normale SIP-Clients (z.B. www.sipgate.de oder Telekom "Deutschland LAN" http://www.telekom.com/dtag/cms/content/dt/de/822948 u.a.). Gerade Sipgate könnte z.B.in Verbindung mit einem Gateway (z.B. Audiocodes 1000) interessant werde, wenn es SIP2SIP umsetzen kann und nebenbei auch als ATA-Adapter agieren kann.

Lync für große Benutzermengen

500 und mehr Benutzer sind für Lync auch kein Problem, wenn das Backend entsprechende Ressourcen bereit halten kann,. aber wenn Sie nun davon ausgehen, dass von 500 Benutzern "nur" 10% gleichzeitig telefonieren. dann sind das schon mindestens 50 "Amtsleitungen" d.h. 2x primärmultiplex mit entsprechendem Gateway. Selbst mit einem SIP-Trunk werden da schon mehrere Megabit benötigt, da VoIP ja nicht so effizient ist, wie ein ISDN B-Kanal mit 64bit, der dank TDM mit deterministischen Laufzeiten aufwarten kann und über die nominell 2 Megabit eines S2M Anschlusses auch 30 Telefonate übertragen kann. Und da ein Ausfall teuer werden kann, wird man langsam auch so eine Struktur redundant auslegen wobei eine "Doppelung "vielleicht gar nicht mehr reicht.

Auch die Zunahme der Meeting-Anzahl und potentieller gleichzeitiger Teilnehmer erfordert hier eine skalierbare Auslegung. Es bleibt also noch viel zu tun.

Lync virtuell

Mittlerweile ist es auch offiziell "supported", wenn Lync-Rolen auf virtuellen Maschinen installiert werden. Wobei Sie hierbei natürlich weniger an eine Einsparung von Ressourcen sondern eher neue Möglichkeiten der Verwaltung (Snapshot für Patches, Failover, Desaster Recovery etc.) denken als an Einsparung von Hardware.

Zudem sollten Sie genau beachten, dass Lync besondere Anforderungen an die Ressource "Netzwerk" hat. Bandbreite ist in kleinen Umgebungen eher nicht das Problem aber Laufzeit ist kritisch. Besonders wenn andere VMs auf dem gleichen Host z.B. große Datenmengen übertragen (Backup, Dateiserver, Exchange Migration etc.) und damit die gemeinsam genutzte Netzwerkkarte beschäftigt ist, kann das "Hintenanstellen" von Lync-Paketen in die Queues die Latenzzeit derart erhöhen, dass Sie die Anwender beschweren. Daher schreibt Microsoft auf Running in a Virtualized Environment
http://technet.microsoft.com/en-us/library/gg399035.aspx auch:

  • The host must have at least one network adapter dedicated to the virtual machines running Lync Server roles. Sharing a network adapter with the host or with a storage area network (SAN) is not recommended
  • Note that a Lync Server workload that includes media (Front End Servers and A/V Conferencing Servers) can reach a peak network utilization of more than 500 Mbps.
  • Enable virtual LAN (VLAN) tagging on the network adapter, and implement multiple VLANs on the virtual servers to optimize network traffic.
  • If one host server is running multiple guest virtual servers that each run Lync Server media workloads, ensure that the host network adapter can handle the traffic. To prevent bottlenecks, consider a higher speed network adapter (such as 10 GbE) or multiple network adapters using link aggregation.
  • Use network adapters enabled für Virtual Machine Queue (VMQ). VMQ is a virtualization technology für the efficient transfer of network traffic to a virtualized operating system. VMQ allows the VMs to filter the queue of packets within the network adapter, resulting in improved efficiency of network traffic.

Weitere Links