How are DNS Aliases modeled in CMDB

curtisrowell · ‎02-04-2016

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.

curtisrowell · ‎10-05-2016

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

Michael Fry1 · ‎02-04-2016

Since I don't have a clear understanding nor detailed view of what you want, I will point you to the many Related Lists available on the Configuration tables. If you look at Windows CI's (for example) you'll see ones like DNS for NIC's, or IP networks, VM's, even things like memory modules or VPN connections and so on. You can start with a base Related List and add extra fields to meet your needs or create a new related list (Relationships) to meet your requirements.

If you're not using Relationships, you can take a look at that too. You can define upstream and downstream Ci's and how they relate to each other.

Hope that helps.

A Westervelt · ‎02-05-2016

Discovery wouldn't create the same server CI multiple times. It recognizes the same defining attributes (serial number, MAC address, hostname, etc) in the Identification phase and only processes one of the responding IP addresses. During the network probes, it will pull back all of the IP addresses and DNS records and process them in their respective related tables.

curtisrowell · ‎02-05-2016

I would agree, Andrew, that what you have described SHOULD be the proper way for discovery to behave; however, what I have are 9 Server CI's each with a unique 'Name' attribute but with all other attributes being identical in every way. Each server registers the DNS aliases on the 'DNS Names for Servers (9)' tab and CI IP's (9).

I believe this may be happening because all the IP Address ranges have been provided in a discovery scope (set) but that the 'Name' attribute is being determined by NSLookup rather than a WMI query executed on the server itself, thus 9 server CI's for the exact same server with only the 'Name' and 'IP Address' (Primary) being different.

curtisrowell · ‎02-05-2016

Added note, Discovery/Properties set which may impact this:

Enforce syncing of IP addresses: Yes

DNS or NetBIOS is trusted host name source: Yes

WMI is trusted host name source: No

Thanks,

Curtis