Planen der Architektur der Unternehmenssuche in SharePoint Server 2016

 

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

**Letztes Änderungsdatum des Themas:**2017-09-08

Zusammenfassung: Hier finden Sie Informationen zum Planen einer Architektur für die Unternehmenssuche.

Bevor Sie Ihre Architektur für die Unternehmenssuche einrichten, müssen einige Dinge sorgfältig geplant werden. Wir unterstützen Sie Schritt für Schritt beim Planen einer kleinen, mittleren, großen oder sehr großen Architektur für die Unternehmenssuche.

Sind Sie mit den Komponenten des Suchsystems in SharePoint Server und mit deren Interaktionen vertraut? Lesen Sie die Artikel Übersicht über die Sucharchitektur in SharePoint Server und Sucharchitekturen für SharePoint Server 2016 (oder Sucharchitekturen für SharePoint Server 2013), bevor Sie beginnen, um sich mit Sucharchitekturen, Suchkomponenten, Suchdatenbanken und mit der Suchtopologie vertraut zu machen. Nachfolgend werden ein paar Vorschläge dazu aufgeführt, was Sie beim Planen einer Sucharchitektur berücksichtigen sollten:

1. Schritt 1: Wie viel Inhalt ist vorhanden?

2. Schritt 2: Welche Größe der Sucharchitektur für wie viel Inhalt?

3. Schritt 3: Welche Hardwareanforderungen muss ich berücksichtigen?

   • Auswählen, ob die Server physisch oder virtuell ausgeführt werden sollen

   • Auswählen der Hardwareressourcen für die Hostserver

   • Planen der Speicherleistung

   • Auswählen der Unterstützung von hoher Verfügbarkeit durch die Sucharchitektur

4. Schritt 4: Wie überprüfe ich die Leistung meiner Sucharchitektur?

   • Testen des E/A-Speichersubsystems

   • Testen der Suchleistung

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.

Beispiel: Wenn Sie mit 12.000 indizierten Elementen beginnen und erwarten, dass sich die Inhaltsmenge in den nächsten 12 Monaten verdreifacht, müssen Sie 36.000 durchsuchbare Elemente einplanen.

Schritt 2: Welche Größe der Sucharchitektur für wie viel Inhalt?

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 Beispielsucharchitekturen, deren Verwendung als Grundlage für die Planung Ihrer eigenen Farm empfohlen wird. Welche Beispielsucharchitektur Sie auswählen, ist von der Menge der durchsuchbaren Inhalte abhängig:

