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]> 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 (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 and not at > 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]> 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]> 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/ > >
