Enterprise-Topologie mit SQL AlwaysOn
Front-End-Pool, dediziertes SQL-Back-End und Pool Pairing für produktionskritische Skype for Business SE-UmgebungenW I S S E N · S K Y P E F O R B U S I N E S S S E R V E R S E
Skype for Business Server SE Enterprise Edition: Front-End-Pool, SQL AlwaysOn und produktionstaugliche Topologie
Wie du eine SE-Enterprise-Umgebung baust, die einen Serverausfall übersteht – inklusive SQL-2022-Tipps, Pool Pairing und realistischem Sizing.
Boddenberg – IT-Beratung & Engineering · boddenberg.de · Stand: Juni 2026
|
TL;DR Die Kurzfassung für Eilige Die Enterprise Edition trennt Front-End-Workload und Datenbank: Du baust einen Front-End-Pool aus zwei bis zwölf Servern und ein dediziertes SQL-Back-End. Echte Hochverfügbarkeit gibt es nur, wenn beide Ebenen redundant sind – der Pool sorgt für HA der Dienste, SQL AlwaysOn (heute Mirroring vorzuziehen) für HA der Datenbank. Wer nur den Pool härtet, hat einen Single-Point-of-Failure im Back-End. Die SQL-Unterstützung ist gegenüber 2019 CU8HF1 unverändert: Express auf den FE-Knoten, volle SQL-Editionen (2016–2022) im Back-End. Für standortübergreifende Ausfallsicherheit kommt Pool Pairing dazu. |
|---|
Worum es hier geht
Die Standard Edition packt alles in eine Box – nett für Pilotumgebungen, aber ohne Hochverfügbarkeit. Sobald UC produktionskritisch ist (und bei Telefonie ist sie das fast immer), führt kein Weg an der Enterprise Edition vorbei. Dieser Artikel zeigt dir, wie eine produktionstaugliche SE-Enterprise-Topologie aussieht: Front-End-Pool, dediziertes SQL-Back-End, die richtige HA-Strategie und ein Sizing, das zur Userzahl passt. Das große Bild liefert der Pillar „Skype for Business Server SE im Überblick“.
Architektonisch hat sich gegenüber Skype for Business Server 2019 nichts geändert – SE baut auf demselben Codestand auf. Was sich aber lohnt zu aktualisieren, sind die SQL-Empfehlungen: SQL Server 2022 ist mittlerweile die sinnvolle Wahl, und die Express-Instanzen auf den FE-Knoten kommen bei SE bereits als 2022 Express mit.
Die Topologie im Überblick
Der Kern der Enterprise Edition ist die Trennung von Rechen- und Datenebene. Front-End-Server machen die Arbeit, ein dediziertes SQL-Back-End hält die zentralen Datenbanken und den Central Management Store.
Skizze 1: Front-End-Pool (HA der Dienste) getrennt vom dedizierten SQL-Back-End mit AlwaysOn (HA der Datenbank), optional ein gepaarter Pool für Disaster Recovery.
Front-End-Pool
Der Front-End-Pool besteht aus zwei bis zwölf Servern, die identisch konfiguriert sind und sich die Last teilen. Fällt ein Knoten aus, übernehmen die anderen – das ist die HA der Dienste. Auf jedem Knoten läuft eine lokale SQL-2022-Express-Instanz für lokale Datenbanken, die Mediation-Rolle ist bei den meisten Setups kolloziert. Davor gehört ein Load Balancer (Hardware-LB für HTTPS, DNS-Load-Balancing für den SIP-Verkehr).
Dediziertes SQL-Back-End
Hier liegen die zentralen Datenbanken und der Central Management Store. Das Back-End läuft auf voller SQL-Server-Edition (Standard oder Enterprise), nicht Express. Genau das ist die Stelle, an der schlampige Setups einen Single-Point-of-Failure einbauen: Der Pool ist redundant, aber das SQL-Back-End läuft auf einer einzigen Box. Fällt die, steht trotz Pool alles.
|
ACHTUNG HA an der Front reicht nicht Die zwei HA-Ebenen werden ständig verwechselt. Ein Front-End-Pool gibt dir HA der Dienste – aber wenn das dahinterliegende SQL-Back-End auf einem einzelnen Server läuft, hast du HA an der Front und einen Single-Point-of-Failure im Back-End. Produktionstauglich ist erst die Kombination: redundanter Pool und gespiegeltes bzw. AlwaysOn-geschütztes SQL-Back-End. |
|---|
SQL-Voraussetzungen – die Optionen-Matrix
Die SQL-Unterstützung ist gegenüber CU8HF1 unverändert. Wichtig ist die Trennung: Express auf den Front-End-Knoten (lokale DBs), volle Edition im Back-End (zentrale DBs).
|
Rolle |
Unterstützte SQL-Server-Versionen (64-Bit) |
|---|---|
|
Standard Edition (alles in einer Box) |
SQL Server 2016 Express oder SQL Server 2022 Express (empfohlen) |
|
Enterprise Back-End |
SQL Server 2016 / 2017 / 2019 / 2022 – Standard oder Enterprise (voll, nicht Express) |
|
Lokale Express-Instanz (FE) |
SQL Server 2022 Express auf den Enterprise-Front-End-Servern für lokale Datenbanken |
|
TIPP SQL-2022-Tipps für SE Nimm 2022, wenn du die Wahl hast. Wer aus älteren 2019er-Setups kommt, hat im Back-End häufig noch SQL 2016/2017 – ein In-Place-Upgrade auf 2022 modernisiert das ohne Topologieänderung. Auf den Front-End-Knoten installiert SE ohnehin 2022 Express. Achte darauf, Back-End und Express-Instanzen nicht zu vermischen: zentrale DBs gehören auf die volle Edition, niemals auf Express – Express-Limits (DB-Größe, RAM) holen dich sonst im Wachstum ein. |
|---|
AlwaysOn vs. Mirroring – was nehmen?
Für die HA des SQL-Back-Ends gibt es zwei Wege: das ältere Database Mirroring und AlwaysOn Availability Groups. Beide werden unterstützt, aber die Richtung ist klar.
|
Kriterium |
Database Mirroring |
AlwaysOn Availability Groups |
|---|---|---|
|
Status |
Ältere Technik, deprecated |
Aktuelle Empfehlung |
|
Setup-Aufwand |
Geringer |
Höher (WSFC nötig) |
|
Automat. Failover |
Mit Witness |
Ja, robuster |
|
Zukunftssicherheit |
Auslaufend |
Strategisch |
|
Empfehlung für SE |
Nur bei Altbestand |
Neubau: AlwaysOn |
Kurz: Neubau immer AlwaysOn. AlwaysOn setzt einen Windows Server Failover Cluster (WSFC) voraus, ist also etwas aufwändiger einzurichten – dafür bekommst du robusteres automatisches Failover und gehst nicht auf einer deprecated Technik in Produktion. Mirroring ist nur dann vertretbar, wenn du eine bestehende, funktionierende Mirroring-Umgebung übernimmst und kurzfristig nicht umbauen willst.
Pool Pairing – standortübergreifende Ausfallsicherheit
Der Front-End-Pool schützt vor dem Ausfall einzelner Server. Gegen den Ausfall eines ganzen Standorts hilft Pool Pairing: Zwei Front-End-Pools an unterschiedlichen Orten werden gepaart, sodass der eine als Backup-Registrar für den anderen einspringt. Fällt der Hauptpool aus, führst du ein Invoke-CsPoolFailover durch, und die User bleiben anmelde- und anruffähig (Voice-Resiliency).
|
FALLE Pool Pairing braucht Disziplin im Failback Das Failover ist die einfache Hälfte – das Failback die, die gern schiefgeht. Nach einem Standortausfall müssen die User sauber zurück auf den ursprünglichen Pool gebracht werden, sonst hängst du in einem Zwischenzustand. Plane Failover und Failback als getesteten Ablauf, nicht als Theorie im Runbook. |
|---|
Sizing – wie viele Knoten für wie viele User?
Beim Sizing wird gern entweder übertrieben oder gespart. Die folgenden Werte sind Orientierungs-Richtwerte für die Größenordnung – die belastbare Dimensionierung hängt am genutzten Funktionsumfang (reines IM vs. Voll-Telefonie mit Konferenzen) und gehört mit dem Microsoft-Planungswerkzeug verifiziert.
|
Userzahl (Richtwert) |
Topologie |
Hinweis |
|---|---|---|
|
bis ~ einige Hundert |
Standard Edition oder kleiner EE-Pool |
HA nur bei EE; Standard = kein HA |
|
~ Tausende |
EE-Pool, mehrere FE-Knoten |
Knotenzahl nach Workload, SQL-Back-End mit AlwaysOn |
|
Zehntausende / mehrere Standorte |
Mehrere gepaarte EE-Pools |
Pool Pairing für DR, getrennte SQL-Back-Ends |
Faustregeln, die fast immer stimmen: Ein Front-End-Pool sollte mindestens drei Knoten haben, wenn er einen Knotenausfall ohne Kapazitätseinbruch verkraften soll (zwei tragen die Last, einer ist Reserve). Telefonie-lastige Umgebungen brauchen mehr Knoten als reine IM-Umgebungen bei gleicher Userzahl. Und das SQL-Back-End wird gern unterschätzt – die zentralen DBs wollen ordentlich RAM und schnelle Disks.
Backup-Strategie
HA ist kein Backup. AlwaysOn schützt vor Server- und DB-Ausfall, nicht vor logischen Fehlern, versehentlichem Löschen oder Ransomware. Eine SE-Enterprise-Umgebung braucht beides.
Export-CsConfiguration -FileName C:\Backup\CMS.zip
Export-CsLisConfiguration -FileName C:\Backup\LIS.zip
|
HINWEIS Der Consulting-Hebel Die meisten „HA-Setups“, die wir vorfinden, haben einen redundanten Front-End-Pool und ein einsames SQL-Back-End – also genau den Single-Point-of-Failure, den HA verhindern soll. Ein ehrlicher Architektur-Review deckt das in einer Stunde auf. Der zweite Klassiker: AlwaysOn ist da, aber niemand hat das Failback je getestet und die CMS-Sicherung läuft nicht. Produktionstauglichkeit entscheidet sich nicht am Diagramm, sondern am getesteten Ernstfall. |
|---|
Häufige Fragen
Was ist der Unterschied zwischen Standard und Enterprise Edition?
Standard packt alle Rollen auf einen Server – kompakt, aber ohne Hochverfügbarkeit. Enterprise trennt Front-End-Pool und dediziertes SQL-Back-End und erlaubt so HA an beiden Ebenen. Produktionstauglich mit HA-Anspruch ist nur Enterprise.
Brauche ich für Hochverfügbarkeit nur einen Front-End-Pool?
Nein – das ist der häufigste Denkfehler. Der Pool gibt HA der Dienste, aber das dahinterliegende SQL-Back-End muss ebenfalls redundant sein (AlwaysOn oder Mirroring). Sonst hast du HA an der Front und einen Single-Point-of-Failure im Back-End.
AlwaysOn oder Database Mirroring – was soll ich nehmen?
Für Neubauten AlwaysOn Availability Groups. Mirroring ist die ältere, auslaufende Technik und nur dann vertretbar, wenn du eine bestehende Mirroring-Umgebung übernimmst. AlwaysOn setzt einen WSFC voraus, ist aber robuster und strategisch zukunftssicher.
Welche SQL-Server-Version soll ich fürs Back-End nehmen?
Unterstützt sind 2016 bis 2022 in voller Edition (Standard oder Enterprise). Wenn du die Wahl hast: 2022. Die Express-Instanzen auf den Front-End-Knoten kommen bei SE ohnehin als 2022 Express – zentrale DBs gehören aber nie auf Express.
Was ist Pool Pairing und wann brauche ich es?
Pool Pairing paart zwei Front-End-Pools an verschiedenen Standorten, sodass einer als Backup-Registrar für den anderen einspringt. Du brauchst es, wenn ein kompletter Standortausfall abgesichert werden muss. Das Failover ist bewusst manuell über Invoke-CsPoolFailover.
Wie viele Front-End-Knoten brauche ich?
Mindestens drei, wenn der Pool einen Knotenausfall ohne Kapazitätseinbruch verkraften soll. Die genaue Zahl hängt an Userzahl und Funktionsumfang – Telefonie-lastige Umgebungen brauchen mehr als reine IM-Umgebungen. Dimensioniere mit dem Microsoft-Planungswerkzeug, nicht nach Bauchgefühl.
Ersetzt AlwaysOn mein Backup?
Nein. HA schützt vor Server- und DB-Ausfall, aber nicht vor logischen Fehlern, versehentlichem Löschen oder Ransomware. Du brauchst zusätzlich regelmäßige SQL-Backups und eine gesicherte CMS-Konfiguration (Export-CsConfiguration).
Weiterführende Themen
Topologie greift in mehrere Nachbarthemen. Weiter geht es hier:
Fazit
Eine produktionstaugliche SE-Enterprise-Topologie ist kein Hexenwerk, sondern Disziplin an zwei Stellen: HA an beiden Ebenen (redundanter Pool und geschütztes SQL-Back-End mit AlwaysOn) und ein Sizing, das zur tatsächlichen Nutzung passt statt zum Bauchgefühl. Wer Pool Pairing braucht, plant Failover und Failback als getesteten Ablauf.
Der Klassiker, den es zu vermeiden gilt, bleibt der einsame SQL-Server hinter einem schicken Pool. HA an der Front ist keine HA, solange das Back-End allein steht.
Über den Autor
Ulrich B. Boddenberg ist unabhängiger IT-Berater, Software-Engineer und Fachbuchautor mit rund 30 Jahren Erfahrung in Microsoft-Enterprise-Infrastrukturen (Active Directory, ADFS, Entra ID, Exchange, SharePoint, PKI, Teams-Telefonie). Webseite: boddenberg.de.