WO2020155987A1

WO2020155987A1 - Scheduling management method and apparatus for network function virtualization nfv architecture

Info

Publication number: WO2020155987A1
Application number: PCT/CN2019/129247
Authority: WO
Inventors: 章佳佳; 陈波; 黄学斌; 曹登京
Original assignee: 华为技术有限公司
Priority date: 2019-02-01
Filing date: 2019-12-27
Publication date: 2020-08-06
Also published as: CN111526168B; CN111526168A

Abstract

Disclosed in embodiments of the present application are a scheduling management method and apparatus for a network function virtualization (NFV) architecture. In the method, a scheduling management device first sets a corresponding VM label for each VM according to the HOSTs to which each VM belongs, and the division of VMs may be implemented by means of the VM labels of the VMs. Under such circumstances, the VMs in the same HOST are of the same type. Then, once determined that a first VM migrates from a first HOST to a second HOST, the scheduling management device updates the VM label of the first VM to the second HOST, and then a scheduler in the NFV architecture is triggered. The scheduler determines whether a first Pod in the first VM meets deployment requirements. If deployment requirements are not met, the scheduler will schedule the first Pod to a second VM of the first HOST. Thus, after the migration of the first VM occurs, the first Pod is still deployed in the first HOST to meet the deployment requirements of the first Pod, thereby meeting the scheduling requirements of the Pod at the HOSTs.

Description

A scheduling management method and device for network function virtualization NFV architecture

This application claims the priority of a Chinese patent application filed with the Chinese Patent Office on February 1, 2019, the application number is 201910104725.8, and the invention title is "A method and device for scheduling management of network function virtualization NFV architecture", and its entire contents Incorporated in this application by reference.

Technical field

This application relates to the field of communication technology, and in particular to a scheduling management method and device for a network function virtualization NFV architecture.

Background technique

Network functions virtualization (NFV) is a software and hardware separation architecture proposed by the European Telecommunications Standards Institute (ETSI) from the perspective of network operators. The goal is based on modern virtualization. Technology, using general-purpose hardware, such as industry-standard large-capacity servers, storage, and switches, to carry multiple network software functions and realize flexible software loading.

