[Linux-cluster] How to achieve a service's "stickyness" toa"preferred" node in RHCS?

[Ralph.Grothe at itdz-berlin.de]

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 at redhat.com
[mailto:linux-cluster-bounces at redhat.com] On Behalf Of Santeramo
Luc
	Sent: Friday, June 24, 2011 9:57 AM
	To: linux-cluster at redhat.com
	Subject: Re: [Linux-cluster] 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 at itdz-berlin.de 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 at redhat.com
	
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.