iQstor iQ2850

By Jack Fegreus
published: Monday, May 18 2009

Delivering iSCSI storage by policy

iQstor compounds the value proposition of their iSCSI storage array with policy driven dynamic storage configurations.

The virtualization of systems through a Virtual Operating Environment (VOE), now garners the lion's share of attention of CIOs. It is impossible to maximize the benefits of a VOE, such as VMware Virtual Infrastructure, however, without first implementing SAN-based storage. Especially at SMB sites, too often there is no SAN for harnessing system and storage virtualization synergies. By leveraging existing Ethernet infrastructure and not burdening IT administrators with new infrastructure to manage, IT can immediately realize all the benefits of a SAN with iQstor's iQ2850.

Further simplifying SAN implementation, the VMware ESX file system (VMFS) handles logical disks belonging to VMs in a way that is analogous to CD-ROM image files. In this way, VMFS encapsulates a VM's files within a logical disk and eliminates the burden of ensuring exclusive ownership of logical disks in order to protect the integrity of the VM's file system. More importantly, advanced VI features, such as VMotion, are designed specifically to leverage shared storage to provide a virtual machine (VM) with mobility for load balancing and disaster recovery. That explains why strong growth in server virtualization is spurring strong iSCSI adoption as the least complicated way to migrate from DAS to a SAN.

To maximize the value proposition of the iQ2850, iQstor utilizes enterprise-class Seagate Barracuda® ES.2 SATA drives. What distinguishes this line of drives is the availability of SAS or SATA interface electronics for drives with all other opponents identical. With the same recording platters and the same firmware to reduce rotational vibration, the reliability of Barracuda ES.2 SATA and SAS drives are the same.

What's more, the iQ2850 sports fully redundant, hot-swappable components. In particular, iQstor puts a Fibre Channel interface on each of the SATA drives and connects them to one of two iSCSI controllers via one of two 4Gbps FC arbitrated loops, which allows the controllers to address up to 240 drives. As a result, iQ2850 can support significant site storage expansion without addition of JBOD expansion units, which for archival applications, such as D2D backup, is a highly cost-effective way to meet site I/O traffic patterns and requirements.

Given the quality of the drives and the system's FC arbitrated loop architecture, we were not surprised to see our sequential I/O benchmarks on VMs reduced to a race to reach wire-speed-about 112MB per second-for iSCSI connections. With one active I/O process on one VM, I/O throughput for sequential reads using a VDisk from our RAID 1+0 storage pool was pegged at 80MB per second. That throughput rate was nearly twice that of a VDisk from our RAID 5 pool, which was measured at 45MB per second. With battery-backed cache in the controllers and local UPS devices for systems, testing with a typical write-back caching configuration put write performance on a par with read performance for VDisks from both pools.

More importantly, that sequential I/O performance was for a single process on a single VM. With two I/O processes utilizing two distinct drives, throughput for standard 8KB reads rose to 105MB per second and for large-block (64KB) reads rose to 160MB using our RAID 1+0 storage pool. At that point, however, the structure of the RAID arrays in the storage pool becomes subsidiary to the EXS server's ability to leverage the eight iSCSI connections provided by the iQ2850. With the iQ2850 iSCSI storage system, I/O scalability is much more likely to be a sever scalability issue rather than a storage system issue.

The iQ2850 compounds its SAN value proposition with integrated software for policy-driven automation of storage management functions. The iQ2850's Web-based data management features, include volume manager-based storage virtualization, storage provisioning, capacity expansion, data migration, snapshots, mirroring, and remote replication.

With the iQ2850, IT administrators can deliver immediate storage services to support application-based SLAs. Using iQstor System Manager-the web interface running on the iQ2850-IT administrators create a hierarchy of storage objects. The storage hierarchy starts with disks, then moves to RAID arrays, then builds storage pools. For host servers, storage pools are the source of logical VDisks-target volumes, mirrors, and snapshots. Within that hierarchy, storage pools and VDisks get the lion's share of attention from IT administrators.

The game changer for IT operations, however, is the manner in which iQstor creates and leverages dynamic storage configurations, such as storage pool expansion. IT administrators are able to invoke simple policies to automate common management tasks. That automation ensures that those common tasks will be done consistently and correctly. What's more, complex issues, such as planning and allocating disk capacity for each storage tier can be made dynamic and self-resolving.

By defining a storage pool as a virtual space of storage blocks with a common underlying RAID level, iQstor System Manager is able to present IT administrators with a simple option to automate storage pool expansion. The automation policy checks for a user-defined minimum threshold of free blocks: If there are fewer free blocks than the threshold mandates, iQstor System Manager automatically configures an appropriate new RAID array and adds it to the storage pool. For sites that use snapshots to improve application availability, a processing disruption caused by the inability to allocate a snapshot is not a pretty picture.

With server virtualization acting as a major driver in iSCSI adoption, VSM Labs set up an iSCSI test scenario for the iQ2850 that centered on a typical Virtual Operating Environment. What's more, for a storage system, such as iQstor's iSCSI iQ2850, full support of a VOE tests all of that storage system's dimensions of functionality and performance.

Our VOE featured VMware ESX server hosting eight VMs on a quad-processor HP DL580 server. We also employed a quad-core Dell PowerEdge server running Windows Server 2003 to manage the virtual infrastructure with vCenter Server (a.k.a. Virtual Center) and VMware Consolidated Backup (VCB) to create and share snapshots of VMs during a backup. To manage the actual end-to-end backup process we used Net Backup 6.5. For iSCSI connectivity on our servers, we used an embedded 1Gbps NIC on the Dell server and installed a dual-port iSCSI HBA, the QLogic QLA4052, on the HP server, dubbed VMzilla.

With ESX hosting eight I/0-intensive VMs, we chose a dual-port iSCSI HBA to leverage support for hardware iSCSI HBA multipath I/O (MPIO). In particular, ESX compounded our ability to leverage the eight iQ2850 iSCSI ports by providing round-robin connection load balancing and active/passive path failover. As a result, when I/O processing involved multiple disks or multiple VMs, we were able to automatically maximize both the number of I/O requests that could be directed to our iQ2850 and the volume of data that could be returned to our VMs.

Nonetheless, I/O throughput is only a small part of a VOE scenario. Besides being a critical business support issue in a VOE, backup is a major technical support issue for IT. Best IT practices call for classic file-level backups of VMs to be augmented with image-level backups that can be moved among VOE servers to enhance business continuity. VMware Consolidated Backup (VCB) provides the framework needed to support both image-level and file-level backup operations; however, VCB also requires the sharing of logical disks on a SAN. To provide backup in our VOE test scenario, we installed VCB with Symantec NetBackup 6.5.3 on our Dell PowerEdge 1900 server. The VCB package includes a VLUN driver that is used to mount ESX snapshots of VM disk volumes.

To make this backup scheme work, the VCB software must be installed on a Windows Server host-dubbed the "proxy server"-that has SAN access to the datastore volume on the ESX server. The proxy server must be able to mount the ESX datastore and access all of the vmdk files associated with the disk volumes belonging to the VM being backed up.

With both the proxy server and the ESX server having access to the datastore and vmdk files via the SAN, the backup window, as seen from the viewpoint of the VM, only lasts the precious few seconds needed for the ESX Server to take and then remove a VMFS snapshot of the VM's vmdk file. During a backup, the proxy server initiates a VMFS snapshot to the ESX Server. The ESX server then creates a point-in-time copy of a VM's disk files; the vmdk file is frozen in a state that reflects the VM at the instance of the snapshot; and all new data for a VM is written to a special file dubbed a delta disk file.