While small and midsize organizations agonize over their servers and networks, many are surprised to find that their computer operations are more frequently slowed down, interrupted or endangered by their data storage configuration. This is not because the equipment is poorly made, but because of physical, geographic and device-specific restrictions common to storage hardware packaging.

openBENCH LABS SCENARIO

UNDER EXAMINATION Virtual disk server software for storage virtualization WHAT WE TESTED DataCore SANMelody Logical blocks are served from tiered storage pools that can be based on such characteristics as drive performance or data availability MMC Snap-in provides a unified single-pane-of-glass management for all storage resources Dynamic virtual disk pools support SAN-wide thin provisioning that only consumes disk blocks when non-zero data is written by an application IT is able to mix and match servers and storage to assemble an HA or DR infrastructure.    HOW WE TESTED (2) Dell PowerEdge 1900 Servers SANmelody SANmelody client utilities Windows 2003 Server SP2 IBM DS4100 FC-SATA storage array, Texas Memory Systems RamSan 400   Benchmark Iometer   KEY FINDINGS Full virtualization of direct attached and SAN-connected storage Simplified SAN infrastructure management through automation of storage administration tasks using the Windows MMC SANmelody caching boosted I/O throughput by 33 percent running Iometer Round-robin LUN distribution of server I/O traffic benchmarked at 50,000 IOPS Using 8KB Reads with no I/O Bottlenecks No single point of failure with support for snapshots, synchronous mirroring and a synchronous replication

SANmelody provides centralized disk virtualization software for small and midsize IT environments with up to 32TB of usable disk space. In the same way that other forms of virtualization improve on server hardware, the notion behind SANmelody is to make disk configurations fail-safe, go-fast, and waste-free. Via modular, capacity based licensing, SANmelody is able to cater to the budget constraints of an SMB site. Nonetheless, since SANmelody inherits all of its essential features from DataCore's large scale SANsymphony product, it can cater to an SMB environment without compromising on technology.

Installing SANmelody software on a general purpose x86 Windows server turns it into a virtual disk server. DataCore software may also run on virtual machines (VMs), alongside application servers housed in the same physical server. This creates a virtual shared storage SAN within the same enclosure.

Administrators interact with SANmelody via the Microsoft Management Console. The DataCore MMC Snap-in provides an extraordinary level of detail and sophisticated control of storage devices attached to the SANmelody server. An example of this capability can be found in the way that the MMC Snap-in dramatically simplifies the standard disk management utility. Utilizing the unique disk signature that Widows initially writes on a disk, the Snap-in identifies all of the duplicate devices that multiple SAN connections can present to a server. Then, it hides them from the Disk Management GUI, while at the same time providing exhaustive details in a new physical disk control view.

The SANmelody servers aggregate all of their available internal disk space, as well as that of any externally-attached disk arrays, into a virtual storage pool. A mix and match of arrays can be attached using any standard device interface including IDE/ATA, SCSI, SATA, SAS, iSCSI and Fibre Channel (FC). Any manufacturer or device differences are hidden from the storage consumers. When storage administrators assign virtual disks to consumer systems, SANmelody automatically allocates just enough space, just-in-time using a technique called thin provisioning.

Equally important, multiple SANmelody servers can be configured in High Availability (HA) and Disaster Recovery (DR) scenarios. Using two servers, SANmelody automatically mirrors virtual disks, which can be set to automatically fail-over and later resynchronize to the original configuration. Redundant virtual disks may be shared among virtualized servers running VMware ESX, Citrix XenServer, Microsoft Hyper-V or other hypervisors to achieve auto-failover and live migrations of VMs.

Alternatively, a remote DR scenario can be set up in which virtual disks are asynchronously replicated. Although long distances preclude keeping the remote site in lock step with the source disk, the replicated disk will be a far better recovery image than any backup could hope for. Snapshots (also included with the software) can be automatically triggered at the remote site to periodically create known good points in time that ensure recovery consistency.

