CN108337116B - Message order-preserving method and device - Google Patents

Abstract

The disclosure relates to a message order-preserving method and a device, wherein the method comprises the following steps: when a VNF device is registered to a VNFM node, the VNFM node creates a message queue for storing configuration messages of the VNF device, and binds any exchanger with the message queue through a binding keyword, so that the exchanger routes the received configuration messages carrying routing keywords matched with the binding keyword to the message queue; and the VNFM node acquires the configuration message from the message queue and sends the acquired configuration message to the VNF equipment. Therefore, all configuration messages to be sent to the VNF equipment are stored in one message queue, and the disorder of the configuration messages can be avoided.

Description

Message order-preserving method and device

Technical Field

The present disclosure relates to the field of network communication technologies, and in particular, to a message order preserving method and apparatus.

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).

Fig. 1 shows a schematic diagram of an NFV architecture. As shown in fig. 1, the NFV architecture includes a cloud platform, an LB (Load Balance) device, a plurality of VNFMs (VNF managers), a Database (Database), and a plurality of VNF devices.

The cloud platform sends a REST API (representational State Transfer Programming Interface) request to the LB device, and the VNF device sends a registration packet and a keep-alive packet to the LB device. The LB device distributes the REST API request, the registration message, and the keep-alive message to a plurality of VNFMs. Each VNFM shares a database.

The VNFM issues a configuration to the assigned VNF cluster by sending a configuration message to the assigned VNF cluster, where the issued configuration is, for example, a VPN (Virtual Private Network) instance configuration.

Whether the configuration message is completely and orderly sent to the VNF device determines whether the VNF device can normally serve as a network element of a corresponding network function. The VNFM needs to ensure that configuration messages corresponding to multiple sequentially arriving REST API requests can be issued to the VNF device in order. However, when REST API requests are too intensive and there is a difference in processing performance between VNFMs, a problem of out-of-order configuration messages results.

Disclosure of Invention

In view of this, the present disclosure provides a message order preserving method and device.

According to an aspect of the present disclosure, there is provided a message order-preserving method applied to a virtualized network function manager VNFM system, the VNFM system including at least one VNFM node and a RabbitMQ node, the RabbitMQ node including at least one switch, the method including:

when a VNF device is registered to a VNFM node, the VNFM node creates a message queue for storing configuration messages of the VNF device, and binds any exchanger with the message queue through a binding keyword, so that the exchanger routes the received configuration messages carrying routing keywords matched with the binding keyword to the message queue;

and the VNFM node acquires the configuration message from the message queue and sends the acquired configuration message to the VNF equipment.

According to another aspect of the present disclosure, there is provided a message order-preserving apparatus applied to a virtualized network function manager VNFM system, the VNFM system including at least one VNFM node and a RabbitMQ node, the RabbitMQ node including at least one switch, the apparatus including:

a creation processing module, configured to create a message queue for storing configuration messages of the VNF device when the VNF device is registered in the VNFM node, and bind any one of the switches with the message queue through a binding key, so that the switch routes the received configuration message carrying a routing key matched with the binding key to the message queue;

and the acquisition processing module is used for acquiring the configuration message from the message queue and sending the acquired configuration message to the VNF equipment.

The technical scheme provided by the embodiment of the disclosure can have the following beneficial effects: when the VNF equipment is registered to the VNFM node, any exchanger is bound with the created message queue through the binding keywords, so that the exchanger routes the received configuration message carrying the routing keywords matched with the binding keywords to the message queue, acquires the configuration message from the message queue and sends the configuration message to the VNF equipment, and therefore all the configuration messages to be sent to the VNF equipment are stored in the message queue, and disorder of the configuration messages can be avoided.

Other features and aspects of the present disclosure will become apparent from the following detailed description of exemplary embodiments, which proceeds with reference to the accompanying drawings.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments, features, and aspects of the disclosure and, together with the description, serve to explain the principles of the disclosure.

Fig. 1 is a schematic diagram of an NFV architecture.

Fig. 2 is a schematic diagram of a process of generating out-of-order configuration messages in the NFV architecture shown in fig. 1.

Fig. 3 is a flowchart of a message order preserving method according to an embodiment of the present disclosure.

Fig. 4 shows a block diagram of a message ordering apparatus according to an embodiment of the present disclosure.

Fig. 5 is a block diagram illustrating a hardware structure for a message order preserving apparatus according to an exemplary embodiment.

Detailed Description

Various exemplary embodiments, features and aspects of the present disclosure will be described in detail below with reference to the accompanying drawings. In the drawings, like reference numbers can indicate functionally identical or similar elements. While the various aspects of the embodiments are presented in drawings, the drawings are not necessarily drawn to scale unless specifically indicated.

