Schlagwort-Archive: BLOB

SharePoint BLOB Management – Shredded Storage und RBS “Better Together”

SharePoint Adventskalender – 21. Türchen

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

————————————————————-

In den letzten beiden Türchen hatten wir jeweils den RBS und Shredded Storage im Fokus. Da jede der beiden Technologien ihre Vorteile hat, können wir uns überlegen, wie wir sie gemeinsam nutzen und was es dabei zu beachten gibt.

Die verschiedenen Funktionsweisen sind deutlich voneinander zu unterscheiden. Kurz zusammengefasst, lagert der RBS Dateien aus SQL aus, um die Datenbankgröße zu verringern und eine verbesserte Performance zu erhalten. Der Shredded Storage hingegen optimiert lediglich den Speicher, in dem beispielsweise bei versionierten Dokumenten nur das Delta und nicht jeweils eine komplett neue Datei gespeichert werden muss. Die Daten bleiben jedoch im SQL! Dateien, die doppelt und dreifach über verschiedene Listen und Seiten gespeichert sind, belegen so auch mehrfach Speicherplatz. Durch Auslagerung kann diese „Dopplung“ jedoch durch den Windows Server Deduplication Service egalisiert oder zumindest minimiert werden.

Wir haben außerdem erfahren, dass jede Technologie auch ihre bestimmten Konfigurationen hat, um bestmögliche Ergebnisse zu erzielen. Das ist auf der einen Seite die Chunk-Größe des Shredded Storage und auf der anderen Seite der RBS-Grenzwert, also ab welcher Dateigröße ausgelagert werden soll. Und in der Tat, ist die Chunk-Größe geringer als der Grenzwert, so würde die Auslagerung nie aktiviert werden. Bitte beachten Sie daher diese Abhängigkeit, wenn Sie zum Shredded Storage auch eine Auslagerungen in Echtzeit nutzen möchten.

Da solche Echtzeitprozesse jedoch sehr ressourcenhungrig sind, werden sie nicht mehr von Microsoft empfohlen. Stattdessen kann man bei RBS Providern von Drittanbietern konfigurieren, dass die Datei als ganzes zählen soll und nicht nur die Fragmente betrachtet werden. Auch andere Regeln sind möglich, die nicht nur auf die Dateigröße abzielen.

Die Unterschiede und Funktionsweisen kennen wir nun. Aber für welche Szenarien ist welche Technologie am besten geeignet? Je nach dem, welche Fragen Sie in der folgenden Tabelle mit „Ja“ beantworten, umso mehr ist die entsprechende Technologie für Ihr Szenario besser geeignet. Können Sie Fragen in beiden Spalten mit „Ja“ beantworten, so wäre eine Kombination aus beiden Technologien das beste für Sie.

Shredded Storage? Antworten Sie mit Ja!

RBS? Antworten Sie mit Ja!

Gibt es viele Transaktionen?

Haben Sie viele große Dateien (> 1 MB)?

Nutzen Sie die Versionierung?

Sind diese Dateien versioniert?

Haben Sie viele Office und xml-basierte Dokumente?

Haben Sie ein SQL-Speicher-„Problem“ (Inhaktsdatenbanken von mehr als 100 GB)?

Nutzen Sie intensiv das Co-Authering Feature?

Sollen die Backups der Inhaltsdatenbanken beschleunigt werden?

Haben Sie I/Ops und Netzwerkprobleme?

Haben Sie (bewusst) viele Datei-Duplikate in verschiedenen SharePoint-Bibliotheken (und möchten Sie die Deduplication nutzen)?

 

Beide Technologien erzielen Geschwindigkeitsvorteile gegenüber der bisherigen nativen Mittel. Noch interessanter wird es jedoch, wenn wir beide Technologien aufeinander abstimmen, um so alle ihre Vorteile anwenden zu können. Besonders im Szenario mit großen Dateien können in Kombination zusätzlich bis zu etwa 80% verbesserte Downloadzeiten erreicht werden. Der Hintergrund ist die gestern angesprochene deutlich einfachere Verarbeitung von „vorgekürzten“ Fargmenten, als die gesamte Datei selbst in Pakete zerschneiden zu müssen.

Die allgemeinen Best Practices sind dafür 1250 KB als FileWriteChunkSize für den Shredded Storage und 1024 KB für den RBS Grenzwert. Microsoft MVP Chris McNulty zeigt auch sehr schön im Detail, dass diese Werte je nach Dateigröße und Umgebung etwas variieren. Bei Interesse empfehle ich Ihnen daher sehr seinen Vortrag von der SharePoint Konferenz 2014: https://channel9.msdn.com/Events/SharePoint-Conference/2014/SPC424.

Viel Spaß beim “SharePointen”!

————————————————————-

Weitere Türchen:

SharePoint BLOB Management – Shredded Storage

SharePoint Adventskalender – 20. Türchen

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

————————————————————-

