Informationen zu StorSimple
Werbung
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. Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten, wenden Sie sich an SharePoint IT Docs Seite 2 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. Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten, wenden Sie sich an SharePoint IT Docs Seite 3 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 Reihe von DLLs, mit denen Methoden für die RBS-APIs implementiert werden und das eigentliche externe Speichern der BLOBs ausgeführt wird. © 2011 Microsoft Corporation. Alle Rechte vorbehalten. Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten, wenden Sie sich an SharePoint IT Docs Seite 4 Microsoft SharePoint Server 2010 April 2011 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 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 2010Kapazitätsverwaltung: Softwarebeschränkungen und –grenzen” (http://technet.microsoft.com/en© 2011 Microsoft Corporation. Alle Rechte vorbehalten. Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten, wenden Sie sich an SharePoint IT Docs Seite 5 Microsoft SharePoint Server 2010 April 2011 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 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. © 2011 Microsoft Corporation. Alle Rechte vorbehalten. Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten, wenden Sie sich an SharePoint IT Docs Seite 6 Microsoft SharePoint Server 2010 April 2011 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. Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten, wenden Sie sich an SharePoint IT Docs Seite 7 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 SharePointTransaktionskonstellation 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 2007Leistungstoolkits generiert. Für die einzelnen Tests wurden die folgenden Transaktionen verwendet. Name des Tests Beschreibung Prozentsatz Page Workflow Durchlaufen eines Seitenworkflows: Auschecken, Genehmigen und Einchecken 1% 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% Create Team Site Erstellen einer neuen Websitesammlung mithilfe der Teamwebsitevorlage im Verzeichnis sites 1% 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% Search Query Ausführen einer Suchabfrage und Anzeigen der Ergebnisse auf der Suchcenterseite 15% © 2011 Microsoft Corporation. Alle Rechte vorbehalten. Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten, wenden Sie sich an SharePoint IT Docs Seite 8 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 SharePointTransaktionsmischung generiert. © 2011 Microsoft Corporation. Alle Rechte vorbehalten. Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten, wenden Sie sich an SharePoint IT Docs Seite 9 Microsoft 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 tempdb H:\ Datendatei der Inhaltsdatenbank P:\ Protokolldatei der Inhaltsdatenbank Q:\ 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 Docs Microsoft SharePoint Server 2010 April 2011 Software Zusätzliche Änderungen Computerrolle WFEs und Anwendungsserver Windows Server® 2008 R2 Enterprise x64 Die neuesten Windows ServerPatches wurden angewendet. Microsoft SharePoint Server 2010 RBS.msi wurde über das SQL Server 2008 R2 Feature Pack installiert. Datenbankserver Windows Server 2008 R2 Enterprise x64 SQL Server 2008 R2 Enterprise x64 Die neuesten Windows ServerPatches wurden angewendet. Die folgenden Änderungen wurden 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 Docs Microsoft SharePoint Server 2010 April 2011 1. Auswirkungen von RBS auf die SQL ServerDatenbankgröß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 DatenbankTransaktionsprotokolldateien (100 GB) 111.6 3.8 96.6% -- 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 DatenbankTransaktionsprotokolldateien (1 TB) 1,173 20 98.3% -- 1,115 -- Größe der extern gespeicherten RBS-Daten Größe der extern gespeicherten RBS-Daten 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 Docs Microsoft 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 Datenund 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 ServerTransaktionsprotokolldatei 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 Docs Microsoft 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 Docs Microsoft 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, N'WSS_Content-Full Database Backup', SKIP, NOREWIND, NOUNLOAD; NAME = Darüber hinaus wurden Tests ausgeführt, um die Auswirkungen des SQL ServerSicherungskomprimierungsfeatures2 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% 71.5 0.7 99.1% 0 96.2 -- 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% 0 1115 -- Größe der SQL Server-Sicherung mit Komprimierung (100 GB) BLOB-Speichergröße (100 GB) Größe der Datenbank-Datendateien (1 TB) BLOB-Speichergröße (1 TB) 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 Docs Microsoft 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 Docs Microsoft 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 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 aktivierter Sicherungskomprimierung 3.160 Sekunden 37 Sekunden 98,8 % Zeitaufwand zum Wiederherstellen von der komprimierten Sicherung 1.330 Sekunden 28 Sekunden 97,9 % Zeitaufwand zum Sichern des BLOB-Speichers (Momentaufnahme) -- 14 Sekunden -- Zeitaufwand zum Wiederherstellen des BLOB-Speichers (Momentaufnahme) -- 28 Sekunden -- Zeitaufwand zum Sichern des BLOB-Speichers (Kopierbefehl) -- 2.578 Sekunden -- Zeitaufwand zum Wiederherstellen des BLOB-Speichers (Kopierbefehl) -- 2.880 Sekunden -- Größe der Datenbank-Datendateien 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 Docs Microsoft 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 ServerServerressourcen, 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, N'WSS_Content-Full Database Backup', SKIP, NOREWIND, NOUNLOAD; NAME = 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 Docs Microsoft 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 Docs Microsoft SharePoint Server 2010 April 2011 Ohne RBS Mit RBS Reduzierung Zeitaufwand für Indexneuerstellung für alle Tabellen (100 GB) 120 Sek. 4 Sek. 96,7 % Zeitaufwand für Indexneuerstellung für alle Tabellen (1 TB) 600 Sek. 146 Sek. 75,7 % 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 SharePointWebanwendung 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 Docs Microsoft 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 SharePointInhaltsdatenbanken, 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 Durchschnittl. Antwortzeit 28 ms 21 ms 25,0 % Tests/s 6,4 6.42 -0,3 % Durchschnittl. Seitenzeit 210 ms 160 ms 23,8 % 0,0 % 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 Docs Microsoft SharePoint Server 2010 April 2011 In der nachfolgenden Tabelle (xii) sind die Antwortzeiten für die 14 Endbenutzertransaktionen weiter aufgegliedert. Transaktion Transaktion (%) Durchschnittliche Transaktionszeit (Sek.) Ohne RBS Reduzierung Mit RBS 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 % 12,2 % 4,03 4,03 0,0 % 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 % MySite Public Download Document MySite Edit Profile 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 Docs Microsoft 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 ServerDatenbank 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 Docs Microsoft 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 Suche mit vollständiger Durchforstung Anzahl von Objekten Ohne RBS Mit RBS Reduzieru ng 503.206 150 Minuten 146 Minuten 2,7 % 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 Docs Microsoft SharePoint Server 2010 April 2011 SQL Server-Datenbank ein transaktionskonsistentes Modell verwendet, muss zusätzlich zum Speichern der eigentlichen Kopie in der Datenbank der gesamte BLOB im SQL Server-Transaktionsprotokoll protokolliert werden. Dies bedeutet die doppelte E/A-Auslastung im System. Mit RBS wird die Leistung von Dateiuploads für umfangreiche Dateien erheblich verbessert, da der BLOB direkt vom WFE aus extern gespeichert wird und deshalb die E/A-Auslastung für das SQL Server-System minimiert wird. Bei den Tests, deren Ergebnisse in diesem Abschnitt zusammengefasst werden, haben wir eine SharePoint-Bereitstellung für die Verwaltung digitaler Objekte modelliert und die Leistung für das Hochladen großer Dateien (zwischen 1 MB und 1,99 GB) mit und ohne aktiviertem RBS gemessen. Die Ergebnisse für den Zeitaufwand zum Hochladen der Dateien mit und ohne RBS sind in der nachfolgenden Tabelle (xiv) zusammengefasst. Dateigröße Zeitaufwand zum Hochladen der Datei (Sekunden) Reduzierung Ohne RBS Mit RBS 1 MB 1,2 1,0 16,7 % 100 MB 12,2 9,7 20,5 % 500 MB 55 28,8 47,6 % 1 GB 69,4 48 30,8 % 1,5 GB 138 71 48,6 % 1,99 GB 178 87 51,1 % Tabelle (xiv) – Zeitaufwand für das Hochladen von Dateien Abbildung (xi) – Zeitaufwand für das Hochladen von Dateien © 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 25 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 Anhand der Tabelle und des Diagramms ist ersichtlich, dass eine Datei mit aktiviertem RBS 15 % bis 50 % schneller hochgeladen wird, als dies bei deaktiviertem RBS der Fall ist. Dies bedeutet in absoluten Zahlen, dass das Hochladen einer Datei mit einer Größe von 1,99 GB 87 Sekunden anstelle von 178 Sekunden benötigt. Für Benutzer eines Datenarchivs, die Dateien hochladen, macht das einen großen Unterschied. Denn ihr Webbrowser ist oft blockiert und sie müssen deshalb warten, bis ein Vorgang abgeschlossen ist, bevor sie die Aktivität fortsetzen können. Bei Hunderten von Benutzern in einer Organisation, die jeweils viele derartige Vorgänge ausführen, summieren sich die Zeiteinsparungen und Vorteile schnell und sind besonders spürbar, wenn auf dem Server ein Ressourcenengpass besteht. Ähnliche Vorteile gelten auch für Dateidownloadvorgänge. Allerdings wird bei Dateidownloads die Datendatei vom SQL Server-System und dem SharePoint-WFE gepuffert, wodurch im Back-End-Speicher weniger Ressourcen verbraucht werden. 8. Zeitaufwand zum Migrieren von Daten Wenn RBS für eine Datenbank aktiviert ist, werden alle hochgeladenen oder geänderten Dateien automatisch in dem RBS-BLOB-Speicher extern gespeichert, der dem aktiven Anbieter zugeordnet ist. Objekte, die zuvor in der Datenbank gespeichert wurden, werden weiterhin dort gespeichert und sind über die Datenbank zugänglich. Sie werden nicht automatisch zum RBS-Speicher migriert. Bei dieser Konfiguration ermöglicht SharePoint den problemlosen Zugriff sowohl auf die Dateien, die über RBS extern gespeichert wurden, als auch auf die noch in der Datenbank gespeicherten Dateien. Der obige Mechanismus funktioniert zwar problemlos, aber im Laufe der Zeit möchten die Benutzer möglicherweise alle in der Datenbank gespeicherten vorhandenen Inhalte zum externen RBS-Speicher migrieren. Oder möglicherweise möchten sie alle extern gespeicherten RBS-Inhalte zurück zur Datenbank migrieren. Beide Vorgänge können mit dem Migrate()-Cmdlet von Windows PowerShell™ 2.0 ausgeführt werden, das im Lieferumfang von SharePoint Server 2010 enthalten ist. Die genaue Abfolge der auszuführenden Windows PowerShell-Befehle ist im nachfolgenden Skript enthalten. $cdb=Get-SPContentDatabase <ContentDbName> $rbss=$cdb.RemoteBlobStorageSettings $rbss.GetProviderNames() $rbss.SetActiveProviderName($rbss.GetProviderNames()[0])3 $rbss.Migrate() Diese Schritte müssen für jede Datenbank ausgeführt werden, für die Sie die BLOBs migrieren möchten. Wenn das Windows PowerShell-Skript bei aktiviertem RBS-Anbieter ausgeführt wird, werden die BLOBs aus der Datenbank und zum RBS-Speicher migriert. Wenn dagegen das Windows PowerShell-Skript bei deaktiviertem RBS-Anbieter ausgeführt wird, werden die BLOBs zurück zur Datenbank migriert. Angesichts der Tatsache, dass eine Inhaltsdatenbank Tausende oder sogar Millionen von gespeicherten Objekten enthalten kann, sollten Sie sich das Migrieren der Daten sorgfältig überlegen, da dieser Vorgang 3 Hinweis: $rbss.GetProviderNames()[0] entspricht dem StorSimple-RBS-Anbieter. © 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 26 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 sehr lange dauern könnte. Es wird empfohlen, das Migrate()-Cmdlet außerhalb der Spitzenauslastungszeiten und auf einem SharePoint-WFE oder Anwendungsserver mit geringfügiger Auslastung auszuführen. Bei unseren Tests führten wir das obige Skript auf dem Anwendungsserver aus, um 500.000 SharePointObjekte mit einer durchschnittlichen Größe von 100 KB zur und aus der Datenbank zu migrieren. Die Testergebnisse sind in der nachfolgenden Tabelle (xv) zusammengefasst. Vorgang Zeitaufwand (Minuten) Migrierte BLOBs pro Sekunde Daten aus der Inhaltsdatenbank zum BLOB-Speicher migrieren (Daten extern speichern) 243 34.3 Daten aus dem BLOB-Speicher zur Inhaltsdatenbank migrieren (Daten intern speichern) 504 16.5 Tabelle (xv) – RBS-BLOB-Migrationszeiten Der zusätzliche Zeitaufwand für das Migrieren der Daten zur Inhaltsdatenbank war auf zusätzliche SharePoint Server- und SQL Server-Verarbeitungsschritte zurückzuführen, die auf dem Back-End ausgeführt werden mussten. Um die Vergleichbarkeit der Ergebnisse sowie die Einhaltung der Supportanforderungen von Microsoft sicherzustellen, wurden an der SQL Server-Datenbank außer den im Abschnitt “Softwarekonfiguration” beschriebenen Optimierungen keine zusätzlichen Optimierungen vorgenommen. Die Migrate-Methode von RBS kann erneut gestartet werden, und es werden dann BLOBs zur oder aus der Datenbank ausgehend von dem Punkt migriert, an dem der Vorgang beim letzten Aufruf der Methode beendet wurde. Schlussbemerkung In diesem Whitepaper haben Sie erfahren, wie Sie durch die Verwendung von RBS die effektive Größe der SharePoint-Inhaltsdatenbank und die Sicherungsgröße um über 95 % reduziert werden können, wodurch wiederum die Sicherungszeit um einen entsprechenden Betrag reduziert wird sowie die Möglichkeit besteht, billigere Speichermedien zum Speichern der BLOB-Daten zu verwenden. Darüber hinaus haben wir gesehen, wie Benutzer mithilfe des RBS-Features große Mediendateien in SharePoint Server speichern und alle Vorteile von SharePoint Server nutzen können, ohne dass ein Engpass für die SQL Server-Datenbank entsteht oder die Lösung unbezahlbar wird. Wir haben außerdem die Auswirkungen von RBS auf die Durchforstungszeiten für die Suche, auf die Leistung des Wartungstasks für die Indexneuerstellung (Reduzierung um 96 %) sowie auf die Transaktionsantwortzeiten für die Endbenutzer (Reduzierung um mindestens 30 % bei bestimmten Transaktionen) analysiert. Zuletzt haben wir die Leistung beim Hochladen von Dateien für einzelne große Mediendateien sowie den Zeitaufwand zum Migrieren von Daten zur und aus der Datenbank mithilfe von RBS gemessen. Insgesamt stellten wir fest, dass die Verwendung von RBS die Wartbarkeit einer SharePoint-Farm unterstützt sowie die Skalierbarkeit der Lösung optimiert. Dies führt wiederum zu Kosteneinsparungen und © 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 27 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 einer positiveren Endbenutzererfahrung. Bei Verwendung von RBS sollten Wartungsvorgänge wie das Sichern des BLOB-Speichers sorgfältig geplant und die Liste der Wartungsaufgaben einbezogen werden. Weitere Ressourcen Übersicht über Remote-BLOB-Speicher – http://technet.microsoft.com/de-de/library/ee748649.aspx Migrieren von Inhalten zum oder vom Remote-BLOB-Speicher – http://technet.microsoft.com/dede/library/ff628254.aspx StorSimple SharePoint Database Optimizer – http://www.storsimple.com/ Microsoft Office SharePoint Server 2007-Leistungsauslastungstests – http://sptdatapop.codeplex.com/releases/view/1214#DownloadId=6918 Microsoft® SQL Server® 2008 R2 Feature Pack – http://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=ceb4346f-657f-4d28-83f5aae0c5c83d52 Informationen zu StorSimple Die Lösung von StorSimple behebt wichtige speicherbezogene Probleme im Zusammenhang mit der Leistung, der Skalierbarkeit, der Verwaltbarkeit, dem Datenschutz und den Kosten für Microsoft SharePoint Server 2010. Mit StorSimple können Sie lokalen Speicher der nächsten Generation bereitstellen, um die heutigen anwendungsbezogenen Herausforderungen zu meistern und ggf. öffentlichen oder privaten Cloudspeicher zu nutzen. Weitere Informationen zu StorSimple finden Sie unter www.storsimple.com. Informationen zu Microsoft Die Microsoft Corporation ist ein multinationaler Konzern mit Firmensitz in Redmond, Washington (USA), der über die verschiedenen Produktbereiche eine umfangreiche Palette an Produkten und Services vorzugsweise für die IT-Branche entwickelt, herstellt, lizenziert und unterstützt. © 2011 Microsoft Corporation. Alle Rechte vorbehalten. Seite 28 Wenn Sie dieses Dokument kommentieren oder weitere Dokumentation zu diesen Features anfordern möchten, wenden Sie sich an SharePoint IT Docs
