Hi, On Tue, Apr 27, 2010 at 11:33:14AM +0200, Gianluca Cecchi wrote: > On Mon, Feb 22, 2010 at 9:50 PM, Andrew Beekhof <[email protected]> wrote: > > > On Fri, Feb 19, 2010 at 4:58 PM, Ruiyuan Jiang <[email protected]> > > wrote: > > > Hi, Andreas > > > > > > I am not sure what you mean to monitor it. Can you give me more detailed > > info? > > > > In the apache OCF script, there is a function called monitor. > > Check what it does, see if that works for you. > > > > > Probably a bit to late to answer/contribute ;-) > But I'm testing/evaluating pacemaker for migration from a system with RH EL > 5.2, heartbeat 2.1.4, drbd 8.2.6 and I arrived here... > > My test base for the new cluster is RH EL 5.5 with Pacemaker 1.0.8-5 from > clusterlabs rpm repo. > I'm doing some tests based on the Cluster from Scratch document. > To have the stock rh el 5.5 based httpd working (version 2.2.3-43) clean, I > have to configure this way: > > crm configure primitive SitoWeb ocf:heartbeat:apache \ > params configfile=/etc/httpd/conf/httpd.conf \ > op monitor interval=1min \ > op start timeout=40 \ > op stop timeout=60 > > In fact using what provided in doc, that should be for Fedora 12 (and > httpd 2.2.14-1, but it seems the conf are quite similar....) > crm configure primitive SitoWeb ocf:heartbeat:apache \ > > params configfile=/etc/httpd/conf/httpd.conf \ > > op monitor interval=1min > I get > > WARNING: SitoWeb: default-action-timeout 20s for start is smaller than the > advised 40s > WARNING: SitoWeb: default-action-timeout 20s for stop is smaller than the > advised 60s > > Who is responsible for "advise" here? Is it because pacemaker version and > default settings changed between the document write up and my version?
No, the advised values come from the resource agent's metadata. Those are the _minimums_ (at least so judged by the author of the resource agent) and they may apply to your particular cluster setup. > Also, answering to the initial question, to have the httpd test resource > started and monitored correctly in rh el 5.5 I only had to modify the > default httpd.conf provided: > [r...@ha1 conf]# diff httpd.conf httpd.conf.orig > > 903,908c903,908 > < <Location /server-status> > < SetHandler server-status > < Order deny,allow > < Deny from all > < Allow from 127.0.0.1 > < </Location> > --- > > #<Location /server-status> > > # SetHandler server-status > > # Order deny,allow > > # Deny from all > > # Allow from .example.com > > #</Location> > > PS: at this moment for preliminary testing I have stonith disabled and the > same for the quorum > > One question: in general who is responsible for the monitor? Only the node > carrying on the service at that moment, or all the configured nodes? The recurring monitor runs only on the node where the resource is running. Probes, which are also monitor ops, are run on all nodes to discover the state of the resource. > In final configuration a web site in general would be colocated with a > cluster ip; in that case will I need again only the line > Allow from 127.0.0.1 as I see in /usr/lib/ocf/resource.d/heartbeat/apache? > While the cluster ip web access sanity will be tested inside the testurl > parameter instead? Sorry, don't follow this. But please note that the monitor function (aka probe) may sometimes be invoked on nodes where the resource is not running. If it succeeds, then your cluster's in for trouble. That's why you want to do the testing only from/to 127.0.0.1. Thanks, Dejan > Thanks, > Gianluca > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
