Neugestaltung der Unternehmenssuchetopologie für mehr Inhalte und Benutzer in SharePoint
GILT FÜR:
2013 2016 2019 Subscription Edition 
SharePoint in Microsoft 365
Im Laufe der Zeit wachsen die meisten Suchumgebungen bei der Menge der Inhalte und der Anzahl der Benutzer. An einem bestimmten Punkt sind Kapazität und Leistung Ihrer Sucharchitektur diesem Anstieg nicht mehr gewachsen. Die Lösung heißt Skalierung der Topologie Ihrer Sucharchitektur:
Umgestalten der Topologie (dieser Artikel)
Implementieren der umgestalteten Topologie (Verwalten der Suchtopologie in SharePoint Server)
Sind Sie mit den Komponenten des Suchsystems in SharePoint Server und deren Interaktion vertraut? Bevor Sie dieses Projekt in Angriff nehmen, sollten Sie zunächst den Artikel Übersicht über die Sucharchitektur in SharePoint Server lesen und sich die PDF-Datei Search architectures for SharePoint Server 2016 (oder die Datei Sucharchitekturen für SharePoint Server 2013) ansehen, um sich mit den verschiedenen Sucharchitekturen und Suchkomponenten, den Suchdatenbanken und der Suchtopologie vertraut zu machen.
In diesem Artikel erfahren Sie Schritt für Schritt, wie Sie Ihre Suchtopologie neu gestalten.
Schritt 2: Auf welche Größe sollte die Sucharchitektur skaliert werden?
Schritt 3: Welche Hardwareanforderungen muss ich berücksichtigen?
Nachdem Sie diese Schritte ausgeführt haben, werden Sie Folgendes wissen:
Die Anzahl der einzelnen Typen von Suchkomponenten und Suchdatenbanken, die Ihre Topologie benötigt.
Die Anwendungs- und Datenbankserver, auf denen die einzelnen Suchkomponenten bereitgestellt werden sollen.
Welche Hardwareressourcen die einzelnen Anwendungsserver und Datenbankserver benötigen.
Schritt 1: Wie viel Inhalt ist vorhanden?
Die Menge an Inhalten, die im Suchindex vorhanden ist, bestimmt, welche Ressourcen zum Hosten der Farm erforderlich sind. Prüfen Sie, wie viele Elemente in Ihrer vorhandenen Suchumgebung durchsuchbar sind. Sie finden diese Nummer auf der Seite Suchverwaltung auf der Website der SharePoint-Zentraladministration. Klicken Sie zum Öffnen der Suchverwaltungsseite auf Dienstanwendungen in der Zentraladministration verwalten, und klicken Sie dann auf den Namen der Suchdienstanwendung.
Schätzen Sie ab, wie stark die Anzahl durchsuchbarer Elemente in den nächsten zwölf Monaten ansteigen wird, und planen Sie die Suchtopologie entsprechend dieser Zahl. Beispiel: Sie haben 8.000.000 indizierte Elemente, und Sie erwarten einen Anwachsen dieser Inhalte um 50 % in den nächsten zwölf Monaten. Sie sollten dann den Entwurf für 12.000.000 durchsuchbare Elemente auslegen..
Schritt 2: Auf welche Größe sollte die Sucharchitektur skaliert werden?
Es lässt sich nicht immer leicht einschätzen, wie groß oder klein eine Sucharchitektur werden soll. Die Größe Ihrer Sucharchitektur richtet sich nach der Inhaltsmenge, der Durchforstungsrate, dem Abfragedurchsatz und dem benötigten Hochverfügbarkeitsgrad. Microsoft stellt eine Reihe von getesteten Beispielsucharchitekturen bereit, die Sie als Grundlage für Ihre eigne Farm verwenden sollten. Vergleichen Sie Ihre aktuelle Sucharchitektur mit den Beispielarchitekturen, und legen Sie fest, welches Beispiel am meisten mit der aktuellen Sucharchitektur übereinstimmt. Überlegen Sie dann, auf welche Beispielsucharchitektur Sie skalieren möchten. Die Auswahl der Beispielsucharchitektur hängt davon ab, wie viele Inhalte durchsuchbar sein sollen:
| Inhaltsvolumen (SharePoint 2016) | Beispielsucharchitektur | Inhaltsvolumen (SharePoint 2013) |
|---|---|---|
| 0–20 Millionen Elemente | Kleine Suchfarm | 0–10 Millionen Elemente |
| 0–80 Millionen Elemente | Mittelgroße Suchfarm | 0–40 Millionen Elemente |
| 0–200 Millionen Elemente | Große Suchfarm | 0–100 Millionen Elemente |
| 0–500 Millionen Elemente | Sehr große Suchfarm | Nicht unterstützt |
Obwohl diese Beispielsucharchitekturen virtuelle Computer verwenden, können Sie sowohl physische Server als auch virtuelle Computer gemäß der Strategie der SharePoint Server-Gesamtlösung Ihrer Sucharchitektur verwenden.
Kleine Suchfarm
Wir haben geschätzt, dass mit dieser Sucharchitektur 50 Dokumente pro Sekunde durchforstet und etwa 10 Abfragen pro Sekunde verarbeitet werden können. Wenn Sie über bis zu 20 Millionen Elemente in einer SharePoint Server 2016-Farm verfügen, ist die kleine Suchfarm wahrscheinlich die am besten geeignete Farm für Sie. Bei einer Durchforstungsrate von 50 Dokumenten pro Sekunde dauert das Durchforsten von 20 Millionen Elementen bei der ersten vollständigen Durchforstung 110 Stunden.
Mittelgroße Suchfarm
Wir haben geschätzt, dass mit dieser Sucharchitektur 100 Dokumente pro Sekunde durchforstet und etwa 10 Abfragen pro Sekunde verarbeitet werden können. Wenn Sie zwischen 20 und 80 Millionen Elemente in einer SharePoint Server 2016-Farm haben, ist die mittlere Suchfarm wahrscheinlich die am besten geeignete Farm für Sie. Bei einer Durchforstungsrate von 200 Dokumenten pro Sekunde dauert das Durchforsten von 80 Millionen Elementen bei der ersten vollständigen Durchforstung 280 Stunden.
Große Suchfarm
Wir haben geschätzt, dass mit dieser Sucharchitektur 200 Dokumente pro Sekunde durchforstet und etwa 10 Abfragen pro Sekunde verarbeitet werden können. Wenn Sie über 80 bis 200 Millionen Elemente in einer SharePoint Server 2016-Farm verfügen, ist die große Suchfarm wahrscheinlich die am besten geeignete Farm für Sie. Bei einer Durchforstungsrate von 200 Dokumenten pro Sekunde dauert das Durchforsten von 200 Millionen Elementen bei der ersten vollständigen Durchforstung 280 Stunden.
Sehr große Suchfarm
Microsoft hat diese Sucharchitektur getestet und gemessen, dass 300–500 Dokumente pro Sekunde durchforstet und etwa 10 Abfragen pro Sekunde verarbeitet werden können. Nur SharePoint Server 2016 unterstützt diese Sucharchitektur. Bei bis zu 500 Millionen Elementen ist eine Farm ähnlich der sehr großen Suchfarm ein guter Ausgangspunkt. Bei einer Durchforstungsrate von 500 Dokumenten pro Sekunde dauert das Durchforsten von etwa 500 Millionen Elementen bei der ersten vollständigen Durchforstung 300 Stunden.
Zum Erstellen einer Suchfarm dieser Größe müssen Sie die Farm sorgfältig planen und optimieren, um die gewünschte Leistung zu erzielen. Möglicherweise ist es für Sie vorteilhaft, Rat von Experten einzuholen. Es ist auch wichtig zu planen, wie eine Suchfarm dieser Größe gesichert und wiederhergestellt wird und wie die Farm wiederhergestellt wird, wenn Ihr Rechenzentrum einen größeren Ausfall aufweist. Wir empfehlen, das Sichern und Wiederherstellen der Farm zu üben.
Schritt 3: Welche Hardwareanforderungen muss ich berücksichtigen?
Nachdem Sie nun das Volumen Ihrer Inhalte ermittelt und eine neue Topologie für den Wechsel ausgewählt haben, besteht der nächste Schritt darin, die Hardware zu planen, die Sie benötigen, wie in diesem Abschnitt beschrieben:
Auswählen, ob die Server physisch oder virtuell ausgeführt werden sollen
Auswählen der Unterstützung von hoher Verfügbarkeit durch die Sucharchitektur
Auswahl zwischen der physischen oder virtuellen Ausführung der Server
Bei der ursprünglichen Planung der Sucharchitektur haben Sie sich für physische Server oder virtuelle Maschinen oder beides entschieden. Überdenken Sie diese Entscheidung noch einmal, ist sie noch gültig? Beispiel: Wenn Sie von einer mittelgroßen zu einer großen Beispielsucharchitektur wechseln, mag es einfacher sein, die größere Anzahl Server als virtuelle Maschinen zu verwalten. Beachten Sie auch, dass eine virtuelle Umgebung einfacher zu verwalten ist, aber ihre Leistung könnte manchmal leicht unterhalb der einer physischen Umgebung liegen. Auf einem physischen Server können mehr Suchkomponenten gehostet werden als auf einem virtuellen Server. Nützliche Anleitungen finden Sie unter Overview of farm virtualization and architectures for SharePoint 2013.
Die Beispiele für kleine, mittlere, große oder extra große Sucharchitekturen werden auf virtuellen Computern ausgeführt, können aber auch auf physischen Servern ausgeführt werden. Verschieben Sie in den Beispielfarmarchitekturen einfach die Suchkomponenten von den virtuellen Computern auf den Hostserver, und entfernen Sie die virtuellen Computer. Jeder physische Server kann bis zu vier Indexkomponenten hosten, aber nur eine der einzelnen Typen der anderen Suchkomponenten. Wenn Sie beispielsweise die Mittlere Beispielsucharchitektur so ändern, dass physische Server verwendet werden, werden Sie feststellen, dass Sie über zwei Inhaltsverarbeitungskomponenten auf Host E verfügen. Die Lösung besteht darin, eine der Inhaltsverarbeitungskomponenten zu entfernen. Dies funktioniert, da die Durchforstung, die Verarbeitung von Inhalten und die Verarbeitung von Analysen von der Menge der verfügbaren Ressourcen und nicht von der Anzahl der Inhaltsverarbeitungskomponenten abhängen.
Auswählen der Hardwareressourcen für die Hostserver
Jede Suchkomponenten und Suchdatenbank erfordert für eine ordnungsgemäße Ausführung ein Mindestmaß an Hardwareressourcen auf dem Hostserver. Deshalb gilt: Je mehr Hardwareressourcen, desto besser die Leistung Ihrer Sucharchitektur. Deshalb ist es ratsam, über mehr als nur die Mindestmenge an Hardwareressourcen zu verfügen. Die Ressourcen, die jede Suchkomponente benötigt, hängt von der Verarbeitungslast ab, die zumeist anhand der Durchforstungsrate, der Abfragerate und der Anzahl indizierter Elemente bestimmt wird.
Beispiel: Beim Hosten virtueller Computer unter Windows Server 2008 R2 Service Pack 1 (SP1) sind nicht mehr als vier CPU-Kerne pro virtuellem Computer möglich. Von Windows Server 2012 und höher werden acht und mehr CPU-Kerne pro virtuellem Computer unterstützt. Anschließend können Sie eine horizontale Skalierung mit mehr CPU-Kernen pro virtuellem Computer anstatt eine vertikale Skalierung mit mehr virtuellen Computern vornehmen. Richten Sie Server oder virtuelle Computer, die dieselben Suchkomponenten hosten, mit denselben Hardwareressourcen ein. Lassen Sie uns als Beispiel die Indexkomponente betrachten. Wenn Sie Indexpartitionen auf virtuellen Computern hosten, bestimmt der virtuelle Computer mit der schwächsten Leistung die Leistung der gesamten Sucharchitektur.
Stellen Sie sicher, dass jeder Hostserver über genügend Speicherplatz für die Basisinstallation des Windows Server-Betriebssystems und für die SharePoint Server-Programmdateien verfügt. Außerdem muss auf dem Hostserver freier Festplattenspeicher für Diagnosefunktionen wie Protokollierung und Debugging, für das Erstellen von Speicherabbildern, für tägliche Vorgänge sowie für die Auslagerungsdatei vorhanden sein. Normalerweise reichen 80 GB Speicherplatz für das Windows Server-Betriebssystem und für die SharePoint Server-Programmdateien aus.
Fügen Sie auf jedem Datenbankserver Speicherplatz für den SQL-Protokollspeicher hinzu. Wenn Sie den Datenbankserver nicht so einrichten, dass die Datenbanken häufig gesichert werden, belegt der SQL-Protokollspeicher viel Speicherplatz. Weitere Informationen zur Planung von SQL-Datenbanken finden Sie unter Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server).
Der Mindestspeicher, den die Analyseberichtsdatenbank benötigt, kann variieren. Dies liegt daran, dass die Speichermenge davon abhängt, wie Benutzer mit SharePoint Server interagieren. Wenn Benutzer häufig interagieren, sind meist mehr Ereignisse zu speichern. Prüfen Sie die Menge an Speicher, die Ihre derzeitige Sucharchitektur für die Analysedatenbank verwendet, und weisen Sie Ihrer umgestalteten Topologie mindestens diese Menge zu.
Minimale Hardwareressourcen für die kleine Suchfarm
In dieser Tabelle wird die Mindestmenge an Hardwareressourcen angezeigt, die die einzelnen Anwendungsserver und Datenbankserver benötigen.
| Server | Auf dem Host | Speicherplatz | Arbeitsspeicher | Prozessor1 | Netzwerkbandbreite |
|---|---|---|---|---|---|
| Anwendungsserver mit Abfrageverarbeitung und Indexkomponenten | A, B | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8-fache CPU-Kerne2,3 | 1 Gbit/s |
| Anwendungsserver mit Durchforstungs-, Suchverwaltungs-, Analyse- und Inhaltsverarbeitungskomponenten. | A, B | 200 GB | 8 GB | 1,8 GHz, 4 CPU-Kerne | 1 Gbit/s |
| Datenbankserver mit allen Suchdatenbanken. | C, D | 100 GB | 16 GB | 1,8 GHz, 4 CPU-Kerne | 1 Gbit/s |
1Hier wird die Anzahl der Prozessorkerne und nicht die Anzahl der CPU-Threads angegeben.
arabische ZifferBei SharePoint Server 2013 sind mindestens 500 GB Speicher, 16 GB RAM und vier CPU-Kerne erforderlich.
3Mit SharePoint Server 2016 können Sie auch 250 GB Speicher, 16 GB RAM und vier CPU-Kerne verwenden, aber dann kann jede Indexkomponente nur 10 Millionen Elemente enthalten, und die Suchfarm unterstützt nur das gleiche Inhaltsvolumen wie eine SharePoint Server 2013-Suchfarm.
Minimale Hardwareressourcen für die mittelgroße Suchfarm
In dieser Tabelle wird die Mindestmenge an Hardwareressourcen angezeigt, die die einzelnen Anwendungsserver und Datenbankserver benötigen.
| Server | Auf dem Host | Speicherplatz | Arbeitsspeicher | Prozessor1 | Netzwerkbandbreite |
|---|---|---|---|---|---|
| Anwendungsserver mit Abfrageverarbeitung und Indexkomponenten | A, B, C, D | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8-fache CPU-Kerne2,3 | 1 Gbit/s |
| Anwendungsserver mit Indexkomponenten | A, B, C, D | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8-fache CPU-Kerne2,3 | 1 Gbit/s |
| Anwendungsserver mit Analyse- und Inhaltsverarbeitungskomponenten. | E, F | 300 GB | 8 GB | 1,8 GHz, 4 CPU-Kerne | 1 Gbit/s |
| Anwendungsserver mit Durchforstungs-, Suchverwaltungs- und Inhaltsverarbeitungskomponenten. | E, F | 100 GB | 8 GB | 1,8 GHz, 4 CPU-Kerne | 1 Gbit/s |
| Datenbankserver mit allen Suchdatenbanken. | G, H | 400 GB | 16 GB | 1,8 GHz, 4 CPU-Kerne | 1 Gbit/s |
1Hier wird die Anzahl der Prozessorkerne und nicht die Anzahl der CPU-Threads angegeben.
arabische ZifferBei SharePoint Server 2013 sind mindestens 500 GB Speicher, 16 GB RAM und vier CPU-Kerne erforderlich.
3Mit SharePoint Server 2016 können Sie auch 250 GB Speicher, 16 GB RAM und vier CPU-Kerne verwenden, aber dann kann jede Indexkomponente nur 10 Millionen Elemente enthalten, und die Suchfarm unterstützt nur das gleiche Inhaltsvolumen wie eine SharePoint Server 2013-Suchfarm.
Minimale Hardwareressourcen für die große Suchfarm
In dieser Tabelle wird die Mindestmenge an Hardwareressourcen angezeigt, die die einzelnen Anwendungsserver und Datenbankserver benötigen.
| Server | Auf dem Host | Speicherplatz | Arbeitsspeicher | Prozessor1 | Netzwerkbandbreite |
|---|---|---|---|---|---|
| Anwendungsserver mit Abfrageverarbeitungs- und Indexkomponenten | A, B, C, D, E, G, H | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8-fache CPU-Kerne2,3 | 1 Gbit/s |
| Anwendungsserver mit Indexkomponenten | A, B, C, D, E, F, G, H, I, J | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8-fache CPU-Kerne2,3 | 1 Gbit/s |
| Anwendungsserver mit Analyse- und Inhaltsverarbeitungskomponenten | K, L, M, N | 300 GB | 8 GB | 1,8 GHz, 4 CPU-Kerne | 1 Gbit/s |
| Anwendungsserver mit Durchforstungs- und Suchverwaltungskomponenten | K, L | 100 GB | 8 GB | 1,8 GHz, 4 CPU-Kerne | 1 Gbit/s |
| Datenbankserver mit Suchdatenbanken | O, P, Q, R | 500 GB | 16 GB | 1,8 GHz, 4 CPU-Kerne | 1 Gbit/s |
arabische ZifferBei SharePoint Server 2013 sind mindestens 500 GB RAM, 16 GB RAM und vier CPU-Kerne erforderlich.
3Mit SharePoint Server 2016 können Sie auch 250 GB Speicher, 16 GB RAM und vier CPU-Kerne verwenden, aber dann kann jede Indexkomponente nur 10 Millionen Elemente enthalten, und die Suchfarm unterstützt nur das gleiche Inhaltsvolumen wie eine SharePoint Server 2013-Suchfarm.
Minimale Hardwareressourcen für die sehr große Suchfarm
In dieser Tabelle wird die Mindestmenge an Hardwareressourcen angezeigt, die die einzelnen Anwendungsserver und Datenbankserver benötigen. Sie können diese Beispielfarm nur mit SharePoint Server 2016 erstellen.
| Server | Auf dem Host | Speicherplatz | Arbeitsspeicher | Prozessor1 | Netzwerkbandbreite |
|---|---|---|---|---|---|
| Anwendungsserver mit Indexkomponenten | A-X | 500 GB | 32 GB | 1,8 GHz, 8 CPU-Kerne | 1 Gbit/s |
| Anwendungsserver mit Abfrageverarbeitungs- und Indexkomponenten | Y, Z | 500 GB | 32 GB | 1,8 GHz, 8 CPU-Kerne | 1 Gbit/s |
| Anwendungsserver mit Durchforstungs-, Suchverwaltungs- oder Inhaltsverarbeitungskomponenten | AA-AF | 100 GB | 8 GB | 1,8 GHz, 4 CPU-Kerne | 1 Gbit/s |
| Anwendungsserver mit Analyseverarbeitungskomponenten | AG, AH | 800 GB | 8 GB | 1,8 GHz, 4 CPU-Kerne | 1 Gbit/s |
| Datenbankserver mit Suchdatenbanken | AI-AL | 500 GB | 16 GB | 1,8 GHz, 4 CPU-Kerne | 1 Gbit/s |
1Hier wird die Anzahl der Prozessorkerne und nicht die Anzahl der CPU-Threads angegeben.
Planen der Speicherleistung
Die Speichergeschwindigkeit hat Einfluss auf die Suchleistung. Stellen Sie sicher, dass der von Ihnen verwendete Speicher schnell genug ist, um den Datenverkehr der Suchkomponenten und -datenbanken zu verarbeiten. Die Datenträgergeschwindigkeit wird in E/A-Vorgängen pro Sekunde (I/O Operations Per Second, IOPS) gemessen.
Die Art und Weise, in der Daten von den Suchkomponenten und vom Betriebssystem auf den Speicher verteilt werden, hat Einfluss auf die Suchleistung. Daher sind die folgenden Maßnahmen sinnvoll:
Teilen Sie die Windows Server-Betriebssystemdateien, die SharePoint Server-Programmdateien und Diagnoseprotokolle auf drei separate Speichervolumes oder Partitionen mit normaler Leistung auf.
Speichern Sie die Daten der Suchkomponenten auf einem separaten Speichervolume oder einer separaten Partition. Für Indexkomponenten muss dieser Speicher auch eine hohe Leistung haben.
Hinweis
Sie können einen benutzerdefinierten Speicherort für Suchkomponentendaten festlegen, wenn Sie SharePoint Server auf einem Host installieren. Suchkomponenten auf dem Host, die Daten speichern müssen, speichern diese an diesem Speicherort. Um diesen Speicherort später zu ändern, müssen Sie SharePoint Server neu installieren.
Auswählen des Speichertyps
Eine Übersicht über Speicherarchitekturen und Datenträgertypen finden Sie unter Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server 2013). Die Server, auf denen die Index-, Analyseverarbeitungs- und Suchverwaltungskomponenten oder Suchdatenbanken gehostet werden, erfordern einen Speicher, der geringe Wartezeiten und gleichzeitig genügend E/A-Vorgänge pro Sekunde (IOPS) ermöglicht. In den folgenden Tabellen wird angegeben, wie viele IOPS die einzelnen Suchkomponenten und -datenbanken erfordern.
Wenn Sie gemeinsam genutzten Speicher wie SAN/NAS bereitstellen, fällt die Spitzenauslastung einer Suchkomponente in der Regel mit der Spitzenauslastung einer anderen Suchkomponente zusammen. Zur Ermittlung der vom gemeinsam genutzten Speicher für die Suchkomponenten erforderlichen IOPS müssen Sie die IOPS-Anforderungen der einzelnen Komponenten addieren.
IOPS-Anforderungen der Suchkomponenten
| Komponentenname | Komponentendetails | IOPS-Anforderungen | Verwendung separater Speichervolumes/Partitionen |
|---|---|---|---|
| Indexkomponente | Verwendet den Speicher beim Zusammenführen des Indexes und beim Verarbeiten und Beantworten von Abfragen | 300 IOPS für zufällige Lesevorgänge (64 KB) 100 IOPS für zufällige Schreibvorgänge (256 KB) 200 MB/s für sequenzielle Lesevorgänge 200 MB/s für sequenzielle Schreibvorgänge |
Ja |
| Analysekomponente | Analysiert Daten lokal, Massenverarbeitung | Nein | Ja |
| Durchforstungskomponente | Speichert heruntergeladene Inhalte lokal, bevor sie an eine Inhaltsverarbeitungskomponente gesendet werden. Der Speicher wird durch die Netzwerkbandbreite begrenzt. | Nein | Ja |
IOPS-Anforderungen an die Suchdatenbanken
| Datenbankname | IOPS-Anforderungen | Standardauslastung des E/A-Subsystems |
|---|---|---|
| Durchforstungsdatenbank | Durchschnittliche bis viele IOPS | 10 IOPS bei einer Durchforstungsrate von 1 Dokument pro Sekunde (DPS) |
| Linkdatenbank | Durchschnittliche IOPS | 10 IOPS pro 1 Mio. Elemente im Suchindex |
| Suchverwaltungsdatenbank | Wenige IOPS | Nicht zutreffend |
| Analyseberichtsdatenbank | Durchschnittliche IOPS | Nicht zutreffend |
Auswählen der Unterstützung von hoher Verfügbarkeit durch die Sucharchitektur
Wenn Sie mit Strategien für Hochverfügbarkeit nicht vertraut sind, finden Sie hier einen Artikel zum Einstieg: Erstellen einer Hochverfügbarkeitsarchitektur und -strategie für SharePoint Server. Wenn Sie redundante Suchkomponenten und Datenbanken in separaten Fehlerdomänen hosten, fällt bei einem Ausfall eines Teils der Farm nicht der gesamte Dienst aus. Die Suchleistung wird hingegen beeinträchtigt, da die Suchkomponenten die Last nicht mehr teilen. Um die Wahrscheinlichkeit des Verlusts eines einzelnen Servers zu verringern, ist es ratsam, die lokale Redundanz zu verbessern. Gehen Sie bei jedem Hostserver in Ihrer Sucharchitektur wie folgt vor:
Verwenden Sie RAID-Speicher auf jedem Server.
Installieren Sie mehrere redundante Netzwerkverbindungen auf jedem Server.
Installieren Sie für jeden Server mehrere redundante Stromversorgungseinheiten mit stehender Verdrahtung oder eine unterbrechungsfreie Stromversorgung (USV).
In allen Beispielsucharchitekturen werden redundante Suchkomponenten auf unabhängigen Servern gehostet. In diesen Architekturen ist der rechte Host in jedem Hostpaar redundant. Es folgt eine große Sucharchitektur mit hervorgehobenen redundanten Hosts:
