On Tue, Apr 27, 2010 at 1:14 PM, Dejan Muhamedagic <[email protected]>wrote:
> [snip]
>
> 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.
[snip]
OK, thanks.
Indeed my apache agent in resource-agents-1.0.3-1.el5 rpm contains:
...
<actions>
<action name="start" timeout="40s" />
<action name="stop" timeout="60s" />
<action name="status" timeout="30s" />
<action name="monitor" depth="0" timeout="20s" interval="10" />
<action name="meta-data" timeout="5" />
<action name="validate-all" timeout="5" />
</actions>
</resource-agent>
with the timeouts referred as in the previous e-mail warning...
This should mean that in my pacemaker version instead, a resource gets by
default 20s fro both start and stop timeout...
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.
>
>
Probably my confusion about "monitor", "status" and "probes" terms...
Is it correct to say that status command is always performed during start
and stop phases, while the monitor command is executed only if I create the
resource with the option
op monitor interval=xxx
as I did ?
Or does it depends on other default parameters at pacemaker level?
>From what I have read inside the apache resource agent, it contains both
testurl and statusurl parameters:
# OCF parameters:
# OCF_RESKEY_configfile
# OCF_RESKEY_httpd
# OCF_RESKEY_port
# OCF_RESKEY_statusurl
# OCF_RESKEY_options
# OCF_RESKEY_testregex
# OCF_RESKEY_client
# OCF_RESKEY_testurl
# OCF_RESKEY_testregex10
# OCF_RESKEY_testconffile
# OCF_RESKEY_testname
# OCF_RESKEY_envfiles
with statusurl long desc
"The URL to monitor (the apache server status page by default).
If left unspecified, it will be inferred from
the apache configuration file.
If you set this, make sure that it succeeds *only* from the
localhost (127.0.0.1). Otherwise, it may happen that the cluster
complains about the resource being active on multiple nodes.
"
and used by monitor_apache_basic function inside monitor_apache function
(recalled if $COMMAND = monitor)
${ourhttpclient}_func "$STATUSURL" | grep -Ei "$TESTREGEX"
that by default should be with wget command
Instead, testurl longdesc:
"URL to test. If it does not start with "http", then it's
considered to be relative to the Listen address.
"
and the corresponding check (monitor_apache_extended) taking place only if
$OCF_CHECK_LEVEL is set to 10... after the basic monitor completes
successfully
How to set this level for the env var?
In this case it should run
$whattorun "$test_url" | grep -Ei "$test_regex"
that in my default case should resolve into wget command again
These two monitors, basic and extended, are run only by the node serving the
resource, correct?
If so, what are the other probes you are referring? Custom that I can decide
to set in place..?
Thanks,
Gianluca
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
