SharePoint hochverfügbar machen in 5 Schritten

Die Anforderungen an die Verfügbarkeit der IT-Infrastruktur in kleinen und mittelständischen Unternehmen (KMU) steigen kontinuierlich. IT-Systeme gewinnen zunehmend an geschäftskritischer Relevanz und müssen daher hochverfügbar sein. Doch Hochverfügbarkeit hat ihren Preis. Daher nehmen insbesondere KMU mögliche Ausfälle häufig in Kauf, um ihr Budget zu schonen.

Doch gerade der Ausfall geschäftskritischer IT-Systeme kann Betriebe teuer zu stehen kommen, wie eine aktuelle Befragung des Marktforschungsunternehmens Techconsult im deutschen Mittelstand bestätigt: Demnach kosten Ausfälle ein Unternehmen pro Jahr durchschnittlich 380.000 Euro. Der unterbrechungsfreie Geschäftsablauf ist also auch für kleine und mittlere Unternehmen ein entscheidender Wettbewerbsfaktor.

Für einen IT-Ausfall gibt es weit mehr Ursachen als die häufig genannten Viren und Würmer. Hinzu kommen Fehler in der Hardware, unausgereifte Software und menschliches Versagen. Stromausfälle und Brände, Diebstahl, Sabotage oder Hochwasser stellen ebenfalls ein Risiko für Infrastruktur und Daten dar. Viele Gründe also, die für hochverfügbare IT-Landschaften sprechen - und gut, dass sich diese mit fundiertem Technikwissen durchaus auch zu akzeptablen Kosten realisieren lassen. Ein Beispiel: SharePoint hat sich in vielen KMU zum Dreh- und Angelpunkt der Kommunikation und damit zur geschäftskritischen Anwendung entwickelt. Umso wichtiger daher, dass die Plattform hochverfügbar ist - und das auf wirtschaftliche Weise.

Aufbau einer hochverfügbaren und wirtschaftlichen SharePoint-Farm

Ein Betrieb mit 50 Mitarbeitern und einem Jahresumsatz von fünf Millionen Euro plant, eine SharePoint-Farm aufzubauen. Dabei verfügt er - wie viele KMU - nur über eine relativ einfache IT-Struktur ohne Storage Area Network (SAN). Das Datenvolumen beläuft sich während des Produktlebenszyklus auf etwa drei Terabyte. Die technische Grundlage bildet eine Server-Farm mit einem beziehungsweise zwei Servern und jeweils einem eigenen SQL-Server. Da es sich in diesem konkreten Fall um ein geschäftskritisches System handelt, sollte die Server-Farm mindestens aus zwei Servern bestehen. Die Struktur sieht demnach aus wie folgt: jeweils zwei Web-Fontend (WFE)-, Anwendungs- sowie SQL-Server. Die Verfügbarkeit des Systems liegt so bei 99,9 Prozent.

Virtualisierung, Clustering und Redundanz für hochverfügbare Systeme

Hochverfügbarkeit gewährleistet einen Betrieb ohne spürbare Unterbrechungen, selbst wenn das gesamte System oder auch nur einzelne seiner Komponenten ausfallen. In der Praxis erreichen Unternehmen dies durch Redundanz und Clustering. Damit in einem Cluster ein zweiter Server den Betrieb des ersten nahtlos übernehmen kann, muss der zweite Server immer betriebsbereit sein und sollte auf dem gleichen "Wissensstand" sein wie der erste Server. Das heißt, die Daten müssen ständig synchronisiert werden. Darüber hinaus ist eine Verbindung zwischen den beiden Servern ebenso erforderlich wie eine Software, die einen Ausfall unmittelbar erkennt und dafür sorgt, dass der zweite Server den Betrieb übernimmt. Hierzu sind IP-Adressen nötig, die sich dynamisch dem jeweils aktiven System zuordnen lassen.

Zudem sollten bei den Servern die zentralen Komponenten, also Netzteile und Festplatten, mehrfach vorhanden sein und mindestens zwei identische Server-Systeme eingesetzt werden. Aus Kostengründen kommt für kleine Unternehmen ein Clustering auf Hardware-Ebene nicht in Betracht. Günstiger ist eine Ausfallsicherheit auf Anwendungsebene. Dazu wird ein Server mit lokalem Speicher als Virtualisierungs-Host implementiert.

