Empfehlungen für FAST Search Server 2010 for SharePoint

Werbung
Größentestbericht für sehr umfangreiche
Dokumentrepositorys
Dieses Dokument wird „wie besehen“ bereitgestellt. Die in diesem Dokument enthaltenen Informationen und
Ansichten, einschließlich URLs und Verweise auf Internetwebsites, können ohne vorherige Ankündigung geändert
werden. Das Risiko der Nutzung liegt bei Ihnen.
Einige der hier beschriebenen Beispiele dienen ausschließlich der Veranschaulichung und sind rein fiktiv. Eventuelle
Ähnlichkeiten mit realen Unternehmen, Organisationen, Produkten, Domänenamen, E-Mail-Adressen. Logos, Personen,
Orten oder Ereignissen sind Zufall und unbeabsichtigt.
Mit diesem Dokument erhalten Sie keine Rechte am geistigen Eigentum an einem Microsoft-Produkt. Sie sind berechtigt,
dieses Dokument zu kopieren und für eigene interne Referenzzwecke zu nutzen.
© 2011 Microsoft Corporation. Alle Rechte vorbehalten.
1
Größentestbericht für sehr umfangreiche
Dokumentrepositorys
Paul Andrew, Paul Learning, Barry Waldbaum, Frank Marasco
Microsoft Corporation
Oktober 2011
Gilt für: Microsoft® SharePoint® Server 2010, Microsoft FAST Search Server 2010 for SharePoint.
Zusammenfassung
In diesem Whitepaper finden Sie eine ausführliche Beschreibung eines Labortests, der bei Microsoft zur Darstellung des
Verhaltens von sehr umfangreichen SharePoint Server 2010-Inhaltsdatenbanken durchgeführt wurde. Es wird
beschrieben, wie zwei SharePoint Server-Inhaltsdatenbanken mit insgesamt 120 Mio. Dokumenten und über 30 TB an
SQL Server®-Datenbanken aufgefüllt wurden. Anschließend wird erklärt, wie diese Inhalte von FAST Search Server 2010
for SharePoint indiziert wurden. Ferner werden die Auslastungstests erläutert, die in der fertig gestellten SharePoint
Server- und FAST Search Server 2010 for SharePoint-Umgebung durchgeführt wurden, und die Ergebnisse aus diesen
Tests und die daraus resultierenden Schlussfolgerungen dokumentiert.
2
Inhalt
Einführung ............................................................................................................................................................................... 5
Testziele .............................................................................................................................................................................. 5
Beteiligte Hardwarepartner ................................................................................................................................................ 5
Definition der zu testenden Arbeitsauslastung ...................................................................................................................... 7
Beschreibung der Architektur für die horizontale Skalierung für Dokumentarchive ......................................................... 7
Die verwendeten Testtransaktionen .................................................................................................................................. 8
Definitionen der Testtransaktionen und Basiseinstellungen .............................................................................................. 8
Testbasismischung .............................................................................................................................................................. 9
Testreihe ........................................................................................................................................................................... 10
Testauslastung .................................................................................................................................................................. 12
Ressourcenerfassung während der Tests ......................................................................................................................... 12
Details zur Hardwarearchitektur der Testfarm ..................................................................................................................... 12
Virtuelle Server ................................................................................................................................................................. 15
Festplattenspeicher .......................................................................................................................................................... 16
SharePoint Server- und SQL Server-Architektur der Testfarm ............................................................................................. 18
IIS-Websites in der SharePoint-Farm ................................................................................................................................ 18
SQL Server-Datenbanken .................................................................................................................................................. 19
Inhaltsindizes in FAST Search Server 2010 for SharePoint ............................................................................................... 21
Methode, Projektzeitplan und Prozess für das Erstellen der Farm ...................................................................................... 21
Projektzeitplan .................................................................................................................................................................. 21
Wie die Beispieldokumente erstellt wurden .................................................................................................................... 22
Leistungscharakteristika für umfangreiche Dokumentladevorgänge............................................................................... 22
E/A-Vorgänge pro Sekunde (Input-Output Operations per Second, IOPS)....................................................................... 24
Durchforstung von Dokumenten in FAST Search Server 2010 for SharePoint ................................................................. 26
Testergebnisse ...................................................................................................................................................................... 28
Testreihe A – Benutzeranzahl verändern.......................................................................................................................... 28
Testreihe B – SQL Server-RAM verändern ........................................................................................................................ 31
Testreihe C – Anteil an Suchtransaktionen verändern ..................................................................................................... 34
Testreihe D – RAM für Front-End-Webserver verändern ................................................................................................. 37
Testreihe E – Anzahl der Front-End-Webserver verändern .............................................................................................. 39
Testreihe F – Anzahl der CPUs für SQL Server verändern ................................................................................................. 43
Test mit Service Pack 1 (SP1) und dem Kumulativen Update vom Juni............................................................................ 45
Sicherungen von SQL Server-Inhaltsdatenbanken............................................................................................................ 47
3
Schlussfolgerungen ............................................................................................................................................................... 47
Empfehlungen ....................................................................................................................................................................... 47
Empfehlungen zu SQL Server 2008 R2 .............................................................................................................................. 47
Empfehlungen zu SharePoint Server 2010 ....................................................................................................................... 47
Empfehlungen für FAST Search Server 2010 for SharePoint ............................................................................................ 48
Referenzen ............................................................................................................................................................................ 49
4
Einführung
Testziele
In diesem Whitepaper werden die Ergebnisse der umfangreichen Tests mit SharePoint Server beschrieben, die im
Juni 2011 bei Microsoft durchgeführt wurden. Das Ziel der Tests bestand darin, Anforderungen für die Skalierung von
Dokumentarchivrepositorys in SharePoint Server für eine hohe Speicherkapazität zu ermitteln und zu veröffentlichen.
Die Tests umfassten folgende Schritte: Erstellen einer großen Anzahl von typischen Dokumenten mit einer
Durchschnittsgröße von 256 KB, Laden dieser Dokumente in eine SharePoint-Farm, Erstellen eines FAST Search
Server 2010 for SharePoint-Index aus den Dokumenten und Ausführen von Tests mit Microsoft Visual Studio® 2010
Ultimate zum Simulieren der Nutzung. Mit diesen Tests wollten wir Verfahren sowohl für die vertikale als auch für die
horizontale Skalierung demonstrieren. Vertikale Skalierung bedeutet der Einsatz von zusätzlicher Hardwarekapazität zur
Erweiterung der Ressourcen und die Skalierung einer einzigen Umgebung, in unserem Fall einer SharePointInhaltsdatenbank. Eine SharePoint-Inhaltsdatenbank ist alle Websitesammlungen, alle Metadaten und alle diesen
Websitesammlungen zugeordneten BLOBs (Binary Large Objects), auf die von SharePoint Server zugegriffen wird.
Horizontale Skalierung bedeutet der Einsatz von mehreren Umgebungen, in unserem Fall mehrerer SharePointInhaltsdatenbanken. Dabei ist zu beachten, dass eine Inhaltsdatenbank nicht einfach eine SQL Server-Datenbank ist,
sondern auch verschiedene Konfigurationsdaten und etwaige Dokument-BLOBs enthält, unabhängig davon, wo diese
BLOBs gespeichert sind.
Die Arbeitsauslastung, die wir für diesen Bericht testeten, bezieht sich primär auf Dokumentarchive. Diese enthalten
eine große Anzahl von typischen Microsoft Office-Dokumenten, die zu Archivierungszwecken gespeichert werden.
Die Speicherung erfolgt in diesem Szenario typischerweise langfristig, wobei selten auf die gespeicherten Dokumente
zugegriffen wird.
Beteiligte Hardwarepartner
Diese Tests wurden durch die freundliche Unterstützung mehrerer Microsoft-Hardwarepartner ermöglicht.
NEC Corporation of America
NEC stellte einen NEC Express5800/A1080a (GX)-Server mit 8 CPUs (Prozessoren) und insgesamt 1 TB RAM zur
Verfügung. Jeder Prozessor enthielt 8 Prozessorkerne, insgesamt war der Server also mit 64 Kernen ausgestattet.
Wie unten beschrieben, wurde auf diesem Server Microsoft Hyper-V mit einer Reihe von virtuellen Computern
ausgeführt, aus denen die SharePoint Server- und FAST Search Server 2010 for SharePoint-Farmen gebildet wurden.
5
Abbildung 1 – NEC Express Server 5800
Quelle:
www.necam.com/servers/enterprise
Spezifikationen für den NEC Express 5800/A1080a-Server




8x Westmere-CPU (E7-8870), jeweils mit 10 Prozessorkernen
1 TB Arbeitsspeicher; jedes Prozessorspeichermodul hat 1 CPU (10 Kerne) und 16 DIMMs
2x Dual-Port 8 GB FC HBA
5 HDDs
Intel
Intel stellte einen zweiten NEC Express5800/A1080a-Server bereit, ebenfalls mit 8 CPUs (Prozessoren) und 1 TB RAM.
Dieser Computer wurde von Intel auf Westmere EX-CPUs aufgerüstet, jeweils mit 10 Kernen, sodass der Server
insgesamt mit 80 Kernen ausgestattet war. Wie weiter unten erläutert, wurden auf diesem Server Microsoft SQL Server
und FAST Search Server 2010 for SharePoint-Indexer direkt auf dem Computer ausgeführt, also ohne Hyper-V.
EMC
EMC stellte ein EMC VNX 5700-SAN mit einer 300 TB-Hochleistungsfestplatte zur Verfügung.
EMC VNX5700 Unified Storage
6
Quelle: http://www.emc.com/collateral/software/15-min-guide/h8527-vnx-virt-msapp-t10.pdf
Spezifikationen für das EMC VNX 5700:




