Planen von SQL Server AlwaysOn und Microsoft Azure für die Notfallwiederherstellung in SharePoint Server

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

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

Erstellen Sie mit SQL Server 2014 und SQL Server 2016 AlwaysOn-Verfügbarkeitsgruppen und Microsoft Azure eine hybride Notfallwiederherstellungsumgebung für die lokale SharePoint Server 2016- und SharePoint Server 2013-Farm. Dieser Artikel beschreibt, wie Sie diese Lösung entwerfen und implementieren.

Die Lösung in diesem Artikel bezieht sich auf Folgendes:

SharePoint Server 2013

• Microsoft Azure

• SQL Server 2014 Enterprise

• Windows Server 2012 R2 Datacenter

SharePoint Server 2016 Enterprise

• SQL Server 2014 mit Service Pack 1 (SP1)

• SQL Server 2016 Enterprise Edition

• Windows Server 2012 R2

• Windows Server 2016 Datacenter Edition

Acknowledgments: Diese SharePoint Server-Notfallwiederherstellungslösung wurde von Tejinder Rai (MCS) entworfen, getestet und geschrieben. Die Lösung kombiniert bewährte Methoden von Microsoft mit praktischen, realistischen Kundenerfahrungen. David Williams und Matthew Robertshaw haben durch ihre Arbeit an SQL Server Failoverautomatisierung und Wiederherstellungstests ebenfalls bedeutende Beiträge zu diesem Artikel geleistet.

Inhalt dieses Artikels

-
Einführung in die hybride Notfallwiederherstellung für SharePoint Server

-
Beschreibung und Architektur der Notfallwiederherstellungslösung

-
Anforderungen für diese Notfallwiederherstellungslösung für SharePoint

-
Verbindliche Konfigurationsanforderungen für beide Farmen

-
Grundlegende Datenbankanforderungen: SQL Server AlwaysOn und SharePoint Server

-
Einrichten der Testfarmen in sechs Phasen

-
Failover und Wiederherstellung der Testfarm

-
Schlussbemerkung

-
Anhang

Einführung in die hybride Notfallwiederherstellung für SharePoint Server

Das Einrichten einer geeigneten Notfallwiederherstellungsumgebung kann ein aufwändiger und komplizierter Vorgang sein. Es erfordert sorgfältige Planung, eine Lösung bereitzustellen und zu testen, die Ihren Geschäftszielen bezüglich der schnellen Wiederherstellung Ihrer Produktionsumgebung und Ihrer Anwendungen entspricht.

Was die Notfallwiederherstellung betrifft, wird durch SharePoint Server die Messlatte für Komplexität und die Notwendigkeit ausführlicher Planungs-, Entwurfs- und Testphasen hoch gelegt. Einschränkungen, die Sie beachten müssen, sind unter anderem die verschiedenen Failovertypen, die SQL Server für Verfügbarkeitsgruppenreplikate unterstützt, sowie die Tatsache, dass manche SharePoint-Datenbanken keine asynchronen Commitvorgänge für Replikate unterstützen. Die Wiederherstellung dieser Sonderfälle macht eine besondere Behandlung erforderlich.

SharePoint Server Wiederherstellung der Suche

Die SharePoint-Suche ist einer der Fälle, die einen anderen Ansatz und besondere Techniken für die Wiederherstellung in einem Notfallszenario erfordern. Der Grund ist, dass die Datenbankgenauigkeit für den Suchindex und das Dateisystem nicht aufrechterhalten werden kann, wenn Sie AlwaysOn-Verfügbarkeitsgruppen mit asynchronem Commit für ein sekundäres Replikat verwenden.

Es ist wichtig, dass Sie die vier verfügbaren Notfallwiederherstellungsoptionen für die Suche in einer SharePoint Server-Farm verstehen. Jede Option hat Vor- und Nachteile, und die beste Option wird durch die Anforderungen an Geschäftskontinuität und Wiederherstellung bestimmt. Weitere Informationen zu den unterstützten Optionen, zu denen auch eine hybride Option zur Wiederherstellung des Suchdiensts in einer in einer öffentlichen Cloud gehosteten Farm gehört, finden Sie unter Best Practices und Strategien zur Notfallwiederherstellung für die SharePoint 2016-Suche.

Kriterien für die Notfallwiederherstellung

