I can share the naming policy I use, and it has served me well thus far.
For CPGs, I name them according to the Tier levels of storage I support. DEV_TIER2_CPG_01 (02, 03 etc) = FC, Raid 5, set size 9, Magsafe, slow inner tracks DEV_TIER3_CPG_01 (02, 03 etc) = NL, Raid 5, set size 9, Magsafe, slow inner tracks PRD_TIER2_CPG_01 (blah blah blah) = FC, Raid 5, set size of 5 (we have 10 shelves and 4 nodes), cagesafe, FAST outer tracks. PRD_TIER3_CPG_01 = NL, Raid5, set size of 5, cagesafe, FAST outer tracks.
For VV's we use the following naming convention: (HOSTAME)_(LUN#) and optionaly will append a (_ROLE)... Some examples:
R6KORAPD1_0 (Bare minimum, hostname + lun#) NTFWEXCHDB1_7_DATA1 (bare minimum plus the name of the echange object on the drive) NTFWEXCHDB1_8_LOG1 NTFWEXCHDB1_9_BU2D (backups to disk) VMWARE_0_VMFS1 (name of the Vmware datastore) NTFWSQLD1_0_E (Name of the drive letter assigned) NTFWSQLD1_1_F NTFWSQLD1_2_G
By having the host name, it makes it easy to filter the list of VVs by host.
By having the lun#, you can easily unmap and remap drives back to hosts in their proper LUN location, and clusters that share disks (we use the cluster name as the host name) can use the same LUN# for the same disk on both sides of the cluster. Plus LUN# is the ONLY way you can positively and uniquely identify a LUN from the host perpsective, to a lun on the 3par on ALL operating systems. OS admins asking you to grow the J drive, or hdisk7 don't help you to identify which disk is the one the grow. However, "Grow LUN 10, on the server NTFWFSP1 to 100g" is an efficient method to communicate* (unless you have 2 lun 10s from 2 different 3PAR systems assigned to the same server).
By having the role appended at the end, it helps you make better sence of the performance data collected and evaluated by your System Reporter... a report of the top 10 luns by iops make more sense when you see the hostnames and role information in the list. PLus it allows you to expedite communications with your admins.... "Hey windows guy, why is your K: drive on that server constantly busy?"
We have recently done some SQL server consolidations and we have some beefy boxes running 30+ databases each. We designed a standard that uses mount points, each DB has a minimum of 2 luns, one for log and one for data (one of these servers has over 80 luns assigned). The idea that we can move DBs from one server to another for balancing work load by detaching the DB, and moving the LUN to a new host. Also, this strategy is ideal for snapshot backups/restores of individual databases. Another benefit is the ability to track within 3PAR system reporter and performance tools, the workload and capacity on the server by database... as long as I label all the luns associated with a database with the DB name... for example: NTFWSQLD1_56_PRIMSTR_DB NTFWSQLD1_57_PRIMSTR_LG NTFWSQLP1_12_PRIMSTR_DB NTFWSQLP1_13_PRIMSTR_LG I can then use the gui/cli or reports to filter on PRIMSTR to get a list of all resources used by that particular application, monitor performance, growth rate, etc etc.
Long story short, you can create functionality that doesn't exist with a clever naming standard.
_________________ Richard Siemers The views and opinions expressed are my own and do not necessarily reflect those of my employer.
|