Lync Server Team (noch keine DAG)

Gleich vorneweg: Es gibt (noch) keine Lync DAG. Die Funktion von Exchange 2010, dass mehrere Server fast völlig unabhängig  von einander den gleichen Datenbestand haben und sich gegenseitig replizieren und ersetzen können gibt es in Lync 2010 nicht. Aber oft sind es nicht mal die Software und Server sondern organisatorische Dinge, die mit weniger Aufwand eine sehr viel höhere Verfügbarkeit erreichen können. Verfügbarkeit ist immer eine Betrachtung des Gesamtsystems. Ich helfe ihnen gerne dabei.

Hier gibt es bislang immer nur die Wahl zwischen einem Lync Standard Server, der in sich autonom ist oder einem Lync Enterprise Pool mit bis zu 8 Servern, die aber all den gleichen SQL-Server im Backend verwenden. Dieser SQL-Server muss dann natürlich "hochverfügbar" sein und da Lync noch keine SQL Replication mit Primary/Backup unterstützt, muss dies ein SQL-Cluster mit "Shared Storage" sein. Ein Design, welches Exchange 5.5 bis 2003 noch gefordert hat aber mit Exchange 2007 CCR schon aufgeweicht wurde und mit der Exchange 2010 Database Availability Group quasi perfektioniert wurde.

Heute in Lync 2010

Ich möchte nicht darüber spekulieren, wohin sich Lync zukünftig entwickelt, aber auch ohne Lync Enterprise Pools und SQL-Cluster enthält Lync im Gegensatz zu OCS 2007R2 schon einige nette Funktionen, die eine bessere "Verfügbarkeit" erreichen lassen. Hier mal eine kleine Auswahl:

Vielleicht können wie Lync 2010 einfach mit einem Zwischenschritt wie Exchange 2007 CCR vergleichen, der zukünftig noch besser wird.

Verfügbarkeit für ...

Zuerst müssen wir uns aber überhaupt mal Gedanken machen, Welche Funktionen wird mit welcher Verfügbarkeit anbieten müssen. Und dabei gibt es zwei Faktoren einfach pro Funktion zu definieren

Zwei weitere Zeiten müssen Sie hierbei noch beachten. Nämlich die Zeit, bis sie sicher feststellen, dass ein Ausfall/Fehler vorliegt und die Zeit um die Ursache zu analysieren und über die Gegenmaßnahmen zu entscheiden. Erst dann beginnt die eigentliche "Wiederherstellung". Und für die wesentlichen Funktionen müssen Sie von ihren verantwortlichen Personen eine Festlegung erhalten

Funktion Beschreibung RTO RPO
Status, Präsenz Buddylisten und Group Expansion fallen hier herein, Besonders beim RPO bestimmt dies, wie aktuell die Listen der Mitarbeiter nach einen Ausfall sind. Bei 1000 Personen, von denen jeder vielleicht 1x/5Tage was ändert, sind dies 200 Änderungen/Tag die bei einer RPO von 8h erst mal "weg" sind.
Kurzmitteilungen Der Versand von Meldungen zwischen Benutzern ist oft weniger kritisch. Kann aber schnell wichtig werden, wenn die Plattform auch für andere Dienste (Maschine zu Mensch und Maschine zu Maschine-Kommunikation genutzt wird.)
Konferenzen Nutzung der Lync MCUs und Webservices. Ohne Lync Server und der MCU gibt es keine
Telefonie Basis Anrufen und angerufen werden. Wer Lync zum Telefonieren einsetzt, erwartet hier höchste Verfügbarkeit. Und das ist auch ohne Enterprise Pools möglich.
Telefon Zusatzfunktionen Responsegroup, Callpark, unassigned Numner etc.

Viele weitere Lync Dienste sind aber nicht besonders "wichtig". Wenn ein Client das aktuelle Adressbuch für einige Stunden nicht herunter laden kann oder ein Lync Telefon Updates erst später bekommt, dann sehe ich das aktuell erst mal als vernachlässigbar an. Auch mobile Clients werden von den meisten Firmen noch als sekundär angesehen. Sie sollten aber über ein entsprechendes Monitoring sicherstellen, dass auch solche Probleme erkannt werden.

Trennung nach Diensten

