Best Practices und Strategien zur Notfallwiederherstellung für die SharePoint 2016-Suche

 

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

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

Erfahren Sie, wie Sie bewährte Methoden für die Notfallwiederherstellung der Suche in einer SharePoint Server 2016- oder SharePoint Server 2013-Farm implementieren.

Dieser Artikel enthält einen Leitfaden für bewährte Methoden, mit denen Sie eine unterstützte Notfallwiederherstellungsstrategie für die Suche in SharePoint Server entwickeln können. Viele Methoden der Notfallwiederherstellung in früheren Versionen von SharePoint Server bieten nicht dieselbe Wiederherstellungsebene für SharePoint Server 2016 und SharePoint Server 2013. Wir untersuchen diese Methoden und beschreiben Ersatzoptionen zusammen mit den jeweiligen Vorteilen und Einschränkungen, die Sie kennen müssen.

Inhalt dieses Artikels:

• Einführung

• Architektur der Suchdienstanwendung

• Übersicht über die Indexstruktur der Suchdienstanwendung

• Allgemeine Notfallwiederherstellungstechniken

• Unterstützte Techniken für die Wiederherstellung

• Zusätzliche Ressourcen

Einführung

Dieser Artikel schließt die Lücke zwischen Dokumentation, die eine Roadmap für die Implementierung einer Notfallwiederherstellungsstrategie enthält, und Dokumentation, die die spezifischen Befehle zum Konfigurieren der Notfallwiederherstellung für die Suchdienstanwendung (SSA) in SharePoint Server bietet. Wir beschreiben mehrere typische Notfallwiederherstellungsszenarien und untersuchen die jeweiligen Vorteile und Einschränkungen. Erwarten Sie nicht, dass diese Szenarien direkt auf Ihre Organisation übertragbar sind. Aber Sie können sie als Leitfaden für eine Notfallwiederherstellungsstrategie verwenden, die den Anforderungen Ihrer Organisation genügt.

Die Notfallwiederherstellung für SharePoint Server und die unterstützenden Technologien ist ein komplexes Thema. Daher gibt es zahlreiche Informationsquellen zur erforderlichen Planung, mit der sichergestellt wird, dass Ihre Unternehmensziele auch nach einem Ereignis, das den Notfallwiederherstellungsplan aktiviert, weiterhin erreicht werden.

Als bewährte Methode wird empfohlen, zunächst die Werte RTO (Recovery Time Objectives, Zielsetzung für die Wiederherstellungsdauer) und RPO (Recovery Point Objectives, Zielsetzung für den Wiederherstellungspunkt) für Ihre Organisation eindeutig zu bestimmen und zu quantifizieren. RTO, die erforderliche Zeit zur Wiederherstellung nach einem Notfall, und RPO, die Daten gemessen in Zeit, die durch denselben Notfall verloren gehen können, sind Schlüsselmetriken für die Planung der Notfallwiederherstellung. Diese beiden geschäftsabhängigen Metriken bestimmen Folgendes:

• Verfahren, Medien und Speicher für die Sicherung und Wiederherstellung

• Zielort der Wiederherstellung

• Größe und Komplexität der Wiederherstellungslösung

Ohne diese Benchmarks ist es nicht möglich, eine Wiederherstellungsstrategie zu entwickeln und technische Lösungen zu evaluieren.

Auch wenn der Gegenstand dieses Artikels die Notfallwiederherstellung für die SharePoint Server-Suche ist, wird empfohlen, als Vorbereitung für die Entwicklung einer Notfallwiederherstellungsstrategie den Artikel Wählen einer Notfallwiederherstellungsstrategie für SharePoint Server zu lesen.

Architektur der Suchdienstanwendung

Bevor die verschiedenen Möglichkeiten zur Entwicklung einer Notfallwiederherstellungsstrategie besprochen werden, werden in der folgenden Tabelle die Komponenten der SharePoint Server-Suche und ihr Beitrag zur Endbenutzererfahrung beschrieben. Die Komponenten und Datenbanken der Suchanwendung in der folgenden Tabelle stellen den Kontext für eine Notfallwiederherstellungsstrategie dar.

Suchdienstkomponenten

Komponente oder Datenbank	Beschreibung
Indexkomponente	Dient als logische Darstellung eines Indexreplikats. Die Indexkomponente enthält Folgendes: Indexpartitionen Sie können den Index in diskrete Abschnitte unterteilen, die jeweils einen gesonderten Teil des Indexes enthalten. Der Suchindex stellt die Aggregation aller Indexpartitionen dar. Jede Indexpartition wird in einem Dateisatz auf einem Datenträger gespeichert. Indexreplikate Jede Indexpartition enthält ein oder mehrere Indexreplikate, die dieselben Informationen enthalten.
Abfrageverarbeitungskomponente	Analysiert und verarbeitet Suchabfragen und Ergebnisse.
Verwaltungskomponente	Führt Systemprozesse für die Suche aus. Pro Suchdienstanwendung können mehrere Suchverwaltungskomponenten vorhanden sein, aber es ist immer nur eine aktiv.
Durchforstungskomponente	Durchforstet Inhalte entsprechend den Angaben in der Durchforstungsdatenbank.
Inhaltsverarbeitungskomponente	Führt verschiedene Prozesse auf den durchforsteten Elementen aus, z. B. Dokumentanalyse und Eigenschaftszuordnung.
Analyseverarbeitungskomponente	Führt Such- und Verwendungsanalysen durch.
Suchverwaltungsdatenbank	Speichert die Suchkonfigurationsdaten. Pro Suchdienstanwendung ist nur eine Suchverwaltungsdatenbank vorhanden.
Durchforstungsdatenbank	Speichert den Durchforstungsverlauf und verwaltet Crawlvorgänge.
Linkdatenbank	Speichert einen Teil der Informationen, die von der Inhaltsverarbeitungskomponente extrahiert wurden. Zudem werden Durchklickinformationen gespeichert.
Analyseberichtsdatenbank	Speichert die Ergebnisse der Verwendungsanalyse.