To assess the potential for IT to utilize SANmelody to configure and control a multi-protocol SAN, we set up a test environment with an internal DAS SATA RAID array and multiple FC storage arrays. Each array sported a full-featured GUI to manage the device. More importantly, all of the GUIs were distinctly incompatible. System administrators would need to support each device independently, even though all of the devices were functionally the same. To fill that void in consolidated management, openBench Labs configured SANmelody on a standard quad-core Windows server with multiple FC and iSCSI connections.

In addition to a Dell PERC 5/i internal SATA RAID controller, we installed two dual-port 4Gbps FC HBAs—an Emulex LP11000 and a QLogic QLE2462—on our SANmelody virtual-disk server. DataCore provides special drivers in SANmelody for all supported FC HBAs. These drivers allow each port on the storage server’s HBA to appear as both an initiator, which connects to a storage device, and as a target, to which an HBA on a client system can make a connection.

For our tests, openBench Labs created two NMV storage pools based on unformatted logical volumes imported from an IBM SAN array that used SATA drives in a RAID 5 configuration and a Texas Memory Systems array that provided RAM-based solid state disks (SSDs). In our tests, we grouped SATA drives on the IBM array into RAID 5 arrays with six active and one standby drive. We then partitioned the array into two 1.6TB logical drives and exported these drives to the SANmelody storage server. That was all that we would require from the IBM array. Once those volumes were assigned to the oblSATA pool, all storage management was performed via SANmelody.

Once we had completed the installation of SANmelody, we encountered a remarkable productivity boosting aspect of this product: System administrators manage SANmelody by simply by invoking the native Microsoft Management Console (MMC) via an MMC Snap-in from DataCore.

For a system or storage administrator to establish centralized control over an existing SAN infrastructure, SANmelody provides a complete set of tools needed to maximally virtualize all of the sites storage resources. As with any SAN storage device, the SANmelody virtual disk server is all about packaging a collection of physical disk blocks and presenting the package to a client system—an application server in the argot of SANmelody—as a logical disk. There are several ways to do this with SANmelody, however, the most functional and sophisticated method employs thin provisioning through the DataCore construct dubbed a Network Managed Volume (NMV).

The notion of thin provisioning came about as a means for IT to allocate storage more efficiently by configuring a logical disk that presents a total capacity which exceeds the actual number of physical disk blocks available to the logical disk at the provisioning time. The trick to successfully carrying out a thin provisioning scheme is to provide just enough space for current operations and an efficient just-in-time (JIT) mechanism to allocate more physical blocks to the logical device as they are required. More importantly, SANmelody does not consider physical blocks to have been utilized until data is actually written to disk by the application server. Simply creating a logical partition on a virtual volume on an application server does not consume space in the SANmelody JIT scheme.

To test the management of both iSCSI and Fibre Channel connections, we created linear virtual volumes within both the oblSATA and oblSSD storage pools.

Within SANmelody, the foundation for thin provisioning is the construct of an NMV storage pool. An NMV storage pool is a unified space of virtual disk blocks: a notion that is used by a number of sophisticated storage virtualization schemes as a means to non-disruptively grow storage resources. Nonetheless, by employing the NMV virtual disk pool construct centrally, system and storage administrators no longer need to monitor storage usage on multiple application servers or within multiple storage arrays; they can now tightly focus on a single virtual storage pool.

NMV storage pool capacity is backed by un-partitioned disks that are mapped from the SANmelody server into the pool. This makes it easy to characterize a tiered storage hierarchy by the characteristics of the disks mapped into a pool. Typically, IT administrators will create NMV pools based on such underlying characteristics as drive rotational speed, drive interface—FC, iSCSI SCSI, SAS, SATA, IDE/ATA—or storage array RAID level.

For more efficient operations, SANmelody allocates space from these storage pools using small available storage allocation units (SAUs). The only constraint on the size of a virtual volume presented to an application server will come from an OS limitation on volume size. As SAUs are consumed and an NMV pool is depleted, SANmelody notifies system and storage administrators through low-watermark alarms and event log messages.

Once we had created the virtual volumes that we would use in testing, we mapped them between FC HBA ports on the storage server and an application server or between Ethernet NIC ports on the storage server and iSCSI HBA ports on an application server.

Before creating virtual volumes based on an NMV storage pool, it is first necessary to generate another virtual construct on the storage server, which SANmelody dubs simply as a volume. Virtual volumes are logical containers exported to application servers.

