Export (0) Print
Expand All

Plan for RBS (SharePoint Foundation 2010)

 

Applies to: SharePoint Foundation 2010

Topic Last Modified: 2012-04-03

This article provides information to help you decide whether to use Remote BLOB Storage (RBS) in a Microsoft SharePoint Foundation 2010 environment, and if you use RBS, how to plan the RBS deployment.

In SharePoint Foundation 2010, a binary large object (BLOB) is a file, such as a Microsoft Office 2010 document or a video file. By default, these BLOBs, also named unstructured data, are stored inline in the SharePoint content database together with the metadata, or structured data. Because BLOBs can be very large, it can be helpful to move BLOB data out of the SQL Server database, and onto commodity or content addressable storage. To do this, you can use RBS.

noteNote
Unless otherwise specified, the information in this article is specific to RBS using the FILESTREAM provider. For guidance specific to another provider, contact the provider manufacturer.

For more information about RBS including information about RBS providers, we highly recommend that you see Overview of RBS (SharePoint Foundation 2010).

In this article:

You should evaluate the implications of using RBS for the whole life cycle of the environment. What might be a good idea for normal operations, such as having large BLOB stores, might present challenges during backup and restore or during an upgrade. By evaluating the effects of using RBS and BLOB store size on the whole life cycle, you can avoid potential problems later.

For example, using a remote RBS provider will require increased IT operations complexity and some cost increases. This is because the content database and the BLOB store must be backed up in synchronization to maintain references consistency.

Another example is that in some cases upgrade operations will enumerate and possibly change each BLOB regardless of where the BLOBs are stored.

Using RBS can add some complexity to setup because you must install and configure the RBS provider on all Web servers in the farm. For more information about how to set up RBS, see Install and configure RBS (SharePoint Foundation 2010).

