Hochverfügbarkeit in Microsoft SharePoint mit SQL Server „Always On“

Mit der Verwendung von Microsoft SharePoint Server für unternehmenskritische Anwendungen wird es zunehmend wichtig, die Ausfallzeiten (Downtime) der Systeme auf ein Minimum zu beschränken und damit die höchstmögliche Verfügbarkeit der Informationen und Dokumente sicherzustellen. Auch die Sicherheit der Daten wie Dokumente, Verträge und in Wikis abgelegte Informationen spielt eine zentrale Rolle.

Auf Seiten von Microsoft SharePoint Server lässt sich dieses Ziel sehr zuverlässig mithilfe von mehrfach vorhandenen Web-Frontend, Applikations- sowie Search Servern erreichen. Diese redundant ausgelegten Systeme decken jedoch nur einen Teil der Anforderungen ab. Fällt durch einen Fehler – verursacht durch Hardware, Software oder „Human Error“ – der Datenbankserver teilweise oder vollständig aus, so stehen einige oder im schlimmsten Fall alle SharePoint-Inhalte nicht mehr zur Verfügung.

Um sich vor einem solchen Szenario zu schützen, kamen bisher vor allem die zwei folgenden Lösungen zum Einsatz:

1. SQL Server Cluster, die eine Failover Möglichkeit auf Instanz-Ebene bieten.
2. SQL Server Spiegelung, die eine Kopie der Datenbank auf einem zweiten SQL Server bereitstellt.

Diese beiden Ansätze haben jedoch auch Nachteile. So schützt der SQL Server Cluster nicht vor einem Ausfall des Storage – was also wieder getrennt mittels gespiegeltem SAN abgesichert werden muss – und ein Failover ist nur für die komplette Instanz mit allen Datenbanken möglich, was je nach Datenbankanzahl und Größe langwierig sein kann. Dies kann dazu führen dass SLAs bezüglich der Down Times nicht eingehalten werden.

Bei der SQL Server Spiegelung erfolgt die Konfiguration und Verwaltung auf Datenbankebene, was die Einrichtung und Überwachung aufgrund der Vielzahl von Datenbanken, die für eine SharePoint Farm notwendig sind, sehr aufwendig macht. Ein weiterer Nachteil beim „Mirroring“ ist auch, dass sich der Servername für die Verbindung bei einem Failover ändert. Dies kann zu Problemen führen, wenn die Applikation weiterhin versucht, sich mit dem primären Server zu verbinden.

Das mit der Version SQL Server 2012 eingeführte Feature „Always On“, vereint nun die Vorteile beider Lösungen:

1. Mehrere Datenbanken können zu Gruppen zusammengefasst werden. Wie etwa eine Gruppe für Inhaltsdatenbanken und eine weitere für Config und Service Applikationen.
2. Pro Verfügbarkeitsgruppe können sogenannte Listener mit DNS Name und IP Adresse angelegt werden, die immer auf den aktiven Node zeigen. Somit bleibt ein Failover für die Applikation transparent. Mittlerweile wird sogar die Verwendung von IP Adressen aus unterschiedlichen Subnetzen unterstützt.
3. Es ist möglich, mehr als eine Replik für unternehmenskritische Inhalte zu erstellen. So können Content DBs beispielsweise synchron in ein lokales Rechenzentrum und zusätzlich asynchron in ein remote Rechenzentrum übertragen werden.
4. Backups können von den sekundären Repliken der Datenbanken erstellt werden, um die Performance der produktiven Datenbanken nicht negativ zu beeinträchtigen.
5. Da sich die Datenbanken auf allen beteiligten Servern bereits im online Zustand befinden, können Failover Vorgänge in extrem kurzer Zeit durchgeführt werden. Das verringert die Downtime für solche Ereignisse massiv.

Diese Übersicht zeigt deutlich, warum SQL Server Always on die bevorzugte Lösung für die Hochverfügbarkeit von SharePoint Datenbanken ist. Durch den Einsatz dieses neuen Features lassen sich Downtimes verringern und die Datensicherheit erhöhen. Durch den Einsatz von 3rd Party Tools von Anbietern wie AvePoint lässt sich die Einrichtung der Verfügbarkeitsgruppen und die notwendige Konfiguration in SharePoint auch weitgehend automatisieren.