The NFV architecture is shown in Figure 1. See Figure 1. The network elements involved in the NFV architecture include: virtualized network function manager (VNFM), virtualized infrastructure manager (VIM) ), platform as a service (platform as a service, PaaS), network function virtualization infrastructure layer (Network Functions Virtualization Infrastructure, NFVI), and the smallest deployment unit Pod. Among them, the main function of VNFM is to realize the life cycle management of VNF, such as deployment/expansion/reduction/offline and other automation capabilities; VNFM decomposes the demand for virtual resources such as virtual machines according to the template and VNF capacity requirements, and can be compared with VIM, etc. cooperate to complete the instantiation of VNF; the main function of VIM is to realize the management and monitoring of the entire infrastructure layer resources (such as computing, storage, network resources); VNFM and VIM together constitute the NFV management module, and can be combined with PaaS Interaction; PaaS is a business model that provides a server platform as a service. PaaS is equipped with a scheduler (such as Google's open source container orchestration engine Kubernetes), which is used to provide resource scheduling, deployment and operation for containerized applications Functions such as expansion and contraction; NFVI is used for the construction of NFV infrastructure. NFVI can include virtual computing (Virtual Computing), virtual storage (Virtual Storage), virtual network (Virtual Network), and virtualization layer (Virtualisation Layer) And hardware resources (Hardware resources); VNF is used to assume the function of virtualization. Pod is the smallest unit of scheduler creation, scheduling and management in PaaS. It runs in a virtual machine (Virtual Machine, VM); in addition, the VM is deployed in the host (HOST), that is, the VM is the parent node of the Pod, and the HOST It is the parent node of the Pod.

In order to cope with various application scenarios, the NFV architecture supports affinity/anti-affinity scheduling for Pod. Pod affinity scheduling refers to deploying the same type of Pod in the same VM. Pod anti-affinity The scheduling of refers to the deployment of Pods of the same or different types in different VMs. Among them, the affinity scheduling of Pods, that is, the deployment of the same type of Pods in different VMs, can reduce the impact of downtime, and the anti-affinity scheduling of Pods, that is, deploy different types of Pods in different VMs. Avoid interference between different types of Pods.

In the current affinity/anti-affinity scheduling of Pods, corresponding labels are set for different VMs in advance, the VMs are divided by labels, and the VMs that the Pod needs to deploy are determined according to the labels of the VMs. For example, when it is necessary to perform affinity scheduling for Pods and deploy each Pod of the same type in the same VM, a target tag can be set for the VM, and each Pod of the same type can be deployed in the VM corresponding to the target tag. All Pods of the same type are deployed in the VM corresponding to the target tag to achieve Pod affinity scheduling; when Pods need to be scheduled for anti-affinity, and each Pod is deployed in different VMs, it can be different VMs are set with different labels. In the process of deploying Pods, when it is determined that a Pod has been deployed in the VM corresponding to a certain label, the Pod to be deployed is deployed in the VM corresponding to other labels, so that each Pod is deployed in different In the VM, the anti-affinity scheduling of Pod is realized.

However, the inventor found in the research process of this application that the prior art can only implement Pod scheduling at the VM level, that is, only a certain type of Pod can be deployed in a specific type of VM. In some application scenarios, it is necessary Realize Pod scheduling at the HOST level, but the existing technology cannot meet the scheduling requirements of the Pod at the HOST, that is, through the existing technology, it is impossible to deploy a certain Pod only in a specific HOST.

Summary of the invention

In order to solve the problem that the prior art cannot meet the scheduling requirements of the Pod on the HOST, embodiments of the present application disclose a scheduling management method and device for a network function virtualization NFV architecture.

In the first aspect, an embodiment of the present application discloses a scheduling management method of a network function virtualization NFV architecture, including:

The scheduling management device in the NFV architecture obtains the host HOST to which each virtual machine VM belongs, and sets a corresponding VM label for the VM, where the VM label includes information about the host to which the VM belongs;

After determining that the first VM is migrated from the first HOST to the second HOST, the scheduling management device updates the VM label of the first VM according to the HOST to which the first VM belongs after the migration;

The scheduling management device triggers a scheduler in the NFV architecture, and the scheduler is used to determine that the first minimum deployment unit Pod in the first VM does not conform to deployment according to the updated VM label of the first VM When required, the first Pod is scheduled to the second VM of the first HOST.

Through the solutions disclosed in the embodiments of the present application, a certain type of Pod can be deployed in a specific HOST, so as to meet the scheduling requirements of the Pod on the HOST and solve the problems of the prior art.

In an alternative design, the scheduling management device obtains the host HOST to which each VM belongs through the VM creation success information fed back by the virtualized infrastructure manager VIM in the NFV architecture;

And/or, the scheduling management device determines that the first VM is migrated from the first HOST to the second HOST through the VM migration completion information fed back by the VIM.

In an optional design, the scheduling management device is a virtualized network function manager VNFM;

Alternatively, the dispatch management device is a platform that is a service module PaaS with the dispatcher built-in.

In an alternative design, when the scheduling management device is a VNFM, the scheduling management device triggers the scheduler in the NFV architecture, including:

The VNFM transmits the VM label change information of the first VM to the PaaS in the NFV architecture, and triggers the scheduler built in the PaaS through the VM label change information of the first VM;

When the scheduling management device is PaaS, the scheduling management device triggering the scheduler in the NFV architecture includes:

After the PaaS determines that the VM label of the first VM has changed, it triggers the built-in scheduler.

In an optional design, when the scheduling management device is a VNFM, after the scheduling management device sets a corresponding VM label for the VM, the method further includes:

The VNFM transmits the correspondence between the VM and the VM tag to the PaaS.

PaaS can obtain the corresponding relationship between the VM and the VM label, so that the VM label of each VM can be determined according to the comparison relationship, and after receiving the VM label change information of the first VM transmitted by the VNFM, according to the VM label of the first VM Change information to determine whether the VM label of the first VM has changed.

In an optional design, before the scheduling management device sets a corresponding VM label for the VM, the method further includes:

The scheduling management device issues an instruction to create a first VM and a second VM to the VIM, and the VIM is used to create the first VM and the second VM after receiving the instruction, and after the creation is successful, to The scheduling management device feeds back the creation success message of the first VM and the second VM.

When a VM needs to be created, the scheduling management device in the NFV architecture will issue an instruction to create a VM to the VIM in the NFV architecture, so that the VIM will create the corresponding VM according to the instruction, and after the VM is successfully created, the VIM will The scheduling management device feeds back a corresponding VM creation success message, so that the creation of the first VM and the second VM can be realized, and the scheduling management device can obtain the creation success message of the first VM and the second VM.

After the scheduling management device sets the corresponding VM label for the VM, the method further includes:

The scheduling management device issues an instruction for creating a first Pod, and the instruction for creating a first Pod includes information about the HOST corresponding to the first Pod.

When the first Pod needs to be deployed in the first HOST, the information of the first HOST can be set in the instruction to create the first Pod. After the first VM in the first HOST receives the instruction to create the first Pod, it determines its own The HOST information included in the VM tag is the same as the HOST information included in the instruction to create the first Pod, and the first Pod deployed on itself is created, so that the first Pod can be created in the first VM.

In an optional design, after the scheduling management device sets a corresponding VM label for the VM, the method further includes:

The scheduling management device issues instructions for creating a third VM and a fourth VM to the VIM, and the instructions for creating the third VM and the fourth VM indicate that the third VM and the fourth VM have a strong anti-affinity The VIM is used to create the third VM and the fourth VM in different HOSTs according to the instructions for creating the third VM and the fourth VM;

The scheduling management device issues an instruction to create a second Pod to the scheduler, and the scheduler is configured to, after receiving the instruction to create a second Pod, determine whether the second Pod and the third VM are When the third Pod has strong anti-affinity, the second Pod is created in the fourth VM.

Since the second Pod and the third Pod have strong anti-affinity, the second Pod and the third Pod need to be deployed in different VMs. In this case, through the above steps, when the third VM is deployed In the case of Pod, the second Pod is deployed in the fourth VM, so as to ensure the strong anti-affinity between the second Pod and the third Pod.

When a VM of the first type needs to be created, the scheduling management device generates an instruction to create a VM of the first type according to a preset limit on the number of VMs of the first type in the same HOST;

The instruction for creating a VM of the first type includes a limit on the number of VMs of the first type, and the instruction for creating a VM of the first type is used to indicate that the VMs of the first type are created in the same HOST. The quantity is not greater than the stated quantity limit.

Through the above steps, it can be ensured that the number of VMs of the first type created in the same HOST does not exceed the number limit.

In the second aspect, an embodiment of the present application discloses a scheduling device of a network function virtualization NFV architecture, which is applied to a scheduling management device, and includes:

The transceiver unit is used to obtain the host HOST to which each virtual machine VM belongs;

The processing unit is configured to set a corresponding VM label for the VM, where the VM label includes information about the HOST to which the VM belongs, and after determining that the first VM migrates from the first HOST to the second HOST, according to the first The host to which the VM belongs after migration updates the VM label of the first VM, and triggers the scheduler in the NFV architecture. The scheduler is used to determine the VM label according to the updated VM label of the first VM. When the first minimum deployment unit Pod in the first VM does not meet the deployment requirements, the first Pod is scheduled to the second VM of the first HOST.

In an optional design, the processing unit is used to obtain the host HOST to which each VM belongs through the VM creation success information fed back by the virtualized infrastructure manager VIM in the NFV architecture;

And/or, the processing unit is configured to determine the migration of the first VM from the first HOST to the second HOST through the VM migration completion information fed back by the VIM.

In an optional design, the embodiment of the application discloses that the scheduling management device is a virtualized network function manager VNFM;

In an alternative design, the embodiment of the present application discloses that when the scheduling management device is a VNFM, the processing unit is configured to transmit the VM label change information of the first VM to the PaaS in the NFV architecture, Triggering the scheduler built in the PaaS through the VM tag change information of the first VM;

When the scheduling management device is PaaS, the processing unit is configured to trigger the built-in scheduler after determining that the VM label of the first VM has changed.

In an alternative design, the embodiment of the present application discloses that when the scheduling management device is a VNFM, after the processing unit sets a corresponding VM tag for the VM, the transceiver unit is further configured to transfer the VM The correspondence relationship with the VM tag is transmitted to the PaaS.

In an optional design, the embodiment of the present application discloses that before setting a corresponding VM label for the VM, the processing unit is further configured to issue the first VM and the second VM to the VIM through the transceiver unit The VIM is used to create a first VM and a second VM after receiving the instruction, and after the creation is successful, feedback the creation success message of the first VM and the second VM to the scheduling management device;

After setting the corresponding VM tag for the VM, the processing unit is further configured to issue an instruction to create a first Pod through the transceiver unit, and the instruction to create the first Pod includes the corresponding first Pod HOST information.

In an alternative design, the embodiment of the present application discloses that after the processing unit sets a corresponding VM tag for the VM, the processing unit is further configured to issue the creation of a third VM to the VIM through the transceiver unit And the fourth VM instructions, the instructions for creating the third VM and the fourth VM indicate that the third VM and the fourth VM have a strong anti-affinity, and the VIM is used to create the third VM according to the The instructions of the VM and the fourth VM respectively create the third VM and the fourth VM in different hosts;

The processing unit is further configured to issue an instruction to create a second Pod to the scheduler through the transceiver unit, and the scheduler is configured to determine the second Pod after receiving the instruction to create the second Pod. When it has a strong anti-affinity with the third Pod in the third VM, the second Pod is created in the fourth VM.

In an optional design, the embodiment of the present application discloses that after setting a corresponding VM label for the VM, when a VM of the first type needs to be created, the processing unit is further configured to, according to the preset The number of VMs of the first type is limited on the same HOST, and an instruction to create the VM of the first type is generated;

In the third aspect, an embodiment of the present application discloses a scheduling management device of a network function virtualization NFV architecture, including:

Processor and memory;

Wherein, the memory is used to store program instructions;

The processor is configured to call and execute program instructions stored in the memory, so that the scheduling management device executes the first aspect or any one of the possible design methods of the first aspect.

In a fourth aspect, the embodiments of the present application disclose a computer-readable medium, including instructions, which when run on a computer, cause the computer to execute the first aspect or any one of the possible design methods of the first aspect.

In the scheduling management method disclosed in the embodiments of the present application, the scheduling management device first sets corresponding VM tags for the VMs according to the HOST to which each VM belongs. The VM tags can be used to divide the VMs. In this case, they are located in the same location. The VMs in a HOST are of the same type; then, after determining that the first VM migrates from the first HOST to the second HOST, the scheduling management device updates the VM label of the first VM to the second HOST, and then triggers NFV The scheduler in the architecture determines whether the first Pod in the first VM meets the deployment requirements. If it does not meet the deployment requirements, the scheduler will schedule the first Pod to the second VM of the first HOST. After a VM is migrated, the first Pod is still deployed in the first HOST to meet the deployment requirements of the first Pod.

In the prior art, only a certain type of Pod can be deployed in a specific type of VM, which cannot meet the scheduling requirements of the Pod on the HOST. With the solution disclosed in the embodiments of the present application, a certain type of Pod can be deployed in a specific HOST, so as to meet the scheduling requirements of the Pod on the HOST and solve the problems of the prior art.

Description of the drawings

In order to explain the technical solution of the present application more clearly, the following will briefly introduce the drawings needed in the embodiments. Obviously, for those of ordinary skill in the art, without paying creative labor, Other drawings can be obtained from these drawings.

FIG. 1 is a schematic diagram of an NFV architecture applied in an embodiment of this application;

2 is a schematic diagram of a work flow of a scheduling management method of an NFV architecture disclosed in an embodiment of the application;

FIG. 3 is a schematic diagram of Pod deployment in an NFV architecture scheduling management method disclosed in an embodiment of the application;

FIG. 4 is a schematic diagram of information exchange among various network elements in the NFV architecture in the scheduling management method of the NFV architecture disclosed in an embodiment of the application;

FIG. 5 is another schematic diagram of information interaction of each network element in the NFV architecture in the scheduling management method of the NFV architecture disclosed in the embodiment of the application;

6 is a schematic diagram of the workflow of another NFV architecture scheduling management method disclosed in an embodiment of the application;

FIG. 7 is another schematic diagram of information interaction of each network element in the NFV architecture in the scheduling management method of the NFV architecture disclosed in an embodiment of the application;

FIG. 8 is a schematic structural diagram of an NFV architecture scheduling management device disclosed in an embodiment of the application;

FIG. 9 is a schematic structural diagram of a scheduling management device of an NFV architecture disclosed in an embodiment of the application.

detailed description

In order to solve the problem that the prior art cannot meet the scheduling requirements of Pod on HOST, the embodiments of this application disclose a scheduling management method and device of a network function virtualization NFV architecture. Among them, the solution disclosed in the embodiment of this application can be applied to FIG. In the NFV architecture shown in 1.

In order to clarify the solutions disclosed in the embodiments of the present application, the solutions of the present application are disclosed through respective embodiments below.

The first embodiment of the present application discloses a scheduling management method of a network function virtualization NFV architecture. Referring to the working flow diagram shown in FIG. 2, the scheduling management method of the network function virtualization NFV architecture includes the following steps:

Step S11: The scheduling management device in the NFV architecture obtains the host HOST to which each virtual machine VM belongs, and sets a corresponding VM label for the VM, and the VM label includes the information of the host to which the VM belongs.

Among them, HOST is the parent node of the VM, that is, the VM is set in the HOST, and one or more VMs can be set in a HOST.

In the NFV architecture, VMs can be created by VIM. In this case, when a VM needs to be created, the scheduling management device in the NFV architecture sends a VM creation instruction to the VIM. After receiving the VM creation instruction, the VIM creates the VM in the HOST.

In addition, after the creation of the VM is completed, the VIM can feed back to the scheduling management device the HOST to which the VM belongs, so that the scheduling management device can obtain the HOST to which each VM belongs, and accordingly set a corresponding VM label for the VM. Wherein, the HOST information included in the VM tag is information that can determine the identity of the HOST and is unique in the NFV architecture. For example, the HOST information may be the network element number, address information, or identity identification of the HOST in the NFV architecture.

Step S12: After determining that the first VM is migrated from the first HOST to the second HOST, the scheduling management device updates the VM label of the first VM according to the HOST to which the first VM belongs after the migration. In this case, the HOST information included in the updated VM tag is the information of the second HOST.

After the VM is created, migration may also occur. For example, when the VM in the first HOST fails, the VM may be migrated to the second HOST.

In addition, after the VM is migrated to the new HOST, the VIM can also feed back the new HOST migrated by the VM to the scheduling management device, so that the scheduling management device can determine whether each VM is migrated and the host to which the VM belongs before and after the migration.

Step S13: The scheduling management device triggers a scheduler in the NFV architecture, and the scheduler is used to determine the first minimum deployment unit Pod in the first VM according to the updated VM label of the first VM When the deployment requirements are not met, the first Pod is scheduled to the second VM of the first HOST.

The scheduler may be set in PaaS in the NFV architecture. For example, the scheduler may be Google's open source container orchestration engine Kubernetes set in PaaS.

The scheduling management device triggers the scheduler after updating the VM label of the first VM. After the scheduler is triggered, according to the updated VM tag of the first VM, it is determined whether the first minimum deployment unit Pod in the first VM meets the deployment requirement. Wherein, when the scheduler determines whether the first Pod meets the deployment requirements, it is based on the affinity/anti-affinity requirements of the first Pod. If the affinity/anti-affinity requirement of the first Pod indicates that the first Pod needs to be set in the VM of the first HOST, then according to the updated VM label of the first VM, the scheduler will determine that the first Pod is deployed in In the second HOST, it is further determined that the first Pod does not meet the deployment requirements, so that the first Pod is scheduled to the second VM of the first HOST. Since the second VM is set in the first HOST, the VM label of the second VM is the first HOST. After the first Pod is scheduled to the second VM, the affinity/anti-affinity of the first Pod can be satisfied Therefore, the first Pod is deployed on the first HOST to meet the deployment requirements of the first Pod.

In order to clarify the scheduling requirements met by the embodiments of the present application, refer to the schematic diagram of Pod deployment shown in FIG. 3. In Figure 3, a first HOST and a second HOST are set. Before migration, the first VM and the second VM are both set in the first HOST, and the VM labels of the first VM and the second VM both include the first VM. A HOST information, and if the first Pod is set in the first VM and the third VM is set in the second HOST, the VM tag of the third VM includes the information of the second HOST. After the first VM is migrated to the second HOST, the VM label of the first VM is updated to include the information of the second HOST. In this case, the scheduler will schedule the first Pod so that the first Pod is scheduled to the first HOST In the second VM, the first Pod is still deployed in the first HOST.

In addition, in the embodiment of the present application, VMs are divided by VM tags, and the scheduler determines whether the first Pod in the first VM meets the deployment requirements according to the VM tags of the VMs and schedules the first Pod so that the first Pod Deploy in a specific type of VM. This operation can be achieved in the following ways:

In the first way, the node selection attribute (ie, nodeSelector attribute) of the Pod is set in the configuration file of the Pod, and the node selection attribute is used to indicate which tags the Pod can be deployed in the VMs with which tags. When the Pod is deployed in the VM corresponding to the label indicated by the node selection attribute, the scheduler determines that the Pod meets the deployment requirements. When the Pod is not deployed in the VM corresponding to the label indicated by the node selection attribute, the scheduler determines the The Pod does not meet the deployment requirements, and the Pod is scheduled, so that the Pod can be deployed in the specific type of VM indicated by the node selection attribute, even if the first Pod is deployed in the specific type of VM.

For example, in the configuration file of the first Pod, the node selection attribute of the first Pod is set to a VM with the first VM label, and the first VM label is a label including the information of the first HOST, then the first Pod is deployed in When in the VM of the first host, the first Pod meets the deployment requirements. In this case, the scheduler obtains the node selection attributes of the first Pod by querying the configuration file of the first Pod. When the first Pod is deployed in the first VM and the first VM is not migrated, the first Pod corresponds to The VM label indicates that the first Pod is deployed in the VM of the first HOST, and the first Pod meets the deployment requirements. When the first Pod is migrated to the second HOST along with the migration of the first VM, the scheduler can determine that the first Pod is deployed in the VM of the second HOST according to the updated VM label of the first VM, that is, the first Pod no longer meets the deployment requirements. In this case, the scheduler schedules the first Pod to the second VM of the first HOST so that the first Pod meets the deployment requirements. In this way, the first Pod can always be deployed in the VM of the first HOST.

The second method is based on the Pod's node affinity (nodeAffinity) scheduling strategy. In the nodeAffinity scheduling strategy, multiple types of scheduling information can be set in the Pod configuration file to achieve Pod scheduling. One type of scheduling information indicates that during the first scheduling, the VM must meet certain conditions before the Pod can be deployed in the VM; the other type of scheduling information indicates the attribute information of the VM where the Pod is located during the operation of the Pod (The attribute information can be the label of the VM) changes, the Pod will be scheduled from the VM to other VMs; another type of information indicates that during the operation of the Pod, if the attribute information of the VM where the Pod is located (the attribute information It can be the label of the VM, and the Pod can continue to run in the VM; another type of information indicates that during the operation of the Pod, if the attribute information of the VM where the Pod is located (the attribute information can be the label of the VM) occurs Change, Pod is not necessarily scheduled from this VM to other VMs.

When the scheduler implements the scheduling of the first Pod through the nodeAffinity scheduling strategy, the corresponding information can be set in the configuration file of the first Pod. This information indicates that when the VM label of the VM where the first Pod is located changes, the first Pod will start from this The VM is scheduled to other VMs. In this case, when the first Pod is migrated to the second HOST along with the migration of the first VM, the scheduler uses the nodeAffinity scheduling strategy to determine that the first Pod does not meet the deployment requirements, thereby scheduling the first Pod to the second host. In the second VM of a HOST, so that the first Pod meets the deployment requirements. In this way, the first Pod can always be deployed in the VM of the first HOST.

Further, in the embodiment of the present application, the scheduling management device obtains the host HOST to which each VM belongs through the VM creation success information fed back by the virtualization infrastructure manager VIM in the NFV architecture.

Among them, VIM is used to create a VM in HOST after receiving a VM creation instruction. After completing the creation of the VM, VIM feeds back the VM creation success information to the scheduling management device. The VM creation success information contains information about the host to which each VM belongs. The relevant information can determine the identity of the host and is unique in the NFV architecture For example, the related information can be the address information or identity of the HOST, so that the scheduling management device can determine the host to which each VM belongs, and set the corresponding VM label for the VM according to the host to which each VM belongs. The label includes the information of the host to which the VM belongs.

And/or, in the embodiment of the present application, the scheduling management device determines that the first VM is migrated from the first HOST to the second HOST through the VM migration completion information fed back by the VIM.

Among them, after the VM in the NFV architecture has completed the migration, the VIM will feed back the migration completion information to the scheduling management device. The migration completion information includes the relevant information of the migrated VM and the relevant information of the host to which the migration belongs, and the relevant information of the VM. In order to be able to determine the identity of the VM and have unique information in the NFV architecture, for example, the relevant information can be the address information or identity identification of the VM, etc. The relevant information of the HOST can determine the identity of the HOST and is unique in the NFV architecture Sexual information, for example, the related information can be the address information or identity of the HOST. After receiving the migration completion information, the scheduling management device can determine the VM where the migration occurs and the HOST to which the VM belongs after the migration.

In this case, after the first VM is migrated from the first HOST to the second HOST, the migration completion information fed back by the VIM includes the related information of the first VM and the related information of the second HOST, so that the scheduling management device can determine the second host. A VM is migrated from the first HOST to the second HOST.

Further, in the NFV architecture, multiple network elements are often included, and accordingly, the scheduling management equipment may be different types of network elements. In one of the feasible implementation manners, the scheduling management device is a virtualized network function manager VNFM, or, in another feasible implementation manner, the scheduling management device is a built-in scheduler Platform as a service module PaaS.

Wherein, when the scheduling management device is a VNFM, the scheduling management device triggering the scheduler in the NFV architecture includes:

The VNFM transmits the VM label change information of the first VM to the PaaS in the NFV architecture, and triggers the scheduler built in the PaaS through the VM label change information of the first VM.

When the scheduling management device is a VNFM, the VNFM transmits the VM label change information of the first VM to the PaaS after updating the VM label of the first VM, and the VM label change information of the first VM includes the first VM change After the VM label. After PaaS receives the change information of the VM label of the first VM, it determines whether the VM label of the first VM has changed, and when it is determined that the change occurs, it drives its built-in scheduler, which is based on the first VM. The updated VM label determines whether the first Pod meets the deployment requirements, and when it is determined that it does not meet the deployment requirements, the first Pod is scheduled to the second VM of the first HOST.

In addition, when the scheduling management device is PaaS, the scheduling management device triggering the scheduler in the NFV architecture includes:

When the scheduling management device is PaaS, PaaS determines whether the VM label of the first VM has changed. When it is determined that the VM label of the first VM has changed, PaaS will trigger its built-in scheduler, which is based on the first VM. The updated VM label determines whether the first Pod meets the deployment requirements, and when it is determined that it does not meet the deployment requirements, the first Pod is scheduled to the second VM of the first HOST.

Further, in the method disclosed in the embodiment of the present application, when the scheduling management device is a VNFM, after the scheduling management device sets a corresponding VM label for the VM, the method further includes:

In this case, PaaS can obtain the corresponding relationship between the VM and the VM label, so that the VM label of each VM can be determined according to the comparison relationship, and after receiving the VM label change information of the first VM transmitted by the VNFM, according to the first VM label change information The VM label change information of a VM is used to determine whether the VM label of the first VM has changed.

For example, when the scheduling management device is a VNFM, after the VNFM determines that the HOST to which the first VM belongs is the first HOST, the VM label set for the first VM includes the information of the first HOST, and the first VM corresponds to its VM label The relationship is transferred to PaaS. After the first VM is migrated from the first HOST to the second HOST, the VNFM transmits the VM label change information of the first VM to the PaaS. The VM label change information of the first VM includes the HOST to which the first VM belongs after the migration (ie The second HOST) information. After receiving the VM label change information of the first VM, the PaaS determines that the current VM label of the first VM includes the information of the second HOST, so as to determine that the VM label of the first VM has changed.

Further, in the embodiment of the present application, before the scheduling management device sets a corresponding VM label for the VM, the following operations are further included:

When a VM needs to be created, the scheduling management device in the NFV architecture will issue an instruction to create a VM to the VIM in the NFV architecture, so that the VIM will create the corresponding VM according to the instruction, and after the VM is successfully created, the VIM will The scheduling management device feeds back a corresponding VM creation success message.

The instruction for creating the VM may include information about the host to which the VM to be created belongs. For example, when the first VM needs to be created in the first HOST, the instruction for creating the first VM may include information about the first HOST. In this case, after the VIM receives the instruction to create the first VM, it can determine that the first VM needs to be created in the first HOST.

In addition, the instructions for creating a VM may also include related parameters of the VM to be created, and the related parameters may include the VM's requirements for central processing unit (CPU) resources and/or memory resources Needs, and/or affinity and anti-affinity needs, etc. In this case, VIM will search for a suitable HOST based on the relevant parameters of the VM to be created included in the VM creation instruction, and create the VM at the appropriate HOST.

Wherein, the scheduling management device may be a VNFM or PaaS. When the scheduling management device is a VNFM, the VNFM issues an instruction to create a VM, and the VIM feedbacks a VM creation success message to the VNFM; when the scheduling management device is a PaaS, the PaaS issues an instruction to create a VM, and the VIM issues a VM creation instruction to the PaaS Feedback the VM creation success message.

In addition, in addition to the scheduling management device, other network elements in the NFV architecture can also generate and issue VM creation instructions. For example, when the scheduling management device is a PaaS, the VNFM can generate and issue VM creation instructions.

Further, in this embodiment of the present application, after the scheduling management device sets a corresponding VM label for the VM, the method further includes:

After receiving the instruction to create the first Pod, the VM will determine whether the HOST information included in its VM tag is the same as the HOST information included in the instruction to create the first Pod. If it is the same, the VM will Create the first Pod deployed with itself.

In the embodiment of the present application, when the first Pod needs to be deployed in the first HOST, the information of the first HOST can be set in the instruction for creating the first Pod. In this case, after the first VM in the first HOST receives the instruction to create the first Pod, it determines that the HOST information included in its VM tag is the same as the HOST information included in the instruction to create the first Pod. Then create the first Pod deployed on itself.

Among them, when the scheduling management device is a VNFM, the VNFM usually issues the instruction to create a Pod to the PaaS. After receiving the instruction, the PaaS can determine the corresponding VM based on the HOST information in the instruction to create the Pod, and then Create a Pod in the VM. For example, if the instruction for creating a Pod includes the information of the first HOST, PaaS will create the Pod in the VM in the first HOST.

The foregoing embodiments of the present application describe the operations that the scheduling management device needs to perform in the scheduling management method of the present application. In order to clarify the interaction process of each network element in the NFV architecture, FIG. 4 is disclosed in the embodiment of the present application.

In the application scenario shown in Figure 4, the scheduling management device is a VNFM. Referring to the information interaction diagram shown in Figure 4, the interaction process of each network element in the NFV architecture includes the following steps:

Step S21: The VNFM issues an instruction to create the first VM and the second VM to the VIM, so that the VIM creates the corresponding first VM and the second VM according to the instructions.

The instruction for creating the VM may include the information of the host to which the VM to be created belongs. For example, when the first VM needs to be created in the first HOST, the instruction for creating the first VM may include the information of the first HOST. In this case, after receiving the instruction to create the first VM, the VIM can determine that the first VM needs to be created in the first HOST.

In the embodiment of the present application, if it is necessary to create the first VM and the second VM in the first HOST, the instructions for the first VM and the second VM creation may include the HOST to which the first VM and the second VM belong (ie The first HOST) related information, so that VIM creates the first VM and the second VM in the first HOST.

Alternatively, the instructions for creating the first VM and the second VM include related parameters of the first VM and the second VM, respectively, when the VIM determines that the first HOST satisfies the first VM and the second VM according to the related parameters of the first VM and the second VM. When the second VM is created, the first VM and the second VM will be created in the first HOST.

Step S22: After receiving the instruction to create the first VM, the VIM determines the first HOST used to create the first VM, and creates the first VM in the first HOST.

Step S23: After receiving the instruction to create the second VM, the VIM determines that the first HOST of the second VM can be created, and creates the second VM in the first HOST.

Among them, in the actual execution process, the order of execution of step S22 and step S23 is not strictly regulated. For example, the operation of step S23 may be performed first, and then the operation of step S22 may be performed.

Step S24: After the first VM and the second VM are successfully created, the VIM sends a VM creation success message to the VNFM. The VM creation success message includes information about the host to which the first VM and the second VM belong respectively.

Step S25: The VNFM sets corresponding VM labels for the first VM and the second VM according to the relevant information of the HOST to which the first VM and the second VM belong respectively, that is, the VM label set for the first VM includes the information of the first HOST, The VM tag set for the second VM includes the information of the first HOST.

Step S26: The VNFM transmits a VM management request to the PaaS, so that the PaaS can manage the first VM and the second VM. The VM management request may include the correspondence between the first VM and the second VM and its own VM tags. relationship. Alternatively, a separate notification message may also be generated, in which the notification message includes the corresponding relationship between the first VM and the second VM and its own VM tags, and the notification message is transmitted to the PaaS.

Through this step, the PaaS can manage the first VM and the second VM, and obtain the corresponding relationship between the first VM and the second VM and the VM tags.

Step S27: After receiving the VM management request transmitted by the VNFM, the PaaS performs a management operation on the first VM and the second VM.

Among them, during the hosting operation, the PaaS can deploy corresponding processes/components on the first VM and the second VM respectively, thereby hosting the first VM and the second VM. In addition, after the PaaS receives the corresponding relationship between the first VM and the second VM and its own VM label, it will also save the corresponding relationship.

The above steps S21 to S27 are the preparation phases of the VM. Through this phase, the first VM and the second VM can be created, and the VNFM sets the corresponding VM tags for the first VM and the second VM, and the PaaS manages the first VM. VM and the second VM, and enable PaaS to obtain the corresponding relationship between the first VM and the second VM and its own VM label.

Step S28: The VNFM issues an instruction for creating a first Pod to the PaaS. The instruction for creating a first Pod includes information about the HOST corresponding to the first Pod.

Wherein, when the first Pod needs to be created in the first HOST, the VNFM issues an instruction for creating the first Pod to the PaaS, and the instruction for creating the first Pod includes the information of the first HOST.

Step S29. After Paas receives the instruction to create the first Pod, it determines the corresponding HOST according to the HOST information in the instruction, selects the appropriate VM in the HOST, and then issues the instruction to create the first Pod to the VM .

Wherein, when the HOST information in the instruction for creating Pod is the first HOST, the first Pod can be created in the first VM of the first HOST, and Paas will issue the instruction for creating the first Pod to the first VM .

Step S30: After receiving the instruction to create the first Pod, the first VM creates the first Pod according to the instruction, and starts to run the first Pod.

The above steps S28 to S30 are the Pod creation and startup phase, through which the first Pod can be created in the first VM.

Step S31: After the VIM detects that the first VM meets the migration condition, the first VM is migrated.

Wherein, when the VIM detects that the first VM has a failure that needs to be migrated, it is generally considered that the first VM meets the migration condition. Or, when the VIM detects that the HOST where the first VM is located (ie, the first HOST) cannot meet the operating requirements of the first VM (for example, the first HOST fails, etc.), it will also consider that the first VM meets the migration condition.

Step S32: After sensing that the first VM completes the migration operation, the VIM feeds back migration completion information to the VNFM.

The migration completion information includes related information about the VM that is migrated (i.e., the first VM) and related information about the HOST (i.e., the second HOST) to which it belongs after the migration. The related information of the VM can determine the identity of the VM and is in the NFV architecture Unique information, for example, the relevant information may be the address information or identity of the VM, etc. The relevant information of the HOST is information that can determine the identity of the HOST and is unique in the NFV architecture. For example, the relevant information may be HOST's address information or identification, etc. After receiving the migration completion information, the VNFM can determine the VM where the migration occurs and the HOST to which the VM belongs after the migration.

Step S33: The VNFM updates the VM label of the first VM, and the updated VM label includes the information of the second HOST.

Step S34: The VNFM transmits the VM label change information of the first VM to the PaaS, and the VM label change information of the first VM includes the updated VM label of the first VM.

Step S35: After the PaaS receives the VM label change information of the first VM, it determines that the VM label of the first VM has changed, thereby triggering its built-in scheduler. The caller determines whether the first Pod meets the deployment requirements based on the updated VM label of the first VM. When it is determined that the first Pod does not meet the deployment requirements, the scheduler will schedule the first Pod to the second of the first HOST. VM.

Step S36: After the first Pod is scheduled into the second VM, the second VM starts the first Pod according to the related information of the first Pod issued by the PaaS, so that the first Pod runs normally.

The above steps S31 to S36 are the Pod scheduling stage. In this stage, when the VM where the Pod is located is migrated, it can still be scheduled to the corresponding VM to meet the Pod's scheduling requirements at the HOST level.

The foregoing Fig. 4 and steps S21 to S37 disclose the interaction process of each network element in the NFV architecture when the scheduling management device is a VNFM. In addition, the scheduling management device can also be a PaaS in the NFV architecture. When the scheduling management device is PaaS, referring to the information interaction diagram shown in Figure 5, the interaction process of each network element in the NFV architecture includes the following steps:

Step S41: The PaaS issues an instruction to create the first VM and the second VM to the VIM, so that the VIM creates the corresponding first VM and the second VM according to the instructions.

In addition, the VM creation instruction may also include related parameters of the VM to be created, and the related parameters may include the VM's demand for CPU resources, and/or demand for memory resources, and/or affinity And anti-affinity needs. In this case, VIM will search for a suitable HOST based on the relevant parameters of the VM to be created included in the VM creation instruction, and create the VM at the appropriate HOST.

In the embodiment of the present application, if the first VM and the second VM need to be created in the first HOST, the instructions for creating the first VM and the second VM may include the HOST to which the first VM and the second VM belong (ie The first HOST) related information, so that VIM creates the first VM and the second VM in the first HOST.

Step S42: After receiving the instruction to create the first VM, the VIM determines the first HOST used to create the first VM, and creates the first VM in the first HOST.

Step S43: After receiving the instruction to create the second VM, the VIM determines that the first HOST of the second VM can be created, and creates the second VM in the first HOST.

Among them, in the actual execution process, the sequence of step S42 and step S43 is not strictly regulated. For example, the operation of step S43 may be performed first, and then the operation of step S42 may be performed.

Step S44: After the first VM and the second VM are successfully created, the VIM sends VM creation success information to the PaaS. The VM creation success information includes information about the host to which the first VM and the second VM belong.

Step S45: PaaS sets corresponding VM labels for the first VM and the second VM according to the relevant information of the HOST to which the first VM and the second VM belong respectively, that is, the VM label set for the first VM includes the information of the first HOST, The VM tag set for the second VM includes the information of the first HOST.

Step S46: PaaS performs a management operation on the first VM and the second VM.

Among them, during the hosting operation, the PaaS can deploy corresponding processes/components on the first VM and the second VM respectively, thereby hosting the first VM and the second VM.

Among them, in the actual execution process, the sequence of step S45 and step S46 is not strictly regulated. For example, the operation of step S46 may be performed first, and then the operation of step S45 may be performed.

The above steps S41 to S46 are the preparation phase of the VM. Through this phase, the first VM and the second VM can be created, and the PaaS can set the corresponding VM tags for the first VM and the second VM, and make the PaaS obtain the first VM and The corresponding relationship between the second VM and its own VM label, and the PaaS manages the first VM and the second VM.

Step S47: Paas issues an instruction to create a Pod to the VM.

Among them, Paas can determine the HOST corresponding to the Pod to be created, and determine the VM deployed in the HOST according to the VM label of each VM, select the appropriate VM from the VMs deployed in the HOST, and then issue the creation of the Pod to the VM Instructions.

Among them, when a Pod needs to be created in the first HOST, the HOST corresponding to the Pod to be created is the first HOST. In this case, the first Pod can be created in the first VM of the first HOST, and PaaS will The first VM issues an instruction to create the first Pod.

Step S48: After receiving the instruction to create the first Pod, the first VM creates the first Pod according to the instruction, and starts to run the first Pod.

The above steps S47 to S48 are the Pod creation and startup phase, through which the first Pod can be created in the first VM.

Step S49: After the VIM detects that the first VM meets the migration condition, the first VM is migrated.

Step S50: After sensing that the first VM completes the migration operation, the VIM feeds back migration completion information to the PaaS.

The migration completion information includes related information about the VM that is migrated (i.e., the first VM) and related information about the HOST (i.e., the second HOST) to which it belongs after the migration. The related information of the VM can determine the identity of the VM and is in the NFV architecture Unique information, for example, the relevant information may be the address information or identity of the VM, etc. The relevant information of the HOST is information that can determine the identity of the HOST and is unique in the NFV architecture. For example, the relevant information may be HOST's address information or identification, etc. After the PaaS receives the migration completion information, it can determine the VM where the migration occurred and the host to which the VM belongs after the migration.

Step S51: PaaS updates the VM label of the first VM, and the updated VM label includes the information of the second HOST.

Step S52: After updating the VM label of the first VM, PaaS triggers its built-in scheduler. The caller determines whether the first Pod meets the deployment requirements based on the updated VM label of the first VM. When it is determined that the first Pod does not meet the deployment requirements, the scheduler will schedule the first Pod to the second of the first HOST. VM.

Step S53: After the first Pod is scheduled into the second VM, the second VM starts the first Pod according to the related information of the first Pod issued by the PaaS, so that the first Pod runs normally.

The above steps S49 to S53 are the Pod scheduling stage. In this stage, when the VM where the Pod is located is migrated, it can still be scheduled to the corresponding VM to meet the Pod's scheduling requirements at the HOST level.

The foregoing Fig. 5 and steps S41 to S53 disclose the interaction process of each network element in the NFV architecture when the scheduling management device is a PaaS. In this embodiment, the PaaS executes multiple operations such as generating instructions for creating a VM, setting a label of the VM, and updating a label of the VM. During this interaction, no VNFM is required.

In addition, if both VNFM and PaaS are set in the NFV architecture, and PaaS is used as the scheduling management device, the VNFM can also generate instructions for creating VMs. In this case, the interaction process of each network element in the NFV architecture may include the following steps:

The VNFM generates instructions for creating the first VM and the second VM, and issues the instructions for creating the first VM and the second VM to the VIM to instruct the creation of the first VM and the second VM;

After receiving the instructions for creating the first VM and the second VM, the VIM creates the corresponding first VM and the second VM according to the instructions, and after completing the creation, it returns a VM creation success message to the VNFM;

After receiving the VM creation success message, the VNFM transmits a VM management request to PaaS, which is used to instruct PaaS to take care of the first VM and the second VM, or VNFM not only transmits the VM management request to PaaS, but also to PaaS Transmission of VM creation notification messages, used to notify PaaS that the first VM and the second VM are currently created;

After PaaS receives the VM hosting request, it manages the first VM and the second VM, and based on the VM hosting request or VM creation notification message, PaaS can determine that the first VM and the second VM are currently created, and Set corresponding VM labels for the first VM and the second VM;

When the first Pod needs to be created, the VNFM or PaaS generates an instruction to create the first Pod, and transmits the instruction to the first VM;

After receiving the instruction to create the first Pod, the first VM creates the first Pod, and starts to run the first Pod;

After VIM detects that the first VM meets the migration condition, it migrates the first VM;

After the VIM senses that the first VM has completed the migration operation, it can transmit the migration completion information to the PaaS, or the VIM can transmit the migration completion information to the VNFM, and the VNFM forwards the migration completion information to the PaaS, so that the PaaS can determine that the first VM has migrated ；

After the PaaS determines that the first VM is migrated, it updates the VM label of the first VM. The updated VM label includes the information of the second HOST, where the second HOST is the HOST where the first VM is located after the migration.

After updating the VM label of the first VM, PaaS triggers its built-in scheduler. The caller determines whether the first Pod meets the deployment requirements based on the updated VM label of the first VM. When it is determined that the first Pod does not meet the deployment requirements, the scheduler will schedule the first Pod to the second of the first HOST. VM.

After the first Pod is scheduled into the second VM, the second VM starts the first Pod according to the related information of the first Pod issued by the PaaS to make the first Pod run normally.

In the above steps, the interaction process of each network element in the NFV architecture is disclosed when the VNFM and PaaS are set in the NFV architecture at the same time, and the PaaS is used as the scheduling management device. During this interaction, PaaS performs operations such as setting VM tags, updating VM tags, and triggering the scheduler, and NFVM performs operations such as creating VM instructions.

Further, this application also discloses another embodiment. See FIG. 6. In this embodiment, after the scheduling management device sets a corresponding VM label for the VM, the following steps are further included:

Step S61: The scheduling management device issues an instruction to create a third VM and a fourth VM to the VIM.

The instructions for creating the third VM and the fourth VM indicate that the third VM and the fourth VM have a strong anti-affinity, and the VIM is used to create the third VM and the fourth VM according to the instructions for creating the fourth VM , Create the third VM and the fourth VM in different HOSTs.

In the embodiment of the present application, the scheduling management device issues an instruction to create the third VM and the fourth VM to the VIM in the NFV architecture, so that the VIM can create the third VM and the fourth VM after receiving the instruction.

Among them, anti-affinity includes strong anti-affinity and weak anti-affinity. When two network elements with strong anti-affinity are deployed, they cannot be deployed in the same parent node. When deploying two network elements with weak anti-affinity, try to deploy them in different parent nodes. Under the current NFV architecture, deploy the two network elements with weak anti-affinity on different parent nodes. Nodes are more difficult, and these two network elements can be deployed in the same parent node.

Since in the embodiment of the present application, the instructions for creating the third VM and the fourth VM indicate that the third VM and the fourth VM have a strong anti-affinity, the VIM receives the creation of the third VM. The instructions of the VM and the fourth VM will create the third VM and the fourth VM in different HOSTs to ensure the strong anti-affinity deployment of the third VM and the fourth VM.

Step S62: The scheduling management device issues an instruction to create a second Pod to the scheduler, and the scheduler is configured to, after receiving the instruction to create a second Pod, determine that the second Pod and the third Pod When the third Pod in the VM has strong anti-affinity, the second Pod is created in the fourth VM.

Since in the embodiment of this application, the second Pod and the third Pod have strong anti-affinity, the second Pod and the third Pod need to be deployed in different VMs. In this case, when the third VM is deployed When there is a third Pod, the second Pod is deployed in the fourth VM to ensure strong anti-affinity between the second Pod and the third Pod.

Through the solutions disclosed in step S61 to step S62, when the two Pods have anti-affinity, the two Pods can not be deployed in the same VM, and the anti-affinity deployment of Pods can be guaranteed from the VM level and the Pod level.

In addition, in the embodiments of the present application, the scheduling management device is a virtualized network function manager VNFM, where a virtualized network function descriptor (VNFD) module is set in the VNFM, and the virtualized network function descriptor (VNFD) module is set in the VNFD template. , Can set strong anti-affinity between different VMs.

For example, in the VNFD module, you can set the maximum number of VMs created in a certain HOST. When the number of VMs created in the HOST reaches the maximum value, no new VMs will be created in the HOST, but new ones The VM is created in other HOSTs, so as to ensure the strong anti-affinity between the VM of the HOST and the newly created VM. In the embodiment of this application, the HOST where the third VM is deployed is used as the third HOST. In the VNFD template, the maximum number of VMs created in the third HOST can be set to 1. In this case, Only the third VM is created in the third host, and the fourth VM is created in other hosts, so as to ensure the strong anti-affinity between the third VM and the fourth VM.

In addition, the scheduler can determine whether there is affinity and anti-affinity between two Pods according to the Pod affinity (ie PodAffinity) scheduling strategy and Pod anti-affinity (ie PodantiAffinity) scheduling strategy. Among them, the PodAffinity scheduling policy is used to specify a Pod and which Pods can be deployed in the same VM, and the PodantiAffinity scheduling policy is used to specify a Pod and which Pods cannot be deployed in the same VM.

In this case, multiple types of deployment information are set in the configuration file of the Pod, so that the scheduler can determine the affinity and anti-affinity between different Pods according to the configuration file. For example, in a certain type of deployment information, the Pod requires the VM to meet certain rules during the first deployment process. If not, the Pod cannot be deployed to the VM. This type of deployment information is used to satisfy Pod’s strong anti-affinity requirements; in another type of deployment information, the VM is required to meet certain rules as much as possible during the first deployment of the Pod. If it is not met, the Pod may also be scheduled to the VM. One type of deployment information is used to meet the Pod’s weak anti-affinity requirements; in the other type of deployment information, the Pod is required to meet certain rules during the first deployment period and during the first scheduling period. If the VM cannot meet the rules, Then the Pod cannot be scheduled to the VM. If the VM meets the rule, the Pod is scheduled to the VM, and in the subsequent operation process, the VM no longer meets the rule, the Pod needs to be rescheduled to make the Pod Deploy to the VM that meets the rule.

In the embodiment of the present application, in order to satisfy the strong anti-affinity between the second Pod and the third Pod, the corresponding deployment information can be set in the configuration file of the second Pod. The deployment information indicates that when the VM does not deploy the third Pod In the case of, it is determined that the VM meets the rules for deploying the second Pod. In this case, when the scheduler obtains the deployment information by querying the configuration file of the second Pod, and determines that the third Pod is deployed in the third VM, the second Pod will not be deployed in the third VM, but The second Pod is scheduled to the fourth VM where the third Pod is not deployed.

Further, in order to clarify the information exchange process of each network element in the NFV architecture in the above embodiment, Fig. 7 is disclosed. Referring to the schematic diagram of information exchange shown in Fig. 7, the information exchange process includes the following steps:

Step S71: The VNFM issues an instruction to create a third VM and a fourth VM to the VIM, and the instruction to create the third VM and the fourth VM indicates that the third VM and the fourth VM have strong anti-affinity .

Step S72: After receiving the instruction to create the third VM and the fourth VM, the VIM creates the third VM in the third HOST.

Step S73: VIM creates a fourth VM, because the instructions for creating the third VM and the fourth VM indicate that the third VM and the fourth VM have strong anti-affinity, and the third VM is created in the first VM. In the third host, VIM will create the fourth VM in the fourth host.

Step S74: VIM feeds back VM creation success information to VNFM.

Step S75: The VNFM transmits a VM management request to the PaaS, so that the PaaS can manage the third VM and the fourth VM.

Step S76: After receiving the VM management request transmitted by the VNFM, the PaaS performs a management operation on the third VM and the fourth VM.

Among them, during the management operation, the PaaS can deploy corresponding processes/components on the third VM and the fourth VM, respectively, so as to manage the third VM and the fourth VM.

Step S77: The VNFM issues an instruction to create a third Pod to the PaaS.

Step S78: After receiving the instruction to create the third Pod, Paas issues an instruction to create the third Pod to the third VM.

Step S79: After receiving the instruction to create the third Pod, the third VM creates the third Pod according to the instruction, and starts to run the third Pod.

Step S80: The VNFM issues an instruction to create a second Pod to the PaaS.

Step S81: After receiving the instruction to create the second Pod, the PaaS determines that the second Pod has strong anti-affinity with the third Pod in the third VM, and then determines that the second Pod needs to be created in the fourth VM, And issue an instruction to create a second Pod to the fourth VM.

Step S82: After receiving the instruction to create the second Pod, the fourth VM creates the second Pod according to the instruction, and starts to run the second Pod.

Furthermore, in some application scenarios, it is necessary to control the number of VMs of a certain type allowed to be deployed in the HOST. In order to meet this requirement, this application discloses another embodiment. In this embodiment, the scheduling management device is a virtualized network function manager VNFM, which includes the following steps:

When a VM of the first type needs to be created, the scheduling management device generates an instruction to create a VM of the first type according to a preset limit on the number of the VMs of the first type in the same HOST.

In this embodiment, the type of the VM is divided by a label set in advance for the VM, and the label may be a VM label that includes the information of the host to which the VM belongs, that is, the VM is classified into different types by the host to which the VM belongs. Or, when there are other classification requirements, the label set for the VM in advance may also be a label including other information, so as to realize the classification of the VM type.

In the above steps, VMs are divided by their own labels, where VMs with the same label are of the same type, and when the number of VMs of the first type is limited to m (m is a positive integer), the creation of VMs of the first type The instruction is used to indicate that the number of VMs of the first type created in the same HOST cannot exceed m, that is, the number of VMs of the first type created in the same HOST is at most m.

After receiving the instruction to create the first type of VM, the PaaS creates the first type of VM according to the instruction of the instruction to ensure that the number of the first type of VM created in the same HOST is at most m.

Wherein, a VNFD template is set in the VNFM. When the scheduling management device is a VNFM, in a feasible implementation manner, a limit on the number of VMs of the first type in the same HOST can be preset in the VNFD template.

Through this step, the number of VMs of a certain type allowed to be deployed in the HOST can be controlled.

Further, in the embodiment of the present application, the number of Pods of the same type that are allowed to be deployed in the VM can also be controlled. In this case, a limit on the number of Pods of various types in the same VM is set in the VNFM in advance. When a Pod needs to be created, the VNFM generates an instruction to create a Pod, and the instruction includes the limit on the number of the Pod in the same VM.

For example, when a Pod of the first type needs to be created in a certain VM, and the number of Pods of the first type in the VM is limited to n (n is a positive integer), the instruction for creating a Pod of the first type is used In the same VM, the number of created Pods of the first type cannot exceed n, that is, in the same VM, the number of created Pods of the first type is at most n.

After receiving the instruction to create the first type of Pod, the PaaS creates the first type of Pod according to the instruction of the instruction to ensure that the number of the first type of Pod created in the same VM is at most n.

Wherein, a VNFD template is set in the VNFM. When the scheduling management device is a VNFM, in a feasible implementation manner, a limit on the number of VMs of the first type in the same VM can be preset in the VNFD template.

Through this step, the number of a certain type of Pod allowed to be deployed in the VM can be controlled.

Furthermore, the above solution can further control the number of Pods of a certain type allowed to be deployed in the same HOST. For example, when the number of first VMs allowed to be deployed in the HOST is controlled to be at most m and the number of first Pods allowed to be deployed in the first VM is controlled to at most n, the first Pod deployed in the HOST is controlled. The number is not more than (m*n), so as to control the number of Pods of a certain type allowed to be deployed in the HOST.

Corresponding to the aforementioned scheduling management method of the network function virtualization NFV architecture, in another embodiment of the present application, a scheduling device of the network function virtualization NFV architecture is also disclosed. Referring to the schematic structural diagram shown in FIG. 8, the scheduling apparatus of the network function virtualization NFV architecture disclosed in the embodiment of the present application includes:

The transceiver unit 110 is configured to obtain the host HOST to which each virtual machine VM belongs;

The processing unit 120 is configured to set a corresponding VM label for the VM, where the VM label includes information about the HOST to which the VM belongs, and after determining that the first VM migrates from the first HOST to the second HOST, according to the first After a VM is migrated, the VM label of the first VM is updated, and the scheduler in the NFV architecture is triggered. The scheduler is used to determine the VM label after the update of the first VM. When the first minimum deployment unit Pod in the first VM does not meet the deployment requirements, the first Pod is scheduled to the second VM of the first HOST.

Wherein, the scheduler may be set in PaaS in the NFV architecture, for example, the scheduler may be Google's open source container orchestration engine Kubernetes set in PaaS.

In the scheduling management device disclosed in the embodiment of the present application, corresponding VM labels can be set for the VMs according to the HOST to which each VM belongs, and the VMs can be divided through the VM labels of the VMs. In this case, the VMs located in the same HOST VMs are of the same type; then, after determining that the first VM migrates from the first HOST to the second HOST, the VM label of the first VM is updated to the second HOST, and then the scheduler in the NFV architecture is triggered. The scheduler determines whether the first Pod in the first VM meets the deployment requirements. If not, the scheduler will schedule the first Pod to the second VM of the first HOST, so that after the migration of the first VM, The first Pod is deployed in the first HOST to meet the deployment requirements of the first Pod.

Further, in the embodiment of the present application, the processing unit is configured to obtain the host HOST to which each VM belongs through the VM creation success information fed back by the virtualization infrastructure manager VIM in the NFV architecture.

And/or, in the embodiment of the present application, the processing unit is configured to determine the migration of the first VM from the first HOST to the second HOST through the VM migration completion information fed back by the VIM.

Wherein, when the scheduling management device is a VNFM, the processing unit is configured to transmit the VM label change information of the first VM to the PaaS in the NFV architecture, and change the information through the VM label of the first VM Trigger the scheduler built in the PaaS;

Further, when the scheduling management device is a VNFM, after the processing unit sets a corresponding VM label for the VM, the transceiving unit is further configured to transmit the correspondence relationship between the VM and the VM label to the PaaS.

Further, before setting a corresponding VM label for the VM, the processing unit is further configured to issue an instruction to create a first VM and a second VM to the VIM through the transceiver unit, and the VIM is used for receiving After the instruction is reached, create the first VM and the second VM, and after the creation is successful, feedback the creation success message of the first VM and the second VM to the scheduling management device;

Further, after the processing unit sets a corresponding VM label for the VM, the processing unit is further configured to issue instructions to create a third VM and a fourth VM to the VIM through the transceiver unit, and the creation The instructions of the third VM and the fourth VM indicate that there is a strong anti-affinity between the third VM and the fourth VM. The VIM is used to create the third VM and the fourth VM according to the instructions for creating the third VM and the fourth VM. Create the third VM and the fourth VM in the HOST of.

Further, after setting the corresponding VM label for the VM, when the VM of the first type needs to be created, the processing unit is further configured to: according to the preset number of the VMs of the first type on the same HOST Limit, generate instructions to create the first type of VM;

Through this embodiment, the number of VMs of a certain type allowed to be deployed in the HOST can be controlled.

Corresponding to the aforementioned scheduling management method of the network function virtualization NFV architecture, in another embodiment of the present application, a scheduling management device of the network function virtualization NFV architecture is also disclosed. Referring to the schematic structural diagram shown in FIG. 9, the scheduling management device of the network function virtualization NFV architecture includes:

Processor 1101 and memory,

Wherein, the memory is used to store program instructions;

The processor is configured to call and execute program instructions stored in the memory, so that the scheduling management device executes all or part of the steps in the embodiments corresponding to FIGS. 2 to 6.

Further, the device may also include: the network device includes a transceiver 1102 and a bus 1103, and the memory includes a random access memory 1104 and a read-only memory 1105.

Among them, the processor is respectively coupled to the receiver, transmitter, random access memory, and read-only memory through the bus. Wherein, when the network device needs to be operated, the basic input output system solidified in the read-only memory or the bootloader in the embedded system is used to boot the system to guide the device into a normal operating state. After the device enters the normal operating state, the application program and the operating system are run in the random access memory, so that the scheduling management device executes all or part of the steps in the embodiments corresponding to FIGS. 2 to 6.

The network device of the embodiment of the present invention may correspond to the scheduling management device of the NFV architecture in the embodiment corresponding to FIG. 2 to FIG. 6, and the processor, etc. in the scheduling management device may implement the scheduling management device corresponding to FIG. 2 to FIG. For the sake of brevity, the functions and/or various steps and methods implemented by the scheduling management device in the embodiment are not repeated here.

It should be noted that this embodiment may also be based on a network device implemented by a general physical server combined with network function virtualization (English: Network Function Virtualization, NFV) technology. The network device is a virtual network device (eg, virtual host, virtual Router or virtual switch). The virtual network device may be a virtual machine (English: Virtual Machine, VM) running a program for sending notification messages, and the virtual machine is deployed on a hardware device (for example, a physical server). Virtual machine refers to a complete computer system with complete hardware system functions that is simulated by software and runs in a completely isolated environment. Those skilled in the art can virtualize multiple network devices with the above-mentioned functions on a general physical server by reading this application. I won't repeat them here.

In specific implementation, an embodiment of the present application further provides a computer-readable medium, and the computer-readable medium includes instructions. Wherein, when the computer-readable medium is installed in any device and runs on a computer, it can implement all or part of the steps in the embodiments corresponding to FIGS. 2 to 6. The storage medium of the computer readable medium may be a magnetic disk, an optical disc, a read-only memory (English: read-only memory, abbreviated as ROM) or a random access memory (English: random access memory, abbreviated as: RAM), etc. .

Anyone skilled in the art can also understand that the various illustrative logical blocks and steps listed in the embodiments of this application can be implemented by electronic hardware, computer software, or a combination of the two. Whether such a function is realized by hardware or software depends on the specific application and the design requirements of the entire system. Those skilled in the art can use various methods to implement the described functions for each specific application, but such implementation should not be understood as going beyond the protection scope of the embodiments of the present application.

The various illustrative logic units and circuits described in the embodiments of this application can be implemented by general-purpose processors, digital signal processors, application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, Discrete gate or transistor logic, discrete hardware components, or any combination of the above are designed to implement or operate the described functions. The general-purpose processor may be a microprocessor. Optionally, the general-purpose processor may also be any traditional processor, controller, microcontroller, or state machine. The processor can also be implemented by a combination of computing devices, such as a digital signal processor and a microprocessor, multiple microprocessors, one or more microprocessors combined with a digital signal processor core, or any other similar configuration achieve.

The steps of the method or algorithm described in the embodiments of the present application can be directly embedded in hardware, a software unit executed by a processor, or a combination of the two. The software unit can be stored in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or any other storage medium in the art. Exemplarily, the storage medium may be connected to the processor, so that the processor can read information from the storage medium, and can store and write information to the storage medium. Optionally, the storage medium may also be integrated into the processor. The processor and the storage medium may be set in the ASIC, and the ASIC may be set in the UE. Optionally, the processor and the storage medium may also be provided in different components in the UE.

It should be understood that, in various embodiments of the present application, the size of the sequence number of each process does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not correspond to the difference in the embodiments of the present application. The implementation process constitutes any limitation.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented by software, it can be implemented in the form of a computer program product in whole or in part. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website, computer, server, or data center. Transmission to another website, computer, server or data center via wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or data center integrated with one or more available media. The usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid state disk (SSD)).

