Bonjour Luc, many thanks for the sample snippet. I am afraid, I couldn't reply yesterday. I will give your suggestion a try. Especially, since I want to assure that failback of a relocated service is disabled, what according to the RHCS admin guide is only applicable to ordered failover domains (i.e. cited from RHCS AG "The failback characteristic is applicable only if ordered failover is configured.") http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html /Cluster_Administration/s1-config-failover-domain-CA.html > > ...and you can have more informations about options on RHCS admin guide > I don't agree. In fact the RHCS AD is quite telling the opposite to your proposal by demanding: "To configure a preferred member, you can create an unrestricted failover domain comprising only one cluster member. Doing that causes a cluster service to run on that cluster member primarily (the preferred member), but allows the cluster service to fail over to any of the other members." So here they claim that it has to be an *unordered* failover domain with only *one* member. Sadly, they even don't care to further elaborate by e.g. providing a mor illustrative config code sample. Because I had configuered my failoverdomains according the above cited statement in RHCS AG to achieve stickyness I was more than surprised to observe the service to failback after it already had been relocated after I had rebooted the node it currently and preferredly ran on. Rgds Ralph ________________________________ From: linux-cluster-bounces@xxxxxxxxxx [mailto:linux-cluster-bounces@xxxxxxxxxx] On Behalf Of Santeramo Luc Sent: Friday, June 24, 2011 9:57 AM To: linux-cluster@xxxxxxxxxx Subject: Re: How to achieve a service's "stickyness" toa"preferred" node in RHCS? Hi, <failoverdomains> <failoverdomain name="FOD_srv1" nofailback="1" ordered="1" restricted="1"> <failoverdomainnode name="srv1" priority="10"/> <failoverdomainnode name="srv2" priority="20"/> </failoverdomain> <failoverdomain name="FOD_srv2" nofailback="1" ordered="1" restricted="1"> <failoverdomainnode name="srv1" priority="20"/> <failoverdomainnode name="srv2" priority="10"/> </failoverdomain> </failoverdomains> <service autostart="1" domain="FOD_srv1" exclusive="0" name="SVC_001" recovery="relocate"> <ip ref="10.100.0.8"/> </service> SVC_001 will be sticked to Failover Domain "FOD_srv1", which have node srv1 as priority node. ...and you can have more informations about options on RHCS admin guide. Luc ________________________________ Le 24/06/2011 09:17, Ralph.Grothe@xxxxxxxxxxxxxx a écrit : Hello Clustering Gurus, I need to have a service during normal operation (i.e. not during relocation when loss of stickyness is ok and wanted) stick to a preferred cluster node. (n.b. this is only a two-node cluster) In the redhat cluster admin guide (we're on RHEL 5.6) I think to have read that such thing as a "preffered_node" or similar attribute doesn't exist in the schema any more and that instead one should define ordered="0" and restricted="0" failover domains for the respective service as this would in effect result in the wanted behavior. Is this correct? And how (e.g. a short cluster.conf XML example snippet would be appreciated) would this have to be applied? Regards Ralph -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster P Pensez à l'environnement avant d'imprimer ce message Think Environment before printing Le contenu de ce mél et de ses pièces jointes est destiné à l'usage exclusif du (des) destinataire(s) désigné(s) comme tel(s). En cas de réception par erreur, le signaler à son expéditeur et ne pas en divulguer le contenu. L'absence de virus a été vérifiée à l'émission, il convient néanmoins de s'assurer de l'absence de contamination à sa réception. The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email in error please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies. eSafe scanned this email for viruses, vandals and malicious content. -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
