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

GILT FÜR:  ja 2013  ja 2016  ja 2019  nein SharePoint in Microsoft 365

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

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

  • Microsoft Azure

SharePoint Server 2013

  • 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

SharePoint Server 2019 Enterprise

  • SQL Server 2016

  • SQL Server 2017

  • Windows Server 2016

  • Windows Server 2019

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.

Hinweis

Die Hinweise und Anweisungen für SharePoint Server 2016 in diesem Artikel gelten auch für SharePoint Server 2019.

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

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.

Hinweis

Ein verwandtes Ziel ist Recovery Level Objective (RLO, Zielsetzung für die Wiederherstellungsstufe). Diese Zielsetzung definiert die Granularität, mit der Sie Daten wiederherstellen können müssen. Dabei geht es darum, ob Sie die gesamte Farm, die Webanwendung, die Websitesammlung, die Website, die Liste oder Bibliothek oder das Element wiederherstellen können. Weitere Informationen finden Sie unter Planen der Sicherung und der Wiederherstellung in SharePoint Server.

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

Diese Abbildung zeigt die logische Architektur für die Hybridnotfallwiederherstellung für SharePoint Server 2013. Weitere Informationen finden Sie im folgenden Absatz.

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.

Hinweis

Alle Beschriftungen im Diagramm basieren auf der Namenskonvention, die wir beim Einrichten und Testen dieses Notfallwiederherstellungsszenarios verwendet haben. Sie bieten Referenzpunkte für den Artikel.

Abbildung 2: Lokale Produktionsfarm

Diese Abbildung zeigt die lokale Architektur für die Hybridnotfallwiederherstellung für SharePoint Server 2013. Weitere Informationen finden Sie im folgenden Absatz.

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

Abbildung 3: Bedingt betriebsbereite Wiederherstellungsfarm

In diesem Diagramm ist die detaillierte Wiederherstellungsarchitektur für die Hybridnotfallwiederherstellung für SharePoint Server 2013 für die Azure-Umgebung dargestellt. Weitere Informationen finden Sie im folgenden Absatz.

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.

Tipp

Verwenden Sie Automatisierung, wann immer es möglich ist. Skriptgestützte Bereitstellung und Konfiguration sorgt für eine konsistente Konfiguration und vermeidet Fehler beim Schreiben von Befehlen oder Navigieren durch die Benutzeroberfläche zum Konfigurieren der Farm.

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.

Komponente Einstellungen
Port
Blockieren Sie UDP-Port 1434.
Es wird empfohlen, TCP-Port 1433 zu blockieren und den von der Standardinstanz verwendeten Port einem anderen Port zuzuweisen. Dies ist jedoch nicht obligatorisch.
Stellen Sie sicher, dass die Portnummer, die der Standardinstanz zugewiesen werden soll, nicht zu den registrierten Ports gehört. Unter Registrierung von Dienstnamen und Transportprotokoll-Portnummern finden Sie Informationen dazu, wie Sie es vermeiden, den registrierten Port zu verwenden.
Befolgen Sie die Sicherheitshinweise unter Konfigurieren der SQL Server-Sicherheit für SharePoint Server.
Firewallregeln: Erstellen Sie neue eingehende Regeln für den von der SQL Server-Instanz verwendeten nichtstandardmäßigen Port.
Instanz ausblenden: Blenden Sie die SQL Server-Instanz auf Clientcomputern aus.
Seiten im Speicher sperren
Erteilen Sie dem SQL Server-Dienstkonto Berechtigungen zum Sperren von Seiten im Speicher. Weitere Informationen finden Sie unter Aktivieren der Option Sperren von Seiten im Speicher (Windows) und Serverkonfigurationsoptionen für den Serverarbeitsspeicher.
Automatisches Erstellen von Statistiken deaktivieren
Aktivieren Sie nicht das automatische Erstellen von Statistiken in SQL Server. Dies wird für SharePoint Server nicht unterstützt. Weitere Informationen finden Sie unter Bewährte Methoden für SQL Server in einer SharePoint Server-Farm.
Maximalen Grad an Parallelität festlegen
Legen Sie den maximalen Grad an Parallelität (MAXDOP) in SQL Server-Instanzen, die SharePoint Server-Datenbanken hosten, auf 1 fest.
Die Note: -SharePoint Server-Installation liefert in SQL Server entwurfsbedingt einen Fehler, wenn das Konto des Installers keine Berechtigung zum Ändern besitzt.
Weitere Informationen finden Sie unter Bewährte Methoden für SQL Server in einer SharePoint Server-Farm.
Ablaufverfolgungsflags
Fügen Sie die Ablaufverfolgungsflags 1222 (An einem Deadlock beteiligte Ressourcen und Sperrtypen zurückgeben) und 3226 (Protokollsicherungseinträge im SQL-Fehlerprotokoll unterdrücken) hinzu.
DBCC TRACEON (1222,-1)
DBCC TRACEON (3226,-1)
SQLAgent-Auftragsverlauf
Stellen Sie sicher, dass SQLAgent über diese Einstellungen verfügt (Jobhistory_max_rows = 50000 und Jobhistory_max_rows_per_job = 10000).
Minimaler Arbeitsspeicher
Min. Arbeitsspeicher = 512 MB. (Dies basiert jedoch auf unserer Testkonfiguration und gilt möglicherweise nicht für Ihre SQL Server-Installation. Sie sollten daher Ihren eigenen Bedarf berechnen.) Weitere Informationen finden Sie unter Serverkonfigurationsoptionen für den Serverarbeitsspeicher und Konfigurieren der Serverkonfigurationsoption Min. Arbeitsspeicher pro Abfrage.
Maximaler Arbeitsspeicher
Legen Sie das Limit für den maximalen Arbeitsspeicher für SQL Server nach folgender Formel fest:
Gesamter Serverarbeitsspeicher (GB) - 4 GB = [max. Serverarbeitsspeicher]
Weitere Informationen finden Sie unter Serverkonfigurationsoptionen für den Serverarbeitsspeicher.
DNS-Aliase
Es wird empfohlen, DNS-Aliase für alle SQL Server-Instanzen zu erstellen. Dies erleichtert die Wartung, z. B. die Verlagerung von Datenbanken auf einen anderen Server. Beispiel: Die SharePoint-Farm im Azure-Notfallwiederherstellungs-Datencenter stellt direkt eine Verbindung mit den SQL Server-Instanznamen her. Sie sollten einen DNS-Alias erstellen, statt die Farm direkt mit den Instanznamen zu konfigurieren.
Hinweis: Der Clientalias und der DNS-Alias sollten übereinstimmen, damit auch Clients, die keine SQL-Clientaliase verwenden, eine Verbindung mit SQL-Servern herstellen können.
Weitere Informationen finden Sie unter Bewährte Methoden für SQL Server in einer SharePoint Server-Farm.
Datenbanksortierung
Latin1_General_Cl_AS_KS_WS
Die SQL Server-Datenbanksortierung muss ohne Unterscheidung von Groß-/Kleinschreibung, mit Unterscheidung nach Akzent, mit Unterscheidung nach Kana und mit Unterscheidung nach Breite konfiguriert sein. Dadurch werden eindeutige Dateinamen sichergestellt, die mit dem Windows-Betriebssystem konsistent sind.

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:

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