Inhaltsmenge (SharePoint 2016)	Beispielsucharchitektur	Inhaltsmenge (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

Im Rahmen dieser Beispielsucharchitekturen werden virtuelle Computer verwendet, Sie können jedoch entsprechend der Strategie der SharePoint Server-Gesamtlösung für Ihre Sucharchitektur sowohl physische Server als auch virtuelle Computer 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. Bei bis zu 20 Millionen Elementen in einer SharePoint Server 2016-Farm ist die kleine Suchfarm wahrscheinlich die für Sie am besten geeignete Farm. 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. Bei 20 bis 80 Millionen Elementen in einer SharePoint Server 2016-Farm ist die mittlere Suchfarm wahrscheinlich die für Sie am besten geeignete Farm. 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. Bei 80 bis 200 Millionen Elementen in einer SharePoint Server 2016-Farm ist die große Suchfarm wahrscheinlich die für Sie am besten geeignete Farm. 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 eine Sucharchitektur in dieser Größe. 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, die Sicherung und Wiederherstellung einer Suchfarm dieser Größe sowie die Wiederherstellung der Farm nach einem größeren Ausfall Ihres Rechenzentrums zu planen. 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 Hardwareressourcen für die Hostserver

  • Planen des allgemeinen Speichers für die Hostserver

  • Minimale Hardwareressourcen für die kleine Suchfarm

  • Minimale Hardwareressourcen für die mittelgroße Suchfarm

  • Minimale Hardwareressourcen für die große Suchfarm

  • Minimale Hardwareressourcen für die sehr große Suchfarm

• Planen der Speicherleistung

  • Auswählen des Speichers

    • IOPS-Anforderungen der Suchkomponenten

    • IOPS-Anforderungen an die Suchdatenbanken

• Auswählen der Unterstützung von hoher Verfügbarkeit durch die Sucharchitektur

Auswählen, ob die Server physisch oder virtuell ausgeführt werden sollen

Wenn Sie eine der Architekturen verwenden, die wir für Sie geschätzt haben, wird die Sucharchitektur auf virtuellen Computern ausgeführt. Beachten Sie außerdem, dass eine virtuelle Umgebung zwar einfacher zu verwalten ist, die Leistungsstufe aber geringfügig niedriger als mit einer physischen Umgebung sein kann. Ein physischer Server kann mehr Suchkomponenten auf demselben Server hosten als ein virtueller Server. Nützliche Hinweise hierzu finden Sie unter Übersicht über Farmvirtualisierung und -architekturen in SharePoint 2013.

Sie können die Sucharchitektur auch auf physischen Servern ausführen. Verschieben Sie in den Beispielfarmarchitekturen einfach die Suchkomponenten von den virtuellen Maschinen auf die Hostserver, und nehmen Sie die virtuellen Maschinen heraus. Jeder physische Server kann bis zu vier Indexkomponenten hosten, aber nur jeweils einen der anderen Suchkomponententypen. Wenn Sie beispielsweise die mittelgroße Sucharchitektur auf physische Server umrüsten, stellen Sie fest, dass Sie zwei Inhaltsverarbeitungskomponenten auf Host E haben. Die Lösung besteht darin, eine der Inhaltsverarbeitungskomponenten zu entfernen. Dies ist möglich, da die Durchforstung, Inhaltsverarbeitung und Analyseverarbeitung von der Anzahl der verfügbaren Ressourcen und nicht von der Anzahl der Inhaltsverarbeitungskomponenten abhängt.

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. Je mehr Hardwareressourcen Sie zur Verfügung stellen können, desto leistungsstärker wird Ihre Sucharchitektur sein. Daher ist es ratsam, mehr als das Mindestmaß an Hardwareressourcen bereitzustellen. Die Ressourcen, die jede Suchkomponente benötigt, hängt von der Arbeitslast ab, die wiederum durch die Durchforstungsrate, die Abfragerate und die Anzahl der indizierten Elemente bedingt 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 auf jedem Hostserver genügend Speicherplatz für die Basisinstallation des Windows Server-Betriebssystems und für die SharePoint Server-Programmdateien zur Verfügung steht. 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. In der Regel reicht ein Speicherplatz von 80 GB 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. Der Grund ist, dass die Speichermenge von der Anzahl der Benutzer abhängt, die 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	Processor1	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 beträgt die erforderliche Mindestressourcenmenge 500 GB RAM, 16 GB RAM und vier CPU-Kerne.

3 Bei SharePoint Server 2016 können Sie auch 500 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 die gleiche Inhaltsmenge 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	Processor1	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 beträgt die erforderliche Mindestressourcenmenge 500 GB RAM, 16 GB RAM und vier CPU-Kerne.

3 Bei SharePoint Server 2016 können Sie auch 500 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 die gleiche Inhaltsmenge 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	Processor1	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 beträgt die erforderliche Mindestressourcenmenge 500 GB RAM, 16 GB RAM und vier CPU-Kerne.

3 Bei SharePoint Server 2016 können Sie auch 500 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 die gleiche Inhaltsmenge 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. Diese Beispielfarm kann nur mit SharePoint Server 2016 erstellt werden.

Server	Auf dem Host	Speicher	RAM	Processor1	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 die 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. Wenn Sie diesen Speicherort später ändern möchten, müssen Sie SharePoint Server neu auf diesem Host 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, auf denen die Index- oder Analyseverarbeitungkomponenten oder Suchdatenbanken gehostet werden, erfordern einen Speicher, der geringe Wartezeiten und gleichzeitig genügend 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 noch nicht mit Strategien für hohe Verfügbarkeit vertraut sind, kann Ihnen der folgende Artikel den Einstieg erleichtern: 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:

1. Redundante Netzwerke

2. 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:

1. Ü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.

2. Stellen Sie die Sucharchitektur in einer Pilotumgebung bereit. Stellen Sie sicher, dass die Pilotumgebung die Produktionsumgebung widerspiegelt.

3. Testen Sie die Suchleistung der Pilotumgebung. Informationen hierzu finden Sie unter Testen der Suchleistung.

Eine Übersicht über die Ausführung allgemeiner 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 diese Tests mit dem SQLIO-Tool ausführen. Informationen hierzu finden Sie unter SQLIO Disk Subsystem Benchmark Tool.

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:

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

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

1. Erstellen Sie eine 1 GB große Testdatei, indem Sie den Befehl sqlio.exe -t32 -s1 -b256 1g ausführen. Mit diesem Befehl wird eine Datei mit dem Namen "1g" erstellt.

2. Speichern Sie die Testdatei auf dem zu testenden Speichergerät, beispielsweise auf der Festplatte von Host A in der mittelgroßen Farm.

3. Verketten Sie die Testdatei mit einer ausreichend (z. B. 256 GB) großen Testdatei. Führen Sie dazu den Befehl copy 1g+1g+1g+...+1g testfile aus.

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

In der nachstehenden Tabelle werden die zum Ausführen der einzelnen Tests zu verwendenden SQLIO-Befehle aufgeführt. Bei allen Befehlen wird davon ausgegangen, dass sich die Testdatei ("testfile") im aktuellen Verzeichnis befindet. Jeder Test wird 300 Sekunden ausgeführt.

Testnummer	Umfang	Befehl
1	64 KB-Lesevorgänge [IOPS]	sqlio.exe -kR -t4 -o25 -b64 -frandom -s300 testfile
2	256 KB-Schreibvorgänge [IOPS]	sqlio.exe -kW -t4 -o25 -b256 -frandom -s300 testfile
3	100 MB-Lesevorgänge [MB/s]	sqlio.exe -kR -t1 -o1 -b100000 -frandom -s300 testfile
4	100 MB-Schreibvorgänge [MB/s]	sqlio.exe -kW -t1 -o1 -b100000 -frandom -s300 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 die Tests auf leeren Datenträgern ausführen, erhalten Sie erhöhte Werte, weil die Testdatei die optimalen Spuren aller Spindeln durchläuft (kurze Taktzeiten). Dadurch kann die Leistung verdoppelt oder verdreifacht werden. Wenn Sie eine Festplatte testen, auf der freie Zugriffe auf nicht initialisiertem Speicherplatz oder Speicher mit Nullen (z. B. dynamische VHD-/VHDX-Dateien) optimiert werden, erhalten Sie unrealistisch hohe Werte. Verwenden Sie in diesem Fall eine sehr große Testdatei, die echte Daten enthält, statt eine synthetische Testdatei mit SQLIO-Befehlen 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)	1.181	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)	2.082	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)	3.763	595	1.173	1.181
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)	3.613	545	1.139	1.164
16 x 1 TB 7200 RPM NLSAS in RAID10 auf Dell H710-RAID-Controller (Stripe-Größe 256 KB, Blockgröße 64 KB)	4.030	1.146	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)	32.385	3.781	1.714	1.319
4 x SmartStorage Optimus 800 GB SSDs in RAID0 auf Dell H710-RAID-Controller (Stripe-Größe 256 KB, Blockgröße 64 KB)	31.747	7.149	1.643	1.798

Testen der Suchleistung

Hier finden Sie eine Prüfliste mit den Aufgaben zum Testen Ihrer Sucharchitektur:

1. Auswählen der zu testenden Inhalte

2. Auswählen der Begriffe und Ausdrücke zum Testen der Abfrageleistung

3. Messen der Suchleistung

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 auch Abfragen von 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 Werte von Suchleistungsmessungen in den Integritätsberichten für Durchforstungen und in den Integritätsberichten für Abfragen. 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, schlagen wir vor, den Speicherplatz der Analysedatenbank zu erweitern.