Scaling Technical Service Offering Group Synchronization

[SNFan]

There is a great feature available in the CMDB to auto-populate the group fields on CIs.

• Support group
• Change group
• Managed by group

This feature leverages a model built on Technical service offerings, and corresponding dynamic CI groups and CMDB groups and is explained on this docs page.

However, there is a challenge that CMDB groups are limited to 10,000 CIs. It is not unusual, in larger implementations, that you may need to synchronize support groups to more than 10,000 CIs. For example, database CIs.

 Here are a few tips to help address this scalability.

1. Work to minimize the number of CIs you actually need in the group
• You can filter so that only ‘Operational’ CIs are included. Once a CI has synchronized and inherited a support (or other) group, it will maintain those groups even if the criteria change and it is no longer in the dynamic group.
2. Attach multiple CMDB & dynamic groups to one technical service offering.
• You can split your CI population, so they are contained in multiple CMDB groups (and corresponding dynamic groups). The dynamic groups are linked to TSO’s by a relationship so many dynamic groups can be linked to one TSO. All the dynamic groups inherit the support/change/managed by groups of the parent TSO.
• There may be a logical sub-grouping that makes sense in your environment, e.g. Create dynamic groups for Windows servers in Facility A vs Facility B.
• If there is no logical grouping, then another technique to evenly allocate CIs across groups is to build CMDB group conditions that includes the sys ID. For instance, you could say only include CIs where the sys ID ends in 1,2,3,4, or 5. Remember sys_ids are hex and use the numbers 0-9 plus the letters a-f
3. Increase CMDB Group maximum limit
• Another option is that you can change increase the maximum number of CIs that can be included in a CMDB CI group. From posts in the community, I have seen mention that this could be moved from 10,000 to 40,000. The property to adjust is: glide.cmdb.group.max_ci_limit
4. Temporary CMDB Group Population
• Another approach - that I have not yet tried – is that you could add a condition such as ‘CI Created in last 7 days’ This way CIs would cycle through the CMDB group getting ‘stamped’ with the synchronized attributes.
• Obviously, this is not ideal, as your CMDB groups / TSOs no longer represent the full population of that technical service, but it does enable the auto-population of CI group fields at scale

Have you needed to use these techniques? Do you have any interesting experiences with CMDB groups?