CN116566836A - A NFV network automation operation and maintenance development method - Google Patents

Abstract

The invention relates to a method for developing automatic operation and maintenance of an NFV network. The method includes: decoupling and packaging each operation and maintenance service of the NFV network into multiple atomic capabilities, and registering an API interface for each atomic capability; for any operation and maintenance scenario According to the business logic to realize the scenario, drag and drop, connect and/or configure the API interface through the process orchestration tool, design and release the process to realize the scenario; for any operation and maintenance scenario, enter the basic information of the operation and maintenance scenario, and Associate the basic information of the operation and maintenance scenario with the published process for realizing the scenario; when the trigger condition in the basic information of the operation and maintenance scenario is met, run the process associated with the basic information of the operation and maintenance scenario. The method of the present invention satisfies the operation and maintenance requirements of the NFV network.

Description

A NFV network automation operation and maintenance development method

technical field

The invention relates to the field of automatic operation and maintenance, in particular to a method for developing automatic operation and maintenance of NFV networks.

Background technique

In the mobile communication industry, with the rapid development of digital transformation, the number of IT systems is increasing rapidly, especially the ultra-large-scale Network Functions Virtualization (Network Functions Virtualization, NFV) network cloud-edge collaboration architecture on the existing network leads to increasing system complexity. Network operation and maintenance capabilities capable of deep perception, precise control, and self-healing and self-optimization are required. Specifically, network equipment must have application-level experience perception capabilities, and the sampling frequency should be changed from minutes to seconds; the network management system must realize the capabilities of active detection of poor quality, end-to-end precise demarcation, and network-side self-optimization; From the perspective of network operation and maintenance, there is zero wait for provisioning, zero business failure, and zero service contact. From the perspective of network operation and maintenance, it is network self-configuration, fault self-repair, and quality self-optimization. Due to problems such as high development threshold, locked operation and maintenance manpower, and long operation and maintenance work cycle, traditional operation and maintenance can no longer meet the needs of the industry.

Contents of the invention

In view of this, the main purpose of the present invention is to provide an NFV network automatic operation and maintenance development method, which can meet the operation and maintenance requirements of the NFV network.

In order to achieve the above purpose, this application provides a development method for automatic operation and maintenance of NFV network, including:

Decouple and encapsulate the operation and maintenance services of the NFV network into multiple atomic capabilities, and register API interfaces for each atomic capability;

For any operation and maintenance scenario, according to the business logic to realize the scenario, drag and drop, connect and/or configure the API interface through the process orchestration tool, design and release the process to realize the scenario;

For any operation and maintenance scenario, enter the basic information of the operation and maintenance scenario, and associate the basic information of the operation and maintenance scenario with the published process for realizing the scenario;

When the trigger condition in the basic information of the operation and maintenance scenario is met, run the process associated with the basic information of the operation and maintenance scenario.

In a possible implementation, it also includes managing the API interfaces by grouping, modifying, debugging, publishing, offline or deleting the API interfaces.

In another possible implementation, the grouping of the registered API interfaces is: according to the atomic capabilities corresponding to the API interfaces, they are divided into performance management interface groups, alarm management interface groups, inspection interface groups, and CMDB interface groups.

In another possible implementation, it also includes encapsulating each process in some or all of the released processes into an atomic capability, and registering an API interface for each atomic capability.

In another possible implementation, the release of the process includes: storing the process after identifying the process by the process name and version number; deploying the process in a way of adding or overwriting; reviewing the deployed process, and completing the release after the review is passed.

Another possible implementation also includes managing the published process by performing preview, simulation, restore or delete operations on the published process.

In another possible implementation, the trigger condition is a running cycle, a set start time, an event that occurs in the operation and maintenance scenario, or manual intervention.

In another possible implementation, it also includes storing and counting the data generated by the running process.

This application proposal mainly solves the problem of slow operation and maintenance efficiency and insufficient intelligence of millions of cloud-based equipment on the cloud edge of the ultra-large-scale NFV network cloud edge in the existing network. Agile provisioning of maintenance services and rapid iteration of operation and maintenance scenarios effectively improve operation and maintenance efficiency and save manpower and time costs.

Description of drawings

FIG. 1 is a schematic flowchart of a method for developing automatic operation and maintenance of an NFV network according to an embodiment of the present invention.

Detailed ways

