SQL Server 2008 : Storage system sizing - Selecting an appropriate storage system

1. Direct-attached storage

Of the three storage options presented in this section, DAS is the most established and is used in a large percentage of SQL Server systems of varying size and usage profiles. As the name suggests, DAS systems connect disks directly to a server, either internally within the server itself or in external storage cabinets filled with disks connected to the server via controller cards.

Correctly configured DAS systems can rival or even exceed the I/O performance obtained with SANs. Using multiple external disk enclosures, you can build DAS systems containing hundreds of disks, and when these systems are connected to multiple controllers, the I/O performance that can be achieved is capable of servicing the most demanding workloads.

Unlike SANs, DAS systems don't rely on expensive storage infrastructure. As such, initial DAS costs tend to be much lower than SANs. On the downside, organizations with lots of DAS-configured servers may find that combined disk utilization levels and management overhead actually raise the cost above that of a SAN. Further, unlike SANs, DAS systems have limited disaster recovery options.

2. Fibre Channel SANs

Fibre Channel SANs are self-contained disk systems containing hundreds or even thousands of disks. Unlike DAS systems, which are connected to a single server, multiple servers can connect to a SAN, as shown in figure 1, via special host bus adapter (HBA) cards installed in each connected server. Disks within the SAN are grouped together into logical unit numbers (LUNs) and presented as required to connected servers. The server sees the LUN as a locally attached disk.

Figure 1. A typical storage area network. In this example, four servers connect to the SAN via their own internal HBA cards and a dedicated switch.
 

While expensive to set up initially, SANs provide increased disk usage efficiency, simplify storage management and allocation, and when configured correctly, can provide exceptional I/O performance for SQL Server platforms. Furthermore, SAN cache capacity, often running into hundreds of gigabytes, is far superior to that found in most DAS systems.

Depending on the vendor and model, SANs also offer superior disaster-recovery options. Examples of this include synchronously replicating LUN data to another SAN at a remote site and leveraging SQL Server's Virtual Device Interface (VDI) to enable near-instant database backup and restores by "snapping" locally mirrored LUNs.

On the downside, SANs are often configured for disk usage efficiency at the expense of maximizing performance. When you configure a SQL Server storage system for maximum performance, data is spread across as many dedicated physical disks as possible, often resulting in each disk having a low utilization percentage. One of the major benefits of a SAN is sharing disks among many servers to maximize usage. These are conflicting goals and, unless well understood, often lead to poor SQL Server performance. As a result, some organizations dedicate an entire SAN to a single, mission-critical database, thereby obtaining the best performance, while also benefiting from the scale and disaster-recovery options of SAN solutions.

Performance testing of SAN solutions needs to be conducted taking into account the impact from other connected servers, particularly if they're using LUNs sharing the same disks. As a result, performance testing in a SAN environment tends to be more complex compared to DAS.

These issues will be explained in further detail in the next section. For now, suffice to say that the correct configuration of a SAN is crucial in delivering high storage performance to SQL Server.

3. iSCSI

Apart from DAS, lower-cost alternatives to Fibre Channel SANs include network-attached storage (NAS) and iSCSI. NAS systems aren't recommended for use with SQL Server as some of them can't guarantee the write ordering that SQL Server requires in maintaining data integrity. Internet SCSI (iSCSI) SANs are recommended instead of NAS.

iSCSI is the name given to a network protocol that carries SCSI commands over a TCP/IP network. iSCSI SANs are similar to Fibre Channel SANs in that they're independent of the servers connected to them. Unlike a Fibre Channel SAN, servers connect to iSCSI systems over a standard TCP/IP infrastructure.

Best practice dictates connecting servers to the iSCSI SAN over a dedicated 1- or 10GB network physically separate from the main network. This involves dedicated switches and servers with multiple network cards, or separate iSCSI HBA cards, to connect to both the public network and the dedicated iSCSI network. The physical separation of networks enables the best I/O performance and reliability. Further, the connections to the iSCSI SAN should ideally be set up using dual network cards in a teaming arrangement.

Given the TCP/IP-centric nature of iSCSI, the components required to connect servers to iSCSI SANs are typically less expensive than the components used for Fibre Channel SANs. Standard network cards can be used to connect to the iSCSI SAN with software components (such as the Microsoft iSCSI Software Initiator), enabling the iSCSI support. Alternatively, dedicated iSCSI HBA cards can be used to offload iSCSI processing from the CPU and improve I/O throughput while reducing system overhead.

iSCSI SANs are becoming increasingly popular due to the lower cost of entry compared to the Fibre alternative, and the ease with which a storage network can be established. The systems used for this installation are all virtualized, including a virtualized iSCSI host server. Both cluster nodes use the host for storage purposes via Rocket Division's StarWind iSCSI software.

Table 1 compares and contrasts the features and attributes of the three storage systems we've just covered. TCO (total cost of ownership) assumes a medium-to-large data center. DR options refers to the built-in ability of the storage system to offer block replication, snapshot backups, and other useful disaster-recovery features. Scale refers to the number of disks that can be stored within the system. DBA control refers to the ability of a DBA to quickly configure a storage system to precise requirements.

4. Recommendations

Compared to DAS, commonly used SAN solutions offer superior disaster-recovery options, and TCO is typically lower with SAN solutions for medium-to-large enterprises.

In most cases, either DAS or Fibre/iSCSI SANs can be configured to deliver the required performance. One advantage DAS systems have over SANs is DBA control. It's much easier for a DBA to configure DAS to meet precise performance requirements than it is to request a specific configuration from the SAN administrator who has to take into account numerous other servers sharing the same SAN.

Perhaps the deciding factor in choosing a storage system is the required number of disks they must support. Earlier we focused on determining the number of disks required to support a specific workload. If the number runs into the hundreds or thousands, then SAN solutions are the clear choice, particularly considering the disaster-recovery options they provide. For smaller disk numbers, either DAS or SANs are valid options, but the overall cost, management, and disaster-recovery options should be considered before making a decision.

It's not uncommon for the storage system validation process to be skipped when SQL Server is installed on a SAN. This is often due to DBAs not having the same degree of control over the SAN as they would over DAS. The next section explores the importance of a good working relationship between the DBA and the SAN administrator in ensuring the required performance of SQL Server deployments involving SAN storage.