16. September 2013

Warum soll Lync 2013 mindestens drei Frontend Server in einem Enterprise Pool haben?

Wer sich mit Lync beschäftigt steht immer wieder vor der Frage: Brauche ich einen Lync Standard Server oder benötige ich mehr Redundanz und mehr Verfügbarkeit mit einer Enterprise Version? und wie viele Front-Ends bentöige ich?

Der große Unterschied zwischen der Lync Enterprise Edition und dem Standard Server ist die Möglichkeit mit mehreren Front-End Servern im Pool einen redundanten Lync Enterprise Pool zu bauen. Hier werden auf mehreren Lync Frontend-Servern die Anwender und Ihre Daten automatisch verteilt. Dieser sogenannte Enterprise Pool kann in Lync 2013 bis zu 12 Server haben und alle Server haben die gleiche Lync-Konfiguration (Lync Pool). Fällt nun ein Server im Pool aus, so übernehmen automatisch die verbleibenden Front-End Server die Funktion und der Lync Client wird im Idealfall, ohne das es der Anwender merkt, auf einem anderen Server angemeldet/verschoben. Die Verteilung der User auf den Servern im Pool geschieht automatisch in sogenannte User Groups und lässt sich nicht durch den Administrator beeinflussen. Die User Groups werden auf zwei weitere Front-End Server im Lync Pool repliziert (vorausgesetzt es gibt mindestens drei Front-Ends). Gibt es weniger, so wird nur die entsprechende Anzahl an Kopien angelegt, mehr als drei sind es aber nie.

Somit wird die User Group einem primären (primary), sekundären (secondary) und tertiären (tertiary) Front-End zugeordnet und die Daten des Anwenders auf diese Server zusätzlich verteilt.

LyncFabric

Mit der neuen Lync 2013 Architektur hat Microsoft ein Hauptproblem der Skalierung von Lync behoben. So werden die Anwenderdaten primär auf dem primären Front-End des Users verwaltet. Dies schließt auch die Verwaltung der Präsenzinformationen ein. Dafür speichern die SQL Express 2012 Datenbanken mehr Informationen lokal auf jedem Front-End Server (RTCLOCAL Instanz).

Nur die dauerhaft zu speichernden Daten (z.B. Response Group Settings, Buddy List, geplante Meetings, Rufumleitungen, etc.) werden auf die SQL Backend Datenbanken als sogenannte „Lazy Writes“ gespeichert. In Lync 2010 gab es diese Trennung nicht. Deshalb führte ein Ausfall der SQL Backend Datenbanken auch immer gleich zu einem „limited functionality mode“ in Lync 2010. In Lync 2013 kann ein Lync Pool bis zu 30 Minuten „überleben“. Erst danach wird ein „limited functionality mode“ für den Anwender sichtbar.

Fällt ein Front-End Server im Pool aus, oder wird heruntergefahren, dann werden die User, die Ihre primäre Gruppe auf diesem Server hatten, auf den Server mit der sekundären, bzw. tertiären Kopie verschoben. Sind alle drei Kopien (Gruppen) nicht erreichbar, und es gibt noch mehr Front-End Server im Pool, dann werden die Daten aus der SQL Backend Datenbank (die mit den Lazy Writes) gelesen und auf dem vierten Front-End Server eine neue User Group erstellt. Anschließend werden die User dann dieser neuen User Group zugeordnet.

Was passiert im Hintergrund?

Bei der Installation eines Lync Enterprise Pools wird ein Windows Fabric Cluster mit allen Lync Front-End Servern als Knoten angelegt (.\Setup\amd64\WindowsFabric.msi). Jeder Knoten (also Lync Front-End Server) bekommt seine eigene eindeutige Routing Group ID und eine Node ID. Leider ist die Verwendung der Begriffe User Group und Routing Group in der Lync Dokumentation etwas verwirrend. Ich verwende in der Zeichnung oben den Begriff Group und meine zur Vereinfachung beide damit.

Aufgrund der eindeutigen Zuordnung von Routing Group ID und Node ID zu Servern und User Groups, weiß also jeder Anwender (Client), an welchem Server er sich anmelden muss. Jeder Front-End Server, bzw. jede Node ID hat einen aktuellen Fabric Status. Die Windows Fabric überwacht diesen Status dauerhaft und speichert dieses in der SQL Backend Datenbank.

LyncFabricSQL

Damit ein Lync Pool läuft und dem Anwender Dienste anbietet muss eine Mindestanzahl an Lync Servern verfügbar sein. Microsoft beschreibt die Anforderungen hier: http://technet.microsoft.com/en-us/library/gg412996.aspx

In diesem Artikel schreibt Microsoft außerdem, dass sie mindestens drei Front-End Server für einen Enterprise Pool empfehlen.

Warum benötige ich mindestens drei Front-End Server in einem Enterprise Pool?

Man kann es bereits erahnen: Wir haben idealerweise drei Kopien der User Groups in unserem Windows Fabric Cluster. Die Windows Fabric setzt ein sogenanntes Cluster Quorum voraus. Dieses Quorum dient dazu die Datenintegrität im Falle eines Ausfalls von Teilkomponenten zu wahren. Damit die Bewertung des Quorums valide ist, muss immer mindestens mehr als die Hälfte der beteiligten Einheiten/Dienste/Komponenten verfügbar sein (Split-Brain Problem). Bein einem Lync Enterprise Pool mit drei Front-End Servern ist also die Mehrheit sehr leicht herzustellen. (2:1 oder 1:2 = 33% : 66%).