Diese Abbildung zeigt die Verteilung von SharePoint-Datenbanken in den AlwaysOn-Verfügbarkeitsgruppen.  Weitere Informationen finden Sie im folgenden Absatz.

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).

Failovertyp Synchroner Commitmodus mit automatischem Failovermodus Synchroner Commitmodus mit manuellem Failovermodus Asynchroner Commitmodus
Automatic failover
Ja
Nein
Nein
Planned manual failover
Ja
Ja
Nein
Forced failover
Ja (1)
Ja
Ja

(1) 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.

Datenbankname Hohe Verfügbarkeit (Synchrone Unterstützung) Notfallwiederherstellung (Asynchrone Unterstützung)
SharePoint Config
Ja
Nein
SharePoint Admin Content
Ja
Nein
State Service
Ja
Nein
WSS Content X
Ja
Ja

Die folgende Tabelle enthält die Datenbanken der SharePoint-Dienstanwendung.

Datenbankname Hohe Verfügbarkeit (Synchrone Unterstützung) Notfallwiederherstellung (Asynchrone Unterstützung)
App Management
Ja
Ja
Business Connectivity Services
Ja
Ja
Managed Metadata
Ja
Ja
PerformancePoint
Ja
Ja
PowerPivot
Ja
Ja
Project (nur SharePoint Server 2013)
Ja
Ja
Secure Store
Ja
Ja
Subscription Settings
Ja
Ja
Machine Translation Services
Ja
Ja
UPS Profile
Ja
Ja
UPS Social
Ja
Ja
UPS Sync
Ja
Nein
Verwendung
Ja
Nein
Word Automation
Ja
Ja

Die folgende Tabelle enthält die Datenbanken der SharePoint-Suche.

Datenbankname Hohe Verfügbarkeit (Synchrone Unterstützung) Notfallwiederherstellung (Asynchrone Unterstützung)
Search Admin
Ja
Nein
Search Crawl
Ja
Nein
Search Link Store
Ja
Nein
Search Analytics Store
Ja
Nein

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.

Infrastrukturkomponente Hinweise
Domänencontroller
Für die lokale Testumgebung haben wir einen Domänencontroller bereitgestellt und die Domäne corp.adventureworks.com erstellt. Wenn Sie ein Proof-of-Concept-Notfallwiederherstellungsszenario ausführen möchten, können Sie den Domänennamen Ihrer Organisation verwenden.
Note: Nach dem Konfigurieren der Domäne haben wir auch alle VMs bereitgestellt, die wir für die Farm verwenden möchten. Das Betriebssystem wurde auf dieselbe Ebene gepatcht. Dies erleichtert die Verwaltung gegenüber einem schrittweisen Ansatz.
Windows Server 2012 R2- und Windows Server 2016-Failoverclustering
Windows Server 2012 R2 oder Windows Server 2016 auf jede Farmserver, konfiguriert entsprechend bewährten Methoden (Windows Server und SharePoint Server). Weitere Informationen finden Sie unter Windows Server-Failoverclustering (WSFC) mit SQL Server.
Auf jedem Server, der einem Clusterknoten angehören soll, müssen das Feature Failovercluster und die Failoverclusterverwaltungs-MMC installiert sein.
Eine Dateifreigabe für das WSFC-Quorum. Laut einer bewährten Methode sollte dies auf einer dritten Website konfiguriert sein, auf die durch die lokale Website und durch die Wiederherstellungswebsite zugegriffen werden kann.
Dokumentieren und befolgen Sie eine einheitliche Namenskonvention für den Cluster.
SQL Server-Datenbankkonfiguration und AlwaysOn-Verfügbarkeitsgruppen
SQL Server 2014 oder SQL Server 2016, konfiguriert nach SharePoint-Anforderungen und den unter „Abhängigkeiten, Voraussetzungen und bewährte Methoden" beschriebenen bewährten Methoden.
Datenbanken verwenden das vollständige Wiederherstellungsmodell. Weitere Informationen finden Sie unter Wiederherstellungsmodelle (SQL Server).
SQL Server-Instanznamen. (Wir haben den Standardinstanznamen verwendet, der in diesem Entwurf für alle Clusterknoten unterstützt wird).
Identische Dateipfade für die Speicherorte der Datenbanken und Protokolldateien jeder SQL Server-Instanz. Folgende Laufwerklayouts wurden verwendet: (System (L:) für SQL-Datenbanken und SharePoint-Datenbanken), (Benutzer (S:) für tempdb-Datenbanken und Protokolldateien), und (Lokales Laufwerk (T:) für SharePoint SQL-Sicherungen).
Dokumentieren und befolgen Sie eine einheitliche Namenskonvention für die Verfügbarkeitsgruppen, Replikate und Listener.
Netzwerk
Clusterknoten – Drei statische IP-Adressen für IP-Cluster (zwei für die lokale Farm und eine für die Wiederherstellungsfarm).
Verfügbarkeitsgruppenlistener – Eine statische IP-Adresse für jeden Listener. (Die Testfarm verwendet vier Listener.)
Microsoft Azure-Gatewayserver
Ein Server in Azure, der den Endpunkt für die VPN-Gatewayverbindung von der lokalen Farm bereitstellt. Er ist mit den Rollen Active Directory-Domänendienste (AD DS) und DNS-Dienste konfiguriert und soll als globaler Katalogserver für die Testdomäne (corp.adventureworks.com) dienen.
Bei einem Notfall kann dieser Server zum primären Domänencontroller werden.
VPN-Gateway
Ein Site-to-Site-VPN oder ExpressRoute, konfiguriert zwischen dem primären Datencenter und dem Windows Azure-Abonnement, in dem die Notfallwiederherstellungsfarm konfiguriert wird.
Weitere Informationen finden Sie unter Erstellen eines VNet mit einer Standort-zu-Standort-Verbindung über das klassische Portal (klassisch) und Erstellen und Ändern einer ExpressRoute-Verbindung mit PowerShell (klassisch).

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

