How to Reduce SharePoint Storage Cost with BLOB Offloading

Data loses its value as it gets older. The reference data which is less frequently used grows exponentially as compared to active data with the passage of time. Treating all this data alike has a negative impact on the costs of storing it as it leads to higher costs and less than optimal utilization of your storage infrastructure.

For a SharePoint environment, this problem is further aggravated by BLOB storage. Coming from a SharePoint Administrator background, I have seen numerous installations of SharePoint that suffer from issues related to management of large volumes of BLOBs, whether new or old. So, despite huge investments in the storage infrastructure, the users end up with a poorly-performing-yet-high-cost SharePoint storage infrastructure.

So, you need to align your storage options across two lines of action. Firstly, adopt the most appropriate storage tier for the data being stored and secondly, keep the data growth in line with its frequency of access.

BLOBs generally consume 95% of the SQL Server storage in SharePoint.  Although SQL Server is a high performance resource manager, when it comes to large binary data streams, it no longer remains a viable option. In SharePoint, a large proportion of content is documents stored as BLOBs. And, unfortunately SQL Server, like all other relational databases, was not designed to handle such large amounts of unstructured data. As a result, a number of problems usually occur.

Optimize SharePoint Performance and Storage - Free Download

As the data file size grows larger than 200 GBs, SQL Server performance degrades considerably which results in a poorly-responsive SharePoint environment. Similarly, storing all the BLOBs in SQL Server is not cost effective as SQL Server storage is typically very expensive. So, it is essential that you should store BLOBs on a lesser expensive storage tier that can manage unstructured data.

Similarly, considering the high costs that the storing of older BLOBs in high-end storage can cause, it is unwise to treat all the BLOBS alike in terms of its storage.

The above situation calls for simply offloading the SharePoint BLOBs payload from expensive, transactional storage to less expensive external storage as it will give you visible cost savings. An effective approach for the storage of externalized BLOBs can be to structure the external storage as a hierarchy of multiple tiers in the form of a hierarchical storage management system (HSM), with one storage tier corresponding to one age-based category of BLOBs.

StorageEdge precisely lets you do that. It has been built keeping the above-mentioned BLOB storage consideration in perspective. It provides multi-tiered storage that allows you to offload your active content in the most expensive storage and archives older content out to less expensive storage.

multi-tiered storage

multi-tiered storage

Figure 1: multi-tiered storage

So, by having an intelligent, reliable facility to offload SharePoint BLOBs in multi-tiered storage, you are able to control your storage cost in alignment with the business needs as you are able to grow you storage options in an incremental manner. You can expect great cost savings if your storage system can continue to move older BLOBs to less expensive storage tiers.

Surprisingly, it also improves SharePoint performance because the most active storage (meaning your Tier-1) no longer contains all those huge amount of documents that would have overwhelmed it. In a nutshell, externalizing BLOBs from SharePoint is not an option; rather it is a necessity for the best use of your SharePoint to perform. StorageEdge lets you achieve that with an absolute ease.

Download StorageEdge | StorageEdge Details

Posted in SharePoint Storage | Leave a comment

Impact of Job Throttling On SharePoint Performance

Externalizing BLOBs is the nicety that can enhance the performance of SharePoint remarkably. However, dealing with TBs of content requires that tasks being performed on this large volume of data don’t hamper the performance of the SharePoint infrastructure. Consider a typical SharePoint environment where the total size of content can easily reach in TBs.  An archival job from one tier of storage to another or such other BLOB transfer activity can easily choke the SharePoint servers. At peak times, if these jobs continue to run, the capacity of the SharePoint infrastructure to service the user requests is seriously compromised.

SharePoint Job throttling is the technique of regulating the performance of these tasks in any system. It can be used in situations where it is required to limit the amount of data that can be transferred in a unit of time. Long running jobs such as Migrate, Revert, Garbage Clean, BLOB Transfer, and EBS to RBS Convert etc are heavily I/O bound jobs having a potential to considerably slow down the performance of WFEs. So SharePoint job throttling is the mechanism which allows the execution of a job / task to be configured to consume system resources at various levels at different points in time. This arrangement ensures that SharePoint WFEs dedicate their maximum resources to servicing the user requests during peak hours and let these resources be consumed in completion of heavy, I/O bound jobs during the non-peak times.

