In the previous blog, we investigated the basic feature set of #NSX Load Balancing, some of the business reasons to use it, and deployed an ESG (Edge Services Gateway), the NSX load balancing platform. Today, we are going to setup our first virtual server. When we look at load balancing, it operates at the Transport layer or above of the OSI model and is inclusive of the network layer. In the most basic of terms, Load Balancing looks at a “session” from the transport layer and applies a load balancing algorithm and a NAT policy to the traffic. I put “session” in quotes because we can load balance both TCP and UDP based applications, but UDP does not have a stateful session, but we can still load balance UDP services.
Whenever someone has stated that and given application cannot be load balanced, I first ask them if the traffic can be processed by a NAT at either the client or server end. If the answer is yes, odds are that it can be load balanced with sufficient understanding of the application and the required ports, protocols and persistence to make the application function correctly. This is true with all load balancing platforms, but there are some corner cases where a very specific application proxy is required to function (such as SIP), so engage your partner SE or #VMware #NSX SE for help. Ultimately you need to combine the knowledge of how the application functions and what it takes to bend the packets in the network to meet those requirements.
http://www.dabcc.com/vmware-nsx-load-balancing-accelerated-layer-4-virtual-servers/
No comments:
Post a Comment