The word "exemplary" is used exclusively herein to mean "serving as an example, embodiment, or illustration. Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.

Furthermore, in the following detailed description, numerous specific details are set forth in order to provide a better understanding of the present disclosure. It will be understood by those skilled in the art that the present disclosure may be practiced without some of these specific details. In some instances, methods, means, elements and circuits that are well known to those skilled in the art have not been described in detail so as not to obscure the present disclosure.

For convenience of explanation, a part of the concept related to the present disclosure will be explained first.

Fig. 2 is a schematic diagram of a process of generating out-of-order configuration messages in the NFV architecture shown in fig. 1. As shown in fig. 2, the process includes the following steps.

In step S110, the cloud platform sends a REST API request I and a REST API request II to the LB device.

In step S120, the LB device transmits REST API request I to VNFM1 and REST API request II to VNFM 2.

In step S130, the VNFM1 parses the REST API request I and writes the parameters carried by the REST API request I into the database; VNFM2 parses REST API request II and writes the parameters carried by REST API request II into the database.

In step S140, the VNFM1 generates a configuration message to be issued to the VNF device according to the parameter carried by the REST API request I and writes the generated configuration message into a queue of the VNFM 1; the VNFM2 generates a configuration message to be issued to the VNF device according to the parameter carried by the REST API request II and writes the generated configuration message into a queue of the VNFM 2.

Because the number of queues is limited, the configuration message to be sent to the VNF device is hashed to the corresponding queue using the IP address of the VNF device, thereby ensuring that the configuration messages to be sent to the same VNF device are stored in the same queue. Meanwhile, there are also configuration messages in one queue to be sent to multiple VNF devices. Assuming that the configuration messages to be sent to VNF1, VNF2, and VNF3 by VNFM1 are in the same queue, VNFM1 needs to send the configuration messages of each VNF device in sequence according to the order of the queue.

In step S150, VNFM1 and VNFM2 return the result of the REST API processing to the cloud platform, respectively.

REST API processing includes: the process of writing the parameters into the database performed in step S130 described above and the process of generating the configuration message from the parameters performed in step S140.

In step S160, the background threads of VNFM1 and VNFM2 process the configuration messages in their respective queues, respectively.

For VNF3, if configuration messages to be sent down to VNF3 are stored in the queue of VNFM1 and the queue of VNFM2, respectively, and the order of REST API requests II takes precedence over the order of REST API requests I, then theoretically configuration commands II arrive at VNF3 before configuration commands I. However, assuming that the network latency between VNFM2 and VNF1 is large and the processing performance of VNF1 is low, the configuration issue result returned by VNF1 to VNFM2 is slow, which blocks the processing of other configuration messages in the queue of VNFM2, so that configuration command II arrives at VNF3 later than configuration command I, thereby causing configuration message misordering.

Therefore, if configuration messages to be sent to the same VNF device are stored in different VNFM queues and processing speeds of different VNFMs are not consistent, the configuration messages to be sent to the same VNF device may be out of order.

For this reason, the present disclosure proposes the following embodiments to solve the above-described problems.

Fig. 3 is a flowchart of a message ordering method that may be applied to a virtualized network function manager VNFM system, wherein the VNFM system includes at least one VNFM node and a RabbitMQ node, and the RabbitMQ node includes at least one switch (Exchange), according to an embodiment of the present disclosure. In this embodiment, the VNFM node and the RabbitMQ node may be deployed on the same physical device, and of course, the VNFM node and the RabbitMQ node may also be deployed on different physical devices.

As shown in fig. 3, the message order-preserving method may include the following steps.

In step S310, when a VNF device is registered in the VNFM node, the VNFM node creates a message queue for storing configuration messages of the VNF device, and binds any switch with the message queue through a binding key, so that the switch routes a received configuration message carrying a routing key matching the binding key to the message queue.

In this embodiment, when a VNF device is registered to the VNFM node, the VNFM node creates a message queue (queue) as a Consumer (Consumer), and all configuration messages to be sent to the VNF device are stored in the message queue, that is, all configuration messages to be sent to a VNF device are stored in a message queue.

The types of switches in the RabbitMQ node include fanout type, direct type, and topic type, each implementing a different routing algorithm. A switch of fanout type sends the received message to all queues bound to the switch. The direct type switch sends the received message to a message queue with a binding key (binding key) completely matched with a routing key (routing key). A topoic-type switch sends the received message to one or more queues that satisfy a wildcard rule, where the symbol "#" matches one word and the symbol "#" matches multiple words.

