Manage Learn to apply best practices and optimize your operations.

How to assign LUNs in a SAN

Last September, you answered a question as follow: "For true concurrent access to a single LUN you would need specialized software to provide lock management for write access to the same LUN." In a SAN environment, does it also mean that the same LUN can be connected and opened by several servers at the same time so that a lot of servers can read from the same LUN at the same time? If several servers can read from the same LUN at the same time, do we need specialized software to provide lock management or to manage the transfer?

SAN-based LUNs can be "assigned" via LUN security to as many servers as you want. This is the reason a SAN can be used for sharing storage between nodes in a cluster environment such as Veritas VCS or Microsoft MSCS. The SAN just provides the plumbing to make this a reality. The intelligence for true data sharing for block-based LUNS needs to be done at a higher level, such as cluster software on your servers or a SAN-based file system. Without this intelligence, it is hard to make sure that once a file system on the LUN is mounted to a particular server, it does not change the underlying INODE structure on the disk. Since most file systems on hosts use some method of file system caching, you need to make absolutely sure no one is changing anything on the LUN or the servers may freak out. 

One method to get around this issue is to use an IP network to share access control metadata to the underlying LUNs being shared between the servers. This requires specialized drivers on the servers and usually another server to act as the "traffic cop" for SAN-based access to the LUN. If you are sure the data will never change and all access is strictly read access, you can try and mount the drive onto multiple servers, but all bets are off. In the good old days, vendors such as Digital Equipment allowed shared BLOCK-based disk access between servers running in a VMS cluster. (This is still the case by the way with VMS users. VMS has NOT gone away yet!) The disks can be mounted cluster wide, and a locking mechanism within VMS allows each node within the cluster to access the disk. This is also true if you are using the SGI IRIX operating system with the CXFS file system. 

Sun has SAMFS which provides similar functionality. If you are using Linux, you can use a product such as Sistina -- currently owned by Red Hat. If cost is an issue, then a better way would be to use NAS. NAS uses the NFS and CIFS protocols over an IP network for FILE access. The NFS and CIFS protocols were built from the ground up to support file sharing. Creating a CIFS (Windows) or NFS (Unix) share on a server or NAS appliance will allow concurrent access to the underlying files. If your SAN host bus adapters (HBAs) in your servers allow binding the Fibre Channel (FC) protocol AND the IP protocol, you can actually use the SAN for access to your NFS or CIFS shares over IP. NOTE: Your SAN switches will also need to support IP. NAS is a better solution for applications like Webb servers that need to access the same data. SAN is a better solution for the databases that support the Web servers. 

This is why you usually see a "three-tiered architecture" for Web-based applications. The Web tier -- user facing – either uses internal disks or NAS, and the logic and database tiers are located behind a firewall and are attached to the SAN. The database tier can then be clustered with Oracle RAC or Microsoft SQL with MSCS. 

Chris The views and opinions expressed by Christopher L. Poelker are his alone and not necessarily shared by Hitachi Data Systems.

Dig Deeper on SAN technology and arrays