Denn in einer vollständig virtualisierten Umgebung können Unternehmen im Ernstfall ihre Infrastruktur - zwar mit verringerter Leistung - komplett funktionsfähig halten. Beliebte Virtualisierungslösungen stellen Microsoft Hyper-V und VMware ESX dar, wobei jedoch deutliche preisliche Unterschiede bestehen. Viele KMU setzen daher auf die Microsoft-Variante. Der Anbieter charakterisiert eine Server-Farm mit hoher Verfügbarkeit dadurch, dass potenzielle Einzelfehlerpunkte minimiert werden, Ausfallereignisse transparent erfolgen und keine beziehungsweise kaum Auswirkungen auf die Nutzeraktivität haben, die Farm belastbar ist und im schlimmsten Fall zwar mit verringerter Leistung arbeitet, aber nicht ausfällt.

Single Points of Failure eliminieren

Bevor sich die IT-Verantwortlichen in Unternehmen daran machen, eine hochverfügbare SharePoint-Umgebung aufzubauen, müssen sie potenzielle Fehlerpunkte identifizieren. Netzwerk, Server, Dienste und Datenbank sind die wichtigsten Einzelfehlerpunkte, auch Single Point of Failure, SPOF, genannt. Prinzipiell ist auch der Ort Serverraum ein potenzieller Einzelfehlerpunkt. In KMUs spielt er jedoch eine untergeordnete Rolle, da sie nur selten verteilte Rechenzentren an unterschiedlichen Örtlichkeiten betreiben.

Einzelfehlerpunkte lassen sich durch Redundanz eliminieren. Im Grunde genommen werden alle vier Fehlerquellen - Netzwerk, Server, Dienste und Datenbank - abgedeckt, wenn die Struktur die Leistungsanforderungen erfüllt und auf jeder dieser Ebenen redundant ausgelegt ist. Beim Netzwerk nützt sämtliche redundante Auslegung der Komponenten und Dienste nichts, wenn die gesamte Architektur zum Beispiel an einem einzelnen Netzwerkswitch hängt. Fällt dieser aus, ist das System nicht erreichbar. Daher bietet sich die Anbindung an mindestens zwei Switches an. Da die Kommunikation der Server untereinander eine große Rolle bezüglich Verfügbarkeit und Leistung spielt, würde in zweiter Instanz eine entsprechende Kapselung im Netzbereich für dedizierte Zwecke erfolgen. Das heißt, es werden mindestens vier Netzwerkbereiche mit dediziertem Nutzen benötigt, im Idealfall sogar fünf:

• ein Clientnetz für die Kommunikation zwischen den Nutzern mit den Web-Frontend (WFE)-Servern,

• ein administratives Netz, über das Administratoren "remote" auf die Server zugreifen,

• ein Intra-Server-Netz, über das die WFE-Server untereinander und mit Anwendungsservern kommunizieren,

• ein Datennetz für die Server-Kommunikation mit den Datenbankservern sowie

• im Idealfall auch ein Intra-Datennetz für die Kommunikation der Datenbankserver untereinander, zum Beispiel für Cluster- oder Mirroring-Zwecke.

Unnötig zu erwähnen, dass für eine hohe Verfügbarkeit eine Netzbandbreite von mindestens 1 GBit pro Netz bereit stehen sollte. Um der Problematik des Ausfalls eines Switches Rechnung zu tragen, gibt es die Möglichkeit des Teamings von mindestens zwei Netzwerkkarten für einen Netzwerkabschnitt. Hierbei würde jeweils ein Netzwerkinterface auf einen eigenen Switch vernetzt. Dieses Szenario ist im Übrigen auch mit virtuellen Netzwerkkarten möglich. Hyper-V ab Version 2012 R2 sowie VMware ab Version 5.1 unterstützen zudem Load-Balancing bei geteamten Netzwerkkarten. Bei den Servern ist darauf zu achten, dass die zentralen Komponenten, also Netzteile und Festplatten, mehrfach vorhanden sind. Zudem sollten mindestens zwei identische Server-Systeme eingesetzt werden.

Bereitstellungsszenarien von SharePoint