Each part of this specification is described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments.

Although the preferred embodiments of the present application have been described, those skilled in the art can make additional changes and modifications to these embodiments once they learn the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications falling within the scope of this application.

Those skilled in the art can clearly understand that the technology in the embodiments of the present invention can be implemented by means of software plus a necessary general hardware platform. Based on this understanding, the technical solutions in the embodiments of the present invention can be embodied in the form of software products, which can be stored in a storage medium, such as ROM/RAM. , Magnetic disks, optical disks, etc., including several instructions to make a computer device (which may be a personal computer, a server, or a network device, etc.) execute the methods described in each embodiment or some parts of the embodiment of the present invention.

The same or similar parts in the various embodiments in this specification can be referred to each other. In particular, for the device embodiment of the present application, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can refer to the description in the method embodiment.

The foregoing embodiments of the present invention do not constitute a limitation on the protection scope of the present invention.

Claims

A scheduling management method for network function virtualization NFV architecture, which is characterized in that it includes:

The scheduling management device in the NFV architecture obtains the host HOST to which each virtual machine VM belongs, and sets a corresponding VM label for the VM, where the VM label includes information about the host to which the VM belongs;

After determining that the first VM is migrated from the first HOST to the second HOST, the scheduling management device updates the VM label of the first VM according to the HOST to which the first VM belongs after the migration;

