CODEWITHSUNDEEP
cloudbees
yash.vyas
yash.vyas

Reputation: 163

Enterprise Jenkins HA plugin not working as it should

I've been trying to setup Enterprise Jenkins with the High Availabilty setup. The current setup consists of two jenkins masters sharing the same jenkins home, say master1 and master2, an installation of the jenkins-ha-monitor-1.1-1.1 rpm on both these masters, say monitor1 and monitor2. With this setup, according to the documentation atleast, the HA plugin should work as expected. Promotion and demotion scripts are similar to the ones in the documentation (only the ip and interface is different, same approach). i.e

For demotion

ifconfig eth0:2 down

For promotion

ifconfig eth0:2 the.floating.ip

Now for the nodes to get registered correctly I have to start master1, master2, monitor1 and monitor2 in that order. Tailing the logs for both I see that when the services are started in that order they are registered correctly by both monitor services as nodes in a cluster, and in the HA status gui in the jenkins console.

Now when master1 is killed by sending it a KILL signal monitor2 recognizes this and runs the promotion script. But monitor one keeps throwing :

Oct 24, 2012 3:47:36 PM com.cloudbees.jenkins.ha.singleton.HASingleton$3 suspect INFO: Suspecting a node failure in a cluster: jenkins-master-1-285 Oct 24, 2012 3:47:39 PM com.cloudbees.jenkins.ha.singleton.HASingleton$3 suspect INFO: Suspecting a node failure in a cluster: jenkins-master-1-285

continuously without ever runnign the demotion script. Now since master2 has taken up the floating ip via its promotion script, and master1 still has that ip because demotion script is not run the setup ends up with two boxes claiming the same ip. Moreover restarting master1 does not do anything, i.e master1 does not get added to the cluster as a seconday node, monitor1 still keeps spitting the above messages to log, the floating ip keeps returning "Unable to connect" and master2 and monitor2 show the cluster as master2,monitor2 and monitor1. So my question/problem is twofold - why isnt master1 accepted back into the cluster? And why isn't the demotion script run as it should?

Also FYI i have tried to do a

service jenkins stop

and in that case the demotion script runs but again there are similar issues when

service jenkins start

is run on the master that was stopped earlier since the promotion script is run regardless of whether a primary jenkins exists. And in this case the two monitors register different clusters like so monitor1 : master1,monitor1 and monitor2 : master2,monitor2. Running an ifconfig shows that both masters have taken up the floating ip at this point.

Any help is appreciated! Thanks!

Upvotes: 4

Views: 822

Answers (1)

Jesse Glick
Jesse Glick

Reputation: 25461

Still under investigation with support. The originally reported problem (here) suggests that the two nodes are communicating fine, but promotions/demotions are not run correctly—either a bug in JGroups or in its usage in Jenkins high availability.

But further tests turned up problems with UDP multicast communication, which has been reported for RedHat/CentOS hosts. Work is underway to offer an alternate JGroups stack which does not rely on multicast (or UDP) at all, using the shared $JENKINS_HOME directory to register Jenkins and monitor instances (as TCP address:port records).

Upvotes: 1

Related Questions