You should consider the average file size and the kind of file access during normal operations. Although using RBS with files larger than 1 MB can improve I/O and processor performance, using RBS with files smaller than 256 KB might decrease overall performance. Storing the BLOBs inline in the content database is more efficient with smaller files. For more information about performance of RBS, see Managing Unstructured Data with SQL Server 2008 (http://go.microsoft.com/fwlink/p/?LinkId=223909).

You should also consider how BLOB content will be used. If users will most frequently read the content but not revise it, RBS can provide performance gains. However, if users will frequently revise the content, using RBS will decrease performance. This is because extensive versioning will cause significant growth in both the metadata in the content database and the size of the BLOB store.

You should weigh any storage cost benefits against potential operational cost increases.

Using RBS also adds some operations overhead because there are several performance counters that are added to monitor RBS. Several options are available to tune RBS performance. For more information, see Maintain RBS (SharePoint Foundation 2010).

You can achieve better efficiency and speed in database index defragmentation and statistics operations when you use RBS. Also regular consistency checks, such as DBCC checks, are also significantly faster when you use RBS.

However, regular database maintenance will become more complex because you must configure and use the RBS Maintainer to maintain link-level consistency between the metadata and the BLOB store and to perform cleanup of orphaned BLOBs. For more information, see Maintain RBS (SharePoint Foundation 2010).

If you use the local FILESTREAM provider with RBS, you can use built-in SharePoint tools to back up and restore. These operations back up and restore both the metadata and the BLOB store. If you use the remote RBS provider, you must carefully coordinate the backup and restore processes. This is because the backup and restore processes involve both the metadata and the BLOB store. You should take this into account when planning the RBS configuration. Not all RBS providers support backup and restore of BLOB data. You must check with the manufacturer of the provider to confirm support.

You cannot use Microsoft System Center Data Protection Manager to back up and restore content that is stored in the RBS stores.

Under some circumstances, an upgrade, or even applying software updates, can enumerate and iterate through each object to include BLOB data regardless of where that data is stored. Therefore, upgrade operations will be similar in duration whether inline or remote BLOBs are used.

You should evaluate the implications of using RBS in different site scenarios. Because RBS was created to solve specific problems, RBS might not perform equally well in all scenarios. The scenarios in the following sections are examples.

If you are considering using RBS with team sites or other highly-collaborative sites, and the sites typically contain documents smaller than 256 KB, you will not see significant gains by using RBS. Moreover, by using versioning, you can cause the content database to grow very quickly if documents are being revised frequently.

importantImportant
The use of RBS-enabled content databases larger than 4TB with collaboration sites is not supported. You cannot upload any document larger than 2GB to an RBS-enabled content database. For more information about RBS limits, see the “Content databases” section is SharePoint Server 2010 capacity management: Software boundaries and limits.

RBS works well for record centers and other archive sites. Because these sites are mostly read-only and do not use versioning, you can store lots of data in the RBS store.

Each RBS provider will have different capabilities and limitations. The FILESTREAM provider has the following limitations:

  • RBS has specific content database size limitations for specific scenarios. For more information about these limitations, see the “Content database limits” section in SharePoint Server 2010 capacity management: Software boundaries and limits.

  • Encryption is not supported on BLOBs, even if Transparent Data Encryption is enabled.

  • RBS does not support using data compression.

  • Support for database mirroring and log shipping is altered. For more information, see Evaluate provider options later in this article.

To determine the capabilities and limitations of third-party providers, contact the provider manufacturer.

This section discusses the benefits and costs of using RBS. These benefits and costs usually apply regardless of which provider you use. For more detailed information about how to use the FILESTREAM RBS provider, see Benefits and costs of using the FILESTREAM RBS provider later in this article. For more detailed information about how to use third-party RBS providers, contact the provider manufacturer.

RBS was designed to move the storage of BLOBs from databases on database servers to directories on commodity storage solutions. Therefore, under the specific environments that RBS was intended to be used in, you can experience performance or cost benefits. By using lower-priced storage instead of more expensive storage on a databases server, you can save on costs. RBS saves storage resources when there are fewer large BLOBs. When there are many smaller files, there is no benefit.

RBS will increase operational costs because the IT staff must perform additional tasks when they back up or restore the content. Large RBS stores can slow down tasks such as backup or restore, updating the environment, upgrading to a newer version of SharePoint Foundation, or migrating the SharePoint sites to another environment. These costs should be considered when you evaluate whether to use RBS.

This section discusses the benefits and costs of using the FILESTREAM provider. These benefits and costs might not be relevant for another provider. For information about how to use third-party RBS providers, contact the provider manufacturer.

Microsoft currently supports only the FILESTREAM RBS provider with SharePoint Server 2010. When you use this provider, the backup and restore features in SharePoint Server 2010 also back up and restore the BLOBs and the structured data in the content database without requiring you to do additional work. The FILESTREAM provider also supports Internet Small Computer System Interface (iSCSI) connected storage devices.

In the case of SharePoint Foundation 2010, consider implementing RBS if you want to remain on a free version of Microsoft SQL Server, and you estimate that the databases will be larger than 4 GB. If you do not expect that the content databases will grow larger than 4 GB, we do not recommend that you implement RBS.

noteNote
If you are upgrading from Windows SharePoint Services 3.0 to SharePoint Foundation 2010, see the following article for additional upgrade advice: Upgrading from a stand-alone installation of Windows SharePoint Services 3.0 to SharePoint Foundation 2010 when content databases exceed 4 GB (RBS).

By default, Microsoft SharePoint Foundation 2010 is installed together with Microsoft SQL Server 2008 Express. SQL Server 2008 Express has a 4 GB size limit for any database. You can immediately extend the supported size of the content databases by installing Microsoft SQL Server 2008 R2 Express, which supports databases up to 10 GB. SQL Server 2008 R2 Express is a free download that is available at http://go.microsoft.com/fwlink/p/?LinkID=189418.

The remainder of this section assumes that you will install SQL Server 2008 R2 Express to support SharePoint Foundation 2010 databases. In this case, if you expect that the content databases will be 10 GB or larger, consider the following options:

  • If the content databases will be up to 16 GB and you do not expect that they contain more than 10 GB of metadata, you should implement RBS. In this case, RBS lets you continue to use a free version of SQL Server. In making this recommendation, we assume that when you migrate a 16 GB content database to RBS, the metadata does not exceed 10 GB.

  • If the content databases are larger than 16 GB, you must purchase Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, or SQL Server 2005 with SP3 and Cumulative Update 3 to support the databases instead of remaining on a free version of SQL Server.

Using the FILESTREAM provider might increase operational costs because the IT staff must perform additional tasks. Large RBS stores can slow down tasks such as backup or restore, updating the environment, upgrading to a newer version of SharePoint Foundation, or migrating the SharePoint sites to another environment. These costs should be considered when you evaluate whether to use RBS.

Because RBS is a solution created for a specific set of conditions, there is an optimal use of RBS in which the benefits outweigh the costs. The optimal environment for using RBS is an environment where the following is true:

  • You want to store fewer large BLOBs (256 KB or larger) for read-intensive or read-only access.

  • The resources on the computer that is running SQL Server might become a performance bottleneck.

  • The expense of high-cost drive space is greater than the expense of increased IT operations complexity that might be introduced by using RBS.

RBS is not a good solution for all environments. The costs will outweigh the benefits most of the time. The least optimal environment for using RBS would be an environment where the following is true:

  • You want to store many small BLOBs (256 KB or less) for write-intensive access.

  • The resources on the computer that is running SQL Server are not a performance bottleneck.

  • The expense of increased IT operations complexity that might be introduced by using RBS is greater than high-cost drive space.

Under these conditions, even a content database less than 200 GB will produce a noticeable performance bottleneck as the small BLOBs are frequently accessed for writing. This occurs because the database contains the metadata for the BLOBs. As the metadata is changed, new rows are added to the table in the database. This can cause the table to quickly grow very large. Large tables can decrease performance.

Although the presence of many small BLOBs can decrease performance, the cost of storage is usually the most important consideration when you evaluate RBS. The predicted decrease in performance is usually an acceptable trade-off for the cost savings in storage hardware.

RBS requires a provider that connects the RBS APIs and SQL Server. Microsoft SQL Server 2008 Express and Microsoft SQL Server 2008 R2 Express include the FILESTREAM provider.

importantImportant
RBS can be run on the local computer that is running Microsoft SQL Server 2008 R2, SQL Server 2008 or SQL Server 2008 R2 Express. To run RBS on a remote server, you must be running SQL Server 2008 R2 Enterprise. SharePoint Foundation 2010 requires you to use the version of RBS that is included with the SQL Server Remote BLOB Store installation package from the Feature Pack for Microsoft SQL Server 2008 R2. Earlier versions of RBS will not work with SharePoint Foundation 2010. In addition, RBS is not supported in SQL Server 2005.

BLOBs can be kept on commodity storage such as direct-attached storage (DAS) or network attached storage (NAS), as supported by the provider. The FILESTREAM provider is supported by SharePoint Foundation 2010 when it is used on local hard disk drives or iSCSI drives only. You cannot use RBS with FILESTREAM on remote storage devices, such as NAS.

The following table summarizes FILESTREAM benefits and limitations.

 

Operational requirement With the FILESTREAM provider Without the FILESTREAM provider

SQL Server integrated backup and recovery of the BLOB Store

Yes

Maybe 1

System Center Data Protection Manager (DPM) 2010 integrated backup and recovery of the BLOB Store

No

Maybe 1

Scripted migration to BLOBs

Yes

Yes

Supports mirroring

No

Yes

Log shipping

Yes

Yes, with provider implementation

Database snapshots

No2

No2

Geo replication

Yes

No

Encryption

NTFS only

No

Local drives supported

Yes

Yes, with provider implementation

Network Attached Storage (NAS)

Only supported by SharePoint 2010 Products with iSCSI and if TTFB is less than 20ms.

Yes, with provider implementation

Direct Attached Storage (DAS)

Not supported by SharePoint 2010 Products

Yes, with provider implementation

iSCSI Drives supported

Yes

Yes, with provider implementation

1Only if the RBS provider that you are using does it.

2If the RBS provider that you are using does not support snapshots, you cannot use snapshots for content deployment or backup. The FILESTREAM provider does not support snapshots.

If the FILESTREAM provider is not practical for the environment, you can purchase a supported third-party provider. In this case, you should use the following criteria when you evaluate a provider:

  • Backup and restore capability

  • Tested disaster recovery

  • Deployment and data migration

  • Performance impact

  • Long-term administrative costs

importantImportant
We do not recommend that you develop a provider unless you are an independent software vendor (ISV) that has significant development experience in designing storage solutions.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft