WO2021027689A1 - 一种基于网络功能虚拟化的版本升级的方法及设备 - Google Patents

一种基于网络功能虚拟化的版本升级的方法及设备 Download PDF

Info

Publication number
WO2021027689A1
WO2021027689A1 PCT/CN2020/107532 CN2020107532W WO2021027689A1 WO 2021027689 A1 WO2021027689 A1 WO 2021027689A1 CN 2020107532 W CN2020107532 W CN 2020107532W WO 2021027689 A1 WO2021027689 A1 WO 2021027689A1
Authority
WO
WIPO (PCT)
Prior art keywords
group
server
information
servers
upgrade
Prior art date
Application number
PCT/CN2020/107532
Other languages
English (en)
French (fr)
Inventor
张兵
夏木强
李志冰
卫晓刚
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2021027689A1 publication Critical patent/WO2021027689A1/zh

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/70Software maintenance or management
    • G06F8/71Version control; Configuration management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/4557Distribution of virtual machine instances; Migration and load balancing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45595Network integration; Enabling network access in virtual machine instances

Definitions

  • This application relates to the field of communication technology, and in particular to a method and device for version upgrade based on network function virtualization.
  • services are deployed in three layers, from top to bottom, the software as a service (SaaS) layer, the platform as a service (PaaS) layer, and the infrastructure as a service (infrastructure as a service) layer.
  • SaaS software as a service
  • PaaS platform as a service
  • IaaS infrastructure as a service
  • IaaS infrastructure as a service
  • the SaaS layer and PaaS layer deploy business-related software environments and software logic.
  • VNF virtualized network functions
  • the IaaS layer includes hardware such as cloud operating systems (deployment of business virtual machines), servers, storage, and switches.
  • cloud operating systems deployment of business virtual machines
  • the upgrade of the cloud operating system requires the restart of the server, which will cause the service virtual machine on the server to be interrupted, which does not meet the requirements of business continuity.
  • the embodiment of the present application provides a method for version upgrade based on network function virtualization, which can ensure business continuity during version upgrade and can ensure rapid upgrade.
  • the embodiments of the present application also provide corresponding equipment.
  • the first aspect of the present application provides a version upgrade method based on network function virtualization, which may include:
  • the management node sends a request to a management and orchestration (MANO) node, where the request is used to request group information to be upgraded, and MANO may also be referred to as an orchestration node for short;
  • MEO management and orchestration
  • the management node receives the group information to be upgraded sent by the MANO node, where the group information to be upgraded includes the information of the servers in the first group and the information of the servers in the second group;
  • the management node sends version upgrade information to the server in the first group, where the version upgrade information is used to instruct the server in the first group to switch the virtualized network function VNF service to the second group And is also used for version upgrades of servers in the first group;
  • the management node sends the version upgrade information to the server in the second group, where the version upgrade information is used to instruct the server in the second group to switch the VNF service to the first group
  • the server in the second group is also used to upgrade the version of the server in the second group.
  • the servers to be upgraded are divided into two groups.
  • the servers in the first group are upgraded, the servers in the second group provide services for the VNF business.
  • the server in the first group provides services for the VNF business, which can ensure business continuity and achieve a lossless upgrade.
  • the servers in the same group can be upgraded at the same time, which improves The efficiency of version upgrade has achieved rapid upgrade.
  • the method further includes:
  • the management node sends the version upgrade information to the control node of the cloud operating system, and the version upgrade information is used by the control node to perform a version upgrade according to the version upgrade information.
  • timely upgrading the version of the control node of the cloud operating system can ensure that the control node can keep synchronized with the versions of the servers in the first group and the servers in the second group.
  • the version upgrade information includes upgrade information of a cloud operating system, and the upgrade information of the cloud operating system is used for the servers in the first group and the first group.
  • the servers in the second group upgrade the software version corresponding to the cloud operating system.
  • the version upgrade information includes hardware upgrade information
  • the hardware upgrade information is used for the servers in the first group and the servers in the second group Upgrade their respective hardware versions.
  • both the software version of the cloud operating system and the hardware version of the server can be upgraded, which improves the efficiency of the version upgrade.
  • the first group includes a first availability zone (availability zone, AZ), and the second group includes a second availability zone;
  • the functional unit in the first available partition is a backup unit
  • the functional unit in the second available partition is the master unit
  • the functional unit in the first available partition is the master unit
  • the second available partition The functional unit in is a standby unit, wherein the functional unit runs on the server of the first group and the server of the second group; or,
  • the first available partition includes a first functional unit in load sharing mode
  • the second available partition includes a second functional unit in load sharing mode.
  • the first functional unit and the second functional unit are composed of The total number of functional units in the load sharing mode, and the difference between the number of the first functional unit and the number of the second functional unit is less than a preset threshold, wherein the first functional unit runs on the first On a group of servers, the second functional unit runs on the second group of servers.
  • the two groups each contain an available partition.
  • the main unit In the active/standby mode, the main unit can be deployed in one available partition and the standby unit can be deployed in the other available partition.
  • the main unit and the standby unit can be collectively referred to as functions Unit.
  • functional units can be evenly distributed to the first available partition and the second available partition. For example, 100 functional units are allocated to 50 in the first available partition and 50 to the second available partition. In the case that the equal distribution is not possible, the functional units are distributed as evenly as possible between the first available partition and the second available partition. For example: allocate 101 functional units to 50 in the first available partition and 51 in the second available partition.
  • the uneven distribution is not limited to the above example, and can be allocated according to actual needs.
  • the above functional units can be cloudized instances of business processes, virtual machines (virtual machines, VMs), and microservices.
  • the first group includes M server groups of the first type
  • the second group includes M server groups of the second type, each of the first type
  • the server group of corresponds to a second type of server group, and the M is an integer greater than 0;
  • Each first type of server group runs at least one standby unit, and each second type server group runs at least one main unit, or each first type server group runs at least one main unit, Each second type of server group has at least one standby unit running; or,
  • At least one first functional unit runs in each first-type server group, and at least one second functional unit runs in each second-type server group.
  • the first functional unit and the second functional unit are composed of The total number of functional units in the load sharing mode, and the difference between the number of the first functional unit and the number of the second functional unit is less than a preset threshold.
  • the two groups each contain at least one server group.
  • the main unit In the active/standby mode, the main unit can be deployed on the server group of one group, and the standby unit can be deployed on the server group of the other group.
  • the unit and the standby unit can be collectively referred to as a functional unit (unit).
  • the functional units In the load sharing mode, the functional units can be evenly distributed to the server groups of the first group and the second group. For example, 100 functional units are allocated to the server group of the first group and 50 are allocated in the first group. 50 servers are allocated to the second group. In the case of not being equally distributed, the functional units shall be distributed as evenly as possible on the server groups of the first group and the second group.
  • the above functional units can be cloudized instances of business processes, virtual machines (virtual machines, VMs), and microservices.
  • the group information to be upgraded further includes server information in the third group, and the method further includes:
  • the management node sends the version upgrade information to the server in the third group, the version upgrade information is used for the server in the third group to perform version upgrade, and the first group, the The second group and the third group only upgrade servers of one group at a time during upgrade.
  • micro-service scenario there can be three instances, and each instance is maintained in a group. These three groups are only upgraded one group at a time when upgrading, and there are two groups.
  • it is not limited to only three instances. There can also be more instances. No matter how many instances there are, an instance can be divided into a different group.
  • each group can be Perform serial upgrades, and only upgrade one group at a time.
  • control node is included in the third group.
  • control node of the cloud operating system may be independently located in a group, and in a microservice scenario, an instance may be located in the group where the control node is located.
  • the receiving, by the management node, the group information to be upgraded sent by the MANO node may include:
  • the management node receives a virtualized network function descriptor (VNFD) file sent by the MANO node, and the VNFD file includes the group information to be upgraded.
  • VNFD virtualized network function descriptor
  • the VNFD file may include the group distribution of all functional units supporting the VNF service, and may include a list of servers in each group.
  • the second aspect of the present application provides a management device, which is used to execute the foregoing first aspect or any possible implementation of the first aspect.
  • the device includes a module or unit for executing the foregoing first aspect or any possible implementation of the first aspect.
  • a third aspect of the present application provides a management device, including: at least one processor, a memory, a transceiver, and computer-executable instructions stored in the memory and running on the processor.
  • a management device including: at least one processor, a memory, a transceiver, and computer-executable instructions stored in the memory and running on the processor.
  • the processor executes the method described in the foregoing first aspect or any one of the possible implementation manners of the first aspect.
  • the fourth aspect of the present application provides a computer-readable storage medium storing one or more computer-executable instructions.
  • the processor executes any of the above-mentioned first aspect or first aspect.
  • One possible implementation is the method described.
  • the fifth aspect of the present application provides a computer program product storing one or more computer-executable instructions.
  • the processor executes any one of the first aspect or the first aspect. Ways of possible implementation.
  • the management device described in the second aspect and the fifth aspect may also be a chip applied to the management device, or other combination devices, components, etc. having the functions of the management device.
  • the receiving unit in the management device can be a communication interface, such as an input/output (I/O) interface.
  • the receiving unit can also be a receiver, which can include antennas and radio frequency circuits, etc.
  • the processing unit may be a processor, such as a central processing unit (CPU), and the sending unit may be a communication interface.
  • the management device is a wireless device, it may be a transmitter, which may include an antenna and a radio frequency circuit, etc.
  • the receiver and transmitter can be integrated transceivers.
  • the technical effects brought by the second aspect to the fifth aspect or any one of the possible implementation manners may refer to the technical effects brought about by the first aspect or the different possible implementation manners of the first aspect, and details are not described herein again.
  • the servers to be upgraded are divided into two groups.
  • the VNF services are switched to the servers in the second group, that is, from the The servers in the two groups provide services for VNF services.
  • the VNF services are switched to the servers in the first group, that is, the servers in the first group Providing services for the VNF business can ensure business continuity and achieve a lossless upgrade.
  • the servers in the same group can be upgraded at the same time. The upgrade that originally took a few days to complete, currently only requires a time window (usually 0: 00-3:00 is a time window) can be completed, which improves the efficiency of version upgrade and realizes rapid upgrade.
  • FIG. 1 is a schematic diagram of an embodiment of a version upgrade system based on network function virtualization provided by an embodiment of the present application
  • FIG. 2 is a schematic diagram of another embodiment of a version upgrade system based on network function virtualization provided by an embodiment of the present application;
  • FIG. 3 is a schematic diagram of an embodiment of a version upgrade method based on network function virtualization provided by an embodiment of the present application
  • FIG. 4 is a schematic diagram of another embodiment of a version upgrade method based on network function virtualization provided by an embodiment of the present application
  • FIG. 5 is a schematic diagram of an example of a master/backup mode provided by an embodiment of the present application.
  • FIG. 6 is a schematic diagram of an example of a load sharing mode provided by an embodiment of the present application.
  • FIG. 7 is a schematic diagram of a group structure based on available partitions according to an embodiment of the present application.
  • FIG. 8 is a schematic diagram of a group structure based on a server group provided by an embodiment of the present application.
  • FIG. 9 is a schematic diagram of an embodiment of a management device provided by an embodiment of the present application.
  • FIG. 10 is a schematic diagram of another embodiment of a management device provided by an embodiment of the present application.
  • the embodiment of the present application provides a method for version upgrade based on network function virtualization, which can ensure business continuity during version upgrade and can ensure rapid upgrade.
  • the embodiments of the present application also provide corresponding equipment. Detailed descriptions are given below.
  • FIG. 1 is a schematic diagram of an embodiment of a version upgrade system based on network function virtualization provided by an embodiment of the application.
  • the system for version upgrade based on network function virtualization may include a management node 10, a management and orchestration (MANO) node 20, a first group 30, and a second group. Group 40.
  • the management node 10 sends a request to the MANO node 20, where the request is used to request group information to be upgraded;
  • the management node 10 receives the group information to be upgraded sent by the MANO node 20, where the group information to be upgraded includes the information of the servers in the first group and the information of the servers in the second group;
  • the management node 10 sends version upgrade information to the servers in the first group 30, and the version upgrade information is used to instruct the servers in the first group to switch the virtualized network function VNF service to the second group
  • the servers in the group are also used for version upgrades of the servers in the first group
  • the management node 10 sends the version upgrade information to the server in the second group 40, where the version upgrade information is used to instruct the server in the second group to switch the VNF service to the first group
  • the server in the second group is also used to upgrade the version of the server in the second group.
  • the servers to be upgraded are divided into two groups.
  • the VNF services are switched to the servers in the second group, that is, from the The servers in the two groups provide services for VNF services.
  • the VNF services are switched to the servers in the first group, that is, the servers in the first group Providing services for the VNF business can ensure business continuity and achieve a lossless upgrade.
  • the servers in the same group can be upgraded at the same time. The upgrade that originally took a few days to complete, currently only requires a time window (usually 0: 00-3:00 is a time window) can be completed, which improves the efficiency of version upgrade and realizes rapid upgrade.
  • the VNF service is based on a cloud operating system.
  • the cloud operating system may include a control part and a service part.
  • the control part is located at the control node, and the service part is located on the servers of the first group and the second group.
  • the control node can be independent of the first group and the second group, or a separate group can be assigned to the control node, and the control node can also be located in the first group or the second group. The following takes a scenario where the control node is independent of the first group and the second group as an example.
  • another embodiment of the system for version upgrade based on network function virtualization provided by the embodiment of the present application may include:
  • the management node sends the version upgrade information to the control node of the cloud operating system, and the version upgrade information is used by the control node to perform a version upgrade according to the version upgrade information.
  • an embodiment of the present application also provides a method for version upgrade based on network function virtualization.
  • an embodiment of the method for version upgrade based on network function virtualization provided by the embodiment of the present application may include:
  • the management node sends a request to the MANO node, where the request is used to request group information to be upgraded.
  • the management node may be a separate server or a virtual machine, and an upgrade tool is installed on the management node, and the upgrade can be used to upgrade network functions virtualization infrastructure, NFVI).
  • NFVI network functions virtualization infrastructure
  • the MANO node sends the group information to be upgraded to the management node, and correspondingly, the management node receives the group information to be upgraded sent by the MANO node.
  • the group information to be upgraded includes the information of the server in the first group and the information of the server in the second group.
  • the MANO node may return a virtualized network function descriptor (VNFD) file to the management node, and the VNFD file includes the group information to be upgraded.
  • VNFD virtualized network function descriptor
  • the management node After receiving the VNFD file, the management node can parse the VNFD file, obtain from the VNFD file the distribution of the groups of functional units that provide support for the VNF business, and save the list of servers corresponding to each group, such as: Server list 1, and server list 2 in the second group.
  • the management node sends version upgrade information to the server in the first group.
  • the version upgrade information is used to instruct the server in the first group to switch the virtualized network function VNF service to the server in the second group, and is also used to upgrade the server in the first group .
  • the management node When the management node determines to upgrade the version of the servers in each group, it will send version upgrade information to the servers in the group.
  • the management node can send the version upgrade information to the corresponding group according to the list of servers in each group obtained in step 102 above.
  • the servers in the group send version upgrade information.
  • the servers in the first group perform version upgrades according to the version upgrade information.
  • the server in the first group After the server in the first group receives the version upgrade information, it will switch the VNF service it runs to the server in the second group, and then perform the version upgrade according to the version upgrade information.
  • the servers in the first group are not currently running VNF services, they may not be switched, and they will only be switched when they are running VNF services.
  • the management node sends the version upgrade information to the server in the second group.
  • the version upgrade information is used to instruct the server in the second group to switch the VNF service to the server in the first group, and is also used to upgrade the version of the server in the second group.
  • the servers in the second group perform version upgrades according to the version upgrade information.
  • the server in the second group After the server in the second group receives the version upgrade information, it switches the VNF service it runs to the server in the first group, and then performs the version upgrade according to the version upgrade information.
  • the handover may not be performed, and the handover will be performed only when the VNF service is running.
  • the method provided in the embodiment of the present application may further include:
  • the management node sends the version upgrade information to the control node of the cloud operating system, and the version upgrade information is used by the control node to perform a version upgrade according to the version upgrade information.
  • both the software version and the hardware version can be upgraded, one can be upgraded, or both can be upgraded at the same time.
  • the version upgrade information includes the upgrade information of the cloud operating system, and the upgrade information of the cloud operating system is used to upgrade the servers in the first group and the servers in the second group The software version corresponding to the cloud operating system.
  • the version upgrade information includes hardware upgrade information, and the hardware upgrade information is used for the servers in the first group and the servers in the second group to upgrade their respective hardware versions .
  • the solution provided by the embodiment of the application can upgrade the software version of the cloud operating system and the hardware version of the server, which improves the efficiency of version upgrade.
  • FIG. 4 another embodiment of the method for version upgrade based on network function virtualization provided by the embodiment of the present application may include:
  • the management node sends a request to the MANO node, where the request is used to request group information to be upgraded.
  • the MANO node sends a VNFD file to the management node, where the VNFD file includes the group information to be upgraded.
  • the management node parses the VNFD file to obtain a list of servers in each group.
  • Servers may exist in the form of server groups.
  • a server group in the first group corresponds to a server group in the second group.
  • server group A corresponds to server group A'.
  • Group B corresponds to server group B',...
  • server group N corresponds to server group N'.
  • Each server group can include at least one server.
  • the management node upgrades the control node.
  • control node can refer to the description of the control node in the foregoing embodiment for understanding, and details are not repeated here.
  • the management node upgrades the version of the server in the first group.
  • the upgraded software version refers to the upgrade of the cloud operating system.
  • the cloud operating system upgrade can be an upgrade of OpenStack, or an upgrade of Vmware, or an upgrade of other systems similar to OpenStack or Vmware.
  • the hardware version can include the firmware of some hardware on the server.
  • the management node upgrades the version of the server in the second group.
  • Step 205 and step 206 are not performed at the same time.
  • the VNF service runs on a server in the second group, and the server in the second group provides services for the VNF service.
  • step 206 is executed, the VNF service runs on the server in the first group, and the server in the first group provides service for the VNF service.
  • the deployment in the active/standby mode or the N-Way load sharing mode is usually adopted.
  • each main unit has a standby unit. If the main unit fails, the standby unit immediately takes over the business to ensure that the steady-state business is not damaged. If the backup unit fails, the main unit works normally, and normal business operations are not affected.
  • n functional units For the N-Way load sharing mode, as shown in Figure 6, there are a total of n functional units (Units), and all n units are in the main state and carry services.
  • the service will occupy up to 70% of the system resources.
  • the business volume In the 0:00-3:00 operating time window, the business volume generally drops to 30% of the peak period. At this time, the resource consumption is about 20%, which is far below 50%. At this time, if 50% of the Unit fails, steady-state business Lossless.
  • n functional units are distributed to different groups as evenly as possible.
  • the value of n is usually larger, and there are at least 2 functional units.
  • the control node of the cloud operating system can also be deployed to a group, such as deploying to group 0.
  • group 0 When NFVI is upgraded, the server corresponding to group 0 will be upgraded first, and the server corresponding to group 1 will be upgraded after the upgrade is successful. Then upgrade the server corresponding to group 2. Since the services in group 1 and group 2 are mutually backup or load sharing, it is ensured that VNF services are not damaged when NFVI is upgraded.
  • the version upgrade in the embodiment of this application can be a version upgrade across availability zones (AZ), or a version upgrade across server groups.
  • AZ version upgrade across availability zones
  • server groups e.g., a version upgrade across server groups.
  • AZ version upgrade across availability zones
  • server groups e.g., a version upgrade across server groups.
  • AZ version upgrade across availability zones
  • server groups e.g., a version upgrade across server groups.
  • cross-cluster version. upgrade Whether it is a cross-AZ or cross-server group upgrade, it can include the above-mentioned active/standby mode and load sharing mode.
  • the first group includes a first available partition
  • the second group includes a second available partition
  • the functional unit in the first available partition is a backup unit
  • the functional unit in the second available partition is the master unit
  • the functional unit in the first available partition is the master unit
  • the second available partition The functional unit in is a standby unit, wherein the functional unit runs on the server of the first group and the server of the second group; or,
  • the first available partition includes a first functional unit in load sharing mode
  • the second available partition includes a second functional unit in load sharing mode.
  • the first functional unit and the second functional unit are composed of The total number of functional units in the load sharing mode, and the difference between the number of the first functional unit and the number of the second functional unit is less than a preset threshold, wherein the first functional unit runs on the first On a group of servers, the second functional unit runs on the second group of servers.
  • the two groups each contain an available partition.
  • the main unit In the active/standby mode, the main unit can be deployed in one available partition, and the standby unit can be deployed in the other available partition.
  • the main unit and the standby unit can be collectively referred to as functional unit (unit ).
  • functional units can be evenly distributed to the first available partition and the second available partition. For example, 100 functional units are allocated to 50 in the first available partition and 50 to the second available partition. In the case that the equal distribution is not possible, the functional units are distributed as evenly as possible between the first available partition and the second available partition. For example: allocate 101 functional units to 50 in the first available partition and 51 in the second available partition.
  • the uneven distribution is not limited to the above example, and can be allocated according to actual needs. Regardless of whether it is the active/standby mode or the load sharing mode, the above functional units can be cloudized instances of business processes, virtual machines (virtual machines, VMs), and microservices.
  • a server group (server aggregate, SA) can also be called a host group (host aggregate, HA).
  • the host group HA_m to which the control node of the cloud operating system belongs can be Separately divide a group 0, the function of the control node can also be divided into two parts, one is located in AZ1, and the other is located in AZ2.
  • the server groups of group 1 are all located in AZ1, and the server groups of group 2 are all located in AZ2.
  • Each server group can contain multiple functional units.
  • the functional units are given in the form of virtual machines (VM).
  • VM virtual machines
  • the embodiment of this application is not limited to the VM form.
  • the VNF service runs on the virtual machine, and the resources provided by group 1 and group 2 for the same VNF service are as much as possible. balanced.
  • the first group includes M server groups of the first type
  • the second group includes M server groups of the second type
  • each server group of the first type corresponds to one
  • the M is an integer greater than 0;
  • Each first type of server group runs at least one standby unit, and each second type server group runs at least one main unit, or each first type server group runs at least one main unit, Each second type of server group has at least one standby unit running; or,
  • At least one first functional unit runs in each first-type server group, and at least one second functional unit runs in each second-type server group.
  • the first functional unit and the second functional unit are composed of The total number of functional units in the load sharing mode, and the difference between the number of the first functional unit and the number of the second functional unit is less than a preset threshold.
  • the two groups each contain at least one server group.
  • the main unit In the active/standby mode, the main unit can be deployed on the server group of one group, and the standby unit can be deployed on the server group of the other group.
  • the unit and the standby unit can be collectively referred to as a functional unit (unit).
  • the functional units In the load sharing mode, the functional units can be evenly distributed to the server groups of the first group and the second group. If they cannot be evenly distributed, try their best on the server groups of the first group and the second group. Balanced distribution of functional units. For example: 100 functional units are allocated to the server group of the first group, 50 are allocated to the server group of the second group. The 101 functional units are allocated to the server group of the first group, and 50 are allocated to the server group of the second group.
  • the uneven distribution is not limited to the above example, and can be allocated according to actual needs. .
  • the above functional units can be cloudized instances of business processes, virtual machines (virtual machines, VMs), and microservices.
  • a server group (server aggregate, SA) can also be called a host group (host aggregate, HA).
  • the host group to which the control node of the cloud operating system belongs HA_m separates a group 0 separately.
  • Group 1 includes multiple server groups, such as: HA_1,...,HA_x, the number of server groups included in group 2 is as balanced as possible with group 1, such as: HA_1',...,HA_x', each server group can It includes multiple functional units.
  • the functional unit in FIG. 8 is given in the form of a virtual machine (VM), and the VNF service runs on the virtual machine.
  • VM virtual machine
  • the functional unit of each server in group 1 is the main unit
  • the functional unit of each server in group 2 is the standby unit.
  • the functional unit of each server in group 2 is the master unit.
  • the server where the main unit is located is upgraded first, the VNF services on the server where the main unit is located need to be switched to the server where the standby unit is located, and then the server where the standby unit is located needs to be switched again. Relatively speaking, upgrading the server where the standby unit is located first can reduce the number of handovers.
  • the group information to be upgraded further includes server information in the third group, and the method may further include:
  • the management node sends the version upgrade information to the server in the third group, the version upgrade information is used for the server in the third group to perform version upgrade, and the first group, the The second group and the third group only upgrade servers of one group at a time during upgrade.
  • micro-service scenario there can be three instances, and each instance is maintained in a group. These three groups are only upgraded one group at a time when upgrading, and there are two groups.
  • it is not limited to only three instances. It can also be four instances, five instances, or more instances. No matter how many instances there are, an instance can be divided into a different group.
  • each group can perform serial upgrades, and only one group can be upgraded at a time.
  • the control node may be included in the third group.
  • the third instance can be divided into group 0, or the third instance can be divided into another group, for example: group 3.
  • group 0 described in FIGS. 7 and 8 may be equivalent to the third group described in the foregoing embodiment; group 1 may be equivalent to the first group described in the foregoing embodiment
  • group 2 may be equivalent to the second group described in the foregoing embodiment; similarly, when group 1 may be equivalent to the second group described in the foregoing embodiment, group 2 may be equivalent to the foregoing The first group described in the embodiment.
  • an embodiment of the management device 60 provided by the embodiment of the present application may include:
  • the sending unit 601 is configured to send a request to the management and orchestration MANO node, where the request is used to request group information to be upgraded;
  • the receiving unit 602 is configured to receive group information to be upgraded sent by the MANO node, where the group information to be upgraded includes information of servers in the first group and information of servers in the second group;
  • the sending unit 601 is further configured to send version upgrade information to the server in the first group, where the version upgrade information is used to instruct the server in the first group to switch the virtualized network function VNF service to The server in the second group is also used for version upgrade of the server in the first group;
  • the sending unit 601 is further configured to send the version upgrade information to the server in the second group, where the version upgrade information is used to instruct the server in the second group to switch the VNF service to The server in the first group is also used for version upgrade of the server in the second group.
  • the servers to be upgraded are divided into two groups.
  • the VNF services are switched to the servers in the second group, that is, from the The servers in the two groups provide services for VNF services.
  • the VNF services are switched to the servers in the first group, that is, the servers in the first group Providing services for VNF services can ensure business continuity and achieve lossless upgrades.
  • servers in the same group can be upgraded at the same time, which improves the efficiency of version upgrades and realizes rapid upgrades.
  • the sending unit 601 is further configured to send the version upgrade information to the control node of the cloud operating system, and the version upgrade information is used by the control node to perform the version according to the version upgrade information. upgrade.
  • the version upgrade information includes upgrade information of the cloud operating system, and the upgrade information of the cloud operating system is used for the servers in the first group and the servers in the second group.
  • the server upgrades the software version corresponding to the cloud operating system.
  • the version upgrade information includes hardware upgrade information
  • the hardware upgrade information is used to upgrade the servers in the first group and the servers in the second group. hardware version.
  • the first group includes a first available partition
  • the second group includes a second available partition
  • the functional unit in the first available partition is a backup unit
  • the functional unit in the second available partition is the master unit
  • the functional unit in the first available partition is the master unit
  • the second available partition The functional unit in is a standby unit, wherein the functional unit runs on the server of the first group and the server of the second group; or,
  • the first available partition includes a first functional unit in load sharing mode
  • the second available partition includes a second functional unit in load sharing mode.
  • the first functional unit and the second functional unit are composed of The total number of functional units in the load sharing mode, and the difference between the number of the first functional unit and the number of the second functional unit is less than a preset threshold, wherein the first functional unit runs on the first On a group of servers, the second functional unit runs on the second group of servers.
  • the first group includes M server groups of the first type
  • the second group includes M server groups of the second type
  • each server group of the first type corresponds to one
  • the M is an integer greater than 0;
  • Each first type of server group runs at least one standby unit, and each second type server group runs at least one main unit, or each first type server group runs at least one main unit, Each second type of server group has at least one standby unit running; or,
  • At least one first functional unit runs in each first-type server group, and at least one second functional unit runs in each second-type server group.
  • the first functional unit and the second functional unit are composed of The total number of functional units in the load sharing mode, and the difference between the number of the first functional unit and the number of the second functional unit is less than a preset threshold.
  • the sending unit 601 is further configured to send all information to the server in the third group when the group information to be upgraded also includes server information in the third group.
  • the version upgrade information is used for the server in the third group to perform version upgrade, and the first group, the second group, and the third group are upgraded once Only upgrade the servers of one group.
  • control node is included in the third group.
  • the receiving unit 602 is configured to receive a virtual network descriptor VNFD file sent by the MANO node, and the VNFD file includes the group information to be upgraded.
  • the management device 60 further includes a processing unit 603,
  • the processing unit 603 is configured to parse the VNFD file, and parse the group information to be upgraded from it.
  • An embodiment of the present application further provides a computer storage medium, wherein the computer storage medium stores a program, and the program executes a part or all of the steps recorded in the foregoing method embodiment.
  • the management device may be a server or other devices that can implement the functions of this application.
  • the management device may include: a processor 701 (for example, a CPU), a memory 702, a transmitter 704, and a receiver 703; the transmitter 704 and the receiver 703 are coupled to the processor 701, and the processor 701 controls the sending and receiving of the transmitter 704 The receiving action of the device 703.
  • the memory 702 may include a high-speed RAM memory, or may also include a non-volatile memory NVM, such as at least one disk memory.
  • the memory 702 may store various instructions for completing various processing functions and implementing the methods of the embodiments of the present application. step.
  • the management device involved in the embodiment of the present application may further include one or more of the power supply 705 and the communication port 706.
  • the devices described in FIG. 10 may be connected through a communication bus or through other The connection mode is connected, which is not limited in the embodiment of this application.
  • the receiver 703 and the transmitter 704 may be integrated in the transceiver of the management device, or may be independent receiving and transmitting antennas on the management device.
  • the communication bus is used to realize the communication connection between the components.
  • the aforementioned communication port 706 is used to implement connection and communication between the management device and other peripherals.
  • the above-mentioned memory 702 is used to store computer executable program code, and the program code includes instructions; when the processor 701 executes the instructions, the processor 701 in the management device can perform the actions performed by the processing unit 603 in FIG. 9.
  • the receiver 703 or the communication port 706 in the management device can perform the actions performed by the receiving unit 602 in FIG. 9, and the transmitter 704 or the communication port 706 in the management device can perform the actions performed by the sending unit 601 in FIG.
  • the technical effects are similar, so I won't repeat them here.
  • the present application also provides a chip system including a processor for supporting the aforementioned management device to realize its related functions, for example, receiving or processing the data and/or information involved in the aforementioned method embodiment.
  • the chip system further includes a memory, and the memory is used to store necessary program instructions and data of the computer equipment.
  • the chip system can be composed of chips, or include chips and other discrete devices.
  • the computer program product includes one or more computer instructions.
  • 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.
  • 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 (for example, coaxial cable, optical fiber, Digital Subscriber Line (DSL)) or wireless (for example, infrared, wireless, microwave, etc.).
  • wired for example, coaxial cable, optical fiber, Digital Subscriber Line (DSL)
  • wireless for example, infrared, wireless, microwave, etc.
  • the computer-readable storage medium may be any available medium that can be stored 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)).
  • the disclosed system, device, and method may be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of the units is only a logical function division, and there may be other divisions in actual implementation, for example, multiple units or components can be combined or It can be integrated into another system, or some features can be ignored or not implemented.
  • the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be in electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.
  • each unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units may be integrated into one unit.
  • the above-mentioned integrated unit can be implemented in the form of hardware or software functional unit.
  • the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer readable storage medium.
  • the technical solution of this application essentially or the part that contributes to the existing technology or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium , Including several instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the method described in each embodiment of the present application.
  • the aforementioned storage media include: U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), magnetic disk or optical disk and other media that can store program code .

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