In the process of self-intelligent operation and maintenance "monitoring, management, control, and operation" supporting the ultra-large-scale NFV network cloud edge equipment on the existing network, there are problems of dispersed operation status and dimensions of cross-professional and cross-vendor equipment, and the problem of scattered resource information of multi-vendor heterogeneous products. As a result, the routine maintenance of massive equipment consumes a lot of manpower. To achieve efficient operation and maintenance, it is necessary to atomically manage interfaces such as resources, performance, alarms, command delivery, and automated operations. This solution proposes to encapsulate the interfaces used in operation and maintenance as "atomic capabilities". The generation of atomic capabilities can be inside or outside the system. Through the orchestration capability of the system, the atomic capabilities are arranged and converted into diversified "processes", and finally the reuse of capabilities and the rapid realization of business are realized. The hierarchical structure of "API Atomic Capability Registration--API Orchestration Process Design" enables rapid business innovation interaction. The use of API orchestration makes capability reuse, convenient and fast, transforms the inspection tasks of various network devices into diversified processes, and responds to complex operation and maintenance requirements through free and convenient process design.

Specifically, the flow of an NFV network automatic operation and maintenance development method according to an embodiment of the present invention is shown in FIG. 1 , including steps 101-104.

Step 101: decoupling and packaging each operation and maintenance service of the NFV network into multiple atomic capabilities, and registering API interfaces for each atomic capability respectively.

Step 102: For any operation and maintenance scenario, according to the business logic for realizing the scenario, drag, connect and/or configure the API interface through the process orchestration tool, design and publish the process for realizing the scenario.

Step 103: For any operation and maintenance scenario, enter the basic information of the operation and maintenance scenario, and associate the basic information of the operation and maintenance scenario with the published process for realizing the scenario;

Step 104: When the trigger condition in the basic information of the operation and maintenance scenario is met, run the process associated with the basic information of the operation and maintenance scenario.

In steps 101-104, operations such as registration, management, and process design of the API by the staff are all implemented through the human-computer interaction interface.

In step 101, the atomic capabilities obtained by decoupling the operation and maintenance services of the NFV network include resources, performance, alarms, configuration verification, configuration delivery, inspection, backup, disaster recovery, Capabilities such as monitoring, monitoring, command issuance, and automated operations.

This step forms an atomic capability pool that aggregates the network cloud edge domain, accumulates atomic capability assets, and provides a standard API interface for external output.

Here, the service registry is used as the central repository of atomic capabilities to store the location and metadata of atomic capabilities. It can be used in conjunction with the API gateway to provide relevant information required for process design.

Among them, the registration API interface includes:

Create an API interface, that is, define the basic information of the API, request information, back-end service information, and return result information;

Configure the API request information; the API request information describes how the API caller initiates a request to the current API interface, including the request method and request parameters.

The request method includes: request basic information "protocol, request Path, HTTP Method" and request input parameters "parameter name, parameter position, type, fixed value and default value". in,

Protocol, HTTP, HTTPS, and WebSocket are supported. The first two items can be selected multiple times, but if WebSocket is selected, only one option can be selected. If you initiate an HTTPS request through a group custom domain name, you need to upload the corresponding certificate in the group management, otherwise the call will be abnormal.

Request Path, specifying the interface path of the request, no character limit, and characters that are not supported by the url (such as: Chinese, punctuation marks, etc.) do not need to be escaped. If escape characters are used in Path, they will be reverse-escaped by API Gateway to save and use the original characters. Match all subpaths: Supports matching of subpaths of the current Path.

HTTP Method, supports GET, POST, DELETE, PUT, HEAD, TRACE, PATCH, CONNECT, OPTIONS, ANY, ANY means any Method. When the Method is POST, PUT, PATCH, or ANY, you need to configure the relevant content of the request body.

Query parameter forwarding mode: supports mapping and transparent transmission.

Header parameter forwarding mode: supports mapping and transparent transmission.

Body parameter forwarding mode: supports mapping and transparent transmission. Currently, API Gateway only supports mapping request bodies whose contentType is application/x-www-form-urlencoded, and transparent transmission is required for other types of request bodies.

Body type confirmation: Confirm whether the contentType of the request body is application/x-www-form-urlencoded. If you want the contentType of the request body to be application/json, refer to the following configuration:

Configuration request input parameters: body parameter mapping only supports content-type as application/x-www-form-urlencoded type. After the body parameter is configured, when the request content-type is other types, the parsed request body parameter will be empty, and on this basis, parameter verification and parameter mapping will be performed, and the content-type forwarded to the backend will be set to application/x-www-form-urlencoded. Therefore, when you want to configure the content-type as application/json type, you cannot add body parameters;

Backend request parameters: When the content-type is application/json, when configuring backend request parameters, parameter mapping to body parameters is not supported, but incoming body data is transparently transmitted to the backend interface.

In a possible implementation, step 101 further includes managing API interfaces by grouping, modifying, debugging, publishing, offline or deleting API interfaces.

Here, the grouping of the registration API interfaces is: according to the atomic capabilities corresponding to the API interfaces, they are divided into performance management interface groups, alarm management interface groups, inspection interface groups, and configuration management database (Configuration Management Database, CMDB) interface groups.

In step 102, the bottom layer of the process orchestration tool uses the process engine (camunda) method for scheduling, and combines the specifications of the business process model and notation 2.0 (BPMN2.0, Business Process Model And Notation 2.0) to provide an independent process engine or combine low-code Platform development. Here, process orchestration is to organize the API interfaces provided by atomic capabilities, microservices, or other services (systems), such as Restful, webService, etc., in a drag-and-drop manner according to certain business logic, so that they can be quickly reorganized A set of services, the API interface generated after orchestration can also be provided as an independent application or service.

Through process design, more attention is paid to the business implementation of the API interface itself, without any code reorganization, to improve the reuse rate of the API interface, to ensure a certain degree of atomicity and independence for the provider, and to configure and view the business logic of each step , support the approval of manual nodes, etc., and can better connect the business cooperation between multiple systems.

In another possible implementation, step 102 further includes, encapsulating each process in some or all of the released processes into an atomic capability, and registering an API interface for each atomic capability.

That is, use process orchestration tools to combine API interfaces, so that API interfaces can be connected in series to form a single function, simplify the complexity of requests and responses, improve the efficiency and reliability of API interface usage, and finally realize the operation and maintenance requirements.

Here, the release of the process includes: storing the process after identifying the process with the process name and version number; deploying the process in a way of adding or overwriting; reviewing the deployed process, and completing the release after the review is passed.

In another possible implementation, step 103 further includes managing the published process by performing preview, simulation, restore or delete operations on the published process.

Here, the trigger condition is an operation cycle, a set start time, an event that occurs in the operation and maintenance scenario, or manual intervention.

In another possible implementation, step 104 further includes storing and counting data generated by the running process.

The above descriptions are only preferred embodiments of the present invention, and are not intended to limit the protection scope of the present invention.

Claims (8)

1. An NFV network automation operation and maintenance development method, comprising:

decoupling and packaging each operation and maintenance service of the NFV network into a plurality of atomic capabilities, and registering an API interface for each atomic capability respectively;

for any operation and maintenance scene, according to the business logic for realizing the scene, dragging, connecting and/or configuring an API interface through a process arranging tool, designing and realizing the process of the scene and publishing;

inputting basic information of any operation and maintenance scene, and associating the basic information of the operation and maintenance scene with published flows for realizing the scene;

and when the triggering condition in the basic information of the operation and maintenance scene is reached, running the flow associated with the basic information of the operation and maintenance scene.

2. The method of claim 1, further comprising managing the API interface by grouping, modifying, debugging, publishing, dropping, or deleting the API interface.

3. The method of claim 2, wherein the grouping of registration API interfaces is: according to the atomic capacity corresponding to the API interface, the system is divided into a performance management interface group, an alarm management interface group, a patrol interface group and a CMDB interface group.

4. The method of claim 1, further comprising encapsulating each of a portion or all of the published flows into an atomic capability and registering an API interface for each atomic capability.

5. The method of claim 1, wherein the process publishing comprises: identifying the process by the process name and the version number and then storing the process; deploying the flow in a newly added or covered mode; and auditing the deployed flow, and completing release after the auditing is passed.

6. The method of claim 1, further comprising managing published flows by performing preview, simulation, restore, or delete operations on published flows.

7. The method of claim 1, wherein the trigger condition is a run period, a set start time, an event of the operation and maintenance scenario, or a manual intervention.

8. The method of claim 1, further comprising storing and counting data generated by the operational flow.