In this embodiment, the VNFM node may declare the type of any switch as a topic type, and bind the created message queue with the switch through a binding key. When the exchanger receives the configuration message, the exchanger matches the route key word in the configuration message with the binding key word, if the matching is successful, the exchanger sends the configuration message to the message queue bound by the exchanger, namely the created message queue. Otherwise, if the matching fails, the switch discards the configuration message.

In step S330, the VNFM node acquires a configuration message from the message queue, and sends the acquired configuration message to the VNF device.

In this embodiment, when the VNF device is registered to the VNFM node, the VNFM node continuously acquires, as a consumer, the configuration message from the created message queue, so that as long as the switch bound to the created message queue sends the configuration message for the VNF device to the message queue, the VNFM node can acquire the configuration message from the message queue. In other words, when the created message queue bound switch sends a configuration message for the VNF device to the message queue, the present VNFM node reads the configuration message from the message queue.

Therefore, in the message order-preserving method of this embodiment, when the VNF device is registered in the VNFM node, any one of the exchangers is bound to the created message queue by the binding keyword, so that the exchanger routes the received configuration message carrying the routing keyword matched with the binding keyword to the message queue, and obtains the configuration message from the message queue and sends the configuration message to the VNF device, and thus, all the configuration messages to be sent to the VNF device are stored in one message queue, and thus, the occurrence of disorder of the configuration messages can be avoided.

In a possible implementation manner, when the VNF device is registered to the VNFM node, the message order-preserving method may further include the following steps:

receiving a registration message sent by VNF equipment;

analyzing the registration message to obtain the IP address of the VNF equipment;

and generating a binding keyword according to the obtained IP address and the first configuration rule.

In this embodiment, when the VNF device is to be registered to the VNFM node, the VNFM node may receive a registration packet sent by the VNF device. The registration message sent by the VNF device carries the source IP address, the destination IP address, and the cluster identifier. The source IP address is an IP address of the VNF device, the destination IP address is an IP address of the VNFM node, and the cluster identifier is an identifier of a VNF cluster to which the VNF device belongs.

Therefore, the VNFM node obtains the IP address of the VNF device by analyzing the registration packet sent by the VNF device, and may generate the binding keyword according to the IP address of the VNF device and the predetermined configuration rule. For example, the binding key is ". mgtIP".

In one possible implementation manner, the message order-preserving method may further include: when a characterization state transfer application programming interface (REST) API request for a VNF device is received, a configuration message for the VNF device is generated, and the generated configuration message is sent to the RabbitMQ nodes, so that each switch in the RabbitMQ nodes receives the configuration message, wherein the generated configuration message carries a routing key.

In this embodiment, when receiving a REST API request for a VNF device, the VNFM node may obtain, by parsing the REST API request, a parameter carried by the REST API request, and may generate a configuration message for the VNF device according to the obtained parameter. The REST API request carries parameters, such as a service identifier, for the production configuration message. In one possible implementation, the VNFM node may generate a configuration message for the VNF device by combining the obtained parameters.

All the switches of the RabbitMQ node can receive the configuration message sent by the VNFM node, each switch matches the routing key in the received configuration message with the binding key of each switch, and if the matching is successful, each switch sends the received configuration message to the binding message queue. Otherwise, if the matching fails, each switch discards the configuration message.

In one possible implementation, when a REST API request for a VNF device is received, the message order preserving method may further include the steps of:

analyzing the REST API request to obtain parameters carried by the REST API request;

determining an IP address of the VNF device according to the parameters;

and generating a routing key according to the determined IP address and a second configuration rule.

In this embodiment, when receiving a VNF cluster allocation request, the VNFM node allocates a cluster for carrying VPC services, and the VNFM node may record a correspondence between an IP address of a VNF device in the allocated VNF cluster and a service identifier carried by the VNF cluster allocation request.

When receiving a REST API request for a VNF device, the VNFM node may obtain a parameter carried by the REST API request by parsing the REST API request, where the parameter includes a service identifier. The VNFM node may determine, according to the recorded correspondence and the service identifier included in the parameter, an IP address corresponding to the service identifier included in the parameter as an IP address of the VNF device.

The VNFM node may generate a routing key according to the IP address of the VNF device and a predetermined configuration rule. For example, the routing key is "cfg.mgtIP", and the routing key is "123. mgtIP".

Since the binding key is ". mgtIP", the routing key containing ". mgtIP" matches the binding key ". mgtIP", and the routing key not containing ". mgtIP" does not match the binding key ". mgtIP", the switch sends the configuration message carrying the routing key containing ". mgtIP" to the bound message queue.

