Konzepte für hohe Verfügbarkeit und Notfallwiederherstellung in SharePoint Server

**Gilt für:**SharePoint Foundation 2013, SharePoint Server 2013, SharePoint Server 2016

**Letztes Änderungsdatum des Themas:**2017-08-01

**Zusammenfassung:**Informationen zu den Konzepten der hohen Verfügbarkeit und Notfallwiederherstellung in SharePoint Server 2016 und SharePoint 2013, damit Sie für Ihre Farm die beste Strategie wählen können.

Die hohe Verfügbarkeit und die Notfallwiederherstellung haben beim Erstellen eines Plans und der Systemspezifikationen für eine SharePoint Server-Farm die höchste Priorität. Andere Aspekte des Plans, z. B. hohe Leistung und Kapazität, erübrigen sich, wenn die Farmserver keine hohe Verfügbarkeit aufweisen oder wenn eine Farm nicht wiederhergestellt werden kann.

Um eine effektive Strategie zur Aufrechterhaltung eines effizienten und unterbrechungsfreien Betriebs zu entwerfen und zu implementieren, sollten Sie mit den Grundlagen der hohen Verfügbarkeit und der Notfallwiederherstellung vertraut sein. Diese Begriffe sind auch wichtig in Bezug auf die Auswertung und Auswahl der besten technischen Lösungen für Ihre SharePoint-Umgebung.

Inhalt dieses Artikels:

• Einführung in das Geschäftskontinuitätsmanagement

• Beschreibung der hohen Verfügbarkeit

• Quantifizierung der Ausfallzeiten

Einführung in das Geschäftskontinuitätsmanagement

Das Geschäftskontinuitätsmanagement ist ein Verwaltungsprozess oder -programm, mit dem die Risiken in Bezug auf den unterbrechungsfreien Betrieb einer Organisation definiert, bewertet und besser verwaltet werden können. Beim Geschäftskontinuitätsmanagement geht es hauptsächlich um die Erstellung und Pflege eines Geschäftskontinuitätsplans. Dabei handelt es sich um eine Roadmap zur Weiterführung des Betriebs, wenn die normalen Geschäftsvorgänge aufgrund widriger Umstände unterbrochen wurden. Dabei kann es sich um natürliche oder menschliche Faktoren oder um eine Kombination aus beidem handeln. Ein Kontinuitätsplan wird aus den folgenden Analysen und Eingaben abgeleitet:

• Analyse der geschäftlichen Relevanz

• Analyse der Bedrohungen und Risiken

• Definition der Auswirkungen

• Satz dokumentierter Wiederherstellungsanforderungen

Das Ergebnis ist ein Lösungsentwurf bzw. ermittelte Optionen, ein Implementierungsplan, ein Testplan oder Akzeptanzplan für die Organisation und ein Wartungsplan bzw. Zeitplan.

Ein Beispiel für Geschäftskontinuitätsmanagement ist Notfallwiederherstellung und Schutz für Daten und Anwendungen, das eine Momentaufnahme des Geschäftskontinuitätsprogramms bei Microsoft bereitstellt.

Für viele Organisationen ist die Informationstechnologie (IT) natürlich ein wichtiger Aspekt der Geschäftskontinuitätsplanung. Die Geschäftskontinuität reicht jedoch noch weiter. Sie umfasst alle erforderlichen Vorgänge, mit denen sichergestellt wird, dass eine Organisation während und unmittelbar nach einer Störung durch einen Ausfall weiterarbeiten kann. Ein Geschäftskontinuitätsplan umfasst die folgenden Elemente, ist jedoch nicht darauf beschränkt:

• Richtlinien, Prozesse und Verfahren

• Mögliche Optionen und Zuständigkeit für die Entscheidungsfindung

• Personalwesen und Betriebsanlagen

• Informationstechnologie

Obwohl die hohe Verfügbarkeit und Notfallwiederherstellung häufig mit dem Geschäftskontinuitätsmanagement gleichgesetzt wird, handelt es sich dabei eher um Teilbereiche des Geschäftskontinuitätsmanagements.

