From: Greinig, Peter (Peter.Greinig@bourne-leisure.co.uk)
Date: Tue Dec 03 2002 - 07:49:12 EST
All,
Sorry to continue on this topic following a summary, but having thought I
had a
solution which would work ok given some care the following comments (from
Alan
Davis) got me more worried!
> The problem goes deeper than that.
> Unless the SAN insulates each machine from SCSI errors (the HSG's don't,
the
> EVA might but I wouldn't bet on it without lots of research) if the
> presented devices take a SCSI error every machine that the device is
> presented to will try to handle it. This causes one or more of the systems
> to crash. The systems may run for months to years without problems, but
you
> are not protected, the systems are not configured in a supportable manner
> (HP service won't help you fix them if they crash), and it's just a Really
> Bad Idea(tm).
Does anyone else (esp. from HP!) have any views on this - I guess I'm
talking the scenario of:
1. Storageset visible to 3 (non-clustered) nodes on SAN (i.e. not tied down
to one machine by the HSG80s).
2. Storageset mounted on 1 (only) of these machines.
3. SCSI error occurs on Storageset (e.g. mirror disk failure while machine
is writing to it)
4. Who/what handles the error?
Is it true that ALL machines that can see the disk really do try and handle
the error (even though
the storageset isn't actually mounted on two of them)?
Comments from people before hadn't suggested this one, and I don't really
want to bring down our
whole production environment because of something like this!
Regards,
Peter Greinig.
-----Original Message-----
From: Greinig, Peter [mailto:Peter.Greinig@bourne-leisure.co.uk]
Sent: Monday, December 02, 2002 9:44 AM
To: tru64-unix-managers@ornl.gov
Subject: SUMMARY: Mounting storageset on multiple nodes in SAN.
All,
Thanks to Martin Petder, Peter Gergen, Johan Brusche, Thomas Sjolshagen,
Mark Deiss and Pat O'Brien for their responses.
The general conclusion is that mounting a fileset on more than one
(unclustered) node simultaneously is not a good idea at all! (I didn't think
it was either...) Pat O'Brien went one stage further and actually tried it
out (you're braver than I am!!!), Pat's conclusion being that with two
different systems writing to the same disk one cannot see the changes made
by the other and eventual corruption is the result.
Given that my whole reason for having this storageset available to any of
the three machines is to be able to move data around without it going over
the LAN (so ruling out NFS mounts etc) then I am proposing the following
(suggested by most of the people above):
1. No entry in /etc/fstab for this domain/fileset on ANY machine
2. A daemon process running on each machine which will be responsible for
mounting the fileset on that machine. For this process to mount the fileset
it will have to receive a 'not mounted' response from BOTH other machines.
3. A simple interactive script which will place a mount (or unmount) request
with the above daemon.
4. Communication between the interactive scripts & the three daemons to be
done using RCP or small NFS mounts.
5. Tell anyone with root access (fortunately very few people) that if they
even THINK of mounting the fileset manually then bits of them will be cut
off (!)
Given that all data on this fileset is transitory, i.e. we can afford to
loose it, then I think this will be the best approach. Thomas Sjolshagen (HP
Tru64 engineer) suggested that corruption could cause an AdvFS IO domain
panic, but that this shouldn't cause a general system panic (unless
live_dumps set to 0 in sysconfig) - I'm happy to live with the possibility
of domain panics...
Again, thanks for the responses.
Regards,
Peter Greinig.
Systems Programmer
Bourne Leisure Group Ltd
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:01 EDT