<br><br><div class="gmail_quote">On Fri, Sep 30, 2011 at 9:20 AM, Gerald Vogt <span dir="ltr"><<a href="mailto:vogt@spamcop.net">vogt@spamcop.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On 30.09.11 15:03, Serge Dubrouski wrote:<br>
</div><div class="im">> May be you didn't look carefully but that script does exactly that, it<br>
> monitors process and service. Also if you want cluster to control your<br>
> service, it has to be able to start and stop it. You can configure your<br>
> service as a clone and it'll be up on several nodes.<br>
> But if you don't want to use it you don't have to.<br>
<br>
</div>You are right. I did not look at the monitor function. I checked the<br>
status function and thought it would be in there if it checked it.<br></blockquote><div><br>That's one of the main differences between LSB and OCF RAs.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<br>
Technically, I don't want the cluster to control the service in the<br>
meaning of starting and stopping. The cluster controls the IP addresses<br>
and moves them between nodes. The dns service resource is supposed to<br>
provide a check that the dns service is working on the node and migrate<br>
the service and most important the IP address if it becomes unresponsive.<br>
<br>
I didn't look at the concept of clones, yet. Maybe I took a completely<br>
wrong approach to what I am trying to do.<br></blockquote><div><br>I think that clones is  rally good solution for this situation. You can configure BIND as a clone service with different configuration though. One node will be master another slave. You can also have a floating VIP tied up to any of the nodes but collocated with the running BIND.If BIND dies for some reason, pacemaker will move your IP to the survived node. You can addsending additional alarms.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
The cluster until recently only operated the two DNS service IP<br>
addresses ns1-ip and ns2-ip for our LAN. Three nodes are used to provide<br>
redundancy in case one node fails. This way our two DNS server IPs are<br>
active at all times.<br>
<br>
Bind is running on all three nodes. Bind is configured to scan for<br>
interface changes every 60s. The three nodes are configured as slave<br>
servers, getting notified of zone updates by the master server.<br></blockquote><div><br>Here you have several options. You can either schedule reload operation for NAMED RA in cluster. or you can try to create an odrer constraint like somebody else suggested:<br>
<br><span style="font-size: 11pt; color: rgb(31, 73, 125);">order named-service-clone-after-Cluster_IP inf: Cluster_IP:start Named_Service:reload</span><br><br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<br>
This works in regard to node failures and similar. If a node crashes the<br>
IP address is moved to another node.<br>
<br>
The problem is if the node is still up but the named process becomes<br>
unresponsive and is hanging. The cluster wouldn't notice this.<br></blockquote><div><br>With NAMED RA it will.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<br>
If I understand your script correctly, it starts and stops the named<br>
process. If I do this, the node which is not running the dns server<br>
won't get zone updates, i.e. if it starts it has outdated zone files.<br></blockquote><div><br>As I said earlier  you can configure it as a clone. In this case cluster will start it on all nodes. and will do monitoring.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Now if the master server is accessible and running at the time of start<br>
the dns server gets updated quickly. The trouble is if the master is<br>
down, too, the dns server will provide outdated dns information until<br>
the master is running again.<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
That seems to me the problem when the bind process is started and<br>
stopped on the nodes and that I was trying to avoid. IMHO the named<br>
process can be running all the time, thus getting zone notifies in the<br>
usual manner.<br></blockquote><div><br>It depend how you populate your zones.  If you put your zone and config files on a shared device (DRBD or so) then you can fail it over along with IP and restart BIND with each failover. If you want to use master/slave BIND replication then you obviously need to have them both running at all times and then you need to use clones.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
But maybe I am not getting what clones do. I think so far I didn't quite<br>
get what they do exactly from the guides in respect to what I am trying<br>
to achieve.<br>
<br>
Maybe you can give me a hint how I would achieve this with a clone,<br>
running named on all nodes at all times and moving the service IP<br>
addresses between nodes in case a node or dns server fails or hangs.<br></blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5"><br>
Thanks!<br>
<br>
Gerald<br>
<br>
_______________________________________________<br>
Pacemaker mailing list: <a href="mailto:Pacemaker@oss.clusterlabs.org">Pacemaker@oss.clusterlabs.org</a><br>
<a href="http://oss.clusterlabs.org/mailman/listinfo/pacemaker" target="_blank">http://oss.clusterlabs.org/mailman/listinfo/pacemaker</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker" target="_blank">http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Serge Dubrouski.<br>