CN109714239A

CN109714239A - A kind of delivery method, VNFM equipment and server managing message

Info

Publication number: CN109714239A
Application number: CN201811607708.8A
Authority: CN
Inventors: 李连泽; 刘畅; 胡鸿辉
Original assignee: New H3C Technologies Co Ltd
Current assignee: New H3C Technologies Co Ltd
Priority date: 2018-12-27
Filing date: 2018-12-27
Publication date: 2019-05-03
Anticipated expiration: 2038-12-27
Also published as: CN109714239B

Abstract

The application provides a kind of management message issuing method, VNFM equipment and cluster state synchronous service, it include: after receiving the management message for target VNF, the inquiry request message for carrying the identification information of target VNF is sent to cluster state synchronous service, to indicate identification information of the cluster state synchronous service according to target VNF, it is determined whether there are the target message queues that target VNF is uniquely bound；When receiving cluster state synchronous service return successful inquiring response message, the mark of the mark of the target message queue entrained by it and the target VNFM of target message queue binding is obtained；According to the mark of target message queue and the mark of target VNFM, the target message queue bound to target VNFM is added in the management message by control target VNFM, the management message is handed down to target VNF by the target message queue, the problem for the management message random ordering that thus can prevent VNF from receiving.

Description

Management message issuing method, VNFM (virtual network management frequency) equipment and server

Technical Field

The present application relates to the field of computer communications, and in particular, to a management message issuing method, a VNFM device, and a server.

Background

The NFV (Network Function virtualization) technology decouples software and hardware of a conventional Network device, uses a standard x86 server to replace physical hardware, and abstracts Network functions into a single software entity, thereby implementing software, virtualization and standardization of the Network device. The virtualized software entity is called VNF (virtual network Function).

The NFV includes a VNFM (VNF Manager ) cluster, and a plurality of VNF devices. The VNFM cluster includes a plurality of VNFMs. After receiving a management message for the VNF sent by a message producer, the VNFM may add the management message to a local message queue, and may then send the management message to the VNF device through the message queue.

However, messages sent to the same VNF device are sequential, so how to ensure that management messages are sent to the VNF device in sequence has a significant impact on the normal operation of the VNF device.

Disclosure of Invention

In view of this, the present application provides a management message issuing method, a VNFM device, and a server, so as to prevent the management messages received by the VNF from being out of order.

Specifically, the method is realized through the following technical scheme:

according to a first aspect of the present application, a management message issuing method is provided, where the method is applied to any VNFM in a virtualized network function manager VNFM cluster, and includes:

after receiving a management message for a target Virtual Network Function (VNF), sending a query request message carrying identification information of the target VNF to a cluster state synchronization service to indicate the cluster state synchronization service to determine whether a target message queue uniquely bound by the target VNF exists or not according to the identification information of the target VNF;

when receiving a response message of successful query returned by the cluster state synchronization service, acquiring the identifier of the target message queue carried by the response message of successful query and the identifier of the target VNFM bound by the target message queue;

and controlling the target VNFM to add the management message into the target message queue bound by the target VNFM according to the identifier of the target message queue and the identifier of the target VNFM, so as to send the management message to the target VNF through the target message queue.

Optionally, the controlling the target VNFM to add the management message to the target message queue bound to the target VNFM, so as to send the management message to the target VNF through the target message queue, including:

checking whether the identifier of the target VNFM is consistent with the identifier of the VNFM;

if yes, adding the management message into a local target message queue indicated by the identification of the target message queue;

and if the VNFM information is inconsistent with the VNFM information, forwarding the management information to the target VNFM.

Optionally, the method further includes:

when receiving a query failure response message returned by the cluster state synchronization service, selecting a first message queue from a plurality of local message queues of the VNFM;

adding the management message to the first message queue so as to issue the management message through the first message queue;

sending the identifier of the first message queue to the cluster state synchronization service, so that the cluster state synchronization service binds the first message queue and the target VNF.

Optionally, the VNFM configures a cache area corresponding to each VNF; the management query message and the query result which are sent to each VNF are recorded in the cache area corresponding to the VNF;

the adding the management message to the local target message queue indicated by the identifier of the target message queue includes:

checking a message type of the management message;

if the management message is a VNF management modification message, adding the management message into the local target message queue;

if the management message is a VNF management query message, then

Determining a target cache region corresponding to a target VNF in the cache regions corresponding to the VNFs;

checking whether the query result of the management message exists in the target cache region; and if the management message does not exist, adding the management message into the local target message queue.

Optionally, the method further includes:

if yes, returning the inquiry result corresponding to the management message to the message producer of the management message.

Optionally, the method further includes:

when a response message to the management query message sent by the target VNF is received, the management message identifier and the query result carried in the response message are added to the target cache region.

According to a second aspect of the present application, a method for issuing a management message is provided, where the method is applied to a server running a cluster state synchronization service, and includes:

receiving a query request message sent by a Virtual Network Function Manager (VNFM); the query request message carries identification information of a target Virtualized Network Function (VNF); the query request message is sent after the VNFM receives a management message for the target VNF;

determining whether a target message queue uniquely bound by the target VNF exists according to the identification information of the target VNF;

and if the management message exists, returning a query success response message to the VNFM, so that the VNFM controls the target VNFM to add the management message to the target message queue according to the identifier of the target message queue carried by the query success response message and the identifier of the target VNFM bound by the target message queue, and sending the management message to the target VNF through the target message queue.

Optionally, the method further includes:

if not, returning a query failure message to the VNFM;

and receiving an identifier of a first message queue sent by the VNFM, and binding the first message queue and the target VNF.

Optionally, the identification information of the target VNF includes: a device type identifier of the target VNF and a target VNF identifier;

the cluster state synchronization service is configured with a node tree;

the node tree comprises: at least one device type node, each device type node comprising: VNF nodes corresponding to each VNF belonging to the device type one to one, and queue nodes corresponding to each message queue corresponding to the device type one to one;

wherein, the VNF node records therein: a message queue identity to which the VNF is uniquely bound;

the queue node records: a VNFM identifier uniquely bound to the message queue corresponding to the queue node;

the determining whether a target message queue identity uniquely bound to the target VNF identity exists includes:

searching a target device type node indicated by the device type identifier of the target VNF in the node tree;

searching a target VNF node corresponding to the target VNF identification in the VNF nodes included in the target device type node;

determining whether a message queue identifier is recorded in the target VNF node; if yes, determining that the target message queue exists, and determining the recorded message queue identifier as a target message queue identifier; if not, determining that the target message queue does not exist;