Bevor die Cloud-Technologie verfügbar war, mussten Organisationen ein sekundäres Datencenter als Standbyumgebung einrichten, in der im Notfall unternehmenskritische Systeme ausgeführt werden konnten. Die Kosten im Zusammenhang mit der Einrichtung und dem Betrieb eines sekundären Datencenters hielten viele Organisationen vom Einrichten einer Notfallwiederherstellungsumgebung für SharePoint ab.

Die Verfügbarkeit und Reife der Infrastruktur und der Plattformdienste für die Cloud machen Microsoft Azure zu einer brauchbaren und kostengünstigen Alternative zum Betrieb eines sekundären Datencenters.

Neben den grundlegenden Kosten im Zusammenhang mit einem sekundären Datencenter müssen Unternehmen auch die Wiederherstellungsanforderungen für kritische Systeme und Unternehmensdaten bestimmen. Wiederherstellungsanforderungen werden durch Beantwortung der folgenden beiden Fragen bestimmt:

• Wie lange können wir offline sein, bevor das Unternehmen erhebliche Verluste erleidet? Diese Verluste könnten z. B. in verringertem Umsatz, beschädigten Geschäftsbeziehungen oder verringerter Glaubwürdigkeit bestehen.

• Wie viele Daten können wir verlieren, bevor das Unternehmen erhebliche Verluste erleidet? Zusätzlich zu den Offlinebeispielen sind einige Branchen völlig datengesteuert und von Daten abhängig.

In der Welt der Notfallwiederherstellung werden diese Kriterien als Recovery Time Objectives (RTO, angestrebte Wiederherstellungsdauer) und Recovery Point Objectives (RPO, angestrebter Wiederherstellungszeitpunkt) bezeichnet.

Die Kosten einer Notfallwiederherstellungslösung sind an diese Ziele gebunden – Tatsache ist, dass eine bessere RTO und RPO mehr kosten. Die Zielsetzung und die Kosten bestimmen auch die Wiederherstellungsumgebung, die Sie wählen. Die Branchenterminologie für drei grundlegende Notfallwiederherstellungsumgebungen lautet: Verzögert betriebsbereit, bedingt betriebsbereit und unmittelbar betriebsbereit. Je nach Branchensektor gibt es natürlich Variationen.

Weitere Informationen zur Notfallwiederherstellung finden Sie unter Konzepte für hohe Verfügbarkeit und Notfallwiederherstellung in SharePoint Server und Wählen einer Notfallwiederherstellungsstrategie für SharePoint Server.

Dieser Artikel stellt ein Framework bereit, das Sie verwenden können, um eine hybride Notfallwiederherstellungslösung für SharePoint Server bereitzustellen.

Nicht in diesem Artikel behandelt

Die folgenden Themen gehen über den Rahmen dieses Artikels hinaus:

• Erstellen eines Plans für Geschäftskontinuität und eines zugehörigen Notfallwiederherstellungsplans.

• Servicelevelanforderungen für RTO und RPO.

• Kostenschätzung auf der Grundlage von Servicelevelanforderungen.

• Ausführliche Schritte für Folgendes:

  • Konfigurieren eines Windows Server Failover Cluster (WSFC)-Clusters

  • Bereitstellen einer Azure-Umgebung (Speicherkonten, virtuelle Netzwerke, Cloud-Dienste, Verfügbarkeitsgruppen und virtuelle Computer)

  • Konfigurieren eines VPN-Tunnels von der lokalen Farm zur Azure-Wiederherstellungsumgebung

Beschreibung und Architektur der Notfallwiederherstellungslösung

Unsere Hybridlösung verwendet eine Topologie, die kontinentübergreifende Redundanz in Nordamerika bereitstellt. Die folgenden Testfarmen werden an zwei Orten bereitgestellt:

• Eine lokale Produktionsfarm, die in einem Datencenter in Redmond, WA (Westküste), ausgeführt wird.

• Eine Wiederherstellungsfarm, die in Microsoft Azure bereitgestellt wird. Diese Farm wird in einem Datencenter im Osten der USA gehostet. Die Farm wird als bedingt betriebsbereite Wiederherstellungsumgebung eingerichtet.