Die Unterscheidung der Verfügbarkeiten nach Diensten ist erforderlich, da verschiedene Funktionen über unterschiedliche Methoden verfügbar gemacht werden Können. Das sieht man besonders gut bei der Telefonie, wo Lync 2010 über SBAs, redundante aber in sich autarke Mediation Server und Gateways auch ohne SQL-Cluster sehr gut verfügbar sein kann. Vergessen Sic auch nicht Abhängigkeiten zu "fremden" Diensten wie z.B. IP-Routing, Namensauflösung, Firewalls etc., die mit zu beachten sind.

Eine genaue Analyse ist daher immer ratsam, ehe Sie Geld und Server investieren. Auch die Dokumentation und Checklisten für den Fall der Fälle sind essentiell.

Zwei Standard Server -Team

Ich vermeide den Begriff DAG oder Cluster hier, weil es faktisch kein Cluster ist. Aber ich möchte ihnen an einem theoretischen Beispiel zeigen, wie sie eine Lösung zwischen dem "Single Standard Server", den Sie vielleicht als Hochverfügbarkeit virtuell betreiben und einem Enterprisepool entwickeln können. Wie immer gibt es aber nicht "dir Lösung", sondern es ist ein Bausteinkasten mit Komponenten. So erlaubt Lync durchaus das "Clustern" von Mediation Servern und AV-Servern als Pool, ohne dass man dazu einen Windows Cluster oder SQL-Cluster braucht.

Trotzdem hat sich gezeigt, dass der Betrieb eines SQL-Clusters und eines Lync Enterprise Pools für Fimen im Bereich 0-5000 Benutzer recht teuer und kompliziert ist und oft das Know-how für die komplexere Umgebung fehlt. Stellen Sie sich mal folgendes vor.:

Natürlich können Sie solch eine Konstruktion auch mit 3 und mehr Standard Servern installieren. Und wer weiß, was die Zukunft bringt. Könnte man die Buddy-Listen und Konferenzen einfach zwischen Servern replizieren, dann wären wir schon ganz nahe an einer Exchange 2010 DAG.

2-Standard Server Failover

Die folgende Beschreibung ist genau genommen keine "Hochverfügbarkeit", da sie natürlich nicht von Microsoft supportet ist. Allerdings kann sie ihnen bei einem Ausfall durchaus einmal helfen.

Es ist möglich, in einer Lync-Umgebung zwei oder mehr Standard Server zu installieren und zu betreiben. Allerdings kann ein Server hier eben auch nur "seine" Anwender betreuen, die auch auf ihm als "Homeserver" angelegt wurden und in der lokalen SQL-Express-Datenbank die Buddy-Liste hinterlegt haben. Damit ein Anwender also arbeiten kann, müssen vier Dinge passen:

  1. Funktionsfähiger Lync Standard Server
    mit lokaler SQL-Datenbank, passendem Zertifikat und Konfiguration
  2. Benutzer im Active Directory
    mit Lync Properties, damit Lync diesen Benutzer "kennt"
  3. BuddyListe des Anwenders
    Diese liegt ebenfalls im SQL-Server des Standard Servers vor
  4. DNS Eintrag zum Server
    Wenn der Server nicht per Gruppenrichtlinie eingetragen wird, muss der passende Eintrag im DNS erfolgen

Wer nun zwei Standard Server hat, kann die Benutzer nun sogar auf beide Server verteilen. Meldet sich ein Client am "falschen" Server, dann wird er an den Homeserver verwiesen. Im Fehlerfall kann also nur die Hälfte der Anwender nicht arbeiten. Wer nun erst mal von "geplanten Wartungsarbeiten" ausgeht, kann die Anwender des betroffenen Servers vorher sogar einfach per "Move-CSUser" auf den anderen Server verlagern und nach den Änderungen wieder zurück schieben. Das geht sogar im laufenden Betrieb. Die Anwender merken nur kurz, dass sich der Lync Client ummeldet. Telefonverbindungen bleiben sogar bestehen.

Bei einem ungeplanten Ausfall hingegen können die Benutzer erst mal nicht arbeiten. Normalerweise müssen Sie hier nun entscheiden, ob der Ausfall nur temporär ist, d.h. in vertretbarer Zeit der Server wieder online geht oder ob der Ausfall mit einem Verlust des Servers samt der Daten der SQL-Datenbank verbunden ist. Wenn ihnen die Anwender genug Zeit geben, können Sie den Server natürlich wieder aus einem Backup wiederherstellen und damit die Funktion samt der Buddylisten wieder bereit stellen.