Es gibt mehrere Möglichkeiten für die Verteilung von Suchkomponenten, um eine hochverfügbare und hochskalierbare Suchtopologie zu erstellen, wie im folgenden Diagramm dargestellt. In dem Diagramm werden Suchkomponenten auf verschiedenen Anwendungsservern bereitgestellt, um Redundanz zu erzielen. Zudem werden die Anwendungsserver auf verschiedenen Virtualisierungshostservern bereitgestellt, was eine weitere Fehlertoleranzstufe und gleichzeitig Skalierbarkeit ermöglicht.

Weitere Informationen zum Verteilen von Suchkomponenten auf Farmservern finden Sie unter Planen der Architektur der Unternehmenssuche in SharePoint Server 2016 und technische Diagramme zur Suche unter Search in SharePoint Server 2016.

Um die Komplexität der Entwicklung einer Notfallwiederherstellungsstrategie für die Suche einschätzen zu können, müssen Sie verstehen, wie im Index und den Datenbanken der Suchdienstanwendung auf Dokumente verwiesen wird. Dieses Verweissystem macht es derzeit unmöglich, die Suchindizes mit irgendeiner Form von Replikations- oder Protokollversandtechnologie zwischen SharePoint Server-Farmen zu kopieren.

Übersicht über die Indexstruktur der Suchdienstanwendung

Weil die Struktur der SharePoint-Suchdienstanwendung so komplex ist, geht eine tiefgreifende Beschreibung über den Gegenstand dieses Artikels hinaus. Einfach ausgedrückt besteht der Index aus mehreren kleinen Teilen, die eine Folge aktualisierbarer Datengruppen darstellen. Stellen Sie sich diese aktualisierbaren Gruppen als Partitionen über Spalten in einer Tabelle vor. Standardmäßig enthält der Suchindex sechs dieser Gruppen. Diese Gruppen lauten wie folgt:

• Hauptgruppe: enthält die Masse der Felder, hier gespeichert als Volltext.

• ACLs: beinhaltet Sicherheitskürzung und schnelle Sicherheitsdurchforstung.

• Pfad und Titel: enthält den Pfad und den Titel.

• Empfehlungen: Beachten Sie, dass diese Daten täglich aktualisiert werden.

• Kollegen in sozialen Medien (Personen): umfasst eine gesonderte Aktualisierungsgruppe für Personenfelder.

• Communitytags: enthält Communitytags.

Stellen Sie sich jede Aktualisierungsgruppe als Indexstruktur für die Felder in der Gruppe vor, ähnlich strukturiert wie eine SQL Server-Datenbank. Die Aktualisierungsgruppen sind auf der Speicherebene in Dateien partitioniert, die jeweils einen Teil der Indexstruktur enthalten. Jede dieser Dateien enthält einen anderen Teil des Gesamtindexes. Inhalte werden mithilfe eines Bezeichners für jedes einzelne Dokument auf diese Partitionen verteilt. Dieser Bezeichner ist die DocID, die auch einen Zähler darstellt.

Beim Erstellen einer neuen Suchdienstanwendung wird der Zähler auf Null gesetzt. Die DocID wird jedes Mal um eins erhöht, wenn bei der Durchforstung ein neues Element gefunden wird, und er wird mit jedem gefundenen neuen Element weiter erhöht. Der Zähler wird nie verringert. Auch nach dem Löschen eines Dokuments wird der entsprechende Zählerwert nicht wieder verwendet. Das Hinzufügen und Entfernen von Dokumenten oder Elementen aus Bibliotheken und Listen über einen Zeitraum hinweg bewirkt auch, dass die DocID innerhalb einer Website oder Bibliothek nicht fortlaufend ist. Daher ist es unmöglich, die DocID eines Dokuments im Suchkorpus vorherzusagen.

Dies bedeutet insofern ein Problem für jede Suchreplikationsstrategie, als es in zwei Farmen keine Garantie und nicht einmal die Wahrscheinlichkeit gibt, dass die DocID-Werte für ein Dokument in der Farm übereinstimmen. Da die DocID-Werte nicht übereinstimmen, können Indexdaten oder Analysedaten, die mit dem DocID-Wert verknüpft sind, nicht repliziert werden. Suchergebnisse werden nicht gültig sein, da dasselbe Dokument in jeder Farm einen anderen DocID-Wert hat.

Eine Notfallwiederherstellungsstrategie in voller Genauigkeit für die Suchdienstanwendung muss die folgenden beiden Aktivitäten umfassen:

• Die Komponenten und Datenbanken mit Daten für Konfiguration und Abfragen werden identifiziert und mit einer geeigneten Methode korrekt in der Zielfarm der Notfallwiederherstellung wiederhergestellt.

• Die Ziel-DR-Farm wird mit der richtigen Anzahl von Komponenten skaliert, um die Größe des Suchdiensts unterstützen zu können.

Auf diese beiden Aktivitäten wird in den folgenden Abschnitten und in den technischen Details der Implementierungsabschnitte Bezug genommen.

Allgemeine Notfallwiederherstellungstechniken

In früheren Versionen von SharePoint konnte auf verschiedene Arten sichergestellt werden, dass eine Failover-Suchdienstanwendung mit aktuellen Indizes und nahezu 100prozentiger Suchaktualität zur Verfügung stand. Die folgenden Beispiele zeigen verschiedene Methoden, die typischerweise zur Notfallwiederherstellung verwendet wurden.