Beschreibung der hohen Verfügbarkeit

Für eine Softwareanwendung oder einen Dienst wird die hohe Verfügbarkeit letztendlich am Eindruck und den Erwartungen der Endbenutzer gemessen. Die tatsächlich messbaren und empfundenen geschäftlichen Auswirkungen von Ausfallzeiten lassen sich als Informationsverlust, Schäden an Betriebseinrichtungen, verringerte Produktivität, Kosten für entgangene Verkaufschancen, Vertragsverletzungen oder Vertrauensverlust beschreiben.

Das Hauptziel einer Lösung für hohe Verfügbarkeit besteht darin, die Auswirkungen aufgrund von Ausfallzeiten zu verringern oder zu mindern. Bei einer guten Strategie besteht eine optimales Gleichgewicht zwischen Geschäftsprozessen und Vereinbarungen zum Servicelevel (Service Level Agreements, SLAs) und technischen Funktionen und Infrastrukturkosten.

Ein Plattform wird gemäß der Vereinbarung zwischen Kunden und Beteiligten und deren Erwartungen als hoch verfügbar angesehen. Die Verfügbarkeit eines Systems kann mithilfe der folgenden Formel ausgedrückt werden:

Ist-Betriebszeit/Soll-Betriebszeit X 100 %

Das Ergebnis wird in der Branche häufig als Anzahl der Zahl 9 für eine Lösung ausgedrückt. So wird die mögliche jährliche Betriebszeit (bzw. die Ausfallzeit) in Minuten angegeben.

Geplante und nicht geplante Ausfallzeiten

Systemausfälle sind entweder antizipiert oder geplant, oder sie sind das Ergebnis eines ungeplanten Ausfalls. Ausfallzeiten sind nicht unbedingt etwas Negatives, solange sie richtig gemanagt werden. Es gibt zwei Hauptarten vorhersehbarer Ausfallzeiten:

• Geplante Wartung: Ein Zeitfenster wird angekündigt und für geplante Wartungsaufgaben koordiniert, z. B. Softwarepatching, Hardwareupgrades, Kennwortupdates, Offline-Neuindizierung, Datenladevorgänge oder das Testen von Maßnahmen zur Notfallwiederherstellung. Wohlüberlegte und professionell verwaltete Betriebsabläufe sollten dazu führen, dass Ausfallzeiten möglichst gering gehalten und Datenverluste vermieden werden. Geplante Wartungsaktivitäten sollten als erforderliche Investition in die Verhinderung oder Minderung ungeplanter Ausfälle mit negativeren Auswirkungen angesehen werden.

• Ungeplanter Ausfall: Es können Ausfälle auf Systemebene oder in Bezug auf die Infrastruktur oder Prozesse auftreten, die ungeplant oder unkontrollierbar sind oder die entweder als zu unwahrscheinlich oder als Ausfall mit akzeptablen Auswirkungen eingestuft wurden. Eine solide Lösung zur Sicherstellung der hohen Verfügbarkeit erkennt diese Arten von Ausfällen, stellt die Betriebsfähigkeit automatisch wieder her und richtet die Fehlertoleranz wieder ein.

Beim Ausrichten von SLAs auf hohe Verfügbarkeit ist es ratsam, separate Key Performance Indicators (KPIs) für geplante Wartungsaktivitäten und ungeplante Ausfallzeiten zu berechnen. Bei diesem Ansatz können Sie Ihrer Investition in geplante Wartungsaktivitäten den Vorteil der Vermeidung von ungeplanten Ausfallzeiten gegenüberstellen.

Herabgesetzte Verfügbarkeit

Hohe Verfügbarkeit sollte nicht als Alles-oder-nichts-Service angesehen werden. Als Alternative zu einem vollständigen Ausfall ist es für Endbenutzer häufig akzeptabel, dass ein System teilweise verfügbar ist oder über einen eingeschränkten Funktionsumfang oder eine herabgesetzte Leistung verfügt. Zu diesen unterschiedlichen Verfügbarkeitsgraden gehört Folgendes:

