Best Practices for Implementing SharePoint on a SAN

Technology is a funny thing. It can accomplish amazing, unimaginable feats—and then make you numb to them. I distinctly remember the first time I saw ademonstration of RAID 5. A colleague pulled a drive out of a running server . . . and it kept running! I was flabbergasted that it actually worked.Fortunately, being in the technology industry, I get to periodically experience these "Oh wow!" moments. It's part of why I love my job so much.

SANs are another example of technological magic. SANs allow us to pool storage in central locations, and then dole it out to individual servers, asneeded. In this article, I cover how we can intelligently and responsibly use SANs in Microsoft SharePoint environments. Because SharePoint employs acomplicated infrastructure, I also discuss how you can use SANs with supporting technologies such as Microsoft SQL Server and virtualization hosts. Bythe end of this article, you'll have a good understanding of how SANs work with SharePoint and its friends, as well as how best to use the technologyin your production environments.

Some SAN Basics

At a basic, physical level, a SAN is a box the size of a refrigerator, filled with hard disks. (Blinking lights everywhere; it can be quite soothingsometimes.) These disks can be carved into an infinite number of combinations, using every RAID level we've ever heard of, and even a couple wehaven't. These combinations (called logical unit numbers-LUNs) are presented to servers and appear as local storage.

This approach provides many benefits. It allows us to centralize storage, making it easier to get a snapshot of our storage usage and needs. It alsogives us the flexibility of adding storage to our servers without doing the "RAID drive shuffle" each time we want to expand the storage. SANs alsoprovide additional disaster recovery options. Most SANs support mirroring drives within the SAN, and many offer the ability to mirror the drives toanother SAN enclosure.

In some cases, SAN storage can be faster than the DAS that might come with a server. SANs are highly tuned devices and routinely have many gigabytes ofcache, which can result in very good performance.

A word of caution about performance is due here. To many of us, SANs are magic boxes that provide bountiful storage and unlimited performance. Weassume they're configured correctly and that they will be fast. That isn't always a correct assumption.

Those shelves and shelves of hard disks in the SAN don't configure themselves. Someone needs to go in and decide how to best group those disks for theapplication for which they'll be used. File servers are happy enough with RAID 5; SQL Server transaction logs perform best with mirroring, or RAID 1.However, just because we're running a SQL Server doesn't mean that the LUN we're using for the transaction logs must be RAID 1. We might have differenttiers of the same type of application: For example, one SQL Server instance might have the databases for an application that requires speed, whereasanother might store the databases for a rarely used legacy application and so can use slower, less-expensive storage. Knowing the type of load and theI/O performance that it requires is an important part of working with your storage team to make sure your needs are met.

To illustrate this point, imagine a SAN shelf with ten 300GB disks. These disks can be carved up and exposed in different ways, each having an effecton their performance. For instance, those ten disks can be configured as RAID 6, which means that two drives are used for parity, and the availablestorage is (n-2) ´ drive size (in our case, 8 ´ 300GB = 2.4TB). This 2.4TB of storage can be exposed as a single LUN or split into smallerLUNs. The server consuming that LUN or LUNs has no idea how it's configured on the back end. RAID 6 has good read performance but poor writeperformance because the parity bits must be calculated before the data can be written. That configuration is a bad fit for SQL Server transaction logs,which benefit from fast write times.

On the other end of the spectrum, those same ten 300GB drives could be configured as a RAID 1 mirror, providing 1.5TB of storage. This LUN would havemuch better write performance than the previous example, but it provides less storage. Same SAN, same disks-radically different experience for theserver consuming those disks.

SharePoint on a SAN

When it comes to disk usage, SharePoint is a bit like a younger sibling. It doesn't use much I/O itself; it talks its siblings into doing all the heavylifting (and taking all the blame). The Microsoft article "Capacity management and sizing overview for SharePoint Server 2010"doesn't even discuss the I/O that's needed for SharePoint Server 2010, only for SQL Server. Thisarticle assumes that any hard disks you can scrape together to host SharePoint will be more than sufficient for the program's modest demands. For themost part, this assumption is correct. If you have a SAN, though, you can leverage it to make SharePoint a little easier to manage and to tweakSharePoint's performance.

From a management standpoint, SANs make it easy to adjust the size and number of SharePoint's hard disks. According to the Microsoft article "Hardwareand software requirements (SharePoint Server 2010)," ,SharePoint's only disk requirement is an 80GBsystem drive.