Diese Abbildung zeigt die Schritte der Erstellungsphase 1, um WSFC und AlwaysOn für die lokale Farm zu konfigurieren.

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

Schritt Hinweise und Anleitungen
1. Konfigurieren eines WSFC-Clusters mit zwei Knoten
Erstellen Sie anhand des Windows Server-Artikels Erstellen eines Failoverclusters einen Cluster mit zwei Knoten. Weitere Informationen zu Windows Server 2016 finden Sie unter Failover-Clusterunterstützung in Windows Server 2016.
2. Konfigurieren eines Dateifreigabenzeugen
Die bevorzugte Konfiguration für WSFC in einer SharePoint-Umgebung besteht in der Verwendung eines Dateifreigabenzeugen und einer Knotenmehrheit. Beide Clusterknoten in der lokalen Farm haben eine Quorumsstimme. Der Clusterknoten in der Wiederherstellungsfarm hat keine Stimme.
Weitere Informationen finden Sie unter Konfigurieren und Verwalten des Quorums in einem Windows Server 2012-Failovercluster. Weitere Informationen zu Windows Server 2016 finden Sie unter Bereitstellen eines Cloudzeugen für einen Failovercluster.
Verwenden Sie das folgende Microsoft PowerShell-Cmdlet zum Konfigurieren einer Dateifreigabe und eines Knotenmehrheitsquorums:
Set-ClusterQuorum -NodeAndFileShareMajority "\\fileserver\share"
Verwenden Sie das folgende PowerShell-Cmdlet, um Stimmen zuzuweisen:
(Get-ClusterNode {CLUSTERNODENAME}).NodeWeight=1
Verwenden Sie folgende PowerShell-Syntax, um einen Cloudzeugen zu konfigurieren:
Set-ClusterQuorum -CloudWitness -AccountName <StorageAccountName> -AccessKey <StorageAccountAccessKey>
3. Installieren von SQL Server auf jedem Windows-Clusterknoten
Installieren Sie SQL Server auf beiden Windows Server-Clusterknoten. Beachten Sie Folgendes:
Do not Führen Sie das SQL Server-Setupprogramm für einen Failovercluster aus. Diese Knoten sind nicht Teil eines SQL-Failoverclusterinstanz-(FCI)-Clusters.
Stellen Sie sicher, dass die SQL Server-Datenpfade für alle Instanzen identisch sind.
Weitere Informationen finden Sie unter Installieren von SQL Server 2014 vom Installations-Assistenten aus (Setup) oder Installieren von SQL Server 2014 von der Eingabeaufforderung. Siehe auch Installieren von SQL Server über den Installations-Assistenten (Setup).
4. Aktivieren von SQL Server-AlwaysOn
Verwenden Sie die Anleitung in Aktivieren und Deaktivieren von AlwaysOn-Verfügbarkeitsgruppen (SQL Server), um AlwaysOn zu aktivieren. Verwenden Sie die Anleitung für SQL Server 2016 unter Aktivieren und Deaktivieren von AlwaysOn-Verfügbarkeitsgruppen (SQL Server).
Der Abschnitt zur Datenbankgruppierung nach dieser Tabelle zeigt, wie Sie SharePoint-Datenbanken logisch gruppieren und verschiedenen Verfügbarkeitsgruppen zuordnen können, um sowohl Ihre Anforderungen an die Notfallwiederherstellung als auch Ihre Anforderungen an hohe Verfügbarkeit zu erfüllen.
5. Konfigurieren der Farmkontosicherheit
Konfigurieren Sie die entsprechenden Berechtigungen in den einzelnen SQL Server-Instanzen für das Administratorkonto des SharePoint-Setupbenutzers. Dieses Konto muss während der Einrichtung und Konfiguration ein Mitglied der db_owner -Rolle und den SQL Server-Sicherheitsrollen securityadmin und dbcreator zugewiesen sein.
Weitere Informationen finden Sie unter Konfigurieren der SQL Server-Sicherheit für SharePoint Server und Kontoberechtigungen und Sicherheitseinstellungen in SharePoint Server 2016.
6. Erstellen von Verfügbarkeitsgruppen, AlwaysOn-Endpunkten und Verfügbarkeitsgruppenlistenern
Erstellen Sie die Verfügbarkeitsgruppen für den synchronen Commitmodus, um hohe Verfügbarkeit sicherzustellen. (Es ist üblich, die Verfügbarkeitsgruppen logisch für das logische Failover von Datenbanken zu konfigurieren). Nachdem Sie die AlwaysOn-Endpunkte erstellt haben, erstellen Sie Verfügbarkeitsgruppenlistener, um Clientkonnektivität zu den einzelnen Verfügbarkeitsgruppen zu ermöglichen.
Note: Sie können die Verfügbarkeitsgruppen mit temporären Datenbanknamen erstellen, damit SharePoint die Listener verwenden kann, wenn die Farm konfiguriert ist. Dies ist der Fall, da die Datenbank-Verbindungszeichenfolgen auf die entsprechenden, von den Listenern erstellten DNS-Einträge verweisen. So müssen Sie die Listener nicht erneut konfigurieren.
Weitere Informationen finden Sie unter Konfigurieren von SQL Server-AlwaysOn-Verfügbarkeitsgruppen für SharePoint Server
Weitere Informationen finden Sie unter Erstellen eines Datenbankspiegelungs-Endpunkts für AlwaysOn-Verfügbarkeitsgruppen (SQL Server PowerShell). Weitere Informationen zu SQL Server 2016 finden Sie unter Datenbankspiegelung- Always On-Verfügbarkeitsgruppe - PowerShell.
Weitere Informationen finden Sie unter Verfügbarkeitsgruppenlistener, Clientkonnektivität und Anwendungsfailover (SQL Server). Weitere Informationen zu SQL Server 2016 hierzu finden Sie unter Listener, Clientkonnektivität, Anwendungsfailover.
Note: Wenn Sie die Verfügbarkeitsgruppenlistener mit SQL Server Management Studio erstellen, müssen Sie für jeden Listener eine IP-Adresse für das Notfallwiederherstellungssubnetz hinzufügen. Dies ist nicht erforderlich, wenn Sie die Verfügbarkeitsgruppenlistener mit dem SQL Server New-SqlAvailabilityGroupListener-Cmdlet PowerShell erstellen. Die Wiederherstellungsfarm verweist auf die SQL-Instanzen über DNS-Hosteinträge (A) und nicht über die Verfügbarkeitsgruppenlistener. Weitere Informationen finden Sie unter New-SqlAvailabilityGroupListener.

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.

