SharePoint Adventskalender - 19. Türchen
Performance Tuning - Performance Monitoring - Best-Practices für SP-SQL-Konfigurationen - BLOB Management - Backup & Recovery
-------------------------------------------------------------
Heute und in den nächsten Kalendertürchen widmen wir uns dem BLOB Management für optimierte Speicherlaufwerke und der daraus resultierenden Verbesserung unserer SharePoint Performance.
Im gestrigen Kalendertürchen sprachen wir noch vom BLOB Caching, um in bestimmten Szenarien die Performance für eine bessere Nutzererfahrung zu steigern. Leider optimiert dies in keinster Weise die Speicherlaufwerke, denn die BLOBs liegen witerhin wie bisher als „Image“ mit einem Dateilimit von 2 GB in den Datentabellen des SQL. Der SQL Server-Storage ist aber sehr ressourcenhungrig und damit teuer. Die Reduzierung der Datenbankgröße durch Auslagerung von Daten und die damit einhergehende Performance-Verbesserung waren daher Ziele bei der Einführung von EBS und RBS. (Die Performance-Verbesserung durch Auslagerung ist auf die Limitationen der Datenbankalgorithmen für große Dateien zurückzuführen, wie gestern bereits erwähnt.)
Der für SharePoint 2007 eingeführte External BLOB Storage (EBS) konnte auf Farmebene angewendet werden. Anhand konfigurierbarer Regeln konnten so große Dateien aus der SQL Datenbank auf einen günstigeren Storage ausgelagert werden. Dafür verwendetet man nun nicht mehr das Image, sondern das VARBINARY Format. Ein Größenlimit gibt es damit theoretisch zwar nicht mehr, aber aus Performance-Gründen behielt Microsoft weiterhin die 2 GB-Limits für SharePoint Datenbanken bei. Mit SharePoint 2016 ist dieses Limit nun endlich auf (aktueller Stand) 10 GB pro Datei angehoben worden.
Da schnell die Grenzen des EBS deutlich wurden, kündigte Microsoft dieses Feature in SharePoint 2010 wieder ab und führte den Remote BLOB Storage (RBS) ein. Dieser kann pro Datenbank angewendet werden und ist somit deutlich flexibler einsetzbar für SharePoint Farm Administartoren.
Ziele und Funktionsweise des RBS
Hauptziel des RBS ist die Auslagerung von entweder großen Dateimengen oder bestimmten Daten anhand definierter Regeln. Hinsichtlich SharePoint-Limitationen werden diese Daten zwar weiterhin zu einer Datenbank hinzugezählt, sie befinden sich jedoch auf einem anderen Storage. Dadurch kann SQL deutlich schneller und effizienter arbeiten, weil keine Table-Queries mehr mit großen BLOBs, sondern nur noch mit kleinen Stubs(Referenz auf den tatsächlichen Speicherort), durchgeführt werden müssen. Außerdem können so auch die erweiterten Datenbankgrenzwerte angewendet werden. Microsoft unterstützt z.B. in SharePoint 2013 Inhaltsdatenbanken mit bis zu 4 TB und einem Disk Subsystem von mindestens 0,25 I/Ops pro GB. Da durch die Auslagerung beispielsweise keine 4 TB, sondern effektiv nur 150 GB in der Datenbank liegen, kann man so auch mit günstigen Laufwerken die erforderten 0,25 I/Ops pro GB erreichen (empfohlen sind 2 I/Ops pro GB - https://technet.microsoft.com/de-de/library/cc262787.aspx).
Beispielrechnung:
Effektive Daten in der Datenbank | Erforderliche I/Ops für das Disk Subsystem |
4 TB (à 0,25 I/Ops * 1024 * 4) | 1024 |
150 GB (à 0,25 I/Ops * 150) | 37,5 |
Sollten Sie also dieses Szenario verfolgen und mit RBS die 200 GB „virtuell“ überschreiten, bedenken Sie Situationen, in denen die BLOBs wieder zurück in den Datenbanken müssen, z.B. bei Migrationen. Auch dafür gibt es zwar Lösungen, z.B. Migrationssoftware von Drittanbietern wie AvePoint. Ich möchte an dieser Stelle aber lediglich darauf hinweisen, dass im RBS-Fall bestimmte Dinge zu berücksichtigen sind.
Die Auslagerung von Daten als Hauptziel ermöglicht zudem weitere Nebenziele:
Performance:
Die Downloadzeiten, also die Dauer bis ein Dokument oder allgemein ein BLOB gerendert ist, wird deutlich reduziert aufgrund der gestern erwähnten Limitation.
Der RBS-Provider kann also deutlich mehr Daten direkt vom Storage in der gleichen Zeit lesen, als es SQL allein aus seinen Datenbanken kann. Diese Unterscheide sind natürlich abhängig von dem Speicher-Subsystem des SQL sowie vom RBS Storage und der Netzwerkgeschwindigkeit (sollte diese eine andere und langsamere als zum SQL sein). Um das BLOB vom Storage zu lesen und zu rendern, muss der Browser für gewöhnlich folgende Schritte unternehmen:
- DNS Lookup
- Initiale Verbindung
- Warten
- Daten erhalten
- Verbindung schließen
Das Warten auf Daten wird als sogenannte TTFB (Time To First Byte – Zeit bis zum ersten Byte) bezeichnet. 100-200 ms sind grundsätzlich gute Werte. Möchten Sie jedoch einen NAS als RBS-Storage nutzen, erfordert Microsoft eine TTFB von unter 20 ms (https://technet.microsoft.com/de-de/library/Ff628583.aspx).
Deduplication:
Auf dem RBS-File-System kann die Deduplication (ein Windows Service) genutzt werden. Ist also ein Dokument doppelt und dreifach in mehreren Bibliotheken abgelegt, so erkennt dies der Deduplication-Algorithmus und komprimiert alle Duplikate in ein einziges und verweist dies in einem Index – einfach ausgedrückt.
In Tests hat sich herausgestellt, dass die beste Performance grundsätzlich mit einem RBS-Grenzwert von 1024 KB erreicht wird. Bei kleineren Dateien ist der SQL Algorithmus schneller. Der Wert kann aber auch minimal abweichen, je nach dem, für welches Szenario Ihre Farm eingesetzt wird und somit welche Dateigrößen hauptsächlich gespeichert sind. Dazu aber morgen mehr in Form von Informationen und Mythen zum Shredded Storage.
Hinweis: Auslagerung kann nicht von SharePoint erfolgen. Stattdessen müssen entsprechende RBS Provider installiert werden. Der Microsoft-eigene Provider, genannt FILESTREAM, erfüllt das Grundgerüst, also das Auslagern von Dateien anhand einer kofigurierten Größe x. Leider kann der FILESTREAM auch nur lokale Laufwerke des SQLs als Auslagerungs-Storage verwenden. Wenn Sie Daten auch auf andere Storages, wie z.B. einen SAN oder Cloud-Speicher, bringen oder weitere Auslagerungsregeln, z.B. per Dokumentenversionen oder bestimmte Spaltenwerte, verwenden möchten, dann kann dies nur eine Drittanbieterlösungen ermöglichen. Exemplarisch möchte ich auch hier AvePoint mit dem "Storage Manager" nennen.
Viel Spaß beim „SharePointen“
-------------------------------------------------------------
Weitere Türchen:
- 1. Türchen: SharePoint Performance Tuning - Cluster Größe der SQL Festplatten
- 2. Türchen: SharePoint Performance Tuning - SQL Speicherzuweisung
- 3. Türchen: SharePoint Performance Tuning - SQL MAXDOP
- 4. Türchen: SharePoint Performance Tuning - SQL AutoGrowth-Einstellungen
- 5. Türchen: SharePoint Performance Tuning - SQL Datenbanken vor konfigurieren
- 6. Türchen: SharePoint Performance Tuning - SQL TempDB Einstellungen
- 7. Türchen: SharePoint Performance Tuning - Der Papierkorb
- 8. Türchen: SharePoint Performance Tuning - Warm Up Skripte
- 9. Türchen: SharePoint Performance Monitoring - Performance Counter für den Prozessor
- 10. Türchen: SharePoint Performance Monitoring - Performance Counter für Speicherlaufwerke
- 11. Türchen: SharePoint Performance Monitoring - Performance Counter für den Arbeitsspeicher
- 12. Türchen: SharePoint Performance Monitoring - Performance Counter für System und Netzwerk
- 13. Türchen: SharePoint Configuration Best Practices - SQL Alias
- 14. Türchen: SharePoint Configuration Best Practices - Benamte SQL Instanzen und dedizierte Ports
- 15. Türchen: SharePoint Configuration Best Practices - Super User und Super Reader
- 16. Türchen: SharePoint Configuration Best Practices - Distributed Cache Service
- 17. Türchen: SharePoint Configuration Best Practices - Request Management Service
- 18. Türchen: SharePoint BLOB Management - BLOB Cache
- 19. Türchen: SharePoint Configuration Best Practices - BLOB Storage (EBS und RBS)
Clik here to view.