Skype for Business Verfügbarkeit
Welche Optionen habe ich, um Skype for Business On-Prem besser verfügbar zu machen? Wann ist PoolPairing und wann ein Enterprise Pool angebracht und welche Rolle spielt noch die SBA?
Beachten Sie dazu aber auch alle anderen Komponenten (Siehe SfB Ausfall ) einer SfB Umgebung, die ausfallen und damit eine Funktionseinschränkung oder Unterbrechung verursachen können.
Verfügbarkeits-Tic-Tac-Toe
Bei der Feuerwehr wird oft von einem "Gefahrendiamant" (https://de.wikipedia.org/wiki/Gefahrendiamant) gesprochen und auch wenn das überhaupt nichts mit einem Edelstein zu tun hat, so kennen viele Leute die Bedeutung. Für Skype for Business habe ich mir ein anderes Muster einfallen lassen, welches unbestritten an das Spiel "Tic-Tac-Toe" oder "3 gewinnt" erinnert. Ich nenne es mein "Gefahren Tic Tac Toe", da es die drei Anwendungsfälle von Skype for Business mit drei Fehlerszenarien in Verbindung setzt.
Die drei Skype for Business Funktionsblöcke, von Microsoft gerne auch "Modalities" genannt, sind:
- Instant Messaging und Präsenz
- Konferenz per Web, Video, PC, Audio, Telefoneinwahl
- Telefonie, Skype for Business als PBX
Für alles drei Bereich kann man unterschiedliche Anforderungen für die Ausfallszenarien aufstellen:
- Reguläre Wartungsmaßnahmen wie z.B. Patchen und Updates
- Einzelne Hardware-Ausfälle
z.B. ein Server ist aus, Speicherdefekt etc., die durch "Hochverfügbarkeit" abgedeckt werden sollen.
Ein Ausfall einer Festplatte im RAID oder eines redundanten Netzwerks oder einen Links in einem Adapter-Teaming zähle ich da aber nicht dazu. - RZ-Fail
d.h. der Ausfall eines kompletten Bauanschnitts mit mehreren Servern. Dann spricht man von "Site Resilency".
Für all diese Fälle kann ich nun die verschiedenen Skype Business Ausbaustufen nutzen, um eine entsprechende Lösung bereit zu stellen.
Single Standard Server
Ein Single Skype for Business Server kann laut Microsoft bis zu 5000 Benutzer betreiben. Diese Zahlen muss man natürlich relativieren, denn die Anzahl der Anwender sehe ich als weniger relevant an als deren Nutzungsverhalten. Viele Konferenzen oder Telefonate über den Mediation Server sind sicher "belastender" als etwas Status und IM. Und die Aussagen zu "schnellen Disks" lassen sich in Zeiten von SSDs auch nur noch eingeschränkt als Limit vorgeben. In Bezug auf die Verfügbarkeit ist aber eine Single Server Installation natürlich der GAU.
Senn der Standards-Server nicht verfügbar ist, geht eigentlich gar nichts mehr. Dennoch gibt es solche Installationen und auch Net at Work hat lange mit diesem Modell gearbeitet, denn Ausfälle gibt es immer wieder. Eie aufwändigere "hochverfügbare" Plattform ist durch die Komplexität nicht immer besser und ein Ausfall in einer so einfachen Umgebung lässt sich mi dem richtigen Backup oder Desaster-Strategie durchaus bewältigen. Insbesondere wenn die Fachleute im eigenen Hause sind.
Standard auf VM
Interessanter wird das Modell in Verbindung mit einer Virtualisierung. Skype for Business Dienst können auch virtuell betrieben werden, wenn ein korrektes Sizing erfolgt. Durch die Virtualisierung gewinnen wir aber nicht nur die Möglichkeiten von Snapshots und schnellen Backup/Restore-Optionen um im Defektfall wieder einen etwas älteren Stand zu erhalten. Sobald zwei oder mehr VM-Hosts vorhanden sind, können Systeme im Fehlerfall der Hardware oder eines RZ in der Regel sehr schnell auf einem anderen Host wieder gestartet werden. Allerdings dauert dies etwas, so dass die Kreise nicht durchgängig "Grün" sind.
Einzig die "geplanten Wartungen" wie z.B. Windows Updates oder Skype for Business Service Packs sind weiterhin mit einem Wartungsfenster verbunden.
Pool Pairing
Mit der Option "Pairing" hat Microsoft einen Weg geschaffen, so etwas die wie damalige Exchange 2007 Datenbank-Replikation auch in Skype for Business einzubauen. Zwei identische Server können ihre Datenbestände, d.h. Buddylisten, Konferenzinhalte etc. miteinander replizieren. Fällt ein Server aus, dann hat der andere Server die Daten schon einmal lokal vorliegen. Allerdings werden diese Daten nicht automatisch aktiv. Der Administrator muss hier manuell eingreifen. In der Zwischenzeit können sich die Anwender aber dennoch an dem "anderen" Pool anmelden. Sie sehen zwar keinen Status und auch ihre Konferenzen funktionieren noch nicht aber sie sind per Telefon weiter erreichbar und auch Kurzmitteilungen kommen weiter an.
Damit der zweite Pool die Arbeit übernehmen kann, muss der Administrator aber von Hand ein "Invoke-CSPoolFailover" ausführen. Dem kommt natürlich bei der Rubrik "Patchen" eine besondere Bedeutung hinzu. Ich habe hier extra "Sternchen" addiert, denn "grün" ist der teil nur, wenn der Administrator einen Pool zum Patchen vorher "Frei" fährt. Das könnte er zwar auch durch ein Verschieben der Benutzer auf den neuen Pool machen aber das bringt wieder viel Unruhe ins Active Directory und die Clients. Besser ist hier ein geplanter Pool-Failover. Dennoch werden die Client für einige Minuten etwas "zucken", bis sie den Wechsel auch vollzogen haben und auch hinsichtlich Federation gibt es Einschränkungen.
Sie können so langsam sicher besser ermessen ,dass ein Pool Pairing eher eine Lösung für "Site Resilency" ist, d.h. Überleben bei einem RZ-.Ausfall mit manuellen Switch-Over. Es kann aber durchaus auch eine Lösung für eine bessere Verfügbarkeit sein. Hochverfügbar würde ich das Konstrukt aber nicht nennen und denken Sie dran, dass Sie jeden Server zu maximal 50% belasten dürften, damit er im Fehlerfall auch die anderen 50% übernehmen kann.
Enterprise Pool
Für eine echte Hochverfügbarkeit hat Microsoft natürlich den "Enterprise Pool" vorgesehen. Hier können bis zu 12 Server gemeinsame auf einer hochverfügbaren Backend-SQL-Datenbanken arbeiten und angeblich bist zu 80.000 Benutzer betreiben. Davon dürfen aber maximal 2 Server gleichzeitig "down" sein. Aus Sicht der Anwender kommt diese Konstruktion natürlich am ehesten einer "Hochverfügbarkeit" entgegen. Auch als Admin können Sie einzelne Server quasi "leerfahren" (Dienste pausieren bzw. Invoke-CSComputerFailover") und dann am Server arbeiten ohne Anwender zu stören.
Das ganze ist natürlich mit einem kräftigen Aufschlag verbunden, da Sie viel mehr Server, Loadbalancer aber auch SQL-Lizenzen benötigen.
Und bei all dem ist so ein Single Pool noch keine Lösung für ein verteiltes Rechenzentrum. Skype for Business unterstützt keine Streched Pools" über zwei Standorte, seien sie auch noch so schnell miteinander Verbunden. Im Gegensatz zu einem Exchange Server halten immer nur drei Server eine Kopie der Daten und wenn Sie daher einen Pool aus 7 Servern haben und ein RZ ausfällt, dann kann ein Teil der Anwender definitiv nicht mehr arbeiten, obwohl 4 Server laufen. Aber auch ein Pool mit 3 Servern ist kritisch, wenn die Seite mit den 2 Servern ausfällt. Dann ist der verbliebene nicht mehr in der Mehrheit. Wenn Sie nun einen Pool mit einer geraden Anzahl an Servern aufbauen wollten, dann muss die SQL-Datenbank, die dann ja auch über zwei RZ-Standorte gespiegelt wird, als Quorum mithelfen. Das kann gehen, das kann aber auch sprichwörtlich daneben gehen und Microsoft wird so eine Konfiguration als "not supported" auch nicht begeistert unterstützen. Da so eine Konstellation auch nicht "getestet" wird, besteht immer das Risiko der Funktionsunfähigkeit mit einem Update oder Servicepack. Daher ist die Spalte "Rz Fail" im Verfügbarkeits-Tic-Tac-Toe auch rot.
Enterprise Pool mit Pairing
Wenn Sie wirklich neben der Hochverfügbarkeit auch einen RZ-Ausfall absichern müssen, dann sind zwei Enterprise Pools mit PoolPairing die propagierte Lösung. Hier verbinden sich wieder alle Funktionen. Allerdings ist das dann schon eine Hardware- und Software-Schlacht, die sich mit kleinen Benutzermengen nicht argumentieren lässt. Hier muss man einfach genau abwägen, welche Anforderungen gestellt werden und welcher Preis dafür aufzurufen ist. Manchmal ist die geforderte Hochverfügbarkeit doch nicht in Stein gemeißelt.
Fragen Sie doch mal, wie "hochverfügbar" die heutige Telefonanlage ist, oder die Amtsleitung nach draußen. haben die Etagen-Switch auch alle eine USV oder sind beim Stromausfall die Server nur noch mit sich selbst beschäftigt, weil kein Client Sie mehr erreichen kann.
Spätestens hier geht es nicht mehr nur um die technisch schicke Lösung sondern auch um betriebswirtschaftliche Betrachtungen.
SBA
In der Betrachtung zum Thema Verfügbarkeit darf man die "Survivable Branch Appliance" oder "Survivable Branch Server" nicht vergessen. Ursprünglich wurde diese Komponenten von Microsoft für Niederlassungen mit eigener Amtsverbindung vorgesehen. Falls hier die WAN-Verbindung zum zentralen Frontend ausfällt, konnten die Anwender zumindest noch miteinander Chatten und natürlich telefonieren. Daher habe ich hier in den beiden Feldern einen gelben Marker gesetzt, da nur Basisfunktionen möglich sind. "Überleben" ist das richtige Wort. Response-Groups, Präsenz etc. sind so nicht möglich.
Interessant ist die Kombination eines "Frontend Server" mit einer SBA/SBS am gleichen Standort. Die Anwender nutzen dann die SBA obwohl der Frontend daneben steht. Konferenzen und Responsegroups bedient der Frontend. Fällt nun der Frontend aus, dann arbeiten die Anwender auf dem SBA/SBS einfach eingeschränkt weiter als wenn eine WAN-Verbindung entfallen wäre. Fällt hingegen die SBA/SBS aus, dann schwenken die Client auf den daneben stehenden Frontend und die Funktion bleibt einfach erhalten, wenn alles richtig konfiguriert ist. Das betrifft insbesondere die Trunks zwischen der Skype for Business Topologie und der externen Anbindung.
Office 365
Wenn sie nun aber "hohe Verfügbarkeit" benötigen aber ihre Benutzeranzahl überschaubar ist und ein Frontend-Pool + Pairing nicht ins Budget passt, dann kann Office 365 durchaus eine Option sein. Microsoft betreibt ja in der Cloud auch Skype for Business Online mit entsprechenden Anforderungen an die Verfügbarkeit und die Funktionen "IM/Präsenz" aber auch "Konferenz" sind weltweit in nahezu allen Ländern verfügbar. Zudem hat Microsoft ein entsprechendes Backbone, um die Client möglich schnell über ihr eigenes Netzwerk zu routen und damit die Laufzeiten möglichst gering zu halten.
In immer mehr Ländern bietet Microsoft selbst schon Telefonnummern an, so dass Sie sogar mit Skype for Business Online schon telefonieren könnten. Wer erweiterte Anforderungen hat oder es keine Rufnummern von Microsoft gibt, kann mit der Skype for Business Cloud Connector Edition (CCE) ebenfalls Telefonnummern bereit stellen. Office 365 kann also schon eine komplette "Lösung" für Skype for Business inklusive Telefonie darstellen.
Weitere Links
- Skype Business Ausbaustufen
- Lync Ausfall
- Lync Server Team (noch keine DAG)
- Lync 2010 HA
- Skype for Business Cloud Connector Edition (CCE)
- SBA - Survivable Branch Appliance / SBS Survivable Branch Server
- Plan for high availability and disaster recovery in Skype
for Business Server 2015
https://technet.microsoft.com/en-us/library/ms.lync.plan.highavailabilitytype.aspx - Front End pool disaster recovery in Skype for Business
Server 2015
https://technet.microsoft.com/en-us/library/jj204697.aspx - Managing Lync Server 2013 disaster recovery, high
availability, and Backup Service
https://technet.microsoft.com/en-us/library/jj721939(v=ocs.15).aspx