On Tue, Apr 27, 2010 at 5:37 PM, Gianluca Cecchi
<gianluca.cec...@gmail.com> wrote:
> On Tue, Apr 27, 2010 at 1:14 PM, Dejan Muhamedagic <deja...@fastmail.fm>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 ?
Correct
> Or does it depends on other default parameters at pacemaker level?
No.
> 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?
... params OCF_CHECK_LEVEL=10
> 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?
No. They are also run once on every node when it first starts.
These are the "probes". Non-recurring "monitor" actions.
> 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
> Linux-HA@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
>
_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
