SharePoint 2010 and Remote Blob Storage – part 1

SharePoint stores its content in SQL databases, called the content databases. Ok, I assume that everyone knows this. If not, try to catch up! The most common farm topology is therefore to have several SharePoint front-end servers with a SQL Server cluster as back-end. SQL stores its databases on a Storage Area Network, or SAN.

All content is stored in these SQL databases, including all (versions of) documents. And it’s these documents which are eating up all that expensive SQL and SAN capacity.

Documents are stored as Binary Large OBjects or BLOBs within the content database. Although SQL can handle these blobs easily, in its inception it wasn’t meant to. SQL likes tables and columns and relationships between those. It doesn’t particular like storing large blobs within its databases.

Even more so when you realize that every version of a document (let’s say a PowerPoint of 15Mb) is stored as a blob. And with version I don’t simply mean the PowerPoint itself. No: if you only change one metadata field, a new version of the complete document is created. Like I said: this is eating up your SAN and SQL capacity.

But there is an alternative. You can use the so-called Remote Blob Storage or RBS. With RBS you separate the blobs from your metadata. The blob is stored on another location (a less expensive SAN, for example), while all other (meta)data is still stored in the content database(s).

When to use

Research done by Microsoft revealed several performance gains when enabling RBS in combination with SharePoint 2010. Especially when using a SAN which can eliminate data replication (when the blob doesn’t change, then the SAN does not store a new version).

The RBS scenario can prove productive when you are using documents larger than 1 Mb. However, because you are writing directly to SAN and to SQL, it might not be wise to use RBS in collaboration scenarios or scenarios with a lot of read/write actions. So, for your DMS or RMS or intranet, RBS might be something to consider.

Also, don’t use RBS in a scenario where your SAN and SQL environments are immensely separated. The latency will be a performance killer. In theory you can use RBS and use a storage provider in the cloud…….Yeah, right. Moving right along.

Drawbacks

Are there drawbacks to a RBS scenario? For one: RBS is not optimal for all SharePoint scenarios, so you will need to think this over. Also, consider the fact that SharePoint data will be stored on multiple locations! So the complexity of your IT landscape will grow.

Filestream

To use RBS, you will need a so-called RBS provider. Microsoft supports the Filestream provider. Other providers are available, though. The Filestream provider offers the basic RBS functionality, but it also takes care of back-up and restore (important one, this!) and makes sure that the data is consistent between content databases and the remote blob store. In other words: it makes sure that these locates are kept in-sync.

How to?

Want to test this out? Follow this procedure in your test environment.

Information thankfully obtained from Microsoft.

In this procedure, replace “WSS_Content” with the name of the content database you want to enable for RBS. Don’t know the name of your content database? Go to Central Administration | Manage Content databases.

Also, where needed, include the correct DB Instance.

Step 1: Enable RBS by setting up an encryption key and databases

Open SQL Server Management  Studio.

Go to the query window en enter the following query.

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

This should result in a succesful operation.

Next. Enter the following query. This will create the necessary databases, but will also create the blob location (c:\blob). So, change this if you feel the need.

use [WSS_Content]
if not exists (select groupname from
sysfilegroups
where groupname=N'RBSFilestreamProvider')
alter database [WSS_Content]
add filegroup RBSFilestreamProvider contains
filestream
use [WSS_Content]
alter database [WSS_Content]
add file (name = RBSFilestreamFile,
filename = 'c:\blob')
to filegroup RBSFilestreamProvider

Step 2: Install Filestream

First of all, download the RBS msi file from Microsoft: http://go.microsoft.com/fwlink/?LinkId=177388

But don’t run this as-is. Use the following procedure.

On the SQL servers, run:

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

On the SharePoint servers, run:

msiexec /qn /lvx* rbs_install_log.txt /i
RBS_X64.msi DBNAME="WSS_Content" DBINSTANCE=""
ADDLOCAL="Client,Docs,Maintainer,ServerScript,
FilestreamClient,FilestreamServer"

Step 3: check the install

Now we are going to use the SharePoint 2010 powershell to check if the RBS provide has been installed. Use the following commands.

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

This will result in “True”.

In my next blog, I will show you what has happened.