The final component to consider is the VM networks, the real data traffic to and from VMs. This, you’ll recall, is the important bit—it’s why you’re building the network in the first place. Think hard on how you want to configure and label your VM networks. These
Lab Scenario 139
are the day-to-day networks that you or your team will be working with, and we’ve seen a lot of environments that use a very poor or confusing naming standard.
Some points to consider:
Q VLAN tagging: In the vast majority of use cases, you will want to specifically define a VLAN ID for each VM port group. This is referred to as Virtual Switch Tag-ging (VST) . It also gives you the operational freedom of using trunk ports on your upstream physical switch and clearly shows anyone looking at the vSphere Client what VLAN the VMs are communicating on.
Q MTU: The default value of 1500 bytes works fine for most folks. It’s rare to change this for VM traffic, but a bit more common to increase the value if you plan to use an overlay protocol such as virtual extensible LAN (VXLAN) or configure IP storage such as iSCSI or NFS. You’ll recall from Chapter 4, “Advanced Layer 2,” that frames larger than 1500 bytes are called Jumbo Frames. If you aren’t sure if you need Jumbo Frames, leave this setting alone. Every piece of physical networking gear which passes your nonstandard-sized frames would also have to be set to the same nonstan-dard MTU size setting.
Q Naming: One of the most overlooked, but probably one of the most important con-figuration items, is the naming scheme. Calling a VM network “virtual machine network 1” works when you have a tiny environment, but will become incredibly confusing down the road. The name should convey meaning in a compact format.
Great names often have the subnet value in them, a designation of the workload type, and perhaps even the VLAN ID. For example, the name “SQL_192.168.50.X_V170”
could communicate that the VM network uses the subnet 192.168.50.0/24 on VLAN 170 for SQL workloads.
REAL WORLD
Try to avoid using names that include spaces. Instead, use underscores or dashes, as spaces often make it more difficult when scripting with PowerShell or other scripting languages.
Lab Scenario
Rather than just talk about setting up standard and distributed vSwitches, along with the use of iSCSI and NFS storage VMkernel ports, we use our company’s engineering demon-stration lab to walk you through virtual switch implementation. The equipment we use is as follows:
Lab Scenario 141
NOTE
Our demo lab is really something, and we love bragging about it. You can see all the toys we get to play with at www.thinkahead.com/ahead-aviation/.
That said, you don’t need any of the equipment we’ve listed here to be successful with learn-ing virtual switches, or even to try out creatlearn-ing a virtual network on your own. Much of what we cover will be done in a vendor-agnostic manner focusing on generic network adapters.
You could easily substitute in hardware from HP, Dell, IBM, SuperMicro, or even use VM-ware Workstation at home to review much of what we cover here. Additionally, if you do not have blade servers or 10 Gb Ethernet adapters, we cover rack mount servers with both 10 Gb and 1 Gb Ethernet in Chapter 18, “Additional vSwitch Design Scenarios,” and Chap-ter 19, “Multi-NIC vMotion Architecture.”
It is, however, important to emphasize that the equipment we’re using is something you might find out in a real world datacenter, so we figured you might want to know what we were using in the screenshots to follow.
We’ve also selected the following networks for each type of traffic:
Q Management traffic: 10.20.0.0 /16, routable, with a gateway of 10.20.0.1, on VLAN 20
Q vMotion traffic: 192.168.205.0 /24, non-routable, on VLAN 205
Q FT logging: 192.168.210.0 /24, non-routable, on VLAN 210
Q VR traffic: Not used
Q iSCSI traffic: 192.168.215.0 /24, non-routable, on VLAN 215
Q NFS traffic: 192.168.220.0 /24, non-routable, on VLAN 220
NOTE
The items listed are similar to a list you might see while working on a design. See the term “non-routable” used after many of the networks? This indicates that there will be no gateway for the traffic to use to crossover from one network to another. It also means that we’ve avoided creating a VLAN interface for inter-VLAN routing.
It is important that all the VLANs exist on the upstream physical network, as otherwise the vSphere host will not be able to communicate using the selected VLANs. In our case, the VLANs must be defined within the Cisco UCS domain itself and in the upstream Nexus 7010. Figure 11.2 shows the VLANs defined in Cisco UCS Manager.
142 CHAPTER 11 Lab Scenario
Figure 11.2 The VLANs configured on the upstream Cisco UCS domain
To tie things together, Figure 11.3 shows a basic view of the lab from the perspective of the vSphere Web Client.
The vCenter Server, named Initech Corp, contains a single datacenter in Chicago. This datacenter contains a cluster named Production, which is our focus for the remaining chapters in this section. Two blades have been added to the cluster, named esx1 and esx2, which are identical for our intents and purposes. A single VM exists named vCSA55 which runs the vCenter Server Appliance version 5.5. Nothing else has been configured—we’re running off the stock default settings for the initial standard vSwitch that the hypervisor automatically creates. Welcome to our greenfield deployment, where a near infinite num-ber of possibilities await.
You might also notice that the value for “NICs” is shown as 2. That’s right, we move through the creation of distributed and virtual switching with just a pair of 10 Gb Ethernet network adapters, and discuss many of the caveats around this tactic, in Chapter 12 and Chapter 13, “Distributed vSwitch Design,” on standard and distributed vSwitches.
Summary 143
Figure 11.3 High-level perspective from the vSphere Web Client
Summary
Behind every great implementation is a great design. In this chapter, we looked over some of the decisions you will face when creating your virtual network design. We also locked down many of the variables that are used in the upcoming chapters on standard and dis-tributed vSwitches in our engineering lab.