Shared Disk in modern data center (SAN, virtualization, etc)

Question

I'm a developer...treading here on foreign terrain. Please pardon any naivete.

I work on an application that stores data both in a database and the filesystem.

Context: Clustering and Network Shares

In the past when we ran the application clustered (i.e. multiple application servers fronting the data), we have handled the filesystem as follows:

• Node A : shares the "data directory " (via samba or nfs)
• Nodes B,C,D, etc: mounts the "network share" and uses that at its "data directory"

Reduced "disk speed" for nodes B,C,D was suboptimal, but not a big problem.

Also note: The application uses its own file locking mechanism. Concurrent writes are not a problem.

The Questions

• So in a modern data center fibre-channel connects servers to SANS, what's the best way to share a "hunk of disk" amongst several servers ?

• Is such 'disk sharing' widely used?

• Any OS-specific concerns ("works on linux, but not available on Windows")

• Any caveats? Hard to configure, unreliable, etc?

I have heard a lot of "we can't do that" from our sysadmins ..which finally when I asked more details, they said "well, technically it's possible, but it's not how we do it here"

thanks in advance,

Update: Thanks for the answers. (They were all good: i had to pick one. Sorry if it wasn't yours) Just as I had (somewhat) expected: my hopes that you could simply attach NTFS or XFS or whatever "regular" filesystem to the same 'hunk of 'disk' proved naive. Clustered filesystem is the ticket. And fancy filesystems aren't on our hosting team's top priorities).

Answer 1

"well, technically it's possible, but it's not how we do it here"

That sounds quite a lot like what I regularly tell developers ;)

From an enterprise operational perspective you want as much as possible that applications use standard repeatable solutions. If your application doesn't need/warrant special treatment you're not going to get it. Non-standard solutions require specialised skills, more expensive or simply more equipment and if it's "state-of-the-art" failures are often catastrophic as well.

For many applications a (highly available) file share is still a very suitable and commonly deployed solution.

Common HA alternate solutions to using a file-share are:

• Do not store files on file-systems but use a highly available database and store them as BLOB's instead. A very common approach. Often you already need a database anyway and this makes application servers almost stateless, solves a lot of locking, replication, HA, consistency and access problems by shifting them to the database layer, where a lot of those problems are old news, well understood and solved. It can be expensive to maintain though once you reach (a sizeable fraction of) the petabyte range.

• A proper clustered file-system, that allows concurrent read-write block-level access to your shared storage over Fiber Channel or iSCSI. Enterprise storage arrays tend to be pretty expensive but this can scale very well. Often the cluster file system requires (expensive) licensing for each node for the cluster FS software. Also quite common in enterprise environments for specialised applications.

• Use a distributed object store. This is the more open source solution, with low-end commodity hardware, creating redundancy and scalability in the software. This is a common "cloud" approach.

Answer 2

If you're connecting several servers to a shared block device (DASD/SAN) you still need to either manually manage access to chunks of disk (some databases do that on raw disks, LVM is also an option, with managed LV access) or use a cluster file system, which will manage concurrent access.

Even with write locks managed on a per-file basis, you might run into FS corruption otherwise, if two hosts attempt to perform FS metadata changes at the same time, on a non-clustered FS. Nothing modern about it, BTW, SANs and concurrent block access have been around since the 80s (if not the 70s).

All modern OS have clustered FS implementations, and block chunk isolation is also possible if you're willing to write everything yourself, so it's very specific to what you intend to use.

EDIT: Your "old" network share approach is still quite feasible, and the file server will take care of file locks, so you don't need extra locking mechanisms. If you're not after extra performance and want a simple deployment, it's probably still the easiest route.

Now, if you want to talk "modern", start thinking about object storage and scale out architecture for your app.

Answer 3

You need not just the shared hardware, but also a clustered filesystem.

Regular filesystems wont work - two computers would end up overwriting each others changes, and you would end up with a corrupt filesystem.

Clustered filesystems have the computers all notify each other about changes they are making, and handle locking files when needed so they don't step on each other's toes.

Some of those filesystems are application specific - VMware has VMFS for example, and Hyper-V has cluster shared volumes - they work great for storing virtual machines, but are not meant as general file storage. There are others that are designed to store any files. Each has various advantages and drawbacks, so which is best depends heavily on what you are doing with it. They are all (as far as I know) OS specific - you wont be able to share a filesystem between windows and linux this way.

For some things like high availability virtual machine failover you really need this. For applications where SMB or NFS will do, those are generally preferred - they may be slightly slower, but there are far fewer things that could go wrong, and easier to recover when they do break.