Optimize SharePoint Performance and Storage - Free Download

StorageEdge provides comprehensive SharePoint job throttling features. When these jobs / tasks are run, various time slots can be configured to make sure that SharePoint application is not under continuous job processing stress.

Job Throttling Settings

Job Throttling Settings

Figure 1: Job Throttling Settings in StorageEdge

StorageEdge provides you the facility to configure these tasks / jobs to be run at different speeds during different timings. Different tasks such as Migrate, Revert, Garbage Clean, BLOB Transfer and EBS to RBS Convert make the use of job throttling features. This allows you to fully control the bandwidth consumption in all types of schedules. You can completely stop the bandwidth consumption in peak hours and can slow it down in normal day activity. You can increase the speed or the bandwidth consumption when it is off time or at nights and during weekends.

Hence StorageEdge ensures that WFEs continue to perform at their best when it comes to servicing the user requests at peak load hours, while managing the completion of important tasks through intelligent time-based allocation of precious resources.

Download StorageEdge | StorageEdge Details

Posted in SharePoint enhancement, SharePoint Job Throttling, SharePoint Job Throttling techniques | Tagged , , | Leave a comment

HTML Payload and SharePoint Performance

SharePoint web interface is essentially an ASP.NET application running on WFE servers. As is true for any other web application that larger the HTML payload sent to the browser, greater the amount of time it takes to travel over the wire and finally show. HTML payload depends upon the number of its constituent elements. For instance, like any other ASP.NET application, the size of View State may exceed tens of KBs owing to a large number of controls and widgets, thus becoming a performance bottleneck. Similarly, the extra overhead is introduced by multiple CSS and JavaScript files. So if this footprint could somehow be reduced, it will surely have a considerable impact on the overall SharePoint performance. Let us see how. 

  • View State is sent to the user’s browser to preserve this state across post-backs. For forms with lots of controls, View State can become quite large. The larger the ViewState size is the slower would be the response time for end user between each post back.
  • Similarly, CSS and JavaScript files are major contributors to the SharePoint HTML payload. Whenever a page is rendered, the browser issues separate GET calls for each JavaScript and CSS file. This can easily result into many extra calls to IIS and reduce SharePoint performance.

Optimize SharePoint Performance and Storage - Free Download

So how do we get performance boost? In-memory caching of BLOB payload  tells that caching might be the answer. Why not cache View State after all it is just another object. StorageEdge provides this out-of-the-box solution whereby it caches View State on WFE servers and sends a much smaller payload to the user’s browser containing only a unique ID for this View State. As a result, your page performance improves and SharePoint also scales much better. A snippet of resulting HTML is shown below:

[code lang="xml" toolbar="false"]
<input id="__NCPVIEWSTATE" type="hidden" name="__NCPVIEWSTATE"
value="vs:cf8c8d3927ad4c1a84da7f891bb89185" />
<input id="__VIEWSTATE" type="hidden" name="__VIEWSTATE" />


Figure 1: StorageEdge Caches View State and Sends an Identifier to the Client

Notice how the original “__VIEWSTATE” hidden field is preserved so everything works as if there was no View State. But, it has inserted its own “__NCPVIEWSTATE” field that it will read when a post-back request comes from the user to the web server. StorageEdge uses the “value” as the key to fetch the corresponding original View State from the in-memory cache and serves it to the ASP.NET page so it can populate the web form with data from the View State.

 Similarly, in case of CSS and Java Script, how about if you could reduce the number of files that form part of HTTP request. StorageEdge employs an intelligent technique called Minification which is a process in which StorageEdge reduces the size of all CSS and JavaScript files and merges them into one or two files. As a result, the web browser only makes one or two extra calls to IIS when requesting a SharePoint page. Thus, you can effectively reduce the number of HTTP requests a browser makes, reduce overall SharePoint HTML payload, and ultimately boost response time.

 So, StorageEdge is not simply an EBS/RBS provider or a BLOB management solution, it is a complete, end-to-end SharePoint management solution. Features such as the ones discussed above take care of all your SharePoint performance needs.

Download StorageEdge | StorageEdge Details

Posted in SharePoint HTML Payload, SharePoint Performance | Tagged , | Leave a comment