SharePoint itself doesn't need much disk space: It uses about 1GB, excluding logs, search index files, and any custom solutions. But that disk alsoneeds to hold Windows and all its associated patches for the next few years. And the disk needs enough space for SharePoint's logs, plus enough spaceto perform a memory dump in the unlikely event of a problem. Also, NTFS gets fussy when disks are more than 90-percent full, so leave enough space forsome overhead, too.

SharePoint requires at least 80GB, but sometimes that isn't enough. If a SAN is hosting your SharePoint drives, expanding that 80GB system drive to,say, 120GB is painless. The SAN administrators turn a few knobs, pull a few levers, and Windows thinks it has a 120GB physical disk. A quick trip toDisk Manager, and your server now has 40GB more storage. Try that with a physical hard disk.

Performance is another area in which proper use of a SAN can help SharePoint. For the most part, SharePoint is understanding when it comes toperformance, and its demands aren't very . . . well, demanding. SharePoint needs little to read from the local disk, and what it does need, it loadsand caches. Still, disk performance can improve users' experience with SharePoint in a couple places: BLOB caching and search. Let's start bydiscussing BLOB caching.

BLOB Cache

In the context of SharePoint, BLOBs are files such as JPGs, GIFs, and MP3s. Large binary objects such as these don't change very often, so they'regreat candidates for caching. And because their size is usually large compared with the page size, they benefit the most from the process.

BLOB caching is a function of Microsoft IIS and is configured in each web application's web.config file (usually located inC:inetpubwwwrootwssvirtualdirectories). Because wading through line after line of XML to make changes isn't for the faint of heart, SharePointmakes it easy for us to take advantage of BLOB caching. When SharePoint creates a web application, the program puts all the settings needed for BLOBcaching in each web.config file-but doesn't turn on BLOB caching. How very thoughtful! To take advantage of BLOB caching, you need only find therelevant line in web.config and change the enabled value from false to true.

Figure 1 shows how the line looks before being altered. This figure is chock-full of good information, all of which Microsoft documents well. For thisarticle, we're interested only in the location and maxsize parameters. By default, the location is set to the C drive. That makessome sense, because every Windows computer under the sun has that drive. However, it's a good practice to move as much as possible off the C drive, andBLOB caching is no exception. The BLOB cache location should be a secondary drive. That's where our SAN comes into play.

 
Figure 1: Before enabling BLOB caching

The reason we're turning on caching in the first place is to improve performance for end users. Each time IIS can serve up a file locally instead ofpestering the back-end SQL Server instance, that file gets into the user's hands more quickly-which makes for happy users. By putting the BLOB cachelocation on a SAN drive that's configured for high performance, we can get that file to end users as quickly as possible. The maxsize parameterdictates how large (in gigabytes) this web application's BLOB can be. The default is 10GB. The larger the cache, the more things can be cached andretrieved quickly. Remember that this setting is per web application, so make sure to plan for enough space. You'll also need to edit the web.configfile for each web application on each server in your farm.

Search

SharePoint search can benefit the most from a high-performing SAN drive. Search has two primary roles: index and query. Both enjoy performanceimprovements from speedier I/O.

Index comes first. During indexing (and crawling, a related task), SharePoint scours itself and other configured content sources for the documents thatyou want to be discoverable in SharePoint. The files are crawled and then copied to the index server's RAM, where they're broken apart by an iFilter(not unlike a coconut on a rock), and all the words are listed. Those words are written to the index files on the index server's file system. Thefaster the index server can get those words out of its memory and onto its file system, the faster it can move on to the next file in its list. Thelarger your SharePoint farm gets, the more important crawl times are. A fast SAN drive on your index servers can reduce those times.

After your files have been indexed, they can be found by users. This is where the query servers come into play. As the index servers index files andwrite the information to their file system, that information is combined with the existing index files on the query servers. When a user searches for adocument in SharePoint, the query servers spring into action. They take the user's search term and compare it to the index files on their file system,looking for matches. As your farm grows larger, the number of documents the query server must slog through grows as well. User queries take longer andlonger. At some point, your users will become impatient as they wait for results. (And they'll spend that waiting time plotting ways to make sure thatthere's no Mountain Dew left in the cafeteria by the time you get there.) Putting the index files on a SAN drive with fast read performance reduces thetime that's needed for queries to run. (Your users will be happy, and your tummy can get all the sweet caffeinated deliciousness it requires.)