the identity of the target VNFM to which the target message queue is bound is determined by:

searching a target queue node indicated by the identifier of the target message queue in a queue node included in the target device type node, and determining the VNFM identifier recorded in the target queue node as a target VNFM identifier;

the binding the first message queue and the target VNF includes:

recording an identification of the first message queue in the target VNF node.

Optionally, the node tree further includes: each VNFM node is recorded with: an identifier of a message queue in the VNFM node and an identifier of a device type corresponding to the message queue;

the method further comprises the following steps:

when the VNFM is detected to be on-line, obtaining the registration information of the VNFM; the VNFM registration information carries the VNFM identifier, the second message queue identifier on the VNFM, and the device type identifier corresponding to the second message queue on the VNFM;

creating a VNFM node corresponding to the VNFM identifier in the node tree;

under the device type node corresponding to the device type identifier, creating a queue node corresponding to the second message queue identifier;

recording, in the VNFM node, a correspondence of the second message queue identification and the device type identification; recording the VNFM identification in the queue node;

or,

acquiring the VNF registration information when the target VNF is detected to be online; the VNF registration information comprises the target VNF identification and a device type identification of the target VNF;

in the node tree, creating a VNF node corresponding to the target VNF identifier under a device type node corresponding to the device type identifier of the target VNF; the message queue identifier of the created target VNF node record is null;

or, when the VNFM is detected to be offline, deleting a VNFM node corresponding to the VNFM from the node tree and a queue node indicated by a message queue identifier recorded in the VNFM node;

or,

and when the target VNF is detected to be offline, deleting the VNF node corresponding to the target VNF node from the node tree.

According to a third aspect of the present application, there is provided a virtualized network function manager, VNFM, device comprising a processor and a machine-readable storage medium storing machine-executable instructions executable by the processor, the processor being caused by the machine-executable instructions to perform the method of the first aspect.

According to a fourth aspect of the present application, there is provided a machine-readable storage medium having stored thereon machine-executable instructions that, when invoked and executed by a processor, cause the processor to perform the method of the first aspect.

According to a fifth aspect of the present application, there is provided a server running a cluster state synchronization service, the server comprising a processor and a machine-readable storage medium storing machine-executable instructions executable by the processor, the processor being caused by the machine-executable instructions to perform the method performed by the cluster state synchronization service of the second aspect.

According to a sixth aspect of the present application, there is provided a machine-readable storage medium having stored thereon machine-executable instructions that, when invoked and executed by a processor, cause the processor to perform the method of the second aspect.

As can be seen from the above description, in the present application, the target VNF only binds to one target message queue, in other words, the management message of the target VNF can only be issued by the target message queue that is uniquely bound by the target VNF, so that the problem of out-of-order management messages received by the target VNF can be overcome.

Drawings

Figure 1 is a schematic diagram of a conventional VNF networking architecture;

FIG. 2 is a diagram illustrating a networking architecture of a VNF according to an exemplary embodiment of the present application;

FIG. 3 is a node tree of a Zookeeper platform shown in an exemplary embodiment of the present application;

FIG. 4 is a node tree of another Zookeeper platform shown in an exemplary embodiment of the present application;

fig. 5 is a flowchart illustrating a method for issuing a management message according to an exemplary embodiment of the present application;

fig. 6 is a block diagram of a management message issuing apparatus according to an exemplary embodiment of the present application;

FIG. 7 is a hardware block diagram of a VNFM device shown in an exemplary embodiment of the present application;

fig. 8 is a block diagram of another management message issuing apparatus according to an exemplary embodiment of the present application;

fig. 9 is a hardware structure diagram of a server running a cluster state synchronization service according to an exemplary embodiment of the present application.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this application and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present application. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

In a conventional VNF networking, it includes: a VNFM cluster, at least one VNF, a cloud database, and a message producer.

The VNFM cluster comprises a plurality of VNFMs, and each VNFM is provided with at least one message queue.

As shown in fig. 1, fig. 1 is a schematic diagram of a conventional VNF networking architecture.

The VNFM cluster in fig. 1 is illustrated as including two VNFMs, which are VNFM1 and VNFM2, respectively. Message queue 1 is configured on VNFM1, and message queue 2 is configured on VNFM 2.

The VNF networking in fig. 1 includes 3 VNFs, VNF1, VNF2, and VNF3, respectively.

The existing management message issuing mode is as follows:

the VNF1 is given an example of issuing management messages.

Assume that a message producer issues management message 1 and management message 2 for VNF1 to a VNFM cluster.

Assume that management message 1 is received by VNFM1 and management message 2 is received by VNFM 2.

Since the acquisition of the distributed lock is random, assuming that VNFM2 first acquires the distributed lock, a lock message may be sent to the cloud database to cause the cloud database to add an exclusive identity to VNF 1. At the same time, VNFM2 may add management message 2 to local message queue 2. After the VNFM2 adds the management message 2 to the local message queue 2, an unlock message is sent to the cloud database to cause the cloud database to delete the exclusive id of the VNF 1.

When the VNFM1 queries the cloud database to delete the exclusive identity of VNF1, the distributed lock may be obtained and a lock message may be sent to the cloud database to cause the cloud database to add the exclusive identity to VNF 1. At the same time, VNFM1 may add management message 1 to local message queue 1. After VNFM1 adds management message 1 to local message queue 1, an unlock message is sent to the cloud database to cause the cloud database to delete the exclusive identity of VNF 1.

The VNFM1 may issue the management message 1 to the VNF1 through the message queue 1. The VNFM2 may send the management message to VNF1 via message queue 2.

It is assumed that due to some factors, such as the message queue 2 issuing rate is greater than the message queue 1, and the network link between the message queue 1 and the VNF1 is congested, the VNF1 receives the management message 2 from the message queue 2 first, and then receives the management message 1 from the message queue 1, so that the received management messages are out of order.

In view of this, the present application sets a server running a cluster state synchronization service in a VNF networking, and the server configures, through the cluster state synchronization service, a message queue uniquely bound to a VNF identifier and a VNFM bound to the message queue. After receiving a management message for a target VNF, the VNFM can obtain, from the cluster state synchronization service, a target message queue identifier uniquely bound to the target VNF and related information of the VNFM identifier bound to the target message queue, and then control the target VNF to add the management message to the target message queue, and issue the management message to the target VNF through the target message queue.

