Bewährte Methoden und Strategien für die Notfallwiederherstellung für die SharePoint-Suche

GILT FÜR:2013 2016 2019 Subscription Edition SharePoint in Microsoft 365

Erfahren Sie, wie Sie die Notfallwiederherstellung mit bewährten Methoden für die Suche in einer SharePoint Server-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 der Ansätze, die in früheren Versionen von SharePoint Server für die Notfallwiederherstellung verwendet wurden, bieten nicht das gleiche Wiederherstellungsniveau für SharePoint Server. Wir untersuchen diese Methoden und beschreiben Ersatzoptionen zusammen mit den jeweiligen Vorteilen und Einschränkungen, die Sie kennen müssen.

Einführung

Dieser Artikel überbrückt die Lücke zwischen der Dokumentation, die eine Roadmap für die Implementierung einer Strategie für die Notfallwiederherstellung enthält, und der Dokumentation, die Ihnen die spezifischen Befehle zum Konfigurieren der Notfallwiederherstellung für die SharePoint ServerSearch Service Application (SSA) bereitstellt. Wir beschreiben mehrere typische Notfallwiederherstellungsszenarien und untersuchen die Vorteile und Einschränkungen der einzelnen Ansätze. Es ist unrealistisch zu glauben, dass diese Szenarien perfekt für Ihre Organisation geeignet sind, aber Sie können sie als Leitfaden für eine Notfallwiederherstellungsstrategie verwenden, die die spezifischen Anforderungen Ihrer Organisation erfüllt.

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

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

• Mit der Option für duale Durchforstung durchforstet die Wiederherstellungsfarm auch die Produktionsfarm, sodass derselbe Inhalt ermittelt und indiziert wurde. Konfigurationsänderungen an verwalteten Eigenschaften oder durchforsteten Dateitypen, installierten IFiltern usw. mussten sowohl in Produktions- als auch in Notfallwiederherstellungsfarmen implementiert werden, aber dies konnte problemlos mithilfe einer geeigneten Änderungssteuerungsrichtlinie verwaltet werden.

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 Sicherungsansätzen gesichert und in der DR-Farm verwendet, um mithilfe von 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. Eine vollständige SSA-Sicherung und -Wiederherstellung erfolgt mithilfe von Microsoft PowerShell oder über die Websiteoberfläche der SharePoint-Zentraladministration. Dadurch werden die Datenbanken und Suchindizes der SSA gesichert, sodass sie in der Notfallwiederherstellungsfarm wiederhergestellt werden können, um die SSA dort aufzufüllen.

Ab SharePoint Server 2013 bedeuten erhebliche Änderungen in der Sucharchitektur und wie Konfigurationselemente gespeichert werden, dass wir bei der Notfallwiederherstellung für Die Suche anders denken müssen. 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. Die neuen Konfigurationsoptionen für Websites und Websitesammlungen bedeuten, dass Websiteadministratoren Änderungen an der Suchkonfiguration vornehmen können, die zuvor nur von Farm- oder Suchadministratoren vorgenommen 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 eine Konfigurationsänderung an einem Suchelement vornehmen, z. B. Abfrageregeln oder Ergebnisquellen, aus der Liste unter Websitesammlungsverwaltung oder Suche, und das Ergebnis ist identisch. Der Speicherort einer Änderung wirkt sich jedoch direkt auf die Notfallwiederherstellung aus. Alle In einer Websitesammlung oder Webanwendung vorgenommenen Änderungen werden nur in der Verwaltungsdatenbank der Suchdienstanwendung (Search Service Application, SSA) gespeichert. Wenn diese Datenbank nicht aus einer Sicherung in der Notfallwiederherstellungsfarm wiederhergestellt wird, sind Konfigurationsänderungen in der wiederhergestellten Umgebung nicht verfügbar.

