Darren, thx for your comments. some answers/reflection below:
On 10/26/08 19:43, Darren Reed wrote: > 9.1 - Health Checks. > Mentioning "root" here is not correct. > Administration of ilbd should be defined through RBAC. > > You list 7 privileges as required by ilbd but only one > as being checked by the kernel. Why? > > 9.2 - External Methods > It sounds like the external method is fork'd every time > the health check is activated. With enough servers, this > could become a significant system overhead. for the initial phase, which we're tentatively planning to release next year, this is true. Later on, we plan to implement a few basic tests in a more efficient way to avoid this overhead. > You may wish > to include some configuration option where the external > method just keeps printing data on stdout. this is certainly an option, something I'll keep in mind for the next phase, but nothing we've currently got in mind. > If this is > what is meant by the design then it needs some editing. no, it's not. see above. > Health Checks. > ============== > This design has a single daemon, with a single thread, > that polls multiple servers to update a single pool of > data in the kernel. > > If we assume that the in-kernel handling of requests > from the daemon enforces MP-safety, why not run multiple > daemons? actually, it's the daemon that will serialise access to the kernel. > i.e. run an ilbd per back end server (or at least a > thread per back-end server.) You might still need a > single daemon to act as the manager? *shrug* this sounds like you're replacing the load of repeatedly starting health check processes by having as many processes sitting around idly a lot of the time. Since in the current design ilbd maintains quite a bit of state, one would indeed have to coordinate all the information to be able to get the "complete" picture again, so the added benefit seem a little elusive to me here. > This does away with the need to use poll/select/event_port > as each thread/daemon is reponsible for just one destination. as you hinted at yourself, not really. > This should also remove the ilbd main-loop from being a > critical section of code, where slow down from dealing > with one external server can impact all of the others. > Instead, scheduling of work is left up to the kernel to > schedule threads/processes, depending on who's busy or > blocked, etc. anything that we expect to block (health check) is farmed out to processes, so that happens anyway. Michael -- Michael Schuster http://blogs.sun.com/recursion Recursion, n.: see 'Recursion' _______________________________________________ networking-discuss mailing list [email protected]
