The vSphere is not Flat!

All too often, when I visit a client’s site, I notice that the VMWare environment is not configured as intended by the customer.  Some of the more common misconfigurations may

• Expose customers to service outages
• Compromise data security
• Infringe on regulartory requirements

Today I will focus on the networking components that are so important to get right.

The number one mistake I see is implementing a vSphere environment onto a single flat network. I’ve seen several deployments where the management network, vmotion network, production network, and iSCSI networks were all sharing the same subnet and all plugged into a single switch. Let me point out a few of the problems with this configuration:

1)      Single Point of Failure at the switch – If the switch fails, you have just lost storage connectivity, your front-end connectivity, your cluster heartbeat, and management network (you can’t log into vCenter or your ESX hosts).  We can easily see the major catastrophe that is waiting to happen with this configuration. Redundancy is key to maintaining maximum availability to your production systems.

2)      Security Risks:

1. The management network is on the same subnet as client machines. This means your hosts are exposed to the network user and WAN. Furthermore, if you are using iLO or DRAC to manage the physical hosts, you have now exposed your console to network users and the WAN (granted, exposure to the WAN can be minimized using firewall rules).
2.  iSCSI presents security risks of its own (which I won’t go into detail in this article). Just remember that iQNs traverse the network in CLEAR-TEXT. If clients share the same network as iSCSI traffic, an attacker can easily sniff iSCSI communication, and gain access to sensitive data. This is obviously a security issue, and could render an organization out-of-compliance with regulatory requirements.

3)      Performance – It’s true, while this configuration may work and without perceived performance issues at the moment, consider the following:

1. What happens if someone creates a network loop or there is some major virus causing traffic? Since the iSCSI traffic is sharing the same network domain, you will most likely lose connectivity to your storage array.  It’s no fun when servers lose connectivity to storage.
2. Jumbo Frames – iSCSI can take advantage of jumbo frames which can increase throughput and reduce the number of frames being processed.  Many switches only allow jumbo frames to be enabled or disabled for all ports on the switch.  If jumbo frames were enabled on the VMKernel ports. An MTU mismatch like this could cause unwanted storage disconnections, data loss, and cluster failure.

There are undoubtedly other issues with vSphere misconfigurations that I will touch on in future posts. Proper networking configuration is instrumental to even the most basic functions of VMWare cluster and storage availability. If you get one component wrong, you may be compromising your entire virtualized environment.

My recommendation when designing and standing up a VM Farm is to Do Your Homework!  Do it once, do it right!

Look for my next posting when I’ll talk about vSphere in the cloud.