Centralized storage virtual machine evacuation method and system, terminal and medium

Abstract

The invention relates to the field of virtual machine migration, and particularly discloses a centralized storage virtual machine evacuation method and system, a terminal and a medium, and the method comprises the steps: constructing a configuration file containing a volume type name which can be used by each computing node; generating a virtual machine mounted volume list on the fault computing node; obtaining a volume type name of each mounted volume according to the mounted volume list, and generating a volume type name list; comparing each volume type name in the volume type name list with a volume type name which can be used by each computing node in the configuration file, if the computing node supports all volume type names in the volume type name list, taking the computing node as an optional computing node, and further generating an optional computing node list of the virtual machine; and screening one computing node from the selectable computing node list as a target computing node, and migrating the virtual machine to the target computing node. According to the method, rapid evacuation of the virtual machines under a relatively large cluster scale is realized, and the timeliness requirement of evacuation is met.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of virtual machine migration, in particular to a centralized storage virtual machine evacuation method and system, a terminal and a medium. BACKGROUND

[0002] OpenStack is an open source cloud management platform software widely used in private cloud scenarios. By using OpenStack to manage the computing resources of public clouds and private clouds, services such as virtual machines, virtual disks, and virtual VPCs can be provided, which can provide resource utilization of data centers and reduce management costs of data centers.

[0003] Evacuation in Nova service of OpenStack refers to a kind of emergency measure to quickly transfer all virtual machines on a computing node to other healthy computing nodes when the computing node fails. Its main functions are as follows: ensure service continuity, when a computing node is unreachable or has a serious failure, evacuation operation can quickly migrate virtual machines on these nodes to other normally running nodes, so as to ensure that the business or service carried by the virtual machine can continue to run, and will not be interrupted due to the failure of a single node. Guarantee data integrity: during the evacuation process, Nova service will ensure the data integrity and consistency of virtual machines, that is, after migration is completed, virtual machines can continue to run normally, and there will be no data loss or damage. Improve system reliability: evacuation operation is part of the automatic fault recovery mechanism of OpenStack cloud platform, through automatic detection and response to node failure, OpenStack can ensure the reliability and stability of the entire cloud platform, help to reduce the business risk caused by node failure, and improve the trust and satisfaction of users to the cloud platform. Support flexible resource management: evacuation operation can not only be automatically triggered when a failure occurs, but also be manually executed by administrators, providing a flexible resource management method, allowing administrators to migrate and optimize resource usage according to actual needs.

[0004] However, the open source implementation of the evacuation function in the current Nova still has problems, and a common problem is that for the scene of mixed use of multiple storage types, the computing node has the probability of using only a certain type of storage device, and the Nova level cannot identify the access relationship between the storage and the computing node, thereby causing the failure of the evacuation action, which will affect the user's SLA (Service-Level Agreement) and increase the burden of operation and maintenance. In related technologies, when performing evacuation, the storage detection mechanism is used to detect the computing node through PING, Telent, SSH and other network protocols to select a suitable computing node to avoid evacuation action failure. However, when the cluster size is small, this method can realize real-time evaluation of the availability of the computing node and selection of the available computing node, and when the size of the computing node is large, the timeliness cannot meet the service SLA requirement, which affects the evacuation efficiency. SUMMARY

[0005] To solve the above problems, the present application provides a centralized storage virtual machine evacuation method, system, terminal and medium, which realizes fast virtual machine evacuation under large cluster size, meets the timeliness requirement of evacuation, and improves the evacuation efficiency.

[0006] In a first aspect, the technical solution of the present application provides a centralized storage virtual machine evacuation method, comprising the following steps: A configuration file of the connection relationship between the computing node and the storage is constructed, and the configuration file contains the volume type name that each computing node can use; All the mounting volume information of each virtual machine on the failed computing node is obtained, and a virtual machine mounting volume list is generated; According to the mounting volume list, the volume type name of each mounting volume is obtained, and a volume type name list is generated; Each volume type name in the volume type name list is compared with the volume type name that each computing node can use in the configuration file, if the computing node supports all the volume type names in the volume type name list, the computing node is selected as a selectable computing node, and then a selectable computing node list of the virtual machine is generated; A computing node is selected from the selectable computing node list as a target computing node, and the virtual machine is migrated to the target computing node.

[0007] In an optional embodiment, the configuration file of the connection relationship between the computing node and the storage is constructed, specifically including: All the volume type names and the Attachment information of all the mounting volumes in the environment are obtained to construct a third dictionary with the volume type name as the key and the linked list as the value; the linked list contains all the Attachment information adapted to the volume type name; Traverse all compute nodes, according to the third dictionary, detect whether the compute node meets all Attachment information of a certain volume type name, if yes, record the volume type name as the volume type name that the compute node can use to the configuration file.

