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

GILT FÜR:2013 2016 2019 Subscription Edition SharePoint in Microsoft 365

Hochverfügbarkeit und Notfallwiederherstellung haben die höchste Priorität, wenn Sie einen Plan und Systemspezifikationen für eine SharePoint Server-Farm erstellen. 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.

Einführung in das Geschäftskontinuitätsmanagement

Business Continuity Management ist ein Verwaltungsprozess oder -programm, der die Risiken für die weitere Ausführung einer Organisation definiert, bewertet und bei der Bewältigung unterstützt. Das Business Continuity Management konzentriert sich auf die Erstellung und Aufrechterhaltung eines Geschäftskontinuitätsplans, der eine Roadmap für den fortzuführenden Betrieb ist, wenn der normale Geschäftsbetrieb durch ungünstige Bedingungen unterbrochen wird. Diese Bedingungen können natürlich, von Menschen gemacht oder eine Kombination aus beidem sein. Aus den folgenden Analysen und Eingaben wird ein Kontinuitätsplan 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.

Informationstechnologie (IT) ist offensichtlich ein wichtiger Aspekt der Geschäftskontinuitätsplanung für viele Organisationen. Die Geschäftskontinuität ist jedoch umfassender: Sie umfasst alle Vorgänge, die erforderlich sind, um sicherzustellen, dass eine Organisation während und unmittelbar nach einem wichtigen disruptiven Ereignis weiterhin Geschäfte tätigen kann. Ein Geschäftskontinuitätsplan umfasst die folgenden Elemente, ist aber nicht beschränkt auf:

• 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ützte und verzögerte Vorgänge. Während eines Wartungsfensters oder während einer stufenweisen Notfallwiederherstellung ist der Datenabruf weiterhin möglich, aber neue Workflows und die Hintergrundverarbeitung werden möglicherweise vorübergehend angehalten oder in die Warteschlange eingereiht.

• Datenlatenz und Reaktionsfähigkeit der Anwendung. Aufgrund einer hohen Workload, eines Verarbeitungsbacklogs oder eines teilweisen Plattformausfalls können eingeschränkte Hardwareressourcen über- oder unterdimensioniert sein. Die Benutzererfahrung kann darunter leiden, aber die Arbeit kann immer noch auf weniger produktive Weise erledigt werden.

• 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 auftreten , entweder geplant oder ungeplant, besteht das primäre Geschäftsziel darin, das System wieder online zu schalten und Datenverluste zu minimieren. Jede Minute ausfallzeit hat direkte und indirekte Kosten. Bei ungeplanten Ausfallzeiten müssen Sie die Zeit und den Aufwand ausgleichen, die erforderlich sind, um zu bestimmen, warum der Ausfall aufgetreten ist, wie der aktuelle Systemstatus ist und welche Schritte zur Wiederherstellung nach dem Ausfall erforderlich sind.

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

Datenredundanz ist eine wichtige Komponente einer Datenbanklösung mit hoher Verfügbarkeit. Die Transaktionsaktivität auf Ihrer primären SQL Server-Instanz wird synchron oder asynchron auf eine oder mehrere sekundäre Instanzen angewendet. Wenn ein Ausfall auftritt, kann für Transaktionen, die ausgeführt wurden, ein Rollback ausgeführt werden, oder sie gehen auf den sekundären Instanzen aufgrund von Verzögerungen bei der Datenweitergabe verloren.

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 Recovery Level Objective (RLO). Dieses Ziel definiert die Granularität, mit der Sie In der Lage sein müssen, Daten wiederherzustellen– unabhängig davon, ob Sie in der Lage sein müssen, die gesamte Farm, Webanwendung, Websitesammlung, Website, Liste oder Bibliothek oder element wiederherzustellen. Weitere Informationen finden Sie unter Plan for backup and recovery 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 von Ausfällen werden insgesamt vermieden, wenn überhaupt kein Ausfall auftritt. 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.

• Validierung. 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 häufig als "Run Book" oder "Kochbuch" 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.

Siehe auch

Konzepte

Wählen einer Notfallwiederherstellungsstrategie für SharePoint Server

Weitere Ressourcen

Welche Arbeitslasten können Sie mit der Azure Site Recovery schützen?

Replizieren einer SharePoint-Anwendung mit mehreren Ebene für die Wiederherstellung mithilfe von Azure Site Recovery