2-TB-Laufwerke, 15 Laufwerke je 3U-DAE, 5 Einheiten = insgesamt 75 Laufwerke, 150 TB Rohspeicher
600-GB-Laufwerke, 25 Laufwerke je 2U-DAE, 10 Einheiten = insgesamt 250 Laufwerke, 150 TB Rohspeicher
2x Speicherprozessoren
2x BBUs (Backup Battery Units)
Definition der zu testenden Arbeitsauslastung
Mit der zugrunde gelegten Arbeitsauslastung sollten die Funktionen von SharePoint Server 2010 für umfangreiche
Dokumentarchive veranschaulicht werden. Charakteristisch für die Arbeitsauslastung durch Dokumentarchive ist die
große Anzahl an Dokumenten, die langsam aufgenommen werden, auf die selten zugegriffen wird und die so gut wie nie
aktualisiert werden.
FAST
Search-Index
Dokumente
Ablagedokumentbibliothek
Inhaltsweiterlei
tung
Archivinhaltsdatenbank(en)
Abbildung 2 – Arbeiten mit umfangreichen Dokumentarchiven
Beschreibung der Architektur für die horizontale Skalierung für Dokumentarchive
Für eine SharePoint-Farm mit mehreren Inhaltsdatenbanken wird Inhaltsweiterleitung empfohlen, damit Dokumente
von einer Erstablagebibliothek an die richtige Inhaltsdatenbank gesendet werden. In den Tests, die in diesem Bericht
beschrieben werden, haben wir keine Inhaltsweiterleitung konfiguriert und uns vielmehr auf die Skalierbarkeit und
Leistung der Installation konzentriert.
Während die Inhaltsweiterleitung für die Aufnahme von Dokumenten in eine von mehreren SharePointInhaltsdatenbanken verwendet wird, kann mit FAST Search Server 2010 for SharePoint ein Dokument optimal in einer
oder mehreren Inhaltsdatenbanken aufgefunden werden. FAST Search Server 2010 for SharePoint erstellt einen Index
mit allen Dokumenten aus allen Inhaltsdatenbanken, und in Suchläufen können Dokumente anhand von
Einschränkungen auf Basis von Metadaten nach Datum, Autor oder anderen Eigenschaften oder auch durch
Volltextsuche ausgewählt werden.
7
Die verwendeten Testtransaktionen
In diesem Whitepaper werden die Ergebnisse einer Reihe von Leistungstests geschildert, die mit SharePoint Server 2010
und FAST Search Server 2010 for SharePoint in einem Dokumentarchivszenario durchgeführt wurden. In diesem
Abschnitt wird die Testmethodik erläutert, die für die in diesem Whitepaper beschriebenen Tests angewendet wurde.
Abweichungen von dieser Methodik sind an den Stellen, an denen Daten präsentiert werden, entsprechend kenntlich
gemacht.
Arbeitsauslastung
Wichtig: Zu beachten ist, dass die spezifischen Kapazitäts- und Leistungsangaben in diesem Whitepaper von den Werten
in tatsächlichen Umgebungen abweichen. Die hier dargestellten Werte sollen Ihnen als Ausgangspunkt für den Entwurf
einer sinnvoll skalierten Umgebung dienen. Nachdem Sie einen ersten Systementwurf erstellt haben, testen Sie die
Konfiguration, um herauszufinden, ob das System die Faktoren in Ihrer Umgebung unterstützt.
Die Arbeitsauslastungen für die Tests wurden nach den Gesichtspunkten eines Speicherszenarios mit umfangreichen
Dokumentarchiven festgelegt und sollen Ihnen helfen, Schätzungen über das Verhalten von anderen
Farmkonfigurationen in Szenarien mit umfangreichen Dokumentrepositorys zu entwickeln.
Die in diesem Szenario beschriebene Testfarm wurde so konzipiert, dass sowohl eine horizontale als auch eine vertikale
Skalierung zum Zwecke der Kapazitätserweiterung bei Bedarf möglich war.
Die Skalierbarkeit ist für kleinere Implementierungen genauso entscheidend wie für Szenarien mit umfangreichen
Dokumentarchiven. Bei der horizontalen Skalierung können Sie einer oder mehreren Farmen weitere Server hinzufügen,
z. B. zusätzliche Front-End-Webserver oder Anwendungsserver. Die vertikale Skalierung ermöglicht eine Erhöhung der
Kapazität der vorhandenen Server durch Hinzufügen von schnelleren CPUs und/oder Arbeitsspeicher zur Steigerung des
Durchsatzes und der Leistung. Auch die Inhaltsweiterleitung sollte in Szenarios mit Archiven genutzt werden, damit die
Benutzer eine Datei einfach „ablegen“ können und diese dann ggf. anhand der Metadaten der Datei dynamisch an die
richtige Dokumentbibliothek und den richtigen Ordner weitergeleitet wird.
Definitionen der Testtransaktionen und Basiseinstellungen
In diesem Abschnitt werden die Testtransaktionen und andere Basiseinstellungen definiert. Außerdem wird ein
Überblick über den für das jeweilige Szenario verwendeten Testprozess gegeben. Ausführliche Informationen wie
Testergebnisse und spezifische Parameter erhalten Sie in den einzelnen Testergebnisabschnitten in diesem Whitepaper.
Basiselement
Beschreibung
Basiseinstellung
(oder Prozentsatz für
die Transaktion)
Dokument hochladen
Ein Dokument in eines der Dokumentcenter
hochladen. In jedem Dokumentcenter wurden pro
Stunde, 24 Stunden am Tag, ein eindeutiger Ordner
und eine eindeutige Datei erstellt.
1%
Dokument
herunterladen (öffnen)
Ein Dokument herunterladen oder öffnen.
30%
Durchsuchen
Auf eine zufällig gewählte DokumentcenterHomepage, Dokumentbibliothek-Listenansichtsseite
oder Ordner-Listenansichtsseite zugreifen.
40%
Suchen
Eine beliebige Suchabfrage an das FAST Search
30%
8
Center übermitteln.
Reaktionszeit
Die Zeit zwischen Transaktionen für jeden Benutzer.
Diese soll die Zeit darstellen, die ein Benutzer
zwischen Webseitenzugriffen mit Lesen oder
Denken verbringt.
10 Sekunden
Gleichzeitige Benutzer
Die Anzahl der Benutzer, die von Testagents zu den
SharePoint-Front-End-Webservern Verbindungen
zur SharePoint-Farm herstellen. Diese stellt keine
mögliche Gesamtbenutzerbasis dar, da in einer
typischen Umgebung nur ein kleiner Anteil der
Gesamtbenutzerzahl gleichzeitig auf das System
zugreift.
10.000
Testdauer
Die Dauer der Durchführung des Tests.
1 Stunde
WebZwischenspeicherung
Ob Web-Zwischenspeicherung für die Front-EndWebserver aktiviert ist oder nicht.
Aktiviert
FAST-Inhaltsindizierung
Ob FAST-Inhaltsindizierung während des Tests
ausgeführt wird oder nicht.
Angehalten
Anzahl der WFEs
Die Anzahl der Front-End-Webserver in der
SharePoint-Farm, die während des Tests eingesetzt
wurden.
3 pro
Inhaltsdatenbank
Benutzeraufstockung
Bei jedem Test wurde mit 1.000 Benutzern
begonnen, die dann in 100-Benutzer-Schritten auf
die endgültige Benutzerlast aufgestockt wurden.
Dabei wurde eine Aufstockungsdauer von
30 Sekunden und eine Schrittdauer von
10 Sekunden angewendet.
100 Benutzer alle
30 Sekunden
Testagents
Visual Studio 2010 Ultimate wurde zur Simulation
der Benutzertransaktionslast verwendet. Diese Last
wurde mithilfe von einem virtuellen Computer für
den Testcontroller und 19 virtuellen Computern für
die Testagents generiert.
19
Tabelle 1 – Testtransaktionen und Basiseinstellungen
Testbasismischung
In diesem Abschnitt werden die verwendeten Testmischungen definiert. Außerdem wird ein Überblick über die
Testergebnisse für die einzelnen Testmischungsszenarien gegeben.
Die Testmischung variierte für jeden Test, je nach den besonderen Test- und Lastzielen. Alle Tests wurden mithilfe von
Visual Studio 2010 Ultimate durchgeführt und waren aufgezeichnete, codefreie, ausschließlich von Visual Studio
generierte Skripts. Für jeden Test wurden spezifische Datenpunkte aufgefüllt. Anschließend wurde die Testmischung
über unterschiedliche Zeiträume und mit unterschiedlichen Anzahlen gleichzeitiger Benutzer ausgeführt, um Kapazitäten
und Grenzwerte der Farm zu ermitteln.
9
Hinweise
Alle Tests im Rahmen des Labors wurden mit 10 Sekunden Reaktionszeit durchgeführt. Die Reaktionszeit ist ein Feature
des Microsoft Visual Studio 2010 Ultimate-Testcontrollers, mit dem Sie die Zeit simulieren können, die ein Benutzer in
einer realen Umgebung zwischen Klicks auf einer Seite mit Denken oder Lesen verbringt.
Die Mischung der Vorgänge, die zur Messung der Leistung im Rahmen dieser Dokumentation herangezogen wurde, ist
„künstlich“. Sämtliche Ergebnisse sollen lediglich die Leistungscharakteristika in einer kontrollierten Umgebung unter
ganz bestimmten Bedingungen veranschaulichen. Diese Testmischungen zeichnen sich durch ein untypisch hohes
Volumen an Listenabfragen aus, die im Vergleich zu anderen Vorgängen große Mengen von SQL Server-Ressourcen
beanspruchen. Dies soll Ihnen als Ausgangspunkt für den Entwurf einer sinnvoll skalierten Umgebung dienen. Nachdem
Sie einen ersten Systementwurf erstellt haben, testen Sie die Konfiguration, um herauszufinden, ob Ihre spezifischen
Umgebungsvariablen und Vorgangskombinationen davon abweichen.
Testreihe
Es wurden sechs Testreihen durchgeführt, die mit A bis F bezeichnet wurden. Bei jeder Reihe wurde der Basistest mit
identischer Parameterkombination und Umgebung durchgeführt, wobei jedoch immer ein Parameter verändert wurde.
Die einzelnen Tests in jeder Reihe wurden mit dem Buchstaben für die Testreihe und einer Nummer benannt. In diesem
Abschnitt werden die einzelnen durchgeführten Testreihen geschildert. In jeder Testliste ist jeweils der Test
gekennzeichnet, der mit dem Basistest übereinstimmte. Anders gesagt: Ein Test in jeder Reihe wurde mit
unverändertem gewählten Parameter durchgeführt, d. h. er war in allen Aspekten mit dem ursprünglichen Basistest
identisch.
Testreihe A – Benutzeranzahl verändern
Bei dieser Testreihe wurde die Anzahl der Benutzer verändert, um festzustellen, wie sich die erhöhte Benutzerlast auf
die Systemressourcen in der SharePoint- und FAST Search Server 2010 for SharePoint-Farm auswirkt. Es wurden drei
Tests durchgeführt, jeweils mit 4.000, 10.000 und 15.000 Benutzern. Bei dem Test mit 15.000 Benutzern wurde eine
erhöhte Testdauer benötigt, nämlich 2 Stunden, und die Front-End-Webserver (WFEs) mussten auf 6 aufgestockt
werden, damit die erhöhte Last verarbeitet werden konnte.
Test
A.1
A.2
A.3
Anzahl der Benutzer
4.000
10.000
15.000
Anzahl der WFEs
3
3
6
Testdauer
1 Stunde
1 Stunde (Basis)
2 Stunden
Testreihe B – SQL Server-RAM verändern
Bei dieser Testreihe wurde die Menge des für Microsoft SQL Server verfügbaren Arbeitsspeichers verändert. Da der
SQL Server-Computer mit umfangreichem physischem RAM ausgestattet war, wollten wir mit dieser Testreihe
herausfinden, welche Leistung im Vergleich dazu ein Server mit SQL Server mit weniger Arbeitsspeicher bringt. Sechs
Tests wurden durchgeführt, wobei der maximale RAM für SQL Server abwechselnd auf folgenden Wert festgelegt wurde:
16 GB, 32 GB, 64 GB, 128 GB, 256 GB und 600 GB.
10
Test
B.1
B.2
B.3
B.4
B.5
B.6
SQL-RAM
16 GB
32 GB
64 GB
128 GB
256 GB
600 GB (Basis)
Testreihe C – Anteil an Suchvorgängen verändern
In dieser Testreihe veränderten wir den Anteil der von den Testbenutzern durchgeführten Suchvorgänge im Vergleich
zum Durchsuchen und zum Öffnen von Dokumenten. Die Testlast, die auf die Farm angewendet wurde, ist eine
Kombination aus verschiedenen Benutzertransaktionen gemäß Basis, wobei Öffnen einen Anteil von 30 % ausmacht,
Durchsuchen einen Anteil von 40 % und Suchen 30 %. Bei den Tests in dieser Reihe wurde der Anteil der Suchvorgänge
verändert, wodurch sich zwangsläufig der Anteil der Vorgänge Öffnen und Durchsuchen veränderte.
Test
C.1
C.2
C.3
C.4
C.5
C.6
Öffnen
30%
30%
20%
20%
25%
5%
Durchsuchen
55%
40%
40%
30%
25%
20%
Suchen
15%
30 % (Basis)
40%
50%
50%
75%
Testreihe D – RAM für WFEs verändern
Bei dieser Testreihe wurde die Menge des den Front-End-Webservern zugeteilten Arbeitsspeichers verändert.
Außerdem wurden für diesen Test vier Front-End-Webserver verwendet. Getestet wurde mit einem Arbeitsspeicher von
4 GB, 6 GB, 8 GB bzw. 16 GB auf jedem der vier Front-End-Webserver.
Test
D.1
D.2
D.3
D.4
WFE-Arbeitsspeicher
4 GB
6 GB
8 GB (Basis)
16 GB
Testreihe E – Anzahl der WFEs verändern
Bei dieser Testreihe wurde die Anzahl der verwendeten Front-End-Webserver verändert. Getestet wurde mit 2, 3, 4, 5
bzw. 6 Servern.
Test
E.1
E.2
E.3
E.4
E.5
Anzahl der Web-Front-Ends
2
3 (Basis)
4
5
6
Testreihe F – Anzahl der CPUs für SQL Server verändern
11
Bei dieser Testreihe wurde die Anzahl der für SQL Server verfügbaren CPUs verändert. Getestet wurde mit 2, 4, 8, 16 und
80 CPUs, die für SQL Server verfügbar sind.
Test
F.1
F.2
F.3
F.4
F.5
Für SQL Server verfügbare CPUs
4
6
8
16
80 (Basis)
Testauslastung
Die Tests sollten unterhalb eines optimalen Lastpunkts (im „grünen Bereich“) und mit einer allgemeinen Kombination
aus Vorgängen erfolgen. Zum Messen einzelner Veränderungen wurden an jedem Punkt Tests ausgeführt, an dem eine
Variable geändert wurde. Bei den Testreihen sollte dann der optimale Lastpunkt überschritten werden, damit
Ressourcenengpässe in der Farmkonfiguration erkannt werden konnten. Es wird empfohlen, für die Bereitstellung von
Produktionsfarmen die Ergebnisse beim optimalen Lastpunkt heranzuziehen, sodass überschüssige
Ressourcenkapazitäten für die Verarbeitung von vorübergehenden, unerwarteten Lasten vorhanden sind. Für das
aktuelle Projekt haben wir den optimalen Lastpunkt so definiert, dass Ressourcen unterhalb der folgenden Metriken
bleiben:






Das 75. Quantil Latenz ist kürzer als 1 Sekunde
Die Auslastung der CPU des Front-End-Webservers ist unter 85 %
Die Auslastung der CPU für SQL Server beträgt weniger als 50 %
Die Auslastung der CPU für Anwendungsserver liegt unter 50 %
Die Auslastung der CPU für FAST Search Server 2010 for SharePoint ist weniger als 50 %
Die Fehlerrate ist kleiner als 0,01 %
Ressourcenerfassung während der Tests
Während jedes Testdurchlaufs wurde die Ressourcenverwendung mithilfe des Systemmonitors (Perfmon.exe) und Visual
Studio 2010 Ultimate erfasst, um die Last auf der Testfarm zu ermitteln. Die folgenden Metriken wurden erfasst und
werden im Berichtsabschnitt aufgeführt.




