Flexible Hochverfügbarkeitsgruppen

Die Konfiguration von Commits ist komplex. Sie zielt letztlich darauf ab, dass ein DNS-Eintrag auf den Listener auf SQL-Server-Seite verweist. Der Listener ist ein virtueller Rechner, den SharePoint anspricht. Daher erfolgt die Implementierung transparent und erfordert keine weiteren Schritte in SharePoint. Bei Ausfall einer primären Replika springt automatisch die optimale sekundäre Replika ein. Ein typisches Beispielszenario in KMU wären zwei separate SQL-Server-Instanzen: eine für Konfiguration, Inhalte und Dienste von SharePoint, eine zweite für die Suche. Die Hochverfügbarkeitsgruppe könnte wie folgt aussehen:

• Konfigurationsdatenbanken: Sie werden in eine spezielle Gruppe integriert und mithilfe von synchronen Commits verarbeitet. Das ist sinnvoll, weil Änderungsfrequenz und Fehlertoleranz niedrig sind.

• Inhaltsdatenbanken: Sie werden ebenfalls in einer Gruppe zusammengefasst und mit asynchronen Commits verarbeitet. In diesem Fall sind Änderungsrate und Fehlertoleranz relativ hoch.

• Servicedatenbanken: Auch diese werden in einer Gruppe zusammengefasst. Die Verarbeitung erfolgt mithilfe asynchroner Commits. Der Hintergrund: Zugunsten der Verwaltbarkeit erfolgt keine weitere Unterteilung in Hochverfügbarkeitsgruppen auf Basis von Datenänderungsfrequenz und Fehlertoleranz.

Fazit

Virtualisierungslösungen eignen sich sehr gut, um hochverfügbare SharePoint-Farmen kostengünstig einzurichten. Wenn man bedenkt, dass ein Ausfall der Server auch KMU schnell einen fünfstelligen Betrag pro Stunde kosten kann, ist es umso wichtiger, sich zu rüsten und über Alternativen nachzudenken. In Anbetracht des möglichen Schadensausmaßes ist eine vergleichsweise kostspielige Hochverfügbarkeitslösung auch für KMU dann im Zweifelsfall vielleicht doch die bessere Wahl. (wh)