Ah, cool, thanks very much, that seems to go a long way to filling the holes in my knowledge. (And thanks, Илья, too.)
This leaves only a second piece of my question: am I being reasonable running multiple services through one (pod of) haproxies and letting the haproxies (all with the same config) tease them apart based on host name and maybe part of path? Jeff On 20/05/2019 17:48, Alex Evonosky wrote: > example: > > pod1: > > primary: 1.1.1.2 > secondary: 1.1.1.3 > virtual: 1.1.1.1 > > > pod2: > > primary: 1.1.1.5 > secondary: 1.1.1.6 > virtual: 1.1.1.4 > > > The mechanism to utilize the virtual IP is VRRP (apps like keepalived). > > > Then on the DNS server, you can use A records for 1.1.1.1 and 1.1.1.4 > > > On Mon, May 20, 2019 at 11:37 AM Jeff Abrahamson <[email protected] > <mailto:[email protected]>> wrote: > > Thanks, Alex. > > I'd understood that, but not the mechanism. Each host has an A > record. Did I miss a DNS mapping type for virtual addresses? Or > do the two hosts run a protocol between them and some other > party? (But if one of my haproxies dies, what is the mechanism of > notification?) > > Said differently, I'm a client and I want to send a packet to > service.example.com <http://service.example.com> (a CNAME). I do > a DNS lookup, I get an IP address, 1.2.3.4. (Did the CNAME map > only to 1.2.3.4?) I establish an https connection to 1.2.3.4. > Who/what on the network decides that that connection terminates at > service2.example.com <http://service2.example.com> and not at > service1.example.com <http://service1.example.com>? > > Does this mean that letsencrypt is incapable of issuing SSL certs > because my IP resolves to different hosts at different moments? > > Sorry if my questions are overly basic. I'm just trying to get a > grip on what this means and how to do it. > > Jeff > > > On 20/05/2019 17:12, Alex Evonosky wrote: >> Jeff- >> >> ViP - Virtual IP. this is a shared IP between nodes. One node >> is primary and the other is hot-standby. If the heartbeat fails >> between the two, then the secondary becomes primary. >> >> The end application/user only needs to know about the virtual >> IP. So in DNS, you can create X amount of these pods to >> distribute the load among the pods. >> >> >> and we run this setup in Apache mesos with about 100 dockers and >> 4 Ha proxy pods. >> >> >> >> >> On Mon, May 20, 2019 at 10:49 AM Jeff Abrahamson <[email protected] >> <mailto:[email protected]>> wrote: >> >> Thanks. Have you tried that, bringing down an haproxy during >> some high load period and watching traffic to see how long it >> takes for traffic all to migrate to the remaining haproxy? >> My fear (see below) is that that time is quite long and still >> expose you to quite a lot of failed clients. (It's better >> than losing one's sole haproxy, to be sure.) >> >> In any case, and more concretely, that raises a few >> additional questions for me, mostly due to my specialty not >> being networking. >> >> *1. VIP addresses.* I've not managed to fully understand >> how VIP addresses work. Everything I've read either (1) >> seems to be using the term incorrectly, with a sort of short >> TTL DNS resolution and a manual fail-over, or (2) requires >> that the relevant servers act as routers (OSPF >> <https://en.wikipedia.org/wiki/Open_Shortest_Path_First>, >> etc.) if not outright playing link-level tricks. On (1), we >> try to engineer our infra so that our troubles will be >> handled automatically or by machines before being handled by >> us. I worry that (2) is a long rabbit hole, but I'd still >> like to understand what that rabbit hole is, either in case >> I'm wrong or so that I understand when it's the right time. >> >> *2. RR DNS. *People talk about RR DNS for availability, but >> I've seen no evidence that it's applicable beyond load >> balancing. Indeed, RFC 1794 >> <https://tools.ietf.org/html/rfc1794> (1995) only talks about >> load balancing. As long as the haproxy hosts are all up, >> clients pick an address at random (I think, I haven't found >> written evidence of that as a client requirement.) But if an >> haproxy goes down, every client has to time out and try again >> independently, which doesn't make me happy. It might still >> be the best I can do. >> >> I'm very open to pointers or insights. And I'm quite aware >> that the relationship between availability and cost is >> super-linear. My goal is to engineer the best solutions we >> can with the constraints we have and to understand why we do >> what we do. >> >> Anecdotally, I noticed a while back that Google and others, >> which used to have DNS resolutions from one name to multiple >> IP's, now resolve to a single IP. >> >> Jeff Abrahamson >> http://p27.eu/jeff/ >> http://transport-nantes.com/ >> >> >> On 20/05/2019 15:04, Alex Evonosky wrote: >>> You could make it a bit more agile and scale it: >>> >>> you can run them in "pods", such as two haproxy instances >>> running keepalived between them and use the ViP IP as the >>> DNS record, so if an HAproxy instance was to die, the >>> alternate HAproxy instance can take over. Set more pods up >>> and use DNS round robin. >>> >>> >>> >>> On Mon, May 20, 2019 at 8:59 AM Jeff Abrahamson <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> We set up an haproxy instance to front several rails >>> servers. It's >>> working well, so we're quickly wanting to use it for >>> other services. >>> >>> Since the load on the haproxy host is low (even >>> miniscule), we're >>> tempted to push everything through a single haproxy >>> instance and to let >>> haproxy notice based on requested hostname to which >>> backend to dispatch >>> requests. >>> >>> Is there any good wisdom here on how much to pile onto a >>> single haproxy >>> instance or when to stop? >>> >>> -- >>> >>> Jeff Abrahamson >>> http://p27.eu/jeff/ >>> http://transport-nantes.com/ >>> >>> >>> >>> >> -- >> >> Jeff Abrahamson >> +33 6 24 40 01 57 >> +44 7920 594 255 >> >> http://p27.eu/jeff/ >> http://transport-nantes.com/ >> > -- > > Jeff Abrahamson > +33 6 24 40 01 57 > +44 7920 594 255 > > http://p27.eu/jeff/ > http://transport-nantes.com/ > -- Jeff Abrahamson +33 6 24 40 01 57 +44 7920 594 255 http://p27.eu/jeff/ http://transport-nantes.com/