• Das Durchforsten schreibgeschützter Inhaltsdatenbanken war eine Möglichkeit, bei der mit SQL Server-Protokollversandmethoden eine Kopie der an die Notfallwiederherstellungsfarm angefügten Produktionsinhaltsdatenbanken im Schreibschutzmodus verwaltet wurde. Somit konnte eine in der Notfallwiederherstellungsfarm gehostete SSA dafür konfiguriert werden, die Datenbanken in der Notfallwiederherstellungsfarm über eine Webanwendung ohne Schreibzugriff zu durchforsten. Alle Konfigurationsänderungen mussten auf SSA-Ebene in beiden Farmen implementiert werden, um für Endbenutzer bei einem Failover die volle Genauigkeit der Wiederherstellung sicherzustellen.

• Bei der dualen Durchforstung durchsucht die Wiederherstellungsfarm auch die Produktionsfarm, und somit wurde derselbe Inhalt ermittelt und indiziert. Konfigurationsänderungen an verwalteten Eigenschaften oder durchforsteten Dateitypen, installierten IFiltern usw. mussten in Produktions- und Notfallwiederherstellungsfarmen implementiert werden. Aber dies war mit einer entsprechenden Änderungssteuerungsrichtlinie einfach zu verwalten.

Andere Optionen für Notfallwiederherstellungsstrategien boten nicht dieselbe Stufe an Suchindexaktualität, aber wenn die Indexaktualität oder die Zeit für die Wiederherstellung nicht unternehmenskritisch sind, stellen sie mögliche Optionen dar. In der Regel sind diese Optionen komplexer zu konfigurieren und zu implementieren. Die folgenden Beispiele zeigen einige typische Methoden.

• Die SSA-Suchverwaltungsdatenbank konnte unabhängig gesichert werden. Die SSA-Suchverwaltungsdatenbank wird unabhängig mit herkömmlichen SQL Server-Sicherungsmethoden gesichert und in der Notfallwiederherstellungsfarm verwendet, um mit Microsoft PowerShell eine SSA zu erstellen. Dadurch wird die Suchkonfiguration wiederhergestellt, aber nicht die Indizes. Eine vollständige Durchforstung ist nötig, um die Suchindizes aufzufüllen und die Wiederherstellung abzuschließen.

• Eine vollständige Sicherung und Wiederherstellung der Suchdienstanwendung. Mit Microsoft PowerShell oder der Oberfläche der die Website für die SharePoint-Zentraladministration wird eine vollständige Sicherung und Wiederherstellung der Suchdienstanwendung ausgeführt. Dadurch werden die Datenbanken und Suchindizes der SSA gesichert, sodass sie in der Notfallwiederherstellungsfarm wiederhergestellt werden können, um die SSA dort aufzufüllen.

In SharePoint Server 2016 oder SharePoint Server 2013 müssen wir die Notfallwiederherstellung für die Suche aufgrund bedeutender Änderungen der Sucharchitektur und der Speicherung von Konfigurationselementen anders betrachten. In den folgenden Abschnitten werden diese Änderungen und ihre Auswirkungen auf die verfügbaren Notfallwiederherstellungsmethoden beschrieben.

Konfigurations- und Funktionsänderungen der Sucherfahrung

Die Websiteverwaltungsseiten in SharePoint Server bieten Optionen, die eine flexible Konfiguration der Sucherfahrung unterstützen. Mit den neuen Konfigurationsoptionen für Websites und Websitesammlungen können Websiteadministratoren Änderungen der Suchkonfiguration vornehmen, die zuvor nur von Farm- oder Suchadministratoren ausgeführt werden konnten. Der nächste Screenshot zeigt die beiden Stellen, an denen Sie Suchoptionen konfigurieren können: unter Websitesammlungsverwaltung oder unter Suche.

Sie können Konfigurationsänderungen an einem Suchelement, z. B. Abfrageregeln oder Ergebnisquellen, in der Liste unter "Websitesammlungsverwaltung" oder unter "Suche" vornehmen. Das Ergebnis ist das gleiche. Allerdings wirkt sich der Speicherort einer Änderung direkt auf die Notfallwiederherstellung aus. Alle Änderungen an einer Websitesammlung oder einer Webanwendung werden nur in der Verwaltungsdatenbank der Suchdienstanwendung (SSA) gespeichert. Wird diese Datenbank nicht aus einer Sicherung in der Notfallwiederherstellungsfarm wiederhergestellt, sind Konfigurationsänderungen nicht in der wiederhergestellten Umgebung verfügbar.

Ein weiteres neues Feature in der SharePoint Server-Suche ist die Funktion zur sofortigen Neuindizierung, mit der Administratoren auf den Ebenen Websitesammlung, Web und Liste eine erneute Indizierung des Containers bei der nächsten Durchforstung anfordern können. Das Feature wird vollständig innerhalb der Inhaltsdatenbank verwaltet. Daher löst eine solche Anforderung eines Administrators in der Notfallwiederherstellungsfarm dasselbe Ereignis in der Produktionsfarm aus, wenn die nächste Durchforstung in der Notfallwiederherstellungsfarm ausgeführt wird.

Suchanalysegesteuerte Benutzerempfehlungen

In der SharePoint Server-Suche erfolgt die Verarbeitung von Such- und Verwendungsanalysen durch eine Analysekomponente, die als Analyseverarbeitung bezeichnet wird. Diese Komponente erfüllt folgende Aufgaben:

• Verarbeitung von Suchanalyseinformationen

• Verarbeitung von Verwendungsanalysen

• Bereitstellen relationaler Informationen, die von der Inhaltsverarbeitung zur Unterstützung der Suchempfehlungen verwendet werden

• Bereitstellen statistischer Informationen zur Beliebtheit von Dokumenten (z. B. Besuche und Klicks auf einer Seite), die von der Inhaltsverarbeitung zur Verbesserung von Relevanz- und Bewertungsberechnungen verwendet werden

Weitere Informationen zu den einzelnen Analyseprozessen finden Sie unter Übersicht über die Analyseverarbeitung in SharePoint Server.

