presenting LUN to different servers without mounting

[Patrick Neuner]

Hello,

is it possible to present 1 LUN to different Linux Servers and mount it only on ONE server - in case of a virtual container move to one of the other servers we would be able to unmount the LUN on server 1 and mount it on server 2 - without rebooting the servers.
Problem on RHEL is that we have to reboot the Server if we present a new LUN - that's why we try to find a way to present all LUNs on all Servers ...

Conclusion:
- LUN is presented on all Server
- but LUN is only mounted on ONE Server

Possible or not?

Thank you
Andreas

[AnthonySN]

you require and an active passive cluster.

what is your redhat veriosn?
what is ur san?
Use redhat cluster suite for cluster

[Patrick Neuner]

Hi,

well its RHEL 5.5.
As SAN we use
MSA P3000
and EVA 4100.

We are not talking about Active/Passive Cluster as we do not want to use like GFS, we have tried it and the performance is really this bad, that it's not usable for webservers with lots of small files.

We are talking about moving a filesystem from running Server A to running Server B.

This scenario is not just for Emergency Failover, but also if a virtual environment (using Paralells Containers) is moved from server A to Server B. That's why we do not want to reboot a server.

We know:
- we must not use the file system at the same time on more servers. Thats clear.

What we do not know is:
- can the LUN of this file system be presented to more servers, but in any case would only be mounted on one server at a time.

Like is only the fact, that it is "presented" already troublesome to crash the filesystem.

I tested it and it seems fine, but to use it on a live system, I want more clarification.

Moving the filesystem would be following:

- unmounting on Server A, once unmounted:
- mounting on Server B

This all "without" the need to unpresent on Server A and present on Server B.

We don't want to restart the server that new LUNS's are recognized, that is basically the main concern.

The scripts, that are doing that are secondary, this could be a custom thing, or work through Cluster Manager of Redhat. But any way, that's not the problem we are facing, just the presenting stuff makes us unsure if troubles arise.

I hope it's more clear.

Thanks
Patrick

[AnthonySN]

>>well its RHEL 5.5.
As SAN we use MSA P3000 and EVA 4100.

why different san ?
MSA P3000 ? havent heard of.
ru telling us abt the different sans available in ur environment.viz P3000, MSA and EVA4100

>> We are not talking about Active/Passive Cluster as we do not want to use like GFS, we have tried it and the performance is really this bad, that it's not usable for webservers with lots of small files.

Yes With GFS you can mount the lun on both the servers at the same time and it is an acive/active cluster,there is performance issue which even we observed when we implemented it hence we reverted to ext3 filesystem and active/passive cluster.

>>We are talking about moving a filesystem from running Server A to running Server B.
This scenario is not just for Emergency Failover, but also if a virtual environment (using Paralells Containers) is moved from server A to Server B. That's why we do not want to reboot a server.

your requirement clearly matches the feature of an active passive cluster.


>>What we do not know is:
- can the LUN of this file system be presented to more servers, but in any case would only be mounted on one server at a time.

yes you can present the LUN to two servers at the same time and mounted on one server. but you need cluster software for this to be acheived

>>Like is only the fact, that it is "presented" already troublesome to crash the filesystem.
I tested it and it seems fine, but to use it on a live system, I want more clarification.

it crashed because you are not using any cluster software

>>Moving the filesystem would be following:
- unmounting on Server A, once unmounted:
- mounting on Server B
This all "without" the need to unpresent on Server A and present on Server B.
We don't want to restart the server that new LUNS's are recognized, that is basically the main concern.

the unmounting and mounting is taken care by cluster

>>The scripts, that are doing that are secondary, this could be a custom thing, or work through Cluster Manager of Redhat. But any way, that's not the problem we are facing, just the presenting stuff makes us unsure if troubles arise.

I hope it's more clear.

scripts are used to start and stop of applications

[Michael Leu · Accepted solution]

Rebooting for LUN changes should not be necessary:
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/html/Online_Storage_Reconfiguration_Guide/

If you want to do it anyway, then the most simple thing IMHO is use the LVM with tags. Check out the man pages of lvm(8) and lvm.conf(5).

The basic mechanism is:
- the VG always has the tag of where it should run
- you set up a filter in lvm.conf to check for one tag on server A, for another on server B
- now VG cannot be activated on the other node unless you change the tag

[Patrick Neuner]

Thanks for your help and the link to the tutorial about online update of the bus.

but my main question has not been answered yet, so i try to ask different:

If I do "multipath -ll" on both servers, it looks like this:

evatest (3600508b40006b7b50000b00001fb0000) dm-3 HP,HSV200
[size=5.0G][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=100][active]
\_ 0:0:0:20 sda 8:0 [active][ready]
\_ 1:0:0:20 sde 8:64 [active][ready]
\_ round-robin 0 [prio=20][enabled]
\_ 0:0:1:20 sdb 8:16 [active][ready]
\_ 1:0:1:20 sdf 8:80 [active][ready]

That means, the LUN is presented to "both" servers at the same time.

mount will show this (on 1 server only!)

/dev/mapper/evatest-logvolevatest on /evatest type ext3 (rw)


Can the fact, that the LUN is presented to both servers at the same time cause errors or crashes?

Again: It is only mounted on one server.

Thanks
Patrick

[Uwe Zessin]

No, the pure presentation to two or more servers does not cause data corruption. If that were the case, many clusters would not work.

The problem is that both servers do not understand how to share a file system and assume exclusive access to it.

The corruption occurs as soon as the second server (2) mounts the file system while it is still held 'open' by the first server (1).

Server 2 sees that the volume was opened and assumes the filesystem was not closed properly. It tries to bring the filesystem into a consistent state without telling server 1.
Server 1 continues working with its own (possible cached) view of meta-data information.