Name der Verfügbarkeitsgruppe SharePoint-Datenbanken
AG_SPConfig (1)
SharePoint-Konfiguration, SharePoint-Verwaltungsinhalt, Statusdienst und UPS-Synchronisierung (nur AG Synchron)
AG_SPContent
WSS-Inhalt X
AG_SPServices
App-Verwaltung, Business Connectivity Services, verwaltete Metadaten, PerformancePoint, PowerPivot, Secure Store Service, Abonnementeinstellungen, Maschinelle Übersetzungsdienste, UPS-Profil und UPS Social, Word Automation und Nutzung (Diese Datenbank unterstützt nur synchronen Commit, und da sie vorübergehende Daten enthält, die für Datamining verwendet werden, wird die Replikation dieser Daten in einem Notfallwiederherstellungsszenario nicht empfohlen.) (2)
AG_SPSearch
Suchadministratoren, Suchdurchforstung, Suchlink und Suchanalysebericht

(1) Diese Namen sind nur Beispiele. Sie können Ihre eigene Benennungskonvention verwenden.

(2) 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.

Servername Beschreibung
DC2
Domänencontroller
SP-WFE1, SP-WFE2
Webinhaltsserver
SP-APP1 bis SP-APP6 (einschließlich)
Anwendungsserver (z. B. Zentraladministration, Dienste und Suche)
SP-SQL-HA1, SP-SQL-HA2
Diese Server sind als zwei Knoten in unserem WSFC-Cluster (SPDRCluster) konfiguriert, jeder mit einer Stimme. Hosten die Farmdatenbanken, konfiguriert mit AlwaysOn-Verfügbarkeitsgruppen. SP-SQL-HA1 hat die Rolle des primären Replikats und SP-SQL-HA2 die Rolle des sekundären Replikats. Diese Verfügbarkeitsgruppen und Listener sind wie folgt konfiguriert: Availability groups = PROD-AG1, PROD-AG2, PROD-AG3, PROD-AG4; Listeners = SQL-PROD-AG1, SQL-PROD-AG2, SQL-PROD-AG3, SQL-PROD-AG4
FS1
Dieser Server stellt das Dateifreigabecluster-Quorum (Hybrid5SPDRClusterQuorum) für den WSFC-Cluster bereit. Er wird auch als freigegebener Verteilungs-Softwarepunkt für die Testfarm verwendet.
OP-FILESERVER (optional)
Dieser Server stellt einen DFSR-Dienstendpunkt (Distributed File System Replication) für die lokale Umgebung bereit. Der andere Endpunkt befindet sich in unserer Azure-Umgebung. DFSR dient zwei Zwecken. Erstens wird es zum Speichern von SQL Server-Sicherungen (inkrementelle und vollständige) verwendet, die auf einen Server (AZSP-FS1) in Azure geschrieben werden. Dadurch haben wir die externe Speicherung simuliert, und in einem Notfallszenario können wir aus diesen Sicherungen die SharePoint-Suche wiederherstellen. Darüber hinaus ermöglicht die DFSR-Konfiguration ein relativ einfaches Verschieben von Dateien zwischen den beiden Farmen.

Erstellungsphase 2

Diese Abbildung zeigt die Schritte der Erstellungsphase 2, um SharePoint Server bereitzustellen und die lokale Farm zu erstellen.

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