Die verarbeiteten Informationen werden im Suchindex und auch in den Berichts- und Linkdatenbanken gespeichert. Daher ist die einzige Methode, um sicherzustellen, dass die Informationen in synchronisiertem Zustand auf die Notfallwiederherstellungsfarm repliziert werden, eine vollständige Sicherung und Wiederherstellung der Suchdienstanwendung.

Verbesserungen der Sicherung und Wiederherstellung der Dienstanwendung

Die Methode, die alle Notfallwiederherstellungsanforderungen für die Erfassung von Konfigurations- und Indexdaten erfüllt, ist die Sicherung und Wiederherstellung der Dienstanwendung. In diese Vorgänge wurde bedeutend investiert, um RTO und RPO gegenüber früheren Versionen von SharePoint zu verringern. Unterstützung für das Ändern der Anzahl von Threads für Sicherungs- und Wiederherstellungsprozesse sowie eine verbesserte Unterstützung vollständiger und differenzieller Sicherungs- und Wiederherstellungsvorgänge sind die wichtigsten Fortschritte in diesem Bereich.

Wenn der Ansatz einer vollständigen Sicherung und Wiederherstellung der Suchdienstanwendung als Notfallwiederherstellungsstrategie verfolgt wird, ist die gesamte RPO von zwei Dingen abhängig. Die Zeit seit der letzten vollständigen Sicherung der Dienstanwendung ist die RPO, die benötigte Zeit für die Wiederherstellung der Dienstanwendung die RTO. Beide Zeiten nehmen wahrscheinlich zu, je mehr der indizierte Inhalt in der Suchdienstanwendung wächst. Daher muss die Erwartung einer Dienstwiederherstellung nach einem erklärten Notfall sorgfältig verwaltet werden. Es wird empfohlen, im Rahmen des Dienstkontinuitätsmanagements häufig Testwiederherstellungen auszuführen, um sicherzustellen, dass eine möglicherweise getroffene SLA bezüglich erforderlicher RTO und RPO erfüllt werden kann. In der folgenden Tabelle sind die Sicherungs- und Wiederherstellungsoptionen für die Suchdienstanwendung zusammengefasst.

Option	Einschränkungen
Durchforsten der schreibgeschützten Datenbanken in der Notfallwiederherstellungsfarm	Konfigurationsänderungen auf Websitesammlungs- oder Webebene werden nicht auf die Notfallwiederherstellungsfarm repliziert.
Durchführen einer dualen Durchforstung der Produktionsfarm	Konfigurationsänderungen auf Websitesammlungs- oder Webebene werden nicht auf die Notfallwiederherstellungsfarm repliziert. Analysegesteuerte Suchindexaktualisierungen werden nicht auf die Notfallwiederherstellungsfarm repliziert.
Wiederherstellen der Suchverwaltungsdatenbank in der Notfallwiederherstellungsfarm und Neuerstellen des Diensts	Analysegesteuerte Suchindexaktualisierungen werden in der Notfallwiederherstellungsfarm nicht wiederhergestellt. Dies liegt daran, dass der Index beim Erstellen der Dienstanwendung leer ist und eine vollständige Durchforstung nötig ist.
Ausführen einer vollständigen Sicherung und Wiederherstellung der Suchdienstanwendung	Bei der Genauigkeit des Suchindex gibt es keine Einschränkungen, das Wiederherstellen einer großen Dienstanwendung kann jedoch mehrere Stunden in Anspruch nehmen und Auswirkungen auf die Wiederherstellungsdauer während eines Failovers haben.

Unterstützte Techniken für die Wiederherstellung

Nur eine der unterstützten Notfallwiederherstellungstechniken bietet eine Wiederherstellung in voller Genauigkeit, einschließlich aller Analyseverarbeitungsverbesserungen am Suchindex und aller Suchkonfigurationselemente auf der Suchanwendungs-, Websitesammlungs- und Webebene in der Produktionsfarm. Dieser Ansatz erfordert eine vollständige Sicherung der Suchdienstanwendung und anschließend eine vollständige Wiederherstellung der Dienstanwendung in der Notfallwiederherstellungsfarm. Die Indizes und die Konfiguration werden im Zustand des Zeitpunkts wiederhergestellt, zu dem die Sicherung erstellt wurde. Ist die Sicherung mehrere Tage alt, muss eine neue Durchforstung ausgeführt werden, um die Indizes zu aktualisieren. Die einzelnen Schritte für diesen Ansatz werden weiter unten in diesem Dokument beschrieben.

Es ist auch möglich, eine Sicherung der Verwaltungsdatenbank der Suchdienstanwendung zu erstellen und am Notfallwiederherstellungsstandort wiederherzustellen. Administratoren können mit Microsoft PowerShell eine neue Suchdienstanwendung aus der Sicherung erstellen. Dadurch werden jedoch nur die tatsächliche Konfiguration der Suchdienstanwendung und alle angepassten Sucheinstellungen in SharePoint-Websites und Webs wiederhergestellt, aber nicht der Suchindex. Der Korpus muss durch eine vollständige Durchforstung aufgefüllt werden. Außerdem kann die analytische Erweiterung der Suchindizes nicht wiederhergestellt werden, da die zur Generierung verwendeten Signale nur in der Produktionsfarm vorhanden sind.

