|
Mon includes a small program which extends what "rpcinfo" can do (and shares
some code!) Look for rpc.monitor.c in the mon package, available from kernel.org
among other places. In a nutshell, you can check all RPC services or specific
RPC services on a remote host to make sure that they respond (via the RPC null
procedure). This, of course, implies that the portmapper is up and responding.
From the README.rpc.monitor file:
This program is a monitor for RPC-based services such as the NFS
protocol, NIS, and anything else that is based on the RPC protocol.
Some general examples of RPC failures that this program can detect
are:
- missing and malfunctioning RPC daemons (such as mountd and nfsd)
- systems that are mostly down (responding to ping and maybe
accepting TCP connections, but not much else is working)
- systems that are extremely overloaded (and start timing out simple
RPC requests)
To test services, the monitor queries the portmapper for a listing of
RPC programs and then optionally tests programs using the RPC null
procedure.
At Transmeta, we use:
"rpc.monitor -a" to monitor Network Appliance filers
"rpc.monitor -r mountd -r nfs" to monitor Linux and Sun systems
-Nathan
Malcolm Cowe wrote:
>
> HP's MC/ServiceGuard cluster software monitors NFS using the "rpcinfo"
> command -- it can be quite sensitive to network congestion, but it is
> probably the best tool for monitoring this kind of service.
>
> The problem with listing an NFS exported directory is that when the
> service bombs, ls will wait for quite a while -- you don't want the
> director hanging because of an NFS query that's gone awry. =)
>
> Malcolm.
>
> P.S. I've now established a modest service for XDM login access via the
> cluster (currently LVS w/ NAT, using HP-UX real-servers). Thanks for all
> your help. Works well -- all I need now are some startup scripts, the
> real-server monitoring and director fail-over! It's a small list.
>
> Joseph Mack wrote:
> > Horms wrote:
> >
> >>On Sat, Aug 04, 2001 at 01:06:49AM -0000, Don Hinshaw wrote:
> >>
> >>>Would a simple TCP_CONNECT be the right way to test NFS?
> >>>
> >>If you are running NFS over TCP/IP then perhaps, but in my experience NFS
> >>deployments typically use NFS over UDP/IP. I'm suspecting a better test
> >>would be to issue some rpc calls to the NFS server and look at the
> >>response, if any. Something equivalent to what showmount can do might not
> >>be a bad start.
> >>
> >
> > how about exporting the directory to the director as well and doing an `ls`
> > every so often
> >
> > Joe
> >
>
> --
> Malcolm Cowe.
> IT | Information Technology, eMail: malcolm_cowe@xxxxxxxxxxx
> Agilent Technologies Ltd. External: +44 131 331 6466
> South Queensferry, EH30 9TG. Telnet: 313-3466
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
|