Sollte das aber alles nicht mehr gehen, dann bietet Lync die Funktion, die Benutzer auf einen anderen vorhandenen Server zu verschieben. Per Powershell können Sie damit alle User von einem Pool auf den anderen Pool verschieben

Get-CsUser -Filter {RegistrarPool -eq "lyn01.msxfaq.de"} | %{
    move-csuser -identity $_.identity -target lync02.msxfaq.de -force
}

Der Parameter "-force" sorgt dabei dafür, dass der Move nicht abgebrochen wird, wenn der Quellpool nicht mehr da sein sollte. Damit erreichen Sie, dass der Benutzer sich wieder anmelden kann. Schade nur, dass er keine Buddyliste mehr hat, da der Move diese Daten nicht exportieren konnte.

Wenn Sie auf diesen Fall besser vorbereitet sein wollen, dann müsste Sie nur etwas Vorarbeit leisten: Microsoft hat ein Programm auf dem Lync-Server hinterlegt, welches es ihnen erlaubt die Buddylisten eines oder aller Benutzers einfach als XML-Datei zu exportieren.

DBImpExp.exe /hrxmlfile:\\lyns2\buddy$\user1.xml /user:user1@msxfaq.de

Fragen Sie mich bitte nicht, warum dies immer noch eine EXE kein kein Powershell Commandlet ist. Aber damit könnten Sie regelmäßig und entsprechend ihrer RPO-Vorgabe die Buddyliste der Benutzer des einen Servers als XML-Dateien auf den anderen Server exportieren lassen. Käme es dann zu einem Ausfall eines Server, der nicht mehr durch Restore oder Reparatur behoben werden kann, dann können Sie die Benutzer "hart" verschieben" und die Buddy-Liste wieder importieren.

DBImpExp.exe /import /hrxmlfile:\\lyns2\buddy$\user1.xml /user:user1@msxfaq.de

Dass der alte Server noch im DNS enthalten ist, ist kein Problem, da der _sipinternaltls._tcp.sipdomain.tld ja idealerweise auf mehrere Server verweist und der Lync-Client alleine dann zum nächsten Server geht. Die Anmeldung dauert nur ein bisschen länger (wenige Sekunden) bis der Client umschwenkt.

Das ist aber leider noch nicht alles. Zu einem Lync-Server gehören mehr als nur ein paar Benutzer mit Buddylisten. Ein Lync Server ist auch Konferenzserver, auf dem z.B. Inhalte für Meetings liegen, auf dem das Adressbuch ist und der in eine ganze Menge anderer Systeme eingebunden sein kann, z.B. als "Next Hop" für den Edge Server oder als IIS-Seite für die Veröffentlichung über eine Firewall. Auch die LIS-Datenbank mit den Standorten etc. sind bei einem solchen "Failover" wieder zu berücksichtigen

Fallback
Wenn Sie aber sowieso wieder einen "Fallback" in relativ kurzer Zeit vorhanden, dann können Sie mit dem Gedanken spielen, nur die Buddyliste zu übertragen und damit den Benutzern eine bessere Funktion für die Übergangszeit bereit zu stellen. Ziel muss dann natürlich eine schnelle Wiederherstellung des Quellservers sein.

Es ist auf jeden Fall „Handarbeit“ und eine gute Dokumentation erforderlich. Einen automatischen Failover o.ä. gibt es hier nicht. Wer mag, kann natürlich alle Wege doppelt auslegen und mit einem Loadbalancer davor sogar die Zugriffe automatisch auf den überlebenden Standard Server weiter reichen. Die Übertragung der Benutzer mit Import der Buddyliste sollte aber immer ein vom Administrator ausgeführter Prozess sein. Denn dazu muss erst sicher festgestellt werden, dass der angeblich ausgefallene Server tatsächlich unwiederbringlich oder nicht zeitnah wiederherstellbar ist. Selbst dann sind Einstellungen in DNS, Adressbuch, Edge-Server Konferenzdateien, Lync Konfiguration, VoIP-Routing etc. zu prüfen.

Wenn Sie aber mit DBIMPEXP vorsorglich die Buddy-Listen regelmäßig exportieren, dann kann der katastrophale Ausfall eines Servers doch deutlich abgemildert werden.

Pool auf zwei Standorte

 

Weitere Links

Keywords:Lync DAG HA Cluster RTO RPO