Wählen einer Notfallwiederherstellungsstrategie für SharePoint Server

  • Artikel

 

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

**Letztes Änderungsdatum des Themas:**2018-03-09

Zusammenfassung: Grundlegendes zu den Optionen für die Notfallwiederherstellung und unterstützten Technologien zum Wiederherstellen einer SharePoint Server 2016- und SharePoint 2013-Farm bei einem Notfall.

Notfallwiederherstellung wird von uns definiert als die Fähigkeit, nach einer Situation eine Wiederherstellung auszuführen, in der ein Rechenzentrum, in dem SharePoint Server gehostet wird, nicht mehr betriebsbereit ist. Unabhängig von der Art des Ereignisses und seiner Ursache ist der Ausfall des Rechenzentrums so schwerwiegend, dass die im Notfallwiederherstellungsplan Ihrer Organisation vorgegebenen Aktionen ausgelöst werden. Dies bedeutet, dass eine vollständige betriebsbereite Farm mithilfe von Computerressourcen in der Produktionsumgebung bereitgestellt wird, die sich in einem nicht von dem Ereignis betroffenen Rechenzentrum befinden.

Inhalt dieses Artikels:

  • Einführung

  • Wiederherstellungsoptionen für das Standby-Rechenzentrum

  • Systemanforderungen für die Wiederherstellung

SharePoint Server 2016 und SQL Server 2014 mit Service Pack 1 (SP1) oder SQL Server 2016, sowie SharePoint 2013 und SQL Server 2008 R2 mit Service Pack 1 (SP1) oder SQL Server 2012bieten Konfigurations- und Inhaltswiederherstellungsoptionen zum Erfüllen der Zielwerte für die Wiederherstellungszeit (Recovery Time Objective, RTO) und den Wiederherstellungspunkt (Recovery Point Objective, RPO) bei einem Notfall in Ihrer Organisation. Weitere Informationen zu diesen und anderen Notfallwiederherstellungskonzepten finden Sie unter Konzepte für hohe Verfügbarkeit und Notfallwiederherstellung in SharePoint Server.

Einführung

Eine wirkungsvolle Strategie für die Notfallwiederherstellung einer SharePoint Server-Farm muss die geschäftlichen Anforderungen Ihrer Organisation erfüllen, die in der Regel mithilfe zweier Angaben definiert werden: den Zielwerten für die Wiederherstellungszeit (RTO) und den Wiederherstellungspunkt (RPO). Die RTO- und RPO-Anforderungen ergeben sich aus dem Bestimmen der Ausfallkosten für die Organisation bei einem Notfall.

Wichtig

Am besten ist es, die Werte für RTO und RPO für Ihre Organisation eindeutig zu bestimmen und zu quantifizieren, bevor Sie eine Wiederherstellungsstrategie entwickeln und eine technische Lösung implementieren. Konzentrieren Sie sich zunächst darauf, was erforderlich ist, und nicht darauf, wie Sie es erreichen können.

Die Kosten von Ausfallzeiten variieren je nach Branche und auch innerhalb von Branchen enorm, insbesondere aufgrund ihrer unterschiedlichen Auswirkungen. Die Unternehmensgröße ist der offenkundigste Faktor, jedoch nicht der einzige. Das Festlegen einer Messgröße bringt mit sich, dass die Art und Auswirkungen des Ausfalls definiert werden. Auf der einfachsten Ebene kann der Ausfall einer kritischen Anwendung zu den folgenden Typen von Verlusten führen:

  • Verlust des Anwendungsdiensts. Die Auswirkungen von Ausfallzeiten variieren je nach Anwendung und Unternehmen.

  • Datenverlust. Der potenzielle Verlust von Daten aufgrund eines Systemausfalls kann beträchtliche rechtliche und finanzielle Auswirkungen haben.

Die meisten Organisation erleiden Ausfallkosten aufgrund der beiden zuvor genannten Typen von Verlust, doch die Art des Geschäfts bestimmt, welcher Ausfalltyp die schwerwiegendsten Auswirkungen hat. Der folgende Artikel von Chris Preimesberger auf der eWEEK-Website erläutert die finanziellen Folgen eines Rechenzentrumsausfalls. Unplanned IT Downtime Can Cost $5K Per Minute: Report.

