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