Structure your Externalized BLOBs using Multi-Tiered Storage

It is an established industry observation that the data loses its value as it gets older. A fair estimate reveals that in a typical environment, the active data constitutes only 2-4%, aging data is close to 10% and the rest is rarely used. So it is cruel to treat all the data the same in terms of its storage. Same is true for SharePoint where the active BLOB content is only a small chunk of the total content that it carries.

Moreover, everyone is in agreement that there is visible cost saving associated with simply offloading BLOBs from transactional SQL Server storage to less-expensive external storage. However, externalization of BLOBs is only one important aspect of BLOB storage management. How you manage the physical storage of externalized BLOBs is the other one. Keeping all the active and aged BLOBs on one, expensive storage is not a wise idea. If you keep all those type of BLOBs, whether active or worn, in your primary storage tier of external storage, there is a fair chance you will get only a marginal benefit out of externalization, as the cost of storage at your primary, high-end tier shall keep on increasing. So, even after offloading 90-95% of data to external storage, you still manage to get only marginal cost savings, rethink of your storage strategy is in order.

Optimize SharePoint Performance and Storage - Free Download

A worthwhile approach for the storage of externalized BLOBs is structure the external storage as a hierarchy of multiple tiers with one storage tier corresponding to one age-based category of BLOBs. This hierarchical multi tiered storage needs to be structured in such a way that the most active BLOBs should reside at Tier-1 which is a high-end, faster-access storage. Similarly, the aging data should be kept at Tier-2 which is typically a SAN/NAS based storage and the archived/seldom-accessed data at Tier-3 which can typically be a Cloud. So based on this strategy, you effectively push lesser active content to the cheaper tiers.

StorageEdge has been built keeping this very important BLOB storage strategy in perspective. It provides “Multi-tiered Storage” that allows you to keep your active content in the most expensive storage and archives older content out to less expensive storage. This effectively ensures that the primary storage is not over-burdened with millions of documents.

“Multi-tiered Storage” allows you to keep your active content in the most expensive storage and archives older content out to less expensive storage.

Figure 1: Configure separate storage profile for each tier in multi tiered storage.

StorageEdge manages the storage of externalized BLOBs on multi storage tiers through archiving based on two criteria:

1. Age: You can specify content age that allows your content to stay in a tier before it gets migrated to the next tier. This age can be specified separately for each storage tier and you can have as many tiers as you want.

2. Versioning: The other criterion is based on document versioning. Usually, everybody works on the latest copy of the documents so it is practical to archive the older versions to the cheaper storage tier

For Cloud Storage, you may want to control bandwidth, for which StorageEdge provides throttling.

So having multi-tiered storage not only reduces storage costs, but it also improves SharePoint performance because the most active storage no longer contains a huge amount of documents that can potentially inundate it.

Download StorageEdge | StorageEdge Details

Posted in BLOB Externalization, Multi-Tier Storage, SharePoint Storage | Tagged , , , | 1 Comment

Data Security of the Externalized BLOBs

There cannot be two opinions about the significance of pushing the unstructured BLOB content out of SharePoint/SQL Server dynamic duo to the inexpensive storage. However, moving BLOBs to the external storage can result in compromising the externalized BLOBs security. Many administrators fail to give due consideration to the fact that externalization of BLOBs affects the existing BLOBs protection strategies put in place for their SharePoint infrastructure. Can you afford to expose your valuable enterprise content and render it vulnerable to various types of threats? For a modern-day enterprise environment of cut-throat competition, the answer is an absolute NO. Moreover, various standards and regulatory compliances mandate you to ensure stricter controls on content storage.

One might argue that the external storage media to which the BLOBs are externalized should carry the burden of BLOBs protection. The external storage media ranges from a simple file system to SAN, NAS or Cloud and they do generally offer such tools to ensure externalized BLOBs security. However, considering the size of the content which might easily soar to multiple TBs for a typical environment, its BLOBs externalization might span numerous storage profiles spanning multiple types of storage. Naturally, for an administrator to manage even the first-level protection of BLOBs using a plethora of different tools will be a huge hassle.

Optimize SharePoint Performance and Storage - Free Download