In the present application, the target VNF only binds to one target message queue, in other words, the management message of the target VNF can only be issued by the target message queue that is only bound by the target VNF, so that the problem of disorder of the management message received by the target VNF can be overcome.

The following explains in detail why "management messages of the target VNF can only be issued by the target message queue uniquely bound by the target VNF" can overcome the problem of out-of-order management messages received by the target VNF.

As can be seen from the above-mentioned VNF1 receiving out-of-order management messages, the main reason for this out-of-order is that VNF1 has two message queues. When two message queues send management messages to the same VNF1, due to factors such as different sending rates of the two message queues and different link congestion between the two message queues and VNF1, the management messages of the two queues received by VNF1 are out of order.

Therefore, the main reason for the out-of-order management messages received by VNF1 is that VNF1 corresponds to multiple message queues.

Therefore, only one message queue of the management messages of one VNF is used for issuing, and the management messages received by the VNF cannot be out of order.

Referring to fig. 2, fig. 2 is a networking architecture diagram of a VNF according to an exemplary embodiment of the present application.

In the application, besides a VNFM cluster and at least one VNF, a Zookeeper platform is configured in the VNF networking, and node trees of the Zookeeper platform are used to record each VNF, each VNFM, and a message queue on each VNFM in the VNF networking and a binding relationship between the VNF and the VNFM.

VNF, VNFM and cluster state synchronization services are logical concepts.

One of the VNFMs may be configured on one physical device, and of course, all of the VNFMs in the VNFM may also be configured on the same physical device.

Different VNFs may be configured on the same physical device, or may be configured on different physical devices.

Of course, the VNF may be configured on the same physical device as the VNFM cluster, or may be configured on a different physical device.

The cluster state synchronization service may include a Zookeeper platform and other services having functions of distributed data storage and the like. The cluster state synchronization service can be carried on one physical device, or can be carried on a physical device cluster formed by a plurality of physical devices. The VNFM, the VNF, and the cluster state synchronization service may be mounted on the same physical device or may be mounted on different physical devices.

The cluster state synchronization service may create a node tree structure, where content stored by each node in the node tree may be acquired by the VNFM, and a state change of any VNFM in the VNFM cluster may be synchronized to other VNFMs in the VNFM cluster through the cluster state synchronization service.

Here, the physical devices mounted on the VNFM, the VNF, and the cluster state synchronization service are merely exemplified, and the physical devices mounted on the VNFM, the VNF, and the cluster state synchronization service are not limited to a specific one.

The cluster state synchronization service is described in detail below as an example of the Zookeeper service.

Before the message issuing method provided by the application is described in detail, a node tree in a lower Zookeeper platform is introduced. The following node tree is introduced by both the construction of the node tree and the creation of the node tree.

It should be noted that the VNF node, the VNFM node, and the queue node described in this application all refer to nodes in a node tree, and the VNF, the VNFM, and the message queue described in this application refer to devices or message queues in a VNF networking.

Referring to fig. 3, fig. 3 is a node tree of a Zookeeper platform according to an exemplary embodiment of the present application.

1. Construction of node trees

The root node of the node tree comprises two nodes, namely a node/Types and a node/Managers, and the node/Types and the node/Managers respectively comprise at least one node for storing related information of VNF and VNFM. The two nodes are permanent nodes in a node tree

For nodes included under "/Types" node and "/Types" node:

(1) included under the "/Types" node are: device type node

For example: as shown in fig. 3, the "Type-a" node and the "Type-B" node are device Type nodes, and the device Type nodes are in one-to-one correspondence with different types of VNF devices and are used for storing Type information of VNFs existing in the networking.

Specifically, at least one device Type node, i.e., "Type" node, is included under "/Types", and each "Type" node corresponds to a Type of VNF. The device types of the VNF may include: virtual routers (abbreviated VSRs) and virtual gateways (abbreviated VSGs). For example, if VNF networks include VNF devices of two Types, i.e., VSR and VSG, a "Type-VSR" node representing the VSR Type and a "Type-VSG" node representing the VSG Type are included under the "/Types" node. The device type node may be named in a device type identification.

The "Type" node is a permanent node

Included under (1-1) "Type" are: a VNF node of each VNF belonging to the device type; the VNF node is configured to store information related to the VNF node.

Specifically, in particular implementations, a "Devices" node may be included under "Type". A "Devices" node is a permanent node. The "Devices" node includes at least one VNF node under, and the VNF node is named by VNF identification.

For example, the "VNF-A-0" node, "VNF-A-1" node, "VNF-A-2" node in FIG. 3 are VNF nodes.

The VNF node has recorded therein: 1) a message queue identification to which the VNF node is bound. 2) And user information (such as a user name, a password and the like) of the VNF device corresponding to the VNF node is represented. The message queue identification may be a message queue ID or the like that uniquely identifies a message queue.

For example, as shown in fig. 3, taking a "VNF-a-1" node as an example, the underlined "queue (id)" in the "VNF-a-1" node is the message queue identifier uniquely bound to the VNF-a-1, and the "user: password" is the user information of the VNF-a-1.

The VNF node is a temporary node, that is, the VNF node is created as the VNF corresponding to the VNF node goes online, and is automatically deleted as the VNF goes offline.

The (1-2) "Type" node also includes: at least one queue node;

the queue node is used for storing the VNFM identification bound by the current queue node. The VNFM identification may be information that uniquely identifies a VNFM, such as an IP address of the VNFM. The queue node may be named with the message queue identification corresponding to the queue node.

For example, as shown in fig. 3, the "Q0" node, "Q1" node, "Q3" node, "Q4" node in fig. 3 are all queue nodes.

Taking the node "Q1" as an example, the underlined "Manager id" in the node "Q1" is the VNFM id of the binding of the node "Q1

The queue node is a temporary node, that is, the queue node is created as the VNFM bound by the queue node goes online, and is automatically deleted as the VNFM bound by the queue node goes offline.

And the queue nodes under each Type node are in one-to-one correspondence with the message queues corresponding to the device types characterized by the Type node.

For example, assuming that the message queue 1, the message queue 2, and the message queue 3 are configured in advance to process management messages of a VNF device with a device Type of VSR, a "Type" node corresponding to the VNF device Type is a "Type-VSR" node, and 3 queue nodes are included below the "Type-VSR" node. These 3 queue nodes correspond one-to-one to message queue 1, message queue 2, and message queue 3.

For the "/Managers" node and the nodes included under the "/Managers" node:

(1) included under the "/Managers" node are: VNFM node