• Schreibgeschützter und verzögerter Betrieb: Während eines Wartungszeitfensters oder einer Notfallwiederherstellung in Phasen ist das Abrufen von Daten weiterhin möglich, aber neue Workflows und die Hintergrundverarbeitungsschritte sind ggf. vorübergehend unterbrochen bzw. befinden sich in der Warteschlange.

• Datenwartezeit und Anwendungsreaktionsfähigkeit: Aufgrund einer hohen Auslastung, einem Rückstand bei der Verarbeitung oder eines Teilausfalls der Plattform kann es dazu kommen, dass Hardwareressourcen mit eingeschränktem Umfang überlastet bzw. für die Auslastung nicht ausgelegt sind. Darunter kann die Benutzerfreundlichkeit leiden, aber die Nutzung ist ggf. weiter möglich, wenn auch mit geringerer Produktivität.

• Teilausfälle, vorübergehende Ausfälle oder drohende Ausfälle: Hierbei ist die Robustheit der Anwendungslogik bzw. des Hardwarestapels entscheidend, damit der Vorgang bei Auftreten eines Fehlers wiederholt wird oder selbständig Korrekturmaßnahmen eingeleitet werden können. Diese Art von Problem wirkt sich für Endbenutzer als Datenwartezeit oder schlechte Reaktionsfähigkeit der Anwendung aus.

• End-to-End-Teilausfall: Geplante oder ungeplante Ausfallzeiten können für die vertikalen Ebenen des Lösungsstapels (Infrastruktur, Plattform und Anwendung) oder auf horizontaler Ebene zwischen unterschiedlichen Funktionskomponenten auftreten. Je nach den betroffenen Funktionen oder Komponenten sind die Aktionen der Benutzer teilweise erfolgreich oder werden mit herabgesetzter Leistung ausgeführt.

Die Annehmbarkeit dieser suboptimalen Szenarien sollte als Teil eines Spektrums von herabgesetzter Verfügbarkeit, die zu einem vollständigen Ausfall führt, und in Bezug auf Zwischenschritte der Notfallwiederherstellung in Phasen überprüft werden.

Quantifizierung der Ausfallzeiten

Wenn Ausfallzeiten entweder geplant oder ungeplant auftreten, besteht das Hauptgeschäftsziel darin, das System wieder in den Onlinezustand zu versetzen und Datenverluste möglichst gering zu halten. Jede Minute der Ausfallzeit ist mit direkten und indirekten Kosten verbunden. Bei ungeplanten Ausfallzeiten müssen die Zeit und der Aufwand abgewogen werden, die bzw. der erforderlich ist, um Folgendes zu bestimmen: warum ist es zum Ausfall gekommen, in welchem Zustand befindet sich das System momentan und welche Schritte sind zur Wiederherstellung nötig.

An einem vorab definierten Punkt jedes Ausfalls sollte die Geschäftsentscheidung getroffen werden, die Untersuchung des Ausfalls zu beenden oder Wartungsaufgaben durchzuführen, die Wiederherstellung durchzuführen, indem das System wieder in den Onlinezustand versetzt wird, und, falls erforderlich, die Fehlertoleranz wieder einzurichten.

Ziele der Wiederherstellung

Die Datenredundanz ist eine wichtige Komponente der hohen Verfügbarkeit. Die Transaktionsaktivitäten der primären SQL Server-Instanz werden synchron oder asynchron auf eine oder mehrere sekundäre Instanzen angewendet. Wenn ein Ausfall auftritt, kann für aktive Transaktionen ein Rollback ausgeführt werden. So soll verhindert werden, dass die Transaktionen aufgrund von Verzögerungen bei der Datenpropagierung auf den sekundären Instanzen verloren gehen.

Sie können sowohl die Auswirkungen messen und Wiederherstellungsziele für die Dauer bis zur Erreichung des normalen Betriebszustands festlegen als auch messen, welche Wartezeit für die zuletzt wiederhergestellte Transaktion gilt:

• Zielsetzung für die Wiederherstellungsdauer (Recovery Time Objective, RTO): Dies ist die Dauer des Ausfalls. Das erste Ziel besteht darin, das System mindestens im schreibgeschützten Modus wieder in den Onlinezustand zu versetzen, um die Untersuchung des Ausfalls zu ermöglichen. Hauptziel ist jedoch die Wiederherstellung des vollständigen Betriebs bis zu dem Punkt, an dem wieder neue Transaktionen durchgeführt werden können.

• Zielsetzung für den Wiederherstellungspunkt (Recovery Point Objective, RPO): Dies wird häufig als das Maß für den akzeptablen Datenverlust bezeichnet. Es handelt sich dabei um den Zeitraum bzw. die Wartezeit zwischen der letzten abgeschlossenen Datentransaktion vor dem Ausfall und den neuesten wiederhergestellten Daten nach dem Ausfall. Der tatsächliche Datenverlust kann je nach Auslastung des Systems zum Zeitpunkt des Ausfalls, Art des Ausfalls und Art der verwendeten Lösung für hohe Verfügbarkeit variieren.

  Hinweis

  Ein verwandtes Ziel ist Zielsetzung für die Wiederherstellungsstufe (Recovery Level Objective, RLO). Bei der Zielsetzung für die Wiederherstellungsstufe geht es um die Definition der Granularität, mit der Sie Daten wiederherstellen können müssen. Dabei geht es darum, ob Sie die gesamte Farm, die Webanwendung, die Websitesammlung, die Website, die Liste oder Bibliothek oder das Element wiederherstellen können. Weitere Informationen finden Sie unter Planen der Sicherung und der Wiederherstellung in SharePoint Server.

Sie sollten RTO- und RPO-Werte als Ziele verwenden, mit denen die Geschäftstoleranz für Ausfallzeiten und den akzeptablen Datenverlust angegeben wird, sowie als Kennzahlen zur Überwachung der Verfügbarkeitsintegrität.

Rechtfertigung von ROI und Kosten für Verkaufschancen

Die Geschäftskosten von Ausfallzeiten können entweder finanzieller Art sein oder die Kundenzufriedenheit betreffen. Diese Kosten können zeitabhängig sein oder zu einem bestimmten Punkt des Ausfallzeitfensters anfallen. Zusätzlich zur Projektierung der Kosten eines Ausfalls mit einer bestimmten Wiederherstellungszeit und einem Datenwiederherstellungspunkt können Sie auch die Geschäftsprozess- und Infrastrukturinvestitionen berechnen, die erforderlich sind, um die RTO- und RPO-Ziele zu erreichen oder den Ausfall ganz zu vermeiden. Diese Investitionsplanung sollte Folgendes umfassen:

• Verhindern von Ausfallzeiten: Kosten für die Wiederherstellung nach einem Ausfall können vollständig vermieden werden, wenn es gar nicht erst zu einem Ausfall kommt. Zu den Investitionen gehören die Kosten für fehlertolerante und redundante Hardware oder Infrastruktur, für die Verteilung von Arbeitslasten auf isolierte potenzielle Fehlerquellen und geplante Ausfallzeiten für Präventivmaßnahmen.

• Automatisieren der Wiederherstellung: Wenn ein Systemausfall auftritt, können Sie die Auswirkungen der Ausfallzeit auf die Kundenzufriedenheit erheblich minimieren, indem Sie für eine automatische und transparente Wiederherstellung sorgen.

• Ressourcenverwendung: Die sekundäre oder Standby-Infrastruktur kann sich im Leerlauf befinden, während sie einen Ausfall erwartet. Außerdem kann sie für Arbeitslasten im schreibgeschützten Modus oder zum Verbessern der Gesamtleistung des Systems genutzt werden, indem Arbeitslasten auf die gesamte verfügbare Hardware verteilt werden.

Für die jeweiligen RTO- und RPO-Ziele können die erforderlichen Investitionen in Verfügbarkeit und Wiederherstellung (in Kombination mit den projizierten Kosten für Ausfallzeiten) als Zeitfunktion ausgedrückt und gerechtfertigt werden. Während eines Ausfalls können Sie so basierend auf der verstrichenen Ausfallzeit kostenabhängige Entscheidungen treffen.