[0008] In an optional implementation, a third dictionary with volume type name as key and linked list as value is constructed, specifically including: Find all volume type information in the environment through the volume type API provided by Cinder, and construct a first dictionary with volume type UUID as key and volume type information as value based thereon, wherein the volume type information includes volume type name; Get all mounted volume information in the environment through the full volume list interface provided by Cinder, and construct a second dictionary with volume ID as key and volume information as value based thereon, wherein the volume information includes corresponding volume type UUID; Get all mounted volume Attachment information through the full Attachment information interface provided by Cinder; Construct a third dictionary with volume type name as key and linked list as value, and initialize it as an empty dictionary; Traverse the Attachment information, find the volume type ID through the volume ID recorded in the Attachment information according to the second dictionary, and then find the volume type name through the first dictionary; Detect whether the third dictionary has the volume type name currently found; If not, record the volume type name currently found and the corresponding Attachment information in the third dictionary; If yes, compare whether the same Attachment information as the current Attachment information exists in the linked list of the same volume type name in the third dictionary, if exists, discard the current Attachment information, if not, record the current Attachment information in the third dictionary.

[0009] In an optional implementation, comparing whether the same Attachment information as the current Attachment information exists in the linked list of the same volume type name in the third dictionary specifically includes: For the volume type name of RBD driver type, compare whether the host address, user name and port number in the two Attachment information are the same, if the same, the two Attachment information are the same; For the volume type name of iSCSI type, compare whether the host address and port number in the two Attachment information are the same, if the same, the two Attachment information are the same; For the volume type name of the FC type, compare the target global port names in the two Attachment information, if same, the two Attachment information are same.

[0010] In an optional embodiment, the configuration file further includes the access network address of the computing node, the non-virtual network card address, and the WWPN information of the local HBA card. According to the access network address, the non-virtual network card address, and the WWPN information of the local HBA card in the configuration file, it is detected whether the computing node meets all the Attachment information of a certain volume type name.

[0011] In an optional embodiment, a computing node is selected from the optional computing node list as a target computing node, specifically including: Obtaining the Flavor information of the cloud server; Obtaining the Aggregate information in full through the host aggregation interface provided by Nova; Comparing the metadata of the Aggregate information with the Flavor information to identify the associated Aggregate information; Selecting the available computing nodes from the optional computing node list through the associated Aggregate information to generate an available computing node list; Excluding the computing nodes in the “deactivated” state in the available computing node list to generate an updated available computing node list; Selecting a computing node from the updated available computing node list as a target computing node.

[0012] In an optional embodiment, before migrating the virtual machine to the target computing node, the following steps are further included: Disabling the computing nodes that can be scheduled at the Nova level but do not meet the conditions for running the virtual machine to be migrated; After migrating the virtual machine to the target computing node, the following steps are further included: Restarting the disabled computing nodes.

[0013] In a second aspect, the technical scheme of the present application provides a centralized storage virtual machine evacuation system, comprising: A configuration file construction module for constructing a configuration file of the connection relationship between the computing nodes and the storage, wherein the configuration file contains the volume type name available for each computing node; A mounted volume list generation module for obtaining all the mounted volume information of each virtual machine on the faulty computing node to generate a virtual machine mounted volume list; The volume type name list generation module is configured to generate a volume type name list according to the mounting volume list and the volume type names of each mounting volume in the mounting volume list. The optional computing node list generation module is configured to compare each volume type name in the volume type name list with the volume type names that can be used by each computing node in the configuration file, and if the computing node supports all the volume type names in the volume type name list, the computing node is regarded as an optional computing node, and then an optional computing node list of the virtual machine is generated. The virtual machine migration module is configured to select a computing node from the optional computing node list as a target computing node, and migrate the virtual machine to the target computing node.

[0014] In a third aspect, the present application provides a terminal, comprising: The memory is configured to store a centralized virtual machine evacuation program. The processor is configured to execute the centralized virtual machine evacuation program to implement the steps of the centralized virtual machine evacuation method according to any one of the above.

[0015] In a fourth aspect, the present application provides a computer readable storage medium, wherein the readable storage medium stores a centralized virtual machine evacuation program, and the centralized virtual machine evacuation program is executed by a processor to implement the steps of the centralized virtual machine evacuation method according to any one of the above.

[0016] As can be seen from the above technical solutions, the present application has the following advantages: a configuration file is constructed, the volume type names that can be used by each computing node are set in the configuration file, the volume type names of the mounting volumes of each virtual machine on the failed computing node are obtained, then optional computing nodes are selected by comparing whether the computing node supports all the volume types of the virtual machine, and finally the virtual machine is successfully migrated. The present application can improve the evacuation success rate and efficiency in a mixed scenario of multiple storage types by constructing a configuration file of the connection relationship between the computing node and the storage and selecting optional computing nodes based on volume type name matching, and by pre-recording the volume type names that can be used by each computing node, the performance bottleneck of the traditional network detection method in a large-scale cluster is avoided, the access relationship between the computing node and the storage can be quickly and accurately identified, the virtual machine can be migrated to a target node that supports all the mounting volume types of the virtual machine, and the problem of evacuation failure caused by storage compatibility in the Nova open source implementation is effectively solved. At the same time, the method reduces the dependence on real-time network detection, greatly shortens the fault response time, meets the service SLA requirements, reduces the operation and maintenance cost, and thus improves the reliability and user satisfaction of the entire cloud platform. BRIEF DESCRIPTION OF DRAWINGS

[0017] In order to more clearly illustrate the technical solutions of the present application, the drawings required to be used in the description will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0018] Figure 1 A centralized storage virtual machine evacuation method flowchart is provided for the embodiments of the present application.

[0019] Figure 2 A flowchart for constructing a third dictionary with a volume type name as a key and a linked list as a value is provided for the embodiments of the present application.

