Intelligently Reducing SharePoint Costs through Storage

Intelligently Reducing SharePoint Costs through Storage

 

Intelligently Reducing SharePoint Costs through Storage Optimization        Don Jones

 

We might also want to implement some kind of tiered storage, so that older, less‐used data  can be moved to less‐expensive storage but still remain generally accessible. We might  need to observe data‐retention policies, too, and it’s possible an “outsourced” storage  mechanism can address that. This is actually a bigger topic than just offloading BLOB data,  and I’ll spend all of Chapter 4 exploring it. 

The Solution: Move the BLOBs 

Ultimately, what we want to do is get the BLOBs out of the SQL Server database. That’ll  reduce the size of the database, which will help improve its performance. Of course, we  need to do so in a way that still keeps the content entirely visible to SharePoint so that all of  its features—alerts, workflow, versioning, metadata, security, and so forth—still work for  us. There are two basic approaches to BLOB offloading: External BLOB Storage (EBS) and 

Remote BLOB Storage (RBS). 

EBS 

EBS was introduced with the previous version of SharePoint. It’s a SharePoint‐specific  feature; it’s not generic to SQL Server. Essentially, EBS was the SharePoint product team’s  way of addressing the BLOB problem without specific help from the SQL Server tea m. 

By the way, you should know that EBS is deprecated in SharePoint 2010, meaning 

Microsoft doesn’t plan to pursue the technology. Instead, they’re pushing for RBS, which I’ll  discuss next. However, it’s still useful to understand what EBS is and how it works. 

How It Works 

EBS basically provides a secondary storage mechanism within SharePoint: You still use SQL 

Server to store structured data, but those unstructured large items are directed to a  different storage mechanism. A Component Object Model (COM) interface coordinates the  two. EBS is an extensibility point; both Microsoft and third parties can supply you with EBS  providers, and the provider makes the connection between SharePoint’s EBS layer (that 

COM interface) and the actual external storage mechanism. Figure 2.7 illustrates how EBS  is built. 

  25

 

Intelligently Reducing SharePoint Costs through Storage Optimization        Don Jones

 

 

 

Figure 2.7: SharePoint EBS. 

As you can see, structured data is still stored in SQL Server in the normal fashion; BLOB  data is redirected at the SharePoint source through the EBS interface. 

Pros 

Obviously, the “pro” is that EBS gets BLOB content out of the SQL Server database, reducing  its size and helping to improve its performance. EBS can work with any version of SQL 

Server supported by SharePoint, so you don’t need to be on the latest versions of  everything in order to use it. 

Cons 

EBS isn’t the most sophisticated technology. For example, it doesn’t automatically  overwrite old BLOBs. If you update a file attachment, EBS creates a new store item, and  redirects all of the structured SharePoint data—metadata and the like—toward the new  item. Whoever wrote the EBS provider is responsible for cleaning up the now‐orphaned 

“old” data item. In practice, Microsoft says most EBS providers will put that off until some  scheduled “garbage collection” time, when orphaned BLOB data will be cleaned  up. 

EBS doesn’t integrate with SQL Server directly, meaning SQL Server’s internal  backup/recovery mechanisms, log shipping, replication, and so forth are unaware that 

BLOB offloading is happening. That adds a layer of complexity to these operations. 

26

 

 

Intelligently Reducing SharePoint Costs through Storage Optimization        Don Jones

 

EBS was always intended as a kind of stopgap solution; even when introducing it, the 

SharePoint team knew that something better would be on the way—and they did not  design EBS to migrate to that better way (which turns out to be RBS, which I’ll cover next). 

That said, some third parties can help migrate from EBS to RBS, and many third‐party EBS  providers have RBS equivalents, so you can often stay with the same storage vendor. 

If you add EBS to an existing SharePoint installation, it won’t convert existing BLOBs over  to the new EBS storage; you’ll have to do that manually—for example, by creating a new 

SharePoint site that uses EBS, then restoring your existing SharePoint data to that new site. 

Not exactly painless; some third parties may offer tools to help automate the process and  make it less painful. 

RBS 

This is a technology implemented entirely by SQL Server (2008 and later); SharePoint has  no clue that it’s there or working, nor would any other application. You don’t configure 