• In einer Kleinstfarm - auch bekannt als Single Server-Umgebung - stellt ein einzelner SharePoint-Server sämtliche Dienste bereit. Dies geschieht entweder mit einem SQL-Server auf derselben Maschine oder mit einer separaten SQL-Maschine. Eine Verfügbarkeit von 99.9 Prozent zu erreichen und die Ausfallsicherheit zu erhöhen, ist bei diesem Modell schwierig: Die Architektur wird in einem Aktiv-/ Passiv-Szenario bereitgestellt. Jedoch entsteht durch das Failover vom defekten System zum Reserve-Server eine Unterbrechung der IT-Dienste, weil die Administratoren das passive System von Hand aktivieren müssen.

• Ab einer Mindestanzahl von vier SharePoint-Servern - je zwei Web-Frontend (WFE)- und zwei Anwendungsserver - spricht man von einer kleinen oder mittleren Serverfarm. Hinzu kommen zwei SQL-Server in einem Verbund. Bei diesem Modell liegt der Fokus auf hochverfügbaren Anwendungen.

Eine Art Datenbank-Clustering ist auch ohne zentralen Datenspeicher möglich. In Form von Always-on-Hochverfügbarkeitsgruppen lässt sich mit SQL Server 2012 Enterprise und der Windows Server Datacenter Edition ein solches Clustering einrichten. Dabei handelt es sich im Prinzip um eine Weiterentwicklung der Datenbankspiegelung mit dem Vorteil, dass eine Datenbank trotz eines Serverausfalls erreichbar bleibt. Jedoch müssen dafür mindestens zwei Datenbankinstanzen mit zwei SQL-Serverlizenzen aktiv sein.

Schritt für Schritt zur hochverfügbaren IT-Infrastruktur

• Arbeits- und Plattenspeicher reservieren

Wichtig ist, für ausreichend Arbeitsspeicher der virtuellen Maschinen (VM) zu sorgen, damit sich die virtualisierte Umgebung nicht negativ auf die Performance auswirkt. Im Normalfall weist der Host die Ressourcen - auch die CPU-Leistung - dynamisch zu, wobei die VM jedoch unbedingt über eine gewisse Grundperformance verfügen sollte. Als Richtwert dient ein Drittel der Zielleistung.

Zwar können Festplatten auf virtuellen SharePoint-Servern dynamisch wachsen. Zu beachten ist dabei aber, dass der IT-Administrator die virtuellen Festplatten des SQL-Servers in ihrer vollständigen Größe anlegt. Zudem sollte er die Datenbanken manuell mit einer Anfangsgröße festlegen, die sich am erwarteten Datenvolumen orientiert. Für eine Farm mit hohem Upload-Anteil sind die Standardeinstellungen nicht zu empfehlen.

• Umsetzung der Infrastruktur: Virtuelle Maschinen

Nun verteilt der IT-Administrator die VMs auf die entsprechenden Hosts. Dadurch ist das Gesamtsystem nicht mehr von einzelnen Komponenten abhängig. Dementsprechend könnten der Hyper-V-Host 1 und der Hyper-V-Host 2 zum Beispiel jeweils über einen SharePoint-Web-Frontend-Server, einen SharePoint-Anwendungsserver und einen SQL-Server verfügen.

So lässt sich mit einem einzelnen Host die gesamte Serverfarm komplett bereitstellen. Dabei müssen die Dimensionen der VMs so ausgelegt sein, dass sie die Leistungsanforderungen aus den Service Level Agreements (SLA) zu 100 Prozent erfüllen.

• Umsetzung der Infrastruktur: Netzwerk

Der Hyper-V-Host muss jede Netzwerkverbindung der VM redundant abbilden. Tabelle 2 zeigt, dass für jedes Fachbereichsteam eines der Teammitglieder auf einen zugeordneten Port eines Switches verbunden wird. So ist das Team selbst dann erreichbar, wenn ein Switch ausfällt.

Tabelle 1: Netzanbindung - Teaming der Netzwerk-Adapter des Hyper-V-Hosts

Das Netz selbst wird in vier Bereiche aufgeteilt, wobei die IP-Adressen in Abbildung 3 exemplarisch sind:

Der rote Bereich besteht aus der Kommunikation mit dem LAN sowie den Application Delivery Controllern und DNS-Servern. Mit Hilfe von zwei 1-GBit-Netzwerkkarten wird das Netz in einem Teaming-Verbund des Hostsystems angelegt. Die Einbindung erfolgt über einen virtuellen Switch auf jedem Host, der die Kommunikation der VM mit der Netzwerkinfrastruktur ermöglicht.