[0020] Figure 3 A centralized storage virtual machine evacuation system structure schematic diagram is provided for the embodiments of the present application.

[0021] Figure 4 A terminal structure schematic diagram is provided for the embodiments of the present application. DETAILED DESCRIPTION

[0022] In order to make the application purposes, features and advantages of the present application more obvious and easy to understand, the technical solutions protected by the present application will be described clearly and completely by using specific embodiments and drawings. Obviously, the following described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0023] Unless otherwise defined, all technical and scientific terms used in the present application have the same meanings as those commonly understood by those skilled in the art to which the present application belongs. The terms used in the specification of the present application are only for the purpose of describing specific embodiments and are not intended to limit the present application.

[0024] The key terms appearing in the present application will be explained as follows.

[0025] Cinder: Cinder is a block storage service component in the OpenStack open source cloud computing platform. It is responsible for managing storage volumes, including volume creation, deletion, mounting, unmounting and other operations. Users can create persistent storage volumes through Cinder and mount them to virtual machines to provide data storage functions for virtual machines. Cinder supports multiple back-end storage, such as Ceph, LVM, etc., which can be configured for use according to different needs.

[0026] Attachment information: refers to the connection information generated when a volume is mounted to a virtual machine or a compute node. These information records the connection details between the volume and the compute node, such as the protocol used for connection (such as RBD, iSCSI, FC, etc.), related parameters (such as hosts host address, Port port number, target_wwn target global port name, etc.), which are used to determine the support of the compute node for the mounted volume in subsequent operations, and to determine the compatibility of the connection in the virtual machine evacuation scenario.

[0027] Aggregate information: Aggregate (host aggregation) is a collection of a group of compute nodes in OpenStack. Aggregate information contains the relevant attributes and policy settings of this group of compute nodes. For example, specific resource tags, shared hardware features (such as high IO performance, etc.), and other custom metadata can be set. By managing Aggregate information, the grouping management of compute node resources can be realized, and in virtual machine scheduling and other operations, the compute nodes that meet the conditions can be selected according to the characteristics of Aggregate.

[0028] Flavor: Flavor (specification) defines the resource configuration specification of a cloud server (virtual machine). It contains the CPU core number, memory size, disk capacity and other information of the virtual machine, and is the basis for specifying the resource quota when creating a virtual machine. Different Flavors correspond to different resource configurations, and users can select appropriate Flavors to create virtual machines according to business needs.

[0029] Nova: Nova is a computing service component in OpenStack, and is one of the core components of OpenStack cloud platform. It is responsible for managing and controlling computing resources, including creating, starting, stopping, deleting, migrating and other operations of virtual machine instances. Nova can work with other OpenStack components (such as Cinder, Neutron, etc.) to realize efficient management and scheduling of computing resources in the entire cloud computing environment, and provide flexible computing services for users.

[0030] Figure 1 A centralized storage virtual machine evacuation method flowchart is provided for the embodiments of the present application. Among them, Figure 1 The execution subject can be a centralized storage virtual machine evacuation system. The centralized storage virtual machine evacuation method provided by the embodiments of the present application is executed by a computer device, and accordingly, the centralized storage virtual machine evacuation system runs in the computer device. According to different needs, the order of steps in the flowchart can be changed, and some can be omitted.

[0031] As Figure 1 shown, the method comprises the following steps.

[0032] S1, constructing a configuration file of the connection relationship between the computing nodes and the storage, wherein the configuration file contains a volume type name that can be used by each computing node.

[0033] This step constructs a storage connection configuration file, pre-records a volume type name that can be supported by each computing node, establishes a mapping relationship between the computing node and the storage type, and subsequently finds a selectable computing node for each virtual machine to be migrated according to the matching of the volume type name, thereby avoiding real-time detection overhead.

[0034] In some optional embodiments, the configuration file further contains an access network address, a non-virtual network card address, and WWPN information of a local HBA card. For example, the configuration file has the following format: [ { "addr":"a.b.c.d", "addrs":[ { "eth0":"a0.b0.c0.d0" }, { "eth1":"a1.b1.c1.d1" } ], "initiators":[ "wwpn0", "wwpn1" ], "nodename":"compute1", "volume_services":[ "service1" "service2" ] } ] The addr records the main access network address of the computing node, the addrs records the address of the non-virtual network port of the computing node, the initiators record the WWPN information of the local HBA card of the computing node, the volume_services record the name of the volume type that can be used by the computing node, and the nodename corresponds to the host name of the computing node.

[0035] To implement the construction of the configuration file, the volume type name that can be used by each computing node needs to be known, and the specific steps include the following.

[0036] S11, all volume type names in the environment and all Attachment information of mounted volumes are acquired to build a third dictionary with volume type name as key and linked list as value.

[0037] The linked list contains all Attachment information adapted to the volume type name.

[0038] In some optional embodiments, as shown in Figure 2 The third dictionary with volume type name as key and linked list as value is built, specifically including the following steps.

[0039] S111, all volume type information in the environment is found through the volume type API provided by Cinder, and a first dictionary with volume type UUID as key and volume type information as value is constructed, wherein the volume type information includes volume type name.

