RBS und SharePoint 2013

Im Netz gibt es unzählige Anleitungen wie man den Remote Blob Storage (RBS) in Verbindung mit SharePoint 2013 installiert und konfiguriert. Jedes Mal wenn ich RBS mal wieder auf einem System umsetzen darf, stolpere ich dann über diese ganzen Anleitungen und muss feststellen, dass ganz oft irgendein Schritt fehlt oder einfach falsch ist. Deshalb möchte ich gerne meine Vorgehensweise dokumentieren, die bisher immer zum Erfolg geführt hat.

Für den Einsatz von RBS gibt es viele Gründe. Einer davon ist, dass man bei kleinen und kostengünstigen Umgebungen die Express Edition vom SQL Server in Verbindung mit SharePoint Foundation verwenden kann. Dadurch kann je nach Umgebung einiges an Lizenzkosten eingespart werden. Allerdings sind damit auch einige Einschränkungen verbunden. Die Beschränkung der Datenbankgröße bei der Express Edition des SQL Servers kann mit RBS recht einfach gelöst werden. Durch RBS erfolgt keine Speicherung von Dokumenten etc. (Dateien ab einer bestimmten Größe, aber dazu später mehr) in der Inhaltsdatenbank selbst, sondern werden in das Filesystem ausgelagert. In der Datenbank verbleibt nur ein „Link“ auf die Datei im Blobstore.

Als erster Schritt müssen die FILESTREAM Einstellungen für die entsprechende SQL Instanz vorgenommen/aktiviert werden. Dies geschieht über den SQL Server-Konfigurations-Manager:

Danach muss man noch folgenden Transact-SQL-Code ausführen, um die FILESTREAM-Konfiguration abzuschließen:

EXEC sp_configure filestream_access_level, 2
RECONFIGURE

Danach muss der SQL Server-Dienst neu gestartet werden und die „globalen“ Einstellungen sind vorgenommen.

Als nächster Schritt müssen die SharePoint-Inhaltsdatenbanken entsprechend für RBS konfiguriert werden. Um später Probleme zu vermeiden, ist es sinnvoll die Datenbank zu diesem Zeitpunkt bereits im SharePoint als Inhaltsdatenbank hinzugefügt zu haben. Die Konfiguration von RBS geschieht ebenfalls über Transact-SQL-Code und die Ausführung erfolgt für jede Inhaltsdatenbank separat:

use [WSS_Content_Test1]
if not exists (select * from sys.symmetric_keys where name =N'##MS_DatabaseMasterKey##') create master key encryption by password = N'Password'

Hier muss natürlich in Zeile 1 der Name der Datenbank angepasst werden und das Ersetzen des Passworts durch eine sichere Variante ist ebenfalls Pflicht.

Danach geht es mit Transact-SQL-Code weiter:

use [WSS_Content_Test1]
if not exists (select groupname from sysfilegroups where groupname=N'RBSFilestreamProvider') alter database [WSS_Content_Test1]
add filegroup RBSFilestreamProvider contains filestream

Und zum Abschluss wird noch der Speicherort für die ausgelagerten Dateien konfiguriert:

use [WSS_Content_Test1]
alter database [WSS_Content_Test1] add file (name = RBSFilestreamFile, filename = 'D:\RBSLocation') to filegroup RBSFilestreamProvider

Dabei ist lediglich zu beachten, dass das angegebene Verzeichnis noch nicht existieren darf. Ansonsten wird beim Ausführen des Befehls ein Fehler geworfen.

Nachdem wir geprüft haben, dass das Verzeichnis auch korrekt angelegt wurde, sind wir mit der Konfiguration auf SQL Seite fertig.

Zu beachten ist nur noch, dass die Berechtigungen ggf. noch angepasst werden müssen. Die Inhaltsdatenbank gehört zu einer Webanwendung im SharePoint. Der Application Pool jeder Webanwendung sollte laut Best Practices unter einem separaten Service Account ausgeführt werden. Und genau dieser Service Account benötigt im Fall von RBS DB Owner Rechte auf der Inhaltsdatenbank. Ansonsten kommt es zu Fehlern im SharePoint, wenn man versucht Dateien über RBS zu öffnen.

Nun müssen wir RBS auf jedem SharePoint Webserver (nicht Applikationsserver) installieren. RBS ist Bestandteil vom SQL Server Feature Pack und kann einzeln heruntergeladen werden. Man muss nur darauf achten, dass man die richtige SQL Server Version und x64 Architektur ausgewählt hat. Die Installation von RBS unterscheidet sich je nachdem, ob man RBS auf dem ersten oder einem weiteren Webserver installiert und ob mehrere Datenbanken für RBS konfiguriert werden sollen. In diesem Artikel geht es primär um kleinere Umgebungen, deshalb zeige ich nur die Installation auf dem ersten Webserver (weil man in kleineren Umgebungen auch nur einen hat). Die Installation von RBS für die erste Datenbank erfolgt mit dem Befehl:

msiexec /qn /lvx* rbs_install_log.txt /i RBS.msi TRUSTSERVERCERTIFICATE=true FILEGROUP=PRIMARY DBNAME="WSS_Content_Test1" DBINSTANCE="SPSQL" FILESTREAMFILEGROUP=RBSFilestreamProvider FILESTREAMSTORENAME=FilestreamProvider_1

Für weitere Datenbanken muss dieser Befehl genutzt werden:

msiexec /qn /lvx* rbs_install_log.txt /i RBS.msi REMOTEBLOBENABLE=1 FILESTREAMPROVIDERENABLE=1 FILEGROUP=PRIMARY FILESTREAMFILEGROUP=RBSFilestreamProvider FILESTREAMSTORENAME=FileStreamProvider_1 ADDLOCAL=EnableRBS,FilestreamRunScript DBINSTANCE="SPSQL" DBNAME="WSS_Content_Test2"