Die hier beschriebene Lösung verwendet SQL Server AlwaysOn-Verfügbarkeitsgruppen als End-to-End-Lösung, die hohe Verfügbarkeit und Failover-Notfallwiederherstellung bietet. Zusätzlich zu einer hohen Verfügbarkeit in einer Produktionsumgebung verbessert SQL Server AlwaysOn die RTO, da die SQL Server-Instanzen im sekundären Datencenter ein Replikat der Datenbanken aus dem primären Datencenter enthalten.

Unsere Testumgebung und die Bedingungen wurden so entworfen, dass sie den Typ der SharePoint-Produktionsfarm und Notfallwiederherstellungslösung darstellen, den Mainstream-Kunden erstellen.

Logische Architektur

Die nächste Abbildung (Abbildung 1) zeigt die logische Architektur für diese Lösung und veranschaulicht die Verwendung lokaler und in Azure gespeicherter Verfügbarkeitsgruppenreplikate.

Abbildung 1: Logische Architektur für Hybridumgebung

Detaillierte Architektur

Die folgende Abbildung (Abbildung 2) zeigt die detaillierte Architektur für die lokale Testfarm. Die Farm wird als hochverfügbare Farm mit Unternehmenssuche konfiguriert.

Abbildung 2: Lokale Produktionsfarm

Die folgende Abbildung (Abbildung 3) zeigt die detaillierte Topologie der in Azure bereitgestellten bedingt betriebsbereiten Farm.

Abbildung 3: Bedingt betriebsbereite Wiederherstellungsfarm

Anforderungen für diese Notfallwiederherstellungslösung für SharePoint Server

Verwenden Sie die folgenden Anforderungen als Leitfaden zum Planen der Bereitstellung dieser Notfallwiederherstellungslösung.

Infrastructure and general configuration

Die folgende Liste bietet eine Übersicht über die Infrastrukturanforderungen und die allgemeinen Konfigurationsanforderungen für die lokale Farm und die Wiederherstellungsfarm:

• Zwei SharePoint Server-Farmen. Eine Produktionsfarm im primären Datencenter und eine bedingt betriebsbereite Farm mit Azure als sekundäres Datencenter. Ein weiterer Vorteil beim Einsatz von Azure ist, dass Sie sich nicht um die Verwendung identischer Hardware für die beiden Farmen kümmern müssen.

• Jede Farm ist in beiden Datencentern online.

• Softwareversionen und Patchebenen. Beide Farmen verwenden dieselbe Softwareversion und Patchebene für Folgendes:

  • Windows Server 2012 R2 oder Windows Server 2016

  • SQL Server 2014 oder SQL Server 2016

  • SharePoint Server 2016 oder SharePoint Server 2013

• Beide Farmen sind für die Verwendung derselben Dienstkonten zur Verwaltung von SharePoint konfiguriert.

• Inhaltsdatenbanken und Dienstanwendungsdatenbanken sind auf SQL Server-Verfügbarkeitsgruppen verteilt.

• Verwenden Sie für die Replikate in der lokalen Umgebung den synchronen Commitmodus. Dies ist die übliche Hochverfügbarkeitskonfiguration für eine SharePoint-Farm, da sie automatisches Failover unterstützt und Datenverluste minimiert.

• Verwenden Sie für das Replikat in der Wiederherstellungsumgebung den asynchronen Commitmodus. Auch wenn kein automatisches Failover unterstützt wird, ist der Datendurchsatz normalerweise höher. Dies kann ein wichtiger Faktor sein, wenn der Abstand zwischen der Produktionsfarm und der Wiederherstellungsfarm groß ist.

  Hinweis

  Es gibt Fälle, in denen synchrone Commits für ein Replikat in einer Wiederherstellungsumgebung getestet und implementiert wurden, da der Durchsatz der gleiche wie bei Verwendung asynchroner Commits für das Wiederherstellungsreplikat ist. Dies wird jedoch nicht allgemein akzeptiert oder empfohlen.

• Jede Farm hat eigene Dienstanwendungen, die zwischen den beiden Umgebungen synchronisierte Datenbanken verwenden. Da für Dienstanwendungen in der Notfallwiederherstellungsfarm schreibgeschützte Datenbanken verwendet werden, müssen die Dienstanwendungen beim Failover der Produktionsfarm nicht erneut bereitgestellt werden.