For example, VNFM (0), VNFM (1), VNFM (N-1) as in fig. 3 are all VNFM nodes.

The VNFM nodes correspond to the VNFMs in the VNF networking one by one. The VNFM node records a queue identifier of each message queue in the VNFM and a device type identifier to which the queue node indicated by the queue identifier belongs. The VNFM node may be named with a VNFM identification corresponding to the VNFM node.

As shown in fig. 3, taking the "VNFM (0)" node as an example, the "type (id) -queue (id)" marked on the downward sliding line in the "VNFM (0)" node is the corresponding relationship between the message queue identifier and the device type identifier on the VNFM (0).

The VNFM node is a temporary node, i.e. the VNFM node is created as the VNFM is brought online and deleted as the VNFM is taken offline.

The node tree stored on the Zookeeper platform is described in detail below by way of specific examples in conjunction with fig. 4.

It is assumed that 5 VNFs are included in the VNF networking, and the identities of the 5 VNFs are VNF41, VNF42, VNF43, VNF44, and VNF45, respectively. The equipment types of VNF41, VNF42 and VNF43 are all VSRs, and the equipment types of VNF44 and VNF45 are VSGs.

The VNFM cluster in the VNF networking includes 2 VNFM devices, and these two VNFM identifiers are VNFM41 and VNFM42, respectively.

VNFM41 includes 3 message queues, message queue 1 (identified as Q1), message queue 2 (identified as Q2), and message queue 3 (identified as Q3).

VNFM42 includes 2 message queues, message queue 4 (identified as Q4) and message queue 5 (identified as Q5).

It is assumed that the message queue 1, the message queue 2, and the message queue 4 are set in advance as message queues for processing management messages sent to VNF devices of the VSR type, and the message queue 3 and the message queue 5 are set in advance as message queues for processing management messages sent to VNF devices of the VSG type.

Assume that VNF41 is bound to message queue 1, VNF42 is bound to message queue 2, VNF43 is bound to message queue 4, VNF44 is bound to message queue 3, and VNF45 is bound to message queue 5.

The node tree stored by the Zookeeper platform for this VNF networking is shown in fig. 4.

In FIG. 4, two permanent nodes are included under the root node of the node tree, namely the "/Types" node and the "/Managers" node.

For the "/Types" node,

included under the "/Types" node are: a "Type-VSR" node and a "Type-VSG" node.

Wherein the "Type-VSR" node corresponds to a VSR Type and the "Type-VSG" corresponds to a VSG Type.

(1) The "Type-VSR" node includes: three queue nodes (temporary nodes) and one "Devices" node (permanent node).

And (1-1) the three queue nodes are respectively a node Q1, a node Q2 and a node Q4.

The "Q1" node characterizes message queue 1 in the VNF networking, and the "Q1" node records the identity of VNFM 41. The "Q2" node characterizes the message queue 2 in the VNF networking, and the "Q1" node records the identity of VNFM 41. The "Q4" node characterizes the message queue 4 in the VNF networking, and the "Q4" node records the identity of VNFM 42.

The (1-2) "Devices" node includes: three VNF nodes, respectively a "VNF 41" node, a "VNF 42" node, and a "VNF 43" node.

The "VNF 41" node represents VNF41 in the VNF networking, and the "VNF 41" node records therein the identifier of the message queue 1 (i.e., Q1), the user information of VNF41, and the like.

The "VNF 42" node characterizes the VNF42 in the VNF networking, and the "VNF 42" node records therein the identification of the message queue 2 (i.e., Q2) and the user information of the VNF42, and the like.

The "VNF 43" node characterizes the VNF43 in the VNF networking, and the "VNF 43" node records therein the identification of the message queue 4 (i.e., Q4) and the user information of the VNF43, and the like.

(2) The "Type-VSG" node includes: 2 queue nodes (temporary nodes) and one "Devices" node (permanent node).

(2-1) the 2 queue nodes are respectively a 'Q3' node and a 'Q5' node.

The "Q3" node characterizes the message queue 3 in the VNF networking, and the "Q3" node records the identity of VNFM 41. The "Q5" node characterizes the message queue 5 in the VNF networking, and the "Q5" node records the identity of VNFM 42.

The (2-2) "Devices" node includes: 2 VNF nodes, respectively "VNF 44" node, "VNF 45".

The "VNF 44" node represents VNF44 in the VNF networking, and the "VNF 44" node records therein the identifier of the message queue 3 (i.e., Q3), the user information of VNF44, and the like.

The "VNF 45" node characterizes the VNF45 in the VNF networking, and the "VNF 45" node records therein the identification of the message queue 5 (i.e., Q5) and the user information of the VNF45, and the like.

For the "/Managers" node,

included under the "/Managers" node are: two VNFM nodes, respectively "VNFM 41" node and "VNFM 42" node.

The VNFM41 node represents the VNFM41 in the VNF networking, and records a Type identifier and a queue identifier of a message queue on the VNFM41, for example, the VNFM41 node records a Type-VSR- - -Q1, a Type-VSR- - -Q2, and a Type-VSG- - -Q3.

The VNFM42 node represents the VNFM42 in the VNF networking, and records a Type identifier and a queue identifier of a message queue on the VNFM42, for example, the VNFM42 node records a Type-VSR- - -Q4 and a Type-VSG- - -Q5.

2. Creation of a node tree

1) A VNFM node and a queue node are created in a node tree.

Step 1: when the Zookeeper platform detects that the VNFM is online, acquiring VNFM registration information; the VNFM registration information carries the identifier of the VNFM, an identifier of a message queue on the VNFM (for convenience of description, the message queue on the VNFM is referred to as a second message queue), and an identifier of a device type corresponding to the second message queue.

When implemented, when the VNFM is online, the VNFM may register with the Zookeeper to establish a connection between the VNFM and the Zookeeper. In the interactive registration process, the VNFM sends registration information to the Zookeeper, where the registration information includes: the VNFM identifier, identifiers of the second message queues included in the VNFM, and VNF device types corresponding to the second message queues.

Step 2: and the Zookeeper platform creates a VNFM node corresponding to the VNFM identifier in the node tree.

Specifically, the Zookeeper platform may generate a node creation path of the VNFM node based on the VNFM identifier in the registration message, and create the VNFM node based on the node creation path.

The VNFM node creation path is to indicate a creation location of the VNFM node in a node tree.

And step 3: the Zookeeper platform may create a queue node corresponding to the second message queue under the device type node corresponding to the device type identifier.

