Naming Conventions for LUNS

I give them numbers.

E.g. LUN1234, first 3 is the RAID group #, last one is a LUN #.

RAID groups starts with 00 which means FLASH drives

RAID group starts with a 0 which means 146 GB, 15 RPM, mirrored (e.g. 025)

RAID group starts with a 1 which means 300 GB, 15 RPM, RAID-5 (7+1) (e.g. 125)

RAID group starts with a 2 which means 500 GB SATA

LUN is assigned position in RAID group (1,2,3, ....)

E.g.

LUN2345 is the 5th LUN in RG 234 (500 GB SATA)

LUN1234 is the 4th LUN in RG 123 (300 GB, 15 RPM, RAID-5 (7+1))

LUN0123 is the 3rd LUN in RG 012 (146 GB, 15 RPM, mirrored)

LUN0012 is the 2nd LUN in RG 001 (Flash)

The benefits for me are if I look at the LUN number and I know my convention, I always immediately know what type it is and where it is located.

If I look at a SG and I see

LUN2441

LUN2451

LUN2461

LUN0101

LUN0112

LUN0122

I immediately know that the LUNs are in seperate RGs (good practice) and the first 3 are supposed to be FRA disks and the last 3 should be data disks.

- Same name as the VMFS data store

- Server name + volume label of that particular drive on the client OS

- Description of what the LUN is used for

What Uwe is saying that represents the Raid level / storage tiering is also a good idea indeed !

We do ServerName_ALU###_RG### . This way I can look at LUN and know what server it belongs to right away then I know what RG the LUN is coming from. We also add descriptors at the end if it warrants it.

We also create RGs in specific ranges so that we know what type of disks are involved very quickly.

I have done it like this.

Raid Group 0   luns 0-10

raid group 1    luns 11-19

raid group 2   luns 20-29

and so forth

I keep that order as much as i can.  occasionally i will have a raid group that needs more then 10 lun's and if i have a bunch of raid groups already, i borrow what was left over fromemptier RG's

As for the name,  id do LunXXX_Server_usage_driveletter

THis way i can look at a lun in navisphere and know exactly the RG, server, application, and drive letter it is on.  Plus with ussing the LUNXXX first, it places then in numerical order under the SP  to find them easier.

everyone has there way of doing it and none are wrong:)

I like

LUN # - RG # - Server Name (or cluster name) - LUN Description

I don't really get too much into what particular LUN # or RG # to use.  All it takes is one LUN migration, or one new application that needs 30 LUNs to mess all of that up.

I just do SPA - Even # LUNs, SPB - Odd # LUNs.

Then I start from 0 and work my way up.

I have my BCVs and some other volumes with really high LUN #s just to keep them away from the list in my regular data LUNs.

We do a slightly different take on this but I like it:

StorageGroupName_HostPresentment_ALU###_RG###

I find that keeping it at the storage group level helps for keeping things the same when you have a cluster or shared storage.  The host presentment is an identifier such as JDrive_TempDB for a mount point or OS-LUN001 for an ESX LUN.

TJ

People who know me well might find this surprising, but we use absolutely no naming standard for LUNs whatsoever, For a while we tried working with the simple LUNXXXY where XXX was the RAID group numebr and Y was the LUN number on that RG. Unfortunately we ran into RAID groups that needed more than 10 LUNs carved out of them, and then LUN migrations that totally invalidated that standard. So now we just bind a LUN and give it the next available LUN number. Everything else about the LUN is tracked in a spreadsheet that tells me all I need to know.