The scheduling management device triggers a scheduler in the NFV architecture, and the scheduler is used to determine that the first minimum deployment unit Pod in the first VM does not conform to deployment according to the updated VM label of the first VM When required, the first Pod is scheduled to the second VM of the first HOST.
The method according to claim 1, wherein:

The scheduling management device obtains the host HOST to which each VM belongs through the VM creation success information fed back by the virtualization infrastructure manager VIM in the NFV architecture;

and / or,

The scheduling management device determines that the first VM is migrated from the first HOST to the second HOST through the VM migration completion information fed back by the VIM.
The method of claim 1 or 2, wherein:

The scheduling management device is a virtualized network function manager VNFM;

Alternatively, the dispatch management device is a platform that is a service module PaaS with the dispatcher built-in.
The method of claim 3, wherein:

When the scheduling management device is a VNFM, the scheduling management device triggering the scheduler in the NFV architecture includes:

The VNFM transmits the VM label change information of the first VM to the PaaS in the NFV architecture, and triggers the scheduler built in the PaaS through the VM label change information of the first VM;

When the scheduling management device is PaaS, the scheduling management device triggering the scheduler in the NFV architecture includes:

After the PaaS determines that the VM label of the first VM has changed, it triggers the built-in scheduler.
The method according to claim 3, wherein when the scheduling management device is a VNFM, after the scheduling management device sets a corresponding VM label for the VM, the method further comprises:

