Hi Willy, Some time back, I had worked on making health checks being done by only one HAProxy process, and to share this information on a UP/DOWN event to other processes (tested for 64 processes). Before I finish it completely, I wanted to check with you if this feature is useful. At that time, I was able to propagate the status to all processes on UP/DOWN, and state of the servers on the other haproxy processes changed accordingly.
The implementation was as follows: - For a backend section that requires shared health check (and which has nbproc>1), add a new option specifying that hc is "shared", with an argument which is a multicast address that is used to send/receive HC messages. Use difference unique MC addresses for different backend sections. - Process#0 becomes the Master process while others are Slaves for HC. - Process #1 to #n-1 listens on the MC address (all via the existing generic epoll API). - When the Master finds that a server has gone UP or DOWN, it sends the information from "struct check", along with proxy-id, server-id on the MC address. - When Slaves receive this message, they find the correct server and updates it's notion of health (each Slave get the proxy as argument via the "struct dgram_conn) whenever this file-descriptor is ready for reading). There may be other issues with this approach, including what happens during reload (not tested yet), support for non-epoll, or if process #0 gets killed, or if the MC message is "lost", etc. One option is to have HC's done by slaves at a much lower frequency to validate things are sane. CLI shows good HC values, but the gui dashboards was showing server DOWN in GREEN color,and other minor things that were not fixed at that time. Please let me know if this functionality/approach makes sense, and adds value. Thanks, - Krishna