• Suchdurchforstung mit schreibgeschützten Datenbanken in der Notfallwiederherstellungsinstanz. Wenn dies nötig ist, müssen Sie eine gesonderte Suchdienstanwendung für die Wiederherstellungsfarm konfigurieren. Weitere Informationen finden Sie unter Unterstützte Hochverfügbarkeits- und Notfallwiederherstellungsoptionen für SharePoint-Datenbanken.

Verbindliche Konfigurationsanforderungen für beide Farmen

Folgende Technologien werden benötigt, um die hier beschriebene Notfallwiederherstellungslösung bereitzustellen:

• Windows Server 2012 R2 oder Windows Server 2016

• SharePoint Server 2016 oder SharePoint Server 2013 mit Service Pack 1 und dem kumulativen Update vom Mai 2014

• SQL Server 2014 oder SQL Server 2016

• Eine sichere Verbindung zwischen dem primären Datencenter und der Wiederherstellungsfarm in Azure. Wir haben eine VPN-Verbindung verwendet, aber wenn in Ihrer Gegend ExpressRoute verfügbar ist, können Sie auch das verwenden.

Grundlegende Datenbankanforderungen: SQL Server AlwaysOn und SharePoint Server

Das primäre Datencenter verwendet Verfügbarkeitsgruppenreplikate mit synchronem Commit, um hohe Verfügbarkeit in der primären Farm zu erzielen. Das sekundäre Datencenter muss Replikate mit asynchronem Commit verwenden. Dies liegt an der Latenz im Netzwerk zwischen dem primären und dem sekundären Datencenter. Es ist wichtig, dass die Latenz bei der Wiedergabe der Protokollpuffer in die Notfallwiederherstellungsfarm beim Testen überwacht wird.

Abhängigkeiten, Voraussetzungen und bewährte Methoden

Überprüfen Sie vor dem Einrichten der Testfarmen die folgenden Abhängigkeiten, Voraussetzungen und bewährten Methoden.

Windows Server-Failoverclustering (WSFC)-Cluster

Der WSFC-Cluster erstreckt sich über zwei Datencenter. Alle Knoten im lokalen Datencenter und in der Wiederherstellungsumgebung gehören demselben WSFC-Cluster an.

SQL Server-Konfiguration für SharePoint

• Erstellen Sie SQL Server-Volumes, um die SQL-Datenbanken, Farmdatenbanken, Datenbankprotokolldateien, tempdb-Datenbanken und tempdb-Datenbankprotokolldateien zu trennen.

• Verteilen Sie die Farmdatenbanken entsprechend der Lese-/Schreibgeschwindigkeit auf die Volumes. Unter Zugrundelegung der Priorität von der schnellsten zur langsamsten Geschwindigkeit ist folgende Verteilung typisch:

  • Tempdb-Datendateien und Transaktionsprotokolldateien

  • Datenbank-Transaktionsprotokolldateien

  • Suchdatenbankdateien

  • Inhaltsdatenbanken

• Richten Sie die Konten für den SQL Server-Dienst und den SQL Agent-Dienst ein.

Verwenden Sie beim Bereitstellen von SQL Server für die SharePoint-Farmen die Konfigurationen in der folgenden Tabelle.

Entwurfsanforderungen und -überlegungen

Jede SQL Server-Instanz, die Teil einer AlwaysOn-Verfügbarkeitsgruppe ist, muss auch Teil desselben WSFC-Clusters sein. Eine Verfügbarkeitsgruppe umfasst ein primäres Replikat, das die aktuellsten Daten enthält, und sekundäre Replikate, die Updates vom primären Replikat erhalten. Jedes Verfügbarkeitsreplikat muss sich auf einem anderen Knoten eines einzelnen Windows Server Failover Clustering (WSFC)-Clusters befinden. Alle SQL Server-Knoten, die Teil eines einzelnen Windows Server-Failoverclusters sind, benötigen im Gegensatz zu SQL Server-Failoverclusterinstanzen (FCIs) eigenen Speicher.

Weitere Informationen zu Voraussetzungen, Einschränkungen, Empfehlungen und zur allgemeinen Verwendung von Verfügbarkeitsgruppen finden Sie unter:

• Voraussetzungen, Einschränkungen und Empfehlungen für AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

• AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

  Die folgende Abbildung (Abbildung 4) zeigt die Infrastruktur der Verfügbarkeitsgruppenreplikate, die wir für die SharePoint-Datenbanken verwendet haben.

