Storage arrays are available in a wide spectrum of capacities and capabilities, and sorting through the options can be confusing. These guidelines can help you narrow down the type of storage array you need to house your SQL Server databases.
Snapshot methodologies. Snapshots work about the same in all storage arrays.The idea is to freeze all the blocks of data in a database and the structure of the data being captured at a point in time. Vendors use one of two basic methodologies for handling snapshots after data has been modified.The first methodology, which Figure A shows, is to leave the snapshot block alone and use a free block to write the modified block information. Of the two approaches, this is the more efficient because it requires only one block I/O operation to write the new block and one update to a pointer.
The second methodology is to copy the snapshot block to a free block, then overwrite the block that was just copied. This approach, which Figure B shows, is often called copy-on-write. Copy-on-write requires more data movement and overhead on the storage array's part than the first approach. In Figure B, block D is moved from the current block to a new block so that the new contents of D can be written to D's old location. Doing so requires three block I/Os and an update to a link, whereas the first approach requires only one block I/O.This difference becomes significant for disk performance as large numbers of blocks are updated.
Support for Fibre Channel and iSCSI on the same array. Consider buying a storage array that supports both Fibre Channel and iSCSI, so that you have the flexibility to switch from one to the other or implement both. (For example, you might want to use an iSCSI SAN for testing and development and use a Fibre Channel SAN for production.)
Ability to create, grow, and delete LUNs dynamically. Being able to create, grow, and delete LUNs without bringing a database down is a major benefit of putting the database on a SAN. If you need this capability, consider storage arrays that provide it.
Integration of snapshot backups with SQL Server. The process of taking a snapshot copy of your SQL Server database needs to be coordinated with your database and NTFS. Storage-array vendors can use Microsoft's SQL Server Virtual Backup Device Interface (VDI) API to accomplish this coordination. If the snapshot process isn't synchronized with NTFS and the database, the created snapshot might not be in a consistent state because either NTFS or the database might not have completely flushed pending writes from memory to the LUN.
A uniform storage OS as you scale up. You'd most likely want to start with a small storage array to test and validate the SAN's benefits before deploying it enterprise-wide. Look for a storage array that lets you grow without having to do a "forklift" upgrade or having to learn a new storage OS. Maintaining a consistent OS lets you upgrade your storage array as your needs grow, with a minimum of database downtime.
A transport mechanism to mirror data over the WAN to a recovery site. The storage array should provide a uniform transport method for sending mirrored data across the WAN to another storage array for disaster recovery purposes.
Ability to instantaneously create a writeable copy of your database. Look for storage arrays that let you instantaneously-create a writeable copy (i.e., clone) of your database for testing upgrades and large data loads without affecting the production-database. This feature could reduce outages and corruption of the production database, giving DBAs a tool to test major changes without endangering data.