[0040] In the Cinder component of OpenStack, the volume type (VolumeType) is an abstraction classification of storage strategies and other attributes, such as SSD type volume and HDD type volume. All volume type information in the OpenStack cloud computing environment is acquired to construct a dictionary with volume type UUID as key and volume type information as value. Subsequently, the corresponding volume type information can be quickly located based on the dictionary through the UUID of the volume. Specifically, the volume type name is located.

[0041] S112, all mounted volume information in the environment is acquired through the full volume list interface provided by Cinder, and a second dictionary with volume ID as key and volume information as value is constructed, wherein the volume information includes the corresponding volume type UUID.

[0042] S113, all Attachment information of mounted volumes in the environment is acquired through the full Attachment information interface provided by Cinder.

[0043] S114, a third dictionary with volume type name as key and linked list as value is constructed and initialized as an empty dictionary.

[0044] S115, the Attachment information is traversed, the volume type ID is found according to the second dictionary through the volume ID recorded in the Attachment information, and then the volume type name is found through the first dictionary.

[0045] S116, whether the third dictionary has the volume type name found currently is detected.

[0046] S117, if not, the volume type name found currently and the corresponding Attachment information are recorded in the third dictionary.

[0047] S118, if yes, compare whether there is the same Attachment information as the current Attachment information in the chain list of the same volume type name in the third dictionary, if yes, discard the current Attachment information, if not, record the current Attachment information to the third dictionary.

[0048] After obtaining the Attachment information of all mounted volumes, traverse the Attachment information, find the volume type ID through the UUID of the volume recorded in the Attachment, and find the volume type name through the first dictionary, find according to the volume type in the third dictionary, and compare with the recorded Attachment, and determine whether to record the Attachment information to the third dictionary according to the comparison result.

[0049] Specifically, when the third dictionary is constructed in advance, it is initialized as an empty dictionary. Before traversing the Attachment information, some basic information has been obtained through the Cinder API. For example, the volume type information is queried through the Cinder API, and a {volume type UUID: volume type information} dictionary is constructed, which may contain volume type names and the like. At the same time, the information of all mounted volumes is obtained through the Cinder API, and a {volume ID: volume information} dictionary is constructed, from which the UUID of the volume and other contents can be obtained. When traversing the Attachment information, the third dictionary is gradually filled. Through the UUID of the volume recorded in the Attachment, the volume type ID is first found, and then the volume type name is found by using the {volume type UUID: volume type information} dictionary constructed in the foregoing. At this time, if there is no key-value pair corresponding to the volume type name in the third dictionary, an empty chain list can be created as a value and added; if it already exists, the Attachment that meets the condition (i.e., different from the recorded Attachment) can be added to the corresponding chain list according to the comparison rule (such as RBD drive type comparison hosts, user name and Port), so as to realize the gradual construction and update of the third dictionary.

[0050] It should be noted that in the third dictionary, one volume type name can correspond to multiple Attachment information. This is because in the actual storage environment of OpenStack, the same type of volume (such as SSD volume type) can be provided by multiple different storage devices or storage instances. The connection information (i.e. Attachment information) of each storage device and the computing node will be different, such as different storage server IP addresses (hosts), ports (Port), or different fiber channel port identifiers (target_wwn), etc. For example, there are multiple different iSCSI storage servers providing storage services for SSD volume type, and their respective hosts and Port information are different. These different connection information will be recorded as different Attachment information in the linked list corresponding to the volume type name. Even if the same type of storage device provides the same type of volume, due to network topology, configuration requirements and other factors, there can be multiple connection methods. For example, under the RBD drive type, in order to achieve load balancing or redundant backup, different user names, host addresses and port combinations will be configured to connect the storage. The Attachment information of these different connection methods needs to be recorded in order to comprehensively judge the connection compatibility of the computing node and the volume type. Therefore, the M3 dictionary is designed to have a linked list as a value, which is used to accommodate multiple different Attachment information under the same volume type.

[0051] In some optional embodiments, the comparison of whether the same Attachment information exists in the linked list of the same volume type name in the third dictionary includes: for the volume type name of the RBD drive type, comparing whether the host address, user name and port number in the two Attachment information are the same, if the same, then the two Attachment information are the same; for the volume type name of the iSCSI type, comparing whether the host address and port number in the two Attachment information are the same, if the same, then the two Attachment information are the same; for the volume type name of the FC type, comparing whether the target global port name in the two Attachment information is the same, if the same, then the two Attachment information are the same.

[0052] Specifically, the comparison of whether the Attachment information is the same is realized by the following comparison method.

[0053] RBD drive type: RBD (RADOS Block Device) is a block device interface provided by the Ceph storage system. For RBD type volumes, the hosts (host address, i.e. the host where the storage service is located), username (authentication user for accessing storage) and Port (port number, used for network communication) need to be compared. If the contents in the Attachment information traversed are different from the contents recorded in the third dictionary corresponding to the volume type, this Attachment is added to the linked list corresponding to the volume type in the third dictionary.

[0054] iSCSI type: iSCSI (Internet Small Computer System Interface) is a storage protocol based on IP network. For iSCSI type volumes, compare hosts (IP address of the storage server) and Port (port number) information. If there is a difference, the Attachment is also added to the corresponding linked list in the third dictionary.