CPU für jede/s/n WFE, SharePoint-Anwendungsserver, FAST Search Server 2010 for SharePoint-Index,
FAST-Suchdienstanwendung (SSA), SQL Server-Computer
RAM-Verwendung für jede/s/n WFE, SharePoint-Anwendungsserver, FAST Search Server 2010 for
SharePoint-Index, FAST-Suchdienstanwendung (SSA), SQL Server-Computer
Seitenaktualisierungsdauer für alle Testelemente
Datenträgerwarteschlangen für jedes Laufwerk
Details zur Hardwarearchitektur der Testfarm
Die Dokumentcenterfarm ist der Host für die SharePoint-Zentraladministration, Dokumentcenter 1, Dokumentcenter 2,
Dienstanwendungen und das integrierte FAST Search-Center. Die Farm besteht aus drei physischen Servern und
22 virtuellen Servern.
Abbildung 3 zeigt ein Diagramm der physischen Architektur.
12
Abbildung 3 – Diagramm der Hardwarearchitektur
13
Document Center Farm
FC HBA (8GB) – VNX5700
PACNEC02
(Hyper-V-HOST)
Physical
64xLP
1TB RAM
Hosting Hyper-V,
FAST Admin
SPDC01
Physical
4xLP
4GB RAM
Domain Controller, DNS
Data/Storage
FC HBA (8GB) – EMC SAN 2
FC HBA (8GB) – VNX5700
PACNEC01
(SQL-HOST)
Physical
80xLP (Westmere)
1TB RAM
Hosting SQL Server,
FAST Document Processors
Abbildung 4 – Physische Server
Hyperthreading war auf den physischen Servern deaktiviert, weil wir keine zusätzlichen CPU-Kerne benötigten und jeder
einzelne virtuelle Hyper-V-Computer auf 4 logische CPUs beschränkt war. Wir wollten Leistungseinbußen aufgrund von
Hyperthreading auf diesen Servern vermeiden. Das Labor umfasste drei physische Server. Alle drei physischen Server
plus die 22 virtuellen Server wurden innerhalb des Labors mit einem virtuellen LAN verbunden, um deren
Netzwerkverkehr von anderen nicht testrelevanten Laborcomputern zu isolieren. Das LAN wurde von einem
1-GBPS-Ethernet-Switch gehostet. Jeder einzelne NEC-Server wurde mit zwei 1-GBPS-Ethernet-Ports verbunden.



SPDC01. Der Windows-Domänencontroller und DNS-Server (Domain Naming System) für das im Labor
verwendete virtuelle Netzwerk.
o 4 physische Prozessorkerne mit 3,4 GHz
o 4 GB RAM
o Festplatte 33 GB RAID SCSI Local Disk Device
PACNEC01. Der Server mit SQL Server 2008 R2, der die Master- und sekundären Dateien für Inhaltsdatenbanken,
Protokolle und TempDB-Dateien hostet. Außerdem wurden 100 FAST-Dokumentprozessoren direkt auf diesem
Server ausgeführt.
o NEC ExpressServer 5800 1080a
o 8 Intel E7 8870-CPUs, die insgesamt 80 physische Prozessorkerne mit jeweils 2,4 GHz enthalten
o 1 TB RAM
o 800 GB Direct-Attached Disk
o 2x Dual-Port-Fiber-Channel-Host-Bus-Adapter-Karten mit jeweils 8 GB/s
o 2x 1-GBPS-Ethernet-Karten
PACNEC02. Der Hyper-V-Host, der die virtuellen Computer mit SharePoint, FAST Search for SharePoint und den
Test Rigs (Prüfständen) in der Farm bedient.
o NEC ExpressServer 5800 1080a
14
o
o
o
o
o
8 Intel X7560-CPUs, die insgesamt 64 physische Prozessorkerne mit jeweils 2,27 GHz enthalten
1 TB RAM
800 GB Direct-Attached Disk
2x Dual-Port-Fiber-Channel-Host-Bus-Adapter-Karten mit jeweils 8 GB/s
2x 1-GBPS-Ethernet-Karten
Virtuelle Server
Abbildung 5 – Virtuelle Server
Diese Server wurden alle auf der Hyper-V-Instanz von PACNEC02 ausgeführt. Alle virtuellen Server wurden von virtuellen
Festplatten (Virtual Hard Disks, VHD-Dateien) gebootet, die lokal auf dem Server PACNEC02 gespeichert waren, und
waren für den Zugriff auf das virtuelle LAN des Labors konfiguriert. Einige dieser virtuellen Server hatten innerhalb des
Gastbetriebssystems direkten Festplattenzugriff auf eine logische Gerätenummer (Logical Unit Number, LUN) im SAN
(Storage Area Network). Der direkte Festplattenzugriff bewirkte eine Leistungssteigerung gegenüber der Nutzung einer
virtuellen Festplatte und wurde daher für den Zugriff auf die FAST Search-Indizes verwendet. Im Folgenden eine Liste
der verschiedenen Typen von virtuellen Servern, die im Labor ausgeführt wurden, jeweils mit Angaben zur
Ressourcenverwendung und den bereitgestellten Diensten.
Typ des virtuellen Servers
Test Rigs (TestRig-1 bis einschl. TestRig-20)
 TestRig-1 ist der Testcontroller aus
Visual Studio 2010 Ultimate.
 TestRig-2 bis einschl. TestRig19 sind
die Testagents aus Visual Studio
Agents 2010, die von TestRig-1
gesteuert werden.
Beschreibung
Der Testcontroller und die Testagents aus
Visual Studio 2010 Ultimate für die
Auslastungstests in der Farm. Diese
virtuellen Server wurden mit 4 virtuellen
Prozessoren und 8 GB Arbeitsspeicher
konfiguriert. Für diese Server wurden
virtuelle Festplatten verwendet.
SP: Zentraladministration, Secure Store ServiceAnwendungen, Crawler
 APP-1 – Host der SharePointZentraladministration und der FAST
Search-Dienstanwendung.
 APP-2 - Host der
SharePoint-Dienstanwendungen und
der FAST Search-Dienstanwendung.
Auf diesem Anwendungsserver
wurden die folgenden SharePointAnwendungen für gemeinsame
Dienste ausgeführt:
Diese virtuellen Computer hosten die in der
Farm verwendete SharePointZentraladministration und die verwendeten
Dienstanwendungen. Diese virtuellen Server
wurden mit 4 virtuellen Prozessoren und 16
GB Arbeitsspeicher konfiguriert. Für diese
Server wurden virtuelle Festplatten
verwendet.
15


Secure Store
Service-Anwendung.
FAST
Search-Dienstanwendung.
FAST-Dienst und -Verwaltung
 FAST-SSA-1 und FAST-SSA-2 –
FAST-Suchdienstanwendungen 1
bzw. 2.
Diese virtuellen Computer hosten den FAST
Search-Dienst und die FAST SearchVerwaltung. Sie wurden jeweils mit
4 virtuellen Prozessoren und
16 GB Arbeitsspeicher konfiguriert und mit
virtuellen Festplatten ausgestattet.
FAST-Index, Search
 FAST-IS-1, FAST-IS2, FAST-IS3 und
FAST-IS4 – Knoten für FAST-Index,
Search und Web Analyzer 1, 2, 3 und 4.
Diese virtuellen Computer hosten den in der
Farm verwendeten FAST-Index sowie die
Knoten für Search und Web Analyzer. Sie
wurden jeweils mit 4 virtuellen Prozessoren
und 16 GB Arbeitsspeicher konfiguriert und
mit einer virtuellen Festplatte als
Startdatenträger verwendet. Sie hatten
zudem direkten Festplattenzugriff auf 3 TB
SAN-LUNs für die Speicherung des
FAST-Index.
Front-End-Webserver (SharePoint und FAST Search)
 WFE-1, WFE-2 und WFE-3 –
Front-End-Webserver 1, 2 und 3 als
Teil einer WindowsLastenausgleichskonfiguration, die
das erste Dokumentcenter hostet.
Diese virtuellen Server wurden mit
4 virtuellen Prozessoren und
8 GB Arbeitsspeicher konfiguriert.
 WFE-4, WFE-5 und WFE-6 –
