How are DNS Aliases modeled in CMDB

curtisrowell
Mega Expert

Given one server with 8 different aliases and each alias is assigned a different IP address (10.243.4.40 - 48/255.255.255.0)   It seems as though if Discovery is given a task to discovery an IP address range 10.243.4.x/24.   Discovery comes back with 9 distinct servers and also associates 8 DNS aliases to the main CI.

This does not seem to be the proper way to model in this scenario.   Seems to me that the 8 aliases should be nothing more than attributes to the first server.

How should this be model in the CMDB?   Surely we would not have 9 cmdb_ci_server items.   It isn't exactly a cluster as there really is only a single discrete server CI.

Any thoughts or recommendations based upon past projects.

1 ACCEPTED SOLUTION

Note:   I have discovered, since the original post, that Fuji and Geneva have issues discovering servers which have DNS Aliases, especially when it comes to AIX Blade Centers and the LPARS which run upon it.   Each LPAR, and DNS Alias for the LPAR, are discovered with the same IP Address and Serial number.   A value of '03' is added to the front of the serial number for the blade center and assigned to the LPAR.   The aliases end up with that serial number also but the CI Identifier and the AIX probe can't differentiate between them so the DNS alias is created as a discrete server.



In Helsinki this is resolved.   Each LPAR will get a serial number like '03<blade serial>-01'.   Each subsequent LPAR hosted upon the same blade center gets -02, -03, -04, etc.   Aliases are identified but skipped - this is noted in the discovery logs and no CI is created for the alias of an LPAR.


View solution in original post

8 REPLIES 8

I will agree that



My concern is your CI Identifiers table and why it isn't "consolidating" your server a single entity. If the primary attributes like serial number is the same across the board, OOB Discovery Identifiers *knows* it is the same piece of equipment and wouldn't duplicate the CI just because of a different hostname.


Further update:   The customer is manually setting "Server - Cluster Service IP" as the CI Classification; however, this doesn't establish any kind of relationship between the parent (the AIX server) and the Cluster Service IP classified CI.   Thus, if the parent server were to go down and anyone wanted to know what else might be impacted, they would miss the Service IP "CI's" unless they knew to look at the detail of the parent server on the CI IP's and DNS tabs.



So, what I am looking for is a better way to register the alias so it can be shown in a BSM map but not as a child server, regardless of classification.   Ideas?


Note:   I have discovered, since the original post, that Fuji and Geneva have issues discovering servers which have DNS Aliases, especially when it comes to AIX Blade Centers and the LPARS which run upon it.   Each LPAR, and DNS Alias for the LPAR, are discovered with the same IP Address and Serial number.   A value of '03' is added to the front of the serial number for the blade center and assigned to the LPAR.   The aliases end up with that serial number also but the CI Identifier and the AIX probe can't differentiate between them so the DNS alias is created as a discrete server.



In Helsinki this is resolved.   Each LPAR will get a serial number like '03<blade serial>-01'.   Each subsequent LPAR hosted upon the same blade center gets -02, -03, -04, etc.   Aliases are identified but skipped - this is noted in the discovery logs and no CI is created for the alias of an LPAR.


In our instance the DNS and Server CIs don't seem to automatically become related CIs.   That must be done manually (which hasn't been done).


What discovery rule am I missing?