ServiceGuard cmviewcl command.

[Serge Dumont]

Hi all,

I'm running SG 11.15 on HPUX 11i and
I have a 3 node cluster.

After I have shutdown a node (shutdown -h)
the cluster reforms with the remaining 2 nodes
but the it then takes exactly 13 seconds to get
the output of the command "cmviewcl".

I did few tests and the moment the network
is up on my third node (the node hasn't joined
the cluster yet) there is no more delay
receiving the output from "cmviewcl"

It's like the command is timing out trying
to query the node that is down.
Is this normal ?

Thanks,
Serge.

[Steve Steel]

Hi

On any network connection there is a timeout

Normal

Wait about 10 seconds then break connection if no reply

So a node which is down will give slower
commands in all multi node accesses

Steve STeel

[Geoff Wild]

What happens if you do a cmhaltnode?

I thought it was always better to do a cmhaltnode prior to a shutdown.

Then run cmviewcl - same result?

Rgds...Geoff

[Dave Hutton]

I think your right Geoff, especially in a 2 node cluster. It's been a while, but I seem to remember having issues where the cluster could panic and TOC the wrong server as the other one went down or came up.
I'm sure someone can clarify this since its been over a year and half since I've been in a clustered environment.

I would suggest cmhalting the node you want to bring down always prior to shutting it down.

Dave

[Serge Dumont]

Geoff, Dave,
Same thing.
After the cmhaltnode, cmviewcl comes back
right away. But the moment I have lost network connectivity, cmviewcl becomes slow.

Thanks.

[G. Vrijhoeven]

Hi Serge,

Here are some possible explanations:

- The node from which the command is issued is not configured in the
cluster.
- The binary cluster configuration file is missing or corrupt.
- cmclconfd is missing or is corrupt or is not configured properly in
the /etc/inetd.conf file.
- The security files .rhosts or cmclnodelist on this or other nodes do
not permit access by the node from which the command is issued.

(man cmviewcl).

HTH,

Gideon

[Stephen Doud · Accepted solution]

Serge,

This is a known issue with Serviceguard.
A request has previously been made to the lab to make SG skip probing nodes which are known by the running cluster to have exitted.

UMCSGKBRC00013544 documents the issue.

StephenD.

[Serge Dumont]

Thank you Steve and Stephen.
This answers my question.

Serge.