SharePoint at all—you simply enable this in SQL Server. Applications can be made RBS‐ aware, though (SharePoint is one such application), and those applications can make even  more efficient use of RBS. 

How It Works 

RBS is designed as an extensible mechanism. To use it, you need an RBS provider, which is  what actually handles dealing with the BLOBs on behalf of SQL Server. Microsoft ships a  default provider, the FILESTREAM provider, that utilizes the new FILESTREAM data type in 

SQL Server’s 2008 R2 Feature Pack. 

Essentially, the FILESTREAM data type is something you assign to a column in a table. That  is, instead of declaring the column as a varbinary() type, you add the FILESTREAM  attribute to the varbinary() column. SQL Server then automatically writes the BLOB data to  the file system rather than into the database. You still use SQL Server to add and retrieve 

BLOB data; all that’s changed is where SQL Server physically stores it. Using a simple 

FILESTREAM column doesn’t change the way you do backup and recovery, in fact; SQL 

Server “knows” about FILESTREAM columns and integrates them into the backup  processes. They even work within SQL Server’s security model and are fully supported by  transactions. Figure 2.8 shows how it works: Essentially, the FILESTREAM type tells SQL 

Server to split out the BLOB data into normal files on the file system. 

27

 

Intelligently Reducing SharePoint Costs through Storage Optimization        Don Jones

 

 

Figure 2.8: How the FILESTREAM type works. 

Developers can choose to use a different technique to access BLOB data, which involves  using Win32 streaming application programming interfaces (APIs), essentially meaning  they can access the externally‐stored files directly through a shared folder—taking some of  the burden off SQL Server and instead using the Windows file system—which is really,  really good at handling files. That does require a programming change in the application,  but it can improve performance pretty significantly. Figure 2.9 shows how this works: The  application, in this case, needs to do a little bit of extra work because it needs to access two  data stores in order to deal with BLOBs. It isn’t a massive undertaking from a programming  perspective, but it isn’t as transparent as just letting SQL Server do the work. However, SQL 

Server isn’t a file system, so the extra programming work is generally rewarded by  improved application performance. SharePoint doesn’t necessarily use this approach;  instead, you’ll typically see it using RBS—which itself can use FILESTREAM. 

  28

 

Intelligently Reducing SharePoint Costs through Storage Optimization        Don Jones

 

 

 

Figure 2.9: FILESTREAM­aware applications. 

The trick with the default FILESTREAM implementation is that it can only store data on the  local disks available to the SQL Server computer. Some SQL Server features—such as  transparent encryption—won’t work for FILESTREAM data. Tables containing 

FILESTREAM data can’t be used in database snapshots or in database mirroring (although  log shipping is supported). 

As I said, SharePoint doesn’t necessarily use FILESTREAM types directly. The next level up  is the RBS API, which is what SharePoint 2010 does normally use. RBS recognizes that some  companies have developed BLOB‐specific storage systems, and RBS provides a way to  offload BLOB data to those. RBS retains full awareness of the BLOB. That is, if you delete a  row, SQL Server will delete the corresponding BLOB data even though it’s stored  elsewhere. RBS also doesn’t provide quite the same level of data consistency that you get  when storing BLOBs directly in the database or by using the normal FILESTREAM type. 

Figure 2.10 illustrates one way in which this can work. Note that in this example, 

SharePoint has been modified (there’s a downloadable RBS component for it) to explicitly  use RBS. 

29

 

Intelligently Reducing SharePoint Costs through Storage Optimization        Don Jones

 

 

Figure 2.10: SharePoint and RBS. 

Figure 2.10 is a bit of a simplification; the actual stack of components is a bit more  complicated, but this illustrates the general idea. For completeness’ sake, I should also note  that RBS doesn’t always require that an application be aware of it. It’s something that can  operate solely within SQL Server, as shown in Figure 2.11. 

  30

 

Intelligently Reducing SharePoint Costs through Storage Optimization        Don Jones

 

 

 

Figure 2.11: Transparent RBS. 

Microsoft’s general intention is that providers of BLOB stores—that is, vendors—will write 

RBS‐compatible providers that tell SQL Server how to talk to that vendor’s BLOB store. 