Seit Microsoft den Shredded Storage für SharePoint 2013 herausgegeben hat, kursieren verschiedene Mythen und Gerüchte über Best Practices und die kombinierte Anwendung mit dem Remote BLOB Storage (RBS) bei IT-Administratoren. So habe ich bei Kunden bereits gehört, dass RBS als Synonym für Shredded Storage verwendet wurde. Außerdem hört man, dass aufgrund der kleinen Datei-Chunks, der RBS-Grenzwert nie berührt wird, oder aber, dass Shredded Storage den RBS sogar obsolet macht.

Um mit diesen Mythen aufzuräumen und Best Practice Empfehlungen geben zu können, besonders in der Kombination des Shredded Storage mit RBS, konzentrieren wir uns heute zunächst auf die Spezialitäten des Shredded Storage.

Abstrakt betrachtet macht der Shredded Storage Algorithmus folgendes:


Technisch sieht dies aber natürlich etwas anders aus. Einfach gesprochen ist der Shredded Storage die Aufteilung einer Datei in viele kleine Teile, sogenannte Chunks. Die „FileWriteChunkSize“ ist dabei der Wert, der angibt, wie groß die Fragmente beim Schreiben in den SQL sein dürfen. Es sind jedoch nicht alle Teile gleich groß, denn z.B. der Header und Footer der Datei kann 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 zusammensetzen zu können. Sobald jedoch erste Änderungen einer Datei mit Versionierung gespeichert werden, wird dieser anfängliche Mehrbedarf an Speicher wieder egalisiert.

Der Algorithmus macht auch keine Unterschiede mehr zwischen Office Dokumenten, Bildern oder anderen Dateitypen. Er versucht grundsätzlich jedes Dokument in Chunks zu zerlegen. Je nach Dateityp und Komplexität der Datei kann dies besser oder schlechter funktionieren. Zum Beispiel: Bei einem meiner Kunden hat eine neue Version einer PowerPoint-Datei fast die gleiche Größe gehabt, wie die Erstversion. Normalerweise sollte mit dem Shredded Storage aber nur das Delta, also beispielsweise die kleine Änderung im Titel, neu gespeichert werden und nicht das gesamte Dokument. Offensichtlich konnte der Algorithmus die Datei aber nicht in kleinere Chunks zerlegen.

Ziele des Shredded Storage:
Während das Hauptziel des gestern vorgestellten RBS die Auslagerung von großen Dateien ist, so verfolgte Microsoft bei der Entwicklung des Shredded Storage folgende vier Ziele:

  1. Bandbreitenoptimierung
    • nur noch Teile einer gesamten Datei müssen gesendet werden
    • dies ermöglicht und verbessert auch das Co-Authoring bei Office-Dokumenten
  2. I/Ops optimieren
    • durch kleinere Datenpakete werden die I/O Muster geglättet
    • es wird realisiert, dass Schreibkosten proportional zur Größe der Änderungen sind
    • es müssen weniger Änderungen an den SQL gesendet werden (nur Delta, nicht gesamte Datei). Dies verkleinert die Transaction Logs und erhöht damit auch die Backup-Performanc
  3. Storage reduzieren
    • es werden nur noch die Änderungen gespeichert, nicht erneut die gesamte Datei
  4. Sicherheit
    • es ist nun schwieriger eine gesamte Datei mit einem PowerShell-Befehl auszulesen
    • mit aktivierter Verschlüsselung kann jedes Datei-Chunk einzelnd verschlüsselt werden

Best Practice:
Basierend auf mehreren Tests mit unterschiedlichen Dateigrößen hat sich ergeben, dass eine FileWriteChunkSize von 1250 KB die beste Performance für Up- und Downlaods erzielt. Je nach Umgebung sowie Art und Größe der Daten, kann auch ein etwas höherer Wert Sinn machen. Als Beispiel, beim Microsoft Cloud-Storage OneDrive werden 2 MB verwendet. Allerdings sollte der Wert nicht größer als 4 MB sein. Warum? Der Hintergrund ist, dass viele System-Operationen Änderung in 4 MB Paketen verarbeiten. Kommt nun ein größeres Datenpaket, so wird dies nur in 4 MB Schritten gelesen – also in 4 MB Pakete „zerschnitten“. Das verursacht einen signifikanten Anstieg der I/Ops. Stattdessen sind zuvür „gekürzte“ Fragmente durch den Shredded Storage deutlich einfach zu verarbeiten.

„For Your Information:“

  • Zusätzlich zu der FileWriteChunkSize gab es auch noch die FileReadChunkSize. Diese Variable sollte zusätzlich die Größe der Pakete definieren, in denen die Daten ausgelesen werden. Da dies aber keine entscheidenen Vorteile brachte, wurde diese Einstellung wieder abgekündigt und man verwendet nur noch die FileReadChunkSize.
  • In SharePoint 2016 wird der Shredded Storage nicht mehr mit dem Cobalt, sondern mit dem BITS (Background Intelligent Transfer Service) Protokoll arbeiten. Damit sind zusätzliche Vorteile möglich, wie z.B. das Unterbrechen und Fortsetzen von Übertragungen (für mehr Stabilität) oder die Verwendung von ungenutzten Netzwerkresourcen zur Übertragung (um nicht andere Netzwerkaktivitäten negativ zu beeinflussen)

