Serviciul contine doar definitia unei adrese IP de genul:
<ip address="10.10.10.101" monitor_link="1"/>iar colegii mei s-au aratat mirati de acest lucru.
Verificand logurile de cluster am gasit ca aproximativ 10 secunde sunt "pierdute" la oprirea serviciului:
Jul 1 12:44:37 node2 clurgmgrd[9896]:Stopping service service:ipA Jul 1 12:44:37 node2 clurgmgrd: [9896]: Removing IPv4 address 10.10.10.101/24 from eth2 Jul 1 12:44:47 node2 clurgmgrd[9896]: Service service:axigenA is stopped Jul 1 12:44:47 node2 clurgmgrd[9896]: Sent remote-start request to 1 Jul 1 12:44:50 node2 clurgmgrd[9896]: Service service:axigenA is now running on member 1
Am facut o scurta verificare in script-ul asociat resursei IP (ip.sh) si am descoperit cauza:
# XXX Let nfsd/lockd clear their queues; we hope to have a # way to enforce this in the future if [ -z "$OCF_RESKEY_sleeptime" ]; then sleep 10 else if [ "$OCF_RESKEY_sleeptime" -gt "0" ]; then sleep $OCF_RESKEY_sleeptime fi fi
Tentatia a fost sa modificam sleep 10 in sleep 3 insa am gasit ca exista parametrul sleeptime care poate fi specificat pentru respectiva resursa:
<parameter name="sleeptime"> <longdesc lang="en"> Amount of time to sleep after removing an IP address. Value is specified in seconds. Default value is 10. </longdesc> <shortdesc lang="en"> Amount of time (seconds) to sleep. </shortdesc> <content type="string"/> </parameter>
Am modificat resursa respectiva in fisierul cluster.conf de pe unul din noduri si am vrut sa propagam configuratia catre restul nodurilor (prin intermediul system-config-cluster) insa am avut surpriza sa constatam ca fisierul este considerat invalid.
Dupa cateva cautari am gasit raportul unui bug, raportat inca din Martie 2009. Dupa adaugarea in fisierul cluster.ng a unei reguli de validare pentru parametrul sleeptime totul a fost in regula.
