best practice in regards to VGs

[derek b smith_1]

Hi All!

Is it true to say that it is best practice for non-clustered SAN devices when creating VGs to have the VG names unique across hosts? Now if there are many many hosts I can understand reusing #s such as vg01..vg20 for example, but if not so many hosts 1-20 with no more than 5 VGs per host. Comments?
And minor numbers must always be unique of course!

thank u!

[Patrick Wallek · Accepted solution]

>>non-clustered SAN devices when creating VGs
>>to have the VG names unique across hosts?

I don't see why. You could have the same names on all hosts and it wouldn't make any difference to the SAN.

Presumable your SAN is zoned such that each server can only see the LUNs it is entitled to see, so there should be no chance of one server seeing another servers LUNs.

Yes, minor numbers should be unique, but only on each host. The minor numbers do NOT have to be unique across ALL hosts. That would make administration somewhat more painful.

[Steven E. Protter]

Shalom,

We use a simple system.

vg20 the minor number is 20

We have vg's named vg2b or vg_2b t comply with this guideline.

No need IMO to go with unique vg names for each host. That would strain my brain.

SEP

[Doug O'Leary]

Hey;

I'm a firm believer that vg00 should *be* vg00 and the lvols in it that comprise the core OS be the standard names. Just makes it easier for any follow on admin.

Any other vg, or any other lvol, you can pretty much name anything you want.

I support a lot of sap systems. So, for instance, the filesystem vg will be named vgsap${sid}. Data vgs named vgsapdata${sid}. The lvols that they contain named after their purpose

/dev/vgsap${sid}/lvora_${sid} => /oracle/${sid}

for instance.

I try to keep the lv names short so bdf's print on one line, but that's only a minor consideration.

As for keeping them unique across systems - not really necessary either. Presumably, the reason is that, in case you want to move a vg to a different system, you're not having name collisions.

That's workable - when you import the vg on the target box, simply rename it to something unique.

As always, it's a personal style choice and what you work out with your fellow admins - if any...

Doug

[VK2COT]

Hello,

As others said, keeping names of volume groups
and logical volumes unique within your company
is not necessary unless clustering is in use.

As far as naming standards are concerned, I
like to build them as follows:

Environment One-letter Three-letter
Production P PRD
Backup (interim for tape backup) B BCK
Development D DEV
User Acceptance Testing U UAT
Training T TRN
Production Support A PSP
Pre-Production S PPD
System Test V SYS
Proof of Concept/Prototype C POC
System Integration Test I SIT
Operational Acceptance Test O OAT
Regression Test R REG
Data Migration M DAM
Enterprise Application Integration E EAI

For example, first production volume group for Oracle database is called vgoraP01
or vgoraPRD01.

I have been in IT business for more than 25
years and I learnt long ago that it is good
to be nice to others.

Having a volume group vg15 is certainly
less intuitive about its role than vginfD01,
which I would use for the first development
Informix DB, for instance :)

Cheers,

VK2COT

[derek b smith_1]

done