Wenn die SharePoint Umgebung nach Best Practices aufgesetzt ist, verwendet man  bei der DBINSTANCE den bereits bestehenden SQL Alias für den Datenbankzugriff. Weiterhin muss der Befehl als Administrator ausgeführt werden.

Nach ca. 30 Sekunden ist die Datei rbs_install_log.txt größer als 0KB geworden. In dieser Datei wird die Installation/Konfiguration  vom RBS protokolliert. Sobald die Dateigröße nicht mehr weiter wächst, sollte man sich den Inhalt einmal näher ansehen und prüfen ob die Installation erfolgreich war. Als Erstes sollte man am Ende der Datei nach folgendem Eintrag suchen:

Allerdings habe ich in der Vergangenheit festgestellt, dass nur der Eintrag „Configuration completed successfully“ nicht zwingend das bedeutet was er eigentlich verspricht. Um ganz sicher zu gehen, sollte die Log-Datei noch weiter nach SQL Statements durchsucht werden. Dadurch werden die Änderungen an der Inhaltsdatenbank protokolliert und sehen exemplarisch so aus:

Wenn diese Meldungen im Log zu finden sind, kann man ziemlich sicher sein, dass die Installation erfolgreich war.

Nun kann man endlich RBS für die SharePoint Inhaltsdatenbank per Powershell aktivieren:

$cdb = Get-SPContentDatabase "WSS_Content_Test1"
$rbss = $cdb.RemoteBlobStorageSettings
$rbss.Installed()
$rbss.Enable()
$rbss.SetActiveProviderName($rbss.GetProviderNames()[0])
$rbss
$rbss.MinimumBlobStorageSize=1048576

In Zeile 3 sollte als Ergebnis TRUE zurückgegeben werden. Wenn nicht, ist bei den vorherigen Schritten ein Fehler aufgetreten. Alle nachfolgenden Befehle können dann logischerweise nicht erfolgreich ausgeführt werden. Der Befehl in Zeile 7 ist optional und legt fest, ab welcher Dateigröße die Dateien im Blobstore gespeichert werden anstelle der Datenbank. Die Größe wird hier in der Einheit Byte angegeben. Im oben dargestellten Beispiel werden also Dateien ab einer Größe von 1MB im Blobstore abgelegt.

Ein neues Feature in SharePoint 2013 ist der Shredded Storage. Auf die genaue Funktionalität möchte ich an dieser Stelle gar nicht eingehen, denn dazu gibt es auch wieder genügend Artikel im Netz. Durch Shredded Storage werden Office Dokumente in kleine Teile (ca. 64KB) zerlegt. Was im Normalfall einige Vorteile mit sich bringt, insbesondere bei der Versionierung, ist bei der Verwendung von RBS suboptimal. Ein Office-Dokument besteht plötzlich aus (ganz) vielen Teilen, die im Dateisystem abgelegt werden. Beim Zugriff auf ein Dokument müssen also eine Vielzahl von Dateien im Dateisystem angefasst (lesen/schreiben) werden, was keine optimale Voraussetzung für eine gute Performance ist. Shredded Storage kann man allerdings auch nicht einfach deaktivieren. Allerdings gibt es die Möglichkeit die Größe der einzelnen Teile anzupassen. Wählt man diese entsprechend groß, wird Shredded Storage also „deaktiviert“. Es empfiehlt sich, die Größe auf 1GB zu setzen. Dies geschieht ebenfalls über die Powershell:

$wa = Get-SPWebApplication http://webappurl
$wa.WebService.FileWriteChunkSize = 1073741824
$wa.webservice.update()

Nun können wir endlich RBS in Aktion sehen. Dazu muss man eine Datei hochladen, die über der definierten Minimalgröße des Blobstores liegt. Danach kann man im Dateisystem anhand des Zeitstempels prüfen, ob die Datei auch wirklich im Blobstore landet. Ein funktionierender RBS sieht so aus:

Natürlich kann man die RBS Konfiguration auch bei bereits mit Daten gefüllten Inhaltsdatenbanken vornehmen. Das Vorgehen ist hierbei identisch, lediglich am Ende muss ein zusätzlicher Befehl in der Powershell ausgeführt werden, der die Migration in den Blobstore startet:

$cdb = Get-SPContentDatabase "WSS_Content_Test2"
$rbss = $cdb.RemoteBlobStorageSettings
$rbss.Installed()
$rbss.Enable()
$rbss.SetActiveProviderName($rbss.GetProviderNames()[0])
$rbss.Migrate()

Der umgekehrte Weg ist natürlich auch möglich:

$cdb = Get-SPContentDatabase "WSS_Content_Test2"
$rbss = $cdb.RemoteBlobStorageSettings
$rbss.SetActiveProviderName("")
$rbss.Migrate()

Damit werden die Daten aus dem Dateisystem wieder in die Datenbank „eingelagert“.

Der letzte Punkt bei der Verwendung von RBS, der gerne vergessen wird, ist die Wartung vom Blobstore. Dateien die im SharePoint gelöscht werden, werden nicht automatisch auch im Dateisystem gelöscht. Je nach Nutzung vom SharePoint kann hier sehr viel Speicherplatz verschwendet werden. Bei der Installation von RBS werden die Grundlagen für die Wartung bereits mit installiert. Man muss diese nur ggf. noch entsprechend anpassen und konfigurieren. Genauere Informationen dazu findet man wie immer im Netz, oder vielleicht auch in einem späteren Blogpost von mir. 😉