Abbildung 4: Infrastruktur der Verfügbarkeitsgruppenreplikate

In der in Abbildung 4 dargestellten Infrastruktur befinden sich üblicherweise die Datenbankserver in der Wiederherstellungsumgebung in einem separaten Subnetz. Dies muss beim Konfigurieren von WSFC und Verfügbarkeitsgruppenlistenern berücksichtigt werden.

Zudem müssen Sie die Netzwerklatenz zwischen der lokalen Farm und der Wiederherstellungsumgebung planen und testen. Die Latenz zwischen Replikaten wirkt sich auf Ihre Recovery Point Objective (RPO) aus.

Schließlich sollten Sie darüber nachdenken, die Datenbankserver in der Wiederherstellungsumgebung in einem eigenen Azure-Cloud-Dienst bereitzustellen. So wurde auch die Testumgebung erstellt. Durch Cloud-Dienste können Sie Serverrollen gruppieren und so Azure-VMs als eine Einheit verwalten. Weitere Informationen finden Sie unter Sollte ich mich für Clouddienste oder eine andere Lösung entscheiden?.

Wie bei SharePoint Server ist es einfacher, die Architektur vorab zu entwerfen, statt die Plattformdienste von Azure später neu zu entwickeln.

Commitmodi und Failovertypen von Verfügbarkeitsgruppen

Es ist wichtig, den Einfluss der Commitmodi auf die Failovertypen für die einzelnen Verfügbarkeitsgruppenkonfigurationen zu verstehen, da sich dies auf die Farmwiederherstellung auswirkt. Die folgende Tabelle stammt aus der SQL Server-Dokumentation. In der Tabelle ist zusammengefasst, welche Formen von Failover in verschiedenen Verfügbarkeits- und Failovermodi unterstützt werden. Für jede Kombination wird der effektive Verfügbarkeitsmodus und Failovermodus durch die Schnittmenge der Modi des primären Replikats und der Modi eines oder mehrerer sekundärer Replikate bestimmt. Weitere Informationen finden Sie unter Failover und Failovermodi (AlwaysOn-Verfügbarkeitsgruppen).

*****Wenn Sie einen Befehl für ein erzwungenes Failover für ein synchronisiertes sekundäres Replikat ausgeben, verhält sich das sekundäre Replikat wie bei einem manuellen Failover.

Die Zeitdauer, für die die Datenbank während eines Failovers nicht verfügbar ist, hängt vom Typ des Failovers und seiner Ursache ab.

Unterstützte Hochverfügbarkeits- und Notfallwiederherstellungsoptionen für SharePoint-Datenbanken

In den Tabellen in diesem Abschnitt sind die unterstützten Optionen für hohe Verfügbarkeit und Notfallwiederherstellung für SharePoint Server-Datenbanken beschrieben. Ausführliche Informationen finden Sie unter Unterstützte Hochverfügbarkeits- und Notfallwiederherstellungsoptionen für SharePoint-Datenbanken.

Einrichten der Testfarmen in sechs Phasen

Das Einrichten einer SharePoint-Umgebung, die hohe Verfügbarkeit (High Availability, HA) und Notfallwiederherstellung (Disaster Recovery, DR) bietet, umfasst mehrere Phasen. Wir haben die Schritte für das Konfigurieren der lokalen Farm und der Wiederherstellungsfarm in folgende Phasen zusammengefasst:

1. Erstellungsphase 1: Konfigurieren der Windows Server-Failovercluster und von SQL Server AlwaysOn für die lokale Umgebung

2. Erstellungsphase 2: Installieren und Konfigurieren von SharePoint Server zur Erstellung der lokalen Farm

3. Erstellungsphase 3: Konfigurieren von Windows Server Failover Cluster und SQL Server in der Wiederherstellungsumgebung

4. Erstellungsphase 4: Installieren und Konfigurieren von SharePoint Server zur Erstellung der Wiederherstellungsfarm

5. Erstellungsphase 5: Abschließen der Konfiguration des Wiederherstellungsendpunkts und der Replikatdatenbanken für die Wiederherstellungsfarm

6. Erstellungsphase 6: Abschließen der Konfiguration von SharePoint Server in der Wiederherstellungsfarm.

Vorbereitungen

