Shulou(Shulou.com)06/01 Report--

This article will explain the example analysis of CMDB for you in detail. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.

The name of the routine 1:CMDB should be changed to IT Resource Management.

What is configuration? It's true that there are a lot of configuration management tools, and these things are inherited, but I prefer the concept of resources mentioned in puppet. Resources can almost be equivalent to the concept of objects, objects have properties, resources also have properties; objects have methods, resources also have actions, add a little extra, resources have states. Keep in mind that you can treat all objects as resources.

Why do I insist on changing my name? In reality, when people talk about CMDB, they all talk about traditional discussions, such as automatic discovery, configuration items and configuration properties. In addition, it is often the design and management of some forms, ignoring what a real CMDB is?

The real CMDB is to manage all the internal IT resources!

The routine 2:CMDB model has layers.

In the model shown below, CMDB's model is hierarchical, and I define it as the core model and the extended model.

Core model. The core model records the relationship among business, application and host Host, while other relationships can be unrecorded. With this model, we can basically run subsequent automation and monitoring systems; secondly, we can effectively manage host information on the public cloud.

The core model is by no means an infrastructure-level resource model!

Extend the model. The extension model is extended by relying on the core model, such as finding some associated resource information based on the needs of the application, and finding some dependent device information associated with it based on the host, such as cabinets, storage, switches, etc., constantly expanding the object model.

Adhere to the introduction of the core model, gradually drive the surrounding supporting resources to improve, which is the core entry point of application-driven CMDB.

The object relationship of routine 3:CMDB should be simplified.

From the figure above, you can see that there are only three relationships in the CMDB model, which are as follows:

Master-slave relationship. This kind of relationship is a strong father-son relationship, and if the Lord does not exist, it will no longer exist. Expressed in a schedule, a relationship at the object level. It can be expressed by parts list and inline table in easyops platform.

Dependency. It is an object-level relationship, such as a server on a cabinet and a cabinet in a computer room. Expressed by the attribute association of the object.

Connection relationship. The relationship between hosts and storage, hosts and network devices is a connection relationship. This relationship is dynamically generated and is an instance-level relationship.

What's the difference between dependencies and connections?

Dependency is an one-to-many relationship, and this relationship is maintained by people, for example, there are many servers on the cabinet.

The connection is a many-to-many relationship, and this relationship is caused by some kind of "connection", such as the server is connected to the switch. It can be realized by automatic discovery, but if it is maintained by people, it is basically impossible.

Trick 4: don't be too superstitious about automatic discovery.

Automatic discovery in a certain Chengdu can reduce the cost and cost of maintenance, but I am not superstitious in this ability. An automatic discovery ability must have a process that requires manual intervention, such as the automatic discovery of the network card rate. When an anomaly occurs, it must not enter the CMDB. Secondly, automatic discovery cannot take effect directly in a certain scenario. For example, for example, the process and port information in a machine needs to be automatically monitored. At this time, if you use automatic discovery to maintain the process and port information on the host (in fact, it is simple), but this requires the monitoring system to adapt to the situation in which the process is paused during the change period, and the pause results in incomplete automatic discovery of the machine's process information.

Have you thought carefully about the boundary between automatic discovery and manual maintenance?

In fact, human participation should be required for changing the division of resource status. For example, the process of IP/ server resources entering and leaving the resource pool; the change of state will involve the automatic change of monitoring policy. From the state dimension, it is easy to find manual and automatic boundaries, while the filling of non-state attributes does not matter.

Second, cross-group resource management needs to be process-driven. Currently, for example, firewalls, IP addresses, and servers are typical cross-group / department-managed resources. The management and users of resources need some process control. Of course, there are improvements in this place, ah, if the management platform is perfect, we can simplify the process through the platform, ha. DNS, load balancing resource management is also a typical example.

Each line in the figure is a CMDB management process, except [initialization completed]!

The leader should participate in the routine 5:CMDB, and the team has the same understanding.

Leadership is very important, and with the participation of leaders and the unanimous understanding of the team, it is difficult for this CMDB not to succeed. The failures of many CMDB projects are not caused by technology, but by people.

When it comes to consistent understanding, I think the concept, model, process, scenario and implementation method of CMDB should be simple enough. The import of CMDB starts to bring in a scene, whether for event support or monitoring support.

Routine 6: the conceptual level of cloud computing is the level of CMDB.

In fact, there is a deep level in the CMDB system, and the conceptual level of cloud computing is the model level of CMDB. You also need to build such a hierarchical capability when you build a model, and once this capability is divided, it will have an impact on continuous deployment. Our practice shows that the continuous deployment of standardized specifications also requires such hierarchical thinking, out of line leads to unclear system management, and so is monitoring!

One thing I didn't think clearly about is whether PaaS resources are managed as ancillary resources or as independent resources. Especially in the public cloud model.

Routine 7:CMDB is a snapshot of your IT resources and organization

It's easy to say that CMDB not only reflects the IT resource model you manage, but also reflects your organization management model. When an object can't find Owner, what exactly do you need to think about? When a process cannot be implemented, you also have to think about whether the management of the organization is complex or not.

There are many tricks behind CMDB. It is different from automation systems. It is more difficult to be a management information system than to be a tool system. To understand these tricks is close to success.

This is the end of this article on "sample Analysis of CMDB". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.