Schritt Hinweise und Anleitungen
1. Erstellen von Buildskripts
Es wird empfohlen, eine Reihe von Buildskripts für die Installation von SharePoint Server 2016 zu entwickeln. Diese Skripts können auch verwendet werden, um die Wiederherstellungsfarm (und zukünftige SharePoint-Farmen) zu erstellen. Da die Wiederherstellungsfarm die gleichen Dienstanwendungen wie die lokale Farm verwenden wird, ist es eine bewährte Methode, identische Dienstanwendungs- und Datenbanknamen zu verwenden. Skripts verringern die Wahrscheinlichkeit von Konfigurationsfehlern und stellen die Konsistenz in der Farmkonfiguration sicher.
Note: Dienstanwendungen verweisen auf die zugehörigen Datenbanken über den Datenbanknamen, während die Inhaltsdatenbanken auch eine Datenbank-ID aufweisen, die in der SharePoint-Konfigurationsdatenbank gespeichert ist.
Es gibt mehrere Beispiele für skriptbasierte SharePoint-Installationen, die Sie in Ihrer Umgebung nutzen können. So ist beispielsweise SharePointDsc oder AutoSPInstaller ein End-to-End-Open-Source-Programm, das auf Codeplex verfügbar ist.
Stellen Sie sicher, dass die Farmkonfigurationsdatenbank, die Inhaltsdatenbanken und die Dienstanwendungsdatenbanken auf den DNS-Alias der SQL Server-Instanz verweisen, die Sie verwenden. Die SharePoint Server 2016-Datenbanken werden mit einer Verbindungszeichenfolge erstellt, die der SQL Server-Instanz zugeordnet ist. Sie werden später mithilfe von SharePoint ServerPowerShell-Cmdlets in Verfügbarkeitsgruppen verschoben.
Nachdem Sie die Farmkonfigurationsdatenbanken erstellt haben, wird empfohlen, Skripts für die folgenden allgemeinen Aufgaben zu erstellen:
Zuweisen eines SharePoint Server zu der Farm mithilfe des Cmdlets Join-SharePointFarm
Registrieren verwalteter Konten mithilfe des Cmdlets New-SPManagedAccount
Erstellen von Webanwendungen
Erstellen von Websitesammlungen
Erstellen von Dienstanwendungen
Festlegen von SharePoint-App-Domäne und -Präfix
2. Installieren der erforderlichen Komponenten und Binärdateien
Weitere Informationen finden Sie unter Installieren von erforderlichen Komponenten für SharePoint Server 2016 von einer Netzwerkfreigabe.
3. Konfigurieren von Farm-SMTP-Einstellungen, Web Apps und Websitesammlungen
Verwenden Sie das Cmdlet New-SPWebApplication, um Webanwendungen zu erstellen, und verwenden Sie das Cmdlet New-SPSite, um Websitesammlungen zu erstellen.
4. Konfigurieren von Dienstanwendungen
Verwenden Sie die Dienstanwendungs-Cmdlets in Index of Windows PowerShell cmdlets for SharePoint Server 2016, um Dienstanwendungen zu konfigurieren.
5. Hinzufügen der Datenbanken der lokalen Produktionsfarm zu Verfügbarkeitsgruppen und Synchronisieren der Replikate
Wenn Sie die Konfiguration der Farm abgeschlossen haben, fügen Sie die Farmdatenbanken den entsprechenden Verfügbarkeitsgruppen hinzu. Verwenden Sie die folgenden PowerShell-Cmdlets zum Hinzufügen der Datenbanken, und überprüfen Sie, ob sie der angegebenen Verfügbarkeitsgruppe hinzugefügt wurden: Add-DatabasetoAvailabilityGroup und Get-AvailabilityGroupStatus
Important: Stellen Sie sicher, dass Sie das vollständige Wiederherstellungsmodell für alle Datenbanken aktiviert haben, die einer Verfügbarkeitsgruppe hinzugefügt werden sollen, bevor Sie sie hinzufügen.
Nachdem Sie die Farmkonfigurationsdatenbank einer Verfügbarkeitsgruppe hinzugefügt haben, müssen Sie alle Server in der Farm neu starten, um die Stabilität der Farm sicherzustellen.
Synchronisieren Sie die Verfügbarkeitsgruppenreplikate. Weitere Informationen finden Sie unter Seite „Anfängliche Datensynchronisierung auswählen“ (AlwaysOn-Verfügbarkeitsgruppen-Assistenten).

Erstellungsphase 3

Diese Abbildung zeigt die Schritte der Erstellungsphase 3, um WSFC und SQL Server in der Wiederherstellungsumgebung zu konfigurieren.

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

Schritt Hinweise und Anleitungen
1. Hinzufügen zweier Knoten zum Azure-Notfallwiederherstellungs-Datencenter zum Erweitern des lokalen WSFC-Clusters
Konfigurieren Sie diese Einstellungen auf dem Server, der der neue Clusterknoten werden soll. Installieren Sie das Feature für Windows-Failoverclustering, testen Sie den Cluster und entfernen Sie dann die Quorumsstimme vom neuen Knoten.
Öffnen Sie die Windows PowerShell-Befehlszeile als Administrator, und führen Sie das folgende Cmdlet aus, um das Feature für das Windows-Failoverclustering und die Verwaltungstools zu installieren: Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools
Testen Sie den Cluster mit dem folgenden Cmdlet: Test-Cluster
Entfernen Sie mit folgenden Befehlen die Quorumsstimme vom Server: (Get-ClusterNode {CLUSTERNODENAME}).NodeWeight=0
Weitere Informationen finden Sie unter Konfigurieren und Verwalten des Quorums in einem Windows Server 2012-Failovercluster. Weitere Informationen zu Windows Server 2016 finden Sie unter Bereitstellen eines Cloudzeugen für einen Failovercluster.
Note: Wenn Sie die gleiche Architektur wie unsere Testumgebung verwenden, müssen Sie diese Konfigurationsschritte auf beiden SQL Server-Instanzen in der Wiederherstellungsumgebung ausführen.
2. Installieren der SQL Server-Instanzen
Installieren Sie SQL Server auf beiden Knoten. Stellen Sie sicher, dass die Datenpfade für jede SQL-Instanz identisch und die Konfigurationen, z. B. Portkonfigurationen, Datenbanksortierung usw., gleich sind. Weitere Informationen finden Sie unter Installieren von SQL Server 2012 vom Installations-Assistenten aus (Setup). Siehe auch Installieren von SQL Server über den Installations-Assistenten (Setup).
3. Aktivieren von SQL Server-AlwaysOn-Verfügbarkeitsgruppen
Verwenden Sie den SQL Server-Konfigurations-Manager, um SQL Server AlwaysOn-Verfügbarkeitsgruppen zu aktivieren. Weitere Informationen finden Sie unter Aktivieren und Deaktivieren von AlwaysOn-Verfügbarkeitsgruppen (SQL Server). Eine Anleitung für SQL Server 2016 finden Sie unter Aktivieren und Deaktivieren von AlwaysOn-Verfügbarkeitsgruppen (SQL Server).
In der Tabelle unter Erstellungsphase 1 finden Sie Beispiele für die logische Gruppierung von SharePoint Server 2016-Datenbanken in Verfügbarkeitsgruppen.
4. Konfigurieren der Farmkontosicherheit
Konfigurieren Sie die entsprechenden Berechtigungen in den einzelnen SQL Server-Instanzen für das Administratorkonto des SharePoint-Setupbenutzers. Dieses Konto muss während der Einrichtung und Konfiguration ein Mitglied der db_owner -Rolle und den SQL Server-Sicherheitsrollen securityadmin und dbcreator zugewiesen sein.
Weitere Informationen finden Sie unter Konfigurieren von SQL Server-Sicherheit für SharePoint Server, Kontoberechtigungen und Sicherheitseinstellungen in SharePoint Server 2016 und Kontoberechtigungen und Sicherheitseinstellungen in SharePoint 2013.

