Before proceeding into facts, here’s what a storage LUN is and what it is meant for? Generally, storage means a disk drive and operating systems must speak with physical hard drives in a language they understand. So, without mediation via logical addressing that translates the physical characteristics of the disk, platters, heads, tracks and sectors, an operating system cannot access disk drives.
This is where storage LUNs come into existence where the physical drives are partitioned into logically addressed portions that allow host servers to access them. Each partition is called a LUN.
In order to make the concept easily understandable, here’s a brief explanation. Almost all PC users will be familiar with disk partitions on a single drive. Like C: drive is for storing operating system and D: for your photos and so on. It depends on the PC user whether he is willing to keep the drive single partitioned or maintain 4-5 partitions.
In the same way, in a shared storage environment such as a SAN, each partition on the entire storage array of disks is assigned a Logical Unit Number called LUN. Storage LUN lets the application or applications interact with storage locations.
So, there is a 1:1 relationship between physical drives and LUNs which can be treated as software partitions. Thus, when provisioning storage the admin uses management software to create LUNs. The admin can create, for example, more than one LUN from one physical drive, which would then appear as two or more discrete drives to the user. Or the admin may create a number of LUNs that span several separate disks that form a RAID array; but, again, these will appear as discrete drives to users.
In enterprise storage environments, the storage provisioned and allocated to enterprise workloads varies, sometimes dramatically, depending on the particular service or application, performance needs, and management capabilities in data center.
Now, the big question—–How many storage LUNs does each server need?
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 a single LUN, where one LUN for the application components and another for the application’s data files.
The advantage of one LUN per application is comparatively straightforward and that is to keep everything in one place. This arrangement makes sense to back up and restore all of that content together.
But keeping one LUN for one server being accessed by multiple applications can simplify things on management terms. But can raise serious problems when it comes to 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. Therefore keeping few but large LUNs is not best practice for an enterprise.
And coming to virtual environments involving multiple virtual server machines, sharing a single LUN may not be yielding expected results when it comes to capacity, performance, and data protection. Therefore, in such cases by assigning each VM its own LUN makes complete sense. As virtualization continues evolving, technologies such as VMware vSphere virtual volumes promise per-VM storage instance provisioning and management which further underscore the practical desirability of more LUNs rather than fewer.
Finally, the extract from this written piece is that while planning the storage management, one should assign LUNs in a data center based on the number of applications and the future storage demands and not simply on the server count.