The VNFM transmits the correspondence between the VM and the VM tag to the PaaS.
The method according to any one of claims 1 to 5, characterized in that:

Before the scheduling management device sets a corresponding VM label for the VM, the method further includes:

The scheduling management device issues an instruction to create a first VM and a second VM to the VIM, and the VIM is used to create the first VM and the second VM after receiving the instruction, and after the creation is successful, to The scheduling management device feeds back the creation success message of the first VM and the second VM;

After the scheduling management device sets the corresponding VM label for the VM, the method further includes:

The scheduling management device issues an instruction for creating a first Pod, and the instruction for creating a first Pod includes information about the HOST corresponding to the first Pod.
The method according to any one of claims 1 to 6, characterized in that, after the scheduling management device sets a corresponding VM label for the VM, the method further comprises:

The scheduling management device issues instructions for creating a third VM and a fourth VM to the VIM, and the instructions for creating the third VM and the fourth VM indicate that the third VM and the fourth VM have a strong anti-affinity The VIM is used to create the third VM and the fourth VM in different HOSTs according to the instructions for creating the third VM and the fourth VM;

The scheduling management device issues an instruction to create a second Pod to the scheduler, and the scheduler is configured to, after receiving the instruction to create a second Pod, determine whether the second Pod and the third VM are When the third Pod has strong anti-affinity, the second Pod is created in the fourth VM.
The method according to any one of claims 1 to 7, characterized in that, after the scheduling management device sets a corresponding VM label for the VM, the method further comprises:

When a VM of the first type needs to be created, the scheduling management device generates an instruction to create a VM of the first type according to a preset limit on the number of VMs of the first type in the same HOST;

The instruction for creating a VM of the first type includes a limit on the number of VMs of the first type, and the instruction for creating a VM of the first type is used to indicate that the VMs of the first type are created in the same HOST. The quantity is not greater than the stated quantity limit.
A scheduling device with network function virtualization NFV architecture is characterized in that it is applied to a scheduling management device and includes:

The transceiver unit is used to obtain the host HOST to which each virtual machine VM belongs;

The processing unit is configured to set a corresponding VM label for the VM, where the VM label includes information about the HOST to which the VM belongs, and after determining that the first VM migrates from the first HOST to the second HOST, according to the first The host to which the VM belongs after migration updates the VM label of the first VM, and triggers the scheduler in the NFV architecture. The scheduler is used to determine the VM label according to the updated VM label of the first VM. When the first minimum deployment unit Pod in the first VM does not meet the deployment requirements, the first Pod is scheduled to the second VM of the first HOST.
The device according to claim 9, wherein:

The processing unit is used to obtain the host HOST to which each VM belongs through the VM creation success information fed back by the virtualization infrastructure manager VIM in the NFV architecture;

and / or,

The processing unit is configured to determine the migration of the first VM from the first HOST to the second HOST through the VM migration completion information fed back by the VIM.
The device according to claim 9 or 10, wherein:

