Planen der Notfallwiederherstellung (SharePoint Server 2010)

Gilt für: SharePoint Foundation 2010, SharePoint Server 2010

Letztes Änderungsdatum des Themas: 2016-11-30

In diesem Artikel werden wichtige Entscheidungen bei der Auswahl von Notfallwiederherstellungsstrategien für eine Microsoft SharePoint Server 2010-Umgebung beschrieben.

Inhalt dieses Artikels

• Notfallwiederherstellung (Übersicht)

• Auswählen einer Notfallwiederherstellungsstrategie

• Planen von Rechenzentren mit nicht betriebsbereitem Standby

• Planen von Rechenzentren mit betriebsbereitem Standby

• Planen von Rechenzentren mit unmittelbar betriebsbereitem Standby

• Systemanforderungen für die Notfallwiederherstellung

Notfallwiederherstellung (Übersicht)

In diesem Artikel wird Notfallwiederherstellung definiert als die Fähigkeit, nach einer Situation eine Wiederherstellung auszuführen, in der ein Rechenzentrum, in dem SharePoint Server gehostet wird, nicht mehr verfügbar ist.

Die Notfallwiederherstellungsstrategie, die Sie für SharePoint Server verwenden, muss mit der Notfallwiederherstellungsstrategie für die zugehörige Infrastruktur einschließlich Active Directory-Domänen, Exchange Server und Microsoft SQL Server koordiniert werden. Arbeiten Sie beim Entwerfen einer koordinierten Notfallwiederherstellungsstrategie und des zugehörigen Plans mit den Administratoren der benötigten Infrastruktur zusammen.

Der Zeitbedarf und der unmittelbare Aufwand für die Inbetriebnahme einer anderen Farm an einem anderen Standort wird oft als unmittelbar betriebsbereiter Standby, nicht unmittelbar betriebsbereiter Standby oder nicht betriebsbereiter Standby bezeichnet. Diese Begriffe werden wie folgt definiert:

Unmittelbar betriebsbereiter Standby Ein zweites Rechenzentrum, das innerhalb von Sekunden oder Minuten verfügbar sein kann.

Betriebsbereiter Standby Ein zweites Rechenzentrum, das innerhalb von Minuten oder Stunden verfügbar sein kann.

Nicht betriebsbereiter Standby Ein zweites Rechenzentrum, das innerhalb von Stunden oder Tagen verfügbar sein kann.

Notfallwiederherstellung ist eine der kostspieligeren Anforderungen für ein System. Mit der Kürze des Intervalls zwischen Fehler und Verfügbarkeit und der Anzahl der geschützten Systeme steigen wahrscheinlich auch die Komplexität und die Kosten einer Notfallwiederherstellungslösung. Wenn Sie in Rechenzentren mit betriebsbereitem Standby investieren, fallen unter anderem folgende Kosten an:

• Zusätzliche Hardware und Software, durch die oft die Komplexität der Vorgänge zwischen Softwareanwendungen steigt (beispielsweise benutzerdefinierte Skripts für Failover und Wiederherstellung).

• Zusätzliche Komplexität bei der Bedienung.

Die Kosten für die Wartung von Rechenzentren mit unmittelbar betriebsbereitem oder betriebsbereitem Standby sollten im Hinblick auf die geschäftlichen Anforderungen bewertet werden. Nicht alle Lösungen in einer Organisation erfordern das gleiche Maß an Verfügbarkeit nach einem Notfall. Sie können für verschiedene Inhalte, verschiedene Dienste oder verschiedene Farmen verschiedene Notfallwiederherstellungsstufen anbieten, beispielsweise für Inhalte mit großen Auswirkungen auf das Geschäft oder Suchdienste oder eine Internetveröffentlichungsfarm.

Notfallwiederherstellung ist ein Schlüsselbereich, in dem IT-Gruppen Vereinbarungen zum Servicelevel bereitstellen, um die Erwartungen der Kundengruppen festzulegen. Viele IT-Organisationen bieten unterschiedliche Vereinbarungen zum Servicelevel an, die jeweils verschiedene Leistungen umfassen.