A proper solution to this issue is the tool, which is used to externalize the BLOBs to external storage, needs to ensure that it adds the first layer of security on the externalized BLOBs. Instead of leaving the administrator on the mercy of a number of storage-media-specific tools, it must ensure sufficient BLOBs security through generic approaches. Various elements which contribute towards this important task include the encryption of content, file shredding, compression and encrypted file names.

StorageEdge has been built with precisely this requirement of externalized BLOBs security in perspective. StorageEdge provides:

  1. Encryption of Content: The BLOBs are encrypted and written to any external media subsequently. It supports encryption on a storage profile thus providing first layer of security to the externalized BLOBs. It supports DES-64bit or AES-128bit encryption.



    Figure 1: Encryption Settings in StorageEdge

  3. File Shredding: The tool responsible for externalized BLOBs management must make sure all such permanently deleted content is irrecoverable using any third-party tools. StorageEdge has a fool-proof file shredding mechanism coming into play when the BLOB is permanently deleted from SharePoint.

    Storage Provider

    Storage Provider

    Figure 2: Enabling Shredding in StorageEdge is Only a Matter of Setting a Param Value

  5. Compression: StorageEdge provides for compression of BLOBs using GZip.
  6. Encrypted File Names: The BLOB management tool must be such as to ensure that the file names are encrypted. This becomes especially important when you move the content to a storage media which is out of your enterprise such as Cloud.

So, StorageEdge takes care of your externalized BLOBs security worries from within SharePoint. If proper care of the externalized content is not taken, the BLOBs security strategies could be compromised, and result in negative impact on the organization’s overall IT governance.

Download StorageEdge | StorageEdge Details

Posted in BLOB Externalization, BLOBs Protection | Tagged , | Leave a comment

Use SharePoint Blob Caching for Performance Boost

I have written on a number of occasions on the way BLOBs are treated by the SharePoint/SQL Server combo and why it is important to separate the BLOBs out from the content metadata. One aspect of BLOB management is their storage which is effectively handled by externalizing them using StorageEdge. Another important aspect of this management is to minimize the access latency of these large chunks of unstructured data when accessed from SharePoint.

A typical SharePoint installation might grow as much as 10 TBs or more with the passage of time. There are a number of tasks that require movement of BLOBs in various directions. These range from the very trivial single-item access from within SharePoint to the much more complex such as BLOBs archiving, and linking legacy documents in SharePoint. Due to large size of unstructured BLOBs, access latencies hit the SharePoint performance badly. At times, even a trivial request such as for a single blob may result in multiple trips to the external storage. This becomes a matter of critical concern when a number of users access the storage media every time a frequently-used BLOB is required.

Optimize SharePoint Performance and Storage - Free Download

SharePoint blob caching is an important consideration when addressing the performance issues of blob access. SharePoint offers a very elementary form of blob caching which is disc based. It is restricted to only one WFE in the SharePoint infrastructure and does not go beyond its confines. But the reality tells us that BLOB access, with payload growing as high as terabytes, requires a much more sophisticated, distributed, in-memory, and fail-safe caching infrastructure.

StorageEdge provides precisely such a blob caching facility. It offers a unique combination of externalization and BLOB caching for effective blob management and access from a single interface. It makes use of NCache® technology to let you cache frequently used BLOBs in a distributed fashion with high availability, complete replication and failover. A distributed cache can give your SharePoint infrastructure a significant scalability boost because it keeps things distributed across multiple servers and still giving one logical view. But the cache actually lives on multiple servers and that’s what allows the cache to really scale.

NCache based caching in StorageEdge can be enabled using pretty inexpensive hardware. As a local cache on a WFE server, memory requirement is only 500 MB. For larger SharePoint install-base with BLOB size close to 10 TBs or more having 4-6 WFEs, caching can be plugged in using 02 inexpensive cache servers. In-memory cache is much faster than the disk based SharePoint BLOB cache that SharePoint provides.

Configuring SharePoint Blob Cache in StorageEdge

Configuring SharePoint Blob Cache in StorageEdge

Figure 1: Configuring SharePoint Blob Cache in StorageEdge

Here are some of the things you can do with SharePoint BLOB caching:

