From: Jesse Pollard <pollard@admin.navo.hpc.mil>
To: "Ragnar Kjørstad" <kernel@ragnark.vestdata.no>
Cc: Rashmi Agrawal <rashmi.agrawal@wipro.com>, linux-kernel@vger.kernel.org
Subject: Re: Failover in NFS
Date: Mon, 18 Nov 2002 16:41:37 -0600 [thread overview]
Message-ID: <200211181641.37773.pollard@admin.navo.hpc.mil> (raw)
In-Reply-To: <20021118232230.F30589@vestdata.no>
On Monday 18 November 2002 04:22 pm, Ragnar Kjørstad wrote:
> On Mon, Nov 18, 2002 at 04:11:06PM -0600, Jesse Pollard wrote:
> > > No, you need to move the IP-address from the old nfs-server to the new
> > > one. Then to the clients it will look like a regular reboot. (Check out
> > > heartbeat, at http://www.linux-ha.org/)
> > >
> > > You need to make sure that NFS is using the shared ip (the one you move
> > > around) rather than the fixed ip. (I assume you will have a fixed ip on
> > > each host in addition to the one you move around). Also, you need to
> > > put /var/lib/nfs on shared stoarage. See the archive for more details.
> >
> > It would actually be better to use two floating IP numbers. That way
> > during normal operation, both servers would be functioning simultaneously
> > (based on the shared storage on two nodes).
> >
> > Then during failover, the floating IP of the failed node is activated on
> > the remaining node (total of 3 IP numbers now, one real, two floating).
> > The NFS recovery cycle should then cause the clients to remount the
> > filesystem from the backup server.
>
> Yes, that would be better.
>
> But it would not work as described above. There are some important
> limitations here:
>
> - I assumed that /var/lib/nfs is shared. If you want two servers to
> be active at once you need a different way to share lock-data.
>
> - AFAIK there is no way for statd to service 2 IP's at once.
> It will (AFAIK) bind to both adresses, but the problem is the
> message that is sent out at startup and includes the ip of
> the local host.
>
> Neither limitation is a law of nature. They can be fixed. I think there
> is work going on to change the way locks are stored, and I'm sure the
> second problem can be solved as well.
Actually, I was thinking that each server served a different mountpoint
instead of both providing the same one.
I'm not sure how the locks currently would be provided unless the
distributed lock from the shared storage interacts with each servers statd
properly. Otherwise you will already have problems.
Second, I thought that statd didn't care about the lock requests coming
from two IP numbers. This should be no different than having two network
interfaces attached to one server (and that works under Solaris). The
client should be using the name from the IP number, not the router used
between the client and server. I view the floating IP as existing behind
a router using the real IP. Since none of the clients are using the real
IP, the naming should remain consistant (I think).
> There may be solutions out there already. E.g. maybe Lifekeeper or
> Convolo include better support for this?
I don't know.
--
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
next prev parent reply other threads:[~2002-11-18 22:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-18 15:04 Failover in NFS Rashmi Agrawal
2002-11-18 15:44 ` Ragnar Kjørstad
2002-11-18 22:11 ` Jesse Pollard
2002-11-18 22:22 ` Ragnar Kjørstad
2002-11-18 22:41 ` Jesse Pollard [this message]
2002-11-18 22:51 ` Ragnar Kjørstad
2002-11-19 1:36 ` Michael Clark
2002-11-19 5:07 ` Rashmi Agrawal
2002-11-19 7:40 ` Michael Clark
2002-11-22 7:07 ` Rashmi Agrawal
2002-11-21 20:58 ` Bill Davidsen
2002-11-21 22:52 ` Jesse Pollard
2002-11-22 19:19 ` Gunther Mayer
2002-11-18 22:33 ` Jan Niehusmann
-- strict thread matches above, loose matches on Subject: below --
2002-11-19 18:24 Juan Gomez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200211181641.37773.pollard@admin.navo.hpc.mil \
--to=pollard@admin.navo.hpc.mil \
--cc=kernel@ragnark.vestdata.no \
--cc=linux-kernel@vger.kernel.org \
--cc=rashmi.agrawal@wipro.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox