Next generation CMDB model building guide

Most CMDB models today still focus on underlying resources. Part of this underlying resource refers to resource management for the IaaS layer and part refers to resource management for the PaaS layer middleware. When it comes to the upper application, the model is actually very simple, just some basic information about the application.

The second thing I want to talk about is the non-application perspective. Today we create and manage so many resource objects, but we do not know who is used, in fact, the real focus is the application. This I summarize as understanding without an application layer.

The model is not very dynamic. As each model object adjusts its properties or relationships, features on the technical side of a traditional database are particularly costly. I abstract the dynamics of the model into two dimensions: the first is the dynamics between model objects at the CI level, and the second is the instance level.

The fourth problem is the design of scene transition. I think scenarios can be preset, but fine-grained models can be a huge administrative burden. Sometimes scenarios are considered too complex, resulting in a particularly heavy subsequent burden of model management. It’s easy to go from simple to complex, but it’s hard to go from complex to simple.

Technology limits imagination. This model cannot be extended due to the limitations of the CMDB platform technology itself.

Lack of IT architecture thinking. I’m going to go from business architecture to application architecture to infrastructure. Business architecture also includes infrastructure architecture and data architecture. By understanding the relationship between these three, you can express what the essential relational connections are at each level of architecture.

New thinking: Break through the perception of configuration management, resulting in unclear boundaries. The configuration is changed to IT resources.

New approach: Push CMDB from the top down, not the bottom up.

New model: Model reconstruction, the traditional relational model can not meet.

New technologies: Redefine functional boundaries with new technologies, new functional architectures.

The CMDB model is ultimately about instantiating data and relationships, and the right model construction can provide a data base for changing scenarios.

The first is the ITSM process for management. In many traditional enterprises, THE CMDB still provides data support services for ITSM processes.

The second is the execution-oriented DevOps process. The entire end-to-end IT delivery process requires complete metadata, especially at the application level.

CMDB architecture is divided into basic resource layer architecture and application resource layer architecture. The resource architecture of the application layer integrates related resources with the application as the center. Resources and their relationship are called topologies (application topologies and physical topologies). Resources can be managed by manual maintenance or automatic discovery. A flow is a complex scenario and means of manual maintenance.

1. Designed for IaaS and PaaS, able to manage all the underlying resources.

2. State control is completed automatically by operation and maintenance process.

3. The maintenance of CI should deeply use automatic discovery rather than manual maintenance.

4. Resource information must be able to provide services for upper-layer applications.

5. CI management needs of basic resources must be met.

1. Provides unified application metadata management capabilities, regardless of application types.

2. The core appeal is application life cycle management.

3. Be application-centric, not resource-centric.

4. Build an elastic relationship with IT resources from the perspective of application resources.

5. Provide support for unified management of application resources, actions, and states.

6. Based on the unified basic resource layer CMDB.

7. The core scenario is continuous delivery.

The application CMDB is a complete description of resources. The resources of an application are divided into deployment resources, service resources, and action resources.

Deployment resources are resources that an application depends on for deployment. They are also called local resources, such as hosts and program packages.

Service resources are the resources on which application operation depends. Generally, they are called additional resources (from 12factor), such as application service interface, application dependent PaaS resources, application dependent application resources and so on.

A scene action is an additional action description on a resource and a resource management method.

Core principle: a resource can provide services, but also depends on its associated resources, so must adopt three-dimensional model solution.

You can instantiate each image and describe them, just properties and relationships.

As shown in the figure above, the IaaS layer software definition object model is organized into three layers. The bottom layer is actually called the dependent running resource, of which the host is just one.

These three layers must contain services, component instances, and hosts. The IP list extends from which instances the service runs and which hosts the instance processes run on.

There are two kinds of component instances. One is its own instance, which needs to be instantiated by the application package when the program is running. One is dependency instance, which instantiates a dependent component.

Self-owned service refers to the way in which the service started by itself is exposed when it is provided externally. Dependent services are what other services are associated with the runtime.

This model representation is similar to that of PaaS layer objects.

It is important to understand the hierarchy between services, instances, and hosts, and to accurately express the difference between a component and a cluster, such as a Mysql component and a Mysql cluster.

Application layer objects also have a deep understanding of the hierarchical relationships between services, instances, and hosts and need to be expressed precisely.

That’s all for today’s sharing, thank you!

Q: How do you describe virtualized resources?

A: Today we manage virtualization and physical machine resource objects together. Added a field in the host object table, which belongs to the mother machine, only one dimension difference.

Q: Is there any introduction to things like disk and network?

A: I summarize disk and network as part of the underlying IaaS. In fact, the description of IaaS object CI is relatively simple. For example, hard disks are classified as hard disk size, classification information and so on, just some hardware information, nothing special. The network should be divided into various networks, such as access, convergence and core can be classified as one network equipment, firewalls should be classified as another. The network aspect needs to pay attention to resource information.

Q: How does the application automatically discover? Can you tell us more about automatic resource discovery?

A: For the application layer to truly automate discovery, it certainly needs to rely on rule libraries. System, subsystem, and application component are logical concepts that only human beings can accurately understand. If we want to relate the instance information of the machine running to the application components recorded and understood in our mind, we need to rely on rules. A rule is nothing more than a collection of rules based on the information scanned by the instance. The underlying resources are automatically discovered, there is an interface to write interface, there is a command to run command, nothing special. Because the complexity of automatic resource layer discovery is not its technology, but its infrastructure