As with the BLOB cache mentioned earlier, getting the index files off the C drive and onto a secondary drive is the best approach. If your querycomponent is already configured to store its index files on the C drive, don't fret. The Search service deals well with change and happily lets youmove the index to a different drive at a moment's notice. To do so, edit the Search Service Application Topology in Central Administration. For each ofyour index partitions, edit the value in the Location of Index field. Figure 2 shows an example in which the location has been changed to theD drive, which is hopefully a super-fast SAN drive.

Figure 2: Moving the index files 

I recommend just changing the drive letter; don't get crazy with the path. Leave the index files in their usual path. Doing so makes it easier whendealing with material that refers to the files in the default location, and it'll make it easier for someone else to step into your shoes after you getthat big promotion or win the lottery. After you've changed the path, click OK and then click Apply Topology Changes.

Search is happy to move your index files for you, but it's in no rush to do so. The service's first concern is being able to respond to end-userrequests, so moving the index doesn't get its full attention. Depending on the size of your index, the move process could take a while. It's worth thewait, though. After your index files are on a blazing fast SAN drive, your users will no longer be plotting your demise.

Virtualization on a SAN

SharePoint relies pretty heavily on other technologies to render pages for your users. In some cases, those technologies can make use of a SAN.Virtualization is one example. These days, almost every SharePoint farm has at least one virtualized server. In many cases, the entire farm (test orproduction) is virtualized. Whether you use virtualization software from Microsoft, VMware, or Jim-Bob's Discount Virtualization, it all can benefitfrom speedy SAN drives-or suffer from poor decisions.

All major virtualization software suites support hosting guests on SAN drives. You should consider the purpose of a farm (i.e., development, test, orproduction) when deciding how to configure the SAN drives that host that farm. Development farms, for instance, can have all their drives carved fromthe same spindles because their performance isn't important. If the servers in the farm are slow, only the developers are affected, and honestly, I'mOK with that. (It teaches them patience.) Test farms might need a little better performance, so those servers should be hosted on better-performing SANdrives. Production farms, if they're virtualized and using SAN drives, should have the best-performing LUNs that the SAN can provide. Unfortunately,there's no good way for you, as the SharePoint administrator, to know how your LUNs are configured. You'll need to take your storage administrators'word for it. Don't be afraid to bribe them with gifts of candy and World of Warcraft figurines.

SQL Server on a SAN

If I've said it once, I've said it 100 times: "SharePoint gets all its performance from SQL Server." In the beginning of this article, I talked abouthow different SAN configurations affect performance. Nowhere is that more important than with SQL Server. Every document, every list item, every searchresult, and every user profile is delivered out of a SQL Server database. If those databases are on a slow drive, then SQL Server is slow. If SQLServer is slow, then no amount of configuration trickery or swearing can make SharePoint fast. SQL Server really is that important.

The Microsoft article "Storage and SQL Server Capacity Planning and Configuration (SharePoint Server 2010)" gives some guidance on which services rely heavily on SQL Server I/O and how to calculate the I/Ooperations per second (IOPS) that you'll need for SharePoint. Again, there's no way to determine the configuration of the SAN drives that SQL Server isusing. You can, however, use a tool such as the Microsoft SQLIO disk subsystem benchmark tool to determine the IOPS of the drives in the system. Youcan use this information to determine whether the drives are up to the task of supporting SharePoint. If they aren't, then you can work with yourstorage team to get the performance you need. (Although this article is about SAN drives, SQLIO works just as well with physical disks if you'recurious to see how they're performing as well.) You can download the tool from the Microsoft site.

The Magic of SAN

Any SharePoint administrator worth his or her salt knows that SharePoint is a complicated beast. It has its fingers in Windows, IIS, and SQL Server, toname a few places. Many of these aspects of SharePoint can benefit from the magic of a SAN. SharePoint can use a SAN to cache frequently used files orstore search index files. SharePoint servers can be virtualized on SAN drives, and SharePoint can use SQL Server databases that are stored on SANdrives. Regardless of how you leverage SANs for your SharePoint environment, keep your eyes on performance, and make sure to watch those blinkinglights at least once. They're mesmerizing.