In den meisten Fällen ist SharePoint-Produkte eine von mehreren Anwendungen, die im Falle eines Rechenzentrumsausfalls, der als Notfall eingestuft wird, wiederhergestellt werden muss. Aus diesem Grund haben wir Informationen zur Planung einer Notfallwiederherstellung nicht berücksichtigt, sondern konzentrieren uns auf Optionen zum Sicherstellen, dass Sie Ihre SharePoint Server 2016-Farm an einem anderen Standort wiederherstellen können.

Unabhängig von Typ und Ausmaß eines Notfalls umfasst die Wiederherstellung den Einsatz eines Standby-Rechenzentrums, in dem Sie die Farm wiederherstellen können.

Optionen für die Wiederherstellung mithilfe eines Standby-Rechenzentrums

Standby-Rechenzentren werden in Szenarien benötigt, bei denen mittels lokaler redundanter Systeme und Sicherungen das primäre Rechenzentrum bei einem Ausfall nicht wiederhergestellt werden kann. Die Zeit und der unmittelbare Aufwand, den Betrieb einer Ersatzfarm aufzunehmen und an einem anderen Standort auszuführen, werden häufig als entweder "unmittelbar betriebsbereit", "betriebsbereit" oder "verzögert betriebsbereit" beschrieben. Unsere Bezeichnungen dieser Rechenzentren zur Farmwiederherstellung lauten wie folgt:

  • Verzögert betriebsbereit. Ein sekundäres Rechenzentrum, das binnen Stunden oder Tagen Verfügbarkeit bieten kann.

  • Betriebsbereit. Ein sekundäres Rechenzentrum, das binnen Minuten oder Stunden verfügbar sein kann.

  • Unmittelbar betriebsbereit Ein sekundäres Rechenzentrum, das binnen Sekunden oder Minuten verfügbar sein kann.

Jedes dieser Standby-Rechenzentren hat bestimmte Merkmale und Anforderungen und weist entsprechende Kosten für Betrieb und Wartung auf.

  • Notfallwiederherstellungsstrategie mit verzögert betriebsbereiter Standby-Lösung: Ein Unternehmen sendet zur Unterstützung der Bare-Metal-Recovery regelmäßig Sicherungen an lokale und regionale Speicherorte außerhalb des Betriebsgeländes und hat Mietverträge für Notfallserver in einer anderen Region abgeschlossen.

    Vorteile

    • Aus betrieblicher Sicht oft die Option mit den niedrigsten Wartungskosten.

    • Im Hinblick auf die Wiederherstellung oft eine kostspielige Option, da nach einem Notfall physische Server ordnungsgemäß konfiguriert werden müssen.

    Nachteile: Die langsamste Wiederherstellungsoption

  • Notfallwiederherstellungsstrategie mit betriebsbereiter Standby-Lösung: Ein Unternehmen sendet virtuelle Computerabbilder an lokale und regionale Notfallwiederherstellungsfarmen.

    Vorteile: Oft relativ kostengünstige Wiederherstellung, da eine virtuelle Serverfarm bei der Wiederherstellung möglicherweise wenig Konfiguration erfordert.

    Nachteile: Die Wartung kann sehr kostspielig und zeitraubend sein.

  • Notfallwiederherstellungsstrategie mit unmittelbar betriebsbereiter Standby-Lösung: Ein Unternehmen betreibt mehrere Rechenzentren, stellt jedoch Inhalte und Dienste nur über ein Rechenzentrum bereit.

    Vorteile: Oft relativ schnelle Wiederherstellung.

    Nachteile: Wartung und Konfiguration können sehr kostspielig sein.

Wichtig

Unabhängig davon, für welche Notfallwiederherstellungslösung Sie sich entscheiden, wird vermutlich ein gewisser Datenverlust auftreten.

Verzögert betriebsbereite Wiederherstellungslösung

