Planen der Notfallwiederherstellung (SharePoint Foundation 2010)
Gilt für: SharePoint Foundation 2010
Letztes Änderungsdatum des Themas: 2016-11-30
In diesem Artikel wird erläutert, welche wichtigen Entscheidungen Sie bei der Auswahl von Strategien für die Notfallwiederherstellung für eine Microsoft SharePoint Foundation 2010-Umgebung treffen müssen.
Inhalt dieses Artikels:
Übersicht über die Notfallwiederherstellung
Im Kontext dieses Artikel wird Notfallwiederherstellung als die Möglichkeit definiert, eine Situation zu beheben, in der ein Rechenzentrum, das SharePoint Foundation hostet, nicht mehr verfügbar ist.
Die Strategie für die Notfallwiederherstellung, die Sie für SharePoint Foundation verwenden, muss mit der Strategie für die zugehörige Infrastruktur abgestimmt werden; dazu gehören Active Directory-Domänen, Exchange Server und Microsoft SQL Server. Entwerfen Sie gemeinsam mit den Administratoren der Infrastruktur, die Sie nutzen, eine koordinierte Strategie und einen Plan für die Notfallwiederherstellung.
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" bzw. "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.
Nicht unmittelbar 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.
Die Notfallwiederherstellung kann eine der kostspieligeren Anforderungen für ein System sein. Je kürzer das Intervall zwischen Ausfall und Verfügbarkeit ist und je mehr Systeme geschützt werden, umso komplexer und teurer ist wahrscheinlich die Lösung für die Notfallwiederherstellung. Wenn Sie in unmittelbar betriebsbereite Standby-Rechenzentren oder nicht unmittelbar betriebsbereite Standby-Rechenzentren investieren, umfassen die Kosten Folgendes:
Zusätzliche Hardware und Software, die häufig die Vorgänge zwischen den Softwareanwendungen komplexer machen, z. B. benutzerdefinierte Skripts für Failover und Wiederherstellung.
Zusätzliche Komplexität der Betriebsabläufe.
Die Kosten der Unterhaltung von unmittelbar betriebsbereiten oder nicht unmittelbar betriebsbereiten Standby-Rechenzentren sollten auf der Grundlage Ihrer geschäftlichen Anforderungen bewertet werden. Nicht für alle Lösungen in einer Organisation ist nach einem Notfall der gleiche Grad an Verfügbarkeit erforderlich. Sie können für verschiedene Inhalte, Dienste oder Farmen unterschiedliche Stufen der Notfallwiederherstellung vorsehen, z. B. für Inhalte, die umfassende Auswirkungen auf Ihre Geschäftsaktivitäten haben, Suchdienste oder eine Internet-Veröffentlichungsfarm.
Notfallwiederherstellung ist ein wichtiger Bereich, in dem IT-Gruppen Vereinbarungen zum Servicelevel (Service Level Agreements, SLAs) bereitstellen, in denen die Erwartungen der Kundengruppen festgelegt sind. Viele IT-Organisationen bieten unterschiedliche Vereinbarungen zum Servicelevel an, die jeweils unterschiedliche Leistungen umfassen.
Wenn Sie Failover zwischen Serverfarmen implementieren, empfiehlt es sich, zuerst die Kernlösung innerhalb einer Farm bereitzustellen und fein abzustimmen und dann die Notfallwiederherstellung zu implementieren und zu testen.
Auswählen einer Strategie für die Notfallwiederherstellung
Sie können unter mehreren Möglichkeiten zur Bereitstellung einer Notfallwiederherstellung für eine SharePoint Foundation-Umgebung auswählen, ganz entsprechend Ihren geschäftlichen Anforderungen. Die folgenden Beispiele veranschaulichen, aus welchen Gründen sich Unternehmen für eine Notfallwiederherstellungsstrategie mit nicht betriebsbereitem Standby, nicht unmittelbar betriebsbereitem Standby oder betriebsbereitem Standby entscheiden.
Notfallwiederherstellungsstrategie mit nicht betriebsbereitem Standby: Ein Unternehmen sendet regelmäßig Sicherungen zur Unterstützung der Bare-Metal-Wiederherstellung zur lokalen und regionalen Offsitespeicherung und hat Verträge zur Anmietung von Notfallservern in einer anderen Region.
Vorteile:
Operativ gesehen oft die preisgünstigste Option in puncto Instandhaltung.
Häufig eine teure Option für die Wiederherstellung, da hierbei die physischen Server nach einem Notfall wieder korrekt konfiguriert werden müssen.
Nachteile: Die zeitaufwändigste Lösung für die Wiederherstellung.
Notfallwiederherstellungsstrategie mit nicht unmittelbar betriebsbereitem Standby: Ein Unternehmen sendet virtuelle Serverabbilder an lokale und regionale Notfallwiederherstellungsfarmen.
Vorteile: Meist relativ kostengünstige Wiederherstellung, weil für eine virtuelle Serverfarm nach einer Wiederherstellung relativ wenig Konfigurationsaufwand anfällt.
Nachteile: Kann hinsichtlich der Instandhaltung sehr teuer und zeitaufwändig sein.
Notfallwiederherstellungsstrategie mit unmittelbar betriebsbereitem Standby: Ein Unternehmen betreibt mehrere Rechenzentren, verarbeitet Inhalte und Dienste jedoch nur über ein einziges Rechenzentrum.
Vorteile: Häufig sehr schnelle Wiederherstellung möglich.
Nachteile: Konfiguration und Instandhaltung können relativ teuer sein.
Wichtig
Welche Notfallwiederherstellungslösung Sie auch immer in Ihrer Umgebung implementieren, Datenverlust ist in gewissem Umfang wahrscheinlich unvermeidbar.
Planen von nicht betriebsbereiten Standby-Rechenzentren
In einem Notfallwiederherstellungsszenario mit nicht betriebsbereitem Standby können Sie eine Wiederherstellung durchführen, indem Sie eine neue Farm an einem neue Standort einrichten (vorzugsweise per Skriptbereitstellung) und Sicherungen wiederherstellen. Oder Sie stellen dazu eine Farm aus einer Sicherungslösung wie etwa Microsoft System Center Data Protection Manager 2007 wieder her, die Ihre Daten auf Computerebene schützt und es Ihnen ermöglicht, jeden Server einzeln wiederherzustellen. Dieser Artikel enthält keine ausführlichen Anweisungen zum Erstellen und Wiederherstellen einer Farm in einem Szenario mit nicht betriebsbereitem Standby. Weitere Informationen finden Sie unter
Planen von nicht unmittelbar betriebsbereiten Standby-Rechenzentren
In einem Notfallwiederherstellungsszenario mit nicht unmittelbar betriebsbereitem Standby können Sie eine entsprechende ausgelegte Lösung erstellen, indem Sie konsequent und häufig virtuelle Abbilder der Server in Ihrer Farm erstellen und an einen zweiten Standort senden. An diesem zweiten Standort muss eine Umgebung verfügbar sein, in der Sie die Abbilder problemlos konfigurieren und verbinden können, um die Farmumgebung wiederherzustellen.
Dieser Artikel enthält keine ausführlichen Anweisungen zum Erstellen von Lösungen für nicht unmittelbar betriebsbereites Standby. Weitere Informationen zum Planen der Bereitstellung von Farmen mithilfe von virtuellen Lösungen finden Sie unter Planen für die Virtualisierung (SharePoint Foundation 2010).
Planen von unmittelbar betriebsbereiten Rechenzentren
In einem Notfallwiederherstellungsszenario mit unmittelbar betriebsbereitem Standby können Sie eine Failoverfarm einrichten, um Notfallwiederherstellung in einem separaten Rechenzentrum bereitzustellen, das nicht mit dem der primären Farm identisch ist. Eine Umgebung mit einer separaten Failoverfarm hat folgende Merkmale:
Eine separate Konfigurationsdatenbank und eine gesonderte Inhaltsdatenbank der Zentraladministration müssen in der Failoverfarm gepflegt werden.
Alle Anpassungen müssen in beiden Farmen bereitgestellt werden.
Hinweis
Es wird empfohlen, die primäre und die Failoverfarm unter Verwendung der gleichen Konfigurationseinstellungen und Anpassungen mithilfe von Skriptbereitstellung zu erstellen.
Updates müssen einzeln auf beide Farmen angewendet werden.
SharePoint Foundation-Inhaltsdatenbanken können asynchron auf die Failoverfarm gespiegelt oder per Protokollversand an die Failoverfarm übermittelt werden.
Hinweis
Spiegelung mit SQL Server kann nur zum Kopieren von Datenbanken auf einen einzigen Spiegelserver verwendet werden, einen Protokollversand können Sie jedoch zu mehreren sekundären Servern durchführen.
Manche Dienstanwendungen können per Protokollversand an eine Farm übermittelt werden, andere nicht. Weitere Informationen finden Sie unter Redundanz von Dienstanwendungen über mehrere Rechenzentren hinweg weiter unten in diesem Artikel.
Diese Topologie kann für mehrere Rechenzentren wiederholt werden, wenn Sie den SQL Server-Protokollversand zu einem oder mehreren zusätzlichen Rechenzentrum konfigurieren.
Erkundigen Sie sich beim Hersteller Ihres Storage Area Network (SAN), ob Sie SAN-Replikation oder einen anderen unterstützten Mechanismus nutzen können, um Verfügbarkeit über mehrere Rechenzentren hinweg sicherzustellen.
Die folgende Abbildung zeigt eine primäre Farm und Failoverfarmen vor einem Failover.
Primäre Farm und Failoverfarmen vor dem Failover
.gif "Primäre Farm und Failoverfarm vor dem Failover")
Redundanz von Dienstanwendungen über mehrere Rechenzentren hinweg
Damit die Verfügbarkeit von Dienstanwendungen über mehrere Rechenzentren hinweg gewährleistet ist, empfiehlt es sich, für die Dienste, die farmübergreifend ausgeführt werden können, eine separate Dienstfarm zu betreiben, auf die sowohl vom primären als auch von den sekundären Rechenzentren aus zugegriffen werden kann.
Für Dienste, die nicht farmübergreifend ausgeführt werden können, und für die Sicherstellung der Verfügbarkeit der Dienstfarm selbst gibt es unterschiedliche Strategien zur Herstellung von alle Rechenzentren übergreifender Redundanz für eine Dienstanwendung. Welche Strategie Sie anwenden sollten, hängt von folgenden Faktoren ab:
Die Ausführung der Dienstanwendung in der Notfallwiederherstellungsfarm, wenn sie nicht gebraucht wird, hat einen betriebswirtschaftlichen Nutzen.
Die der Dienstanwendung zugeordneten Datenbanken können per Protokollversand übermittelt 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 der Strategie gruppiert.
Datenbanken, die per Protokollversand übermittelt oder asynchron gespiegelt werden können
Nach der ersten Bereitstellung einer Dienstanwendung in einer sekundären Farm können die Datenbanken, die die folgenden Dienstanwendungen unterstützen, asynchron gespiegelt oder per Protokollversand zwischen Farmen übermittelt werden:
Anwendungsregistrierungsdienst-Anwendung
Datenbanken: Anwendungsregistrierungsdienst
Business Data Connectivity-Dienstanwendung
Datenbanken: Business Data Connectivity
Dienstanwendung für die Erfassung von Verwendungs- und Integritätsdaten
Datenbanken: Protokollierung
Hinweis
Es ist möglich, die Protokollierungsdatenbank per Protokollversand zu übermitteln oder zu spiegeln. Es empfiehlt sich jedoch, den Dienst für die Erfassung von Verwendungs- und Integritätsdaten nicht in der Notfallwiederherstellungsfarm auszuführen und die Protokollierungsdatenbank weder zu spiegeln noch per Protokollversand zu übermitteln.
Dienstanwendungen und Datenbanken, die nicht per Protokollversand übermittelt oder nicht asynchron gespiegelt werden können
Die folgenden Dienstanwendungen müssen sowohl in der primären Farm als auch in den Failoverfarmen bereitgestellt werden und können nicht asynchron gespiegelt oder per Protokollversand übermittelt werden. Für die meisten dieser Dienstanwendungen wird empfohlen, sie bereitzustellen und dann sicherstellen, dass in der Failoverfarm die gleichen Konfigurationseinstellungen gelten wie in der primären Farm. Werden in der primären Farm Konfigurationsänderungen vorgenommen, die sich auf den Dienst auswirken, müssen Sie die Failoverfarm aktualisieren.
Dienstanwendung Microsoft SharePoint Foundation-Abonnementeinstellungen
Datenbank: Abonnementeinstellungen
Hinweis
Protokollversand der Datenbank Abonnementeinstellungen wird nicht unterstützt.
Systemanforderungen für die Notfallwiederherstellung
Im Idealfall stimmen die Failoverkomponenten und -systeme in allen Einzelheiten mit den primären Komponenten und Systemen überein: Plattform, Hardware und Anzahl der Server. Mindestvoraussetzung ist, dass die Failoverumgebung den Datenverkehr verarbeiten kann, der während eines Failovers zu erwarten ist. Bedenken Sie, dass der Failoverstandort möglicherweise nur einen Teil der Benutzer verarbeiten kann. Die Systeme müssen mindestens in folgenden Kriterien übereinstimmen:
Betriebssystemversion einschließlich aller Updates
SQL Server-Versionen einschließlich aller Updates
SharePoint 2010-Produkte-Versionen einschließlich aller Updates
Auch wenn in diesem Artikel vor allem die Verfügbarkeit von SharePoint 2010-Produkte behandelt wird, beeinflussen doch auch die anderen Komponenten im System die Systembetriebszeit. Folgende Schritte sollten Sie deshalb unbedingt ausführen:
Sicherstellen, dass die Systeme, von denen die Infrastruktur abhängt, d. h. Strom, Kühlung, Netzwerk, Verzeichnisse und SMTP, vollständig redundant sind
Einen Schaltmechanismus verwenden, sei es DNS oder Hardwarelastenausgleich, der Ihre Anforderungen erfüllt.