The Zookeeper platform may generate a queue node creation path based on the identifier of the second message queue and the device type identifier in the registration message, and create a queue node corresponding to the message queue on the VNFM based on the queue node creation path.

Wherein the queue node creation path is used for indicating the creation position of the queue node in the node tree.

It should be noted that the number of message queues on the VNFM may be one or more, and is not specifically limited herein.

And 4, step 4: the Zookeeper platform may record, in the VNFM node, a correspondence between the second queue identifier and the device type identifier, and record, in the queue node, the VNFM identifier.

For example, taking fig. 4 as an example, assuming that VNF41 in the VNF network is online, VNFM41 includes 3 message queues, namely message queue 1 (queue id Q1), message queue 2 (queue id Q2), and message queue 3 (queue id Q3). Message queue 1 and message queue 2 are allocated for use by VNF devices of the VSR type, and message queue 3 is allocated for use by VNF devices of the VSG type.

After VNFM41 comes online, VNFM41 may perform registration interactions with Zookeeper to establish a connection between VNFM41 and Zookeeper. During the registration interaction, the VNFM41 may send VNFM registration information to the Zookeeper platform, where the VNFM registration information includes: VNFM41, queue identification Q1-device type identification VSR, queue identification Q2-device type identification VSR, and queue identification Q3-device type identification VSG.

After receiving the VNFM registration information, the Zookeeper platform may generate a VNFM node creation path for the VNFM41 node, that is, "/Managers/VNFM 41", according to the VNFM41 in the VNFM registration information, and then the Zookeeper platform may create a path according to the VNFNM node, create a VNFM41 node corresponding to the VNFM41 under the "/Managers" node, and record Type-VSR-Q1, Type-VSR-Q2, and Type-VSR-Q3 in the VNFM41 node.

In addition, taking the queue node Q1 corresponding to the message queue 1 as an example, the Zookeeper platform may also generate a node creation path of the queue node Q1 according to the Q1-VSR in the registration information. The node creates a path as follows: "/Types/Type-VSR/Q1", the Zookeeper platform may create a queue node Q1 under the "Type-VSR" node based on the creation path and record VNFM41 in the queue node Q1.

Similarly, the Zookeeper platform may create queue node Q2, such as in the manner of generating node queue Q1.

For the create queue node Q3, the Zookeeper platform may also generate a node creation path for queue node Q3 according to Q3-VSG in the registration information. The node creates a path as follows: "/Types/Type-VSG/Q3", the Zookeeper platform may create a queue node Q3 under the "Type-VSG" node based on the creation path and record VNFM41 in the queue node Q3.

2) VNF nodes are created in a node tree. (hereinafter, the target VNF is described as an example)

Step 1: the Zookeeper platform acquires the VNF registration information when detecting that the target VNF is online; the VNF registration information comprises the target VNF identification and a device type identification of the target VNF.

In implementation, when the target VNF is online, the target VNF performs registration interaction with the Zookeeper to establish a connection between the target VNF and the Zookeeper.

In the interactive registration process, the target VNF sends registration information to the Zookeeper, where the registration information includes: a target VNF identification, a device type identification of the target VNF.

Step 2: the Zookeeper platform creates a VNF node corresponding to the target VNF under the device type node corresponding to the device type identifier of the target VNF in the node tree; the message queue identifier of the created target VNF node record is null;

in implementation, the Zookeeper platform may generate a VNF node creation path based on the VNF identifier and the device type identifier in the registration message, and create a VNF node corresponding to the newly online VNF based on the VNF node creation path.

For example, the VNF41 is illustrated as being on-line, again taking the example shown in fig. 4 as an example. VNF41 is of the VSR type.

After VNF41 comes online, VNF41 may perform registration interactions with Zookeeper to establish a connection between VNF41 and Zookeeper. During the registration interaction, the VNF41 may send registration information to the Zookeeper platform, where the registration information includes: VNF 41-VSR.

After receiving VNF registration information sent by the VNF41, the Zookeeper platform may generate a VNF node creation path for a VNF41 node, that is, "/Types-VSR/Devices/VNF 41", according to the VNF41-VSR in the VNF registration information, and then the Zookeeper platform may create a path according to the VNF node, and create a VNF41 node corresponding to the VNF41 under a "Devices" node under the "Type-VSR" node.

Certainly, the registration message of the VNF may also carry user information corresponding to the target VNF, and the Zookeeper platform may record the user information on the newly created target VNF node.

It should be noted that, since the newly created target VNF node does not have a unique binding message queue, a message queue identifier uniquely bound by the VNF node is not recorded on the newly created target VNF node. How to bind the queue identification for the newly created target VNF node is described in detail below.

3) Deleting VNFM nodes and queue nodes in a node tree

And when the Zookeeper platform detects that the VNFM is offline, deleting the VNFM node corresponding to the VNFM and the queue node indicated by the queue node identification recorded in the VNFM node from the node tree.

For example, still taking fig. 4 as an example, the VNFM41 is taken as an off-line for illustration.

When the Zookeeper platform detects that the VNFM goes offline, the Zookeeper platform can delete the VNFM41 node in the node tree, and delete the queue node Q1 and the queue node Q2 under the "Type-VSR" node and delete the queue node Q3 under the "Type-VSG" node according to the Type-VSR-Q1, the Type-VSR-Q2 and the Type-VSR-Q3 recorded in the VNFM 41.

4) Deleting VNF nodes in a node tree

After the node tree in the Zookeeper platform is introduced, the method for issuing the management message provided by the present application is described in detail below.

Referring to fig. 5, fig. 5 is a flowchart illustrating a method for issuing a management message according to an exemplary embodiment of the present application, which may include the following steps.

Step 501: after receiving the management message for the target VNF, the VNFM sends a query request message carrying the identification information of the target VNF to the Zookeeper platform.

The management message received by the VNFM may be sent by the message producer, or may be sent by other VNFMs in the VNFM cluster.

Step 502: and the Zookeeper platform determines whether a target message queue uniquely bound by the target VNF exists according to the identification information of the target VNF.

The identification information of the target VNF includes: a device type identification of the target VNF, a target VNF identification.

And the Zookeeper platform searches the target device type node indicated by the device type identification of the target VNF in the node tree.

Then, the Zookeeper platform may search, in the VNF nodes included in the target device type node, a target VNF node corresponding to the target VNF identifier.

The Zookeeper can determine whether a message queue identifier is recorded in the VNF node.