In der folgenden Tabelle sind die wichtigsten Infrastrukturkomponenten für dieses Notfallwiederherstellungsszenario aufgeführt. Dabei werden Voraussetzungen genannt und Anleitungen zur Konfiguration gegeben.

Microsoft Azure und die Wiederherstellungsumgebung

Die ersten Schritte beim Einrichten der Wiederherstellungsumgebung bestehen im Bereitstellen eines Servers in Azure und Einrichten einer VPN- oder ExpressRoute-Verbindung zwischen der lokalen Farm und dem Azure-Server.

Azure Infrastructure as a Service (IaaS) gleicht in vielerlei Hinsicht einer lokalen privaten Cloud mit Windows Server Hyper-V-Virtualisierung und System Center Virtual Machine Manager (VMM). Allerdings haben sogar IT-Profis mit umfassender Erfahrung im Arbeiten in einer privaten Cloud mit den Unterschieden zu kämpfen!

Das Datenblatt Anhang im Anhang hilft Ihnen bei der Planung, Bereitstellung und dem Betrieb von SharePoint Server 2016 in der Azure-Umgebung. Es ersetzt weder die Azure-Dokumentation noch praktische Erfahrungen, aber es erleichtert Ihnen den Zugang zur Azure-Welt aus einer SharePoint-Perspektive. Weitere Informationen zu Azure-Notfallwiederherstellungslösungen finden Sie unter Replizieren einer SharePoint-Anwendung mit mehreren Ebenen für die Notfallwiederherstellung mithilfe von Azure Site Recovery und Was ist Site Recovery?.

Erstellungsphase 1

Die folgende Tabelle bietet weitere Informationen zu den Schritten in Erstellungsphase 1.

Set-ClusterQuorum -NodeAndFileShareMajority "\\fileserver\share"

(Get-ClusterNode {CLUSTERNODENAME}).NodeWeight=1

Set-ClusterQuorum -CloudWitness -AccountName <StorageAccountName> -AccessKey <StorageAccountAccessKey>

Datenbankgruppierung für die Notfallwiederherstellung

Es wird empfohlen, SharePoint-Datenbanken zu gruppieren und entsprechend Ihren Notfallwiederherstellungsanforderungen verschiedenen Verfügbarkeitsgruppen zuzuweisen.

Dies ist notwendig, da jede Verfügbarkeitsgruppe lokal für hohe Verfügbarkeit über ein Replikat mit synchronem Commit und in der Notfallwiederherstellungsumgebung über ein Replikat mit asynchronem Commit verfügt.

Wie im Abschnitt Unterstützte Hochverfügbarkeits- und Notfallwiederherstellungsoptionen für SharePoint-Datenbanken erwähnt, unterstützen Datenbanken, die synchrone Commits unterstützen, nicht notwendigerweise asynchrone Replikate. Die folgende Tabelle zeigt ein Beispiel, wie Datenbanken in bestimmte AlwaysOn-Verfügbarkeitsgruppen gruppiert werden können.

* Diese Namen sind nur Beispiele. Sie können Ihre eigene Benennungskonvention verwenden.

** Die Verwendungsdatenbank kann unabhängig auf jeder SQL Server-Instanz im Cluster erstellt werden. Neben der Speicherung vorübergehender Daten weist sie sehr hohe Transaktionen auf, was ein weiterer Grund ist, sie nicht in einer Verfügbarkeitsgruppe zu platzieren. Verwenden Sie das Set-SPUsageApplication-Cmdlet zum Erstellen der Datenbank in der sekundären SQL-Instanz. Verwenden Sie anschließend das Set-SPUsageApplication-Cmdlet mit der -FailoverDatabaseServer-Option, um die sekundäre SQL-Instanz in der Hochverfügbarkeitsumgebung anzugeben.

In der folgenden Tabelle wird unsere Testkonfiguration am Ende der Erstellungsphase 1 beschrieben.

Erstellungsphase 2

Die folgende Tabelle bietet weitere Informationen zu den Schritten in Erstellungsphase 2.

Erstellungsphase 3

Die folgende Tabelle bietet weitere Informationen zu den Schritten in Erstellungsphase 3.

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

Test-Cluster

(Get-ClusterNode {CLUSTERNODENAME}).NodeWeight=0

Erstellungsphase 4

