Planen der Unternehmenssucharchitektur in SharePoint Server
GILT FÜR:
2013 2016 2019 Subscription Edition 
SharePoint in Microsoft 365
Bevor Sie Ihre Architektur für die Unternehmenssuche einrichten, müssen einige Dinge sorgfältig geplant werden. Schritt für Schritt helfen wir Ihnen bei der Planung einer kleinen, mittleren, großen oder extra großen Unternehmenssucharchitektur.
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. Nachfolgend werden ein paar Vorschläge dazu aufgeführt, was Sie beim Planen einer Sucharchitektur berücksichtigen sollten:
Schritt 2: Wie groß ist die Sucharchitektur für wie viele Inhalte?
Schritt 3: Welche Hardwareanforderungen muss ich berücksichtigen?
Schritt 4: Wie überprüfe ich die Leistung meiner Sucharchitektur?
Schritt 1: Wie viel Inhalt ist vorhanden?
Die in Ihrem Suchindex enthaltene Inhaltsmenge hat Einfluss auf die zum Hosten der Farm erforderlichen Ressourcen. Ermitteln Sie die ungefähre Anzahl der durchsuchbaren Elemente. Beispiele für Elemente sind Dokumente, Webseiten, SharePoint-Listeneinträge und Bilder. Jeder Eintrag in einer SharePoint-Liste gilt als ein Element.
Wenn Sie eine Zahl ermittelt haben, multiplizieren Sie sie mit dem Wert der in den nächsten 12 Monaten erwarteten Zunahme dieser Inhalte.
Wenn Sie beispielsweise mit 12.000 indizierten Elementen beginnen und erwarten, dass sich das Volumen dieser Inhalte in den nächsten 12 Monaten verdreifachen wird. Sie sollten 36.000 durchsuchbare Elemente einplanen.
Schritt 2: Wie groß ist die Sucharchitektur für wie viele Inhalte?
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. Es gibt Beispiel-Sucharchitekturen, die wir als Grundlage für die Planung Ihrer eigenen Farm empfehlen. Welche Beispielsucharchitektur Sie auswählen, ist von der Menge der durchsuchbaren Inhalte abhängig:
| 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 die Inhaltsmenge bestimmt und eine Beispielsucharchitektur ausgewählt haben, besteht der nächste Schritt darin, die erforderliche Hardware gemäß der Beschreibung in diesem Abschnitt zu planen:
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
Wenn Sie eine der Architekturen verwenden, die wir für Sie geschätzt haben, führen Sie Ihre Sucharchitektur auf virtuellen Computern aus. Beachten Sie jedoch, dass obwohl eine virtuelle Umgebung einfacher zu verwalten ist, ihr Leistungsgrad mitunter geringfügig niedriger ist als der einer physischen Umgebung ist. 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.
Es ist auch möglich, Ihre Sucharchitektur auf physischen Servern auszuführen. 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.
Allgemeiner Speicher
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 zum Planen 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 | Speicher | RAM | Prozessor1 | Netzwerkbandbreite |
|---|---|---|---|---|---|
| Anwendungsserver mit Abfrageverarbeitung und Indexkomponenten | A, B | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8x 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.
2 Bei SharePoint Server 2013 sind mindestens 500 GB Speicher, 16 GB RAM und vier CPU-Kerne erforderlich.
3 Mit 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 | Speicher | RAM | Prozessor1 | Netzwerkbandbreite |
|---|---|---|---|---|---|
| Anwendungsserver mit Abfrageverarbeitung und Indexkomponenten | A, B, C, D | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8x CPU-Kerne2,3 | 1 Gbit/s |
| Anwendungsserver mit Indexkomponenten | A, B, C, D | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8x 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.
2 Bei SharePoint Server 2013 sind mindestens 500 GB Speicher, 16 GB RAM und vier CPU-Kerne erforderlich.
3 Mit 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 | Speicher | RAM | Prozessor1 | Netzwerkbandbreite |
|---|---|---|---|---|---|
| Anwendungsserver mit Abfrageverarbeitungs- und Indexkomponenten | A, B, C, D, E, G, H | 500 GB2, 3 | 32 GB2, 3 | 1,8 GHz 8x 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 8x 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 |
1Hier wird die Anzahl der Prozessorkerne und nicht die Anzahl der CPU-Threads angegeben.
2 Bei SharePoint Server 2013 sind mindestens 500 GB Speicher, 16 GB RAM und vier CPU-Kerne erforderlich.
3 Mit 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 | Speicher | RAM | 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 Systemdateien des Windows Server-Betriebssystems, die SharePoint Server-Programmdateien und der 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 mit hoher Leistung.
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 auf diesem Host neu installieren.
Auswählen des Speichers
Eine Übersicht über Speicherarchitekturen und Datenträgertypen finden Sie unter Speicher- und SQL Server Kapazitätsplanung und -konfiguration (SharePoint Server). Die Server, die die Index- oder Analyseverarbeitungskomponenten hosten oder Datenbanken durchsuchen, benötigen Speicher, der eine geringe Latenz bei gleichzeitig ausreichenden E/A-Vorgängen pro Sekunde (IOPS) bietet. 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. Ihre Sucharchitektur unterstützt hohe Verfügbarkeit, wenn Sie redundante Suchkomponenten und -datenbanken in separaten Fehlerdomänen hosten. In allen Beispielsucharchitekturen werden redundante Suchkomponenten auf unabhängigen Servern gehostet.
Planen Sie für jeden redundanten Hostserver in Ihrer Sucharchitektur die Installation der folgenden Komponenten:
Redundante Netzwerke
Redundante Stromversorgungseinheiten mit stehender Verdrahtung oder eine unterbrechungsfreie Stromversorgung (USV)
Schritt 4: Wie überprüfe ich die Leistung meiner Sucharchitektur?
Bevor Sie Ihre Sucharchitektur in einer Produktionsumgebung bereitstellen, müssen Sie überprüfen, ob sie gut funktioniert. Hier finden Sie eine Prüfliste mit den auszuführenden Aufgaben:
Überprüfen Sie, ob die Indexkomponenten ein E/A-Speichersubsystem mit einer ausreichenden Anzahl von IOPS verwenden. Informationen hierzu finden Sie unter Testen des E/A-Speichersubsystems.
Stellen Sie die Sucharchitektur in einer Pilotumgebung bereit. Stellen Sie sicher, dass die Pilotumgebung die Produktionsumgebung widerspiegelt.
Testen Sie die Suchleistung der Pilotumgebung. Informationen hierzu finden Sie unter Testen der Suchleistung.
Eine Übersicht über allgemeine Tests in SharePoint finden Sie unter Leistungstests für SharePoint Server 2013.
Testen des E/A-Speichersubsystems
Führen Sie zum Testen des E/A-Speichersubsystems die wichtigsten Datenträgervorgänge aus, und ermitteln Sie die IOPS. Sie können das DiskSpd-Tool verwenden, um diese Tests auszuführen. Weitere Informationen finden Sie unter DiskSpd: Ein robustes Speicherleistungstool.
Einrichten der Testumgebung
Sie müssen nicht die gesamte Sucharchitektur einrichten oder SharePoint Server installieren. Die Einrichtung einer Testumgebung mit einer realistischen Arbeitsauslastung des E/A-Speichersubsystems reicht aus.
Wir ziehen hier einen lokalen Speicher in Betracht. Wenn Host A in der mittelgroßen Suchfarm beispielsweise einen lokalen Datenträger verwendet, müssen Sie die zwei virtuellen Computer installieren und die Tests der Datenträgervorgänge auf beiden virtuellen Computern gleichzeitig ausführen.
Für gemeinsam genutzten Speicher ist ein anderes Setup erforderlich. Wenn beispielsweise für die Arbeitsauslastungen aller Indexkomponenten in der mittelgroßen Suchfarm und für andere damit nicht zusammenhängende Arbeitsauslastungen derselbe Speicher gemeinsam genutzt wird, müssen Sie die folgenden Schritte ausführen:
Installieren Sie die acht virtuellen Computer auf Host A, B, C und D, und richten Sie die Quellen der damit nicht zusammenhängenden Arbeitsauslastungen ein.
Stellen Sie sicher, dass die nicht zusammenhängende Arbeitsauslastung auf dem gemeinsam genutzten Speicher zur selben Zeit stattfindet, zu der Sie die Tests der Datenträgervorgänge auf allen virtuellen Computern auf Host A, B, C und D gleichzeitig ausführen.
Erstellen einer Testdatei
Erstellen Sie mit dem Befehl
diskspd -c256G testfileeine Testdatei mit 256 GiBytes. Dieser Befehl erstellt eine 256 GiBytes-Datei mit dem Namen "testfile". Sie können auch eine Datei mit einer anderen Größe erstellen, indem Sie der Syntax folgen:diskspd -c<size>[K|M|G|b] <filename>Speichern Sie die Testdatei auf dem Speichergerät, das Sie testen möchten. Beispiel: auf der Festplatte von Host A in der mittleren Farm.
Starten Sie den Server neu. Dadurch wird sichergestellt, dass die Testergebnisse nicht durch Zwischenspeicherung verfälscht werden.
Ausführen von Tests
Die Messung der folgenden Faktoren ist sinnvoll:
Leistung der durchschnittlichen Anzahl zufälliger Zugriffe (siehe Testnummern 1 und 2 unten)
Durchsatz von Lese- und Schreibvorgängen bei großen Übertragungen (siehe Testnummern 3 und 4 unten)
Die folgende Tabelle zeigt die DiskSpd-Befehle, die Sie zum Ausführen der einzelnen Tests verwenden sollten. Bei allen Befehlen wird davon ausgegangen, dass sich die Testdatei ("testfile") im aktuellen Verzeichnis befindet. Jeder Test wird 300 Sekunden ausgeführt.
| Testnummer | Bereich | Get-Help |
|---|---|---|
| 1 | 64 KB-Lesevorgänge [IOPS] | diskspd -t4 -b64K -o25 -r -d300 testfile |
| 2 | 256 KB-Schreibvorgänge [IOPS] | diskspd -t4 -b256K -o25 -r -w100 -d300 testfile |
| 3 | 100 MB-Lesevorgänge [MB/s] | diskspd -t1 -o1 -b100M -r -d300 testfile |
| 4 | 100 MB-Schreibvorgänge [MB/s] | diskspd -t1 -o1 -b100M -r -w100 -d300 testfile |
Beispielergebnisse für lokalen Datenträgerspeicher
Die Beispielergebnisse in der nachstehenden Tabelle beziehen sich auf eine Bereitstellung, bei der die Kapazität des Datenträgersubsystems vor dem Hinzufügen der Testdatei zu mindestens 50 Prozent genutzt wurde.
Der Datenträgercontroller und die Spindeln des Datenträgers haben starken Einfluss auf diese Ergebnisse.
Wenn Sie auf leeren Datenträgern testen, erhalten Sie erhöhte Ergebnisse, da sich die Testdatei auf allen Spindeln in den optimalen Spuren befindet (kurzes Streichen). Dadurch kann die Leistung verdoppelt oder verdreifacht werden. Sie erhalten unrealistisch hohe Ergebnisse, wenn Sie eine Festplatte testen, die den Zugriff auf nicht initialisierten Speicherplatz optimiert, oder Speicher, der alle Nullen enthält, z. B. dynamische VHD/VHDX-Dateien. Verwenden Sie in diesem Fall eine sehr große Testdatei, die echte Daten enthält, anstatt mithilfe von DiskSpd-Befehlen eine synthetische Testdatei zu generieren.
| Datenträgerlayout | Test 1 | Test 2 | Test 3 | Test 4 | |
| Empfohlene IOPS-Mindestanzahl bei normalen Vorgängen | 300 | 100 | 200 | 200 | |
| 4 x 1 TB 7200 RPM NLSAS in RAID5 auf Dell H710-RAID-Controller (Stripe-Größe 64 KB, Blockgröße 64 KB) | 1181 | 206 | 284 | 296 | |
| 8 x 1 TB 7200 RPM NLSAS in RAID5 auf Dell H710-RAID-Controller (Stripe-Größe 64 KB, Blockgröße 64 KB) | 2082 | 337 | 610 | 645 | |
| 16 x 1 TB 7200 RPM NLSAS in RAID5 auf Dell H710-RAID-Controller (Stripe-Größe 64 KB, Blockgröße 64 KB) | 3763 | 595 | 1173 | 1181 | |
| 16 x 1 TB 7200 RPM NLSAS in RAID50 (2 x 8) auf Dell H710-RAID-Controller (Stripe-Größe 64 KB, Blockgröße 64 KB) | 3613 | 545 | 1139 | 1164 | |
| 16 x 1 TB 7200 RPM NLSAS in RAID10 auf Dell H710-RAID-Controller (Stripe-Größe 256 KB, Blockgröße 64 KB) | 4030 | 1146 | 970 | 775 | |
| 4 x SmartStorage Optimus 800 GB SSDs in RAID5 auf Dell H710-RAID-Controller (Stripe-Größe 64 KB, Blockgröße 64 KB) | 32385 | 3781 | 1714 | 1319 | |
| 4 x SmartStorage Optimus 800 GB SSDs in RAID0 auf Dell H710-RAID-Controller (Stripe-Größe 256 KB, Blockgröße 64 KB) | 31747 | 7149 | 1643 | 1798 |
Testen der Suchleistung
Hier finden Sie eine Prüfliste mit den Aufgaben zum Testen Ihrer Sucharchitektur:
Auswählen der zu testenden Inhalte
Wählen Sie Inhalte aus, die für die Produktionsinhalte repräsentativ sind. Wenn Sie Inhalte auswählen, die nur zu Testzwecken vorhanden sind, müssen Sie sicherstellen, dass Sie verschiedene Elementtypen und nicht nur ein einziges vielfach dupliziertes Element verwenden. Der Grund dafür ist, dass die Erkennung von duplizierten Elementen den Abfrageprozessor Zeit kostet, was sich wiederum auf die Suchleistung auswirkt, und die erzielten Ergebnisse wären für eine Produktionsumgebung nicht repräsentativ.
Richten Sie mindestens eine Inhaltsquelle zum Durchforsten des Inhalts ein. Stellen Sie sicher, dass Sie über das erforderliche Benutzerkonto und über Netzwerkzugriff verfügen.
Auswählen der Begriffe und Ausdrücke zum Testen der Abfrageleistung
Die Anzahl der Ergebnisse, die Sie für eine Abfrage erhalten, wird als Trefferquote bezeichnet.
Damit Sie die Abfrageleistung testen können, müssen Sie zuerst einen Satz von Begriffen und Ausdrücken erstellen, die als Abfragen verwendet werden sollen. Alternativ können Sie Abfragen aus einer vorhandenen Installation sammeln. Stellen Sie sicher, dass der Satz Begriffe und Ausdrücke mit niedriger und hoher Trefferquote enthält und dass die Begriffe und Ausdrücke für Ihre Umgebung relevant sind.
Beispiele
Wenn Sie in einem Produktkatalog nach einer Produktnummer suchen, gibt es wahrscheinlich für jedes Produkt nur eine Nummer. Daher liegen Ihnen die Suchergebnisse schnell vor. Dies entspricht einer niedrigen Trefferquote.
Wenn Sie im Intranet eines Unternehmens nach einem gängigen Begriff wie "Präsentation" suchen, erhalten Sie wahrscheinlich viele Ergebnisse, und die Suche dauert möglicherweise länger. Dies entspricht einer hohen Trefferquote.
Wenn sich Ihre Inhalte beispielsweise auf das Personalwesen beziehen, verwenden Sie Begriffe aus diesem Bereich.
Messen der Suchleistung
SharePoint Server sammelt Suchleistungsmessungen in den Durchforstungsintegritätsberichten und Abfrageintegritätsberichten. Sie finden diese Berichte in der Zentraladministration unter "Suchverwaltung".
Es ist sinnvoll, die Suchleistung zuerst anhand einer synthetischen Auslastung und dann mit einer kleinen Gruppe von Livebenutzern und Liveinhalten zu messen. Bei der Verwendung von Livebenutzern und Liveinhalten können Sie die Leistung der Sucharchitektur beobachten. Wenn die Inhalte schneller als geplant zunehmen, kann es sinnvoll sein, die Verwendung der nächst größeren Sucharchitektur in Erwägung zu ziehen. Wenn Ihre Benutzer aktiver sind als erwartet, empfehlen wir Ihnen, den Speicherplatz der Analysedatenbank zu erhöhen.