Erstellungsphase 4

Diese Abbildung zeigt die Schritte der Erstellungsphase 4, um SharePoint in Azure bereitzustellen und die Wiederherstellungsfarm zu erstellen.

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

Schritt Hinweise und Anleitungen
1. Erstellen von Buildskripts
Es wird empfohlen, eine Reihe von Buildskripts für die Installation von SharePoint Server zu entwickeln. Diese Skripts können auch verwendet werden, um die Wiederherstellungsfarm (und zukünftige SharePoint-Farmen) zu erstellen. Da die Wiederherstellungsfarm die gleichen Dienstanwendungen wie die lokale Farm verwenden wird, ist es eine bewährte Methode, identische Dienstanwendungs- und Datenbanknamen zu verwenden. Skripts verringern die Wahrscheinlichkeit von Konfigurationsfehlern und stellen die Konsistenz in der Farmkonfiguration sicher.
Note: Dienstanwendungen verweisen auf die zugehörigen Datenbanken über den Datenbanknamen, während die Inhaltsdatenbanken auch eine Datenbank-ID aufweisen, die in der SharePoint-Konfigurationsdatenbank gespeichert ist.
Es gibt mehrere Beispiele für skriptbasierte SharePoint-Installationen mit PowerShell. So ist beispielsweise SharePointDsc oder AutoSPInstaller ein End-to-End-Open-Source-Programm, das auf Codeplex verfügbar ist.
Stellen Sie sicher, dass die Farmkonfigurationsdatenbank, die Inhaltsdatenbanken und die Dienstanwendungsdatenbanken auf den DNS-Alias der SQL Server-Instanz verweisen, die Sie verwenden. Die SharePoint Server-Datenbanken werden mit einer Verbindungszeichenfolge erstellt, die der SQL Server-Instanz zugeordnet ist. Sie werden später mithilfe von SharePoint PowerShell-Cmdlets in Verfügbarkeitsgruppen verschoben.
Nachdem Sie die Farmkonfigurationsdatenbanken erstellt haben, wird empfohlen, Skripts für die folgenden allgemeinen Aufgaben zu erstellen:
Weisen Sie der Farm einen SharePoint Server mithilfe des Cmdlets Join-SharePointFarm zu. Registrieren Sie verwaltete Konten mithilfe des Cmdlets New-SPManagedAccount. Erstellen Sie Webanwendungen, Websitesammlungen und Dienstanwendungen. Legen Sie schließlich die Domäne und das Präfix der SharePoint-App fest.
2. Installieren der erforderlichen Komponenten und Binärdateien
Weitere Informationen finden Sie unter Installieren von erforderlichen Komponenten für SharePoint Server 2016 von einer Netzwerkfreigabe.
3. Konfigurieren von Farm-SMTP-Einstellungen, Webanwendungen und Websitesammlungen
Verwenden Sie das Cmdlet New-SPWebApplication, um Webanwendungen zu erstellen, und verwenden Sie das Cmdlet New-SPSite, um Websitesammlungen zu erstellen.
4. Konfigurieren von Dienstanwendungen
Verwenden Sie die Dienstanwendungs-Cmdlets in Index of Windows PowerShell cmdlets for SharePoint Server 2016, um Dienstanwendungen zu konfigurieren.
Note: Dienstanwendungen werden in der Notfallwiederherstellungsfarm mit genau denselben Namen wie in der primären Farm erstellt. Stellen Sie sicher, dass die Datenbanken ebenfalls genau wie in der primären Farm benannt sind, da auf die Datenbank durch die Dienstanwendungen in der Notfallwiederherstellungsfarm verwiesen wird, in der die Dienstanwendungsdatenbanken schließlich als Replikate erstellt werden. Im Rahmen des Prozesses werden die Datenbanken in der Notfallwiederherstellungsfarm aus den primären Replikaten wiederhergestellt, wenn die asynchronen Replikate zur SQL-Verfügbarkeitsgruppe hinzugefügt werden.
Die Inhaltsdatenbanken in der Notfallwiederherstellungsfarm können aus der SharePoint-Konfiguration entfernt werden, da für die Inhaltsdatenbanken der primären Farm ein schreibgeschütztes Replikat in der SQL Server-Instanz für die Notfallwiederherstellung verfügbar ist.
Verwenden Sie die SharePoint 2016-Verwaltungsshell zum Ausführen des folgenden PowerShell Cmdlets, um die Einbindung aller Inhaltsdatenbanken in der Notfallwiederherstellungsfarm aufzuheben: Remove-SPContentDatabase.
Wenn weitere Inhaltsdatenbanken in den SQL Server-Instanzen in der Notfallwiederherstellungsfarm vorhanden sind, löschen Sie sie alle. Sie können eine der folgenden Methoden verwenden: DROP DATABASE (Transact-SQL), Database.Drop-Methode () oder Löschen einer Datenbank.
5. Herunterfahren der Farm
Fahren Sie die Farm nach dem Beenden der SharePoint-Konfiguration herunter. Jetzt können Sie asynchrone Replikate für die Datenbanken in der lokalen Farm erstellen.

