[Pacemaker] designing a load balancer - request for comments

[Raoul Bhatia [IPAX]]

hi,

On 02/11/2011 05:55 PM, Klaus Darilion wrote:
>> if the clone'd resource properly synchronizes by itself, you only need
>> to migrate the (public) service ip address. a colocation rule will
>> achieve that.
> 
> fine
> 
>> basic clone setup:
>> primitive extip ocf:heartbeat:IPaddr2 \
>>         params ip="a.b.c.d" nic="eth0.123" cidr_netmask="28" \
>>         op monitor interval="30"
>> primitive kamailio ocf:pernau:kamailio \
>>         op monitor interval="30" timeout="30" \
>>         op monitor interval="15" role="Slave" timeout="30" \
>>         op monitor interval="10" role="Master" timeout="30"
>> clone clone-kamailio kamailio
>> colocation colo_extip_with_kamailio inf: extip ms-kamailio
> 
> If I understand it right, this means that extip (the virtual-IP
> resource) must run on a node which also runs ms-kamailio. Shouldn't that
> be 'kamailio' instead of 'ms-kamailio' or is there some implicit
> resource naming happening?

first of all, i made an error when modifying the ms example for
clone. above, it should read "clone-kamailio".

you can only reference the clone or the ms resource and should never,
ever reference one single instance.

what the clones (and the ms) do (actually not exactly true but enough
to illustrate what i want to say):

1. if you clone a resource, like above, the cluster (internally) creats:
kamailio:0, kamailio:1, kamailio:n-1 (n=clone-max) [1]

if you colcate it with clone-kamailio, the cluster knows that you want
to run extip on the same host as a "clone of kamailio" aka kamailio:0
or kamailio:1 is started.

> Additionally I want the virtual-IP to be moved if upstream-connectivity
> of a node is broken. Therefore I used ping as below:
> 
> primitive extip ocf:heartbeat:IPaddr \
>         params ip="11.222.32.161" \
>         op monitor interval="3s"
> primitive pingtest ocf:pacemaker:ping \
>         params host_list="11.222.53.113" multiplier="10" dampen="5s" \
>         op monitor interval="10s"
> clone clonePing pingtest
> location aktiverLB extip \
>         rule $id="aktiverLB-rule" -inf: not_defined pingd or pingd lte 0

sorry, never successfully used ping so i cannot quote on its
functionality. ;)


> So, now I am not sure anymore if I should use "location" or "colocation"
> as constraint to have the virtual-IP only on a node which has
> connectivity. I got the impression that colocation is for binary
> decisions (Kamailio is either running or not) and location for resources
> which may have non-binary score values (eg. ping score can be 0-x if I
> ping x hosts).

location: add more/less weight for a host in regard to running a
resource.
think: "on which servers aka #uname am i allowed to run".

colocation: defines which resources shall/have to or should/must not
run on the very same host.
think: db must not run on the same host as webserver. extip webserver
has to run on the same host as webserver.

> So, will it be correct to just add
> 
> primitive pingtest ocf:pacemaker:ping \
>         params host_list="11.222.53.113" multiplier="10" dampen="5s" \
>         op monitor interval="10s"
> clone clonePing pingtest
> location aktiverLB extip \
>         rule $id="aktiverLB-rule" -inf: not_defined pingd or pingd lte 0
> 
> to your configuration or do I have to change this constraint to a
> "colocation" constraint?

as said, i have never actually used the ping resource.

but i suggest you add a strong colocation rule between extip and
kamailio (and quite possibly extip and ping or kamailio and ping),
because it might happen that one node isn't able to start kamilio
(e.g. config error during upgrade) so you do not want extip to
"accidentally" run on this host.


so once more: read the documentation and some of the tutorials
in the wiki and then try and play around to get a feeling for
pacemaker.

btw, handy tools are: drbd-mc
showscores.sh to fetch a resource's score -> higher score for a node
-> more likely to run the resource there.
(available from the hg repository) and
ptest -G/ptest -D to create a diagram of what the cluster is going to do


cheers,
raoul


[1]
http://www.clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/ch10s02s02.html
-- 
____________________________________________________________________
DI (FH) Raoul Bhatia M.Sc.          email.          r.bhatia at ipax.at
Technischer Leiter

IPAX - Aloy Bhatia Hava OG          web.          http://www.ipax.at
Barawitzkagasse 10/2/2/11           email.            office at ipax.at
1190 Wien                           tel.               +43 1 3670030
FN 277995t HG Wien                  fax.            +43 1 3670030 15
____________________________________________________________________