Shared volume group

[Glenn Mallard]

I was wondering if anyone knew of any way to share a volume group among 6 machines. There is no ServiceGuard on these servers but would like to mount one as the master ( read/write ) on one server and the rest as read/only. We have binaries that are identical and don't want to assign SAN space to all the servers. Plus don't want to have to update each instance of the binaries. Thanks

[Massimo Bianchi]

You can import and open in read-only mode the vg you want.

vgchange -a r vgname

Plus, you can mount read-only also all the logical volume, but every file created after the mount won't be visible untill next mount/remount.


mount -o ro /dev/vgnamr/lvol.... /dir

You can do it, but i do not suggest it.
If, for any reason, one of the executable uses some directory for storing logs/socket/lock or something else, it simply will have a random chaotic behaviuor, difficult to analyze.

Massimo

[Glenn Mallard]

Thanks, that is what we are thinking but we have been guaranteed that nothing will be written to the volume group during regular operation.

[Pete Randall]

Glenn,

Without MC/SG to control this scenario, you're risking disaster. It can be done, HP doesn't support it, and you can end up activating the VG with full access from multiple servers. If you're going to attempt this, you have to be extremely careful about running vgchange -a y on one, and only one, server. Believe me, I learned the hard way.


Pete

[Uday_S_Ankolekar]

I ve tested this in our setup. Both servers are attached to a SAN, and shared VG is mounted Read only on secondary server.
One thing we found though, if you create a new file on master server it does not reflect on secondary server till you unmount and mount the shared VG on secondary server

-USA..

[A. Clay Stephenson]

I assume that you are actually referring to "cooked" files (i.e. filesystems) since you mention binaries. The answer is that case is no --- all the mounts must be read-only or absolute chaos is ensured. The problem occurs when systemA does a write. SystemB's buffer cache doesn't know anything about this change. You can actually mount all the systems read-write and things will seem to work --- for a while but corruption will certainly result in very short order.

Now, if you are willing to unmount all the hosts and mount one read-write to do the updates and then unmount it and finally remount all the hosts read-only then that will work just fine -- and be perfectly safe.

[Glenn Mallard]

Yes, we are really trying to find a way to get around having to unmount/mount to get the updates from the one loaded read/write

[MANOJ SRIVASTAVA]

Glenn


If you have the veritas foundation suite , it comes with a intersting product called as CFS cluster file system which will subsitute for NFS in times to come , you may like to look at the same , and ofcourse you always can activate the shared vg in read only mode .


Manoj Srivastava

[Todd McDaniel_1]

Im curious why you dont NFS mount it? Shouldnt that solve your problem?

Of course, then it would be writable by all... You would have to restrict the filesystem if that would be necessary.

[Todd McDaniel_1]

Sorry forgot one thing....

Just load /etc/exports with the hostnames of the remote boxes and then run the NFS mount on the remote box.

then type exportfs at the prompt

mount your.host.com:/my/LVOL /my/mount/point