[Linux-cluster] Resource tree in service?

Jakov Sosic jsosic at srce.hr
Mon Feb 18 18:25:07 UTC 2013


Hi.

First of all, I'm running CentOS 6.3. Now, my problem is the following.
I have this kind of resource tree in my service:

<service autostart="0" domain="domain12" name="pgmaster">
   <ip ref="192.168.50.101">
      <ip ref="10.200.200.101">
         <fs ref="intern">
            <postgres-8 ref="pgmaster"/>
         </fs>
      </ip>
   </ip>
</service>


This configuration in cluster.conf starts postgresql in a way that
database listens only on the first ip address of the service
(listen='192.168.50.101').

If I reorder the code to look like this:


<service autostart="0" domain="domain12" name="pgmaster">
   <fs ref="intern">
      <ip ref="192.168.50.101">
         <ip ref="10.200.200.101">
            <postgres-8 ref="pgmaster"/>
         </ip>
      </ip>
   </fs>
</service>

then postgres can't even start because no IP address was found (listen='').

So, script obviously checks only first level of hierarchy in the
cluster.conf.

I've examined the script further, and found out that postgres-8.sh uses
bash function 'build_ip_list()' from "config-utils.sh" script.

That function iterates through ip's, by using ccs_tool, like this:

# ccs_tool query '/cluster/rm/service[@name="pgmaster"]/ip[$x]/@ref'

$x is integer that equals 1, and is being iterated until ccs_tool
returns error.

In the first case presented, this is the output that I get:

# ccs_tool query '/cluster/rm/service[@name="pgmaster"]/ip[1]/@ref'
192.168.50.101

# echo $?
0

# ccs_tool query '/cluster/rm/service[@name="pgmaster"]/ip[2]/@ref'
Query failed: Invalid argument

# echo $?
1


Now, for the current state of scripts to work ok, I have to model my
service in this manner:

<service autostart="0" domain="domain12" name="pgmaster">
   <ip ref="192.168.50.101"/>
   <ip ref="10.200.200.101"/>
   <fs ref="intern">
      <postgres-8 ref="pgmaster"/>
   </fs>
</service>

Now both IP addresses get figured out by ccs_tool query, and postgresql
starts fine with listen='192.168.50.101,10.200.200.101'.


My question is, is this a bug, or should I always put all my ip
addresses at the root level of service hierarchy, out of dependency tree?

And is this a problem for a service, I mean, what is the ordering in
which resources are started? In this scenario if the order of execution
of resources isn't deterministic but random, there is a possibility for
a service to fail, if IP addresses didn't get up before the service started.

If that's not the case, and if ip addresses have to be in the dependency
relation to other resources, then "config-utils.sh" script should have
to be rewritten, in a way that searches for IP addresses deeply in a
hierarchy and not only at root level...




Thank you for all your comments.




More information about the Linux-cluster mailing list