If the target VNF records a message queue identifier, it is determined that the target message queue exists, and the recorded message queue identifier is determined as the target message queue identifier.

If no message queue identification is recorded in the target VNF, determining that the target message queue does not exist;

and 503, after the Zookeeper platform determines that the target message queue uniquely bound by the target VNF exists, the Zookeeper platform returns a query success response message to the VNFM. The query success response message carries the target message queue identifier and the identifier of the target VNFM bound to the target message queue.

In implementation, after the Zookeeper platform determines that the target message queue uniquely bound by the target VNF exists, the Zookeeper platform may first determine the identifier of the target VNFM uniquely bound by the target message queue.

Upon determining, the Zookeeper platform may find a target queue node indicated by the target message queue identifier from the queue nodes included in the target device type node found in step 502, and then determine the VNFM identifier recorded in the target queue node as the target VNFM identifier.

Then, the Zookeeper platform may send a query success response message carrying the identifier of the searched target message queue and the identifier of the target VNFM to the VNFM.

Step 504: and after receiving the query success response message, the VNFM controls the target VNFM to add the management message into the target message queue so as to send the management message to the target VNF through the target message queue.

When the query success response message is received by the VNFM, the VNFM can obtain the target message queue identifier and the target VNFM identifier carried by the query success response message.

The VNFM can then detect whether the present VNFM identity is consistent with the target VNFM identity.

1) And if the VNFM identifier is consistent with the target VNFM identifier, adding the management message into a local message queue indicated by the target queue identifier, and sending the management message to the target VNF through the local message queue.

In implementation, generally, the management message can be divided into a management modification message and a management query message.

The management modification message is also called a transaction message, and the management modification message modifies the configuration of the VNF, and common management modification messages include adding configuration, deleting configuration, modifying configuration, and partial real-time query message.

The management query message, also referred to as a non-transaction message, does not modify the configuration of the VNF, mostly for querying the configuration of the VNF.

The message format of the management message is shown in fig. 6.

In fig. 6, the "Type" field of the management message indicates the device Type identification of the VNF to which the management message is directed. For example, when the VNF device for which the management message is intended is a VSR device, the value of the "Type" field may be a value that characterizes the VSR device.

The "Device" field indicates the VNF identification of the VNF Device for which the management message is intended.

The "Operation Type" field indicates the Type of the management message. For example, when the value of the "Operation Type" field is a first preset value, it indicates that the management message is a management modification message, and when the value of the "Operation Type" field is a second preset value, the management message is a management query message.

The "Data" field is used to carry the payload of the management message.

In addition, when the management message is a management query message, a query result is returned to a message producer in order to quickly. In the present application, a cache area is configured on the VNFM for each VNF device. For the cache area corresponding to each VNF device, the cache area records a correspondence between a management query message that has been issued to the VNF device and a query result for the management query message that is returned by the VNF device.

Specifically, in implementation, the cache region may store a hash value of a management query message that has been issued to the VNF device and a corresponding relationship between a query result returned by the VNF device and the management message, where the hash value may be obtained by performing a hash operation on the entire management message; alternatively, the hash operation may be performed on a part of the fields of the management message.

In this embodiment of the present application, the VNFM device only adds the management modification message and the management query message, in which the query result is not stored in the cache of the target VNF, to the local message queue indicated by the target message queue identifier, and sends the two messages to the target VNF for processing. For the management query message with the query result stored in the cache region, the VNFM can directly return the query result to the message producer, thereby greatly improving the message response rate.

In this embodiment, when the management message is added to the local target message queue indicated by the target message queue identifier, the VNFM may first determine the message type of the management message.

Specifically, the VNFM may check an "Operation Type" field of the management message, and if a value of the "Operation Type" is a first preset value, determine that the management message is a management modification message. And if the value of the 'Operation Type' field is a second preset value, determining that the management message is a management query message.

And if the management message is a management modification message, adding the management message into a local target message queue indicated by the target message queue identification.

If the management message is a management query message, determining a cache area corresponding to the target VNF. Then, it is checked whether a query result corresponding to the management query message exists in a cache corresponding to the target VNF.

And if the cache area corresponding to the target VNF has the query result corresponding to the management query message, directly returning the query result to the message producer. And if the cache area corresponding to the target VNF does not have the query result corresponding to the management query message, adding the management message into the local target message queue indicated by the target message queue identifier.

The VNFM may send the management message to the target VNF through a local target message queue.

In addition, after the VNFM receives the query result returned by the target VNF for the management query message, the hash value of the management query message and the query result of the management query message may be added to the cache corresponding to the target VNF.

2) And if the VNFM identifier is not consistent with the target VNFM identifier, sending the management message to the target VNFM. The target VNFM device may perform the operations of step 501 to step 504 after receiving the management message.

In addition, in this embodiment of the application, after the Zookeeper platform determines that the target message queue uniquely bound to the target VNF does not exist, a query failure response message may be returned to the VNFM.

When the VNFM receives the query failure response message, the VNFM may select one local message queue (referred to as a first message queue for convenience of description herein) from a plurality of local message queues on the VNFM.

The VNFM may add the management message to the first message queue to send the management message to the target VNF through the first message queue. Meanwhile, the VNFM may also return the identifier of the first message queue to the Zookeeper platform.

And after receiving the identifier of the first message queue, the Zookeeper platform binds the first message queue with the target VNF.

Specifically, the Zookeeper platform may record the identifier of the first message queue in the target VNF node corresponding to the target VNF identifier.

It should be noted that, after receiving the query failure response message sent by the Zookeeper platform, the VNFM indicates that the target VNF is not yet bound to the unique message queue. The sending of the first queue identifier of the selected local message queue to the Zookeeper platform is to establish a binding relationship between the selected local message queue and the target VNF.

In addition, the VNFM cluster has a principle that a management message of a certain VNF device is issued by preferentially using the same VNFM.

When the VNFM receives a query failure message sent by the Zookeeper platform, it indicates that the VNFM receives a management message for the target VNF for the first time, and due to the principle, the VNFM subsequently receives a large amount of management messages for the target VNF, and in order to reduce cross-VNFM forwarding of the management messages (i.e., in order to forward subsequent management messages for the target VNF through a local message queue, instead of sending the management messages to message queues on other VNFMs for forwarding), the VNFM binds one message queue on the VNFM with the target VNF. By adopting the binding mode, the forwarding of the management message across the VNFMs can be greatly reduced, and the workload of each VNFM is reduced.

