[Linux-cluster] iptables protection wrapper; nfsexport.sh vs ip.sh racing
Lon Hohberger
lhh at redhat.com
Mon Aug 29 18:41:19 UTC 2005
On Tue, 2005-08-23 at 00:52 +0200, Axel Thimm wrote:
> The typical NFS cluster setups seem to fail for Gigabit NFS/tcp. Some
> clients that are busy during the relocation of services either bail
> out with RPC garbage, or set the filesytem to EACCES, or timeout for
> 17 min.
>
> This has to do with some racing/timing in the NFS vs ip setup/teardown
> procedure. Protecting the service startup/shutdown with an iptables
> rule is a good workaround to fix this.
>
> But what is the proper way to integrate this workaround? I could setup
> new resource agents, one with start=1 and another with start=6 to
> start/stop dropping packages. Or I could modify the current resource
> agents to allow for child entities and wrap one script around the
> service and one in the inner element.
>
> I could probably also hack ip.sh to introduce some delay, to make sure
> the NFS services are really up/down before proceeding. Or maybe fix
> the true evil by making nfsexport.sh wait for NFS startup/stop
> completion (how?)?
Traditionally, we start the NFS daemons as a service to people who
forget to start them before starting rgmanager.
I.e. Red Hat / Fedora Core users are supposed to do this prior to
configuring NFS services in rgmanager:
chkconfig --level 345 nfslock on
chkconfig --level 345 nfs on
It's really an attempt at a workaround a configuration problem -- and
nothing more.
-- Lon
More information about the Linux-cluster
mailing list