[0055] FC type: FC (Fibre Channel) is a high-speed network technology commonly used to connect servers and storage devices. For FC type volumes, compare target_wwn (target global port name, used to uniquely identify the storage device port in the FC network). If they are not consistent, add the Attachment to the linked list in the third dictionary.

[0056] S12, traverse all computing nodes, and according to the third dictionary, detect whether the computing node meets all Attachment information of a certain volume type name. If so, record the volume type name as a volume type name that the computing node can use in the configuration file.

[0057] Traverse all computing nodes and all volume types. In the discrimination process, each type of Attachment corresponding to the volume type is discriminated. If all Attachments meet the requirements, the volume type is recorded in volume_services. If one of the Attachments does not meet the requirements, the process is exited early, indicating that the computing node does not support this volume type.

[0058] Specifically, according to the access network address, non-virtual network card address, and local HBA card WWPN information in the configuration file, detect whether the computing node meets all Attachment information of a certain volume type name. Specifically, the following steps are included.

[0059] S121, RBD drive type judgment.

[0060] Traverse the RBD type Attachment information in attachment_list.

[0061] For each Attachment, compare its hosts, user name and Port with the corresponding network connection information in the compute node configuration (such as the IP address of the compute node used to access the storage can be used as the basis for hosts comparison). If the configuration information of the compute node can match the information in the Attachment (such as the hosts are within the accessible range, the user name is correct, the port is open and matches), it means that the compute node has compatibility with the mount of this volume type in terms of RBD connection; if it does not match, there is a compatibility problem.

[0062] S122, iSCSI type judgment.

[0063] The Attachment information of the iSCSI type in the attachment_list is also traversed.

[0064] For each Attachment, compare its hosts (storage server IP address) and Port with the network address and port information in the compute node configuration. If the compute node can access the hosts address and port in the Attachment through its own network configuration, it has compatibility; otherwise, there is a problem.

[0065] S123, FC type judgment.

[0066] The Attachment information of the FC type in the attachment_list is traversed.

[0067] The WWPN of the compute node HBA card is compared with the target_wwn in the Attachment. If the WWPN of the compute node is within the range that the storage device can recognize (i.e. it can establish an effective connection with target_wwn), it means that it has compatibility in FC connection; otherwise, there is a compatibility problem.

[0068] If all the relevant Attachment information is traversed, the compute node is compatible with the Attachment information in all connection types (RBD, iSCSI, FC, etc.) of the volume type, then it can be judged that the compute node supports the mount of the specific volume type; as long as there is an incompatible situation in a certain connection type, it means that the compute node does not support the mount of the volume type, or there is a connection compatibility problem.

[0069] S2, obtain all the mount volume information of each virtual machine on the failed compute node, and generate a virtual machine mount volume list.

[0070] This step obtains the mount volume list of the failed node, identifies the mount volume information of all virtual machines on the failed compute node, and clearly identifies the storage resources that need to be migrated.

[0071] S3, according to the mounting volume list, obtaining the volume type name of each mounting volume, generating a volume type name list.

[0072] This step extracts the volume type list, parses the corresponding volume type name from the mounting volume information, and determines the storage type support required for migration.

[0073] S4, compare each volume type name in the volume type name list with the volume type name that each computing node in the configuration file can use. If the computing node supports all the volume type names in the volume type name list, the computing node is selected as the optional computing node, and then the optional computing node list of the virtual machine is generated.

[0074] This step screens the optional computing nodes, quickly matches the computing nodes supporting all volume types through the configuration file, generates a candidate node list, and solves the performance bottleneck of the traditional detection method.

[0075] S5, select one computing node from the optional computing node list as the target computing node, and migrate the virtual machine to the target computing node.

[0076] This step performs virtual machine migration, selects the target node from the candidate list, completes the migration of the virtual machine and the mounting volume, and ensures storage compatibility and service continuity.

[0077] In some optional embodiments, when performing evacuation, the metadata recorded in the Flavor is obtained through the Flavor information of the cloud server, the properties starting with hw: are excluded because these properties are irrelevant to the scheduling of the virtual machine, the Aggregate information is obtained through the host aggregation (Aggregate) interface provided by Nova, and the Aggregate metadata and the Flavor information are compared to identify the Aggregate list information corresponding to the Flavor, and the computing node information recorded in the Aggregate is used to construct a list of available computing nodes. Through the interface of the Nova computing node service, the state of the computing node service is obtained, and the computing node in Down state is excluded from the list. It is noted that the computing node list is the full set of computing nodes that can be scheduled by all Nova services and is a subset of the full set of computing nodes, so it is avoided to operate on the full set of computing nodes.

[0078] Specifically, selecting one computing node from the optional computing node list as the target computing node specifically includes the following steps.

[0079] S51, obtain the Flavor information of the cloud server.

[0080] Flavor defines the specifications of cloud server (virtual machine), such as CPU, memory, disk size and other resource configurations. The properties starting with hw: are usually related to the hardware of the virtual machine and are mostly the settings of the underlying hardware, and have little relevance to the scheduling of virtual machines among computing nodes. Excluding these properties from the Flavor can reduce interference information and focus on key scheduling factors when filtering computing nodes later.

[0081] S52, obtain Aggregate information in full through the host aggregation interface provided by Nova.

