xStack Storage DSN-Series SAN Arrays
VMware ESX 3.0.2 & 3.5
D-Link Systems, Inc. Page
9
December 2, 2009
Basic Setup
To provide a basic setup using an xStack Storage iSCSI storage offering, a PowerEdge 2850 ESX
host with two Intel® dual-core Xeon® processors running at 2.66GHz and with 4GB memory
was connected as described in the previous section to five-disk RAID 5 LUNs on one xStack
Storage DSN-3200-10 storage array. We used the two built-in NICs for the ESX Service Console,
VMkernel (including iSCSI traffic) and the virtual machine (VM) traffic as shown in Figure 2.
For testing this basic setup, two Windows Server 2003 R2 VMs with Microsoft SQL Server 2005
running a medium size (1 GB) version of the D-Link DVD Store database test application were
created with their 10GB virtual disks stored on the five-disk LUN on one array. The VMs were
then cloned three times with the copies’ virtual disks placed on similar LUNs on each of the other
three arrays. The VMs were configured with 4 virtual CPUs and 512MB each so that each virtual
CPU roughly had the resources of a single processor core.
The SQL Server database on each VM is created on that VM’s local disk so it, too, is stored on
the LUN. Since the database size (1 GB) exceeds the memory available to the VM (512 MB),
SQL Server will have to access its content from the LUN during the test.
The two VMs attached to a single iSCSI storage array were then stressed using an order entry
simulator (included as part of the DVD Store kit) which models users logging into the online
DVD Store, browsing for DVDs by title, artist or category, and finally making a DVD purchase.
A complete cycle of logging in, browsing, and purchasing counts as one order. The number of
users and the amount of time they spend thinking during an order can be controlled by the
simulator. In this test, the think time was set to 0 seconds so that each driver thread can be
thought of as a super user entering orders without stopping.
Starting with 2 such driver threads per VM, a workload was applied to each VM pair for 4
minutes and the average orders per minute and response time recorded. Then the VMs’ databases
were restored to their original state and a larger workload applied. The workload was increased
until the orders per minute rate stopped increasing. At that point the storage array could handle no
more IOs per second (IOPS) even as the applied workload increased.