I've been testing DNS service discovery and the use of SRV records and have
a few thoughts on a couple things that I noticed.
1. Reloading with SRV records ignores server-state-file
- While this is not a huge deal, it does mean that the backend in
question becomes unavailable when the proxy is reloaded until the SRV and
subsequent A records are resolved
- I understand that the point of these records is to dynamically build
the backend, and populating servers from outdated and potentially invalid
information is not ideal, but it might be nice to seed the backend before
the first SRV query returns
- Below is the related config since it is very likely that I have
misconfigured something :)
globals
...
server-state-base /var/lib/haproxy
server-state-file state
defaults
...
load-server-state-from-file global
default-server init-addr last,libc,none
...
resolvers sd
nameserver sd 127.0.0.1:9999
backend dynamic
server-template srv 5 _http._tcp.serviceA.tait.testing resolvers sd
resolve-prefer ipv4 check
2. Additional record responses from the nameserver are not parsed
- This just means that any servers that are populated from the SRV
records require a second round of querying for each of the hosts after the
fqdn is stored. It might be more efficient if these records are also parsed
but I can see that it might be pretty challenging in the current DNS
resolver
- Only reason I thought of this was to try and reduce up the time it
takes to populate the backend servers with addresses in an effort to lessen
the effects of #1
I'm happy with the workaround I'll be pursing for now where my SD service
(that originally was going to be a resolver and populate via SRV records)
is going to write all the backend definitions to disk so this is not a
pressing issue, just thought I'd share the limitations I discovered. My
knowledge of C (and the internal workings of HAproxy) is not great
otherwise this would probably be a patch submission for #1 :)
Tait