As can be seen from the above description, in the present application, a Zookeeper platform is set in a VNF networking, and the Zookeeper platform configures a message queue uniquely bound by a VNF identifier and a VNFM bound by the message queue. After receiving a management message for a target VNF, the VNFM can obtain, from the Zookeeper platform, a target message queue identifier uniquely bound to the target VNF and a VNFM identifier bound to the target message queue, and then control the target VNF to add the management message to the target message queue, and issue the management message to the target VNF through the target message queue.

Next, the management message issuing method provided by the present application is described in detail by taking fig. 4 as an example.

VNFM41 includes 3 message queues, namely message queue 1 (queue id Q1), message queue 2 (queue id Q2), and message queue 3 (queue id Q3).

The VNFM42 includes 2 message queues, namely a message queue 4 (identified as Q4) and a message queue 5 (identified as Q5).

It is assumed that message queue 1, message queue 2, and message queue 4 are pre-assigned to VNF devices of the VSR type, and message queue 3 and message queue 5 are pre-assigned to VNF devices of the VSG type.

Take the example that VNFM41 receives a management message for VNF 41.

Step 601: when the VNFM41 receives a management message for the VNF41, the VNFM41 may send a query message to the Zookeeper platform, where the query message carries the device type identifiers (i.e., VSRs) of the VNF41 and the VNF 41.

Step 602: after receiving the query message, the Zookeeper platform acquires the VNF41 and the VSR carried in the query message. The Zookeeper platform can find the "Type-VSR" node corresponding to the VSR in the node tree, and then find the VNF41 node in each VNF node included under the "Devices" node under the "Type-VSR" node.

Step 603: the Zookeeper platform may determine whether a message queue identification is recorded in the VNF41 node.

1) If the Zookeeper platform determines that the VNF41 node records a message queue identifier.

Step 60311: if the Zookeeper platform determines that the VNF41 node records a message queue identifier (i.e., Q1), the Q1 node is searched for in each queue node included under the "Type-VSR" node, and the VNFM identifier (i.e., VNFM41) recorded in the Q1 node is obtained.

Step 60312: the Zookeeper platform may return a query success response message to the VNFM41, where the query success response message carries the message queue identifier (i.e., Q1) uniquely bound by the VNF41 and the VNFM identifier (i.e., VNFM41) bound by the message queue.

Step 60313: the VNFM41 may detect whether the VNFM identifier carried in the query success message is consistent with the VNFM identifier.

Step 60314: if the VNFM41 is consistent with the VNFM identifier carried by the query success message, the management message is added to the message queue 1 indicated by the Q1, so that the management message is sent to the VNF41 through the message queue 1.

Upon adding the management message to message queue 1, VNFM41 may determine the message type of the management message.

If the management message is a management modification message, the management message is added to the message queue 1.

If the management message is a management query message, the cache 41 corresponding to VNF41 will be determined.

Then, the VNFM41 may check whether the query result corresponding to the management query message exists in the cache 41.

If the cache area 41 has the query result corresponding to the management query message, the query result is returned to the message producer.

If the query result corresponding to the management query message does not exist in the buffer area 41, the management query message is added to the message queue 1.

Step 60315: and if the VNFM41 is not consistent with the VNFM identifier carried by the inquiry success message, sending the management message to the VNFM indicated by the VNFM identifier carried by the inquiry success message.

For example, assuming that the VNFM identifier carried in the query success message is VNFM42, VNFM41 sends the management message to VNFM 42.

After the VNFM42 receives the management message, the above steps 601 to 603 may be repeated.

2) If the Zookeeper platform determines that no message queue identity is recorded in the VNF41 node.

Step 60321: and if the Zookeeper platform determines that no message queue identification is recorded in the VNF41 node, returning a query failure response message to the VNFM 41.

Step 60322: after receiving the query failure response message, the VNFM41 may select one of the local message queue 1, message queue 2, and message queue 3, assuming that the selected message queue is message queue 2.

Step 60323: the VNFM41 may add the management message to the message queue 2 and send the identification of the message queue 2 (Q2) to the Zookeeper platform.

Step 60324: the Zookeeper platform may record Q2 in VNF41 node in the node tree to establish the binding relationship between VNF41 and Q2.

The above is a description of the management message issuing method provided in the present application.

In addition, the application also provides a management message issuing device on the application and VNFM, which corresponds to the management message issuing method.

Referring to fig. 6, fig. 6 is a block diagram of a management message issuing apparatus according to an exemplary embodiment of the present application; the apparatus is applicable to a VNFM and may comprise the following elements.

A sending unit 601, configured to send, after receiving a management message for a target VNF, an inquiry request message carrying identification information of the target VNF to a cluster state synchronization service, so as to indicate that the cluster state synchronization service determines, according to the identification information of the target VNF, whether a target message queue uniquely bound to the target VNF exists;

an obtaining unit 602, configured to obtain, when receiving a response message to successfully query returned by the cluster state synchronization service, an identifier of the target message queue carried in the response message to successfully query and an identifier of a target VNFM bound to the target message queue;

the control unit 603, according to the identifier of the target message queue and the identifier of the target VNFM, controls the target VNFM to add the management message to the target message queue bound to the target VNFM, so as to send the management message to the target VNF through the target message queue.

Optionally, the control unit 603 is specifically configured to check whether the identifier of the target VNFM is consistent with the identifier of the VNFM; if yes, adding the management message into a local target message queue indicated by the identification of the target message queue; and if the VNFM information is inconsistent with the VNFM information, forwarding the management information to the target VNFM.

Optionally, the apparatus further comprises:

a selecting unit 604 (not shown in fig. 6), configured to, when receiving a query failure response message returned by the cluster state synchronization service, select a first message queue from multiple local message queues of the VNFM; adding the management message to the first message queue so as to issue the management message through the first message queue; sending the identifier of the first message queue to the cluster state synchronization service, so that the cluster state synchronization service binds the first message queue and the target VNF.

the control unit 603, when adding the management message to the local target message queue indicated by the identifier of the target message queue, is specifically configured to check the message type of the management message; if the management message is a VNF management modification message, adding the management message into the local target message queue; if the management message is a VNF management query message, determining a target cache area corresponding to the target VNF in the cache area corresponding to each VNF; checking whether the query result of the management message exists in the target cache region; and if the management message does not exist, adding the management message into the local target message queue.

Optionally, the control unit 603 is further specifically configured to, if the query result exists, return the query result corresponding to the management message to the message producer of the management message.