Illustratively, the routing keys "cfg.mgtIP" and "123. mgtIP" in the above example both contain ". mgtIP", so the routing keys "cfg.mgtIP" and "123. mgtIP" both match the binding key ". mgtIP", and the switch sends the configuration message carrying "cfg.mgtIP" and the configuration message carrying "123. mgtIP" to the bound message queue.

In one possible implementation manner, issuing the acquired configuration message to the VNF device includes: and sending the acquired configuration message carrying the routing keyword matched with the IP address of the VNF equipment to the VNF equipment.

In this embodiment, it can be implemented that the configuration message to be sent to one VNF device is stored in one message queue, where the message queue may store only the configuration message to be sent to one VNF device, or may store the configuration messages to be sent to multiple VNF devices.

When a message queue only stores configuration messages of one VNF device, the VNFM node continuously acquires the configuration messages from the created message queue as a consumer, and directly issues the acquired configuration messages to the VNF device.

When one message queue stores configuration messages of a plurality of VNF devices, the VNFM node is used as a consumer to continuously acquire the configuration messages from the created message queue, matches routing keywords carried by the acquired configuration messages with the IP addresses of the VNF devices, and if the routing keywords are matched with the IP addresses of the VNF devices, sends the configuration messages to the VNF devices.

Fig. 4 shows a block diagram of a message ordering apparatus that may be applied to a virtualized network function manager VNFM system, wherein the VNFM system includes at least one VNFM node and a RabbitMQ node, and the RabbitMQ node includes at least one switch, according to an embodiment of the present disclosure. In this embodiment, the VNFM node and the RabbitMQ node may be deployed on the same physical device, and of course, the VNFM node and the RabbitMQ node may also be deployed on different physical devices.

As shown in fig. 4, the message order-preserving apparatus 400 may include a creation processing module 410 and an acquisition processing module 430.

The creation processing module 410 is configured to create a message queue for storing configuration messages of the VNF device when the VNF device is registered in the VNFM node, and bind any one of the switches with the message queue through the binding key, so that the switch routes the received configuration message carrying the routing key matching with the binding key to the message queue.

The obtaining processing module 430 is connected to the creating processing module 410, and is configured to obtain the configuration message from the message queue, and send the obtained configuration message to the VNF device.

In a possible implementation manner, when the VNF device is registered to the VNFM node, the message order-preserving apparatus 400 may further include:

a receiving module (not shown) configured to receive a registration packet sent by the VNF device;

a parsing module (not shown) for parsing the registration packet to obtain an IP address of the VNF device;

a generating module (not shown) for generating a binding key according to the obtained IP address and the first configuration rule.

In a possible implementation manner, the message ordering apparatus 400 may further include:

and a generation processing module (not shown) for generating a configuration message for the VNF device when receiving a characterization state transfer application programming interface, REST, API, request for the VNF device, and sending the generated configuration message to the RabbitMQ nodes, so that each switch in the RabbitMQ nodes receives the configuration message, wherein the generated configuration message carries the routing key.

In a possible implementation manner, when receiving a REST API request for a VNF device, the message order keeping apparatus 400 may further include:

the analysis module is used for analyzing the REST API request to obtain parameters carried by the REST API request;

a determining module for determining an IP address of the VNF device according to the parameter;

and the generating module is used for generating the routing key words according to the determined IP address and the second configuration rule.

In one possible implementation, the acquisition processing module 430 is configured to: and sending the acquired configuration message carrying the routing keyword matched with the IP address of the VNF equipment to the VNF equipment.

With regard to the apparatus in the above-described embodiment, the specific manner in which each module performs the operation has been described in detail in the embodiment related to the method, and will not be elaborated here.

Fig. 5 is a block diagram illustrating a hardware structure for a message order preserving apparatus according to an exemplary embodiment. Referring to fig. 5, the apparatus 900 may include a processor 901, a machine-readable storage medium 902 having stored thereon machine-executable instructions. The processor 901 and the machine-readable storage medium 902 may communicate via a system bus 903. Also, the processor 901 performs the message ordering method described above by reading machine-executable instructions in the machine-readable storage medium 902 corresponding to the message ordering logic.

The machine-readable storage medium 902 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: a RAM (random Access Memory), a volatile Memory, a non-volatile Memory, a flash Memory, a storage drive (e.g., a hard drive), a solid state drive, any type of storage disk (e.g., an optical disk, a dvd, etc.), or similar storage medium, or a combination thereof.

Having described embodiments of the present disclosure, the foregoing description is intended to be exemplary, not exhaustive, and not limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terms used herein were chosen in order to best explain the principles of the embodiments, the practical application, or technical improvements to the techniques in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