Ein weiteres neues Feature in der SharePoint Server-Suche ist die Funktion Jetzt neu indizieren, mit der Administratoren auf websitesammlungs-, Web- und Listenebenen während der nächsten Durchforstung eine Neuindizierung des Containers anfordern können. Dieses Feature wird vollständig in der Inhaltsdatenbank verwaltet. Daher löst ein Administrator, der dies innerhalb der Notfallwiederherstellungsfarm anfordert, das gleiche 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 Sie den Ansatz einer vollständigen Suchdienst Anwendungssicherung und -wiederherstellung als Dr.-Strategie übernehmen, wird RPO insgesamt von zwei Dingen gesteuert. Die Zeit seit der letzten vollständigen Dienstanwendungssicherung ist das RPO, und die Zeit, die zum Tatsächlichen Durchführen einer Dienstanwendungswiederherstellung benötigt wird, ist die RTO. Beide Zeiten werden wahrscheinlich länger, wenn der indizierte Inhalt in der Suchdienst Anwendung zunimmt. Daher ist eine sorgfältige Verwaltung der Erwartung für die Dienstwiederherstellung im Falle einer Notfalldeklaration erforderlich. Es wird empfohlen, häufige Testwiederherstellungen im Rahmen Ihrer Übungen zur Verwaltung der Dienstkontinuität durchzuführen, um sicherzustellen, dass alle SLA für erforderliche RTO und RPO weiterhin erfüllt werden können. In der folgenden Tabelle sind die Sicherungs- und Wiederherstellungsoptionen für die Suchdienst-Anwendung zusammengefasst.

Unterstützte Techniken für die Wiederherstellung

Es gibt nur ein unterstütztes Notfallwiederherstellungsverfahren, das eine vollständige Wiederherstellung ermöglicht, einschließlich aller Verbesserungen der Analyseverarbeitung am Suchindex und allen Suchkonfigurationselementen auf Dienstanwendungs-, Websitesammlungs- und Webebene innerhalb der Produktionsfarm. Dieser Ansatz erfordert eine vollständige Sicherung der Suchdienst Anwendung gefolgt von einer vollständigen Wiederherstellung der Dienstanwendung in der Notfallwiederherstellungsfarm. Die Indizes und die Konfiguration werden auf denselben Zeitpunkt wiederhergestellt, zu dem die Sicherung erstellt wurde. Wenn die Sicherung also mehrere Tage alt war, ist eine neue Durchforstung erforderlich, um die Indizes auf den neuesten Stand zu bringen. Die spezifischen 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.

Unter Berücksichtigung all dieser Dinge lohnt es sich, die erwarteten RPO- und RTO-Anforderungen der Suchdienst Anwendung zu untersuchen. Derzeit unterstützt SharePoint eine RPO und eine RTO von einer Woche für die Suchdienstanwendung. Wenn Sie sich überlegen, was dies bedeutet, bedeutet dies, dass Konfigurationselemente, verarbeitete Informationen und Die Aktualität der Suche bei einer Wiederherstellung maximal eine Woche veraltet sein können. Abhängig von der erwarteten Änderungsrate in der Umgebung und der Wichtigkeit der Sucheinrichtung kann es ratsam sein, tägliche oder sogar untergeordnete Sicherungen durchzuführen, um sicherzustellen, dass ein optimales RPO und RTO für das Unternehmen erreicht werden können. Es ist nicht erforderlich, mehrere Sicherungskopien wie bei Inhaltssicherungen zu verwalten, da der Suchinhalt sehr flüssig und vorübergehend ist, sodass höchstens eine oder zwei vollständige Sicherungen beibehalten werden.

Sicherung und Wiederherstellung der Dienstanwendung

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

• Sichern von Suchdienstanwendungen in SharePoint Server

• Wiederherstellen von Suchdienstanwendungen in SharePoint Server

Die Häufigkeit, mit der Suchdienstsicherungen erstellt werden müssen, wird von vielen Dingen beeinflusst, aber in erster Linie ist die vom Unternehmen erforderliche RPO der wichtigste Treiber. Wenn der Suchindex größer wird, wird die Zeit, die zum Sichern und Wiederherstellen der Dienstanwendung benötigt wird, länger und länger. Es kann jeweils nur eine Suchsicherung ausgeführt werden, und die Zeit bis zum Abschluss der Sicherung ist die minimale RPO, die erreicht werden kann. Die Dauer für die Wiederherstellung in der Notfallwiederherstellungsfarm ist daher die minimale RTO, die erreicht werden kann, und wie die Sicherungszeit verlängert sich dies im Laufe der Zeit. Wenn die Sicherungs- oder Wiederherstellungszeiten in die erforderlichen Vereinbarungen zum Servicelevel (SLAs) für RPO und RTO für die Suche eingegriffen werden, muss das Unternehmen einige Entscheidungen treffen, um einen flexibleren, wenn weniger genauigkeitsbasierten Ansatz zu verfolgen, wie hier weiter unten beschrieben, oder die SLAs anpassen, um ein erreichbares 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 ist 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 Suchdienst Anwendung mit dem Namen Contoso Search Service Application erstellt und die Sicherungsdateien im Speicherort \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 Statusangaben 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

