- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-18-2012 07:10 AM
In the CMDB there seem to be two ways to model clusters and their member servers. Firstly, cluster CI forms have a "cluster nodes" related list, where each cluster node is a record with a reference to a server CI. And secondly, there's a Members::Member of relationship type between clusters and computers/servers.
Does anyone know why there are these two different ways, and which is the correct one to use? I know that ServiceNow Discovery uses cluster nodes. To my mind, the Members::Member of relationship seems simplest, in which case I need to remove the Cluster Nodes related lists from the Cluster CI forms.
If we're not using Discovery, is there any particular benefit from going for one approach over the the other?
Thanks in advance for any thoughts or feedback.
Solved! Go to Solution.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-26-2012 10:58 AM
Discovery uses the Cluster Nodes class, fills out the reference field for the related list in conjunction with a relationship to ensure they are displayed on the BSM. If you plan to use Discovery, I would follow the approach Discovery will use to ensure that your CMDB doesn't get confusing later in life.
If you have no plans of using Discovery, I would utilize the relationship at a minimum if your goal is to display the child nodes on the BSM and/or utilize the CIUtils Script Include for any automation of upstream/downstream CI's. However, in all honesty, you might as well utilize the reference field, too. One could also write a business rule to keep the two in sync. I've done that for clients with a custom Rack field on the Server table to ensure a matching "Rack contains::In Rack" relationship is built.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-26-2012 10:58 AM
Discovery uses the Cluster Nodes class, fills out the reference field for the related list in conjunction with a relationship to ensure they are displayed on the BSM. If you plan to use Discovery, I would follow the approach Discovery will use to ensure that your CMDB doesn't get confusing later in life.
If you have no plans of using Discovery, I would utilize the relationship at a minimum if your goal is to display the child nodes on the BSM and/or utilize the CIUtils Script Include for any automation of upstream/downstream CI's. However, in all honesty, you might as well utilize the reference field, too. One could also write a business rule to keep the two in sync. I've done that for clients with a custom Rack field on the Server table to ensure a matching "Rack contains::In Rack" relationship is built.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-17-2012 08:39 AM
Thanks for that, Tony - that sounds like a good approach. To be honest, we're unlikely to implement discovery any time soon, so I think I'll go for the relationships, and remove the cluster nodes related lists from the cluster CI forms, which understandably are confusing people at the moment.
If we do go for discovery in future, I could always do a one-off script to populate the reference fields for the cluster nodes. Thanks again for your suggestion.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-19-2012 01:55 PM
If you feel your questions are answered, be sure to mark the topic as such so those searching the community know our thread contains a solution to your problem.