Claims (8)

1. A message order-preserving method applied to a Virtualized Network Function Manager (VNFM) system, the VNFM system including at least one VNFM node and a RabbitMQ node, the RabbitMQ node including at least one switch, the method comprising:

when a VNF device is registered to a VNFM node, the VNFM node creates a message queue for storing configuration messages of the VNF device, and binds any exchanger with the message queue through a binding keyword, so that the exchanger routes the received configuration messages carrying routing keywords matched with the binding keyword to the message queue;

the VNFM node acquires a configuration message from the message queue and sends the acquired configuration message to the VNF equipment;

when the VNF device is registered to the VNFM node, the method further includes: receiving a registration message sent by the VNF equipment; analyzing the registration message to obtain an IP address of the VNF device; generating the binding keyword according to the obtained IP address and a first configuration rule;

the VNFM node acquires a configuration message from the message queue and issues the acquired configuration message to the VNF device, including:

when a message queue only stores configuration messages of one VNF device, the VNFM node continuously acquires the configuration messages from the created message queue as a consumer and directly sends the acquired configuration messages to the VNF device;

when one message queue stores configuration messages of a plurality of VNF devices, the VNFM node is used as a consumer to continuously acquire the configuration messages from the created message queue, matches routing keywords carried by the acquired configuration messages with the IP addresses of the VNF devices, and if the routing keywords are matched with the IP addresses of the VNF devices, sends the configuration messages to the VNF devices.

2. The method of claim 1, further comprising:

generating a configuration message for the VNF device upon receiving a characterization state transfer application programming interface (REST API) request for the VNF device, and sending the generated configuration message to the RabbitMQ nodes such that each switch in the RabbitMQ nodes receives the configuration message, wherein the generated configuration message carries the routing key.

3. The method of claim 2, wherein when a REST API request is received for the VNF device, further comprising:

analyzing the REST API request to obtain parameters carried by the REST API request;

determining an IP address of the VNF device according to the parameters;

and generating the routing key according to the determined IP address and a second configuration rule.

4. The method according to any of claims 1 to 3, wherein issuing the acquired configuration message to the VNF device comprises:

and sending the acquired configuration message carrying the routing keyword matched with the IP address of the VNF equipment to the VNF equipment.

5. A message order-preserving apparatus applied to a Virtualized Network Function Manager (VNFM) system, the VNFM system including at least one VNFM node and a RabbitMQ node, the RabbitMQ node including at least one switch, the apparatus comprising:

a creation processing module, configured to create a message queue for storing configuration messages of the VNF device when the VNF device is registered in the VNFM node, and bind any one of the switches with the message queue through a binding key, so that the switch routes the received configuration message carrying a routing key matched with the binding key to the message queue;

the acquisition processing module is used for acquiring the configuration message from the message queue and sending the acquired configuration message to the VNF equipment;

when the VNF device is registered to the present VNFM node, the apparatus further includes:

a receiving module, configured to receive a registration packet sent by the VNF device;

the analysis module is used for analyzing the registration message to obtain the IP address of the VNF equipment;

the generating module is used for generating the binding keyword according to the obtained IP address and the first configuration rule;

the acquisition processing module is further configured to: when a message queue only stores configuration messages of one VNF device, the VNFM node continuously acquires the configuration messages from the created message queue as a consumer and directly sends the acquired configuration messages to the VNF device;

when one message queue stores configuration messages of a plurality of VNF devices, the VNFM node is used as a consumer to continuously acquire the configuration messages from the created message queue, matches routing keywords carried by the acquired configuration messages with the IP addresses of the VNF devices, and if the routing keywords are matched with the IP addresses of the VNF devices, sends the configuration messages to the VNF devices.

6. The apparatus of claim 5, further comprising:

and the generation processing module is used for generating a configuration message for the VNF device when a representation state transfer application programming interface (REST) API request for the VNF device is received, and sending the generated configuration message to the RabbitMQ nodes so that each switch in the RabbitMQ nodes receives the configuration message, wherein the generated configuration message carries the routing key.

7. The apparatus of claim 6, wherein when a REST API request is received for the VNF device, the apparatus further comprises:

the analysis module is used for analyzing the REST API request to obtain parameters carried by the REST API request;

a determining module for determining an IP address of the VNF device according to the parameter;

and the generating module is used for generating the routing key words according to the determined IP addresses and the second configuration rule.

8. The apparatus of any of claims 5 to 7, wherein the acquisition processing module is configured to:

and sending the acquired configuration message carrying the routing keyword matched with the IP address of the VNF equipment to the VNF equipment.

Images