• Keep a subset of SharePoint BLOBs in client cache on WFE servers
• Specify max cache size and evict some BLOBs when cache is full
• Keep BLOBs fresh by expiring them in the cache
• Keep cache light by removing unreferenced BLOBs from cache
• Manage all SharePoint BLOB caching from a centralized web based admin app
• Monitor SharePoint BLOB cache activity in PerfMon

Download StorageEdge | StorageEdge Details

Posted in Blob Cache, BLOB Externalization, SharePoint Blob Caching, SharePoint Performance | Tagged , , | 1 Comment

Backup and Restore of SharePoint Elements: Order is the Key

Taking regular backups of SharePoint is an important aspect of SharePoint Administration as the granular recovery of the SharePoint items is a core part of an administrator’s job. The backup and recovery challenges which accompany the growing volume of SharePoint data demand that the administrators externalize the BLOB data.

The separation of content database from BLOBs means you have distinct, independent elements which are needed to be backed up. Content database resides in SQL Server. BLOB index, which the StorageEdge maintains for the externalized blobs, exists either separately or within the content database. Similarly, the externalized BLOBS may be sitting on files, NAS, SAN or Cloud. So, you need to give serious consideration to the order in which you plan your backup of these distinct elements.

SharePoint performs two distinct operations on the BLOB items – Add and Delete. The Update is handled by SharePoint as an Add operation as it doesn’t overwrite the existing BLOBs. Let us analyze some of the scenarios, which you need to be aware of, which potentially might evolve during the course of backup vis-à-vis these operations and the order of the backup and impact on restore.

Optimize SharePoint Performance and Storage - Free Download

Consider a situation when new content is added and the externalized content is backed up first and the content database subsequently. In this scenario, StorageEdge will update the content database and the BLOB index with new entries but backup will not have the content in it. If this backup is restored, an inconsistency will occur since the content database and BLOB index will contain content entries that will not be present on the external storage. This will give rise to a dangling reference and generate a “file not found” type of errors when the item is requested within SharePoint.

Similarly, if an item is deleted from SharePoint when the BLOBs are being backed up first and the backup is in progress, the item might have already been backed up. On delete, the entry will be removed from the content database, the BLOB index of StorageEdge and from the physical storage as well. However, if this backup is restored at some point in time, the deleted BLOB will be restored but it will not have a corresponding entry in the BLOB index of StorageEdge as well as the content database. Such deleted content will also not show up in SharePoint. However, it will reside as an Orphan BLOB on the external storage. Such repeated backups and restores may produce a large number of orphan blobs occupying storage unnecessarily.

So, whenever you backup the content externalized using StorageEdge, it is important that you backup the content database and the BLOB index first before the BLOB store to avoid data inconsistencies. Similarly, the restore must take place in the reverse order. This is essential to avoid potential inconsistencies.

SharePoint back up and restore

SharePoint back up and restore

 Figure 1: Right Order of Backup with Externalization Using StorageEdge

The garbage cleaner of StorageEdge helps you tackle the issues of dangling references and the orphan BLOBs. But you still need to be mindful of the fact that when you externalize your BLOBs, the order in which you backup/restore various SharePoint elements is crucial. Otherwise you might end up with dangling references and orphan BLOBS.

Download StorageEdge | StorageEdge Details

Posted in BLOB Externalization, Multi-Tier Storage, SharePoint Archiving, SharePoint Backup, SharePoint Backup and Recovery, SharePoint Storage | Tagged , , , , | Leave a comment

SharePoint Backup and Recovery: From troubles to bliss

With ever-increasing number of documents added to SharePoint repositories, one challenge seems to be growing and that is the amount of time it takes to complete SharePoint backups. Larger SharePoint databases due to BLOB storage in them are resulting in longer and longer running backups that never seem to finish. And, this is causing performance-loss, inefficient resource usage, increased likelihood of data-loss and failure to meet SLA commitments of SharePoint backup/recovery windows.

I receive complains from SharePoint administrators that many times they have to recover documents that users accidently deleted and they have also been removed from the Recycle Bin. Although SharePoint comes with a set of native tools for recovery, these tools usually don’t help much as none of them provides a very granular level of recovery.

Optimize SharePoint Performance and Storage - Free Download

