zhu difeng - Fotolia
Should I make a storage LUN for each server?
In some scenarios, more than one LUN per server makes sense. In others, it's better to maintain a one-to-one ratio. So which is better?
When an enterprise deploys a new application, such as an SQL database, the application requires one or more block storage LUNs associated to it. The creation, association, management and protection of these LUNs form the foundation of storage provisioning.
A logical unit number (LUN) is a logical representation of physical block storage space -- an entire disk; a portion thereof; or a group, such as a redundant array of inexpensive disks, aggregated from multiple disks and controllers. A storage LUN lets the application or applications interact with storage locations. Applications cannot control which tracks, sectors and clusters are used on the disk, for example. Storage allotment requires this kind of physical-to-logical translation involving the operating system and file system.
The storage provisioned and allocated to enterprise workloads varies, sometimes dramatically, depending on the particular service or application, performance needs and management capabilities in the data center.
How many storage LUNs does each server need?
The question of how many LUNs each server needs remains a topic of debate. In a physical, non-virtualized environment where one server hosts a single application, one LUN is probably adequate for the application and its data. More sophisticated applications require more than one storage LUN, with one LUN for the application components and another for the application's data files. The advantage of one LUN per application is a comparatively straightforward backup and restoration schema -- everything is in one place, and it makes sense to back up and restore all of that content together.
Multiple applications can use the same storage LUN. For example, block-based applications on several servers could use the same LUN, meaning less than one storage LUN per physical server. This can simplify provisioning, but raises other serious problems, such as capacity, performance and backup. The LUN must be large enough to service the storage needs of multiple applications. Multiple servers all making simultaneous read and write requests to the same LUN can cause storage, and application, performance degradation. Since backups typically involve a full LUN, backups of large, shared LUNs take considerably longer, and restoring everything is time-consuming and unnecessary for the other applications involved. Generally, few large LUNs are not best practice for an enterprise.
Storage LUN best practices also carry over into virtualized servers that host multiple VMs. It is possible for multiple VMs to share a LUN, but the same potential capacity, performance and data protection issues arise. In this case, consider assigning each VM its own LUN. As virtualization continues evolving, technologies such as VMware vSphere virtual volumes promise per-VM storage instance provisioning and management -- further underscoring the practical desirability of more LUNs rather than fewer.
To plan storage management, base the actual number of LUNs in the data center on the number of applications and their storage demands -- not the number of servers.