Um eine SharePoint Server Suchdienst Anwendung wiederherzustellen, muss die Sicherung erfolgreich abgeschlossen sein. Wenn Sicherungen häufig erstellt werden, ist die ID der wiederherzustellenden Sicherung erforderlich. Diese ID kann einfach auf verschiedene Arten abgerufen werden. Am einfachsten öffnen Sie die Seite Sicherungs- und Wiederherstellungsverlauf in der Produktionsfarm, in der die Sicherung erstellt wurde, und geben Sie den Speicherort des Sicherungsverzeichnisses ein. Dadurch wird eine Liste aller Einträge in der Sicherungs- und Wiederherstellungsmanifestdatei (psbrtoc.xml) bereitgestellt. Im folgenden Screenshot ist die Sicherungs-ID {149fc816-8927-4a32-9437-6e05c2869ab7} leicht zu sehen.

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 Get-SPBackupHistory Cmdlets, das auch die gleichen Informationen wie die spbrtoc.xml-Datei bereitstellen kann.

Die nächsten beiden Beispiele zeigen, wie der Wiederherstellungsvorgang mithilfe des Restore-SPFarm Cmdlets 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 RestoreMethod von Ihnen verwendete bestimmt, wie der Prozess nach der Ausführung des Restore-SPFarm Cmdlets ablaufen soll.

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.

Wenn das Durchforsten schreibgeschützter Datenbanken in der Notfallwiederherstellungsfarm die bevorzugte Wahl ist, müssen Sie berücksichtigen, dass Änderungen in der Produktionsfarm nicht in die Wiederherstellungsfarm repliziert werden. Wie bereits erwähnt, umfasst dies die Analyseaktualisierungen des Suchdiensts für den Index und Änderungen an Konfigurationselementen wie Ergebnisquellen, Abfrageregeln und Schemaänderungen. Wenn Sie einen kombinierten Ansatz verfolgen, ist es sehr wichtig, alle Auswirkungen zu verstehen und eine geeignete Strategie zu entwickeln. Derzeit gibt es keine unterstützte Möglichkeit, den Verlust der Analyseupdates zu umgehen, aber es können Schritte unternommen werden, um Updates von Konfigurationsänderungen zu umgehen. Sie können Aktionen wie in den folgenden Beispielen ausprobieren.

Stellen Sie sicher, dass alle benutzerdefinierten Ergebnisquellen, Abfrageregeln und Änderungen des Suchschemas, die als unternehmenskritisch betrachtet werden, auf der Ebene der Suchdienstanwendung in der Zentraladministration und nicht innerhalb von Websitesammlungen oder Unterwebsites vorgenommen werden. 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 beispielsweise Konfigurationselemente von der Website exportiert.http://intranet.contoso.com" in eine XML-Datei mit dem Namen intranetcontosocom.xml. Dieser Ansatz wurde in der SharePoint-Community veröffentlicht und wird mit deren Erlaubnis verwendet. Sie können diesen Blogbeitrag unter Importieren und Exportieren von Suchkonfigurationseinstellungen in SharePoint 2013 anzeigen.

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 das Durchforsten der schreibgeschützten Datenbanken und die regelmäßige Aktualisierung der Siteübersicht kann in der Notfallwiederherstellungsfarm ein hohes Maß an Indexaktualisierung beibehalten werden. Die zweite Phase des kombinierten Ansatzes besteht darin, was mit den Suchdienst Anwendungssicherungen zu tun ist. Es gibt hier zwei echte Optionen, die in der folgenden Liste angezeigt werden, aber beachten Sie, dass die ausgewählte Auswahl von den Anforderungen des Unternehmens 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 mithilfe von VSS