Die folgende Tabelle bietet weitere Informationen zu den Schritten in Erstellungsphase 4.

Erstellungsphase 5

Die folgende Tabelle bietet weitere Informationen zu den Schritten in Erstellungsphase 5.

Erstellungsphase 6

Die folgende Tabelle bietet weitere Informationen zu den Schritten in Erstellungsphase 6.

# Refresh sites in the configuration database
Get-SPContentDatabase -WebApplication http://webapplicationsitename | | ForEach {
Write-host "Refreshing sites in configuration database for database: " $_.Name
$_.RefreshSitesInConfigurationDatabase()
}

Failover und Wiederherstellung der Testfarm

Die Verfahren in diesem Abschnitt erläutern, wie ein Farmfailover und eine anschließende Wiederherstellung simuliert werden. Verwenden Sie nach der Wiederherstellung die Verfahren zum Failback zur lokalen Farm.

Die Dienstanwendungen in der Notfallwiederherstellungsfarm wurden im Rahmen des Erstellungsprozesses erstellt. Da die Dienstanwendungen nach einem vollständigen Websiteausfall wiederhergestellt werden, befinden sie sich auf der Notfallwiederherstellungswebsite im Schreibmodus, da die Wiederherstellung der SQL-Verfügbarkeitsgruppen in den SQL Server-Instanzen der Notfallwiederherstellung nach Abschluss des Notfallwiederherstellungsfailovers zum primären Replikat wird. Die Datenverschiebung zu den SQL Server-Instanzen im primären Datencenter wird nicht mehr fortgesetzt und in einen angehalten Zustand versetzt, bis sie manuell neu gestartet wird. Wenn eine SQL-Instanz ein primäres Verfügbarkeitsgruppenreplikat hostet, werden alle anderen Replikate als sekundäre Replikate in der Verfügbarkeitsgruppe betrachtet.

Gehen Sie folgendermaßen vor, um die SharePoint-Farm in der Failoverumgebung wiederherzustellen, wenn Sie ein Failover starten.

Failoverschritt 1

Die Entscheidung für eine Notfallwiederherstellung wird in der Regel von Business Continuity Management (BCM)-Teams und Dienstbesitzern basierend auf Managemententscheidungen gefällt. Die Notfallwiederherstellungsentscheidung wird in der Regel in Betracht gezogen, wenn die primäre Website nicht mehr zugänglich ist. Mit den folgenden Verfahren wird dann ein Failover der primären Farm zur Notfallwiederherstellungsfarm ausgeführt.

Failoverschritt 2

Start a cluster and availability group failover

Führen Sie ein Failover des Clusters und der Verfügbarkeitsgruppen mithilfe der PowerShell-Cmdlets in der folgenden Liste aus.

1. Beenden Sie den Clusterdienst mit dem Stop-Service Clussvc.

2. Starten Sie den Clusterknoten, und beheben Sie das Quorum mit dem folgenden Befehl:

   Start-ClusterNode -Name <ACTIVE SQL NODE> -FixQuorum
   

3. Verschieben Sie die Clustergruppe mit dem folgenden Befehl zu einem aktiven SQL-Knoten im Notfallwiederherstellungs-Datencenter.

   Move-ClusterGroup -Cluster  <CLIUSTER GROUP>  -node <ACTIVE SQL NODE>
   

4. Bestätigen Sie mit dem folgenden Befehl, dass der Clusterdienst gestartet wurde.

   Get-ClusterNode -Name "<NodeName>"
   

5. Passen Sie die Stimmrechte für den Cluster an. Allen SQL Server-Knoten auf der Notfallwiederherstellungswebsite müssen Quorumstimmrechte erteilt werden. Wiederholen Sie den folgenden Befehl für jeden Clusterknoten im Notfallwiederherstellungs-Datencenter.

   (Get-ClusterNode -Name "NodeName").NodeWeight=1
   Get-ClusterNode | fl Name, NodeWeight
   

6. Nachdem dem Remoteknoten eine Stimme für das Quorum gewährt wurde, verwenden Sie den folgenden Befehl, um die Stimmen der beiden Knoten in der lokalen Farm zu entfernen.

   (Get-ClusterNode -name "Node1").NodeWeight=0
   (Get-ClusterNode -name "Node2").NodeWeight=0
   