That extra layer of virtualization may at first appear to be superfluous; however, it’s essential to achieve the first level of elevated data availability that SANmelody provides. While virtual volumes may be assigned one logical container volume in a “linear” configuration, a system or storage manager can assign two volumes to a virtual volume. When two container volumes are used, RAID-1 mirrors are created and the virtual volume is exported to the application server as a mirror set.

Running Iometer using 8KB random I/Os in a 50/50 mix of reads and writes, we measured the ability of the SANmelody storage server to improve throughput performance under a heavy workload. We measured throughput at ports on the QLogic FC switch, where the normal data flow perspective is reversed. On reads, a port connected to an array receives data, while a port connected to a server transmits data. In our tests, total throughput between the application server and the storage server was about 300MB per second with reads and writes split 50/50. Write throughput between the storage server and the SSD array remained at 150MB per second, but read throughput was only about 100MB per second as a third of the reads came from the SANmelody cache.

The final step in virtualizing a storage device for use by an application server is providing an access path. For an IT administrator using SANmelody, this amounts to identifying the two end nodes—FC or iSCSI ports—of a valid path in the SAN fabric. To simplify this task, SANmelody supplies a drop-down list of all discovered devices. In addition, there are several options that provide for multipath redundancy on both SANmelody storage and application servers.

For performance testing, openBench Labs deliberately chose to avoid
multipath I/O configurations in order to more easily observe and isolate traffic at FC and iSCSI SAN ports. In normal operations, we would have enabled round-robin LUN distribution on the storage server channels. For our tests, however, we isolated each SAN path endpoint on a separate port—storage server to storage array and application server to storage server.

We began testing using Iometer to simulate high-end transaction processing applications on a virtual disk carved out of our oblSSD pool. This was a pure 4Gbps FC play that would stress I/O processing capabilities well beyond normal circumstances. The goal was to unleash a flood of I/O requests on the application server and to observe potential bottlenecks on the storage server as I/O processing requests flowed from the application server to the storage array through the storage server and data flowed back from the storage array to the application server through the storage server.

Using a logical device provisioned from our oblSATA pool, we tested throughput utilizing iSCSI connections. The SANmelody storage server was easily able to support I/O throughput at 1Gbps wire speeds.

We fully expected to see some loss in throughput at the virtual disk server due to the inherent overhead of our topology; however, what we encountered was a measurably significant drop in I/O workload at the storage array as a sizeable number of read requests were satisfied out of SANmelody’s cache. Using 8KB random read requests, we were able to handle 50,000 I/O requests per second (IOPS). That load flooded the path between the application and storage server with 400MB of data per second, which is the limit for reads on a 4Gbps link. Nonetheless, read throughput on the link from the storage array to the server running SANmelody was only 250MB per second. SANmelody was satisfying roughly 37.5 percent of the I/O requests from the application server using its cache.

Given the level of I/O throughput sustained over 4Gbps Fibre Channel connections, we anticipated that there would be little or no problems in driving iSCSI data connections over Gigabit Ethernet. In this test, we utilized a more real-world test scenario. In particular, we created virtual volumes backed by our oblSATA NMV storage pool. Once again, using Iometer to drive random 8KB read requests, we were able to easily saturate the 1Gb-per-second path between the NIC port on the storage server and the iSCSI HBA port on the application server. The only issue for the SANmelody storage server was throttling down I/O on the FCconnection to the IBM array.

At most SMB sites today, IT is likely to have multiple vendor storage arrays that sport similar functions which must be managed in different ways. From an operations perspective, multiple arrays with multiple management systems force IT administrators to develop overlapping sets of skills. Worse, if IT attempts to automate based on one of these proprietary functions, they may be unable to move data from one system to another.

Worse yet, substantial capital costs are incurred as the same critical management functions are repeatedly licensed for every storage array. For example, licenses for snapshot, mirror and replication functionality on an 8TB FC SAN array with SATA disks can more than double the cost of the array. With SANmelody in place, IT buyers don’t plan for new storage devices with an eye to the bottom line, but employ instead  laser-like precision.