dslreports logo
    All Forums Hot Topics Gallery


how-to block ads

Search Topic:
share rss forum feed

·Cox HSI
·KCH Cable
reply to Modus

Re: New SAN - remapping volumes - naming scheme

Good questions! Lol, so it goes with things being outdated on naming conventions.
Current stuff: One old HP MSA (fibre channel), two Equallogics (iSCSI)
Total HP storage, ~4.5TB - - Total Equallogic storage, ~38TB

New Stuff: Compellent (fibre channel) 2 SC8000 controllers and a boatload of drives - price... can't really say much on that, other than "expensive."

iSCSI within a VM?? Interesting.. Seems odd to me, as I've always just added volumes to the machine directly through VMWare, leaving the OS to see the drive without an internal initiator.

The "vdivol1,2,3" scheme is similar to what we have now.
The problem is with disparate machines within them. I hate having to look up, for example, "vdivol5" and track what machines are there.
Example: "machine "x" is also in vdivol5, and is thin provisioned up to "y," so I cannot grant "z" without being very careful, due to considerations for machine "w" and its allocations"
...would rather just look at machine 'x' and know what it's provisioned for, go to the SAN volume for further needs, without being worried about other considerations. Would help with better tracking of what's actually allocated in the "bigger picture."
I don't mind some groupings, as long as it's sane. Just want to start "clean" this time, and lay things out as sensibly as possible for my own sanity.

I may just take the 1st set of #'s out of the scheme, as that could get out of hand if I wanted to add, say, another volume to a file server, and it ends up being "vol.72.fileserver4.06" when others are "vol.10..." - - looking at it now, I'm leaning towards this being simpler. Perhaps changing it to something like the following for future tracking reasons.

"hq.sql01.01" etc