One such tool is STSAdm for SharePoint backup. Its granularity is low and can be CPU intensive. As a result, Microsoft doesn’t recommend using it for large SharePoint backups. Another is “SharePoint Central Administration Backup/Restore”. It can help you protect content databases and associated search/index files. However, it cannot run backups on schedule. Further, it doesn’t allow retrieving subset of backup data and forces you to restore the entire content database. Microsoft doesn’t recommend using either of these tools for content databases larger than 100 GB and specially STSAdm for site collections larger than 15 GB.

Additionally, SharePoint administrators can use SQL Server database tools and techniques for reliable and timely backup/recovery, but they too have their own limitations.

Firstly, SharePoint by-default creates a single data-file for content database. And the BLOBs it stores in the database eventually grow to terabytes. But, they are all stored in one database file unless data-file is manually partitioned. A data-file of more than 200 GB is not recommended by Microsoft, as their backup usually results in a performance hit, exceeds the backup window and needs larger storage. It introduces an element of periodic maintenance too.

Secondly, content databases by design cannot span multiple file-groups; hence the option of parallel backups of file-groups in SQL Server cannot be exploited.

Resultantly, the available tools may assist the administrators with elementary SharePoint backup/recovery at best at certain costs. The question arises how long can you wait for your administrator to find/restore a lost document — minutes, hours, or days?

StorageEdge provides an out-of-the-box solution to overcome SharePoint backup/recovery troubles. By taking charge of your BLOBs and moving them out of database, it effectively addresses the root-cause of SharePoint backup concerns.



Figure 1: Configuring Storage Tiers in StorageEdge for BLOB storage

StorageEdge ensures the management of these BLOBS including their backup/recovery through the following:

• Simplified SharePoint backup/recovery – With fewer, smaller content databases, the SharePoint backup tools work like a charm.
• Externalizing BLOBs to different storage tiers such as SAN or NAS, administrators exploit the built-in features of these hardware.
• Letting the administrators configure the Recycle Bins to hold items for unlimited periods without fear of increasing database size makes self-recovery of documents possible.
• SQL Server is not the right place for your BLOBs. StorageEdge takes them to where they belong – File system, SAN, NAS or Cloud.
• Facilities such as policy-based storage tiers, compression and encryption not only reduce SharePoint backup/recovery times but also help you save on overall storage costs.

Download StorageEdge | StorageEdge Details

Posted in Multi-Tier Storage, SharePoint Archiving, SharePoint Backup, SharePoint Backup and Recovery, SharePoint Storage | Tagged , , , , | 1 Comment

Use SharePoint Storage Wisely by Externalizing BLOBs

SQL Server is a great database but like all other relational databases, it wasn’t designed to store BLOBs. And ironically SQL Server is the main SharePoint storage even though a large portion of SharePoint data is documents that are stored as BLOBs in SQL Server. And, this causes issues with SQL Server.

First, as the database size grows beyond 200 GB, SQL Server performance degrades considerably which results in a poorly-responsive SharePoint. Some people have even reported this degradation after 50 GB of database size. Either way, as you know, SharePoint can easily cross both of these limits and in fact get into TB’s of data.

Second, storing all the BLOBs in SQL Server is not very cost effective because SQL Server storage is typically very expensive. So, storing TB’s of data in that expensive storage can quickly become prohibitively expensive.

And, finally, if you have a really large database size, doing backup and restore becomes very challenging and slow. Many customers have complained that they cannot meet their backup restore SLA requirements with large SharePoint configurations.

The answer to all of this is to use StorageEdge. First, it will let you reduce the database size by externalizing all the BLOBs. StorageEdge moves the BLOBs to an external storage whether it is file system, SAN, NAS, or Cloud storage. StorageEdge does this either through EBS or RBS.

Optimize SharePoint Performance and Storage - Free Download

Another thing that StorageEdge would do is let you use multiple SharePoint storage tiers along with archiving feature. This way, you can keep the most active documents in the most expensive SharePoint storage tier and move less active or older documents to cheaper SharePoint storage tiers. This will reduce your SharePoint storage cost dramatically. StorageEdge lets you archive your content based on various policies. It lets you move your content from one type of storage tier to another in real time, without any downtime or decline in performance.

And, when your documents are kept outside of the database, doing backup and restore also becomes much simpler. This will reduce your back and restore time and allow you to meet your SLA requirements.

