Wählen einer Notfallwiederherstellungsstrategie für SharePoint Server

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

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.

SharePoint Server 2019, 2016, 2013 und die SQL Server-Instanzen, die sie unterstützen, bieten Konfigurations- und Inhaltswiederherstellungsoptionen, die die RTO (Recovery Time Objective) und RPO (Recovery Point Objective) erfüllen können, die für Ihr Unternehmen im Notfall erforderlich sind. 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.

Die Kosten für Ausfallzeiten variieren zwischen und innerhalb der Branche erheblich, insbesondere aufgrund der unterschiedlichen Auswirkungen von Ausfallzeiten. Die Unternehmensgröße ist der offensichtlichste Faktor. Es ist jedoch nicht die einzige. Die Festlegung einer Maßnahme bedeutet, die Art und die Auswirkungen des Scheiterns zu ermitteln. Auf die einfachste Ebene reduziert, kann ein Ausfall einer kritischen Anwendung zu den folgenden Arten 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 keine Informationen zur Planung der Notfallwiederherstellung aufgenommen, sondern konzentrieren uns auf Optionen, um sicherzustellen, dass Sie Ihre SharePoint Server-Farm an einem anderen Ort 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.

  Pros: Häufig die günstigste Option für die Wartung. 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 mit Azure Site Recovery.

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

  Cons: 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.

  Pros: Oft relativ schnelle Wiederherstellung.

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

Verzögert betriebsbereite Wiederherstellungslösung

In einem Notfallwiederherstellungsszenario im kalten Standbymodus können Sie eine Wiederherstellung durchführen, indem Sie eine neue Farm an einem neuen Speicherort einrichten (vorzugsweise mithilfe einer skriptbasierten Bereitstellung) und Sicherungen wiederherstellen. Alternativ können Sie die Farm mithilfe einer Sicherungslösung wie System Center – Data Protection Manager (DPM) wiederherstellen. DPM schützt Ihre Daten auf Der Betriebssystemebene des Computers und ermöglicht es Ihnen, jeden Server einzeln wiederherzustellen. 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:

• Übersicht über Sicherung und Wiederherstellung in SharePoint Server

• Planen der Sicherung und der Wiederherstellung in SharePoint Server

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. Weitere Informationen finden Sie unter Bereitstellen von SharePoint Server mit SQL Server Always On Verfügbarkeitsgruppen 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 SQL Server Datenbankspiegelungsfeatures wird in zukünftigen Versionen entfernt. Es wird empfohlen, dieses Feature in neuen Bereitstellungen zu vermeiden. Planen Sie das Ändern von Anwendungen, die dieses Feature derzeit verwenden. Verwenden Sie stattdessen Always On 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.

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.

Siehe auch

Konzepte

Konzepte für hohe Verfügbarkeit und Notfallwiederherstellung in 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