Labeling CI

[JoePearson]

This is the same question as that of using a surrogate key in database design. No one should make CI naming decisions without understanding data modelling principles - let somebody else make the decisions if necessary.

A CI needs a unique name (I think the need for uniqueness is obvious!) that never changes (so you can track it, so links to it from other tables remain consistent). The OS host name is a natural key, but it has significance outside the database ... and if it can change in your environment, it's no good as a CI name. Plain and simple.

The serial number would be another candidate. Can that change (in an "upgrade")? Would it then be genuinely a new CI?

Otherwise, you need a surrogate key, a CI name which has no significance at all anywhere else, so you can guarantee it won't change.

[rpmason]

A unique ID lets you track it from the time it comes in the door until it goes to the recycling center.

Develop your own unique id standard for CIs. You could start with 1 and go until you're done or you could have a complex algorithm. Whatever works for you.

Using hostnames as a unique id could give you MLXNP345XX001 -- or you could just call the poor thing Ted. Our data center includes customer-owned systems. I think we have three CIs with the hostname Michael; all owned by different customers. We have no control of their hostnames.

Replacement equipment taking on the previous hostname is commonplace. Techies know that Snoopy is a major network switch. If you mention Snoopy and Incident in the same breath, you can literally watch blood drain from faces. If we replace Snoopy with a bigger switch, why rename it to Sally?

If you include location in your ID, what happens when that equipment moves across town or across the world?

Just some thoughts.

[ChasingSleep]

Thank you guys, your help was awesome!

I think we will have a new nomenclature for servers CIs. Their hostname will be just another (important) attribute.

Chrees!

[milligna]

Hi Chasing Sleep,

One thing that I found useful when defining server CIs, especially in light of the recent push for virtual clusters was to have the OS instance separate from the physical machine. That way, when the machine is converted P2V, the OS layer, hostname and all, can just travel across to the Virtual Host or cluster of hosts and all you really need to do is relate it to the new physical layer and change its category to "Virtual Instance" or something similar.

This also helps the server guys - when they're dealing with physical problems they can look at the physical CI by serial number or asset number (i prefer SN coz it's more easily discovered), and if they're looking at OS problems or changes they can focus on the OS CI.

I think this future proofs a little bit for virtualisation. I think it's a pretty good idea to keep the OSI model in mind when defining CIs...

Cheers,
Kev

Edit: dumb grammatical error begone!

[ChasingSleep]

miligna,

That's an interesting idea. Thank you!