after the doubling of the serial numbers was solved after some months with the TKU 10/2019, it's time to address the many other inconsistencies in the CMDB sync. In the current state the stacked switches are practically unusable/not manageable. I already mentioned this in the other thread (Switch Stack Represented in Atrium ), here they are
- Sync real serial numbers only for real devices - solved with TKU 10/2019 (added suffix "_STACK" to logical stacked devices)
- real devices should be linked to real and complete operating system entries, logical stacked devices do not necessarily need their own OS
critical for the CMDB is that the real OS no longer contains version information. This is only filled at the logical device. This is not how normalization usually works, products and OS usually have a version number. Currently you also have more OS than real devices
- logical stack masters are linked to an OS, OS CI is complete including version
- real devices are linked to an incomplete OS, without version information
- real devices should be linked to complete OS information. Otherwise, normalization against a maintained product catalog does not work and version numbers are standard there.
- logical units should not have OS from my point of view. But more important is that OS are ALWAYS fully synced, no incomplete dummy CIs
- Sync relationships between real devices, not to the logical device.
critical for the CMDB is that It is that stacked devices do not function like server clusters, where another cluster partner takes over the function in case of failure. A hardware defect like a defective cable or defective port leads to the failure of the connected devices. Currently, all relationships are modeled to the logical device, which undermines the impact functionality of the CMDB. Currently a defect real device has no impact.
Another scenario is the use of a technician. It would be so much easier if the technician could be immediately referred to the real device based on the fault message. Often the real devices are administered in the asset management and then if necessary also the tickets hang there or the life cycle is investigated.
- currently, all relationships are modeled to the logical device,with all the disadvantages described above.
- Model the REAL relationships and they always go to the REAL device and never to the logical master. Stacked devices do not know a failover and if a port is defective, the port is defective and this always affects the connected devices.
- Sync real model names for real devices, never sync the logical stacked device with real model name.
critical to the CMDB is that normalization runs against a product catalog, which very often uses real, marketable product names. Everything else often makes no sense.
We currently have to invent normalization rules for almost every real device in order to remove the added additions. This is time-consuming and extremely error-prone, because the next TKU may have thought up a completely different addition.
An extreme example are real devices with the model designation "Fex-113 Nexus2348UPQ-10GE Chassis" or "Fex-112 Nexus2348UPQ-10GE Chassis".
In truth, it's the "Nexus 2348UPQ-10GE" model from Cisco. Exactly this model is also in the product catalogue, no more (Fex-11? or Chassis) not less. If you want or need to store more information, use the description field and not the model name.
The logical stacked device should already be recognizable by the model name and should get an addition analogous to the serial number. Otherwise the device could not be normalized differently.
In DISCO itself the product names are correct. But during sync these real model names are alienated with some additional information and synced into the CMDB.
Please stop that. The model is extremely important in the CMDB and must match the product catalog. Therefore, nobody will include these fantasy model names in their product catalog. It takes a lot of work to correct these wrong model names via normalization. If you have additional information, sync it into the description fields, there they belong and don't disturb.
There are many examples, some I have described above. There are also some broken ones. It applies everywhere, model names are model names and not description fields.
- Do not constantly jump between real and logical devices - very, very important!
critical for cmdb is that existing ticket relationships can be lost if the master changes. This is very difficult to clean up afterwards and can take hours.
Currently, when the Stackmaster is modified, a real device is converted to a logical device and a new real device is created. The former real device keeps its ReconID in the CMDB and the real device gets a new ReconID. The chaos in the CMDB then begins, information merged via the ReconID is mixed and the "new" device no longer finds its asset information. It is almost impossible to clean this up!
Suggestion: When a device becomes a master, a new logical device is created and NOT the existing one is converted. The real device always remains the real device.
It's hard to describe, I'll try to give you an example. You have a stackable network device (only one). This is synced into the CMDB, normalized and reconciled there.
Then you plug in a second device and the first one becomes the master. With sync, the previous device is now converted to a logical device and new CIs are synced for real devices.
This has a negative effect on the CMDB, because in asset management the first real device was bought of course and with the ReconID the real device suddenly becomes the logical master. The "new" real master device gets a new Recon, if DISCO mistakenly syncs it as a new Device synct.
Once a device is detected, it must remain the same. If a logical device is added, the logical device is new, NOT the existing one. And these two CIs must never be exchanged, this is not possible and can no longer be cured in the CMDB without investing days in work.
Supplementary question: Is ComputerSystem the right class for the logical device at all?
Isn't it much more a collection of devices? It's not in the impact model, it doesn't work like a cluster and it doesn't act like a computer system.
I'm looking forward to your comments and of course even more about solutions from BMC