I decided to add some high availability to my lab's DNS architecture. I currently have a physical DNS server but have decided to add a secondary server within my ESXi environment. Why not take this as an opportunity to experiment with load balancers? I decided to configure two virtual DNS servers and load balance the UDP traffic using the free and open source Zen Load Balancer. Check out my topology below.
 |
| Virtualized Load Balancer/DNS Environment |
From within ESXi, I have set up two virtual DNS servers (above). Both devices have zone information that has been replicated from the current physical DNS server; Server A (10.10.2.61) and Server B (10.10.2.62). Most people tend to deploy load balancers for SSL and HTTP and tend to go with other options such as HAProxy when they want to do it for free. I chose to deploy Zen Load Balancer (ZLB) Community Edition as my application delivery controller (ADC) to lab with as it appeared to support the most protocols (UDP for this case) and offers more flexibility. You can read more about ZLB and download the latest ISOs from http://www.zenloadbalancer.com/. Of course there are also your higher-end ($$$) load balancers from F5, Citrix, Kemp, A10, and Barracuda just to name a few that do a lot more.
I deployed ZLB within ESXi and after completing the simple install, I simply gave an IP address to the load balancer (10.10.2.160). To manage the appliance, you simply navigate to the management console in a web browser through the URL https://xxx.xxx.xxx.xxx:444 (where xxx is your statically assigned IP or FQDN if you have that registered). The default user name and password is admin and admin. Being the security conscious, aspiring engineer that you are, I have the utmost confidence that you will change this.
 |
| Zen Load Balancer Community Edition Console |
The next thing to do was to configure my server farms. The server farms are simply the servers that ZLB (or any other ADC/LB) will balance connections for; also known as back-end servers. In Zen, the server farms are configured based on protocol and port number. In this instance, I simply named mine dnsfarm and added both of my newly configured DNS servers (10.10.2.61 and 62).
 |
| Managing Server Farms in ZLB |
The Virtual IP (10.10.2.59) represents the IP address that all servers in the farm will share for balancing purposes. You will also notice that my profile for this farm is UDP based using port 53. During configuration of the farm, you will be given a number of options for load-balancing. I left mine at the default of round-robin. You will also be allowed to set thresholds. In my current configuration, connections will be split evenly between both servers.
Some time into my configuration, I decided to utilize this architecture as my primary DNS. So on my DHCP server, I made sure to specify that the virtual IP of the server farm (10.10.2.59) would be assigned to clients, NOT the actual IP address of the individual servers themselves. You want your requests to go to the load balancer first; not directly to the back-end servers.
Below, you can see each server added to the farm. This can be viewed by selecting View <farm-name> backends Status from the Action section of the Farms table. The entire farm can be started and stopped, as it is essentially a service.
 |
| Back-End (Real) Servers |
You can see the active servers as well as the number of clients being load balanced over each. Basically the clients are sending all DNS requests to 10.10.2.59 (the virtual IP of the load balancer) and from there it is evenly distributing the requests to the back-end DNS servers. Check out the statistics below.
 |
| Monitoring Load Balancing Statistics |
The final piece to the puzzle was adding another load balancer for HA just for good measure. A load balancer is a device designed to enable high availability but can, in itself, become a single point of failure (SPoF) if implemented without a secondary.
Configuring the secondary load balancer was even more simple than the first, as all you need to do is whip up a second virtual appliance, and give both devices a another, separate virtual IP for clustering. Once they are synced via RSA connection, the secondary will conveniently copy the configuration from the primary rather than requiring manual configuration.
 |
| ZLB Clustering |
You can configure various clustering scenarios including Active/Standby and Active/Active. For now, I chose to go with Active/Standby for simplicity. Any fault in the primary and fail-over is almost instantaneous. You can also force the primary into backup for maintenance which will automatically bring the secondary online as primary or the master of the cluster. This configuration also supports auto-fail-back.
My install was not without issue. I did have a couple of problems with the clustering service and some arp issues with the virtual IP (that was mostly back on my Cisco gear's cache). Overall, the ZLB installation and deployment is relatively painless.
There you have it. That's my Zen experience in a nutshell. As you can see, it is very easy to set up and to configure and has a few other features such as the ability to backup your configuration and restore from backup. Zen can also can serve as sort of a link balancer via the datalink type farm, whereby an admin can configure Zen to load balance internet or WAN connections to upstream edge/gateway routers. My configuration is probably not the most efficient or polished (at the moment), but it is my first extended experience with a load balancer.
I definitely would not deploy the community edition of Zen (or almost anything else) in a production enterprise environment, but I would highly recommend using it for lab use. There is also a professional version for those wanting to dive deeper and consider using this for their business environment. You can learn more about deploying ZLB from http://www.zenloadbalancer.com/zlb-administration-guide-v304/ and also by searching for some of the helpful videos on YouTube.
Feel free to comment and let me know what you think of Zen Load Balancer as well as any experience you have had with load balancers in your lab or even at work.
