Helllo Florian, Thanks!
So basically when the kamailio process stops on the primary server, the IP's are migrated to the secondary server and kamailio is restarted on the secondary server, is that correct? Also, do when I manually restart kamailio back on the primary server, the IP's will automatically be migrated back to the primary? What will happen with the kamailio process still running on the secondary server? Do I have to stop this one manually? Grant -----Original Message----- From: Florian Crouzat [mailto:gen...@floriancrouzat.net] Sent: Tuesday, February 19, 2013 2:20 PM To: pacemaker@oss.clusterlabs.org Subject: Re: [Pacemaker] Monitor process, migrate only ip resources Le 19/02/2013 13:54, Grant Bagdasarian a écrit : > Hello, > > I wish to monitor a certain running process and migrate floating IP > addresses when this process stops running. > > My current configuration is as following: > > crm(live)configure# show > > node $id="8fe81814-6e85-454f-b77b-5783cc18f4c6" proxy1 > > node $id="ceb5c90f-ee6a-44b9-b722-78781f6a61ab" proxy2 > > primitive sip_ip ocf:heartbeat:IPaddr \ > > params ip="10.0.0.1" cidr_netmask="255.255.255.0" nic="eth1" > \ > > op monitor interval="40s" timeout="20s" > > primitive sip_ip_2 ocf:heartbeat:IPaddr \ > > params ip="10.0.0.2" cidr_netmask="255.255.255.0" nic="eth1" > \ > > op monitor interval="40s" timeout="20s" > > primitive sip_ip_3 ocf:heartbeat:IPaddr \ > > params ip="10.0.0.3" cidr_netmask="255.255.255.0" nic="eth1" > \ > > op monitor interval="40s" timeout="20s" > > location sip_ip_pref sip_ip 100: proxy1 > > location sip_ip_pref_2 sip_ip_2 101: proxy1 > > location sip_ip_pref_3 sip_ip_3 102: proxy1 > > property $id="cib-bootstrap-options" \ > > dc-version="1.0.8-042548a451fce8400660f6031f4da6f0223dd5dd" \ > > cluster-infrastructure="Heartbeat" \ > > stonith-enabled="false" > > Couple days ago our kamailio process stopped and the ip resources > weren't migrated to our secondary node. Of course, why would they ? > > The secondary node already has the kamailio process running. First, you remove kamailio from runlevel so that it doesn't start on server boot and only the cluster manages it. > > How do I configure ha so that the kamailio process is monitored every > x seconds and when it has stopped the three ip addresses are migrated > to the secondary node? Then, you define a kamailio resource (possibly by using lsb:kamailio is there is not a real resource-agent). Finally, you create a group with your 3 IPs + kamailio. Remember, groups are ordered and collocated set of resources that starts from left to right, and are stopped in the opposite order. Possibly, you define a location constraint for the group to prefer proxy1. In the end, it might be something like: ... primitive sip_ip ocf:heartbeat:IPaddr \ params ip="10.0.0.1" cidr_netmask="255.255.255.0" nic="eth1" \ op monitor interval="40s" timeout="20s" primitive sip_ip_2 ocf:heartbeat:IPaddr \ params ip="10.0.0.2" cidr_netmask="255.255.255.0" nic="eth1" \ op monitor interval="40s" timeout="20s" primitive sip_ip_3 ocf:heartbeat:IPaddr \ params ip="10.0.0.3" cidr_netmask="255.255.255.0" nic="eth1" \ op monitor interval="40s" timeout="20s" primitive kamailio lsb:kamailio \ op monitor interval="40s" timeout="20s" group SIP sip_ip sip_ip_2 sip_ip_3 kamailio location SIP_prefer_proxy1 SIP 100: proxy1 ... Note that with such as config, kamailio is restarted when it is migrated, which I assumed is something you want, so that it can bind on the sip_ip ... -- Cheers, Florian Crouzat _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
