What is the purpose of creating logical unit numbers (LUNs), and in what situation would I create only one LUN and not several?
Good question, a LUN is the primary means of allocating and addressing open system (e.g. non-mainframe) storage. An open system storage device, whether it be a disk drive, tape drive or disk array, is accessed by host servers using a device address or target address. For example, you could partition a disk drive on a Windows or Unix server to appear as multiple partitions (e.g. LUNs or logical volumes) to the system for use as, say, a C: or a D: drive. On larger storage arrays where two or more disks exist and some type of RAID controller is present, the disks may be RAID protected using mirroring or some other RAID level, and the subsequent storage allocated as LUNs of various sizes.
So the LUNs are essentially a way for storage to be accessed, as well as a means of assigning different service criteria and characteristics to a piece of storage. Creating single or multiple LUNs will depend on a couple of things, including:
• How many servers are involved? There should be at least one LUN per server, more if you have the need to keep data and OS storage separate on each server.
• How granular do you want or need to have your storage allocated?
• What types of service characteristics do you need to assign to your storage? For example, supporting a tiered storage environment.
• What do your applications or your database administrators (DBAs) require for storage allocation? Many DBAs have been taught to have as many small disks or LUNs as possible. This is a hold-over from the thinking that you need to throw lots of disks at a problem instead of combining robust disk drives, cache, controllers and RAID to address performance and capacity issues.
• What level of isolation do you need to maintain among your different data? For example, having separate areas for daily or weekly backup, and other areas for continuous or near-continuous copies so as to reduce the chance of accidentally overwriting your backups.
This was first published in October 2005