by JerseyBob
31. May 2010 08:30
This is personally one of my favorites for two reasons, 1) the absolute opposite is true and 2) StoragePoint has been architected from the beginning to handle this. I love having the replication (or how do I create a replica?) conversation with customers and partners because they are always shocked how easy it is to do this with StoragePoint in place. I regularly have a hypothetical conversation with a SharePoint admin or IT management type around the following scenario: We regularly take content from our production environment and refresh one or more of our pre-production environments for development, testing, or staging purposes. How do I move the content databases without them pointing back to my production BLOB stores? The answer to this question is simple with StoragePoint. It helps to understand that the BLOB References we hand back to SharePoint and that are stored in the content DB contain to pieces of information, one is an Endpoint ID (reference to the physical location of the BLOB store) and the BLOB ID (reference to the relative location of the BLOB within the BLOB store). This de-coupling or abstraction of the physical location from the BLOB reference allows us to point the BLOB refs to a different BLOB store by simply changing the physical location of the BLOB store within the Endpoint definition. So an admin can attach the content db from the prod environment into their non-prod environment (...or do a backup and restore), simply copy the prod BLOB store to another location, and change the Endpoint entry in StoragePoint to reflect the new non-prod BLOB store location. Done! No need to re-synthesize (...re-build) BLOB References. No need to internalize and then re-externalize content. This same "shallow copy" methodology can be used for other replication scenarios, whether they be batch processed or real-time. You're just moving the list item information along with the BLOB Reference from a SharePoint perspective and using Windows DFS or some other replication capability to move the BLOBs. The DR site has the same Endpoint definitions, the path (FileSystem adapter) or accesspoint/bucket/container/tenant (cloud Adapter) of each Endpoint definition is just different.
If you're looking at other solutions and replication is important to you, make sure they don't store the physical location of the BLOB in the BLOB reference because it will unnecessarily complicate or restrict certification and disaster recovery tasks if they do. This seemed like the obvious architectural approach to us, but based on feedback from some of our customers and partners that evaluated other solutions along with StoragePoint it apparently is not that obvious a choice. I tend to chalk it up to us being focused on delivering a best of breed solution that handles a wide array of real-world usage scenarios elegantly and simply rather than just flinging something out there in an effort to be all things SharePoint.
There will be more on this in a DR whitepaper we are releasing along with the RTM of StoragePoint 3.0 on June 14th.
StoragePoint 3.0 Information
- Contact us at info@storagepoint.com if you have any questions or would like to request access to the Release Candidate. We will not issue pre-release trials without full corporate contact information (Name, Title, Company, Address, Phone Number, and Email Address).
- Attend one of our weekly StoragePoint 3.0 Overview sessions.
- Follow us on Twitter for updates on new content (videos, whitepapers, blogs, etc.).
- Find us on Facebook @ www.facebook.com/StoragePoint
- Check storagepoint.com on June 14th for our new site.
Subscribe