With DataCore's SANmelody, SMB IT administrators can create central pools of virtual disk blocks using DAS and SAN-connected arrays, and then apply advanced features from thin provisioning to mirroring from one GUI.
By Jack Fegreus
-- DataCore Software's SANmelody provides centralized disk virtualization software for small and medium-sized IT environments with 2TB 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. SANmelody is able to cater to the budget constraints of SMBs via modular, capacity-based licensing. Nonetheless, since SANmelody inherits all of its essential features from DataCore's larger-scale SANsymphony software, it can meet SMB requirements without compromising on functionality.
Installation of SANmelody software on an x86 Windows server turns it into a virtual disk server. The software can 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.
The SANmelody servers aggregate all 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 interface, including IDE/ATA, SCSI, SATA, SAS, iSCSI, and Fibre Channel. When storage administrators assign virtual disks to 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-fail-over and live migrations of VMs.
|openBench Labs created two NMV storage pools based on unformatted logical volumes imported from an IBM SAN array with SATA drives in a RAID-5 configuration and Texas Memory Systems' RAM-based SSDs. We grouped SATA drives on the SAN array into 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. Once those volumes were assigned to the oblSATA pool, all storage management was performed via SANmelody.|
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 use SANmelody to configure and control a multi-protocol SAN, we set up a test environment with an internal direct-attached storage (DAS) SATA RAID array and multiple Fibre Channel storage arrays. Each array included a full-featured GUI for device management. More importantly, all of the GUIs were distinctly incompatible. 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 Fibre Channel and iSCSI connections.
In addition to a Dell PERC 5/i internal SATA RAID controller, we installed two dual-port 4Gbps Fibre Channel host bus adapters (HBAs) -- an Emulex LP11000 and a QLogic QLE2462 -- on our SANmelody virtual-disk server. DataCore provides special drivers in SANmelody for all supported 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.
Once we had completed the installation of SANmelody, we encountered a productivity boosting aspect of this product: Administrators manage SANmelody by simply invoking the native Microsoft Management Console (MMC) via an MMC Snap-in from DataCore.
|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. Total throughput between the application server and storage server was about 300MBps with reads and writes split 50/50. Write throughput between the storage server and the SSD array remained at 150MBps, but read throughput was only about 100MBps as one-third of the reads came from the SANmelody cache.|
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 site's storage resources. As with any SAN storage device, the SANmelody virtual-disk server packages a collection of physical disk blocks and presents 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 that exceeds the actual number of physical disk blocks available to the logical disk at the time of provisioning. The trick to successfully carry 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 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.
Within SANmelody, the foundation for thin provisioning is the construct of an NMV storage pool, which is a unified space of virtual disk blocks -- a technique 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 multiple storage arrays. Their attention can now be focused on a single virtual storage pool.
NMV storage pool capacity is backed by unpartitioned disks that are mapped from the SANmelody server into the pool. That makes it easy to characterize a tiered storage hierarchy by the characteristics of the disks that are mapped into a pool. Typically, IT administrators will create NMV pools based on such underlying characteristics as drive rotational speed, drive interface, or 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 administrators through low-watermark alarms and event log messages.
Before creating virtual volumes based on an NMV storage pool, it is first necessary to create 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 superfluous; however, it is 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.
|Using a logical device provisioned from our oblSATA pool, we tested throughput using iSCSI connections. The SANmelody storage server was able to support I/O throughput at 1Gbps wire speeds.|
The final step in virtualizing a storage device for use by an application server is to provide an access path. For an IT administrator using SANmelody, this amounts to identifying the two end nodes -- Fibre Channel 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 multi-path redundancy on both SANmelody storage and application servers.
For part of our performance testing, openBench Labs deliberately chose to avoid multi-path I/O configurations to more easily observe and isolate traffic at Fibre Channel and iSCSI SAN ports. In normal operations we enabled round-robin LUN distribution on the storage server channels.
We began testing using the IOmeter benchmark to simulate high-end transaction processing applications on a virtual disk carved out of our oblSSD pool. This was a pure 4Gbps Fibre Channel 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 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.
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 sizable number of read requests were satisfied out of SANmelody's cache. Using 8KB random read requests, we were able to handle 50,000 I/Os 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 250MBps. SANmelody was satisfying approximately 37.5% 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 there would be little or no problems in driving iSCSI data connections over Gigabit Ethernet. In this test, we used 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 easily saturated the 1Gbps 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 Fibre Channel connection to our IBM array.
At most SMB sites today, IT is likely to have multiple vendors' storage arrays that have similar functions that must be managed in different ways. From an operations perspective, multiple arrays with multiple management systems forces IT administrators to develop overlapping sets of skills.
Worse yet, substantial capital costs are incurred when the same critical management functions are repeatedly licensed for every storage array. For example, licenses for snapshot, mirror, and replication functionality on an 8TB Fibre Channel SAN array with SATA disks can more than double the cost of the array. With SANmelody in place, IT buyers can plan for new storage devices not with an eye to the bottom line, but with laser-like precision.
Jack Fegreus is CTO of openBench Labs. This article was excerpted from a longer review. To view the full review, visit www.openbench.com.
openBench Labs Scenario
Virtual disk server software for storage virtualization
WHAT WE TESTED
--Logical blocks are served from tiered storage pools that can be based on characteristics such 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 data is written by an application.
--Administrators are able to mix-and-match servers and storage to implement an HA or DR infrastructure
HOW WE TESTED
Two Dell PowerEdge 1900 servers
--SANmelody client utilities
--Windows 2003 Server SP2
--IBM DS4100 FC-SATA disk array
--Texas Memory Systems' RamSan-400 SSD
--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% 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 synchronous replication