Saturday, July 12, 2014

Gift from Tintri to vExperts 2014


Few days back I received one parcel from Fedex after opening it I found Nike Tshirt my name on it with vExpert logo, I would like to thanks Tintri for the generosity sending TShirt on becoming vExpert 2014. 


Tintri Zero Management Storage™ helps IT organizations eliminate storage complexity and minimize costs for their virtualized environments. Designed from the ground up for virtualization and cloud, Tintri addresses the mismatch between storage and virtualization with the industry’s first and leading VM-Aware Storage architecture.  With intelligence that understands virtual machines and keeps storage always optimized, Tintri VMstore improves performance by as much as 10x, makes virtualization predictable and enables higher IT productivity—all while slashing costs. Production-proven in hundreds of global enterprises, Tintri helps businesses and organizations worldwide maximize their virtualization investments.
Check out more at http://www.tintri.com

Wednesday, July 9, 2014

VMware Networking 101: VMware Network Load Balancing policies – Part 1



Route based on originating virtual port ID: Policy works like as similar as Round Robin technic. Let’s suppose you have multiple VMs on vswitch and that vswitch having only 2 physical nic cards assigned. Here VM1 will get vmnic0, VM2 will be on vmnic1 after VM3 will get mapped to vmnic0 and so on.

If we look at the pros, you don’t have to configure any special configuration at physical network side, it puts zero load on esxi. This is default setting.

Con of this policy is, it’s not aware of the physical NIC card load. As an example I have seen one of the bad design of having 2 physical NIC with different speed 10Gig and 1Gig attached to vSwitch using Route based on originating virtual port as load balancing, there might be a chance your heavy traffic vms get mapped to 1 GBps NIC and 10 GBps NIC is sitting idle (getting mapped idle vms).

Traffic of the VMs will not exceed the underlying mapped NIC speed. If my 5 VMs start utilizing more than 200 MB (mapped to 1 GBPS NIC), this policy will not load balance traffic to other NIC.




Route based on source MAC hash: It is little bit similar to Route based on originating virtual port but the calculation is done on the algorithm of Mac hash value.


Route Based on IP Hash: This policy uses source and destination IP to determine on which physical NIC traffic will be send. It knows the best path to send traffic on and it is unaware load on the link.

This policy is complex compared to other policies, if not implemented correctly might cause 1 link saturated completely and other is sitting idle. To implement this policy you will have to configure Etherchannel (802.3(AD) Link aggregation) on the Physical switch. Beacon probing cannot be used with policy as all links are in Etherchannel and considered as single link. 




Route Based on physical NIC load: This is my favorite load balancing policy, it is only available on Distributed vSwitches. In the initial works as same as Route based on originating virtual port ID, maps vm port to physical NIC but as soon as it detects Physical NIC load reaches threshold of 75% over 30 Sec, it load balances traffic to another less saturated Physical NIC.



Explicit failover order: In this policy you are defining the active NIC and standby NIC. Generally speaking it in not doing any kind of load balancing. Standby will be used only when the active NIC fails. As earlier I gave bad design example in the Originating virtual port ID, you can correct it with this policy keeping 10 GBps in active and 1 GBps as standby.

VMware Networking 101: VMware Network Load Balancing policies – Part 1
VMware Networking 101: VLAN handling in vSwitches – Part 2
VMware Networking 101: Network Failure Detection – Part 3
VMware Networking 101: vSwitches or PortGroup Security Settings – Part 4
Disclaimer:

This is a personal weblog. The opinions expressed here represent my own. If you find any correction need to be done or anything inappropriate, Feel free to comment on the post.