Use Storage Wisely - Externalize BLOBs

Use Storage Wisely - Externalize BLOBs

Figure 1 : StorageEdge Rids you of BLOB Mgmt Tasks by Managing SharePoint Storage

 In a nutshell, externalizing BLOBs from SharePoint is not an option; rather it is a necessity for the best use of your storage and for SharePoint deployment to perform. StorageEdge lets you achieve that with an absolute ease.

Download StorageEdge | StorageEdge Details  

Posted in BLOB Externalization, Multi-Tier Storage, SharePoint RBS, SharePoint Storage | Tagged , , , , , , , , | 1 Comment

External vs. Remote BLOB Storage

In my various blog posts on SharePoint Storage I have highlighted the fact that SQL Server is not the right place to carry heavy payload of SharePoint unstructured data called BLOBs. This is because the BLOB storage in SQL Server is bound to hamper the performance of a SharePoint infrastructure. So, as a strategy Microsoft first introduced External BLOB Storage (EBS) in SharePoint 2007 SP1 through COM interface and then later in SharePoint 2010 provided another approach for externalizing the blobs through Remote BLOB Storage (RBS).    

An RBS provider offloads all the BLOB content being pushed to SQL Server whereas an EBS Provider gives an opportunity to offload the BLOB and passes an ID to SharePoint to keep track of it. The primary purpose of both is to rid your SQL Server of the BLOB content and move it to inexpensive media. StorageEdge lets you connect your SharePoint with external storage locations through these providers.    

Optimize SharePoint Performance and Storage - Free Download

People often tend to confuse EBS and RBS. Following shall bring out salient aspects of both.   

SharePoint EBS Provider vs Remote Blob Storage Provider  

  1. Remote blob storage is implemented in SQL Server 2008 R2 and has no direct relation to SharePoint. On the other hand, EBS has been provided as a layer in the MOSS 2007 stack at a level where it talks to SQL Server.

External vs Remote BLOB Storage

External vs Remote BLOB Storage

  Figure 1: How External Blob Storage and Remote Blob Storage Works    

2.   EBS (External Blob Storage) has a SharePoint farm-wide applicability whereas the RBS provider library can be associated with each individual content database.    

3.   Remote Blob Storage is not unique to SharePoint only as it is available to any application using SQL Server, whereas EBS is SharePoint specific.    

4.   Remote Blob Storage provider can be associated at content database level whereas EBS has a farm-wide applicability.    

Having said so, there are certain pros and cons of both the approaches. Some of the important ones are:    

Pros and cons of EBS and Remote Blob Storage Providers    

  1. While EBS is part of SharePoint stack, it can take ownership of the BLOB as it has the context information of the BLOB and changes/deletes on it can be tracked through SharePoint. RBS has lesser context information of the BLOB being externalized; the metadata information has to be stored out of SQL Server. 
  2. In case of EBS, every request either related or not must have to go through EBS whereas RBS only receives the relevant traffic. 
  3. Remote Blob Storage has managed interface whereas EBS is unmanaged COM interface which might create a slight performance overhead. 
  4. Though not certain, but it is likely that RBS might have more performance, as it is likely that EBS will fade out over time.

 The pros and cons of both the approaches suggests that you need a tool that works as an integral part of SharePoint installation, provides reliable providers for both EBS and RBS for externalizing your blob content   

 StorageEdge provides both EBS and RBS providers for SAN, NAS and Cloud storage and helps you reduce your SharePoint content database size up to 95%. StorageEdge gives you great control over the blob externalization where you can externalize blobs based on certain criteria and organize them in various folder structures. StorageEdge keeps the content database and the externalize content synchronized and provides full management for orphan content. It also helps you migrate from EBS to RBS. Furthermore, it allows for hierarchical multi-tiered storage such as local storage, NAS and SANs. 

Thus, in the debate of EBS vs. RBS, none is a clear winner. Though RBS seems likely to stay longer, EBS does have an existence for now. In any case, StorageEdge is the solution to help you leverage benefits of both while allowing you to switch between the two in case you wish to and providing you at the same time with much more than a simple provider.   

Download StorageEdge | StorageEdge Details  

Posted in BLOB Externalization, SharePoint RBS, SharePoint Storage | Tagged , , , , , | Leave a comment