The scheduling management device is a virtualized network function manager VNFM;

Alternatively, the dispatch management device is a platform that is a service module PaaS with the dispatcher built-in.
The device according to claim 11, wherein:

When the scheduling management device is a VNFM, the processing unit is configured to transmit the VM label change information of the first VM to the PaaS in the NFV architecture, and trigger the VM label change information of the first VM. The scheduler built into the PaaS;

When the scheduling management device is PaaS, the processing unit is configured to trigger the built-in scheduler after determining that the VM label of the first VM has changed.
The apparatus according to claim 10, wherein when the scheduling management device is a VNFM, after the processing unit sets a corresponding VM tag for the VM, the transceiver unit is further configured to transfer the VM The correspondence relationship with the VM tag is transmitted to the PaaS.
The device according to any one of claims 10 to 13, wherein:

Before setting the corresponding VM label for the VM, the processing unit is further configured to issue an instruction to create a first VM and a second VM to the VIM through the transceiver unit, and the VIM is used for receiving the After the instruction, create the first VM and the second VM, and after the creation is successful, feedback the creation success message of the first VM and the second VM to the scheduling management device;

After setting the corresponding VM tag for the VM, the processing unit is further configured to issue an instruction to create a first Pod through the transceiver unit, and the instruction to create the first Pod includes the corresponding first Pod HOST information.
The device according to any one of claims 10 to 14, wherein:

After the processing unit sets a corresponding VM label for the VM, the processing unit is further configured to issue instructions to create a third VM and a fourth VM to the VIM through the transceiver unit, and the create third VM The instructions of the fourth VM and the fourth VM indicate that there is a strong anti-affinity between the third VM and the fourth VM, and the VIM is used to create the third VM and the fourth VM according to the instructions for creating the third VM and the fourth VM in different HOSTs. Create the third VM and the fourth VM respectively;

The processing unit is further configured to issue an instruction to create a second Pod to the scheduler through the transceiver unit, and the scheduler is configured to determine the second Pod after receiving the instruction to create the second Pod. When it has a strong anti-affinity with the third Pod in the third VM, the second Pod is created in the fourth VM.
The device according to any one of claims 10 to 15, wherein:

After setting the corresponding VM label for the VM, when the VM of the first type needs to be created, the processing unit is further configured to generate according to the preset number limit of the VM of the first type on the same HOST Instructions to create the first type of VM;

The instruction for creating a VM of the first type includes a limit on the number of VMs of the first type, and the instruction for creating a VM of the first type is used to indicate that the VMs of the first type are created in the same HOST. The quantity is not greater than the stated quantity limit.
A scheduling management device of network function virtualization NFV architecture, which is characterized in that it includes:

Processor and memory;

Wherein, the memory is used to store program instructions;

The processor is configured to call and execute the program instructions stored in the memory, so that the scheduling management device executes the method according to any one of claims 1 to 8.
A computer-readable medium, including instructions, which when run on a computer, causes the computer to execute the method according to any one of claims 1 to 8.