[0082] Aggregate is a collection of computing nodes in OpenStack, and specific properties and policies can be set for it, such as shared hardware resource characteristics. By obtaining all Aggregate information through Nova API, the situation of these computing node collections in the entire OpenStack environment can be mastered.

[0083] S53, compare the metadata of Aggregate information with Flavor information to identify the associated Aggregate information.

[0084] Compare the metadata of Aggregate (such as set resource tags, characteristics, etc.) with Flavor information (virtual machine specification requirements) to filter out Aggregate whose resource characteristics meet the virtual machine specification requirements. For example, if the Flavor requires high IO performance, filter out Aggregate with high IO related properties.

[0085] S54, filter out available computing nodes from the list of selectable computing nodes through the associated Aggregate information to generate a list of available computing nodes.

[0086] Extract the list of computing nodes contained in the filtered associated Aggregate to preliminarily determine the range of computing nodes that meet the resource requirements of the virtual machine.

[0087] S55, exclude computing nodes in the "disabled" state from the list of available computing nodes to generate an updated list of available computing nodes.

[0088] S56, filter a computing node from the updated list of available computing nodes as the target computing node.

[0089] Computing nodes may be in a Down state due to hardware failure, software problems, etc., and cannot normally run virtual machines. Check the service state of the computing node through Nova API, and exclude nodes in the Down state from the list of computing nodes obtained earlier to ensure that the final list of computing nodes is currently available for service, which can be used for subsequent virtual machine scheduling and evacuation operations.

[0090] In some optional embodiments, before migrating the virtual machine to the target computing node, the following step is further included: disabling the computing nodes that can be scheduled at the Nova level but do not meet the condition of running the virtual machine to be migrated. Further, after migrating the virtual machine to the target computing node, the disabled computing nodes are restarted.

[0091] This is because for those computing nodes that can be scheduled at the Nova level (i.e., Nova considers that the node can be used to allocate resources), but actually do not meet the condition of running the virtual machine to be evacuated (such as not supporting the required volume type of the virtual machine), their services are disabled through the computing node service API provided by Nova, which can prevent the system from incorrectly scheduling the virtual machine to these unavailable computing nodes during the virtual machine scheduling process, thereby improving the success rate of evacuation.

[0092] Specifically, when evacuating the virtual machines of the faulty node, first, the virtual machine list running on the faulty computing node is screened through the virtual machine details interface provided by Nova, and the evacuation of a single virtual machine is performed by traversing the virtual machine list. The volume information mounted by the virtual machine to be evacuated is obtained, the list of volumes mounted by the virtual machine is obtained, the list of volume types of the volumes is obtained through the list of mounted volumes, the list of selectable computing nodes is traversed, and the cached volume_services list corresponding to the computing nodes is compared with the list of all used volume type names of the cloud server to be evacuated. The computing nodes that do not meet the condition are excluded, and the computing nodes that do not meet the condition of running the virtual machine to be evacuated but can be scheduled at the Nova level are disabled through the computing node service API provided by Nova, so as to avoid these computing nodes being incorrectly selected during virtual machine scheduling, thereby realizing the exclusion of the computing nodes that can be scheduled at the OpenStack level but cannot be used by the virtual machine, and thereby guaranteeing the success rate of evacuating the virtual machine. After the evacuation of the virtual machine is completed, the computing nodes that were actively disabled in the foregoing are re-enabled through the Nova interface, and the evacuation of the next virtual machine to be evacuated is continued. Among them, the volume types supported by the computing node must completely contain all the volume types used by the cloud server to be evacuated, and the computing node meets the condition and can run the cloud server to be evacuated migrated to the computing node.

[0093] In some optional embodiments, for a hybrid architecture server environment, there are scenarios in which multiple architecture servers are mixed in the same host aggregation, in order to avoid scheduling errors without architecture selection, first, the architecture information of the failed compute node is obtained through the Hypervisor details interface provided by Nova, and then in the process of traversing the virtual machines to be evacuated, the list of compute nodes that the virtual machine can use is obtained through the foregoing steps, the architecture of the compute node is obtained by traversing the compute node information, if the architecture is different from that of the compute node where the virtual machine is currently located, the compute node is disabled and recorded through the interface provided by Nova, and after the evacuation of all virtual machines to be evacuated is completed, the recorded compute node is re-enabled.

[0094] In the foregoing detailed description of the embodiment of the centralized storage virtual machine evacuation method, based on the centralized storage virtual machine evacuation method described in the foregoing embodiment, the embodiment of the application further provides a centralized storage virtual machine evacuation system corresponding to the method.

[0095] Figure 3 A centralized storage virtual machine evacuation system structure schematic block diagram is provided in the embodiment of the application, in the embodiment, the centralized storage virtual machine evacuation system 300 can be divided into multiple functional modules according to the functions performed by the centralized storage virtual machine evacuation system 300. The module referred to in the application refers to a series of computer program segments that can be executed by at least one processor and can complete a fixed function, and the module is stored in a memory.

[0096] The configuration file construction module 310 is configured to construct a configuration file of the connection relationship between the compute nodes and the storage, and the configuration file contains the volume type name that can be used by each compute node.

[0097] The mounted volume list generation module 320 is configured to obtain all mounted volume information of each virtual machine on the failed compute node, and generate a virtual machine mounted volume list.

