In VMware vSphere, there are an infinite number of ways to accomplish almost anything. Many architects and administrators tend to do things “their” way, from location they install ESXi to,to the way they access a virtual machine in vCenter. When it comes to making vSphere networking design choices, the same holds true.
vSphere networking is another one of these things which can be done numerous ways. There really is not a right or wrong way to design a vSphere network, as long as you are meeting your requirements. I am not going to cover specific vSphere networking designs, however I am going to take a look at some things to be thinking about during the design process.
Please note, when I am talking about vSphere networking, I am not including NSX.
vSphere Licensing Considerations
One of the biggest factors in deciding how to implement vSphere networking is your vSphere licensing level. If you are using vSphere Standard, standard vSwitches are your only option. However, if you are using vSphere Enterprise plus, you may choose to use standard or distributed virtual switches, which provide additional features and functionality.
When using VMware products such as VSAN or NSX, the Standard license levels include the Distributed Virtual Switch, as this switch is critical to the proper implementation and operation of these products.
vSphere Networking Design Qualities
When making VMware vSphere networking design choices, I tend to think of things in terms of the infrastructure design qualities, which are:
I like to remember them as AMPRS, though you may prefer another acronym.
Let’s go through the design qualities one by one and talk about how they can impact your vSphere networking design.
This can be one of the most important qualities of your environment, because your network is not available, the rest of your ESXi host doesn’t really matter. There are many ways to ensure your ESXi host’s networking availability. First and foremost, the most important thing in my mind is to have multiple network connections to separate physical switches. This way, you are protected in the case of an upstream switch failure.
In addition, it is also important to ensure the virtual switches are configured in a way that represents this. If you have four connections from your ESXi host to two physical switches, and one virtual switch has two connections to the same physical switch, your host will encounter issues in the event that physical switch fails. We’re about to talk more about configuration of your virtual switches.
Distributed Virutal Switches certainly make your vSphere networking easy to manage, since they are configured centrally. It is extremely important to ensure vSphere hosts in the same cluster have compatible network configurations. Host profiles also make this easy to achieve, regardless of the switch you use in your environment,. These are both vSphere Enterprise Plus features, however.
Before the days of Distributed Virutal Switches and Host Profiles, I used scripts to configure my networking. For those with vSphere standard, this is also a way to help ensure the networking configuration is uniform across the cluster. As mentioned in the availability section, it is extremely important to make sure your virtual switches are configured correctly. Automating their configuration, with something like PowerCLI if you are not licensed for Host Profiles can help ensure uniform configuration.
There are a few things to consider when thinking about your vSphere host’s network performance. First, it is important to make sure you have enough bandwidth. Items such as your workloads and whether or not you are using IP storage will greatly impact this. Also, you must decide if degraded network performance is acceptable in a failure scenario or not.
You friend vMotion? vMotion performance is highly dependent on your network configuration. One benefit to Distributed Virtual Switches is Network I/O Control https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.networking.doc/GUID-98E0B3C2-52A7-4CAB-A839-4DA82A9F6D3A.html. This allows you to tell your vSphere environment which traffic is the most important during contention, and how resources should be split during that period.
In the case of vSphere networking, this ties back to how you inailly created your networking configuration. Distributed Virutal Switch configurations can be backed up and imported, and scripts to configure vSphere Standard switches can be re-run. You must ensure these important files are avilable in a recovery scenario. Beyond just your virtual network configuration, you should be considering how you would restore your complete vSphere environment in the event of a disaster.
Security is of course one of the hottest topics today, and there are many things to consider when designing your vSphere networking environment. Luckily, many of the things you need to think about carry over from the physical networking side. It is still important to restrict network access just like you would in the physical world. One of the big things to think about is the MAC addresses of your virtual machines, and your requirements around them. Will the initial and effective MAC addresses always match, or is there a legitimate case where they may be different? This is a design choice where you will have to weigh risks and requirements.
This, of course, is not a full list of everything you will encounter while you are designing your VMware vSphere networking environment. It is meant to give you ideas around the type of things you should be thinking about as you begin the VMware vSphere networking design process.