MSA2000fc - Is my setup correct ?

[Neil Sutton]

Hi all,

We are currently looking to implement our first san, we have 10 servers 2 of which are blades in a C3000 enclosure.
Eventually everything will migrate to the blade enclosure and we would like to attach a san to it for consolidated fast server storage.
As I have no experience with SANs could someone confirm if this setup would be correct ?

I am assuming the correct way of accessing SAN resources would be share them via the blade servers which would then in turn be accessible via the trunked link ?

Our main concern is fast storage between the servers but this will also be our main storage area for the entire network.

Any advice would be appreciated!
Thanks

[Neil Sutton]

I should have noted.. the proposed setup is mocked up in a diagram I have attached to the initial question :)

Cheers

[Uwe Zessin]

We need to learn a bit more details, for example:

- is this a single or dual-controlle MSA2000fc?
- how are the controllers cabled, exactly?
- what operating system is running on the blades?
-- not that two Windows instances CANNOT access the same volume on the MSA2000 concurrently when the file system is NTFS

As the 'clients' do not have an FC interconnect, they cannot access the MSA2000fc directly. You have to decide on a LAN protocol. Again, a block-oriented protocol like FCP(Fibre Channel Protocol) or iSCSI _DOES NOT_ allow concurrent access to an NTFS volume.

[Neil Sutton]

Hi Uwe,

- is this a single or dual-controlle MSA2000fc?
Dual
- how are the controllers cabled, exactly?
Directly to the Brocade 4/12 San switch in the blade enclosure
- what operating system is running on the blades?
Windows Server 2008

It is a little worrying about what you mention regarding concurrent access.. are you saying that if the MSA is setup with NTFS then only one server can access the drives at a time?
Would that be the same for clients, if they access the SAN via a share on the server?

If that is so then is there a way around this problem ?

To give some background we are looking to use the san for storing shared documents, profiles etc. and then at night take backups of the servers to the SAN so we can make quick file restores instead of having to seek through tapes.

Thanks for your help.

[Uwe Zessin]

> - how are the controllers cabled, exactly?
>Directly to the Brocade 4/12 San switch in the blade enclosure

I wanted to know which controller's port (each one has two) is going to which switch - this is important to tell if the configuration can withstand a component failure.

> only one server can access the drives at a time?

Correct, but it is a Windows NTFS limitation which exists will all other block-serving arrays as well. The NTFS handler assumes exclusive access of the volume and simply does not know how to interact with another handler on another server.

> Would that be the same for clients, if they access the SAN via a share on the server?

It won't be a problem if the clients use a file-sharing protocol like CIFS or NFS.

> If that is so then is there a way around this problem ?

A MicroSoft Cluster Server can arbitrate access so that one server can access one volume. The second one is locked out. If the first server fails, the volume is moved to the other server.

A true shared file system like HP's PolyServe. As far as I know it does not support Windows 2008, though.


From your description it seems like the two blades just serve as backups. In that case it might be acceptable if the second blades is configured as a "cold standby" (= being powered off)?

[Neil Sutton]

>I wanted to know which controller's port (each one has two) is going to which switch - this is important to tell if the configuration can withstand a component failure

Apologies for that.. I didn't realise.
We haven't yet purchased the hardware (only have the blades/enclosure at the moment) so I can't answer that one.

The blades are both in use and eventually as our other rack servers are replaced they will be new blades in the enclosure.

Thanks for the blocking explanation - I have just been googling it and it's a little clearer now.

Can I ask, if we had say 3 disks setup in raid 5 and then made 2 partitions on it.
Would we be able to use/assign a single partition per server to get around the blocking issue?
The storage will be shared to clients via SMB so hopefully it won't be a problem from that angle..

Are we barking up the wrong tree look at this SAN - maybe there would be something else better suited?

Thanks for you help - as you can see I have no experience when it comes to SAN's :)

[Uwe Zessin]

No apology needed - we can leave the cabling for later ;-)


The MSA2000 does allow you to combine up to 16 disk drives in a RAID-5 combination - the MSA2000 terminology calls it a 'virtual disk' or 'vdisk'. From there you can cut it into smaller so-called 'volumes' (not to be confused with a file-system volume). Each volume can be presented to a single server or to multiple servers (for failover or trued shared filesystem clustering).

So you can have one volume presented to first blade and another volume presented to the second blade - both running on the same set of physical disk drives.
You are free to shut down one blade (to dismount the file system clean) and then present it to the other blade at any time - that is one of the great thing of SANs.

If you need more space, you can later add disk drives to the vdisk and then grow a single volume/ create new volumes -- or create another vdisk with one or more volumes. Those volumes can be presented to the exiting blades, or maybe you have added blades - then you can present them to the new blades --- the choice is yours.



The clients can certainly access the files through the SMB=CIFS protocol as this protocol is meant for file sharing and the operating system running on a blades hides the block-only SAN access for the clients. People have been running that for quite a number of years (I've just looked in my archive and I have some SAN configuration files from November 1999!).

[Neil Sutton]

Excellent, thats what I was hoping to hear! ;)

It sounds like we should be able to manage our goal using this hardware - I'm now more optimistic and much better informed than the same time yesterday :p

Thanks for all your help!