This paper discusses the management of resource data based on container cloud scenario, and points out the difference between data management under traditional architecture and cloud native architecture. This paper defines the scope of data resources, and discusses the operation and maintenance benefit scenario after data management. In the process of cloud native transformation, enterprises often face the problem of dynamic resource awareness. The author also gives some practical and effective solutions.
Under the background of cloud native, the construction and capability of the operation and maintenance system are facing great challenges. In the traditional operation and maintenance scenarios, there are fixed resource management methods and process support. Similarly, the operation and maintenance support for business cannot cover a large area. In the cloud native or DevOps scenarios, the operation and maintenance engineers or cloud native engineers need to upgrade the capabilities of the operation and maintenance scenarios. Typically, they need to have full link service quality monitoring coverage, covering data domains and business domains; An intelligent and intensive resource dynamic scheduling and scaling mechanism is required; It is required to have a terminal oriented monitoring system and the ability to solve fault early warning and problem positioning; It is required to have the ability to defend against unreliable factors at all stages of the “value” delivery process; Need to have a process mechanism for efficient resource delivery and the ability to quickly go online; The ability to promote business to the cloud quickly within the IT organization is required.
We can find that among all the above capabilities, there is a core element. Data needs to be in the central position in various scenarios or capabilities of the cloud native, and resources need to be coordinated and managed to achieve correlation and linkage between data.
Traditional resource management
The management of container cloud resource data is fundamentally different from the traditional CMDB. In many people’s understanding, the traditional CMDB is just a database for managing IT equipment configuration. Its functions are limited to collecting equipment configuration and storage equipment configuration, and rough processing of configuration data.
Resource management mode for automatic operation and maintenance
With the popularization of the concept of automatic operation and maintenance and the development of operation and maintenance technology, the way or method of resource management has also been quietly “upgraded”. There are two main aspects, namely, the resource management of the data center and the resource management of the application. The former expands the functions of IT asset management, and the latter, in order to better support the application data, essentially, These are important steps for the promotion or implementation of automatic operation and maintenance. As shown in the figure below, the efficiency of operation and maintenance is improved through problem diagnosis, resource batch management, automatic patrol inspection, SLA guarantee and resource utilization management. Operation and maintenance automation is supported through automatic data collection, open APIs, visual views, resource standardization and service management.
In the scenario of automatic operation and maintenance, resource management is the management capability of the bottom layer, which provides support for the application of the top layer through API capabilities. Typically, there are standard consistent data support and solid barrier free process support.
DevOps oriented resource management
DevOps oriented resource management is actually the integration of DevOps and CMDB, which is described in detail in the author’s DevOps Authoritative Guide and refined here.
The integration scenarios of CMDB and DevOps mainly include business scenarios, architecture scenarios, deployment scenarios, data output scenarios and traditional infrastructure scenarios. In terms of business scenarios, the service is visualized based on the way of business access flow; In terms of architecture scenarios, the granularity of applications is integrated based on the architecture view to form a complete business and business panorama; In terms of deployment scenarios, it includes the nodes and components corresponding to the application, forming the deployment view of the application; In terms of data output scenarios, including all external output scenarios of data provided by CMDB, this scenario mainly conducts one-way and two-way data interaction with other integration scenarios; The traditional infrastructure scenario refers to the view output of the underlying infrastructure, and provides collection, query, storage and display functions.
In terms of application, CMDB supports business scenarios and drives business processes through DevOps. In the value delivery pipeline, CMDB provides accurate configuration data for each business process. In the process of architecture design, capacity management, continuous delivery and business domain guarantee, the business system implements business processes through data empowerment. At the same time, the high-level use mode of data provided by CMDB is mainly the data association of multiple scenarios and the end-to-end view to assist DevOps in root cause analysis, fault location and rapid “self-healing” in the monitoring field. In the measurement and feedback phase of DevOps, the data provided by CMDB is operated in a service-oriented manner to achieve business operation analysis and cost re checking, as well as resource capacity planning and management.
Management mode of container cloud resources
Whether it is a private cloud, a public cloud, or a container cloud scenario, it will face cloud native resource management, also known as cloud native asset management, including applications, data, and components. The cloud native resource management method is very different from the traditional resource management method. In the cloud native environment, all resources are constantly changing, so the supported applications and scenarios are also complex and changeable. At the same time, most cloud native applications use the microservice method, so the number of configuration items managed also shows a geometric increase.
In this case, the container cloud resource management method needs to combine resource data management and resource scenario management, define the model, attribute, and combination relationship of resource management through resource data, describe resources through resource scenarios, and standardize data types.
Container Cloud Resource Data Association
The association of resource data involves three core issues: how to abstract and define resources, how to determine the relationship between resource data, and how to track resources in the container cloud scenario.
The container cloud resource data includes the data of the container cloud platform itself, data center data, event data and change data oriented to reliability assurance, as well as monitoring data oriented to business continuity, application configuration data and business cluster data.
The author also gives a simple example to describe the data association of container cloud resources. When the operation and maintenance team monitors an object and receives an alert message of a monitoring indicator, the operation and maintenance leader first focuses on whether business continuity or the ability to provide sustainable services are affected. The engineer in charge of the object needs to troubleshoot the upstream and downstream relationship of the object in a short time, For example, whether the failure of this object is caused by downstream components, whether it causes problems to the upstream system, what environment this object is in the application service, whether it has high availability, which team the hosted application belongs to, whether it has changed recently, whether it is dependent on other components, and whether it is caused by the container cloud platform itself. At this time, you need a complete set of topology maps of container cloud resource data association, such as application topology, cluster topology, module topology, container cloud resource topology, and data association relationship.
The association of resource data not only requires that the container cloud platform itself has the ability of data association, but also needs to interface with third-party systems, such as interface systems, application monitoring systems, configuration center systems, organizational structure systems, and operation and maintenance process systems. During the docking process of bilateral systems, any two models need to form one-way or multi-directional relationships through data association.
Linkage of container cloud resource data
When the container cloud resource data has the ability of data association, it needs to adapt to specific scenarios for data linkage. Generally, in the container cloud environment, the operation and maintenance team is faced with the operation of various environments and resources. Although the container cloud platform has its own linkage of resource data, the linkage with applications is still unfriendly. Therefore, it is necessary to provide flexible, customizable and manageable template O&M capabilities for resource data in the way of data linkage by developing and encapsulating composable components and plug-ins on top of the internal resource orchestration capabilities of the container cloud platform, covering the O&M management, O&M approval, O&M decision-making and O&M implementation scenarios in the business continuity management process, and ultimately realizing O&M automation and O&M intelligence.
Container cloud resource data linkage can be divided into three layers, namely infrastructure layer, container service layer, and application layer. The infrastructure layer corresponds to cloud resource linkage, the container service layer corresponds to kubernetes linkage, and the application layer corresponds to operation and maintenance linkage. It can also correspond to the linkage of other capability sub domains within the IT organization. To protect your data, Vinchin offers solutions such as VMware backup for the world’s most popular virtual environments, XenServer backup, XCP-ng backup, Hyper-V backup, RHV/oVirt backup, Oracle backup, etc.