Seit Microsoft den Shredded Storage für SharePoint 2013 herausgegeben hat, kursieren bei IT-Administratoren verschiedene Mythen und Gerüchte über Best Practices und die kombinierte Anwendung mit dem Remote BLOB Storage (RBS). So kommt es mitunter vor, dass RBS als Synonym für Shredded Storage verwendet wird. Man hört auch immer wieder, dass aufgrund der kleinen Datei-Chunks, der RBS-Grenzwert nie berührt wird, oder aber, dass Shredded Storage den RBS gar obsolet machen soll.
In diesem blog post soll mit einigen dieser Mythen aufgeräumt und Best Practice Empfehlungen gegeben werden, wie der Shredded Storage, auch in Kombination mit RBS , im Idealfall konfiguriert werden soll.
Wie der Name schon sagt, soll der RBS die Binary Large Objects (BLOB) aus dem SQL Server auslagern. Solche BLOBs lagen bisher als Image mit einem Dateilimit von 2GB in den Datentabellen des SQL. Seit Einführung des External BLOB Storage (EBS) und später des RBS, werden diese großen Daten im varbinary Format abgelegt. Ein Größenlimit wäre daher zwar nicht mehr nötig, aber aus Performance-Gründen behält Microsoft weiterhin das 2GB Limit für SharePoint Datenbanken bei.
Die Reduzierung der Datenbankgröße durch Auslagerung von Daten und die damit einhergehende Performance-Verbesserung waren Ziele des RBS. Nicht zuletzt, da der SQL Storage sehr teuer und ressourcen-hungrig ist. Die Idee dahinter war daher, große Dateien auf günstigere SANs, NAS‘ oder andere Datenträger auszulagern. Bis zur Einführung des Shredded Storage war das auch ein sehr guter Ansatz. Ein Grenzwert von 1MB galt dabei als Best Practice, um Dateien, die größer als dieser Grenzwert waren, aus dem SQL auszulagern.
Bei der Entwicklung des Shredded Storage hatte Microsoft sich hingegen folgende vier Ziele gesetzt:
1. Bandbreitenoptimierung
- nur noch Teile einer gesamten Datei müssen gesendet werden
- dies ermöglicht bzw. verbessert auch das Co-Authoring bei Office-Dokumenten
2. I/Ops-Optimierung
- durch kleinere Datenpakete werden die I/O Muster geglättet
- es wird realisiert, dass Schreib-„Kosten“ proportional zur Größe der Änderungen sind
- es werden weniger Änderungen an den SQL gesendet, was die Transaction Logs verkleinert und damit die Backup-Performance erhöht
3. Storage-Reduzierung
- es werden nur noch Änderungen gespeichert, nicht erneut die gesamte Datei Sicherheit
- jedes Datei-Chunk wird einzeln verschlüsselt
- es ist nun schwieriger eine gesamte Datei mit einem PowerShell-Befehl auszulesen
Was ist also nun der Shredded Storage? Einfach gesprochen ist es die Aufteilung einer Datei in viele kleine Teile – sogenannte Chunks. Die „FileWriteChunkSize“ ist dabei der Wert, wie groß die Fragmente beim Schreiben in den SQL sein dürfen. Jedoch entsprechen nicht alle Teile der Größe dieses Wertes, denn z.B. der Header und Footer der Datei können eine andere Größe haben. Diese Architektur lässt somit auch erahnen, dass eine Datei im Shredded Storage Konzept zunächst etwas größer ist, als im alten Format, da mehr Informationen gespeichert werden müssen um die einzelnen Chunks am Ende wieder zusammen setzen zu können. Sobald jedoch erste Änderungen einer Datei mit Versionierung gespeichert werden, wird dieser anfängliche Mehrbedarf an Speicher wieder egalisiert.
Je nach Umgebung, Art der Daten, Hardware Ressourcen etc. wird eine FileWriteChunkSize von 1-4MB empfohlen. Zum Beispiel werden beim Microsoft Cloud-Storage OneDrive 2MB verwendet.
Zusätzlich zu der FileWriteChunkSize kann auch noch die FileReadChunkSize definiert werden. Je nach Umgebung kann man so zusätzlich definieren, in welchen Datenpaketen vom Shredded Storage gelesen werden soll. Dies ist natürlich sehr stark abhängig von den Lesetätigkeiten in einer Farm und sollte dementsprechend abgestimmt werden, um tatsächliche Performance-Steigerungen zu erhalten. Als Faustformel für die FileReadChunkSize können folgende Werte angenommen werden:
- x > 12.5% der durchschnittlichen Dateigröße = mehr Schreiboperationen
- 6% < x < 12.5% = 10% auf Leseoperationen
- 3% < x < 6% = 20% auf Leseoperationen
- x < 3% = 50% auf Leseoperationen
Was macht nun der RBS in diesem Framework? Hauptziel des RBS ist die Auslagerung von entweder großen Dateimengen oder aber die Auslagerung von 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 Stub-Referenzen (Referenz auf den tatsächlichen Speicherort), durchgeführt werden müssen.
Was ist nun das Best Practice von RBS in Verbindung mit Shredded Storage? Dazu muss man sich zunächst die Frage stellen, ob beide Systeme parallel überhaupt benötigt werden. Folgende Fragen können dazu eine Antwort liefern:
Shredded Storage? – Antworten Sie mit JA:
- Gibt es viele (konkurrierende) Transaktionen?
- Wird Versionierung genutzt?
- Gibt es viele Microsoft Office Dokumente?
- Wird das Co-Authoring genutzt?
- Gibt es I/Ops und/oder Netzwerk Probleme?
RBS? – Antworten Sie mit JA:
- Gibt es viele sehr große Dateien (4+ MB)?
- Werden solche großen Dateien versioniert?
- Gibt es SQL Storage Probleme?
- Müssen Content-DB Backups schneller durchgeführt werden?
- Gibt es gleiche Dateien in mehreren Bibliotheken (und Deduplication soll genutzt werden)?
Je nachdem, welche Antworten Sie getroffen haben, und wie wichtig diese Themen in Ihrem Unternehmen sind, sollten Sie sich entweder für ShreddedStorage, RBS oder sogar für eine Kombination beider Lösungen entscheiden. Wenn letzteres der Fall ist, muss der Grenzwert zur Dateigröße natürlich entsprechend der FileWriteChunkSize angepasst werden, damit ein jeweiliger RBS-Job ausgelöst werden kann. Außerdem ist es empfehlenswert das Framework hinsichtlich Performance zu testen.
Wie eingangs erwähnt, bringt der RBS eine Performance-Steigerung für die Auslagerung von Dateien, die größer als 1MB sind. In Kombination mit dem Shredded Storage kann dies aber auch erst bei 2, 3 oder vier MB der Fall sein. Ist jedoch der Speichervorteil in Verbindung mit Deduplication ein viel wichtigerer Punkt, kann die Performance vernachlässigt werden. Die FileWriteChunkSize kann dann beispielsweise auf 1,1 MB konfiguriert und der RBS Grenzwert auf 1 MB gesetzt werden. Es können aber auch eigene Regeln definiert werden, die nicht die Dateigröße als Variable betrachten.
Welche Werte Sie letztendlich in der angegebenen Best Practice Spanne wählen, und für welche der zwei Systeme Sie sich entscheiden, oder ob Sie eine Kombination aus beiden wählen, ist speziell von Ihrer Umgebung und den Geschäftszielen abhängig. Microsoft, aber auch Partner mit einer RBS-Lösung im Portfolio, können Sie dazu dediziert beraten.
So bietet beispielsweise die Firma AvePoint mit ihrer RBS-Lösung „Storage Manager“ verschiedene Module und Funktionalitäten an, um Daten aus dem SQL auszulagern. Ein dazu passender AvePoint Beratungsservice kann darüber hinaus Ihre Umgebung und Geschäftsziele detailliert analysieren und die Konzepte für Ihre Anforderungen konfigurieren.
Wird demnach kein RBS mehr benötigt, wenn ShreddedStorage im Einsatz ist? NEIN! Es sind jedoch Ihre SharePoint Umgebung, deren Probleme und Ihre Geschäftsziele, die bestimmen, welches Konzept, oder aber eine Kombination aus beiden, den besten Nutzen für Ihr Unternehmen stiftet. Finden Sie es heraus!
Viel Spaß beim „SharePointen“!