Falls die Suche vor allem deswegen in die Notfallwiederherstellungsstrategie aufgenommen werden soll, damit zur Failoverzeit die Suchindexaktualität gewährleistet ist, gibt es einen weiteren möglichen Ansatz. Der Index kann mit einer von zwei Methoden ziemlich aktuell gehalten werden, allerdings auf Kosten einer komplexen Konfiguration und mehrerer Einschränkungen. Die Komplexität entsteht dadurch, dass entweder die Crawler in der Notfallwiederherstellungsfarm für die Durchforstung der Produktionsfarm konfiguriert werden müssen oder die Inhaltsdatenbanken in lesbarem Zustand auf die Notfallwiederherstellungsfarm repliziert werden müssen, um lokale Durchforstung zu unterstützen. Dieser Ansatz hat die Einschränkungen, dass die Konfiguration der Suchdienstanwendung in Produktion in keiner Weise für die Notfallwiederherstellung repliziert wird und Suchindexaktualisierungen von der Verarbeitung der Analysedaten ebenfalls fehlen. Falls diese Einschränkungen hinnehmbar sind, ist dies eine sehr flexible Möglichkeit, hohe Indexaktualität und Suchverfügbarkeit in der Notfallwiederherstellungsfarm zu gewährleisten.

Ein abschließender Ansatz besteht darin, die beiden oben beschriebenen Techniken zu einer Strategie zu kombinieren, die hohe Suchindexaktualität beim Failover bietet, aber zusätzlich die Ausführung einer vollständigen Wiederherstellung ermöglicht, um die Analyseinformationen und Suchkonfiguration in die Notfallwiederherstellungsfarm zu übertragen.

In diesem Fall würden eine vollständige Sicherung und eine remote oder lokal ausgeführte Durchforstung eingesetzt sowie bei Bedarf ein Prozess für die Wiederherstellung zur Verfügung gestellt. Ein typischer Grund für den Start des vollständigen Wiederherstellungsprozesses könnte sein, dass das Failover zum Notfallwiederherstellungsstandort mehr als eine vorübergehende Unterbrechung des normalen Diensts darstellt und das Failback zur Produktionsumgebung in einem bestimmten Zeitraum nicht möglich ist. In diesem Fall würde der Wiederherstellungsprozess aufgerufen, um die Verfügbarkeit der Suche in voller Genauigkeit am Notfallwiederherstellungsstandort sicherzustellen. Anschließend würde eine neue Durchforstung ausgelöst, um den Suchindex vollständig zu aktualisieren.

Beim Wiederherstellen einer Suchdienstanwendung, die die Überschreibungsoption verwendet, sind bestimmte Implikationen zu bedenken. Die Dienstanwendung ist während der Wiederherstellung offline, also können keine Aktualisierungen oder Abfragen verarbeitet werden. Für ein Unternehmen, für das die Suche keine kritische Funktion darstellt, ist dies wahrscheinlich kein Problem. Aber wenn die Suchabfragefunktion während der Wiederherstellung verfügbar sein muss, kann eine andere Option in Erwägung gezogen werden. Die alternative Option besteht darin, während der Wiederherstellung immer eine neue Suchdienstanwendung zu erstellen und nach Abschluss der Wiederherstellung eine neue Durchforstung auszuführen, um den Index zu aktualisieren. Nach der Durchforstung stellen Sie die Zuordnung der Dienstanwendung auf die neue Dienstanwendung um und setzen die Arbeit unterbrechungsfrei fort. Die ältere Dienstanwendung kann dann gelöscht werden. Das größte Problem besteht dabei in der Kapazität, da im Wesentlichen der doppelte Index- und Datenbankspeicherplatz nötig ist, um zwei Dienstanwendungen parallel zu hosten. Es hängt von der Wichtigkeit der Suchdienste für das Unternehmen ab, ob diese Anforderung erfüllt werden muss.

In Anbetracht aller dieser Faktoren lohnt es sich, die erwarteten RPO- und RTO-Anforderungen der Suchdienstanwendung zu untersuchen. Zurzeit unterstützt Office 365 SharePoint eine RPO und RTO von einer Woche für die Suchdienstanwendung. Das bedeutet, dass Konfigurationselemente, Analyseprozessinformationen und Suchaktualität bei einer Wiederherstellung maximal eine Woche veraltet sein können. Wie gesagt, abhängig von der erwarteten Änderungsrate in der Umgebung und der Wichtigkeit der Suche sind möglicherweise tägliche oder noch häufigere Sicherungen angezeigt, um eine optimale RPO und RTO für das Unternehmen zu erreichen. Es ist nicht notwendig, mehrere Sicherungskopien zu halten, wie Sie es bei Inhaltssicherungen tun würden, da Suchinhalte veränderlich und kurzlebig sind. Maximal ein oder zwei vollständige Sicherungen genügen.

Sicherung und Wiederherstellung der Dienstanwendung

Die folgenden Informationen stellen eine kurze Zusammenfassung der wichtigsten Punkte aus den TechNet-Artikeln zu Sicherung und Wiederherstellung der Suche dar:

• Sichern von Suchdienstanwendungen in SharePoint Server

• Wiederherstellen von Suchdienstanwendungen in SharePoint Server

Die notwendige Häufigkeit von Suchdienstsicherungen wird von vielen Faktoren beeinflusst, aber die größte Rolle spielt die für das Unternehmen erforderliche RPO. Mit wachsendem Umfang des Suchindexes nimmt auch die Dauer von Sicherung und Wiederherstellung der Dienstanwendung immer mehr zu. Zu einem bestimmten Zeitpunkt kann jeweils nur eine einzelne Sicherung der Suche stattfinden. Und die Dauer der Sicherung ist die kleinste erzielbare RPO. Die Dauer der Wiederherstellung in der Notfallwiederherstellungsfarm ist daher die kleinste erzielbare RTO, und wie die Dauer der Sicherung nimmt diese mit der Zeit zu. Wenn die Sicherungs- oder Wiederherstellungsdauern beginnen, die erforderlichen Vereinbarungen zum Servicelevel (SLA) für RPO und RTO der Suche zu beeinträchtigen, muss im Unternehmen eine Entscheidung gefällt werden zwischen einem flexibleren Ansatz mit geringerer Genauigkeit, wie weiter unten beschrieben, oder der Anpassung der SLAs, um ein erfüllbares Ziel zu erreichen.