[0098] The volume type name list generation module 330 is configured to obtain the volume type name of each mounted volume in the mounted volume list according to the mounted volume list, and generate a volume type name list.

[0099] The optional compute node list generation module 340 is configured to compare each volume type name in the volume type name list with the volume type name that can be used by each compute node in the configuration file, if the compute node supports all volume type names in the volume type name list, the compute node is taken as an optional compute node, and then an optional compute node list of the virtual machine is generated.

[0100] The virtual machine migration module 350 is configured to select a compute node as a target compute node from the optional compute node list, and migrate the virtual machine to the target compute node.

[0101] The centralized storage virtual machine evacuation system of the embodiment is used to implement the foregoing centralized storage virtual machine evacuation method, and therefore the specific implementation of the system can be seen from the foregoing embodiment part of the centralized storage virtual machine evacuation method, and therefore the specific implementation can be referred to the description of the corresponding embodiment part, and will not be introduced here.

[0102] In addition, since the centralized storage virtual machine evacuation system of the embodiment is used to implement the foregoing centralized storage virtual machine evacuation method, the role thereof corresponds to the role of the foregoing method, and will not be described here.

[0103] Figure 4 A structure schematic diagram of a terminal 400 provided by the embodiment of the application includes a processor 410, a memory 420, and a communication unit 430. The processor 410 is used to implement the flow steps of the foregoing centralized storage virtual machine evacuation method embodiment when implementing the centralized storage virtual machine evacuation program stored in the memory 420.

[0104] The terminal 400 includes the processor 410, the memory 420, and the communication unit 430. These components communicate through one or more buses, and those skilled in the art can understand that the structure of the server shown in the figure does not constitute a limitation to the application, and it can be a bus structure or a star structure, and can include more or fewer components than shown in the figure, or combine some components, or different component arrangements.

[0105] The memory 420 can be used to store the execution instructions of the processor 410, and the memory 420 can be implemented by any type of volatile or non-volatile storage terminal or a combination thereof, such as a static random access memory (SRAM), an electrically erasable programmable read-only memory (EEPROM), an erasable programmable read-only memory (EPROM), a programmable read-only memory (PROM), a read-only memory (ROM), a magnetic storage, a flash memory, a magnetic disk, or an optical disk. When the execution instructions in the memory 420 are executed by the processor 410, the terminal 400 can execute part or all of the steps in the foregoing method embodiment.

[0106] The processor 410 is a control center of the storage terminal, connects various parts of the electronic terminal by using various interfaces and lines, executes various functions of the electronic terminal and / or processes data by running or executing software programs and / or modules stored in the memory 420 and calling data stored in the memory. The processor can be composed of an integrated circuit (IC), for example, can be composed of a single packaged IC, or can be composed of multiple packaged ICs connected together. For example, the processor 410 can only include a central processing unit (CPU). In the embodiments of the present application, the CPU can be a single operation core or can include multiple operation cores.

[0107] The communication unit 430 is configured to establish a communication channel, so that the storage terminal can communicate with other terminals. The communication unit 430 receives user data sent by other terminals or sends user data to other terminals.

[0108] The present application also provides a computer storage medium, wherein the storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM).

[0109] The present application also provides a computer storage medium, wherein the storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM).

[0110] The computer storage medium stores the centralized storage virtual machine evacuation program, and the centralized storage virtual machine evacuation program is executed by the processor to realize the process steps of the centralized storage virtual machine evacuation method.

[0111] Those skilled in the art can clearly understand that the technical solutions in the embodiments of the present application can be implemented by means of software plus necessary universal hardware platforms. Based on such an understanding, the technical solutions in the embodiments of the present application can be embodied in the form of a software product, which can be stored in a storage medium, such as a USB flash disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and the like, and includes a plurality of instructions for causing a computer terminal (which can be a personal computer, a server, or a second terminal, a network terminal, or the like) to execute all or part of the steps of the methods described in the embodiments of the present application.

[0112] In several embodiments provided by the present application, it should be understood that the disclosed system, device and method can be implemented in other manners. For example, the described device embodiments are merely schematic. For example, the division of the units is only a logical function division. There can be another division manner for the actual implementation, for example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections between the units can be indirect couplings or communication connections through some interfaces, devices or units, and can be electrical, mechanical or in other forms.

[0113] The units described as separated components can or can not be physically separated, and the components displayed as units can or can not be physical units, i.e., can be located in one place, or can be distributed on multiple network units. In actual implementation, some or all of the units can be selected according to the actual needs to achieve the purposes of the embodiments of the present application.

[0114] In addition, each function unit in the embodiments of the present application can be integrated in a processing unit, or each unit can exist physically as a separate unit, or two or more units can be integrated in one unit.

[0115] The above description of the disclosed embodiments enables a person skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined in the present application can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown in the present application, but will conform to the widest scope consistent with the principles and novel features disclosed in the present application.

Claims

1. A centralized storage virtual machine evacuation method, characterized in that: The following steps are involved: Constructing a configuration file for the connection between computing nodes and storage, wherein the configuration file includes the name of the volume type that each computing node can use; Obtain all mounted volume information for each virtual machine on the failed computing node and generate a list of virtual machine mounted volumes; According to the mounted volume list, obtain the volume type name of each mounted volume and generate a volume type name list; Compare each volume type name in the volume type name list with the volume type names that can be used by each compute node in the configuration file. If a compute node supports all volume type names in the volume type name list, then the compute node is selected as an optional compute node, thereby generating an optional compute node list for the virtual machine. Select a compute node from the available compute node list as the target compute node and migrate the virtual machine to the target compute node.

