Sunday, February 17, 2013

Port Group Options for vSS - Part 2

In my last post, I discussed the options available to a vSS VM Port Group on the General and Security tabs. Now that you've had a chance to let that sink in, we're moving on to the remaining tabs: Traffic Shaping and NIC Teaming. Here we go.

The Traffic Shaping Tab

The Traffic Shaping Tab.
The Traffic Shaping tab gives you a significant amount of control over the performance of a virtual interface within your port group. It's important to keep in mind that these policies, if enabled, only affect outbound traffic from the selected port group. By default, these options will inherit the vSwitch's configuration, which by default is disabled. If you'd like to use these features, check the box and select Enabled. Now you can set the following configuration options:

Average Bandwidth - The amount of bandwidth your port group is allowed to use over time, measured in Kbits.

Peak Bandwidth - The absolute upper limit on bandwidth, including the Burst Size.

Burst Size - The amount of "bonus" bandwidth a port group can use, if available. This amount is used when your port group (well, really the VMs contained in your port group) request more bandwidth than the Average Bandwidth allows for. If additional bandwidth is available, the Burst Size is in play.

NOTE: These three items are very closely related; setting one improperly can muck up the other two pretty badly. For this reason, vSphere kindly displays an error if you've made a big mistake.

vSphere: "You're doing it wrong."
Take a moment and think about this: if you set your Average Bandwidth to 100,000 Kbits/sec, and your Peak Bandwidth to 9,000 Kbits/sec... not so good. You're basically saying that the average can never be reached, as it exceeds the Peak. Also remember that the Peak takes into account the Burst Size. So Average Bandwidth + Burst Size must be less than or equal to Peak Bandwidth.

In my experience, if you've considered capacity planning in your design (you did, didn't you?) then these values are less important. You don't want to build a vSwitch that is either too large or too small for the VMs contained therein.

You ready for the really fun tab? Good. Because next is...

The NIC Teaming Tab

The NIC Teaming Tab.
Now you know why the Port Group Properties page is so tall. The NIC Teaming tab has a ton of configuration options, relative to the other tabs that is. And these things are IMPORTANT. Don't make changes here, even if you're feeling bold and it's Friday afternoon, unless you know exactly what the impact will be.

Load Balancing - This setting allows you to select a different load balancing method than the one your vSwitch is using. You've got a decision to make here:
  1. Route based on the originating virtual port ID
  2. Route based on source MAC Address
  3. Route based on IP hash
  4. Explicit failover order
I won't get into the details of these methods in this post; they warrant a post unto themselves. Plus I have to create some drawings for each, which will take a bit of time.

Network Failover Detection - This option will determine how the port group identifies a network failure at the upstream switch. You can select Link Status, Beacon, or both.
  • Link status detection will be tripped if a physical cable between your ESXi host and your upstream switch is unplugged, or if the switch itself loses power. But it can't see problems beyond that switch; if the upstream switch is isolated from the rest of the network, link status will not detect a failure, and the link will remain active. In this case, you'll want to enable Beaconing.
  • Beaconing - When you enable Beaconing, you're telling ESXi to probe the status of all the physical uplinks for this port group or vSwitch. ESXi will be more capable of detecting links beyond your upstream switch.

Notify Switches - When enabled, ESXi will attempt to notify the upstream physical switch when virtual machines are connected to the virtual switch.

Failback - When set to yes, this option will move your VM traffic back to the original physical ethernet adaptor once it becomes available again. I recommend setting this to No. You'll want to validate that your network connection is stable before moving traffic back to it.

Failover Order - When your create your vSS, you specify the failover order for your active physical NICs. This setting allows you to override the vSS's failover order, based on the needs of your port group. A classic example is for your management port group. Your vSwitch may be configured to use multiple active uplinks to provide greater bandwidth, but bandwidth typically isn't a problem for your management traffic. Instead, you'll want to provide high availability. Do so by choosing to override the failover order for your management port group and select one NIC as Active, and at least one more NIC as a standby adapter.

Ok. So that's about it. Those of you with experience managing and deigning vSphere environments will recognize that I've glossed over lots of stuff here, but for those of you who are just getting into vSphere networking, you should now have enough information to get started with some basic configurations.

As always, let me know if anything is unclear, or if you'd like to see additional information on this topic.
Mastodon