On 11/26/2009 8:36 PM, Markus wrote:
>
>>>> * 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.
Ah, I understand what you mean now. At least in the case of F5 load
balancers, I'm not sure if it's the default for source IP session persistence,
but it's quite possible to set them up so that the source IP is used as a key
into a persistent state table that maintains the client to backend server
mappings. HTTP session persistence is a pretty common problem in the load
balancing world, so as long as puppet clearly spells out its requirements, it
should be possible to set things up to meet them.
Alternatively, I haven't looked deeply enough, but if puppet uses a single TCP
socket for the entire lifetime of a run, then you could set up the load
balancer to operate on the TCP layer instead of digging into the HTTP(S)
layer. That way, since the load balancer sees everything as a single atomic
TCP session, there's no possibility for it to send different requests to
different backend servers within a single run.
--
Frank Sweetser fs at wpi.edu | For every problem, there is a solution that
WPI Senior Network Engineer | is simple, elegant, and wrong. - HL Mencken
GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC
--
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.
