On 06.05.2009 14:35, jean-frederic clere wrote: > Jess Holle wrote: >> Rainer Jung wrote: >>> Yes, I think the counter/aging discussion is for the baseline, i.e. when >>> we do not have any information channel to or from the backend nodes. >>> >>> As soon as mod_cluster comes into play, we can use more up-to-date real >>> data and only need to decide how to interprete it and how to interpolate >>> during the update interval. >>> >> Should general support for a query URL be provided in >> mod_proxy_balancer? Or should this be left to mod_cluster? > > Can you explain more? I don't get the question. > >> Does mod_cluster provide yet another approach top to bottom (separate >> than mod_jk and mod_proxy/mod_proxy_ajp)? > > Mod_cluster is just a balancer for mod_proxy but due to the dynamic > creation of balancers and workers it can't get in the httpd-trunk code > right now. > >> It would seem nice to me if mod_jk and/or mod_proxy_balancer could do >> health checks, but you have to draw the line somewhere on growing any >> given module and if mod_jk and mod_proxy_balancer are not going in >> that direction at some point mod_cluster may be in my future. > > Cool :-)
There are at several different sub systems, and as I understood mod_cluster it already carefully separates them: 1) Dynamic topology detection (optional) What are our backend nodes? If you do not want to statically configure them, you need some mechanism based on either - registration: backend nodes register at one or multiple topology management nodes; the addresses of those are either configured, or they announce themselves on the network via broad- or multicast). - detection: topology manager receives broad- or multicast packets of the backend nodes. They do not need to know the topology manager, only the multicast address More enhanced would be to already learn the forwarding rules (e.g. URLs to map) from the backend nodes. In the simpler case, the topology would be configured statically. 2) Dynamic state detection a) Livelyness b) Load numbers Both could be either polled by (maybe scalability issues) or pushed to a state manager. Push could be done by tcp (the address could be sent to the backend, once it was detected in 1) or defined statically). Maybe one would use both ways, e.g. push for active state changes, like when an admin stops a node, poll for state manager driven things. Not sure. 3) Balancing Would be done based on the data collected by the state manager. It's not clear at all, whether those three should be glued together tightly, or kept in different pieces. I had the impression the general direction is more about separating them and to allow multiple experiments, like mod_cluster and mod_heartbeat. The interaction would be done via some common data container, e.g. slotmem or in a distributed (multiple Apaches) situation memcache or similar. Does this make sense? Regards, Rainer