Sichern der Suchdienstanwendung

Zum Sichern der Suchdienstanwendung können Sie entweder Microsoft PowerShell oder die Benutzeroberfläche der Zentraladministration verwenden. Das entsprechende PowerShell-Cmdlet lautet:

Backup-SPFarm -Directory <Backup Folder> - BackupMethod <Full | Differential> -Item <Full Path to Search Service Application>

Hier ein Beispiel:

Backup-SPFarm -Directory \\server\searchbackup - BackupMethod Full -Item "Farm\Shared Services\Shared Services Applications\Contoso Search Service Application"

In diesem Beispiel wird eine vollständige Sicherung der Suchdienstanwendung mit dem Namen "Contoso Search Service Application" ausgeführt. Die Sicherungsdateien werden im Ordner "\\server\searchbackup" gespeichert.

Der allgemeine Status aller Sicherungsaufträge wird oben auf der Seite Status von Sicherungs- und Wiederherstellungsaufträgen im Abschnitt Bereitschaft angezeigt. Der Status des aktuellen Sicherungsauftrags wird im unteren Teil der Seite im Abschnitt Sichern angezeigt. Die Statusseite wird alle 30 Sekunden automatisch aktualisiert. Durch Klicken auf Aktualisieren können die Statusdetails manuell aktualisiert werden. Sicherung und Wiederherstellung sind Timerdienstaufträge. Daher kann es mehrere Sekunden dauern, bis die Sicherung gestartet wird. Für den Fall, dass Fehler gemeldet werden, können Sie diese in der Spalte Fehlermeldung auf der Seite "Status von Sicherungs- und Wiederherstellungsaufträgen" überprüfen. Weitere Details finden Sie in der Datei Spbackup.log unter dem UNC-Pfad, den Sie zum Speichern der Sicherungsdatei angegeben haben.

Wiederherstellen der Suchdienstanwendung

Zum Wiederherstellen einer SharePoint Server-Suchdienstanwendung muss die Sicherung vollständig erfolgreich abgeschlossen sein. Falls häufig Sicherungen ausgeführt werden, wird die ID der Sicherung benötigt, die wiederhergestellt werden soll. Diese ID kann auf verschiedene Arten einfach ermittelt werden. Am einfachsten ist es, die Seite Sichern und Wiederherstellen - Verlauf in der Produktionsfarm zu öffnen, in der die Sicherung ausgeführt wurde, und Speicherort des Sicherungsverzeichnisses einzugeben. Daraufhin wird eine Liste aller Einträge in der Manifestdatei für Sicherungen und Wiederherstellungen ("psbrtoc.xml") angezeigt. Der folgende Screenshot zeigt die Sicherungs-ID {149fc816-8927-4a32-9437-6e05c2869ab7}.

Alternativ können Sie das Manifest für Sicherungen und Wiederherstellungen auch direkt öffnen und nach dem gewünschten Eintrag suchen. Da die Datei mit jeder ausgeführten Sicherung und Wiederherstellung wächst, ist die Suche in der Datei möglicherweise nicht die optimale Methode – vor allem, wenn Sicherungs- und Wiederherstellungsvorgänge sehr häufig ausgeführt werden.

Das folgende Beispiel zeigt typische Einträge in spbrtoc.xml, und Sie sehen, dass die Sicherungs-ID leicht zu erkennen ist.

<?xml version="1.0" encoding="utf-8"?>
<SPBackupRestoreHistory>
 <SPHistoryObject>
 <SPId>149fc816-8927-4a32-9437-6e05c2869ab7</SPId>
 <SPRequestedBy>REDMOND\pkmacct</SPRequestedBy>
 <SPBackupMethod>Full</SPBackupMethod>
 <SPRestoreMethod>None</SPRestoreMethod>
 <SPStartTime>01/11/2016 02:30:27</SPStartTime>
 <SPFinishTime>01/11/2016 02:38:48</SPFinishTime>
 <SPIsBackup>True</SPIsBackup>
 <SPConfigurationOnly>False</SPConfigurationOnly>
 <SPBackupDirectory>\\server\backups\spbr0000\</SPBackupDirectory>
 <SPDirectoryName>spbr0000</SPDirectoryName>
 <SPDirectoryNumber>0</SPDirectoryNumber>
 <SPTopComponent>Farm\Shared Services\Shared Services Applications\Search Service Application Prod</SPTopComponent>
 <SPTopComponentId>013aa694-673d-46d1-9313-fbba6df691e7</SPTopComponentId>
 <SPWarningCount>0</SPWarningCount>
 <SPErrorCount>0</SPErrorCount>
 </SPHistoryObject>
</SPBackupRestoreHistory>

Eine weitere verfügbare Methode ist die Verwendung des Cmdlets Get-SPBackupHistory, das dieselben Informationen liefern kann wie die Datei spbrtoc.xml.

Die nächsten beiden Beispiele zeigen, wie die Wiederherstellung mit dem Cmdlet Restore-SPFarm ausgeführt wird.

Restore-SPFarm -Directory <BackupFolder> -Item "<ServiceApplicationName>" -RestoreMethod Overwrite [-BackupId <GUID>]

Restore-SPFarm -Directory \\server\searchbackup - Item "Farm\Shared Services\Shared Services Applications\Contoso Search Service Application" -RestoreMethod New -BackupID "149fc816-8927-4a32-9437-6e05c2869ab7"

Die verwendete RestoreMethod bestimmt den weiteren Prozessfluss nach der Ausführung des Cmdlets Restore-SPFarm.

