10 Replies Latest reply on Oct 30, 2019 4:16 PM by Stefan Hall

    Switch Stack represented in CMDB - critical issues part 2

    Stefan Hall
      Share This:

      Hi Jean Louis Deshairs, Mykola Bocharov, All

       

      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)

      ---

      1. 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

        CURRENT BEHAVIOR:
        - 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

        CORRECT BEHAVIOR:
        - 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

      2. 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. 

        CURRENT BEHAVIOR:
        - currently, all relationships are modeled to the logical device,with all the disadvantages described above.

        DESIRED BEHAVIOR:
        - 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.

      3. 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.

        CURRENT BEHAVIOR:
        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.

        CORRECT BEHAVIOR:
        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.

      4. 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.

        CURRENT BEHAVIOR
        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.

        CORRECT BEHAVIOR
        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

       

      Stefan

       

      CMDB

        • 1. Re: Switch Stack represented in CMDB - critical issues part 2
          Arlene Paraiso

          I hope BMC is able to reply to this post to address the points mentioned by Stefan Hall.

          • 2. Re: Switch Stack represented in CMDB - critical issues part 2
            Stefan Hall

            Hi Matt Laurenceau

            can you please help me again and make direct contact.

            I had the mail addresses of Jean and Mykola in my mailbox and wanted to take care of it later. Now is later and the mailbox seems to forget older information

            • 3. Re: Switch Stack represented in CMDB - critical issues part 2
              Matt Laurenceau

              I know Jean Louis, he's a great chap (and yes, happens to be French )

               

              I'm sure he has a lot of items to prioritize for the next TKUs (strategic improvement, clean-up of outdated items, bug fixes).

              Also looping in Product Mgr, Greg DeaKyne, to best assess priority of each item.

              1 of 1 people found this helpful
              • 4. Re: Switch Stack represented in CMDB - critical issues part 2
                Lisa Keeler

                Hi Stefan,

                 

                I read your list, and I don't understand alot of it.

                 

                Point#1:  There is no OS for Devices, correct?  Are you saying you think we should add one?

                Point#2:  Are you saying that the physical Devices do not have relationships?

                 

                Items #3 and #4 sound like CMDB issues.  Normalization is performed by the CMDB.  And, ReconID is also assigned by the CMDB during Reconciliation.

                Is there something for Item#3 and Item#4 that you think Discovery should change?

                 

                If you would re-word your points to include:

                    CURRENT BEHAVIOR:

                    DESIRED BEHAVIOR:

                I think things would become more clear.

                • 5. Re: Switch Stack represented in CMDB - critical issues part 2
                  Stefan Hall

                  Hi, Lisa,

                  thank you for your interest, too bad I can obviously describe it so badly.

                   

                  First of all, it can be said that it's definitely ALL sync problems and NOT CMDB problems. And I wish the sync would stop messing up my CMDB every day with wrong stacked device information.

                   

                  I try to complete my contribution as desired. Please make sure that someone with Stacked Switch and Sync experience takes care of it.

                  • 6. Re: Switch Stack represented in CMDB - critical issues part 2
                    Jean Louis Deshairs

                    Stefan, thanks again for your detailed inputs about Stack Switches. Mykola Bocharov and myself are currently reviewing this and we will come back to you shortly with an update. Just wanted to ask you be ready to go on a call with us if need be?

                     

                    Thanks.

                    Cheers,

                    JL

                    1 of 1 people found this helpful
                    • 7. Re: Switch Stack represented in CMDB - critical issues part 2
                      Stefan Hall

                      Hi, Lisa,

                      done, I've been trying to highlight the information you're missing.

                      • 8. Re: Switch Stack represented in CMDB - critical issues part 2
                        Stefan Hall

                        Hi, Jean,

                        my Englist is rusty , reading goes well but otherwise I often lack the words. Let's see how far we can get

                        • 9. Re: Switch Stack represented in CMDB - critical issues part 2
                          Lisa Keeler

                          That is much more clear, thanks!  Lisa

                           

                          JL (JeanLouis) said he is in touch with you about this.

                           

                          But, here are my quick observations:

                           

                          #1: OS for Device.

                          I see there is a CMDB Syncmapping for NetworkDevice_OperatingSystem, but it does not have any different behavior for logical or physical device.

                          So, the syncmapping does not explain a difference in the OS Version.

                           

                          The CMDB should be showing exactly the same as the "os_version" attribute in Discovery.

                          If there is a difference, then there must be also be a difference in Discovery, right?

                           

                          syncmapping NetworkDevice_OperatingSystem 2.1

                              """

                              NetworkDevice OS mapped to BMC_OperatingSystem.

                              """

                              overview

                                  tags CMDB, Core_Mapping;

                                  datamodel 0, 1, 2, 3, 4, 5, 6;

                              end overview;

                           

                              mapping from NetworkDevice_ComputerSystem.device where os_type defined as device

                                  device_os -> BMC_OperatingSystem;

                              end mapping;

                           

                              body

                                  device_cs := NetworkDevice_ComputerSystem.device_cs;

                                  name  := "%device.os_vendor% %device.os_type% %device.os_version%";

                                  short := "%device.os_type% %device.os_version%";

                                  if Config.cs_in_ci_name then

                                      name := "%name% : %device_cs.Name%";

                                  end if;

                           

                                  device_os := sync.BMC_OperatingSystem(

                                      key              := device.key,

                                      Name             := name,

                                      ShortDescription := short,

                                      Description      := name,

                                      ManufacturerName := device.os_vendor,

                                      MarketVersion    := device.os_version,

                                      Model            := device.os_type,

                                      OSType           := 0, // Other

                                      VersionNumber    := device.os_version,

                                      Company          := device_cs.Company,

                                      Category         := "Software",

                                      Type             := "Operating System Software",

                                      Item             := "Network Operating System"

                                  );

                                  sync.rel.BMC_HostedSystemComponents(

                                      Source      := device_cs,

                                      Destination := device_os,

                                      Name        := "SYSTEMOS"

                                  );

                              end body;

                          end syncmapping;

                           

                           

                          #2: Relationships.

                          There is this special syncmapping pattern (NetworkDevice_Stack )  ... to create a relationship from the Stack Member to the Stack Master, I believe. 

                          But, that is probably not the relationship you mean? 

                          What specific relationships are you referring to?

                           

                           

                          #3: Model:

                          When I look at the CMDB Syncmapping for NetworkDevice_ComputerSystem.tpl, I see that Model in the CMDB comes directly from the device "model" in Discovery.

                          So, I don't think the Model in the CMDB should be different from the device model in Discovery.

                          (However, Normalization may be changing the Model in the CMDB?)

                           

                                  device_cs := sync.BMC_ComputerSystem(

                                      key               := device.key,

                                      Name              := device.name,

                                      ShortDescription  := device.name,

                                      Description       := device.name,

                                      CapabilityList    := capability_list,

                                      HostName          := device.name,

                                      isVirtual         := device.virtual,

                                      LastScanDate      := device.last_update_success,

                                      ManufacturerName  := device.vendor,

                                      Model             := device.model,

                                      PrimaryCapability := primary_capability,

                                      SerialNumber      := device.serial,

                                      PartitionId       := device.partition_id,

                                      SystemOID         := device.sysobjectid,

                                      ComponentAliases  := device.cdm_component_aliases,

                                      Category          := cdm_category,

                                      Type              := cdm_type,

                                      Item              := cdm_item

                                  );

                           

                          #4, I imagine this behavior (logical device / physical device) is in Discovery itself because I don't see that the CMDB Syncmappings decide what is logical and what is physical.

                          1 of 1 people found this helpful
                          • 10. Re: Switch Stack represented in CMDB - critical issues part 2
                            Stefan Hall

                            Hi Lisa.,

                            I don't know DISCO very well, I only see what is wrong with the CMDB.