> >> * we ask users to use a LB with an client ip hash load balancing scheme > >> (ie client are sent always to the same master). > > > > That could work, though it makes rollover more granular and may > > require a more sophisticated LB setup. If puppetmasters can come on > > and off line without requiring a system-wide hiatus, the LB is going > > to have to be pretty savvy. > > On the couple of commercial grade load balancers I've used (mostly F5) this > kind of sophistication is standard fare. Typically you define a functional > health check (open a TCP connection, do an HTTP request, that sort of thing) > that is used to determine if a given server is functional. If it fails the > health check, the server is pulled out of the pool until it starts passing > again, and all of its clients get redirected to new backend servers.
The problem is we're talking about using it to maintain a stateful association between the client and the puppetmaster. If a client sends its facts to a server before it goes down, the backup server isn't going to have access to those facts; likewise, if a client sends its facts to a backup server right before the primary comes back on line. And so on. The problem isn't determining if a server is functional (that part, as you note, is standard) it's dealing with the statefulness of client/ server bindings and doing the right thing when those change. -- Markus -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
