RBS und SharePoint 2013

By | 18. März 2015

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. 😉

10 thoughts on “RBS und SharePoint 2013

  1. Ralf Lueders

    Hallo Frank,

    ein sehr guter Artikel, verschärftes Lob!
    Leider bin ich jetzt erst drauf gestossen, hab mir alle deine Erkenntnisse mühsam zusammengesammelt.
    Du bist ja sogar auf Shredded Storage eingegangen. Super.

    Ich habs getested mit Windows 2012R2, Sharepoint 2013 Foundation und SQL Server 2014 Express (Filestream-Ordner auf eigenem SSD-Laufwerk auf dem SQL-Server).
    Habe 30GB Bilder hochgeladen. Sind alle brav im FileStream Ordner gelandet (ungeshredded 🙂
    Die Content-DB hatte danach nur ca. 500MB. Die sqlserver.exe hat nur ca. max. 1800MB RAM benutzt.
    SQL Server Express 2014 kann ja offiziell nur 1GB pro Instanz, der restliche RAM im SQL-Server wurde fleissig vom NTFS-FileCache benutzt und sorgte für gute FileStream-Performance.
    Schreiben war nicht so schnell (2MBytes/s), Lesen ging aber dann mit 15MBytes/s. (Vergleich: Lesen vom File-Server in meiner Test-Umgebung: 65MBytes/s)

    Ich habe hauptsächlich kleinere bis mittlere Kunden, da ist Sharepoint 2013 Foundation und SQL Server 2014 Express mit RBS natürlich lizenzkostentechnisch der Hammer.
    Aber auch mit fetten Video- und Bildbibliotheken finde ich RBS eine coole Lösung. Als CAD-Zeichnungsverwaltung könne ich mir das auch gut vorstellen.
    Ich habe Tests mit Office-Dokumenten & Versionierung gemacht, war auch sehr performant.

    Ich habe einen SQL-Backup und Restore gemacht, war schnell und hat gut funktioniert.

    Manche Artikel im Web sagen, man sollte RBS.msi auf dem SQL-Server ausführen (ist doch falsch, oder?)

    Viele Grüße aus Augsburg
    Ralf

    Reply
    1. frank Post author

      Hallo Ralf,
      vielen Dank für Dein Lob und Deine ausführlichen Erläuterungen.
      Wir nutzen auch häufig diese Konstellation, wenn die Lizenzkosten ein Thema sind. Damit kann man schon recht viele Anforderungen abdecken, auch wenn so „Komfort-Funktionen“ wie User Profile Service fehlen. Bin auch sehr gespannt, wie das ganze Thema mit SharePoint 2016 aussehen wird.
      Die RBS.msi kann man zwar durchaus auf dem SQL-Server ausführen, allerdings braucht man diese nicht für RBS und SharePoint. Kaputt gehen tut dadurch aber auch nichts.

      Viele Grüße
      Frank

      Reply
  2. Röhner

    Mal eine Frage an die Spezialisten. Ich habe einen SharePoint Foundation Server 2010 mit aktiviertem RBS, der ca. 30 GB groß ist. Der SQL Server dahinter ist ein SQL Server 2008 R2 Std. Also alles kein Problem.

    Nun soll die Umgebung migriert werden, nach SharePoint Foundation 2013 mit wie oben beschrieben, einen MS SQL Server 2014 Express. Laut Internet ist der unterstützte Weg, RBS Store komplett in DB überführen (was an der Quelle mit MS SQL Server 2008 R2 Std. kein Problem ist). Nun aber bekomme ich die 30 GB große DB nicht in den Express Server rein, da 10 GB DB Begrenzung, hier bräuchte ich also schon den aktivierten RBS Store.

    Lange Rede kurzer Sinn, 1. kann man eine DB Migration mit aktiviertem RBS Store zwischen 2 SQL Servern machen, meines erachtens nicht.

    @Ralf Lueders: Auch bei ihren Kundenszenarien, wie werden Sie mal die SharePoint Umgebungen z.B. nach SharePoint Server 2016 migrieren, wie soll das fkt.?

    Reply
  3. Ralph

    Hallo Frank,

    vielen Dank für die super Anleitung.

    Mir ist bei einer bereits befüllten Datenbank jedoch ein „Feature“ aufgefallen. in der DB liegen recht viele Bilddateien, der Migrate() befehl schiebt verhältnismäßig wenige daten von der DB in den RBS. Ich vermute das hier der Shredded Storage seinen Job getan hat.
    Gibt es eine Möglichkeit dass der Shredded Storage seinen neuen ChunkSize auf die bestehenden Files anwendet?

    Oder bin ich auf der falschen Fährte?

    Grüße Ralph

    Reply
    1. frank Post author

      Hallo Ralph,

      vielen Dank für Dein Lob.
      Ich würde sagen, Du bist auf der richtigen Fährte.
      Einen einfachen Kniff, um die Chunk Size auf bestehenden Daten anzuwenden, fällt mir allerdings nicht ein.
      Wenn Du einen findest, würde ich mich über eine kurze Rückmeldung freuen.

      Viele Grüße
      Frank

      Reply
      1. Ralph

        Hallo Frank,

        hmm, eine Idee wie ich die Kuh vom Eis bekomme? Es geht um einen SP2013 Foundation mit SQL Express.

        Folgende Überlegung:

        Die Chunk Size wird je Inhaltsdatenbank festgelegt, richtig?

        Würde es helfen wenn ich eine neue Inhaltsdatenbank mit RBS und entsprechender Chunk Size anlege und daraufhin die Sitecollection schlicht verschiebe?

        Alternativ zum Verschieben, Backup/Restore oder Export/Import.

        Das würde mir jedoch mur helfen wenn der Move „filebasiert“ verläuftbund nicht einfach nur die Tabellen der DB umzieht. Und genau hier endet mein Latein.

        Vielleicht hast Du mir hier den ausschlaggebenden Hinweise.

        Danke.

        Ralph

        Reply
        1. frank Post author

          Hallo Ralph,

          es ist zumindest einen Versuch wert. Kann es dir auch nicht genau sagen, aber ich denke schon, dass der Move „filebasiert“ laufen sollte. Alternativ (wenn es in Deiner Umgebung problemlos funktioniert) wäre auch z.B. ein Migrationstool wie Sharegate hilfreich. Das ist im Testzeitraum kostenlos und damit kannst Du auch Daten verschieben. Und dieser Vorgang läuft definitiv „filebasiert“.

          Viele Grüße
          Frank

          Reply
          1. Ralph

            Der Move hat definitiv nichts gebracht, maximal die Bereinigung verwaister Dateien in der RBS Location…

            Werden Backup und Restore nochmals testen und dann mal schauen.

            Grüße Ralph

          2. Stephan

            Hallo Ralph,
            hattest du dies damals lösen können? Ich stehe vor demselben Problem
            Grüße
            Stephan

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.