Wenn Sie Failover zwischen Serverfarmen implementieren, wird empfohlen, zuerst die Kernlösung in einer Farm bereitzustellen und zu optimieren und dann die Notfallwiederherstellung zu implementieren und zu testen.

Auswählen einer Notfallwiederherstellungsstrategie

Sie können abhängig von den geschäftlichen Anforderungen zwischen zahlreichen Methoden für die Bereitstellung von Notfallwiederherstellung für eine SharePoint Server-Umgebung auswählen. In den folgenden Beispielen wird gezeigt, aus welchen Gründen Unternehmen Notfallwiederherstellungsstrategien mit nicht betriebsbereitem, betriebsbereitem oder unmittelbar betriebsbereitem Standby auswählen.

• Notfallwiederherstellungsstrategie mit nicht betriebsbereitem Standby: 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 betriebsbereitem Standby: Ein Unternehmen sendet virtuelle Serverabbilder 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 Zeit raubend sein.

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

  Vorteile: Oft relativ schnelle Wiederherstellung.

  Nachteile: Die Wartung und Konfiguration kann relativ kostspielig sein.

Planen von Rechenzentren mit nicht betriebsbereitem Standby

In einem Notfallwiederherstellungsszenario mit nicht betriebsbereitem Standby können Sie eine Wiederherstellung ausführen, indem Sie eine neue Farm an einem neuen Standort einrichten (vorzugsweise mithilfe einer Bereitstellung mit Skripts) und Sicherungen wiederherstellen. Alternativ können Sie eine Wiederherstellung ausführen, indem Sie eine Farm von einer Sicherungslösung wie beispielsweise Microsoft System Center Data Protection Manager 2007 wiederherstellen, bei der die Daten auf Computerebene geschützt werden und jeder Server einzeln wiederhergestellt werden kann. Dieser Artikel enthält keine detaillierten Anweisungen zum Erstellen und Wiederherstellen in Szenarien mit nicht betriebsbereitem Standby. Weitere Informationen finden Sie unter:

• Wiederherstellen einer Farm (SharePoint Server 2010)

• Wiederherstellen von Anpassungen (SharePoint Server 2010)

Planen von Rechenzentren mit betriebsbereitem Standby

In einem Notfallwiederherstellungsszenario mit betriebsbereitem Standby können Sie eine Lösung mit betriebsbereitem Standby erstellen, indem Sie sicherstellen, dass konsistent und häufig virtuelle Abbilder der Server in der Farm erstellt werden, die an einen sekundären Standort gesendet werden. 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.

Dieser Artikel enthält keine detaillierten Anweisungen zum Erstellen von Lösungen mit betriebsbereitem Standby. Weitere Informationen zum Planen der Bereitstellung von Farmen mithilfe von virtuellen Lösungen finden Sie unter Planen der Virtualisierung (SharePoint Server 2010).

Planen von Rechenzentren mit unmittelbar betriebsbereitem Standby

In einem Notfallwiederherstellungsszenario mit unmittelbar betriebsbereitem Standby können Sie eine Failoverfarm einrichten, um Notfallwiederherstellung in einem von der primären Farm getrennten Rechenzentrum bereitzustellen. Eine Umgebung mit einer getrennten Failoverfarm weist die folgenden Merkmale auf:

• In der Failoverfarm muss eine separate Konfigurationsdatenbank und Inhaltsdatenbank der Zentraladministration verwaltet werden.

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

  Hinweis

  Es wird empfohlen, zum Erstellen der primären Farm und der Failoverfarm mit den gleichen Konfigurationseinstellungen und Anpassungen die Bereitstellung mit Skripts zu verwenden. Weitere Informationen finden Sie unter Installieren von SharePoint Server 2010 mithilfe von Windows PowerShell.

• Updates müssen einzeln auf beide Farmen angewendet werden.

• SharePoint Server-Inhaltsdatenbanken können erfolgreich asynchron gespiegelt oder per Protokoll an die Failoverfarm gesendet werden.

  Hinweis

  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.

• Nicht alle Dienstanwendungen können per Protokoll an eine Farm gesendet werden. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Service application redundancy across data centers.

Diese Topologie kann über viele Rechenzentren hinweg wiederholt werden, wenn Sie den SQL Server-Protokollversand an ein oder mehrere zusätzliche Rechenzentren konfigurieren.