Zur Vollständigkeit hier noch die PowerShell Befehle, um den Shredded Storage zu konfigurieren. Achten Sie darauf, dass der Wert nur für die gesmate Farm konfiguriert werden kann, auch wenn der allgemeine PS-Ansatz etwas anderes vermuten lässt. Dies liegt daran, dass der Shredded Storage ein Web Service ist. Sollten Sie also den Shredded Storage im „gewöhnlich“ Fall mit einer bestimmten Web Application konfigurieren, behalten Sie im Hinterkopf, dass die anderen Web Applications dieses Wert auch übernehmen. Die folgenden Befehle machen diesen Sachverhalt deutlich:

Casual:
$webapp = Get-SPWebApplication http://WebAppUrl
webapp.WebService.FileWriteChunkSize =
chunk size in Bytes
$webapp.webservice.update()

Formal :
[void][System.Reflection.Assembly]::LoadWithPartialName(„Microsoft.SharePoint“)
$service = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$service.FileWriteChunkSize = 1280000
$service.Update()

Viel Spaß beim „SharePointen“

————————————————————-

Weitere Türchen:

SharePoint BLOB Management – BLOB Storage (EBS und RBS)

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:

  1. DNS Lookup
  2. Initiale Verbindung
  3. Warten
  4. Daten erhalten
  5. 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:

SharePoint BLOB Management – BLOB Cache

SharePoint Adventskalender – 18. 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.

Nach einer Umfrage der AIIM (Association for Information and Image Management) verzeichnen Firmen ein Datenwachstum von 50-75% pro Jahr. Durchschnittlich sind dabei von allen Daten 20% strukturiert und 80% unstrukturiert oder semi-strukturiert. Der nicht strukturierte Anteil wird in den meisten Fällen von BLOBs (Binary Large Objects) repräsentiert.

Leider ist aber die Funktionsweise eines Datenbanksystems und damit auch SQL dafür optimiert, kleine Informationspakete aus den verschiedenen Datenbanken und Tabellen zu kummulieren. Dies würd über „Queries“ realisiert und die Ergebnisse an den „Anfrager“ zurück geschickt. Die dazugehörigen Algorithmen können jedoch gar nicht gut mit großen Dateien (BLOBs) umgehen. Eine Anfrage auf eine einzige Datei mit einer Größe von 10 MB wird besipielsweise von SQL langsamer bedient, als würde ich sie direkt über das Netzwerk von einem File-Share laden. Somit ist klar, warum ein optimiertes BLOB Management große Performance-Verbesserungen für die Endnutzer bringt.

Beginnen wir mit dem vermutlich bekanntesten Ansatz, dem SharePoint BLOB Cache. Dieser speichert Dateien auf den WFEs, sodass SQL diese nicht bei einer erneuten Anfrage laden muss. Den Vorgang kann man sich vereinfacht folgendermaßen vorstellen:

 

Wie man sieht, ist auch hier der „frühe Vogel“ etwas langsamer unterwegs, weil er zunächst durch seinen Request den Cache des Servers „füttert“. Wird er bei einer Aktualisierung auf einen anderen WFE durch den Load Balancer geroutet, so muss auch da der Cache zunächst befüllt werden. Bei kleinen Bildern ist der Cache-Vorteil kaum zu spüren. Aber wenn wir von Dateien jenseits der 10 MB-Grenze reden, dann werden die Geschwindigkeitsunterschiede schnell deutlich.

Damit die jeweilige Datei zum Rendern schnell wieder gefunden werden kann, wird ein BLOB Cache Index erzeugt. Der Umfang dieses Index kann bei extrem vielen verschiedenen Dateien im Cache auch durchaus etwas größer werden. Im RAM-Speicher werden dafür etwa 800 Bytes pro Eintrag benötigt. Achten Sie daher darauf, welche Werte Sie für den BLOB Cache in der web.config-Datei der jeweiligen Web Application IIS-Webseiten konfigurieren. Sie können dabei definieren, welche Dateien ge-cached werden sollen und wie groß der Cache maximal werden darf (Angabe ist in GB! – standard sind 10 GB). Der ObjectCache definiert hingegen, wie viel vom Arbeitsspeicher für das Caching maximal verwendet werden darf (Standard = 100 MB!).

Der BLOB Cache ist jedoch nicht für alle Szenarien gut geeignet. Entscheiden Sie selbst, welche der beiden folgenden Szenarien bei Ihnen zu finden ist und werden Sie entsprechend tätig.

BLOB Caching besonders nützlich

BLOB Caching weniger nützlich

Seiten und deren Inhalte werden häufig besucht Weniger häufig genutzte Dateien
Vor allem “Rich Media”, also größere Dateien, wie Videos, sind solche Inhalte Dateien, die häufig geändert werden

Viel Spaß beim „SharePointen“!

————————————————————-

Weitere Türchen: