parallel read/write access to volume group

[Hrvoje Dubravica]

Hi everyone,

we have a problem,

we have two node cluster (HP-UX 10.20 MC/ServiceGuard). Each of
them runs one package with one oracle database ( it is not OPS), also
one node runs nfs package (mount one disk localy, export it and using remsh
mount it on other node (nfs)). We use this (nfs) because we have application running on
both nodes and need same disk(s) for properly work (read/write access). Solution with nfs
is simple but very, very slow on client node (on server node is ok, of course).
Each package is independent. For this problem database packages (and volume groups) are not importan, they
work fine.

So, as much as we know there is no way to activate volume group in share mode and
allow read/write access (there is solution for read only, but we need read/write because application).

We'd like to know is there any chance (using some software either on nodes or XP box, with current hardware configuration) to avoid
nfs using parallell read/write access to the volume group.

Thank you in advance.

Your H.

P.S.
Servers: K9000 (K570).
External storage: HP XP256 disk system

P.S. This thread has been moved from HP 9000 to HP-UX > Serviceguard. -HP Forum Moderator       

[Victor BERRIDGE]

If a solution exist, it will be with raw devices, with a software that can manage concurrent access from 2 hosts...
because since the OS will cache data, how to you expect it to keep up the data consistency if another host writes...
I know there are things out on the market maybe OPS will do...Well IBM has for SP its VSD (Virtual shared Disks)GPFS etc... I dont see the others staying behind...

Good luck
All the best
Victor
Victor

[Dave Wherry]

When I was in the XP Admin class a year ago we were able to access the same LUN from 2 different hosts at the same time. It was an experiment to see if we could run production on one box (adds, changes, deletes) and queries from another box. For a simple file system it worked. On the query box we attempted to mount the file system as read only. However, we were able to write to it. As the previous post said, it created the problem of the 2 hosts with their resp[ective buffer cache being out of sync. You could not assure the integrity of the data. We just dropped the idea.
So, physically it can happen. Logically it does not seem like a good idea.