Was ist bei einem Enterprise Pool mit nur zwei Front-End Servern?

Wir haben gelernt, dass der Windows Fabric Cluster immer eine Mehrheit (Quorum) benötigt, damit er seine Lync Dienste bereitstellt. Bei einem Lync Pool mit nur zwei Servern bekommen wir diese Mehrheit nicht zustande: (1:1 oder 50% : 50%). Hier behilft sich die Windows Fabric eines Tricks um einen Entscheidungsmehrheit herbeizuführen. Es ernennt den SQL Backend Server zu einem weiteren „Voter“. Damit haben wir wieder eine ungerade Anzahl von Stimmberechtigten und wir erhalten in jedem Fall eine Mehrheit (Quorum). Schaut man sich die aktuelle Windows Fabric Konfiguration auf einem Lync Server in einem „2 Front-End Server“ Pool an sieht man den SQL Server als zusätzlichen „Voter“.

FabricVoter

Was aber auch auffällt, ist das hier in diesem Beispiel nur der Name des SQL Mirror Principals (SQL01.uccloud.net) gespeichert ist. Tatsächlich ist in diesem Beispiel der SQL01 noch mit dem Server SQL02 gemirrored (sh. Bild oben). Findet also ein Failover des SQL Principal auf den Mirror statt, verlieren wir unseren zusätzlichen „Voter“, und damit die Mehrheit im Windows Fabric Cluster. Ohne die Mehrheit (Quorum) ist unser Lync Pool nicht mehr einsatzfähig und schaltet nach fünf Minuten in den „Limited Functionality Mode“. Ob die Windows Fabric in zukunft noch ein Update erhält um auch einen SQl Mirror als Voter zu unterstützen, kann ich derzeit nicht sagen.

Sollte ich einen Front-End Pool mit zwei Server betreiben?

Nun, das überlasse ich Ihnen. Ihnen muss bewusst sein, das derzeit ein 2 Front-End Server Pool zusammen mit SQL Mirroring keine gute „Überlebensfähigkeit“ darstellt. Nach fünf Minuten Ausfall des SQL Principals wird der Limited Functionality Mode initiiert. Sie gewinnen durch das SQL Mirroring also keine höhere Verfügbarkeit Ihrer Dienste. Auch werden Ihre Benutzerdaten nicht wie sonst auf drei Replicas verteilt, sondern stehen nur als primary und secondary Kopie zur Verfügung. Ansonsten läuft ein Lync Pool mit zwei Server wie ein Pool mit drei ober mehr Servern.

Zusammengefasst sind für den Betrieb eines 2 FE Pools folgende Punkte zu beachten:

  • Wenn Sie für Updates einen Front-End herunterfahren müssen, sollten Sie diesen so schnell wie möglich wieder online bringen.
  • SQL Mirroring bringt Ihnen nicht viel. Ohne den SQL Principal wird der Pool nach fünf Minuten in den Limited Functionality Mode gehen.
  • Am Besten starten Sie beide Front-Ends gleichzeitig neu. So vermeiden Sie Probleme bei der Bestimmung des Fabric Quorums!
  • Können Sie nicht beide Front-End Server gleichzeitig starten, so starten Sie diese in umgekehrter Reihenfolge zum Shutdown. Die Reihenfolge der Server können Sie sich mit folgendem cmdlet ausgeben lassen:

Get-CsPoolFabricState -PoolFQDN <FQDN>

  • Können Sie die Server nicht in umgekehrter Reihenfolge starten, so müssen Sie vor dem Start der Lync Dienste das Windows Fabric Quorum neu berechnen lassen:

Reset-CsPoolRegistrarState -ResetType QuorumLossRecovery -PoolFQDN <FQDN>

Was ist mit einem Lync Enterprise Pool und nur einem Front-End Server?

Diese Variante ist ähnlich dem Setup des 2FE Pools. Einen echten Vorteil gegenüber einer Standard Edition sehe ich aber nicht. Sollten Sie planen einen zweiten und dritten Front-End Server zeitnah (am nächsten Tag/Woche) zu installieren, dann ist dieser Schritt natürlich legitim. Haben Sie aber noch keine konkreten Pläne für die Installation der weiteren Server, und wollen sich einfach alles offenhalten, dann empfehle ich dennoch nur die Installation einer Standard Edition. Lizenztechnisch ist dieses dieselbe Lizenz, und sie sparen sich eine SQL Server Lizenz. Der Betrieb einer Standard Edition ist für den Einstieg sicherlich die einfachere Option, denn die Funktionen aus Anwendersicht sind die gleichen. Sie verbauen sich nichts mit der Entscheidung zu einer Standard Edition.

Kommentare:

  1. Endlich hat das jemand mal anschaulich erklärt! Danke

    AntwortenLöschen
  2. From the Feinsten ;-) Grazie Mille!

    AntwortenLöschen