In diesen Vortrag musste ich einfach gehen. Bei der Diskussion SharePoint oder nicht ist immer als Argument gegen SharePoint sofort gekommen "Da werden ja alle Files in der Datenbank gespeichert" und man hat nur sagen können – "Ja. Es entstehen dadurch Vorteile, aber auch Nachteile". Aktuell haben wir ContentDB bei großen Bauprojekten von 300GB stetig wachsend. Wir haben schon einige Vorkehrungen getroffen, wie jedes Projekt bzw. auch jedes Teilprojekt schon in einer eigenen Content-DB, aber naja bei einem Bauprojekt wie dem Wiener Hauptbahnhof, das über 15 Jahre läuft und dementsprechend viele Dokumente anfallen -> ist die DB-Größe immer im Hinterkopf.
Also here we go:
BLOB Data in SharePoint:
- Blob is the data stream associated with a file
- SharePoint File Metadata and BLOBs are stored in SQL databases
- BLOBs do not participiate in query operations
- Sharepoint deployments are file heavy (ja was heißt…)
- BLOBs typically account for 60-70% of total content (da hätte ich mehr geschätzt)
- Wo sind BLOB Daten zurzeit gespeichert? -> eh klar, in der ContentDB
Aber wo liegt das Problem?
- SQL storage ist teuer
- Performance Impact
- Manageability costs (längere Backup's / Recovery) … mhm.. können wir ein Lied davon singen
- Richer Policy Requirements
Remote BLOB Storage (RBS) ist die RETTUNG -> yuhuuuu ;-)
- Kann man downloaden und als add-in Komponente in einer SharePoint Farm registrieren
- External Blob Store gibt's schon seit 2007 SP1, aber habe ich ehrlich gesagt noch nirgends gesehen
- SharePoint 2010 hat automatisch SQL Remote BLOB Storage (RBS) integriert
- Vorteile gegenüber EBS
- Es gibt ein managed Interface dazu
- Der BLOB Store Scope ist auf ContentDB Ebene
- Es gibt ein SharePoint UI über die PowerShell
- Man kann viele verschiedene Provider verwenden
- Why should RBS used? (blöde frage ;-))
- Billiger Storage Kosten
- Besseres / schnelleres Backup / Restore
- Es können die Vorteile von Data Storages Ventures verwendet werden
- Welche Hersteller vertreiben RBS BLOB Storages
- EMC²
- OpenText
- AvePoint
- Commvault
- NetApp
- Und viele weitere werden noch folgen (das glaube ich auch)
Wie geht man vor?
- Muss zusätzlich zum SQL 2008 R2 heruntergeladen werden
- RBS und Providers DLLs müssen auf allen WebFront-ends installiert werden
- RBS muss über PowerShell aktiviert werden
- Migration kann über PowerShell gemacht werden (EBS manuell) -> also aus bestehenden ContentDB kann das mit PowerShell umgewandelt werden auf RBS
Wie läuft das ganze ab beim Speichern eines Dokuments:
Wie läuft das ganze ab beim Laden eines Dokuments:
Demo RBS mit RBS FileStream (was automatisch beim RBS Provider dabei ist) – es funkt wirklich :)
Speichern des Dokuments – normal über SharePoint:
Unglaublich aber wahr, das File liegt im FileSystem (mit GUID und ohne File-Type)
Performance – little to no Overhead :)
Wichtig: man braucht SQL Server Enterprise Edition Lizenz!