Home / server / Questions / 486520
In Process
Glenn Slaven
Asked: 2013-03-11 17:46:58 +0800 CST

How does mod_proxy determine which IP address to load from when there are multiple A records

  • 772

So I have mod_proxy setup pointing at 

ProxyPass / http://www.mydomain.com/
ProxyPassReverse / http://www.mydomain.com/

and www.mydomain.com has 4 A records (ie DNS load balancing) will mod_proxy pick 1 ip from that list for all it's worker processes and expire on the ttl of the DNS record, or will each worker process pick its own IP from that list?

I'm setting up a proxy sitting in front of a web server that is using this DNS load balancing, and I don't want to have to hard-code their IP addresses into BalancerMember directives as then they can't add & remove IP addresses without changing the proxy too.

domain-name-system

1 Answers

  1. I don’t think mixing DNS load balancing & mod_proxy load balancing will help anything. The IP choice in DNS load balancing is independent of any Apache settings you have so your load balancer will be at the mercy of whatever DNS IP address comes up when it rolls the dice.

    I would suggest that you really rethink this & instead do the following:

    1. For the servers you already have set as A records, change them all to also respond to differently named DNS entries such as www0.mydomain.com & www1.mydomain.com and such.
    2. Set up the Apache configs for www0.mydomain.com & www1.mydomain.com to only deliver content to the IP of your load balancer.
    3. Configure your load balancer to respond to www.mydomain.com and set the mod_proxy setup to utilize www0.mydomain.com & www1.mydomain.com

    This is really the only way to truly use a real load balancing solution. Because honestly DNS load balancing is a sloppy mess that I have never seen work well in practice in my 20+ years of doing web & Unix work. Apache mod_proxy is a bit tricky to setup, but the setup works very well & gives you more future options than you might even use; very future proof & scalable.

    Good luck!

    • 0