Erkundigen Sie sich beim SAN-Anbieter, ob Sie zum Bereitstellen der Verfügbarkeit zwischen Rechenzentren SAN-Replizierung oder einen anderen unterstützten Mechanismus verwenden können.

In der folgenden Abbildung werden eine primäre Farm und eine Failoverfarm vor dem Failover gezeigt.

Primäre Farm und Failoverfarm vor dem Failover

Dienstanwendungsredundanz zwischen Rechenzentren

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 über das 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 Protokoll gesendet oder asynchron gespiegelt werden.

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

In den folgenden Abschnitten werden die Notfallwiederherstellungsstrategien beschrieben, die für die einzelnen Dienstanwendungen empfohlen werden. Die Dienstanwendungen sind nach Strategien gruppiert.

Datenbanken, die per Protokoll gesendet oder asynchron gespiegelt werden können

Nach der anfänglichen Bereitstellung einer Dienstanwendung in einer sekundären Farm können die Datenbanken zur Unterstützung der folgenden Dienstanwendungen zwischen Farmen asynchron gespiegelt oder per Protokoll gesendet werden:

• Dienstanwendung für verwaltete Metadaten

  Datenbanken: Verwalteter Metadatendienst

  Hinweis

  Wenn Kategorien verwendet werden, müssen Sie das im SharePoint Administration Toolkit enthaltene Benutzerprofilreplikations-Modul ausführen, um die Dienstanwendung für verwaltete Metadaten in der Notfallwiederherstellungsfarm erfolgreich verwenden zu können. Weitere Informationen finden Sie unter Benutzerprofilreplikations-Modul (Übersicht) (SharePoint Server 2010).

• PerformancePoint-Dienste

  Datenbanken: PerformancePoint Service-Anwendung

• Project Server-Dienstanwendung

  Datenbanken: Entwurfsdatenbank, veröffentlichte Datenbank, Archivdatenbank, Berichtsdatenbank

  Die Project Server 2010-Datenbanken müssen miteinander synchronisiert werden. Project Server kann mithilfe eines asynchronen Replikationsmechanismus (asynchrone Datenbankspiegelung, Protokollversand oder asynchrone SAN-Replikation) zwischen Farmen repliziert werden. Bei der Wiederherstellung müssen Sie jedoch sicherstellen, dass die Protokolle der Project-Datenbank synchronisiert sind.

  Hinweis

  Obwohl empfohlen wird, die Project Server-Datenbanken per Protokoll an die Notfallwiederherstellungsfarm zu senden oder in dieser zu spiegeln, kann die Project Server-Dienstanwendung nicht mit schreibgeschützten Datenbanken ausgeführt werden. Daher wird empfohlen, die Project Server-Dienstanwendung erst nach dem Failover in der Notfallwiederherstellungsfarm auszuführen. Zum erfolgreichen Synchronisieren der Project Server-Datenbanken in der Notfallwiederherstellungsfarm müssen Sie Zeitstempel oder Protokollkennzeichnungen für die Datenbanken konfigurieren.

• Secure Store Service-Anwendung

  Datenbanken: Secure Store

• Dienstanwendung für die Erfassung von Verwendungs- und Integritätsdaten

  Datenbanken: Protokollierungsdatenbank

  Hinweis

  Die Protokollierungsdatenbank kann per Protokoll gesendet oder gespiegelt werden. Es wird jedoch empfohlen, den Dienst für die Erfassung von Verwendungs- und Integritätsdaten in der Notfallwiederherstellungsfarm nicht auszuführen und die Protokollierungsdatenbank weder zu spiegeln noch per Protokoll zu senden.

• Web Analytics-Dienstanwendung

  Datenbanken: Stagingdatenbank, Berichtsdatenbank

  Hinweis

  Es wird empfohlen, die Web Analytics-Stagingdatenbank und -Berichtsdatenbank per Protokoll zu senden oder zu spiegeln. Jedoch wird empfohlen, die Web Analytics-Dienstanwendung erst nach dem Failover in der Notfallwiederherstellungsfarm auszuführen.

Dienstanwendungen und Datenbanken, die nicht per Protokoll gesendet oder asynchron gespiegelt werden können