7. Verwenden Sie den folgenden Befehl, um die Gewichtungseinstellungen der Knoten zu überprüfen.

   Get-ClusterNode | fl Name,NodeWeight
   

8. Wenn die Knotengewichte erfolgreich angewendet wurden, können die Verfügbarkeitsgruppen mithilfe des SQL Server-Cmdlets Switch-SqlAvailabilityGroup zu den entsprechenden SQL Server-Instanzen in der Notfallwiederherstellungsfarm verschoben werden. Bei Verwendung dieses Cmdlets müssen Sie den Parameter -AllowDataLoss verwenden. Beispiel:

   Switch-SqlAvailabilityGroup -Path SQLSERVER:\Sql\<SQLNODE>\<MSQLINSTANCE>\AvailabilityGroups\<AGName> -AllowDataLoss
   

9. Führen Sie diesen Vorgang für jede Verfügbarkeitsgruppe aus.

Weitere Informationen finden Sie unter Ausführen eines geplanten manuellen Failovers einer Verfügbarkeitsgruppe (SQL Server).

Failoverschritt 3

SharePoint Content Databases

Binden Sie ggf. weitere SharePoint-Inhaltsdatenbanken ein, die nicht Teil der ursprünglichen Farmkonfiguration waren. Möglicherweise wurden seit der anfänglichen Bereitstellung zusätzliche Inhaltsdatenbanken erstellt und einer Verfügbarkeitsgruppe hinzugefügt.

Verwenden Sie das Cmdlet Mount-SPContentDatabase, um die Inhaltsdatenbanken einzubinden.

Es wird empfohlen, die Websites in der SharePoint-Konfigurationsdatenbank zu aktualisieren. Verwenden Sie für jede Inhaltsdatenbank den folgenden Code, um die Websites in der Konfigurationsdatenbank zu aktualisieren. Dadurch wird sichergestellt, dass die Sitemap auf dem neuesten Stand ist.

# Refresh sites in the configuration database
Get-SPContentDatabase -WebApplication http://webapplicationsitename | | ForEach {

Write-host "Refreshing sites in configuration database for database: " $_.Name

$_.RefreshSitesInConfigurationDatabase()

}

Failoverschritt 4

Service Applications

Melden Sie sich als Mitglied der SharePoint-Gruppe der Farmadministratoren an, und führen Sie die folgenden Aufgaben aus:

1. Überprüfen Sie, ob auf die Dienstanwendungen zugegriffen werden kann.

2. Starten Sie den Benutzerprofil-Synchronisierungsdienst auf einem Server in der Notfallwiederherstellungsfarm.

3. Führen Sie einen vollständigen Import der Benutzerprofile aus.

Failoverschritt 5

Configure DNS Redirection

Aktualisieren Sie DNS, um die folgenden Umleitungen bereitzustellen:

• Zur Wiederherstellungsfarm für Webanwendungen und Websitesammlungen.

• Zur Wiederherstellungsfarm für die Anwendungsdomäne.

Failoverschritt 6

Validate the recovery

Führen Sie Testfälle in Ihrer Umgebung aus, um sicherzustellen, dass die Wiederherstellung wie erwartet erfolgt.

Nach der Überprüfung der Wiederherstellung:

• Aktivieren Sie den Zeitgeberauftrag für den Benutzerprofil-Synchronisierungsdienst.

• Planen Sie eine vollständige Sicherung der Wiederherstellungsfarm.

Failoverschritt 7

Send out notifications

Benachrichtigen Sie nach der Überprüfung der Wiederherstellung die entsprechenden Geschäftsbeteiligten.

Schlussbemerkung

Nachdem Sie das Failover ausgeführt und die Wiederherstellung überprüft haben, können Sie beginnen die Farm so zu konfigurieren, dass die aktuellen und zukünftigen Betriebsanforderungen, z. B. hinsichtlich Kapazität und hoher Verfügbarkeit, erfüllt werden. Diese Anforderungen werden durch die Dauer der Ausfallzeit und der Wiederherstellung der Farm im lokalen Datencenter bestimmt.

Abschließend müssen Sie Ihren Plan für die Rückkehr zur lokalen Farm überprüfen und auswerten, sobald sie wieder betriebsbereit ist.

Anhang

Appendix 1: Getting started in Microsoft Azure

See also

SharePoint Server 2016 in Microsoft Azure