Service Desk Practitioners Forum
cancel
Showing results for 
Search instead for 
Did you mean: 

Attributes of a platform

Highlighted
Mark Chandler2
Occasional Advisor

Attributes of a platform

Now by platform I mean X86, Itanium, etc.

With this in mind what would be the attributes of a platform. Here is an example.

Serial # = indentifier key (Parent)
Vendor
Family
Model
Location
Warranty
Maint
Disk
CPU
MEM
NIC
Fiber
Power Recepticles

Now a Ci withing this platform Ci. Keep in mind that every server is virtual.

Server Attributes (CHILD)
Host Name = Primary key Identifier
v-cpu
v-MEM
v-Nic
v-fiver
v-Disk
IP
DNS

Now does anyone see any attributes that I'm not seeing?

A platform could come with MANY NIC cards. What is the best way to solve this. Above I have NIC as an attribute but there could be many NIC's. NIC's come with their own identifier which is a MAC address. How about CPU since there could be more than one CPU in a HW Platform.

I'm starting a CMDB from scratch and decided to start with the HW Platform.

Any Ideas?
3 REPLIES
Robert S. Falko
Honored Contributor

Re: Attributes of a platform

Hello,

I would not define ANY attribute for a CI unless I knew exactly how the staff would be using it. If nobody is using it, I would not put it in the CMDB. In other words, make your use cases first; define your CMDB structure afterwards.

This strategy will give you the answer to the question about NICs. But basically you only have five options:

1) create as many fields as you think you might need for NICs;
2) create a relation between individual NICs and the platforms where they are installed ("platform" could mean whatever you need - a physical machine, a virtual machine, a logical network interface, or whatever). That relationship is likely to be a parent-child, but it could be another type.
3) create a relation between a generic NIC (a non-unique CI) and the platform - which might be fine if you do not manage NICs individually.
4) just have one field for NICs, and describe in free text whatever you what to say about them.
5) put any information you need about NICs in a general description field.

So there are a lot of possibilities, and any one of them may be the right one for your organization, depending on what you really need to do, what you are really managing.

-Josh
Mark Chandler2
Occasional Advisor

Re: Attributes of a platform

Ok, Thank you very much for your informative reply.

With the example above from having platform was the actual infrastructure.

Would Server to Platform be a Child(Server) to Parent(Platform) relationship?
Robert S. Falko
Honored Contributor

Re: Attributes of a platform

Hello,

As far as I know, the only real difference between Parent - Child and any other type of CI relation is that OVSD prevents you from creating more parent-child relations than the max. number of installations allowed for the child CI. This is irrelevant for physical and virtual servers, so I think you can do whatever you want.

We reserve the parent-child relation for cases where the child cannot function if the parent does not. If this is also your rule, than parent-child might be a good bet for you.

However, it might be confusing for users to have part of the relations in one list, and another part in another list.

Yer pays yer money and yer takes yer choice.

-Josh
//Add this to "OnDomLoad" event