Bei einem Notfallwiederherstellungsszenario mit verzögert betriebsbereiter Standby-Lösung können Sie eine Wiederherstellung ausführen, indem Sie eine neue Farm an einem neuen Standort einrichten (vorzugsweise mithilfe einer skriptgestützten Bereitstellung) und Sicherungen wiederherstellen. Alternativ können Sie eine Wiederherstellung ausführen, indem Sie eine Farm von einer Sicherungslösung wie beispielsweise System Center 2016 - Data Protection Manager (DPM) oder System Center 2012 – Data Protection Manager (DPM) wiederherstellen. Bei System Center Data Protection Manager werden die Daten auf Computerebene geschützt, und jeder Server kann einzeln wiederhergestellt werden. Dieser Artikel enthält keine detaillierten Anweisungen zum Erstellen und Wiederherstellen in Szenarien mit verzögert betriebsbereiter Standby-Lösung. Weitere Informationen finden Sie unter:

Betriebsbereite Wiederherstellungslösung

Bei einer Notfallwiederherstellung mit betriebsbereiter Standby-Lösung richten Sie eine betriebsbereite Standby-Umgebung ein, indem Sie die Farm im sekundären Rechenzentrum duplizieren und regelmäßig mithilfe vollständiger und inkrementeller Sicherungen der primären Farm aktualisieren.

Virtuelle betriebsbereite Standby-Umgebungen

Die Virtualisierung bietet eine funktionsfähige und wirtschaftliche Option für eine betriebsbereite Standby-Wiederherstellungslösung. Sie können Hyper-V als interne oder Azure als gehostete Lösung nutzen, um die für die Wiederherstellung benötigte Infrastruktur bereitzustellen.

Sie können virtuelle Abbilder der Produktionsserver erstellen und diese Abbilder in das Standby-Rechenzentrum übertragen. Bei Wahl der virtuellen Standby-Lösung müssen Sie sicherstellen, dass die virtuellen Abbilder häufig genug erstellt werden, um den Grad an Aktualität bei Konfiguration und Inhalten zu bieten, der für die Wiederherstellung der Farm erforderlich ist. Am sekundären Standort muss eine Umgebung zur Verfügung stehen, in der Sie die Abbilder einfach konfigurieren und verbinden können, um die Farmumgebung neu zu erstellen. Weitere Informationen finden Sie unter Bereitstellen von SQL Server AlwaysOn-Verfügbarkeitsgruppen für SharePoint Server 2016 in Azure.

Unmittelbar betriebsbereite Wiederherstellungslösung

In einem Notfallwiederherstellungs-Szenario mit unmittelbar betriebsbereiter Standby-Lösung können Sie eine Failoverfarm so im Standby-Rechenzentrum einrichten, dass diese den Produktionsbetrieb nahezu sofort übernehmen kann, nachdem die primäre Farm offline gegangen ist. Eine Umgebung mit einer getrennten Failoverfarm weist die folgenden Merkmale auf:

  • In der Failoverfarm müssen eine separate Konfigurationsdatenbank und Inhaltsdatenbank der die Website für die SharePoint-Zentraladministration verwaltet werden.

  • Alle Anpassungen müssen in beiden Farmen bereitgestellt werden.

    Tipp

    Es besteht Konsistenz zwischen den beiden Farmen, und zum Verringern der Fehlerwahrscheinlichkeit wird empfohlen, zum Erstellen der primären Farm und der Failoverfarm mit den gleichen Konfigurationseinstellungen und Anpassungen die skriptgestützte Bereitstellung zu verwenden.

  • Betriebssystem-, SQL Server- und SharePoint Server-Softwareupdates müssen in beiden Farmen eingespielt werden, damit beide eine einheitliche Konfiguration aufweisen.

  • Sie können SharePoint Server-Inhaltsdatenbanken mithilfe der asynchronen Spiegelung, eines asynchronen Commits für ein Verfügbarkeitsgruppenreplikat oder des Protokollversands kopieren.

    Hinweis

    Die SQL Server-Spiegelung kann nur zum Kopieren von Datenbanken auf einen einzigen Spiegelserver verwendet werden. Sie können jedoch den Protokollversand an mehrere sekundäre Server verwenden.
    Das Feature der SQL Server-Datenbankspiegelung wird in zukünftigen Versionen entfernt. Wir empfehlen Ihnen daher, bei der Entwicklung neuer Anwendungen auf die Verwendung dieses Features zu verzichten. Verwenden Sie stattdessen AlwaysOn-Verfügbarkeitsgruppen.

  • Nicht alle Dienstanwendungen können per Protokollversand an eine Farm gesendet werden. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Redundanz von Dienstanwendungen.