Front-End-Webserver 4, 5 und 6 als
Teil einer WindowsLastenausgleichskonfiguration, die
das zweite Dokumentcenter hostet.
Diese virtuellen Server wurden mit
4 virtuellen Prozessoren und
8 GB Arbeitsspeicher konfiguriert.
Diese virtuellen Computer hosteten alle
Front-End-Webserver und einen dedizierten
FAST-Crawler innerhalb der Farm. Jede
Inhaltsdatenbank enthielt ein
Dokumentcenter, das mit 3 SharePoint
Server-WFEs mit Lastenausgleich
konfiguriert war. Dies sollte die
Testmischung für die Auslastungstests in
den beiden Inhaltsdatenbanken
vereinfachen. In einer realen Farm wäre
jedes WFE für mehrere Inhaltsdatenbanken
vorgesehen. Für diese Server wurden
virtuelle Festplatten verwendet.
Festplattenspeicher
Für den Speicher wurde EMC VNX5700 Unified Storage verwendet. Das VNX5700-Array wurde über
8-GBPS-Fiber-Channel mit den physischen Servern PACNEC01 und PACNEC02 verbunden. Jeder dieser physischen
Server enthält zwei Fiber-Channel-Host-Bus-Adapter, sodass er eine Verbindung mit beiden Speicherprozessoren
im primären SAN herstellen kann. Dies ermöglicht Redundanz sowie die gleichmäßige Verteilung der logischen
Gerätenummern (LUNs) auf die Speicherprozessoren durch das SAN.
16
Storage Area Network – EMC VNX5700-Array
Ein EMC VNX5700-Array (http://www.emc.com/products/series/vnx-series.htm#/1) wurde für die Speicherung der
SQL Server-Datenbanken und des FAST Search Server 2010 for SharePoint-Suchindex verwendet. Das VNX5700 wurde
mit 300 TB Rohdatenträgerkapazität konfiguriert. Das Array wurde mit 250 600-GB-SAS-Laufwerken mit 10.000 RPM und
75 2-TB-Nearline-SAS-Laufwerken mit 7.200 RPM gefüllt (Nearline-SAS-Laufwerke haben physische SATA-Schnittstellen
und SAS-Anschlüsse, während die üblichen SAS-Laufwerke physische SCSI-Schnittstellen haben). Die Laufwerke wurden
im RAID-10-Format für Spiegelung und Striping konfiguriert. Das konfigurierte RAID-Volume im Storage Area Network
(SAN) wurde auf 3 Pools aufgeteilt, und die logischen Gerätenummern wurden aus einem bestimmten Pool zugeordnet,
wie in Tabelle 2 gezeigt.
Pool
Nr.
0
1
2
Beschreibung
Festplattentyp
FAST
Inhaltsdatenbank
Reserve – nicht verwendet
SAS
SAS
NL SAS
Benutzerkapazität
(GB)
31.967
34.631
58.586
Zugeordnet (GB)
24.735
34.081
5.261
Tabelle 2 – Zugeordnete SAN-Pools
Die logischen Gerätenummern (Logical Unit Numbers, LUNs) auf dem VNX 5700 wurden wie folgt definiert (siehe Tabelle 3).
LUN
Beschreibung
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
SP-Dienstdatenbank
Extra-Speicher für PACNEC02
FAST-Index 1
FAST-Index 2
FAST-Index 3
FAST-Index 4
SP-Inhaltsdatenbank 1
SP-Inhaltsdatenbank 2
SP-Inhaltsdatenbank 3
SP-Inhaltsdatenbank 4
SP-Inhaltsdatenbank-TransProt
SP-Dienstdatenbank-TransProt
Temporäre Datenbank
Protokoll für temp. DB
SP-Verw.- und Integritäts-DB
FAST-Durchforstungs-DB/Verw.-DB
Reserve – nicht verwendet
Großteil der Office-Dok.-Inhalte
WMs-Auslagerungsdateien
DB-Sicherung 1
DB-Sicherung 2
Größe
(GB)
1.024
5.120
3.072
3.072
3.072
3.072
7.500
6.850
6.850
6.850
2.048
512
2.048
2.048
3.072
1.024
5.120
3.072
1.024
16.384
16.384
Server
PACNEC01
PACNEC02
PACNEC02
PACNEC02
PACNEC02
PACNEC02
PACNEC01
PACNEC01
PACNEC01
PACNEC01
PACNEC01
PACNEC01
PACNEC01
PACNEC01
PACNEC01
PACNEC01
PACNEC01
PACNEC01
PACNEC02
PACNEC01
PACNEC01
Datenträgerpool
Nr.
0
0
0
0
0
0
1
1
1
1
1
0
1
0
0
1
2
Zusätzliche
Zusätzliche
Zusätzliche
Zusätzliche
Laufwerkbuchstabe
F
F
G
H
I
H
I
J
K
G
L
M
N
O
P
T
K
R
S
Tabelle 3 – Logische Gerätenummern
Storage Area Network – Zusätzliches Datenträgerarray
Ein zusätzliches Datenträgerarray mit geringerer Leistung wurde zu Sicherungszwecken und zum Hosten des Großteils
der Inhalte von Office-Dokumenten, die in die SharePoint Server 2010-Farm geladen wurden, verwendet. Dieses Array
wurde während der Testdurchläufe nicht verwendet.
17
SharePoint Server- und SQL Server-Architektur der Testfarm
Die logische Architektur wurde im Hinblick auf die Darstellung der empfohlenen Grenzwerte für SharePoint Server 2010
definiert. Di Architektur besteht aus zwei Webanwendungen, von denen jede eine einzige Websitesammlung in einer
einzigen, eindeutigen Inhaltsdatenbank enthält. In jede Inhaltsdatenbank wurden 60 Mio. Dokumente vom Typ
Microsoft Word (DOCX), Excel (XSLX), PowerPoint (PPTX) und Hyper-Text Markup Language (HTML-Seiten) geladen,
jeweils mit einer durchschnittlichen Größe von 250 KB. Die Inhaltsdatenbanken waren jeweils ca. 15 TB groß, woraus
sich ein Gesamtdatenkörper von 30 TB ergab. Die logische Architektur für das umfangreiche Labor ist in Abbildung 6 zu
sehen.
Document Center Farm and Data/Storage
IIS Web Site – “SP CA v4”
IIS Web Site – “SharePoint Services”
Application Pool
Application Pool
Web Application 1
Central Administration
Secure Store
Service Application
E
M
C
V
N
X
5
7
0
0
S
A
N
http://app-1:2010
SharePoint Central
Administration
SharePoint
Configuration
TempDB
SharePoint Content
FAST Crawl/Admin
Default group
Bulk
Bulk
VMs
VMs
FAST Index
Swap
Swap Swap
Swap Swap
Swap Swap
Swap Swap
Swap
IIS Web Site – “doccenter1.lab80”
IIS Web Site – “doccenter2.lab81”
IIS Web Site – “search.lab2011”
Application Pool
Application Pool
Application Pool
Web Application 2
Document Center Template
Web Application 3
Document Center Template
Web Application 4
FAST Search Center Template
http://doccenter1:80
http://doccenter2:81
http://search.lab:2011
Abbildung 6 – Softwarearchitektur
Die SharePoint-Dokumentcenter-Farm soll in einem Szenario mit Dokumentarchiven verwendet werden und ist so
ausgelegt, dass sie eine große Zahl von Dokumenten, die in mehreren Dokumentbibliotheken gespeichert sind,
aufnehmen kann. Die Dokumentbibliotheken wurden jeweils auf rund eine Million Dokumente beschränkt.
Die Ordnerhierarchie beschränkte die Dokumente pro Container auf ca. 2.000 Elemente. Dies diente ausschließlich dem
Zweck, den umfangreichen Dokumentladeprozess zu unterstützen und zu verhindern, dass die Ladedauer sich nach
Überschreitung von 1 Mio. Elementen in einer Dokumentbibliothek verschlechtert.
IIS-Websites in der SharePoint-Farm
Für die zwei Inhalts-Websitesammlungen wurde die Dokumentcenter-Vorlage verwendet. Für die
Search-Center-Websitesammlung wurde die FAST Search-Center-Vorlage verwendet. Jede Websitesammlung befand
sich in einer eindeutigen Webanwendung. Für jede Webanwendung wurde ein separater Anwendungspool verwendet.
18
IIS-Website – SharePoint Services
Die SharePoint Services-IIS-Website hostete die gemeinsamen Dienste, die in SharePoint Server 2010 verwendet
wurden. Im Rahmen unseres Labors verwendeten wir Secure Store.
IIS-Website – SharePoint-Zentraladministration, Version 4
Die IIS-Website für die SharePoint-Zentraladministration hostet die Website und die Benutzeroberfläche der
Zentraladministration für SharePoint Server 2010.
IIS-Website – Dokumentcenter 1
Die IIS-Website für das Dokumentcenter 1 hostet das erste Dokumentcenter-Archiv.
IIS-Website – Dokumentcenter 2
Die IIS-Website für das Dokumentcenter 2 hostet das zweite Dokumentcenter-Archiv.
IIS-Website – FAST Search-Center
Die IIS-Website für das FAST Search-Center hostet die Benutzeroberfläche der Suche für die Farm.
Bei 70 Mio. Dokumenten und höher wurde die Durchforstungsdatenbank merklich langsamer, und es war einige
Optimierung erforderlich, um von 100 Mio. auf 120 Mio. aufzustocken.
SQL Server-Datenbanken
Die folgenden SQL Server-Datenbanken werden im EMC VNX 5700-SAN (Storage Area Network) gehostet.
Datenbankname
Zweck
SharePointAdminContent_<GUID>
Datenbank der SharePointZentraladministration
SharePoint_Config
SharePoint-Konfigurationsdatenbank
Systemdatenbanken – tempdb
Temporäre SQL Server-Datenbank
ReportServer
ReportServerTempDB
Eine Microsoft SQL Server-Datenbank, in der
alle Berichtsmetadaten gespeichert werden,
einschließlich Berichtsdefinitionen,
Berichtsverlauf und Momentaufnahmen
sowie Informationen zur Zeitplanung.
Eine Microsoft SQL Server-Datenbank, in der
alle temporären Momentaufnahmen
während der Ausführung von Berichten
gespeichert werden.
Größe (MB)
768
1.574
16.384
10
3
SPContent01 (Inhaltsdatenbank für
Dokumentcenter 1)
SharePoint-Inhaltsdatenbanken
15.601.286
SPContent02 (Inhaltsdatenbank für
Dokumentcenter 2)
SharePoint-Inhaltsdatenbanken
15.975.266
19
FAST_Query_CrawlStoreDB_<GUID>
Durchforstungsspeicher für die
Abfrage-Suchdienstanwendung von FAST
Search. Diese
Durchforstungsspeicherdatenbank wird nur
für Benutzerprofile verwendet
(Personensuche).
FAST_Query_DB_<GUID>
Verwaltungsdatenbank für die
Abfrage-Suchdienstanwendung von FAST
Search.
125
FAST_Query_PropertyStoreDB_<GUID>
Speichert die Metadateneigenschaften und
Sicherheitsdeskriptoren für die
Benutzerprofilelemente im Index für die
Personensuche. Sie wird in auf Eigenschaften
basierenden Abfragen in der Personensuche
verwendet und gibt
Standarddokumentattribute für
Abfrageergebnisse in der Personensuche
zurück.
173
FASTContent_CrawlStoreDB_<GUID>
Durchforstungsspeicher für die InhaltsSuchdienstanwendung von FAST Search.
Diese Durchforstungsspeicherdatenbank wird
für alle durchforsteten Elemente außer
Benutzerprofile verwendet.
502.481
FASTContent_DB_<GUID>
Verwaltungsdatenbank für die InhaltsSuchdienstanwendung von FAST Search.
FASTSearchAdminDatabase
Verwaltungsdatenbank für die FAST Search
Server 2010 for SharePoint-Farm. Speichert
und verwaltet Sucheinstellungsgruppen,
Schlüsselwörter, Synonyme, Dokument- und
Websiteherauf- und -herabstufungen,
Inklusionen und Ausschlüsse für die
Eigenschaftsextraktion, Ausschlüsse für die
Rechtschreibprüfung, beste Suchergebnisse,
visuelle beste Suchergebnisse und
Suchschema-Metadaten.
WSS_Content_FAST_Search
Inhaltsdatenbank für FAST Search-Center.
LoadTest2010
Repository für die Ergebnisse der
Auslastungstests
15
23
4
52
4.099
Tabelle 4 – SQL Server-Datenbanken
20
Inhaltsindizes in FAST Search Server 2010 for SharePoint
Für die FAST Search Server 2010 for SharePoint-Datenverzeichnisse wird ein Hyper-V-Passthrough-Laufwerk direkt zum
SAN verwendet.
Auf dem virtuellen Server FAST-IS1 verwendet das Datenverzeichnis 745 GB der 3 TB, wobei kein temporärer
Speicherplatz genutzt wird (aufgrund der Bereinigung).
Tabelle 5 zeigt den Datenspeicher in den FAST Search Server 2010 for SharePoint-Indexdateiordnern, die im SAN
gespeichert sind.
Name
Zweck
Anzahl der
Dateien
Größe (GB)
data_fixml
Indexquelle zum Erstellen
des Index
6 Mio.
223
data_index
Tatsächlicher Suchindex, der
von Abfragen verwendet
wird
3,729
490
sprel
SharePointRelevanzinformationen.
Dient zum Heraufstufen von
beliebten Suchergebnissen
zum Anfang der Liste.
9
3
webanalyzer
Heraufstufen von
Suchergebnissen nach
häufiger verlinkten
Dokumenten.
135
12
Tabelle 5 – Speicher, der von einem von vier FAST-Indizes verwendet wird
Methode, Projektzeitplan und Prozess für das Erstellen der Farm
Projektzeitplan
Dies ist die ungefähre Zeitplanung für das Projekt.









Planen der Farmarchitektur
Installieren des Servers und der SAN-Hardware
Erstellen der virtuellen Computer für die Farm
Erstellen von Beispielinhaltselementen
Laden von Elementen in SharePoint Server
Entwickeln von Testskripts
FAST Search-Indizierung der Inhalte
Durchführen der Auslastungstests
Verfassen der Berichte
2 Wochen
1 Woche
1 Woche
2 Wochen
3 Wochen
1 Woche
2 Wochen
3 Wochen
2 Wochen
21
Wie die Beispieldokumente erstellt wurden
Damit wir ein realistisches Szenario mit Dokumentarchiven entwickeln konnten, war die Eindeutigkeit von Dokumenten
entscheidend. Wir verwendeten zwei separate Hilfsprogramme: eines zum Erstellen von eindeutigen Dokumenten und
ein zweites zum Lesen dieser Dateien vom Datenträger und anschließenden Laden direkt in die vorgesehenen
SharePoint-Webanwendungen und -Dokumentbibliotheken.
Tool zum Erstellen einer großen Anzahl von Dokumenten
Die Dokumente wurden mithilfe des Befehlszeilentools Bulk Loader erstellt, das auf Microsoft .NET Framework 4.0
basiert. Bei diesem Tool werden anhand einer Abbilddatei von Wikipedia-Inhalten als Eingabe bis zu 10 Mio. eindeutige
Dokumente auf einem Datenträger erstellt. Die Bildverweise aus den Wikipedia-Abbildern werden durch Archivbilder
ersetzt. Dieses Tool steht als Quellcode unter http://code.msdn.microsoft.com/Bulk-Loader-Create-Unique-eeb2d084
zur Verfügung.
Tool zum Laden von Dokumenten in SharePoint
Die Dokumente wurden mithilfe des Befehlszeilentools LoadBulk2SP zu SharePoint Server hinzugefügt. Dieses Tool
wurde mit C# und Microsoft .NET Framework 3.5 geschrieben, um Kompatibilität mit SharePoint Server zu
gewährleisten. Es verwendet die Datenträger-Ausgabedateien des Tools Bulk Loader als Eingabe und imitiert die gleiche
Ordner- und Dateistruktur mithilfe der in der Anwendungskonfiguration angegebenen Zielwebanwendungen und dokumentbibliotheken direkt in SharePoint Server. Mit diesem Tool wurden über 100 Mio. 250-KB-Dokumente bei einer
maximalen Leistung von 233 Dokumenten pro Sekunde und einer durchschnittlichen Gesamtladedauer von
137 Dokumenten pro Sekunde in SharePoint Server geladen. Dieses Tool steht als Quellcode unter
http://code.msdn.microsoft.com/Load-Bulk-Content-to-3f379974 zur Verfügung.
Leistungscharakteristika für umfangreiche Dokumentladevorgänge
Das Laden von Dokumenten erfolgte mit dem Tool LoadBulk2SP, das weiter oben beschrieben wurde. Dieses Tool fügt
mithilfe der SubFolderCollection.Add()-Methode neue Ordner zu angegebenen Dokumentbibliotheken hinzu und mit der
SPFileCollection.Add()-Methode Dateien direkt in die neu erstellten SharePoint-Dokumentbibliotheksordner ein. Die in
SharePoint Server erstellte Ordner- und Dateistruktur imitiert die Ausgabehierarchie, die vom Tool Bulk Loader generiert wird.
Größen der Inhaltsdatenbanken für Dokumentbibliotheken
In der folgenden Tabelle werden die Einzelheiten zur Größe der Inhaltsdatenbanken für Dokumentbibliotheken
angegeben, einschließlich der in der Farm verwendeten SQL Server-Dateigruppen, primären und sekundären Dateien.
SQL-Inhaltsdatei
Dateigruppe
LUN
SPCPrimary01.mdf
SPCData0102.mdf
SPCData0103.mdf
SPCData0104.mdf
SPCData0105.mdf
SPCData0106.mdf
Dokumentcenter 1
SPCPrimary02.mdf
SPCData0202.mdf
SPCData0203.mdf
SPCData0204.mdf
SPCData0205.mdf
SPCData0206.mdf
Dokumentcenter 2
Gesamtkörper:
Primär
SPCData01
SPCData01
SPCData01
SPCData01
SPCData01
Summen:
SPCData02
SPCData02
SPCData02
SPCData02
SPCData02
SPCData02
Summen:
H:/
I:/
J:/
K:/
H:/
O:/
H:/
I:/
J:/
K:/
H:/
O:/
Größe (KB)
53.248
3.942.098.048
4.719.712768
3.723.746.048
3.371.171.968
4.194.394
15.760.968.474
52.224
3.240.200.064
3.144.130.944
3.458.544.064
3.805.828.608
2.495.168.448
16.143.924.352
31.904.892.826
Größe (MB)
52,000
3.849.697,312
4.609.094,500
3.636.470,750
3.292.160,125
4.096,087
15.391.570,775
51,00
3.164.257,875
3.070.440,375
3.377.484,437
3.716.629,500
2.436.687,937
15.765.551,125
31.157.121,900
Größe (GB)
0,050
3.759,470
4.501,068
3.551,240
3.215,000
4,000
15.030,820
0,049
3.090,095
2.998,476
3.298,324
3.629,521
2.379,578
15.396,046
30.426,876
Größe
(TB)
0,000
3,671
4,395
3,468
3,139
0,003
14,678
0,000
3,017
2,928
3,221
3,544
2,323
15,035
29,713
22
Tabelle 6 – Größe der SQL Server-Datenbanken
Hierarchien, Ordner und Dateien für Dokumentbibliotheken
In den folgenden Abschnitten werden die Einzelheiten zu den Dokumentbibliothekshierarchien sowie die Gesamtzahl
der Ordner und Dokumente angegeben, die mit dem Tool LoadBulk2SP für jedes Dokumentcenter generiert wurden.
Für beide Dokumentcenter zusammen ergeben sich folgende Summen: 60.234 Ordner und 120.092.033 Dateien.
Dokumentcenter 1
Die Gesamtzahl der Ordner und Dateien, die in jeder Dokumentbibliothek in der Inhaltsdatenbank enthalten sind,
sehen Sie in Tabelle 7. Wie bereits erwähnt, wurde eine strikte Obergrenze von 1 Mio. Dokumente pro
Dokumentbibliothek festgelegt, um den Prozess des Ladens der umfangreichen Inhalte zu unterstützen. Ergebnisse für die
SharePoint
2010-Farmarchitektur und Hinweise zur Speicherung von umfangreichen Dokumentbibliotheken finden Sie in einem
früheren Testbericht mit dem Titel Schätzen der Leistungs- und Kapazitätsanforderungen für große Dokumentrepositorys
in SharePoint Server 2010 (http://technet.microsoft.com/de-de/library/hh395916.aspx). Bei diesem damaligen Test ging
es schwerpunktmäßig um die Skalierung von Elementzahlen in einer Dokumentbibliothek.
Bitte lesen Sie auch die Hinweise zu SharePoint Server 2010-Grenzwerten für Elemente in Dokumentbibliotheken und
Elemente in Inhaltsdatenbanken unter SharePoint Server 2010-Kapazitätsverwaltung: Softwarebeschränkungen und -grenzen
(http://technet.microsoft.com/de-de/library/cc262787.aspx) auf der TechNet-Website.
Dokumentcenter 1
Dokumentbibliothek
SUMMEN FÜR DC1:
Zahlen
Ordner
30.447
Dateien
60.662.595
Tabelle 7 – Dokumentbibliotheken in Dokumentcenter 1
Dokumentcenter 2
Die Gesamtzahl der Ordner und Dateien, die in jeder Dokumentbibliothek in der Inhaltsdatenbank enthalten sind,
sehen Sie in Tabelle 8.
Dokumentcenter 2
Dokumentbibliothek
Zahlen
Ordner
Dateien
SUMMEN FÜR DC2:
29.787
59.429.438
SUMMEN FÜR DC1:
30.447
60.662.595
60.234
120.092.033
SUMMEN GESAMTKÖRPER:
Tabelle 8 – Dokumentbibliotheken in Dokumentcenter 2
23
Es folgen statistische Beispiele aus den fünf Top-Durchläufen des Tools LoadBulk2SP mit vier gleichzeitigen Prozessen,
jeweils mit 16 Threads für unterschiedliche Dokumentcenter, Dokumentbibliotheken und Eingabeordnern und -dateien.
Durchlauf 26:
5 Ordner @
2.000 Dateien
Durchlauf 9:
30 Ordner @
2.000 Dateien
Durchlauf 10:
30 Ordner @
2.000 Dateien
Durchlauf 8:
30 Ordner @
2.000 Dateien
Durchlauf 7:
30 Ordner @
2.000 Dateien
Stunden
Zeit
0
Sekunden
0
Minuten
Sekunden
45
46
Gesamt:
2.700
46
2.746
Stunden
Zeit
5
Sekunden
18.000
Minuten
Sekunden
58
46
Gesamt:
3.480
46
21.526
Stunden
Zeit
6
Sekunden
21.600
Minuten
Sekunden
33
50
Gesamt:
1.980
50
23.630
Stunden
Zeit
6
Sekunden
21.600
Minuten
Sekunden
51
30
Gesamt:
3.060
30
24.690
Stunden
Zeit
6
Sekunden
21.600
Minuten
Sekunden
55
0
Gesamt:
3.300
0
24.900
Ordner
315
Dateien
639.980
Dok./Sek.
233
58264
Ordner
Dateien
1.920 3.839.864
Dok./Sek.
178
Ordner
Dateien
1.920 3.839.881
Dok./Sek.
162
Ordner
Dateien
1.920 3.839.857
Dok./Sek.
155
Ordner
Dateien
1.920 3.839.868
Dok./Sek.
154
Tabelle 9 – Detaillierte Leistungsergebnisse aus LoadBulk2SP
E/A-Vorgänge pro Sekunde (Input-Output Operations per Second, IOPS)
SQLIO ist ein Tool für Stresstests, mit dem die E/A-Kapazität einer gegebenen Konfiguration ermittelt werden kann.
Es wurde nach dem Abschluss der Leistungstests auf dem System ausgeführt. Daher konnten mehrere durch SAN-LUNs
gestützte Datenträger nicht mit einbezogen werden, da auf ihnen zu viele Daten vorhanden waren. Der SQLIO-Test wird
für jeden Laufwerksbuchstaben einzeln ausgeführt und anschließend auf allen Laufwerken gleichzeitig. In der rechten
24
Spalte der Tabelle sehen Sie den Wert für IOPS pro GB. Dieser wird durch Dividieren des IOPS-Werts durch die
Laufwerkskapazität berechnet. Für diese alle gleichzeitig getesteten Laufwerke wurden 105.730 IOPS erreicht.
IOPS gemäß Test mit dem Tool SQLIO
Größe
(GB)
LeseIOPS
(MAX)
SP-Dienstdatenbank
1024
2.736
23.778
26.514
25,89
G:
InhaltsdatenbankenTransProt
2048
3.361
30.021
33.383
16,30
L:
DienstdatenbankenTransProt
512
2.495
28.863
31.358
61,25
M:
TempDB
2048
2.455
21.778
24.233
11,83
N:
TempDB-Protokoll
2048
2.751
29.522
32.273
15,76
O:
Inhaltsdatenbanken
5
3.072
2.745
28.767
31.511
10,26
P:
Durchforstungs/Verw.-DBs
1024
2.603
22.808
25.411
24,81
Alle gleichzeitig
11776 16.665
89.065
105.730
8,98
SUMME:
11.776 19.145
185.536
310.412
26.505
38.801
LUN
Beschreibung der
LUN
F:
DURCHSCHNITT:
1.682
2.735
Schreib- GesamtIOPS
IOPS
IOPS pro GB
(MAX)
(MAX)
22
Tabelle 10 – IOPS-Testergebnisse für SAN mit SQLIO-Tool
Während der Auslastungstests erzielte IOPS
Systemmonitoraufträge wurden konsistent parallel zur FAST-Indizierung, dem Laden von Inhalten und den Visual
Studio-Auslastungstests ausgeführt. In der folgenden Tabelle werden die erzielten maximalen IOPS pro LUN aufgeführt,
jeweils mit Angabe der LUN, Beschreibung, Gesamtgröße, Max. Lesevorgänge, Max. Schreibvorgänge, Gesamt-IOPS
und IOPS pro GB.
25
Da diese Ergebnisse während der Tests gewonnen wurden, geben sie die IOPS wieder, die die Testumgebung im SAN
ausführen konnte. Da die Laufwerke H:, I:, J: und K: einbezogen werden konnten, war die erzielte Gesamtzahl der IOPS
wesentlich höher als beim Test mit SQLIO.
LUN
Beschreibung der LUN
G:
InhaltsdatenbankenTransProt
Inhaltsdatenbanken 1
Inhaltsdatenbanken 2
Inhaltsdatenbanken 3
Inhaltsdatenbanken 4
DienstdatenbankenTransProt
TempDB
TempDB-Protokoll
Inhaltsdatenbanken 5
Durchforstungs/Verw.-DBs
SUMME:
DURCHSCHNITT:
H:
I:
J:
K:
L:
M:
N:
O:
P:
Größe
Lese-IOPS
SchreibGesamtIOPS pro GB
(GB)
(MAX)
IOPS (MAX) IOPS (MAX)
2048
5.437
11.923
17.360
8,48
6.850
6.850
7.500
6.850
512
5.203
5.284
5.636
5.407
5.285
18.546
11.791
11.544
11.146
10.801
23.749
17.075
17.180
16.553
16.086
2048
2048
3072
1024
5.282
5.640
5.400
5.249
11.089
11.790
11.818
11.217
16.371
17.429
17.218
16.467
31.365
3.136
53.824
5.382
121.667
12.167
175.491
17.549
3,47
2,49
2,29
2,42
31,42
7,99
8,51
5,60
16,08
5,60
Tabelle 11 – IOPS gemäß Messung aus Systemmonitor-Protokollen
Durchforstung von Dokumenten in FAST Search Server 2010 for SharePoint
Das Durchforsten von SharePoint-Websites für die Suche erfolgt mit dem SharePoint-Crawler, der für die Zuführung zu
den FAST-Inhaltsverteilungen konfiguriert ist. Die Inhalts-SSA (Search Service Application, Suchdienstanwendung) wurde
für die Ausführung auf zwei Servern konfiguriert – APP-1 und APP-2 –, und die Abfrage-SSA wurde auf den Servern
FAST-1 und FAST-2 ausgeführt.
26
100 Dokumentprozessoren für die FAST-Indexerstellung wurden auf dem Computer mit SQL Server ausgeführt.
Den folgenden Screenshot erstellten wird im Task-Manager. Er zeigt die Aktivität, während beide Dokumentprozessoren
arbeiten und ein Auslastungstest mit 10.000 Benutzern ausgeführt wird, wobei SQL Server sich auch auf diesem
Computer befindet.
Abbildung 7 – Task-Manager auf PACNEC01 während FAST-Indexerstellung und Auslastungstest
27
Testergebnisse
Damit wir während der Tests eine erhebliche Last generieren konnten, verwendeten wird die folgende Software: Visual
Studio 2010 Ultimate, Visual Studio 2010 Load Control und Microsoft Visual Studio Agents 20101. Ein Test Rig (Prüfstand)
wird benötigt, um eine Anzahl von Benutzern zu simulieren und eine erhebliche Last zu generieren. Ein Test Rig besteht aus
einem Testcontroller-Computer und mindestens einem Testagent-Computer. Der Testcontroller steuert und koordiniert die
Agent-Computer, und die Agents generieren die Last in SharePoint Server. Der Testcontroller ist zudem für die Erfassung von
Systemmonitordaten aus den Computern, die getestet werden, und aus den Agent-Computern zuständig.
In diesem Abschnitt werden die Ergebnisse der Leistungstestdurchläufe präsentiert.
Testreihe A – Benutzeranzahl verändern
In dieser Testreihe haben wir die Anzahl der Benutzer verändert, die in die Testfarm geladen wurden. Abbildung 8 zeigt
die Anforderungen pro Sekunde, die der Visual Studio 2010 Ultimate-Testcontroller während der Tests für die
unterschiedlichen Benutzerlasten über die SharePoint-Farm verarbeiten konnte. Wie Sie sehen, nimmt die Zahl der
Anforderungen zu, wenn die Benutzerlast erhöht wird. Nähert sich die Benutzeranzahl jedoch der 15.000-Marke,
wird die Farm stark ausgelastet, sodass der Wert nicht so stark ansteigt wie die angewendete Last.
Da der Test mit 15.000 Benutzern zusätzliche Zeit für die Aufstockung beanspruchte, führten wir diesen Test 2 Stunden
lang aus und nicht 1 Stunde, wie gemäß Testbasis vorgesehen. Wir stellten auch fest, dass aufgrund der Last 3
Front-End-Webserver nicht ausreichend waren. Daher führten wir diesen Test mit 6 Front-End-Webservern durch.
250
200
150
Durchschn. RPS
100
50
0
A.1 4000
A.2 10,000
A.3 15,000
Abbildung 8 – Durchschnittliche RPS für Reihe A
In Abbildung 9 sehen Sie, dass für den Test mit 15.000 Benutzern die Antwortzeiten für Testtransaktionen parallel zur
Seitenaktualisierungsdauer ansteigen. Das deutet darauf hin, dass für diese hohe Benutzerlast ein Engpass im System
besteht. Wir beobachteten während dieses Tests eine hohe IOPS-Last auf Laufwerk H:, das die primäre Datendatei für
1
Visual Studio Agents 2010 (in englischer Sprache)
28
die Inhaltsdatenbank enthielt. Nach weiteren Untersuchungen in diesem Bereich hätten wir diesen Engpass beseitigen
können.
25
20
15
Anzahl der WFEs
Durchschn. Seitenantwortzeit
10
Durchschn. Antwortzeit
5
0
A.1 4000
A.2 10,000
A.3 15,000
Abbildung 9 – Zeiten und verwendete WFEs für Reihe A
In Abbildung 10 sehen Sie die zunehmende CPU-Auslastung bei Erhöhung der Benutzerlast von 4.000 auf
10.000 Benutzer. Und Sie sehen die abnehmende CPU-Auslastung nur für die Front-End-Webserver (WFEs) beim
Verdoppeln der
WFE-Anzahl von 3 auf 6. Unten sehen Sie, dass die CPU-Auslastung auf dem Server APP-1 relativ konstant ist und für den
großen SQL Server-Computer PACNEC01 3 % der Gesamt-CPU-Auslastung nicht erreicht wird.
70.00%
60.00%
Durchschn. CPU-Nutzung PACNEC01
50.00%
Durchschn. CPU-Nutzung APP-1
Durchschn. CPU-Nutzung WFE-1
40.00%
Durchschn. CPU-Nutzung WFE-2
30.00%
Durchschn. CPU-Nutzung WFE-3
20.00%
Durchschn. CPU-Nutzung WFE-4
Durchschn. CPU-Nutzung WFE-5
10.00%
Durchschn. CPU-Nutzung WFE-6
0.00%
A.1 4000
A.2 10,000
A.3 15,000
Abbildung 10 – Durchschnittliche CPU-Auslastung für Reihe A
29
Tabelle 12 zeigt eine Zusammenfassung der Daten, die während der drei Tests in Testreihe A erfasst wurden.
Datenelemente mit der Angabe „n.z.“ wurden nicht erfasst.
Test
Benutzer
WFEs
Dauer
Durchschn. RPS
Durchschn. Seitenantwortzeit
Durchschn. Antwortzeit
Durchschn. CPU-Nutzung WFE-1
Verfügbarer RAM WFE-1
Durchschn. CPU-Nutzung WFE-2
Verfügbarer RAM WFE-2
Durchschn. CPU-Nutzung WFE-3
Verfügbarer RAM WFE-3
Durchschn. CPU-Nutzung
PACNEC01
Verfügbarer RAM PACNEC01
Durchschn. CPU-Nutzung APP-1
Verfügbarer RAM APP-1
Durchschn. CPU-Nutzung APP-2
Verfügbarer RAM APP-2
Durchschn. CPU-Nutzung WFE-4
Verfügbarer RAM WFE-4
Durchschn. CPU-Nutzung WFE-5
Verfügbarer RAM WFE-5
Durchschn. CPU-Nutzung WFE-6
Verfügbarer RAM WFE-6
Durchschnittl.
Warteschlangenlänge f.
Datenträger-Schreibvorgänge,
PACNEC01 H: SPContent DB1
A.1
4.000
3
1 Stunde
96,3
0,31 s
0.26 s
22,3%
5.828
36,7%
5.651
22,8%
5.961
1,29%
A.2
10.000
3
1 Stunde
203
0,71 s
0.58 s
57,3%
5.786
59,6%
5.552
57,7%
5.769
2,37%
A.3
15.000
6
2 Stunden
220
19,2 s
13.2 s
29,7%
13.311
36,7%
13.323
34%
13.337
2,86%
401.301
6,96%
13.745
0,73%
14.815
n.z.
n.z.
n.z.
n.z.
n.z.
n.z.
0,0 (Spitze:
0,01)
400.059
14,5%
13.804
1,09%
14.992
n.z.
n.z.
n.z.
n.z.
n.z.
n.z.
0,0 (Spitze: 0,02)
876.154
13,4%
13.311
0,27%
13.919
29,7%
13.397
30,4%
13.567
34,9%
13.446
0,3 (Spitze: 24,1)
Tabelle 12 – Ausführliche Ergebnisse der Testreihe A
30
Testreihe B – SQL Server-RAM verändern
Bei dieser Testreihe wurde die Menge des für SQL Server verfügbaren Arbeitsspeichers verändert. Wie Sie in Abbildung 11
sehen, hatte der SQeStiSt guzSeSvreS L Arbeitsspeicher keinen Einfluss auf die Anforderungen pro Sekunde (RPS).
250
200
150
Durchschn. RPS
100
50
0
B.1 16GB B.2 32GB B.3 64GB
B.4
128GB
B.5
256GB
B.6
600GB
Abbildung 11 – Durchschnittliche RPS für Reihe B
In Abbildung 12 sehen Sie, dass bei allen Tests die Seiten- und Transaktionsantwortzeiten unter 1 Sekunde lagen.
1
0.9
0.8
0.7
0.6
Durchschn.
Seitenantwortzeit
0.5
0.4
Durchschn. Antwortzeit
0.3
0.2
0.1
0
B.1
16GB
B.2
32GB
B.3
64GB
B.4
128GB
B.5
256GB
B.6
600GB
Abbildung 12 – Seiten- und Transaktionsantwortzeiten für Reihe B
31
Abbildung 13 zeigt die CPU-Nutzung für die Front-End-Webserver (WFE), den Anwendungsserver und den SQL
Server-Datenbankserver. Wie Sie sehen, waren die 3 WFEs für alle Tests konstant ausgelastet, der Anwendungsserver
war überwiegend im Leerlauf und der Datenbankserver kommt nicht über 3 % CPU-Auslastung hinaus.
70.00%
60.00%
Durchschn. CPU-Nutzung
WFE-1
50.00%
Durchschn. CPU-Nutzung
WFE-2
40.00%
30.00%
Durchschn. CPU-Nutzung
WFE-3
20.00%
Durchschn. CPU-Nutzung
PACNEC01
10.00%
Durchschn. CPU-Nutzung
APP-1
0.00%
B.1
16GB
B.2
32GB
B.3
64GB
B.4
B.5
B.6
128GB 256GB 600GB
Abbildung 13 – Durchschnittliche CPU-Auslastung für Reihe B
1,000,000
Verfügbarer RAM WFE-1
900,000
800,000
Verfügbarer RAM WFE-2
700,000
600,000
Verfügbarer RAM WFE-3
500,000
400,000
300,000
Verfügbarer RAM
PACNEC01
200,000
Verfügbarer RAM APP-1
100,000
Verfügbarer RAM APP-2
0
B.1
16GB
B.2
32GB
B.3
B.4
B.5
B.6
64GB 128GB 256GB 600GB
Abbildung 14 – Verfügbarer RAM für Reihe B
32
Tabelle 13 zeigt eine Zusammenfassung der Daten, die während der drei Tests in Testreihe B erfasst wurden.
Test
SQL-RAM
Durchschn. RPS
Durchschn.
Seitenantwortzeit
Durchschn.
Antwortzeit
Durchschn. CPUNutzung WFE-1
Verfügbarer RAM
WFE-1
Durchschn. CPUNutzung WFE-2
Verfügbarer RAM
WFE-2
Durchschn. CPUNutzung WFE-3
Verfügbarer RAM
WFE-3
Durchschn. CPUNutzung PACNEC01
Verfügbarer RAM
PACNEC01
Durchschn. CPUNutzung APP-1
Verfügbarer RAM
APP-1
Durchschn. CPUNutzung APP-2
Verfügbarer RAM
APP-2
B.1
16 GB
203
0,66
B.2
32 GB
203
0,40
B.3
64 GB
203
0,38
B.4
128 GB
204
0,42
B.5
256 GB
203
0,58
B.6
600 GB
202
0,89
0,56
0,33
0,31
0,37
0,46
0,72
57,1%
58,4%
58,8%
60,6%
60%
59%
6.239
6.063
6.094
5.908
5.978
5.848
55,6%
60,1%
57,1%
59,6%
60,3%
58,1%
6.184
6.079
6.141
6.119
5.956
5.828
59,4%
56%
56,9%
58,4%
61,4%
59,8%
6.144
6.128
6.159
6.048
5.926
5.841
2,84%
2,11%
2,36%
2,25%
2,38%
2,29%
928.946
923.332
918.526
904.074
861.217
881.729
14,3%
12,6%
13,3%
12,5%
13,4%
13,8%
14.163
14.099
14.106
14.125
14.221
14.268
1,29%
1,14%
1,2%
1,2%
1,03%
0,96%
15.013
14.884
14.907
14.888
14.913
14.900
Tabelle 13 – Ausführliche Ergebnisse der Testreihe B
33
Testreihe C – Anteil an Suchtransaktionen verändern
In dieser Testreihe haben wir den Anteil der Suchtransaktionen an der Arbeitslastkombination verändert.
250
200
150
Durchschn. RPS
100
50
0
C.1 15%
C.2 30%
C.3 40%
C.4 50%
C.5 50%
C.6 75%
Abbildung 15 – Durchschnittliche RPS für Reihe C
In Abbildung 16 sehen Sie, dass bei dem Test C.5 deutlich längere Seitenantwortzeiten auftraten. Das weist darauf hin,
dass die SharePoint Server 2010- und FAST Search Server 2010 for SharePoint-Farm während dieses Tests überlastet war.
30
25
20
Durchschn. Seitenantwortzeit
15
Durchschn. Antwortzeit
10
5
0
C.1 15%
C.2 30%
C.3 40%
C.4 50%
C.5 50%
C.6 75%
Abbildung 16 – Seiten- und Transaktionsantwortzeiten für Reihe C
34
90%
Öffnen
80%
Durchsuchen
70%
Suchen
60%
Durchschn. CPU-Nutzung WFE-1
50%
Durchschn. CPU-Nutzung WFE-2
40%
Durchschn. CPU-Nutzung WFE-3
30%
Durchschn. CPU-Nutzung PACNEC01
20%
Durchschn. CPU-Nutzung APP-1
10%
Durchschn. CPU-Nutzung FAST-1
Durchschn. CPU-Nutzung FAST-2
0%
C.1 15%
C.2 30%
C.3 40%
C.4 50%
C.5 50%
C.6 75%
Abbildung 17 – Durchschnittliche CPU-Nutzung für Reihe C
16,000
Verfügbarer RAM WFE-1
14,000
Verfügbarer RAM WFE-2
12,000
Verfügbarer RAM WFE-3
10,000
Verfügbarer RAM APP-1
8,000
Verfügbarer RAM FAST-1
Verfügbarer RAM FAST-2
6,000
Verfügbarer RAM FAST-IS1
4,000
Verfügbarer RAM FAST-IS2
2,000
Verfügbarer RAM FAST-IS3
0
Verfügbarer RAM FAST-IS4
C.1 15%
C.2 30%
C.3 40%
C.4 50%
C.5 50%
C.6 75%
Abbildung 18 – Verfügbarer RAM für Reihe C
Tabelle 14 zeigt eine Zusammenfassung der Daten, die während der drei Tests in Testreihe C erfasst wurden.
Test
Öffnen
Durchsuchen
Suchen
Durchschn. RPS
Durchschn.
Seitenantwortzeit (s)
Durchschn.
Antwortzeit (s)
Durchschn. CPUNutzung WFE-1
C.4
30%
55%
15%
235
1,19
C.2 (Basis)
30%
40%
30%
203
0,71
C.1
20%
40%
40%
190
0,26
C.2
20%
30%
50%
175
0,43
C.3
25%
25%
50%
168
0,29
C.5
5%
20%
75%
141
25,4
0,87
0,58
0,20
0,33
0,22
16,1
62,2%
57,30%
44,2%
40,4%
36,1%
53,1%
35
Verfügbarer RAM
WFE-1
Durchschn. CPUNutzung WFE-2
Verfügbarer RAM
WFE-2
Durchschn. CPUNutzung WFE-3
Verfügbarer RAM
WFE-3
Durchschn. CPUNutzung PACNEC01
Verfügbarer RAM
PACNEC01
Durchschn. CPUNutzung APP-1
Verfügbarer RAM
APP-1
Durchschn. CPUNutzung APP-2
Verfügbarer RAM
APP-2
Durchschn. CPUNutzung FAST-1
Verfügbarer RAM
FAST-1
Durchschn. CPUNutzung FAST-2
Verfügbarer RAM
FAST-2
Durchschn. CPUNutzung FAST-IS1
Verfügbarer RAM
FAST-IS1
Durchschn. CPUNutzung FAST-IS2
Verfügbarer RAM
FAST-IS2
Durchschn. CPUNutzung FAST-IS3
Verfügbarer RAM
FAST-IS3
Durchschn. CPUNutzung FAST-IS4
Verfügbarer RAM
FAST-IS4
14.091
5.786
6.281
6.162
6.069
13.766
65,2%
59,60%
45,2%
40,1%
37,6%
58,8%
13.944
5.552
6.271
6.123
6.044
13.726
65,3%
57,70%
49,4%
44,2%
39,6%
56,8%
13.693
5.769
6.285
6.170
6.076
13.716
2,4%
2,37%
2,6%
2,51%
2,32%
3,03%
899.613 400.059
814.485
812.027
808.842
875.890
8,27%
14,50%
17,8%
20,7%
18,4%
16,2%
13.687
13.804
14.002
13.991
13.984
13.413
0,28%
n.z.
0,88%
0,8%
0,79%
0,14%
13.916
n.z.
14.839
14.837
14.833
13.910
8,39%
n.z.
n.z.
n.z.
n.z.
16,6%
13.998
n.z.
n.z.
n.z.
n.z.
13.686
8,67%
n.z.
n.z.
n.z.
n.z.
16,7%
14.135
n.z.
n.z.
n.z.
n.z.
13.837
37,8%
n.z.
n.z.
n.z.
n.z.
83,4%
2.309
n.z.
n.z.
n.z.
n.z.
2.298
30,2%
n.z.
n.z.
n.z.
n.z.
66,1%
5.162
n.z.
n.z.
n.z.
n.z.
5.157
30,6%
n.z.
n.z.
n.z.
n.z.
69,9%
5.072
n.z.
n.z.
n.z.
n.z.
5.066
25,6%
n.z.
n.z.
n.z.
n.z.
58,2%
5.243
n.z.
n.z.
n.z.
n.z.
5.234
Tabelle 14 – Ausführliche Ergebnisse der Testreihe C
36
Testreihe D – RAM für Front-End-Webserver verändern
Bei dieser Testreihe wurde die Menge des Arbeitsspeichers auf jedem virtuellen Computer für einen
Front-End-Webserver verändert.
200
180
160
140
120
100
Durchschn. RPS
80
60
40
20
0
D.1 4GB
D.2 6GB
D.3 8GB
D.4 16GB
Abbildung 19 – Durchschnittliche RPS
0.25
0.2
0.15
Durchschn.
Seitenantwortzeit
Durchschn.
Antwortzeit
0.1
0.05
0
D.1 4GB
D.2 6GB
D.3 8GB
D.4 16GB
Abbildung 20 – Seiten- und Transaktionsantwortzeiten
37
50.00%
Durchschn. CPUNutzung WFE-1
45.00%
40.00%
Durchschn. CPUNutzung WFE-2
35.00%
30.00%
Durchschn. CPUNutzung WFE-3
25.00%
Durchschn. CPUNutzung PACNEC01
20.00%
15.00%
Durchschn. CPUNutzung APP-1
10.00%
5.00%
Durchschn. CPUNutzung WFE-4
0.00%
D.1 4GB
D.2 6GB
D.3 8GB
D.4 16GB
Abbildung 21 – Durchschnittliche CPU-Nutzung
In Abbildung 22 sehen Sie, dass der verfügbare RAM auf jedem Front-End-Webserver in allen Fällen der dem virtuellen
Computer zugeordnete RAM abzüglich 2 GB ist. Dies weist darauf hin, dass für eine Arbeitslast mit 10.000 Benutzern und
diese Testtransaktionskombination die Front-End-Webserver mindestens 2 GB RAM plus eine etwaige Reserve
benötigen.
16,000
14,000
Verfügbarer RAM
WFE-1
12,000
Verfügbarer RAM
WFE-2
10,000
8,000
Verfügbarer RAM
WFE-3
6,000
Verfügbarer RAM
WFE-4
4,000
Verfügbarer RAM APP1
2,000
0
D.1 4GB
D.2 6GB
D.3 8GB D.4 16GB
Abbildung 22 – Verfügbarer RAM für Reihe D
38
Tabelle 15 zeigt eine Zusammenfassung der Daten, die während der drei Tests in Testreihe D erfasst wurden.
Test
WFE-RAM
Durchschn. RPS
Durchschn.
Seitenantwortzeit
(s)
Durchschn.
Antwortzeit (s)
Durchschn. CPUNutzung WFE-1
Verfügbarer RAM
WFE-1
Durchschn. CPUNutzung WFE-2
Verfügbarer RAM
WFE-2
Durchschn. CPUNutzung WFE-3
Verfügbarer RAM
WFE-3
Durchschn. CPUNutzung
PACNEC01
Verfügbarer RAM
PACNEC01
Durchschn. CPUNutzung APP-1
Verfügbarer RAM
APP-1
Durchschn. CPUNutzung APP-2
Verfügbarer RAM
APP-2
Durchschn. CPUNutzung WFE-4
Verfügbarer RAM
WFE-4
D.1
4 GB
189
0,22
D.2
6 GB
188
0,21
D.3
8 GB
188
0,21
D.4
16 GB
188
0,21
0,17
0,16
0,16
0,16
40,5%
37,9%
39,6%
37,3%
2.414
4.366
6.363
14.133
42,3%
40%
40,3%
39,5%
2.469
4.356
6.415
14.158
42,6%
42,4%
42,2%
43,3%
2.466
4.392
6.350
14.176
2,04%
1,93%
2,03%
2,14%
706.403
708.725
711.751
706.281
11,8%
13,1%
12,9%
12,3%
13.862
13.866
13.878
13.841
0,84%
0,87%
0,81%
0,87%
14.646
14.650
14.655
14.636
42,3%
43,6%
41,9%
45%
2.425
4.342
6.382
14.192
Tabelle 15 – Ausführliche Ergebnisse der Testreihe D
Testreihe E – Anzahl der Front-End-Webserver verändern
Bei dieser Testreihe wurde die Anzahl der Front-End-Webserver in der Farm verändert. Wie aus Abbildung 23 ersichtlich,
ist der Wert für durchschnittliche RPS bei 2 und 3 Front-End-Webservern etwas niedriger, da das System mit der
angewendeten Benutzerlast nicht ganz mithalten kann. Bei 4, 5 oder 6 Front-End-Webservern ist dagegen ein konstanter
RPS-Wert zu beobachten, da das System die volle Last von den Testagents aus verarbeitet.
39
250
200
150
Durchschn. RPS
100
50
0
E.1 2
WFEs
E.2 3
WFEs
E.3 4
WFEs
E.4 5
WFEs
E.5 6
WFEs
Abbildung 23 – Durchschnittliche RPS für Reihe E
Ein ähnliches Muster ist in Abbildung 24 zu erkennen: die Antwortzeiten sind für 2 und 3 WFEs hoch und für mehr
Front-End-Webserver sehr niedrig.
9
8
7
6
5
Durchschn.
Seitenantwortzeit
4
Durchschn.
Antwortzeit
3
2
1
0
E.1 2
WFEs
E.2 3
WFEs
E.3 4
WFEs
E.4 5
WFEs
E.5 6
WFEs
Abbildung 24 – Seiten- und Transaktionsantwortzeiten für Reihe E
Wie Sie in Abbildung 25 sehen, ist die CPU-Auslastung niedriger, wenn mehr Front-End-Webserver verfügbar sind. Durch
den Einsatz von 6 Front-End-Webservern kann die durchschnittliche CPU-Auslastung deutlich verringert werden, doch
für die Last von 10.000 Benutzern werden nur 4 Front-End-Webserver benötigt. Beachten Sie, dass Sie anhand dieser
Grafik nicht erkennen können, welche Konfigurationen die Last verarbeiten und welche nicht. Wie Sie sehen, liegt bei 3
Front-End-Webservern, für die wir feststellten, dass sie die Last nicht vollständig verarbeiten, die CPU-Auslastung knapp
über 50 %.
40
90.00%
80.00%
Durchschn. CPU-Nutzung WFE-1
70.00%
Durchschn. CPU-Nutzung WFE-2
60.00%
Durchschn. CPU-Nutzung WFE-3
50.00%
Durchschn. CPU-Nutzung WFE-4
40.00%
Durchschn. CPU-Nutzung WFE-5
30.00%
Durchschn. CPU-Nutzung WFE-6
20.00%
Durchschn. CPU-Nutzung APP-1
10.00%
Durchschn. CPU-Nutzung PACNEC01
0.00%
E.1 2 WFEs
E.2 3 WFEs
E.3 4 WFEs
E.4 5 WFEs
E.5 6 WFEs
Abbildung 25 – Durchschnittliche CPU-Auslastung für Reihe E
16,000
14,000
Verfügbarer RAM WFE-1
12,000
Verfügbarer RAM WFE-2
10,000
Verfügbarer RAM WFE-3
8,000
Verfügbarer RAM WFE-4
6,000
Verfügbarer RAM WFE-5
4,000
Verfügbarer RAM WFE-6
Verfügbarer RAM APP-1
2,000
0
E.1 2 WFEs
E.2 3 WFEs
E.3 4 WFEs
E.4 5 WFEs
E.5 6 WFEs
Abbildung 26 – Verfügbarer RAM für Reihe E
41
Tabelle 16 zeigt eine Zusammenfassung der Daten, die während der drei Tests in Testreihe E erfasst wurden.
Test
WFE-Server
Durchschn. RPS
Durchschn.
Seitenantwortzeit (s)
Durchschn.
Antwortzeit (s)
Durchschn. CPUNutzung WFE-1
Verfügbarer RAM
WFE-1
Durchschn. CPUNutzung WFE-2
Verfügbarer RAM
WFE-2
Durchschn. CPUNutzung WFE-3
Verfügbarer RAM
WFE-3
Durchschn. CPUNutzung WFE-4
Verfügbarer RAM
WFE-4
Durchschn. CPUNutzung WFE-5
Verfügbarer RAM
WFE-5
Durchschn. CPUNutzung WFE-6
Verfügbarer RAM
WFE-6
Durchschn. CPUNutzung PACNEC01
Verfügbarer RAM
PACNEC01
Durchschn. CPUNutzung APP-1
Verfügbarer RAM
APP-1
Durchschn. CPUNutzung APP-2
Verfügbarer RAM
APP-2
E.1
2
181
8,02
E.2
3
186
0,73
E.3
4
204
0,23
E.4
5
204
0,20
E.5
6
205
0,22
6,34
0,56
0,19
0,17
0,18
77,4
53,8
45,7
39,2
32,2
5.659
6.063
6.280
6.177
6.376
76,2%
53,8%
45,9%
38,2%
28,8%
5.623
6.132
6.105
6.089
5.869
n.z.
52,5%
43,9%
37,7%
31,2%
n.z.
6.124
6.008
5.940
6.227
n.z.
n.z.
44,5%
34,8%
34,7%
n.z.
n.z.
6.068
6.083
6.359
n.z.
n.z.
n.z.
35,1%
32%
n.z.
n.z.
n.z.
6.090
6.245
n.z.
n.z.
n.z.
n.z.
33,9%
n.z.
n.z.
n.z.
n.z.
5.893
2,13%
1,93%
2,54%
2,48%
2,5%
899.970
815.502
397.803
397.960
397.557
9,77%
11,7%
15%
14,7%
13,6%
14.412
13.990
14.230
14.227
14.191
1,06%
0,92%
1%
1%
1,04%
14.928
14.841
14.874
14.879
14.869
Tabelle 16 – Ausführliche Ergebnisse der Testreihe E
42
Testreihe F – Anzahl der CPUs für SQL Server verändern
Bei dieser Testreihe wurde die Anzahl der für SQL Server verfügbaren CPUs verändert.
250
200
150
Durchschn. RPS
100
50
0
F.1 4CPUs
F.2 6CPUs
F.3 8CPUs
F.4 16CPUs
F.5 80CPUs
Abbildung 27 – Durchschnittliche RPS für Reihe F
Wie Sie in Abbildung 28 erkennen, steigen trotz minimaler CPU-Auslastung auf dem Computer mit SQL Server die
Seiten- und die Transaktionsantwortzeiten, wenn weniger CPUs für SQL Server zur Verfügung stehen.
4.5
4
3.5
3
2.5
Durchschn. Seitenantwortzeit
2
Durchschn. Antwortzeit
1.5
1
0.5
0
F.1 4CPUs
F.2 6CPUs
F.3 8CPUs
F.4 16CPUs
F.5 80CPUs
Abbildung 28 – Seiten- und Transaktionsantwortzeiten für Reihe F
In Abbildung 29 übersteigt die durchschnittliche CPU-Nutzung in SQL Server für den gesamten Computer nicht 3 %. Bei
den drei Front-End-Webservern liegt der Wert während der gesamten Tests jeweils bei ca. 55 %.
43
70.00%
Durchschn. CPU-Nutzung WFE-1
60.00%
Durchschn. CPU-Nutzung WFE-2
50.00%
40.00%
Durchschn. CPU-Nutzung WFE-3
30.00%
Durchschn. CPU-Nutzung APP-1
20.00%
Durchschn. CPU-Nutzung FAST-1
10.00%
Durchschn. CPU-Nutzung FAST-2
0.00%
F.1 4CPUs
F.2 6CPUs
F.3 8CPUs
F.4 16CPUs
F.5 80CPUs
Abbildung 29 – Durchschnittliche CPU-Auslastung für Reihe F
16,000
14,000
12,000
Verfügbarer RAM WFE-1
10,000
Verfügbarer RAM WFE-2
8,000
Verfügbarer RAM WFE-3
Verfügbarer RAM APP-1
6,000
Durchschn. CPU-Nutzung FAST-1
4,000
Durchschn. CPU-Nutzung FAST-2
2,000
0
F.1 4CPUs
F.2 6CPUs
F.3 8CPUs
F.4 16CPUs
F.5 80CPUs
Abbildung 30 – Verfügbarer RAM für Reihe F
Tabelle 17 zeigt eine Zusammenfassung der Daten, die während der drei Tests in Testreihe F erfasst wurden.
Test
SQL-CPUs
Durchschn. RPS
Durchschn.
Seitenantwortzeit (s)
Durchschn.
Antwortzeit (s)
Durchschn. CPUNutzung WFE-1
Verfügbarer RAM
WFE-1
F.1
4
194
4,27
F.2
6
200
2,33
F.3
8
201
1,67
F.4
16
203
1,2
F.5
80
203
0,71
2,91
1,6
1,16
0,83
0,58
57,4%
57,4%
56,9%
55,5%
57,30%
13.901
13.939
13.979
14.045
5.786
44
Durchschn. CPUNutzung WFE-2
Verfügbarer RAM
WFE-2
Durchschn. CPUNutzung WFE-3
Verfügbarer RAM
WFE-3
Durchschn. CPUNutzung PACNEC01
Verfügbarer RAM
PACNEC01
Durchschn. CPUNutzung APP-1
Verfügbarer RAM
APP-1
Durchschn. CPUNutzung APP-2
Verfügbarer RAM
APP-2
Durchschn. CPUNutzung FAST-1
Verfügbarer RAM
FAST-1
Durchschn. CPUNutzung FAST-2
Verfügbarer RAM
FAST-2
60,3%
58,9%
62,6%
61,9%
59,60%
13.920
14.017
13.758
14.004
5.552
56,8%
62%
61%
62,1%
57,70%
13.859
13.942
13.950
13.971
5.769
1,56%
2,57%
2,69%
2,6%
2,37%
865.892
884.642
901.247
889.479
400.059
12,5%
12,8%
12,8%
12,8%
14,50%
13.856
13.713
13.725
13.745
13.804
0,22%
0,25%
0,26%
0,25%
n.z.
14.290
14.041
14.013
13.984
n.z.
12,8%
13%
13%
13%
n.z.
13.913
14.051
14.067
14.085
n.z.
12,9%
13,4%
13,3%
13,5%
n.z.
14.017
14.170
14.183
14.184
n.z.
Tabelle 17 – Ausführliche Ergebnisse der Testreihe F
Test mit Service Pack 1 (SP1) und dem Kumulativen Update vom Juni
Nach dem vollständigen Auffüllen der SharePoint Server 2010-Farm mit 120 Mio. Elementen installierten wir SharePoint
Server 2010 SP1 und FAST Search Server 2010 for SharePoint SP1, um herauszufinden, wie lang der Prozess auf einer
umfangreichen aufgefüllten Farm dauern würde.
SharePoint Server 2010
Wir wendeten SharePoint Server 2010 Service Pack 1 (SP1) und das Kumulative Update vom Juni im Labor an, um eine
Basis-Upgradezeit für ein Farmszenario mit umfangreichen Dokumentcentern zu ermitteln. In der folgenden Tabelle
werden die Server in der Farm aufgeführt, die das Upgrade mit SP1 und dem Kumulativen Update vom Juni benötigten,
der Start- und Endzeitpunkt jeder Installation, die Gesamtdauer der jeweiligen Installation, der Start- und Endzeitpunkt
des PSCONFIG-Upgradebefehls, die Gesamtdauer der Ausführung des PSCONFIG-Upgradebefehls sowie die
Gesamtdauer des Upgrades nach Servername und die Gesamtdauer aller Installationen.
45
Servername
Start SP1
Ende SP1
Diff.
(h:mm:ss)
Start KU/Juni
Ende
KU/Juni
Diff.
Start
(h:mm:ss) PSConfig
Ende
PSConfig
Diff.
(h:mm:ss)
APP-1
12.07.2011
04:00:00
12.07.2011
04:15:51
0:15:51
29.07.2011
10:45:00
29.07.2011
11:00:05
0:15:05
29.07.2011
13:25:50
29.07.2011
13:30:15
0:04:25
APP-2
12.07.2011
04:26:07
12.07.2011
04:39:31
0:13:24
29.07.2011
11:02:30
29.07.2011
11:17:23
0:14:53
29.07.2011
13:33:15
29.07.2011
13:35:11
0:01:56
WFE-1
12.07.2011
04:41:05
12.07.2011
04:49:16
0:08:11
29.07.2011
11:23:00
29.07.2011
11:31:07
0:08:07
29.07.2011
13:36:35
29.07.2011
13:38:11
0:01:36
WFE-2
12.07.2011
04:50:24
12.07.2011
04:57:47
0:07:23
29.07.2011
11:32:45
29.07.2011
11:40:46
0:08:01
29.07.2011
13:39:20
29.07.2011
13:40:54
0:01:34
WFE-3
12.07.2011
04:59:00
12.07.2011
05:06:39
0:07:39
29.07.2011
11:42:00
29.07.2011
11:49:47
0:07:47
29.07.2011
13:42:40
29.07.2011
13:44:14
0:01:34
WFE-4
12.07.2011
05:10:060
12.07.2011
05:17:30
0:07:24
29.07.2011
11:51:00
29.07.2011
11:58:49
0:07:49
29.07.2011
13:46:05
29.07.2011
13:47:41
0:01:36
WFE-5
12.07.2011
05:18:49
12.07.2011
05:27:07
0:08:18
29.07.2011
11:59:45
29.07.2011
12:08:19
0:08:34
29.07.2011
13:49:00
29.07.2011
13:50:36
0:01:36
WFE-6
12.07.2011
05:28:25
12.07.2011
05:35:40
0:07:15
29.07.2011
12:09:30
29.07.2011
12:17:10
0:07:40
29.07.2011
13:52:00
29.07.2011
13:53:35
0:01:35
WFE-CRAWL1
12.07.2011
05:37:20
12.07.2011
05:44:35
0:07:15
29.07.2011
12:18:10
29.07.2011
12:25:51
0:07:41
29.07.2011
13:54:35
29.07.2011
13:56:19
0:01:44
FAST-SSA-1
12.07.2011
05:49:00
12.07.2011
05:57:45
0:08:45
29.07.2011
12:39:40
29.07.2011
12:48:24
0:08:44
29.07.2011
13:57:30
29.07.2011
13:59:07
0:01:37
FAST-SSA-2
12.07.2011
05:59:08
12.07.2011
06:08:29
0:09:21
29.07.2011
12:51:30
29.07.2011
13:00:11
0:08:41
29.07.2011
14:00:00
29.07.2011
14:01:58
0:01:58
Gesamtdauer:
Gesamt:
1:40:46
1:43:02
0:21:11
3:44:59
Tabelle 18 – Zeitaufwand für die Anwendung von SP1 und der Kumulativen Updates vom Juni
FAST Search Server 2010 for SharePoint
Das Upgrade auf FAST Search Server 2010 for SharePoint SP1 nahm pro Knoten ca. 15 Minuten in Anspruch.
46
Sicherungen von SQL Server-Inhaltsdatenbanken
Dokumentcenter 1
Eine SQL Server-Datenbanksicherung wurde für die Inhaltsdatenbank für Dokumentcenter 1 (SPContent01) ausgeführt.
Die Sicherung wurde vor Anwendung von SP1 und des Kumulativen Updates vom Juni sowie nach SP1 ausgeführt. Im
Folgenden die Angaben zu Sicherungsdauer und -größe.
Datenbankname
SPContent01
SPContent01
Start Sicherung
Ende Sicherung
10.07.2011
09:56:00
29.07.2011
14:22:10
10.07.2011
23:37:00
30.07.2011
04:28:00
Diff.(h:mm:ss) Größe
(TB)
13:41:00
14,40
Hinweise
14:05:50
nach SP1/
KU/Juni
14,40
vor SP1
Tabelle 19 – Dauer der Ausführung von Sicherungen
Schlussfolgerungen
Die SharePoint Server 2010-Farm wurde bei einer Last von 15.000 gleichzeitigen Benutzern und zwei
SharePoint-Inhaltsdatenbanken mit insgesamt 120 Mio. Dokumenten erfolgreich getestet. Die Last von
15.000 gleichzeitigen Benutzern konnte mit drei Front-End-Webservern, wie in der Basisumgebung vorgesehen,
nicht unterstützt werden. Vielmehr benötigten wir für diese Arbeitslast sechs Front-End-Webserver.
Empfehlungen
Es folgt eine Zusammenfassung der Empfehlungen, die sich aus den Tests ergeben. Ausführlichere Erläuterungen zu
diesen Empfehlungen werden in eine Dokumentation zu bewährten Methoden für umfangreiche Dokumentbibliotheken
aufgenommen, die in Kürze veröffentlicht werden soll. Die Hinweise zur Hardware in den einzelnen Abschnitten sind
keine vollständige Liste. Vielmehr wird die Mindesthardware angegeben, die sich beim Auslastungstest mit
15.000 gleichzeitigen Benutzern und einer SharePoint Server 2010-Farm mit 120 Mio. Dokumenten als erforderlich
herausstellte.
Empfehlungen zu SQL Server 2008 R2




Hinweise zur Hardware für die getestete Last:
o 64 GB RAM auf dem Server mit SQL Server
o 16 CPU-Kerne auf dem Server mit SQL Server
Eine ausreichende IOPS-Leistung, etwa 2 IOPS pro in der SharePoint-Inhaltsdatenbank gespeichertem GB,
sollte gewährleistet sein.
Legen Sie die SQL Server 2008 R2-Eigenschaft Max. Grad an Parallelität auf (MAXDOP)=1 fest; der Standardwert ist 0.
Verwenden Sie mehrere LUNs (Laufwerksbuchstaben) im SAN, wobei jede LUN eine SQL Server-Datendatei
aufweist und jeder LUN eine (1) virtuelle CPU für jede verwendete LUN zugeordnet ist. Wir haben
5 Datendateien verwendet, alle auf separaten LUNs.
Empfehlungen zu SharePoint Server 2010

Hinweise zur Hardware für die getestete Last:
o 8 GB RAM auf jedem Front-End-Webserver
o 6 Front-End-Webserver
47



Fügen Sie den Registrierungsschlüssel für die Deaktivierung der Loopbackprüfung wie folgt hinzu:
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\DisableLoopbackCheck=1
Dämmen Sie Probleme mit der Tabellenindexfragmentierung während des Massenimports von Dokumenten
manuell ein, indem Sie ALTER INDEX für die betroffenen Tabellenindizes ausführen.
Verwenden Sie für den Massenimport von Dokumenten eher SPFileCollection.ADD, anstatt mit SPFolder.CopyTo
Dokumentduplikate zu erstellen.
Empfehlungen für FAST Search Server 2010 for SharePoint


Hinweise zur Hardware für die getestete Last:
o 4 Reihen FAST Search Server 2010 for SharePoint-Indexserver
Registrierungsupdates für den SharePoint Server 2010-Dokumentcrawler
Auf Knoten, auf denen der FAST-Crawler für die Inhalts-SSA (APP-1 und APP-2) ausgeführt wurde, wurden die
folgenden Registrierungswerte aktualisiert, um die Crawlerleistung in der Struktur zu steigern:
HKLM\SOFTWARE\Microsoft\Office Server\14.0\Search\Global\Gathering Manager
1. FilterProcessMemoryQuota
Der Standardwert 100 MB wurde auf 200 MB geändert.
2. DedicatedFilterProcessMemoryQuota
Der Standardwert 100 MB wurde auf 200 MB geändert.
3. FolderHighPriority
Der Standardwert 50 wurde auf 500 geändert.

Überwachen der FAST Search Server 2010 for SharePoint-Indexdurchforstung
Der Crawler sollte mindestens dreimal täglich überwacht werden. Die Durchforstung von 100 Mio. Elementen
dauerte rund 2 Wochen. Bei jeder Überwachung der Durchforstung wurden die folgenden vier Prüfungen ausgeführt:
1. rc –r | select-string “# doc”
Prüft, wie stark die Dokumentprozessoren ausgelastet sind.
2. Überwachen der Größe der Durchforstungswarteschlange
Verwenden Sie die Berichterstellung oder SQL Server Management Studio, um MSCrawlURL abzurufen.
3. indexerinfo –a doccount
Stellen Sie sicher, dass alle Indexer Berichte generieren, um festzustellen, wie viele Dokumente in
1.000 ms indiziert werden. Je nach Typ der zu indizierenden Dokumente lag dieser Wert zwischen
40 und 120.
4. Indexerinfo –a status
Überwachen Sie die Integrität der Indexer und des Partitionslayouts.
48
Referenzen











SharePoint Server 2010-Kapazitätsverwaltung: Softwarebeschränkungen und -grenzen
(http://technet.microsoft.com/de-de/library/cc262787.aspx)
Schätzen der Leistungs- und Kapazitätsanforderungen für große Dokumentrepositorys in SharePoint Server 2010
(http://technet.microsoft.com/de-de/library/hh395916.aspx)
Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server 2010)
(http://technet.microsoft.com/de-de/library/cc298801.aspx)
Ressourcencenter: Leistungs- und Kapazitätsplanung für SharePoint auf TechNet
(http://technet.microsoft.com/de-de/office/sharepointserver/bb736741)
Bewährte Methoden für die Virtualisierung (SharePoint Server 2010) (http://technet.microsoft.com/dede/library/hh295699.aspx)
Bewährte Methoden für SQL Server 2008 in einer SharePoint Server 2010-Farm
(http://technet.microsoft.com/de-de/library/hh292622.aspx)
Bewährte Methoden für die Kapazitätsverwaltung für SharePoint Server 2010 (http://technet.microsoft.com/dede/library/hh403882.aspx)
Empfehlungen zur Leistung und Kapazität für FAST Search Server 2010 for SharePoint
(http://technet.microsoft.com/de-de/library/gg702613.aspx)
Bulk Loader (Tool) (http://code.msdn.microsoft.com/Bulk-Loader-Create-Unique-eeb2d084)
LoadBulk2SP (Tool) (http://code.msdn.microsoft.com/Load-Bulk-Content-to-3f379974)
Skripts für SharePoint-Leistungstests (http://code.msdn.microsoft.com/SharePoint-Testing-c621ae38)
49
Herunterladen