Im schwarzen Bereich wird die Kommunikation der SharePoint-Server untereinander geregelt. So sind zwei weitere 1-GBit/s-Netzwerkkarten in einem Teaming-Verbund des Hosts an die virtuellen Switches angekoppelt. Zudem findet hier das Load-Balancing zwischen den Web-Frontend (WFE)-Servern statt.

Der grüne Bereich ermöglicht die Kommunikation der SQL-Server mit den SharePoint-Servern. Hier erfolgt die Anbindung an die Hyper-V-Hosts über zwei 1-GBit/s-LAN-Adapter in einem Teaming-Verbund.

Im gelben Bereich schließlich findet die Kommunikation der SQL-Server untereinander statt. Die zweiten 10-GBit/s-Adapter sind als Pass-Through-Karten in die virtuellen Server integriert; das Clustering erfolgt in Form einer Hochverfügbarkeitsgruppe direkt über dieses Netz.

• Umsetzung der Infrastruktur: Anwendung

Die Tabellen 3 und 4 zeigen exemplarisch, wie die Verteilung der Anwendungen aussehen müsste, damit sie bei einem Systemausfall weiterhin zur Verfügung stehen. Dafür sind alle Komponenten und Rollen der SharePoint-Suche auf beiden Servern bereitzustellen.

Tabelle 2: Verteilung der Services (Quelle Comparex).

Darüber hinaus muss die Verteilung der Dienstanwendungen ebenfalls geplant werden. Sie könnte sich wie folgt gestalten - nur verwendete Dienste:

Tabelle 3: Verteilung der Dienstanwendungen (Quelle Comparex).

Wie bereits erwähnt, kommt bei der Suche hinzu, dass sämtliche Komponenten und Rollen dieser speziellen Dienstanwendung auf beiden Servern bereitzustellen sind.

• Umsetzung Infrastruktur: Datenbank

Grundlage für Redundanz und Hochverfügbarkeit der SQL-Datenbank auf Basis von SQL Server 2012 sind die Hochverfügbarkeitsgruppen. Hierzu benötigt das Unternehmen mindestens zwei Windows-Server in einem Windows-Server-Failover-Cluster. Bei Hochverfügbarkeitsgruppen spricht man dann von primären und sekundären Replikas. Es lassen sich bis zu fünf Knoten implementieren: eine primäre Replika und bis zu vier sekundäre.

Diese Strategie hat einige Vorteile:

• Sie erfordert keinen zentralen Speicher.

• Eine sekundäre Replika kann als "lesbar" konfiguriert werden. Das ermöglicht zum Beispiel die Umleitung der Suche auf diese Datenbank.

• Der Failover erfolgt automatisch.

• Pro Gruppe lassen sich unterschiedliche Synchronisierungsmechanismen einsetzen.

• Es können jederzeit neue Datenbanken in die Gruppe aufgenommen werden.

• Die Fehlertoleranz ist relativ hoch. Wenn zum Beispiel durch eine "still defekte" Festplatte die Datendateien der Datenbank korrupt sind, findet sich dieser Fehler nicht in den anderen Replikas.

Generell werden die Daten auf Basis von SQL-Transaktionen zwischen den Replikas synchronisiert. Dies kann über synchrone oder asynchrone Commits erfolgen. Beim synchronen Commit werden alle Transaktionen auf allen Replikas synchron durchgeführt. Das heißt, wenn ein Nutzer eine Änderung vornimmt, wird diese in einer Transaktion aufgereiht. Um eine Transaktion konsistent in die Datenbank zu schreiben, braucht es ein Commit, quasi eine Bestätigung, um die Transaktion erfolgreich auszuführen.

Bei synchronen Commits wartet die primäre Replika, also der Server, auf dem der Nutzer arbeitet, bis die Transaktionen auf allen sekundären Replikas erfolgreich ausgeführt wurden. Änderungen erfolgen daher langsamer. Der Vorteil ist, dass alle Replikas synchron sind und im Fehlerfall kaum Daten verloren gehen. Diese Option bietet sich für Datenbanken mit geringen Änderungsfrequenzen an.

Beim asynchronen Commit übernimmt die primäre Replika die Änderung direkt, unabhängig davon, ob die sekundären Replikas das bereits getan haben. Aus Sicht des Nutzers werden Änderungen umgehend vorgenommen. Bei Ausfall einer Replika können jedoch Daten verloren gehen. Der asynchrone Commit eignet sich daher für Datenbanken mit häufigen Änderungen.

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)