Hochverfügbarkeit in Microsoft SharePoint mit SQL Server „Always On“
![author](/_image?href=https%3A%2F%2Fassets.avepoint.com%2Fupload%2Fblog%2Fauthor-headshot%2Fdefault.png&w=70&h=70&q=90&f=avif)
By Mario. S
![feature image](https://assets.avepoint.com/upload/blog/featured-image/default-feature-image.png)
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:
- SQL Server Cluster, die eine Failover Möglichkeit auf Instanz-Ebene bieten.
- SQL Server Spiegelung, die eine Kopie der Datenbank auf einem zweiten SQL Server bereitstellt.
- Mehrere Datenbanken können zu Gruppen zusammengefasst werden. Wie etwa eine Gruppe für Inhaltsdatenbanken und eine weitere für Config und Service Applikationen.
- 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.
- 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.
- Backups können von den sekundären Repliken der Datenbanken erstellt werden, um die Performance der produktiven Datenbanken nicht negativ zu beeinträchtigen.
- 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.
Share this blog