Wenn die Option new gewählt wird, wird der Administrator, der das Cmdlet ausführt, aufgefordert, für jede Komponente und Datenbank in der Sicherung einen Speicherort in der neuen Farm anzugeben. Dies ist besonders nützlich, wenn die Serverfarmtopologie und die Benennungskonvention in der Notfallwiederherstellungsfarm nicht genau mit der Produktionsumgebung übereinstimmt, was häufig der Fall ist. Wenn die Suchdienstanwendung in einer Farm wiederhergestellt wird, die mit den gleichen Namen und der gleichen Servertopologie erstellt wurde, kann die Option overwrite verwendet werden. Diese Option wird in der Regel nur bei der Wiederherstellung in derselben Farm verwendet, aus der die Sicherung stammt.

Wenn eine Suchdienstanwendung wiederhergestellt wird, wird diese während und nach der Wiederherstellung automatisch angehalten. Verwenden Sie den folgenden PowerShell-Befehl, um die Dienstanwendung nach der Wiederherstellung fortzusetzen.

$ssa = Get-SPEnterpriseSearchServiceApplication <SearchServiceApplicationName> $ssa.ForceResume($ssa.IsPaused())

Ebenfalls von besonderer Bedeutung für den Administrator ist der Vorgang, mit dem eine Suchdienstanwendung wiederhergestellt wird, die über mehrere Replikate pro Partition verfügt. Der Wiederherstellung erfolgt nur auf eines der Replikate in jeder Partition, und ein Hintergrundtask behandelt die Replikation der Partitionsinformationen auf alle anderen Replikate für jede Partition. Während des Vorgangs sind die Suchindizierung und Abfragefunktionalität online und funktionsfähig, aber auf den Verwaltungsseiten für die Suchdienstanwendung können die Replikate als heruntergestuft erscheinen, bis der Vorgang abgeschlossen ist.

Kombinierter Ansatz zur Notfallwiederherstellung

Wie gesagt: Da die Sicherung und Wiederherstellung der Dienstanwendung die einzige unterstützte Methode für eine Notfallwiederherstellungslösung mit voller Genauigkeit darstellt, ist es eine besondere Herausforderung, eine niedrige RPO/RTO für die Suche zu erzielen. Die Dauer der Sicherung und der Wiederherstellung kann im Lauf der Zeit zunehmen, wenn der indizierte Korpus größer wird. Dies kann zu einer unerwünscht langen RPO und RTO führen.

Eine Möglichkeit, die Schwierigkeiten beim Erreichen einer niedrigen RPO/RTO zu überwinden, besteht in einer zweigleisigen Lösung. Die folgende Liste zeigt diese Lösung:

• Verwenden Sie eine Durchforstung schreibgeschützter Inhaltsdatenbanken oder eine duale Durchforstung des Produktionsstandorts, um eine akzeptable Aktualitätsstufe des Suchindexes in der Notfallwiederherstellungsfarm aufrechtzuerhalten.

• Führen Sie Sicherungen der Suchdienstanwendung aus, und stellen Sie sie entweder regelmäßig in der Notfallwiederherstellungsfarm wieder her, oder halten Sie sie für den Fall bereit, dass der primäre Standort nicht wiederhergestellt werden kann.

Falls Sie sich für die Durchforstung schreibgeschützter Datenbanken in der Notfallwiederherstellungsfarm entscheiden, müssen Sie bedenken, dass Änderungen in der Produktionsfarm nicht auf die Wiederherstellungsfarm repliziert werden. Wie erwähnt schließt dies die Suchdienstanalyse-Aktualisierungen des Indexes und Änderungen an Konfigurationselementen wie Ergebnisquellen, Abfrageregeln und Schemaänderungen ein. Wenn Sie einen kombinierten Ansatz wählen, ist es sehr wichtig, dass Sie alle Implikationen verstehen und eine entsprechende Strategie entwerfen. Zurzeit gibt es keine unterstützte Möglichkeit, den Verlust der Analyseaktualisierungen zu verhindern. Aber Sie können Maßnahmen ergreifen, um Aktualisierungen an Konfigurationsänderungen zu umgehen. Sie können z. B. Aktionen wie in den folgenden Beispielen versuchen.

Sorgen Sie dafür, dass alle als unternehmenskritisch betrachteten benutzerdefinierten Ergebnisquellen, Abfrageregeln und Schemaänderungen auf der Ebene der Suchdienstanwendung in Zentraladministration geändert werden und nicht in Websitesammlungen oder Unterwebsites. Betrachten Sie z. B. ein Unternehmensintranetportal, das eine Abhängigkeit von bestimmten Abfrageregeln aufweist, um den Inhalt der Homepage zu verwalten. Diese Regeln würden in der Produktionsfarm erstellt und manuell auf die Notfallwiederherstellungsfarm repliziert, um die Zuverlässigkeit dieser Konfiguration zu gewährleisten. Entsprechend müssen die benutzerdefinierten Zuordnungen durchforsteter Eigenschaften zu verwalteten Eigenschaften in beiden Farmen auf der Ebene der Dienstanwendung implementiert werden.

Es ist möglich, die Suchkonfigurationselemente auf Website- und Webebene zu erfassen und mit PowerShell in eine XML-Datei zu exportieren. Im nächsten PowerShell-Beispiel werden z. B. Konfigurationselemente aus der Website "http://intranet.contoso.com" in eine XML-Datei "intranetcontosocom.xml" exportiert. Dieser Ansatz wurde in der SharePoint-Community veröffentlicht und wird mit deren Erlaubnis verwendet. Sie finden den Blogbeitrag unter Importieren und Exportieren von Suchkonfigurationseinstellungen in SharePoint 2013.

