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 primäry/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:

  • Lync SBA
    So gibt es z.B. die Lync SBA, die in Niederlassungen den kompletten Lync Server einspart, weil die Anwender auch ohne Verbindung zur Benutzerdatenbank zumindest telefonieren können.
  • Anmeldung per Zertifikat
    Vielleicht haben Sie schon gemerkt, dass sich ein Lync Client nur erstmalig mit ihren Benutzernamen und Kennwort anmeldet aber dann ein Zertifikat zur Anmeldung erhält. Der einfache Trick dahinter ist, dass die Anmeldung damit auch möglich ist, wenn die DomainController eben nicht erreichbar wären.
  • Failover
    Zwei Lync Pools, die durchaus aus zwei Standard Servers bestehen können, können sich gegenseitig vertreten. Zwar ist auch das dann mit FunktionsEinschränkungen verbunden aber es ist kein Totalausfall.

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

  • RTO = Recovery Time Objective (in Stunden)
    Ein Ausfall ist immer ärgerlich und diese Zeit bestimmt, wie lange ein Dienst maximal ausfallen darf. Abhängig von den Vorgaben hier und den Recoveryplänen wird letztlich das Design festgelegt. Das kann ein Single Server mit Restore sein (z.B.: >4h). das kann mit Virtualisierung weiter reduziert werden und wer im Bereich von Minuten agiert, wird dann doch um einen Cluster nicht umhin kommen
  • RPO = Recovery Point Objective (in Stunden)
    Bei jedem Serverausfall, der in einem Neuaufbau mit Restore verbunden ist, gehen Daten verloren, nämlich genau die Änderungen die zwischen der letzten Sicherung und dem Ausfall vorgenommen wurden. Sie können Backups eines Servers nicht im Minuten oder gar Sekundenabstand machen. Sie könnten aber mit SQL-Server und Logs einen Zwischenweg schaffen oder gar per Import/Export der Konfiguration einen Mittelweg finden.

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.:

  • 2x Standard Server
    Ein Lync Standard Server kann bis zu 5000 user hosten. Das kann aber bei vielen Konferenzen vielleicht schon zu viel sein und bei Telefonie ebenfalls. Aber sie könnten zwei Server nebeneinander installieren
  • 2500 user pro Server
    Dann verteilen Sie ihre Benutzer einfach zwischen den Servern gleichmäßig auf. So haben Sie schon mal eine 50% Funktion, wenn einer der Server ausfällt. Nur die Hälfte der Benutzer hat ein noch zu definierendes Problem bei der Anwendung.
  • Mediation Server schon redundant
    Die Mediation Server Rolle, die auf beiden Lync Servern mit installiert ist, ist in sich schon redundant. Ihnen fehlt zur TK-Welt also nur noch das zweite Gateway und die zweite externe Anbindung, um auch hier einen Single-Server-Failure unbeschadet zu überstehen
  • "Backup Pool"
    Seit Lync 2010 können Sie jedem Pool einen Backup Pool zuweisen. Ein Standard Server ist auch einfach nur ein "Pool", in dem eben nur ein Server enthalten ist. Mit zwei Servern haben Sie zwei Pools und können diese Gegenseitig als "Backup" zuweisen. Fällt ein Server aus, dann können sich die Clients am anderen Pool anmelden. Sie haben dann zwar keine Buddyliste und Konferenzen, die auf dem ausgefallenen Pool eingerichtet sind, funktionieren auch nicht mehr, aber Sie können weiter Kurzmitteilungen unter Nutzung der SIP-Adresse senden und empfangen. Und sie können vor allem weiter telefonieren
  • Fast Recovery mit "Force Move"
    Sollte dann erkennbar sein, dass der ausgefallene Server vielleicht nicht mehr "schnell" wiederhergestellt werden kann, dann bietet Ihnen Lync die Option, die Benutzer von dem ausgefallenen Server auf den verbliebenen Server zu verschieben. Technisch wird dabei nur im Active Directory der Homeserver angepasst und der neue Lync-Pool ist dann dafür zuständig. Leider können dabei natürlich weder Buddylisten noch Konferenzen mehr übertragen werden.
    Interessant wird so eine 2 Server Lösung, wenn Sie regelmäßig die wichtigen Daten (Buddylisten) der Server exportieren. Das Programm DBIMPEXP.EXE von Lync erlaubt ihnen einen Export dieser Daten in Dateien, die sie z.B. kreuzweise als Datei ablegen. Dann ist es letztlich nur noch ein Import.
    Ich sage nicht, dass dies eine 100% Wiederherstellung ist, aber es könnte ausreichen, um die RTO/RPO-Anforderungen zu erfüllen.
  • "geplante Ausfälle"
    Aber auch für Servicearbeiten, umbauten im Serverraum, Speichererweiterungen o.ä. sind sie vielleicht besser gerüstet. Es ist relativ einfach und schnell möglich, Benutzer von einem laufenden Server auf einen anderen Server zu verlagern. Wird ein Server durch eine umbaumaßnahme also geplant mehrere Stunden "offline" gehen, dann kann es eine Option sein, alle oder zumindest die wichtigen Benutzer und Dienste umzuziehen. Daher bin ich auch von max. 2500 Benutzern pro Server ausgegangen.

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