It’s a couple of weeks ago since I first looked at using the vCNS Edge Gateway to publish my Horizon View environment, and I always intended to double-back to that configuration to play about with the load-balancing features of the Edge Gateway. When myself and Barry Coombs were working on our View book (eucbook.com) I ended up using F5’s BIG-IP as the load-balancing system. I’d always wanted to include the Edge Gateway – but I ran out of time. I wanted to start with a simple load-balancing model of just two static web-servers and cut my teeth there before pressing on with the install/configuration of my second View Security and Connection Servers.
The vCNS Edge Gateway uses the terms “Pool Servers” and “Virtual Server” to describe the load-balancing system. The “pool server” is the collection of VMs in a vApp you want to load-balance – you create a “pool” of these servers. The “virtual server” is the IP address that is used connect by the clients…
In my case the “web” based vApp is itself behind a vApp Network using 192.168.15.x as the address – remember however that every VM within a vApp gets it own “external” address for the Organization Network as well – a vApp isn’t using a vApp Network it just gets an IP address direct from the Organization Network:
These would be my “member” or “virtual servers” so I would need to know these IP addresses. For testing purposes I set these up with a basic “Hello World” page so I could check I could connect to them properly.
To get to the load-balancing options I needed to modify the Organization Network Edge Gateway (the load-balancing tab doesn’t appear on a vApp Network enabled vApp) clicking the “Add” button to add in the “Pool Server”.
The Edge Gateway supports N types of load-balancing algorithm – IP Hash, Round-Robin, URI and Least Connected. These methods might already be familiar to you.
IP Hash basically carries out a computation on the source/destination IP of each packet. Round-Robin basically cycles between servers within the pool, but is possible to weight each virtual server in the pool. This sort of load-balancing is “fairest” of them all as it guarantees an equal distribution of sessions to all the members in the pool itself. URI uses a hash calculation based on the total number of servers in the pool – it makes sure that requests are directed to the same server so long as that server is available. Finally, “Least Connected” measure the number of open/active session to a virtual server in the pool – and directs any new request to least connected server (a method that might be very useful in Horizon View environment). In my case I select the default because I initially I wanted a round robin affect so I could confirm that both my web-servers in the pool would respond correctly.
Common with many load-balancing technologies there’s a “Health Check” feature that confirm if a member in the pool is actually listening and responding to connections. That’s pretty vital. Without it would have sort of circa-1990’s “DNS Round-Robin” that just distributed load by query, without any idea of whether a server is up or down. In my case the port numbers were the same, and set the index.htm as default URI that would be checked to confirm the status of the server.
Finally, all I needed to do next was add the web-servers into the pool under “Manage Members”
Note: It is possible to set the “Ratio Weight” to zero (0). This has the effect of excluding a member from the pool for usage, and could be useful doing upgrades, patch management and essential maintenance on a web-server for example. Of course this member pool list can be used to add additional web-servers or decommission a web-server as well.
The next step was to assign a “virtual server”. That term might seem a bit odd in our virtual world, but in my experience its common term within the world of load-balancers. Where term “virtual server” is used to describe an IP listener on the load-balancing appliance – as opposed to the server(s) in the pool themselves. Sometimes it’s referred to as the “cluster” IP address by other vendors – as each node in the web-server farm is represented by single cluster IP which is used by external clients. I guess here other vendors are substituting the term “pool” for “cluster”.
So under the “Virtual Servers” tab, I clicked the “Add” button – and added in a reference like so using a free IP address from my 172.168.5.x range:
Note: Be careful what you type in the IP Address field. It must be a free and available IP otherwise the Edge Gateway will refuse your configuration. Whatever IP you use it must come from the Organization “Network Specification” and it mustn’t be already in use in the environment. You can check the “Network Specification” by right-clicking the Edge Gateway’s properties:
…and you can see what IP addresses are currently in use in the Organization Network by right-clicking it and selecting the “IP Allocations” option:
The next step is to add in the Virtual Server reference ..
I verified that the “172.168.5.99” address was ping-able, and I was able to test the load-balancing was working as expected by opening a web-browser on 192.168.5.99 and using the [shift key], and right-clicking in FireFox to force a reload of the page.
Having successfully setup load-balancing for a simple web-page I was ready to do the same for my Horizon View environment as well. Installing a replica of Standard Server is very simple – you merely select “replica” server from the install/setup program of the View software.