Add-PSSnapin Microsoft.SharePoint.PowerShell-ea 0
[reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint.Client") | Out-Null
[reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint.Client.search") | Out-Null
$context = New-Object Microsoft.SharePoint.Client.ClientContext("http://intranet.contoso.com")
$searchConfigurationPortability = New-Object Microsoft.SharePoint.Client.Search.Portability.searchconfigurationportability($context)
$owner = New-Object Microsoft.SharePoint.Client.Search.Administration.searchobjectowner($context,"SPSite")
$value = $searchConfigurationPortability.ExportSearchConfiguration($owner)
$context.ExecuteQuery()
[xml]$schema = $value.Value
$schema.OuterXml | Out-File intranetcontosocom.xml -Encoding UTF8

Das nächste Beispiel zeigt, wie die Einstellungen importiert werden, die Sie aus einer anderen Umgebung abrufen.

[reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint.Client") | Out-Null
[reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint.Client.search") | Out-Null
$context = New-Object Microsoft.SharePoint.Client.ClientContext("http://dr.contoso.com")
$searchConfigurationPortability = New-Object Microsoft.SharePoint.Client.Search.Portability.searchconfigurationportability($context)
$owner = New-Object Microsoft.SharePoint.Client.Search.Administration.searchobjectowner($context,"SPSite")
[xml]$schema = gc .\schema.xml
$searchConfigurationPortability.ImportSearchConfiguration($owner,$schema.OuterXml)
$context.ExecuteQuery()

Sie können diese Beispiele anpassen, um einen Export-/Importvorgang für die Suchkonfiguration zu entwickeln, der Ihre Anforderungen für eine kombinierte Notfallwiederherstellungslösung erfüllt.

Beim Durchforsten schreibgeschützter Inhaltsdatenbanken in der Notfallwiederherstellungsfarm wird die Websitezuordnungstabelle in der SharePoint-Konfigurationsdatenbank nicht aktualisiert, um neu erstellte Websites in der Produktionsfarm zu registrieren. Das heißt, dass diese Websites und deren Inhalt bei vollständigen oder inkrementellen Durchforstungen nicht indiziert werden. Daher ist es wichtig, regelmäßig den folgenden PowerShell-Befehl auszuführen, der die Websitezuordnung in der Notfallwiederherstellungsfarm für alle Inhaltsdatenbanken in der betreffenden Webanwendung aktualisiert.

Get-SPContentDatabase -WebApplication https://intranet.contoso.com | % {$_.refreshsitesinconfigurationdatabase()}

Durch regelmäßiges Durchforsten der schreibgeschützten Datenbanken und Aktualisieren der Websitezuordnung kann eine hohe Indexaktualität in der Notfallwiederherstellungsfarm erreicht werden. Die zweite Phase des kombinierten Ansatzes betrifft die Sicherungen der Suchdienstanwendungen. Hier gibt es zwei Wahlmöglichkeiten, die in der folgenden Liste aufgeführt sind. Beachten Sie aber, dass die gewählte Alternative von den geschäftlichen Anforderungen abhängt.

• Kann der Geschäftsbetrieb auch ohne Suche in voller Genauigkeit erfolgreich aufrechterhalten werden und seine Hauptfunktionen erfüllen – das heißt, die Kernkonfigurationselemente in der Suchverwaltungs-Dienstanwendung und die Fähigkeit, eine hohe Suchindexaktualität aufrechtzuerhalten, ermöglichen den Betrieb in der Notfallwiederherstellungsfarm – wird die Dienstanwendung möglicherweise nie in der Notfallwiederherstellungsfarm wiederhergestellt. Die Wiederherstellung der Suchdienstanwendung ist unter Umständen nur erforderlich, wenn klar wird, dass der primäre Standort längere Zeit nicht verfügbar ist. Das heißt, dass ein Failback zum primären Standort nicht möglich und somit die vollständige Wiederherstellung der Suchdienstanwendung nötig ist, um alle von der Suche abhängigen Geschäftsfunktionen wieder online zu schalten. Es könnte ein bestimmter Zeitraum ausgewählt werden, um die Wiederherstellung auszulösen.

• Wenn die Notwendigkeit besteht, bei Failover so viel Suchfunktionalität in voller Genauigkeit wie möglich in der Notfallwiederherstellungsfarm aufrechtzuerhalten, können regelmäßige Sicherungen und Wiederherstellungen ausgeführt werden. Mögliche Szenarien sind tägliche oder wöchentliche Sicherungs- und Wiederherstellungsvorgänge zusammen mit Durchforsten schreibgeschützter Datenbanken, um die Aktualität möglichst nahe bei 100 Prozent aufrechtzuerhalten. Wenn der Suchindex allerdings so groß ist, dass die Wiederherstellung viele Stunden dauert, werden dadurch wiederum die RTO/RPO-Ziele gefährdet.

Der kombinierte Ansatz ist eindeutig komplexer als eine einfache Sicherung und Wiederherstellung. Die Vorteile überwiegen jedoch die Probleme, sofern die geschäftlichen Anforderungen die Voraussetzungen zum Implementieren einer solchen Lösung erfüllen.

Zusätzliche Ressourcen

Weitere Informationen finden Sie in den folgenden Ressourcen.

• Sichern von Suchdienstanwendungen in SharePoint Server

• Wiederherstellen von Suchdienstanwendungen in SharePoint Server

Neben den Optionen in diesen Artikeln und in diesem Dokument gibt es weitere Methoden zum Sichern und Wiederherstellen der Suchdienstanwendung in SharePoint Server. Diese Methoden sind genauer abgestimmt und umfassen die unabhängige Wiederherstellung der Suchindizes und Suchdatenbanken in einer neuen Farm. Wir haben diese Verfahren nicht behandelt, aber wenn Sie einen Skriptansatz in Betracht ziehen, ist es ratsam, zunächst die folgenden Ressourcen zu lesen.

• Get-SPEnterpriseSearchServiceApplicationBackupStore

• Restore-SPEnterpriseSearchServiceApplication

• Restore-SPEnterpriseSearchServiceApplicationIndex

• Sichern und Wiederherstellen einer Suchdienstanwendung in SharePoint 2013 mit VSS.

Verwandte Themen

Planen von hoher Verfügbarkeit und Notfallwiederherstellung für SharePoint Server