vSphere and the Iomega ix2-200d

vSphere and the Iomega ix2-200d

I picked up an Iomega ix2-200d a couple of months back to use in place of my DataCore SANMelody box that I created back in this article.

Since the device is VMware certified for iSCSI, it seemed a natural fit for a test network that wouldn't be seeing a ridiculous amount of traffic.

There are many reviews of the product and its larger siblings: ix4-200d, ix4-200r and the new ix12-300r already out on the web so I won't get into that here. My goal is more to shed some light on how well and easily the unit can fit into your network.

One of the major differences between using this device versus a full blown managed storage array is that it allows you to focus on the control from the ESX side of the house, not the SAN side. What I mean is that once you have enabled the device for iSCSI and gone through the motions of getting it ready to present storage, you're pretty much done with it. From that point on it simply sits out on your network and waits to be pinged.

ESX Cluster

If your goal is to focus on vSphere and its tools and features, this setup is ideal because it cuts the complexity down by half (okay not half but a lot). You simply don't have conflict issues that arise where a drive won't connect or work as expected and you're forced to troubleshoot both sides of the equation. With the ix2, once its running you're pretty well assured that any new problems going forward are bound to be on the ESX side of the house. This is what the maps in vCenter show when all is working fine:

SQLVM-Clustered

The SQLExpress 2005 VM is stored on the Iomega iSCSI SAN (okay so putting EMC instead of Iomega in the description looks better) With the VM centrally located on shared storage that is accessible by the three ESX servers pictured, all lights are green. The VM is free to roam about.

The next image shows what a VM running on local ESX storage space looks like in the grand scheme of things. The VM in this case is not free to roam around and if that ESX box goes down, the VM is heading down with it. At this point you can use Storage vMotion while the VM is running of course to move it over to the ix2. From there all lights would be green again.

VM non-clustered

That being said, there are of course many cool projects you can work on and test when you have an active storage array. The best part is you don't have to choose. You can run the ix2-200d for your every day VMs and to handle the cluster of ESX so you can do vMotion and storage migrations; and then when you want move some of your appliances over to the active storage to do Site Recovery Manager and other products.

In other experiments I used a whitebox nVidia 680i running ESXi 4 with 4 2TB SATA drives in a RAID 10 configuration. On this box I ran tests with either the Falconstor Virtual SAN or the HP StorageWorks P4000 Virtual SAN Appliance. By using ESXi and running only one virtual appliance at a time I managed to replicate as close as possible having a dedicated device from one of the companies. At that point with multiple GBics, redundant power and hot swappable drives I was able to host the ESX cluster in more of an Enterprise production mode.

Bottom line is that there are many different ways to geek out and build your own SAN with off-the-shelf components. It's helpful to be able to differentiate between different types of units and software, and then constantly evolve as you go along.

Your rating: None Average: 1 (7 votes)

You say that the advantage of

You say that the advantage of ISCSI is so you can use vmotion between two esx servers if one went down. Can't you just vmotion between the internal storage of the two esx servers?

You can only VMotion between

You can only VMotion between servers that can see the same shared storage at the same time. For instance, if the VM is stored on local storage of ESX1, and ESX1 also has shared iSCSI storage between it and ESX2, then to Vmotion a live VM you would have to do a two part move. First you'd have to storage Vmotion the VM to the shared storage, THEN you could Vmotion the live VM to ESX2. In the event of a host failure on ESX1, however, the VM would need to be on shared storage for Vmotion to work simply because the local storage of ESX1 would no longer be available.
Michael LeFevers

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer

Drupal SEO
Drupal 6 Appliance - Powered by TurnKey Linux