Optionally, the apparatus further comprises: an adding unit 605 (not shown in fig. 6) configured to, when receiving a response message to the management query message sent by the target VNF, add the management message identifier and the query result carried in the response message to the target cache.

Referring to fig. 7, fig. 7 is a hardware block diagram of a VNFM device according to an exemplary embodiment of the present application.

The VNFM device may include: a communication interface 701, a processor 702, a machine-readable storage medium 703, and a bus 704; the communication interface 701, the processor 702, and the machine-readable storage medium 703 are in communication with one another via a bus 704. The processor 702 may perform the above-described management message delivery method by reading and executing machine-executable instructions in the machine-readable storage medium 703 corresponding to the management message delivery control logic.

The machine-readable storage medium 703 as referred to herein may be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, and the like. For example, the machine-readable storage medium may be: volatile memory, non-volatile memory, or similar storage media. In particular, the machine-readable storage medium 403 may be a RAM (random Access Memory), a flash Memory, a storage drive (e.g., a hard disk drive), a solid state disk, any type of storage disk (e.g., a compact disk, a DVD, etc.), or similar storage medium, or a combination thereof.

In addition, the application also provides a management message issuing device corresponding to the management message issuing method.

Referring to fig. 8, fig. 8 is a block diagram of another management message issuing apparatus according to an exemplary embodiment of the present application. The device can be applied to a server running a cluster state synchronization service, and can comprise the following units.

A receiving unit 801, configured to receive an inquiry request message sent by the VNFM; the query request message carries identification information of the target VNF; the query request message is sent after the VNFM receives a management message for the target VNF;

a determining unit 802, configured to determine whether a target message queue uniquely bound to the target VNF exists according to the identification information of the target VNF;

if the VNFM exists, the returning unit 803 returns a query success response message to the VNFM, so that the VNFM controls the target VNFM to add the management message to the target message queue according to the identifier of the target message queue carried by the query success response message and the identifier of the target VNFM bound to the target message queue, and sends the management message to the target VNF through the target message queue.

Optionally, the returning unit 803 is further configured to return a query failure message to the VNFM if the query failure message does not exist;

the device further comprises:

a binding unit (not shown in fig. 8), configured to receive an identifier of a first message queue sent by the VNFM, and bind the first message queue and the target VNF.

the cluster state synchronization service is configured with a node tree;

the determining unit 802 is specifically configured to search, in the node tree, a target device type node indicated by the device type identifier of the target VNF;

the binding unit is specifically configured to record the identifier of the first message queue in the target VNF node.

the device further comprises:

a node creating unit (not shown in fig. 8) configured to acquire the VNFM registration information when detecting that the VNFM is online; the VNFM registration information carries the VNFM identifier, the second message queue identifier on the VNFM, and the device type identifier corresponding to the second message queue on the VNFM;

creating a VNFM node corresponding to the VNFM identifier in the node tree;

or,

the device further comprises:

a node deleting unit (not shown in fig. 8), configured to, when the VNFM is detected to be offline, delete, from the node tree, a VNFM node corresponding to the VNFM and a queue node indicated by a message queue identifier recorded in the VNFM node;

or,

Referring to fig. 9, fig. 9 is a hardware structure diagram of a server running a cluster state synchronization service according to an exemplary embodiment of the present application.

The server may include: a communication interface 901, a processor 902, a machine-readable storage medium 903, and a bus 904; wherein the communication interface 901, the processor 902, and the machine-readable storage medium 903 communicate with one another over a bus 904. The processor 902 may perform the management message delivery method described above by reading and executing machine-executable instructions in the machine-readable storage medium 903 corresponding to the management message delivery control logic.

The machine-readable storage medium 903 referred to herein may be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, and the like. For example, the machine-readable storage medium may be: volatile memory, non-volatile memory, or similar storage media. In particular, the machine-readable storage medium 403 may be a RAM (random Access Memory), a flash Memory, a storage drive (e.g., a hard disk drive), a solid state disk, any type of storage disk (e.g., a compact disk, a DVD, etc.), or similar storage medium, or a combination thereof.

The implementation process of the functions and actions of each unit in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.

For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the application. One of ordinary skill in the art can understand and implement it without inventive effort.

The above description is only exemplary of the present application and should not be taken as limiting the present application, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the scope of protection of the present application.

Claims

1. A management message issuing method is applied to any VNFM in a VNFM cluster of a virtual network function manager, and comprises the following steps:

2. The method of claim 1, wherein the controlling the target VNFM to add the management message to the target message queue bound to the target VNFM to send the management message to the target VNF through the target message queue comprises:

3. The method of claim 1, further comprising:

4. The method according to claim 2, wherein the VNFM is configured with a cache area corresponding to each VNF; the management query message and the query result which are sent to each VNF are recorded in the cache area corresponding to the VNF;

checking a message type of the management message;

if the management message is a VNF management query message, then

5. The method of claim 4, further comprising:

6. The method of claim 4, further comprising:

7. A method for issuing management messages, which is characterized in that a server running with cluster state synchronization service comprises:

8. The method of claim 7, further comprising:

if not, returning a query failure message to the VNFM;

9. The method of claim 8, wherein the identification information of the target VNF comprises: a device type identifier of the target VNF and a target VNF identifier;

the cluster state synchronization service is configured with a node tree;

the binding the first message queue and the target VNF includes:

recording an identification of the first message queue in the target VNF node.

10. The method of claim 9, further comprising, in the node tree: each VNFM node is recorded with: an identifier of a message queue in the VNFM node and an identifier of a device type corresponding to the message queue;

the method further comprises the following steps:

creating a VNFM node corresponding to the VNFM identifier in the node tree;

or,

11. A Virtualized Network Function Manager (VNFM) device comprising a processor and a machine-readable storage medium storing machine-executable instructions executable by the processor, the processor being caused by the machine-executable instructions to perform the method of any one of claims 1 to 6.

12. A machine-readable storage medium having stored thereon machine-executable instructions which, when invoked and executed by a processor, cause the processor to perform the method of any of claims 1 to 6.

13. A server having a cluster state synchronization service running thereon, the server comprising a processor and a machine-readable storage medium storing machine-executable instructions executable by the processor, the processor being caused by the machine-executable instructions to perform a method as claimed in any one of claims 7 to 10 performed by the cluster state synchronization service.

14. A machine-readable storage medium having stored thereon machine-executable instructions which, when invoked and executed by a processor, cause the processor to perform the method of any of claims 7 to 10.