一种基于网络功能虚拟化的版本升级的方法,包括:管理节点向MANO节点请求待升级的群组信息(101);管理节点接收MANO节点发送的待升级的群组信息(102),待升级的群组信息包括第一群组中服务器的信息和第二群组中服务器的信息;管理节点串式升级第一群组和第二群组中的服务器的版本,在一个群组中的服务器升级时,由另一个群组中的服务器运行VNF业务。上述版本升级方案包括云操作系统升级或服务器硬件升级,每次只升级一个群组,由另一个群组提供VNF服务,这样可以确保业务的连续性,做到了无损升级,另外,同一个群组中的服务器可以同时升级,实现了在一个操作时间窗内完成升级,提高了版本升级的效率。

Description

一种基于网络功能虚拟化的版本升级的方法及设备
本申请要求于2019年8月9日提交中国国家知识产权局、申请号为201910733775.2、发明名称为“一种基于网络功能虚拟化的版本升级的方法及设备”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信技术领域,具体涉及一种基于网络功能虚拟化的版本升级的方法及设备。
背景技术
在电信场景下,业务按3层部署,从上到下依次是软件即服务(software as a service,SaaS)层、平台即服务(platform as a service,PaaS)层、基础设施即服务(infrastructure as a service,IaaS)层。SaaS层和PaaS层部署了业务相关的软件环境和软件逻辑,从功能角度上来看,虚拟网络功能(virtualized network function,VNF)部署在IaaS层之上,归属于SaaS层和PaaS层,由IaaS层提供计算、存储、网络资源给SaaS层、PaaS层使用。
IaaS层包含云操作系统(业务虚拟机的部署)、服务器、存储、交换机等硬件。云操作系统的升级需要重启服务器,这会造成所在服务器上业务虚拟机中断,不满足业务连续性的要求。
发明内容
本申请实施例提供一种基于网络功能虚拟化的版本升级的方法,可以在版本升级时确保业务连续,且可以保证快速升级。本申请实施例还提供了相应的设备。
本申请第一方面提供一种基于网络功能虚拟化的版本升级的方法,可以包括:
管理节点向管理和编排(management and orchestration,MANO)节点发送请求,所述请求用于请求待升级的群组信息,MANO也可以简称为编排节点;
所述管理节点接收所述MANO节点发送的待升级的群组信息,所述待升级的群组信息包括第一群组中服务器的信息和第二群组中服务器的信息;
所述管理节点向所述第一群组中的服务器发送版本升级信息,所述版本升级信息用于指示所述第一群组中的服务器将虚拟化网络功能VNF业务切换到第二群组中的服务器,且还用于所述第一群组中的服务器进行版本升级;
所述管理节点向所述第二群组中的服务器发送所述版本升级信息,所述版本升级信息用于指示所述第二群组中的服务器将所述VNF业务切换到第一群组中的服务器,且还用于所述第二群组中的服务器进行版本升级。
上述第一方面中,将要升级的服务器划到两个群组中,当升级第一个群组中的服务器时,由第二个群组中的服务器为VNF业务提供服务,当升级第二个群组中的服务器时,由 第一个群组中的服务器为VNF业务提供服务,这样可以确保业务的连续性,做到了无损升级,另外,同一个群组中的服务器可以同时升级,提高了版本升级的效率,实现了快速升级。
在第一方面的一种可能的实现方式中,所述方法还包括:
所述管理节点向云操作系统的控制节点发送所述版本升级信息,所述版本升级信息用于所述控制节点根据所述版本升级信息进行版本升级。
上述可能的实现方式中,及时升级云操作系统的控制节点的版本,可以确保控制节点能与第一群组中的服务器和第二群组中的服务器的版本保持同步。
在第一方面的一种可能的实现方式中,所述版本升级信息中包括云操作系统的升级信息,所述云操作系统的升级信息用于所述第一群组中的服务器和所述第二群组中的服务器升级所述云操作系统对应的软件版本。
在第一方面的一种可能的实现方式中,所述版本升级信息中包括硬件的升级信息,所述硬件的升级信息用于所述第一群组中的服务器和所述第二群组中的服务器升级各自的硬件版本。
上述可能的实现方式中,既可以升级云操作系统的软件版本,又可以升级服务器的硬件版本,提高了版本升级的效率。
在第一方面的一种可能的实现方式中,所述第一群组包括第一可用分区(availability zone,AZ),所述第二群组包括第二可用分区;
所述第一可用分区中的功能单元为备单元,所述第二可用分区中的功能单元为主单元,或者,所述第一可用分区中的功能单元为主单元,所述第二可用分区中的功能单元为备单元,其中,所述功能单元运行于所述第一群组的服务器之上和所述第二群组的服务器之上;或者,
所述第一可用分区中包括负荷分担模式下的第一功能单元,所述第二可用分区中包括负荷分担模式下的第二功能单元,所述第一功能单元和所述第二功能单元组成所述负荷分担模式下功能单元的总体,且所述第一功能单元的数量与所述第二功能单元的数的差值小于预设阈值,其中,所述第一功能单元运行于所述第一群组的服务器之上,所述第二功能单元运行于所述第二群组的服务器之上。
上述可能的实现方式中,两个群组各自包含一个可用分区,在主备模式下,可以在一个可用分区部署主单元,在另一个可用分区部署备单元,主单元和备单元可以统称为功能单元(unit)。在负荷分担模式下,可以将功能单元平均分配到第一可用分区和第二可用分区,例如:将100个功能单元,在第一可用分区分配50个,在第二可用分区分配50个。在不能平均分配的情况下,在第一可用分区和第二可用分区之间尽量均衡分配功能单元。例如:将101个功能单元,在第一可用分区分配50个,在第二可用分区分配51个,当然,不平均分配的情况也不限于上述举例,可以根据实际需求分配。无论是主备模式,还是负荷分担模式,上述的功能单元都可以为业务进程、虚拟机(virtual machine,VM)、微服务等业务的云化实例。
在第一方面的一种可能的实现方式中,所述第一群组包括M个第一类型的服务器组,所述第二群组包括M个第二类型的服务器组,每个第一类型的服务器组对应一个第二类型 的服务器组,所述M为大于0的整数;
每个第一类型的服务器组中运行有至少一个备单元,每个第二类型的服务器组中运行有至少一个主单元,或者,每个第一类型的服务器组中运行有至少一个主单元,每个第二类型的服务器组中运行有至少一个备单元;或者,
每个第一类型的服务器组中运行有至少一个第一功能单元,每个第二类型的服务器组中运行有至少一个第二功能单元,所述第一功能单元和所述第二功能单元组成所述负荷分担模式下功能单元的总体,且所述第一功能单元的数量与所述第二功能单元的数的差值小于预设阈值。
上述可能的实现方式中,两个群组各自包含至少一个服务器组,在主备模式下,可以在一个群组的服务器组上部署主单元,在另一个群组的服务器组部署备单元,主单元和备单元可以统称为功能单元(unit)。在负荷分担模式下,可以将功能单元平均分配到第一群组和第二群组的服务器组上,例如:将100个功能单元,在第一群组的服务器组上分配50个,在第二群组的服务器组上分配50个。在不能平均分配的情况下,在第一群组和第二群组的服务器组上尽量均衡分配功能单元。例如:将101个功能单元,在第一群组的服务器组上分配50个,在第二群组的服务器组上分配51个,当然,不平均分配的情况也不限于上述举例,可以根据实际需求分配。无论是主备模式,还是负荷分担模式,上述的功能单元都可以为业务进程、虚拟机(virtual machine,VM)、微服务等业务的云化实例。
在第一方面的一种可能的实现方式中,在微服务化场景下,所述待升级的群组信息还包括第三群组中的服务器信息,所述方法还包括:
所述管理节点向所述第三群组中的服务器发送所述版本升级信息,所述版本升级信息用于所述第三群组中的服务器进行版本升级,且所述第一群组、所述第二群组和所述第三群组在升级时一次只升级一个群组的服务器。
上述可能的实现方式中,在微服务化场景下,可以有三个实例,每个实例维护在一个群组中,这三个群组在升级时一次只升级一个群组,保证有两个群组为微服务提供业务支持。当然,在微服务化场景下也不限于只有三个实例,也可以有更多实例,不管有多少实例都可以将一个实例划分到一个不同的群组中,在升级时各个群组之间可以执行串式升级,每次只升级一个群组。
在第一方面的一种可能的实现方式中,所述控制节点包含于所述第三群组中。
上述可能的实现方式中,云操作系统的控制节点可以独立位于一个群组中,在微服务化场景下,一个实例可以位于控制节点所在的群组。
在第一方面的一种可能的实现方式中,所述管理节点接收所述MANO节点发送的待升级的群组信息,可以包括:
所述管理节点接收所述MANO节点发送的虚拟网络描述符(virtualized network function descriptor,VNFD)文件,所述VNFD文件中包括所述待升级的群组信息。
上述可能的实现方式中,VNFD文件可以包括支持VNF业务的所有功能单元的群组分布情况,可以包括各群组中服务器的清单。
本申请第二方面提供一种管理设备,用于执行上述第一方面或第一方面的任意可能的实现方式中的方法。具体地,该装置包括用于执行上述第一方面或第一方面的任意可能的 实现方式中的方法的模块或单元。
本申请第三方面提供一种管理设备,包括:至少一个处理器、存储器、收发器以及存储在存储器中并可在处理器上运行的计算机执行指令,当所述计算机执行指令被所述处理器执行时,所述处理器执行如上述第一方面或第一方面任意一种可能的实现方式所述的方法。
本申请第四方面提供一种存储一个或多个计算机执行指令的计算机可读存储介质,当所述计算机执行指令被处理器执行时,所述处理器执行如上述第一方面或第一方面任意一种可能的实现方式所述的方法。
本申请第五方面提供一种存储一个或多个计算机执行指令的计算机程序产品,当所述计算机执行指令被所述处理器执行时,所述处理器执行上述第一方面或第一方面任意一种可能实现方式的方法。
上述第二方面和第五方面所描述的管理设备也可以是应用于管理设备中的芯片,或者其他具有上述管理设备功能的组合器件、部件等。
管理设备中的接收单元可以是通信接口,例如:输入/输出(input/output,I/O)接口,当管理设备是无线设备时,接收单元也可以是接收器,可以包括天线和射频电路等,处理单元可以是处理器,例如:中央处理单元(central processing unit,CPU),发送单元可以是通信接口,当管理设备是无线设备时,可以是发射器,可以包括天线和射频电路等,其中接收器和发射器可以是整合的收发器。
其中,第二方面至第五方面或者其中任一种可能实现方式所带来的技术效果可参见第一方面或第一方面不同可能实现方式所带来的技术效果,此处不再赘述。
本申请实施例提供的方案,将要升级的服务器划到两个群组中,当升级第一个群组中的服务器时,将VNF业务切换到第二个群组的服务器上,也就是由第二个群组中的服务器为VNF业务提供服务,当升级第二个群组中的服务器时,将VNF业务切换到第一个群组的服务器上,也就是由第一个群组中的服务器为VNF业务提供服务,这样可以确保业务的连续性,做到了无损升级,另外,同一个群组中的服务器可以同时升级,原来需要几天完成的升级,当前只需要一个时间窗(一般0:00-3:00为一个时间窗)就可以完成,提高了版本升级的效率,实现了快速升级。
附图说明
图1是本申请实施例提供的基于网络功能虚拟化的版本升级的系统的一实施例示意图;
图2是本申请实施例提供的基于网络功能虚拟化的版本升级的系统的另一实施例示意图;
图3是本申请实施例提供的基于网络功能虚拟化的版本升级的方法的一实施例示意图;
图4是本申请实施例提供的基于网络功能虚拟化的版本升级的方法的另一实施例示意图;
图5是本申请实施例提供的主备模式的一示例示意图;
图6是本申请实施例提供的负荷分担模式的一示例示意图;
图7是本申请实施例提供的基于可用分区的一群组结构示意图;
图8是本申请实施例提供的基于服务器组的一群组结构示意图;
图9是本申请实施例提供的管理设备的一实施例示意图;
图10是本申请实施例提供的管理设备的另一实施例示意图。
具体实施方式
下面结合附图,对本申请的实施例进行描述,显然,所描述的实施例仅仅是本申请一部分的实施例,而不是全部的实施例。本领域普通技术人员可知,随着技术的发展和新场景的出现,本申请实施例提供的技术方案对于类似的技术问题,同样适用。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
本申请实施例提供一种基于网络功能虚拟化的版本升级的方法,可以在版本升级时确保业务连续,且可以保证快速升级。本申请实施例还提供了相应的设备。以下分别进行详细说明。
图1为本申请实施例提供的基于网络功能虚拟化的版本升级的系统的一实施例示意图。
如图1所示,本申请实施例提供的基于网络功能虚拟化的版本升级的系统可以包括管理节点10、管理和编排(management and orchestration,MANO)节点20、第一群组30和第二群组40。
管理节点10向MANO节点20发送请求,所述请求用于请求待升级的群组信息;
管理节点10接收所述MANO节点20发送的待升级的群组信息,所述待升级的群组信息包括第一群组中服务器的信息和第二群组中服务器的信息;
所述管理节点10向所述第一群组30中的服务器发送版本升级信息,所述版本升级信息用于指示所述第一群组中的服务器将虚拟化网络功能VNF业务切换到第二群组中的服务器,且还用于所述第一群组中的服务器进行版本升级;
管理节点10向所述第二群组40中的服务器发送所述版本升级信息,所述版本升级信息用于指示所述第二群组中的服务器将所述VNF业务切换到第一群组中的服务器,且还用于所述第二群组中的服务器进行版本升级。
本申请实施例提供的方案,将要升级的服务器划到两个群组中,当升级第一个群组中的服务器时,将VNF业务切换到第二个群组的服务器上,也就是由第二个群组中的服务器为VNF业务提供服务,当升级第二个群组中的服务器时,将VNF业务切换到第一个群组的服务器上,也就是由第一个群组中的服务器为VNF业务提供服务,这样可以确保业务的连续性,做到了无损升级,另外,同一个群组中的服务器可以同时升级,原来需要几天完成的升级,当前只需要一个时间窗(一般0:00-3:00为一个时间窗)就可以完成,提高了版本升级的效率,实现了快速升级。
本申请实施例中,VNF业务是基于云操作系统的,云操作系统可以包括控制部分和业务部分,控制部分位于控制节点,业务部分位于第一群组和第二群组的服务器上。控制节点可以独立于第一群组和第二群组之外,也可以为控制节点单独分配一个群组,控制节点也可以位于第一群组或第二群组。下面以控制节点独立于第一群组和第二群组之外的场景为例进行介绍。
如图2所示,本申请实施例提供的基于网络功能虚拟化的版本升级的系统的另一实施例可以包括:
所述管理节点向云操作系统的控制节点发送所述版本升级信息,所述版本升级信息用于所述控制节点根据所述版本升级信息进行版本升级。
在升级时,及时升级云操作系统的控制节点的版本,可以确保控制节点能与第一群组中的服务器和第二群组中的服务器的版本保持同步,才有利于控制节点执行相应的控制。
结合上述基于网络功能虚拟化的版本升级的系统,本申请实施例还提供了基于网络功能虚拟化的版本升级的方法。
如图3所示,本申请实施例提供的基于网络功能虚拟化的版本升级的方法的一实施例可以包括:
101、管理节点向MANO节点发送请求,所述请求用于请求待升级的群组信息。
本申请实施例中,管理节点可以是一个单独的服务器,也可以是一个虚拟机,该管理节点上安装有升级工具,该升级工作可以用于升级网络功能虚拟化基础设施(network functions virtualization infrastructure,NFVI)。
102、MANO节点向管理节点发送待升级的群组信息,对应地,管理节点接收所述MANO节点发送的待升级的群组信息。
所述待升级的群组信息包括第一群组中服务器的信息和第二群组中服务器的信息。
一种可能的实现方式中,MANO节点可以向管理节点返回虚拟网络描述符(virtualized network function descriptor,VNFD)文件,所述VNFD文件中包括所述待升级的群组信息。
管理节点接收VNFD文件后,可以解析VNFD文件,从VNFD文件获取为VNF业务提供支持的功能单元的群组的分布情况,并保存各群组对应的服务器的清单,如:第一群组中的服务器清单1,以及第二群组中的服务器清单2。
103、管理节点向所述第一群组中的服务器发送版本升级信息。
所述版本升级信息用于指示所述第一群组中的服务器将虚拟化网络功能VNF业务切换到第二群组中的服务器,且还用于所述第一群组中的服务器进行版本升级。
管理节点在确定对各群组中的服务器进行版本升级时,会向群组中的服务器发送版本升级信息,管理节点可以根据上述步骤102中获得的各群组中的服务器的清单,向相应群组中的服务器发送版本升级信息。
104、第一群组中的服务器根据版本升级信息进行版本升级。
第一群组中服务器收到版本升级信息后,就会将自身所运行的VNF业务切换到第二群组的服务器中,然后根据版本升级信息进行版本升级。
如果第一群组中的服务器当前没有运行VNF业务,则可以不进行切换,只有在运行VNF 业务时才会进行切换。
105、管理节点向所述第二群组中的服务器发送所述版本升级信息。
所述版本升级信息用于指示所述第二群组中的服务器将所述VNF业务切换到第一群组中的服务器,且还用于所述第二群组中的服务器进行版本升级。
106、第二群组中的服务器根据版本升级信息进行版本升级。
第二群组中服务器收到版本升级信息后,就会将自身所运行的VNF业务切换到第一群组的服务器中,然后根据版本升级信息进行版本升级。
如果第二群组中的服务器当前没有运行VNF业务,则可以不进行切换,只有在运行VNF业务时才会进行切换。
如上述系统部分所描述的,一种可能的实现方式中,本申请实施例提供的方法还可以包括:
所述管理节点向云操作系统的控制节点发送所述版本升级信息,所述版本升级信息用于所述控制节点根据所述版本升级信息进行版本升级。
在升级时,及时升级云操作系统的控制节点的版本,可以确保控制节点能与第一群组中的服务器和第二群组中的服务器的版本保持同步,才有利于控制节点执行相应的控制。
本申请实施例中,既可以升级软件版本,也可以升级硬件版本,可以择一升级,也可以两者同时升级。
当升级软件版本时,所述版本升级信息中包括云操作系统的升级信息,所述云操作系统的升级信息用于所述第一群组中的服务器和所述第二群组中的服务器升级所述云操作系统对应的软件版本。
当升级硬件版本时,所述版本升级信息中包括硬件的升级信息,所述硬件的升级信息用于所述第一群组中的服务器和所述第二群组中的服务器升级各自的硬件版本。
本申请实施例提供的方案既可以升级云操作系统的软件版本,又可以升级服务器的硬件版本,提高了版本升级的效率。
上述实施例所描述的方案,还可以参阅图4进行理解,如图4所示,本申请实施例提供的基于网络功能虚拟化的版本升级的方法的另一实施例可以包括:
201、管理节点向MANO节点发送请求,所述请求用于请求待升级的群组信息。
202、MANO节点向管理节点发送VNFD文件,所述VNFD文件中包括所述待升级的群组信息。
203、管理节点解析VNFD文件,以获取各群组中服务器的清单。
服务器可以是以服务器组的形式存在的,第一群组中的一个服务器组会对应一个第二群组中的服务器组,如图4中所示出的服务器组A对应服务器组A’,服务器组B对应服务器组B’,…,务器组N对应服务器组N’。每个服务器组中都可以包括至少一个服务器。
204、管理节点升级控制节点。
控制节点可以参阅前述实施例中对控制节点的描述进行理解,此处不再重复赘述。
205、管理节点升级第一群组中的服务器的版本。
升级的软件版本指的是升级云操作系统,云操作系统升级可以是升级OpenStack,也可以是升级Vmware,也可以是升级其他与OpenStack或Vmware类似的系统。硬件版本可以 包括服务器上一些硬件的固件等。
206、管理节点升级第二群组中的服务器的版本。
步骤205和步骤206不同时执行,在执行步骤205时,VNF业务运行在第二群组中的服务器上,由第二群组中的服务器为VNF业务提供服务。在执行步骤206时,VNF业务运行在第一群组中的服务器上,由第一群组中的服务器为VNF业务提供服务。
电信领域为了确保业务达到5个9或6个9的可靠性,通常采用主备模式部署或N-Way负荷分担模式部署。
对于主备模式,如图5所示,每个主单元都有一个备单元。如果主单元故障,备单元立即接管业务,确保稳态业务无损。如果备单元故障,主单元正常工作,业务正常运行不受影响。
对于N-Way负荷分担模式,如图6所示,共n个功能单元(Unit),于n个Unit都处于主状态并且承载业务,业务高峰期业务最多会占用系统70%的资源。在0:00-3:00操作时间窗内业务量一般降至高峰期的30%,此时资源消耗约20%,远低于50%,此时如果有50%的Unit故障,稳态业务无损。
结合电信业务可靠性机制,在安装部署阶段通过VNFD的规划,将VNF的所有Unit分散到上述所描述的第一群组和第二群组中。
主备模式下,主单元和备单元分布到不同群组,负荷分担模式下,n个功能单元尽量平均分布到不同群组,n的取值通常较大,至少有2个功能单元。
云操作系统的控制节点也可以部署到一个群组中,如部署到群组0,NFVI升级时优先升级群组0对应的服务器,等升级成功后再升级群组1对应的服务器,等升级成功后再升级群组2对应的服务器。由于群组1与群组2中的业务互为主备或负荷分担,从而确保NFVI升级时VNF业务不受损。
本申请实施例中的版本升级,可以是跨可用分区(availability zone,AZ)进行版本升级,也可以是跨服务器组的版本升级,当然,在VMware的情况下,也可以称为跨集群的版本升级。无论是跨AZ的,还是跨服务器组的升级都可以包括上述主备模式和负荷分担模式。
在跨AZ的场景中,所述第一群组包括第一可用分区,所述第二群组包括第二可用分区;
所述第一可用分区中的功能单元为备单元,所述第二可用分区中的功能单元为主单元,或者,所述第一可用分区中的功能单元为主单元,所述第二可用分区中的功能单元为备单元,其中,所述功能单元运行于所述第一群组的服务器之上和所述第二群组的服务器之上;或者,
所述第一可用分区中包括负荷分担模式下的第一功能单元,所述第二可用分区中包括负荷分担模式下的第二功能单元,所述第一功能单元和所述第二功能单元组成所述负荷分担模式下功能单元的总体,且所述第一功能单元的数量与所述第二功能单元的数的差值小于预设阈值,其中,所述第一功能单元运行于所述第一群组的服务器之上,所述第二功能单元运行于所述第二群组的服务器之上。
该场景中,两个群组各自包含一个可用分区,在主备模式下,可以在一个可用分区部署主单元,在另一个可用分区部署备单元,主单元和备单元可以统称为功能单元(unit)。 在负荷分担模式下,可以将功能单元平均分配到第一可用分区和第二可用分区,例如:将100个功能单元,在第一可用分区分配50个,在第二可用分区分配50个。在不能平均分配的情况下,在第一可用分区和第二可用分区之间尽量均衡分配功能单元。例如:将101个功能单元,在第一可用分区分配50个,在第二可用分区分配51个,当然,不平均分配的情况也不限于上述举例,可以根据实际需求分配。无论是主备模式,还是负荷分担模式,上述的功能单元都可以为业务进程、虚拟机(virtual machine,VM)、微服务等业务的云化实例。
该跨AZ的场景下,如图7所示,服务器组(server aggregate,SA)也可以称为主机组(host aggregate,HA),该场景下可以将云操作系统的控制节点所属的主机组HA_m单独划分出一个群组0,该控制节点的功能也可以划分为两部分,一部分位于AZ1,一部分位于AZ2。群组1的服务器组都位于AZ1,群组2的服务器组都位于AZ2,各服务器组都可以包含多个功能单元,图7中该功能单元是以虚拟机(virtual machine,VM)的形式给出的,当然本申请实施例中不限于VM这一种形式,当是VM形式时,VNF业务运行于虚拟机上,群组1与群组2在针对同一个VNF业务所提供的资源是尽量均衡的。在版本升级时,可以先升级备单元所在的服务器,也可以先升级主单元所在的服务器,若先升级备单元所在的服务器,则升级备单元所在的服务器时不需要切换VNF业务,升级主单元所在的服务器时,执行一次VNF业务切换即可。若先升级主单元所在的服务器,则需要先把主单元所在的服务器上的VNF业务切换到备单元所在的服务器,再升级备单元所在的服务器时,还要再切换一次。相对来说,先升级备单元所在的服务器可以减少切换的次数。
在跨服务器组的场景中,所述第一群组包括M个第一类型的服务器组,所述第二群组包括M个第二类型的服务器组,每个第一类型的服务器组对应一个第二类型的服务器组,所述M为大于0的整数;
每个第一类型的服务器组中运行有至少一个备单元,每个第二类型的服务器组中运行有至少一个主单元,或者,每个第一类型的服务器组中运行有至少一个主单元,每个第二类型的服务器组中运行有至少一个备单元;或者,
每个第一类型的服务器组中运行有至少一个第一功能单元,每个第二类型的服务器组中运行有至少一个第二功能单元,所述第一功能单元和所述第二功能单元组成所述负荷分担模式下功能单元的总体,且所述第一功能单元的数量与所述第二功能单元的数的差值小于预设阈值。
上述可能的实现方式中,两个群组各自包含至少一个服务器组,在主备模式下,可以在一个群组的服务器组上部署主单元,在另一个群组的服务器组部署备单元,主单元和备单元可以统称为功能单元(unit)。在负荷分担模式下,可以将功能单元平均分配到第一群组和第二群组的服务器组上,在不能平均分配的情况下,在第一群组和第二群组的服务器组上尽量均衡分配功能单元。例如:将100个功能单元,在第一群组的服务器组上分配50个,在第二群组的服务器组上分配50个。将101个功能单元,在第一群组的服务器组上分配50个,在第二群组的服务器组上分配51个,当然,不平均分配的情况也不限于上述举例,可以根据实际需求分配。无论是主备模式,还是负荷分担模式,上述的功能单元都可以为业务进程、虚拟机(virtual machine,VM)、微服务等业务的云化实例。
该跨服务器组的场景下,如图8所示,服务器组(server aggregate,SA)也可以称为主机组(host aggregate,HA),该场景下可以将云操作系统的控制节点所属的主机组HA_m单独划分出一个群组0。群组1中包括多个服务器组,如:HA_1,…,HA_x,群组2中包括的服务器组的数量与群组1尽量均衡,如:HA_1’,…,HA_x’,各服务器组都可以包含多个功能单元,图8中该功能单元是以虚拟机(virtual machine,VM)的形式给出的,VNF业务运行于虚拟机上。在主备模式下,若群组1中的各服务器的功能单元为主单元,则群组2中各服务器的功能单元为备单元。当然,若群组1中的各服务器的功能单元为备单元,则群组2中各服务器的功能单元为主单元。在版本升级时,可以先升级备单元所在的服务器,也可以先升级主单元所在的服务器,若先升级备单元所在的服务器,则升级备单元所在的服务器时不需要切换VNF业务,升级主单元所在的服务器时,执行一次VNF业务切换即可。若先升级主单元所在的服务器,则需要先把主单元所在的服务器上的VNF业务切换到备单元所在的服务器,再升级备单元所在的服务器时,还要再切换一次。相对来说,先升级备单元所在的服务器可以减少切换的次数。
一种可能的实现方式中,在微服务化场景下,所述待升级的群组信息还包括第三群组中的服务器信息,所述方法还可以包括:
所述管理节点向所述第三群组中的服务器发送所述版本升级信息,所述版本升级信息用于所述第三群组中的服务器进行版本升级,且所述第一群组、所述第二群组和所述第三群组在升级时一次只升级一个群组的服务器。
上述可能的实现方式中,在微服务化场景下,可以有三个实例,每个实例维护在一个群组中,这三个群组在升级时一次只升级一个群组,保证有两个群组为微服务提供业务支持。当然,在微服务化场景下也不限于只有三个实例,也可以是四个实例或五个实例,或者更多实例,不管有多少实例都可以将一个实例划分到一个不同的群组中,在升级时各个群组之间可以执行串式升级,每次只升级一个群组。
所述控制节点可以包含于所述第三群组中。
也就是说,在微服务化三实例的场景中,可以将第三个实例划分到群组0中,也可以为第三个实例再重新划分个群组,例如:群组3。
需要说明的是,上述图7和图8中所描述的群组0可以相当于前述实施例中所描述的第三群组;在群组1可以相当于前述实施例中所描述的第一群组时,群组2可以相当于前述实施例中所描述的第二群组;同样,当群组1可以相当于前述实施例中所描述的第二群组时,群组2可以相当于前述实施例中所描述的第一群组。
以上描述了本申请实施例所提供的基于网络功能虚拟化的版本升级的系统及方法,下面结合附图介绍本申请实施例提供的管理设备。
如图9所示,本申请实施例提供的管理设备60的一实施例可以包括:
发送单元601,用于向管理和编排MANO节点发送请求,所述请求用于请求待升级的群组信息;
接收单元602,用于接收所述MANO节点发送的待升级的群组信息,所述待升级的群组信息包括第一群组中服务器的信息和第二群组中服务器的信息;
所述发送单元601,还用于向所述第一群组中的服务器发送版本升级信息,所述版本 升级信息用于指示所述第一群组中的服务器将虚拟化网络功能VNF业务切换到第二群组中的服务器,且还用于所述第一群组中的服务器进行版本升级;
所述发送单元601,还用于向所述第二群组中的服务器发送所述版本升级信息,所述版本升级信息用于指示所述第二群组中的服务器将所述VNF业务切换到第一群组中的服务器,且还用于所述第二群组中的服务器进行版本升级。
本申请实施例提供的方案,将要升级的服务器划到两个群组中,当升级第一个群组中的服务器时,将VNF业务切换到第二个群组的服务器上,也就是由第二个群组中的服务器为VNF业务提供服务,当升级第二个群组中的服务器时,将VNF业务切换到第一个群组的服务器上,也就是由第一个群组中的服务器为VNF业务提供服务,这样可以确保业务的连续性,做到了无损升级,另外,同一个群组中的服务器可以同时升级,提高了版本升级的效率,实现了快速升级。
一种可能的实现方式中,所述发送单元601,还用于向云操作系统的控制节点发送所述版本升级信息,所述版本升级信息用于所述控制节点根据所述版本升级信息进行版本升级。
一种可能的实现方式中,所述版本升级信息中包括云操作系统的升级信息,所述云操作系统的升级信息用于所述第一群组中的服务器和所述第二群组中的服务器升级所述云操作系统对应的软件版本。
一种可能的实现方式中,所述版本升级信息中包括硬件的升级信息,所述硬件的升级信息用于所述第一群组中的服务器和所述第二群组中的服务器升级各自的硬件版本。
一种可能的实现方式中,所述第一群组包括第一可用分区,所述第二群组包括第二可用分区;
所述第一可用分区中的功能单元为备单元,所述第二可用分区中的功能单元为主单元,或者,所述第一可用分区中的功能单元为主单元,所述第二可用分区中的功能单元为备单元,其中,所述功能单元运行于所述第一群组的服务器之上和所述第二群组的服务器之上;或者,
所述第一可用分区中包括负荷分担模式下的第一功能单元,所述第二可用分区中包括负荷分担模式下的第二功能单元,所述第一功能单元和所述第二功能单元组成所述负荷分担模式下功能单元的总体,且所述第一功能单元的数量与所述第二功能单元的数的差值小于预设阈值,其中,所述第一功能单元运行于所述第一群组的服务器之上,所述第二功能单元运行于所述第二群组的服务器之上。
一种可能的实现方式中,所述第一群组包括M个第一类型的服务器组,所述第二群组包括M个第二类型的服务器组,每个第一类型的服务器组对应一个第二类型的服务器组,所述M为大于0的整数;
每个第一类型的服务器组中运行有至少一个备单元,每个第二类型的服务器组中运行有至少一个主单元,或者,每个第一类型的服务器组中运行有至少一个主单元,每个第二类型的服务器组中运行有至少一个备单元;或者,
每个第一类型的服务器组中运行有至少一个第一功能单元,每个第二类型的服务器组中运行有至少一个第二功能单元,所述第一功能单元和所述第二功能单元组成所述负荷分 担模式下功能单元的总体,且所述第一功能单元的数量与所述第二功能单元的数的差值小于预设阈值。
一种可能的实现方式中,所述发送单元601,还用于在所述待升级的群组信息还包括第三群组中的服务器信息时,向所述第三群组中的服务器发送所述版本升级信息,所述版本升级信息用于所述第三群组中的服务器进行版本升级,且所述第一群组、所述第二群组和所述第三群组在升级时一次只升级一个群组的服务器。
一种可能的实现方式中,所述控制节点包含于所述第三群组中。
一种可能的实现方式中,所述接收单元602,用于接收所述MANO节点发送的虚拟网络描述符VNFD文件,所述VNFD文件中包括所述待升级的群组信息。
一种可能的实现方式中,管理设备60还包括处理单元603,
处理单元603,用于解析VNFD文件,从中解析出所述待升级的群组信息。
需要说明的是,上述所描述的管理设备由于与本申请方法实施例基于同一构思,其带来的技术效果与本申请方法实施例相同,具体内容可参见本申请前述所示的方法实施例中的叙述,此处不再赘述。
本申请实施例还提供一种计算机存储介质,其中,该计算机存储介质存储有程序,该程序执行包括上述方法实施例中记载的部分或全部步骤。
如图10所示,为本申请实施例的又一种管理设备的结构示意图,该管理设备可以是服务器,也可以是其他可以实现本申请功能的设备。该管理设备可以包括:处理器701(例如CPU)、存储器702、发送器704和接收器703;发送器704和接收器703耦合至处理器701,处理器701控制发送器704的发送动作和接收器703的接收动作。存储器702可能包含高速RAM存储器,也可能还包括非易失性存储器NVM,例如至少一个磁盘存储器,存储器702中可以存储各种指令,以用于完成各种处理功能以及实现本申请实施例的方法步骤。可选的,本申请实施例涉及的管理设备还可以包括:电源705、以及通信端口706中的一个或多个,图10中所描述的各器件可以是通过通信总线连接,也可以是通过其他连接方式连接,对此,本申请实施例中不做限定。接收器703和发送器704可以集成在管理设备的收发器中,也可以为管理设备上分别独立的收、发天线。通信总线用于实现元件之间的通信连接。上述通信端口706用于实现管理设备与其他外设之间进行连接通信。
在一些实施例中,上述存储器702用于存储计算机可执行程序代码,程序代码包括指令;当处理器701执行指令时,管理设备中的处理器701可以执行图9中处理单元603执行的动作,管理设备中的接收器703或通信端口706可以执行图9中接收单元602执行的动作,管理设备中的发送器704或通信端口706可以执行图9中发送单元601执行的动作,其实现原理和技术效果类似,在此不再赘述。
本申请还提供了一种芯片系统,该芯片系统包括处理器,用于支持上述管理设备实现其所涉及的功能,例如,例如接收或处理上述方法实施例中所涉及的数据和/或信息。在一种可能的设计中,所述芯片系统还包括存储器,所述存储器,用于保存计算机设备必要的程序指令和数据。该芯片系统,可以由芯片构成,也可以包含芯片和其他分立器件。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。
所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时,全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(Digital Subscriber Line,DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统,装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,以上实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (11)

  1. 一种基于网络功能虚拟化的版本升级的方法,其特征在于,包括:
    管理节点向编排MANO节点发送请求,所述请求用于请求待升级的群组信息;
    所述管理节点接收所述MANO节点发送的待升级的群组信息,所述待升级的群组信息包括第一群组中服务器的信息和第二群组中服务器的信息;
    所述管理节点向所述第一群组中的服务器发送版本升级信息,所述版本升级信息用于指示所述第一群组中的服务器将虚拟化网络功能VNF业务切换到第二群组中的服务器,且还用于所述第一群组中的服务器进行版本升级;
    所述管理节点向所述第二群组中的服务器发送所述版本升级信息,所述版本升级信息用于指示所述第二群组中的服务器将所述VNF业务切换到第一群组中的服务器,且还用于所述第二群组中的服务器进行版本升级。
  2. 根据权利要求1所述的方法,其特征在于,所述方法还包括:
    所述管理节点向云操作系统的控制节点发送所述版本升级信息,所述版本升级信息用于所述控制节点根据所述版本升级信息进行版本升级。
  3. 根据权利要求1或2所述的方法,其特征在于,所述版本升级信息中包括云操作系统的升级信息,所述云操作系统的升级信息用于所述第一群组中的服务器和所述第二群组中的服务器升级所述云操作系统对应的软件版本。
  4. 根据权利要求1或2所述的方法,其特征在于,所述版本升级信息中包括硬件的升级信息,所述硬件的升级信息用于所述第一群组中的服务器和所述第二群组中的服务器升级各自的硬件版本。
  5. 根据权利要求1-4任一项所述的方法,其特征在于,所述第一群组包括第一可用分区,所述第二群组包括第二可用分区;
    所述第一可用分区中的功能单元为备单元,所述第二可用分区中的功能单元为主单元,或者,所述第一可用分区中的功能单元为主单元,所述第二可用分区中的功能单元为备单元,其中,所述功能单元运行于所述第一群组的服务器之上和所述第二群组的服务器之上;或者,
    所述第一可用分区中包括负荷分担模式下的第一功能单元,所述第二可用分区中包括负荷分担模式下的第二功能单元,所述第一功能单元和所述第二功能单元组成所述负荷分担模式下功能单元的总体,且所述第一功能单元的数量与所述第二功能单元的数的差值小于预设阈值,其中,所述第一功能单元运行于所述第一群组的服务器之上,所述第二功能单元运行于所述第二群组的服务器之上。
  6. 根据权利要求1-4任一项所述的方法,其特征在于,所述第一群组包括M个第一类型的服务器组,所述第二群组包括M个第二类型的服务器组,每个第一类型的服务器组对应一个第二类型的服务器组,所述M为大于0的整数;
    每个第一类型的服务器组中运行有至少一个备单元,每个第二类型的服务器组中运行有至少一个主单元,或者,每个第一类型的服务器组中运行有至少一个主单元,每个第二 类型的服务器组中运行有至少一个备单元;或者,
    每个第一类型的服务器组中运行有至少一个第一功能单元,每个第二类型的服务器组中运行有至少一个第二功能单元,所述第一功能单元和所述第二功能单元组成所述负荷分担模式下功能单元的总体,且所述第一功能单元的数量与所述第二功能单元的数的差值小于预设阈值。
  7. 根据权利要求2所述的方法,其特征在于,在微服务化场景下,所述待升级的群组信息还包括第三群组中的服务器信息,所述方法还包括:
    所述管理节点向所述第三群组中的服务器发送所述版本升级信息,所述版本升级信息用于所述第三群组中的服务器进行版本升级,且所述第一群组、所述第二群组和所述第三群组在升级时一次只升级一个群组的服务器。
  8. 根据权利要求7所述的方法,其特征在于,所述控制节点包含于所述第三群组中。
  9. 根据权利要求1-8任一项所述的方法,其特征在于,所述管理节点接收所述MANO节点发送的待升级的群组信息,包括:
    所述管理节点接收所述MANO节点发送的虚拟网络描述符VNFD文件,所述VNFD文件中包括所述待升级的群组信息。
  10. 一种管理设备,其特征在于,包括:
    处理器、存储器和收发器,其中,所述存储器存储有程序代码,所述处理器调用所述存储器中存储的程序代码,使得所述管理设备执行如权利要求1-9任一项所述的基于网络功能虚拟化的版本升级的方法。
  11. 一种基于网络功能虚拟化的版本升级的系统,其特征在于,包括:管理节点、编排MANO节点、第一群组和第二群组;
    所述管理节点向所述MANO节点发送请求,所述请求用于请求待升级的群组信息;
    所述管理节点接收所述MANO节点发送的待升级的群组信息,所述待升级的群组信息包括第一群组中服务器的信息和第二群组中服务器的信息;
    所述管理节点向所述第一群组中的服务器发送版本升级信息,所述版本升级信息用于指示所述第一群组中的服务器将虚拟化网络功能VNF业务切换到第二群组中的服务器,且还用于所述第一群组中的服务器进行版本升级;
    所述管理节点向所述第二群组中的服务器发送所述版本升级信息,所述版本升级信息用于指示所述第二群组中的服务器将所述VNF业务切换到第一群组中的服务器,且还用于所述第二群组中的服务器进行版本升级。
PCT/CN2020/107532 2019-08-09 2020-08-06 一种基于网络功能虚拟化的版本升级的方法及设备 WO2021027689A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910733775.2 2019-08-09
CN201910733775.2A CN112346755A (zh) 2019-08-09 2019-08-09 一种基于网络功能虚拟化的版本升级的方法及设备

Publications (1)

Publication Number Publication Date
WO2021027689A1 true WO2021027689A1 (zh) 2021-02-18

Family

ID=74367522

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/107532 WO2021027689A1 (zh) 2019-08-09 2020-08-06 一种基于网络功能虚拟化的版本升级的方法及设备

Country Status (2)

Country Link
CN (1) CN112346755A (zh)
WO (1) WO2021027689A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115913940A (zh) * 2021-09-29 2023-04-04 中兴通讯股份有限公司 网络升级方法、电子设备及存储介质
CN116155911A (zh) * 2021-11-23 2023-05-23 华为云计算技术有限公司 一种版本升级方法及装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105681060A (zh) * 2014-11-17 2016-06-15 中兴通讯股份有限公司 一种虚拟化网络功能管理升级方法、装置及服务器
CN106569871A (zh) * 2015-10-12 2017-04-19 中兴通讯股份有限公司 升级处理方法及装置
CN106657173A (zh) * 2015-10-29 2017-05-10 华为技术有限公司 一种nfv架构下软件升级中的业务迁移方法、装置及服务器
CN108319492A (zh) * 2017-01-18 2018-07-24 华为技术有限公司 复位物理机的方法、装置与系统
US20190073235A1 (en) * 2016-04-21 2019-03-07 Nec Corporation Network system, patch file application method, and recording medium

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105681060A (zh) * 2014-11-17 2016-06-15 中兴通讯股份有限公司 一种虚拟化网络功能管理升级方法、装置及服务器
CN106569871A (zh) * 2015-10-12 2017-04-19 中兴通讯股份有限公司 升级处理方法及装置
CN106657173A (zh) * 2015-10-29 2017-05-10 华为技术有限公司 一种nfv架构下软件升级中的业务迁移方法、装置及服务器
US20190073235A1 (en) * 2016-04-21 2019-03-07 Nec Corporation Network system, patch file application method, and recording medium
CN108319492A (zh) * 2017-01-18 2018-07-24 华为技术有限公司 复位物理机的方法、装置与系统

Also Published As

Publication number Publication date
CN112346755A (zh) 2021-02-09

Similar Documents

Publication Publication Date Title
US10789006B1 (en) Path-based data migration from source device to target device
US10936335B2 (en) Path-based migration of control of a multi-path logical device from a current MPIO driver to a target MPIO driver
US20200110552A1 (en) Migrating control of a multi-path logical device from a current mpio driver to a target mpio driver
CN110720091B (zh) 用于与托管的应用/虚拟网络功能(vnf)协调基础设施升级的方法
CN106657173B (zh) 一种nfv架构下软件升级中的业务迁移方法、装置及服务器
WO2019184727A1 (zh) 一种服务升级管理的方法、装置及存储介质
US10050850B2 (en) Rack awareness data storage in a cluster of host computing devices
CN111385114B (zh) Vnf服务实例化方法及装置
US10628273B2 (en) Node system, server apparatus, scaling control method, and program
US11237746B2 (en) Storage system and node management method
CN108628660B (zh) 一种虚拟机扩缩容方法及虚拟管理设备
WO2016206456A1 (zh) 物理机升级方法、业务迁移方法及装置
WO2021027689A1 (zh) 一种基于网络功能虚拟化的版本升级的方法及设备
CN111698112A (zh) 一种容器化虚拟网络功能vnf的资源管理方法及装置
CN110262893B (zh) 配置镜像内存的方法、装置及计算机存储介质
CN115858102A (zh) 一种用于部署支持虚拟化硬件加速的虚拟机的方法
CN112015515B (zh) 一种虚拟网络功能的实例化方法及装置
WO2020224421A1 (zh) 升级方法、装置、系统及存储介质
CN113037654B (zh) 分布式交换机业务板卡虚拟化方法、装置及电子设备
US20230305877A1 (en) Accelerated lifecycle management in hci systems
CN117519908B (zh) 一种虚拟机热迁移方法、计算机设备及介质
US11461026B2 (en) Non-disruptive update of host multipath device dependency
US20240143544A1 (en) Synchronizing host movement to hci satellite nodes
JP7184097B2 (ja) ネットワーク機能仮想化システム及びオペレーティングシステム更新方法
EP3633956B1 (en) Wireless network function virtualization method and device

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20852916

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20852916

Country of ref document: EP

Kind code of ref document: A1