Erstellungsphase 5

Diese Abbildung zeigt die Schritte der Erstellungsphase 5, um die Konfiguration des Azure-Endpunkts abzuschließen und die Datenbanken in der Wiederherstellungsfarm zu replizieren.

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

Schritt Hinweise und Anleitungen
1. Stellen Sie sicher, dass die SQL-Instanz auf die Datenbank und die Sicherungsfreigaben zugreifen kann.
Jeder Knoten in einer Verfügbarkeitsgruppe muss Zugriff auf einen gemeinsamen Sicherungsspeicherort haben. Dies ist für das anfängliche Datenbankseeding beim Hinzufügen von Replikaten zur Verfügbarkeitsgruppe erforderlich.
Das SQL Server-Konto muss Zugriff auf den gemeinsamen Sicherungsspeicherort besitzen.
2. Erstellen Sie einen SQL Server-Endpunkt, und erteilen Sie Berechtigungen zum Herstellen einer Verbindung mit dem Endpunkt.
Sie müssen eine Anmeldung für die SQL Server-Instanz für die Notfallwiederherstellung erstellen, um ein sekundäres Replikat zu erstellen und die Datenbanken den Verfügbarkeitsgruppen zuzuweisen. Weitere Informationen finden Sie unter Einrichten von Anmeldekonten für die Datenbankspiegelung oder AlwaysOn-Verfügbarkeitsgruppen (SQL Server) und Einrichten von Anmeldekonten: Datenbankspiegelung von Always On-Verfügbarkeit.
Ein SQL Server-Endpunkt wird auf dem primären Replikat benötigt, damit die SQL-Instanz Protokollpuffer an die sekundären Replikate senden kann. Verwenden Sie den Prozess unter Erstellen eines Datenbankspiegelungs-Endpunkts für AlwaysOn-Verfügbarkeitsgruppen (SQL Server PowerShell) und Datenbankspiegelung - Always On-Verfügbarkeitsgruppe - PowerShell, um den Endpunkt zu erstellen.
Sie müssen dem Dienstkonto auf der primären SQL Server-Instanz Zugriff auf den Endpunkt gewähren, um Protokollpuffer an Notfallwiederherstellungsinstanzen zu übertragen. Die CONNECT-Berechtigung ist erforderlich.
Weitere Informationen finden Sie unter Gewähren von Endpunktberechtigungen (Transact-SQL).
3. Erstellen Sie sekundäre Replikate der Benutzerinhalts- und Dienstanwendungsdatenbanken in der Wiederherstellungsfarminstanz.
Jede Verfügbarkeitsgruppe erfordert ein sekundäres Replikat in der Notfallwiederherstellungsfarm. Sie müssen mit der SQL-Instanz verbunden sein, die das primäre Replikat hostet, damit Sie das sekundäre Replikat erstellen können.
Weitere Informationen finden Sie unter Hinzufügen eines sekundären Replikats zu einer Verfügbarkeitsgruppe (SQL Server).
4. Stellen Sie sicher, dass die Replikate in der Wiederherstellungsfarm für schreibgeschützten Zugriff konfiguriert sind.
Die Verfügbarkeitsreplikate in den SQL Server-Instanzen für die Notfallwiederherstellung werden als lesbare sekundäre Replikate konfiguriert. Die Notfallwiederherstellungsfarm greift auf die Dienstanwendung und die Inhaltsdatenbanken im schreibgeschützten Modus zu. Dies liegt daran, dass die Wiederherstellungsfarm bereits auf die Datenbanknamen der Dienstanwendung verweist. Dadurch wird die Recovery Time Objective (RTO) beim Failover in die Notfallwiederherstellungsumgebung reduziert.
Hinweis: Wenn dies nicht ordnungsgemäß konfiguriert ist, können Fehler in der Wiederherstellungsumgebung auftreten.
Weitere Informationen finden Sie unter Konfigurieren des schreibgeschützten Routing für eine Verfügbarkeitsgruppe (SQL Server) und Konfigurieren des schreibgeschützten Zugriffs auf ein Verfügbarkeitsreplikat (SQL Server).
5. Kopieren Sie Anmeldungen aus der primären SQL Server-Instanz in die sekundären SQL Server-Instanzen.
Sie müssen SQL-Benutzernamen und Kennwörter aus der primären Instanz in die sekundären Instanzen kopieren. SQL Server kopiert nur die Inhalte einer Verfügbarkeitsgruppen-Datenbank . Benutzernamen und Kennwörter werden nicht von einer Instanz in eine andere kopiert.
Weitere Informationen finden Sie unter Übertragen von Benutzernamen und Kennwörtern zwischen Instanzen von SQL Server und Problembehandlung bei verwaisten Benutzern (SQL Server).

Erstellungsphase 6

Diese Abbildung zeigt die Schritte der Erstellungsphase 6, um die Konfiguration von SharePoint für die Wiederherstellungsfarm abzuschließen.

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

Schritt Hinweise und Anleitungen
1. Einschalten der Wiederherstellungsfarm
Nachdem nun die Dienstanwendung und die Inhaltsdatenbanken im schreibgeschützten Modus in SQL Server-Instanzen der Wiederherstellungsfarm verfügbar sind, können Sie die SharePoint-Farm einschalten.
2. Einbinden der Inhaltsdatenbanken für die Webanwendung(en)
Für jede Inhaltsdatenbank, die über ein schreibgeschütztes Replikat in der SQL-Instanz für die Notfallwiederherstellung verfügt, das den neuesten Inhalt in der primären Farm enthält, muss die Datenbank in den entsprechenden Webanwendungen in der Notfallwiederherstellungsfarm eingebunden werden. Mithilfe des Cmdlets Mount-SPContentDatabase können Sie die Inhaltsdatenbanken einbinden.
3. Aktualisieren von Websites in der Konfigurationsdatenbank
Es wird empfohlen, die Websites in der SharePoint-Konfigurationsdatenbank zu aktualisieren. Verwenden Sie das im (1) -Hinweis gezeigte PowerShell-Beispiel nach dieser Tabelle, um die Websites für jede Inhaltsdatenbank zu aktualisieren.
4. Überprüfen der Farmdienste
Stellen Sie sicher, dass alle Farmdienste wie erwartet ausgeführt werden.
5. Ausführen einer Integritätsprüfung für die Farm
Führen Sie Integritätsprüfungen in der Farm aus, um sicherzustellen, dass die Farm stabil und ordnungsgemäß funktioniert.