Microsoft offers an RBS provider that simply utilizes the FILESTREAM type, so you can get  a basic RBS setup running out of the box (with SQL Server 2008 R2, at least). Essentially,  what you do is create a new database in SQL Server that will be your “BLOB Store.” You  configure RBS on your SharePoint database to offload BLOBs to that BLOB Store; the BLOB 

Store in turn is set up to use the FILESTREAM type to push the BLOB data to disk. So the 

BLOB store winds up being nothing more than pointers to the actual BLOB data; the 

SharePoint database, in turn, contains pointers to the BLOB Store. Figure 2.12 shows how  this all fits together. 

31

 

Intelligently Reducing SharePoint Costs through Storage Optimization        Don Jones

 

 

 

Figure 2.12: Microsoft’s FILESTREAM RBS provider. 

Again, all of this happens locally on the SQL Server—the files must be on the same physical  machine as the BLOB database when using Microsoft’s FILESTREAM RBS provider. 

Pros 

Obviously, the big advantage here is reducing your SQL Server database size—by as much  as 90 to 95% in some instances I’ve seen. That’s huge for maintaining SQL Server’s  efficiency as well as giving you a bit more flexibility in the backup and recovery  department. Using strictly the Microsoft‐offered FILESTREAM provider, however, does  limit your flexibility: You’re still stuck with only local storage, and there are complex  interactions with other SQL Server features. 

RBS is definitely the “way forward” for both SQL Server and SharePoint. Using RBS will  provide a longer future for you than EBS will. 

32

 

 

Intelligently Reducing SharePoint Costs through Storage Optimization        Don Jones

 

Cons 

RBS obviously creates a somewhat more complex environment. Although normal SQL 

Server backups can work transparently, third‐party backups may or may not work with 

RBS, depending on their exact approach—so it’s something to investigate. 

Not every RBS approach is created equal. You explicitly need to ensure that offloaded data  can still contain metadata, still be indexed for searching, still be managed by SharePoint  and its security rules, and so forth. You might want to offload different types of data to  different locations, and the RBS provider would need to offer that kind of filtering  functionality; if you just want to offload everything, you can likely use a simpler RBS  provider. 

Finally, RBS does require the latest versions of SQL Server and SharePoint. Thus, if you’re  stuck using older versions with no chance of upgrading, this might not be an option for you. 

Third‐Party Approaches 

Many third parties are now offering their own RBS providers, as RBS is the officially‐ supported BLOB offloading mechanism. SharePoint only needs to understand that “RBS is  in use;” it doesn’t care what’s actually handling the BLOBs in the background. 

How It Works 

Third parties can either write an RBS provider that is installed on SQL Server or even tap  into the EBS architecture used by older versions of SharePoint. If you’re in a mixed‐version  environment, an extender that can use either RBS or EBS might be desirable. 

Added Flexibility 

Third‐party RBS providers can provide much faster BLOB offloading and can take more  load off SQL Server. Keep in mind that the RBS FILESTREAM provider still places a load on 

SQL Server because SQL Server has to process the BLOBs into and off of the file system. 

Third‐party providers can also offer other features: 

• Offload to remote storage (such as a network‐attached store or even to cloud  storage) 

• Cache BLOB data for transmission to off‐premises storage (such as a cloud‐based  backup) 

• Spread BLOB data across multiple storage locations, potentially storing different  types of data in different places—Figure 2.13 shows one way in which that might  work, with files of different categories (perhaps defined by SharePoint metadata)  are offloaded to different storage mechanisms 

33

 

Intelligently Reducing SharePoint Costs through Storage Optimization        Don Jones

 

 

 

Figure 2.13: Offloading data to different locations. 

• Add secure deletion (erasing) to the BLOB deletion process to help comply with  security requirements 

• Compress and/or encrypt BLOB data—something that the native FILESTREAM  provider cannot do 

• Work with hierarchical storage mechanisms for tiered storage, enabling you to  migrate older content (for example) into near‐line storage; note that some vendors  may implement this kind of functionality as a discrete product that works in  conjunction with a separate RBS provider, while others may build the functionality  into an RBS provider 

• Transparently ensure that SharePoint can access BLOB data for search indexing 

34

Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement

Table of contents