SQL SERVER-RBS-LEISTUNG MIT SHAREPOINT SERVER 2010 UND STORSIMPLE-SPEICHERLÖSUNG
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
SQL Server-RBS-Leistung mit SharePoint
Server 2010 und StorSimple-Speicherlösung
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.
Mit diesem Dokument werden keine Rechte an geistigem Eigentum an einem Microsoft-Produkt auf Sie
übertragen. Sie sind berechtigt, dieses Dokument zu kopieren und für eigene interne Referenzzwecke zu
nutzen. Sie sind nicht berechtigt, dieses Dokument für eigene interne Zwecke oder Referenzzwecke zu
bearbeiten.
© 2011 Microsoft Corporation. Alle Rechte vorbehalten.
Microsoft SharePoint Server 2010 April 2011 SQL Server-RBS-Leistung mit SharePoint Server 2010 und StorSimple-Speicherlösung Burzin Patel StorSimple, Inc. Peter Scharlock Microsoft Corporation Technische Lektoren: John Flores (StorSimple, Inc.), Srini Acharya, Steve Howard, Shaun Tinline-Jones, Mike Weiner, Kun Cheng, Prem Mehra, Jimmy May, David Koronthaly, Bill Baer Dezember 2010; überarbeitet im April 2011 Gilt für: SharePoint Server 2010 und SQL Server 2008 R2 Zusammenfassung: Die Nutzung von Microsoft® SharePoint®-Technologie hat in den letzten Jahren stark zugenommen. Dies ist darauf zurückzuführen, dass die Benutzer mehr und umfangreichere Dokumente in SharePoint-Bibliotheken speichern. Diese beiden Faktoren bedeuten für SharePoint-Administratoren eine Zunahme der Speicherkosten sowie Herausforderungen bezüglich der Leistung und Verwaltbarkeit. Microsoft hat aus diesem Grund in SharePoint Server 2010 die systemeigene Unterstützung des Remote-BLOB-Speicher (RBS)-Features eingeführt. In diesem Whitepaper wird das RBS-Feature in Bezug auf SharePoint Server 2010 erläutert, und außerdem werden Auswirkungen auf die Leistung in Bezug auf wichtige Faktoren einer SharePoint-Farm analysiert, wie beispielsweise Datenbankgröße, Datenbanksicherungsgröße, Transaktionsantwortzeiten und Sicherungs-/Wiederherstellungszeit. © 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 2 Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten, wenden Sie sich an SharePoint IT Docs
Microsoft SharePoint Server 2010 April 2011
Inhalt
Einführung ........................................................................................................................................................4
Remote-BLOB-Speicher .......................................................................................................................................4
Gründe für die Verwendung von RBS ..............................................................................................................5
Testziele ...........................................................................................................................................................6
Testmethodik.....................................................................................................................................................7
Arbeitsauslastung ........................................................................................................................................7
Serverkonfiguration......................................................................................................................................9
Hardwarekonfiguration ......................................................................................................................... 10
Speicherkonfiguration .......................................................................................................................... 10
Softwarekonfiguration .......................................................................................................................... 10
Testergebnisse und Beobachtungen .................................................................................................................... 11
1. Auswirkungen von RBS auf die SQL Server-Datenbankgröße ....................................................................... 12
2. Auswirkungen von RBS auf die Datenbanksicherungsgröße .......................................................................... 14
3. Auswirkungen von RBS auf die Sicherungs- und Wiederherstellungszeiten ............................................. 17
4. Auswirkungen von RBS auf die Indexneuerstellungsleistung ........................................................................ 19
5. Auswirkungen von RBS auf die Antwortzeiten von SharePoint-Transaktionen ................................................. 21
6. Auswirkungen von RBS auf die Durchforstungsleistung ............................................................................... 23
7. Auswirkungen von RBS auf die Leistung beim Hochladen von Dateien ........................................................... 24
8. Zeitaufwand zum Migrieren von Daten ...................................................................................................... 26
Schlussbemerkung ........................................................................................................................................... 27
Weitere Ressourcen .......................................................................................................................................... 28
Informationen zu StorSimple ............................................................................................................................. 28
Informationen zu Microsoft ................................................................................................................................ 28
© 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 3
Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten,
wenden Sie sich an SharePoint IT Docs
Microsoft SharePoint Server 2010 April 2011
Einführung
Die Popularität von Microsoft SharePoint Server hat in den letzten Jahren beinahe exponentiell
zugenommen. Dies ist darauf zurückzuführen, dass mehr Kunden SharePoint Server nutzen sowie dass
mehr Kunden größere Dokumente und Datasets innerhalb der SharePoint-Farmen speichern. Mit der
neuesten Version von SharePoint Server 2010 wird diese Zunahme bei den Nutzungszahlen voraussichtlich
sogar noch verstärkt.
SharePoint Server 2010 bietet eine optimierte Benutzeroberfläche, die das Arbeiten vereinfacht, wodurch
SharePoint Server für alle Datentypen zum Repository der Wahl wird. In Kombination mit der Zunahme an
Rich-Media-Inhalten werden die Inhalte der SharePoint-Farm aufgebläht, was wiederum zu einer
erheblichen Zunahme an benötigtem physischen Speicher führt. Diese quantitative Zunahme stellt oft eine
Herausforderung für SharePoint-Administratoren dar, die nun den zusätzlichen Aufwand aufgrund der
Verwaltung von mehr Inhalten, größeren Datenbanken und umfangreicheren Sicherungen meistern
müssen. Zur Bewältigung all dieser Probleme gibt es in SharePoint Server 2010 ein neues Feature, nämlich
Remote-BLOB-Speicher (RBS), durch das die Probleme im Zusammenhang mit der Zunahme von
SharePoint-Inhalten behoben werden können.
In diesem Whitepaper werden die Vorteile und Verwendungsmerkmale des RBS-Features in Kombination
mit Microsoft SharePoint Server 2010 vorgestellt. Darüber hinaus werden die Leistungsmerkmale einer
SharePoint-Farm erläutert, die wie im nächsten Abschnitt beschrieben für die Verwendung mit der
StorSimple-Speicherlösung konfiguriert ist. Vorteile wie beispielsweise die Reduzierung der
Datenbankgröße, schnellere Datenbanksicherungen, schnellere Datenbankwiederherstellungen, kürzere
Antwortzeiten bei größeren Dokumenten, Vorteile bei der Datenbankwartung und geringere Anforderungen
an den Back-End-Speicher werden im Zusammenhang mit den entsprechenden Leistungsdatenpunkten
behandelt. Alle in diesem Whitepaper beschriebenen Datenpunkte wurden im Rahmen der Leistungstests in
den Messlabors von StorSimple, Inc. in Santa Clara zusammen mit den SQL Server- und
SharePoint-Produktteams von Microsoft erstellt.
Hinweis: Die Testergebnisse in diesem Whitepaper gelten speziell für die in diesem
Whitepaper beschriebenen Umgebungen. Ihre Ergebnisse können davon abweichen.
Remote-BLOB-Speicher
BLOB ist ein Akronym für Binary Large Object und bezieht sich im Kontext der SharePoint-Anwendung auf
das in der Datenbank gespeicherte Dateiobjekt. Remote-BLOB-Speicher (RBS) ist eine Microsoft®
SQL Server®-Bibliotheks-API (Application Programming Interface, Anwendungsprogrammierschnittstelle),
die als zusätzliches Feature Pack für Microsoft SQL Server 2008 R2 integriert ist. Mit dem RBS-Feature
können BLOBs (Binary Large Objects) von Anwendungen in einem externen Speicherort außerhalb der
Datenbank gespeichert werden, wie beispielsweise in einer Dateifreigabe. Dadurch wird der erforderliche
Speicherplatz für die SQL Server-Datenbank reduziert. Ein RBS-Speicher besteht in der Regel aus einem
separaten Volume im selben Netzwerk wie SQL Server. SharePoint Server 2010 nutzt das RBS-Feature zum
externen Speichern von in der Inhaltsdatenbank gespeicherten BLOBs. Von SQL Server und SharePoint
Server wird die Datenintegrität zwischen den Datenbank-Datensätzen und dem externen RBS-Speicher auf
Datenbankbasis gemeinsam verwaltet.
Für das RBS-Feature von SQL Server muss auf jedem SharePoint-Web-Front-End-Server (WFE), auf dem
die SharePoint-Anwendung konfiguriert ist, ein Anbieter installiert sein. Der Anbieter besteht aus einer
© 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 4
Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten,
wenden Sie sich an SharePoint IT Docs
Microsoft SharePoint Server 2010 April 2011
Reihe von DLLs, mit denen Methoden für die RBS-APIs implementiert werden und das eigentliche externe
Speichern der BLOBs ausgeführt wird.
Für alle in diesem Whitepaper durchgeführten Tests war der StorSimple SharePoint Database Optimizer,
der einen RBS-Anbieter aufweist, für die SharePoint Server 2010-Farm konfiguriert. Die Konfiguration
erfolgte wie in der nachfolgenden Abbildung (i) dargestellt mithilfe des RBS-Konfigurationsmanagers von
StorSimple SharePoint Database Optimizer, der eine Erweiterung der Website für die Zentraladministration
darstellt.
Abbildung (i) – StorSimple SharePoint Database Optimizer – RBS-Konfiguration
Gründe für die Verwendung von RBS
Von SharePoint Server werden alle Daten in der Datenbank gespeichert. Wenn immer mehr Inhalte
gespeichert werden, kann die Datenbank sehr schnell an Größe zunehmen. Dies ist zurückzuführen auf das
Hochladen neuer Inhalte nach SharePoint Server sowie auf Überarbeitungen an vorhandenen Inhalten,
wenn die SharePoint-Versionsverwaltung aktiviert ist. Auch wenn nur ein einziges Byte eines
SharePoint-Dokuments geändert wird, wird eine neue Kopie des gesamten BLOB in der Datenbank
gespeichert, und die vorherige Kopie wird als ältere Version gekennzeichnet. Viele
SharePoint-Administratoren mussten bereits feststellen, dass dies zu einer exponentiellen Zunahme bei der
Größe der Inhalte führt.
Wenn die Größe der Datenbank zunimmt, wird es immer schwieriger, das System zu verwalten und eine
optimale Leistung sicherzustellen. Andererseits wird die Ausführung grundlegender Aufgaben wie das
Sichern und Wiederherstellen sowie die Datenbankdefragmentierung immer schwieriger. Dies ist einer der
© 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 5
Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten,
wenden Sie sich an SharePoint IT Docs
Microsoft SharePoint Server 2010 April 2011
Gründe, weshalb Microsoft den Kunden empfiehlt, die Größe der Datenbanken wie im folgenden Artikel
erläutert auf eine leichter verwaltbare Größe zu beschränken: „SharePoint Server 2010-
Kapazitätsverwaltung: Softwarebeschränkungen und –grenzen” (http://technet.microsoft.com/en-
us/library/cc262787.aspx#ContentDB). Bei Einhaltung dieser empfohlenen bewährten Methoden muss der
SharePoint-Administrator möglicherweise mehrere Datenbanken erstellen, was aus Sicht der Verwaltung
und Wartbarkeit kostspielig ist. Durch die Zunahme der Anzahl von Datenbanken müssen mehr
Sicherungen verwaltet und überwacht werden, wofür wiederum mehr SharePoint-Administratoren benötigt
werden.
Mithilfe von RBS können von Ihrer Anwendung große Mengen unstrukturierter Daten gespeichert werden,
wie z. B. Rich-Media-Videos oder -Audiodateien, wobei sowohl die relationalen Funktionen von SQL Server
als auch die Skalierbarkeit eines Windows®-Dateisystem-BLOB-Speichers genutzt werden. Zusätzlich zu
diesem Hauptvorteil bietet das RBS-Feature zahlreiche weitere Vorteile im Zusammenhang mit
Speicherkosten, Wartbarkeit, Leistung und Flexibilität:
Kleinere Datenbanken und damit die optimale Nutzung von teuren Datenbankserverressourcen wie
Prozessoren, Arbeitsspeicher und Datenträgern
Kleinere Datenbanksicherungsdateien
Schnellere Sicherung und Wiederherstellung
Schnellere Datenbankwartungsvorgänge wie Defragmentierung und Indexneuerstellung
Verbesserte Gesamtleistung, insbesondere beim Speichern von großen Objekten und beim Zugreifen
auf große Objekte.
Wenn für SharePoint Server die Verwendung von RBS konfiguriert ist, bleibt die Transaktionssemantik von
Benutzervorgängen vollständig erhalten, und aus Sicht des Endbenutzers gibt es überhaupt keine
Änderung. Das externe Speichern der BLOBs außerhalb der Datenbank erfolgt auf dem Back-End
automatisch durch SharePoint Server in Verbindung mit dem RBS-Anbieter. RBS arbeitet bei Verwendung
mit dem SQL Server-Failoverclustering problemlos. Allerdings kann RBS nicht zusammen mit der
SQL Server-Spiegelung verwendet werden, wenn die SharePoint-Inhaltsdatenbank auf einem
Datenbankserver in einer anderen Farm gespiegelt wird.
Testziele
Ziel unserer Tests war es, die Leistung einer SharePoint-Farm zu beschreiben, für die RBS mithilfe des
StorSimple-RBS-Anbieters konfiguriert ist, der Bestandteil von StorSimple SharePoint Database Optimizer
ist, und anschließend die Leistung mit der Leistung einer SharePoint-Farm ohne aktiviertes RBS-Feature zu
vergleichen. Darüber hinaus wollten wir die Auswirkungen von RBS auf folgende Aspekte messen:
Größe von SQL Server-Datenbankdaten und -Transaktionsprotokolldateien
Größe der Sicherungsdatei
Zeitaufwand zum Sichern und Wiederherstellen der Inhaltsdatenbank
Zeitaufwand für die Neuerstellung der Inhaltsdatenbankindizes
Auswirkungen der Indexneuerstellung auf die Leistung von Endbenutzertransaktionen
Antwortzeiten von SharePoint-Transaktionen
SharePoint Server-Suchdurchforstung
Leistung beim Hochladen von Dateien
Einheitliche Leistung bei Zunahme des Inhalts
Zeitaufwand für das Migrieren von Daten zum und aus dem RBS-Speicher
© 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 6
Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten,
wenden Sie sich an SharePoint IT Docs
Microsoft SharePoint Server 2010 April 2011 Das Verhalten von SharePoint Server 2010 für unterschiedliche Arbeitsauslastungen von Anwendungen oder unterschiedliche Schwellenwerte für die Größe von BLOBs, die extern gespeichert werden, würde den Rahmen dieses Whitepapers sprengen. Testmethodik Wir hatten uns das Ziel gesteckt, die im vorherigen Abschnitt beschriebenen Tests für eine möglichst realistische Arbeitsauslastung auszuführen. Außerdem wollten wir für alle Tests eine relativ einheitliche Testkonfiguration (Serverkonfiguration, Datenbankeinstellungen, Tabellenschema usw.) verwenden, um die Leistung der verschiedenen Vorgänge vergleichen und gegenüberstellen zu können. Die Tests waren grob in drei Kategorien unterteilt: (1) Uploadtest, (2) voller Transaktionsmischungstest und (3) verschiedene Tests. Dokumentuploadtest: Mit diesen Tests wurden Leistung und Auswirkungen von RBS auf das Hochladen von Benutzerdokumenten für verschiedene durchschnittliche Dateigrößen gemessen. Voller SharePoint-Transaktionsmischungstest: Mit diesen Tests wurden die Auswirkungen von RBS auf die Leistung der SharePoint-Farm gemessen. Diese Tests beinhalteten alle häufig ausgeführten SharePoint--Benutzertransaktionen wie Durchsuchen, Suchen, Hochladen von Dokumenten und Websiteerstellung. Die wichtigste verwendete Leistungsmetrik war die durchschnittliche Antwortzeit der Webseiten. Verschiedene Tests: Dieses Tests beinhalteten Vorgänge wie Datenbanksicherung und - wiederherstellung, die Migration von Objekten zur Datenbank und aus der Datenbank sowie zum RBS-Speicher sowie die SharePoint Server-Suchdurchforstung. Arbeitsauslastung Die verschiedenen Fragen, auf die wir mithilfe unserer Tests Antworten suchten, zwangen uns zur Verwendung unterschiedlicher Arbeitsauslastungen in Form von Datasets. Für die Tests wurden zwei Arbeitsauslastungen verwendet: (1) die Dateiupload-Arbeitsauslastungsmischung und die (2) volle SharePoint-Transaktionsmischung. Die Dateiupload-Arbeitsauslastungsmischung beinhaltete zwei Dateisätze mit einer durchschnittlichen gewichteten Größe von etwa 100 KB zum Erstellen der Datenbank mit 100 GB sowie 500 KB zum Erstellen der Inhaltsdatenbank mit 1 TB. Die Verteilung der Dateigröße für das Dataset mit 100 KB ist in Abbildung (ii) dargestellt. © 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 7 Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten, wenden Sie sich an SharePoint IT Docs
Microsoft SharePoint Server 2010 April 2011
Abbildung (ii) – Verteilung der Dateigröße für die Arbeitsauslastung
Die Dateiupload-Arbeitsauslastungsmischung wurde in erster Linie zum Messen der
Dokumentuploadmerkmale mit und ohne RBS verwendet.
Die volle SharePoint-Transaktionsmischung wurde zur Darstellung einer typischen SharePoint-
Transaktionskonstellation verwendet, die ein Endbenutzer täglich ausführen würde. Mit Microsoft Visual
Studio® Team System 2008 Team Suite wurde die Arbeitsauslastung mithilfe einer auf Codeplex
verfügbaren modifizierten Version des ursprünglichen Microsoft Office SharePoint Server 2007-
Leistungstoolkits generiert. Für die einzelnen Tests wurden die folgenden Transaktionen verwendet.
Name des Tests Beschreibung Prozentsatz
Durchlaufen eines Seitenworkflows: Auschecken, Genehmigen und
Page Workflow 1%
Einchecken
Create Page Erstellen einer neuen Seite 6%
Site Manager Öffnen der Website-Manager-Ansicht 1%
Create Publishing Site Erstellen einer neuen Website mithilfe der Veröffentlichungsvorlage 1%
Erstellen einer neuen Websitesammlung mithilfe der
Create Team Site 1%
Teamwebsitevorlage im Verzeichnis sites
Homepage Navigieren zur Portalhomepage 25%
Large Page Navigieren zu einer Reihe von Seiten im Portal 10%
My Site Public Navigieren zur öffentlichen Seite Meine Website 16%
My Site Edit Profile Bearbeiten des persönlichen Profils 7%
Ausführen einer Suchabfrage und Anzeigen der Ergebnisse auf der
Search Query 15%
Suchcenterseite
© 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 8
Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten,
wenden Sie sich an SharePoint IT Docs
Microsoft SharePoint Server 2010 April 2011
Upload Document Hochladen eines Dokuments (durchschnittlich 90 KB) 5%
Download Document Herunterladen eines Dokuments (durchschnittlich 90 KB) 12%
Gesamt: 100%
Tabelle (i) – Voller SharePoint-Transaktionsmischungstest
Serverkonfiguration
Für die SharePoint-Farm waren wie in in Abbildung (iii) dargestellt sechs Web-Front-End-Server (WFE), ein
Anwendungsserver zum Ausführen des Suchcrawlers sowie ein Datenbankserver konfiguriert.
Abbildung (iii) - SharePoint-Farmtopologie
Die WFE- und Anwendungsserver waren für die Ausführung auf einem virtuellen Computer konfiguriert,
während der Datenbankserver auf einem dedizierten physischen Server (nicht virtualisiert) ausgeführt
wurde.
Darüber hinaus wurde mithilfe von sechs Arbeitsauslastungsservern auf der Basis eines virtuellen
Computers (in der obigen Abbildung nicht dargestellt) die
Arbeitsauslastung für die Dateiupload-Transaktionsmischung und die volle SharePoint-
Transaktionsmischung generiert.
© 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 9
Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten,
wenden Sie sich an SharePoint IT DocsMicrosoft SharePoint Server 2010 April 2011
Hardwarekonfiguration
Computerrolle Hardware
WFEs 2 Intel Xeon E5504-Prozessoren mit 2 GHz (virtualisiert)
8 GB RAM
Anwendungsserver 2 Intel Xeon-Prozessoren mit 2 GHz (virtualisiert)
8 GB RAM
Datenbankserver 2 Intel Xeon-Vierkernprozessoren mit 2 GHz (nicht virtualisiert)
16 GB RAM (12 GB davon für SQL Server)
Tabelle (ii) – Hardwarekonfiguration
Speicherkonfiguration
Der gesamte für den Benchmarktest verwendete Speicher wurde für die StorSimple 1010 Storage
Appliance1 konfiguriert. Die SQL Server-Systemdatenbanken, SharePoint-Datenbanken und der
BLOB-Speicher befanden sich wie in der nachfolgenden Tabelle (iii) dargestellt auf separaten Volumes.
Volume Laufwerk
SQL-Systemdatenbanken C:\
Daten- und Protokolldateien von H:\
tempdb
Datendatei der Inhaltsdatenbank P:\
Protokolldatei der Q:\
Inhaltsdatenbank
Datendatei der Suchdatenbank S:\
Protokolldatei der Suchdatenbank Q:\
BLOB-Speicher X:\
Sicherungen O:\
Tabelle (iii) – Speicherkonfiguration
Softwarekonfiguration
Für die verschiedenen Server wurden die in der nachfolgenden Tabelle (iv) aufgeführten Softwareversionen
und Einstellungen verwendet.
1
StorSimple 1010 ist eine anwendungsoptimierte Speicherappliance für Anwendungen wie Microsoft SharePoint und
Microsoft Exchange. Weitere Informationen finden Sie unter http://www.storsimple.com.
© 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 10
Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten,
wenden Sie sich an SharePoint IT DocsMicrosoft SharePoint Server 2010 April 2011
Software Zusätzliche Änderungen
Computerrolle
WFEs und Windows Server® 2008 R2 Die neuesten Windows Server-
Anwendungsserver Enterprise x64 Patches wurden angewendet.
Microsoft SharePoint Server 2010
RBS.msi wurde über das
SQL Server 2008 R2 Feature Pack
installiert.
Datenbankserver Windows Server 2008 R2 Die neuesten Windows Server-
Enterprise x64 Patches wurden angewendet.
SQL Server 2008 R2
Die folgenden Änderungen wurden
Enterprise x64
an den Einstellungen des
Datenbankservers vorgenommen:
- 'Max. Serverarbeitsspeicher' =
12 GB
- 4 tempdb-Datendateien wurden
erstellt und in ein eigenes
Volume verschoben.
Tabelle (iv) – Softwarekonfiguration
Testergebnisse und Beobachtungen
In diesem Abschnitt finden Sie eine Zusammenfassung der Ergebnisse für die Tests, mit denen die
Auswirkungen der Verwendung von RBS zum externen Speichern der BLOB-Inhalte auf die verschiedenen
Attribute einer Bereitstellung von SharePoint Server 2010 gemessen und die in der folgenden Tabelle (v)
aufgeführten Fragen beantwortet werden sollen.
Testbeschreibung
1 Auswirkungen von RBS auf die Datenbankgröße
2 Auswirkungen von RBS auf die Datenbanksicherungsgröße
3 Auswirkungen von RBS auf die Sicherungs- und Wiederherstellungszeit
4 Auswirkungen von RBS auf die Indexneuerstellungsleistung
5 Auswirkungen von RBS auf die Antwortzeiten von SharePoint-Transaktionen
6 Auswirkungen von RBS auf den Durchforstungsvorgang
7 Auswirkungen von RBS auf den Dateiupload für verschiedene Dateigrößen
8 Zeitaufwand für das Migrieren von Daten zum und aus dem RBS-Speicher
Tabelle (v) – Testszenarien
© 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 11
Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten,
wenden Sie sich an SharePoint IT DocsMicrosoft SharePoint Server 2010 April 2011
1. Auswirkungen von RBS auf die SQL Server-
Datenbankgröße
Wie im Abschnitt zu RBS erläutert entspricht die Mehrzahl der Daten in der SQL Server-Datenbank
SharePoint-BLOB-Daten. Bei den meisten SharePoint-Kundenbereitstellungen, insbesondere wenn
SharePoint für die Zusammenarbeit und die Datensatzverwaltung verwendet wird, machen die BLOB-Daten
über 95 % der Datenbankgröße aus. In Abhängigkeit von der Größe der Datenbank kann dieser Inhalt
problemlos Hunderten von Gigabytes an Datenbankdaten entsprechen. Dies ist zwar beabsichtigt, wirft
aber viele Probleme auf und schränkt oft die Verwendung von SharePoint Server, die Skalierbarkeit der
Lösung sowie die Verwendung bestimmter vorteilhafter Features wie z. B. Papierkörbe ein.
Bei den Tests, deren Ergebnisse in diesem Abschnitt zusammengefasst werden, haben wir die Größe der
Datenbank, der Datendateien und der Transaktionsprotokolldatei für SharePoint-Inhaltsdatenbanken mit
100 GB bestehend aus 100.000 Objekten und für eine SharePoint-Inhaltsdatenbank mit 1 TB bestehend
aus 2 Millionen Objekten mit und ohne das RBS-Feature gemessen. Die Dateigrößen für jede dieser
Datenbanken sind in Tabelle (vi) angegeben.
Größe (GB)
Reduzierung
Ohne RBS Mit RBS
Datenbankgröße (100 GB) 217.2 7.0 96.8%
Größe der Datenbank-Datendateien (100 GB) 106.9 3.2 97.0%
Größe der Datenbank-
Transaktionsprotokolldateien (100 GB) 111.6 3.8 96.6%
Größe der extern gespeicherten RBS-Daten -- 96.2 --
Datenbankgröße (1 TB) 2,292 26 98.9%
Größe der Datenbank-Datendateien (1 TB) 1,120 6.5 99.4%
Größe der Datenbank-
Transaktionsprotokolldateien (1 TB) 1,173 20 98.3%
Größe der extern gespeicherten RBS-Daten -- 1,115 --
Tabelle (vi) – Datenbank- und Dateigrößen
© 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 12
Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten,
wenden Sie sich an SharePoint IT DocsMicrosoft SharePoint Server 2010 April 2011
Abbildung (iv) – Datenbank- und Dateigrößen
Wie in Abbildung (iv) oben dargestellt hatten ohne RBS die Datenbanken nach dem Hochladen von 100 GB
bzw. 1 TB an SharePoint-Inhalten eine Größe von insgesamt 217,2 GB bzw. 2,29 TB. Für die Datenbank
mit 100 GB an SharePoint-Inhalten entsprachen 106,9 GB den eigentlichen Datenbankdaten, während die
anderen 111,6 GB dem Datenbanktransaktionsprotokoll entsprachen. Auf ähnliche Weise entsprachen für
die Datenbank 1 TB an SharePoint-Inhalten 1,12 TB der Datenbank, und 1,2 TB entsprachen dem
Datenbanktransaktionsprotokoll. Für eine Datenbank mit aktiviertem RBS war die Inhaltsdatenbank mit
100 GB um 96,8 % kleiner, während die Inhaltsdatenbank mit 1 TB um 98,9 % kleiner war. Die Daten-
und Transaktionsprotokolldateien waren entsprechend kleiner.
Während der zusätzliche erforderliche Speicherplatz zum Speichern von BLOBs innerhalb der Datenbank in
vielen Fällen offensichtlich und gut nachvollziehbar ist, ist das Wachstum der SQL Server-
Transaktionsprotokolldatei ein nicht so bekannter und oft sogar weniger nachvollziehbarer Punkt. Dieses
Wachstum ist darauf zurückzuführen, dass SQL Server eine transaktionskonsistente Datenbank ist und
vollständige ACID-Eigenschaften (Atomicity, Consistency, Isolation, Durability = Atomarität, Konsistenz,
Isolation und Dauerhaftigkeit) bietet. Dadurch wird garantiert, dass jede Transaktion entweder erfolgreich
ausgeführt wird oder fehlschlägt. Es gibt keinen Status dazwischen. Die ACID-Eigenschaften werden von
SQL Server implementiert, indem jeder Vorgang mithilfe des Write-Through-Datenträgerzugriffs vollständig
im Datenbanktransaktionsprotokoll protokolliert wird, bevor ein Commit für den Vorgang ausgeführt wird.
ACID-Eigenschaften gelten für alle SQL Server-Daten und -Datentypen, einschließlich BLOBs. Es gibt
keinen Mechanismus, um dies irgendwie zu deaktivieren oder zu umgehen. Wenn die SharePoint-BLOBs in
der SQL Server-Datenbank gespeichert werden, werden die BLOBs erwartungsgemäß zweimal geschrieben.
Zum einen in das Transaktionsprotokoll und danach in die Datenbankdatei, was anhand der Größe der
Datenbank (2,29 TB), die zum Speichern von 1 TB an Benutzerinhalten verwendet wird, ersichtlich ist.
Diese Protokolldatei wird abgeschnitten, wenn die Datenbanksicherung erstellt und die Option Protokoll
abschneiden ausgewählt ist.
© 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 13
Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten,
wenden Sie sich an SharePoint IT DocsMicrosoft SharePoint Server 2010 April 2011
Wenn RBS für das externe Speichern der BLOB-Inhalte verwendet wird, werden die BLOB-Daten in den
BLOB-Speicher geschrieben, bevor für den SharePoint-Vorgang ein Commit ausgeführt wird. Deshalb
werden die ACID-Eigenschaften des Vorgangs indirekt umgesetzt, ohne dass der doppelte Schreibaufwand
für das Transaktionsprotokoll anfällt. Der Grad der Reduzierung bei den Datenbankdaten und
Transaktionsprotolldateien ist abhängig von der Größe der Daten und der Tatsache, wie oft Sie das
Transaktionsprotokoll während einer Sicherung abschneiden.
Die extern gespeicherten BLOB-Inhalte werden in einer zentralen Dateifreigabe gespeichert, auf die alle
SharePoint-WFEs und Anwendungsserver Zugriff haben. Dieses Dateifreigabevolume kann sich auf dem
Datenbankserver oder einem anderen Server befinden. In Abbildung (v) sind die Eigenschaften der für die
Benchmarktests verwendeten Dateifreigabe dargestellt.
Abbildung (v) – Größe des RBS-Dateifreigabevolumes
Hinweis: RBS reduziert die Größe der Datenbank, indem die BLOB-Daten auf einen externen Speicher
verschoben werden. Deshalb müssen Sie unbedingt berücksichtigen, dass der von BLOB-Daten insgesamt
belegte Speicherplatz nicht reduziert wird. Speicherhersteller können dabei eventuell mit proprietären
Technologien wie z. B. der Deduplizierung behilflich sein, womit der belegte Speicherplatz reduziert werden
kann. Die BLOBs werden nicht automatisch auf dem RBS-Speicher gelöscht, wenn die entsprechenden
Inhalte in SharePoint gelöscht werden. Ein separater Garbage Collection-Zyklus mithilfe des integrierten
RBS-Maintainer-Tasks ist zum Löschen der verwaisten BLOBs erforderlich.
2. Auswirkungen von RBS auf die
Datenbanksicherungsgröße
Bei den Tests, deren Ergebnisse in diesem Abschnitt zusammengefasst werden, haben wir die
Auswirkungen von RBS auf die Datenbanksicherungsgröße für eine SharePoint-Inhaltsdatenbank mit
100 GB bestehend aus 100.000 Objekten und für eine SharePoint-Inhaltsdatenbank mit 1 TB bestehend
aus 2 Millionen Objekten gemessen. Der RBS-Speicher wurde bei den Tests und Analysen nicht verwendet.
Das heißt, die Techniken und die Dauer im Zusammenhang mit dem Sichern und Wiederherstellen von
BLOB-Daten, die sich auf dem RBS-Speicher befinden, gehen über den Rahmen dieses Whitepapers hinaus.
© 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 14
Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten,
wenden Sie sich an SharePoint IT DocsMicrosoft SharePoint Server 2010 April 2011
Der folgende Transact-SQL-Befehl wurde zum Sichern verwendet.
BACKUP DATABASE [WSS_Content] TO DISK = N'O:\WSS_Content' WITH NOFORMAT, INIT, NAME =
N'WSS_Content-Full Database Backup', SKIP, NOREWIND, NOUNLOAD;
Darüber hinaus wurden Tests ausgeführt, um die Auswirkungen des SQL Server-
Sicherungskomprimierungsfeatures2 zu messen und die Auswirkung auf die Größe der Sicherung mit und
ohne RBS zu bestimmen. Die Testergebnisse sind in der nachfolgenden Tabelle (vii) zusammengefasst.
Größe (GB)
Reduzierung
Ohne RBS Mit RBS
Größe der Datenbank-Datendateien (100 GB) 106.9 3.2 97.0%
Größe der SQL Server-Sicherung (100 GB) 107.0 3.3 96.9%
Größe der SQL Server-Sicherung mit Komprimierung
(100 GB) 71.5 0.7 99.1%
BLOB-Speichergröße (100 GB) 0 96.2 --
Größe der Datenbank-Datendateien (1 TB) 1120 6.5 99.4%
Größe der SQL Server-Sicherung (1 TB) 1,119.0 6.6 99.4%
Größe der SQL Server-Sicherung mit Komprimierung
(1 TB) 1,046.0 1.2 99.9%
BLOB-Speichergröße (1 TB) 0 1115 --
Tabelle (vii) – Datenbank- und Sicherungsgrößen
2
Zum Komprimieren von Datenbanksicherungen muss SQL Server Enterprise verwendet werden. Dieses
Feature ist in SQL Server Standard oder SQL Server Express nicht verfügbar.
© 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 15
Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten,
wenden Sie sich an SharePoint IT DocsMicrosoft SharePoint Server 2010 April 2011
Abbildung (vi) – Datenbank- und Sicherungsgrößen
Anhand des obigen Diagramms und der obigen Tabelle ist ersichtlich, dass bei aktiviertem RBS die Größe
der Datenbanksicherung für die Inhalte mit 100 GB um 96,9 % reduziert wurde (107 GB gegenüber
3,3 GB), während die Größe der Datenbanksicherung für die Inhalte mit 1 TB um 99,4 % reduziert wurde
(1.119 GB gegenüber 6,6 GB). Für Inhalte mit 100 GB betrug die Größe der BLOBs, die aus der Datenbank
extern gespeichert wurden, 96,2 GB, und für die Datenbank mit 1 TB betrug sie 1.115 GB.
Wenn das SQL Server-Sicherungskomprimierungsfeature für die Datenbank aktiviert war, reduzierte sich
die Größe der Sicherungen weiter auf 71,5 GB bzw. 1.046 GB ohne RBS, und auf 0,7 GB bzw. 1.2 GB mit
RBS. Beachten Sie, dass durch die Sicherungskomprimierung tatsächlich Speicherplatz reduziert werden
konnte für den Fall, dass RBS nicht verwendet wurde, da die BLOB-Daten von SharePoint Server innerhalb
der Zeile zusammen mit den anderen Daten (Metadaten) gespeichert werden. Falls festgelegt wird, dass
die BLOBs außerhalb der Zeile gespeichert werden sollen, hätte die Sicherungskomprimierung keinerlei
Effekt, da außerhalb der Zeile gespeicherte BLOBs nicht komprimiert werden. Dies ist zwar in diesem Fall
ein Vorteil, geht aber zu Lasten eines größeren Workingsets und beeinträchtigter Cacheeffizienz, wodurch
letztlich die Leistung beeinträchtigt wird.
SharePoint-BLOBs sind unveränderlich, das heißt, nach dem Erstellen werden sie nie mehr geändert.
Deshalb können die BLOB-Inhalte jederzeit nach Abschluss der SQL Server-Datenbanksicherung gesichert
werden. Dies bietet die Flexibilität, eine schnelle transaktionskonsistente Sicherung der SQL
Server-Datenbank zu einem bestimmten Zeitpunkt vorzunehmen und dann das BLOB-Speichervolume zu
einem späteren Zeitpunkt zu sichern. Die SQL Server-Sicherung und die Sicherung des
RBS-Inhaltsspeichers ergeben zusammen einen vollständigen Sicherungssatz der SharePoint-Inhalte. Nach
Abschluss der Sicherung kann mit dem Sicherungssatz die SharePoint-Datenbank in dem Status zu Beginn
der SQL Server-Sicherung wiederhergestellt werden. Hinweis: Bei der Planung einer Sicherungs- und
Wiederherstellungsstrategie, die die RBS-Datenspeicherung beinhaltet, sollten Sie die
RBS-Wiederherstellungszeit einplanen. SharePoint-Dokumente sind bis zur Wiederherstellung von RBS
nicht verfügbar.
© 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 16
Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten,
wenden Sie sich an SharePoint IT DocsMicrosoft SharePoint Server 2010 April 2011
3. Auswirkungen von RBS auf die
Sicherungs- und Wiederherstellungszeiten
Bei den Tests, deren Ergebnisse in diesem Abschnitt zusammengefasst werden, haben wir die
Auswirkungen von RBS auf den Zeitaufwand zum Sichern und Wiederherstellen einer Datenbank
gemessen. Ähnlich wie im vorherigen Abschnitt haben wir eine SharePoint-Inhaltsdatenbank mit 100 GB
bestehend aus 100.000 Objekten verwendet. Eine Reihe von Tests wurden ausgeführt, um den
erforderlichen Zeitaufwand zum Sichern und Wiederherstellen der Datenbanken mit und ohne aktivierten
RBS zu messen. Die Testergebnisse für die Datenbank mit 100 GB sind in der nachfolgenden Tabelle (viii)
zusammengefasst.
Vorgang Ohne RBS Mit RBS Reduzierung
Größe der Datenbank-Datendateien 106,9 3,2 97,0 %
Zeitaufwand zum Sichern der Datenbank 2.490 Sekunden 38 Sekunden 98,5 %
Zeitaufwand zum Wiederherstellen der Datenbank 1.290 Sekunden 28 Sekunden 97,8 %
Zeitaufwand zum Sichern der Datenbank mit 3.160 Sekunden 37 Sekunden 98,8 %
aktivierter Sicherungskomprimierung
Zeitaufwand zum Wiederherstellen von der 1.330 Sekunden 28 Sekunden 97,9 %
komprimierten Sicherung
Zeitaufwand zum Sichern des BLOB-Speichers -- 14 Sekunden --
(Momentaufnahme)
Zeitaufwand zum Wiederherstellen des -- 28 Sekunden --
BLOB-Speichers (Momentaufnahme)
Zeitaufwand zum Sichern des BLOB-Speichers -- 2.578 Sekunden --
(Kopierbefehl)
Zeitaufwand zum Wiederherstellen des -- 2.880 Sekunden --
BLOB-Speichers (Kopierbefehl)
Tabelle (viii) – Sicherungs- und Wiederherstellungszeiten für eine Datenbank mit 100 GB
© 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 17
Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten,
wenden Sie sich an SharePoint IT DocsMicrosoft SharePoint Server 2010 April 2011
Abbildung (vii) – Sicherungs- und Wiederherstellungszeiten für ein Dataset mit 100 GB
Für Datenbanksicherungen und -wiederherstellungen ist der erforderliche Zeitaufwand linear proportional
zur Größe der Datenbank. Da die Datenbank mit aktiviertem RBS deutlich kleiner war, verkürzte sich der
Zeitaufwand wie in Abbildung (vii) dargestellt entsprechend. Mit aktiviertem RBS verkürzte sich der
Zeitaufwand zum Sichern der Datenbank um 98,5 % (2.490 Sekunden gegenüber 38 Sekunden), während
sich der Zeitaufwand zum Wiederherstellen der Datenbank um 97,7 % (1.284 Sekunden gegenüber
28 Sekunden) verkürzte. Entsprechend verkürzte sich der Zeitaufwand zum Sichern der Datenbank mithilfe
der SQL Server-Sicherungskomprimierung um 98,8 %, während sich der Zeitaufwand zum
Wiederherstellen einer Datenbank mit Sicherungskomprimierung um 97,9 % verkürzte. Das Sichern der
Datenbank mit Sicherungskomprimierung dauerte 27 % länger und erforderte deutlich mehr SQL Server-
Serverressourcen, da zusätzlicher Verarbeitungsaufwand zum Komprimieren der Daten erforderlich ist. Die
Befehle zum Sichern und Wiederherstellen der Datenbanken lauteten wie folgt:
BACKUP DATABASE [WSS_Content] TO DISK = N'O:\WSS_Content' WITH NOFORMAT, INIT, NAME =
N'WSS_Content-Full Database Backup', SKIP, NOREWIND, NOUNLOAD;
BACKUP DATABASE [WSS_Content] TO DISK = N'O:\WSS_Content' WITH COMPRESSION, NOFORMAT,
INIT, NAME = N'WSS_Content-Full Database Backup', SKIP, NOREWIND, NOUNLOAD;
RESTORE DATABASE [WSS_Content] FROM DISK = N'O:\WSS_Content' WITH FILE = 1, MOVE
N'WSS_Content' TO N'J:\ContentDB_Data\WSS_Content.mdf', MOVE N'WSS_Content_log' TO
N'S:\ContentDB_Log\WSS_Content_log.LDF', NOUNLOAD, REPLACE;
Bei Verwendung von RBS muss der RBS-Speicher separat gesichert werden. Diese Sicherung kann
asynchron und parallel zur Datenbanksicherung erfolgen. Die Sicherung des RBS-Speichers muss jedoch
nach der Datenbanksicherung gestartet werden. Verschiedene Mechanismen können zum Sichern des
RBS-Speichers verwendet werden. Bei unseren Tests haben wir den Zeitaufwand zum Sichern des
Speichers mithilfe einer Datenträgermomentaufnahme sowie mithilfe eines einfachen sequenziellen
Verzeichniskopiervorgangs gemessen. Für die Inhalte mit 100 GB dauerte das Sichern des RBS-Speichers
© 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 18
Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten,
wenden Sie sich an SharePoint IT DocsMicrosoft SharePoint Server 2010 April 2011
mithilfe einer Datenträgermomentaufnahme 14 Sekunden, während es mit dem Kopierbefehl
2.578 Sekunden dauerte.
Hinweis – Bei Verwendung des FILESTREAM-Anbieters werden von SharePoint 2010 sowohl die
BLOB-Daten als auch die Metadaten automatisch gesichert oder wiederhergestellt.
Wenn Sie eine Datenbank mit aktiviertem RBS wiederherstellen, muss auch der BLOB-Speicher
wiederhergestellt werden. Die SharePoint-Farm gilt erst als vollständig wiederhergestellt und zugänglich,
nachdem der BLOB-Speicher wiederhergestellt wurde. Für die Inhalte mit 100 GB dauerte das
Wiederherstellen des RBS-Speichers mithilfe einer Datenträgermomentaufnahme 28 Sekunden, während es
mit dem Kopierbefehl 2.880 Sekunden dauerte. Es sollte erwähnt werden, dass der RBS-Speicher nur
wiederhergestellt werden muss, wenn er beschädigt wurde oder einen inkonsistenten Status aufweist.
4. Auswirkungen von RBS auf die
Indexneuerstellungsleistung
Eines der Merkmale von SharePoint Server ist die häufige und umfangreiche Fragmentierung der
SQL Server-Back-End-Datenbanktabellen, in denen die BLOB-Inhalte gespeichert werden. Diese
Fragmentierung ist in vielerlei Hinsicht beabsichtigt und auf die Architektur der SharePoint-Anwendung
sowie das Zugriffsmuster der SQL Server-Back-End-Datenbank zurückzuführen. Wenn die Datenbank
fragmentiert wird, werden logisch zusammenhängende Datenbankseiten in der Datendatei nicht physisch
zusammengehörend angezeigt. Darüber hinaus wird die Kapazität von Datenseiten oft nicht voll
ausgeschöpft, weshalb eine größere Anzahl derartiger Seiten mit geringer Dichte zum Speichern der Daten
erforderlich ist. Aufgrund dieser beiden Faktoren ist das Workingset größer als erforderlich, was eine
Leistungsbeeinträchtigung bewirken kann.
Die gute Nachricht ist, dass die Fragmentierung von SharePoint 2010 automatisch reduziert wird, indem
drei SharePoint-Integritätsanalyseregeln ausgeführt werden. Mit diesen Regeln wird regelmäßig die
Fragmentierung der Indizes überprüft und die gespeicherte Prozedur proc_DefragmentIndices ausgeführt,
um die Indizes automatisch zu defragmentieren. Es sollte jedoch berücksichtigt werden, dass dieser
Vorgang ressourcenintensiv ist und dass die gesamte SharePoint-Farm während des
Indexneuerstellungsleistungsprozesse nicht verfügbar ist. Dies sind die drei Regeln:
Von SharePoint verwendete Datenbanken weisen fragmentierte Indizes auf
Suche – Mindestens eine verwendete Durchforstungsdatenbank weist einen fragmentierten Index
auf
Suche – Mindestens eine Eigenschaftendatenbank weist einen fragmentierten Index auf
Durch die externe Speicherung der BLOBs mithilfe von RBS wird dieses Problem drastisch gemildert, da die
kleinere Datenbank weniger Zeit für die Neuerstellung der Indizes benötigt.
Um die Auswirkungen der Neuerstellung von Indizes zu messen, haben wir eine Reihe von Tests
ausgeführt, bei denen wir die Indexneuerstellung für alle Tabellen in der SharePoint-Inhaltsdatenbank
erzwangen. Dies mag zwar für eine reale Bereitstellung, bei der Indizes bei Bedarf neu erstellt werden,
nicht repräsentativ sein, aber diese Vorgehensweise wurde gewählt, um den Test deterministisch und
wiederholbar zu gestalten. Im Rahmen dieser Tests haben wir den Zeitaufwand für die Neuerstellung von
Indizes für Inhaltsdatenbanken mit 100 GB und 1 TB mit und ohne aktiviertem RBS gemessen. Darüber
hinaus haben wir die Auswirkungen eines Indexneuerstellungsvorgangs auf die Verfügbarkeit und Leistung
der SharePoint-Farm gemessen.
© 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 19
Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten,
wenden Sie sich an SharePoint IT DocsMicrosoft SharePoint Server 2010 April 2011
Ohne RBS Mit RBS Reduzierung
Zeitaufwand für Indexneuerstellung für alle 120 Sek. 4 Sek. 96,7 %
Tabellen (100 GB)
Zeitaufwand für Indexneuerstellung für alle 600 Sek. 146 Sek. 75,7 %
Tabellen (1 TB)
Tabelle (x) – Datenbankfragmentierung
Anhand der obigen Tabelle (x) ist ersichtlich, dass die Neuerstellung von Indizes für die Datenbank mit
100 GB 96,7 % schneller (120 Sekunden gegenüber 4 Sekunden) und für die die Datenbank mit 1 TB
75,7 % schneller (600 Sekunden gegenüber 146 Sekunden) ist, wenn RBS aktiviert ist. Da die SharePoint-
Webanwendung die meiste Zeit nicht verfügbar ist, wenn die Indizes neu erstellt werden, wirkt sich der
kürzere Zeitaufwand direkt auf die Verfügbarkeit der SharePoint-Anwendung aus und ermöglicht die
häufigere Ausführung des Indexneuerstellungsvorgangs und in der Folge eine einheitlichere Leistung.
Mehrere Tests wurden ausgeführt, um die Auswirkungen der Indexneuerstellung auf eine Datenbank mit
100 GB ohne aktivierten RBS zu messen. In der nachfolgenden Abbildung (viii) sind die Ergebnisse für
einen derartigen Test dargestellt, bei dem eine Dokumentupload-Arbeitsauslastung simuliert und der
Indexneuerstellungsvorgang im stabilen Zustand ausgeführt wurde.
Abbildung (viii): Auswirkungen des Indexneuerstellungsvorgangs auf die Leistung
Während des Normalbetriebs (06:28 bis 06:56 Uhr) entsprach die erwartete Dateiuploadrate im Schnitt 85
Dateien pro Sekunde. Um 06:56 Uhr wurde ein Indexneuerstellungsvorgang ausgeführt, der 120 Sekunden
dauerte. Anhand des Diagramms ist ersichtlich, dass während dieses Zeitraums die Dateiuploadrate fast
auf null abgefallen ist. Dies ist ein Hinweis darauf, dass die während dieses Zeitraums ausgeführten
Benutzervorgänge entweder bis zu 120 Sekunden lang unterbrochen werden oder dass im schlimmsten Fall
ein Timeout eintritt und dem Endbenutzer eine Fehlermeldung angezeigt.
© 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 20
Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten,
wenden Sie sich an SharePoint IT DocsMicrosoft SharePoint Server 2010 April 2011
Angesichts der Tatsache, dass der Indexneuerstellungsvorgang nur 4 Sekunden dauert, wenn RBS für die
Datenbank aktiviert ist, war das Zeitfenster so kurz, dass die Auswirkungen insgesamt nicht spürbar
waren. Die Leistungsbeeinträchtigung war so geringfügig, dass sie im Diagramm kaum dargestellt werden
konnte und deshalb nicht berücksichtigt wurde. Während dieser Test mithilfe eines Dateiuploads als
Arbeitsauslastung ausgeführt wurde, sind die Auswirkungen auf die Verfügbarkeit der SharePoint-Farm für
alle Transaktionstypen identisch.
5. Auswirkungen von RBS auf die Antwortzeiten
von SharePoint-Transaktionen
Wie in den obigen Abschnitten erläutert führt die Aktivierung des RBS-Features zu kleineren SharePoint-
Inhaltsdatenbanken, die wiederum auf dem SQL Server-Datenbankserver weniger Ressourcen zum
Ausführen der Abfragen erfordern. Die gespeicherten Ressourcen werden freigegeben, um die vorhandenen
Abfragen schneller sowie mehr Abfragen zu verarbeiten.
Bei dem Test, dessen Ergebnisse in diesem Abschnitt zusammengefasst werden, haben wir die
Auswirkungen der Aktivierung von RBS auf die Transaktionsantwortzeiten gemessen. Für diesen Test
haben wir die Arbeitsauslastung für die volle SharePoint-Transaktionsmischung verwendet, die im Abschnitt
„Testmethodik” erläutert wird. Diese Arbeitsauslastung wurde auf 6 Arbeitsauslastungsservern ausgeführt,
womit eine Benutzerauslastung von 100 Benutzern, die die SharePoint-Transaktion im Schnitt alle
15 Sekunden ausführten, simuliert wurde. Jeder Test wurde 5 Minuten lang mit voller Belastung gefahren
und dann 2 Stunden lang kontinuierlich ausgeführt. Die durchschnittlichen Antwortzeiten wurden für den
gesamten zweistündigen stabilen Leistungszustand des Tests gemessen. Diese allgemeinen Ergebnisse sind
in der nachfolgenden Tabelle (xi) dargestellt.
Metrik Ohne RBS Mit RBS Reduzierung
Maximale Benutzerauslastung 100 100 0,0 %
Anforderungen/Sekunde 84 84,3 -0,4 %
Fehler bei Anforderungen 0 0 0,0 %
Durchschnittl. Antwortzeit 28 ms 21 ms 25,0 %
Tests/s 6,4 6.42 -0,3 %
Durchschnittl. Seitenzeit 210 ms 160 ms 23,8 %
Tabelle (xi) – Testmetriken für Transaktionsantwortzeit
Die durchschnittliche Antwortzeit für alle Transaktionen war 25 % kürzer (28 Millisekunden gegenüber
21 Millisekunden), wenn RBS für die Inhaltsdatenbank aktiviert war. Dies weist darauf hin, dass bei
aktiviertem RBS die Endbenutzerantwortzeiten von SharePoint-Transaktionen für die verschiedenen
Transaktionstypen durchschnittlich 25 % schneller waren. Angesichts der Tatsache, dass Produktivität und
Zufriedenheit der SharePoint-Benutzer oft von den SharePoint-Transaktionsantwortzeiten abhängig sind,
würde eine Reduzierung von 25 % zu einer höheren Produktivität und größeren Zufriedenheit führen.
© 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 21
Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten,
wenden Sie sich an SharePoint IT DocsMicrosoft SharePoint Server 2010 April 2011
In der nachfolgenden Tabelle (xii) sind die Antwortzeiten für die 14 Endbenutzertransaktionen weiter
aufgegliedert.
Durchschnittliche
Transaktion Transaktionszeit (Sek.)
Transaktion Reduzierung
(%)
Ohne RBS Mit RBS
MySite Public 16,0 % 0,14 0,08 42,9 %
Homepage 25,0% 0,43 0,22 48,8 %
Page Workflow 1,1 % 109,00 109,00 0,0 %
Create Page 6,0 % 15,72 15,67 0,3 %
Create Publishing Site 1,0 % 13,00 12,70 2,3 %
Create Team Site 1,0 % 17,90 18,30 -2,2 %
Download Document 12,2 % 4,03 4,03 0,0 %
MySite Edit Profile 6,9 % 29,84 29,90 -0,2 %
Large Page 10,1 % 0,12 0,09 25,0 %
Search Query 14,8 % 60,00 60,10 -0,2 %
Site Manager 1,0 % 0,45 0,31 31,1 %
Upload Documents 4,9 % 30,20 30,50 -1,0 %
Tabelle (xii) – Transaktionsantwortzeiten
© 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 22
Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten,
wenden Sie sich an SharePoint IT DocsMicrosoft SharePoint Server 2010 April 2011
Abbildung (ix) – Transaktionsantwortzeiten
Wie oben dargestellt waren die durchschnittlichen Antwortzeiten für 10 der 14 Transaktionen identisch oder
kürzer, wenn RBS aktiviert war, wobei bei vier Transaktionen eine Verbesserung von fast 50 % zu
verzeichnen war. Für die vier Transaktionen mit einer Leistungsbeeinträchtigung betrug die Reduzierung
weniger als 2,2 %, was der Benutzer wahrscheinlich überhaupt nicht bemerken würde. Im Allgemeinen
kann man bei aktiviertem RBS eine Leistungsverbesserung bei großen Dateien erwarten, insbesondere für
Systeme, die von E/A-Vorgängen abhängig sind, wenn die Eingabe/Ausgabe von der SQL Server-
Datenbank weggeleitet wird. Für kleinere Dateien kann eine relative Leistungsbeeinträchtigung auftreten,
da das WFE nicht nur eine Anforderung, sondern zwei Anforderungen über die Leitung ausstellen muss. Es
wird jedoch erwartet, dass der relative Anstieg selbst bei einer hohen prozentualen Differenz nicht
bemerkbar ist, da die Dateizugriffszeiten generell vernachlässigbar sind.
6. Auswirkungen von RBS auf die
Durchforstungsleistung
Die Suche ist ein fester Bestandteil der meisten SharePoint-Bereitstellungen und einer der
ressourcenintensiveren SharePoint-Dienste. Viele Unternehmensbereitstellungen weisen einen hohen
Prozentsatz von Benutzern auf, die für den Datenzugriff im Suchportal navigieren, anstatt direkt auf die
Website oder das Dokument zuzugreifen. Dieses Verhalten bedeutet eine intensive Verwendung der Suche
und es überrascht nicht, dass viele Kunden behaupten, dass die Suche zu ihrer wichtigsten Ressource
geworden ist oder dass die Suche oft einen Engpass darstellt.
© 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 23
Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten,
wenden Sie sich an SharePoint IT DocsMicrosoft SharePoint Server 2010 April 2011
Die SharePoint Server-Suche besteht aus zwei Komponenten, nämlich der Suchdurchforstung und der
Suchabfrage. Beim Suchdurchforstungsprozess wird der Suchkorpus von Crawlern durchforstet und der
Suchindex erstellt (oder aktualisiert). Der SharePoint-Suchindex besteht aus zwei Komponenten, nämlich
einer Suchdatenbank und einer Suchindex-Flatfile. Die Suchabfragen wiederum geben mithilfe der
Suchdatenbank und des Suchindexes Ergebnisse für Suchabfragen von Benutzern zurück.
Bei den Tests, deren Ergebnisse in diesem Abschnitt zusammengefasst werden, haben wir den Zeitaufwand
für das Durchforsten des Suchkorpus mithilfe eines einzelnen Anwendungsservers unter Verwendung der
vorkonfigurierten Sucheinstellungen gemessen. Die Ergebnisse für den Zeitaufwand mit und ohne RBS sind
in der nachfolgenden Tabelle (xiii) zusammengefasst. Eine Zusammenfassung der Suchabfrageergebnisse
finden Sie im vorherigen Abschnitt. Sie werden deshalb an dieser Stelle nicht wiederholt.
Vorgang Anzahl von Ohne RBS Mit RBS Reduzieru
Objekten ng
Suche mit 503.206 150 Minuten 146 Minuten 2,7 %
vollständiger
Durchforstung
Tabelle (xiii) – Durchforstungszeiten für die Suche
Abbildung (x) – Zusammenfassung der Suche mit vollständiger Durchforstung
Anhand der obigen Ergebnisse ist ersichtlich, dass die Aktivierung von RBS für die Suchkorpusdatenbanken
eine absolut vernachlässigbare Auswirkung auf die Leistung hat und die Leistung nur um 2,7 % steigert.
Dies entspricht unseren Erwartungen, da der Verarbeitungsaufwand in beiden Fällen in etwa identisch ist.
7. Auswirkungen von RBS auf die Leistung beim
Hochladen von Dateien
Der Zeitaufwand für das Hochladen großer Dateien nach SharePoint Server ist für Benutzer, die
umfangreiche Inhalte hochladen, oft ein Hindernis. Die häufigste Beschwerde lautet, dass das Kopieren
einer Datei in eine Windows-Dateifreigabe oft wesentlich schneller ist, als das Hochladen derselben Datei
nach SharePoint Server. Einer der Gründe hierfür ist darin zu suchen, dass standardmäßig alle Dateiinhalte
in der SQL Server-Datenbank gespeichert werden, womit ein Mehraufwand verbunden ist. Da die
© 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 24
Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten,
wenden Sie sich an SharePoint IT DocsSie können auch lesen