(1) Verwenden Sie die folgende PowerShell-Syntax für Schritt 3 in der Tabelle zur 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, indem Sie Stop-Service Clussvc ausführen.

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

Start-ClusterNode -Name <ACTIVE SQL NODE> -FixQuorum
  1. 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>
  1. Bestätigen Sie mit dem folgenden Befehl, dass der Clusterdienst gestartet wurde.
Get-ClusterNode -Name "<NodeName>"
  1. 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
  1. 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
  1. Verwenden Sie den folgenden Befehl, um die Gewichtungseinstellungen der Knoten zu überprüfen.
Get-ClusterNode | fl Name,NodeWeight
  1. 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
  1. 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.

Wichtig

Es ist im Rahmen eines Betriebsprozesses sehr wichtig, dass alle in der primären Farm erstellten Inhaltsdatenbanken den Verfügbarkeitsgruppen hinzugefügt und in der Notfallwiederherstellungsfarm eingebunden werden.

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.

Hinweis

Möglicherweise erfordert der Secure Store Service, dass der SharePoint-Farmadministrator den Schlüssel aktualisiert, damit die im Secure Store registrierten Anwendungen entschlüsselt werden können. Der Administrator muss zum Aktualisieren des Schlüssels über Vollzugriff auf den Secure Store verfügen. Sie können auch das Cmdlet Update-SPSecureStoreApplicationServerKey zum Aktualisieren des Secure Store-Schlüssels verwenden.

Hinweis

Der Zeitgeberauftrag für die Benutzerprofilsynchronisierung muss erneut aktiviert werden, und Profilimporte sollten geplant werden. Da sich die Datenbanken nach einem Failover jetzt im Schreibmodus befinden, sollten die Importe entsprechend geplant werden.

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

Element Hinweise
Azure-Abonnements und Speicherkonten
Sie benötigen mindestens ein Abonnement, um die Azure-Wiederherstellungsfarm zu erstellen. Sobald Sie ein Abonnement besitzen, können Sie bis zu 100 eindeutig benannte Speicherkonten erstellen. Wie bei anderen Azure-Diensten gibt es Standard- und Premium-Speicherkonten. Weitere Informationen finden Sie unter Einführung in Microsoft Azure Storage.
Clouddienste
Wenn Sie den Server für das VPN-Gateway erstellen, wird ein Clouddienst für den virtuellen Computer erstellt. An diesem Punkt müssen Sie festlegen, wie viele Clouddienste Sie für die Wiederherstellungsfarm benötigen. Sie möchten natürlich keinen eigenen Clouddienst für jeden Server in der Farm. Aber sollten Sie einen oder mehrere verwenden? Es gibt gute Argumente für beide Optionen. Durch die Gruppierung virtueller Computer in separate Clouddienste können Sie mehrere Server als eine Einheit verwenden. In unserer Testfarm haben wir vier Clouddienste verwendet. Der erste war für das VPN-Gateway bestimmt, und dann gab es einen für jede der folgenden Ebenen: Front-End-Webserver, Anwendungsserver und Datenbankserver. Weitere Informationen finden Sie unter Sollte ich mich für Cloud Services entscheiden?.
Netzwerk
Virtuelle Netzwerke spielen in diesem Notfallwiederherstellungsszenario eine wichtige Rolle. Weitere Informationen finden Sie unter Dokumentation zu virtuellen Netzwerken.
PowerShell
Azure PowerShell-Cmdlets helfen Ihnen bei der Automatisierung von Aufgaben in der virtuellen Umgebung. Weitere Informationen finden Sie unter Windows Azure PowerShell-Cmdlets (v2.2.2).
Automatisierung
Azure unterstützt die Verwendung von Runbooks zur Automatisierung einer breiten Palette von Bereitstellungs- und Verwaltungsaufgaben. Weitere Informationen finden Sie unter Erste Schritte mit Azure Automation.
Virtuelle Computer, Festlegen der Größe
Azure VMs stehen in mehreren Serien zur Verfügung, die verschiedenen Leistungs- und Kapazitätsmerkmale aufweisen. Sie können virtuelle Computer entsprechend Ihren Workload- und Farmebenen mischen und anpassen.
Weitere Informationen finden Sie unter Größen für virtuelle Windows-Computer in Azure.
Verfügbarkeitsgruppen
Verfügbarkeitsgruppen stellen eine empfohlene Option dar, da sie sicherstellen, dass die virtuellen Computer einer Gruppe (mindestens zwei) für hohe Verfügbarkeit in verschiedenen Gestellen gehostet werden. Sie sind auch erforderlich, wenn Sie die Azure SLA nutzen möchten. Verfügbarkeitsgruppen dienen nicht nur zur Verwaltung der Verfügbarkeit Ihrer virtuellen Maschinen, sondern leisten auch einen Beitrag zum Lastenausgleich und unterstützen die Skalierung einer Gruppe von Servern.
Hinweis: SharePoint Server 2016 unterstützt keine automatische zentrale Hochskalierung oder Herunterskalierung von Farmservern.
Weitere Informationen finden Sie unter Verwalten der Verfügbarkeit virtueller Windows-Computer in Azure.

Siehe auch

Weitere Ressourcen

SharePoint Server 2016 in Microsoft Azure

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