Überwachen der Verfügbarkeitsintegrität

Aus betrieblicher Sicht sollten Sie während eines Ausfalls nicht versuchen, alle relevanten Variablen zu berücksichtigen und den ROI oder die Kosten für Verkaufschancen in Echtzeit zu berechnen. Stattdessen sollten Sie die Datenwartezeit auf Ihren Standby-Instanzen als Proxy für den erwarteten RPO-Wert überwachen.

Bei einem Ausfall sollten Sie auch die Zeit begrenzen, die direkt nach dem Auftreten zur Untersuchung der Hauptursache aufgewendet wird, und sich stattdessen auf die Überprüfung der Integrität Ihrer Wiederherstellungsumgebung konzentrieren und später dann ausführliche Systemprotokolle und Zweitkopien von Daten für eine genaue Analyse nutzen.

Planen der Notfallwiederherstellung

Während es bei der Sicherstellung der hohen Verfügbarkeit darum geht, was Sie zur Verhinderung eines Ausfalls tun können, geht es bei der Notfallwiederherstellung darum, welche Maßnahmen zum Wiederherstellen der hohen Verfügbarkeit nach einem Ausfall getroffen werden.

Die Verfahren und Zuständigkeiten für die Notfallwiederherstellung sollten so weit wie möglich festgelegt werden, bevor ein Ausfall auftritt. Mithilfe von aktiver Überwachung und Warnungen sollte die Entscheidung, einen automatisierten oder manuellen Failover- und Wiederherstellungsplan zu initiieren, an vorab definierte RTO- und RPO-Schwellenwerte gebunden sein. Ein guter Plan für die Notfallwiederherstellung sollte Folgendes umfassen:

• Granularität für Ausfall und Wiederherstellung: Je nach Ort und Art des Ausfalls können Sie auf unterschiedlichen Ebenen Korrekturmaßnahmen einleiten, z. B. auf den Ebenen Rechenzentrum, Infrastruktur, Plattform, Anwendung oder Arbeitsauslastung.

• Quellmaterial für Untersuchungen. Grundlegende und aktuelle Daten in Form von Überwachungsverläufen, Systemwarnungen, Ereignisprotokollen und Diagnoseabfragen sollten für alle wichtigen Stellen direkt verfügbar sein.

• Koordination von Abhängigkeiten: Welche System- und Geschäftsabhängigkeiten gelten im Anwendungsstapel und für die Beteiligten?

• Entscheidungsstruktur: Dies ist eine vordefinierte, wiederholbare, überprüfte Entscheidungsstruktur, die Rollenzuständigkeiten, Fehlerselektierung, Failoverkriterien in Bezug auf RPO- und RTO-Ziele und vorgeschriebene Wiederherstellungsziele umfasst.

• Überprüfung: Was muss nach dem Ausführen von Schritten zur Wiederherstellung bei einem Ausfall erfolgen, um sicherzustellen, dass das System zum normalen Betrieb zurückgekehrt ist?

• Dokumentation: Erfassen Sie alle obigen Punkte in ausreichender Ausführlichkeit und Deutlichkeit in einer Dokumentation, damit auch Dritte den Wiederherstellungsplan mit minimaler Hilfestellung ausführen können. Diese Art von Dokumentation wird auf Englisch häufig als "Run Book" oder "Cook Book" bezeichnet.

• Testläufe der Wiederherstellung: Führen Sie regelmäßig Testläufe des Plans zur Notfallwiederherstellung durch, um in Bezug auf die RTO-Ziele grundlegende Erwartungen aufzustellen. Erwägen Sie außerdem, das Hosten der primären Produktionswebsite per Rotationssystem regelmäßig von der primären Website auf die einzelnen Websites für die Notfallwiederherstellung zu verlagern.

See also

Wählen einer Notfallwiederherstellungsstrategie für SharePoint Server