2. The centralized storage virtual machine evacuation method according to claim 1, characterized in that: Build a configuration file for the connection between compute nodes and storage, including: Obtain all volume type names and attachment information of all mounted volumes in the environment, and construct a third dictionary with the volume type name as the key and a linked list as the value; the linked list contains all attachment information that matches the volume type name; Traverse all computing nodes and detect whether the computing nodes meet all the attachment information of a certain volume type name according to the third dictionary. If so, record the volume type name as a volume type name that the computing node can use in the configuration file.

3. The centralized storage virtual machine evacuation method according to claim 2, characterized in that: Construct a third dictionary with the volume type name as the key and the linked list as the value, specifically including: Use the volume type API provided by Cinder to find all volume type information in the environment, and use it to construct a first dictionary with the volume type UUID as the key and the volume type information as the value, where the volume type information includes the volume type name; Use the full volume list interface provided by Cinder to obtain the information of all mounted volumes in the environment, and use this to construct a second dictionary with the volume ID as the key and the volume information as the value, where the volume information includes the corresponding volume type UUID; Obtain the attachment information of all mounted volumes in the environment through the full attachment information interface provided by Cinder; Construct a third dictionary with the volume type name as the key and the linked list as the value, and initialize it to an empty dictionary; Traverse the Attachment information, use the volume ID recorded in the Attachment information to find the volume type ID according to the second dictionary, and then use the first dictionary to find the volume type name; Check whether the volume type name currently found exists in the third dictionary; If not, record the currently found volume type name and corresponding Attachment information into the third dictionary; If so, compare whether there is Attachment information identical to the current Attachment information in the linked list of the same volume type name in the third dictionary. If so, discard the current Attachment information. If not, record the current Attachment information in the third dictionary.

4. The centralized storage virtual machine evacuation method according to claim 3, characterized in that: Compare the linked list of the same volume type name in the third dictionary to see if there is attachment information identical to the current attachment information, specifically including: For the volume type name of the RBD driver type, compare the host address, user name, and port number in the two attachment information to see if they are the same. If they are the same, the two attachment information are the same; For iSCSI volume type names, compare the host addresses and port numbers in the two attachment information to see if they are the same. If they are, the two attachment information are identical. For FC volume type names, the target global port names in the two attachment information are compared to see if they are the same. If they are the same, the two attachment information are the same.

5. The centralized storage virtual machine evacuation method according to claim 2, characterized in that: The configuration file also includes the computing node's access network address, non-virtual network card address, and local HBA card WWPN information; Based on the access network address, non-virtual network card address, and WWPN information of the local HBA card in the configuration file, the compute node is checked to see whether it meets all the attachment information of a certain volume type name.

6. The centralized storage virtual machine evacuation method according to any one of claims 1 to 5, characterized in that: Select a compute node from the list of available compute nodes as the target compute node, including: Get the flavor information of the cloud server; Obtain full Aggregate information through the host aggregation interface provided by Nova; Compare the metadata of the Aggregate information with the Flavor information to identify the related Aggregate information; Filter available computing nodes from the optional computing node list through the associated Aggregate information to generate an available computing node list; Exclude the computing nodes in the "disabled" state from the list of available computing nodes to generate an updated list of available computing nodes; Select a compute node from the updated list of available compute nodes as the target compute node.

7. The centralized storage virtual machine evacuation method according to any one of claims 1 to 5, characterized in that: Before migrating the VM to the target compute node, the following steps are also included: Disable compute nodes that can be scheduled at the Nova level but do not meet the requirements for running the VMs to be migrated. After migrating the VM to the target compute node, the following steps are also included: Restart the disabled compute node.

8. A centralized storage virtual machine evacuation system, characterized in that: include: A configuration file building module is used to build a configuration file of the connection relationship between the computing node and the storage, wherein the configuration file includes the name of the volume type that can be used by each computing node; The mount volume list generation module is used to obtain all mount volume information of each virtual machine on the failed computing node and generate a virtual machine mount volume list; A volume type name list generation module is used to obtain the volume type name of each mounted volume according to the mounted volume list and generate a volume type name list; An optional computing node list generation module is used to compare each volume type name in the volume type name list with the volume type names that can be used by each computing node in the configuration file. If a computing node supports all volume type names in the volume type name list, the computing node is used as an optional computing node, thereby generating an optional computing node list for the virtual machine; The virtual machine migration module is used to select a computing node from the optional computing node list as the target computing node and migrate the virtual machine to the target computing node.

9. A terminal, characterized in that: include: A memory for storing a centralized storage virtual machine evacuation program; A processor is configured to implement the steps of the centralized storage virtual machine evacuation method according to any one of claims 1 to 7 when executing the centralized storage virtual machine evacuation program.

10. A computer-readable storage medium, characterized in that The readable storage medium stores a centrally stored virtual machine evacuation program, and when the centrally stored virtual machine evacuation program is executed by the processor, the steps of the centrally stored virtual machine evacuation method according to any one of claims 1 to 7 are implemented.

Images