Diese Topologie kann bei mehreren Rechenzentren wiederholt werden, sofern Sie den SQL Server-Protokollversand an ein oder mehrere zusätzliche Rechenzentren konfigurieren.

Wichtig

Die verfügbare Netzwerkbandbreite und Latenz sind wesentliche Aspekte bei Befolgen eines Failoveransatzes bei der Notfallwiederherstellung.
Erkundigen Sie sich am besten beim SAN-Anbieter, ob Sie zum Bereitstellen der Verfügbarkeit einer unmittelbar betriebsbereiten Standby-Lösung zwischen Rechenzentren die SAN-Replikation oder einen anderen unterstützten Mechanismus verwenden können.

Redundanz von Dienstanwendungen

Zum Bereitstellen von Verfügbarkeit für Dienstanwendungen zwischen Rechenzentren wird empfohlen, für Dienste, die farmübergreifend ausgeführt werden können, eine separate Dienstfarm auszuführen, auf die über das primäre und sekundäre Rechenzentrum zugegriffen werden kann.

Für Dienste, die nicht farmübergreifend ausgeführt werden können, und für die Bereitstellung von der Verfügbarkeit für die Dienstfarm selbst gibt es unterschiedliche Strategien für die Bereitstellung von Redundanz für eine Dienstanwendung zwischen Rechenzentren. Die verwendete Strategie hängt von folgenden Faktoren ab:

  • Die Ausführung der Dienstanwendung in der Notfallwiederherstellungsfarm, wenn diese nicht verwendet wird, hat einen geschäftlichen Nutzen.

  • Die der Dienstanwendung zugeordneten Datenbanken können per Protokollversand gesendet, asynchron gespiegelt oder über einen asynchronen Commit repliziert werden werden.

  • Die Dienstanwendung kann mit schreibgeschützten Datenbanken ausgeführt werden.

Lesen Sie den Artikel Unterstützte Hochverfügbarkeits- und Notfallwiederherstellungsoptionen für SharePoint-Datenbanken, bevor Sie eine Notfallwiederherstellungslösung entwerfen, die ein betriebsbereites bzw. unmittelbar betriebsbereites Standby-Rechenzentrum nutzt.

Systemanforderungen für die Wiederherstellung

In einem idealen Szenario entsprechen die Failoverkomponenten und -systeme in jeder Hinsicht den primären Komponenten und Systemen: Plattform, Hardware und Anzahl der Server. Die Failoverumgebung muss mindestens in der Lage sein, den Datenverkehr zu verarbeiten, den Sie während eines Failovers erwarten. Beachten Sie, dass nur eine Teilmenge der Benutzer von der Failoverwebsite bedient wird. Die Systeme müssen mindestens in diesen Aspekten übereinstimmen:

  • Betriebssystemversion und alle Updates

  • SQL Server-Versionen und alle Updates

  • SharePoint Server-Versionen und alle Updates

Zusätzlich zu den vorherigen Anforderungen ist die Farmwiederherstellungsdauer auch von der Verfügbarkeit von Versorgungssystemen und Infrastrukturkomponenten abhängig. Stellen Sie sicher, dass folgende Anforderungen erfüllt sind:

  • Infrastrukturabhängigkeiten wie beispielsweise Stromversorgung, Kühlung, Netzwerk, Verzeichnis und SMTP sind vollständig redundant.

  • Wählen Sie einen den Anforderungen entsprechenden Umschaltmechanismus (DNS oder Hardwarelastenausgleich) aus.

See also

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