[wplug] Re: NFS Availability Issues -- why I should just help off-list ...

[Bryan J. Smith]

Brandon Poyner <bpoyner at gmail.com> wrote:
> NFS certainly brings its own baggage,

Of course.

> and I'll say that I personally don't use DRBD + HA for any
> type of NFS services.

Why do I keep running into this on LUG lists?
I discuss only to find out people have never done it.
Let alone I found out they are solely focused on a web context.
(and the original question and required solution was not).

Can I shoot myself now?!  ;)

> In fact I'm not a huge fan of NFS partially because it's not
> 'designed for' high availability.  I've been using DRBD for
> web, mail, smtp, lpd, etc without any type of file open/
> locking issues.

Saying you don't use NFS because of all that is like saying you don't
eat Oranges because Vitamin C is acidic.  It not only doesn't make
sense and is rather and utterly transposed, but it isn't even a
technically relevant statement.

I invite you to read the early posts from the original poster on this
matter.  Just because you don't use it doesn't mean that you have
been exposed to the case where there is a _real_need_ for network
filesystems in general.  I apologize, but I'm trying to point this
out.

After reading your statements, its as if you don't ever see a need
for network filesystems in general.  Or that a web-centric Internet
platform can do everything that a network filesystem or other, mass,
distributed file storage approach does.

I will repeat ... Can I shoot myself now?!  ;)

> But that doesn't mean that some people haven't had good success
> with DRBD + HA + NFS.  Keep in mind that this is trying to do
> something at a very low capital expenditure.

That's not even what I'm talking about.  I don't know how many times
I see people think I'm talking "costs."  I've had this discussion on
using FireWire for Oracle RAC clustering.  There are just certain
functions that _break_.  Not merely "doesn't work well" or "is not
enterprise grade" -- but functions that _break_.

How corporate network filesystems provide "inodes like they are
local" is wholly different and irrelevant to how stateless Internet
protocols work.  In fact, exposure to only the latter will not give
you any insight into the former.  There is a reason why I avoid
discussing areas where I am not familiar, or purposely avoid (for
various reasons), because it causes me to make recommendations that
are wholly ignorant of a what a feasible solution should do.

I will repeat ... Can I shoot myself now?!  ;)

> If you have the money to spend on something better by all
> means use something better.

Again, has _zilch_ to do with any of this.  It has to do with what
will _not_ "break" when you have persistent open directories, files,
mounts, etc...  End user applications on a workstation, with open and
locked files for writing to a directory, versus files that are opened
read-only and quickly closed on a web server.

I will repeat ... Can I shoot myself now?!  ;)

> The HA wiki addresses NFS file locking with the following two
> disclaimers:
> If client applications do not use file locking, HA NFS works very
> well. However, if a client application uses locking, it may get
> errors that it will not get in a single NFS server. IMHO there
> are some bugs in NFS that cause problems above. -- GuochunShi

It's more than just that simple disclaimer.  In fact, it goes to the
_heart_ of why this approach is wholly inapplicable to the context
I've tried to maintain.  Furthermore, and this regularly happens,
Internet and web approaches seem to dominate, because that's where
97% of Linux consultants are.

I will repeat ... Can I shoot myself now?!  ;)

> However, most of these are now fixed, if you're running the right
> NFS kernel. But, the occasional lock failure in intensive locking
> can still occur. There is not yet any known solution. --
> AlanRobertson 
> Source:  http://www.linux-ha.org/HaNFS

This is my favorite statement ...
  "There is not yet any known solution."

The problem is that the solution does _not_ and will _never_ work for
many applications.  It only works for a select context.  And that
context is not related to the question asked.  It's not related to
the very much needed locking and other details of a home directory
mounted over a network filesystem.

I'm not hammering you for bringing it up.  I'm hammering you for
marginalizing my statements and chalking them up to "if you have
money."  It has _zilch_ to do with that.  It has to do with the fact
that web services are nothing like those required for remote home
directories and files that appear as local inodes to end-user
applications.

I will repeat ... Can I shoot myself now?!  ;)

> If I were attempting to make a highly available networked
> filesystem on the cheap, I would probably go with DRBD with
> a clustered filesystem and skip NFS altogether.  The Xen
> community, another big group using DRBD in interesting ways,
> has reported success with that method.

And that's yet skipping to _another_ context.  The whole "thin"
client v. "fat" workstation.  I'm not against such discussions, I'm
just trying to point out this isn't about "money" or why someone does
or doesn't use NFS, or network filesystems in general, or why they
could even try to ignore the real, enterprise need for network
filesystems, or at least a distributed way of reading _and_ writing
_and_ locking files.

Case-in-point:  

People don't maintain their application settings or user data files
over a web or other, common, stateless Internet service.  At most,
it's used for version control (WebDAV+DeltaV), but that's not "acting
local."  Desktop applications expect local files to "act local." 
Desktop environments have real file usage constraints, and I've yet
to see any stateless Internet service work for that.

I will repeat ... Can I shoot myself now?!  ;)

In case it didn't click ...

I'm not trumping your offering.  Many threads go all over a concept. 
This is not even moderating or criticism, as I am so guilty of
abusing mailing lists myself in excess of anyone else.

However, the detail is ...
- Maintain the context of the question
- That will offer solutions that address the question
- Which involves people actually sharing what they used
- And, most importantly, what actually worked

I have stated, repeatedly, that the context of my offerings are not
about "price" or "preference" or anything else.  It is the context
that _web_ applications are wholly _different_ than workstations.

This is not the first time this has happened, and makes me regularly
question why I even bother trying to help on-list.  I am wholly in
the heavy minority.  My first-hand experience in corporations and
result comments and recommendations are marginalized as "too
expensive" or "too anal" or something else.

And in 97% of the cases, it's because the context of the original
question is outside of web services, but 97% of the comments being
offered are based entirely on things that _only_ work well for web
services.  Because that's where 97% of Linux consulting is at.  Which
means, again, my comments are marginalized as "too expensive" or "too
anal."

Because what is suggested "works for others," even if it's not
remotely related to the context of the question and solution called
for.  I'm very sorry I even responded on-list at this point.  I think
I would be better off just helping people off-list from this point
forward.

I'm sorry if I "burnt" anyone here.  But I have seen too many times
where people get into something, and then hit the obviousness of the
truth ... "oh crap, that's not going to work."  And then they finally
post to the "experts" on the matter, and even they turn around and
say, "what the hell are you doing that for, it's not designed for
it?" 

And weeks into the endeavor, after hundreds of man-hours are spent in
setup, pilot, test, debug and ... largely ... downtime ... people are
just exhausted -- and possibly even their jobs are not in jeapordy.


-- 
Bryan J. Smith   Professional, Technical Annoyance
b.j.smith at ieee.org    http://thebs413.blogspot.com
--------------------------------------------------
     Fission Power:  An Inconvenient Solution