Die folgenden Dienstanwendungen müssen in der primären Farm und in der Failoverfarm bereitgestellt werden und können nicht per Protokoll gesendet oder asynchron gespiegelt werden. Für die meisten dieser Dienstanwendungen wird empfohlen, diese bereitzustellen und dann zu überprüfen, ob die Failoverfarm die gleichen Konfigurationseinstellungen hat wie die primäre Farm. Wenn in der primären Farm Konfigurationsänderungen vorgenommen werden, die sich auf den Dienst auswirken, müssen Sie die Failoverfarm aktualisieren.

• Anwendung Anwendungsregistrierungsdienst

  Datenbanken: Anwendungsregistrierungsdienst

  Der Protokollversand der Datenbank des Anwendungsregistrierungsdiensts wird nicht unterstützt.

• Business Data Connectivity-Dienstanwendung

  Datenbanken: Business Data Connectivity

• Benutzerprofildienst-Anwendung

  Datenbanken: Profildatenbank, Synchronisierungsdatenbank, Datenbank für thematische Kategorien

  Die Profil- und Synchronisierungsdatenbanken sowie die Datenbanken für thematische Kategorien können nicht per Protokoll gesendet werden.

  Zum Bereitstellen von Redundanz für die Benutzerprofildienst-Anwendung müssen Sie zuerst die Dienstanwendung im primären und im sekundären Rechenzentrum bereitstellen.

  Zum Einrichten der Profil- und Synchronisierungsdatenbanken wird empfohlen, eine Sicherung der Datenbanken im sekundären Rechenzentrum wiederherzustellen und die Datenbanken in diesem Rechenzentrum der Benutzerprofildienst-Anwendung anzufügen.

  Zum Synchronhalten der Profile müssen Sie nach der Aktualisierung der Profildaten in der primären Farm das im SharePoint Administration Toolkit enthaltene Benutzerprofilreplikations-Modul verwenden. Weitere Informationen finden Sie unter Benutzerprofilreplikations-Modul (Übersicht) (SharePoint Server 2010).

• Anwendung für den Microsoft SharePoint Foundation-Abonnementeinstellungendienst

  Datenbank: Abonnementdatenbank

  Hinweis

  Protokollversand an die Abonnementeinstellungsdatenbank wird nicht unterstützt.

• Access Services

  Datenbanken: keine

• Excel Services

  Datenbanken: keine

• Suche

  Datenbanken: Durchforstungsdatenbank, Eigenschaftendatenbank, Suchverwaltungsdatenbank

  Die Suche erfordert die vollständige Synchronisierung zwischen den Datenbanken und dem Index. Aufgrund dieser Anforderung kann die Suche nicht mithilfe eines asynchronen Replikationsmechanismus (asynchrone Datenbankspiegelung, Protokollversand oder asynchrone SAN-Replikation) zwischen Farmen repliziert werden.

  Zum Bereitstellen einer aktuellen Suche in einer Failoverfarm müssen Sie die Suche in der sekundären Farm ausführen.

  Wichtig

  Für die Suchdienstanwendung in der Failoverfarm muss das aktive Durchforsten der sekundären Farm festgelegt sein. Beim Failover müssen Sie die Webanwendungszuordnung für die Verwendung der Failoversuchdienstanwendung konfigurieren.

• Statusdienst

  Datenbanken: Statusdatenbank

  Hinweis

  Protokollversand an die Statusdatenbank wird nicht unterstützt.

• Visio Services

  Datenbanken: keine

• Word Automation Services

  Datenbanken: Word Automation Services-Datenbank

  Protokollversand an die Word Automation Services-Datenbank wird nicht unterstützt.

Systemanforderungen für die Notfallwiederherstellung

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 2010-Produkte-Versionen und alle Updates

Obwohl in diesem Artikel in erster Linie die Verfügbarkeit von SharePoint 2010-Produkte behandelt wird, wird die Systembetriebszeit auch von den anderen Komponenten im System beeinflusst. Stellen Sie insbesondere sicher, dass Sie folgende Aktionen ausführen:

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

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

See Also

Other Resources

Ressourcencenter: Geschäftskontinuitätsmanagement für SharePoint Server 2010 (in englischer Sprache)