Browsed by
Tag: RBS

Review of the new storage “guidance” for SharePoint 2010 SP1

Review of the new storage “guidance” for SharePoint 2010 SP1

Rob D’Oria, father of StoragePoint, has written a very comprehensive review of the new storage “guidance” from Microsoft with regard to the limits on ContentDB size when using RBSEBS.  It is a very long post, but completely worth reading from start to finish. 

For a peak at what you can expect, here is a direct excerpt from one of my favorite sections:

Everyone hold on, here’s the super-hard backup/restore process you have to follow in this brave new world:

Backup

  1. Backup content database
  2. Backup BLOB store(s) referenced by content database

Restore

  1. Restore BLOB store(s) referenced by content database
  2. Restore content database

Did anyone pass out?  Anyone hyper-ventilating?  Anyone soil themselves?  I didn’t think so.  That’s the process in all of its complicated ugliness.  In this scenario the worst thing you end up with is some orphaned BLOBs…you have some extra BLOBs in the BLOB store back-up that are not reflected in the content DB backup because it was taken first.  Upon restoring these datasets the extra BLOBs are orphaned, but they will be garbage-collected if the EBS/RBS solution supports it.

And, oh by the way, this is your worst case scenario.

Please take some time and read Rob’s full post, which can be found here: http://blog.sharepointedutech.com/2011/07/11/sharepoint-contentdb-guidance-too-many-shades-of-gray-along-with-a-little-brown/

Connect with Rob on Twitter at @robdoria or on LinkedIn at http://www.linkedin.com/in/robdoria

Rob’s opinions in his post of ISVs are his own.  I may or may not agree with everything he says, so be sure to rub a couple of brain cells together and form your own opinions.

The big news: Data Storage Changes for SharePoint 2010

The big news: Data Storage Changes for SharePoint 2010

I go on vacation for one week and they try to change the entire strategy on us, eh?  When I first started hearing rumbles about the changes announced by the Microsoft SharePoint Product Group via their blog it sounded like the world was completely changed and that all previously known storage strategies can be thrown out the window in favor of using RBS and storing whatever you want in the Content DB!

Happily that is not at all what was being said.  While the recommended limits have been revised by Microsoft to suggest that significantly more can be stored, the key word in the statement is CAN, not should.

Let’s examine a few telling things from the Product Group’s blog article:

For a SharePoint content database up to 4 TB you need to additionally plan for the following two requirements:

  • Requires disk sub-system performance of 0.25 IOPS per GB, 2 IOPS per GB is recommended for optimal performance.

  • Requires the customer to have plans for high availability, disaster recovery, future capacity, and performance testing.

  • And you need to review additional considerations in the TechNet Boundaries and Limits article.

What this part is suggesting to us is we can us a single mirrored set (RAID1) for a large content database and get what Microsoft is defining as “optimal performance” using a 15k RPM drive scenario (approximately 180 IOPS per drive).  Great if you are looking to get some separation and you are doing sequential I/O, however when you separate the BLOBs out of the ContentDB you aren’t doing sequential I/O anymore.