Freely subscribe to our NEWSLETTER

Server virtualization implementations began in Test and Development organizations. Mostly in large businesses where existing fiber channel SANs were already in place. As the benefits server virtualization accelerated adoption by smaller organizations, the ease of use and affordability offered by iSCSI motivated end users to implement iSCSI SANs instead of fiber channel for storage. IT managers who are familiar with both technologies began to understand some inherent benefits from using iSCSI as storage for virtualized environments. Over half of our customers are purchasing LeftHand iSCSI SANs in conjunction with some sort of server virtualization project, when asked “why iSCSI instead of FC?” customers had a litany of reasons. I’ve tried to summarize their responses below.

The hardware-centric nature of Fibre Channel (FC) creates a number of problems when implementing virtual machines. In FC environments WWNs (World Wide Names) are used to uniquely identify equipment in the SAN. The WWN is an identifier tied to specific hardware such as a server HBA or a storage array. In virtualized environments, this dependency on physical hardware intensifies the complexity of managing the environment and exposes new security risks. iSCSI provides a number of advantages in virtualized environments.

1. iSCSI Simplifies Virtual Machine Mobility for High Availability (HA): Virtualization increases the need for HA. With server virtualization, users typically run multiple applications on each physical server, exposing themselves to a potentially significant impact if a server fails since every single application (all the VMs) running on that server will go down. To solve this problem, virtualization vendors have implemented mobility features that enable VMs to move to other physical servers in the event the server they reside on fails. Using a FC SAN in this type of environment creates additional complexity.

a. Every VM must be mapped to every FC HBA that could potentially be used as the physical connection to the SAN.

b. Every FC HBA that a VM may use must have access to that VMs’ storage.

The multiple layers of relationships (VM to HBA to storage) create complexity and make the FC SAN difficult to manage.

iSCSI avoids this complexity because it uses an IQN (iSCSI qualified name) on each virtual machine that can be mapped directly to its storage. There are no intermediate hardware relationships to complicate things. With iSCSI, VMs are mapped directly to their storage and that relationship remains even if the VM moves to a different physical server. iSCSI also eliminates the FC requirement of ensuring that all VMs are related to any HBAs that might have to be used.

This brings us to a second issue. Security.

2. iSCSI Simplifies Security for Virtualized Environments: If you map VMs to a FC HBA, and then map that HBA to the storage, every single VM on that server has access to every other VM’s storage. Users can leverage the security features in the hypervisor or new emerging FC security features to sort this out, but this creates additional complexity and management.

iSCSI is not exposed to this because each VM is mapped to its own storage and there is no need to have to use the hypervisor or some new FC switch to manage security between VMs. Standard Ethernet security protocols like CHAP authentication are used to effortlessly ensure a secure connection. Likewise, since iSCSI is standard IP (Internet Protocol) traffic any/all common IP security mechanisms work.

3. iSCSI Delivers Performance Without Configuration Headaches: Virtualization increases server utilization. By running more applications on a single physical server, end users can achieve much higher utilization rates for servers. However, most FC SANs are configured assuming a load from one application per server. By increasing the utilization of the server with multiple virtual machines you increase the amount of performance the server requires from the SAN. If zones and LUNs are not properly set up to accommodate this increase in load, VMs can experience disk contention resulting in inadequate performance.

iSCSI avoids disk contention by providing each VM with the ability to connect directly to its storage. Users aren’t constrained by the storage resources to which the server is mapped, and have the flexibility to map each VM independently so disk contention issues are avoided.

These are just a few of the advantages that end users are discovering about iSCSI vs FC in virtualized environments. Some of the emerging iSCSI storage vendors like LeftHand Networks take these advantages even further.

LeftHand Network’s Performance Advantage for Server Virtualization: As higher utilization rates of servers are achieved SANs are required to provide higher performance. Of course users can purchase a new controller and rip and replace their existing one, but even then users may have to reconfigure their SAN so that zones and LUNs can accommodate the increased load resulting from the multitude of virtual machines.

Performance issues in a virtualized environment can be avoided with a LeftHand SAN. LeftHand delivers a clustered storage system, whereby each unit in the cluster provides network connections, processing power, cache, etc… The LeftHand SAN automatically balances the load from all VMs evenly across each unit in the cluster. By distributing the load evenly, controller bottlenecks are avoided. In addition, each volume on the SAN leverages every single disk drive, network connection, and processor in the SAN ensuring consistent performance of every volume and avoiding disk contention issues.

Beyond performance, LeftHand can also simplify manageability of highly available environments.

Seamless VM and Storage HA, No Manual Intervention for Failover and Failback: Lots of vendors talk about enabling virtual machine HA, but the fact of the matter is if a storage system does not provide HA, the environment is not highly available. If the storage goes down, the VMs don’t have access to the data. To implement highly available storage, traditional vendors use synchronous replication where they keep two volumes synchronized so that if one volume goes down, the other is an exact replica. The issue with this approach is that if VMs come back up in the secondary site, they have to be remapped to the secondary volume. This same issue occurs when users failback to the primary site. This is a manual process and at best it is done by scripting.

A LeftHand SAN avoids these complex manual tasks. By managing two copies of the data (one at each location) within a single volume on the SAN, virtual machines don’t ever have to be connected to the secondary volume or reconnected to the primary. These tasks are eliminated altogether as the virtual machines remain connected to the same volume regardless of physical location. Now the entire environment, including applications, virtual machines and storage, is highly available with automated failover and failback capabilities. No user intervention for failover/failback is ever required.

With all of the advantages of iSCSI over FC in virtualized environments, plus new emerging vendors like LeftHand Networks taking performance and availability to the next level, iSCSI storage is proving to be the defacto standard for server virtualization environments. Not sure who said it first, but it is worth saying again: Server Virtualization is the Killer App for iSCSI.