WO2019000535A1 - 云平台的构建方法及云平台 - Google Patents
云平台的构建方法及云平台 Download PDFInfo
- Publication number
- WO2019000535A1 WO2019000535A1 PCT/CN2017/094496 CN2017094496W WO2019000535A1 WO 2019000535 A1 WO2019000535 A1 WO 2019000535A1 CN 2017094496 W CN2017094496 W CN 2017094496W WO 2019000535 A1 WO2019000535 A1 WO 2019000535A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- image file
- computing node
- storage
- virtual machine
- domain
- Prior art date
- Legal status (The legal status 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 status listed.)
- Ceased
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements 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/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/0604—Improving or facilitating administration, e.g. storage management
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0629—Configuration or reconfiguration of storage systems
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0629—Configuration or reconfiguration of storage systems
- G06F3/0635—Configuration or reconfiguration of storage systems by changing the path, e.g. traffic rerouting, path reconfiguration
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements 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/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements 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/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
- G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
- G06F11/2094—Redundant storage or storage space
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements 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/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements 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/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45579—I/O management, e.g. providing access to device drivers or storage
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements 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/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45595—Network integration; Enabling network access in virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
- G06F8/63—Image based installation; Cloning; Build to order
Definitions
- the present invention relates to the field of Internet technologies, and in particular, to a method for constructing a cloud platform and a cloud platform.
- OpenStack can be used as a management middleware in cloud computing systems by providing computing services (nova), network services (neutron), block storage services (cinder), computing services (glance), and authentication services (keystone).
- a storage backend can be established based on the Ceph system to complement OpenStack's block storage service to provide access support for virtual machine images for computing services.
- the current expansion method is to add storage nodes to the storage backend.
- the virtual machines in the compute nodes are crashed, and the stability of the system is poor. .
- the purpose of the application is to provide a method and a platform for constructing a cloud platform, which can improve the disaster tolerance rate and stability of the entire cloud platform.
- the present application provides a method for constructing a cloud platform, where the cloud platform is A plurality of computing nodes and at least two storage backends are included, and the building method includes:
- At least one virtual machine is deployed on each of the computing nodes
- the type of the image file includes a base image file and a exported image file
- the image file is stored according to the type of the image file and the storage backend associated with the computing node that generated the image file.
- an available domain is set for the storage backend; correspondingly, establishing an association relationship between the computing node and the at least two storage backends includes:
- the compute nodes are partitioned into the available domains such that each compute node has one and only one available domain; the domain values of each of the available domains are assigned to respective compute nodes.
- the method further includes:
- the storage backends are merged two-two, and different available domains are set for the merged storage backend.
- the method further includes:
- the virtual machine that generates the virtual machine change computing node operation is changed from the preset computing node to the target computing node.
- storing the image file includes:
- the image file is stored in each of the storage backends.
- the method before the storing the image file in each of the storage backends, the method further includes:
- the method further includes:
- the filter is configured to determine a type of the specified image file; when the specified mirror image When the type of the component is a base image file, select any computing node, and create a virtual machine by using the selected computing node; when the type of the specified image file is an export image file, select a domain value of the available domain and the Specify a compute node with the same domain value of the available domain of the image file, and create a virtual machine by selecting the compute node
- storing the image file includes:
- the image file is an export image file
- determining a storage back end associated with the computing node that generates the image file and storing the image file in the determined storage back end.
- the method before the storing the image file in the determined storage backend, the method further includes:
- the method further includes:
- the step of verifying whether the corresponding storage backend identifier is consistent with the storage backend identifier included in the mirrored service specified field is cancelled.
- the method further includes:
- the size information of the exported image file is obtained by the computing service corresponding to the computing node where the virtual machine is located, and the size information is sent to the image service by the computing service. .
- the present application further provides a cloud platform, where the cloud platform includes a plurality of computing nodes and at least two storage backends, and each of the computing nodes is deployed with at least one virtual machine, where the cloud platform includes:
- An association establishing unit configured to establish an association relationship between the computing node and the at least two storage backends, so that each computing node has one and only one storage backend associated with it;
- An image file type determining unit configured to determine a type of the image file when the image file is generated in the computing node; the type of the image file includes a base image file and a exported image file;
- An image file storage unit is configured to store the image file according to a type of the image file and a storage backend associated with a computing node that generates the image file.
- the unit includes:
- An available domain partitioning module is configured to divide the computing node into each available domain such that each computing node has one and only one available domain;
- a domain value allocation module is configured to allocate domain values of each of the available domains to respective computing nodes.
- the cloud platform further includes:
- a target computing node determining unit configured to select a target computing node that can be changed from the available domain when a preset computing node in the target available domain generates a virtual machine change computing node operation
- a changing unit configured to change a virtual machine that generates the virtual machine change computing node operation from the preset computing node to the target computing node.
- the image file storage unit includes:
- a basic image file storage module configured to store the image file in each of the storage backends when the image file is a base image file
- Exporting an image file storage module configured to: when the image file is an export image file, determine a storage backend associated with a computing node that generates the image file, and store the image file after the determined storage In the end.
- the cloud platform further includes:
- a type determining unit configured to determine a type of the specified image file when creating a virtual machine according to the specified image file
- a virtual machine creating unit configured to: when the type of the specified image file is a base image file, select any computing node, and create a virtual machine by using the selected computing node; when the type of the specified image file is an export image When the file is selected, a computing node whose domain value of the available domain is the same as the domain value of the available domain of the specified image file is selected, and the virtual machine is created by the selected computing node.
- each computing node can first be associated with a different storage backend, such that each storage backend can correspond to a respective compute node.
- a compute node When a compute node generates an image file, it needs to be stored differently according to the specific type of the image file. Specifically, in the present application, when the image file is the base image file, it needs to be stored in each storage backend; and when the image file is the exported image file, the exported image file needs to be stored to generate the export image.
- the purpose of this processing is that the base image only carries the operating system in the factory state, so the virtual machine can be created by any computing node and thus needs to be stored in each storage backend.
- the export image file has a user state of the operating system in which the virtual machine is running, and the exported image file is stored in the storage backend associated with the compute node that generates the virtual machine, so that when the virtual state of the exported image file needs to be created At the time of the machine, you can use the export image file and select the compute nodes associated with the same storage backend to create a new virtual machine. This way, the exported image file can only be stored in one of the storage backends. Based on this, by adding an additional storage backend, the disaster recovery rate of the cloud platform can be improved, and the storage of the cloud platform can be no longer affected by the virtual machine running on the network when the new storage backend is added. Ensure the stability of the cloud platform.
- FIG. 1 is a flowchart of a method for constructing a cloud platform according to Embodiment 1 of the present invention
- FIG. 2 is a schematic diagram of association between a computing node and a storage backend according to Embodiment 1 of the present invention
- FIG. 3 is a schematic diagram of storage of an image file in the first embodiment of the present invention.
- Embodiment 4 is a functional block diagram of a cloud platform in Embodiment 2 of the present invention.
- the cloud platform of the multi-storage backend may include a computing node and at least two storage backends.
- the computing node may be a physical device having a data processing function.
- zero or more virtual machines can be carried on the computing node, and these virtual machines can have their own operating systems to handle different computing tasks.
- the computing node can work based on the OpenStack architecture.
- the meter The compute node can correspond to the subservice nova-compute of the computing service.
- the image file of a user state of the running virtual machine can be obtained through the export mirroring operation.
- the storage backend can operate based on the Ceph file system.
- the storage backend can be a distributed structure in which multiple storage nodes can be included.
- the storage node may be a physical device having a data storage function.
- the method for constructing the cloud platform of the multiple storage backend may include the following steps.
- S1 Establish an association relationship between the computing node and the at least two storage backends, so that each computing node has one and only one storage backend associated with it.
- each storage backend can correspond to its own available domain (availability_zone).
- the corresponding domain values can be set in advance for each available domain.
- the value of the field may be a value or a string, which is not limited in this application. For example, there are currently two storage backends, which correspond to two available domains with domain values "AZ1" and "AZ2", respectively.
- the computing node may be divided into respective available domains, where computing nodes in different available domains are different.
- the corresponding domain value can be set for each computing node through the built-in instructions of the OpenStack computing service.
- the domain value set for the compute node can be one of the corresponding storage backend corresponding domain values. For example, if the domain values of the current two storage backends are "AZ1" and "AZ2", respectively, the domain value "AZ1" or "AZ2" can be set for the compute node.
- a computing node only has one domain value, so the computing nodes associated with different storage backends are different. It can be seen from the above that the domain values of the respective available domains are allocated to the respective associated computing nodes, so that the division of the computing nodes can be realized.
- n computing nodes may be associated with corresponding storage backends, and computing nodes in the same storage backend may have the same domain value.
- the domain values of the compute nodes 1 to i in the storage backend 1 are both "AZ1".
- the method may further include:
- S2 determining, when the virtual machine of the computing node generates an image file, the type of the image file;
- the types of image files include the base image file and the export image file.
- the virtual machine in the compute node can generate an image file.
- the image file may be divided into a base image file and a exported image file.
- the basic image file may refer to an image file created by a native operating system (such as Centos7 and Windows 2012), and the base image file carries a factory-operated operating system, and does not have a personalized configuration of the user (such as installed software). And running programs, etc.).
- the export image file refers to an image file obtained by the export image operation of the running virtual machine. Since the image file of this type is generated for the running virtual machine, the image file of this type usually corresponds to one system. Operating status.
- the storage manner of the base image file and the exported image file may be different. Based on this, when an image file is generated in a computing node, the type of the image file is determined first.
- S3 Store the image file according to the type of the image file and a storage backend associated with the computing node that generates the image file.
- the base image file does not have the operating state of the operating system, so the virtual machine can be created by any computing node, and thus needs to be stored in each storage backend.
- the exported image file has the system running state of the virtual machine, so only the computing node associated with the same storage backend can create a virtual machine based on the exported image file. This way, the exported image file can only be stored in one of the storage backends.
- the image file when the image file is a base image file, the image file needs to be stored in each of the storage backends.
- an available domain attribute may be added to the image file in a mirroring service (glance), and the value of the available domain attribute may be set to none.
- the value of the available domain attribute is null, indicating that no available domain is specified for the image file, and the image file needs to be stored in each storage backend.
- the storage back end associated with the computing node that generates the image file may be determined, and the image file is stored in the determined storage back end.
- the computing node in the available domain AZ1 when the computing node in the available domain AZ1 generates the exported image file, only the exported image file is stored in the storage backend with the domain value AZ1, and the copy of the image does not exist in the other storage backend.
- a domain value of an available domain corresponding to the computing node that generates the image file may be determined, and in a mirroring service (glance), an available domain attribute is added for the image file, and a value of the available domain attribute is set.
- the computing service adds the available domain attribute to the export image file and sets the value of the available domain attribute to AZ1.
- the available domain attribute value of the base image file is null, and an operation and maintenance personnel prepares a copy at each storage backend when the cloud platform is online, so the base image file can be calculated by any one.
- the node creates a virtual machine.
- the export image file available domain attribute value is not empty and exists only in the storage backend with the same available domain value, so using the export image file can only create virtual machines from compute nodes associated to the same storage backend. In this way, the exported image file can usually only be stored in one of the storage backends.
- the method may further include the step of merging at least two storage backends into one storage backend and setting an available domain for the merged storage backend.
- the base image file 1 needs to be stored in the storage backend with the domain value AZ1 and the domain value AZ2 (implemented by the operation and maintenance personnel before the cloud platform goes online).
- the exported image file 1 generated by the computing node with the domain value AZ1 can only be stored in the storage backend with the domain value AZ1 (generated by the user on the online cloud platform operation).
- the exported image file 2 generated for the compute node with the domain value AZ12 can only be stored in the storage backend with the domain value AZ2.
- the purpose of curing the available domains is to limit the changes to the compute nodes to the available domains in which the compute nodes are located. That is to say, when a virtual machine needs to change from one computing node to another, the computing node before the change and the computing node after the change should be in the same available domain.
- virtual machine operations that may cause a compute node change may include change configuration, cold migration, hot migration, evacuation, and cancellation.
- the target computing node may be first determined in the target available domain.
- the virtual machine that generated the virtual machine change operation can then be changed from the preset compute node to the target compute node. This ensures that both the compute node before the change and the compute node after the change are In the same available domain.
- the manner of determining the target computing node in the target available domain may include randomly selecting a computing node different from the preset computing node in the target available domain, and using the selected computing node as the Target computing node.
- the computing nodes other than the preset computing node in the target available domain may be sorted according to the current remaining CPU resources and memory resources, and the remaining The computing node with the largest CPU resource and memory resource serves as the target computing node.
- a filter may be added to the scheduler of the computing service (nova), and the filter may: when the virtual machine is created according to the specified image file, the available domain of the computing node and the specified image file The available domains are matched.
- the type of the specified image file can be determined first.
- the type of the specified image file is a base image file, it indicates that it has a copy at all storage backends. At this time, any computing node can be selected, and the virtual machine is created by the selected computing node.
- the type of the specified image file is an export image file, indicating that it has a copy on only one storage backend, the domain value of the available domain may be selected and the available domain of the specified image file.
- a compute node with the same domain value and a virtual machine created by the selected compute node For example, the specified image file is an export image file, and the computing service can query the domain value of the available domain of the exported image file as AZ1. Then, a computing node can be selected from the computing nodes with the domain value AZ1, and The selected compute node creates a virtual machine.
- the specified image file is an export image file
- the computing service can query the domain value of the available domain of the exported image file as AZ1. Then, a computing node can be selected from the computing nodes with the domain value AZ1, and The selected compute node creates a virtual machine.
- the computing node checks whether the identifier of the corresponding ceph storage backend is The image used is the same as the storage location of the image file contained in the specified field of the mirror service. For example, it is usually checked whether the "fsid" of the ceph storage backend associated with the compute node is equal to the "fsid" contained in the location field of the mirror service. If they are equal, the virtual machine is allowed to be created or the export mirror operation is performed. Otherwise, the request is rejected. .
- This mechanism can only guarantee that the computing service and the mirroring service use the same storage backend in a single storage backend scenario, which is obviously not applicable in the multi-storage backend scenario.
- the computing node when the computing node creates the virtual machine and generates the image file, cancel whether the storage backend identifier associated with the verification computing node is equal to the storage backend identifier included in the location field of the mirroring service. So that you can create a virtual machine or produce The raw export image file supports multiple backend scenarios.
- the at least two storage backends corresponds to the mirroring service, and the other storage backends cannot correspond to the mirroring service.
- the size of the exported image file is usually obtained or verified by the mirroring service from the storage backend.
- only one storage backend corresponds to the mirroring service, and if the virtual machine in the computing node associated with the other storage backend generates the export image file operation, due to other storage The end does not correspond to the mirroring service, which causes the mirroring service to fail to obtain the size of the mirror from the storage backend.
- the mirror size cannot be obtained and the export operation fails.
- the AZ1 storage backend and the AZ2 storage backend are currently available.
- the AZ1 storage backend corresponds to the mirroring service
- the AZ2 storage backend cannot correspond to the mirroring service.
- the image service attempts to obtain the AZ1 storage backend.
- Mirror size since the mirror service only corresponds to the AZ1 storage backend
- the export image file operation is generated in the AZ2 available domain, the mirror service must not be able to get the image size from the AZ1 storage backend.
- the size information of the exported image file may be obtained by the computing service corresponding to the computing node where the virtual machine is located, instead of the mirroring service. And transmitting, by the computing service, the size information to a mirroring service. In this way, the mirroring service can normally obtain the mirror size and ensure the smooth operation of the export operation.
- the application further provides a cloud platform, where the cloud platform includes multiple computing nodes and at least two storage backends, each of which can host zero or more virtual machines, the cloud The platform includes:
- the association relationship establishing unit 100 is configured to establish an association relationship between the computing node and the at least two storage backends, so that each computing node has one and only one storage backend associated with it;
- the image file type determining unit 200 is configured to determine a type of the image file when the image file is generated in the virtual machine of the computing node; the type of the image file includes a base image file and an export image file;
- the image file storage unit 300 is configured to store the image file according to the type of the image file and a storage backend associated with the computing node that generates the image file.
- each of the storage backends has a respective available domain; correspondingly, the association establishing unit includes:
- An available domain partitioning module is configured to divide the computing node into each available domain such that each computing node has one and only one available domain;
- a domain value allocation module is configured to allocate domain values of each of the available domains to respective computing nodes.
- the cloud platform further includes:
- a target computing node determining unit configured to select a target computing node that can be changed from the available domain when a preset computing node in the target available domain generates a virtual machine change computing node operation
- a changing unit configured to change a virtual machine that generates the operation of the change computing node from the preset computing node to the target computing node.
- the image file storage unit includes:
- a basic image file storage module configured to store the image file in each of the storage backends when the image file is a base image file
- Exporting an image file storage module configured to: when the image file is an export image file, determine a storage backend associated with a computing node that generates the image file, and store the image file after the determined storage In the end.
- the cloud platform further includes:
- a type determining unit configured to determine a type of the specified image file when creating a virtual machine according to the specified image file
- a virtual machine creating unit configured to: when the type of the specified image file is a base image file, select any computing node, and create a virtual machine by using the selected computing node; when the type of the specified image file is an export image When the file is selected, a computing node whose domain value of the available domain is the same as the domain value of the available domain of the specified image file is selected, and the virtual machine is created by the selected computing node.
- the cloud platform embodiments described above are merely illustrative, wherein 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, ie, Located in one place, or distributed to multiple network units on. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the embodiment. Those of ordinary skill in the art can understand and implement without deliberate labor.
- each computing node can first be associated with a different storage backend, such that each storage backend can correspond to a respective compute node.
- a compute node When a compute node generates an image file, it needs to be stored differently according to the specific type of the image file. Specifically, in the present application, when the image file is the base image file, it needs to be stored in each storage backend; and when the image file is the exported image file, the exported image file needs to be stored to generate the export image.
- the compute node of the file is associated with the storage backend.
- the purpose of this processing is that the base image only carries the operating system in the factory state, so the virtual machine can be created by any computing node and thus needs to be stored in each storage backend.
- the exported image file has a user state of the operating system in which the virtual machine is running. Therefore, only the computing node associated with the same storage backend can create a virtual machine according to the exported image file, so that the exported image file can only be exported.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Human Computer Interaction (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Stored Programmes (AREA)
Abstract
本发明公开了一种云平台及其构建方法,其中,所述云平台包括多个计算节点以及至少两个存储后端,所述构建方法包括:建立所述计算节点与所述至少两个存储后端之间的关联关系,以使得每个所述存储后端与各自的计算节点相关联;其中,不同的存储后端关联的计算节点各不相同;当计算节点中产生镜像文件时,确定所述镜像文件的类型;所述镜像文件的类型包括基础镜像文件和导出镜像文件;根据所述镜像文件的类型以及产生所述镜像文件的计算节点所关联的存储后端,对所述镜像文件进行存储。本申请提供的技术方案,能够提高整个云平台的容灾率和稳定性。
Description
本发明涉及互联网技术领域,特别涉及一种云平台的构建方法及云平台。
随着互联网技术的不断发展,云计算由于其高效、便捷、可配置等优势,正在逐渐取代传统的计算方式。当前,云计算的系统通常可以采用OpenStack架构来实现。OpenStack通过提供计算服务(nova)、网络服务(neutron)、块存储服务(cinder)、计算服务(glance)和认证服务(keystone)等,可以作为云计算系统中的管理中间件。
为了构建完整的云计算系统,通常会为OpenStack配置相应的底层服务。当前,可以基于Ceph系统建立存储后端,以配合OpenStack的块存储服务,从而为计算服务提供虚拟机镜像的存取支持。
现有技术中,在云计算系统中通常仅配置单一的存储后端,各个计算节点中虚拟机的镜像文件均可以存储于该单一的存储后端中。然而,采用单一的存储后端通常会存在以下问题:
1.一旦该存储后端发生故障,会导致所有的计算节点陷入瘫痪,系统的容灾率较低;
2.随着数据量的不断增大,势必需要对存储后端进行扩容。当前的扩容方式是通过在存储后端中添加存储节点,然而,在实际应用中,通过添加存储节点进行扩容的方式,有时候会导致计算节点中虚拟机发生崩溃,系统的稳定性也较差。
发明内容
本申请的目的在于提供一种云平台的构建方法及平台,能够提高整个云平台的容灾率和稳定性。
为实现上述目的,本申请一方面提供一种云平台的构建方法,所述云平台
包括多个计算节点以及至少两个存储后端,所述构建方法包括:
建立所述计算节点与所述至少两个存储后端之间的关联关系,以使得每个计算节点有且仅有一个存储后端与其关联。
在本实施方式中,每个所述计算节点上部署至少一个虚拟机;
当计算节点的虚拟机生成镜像文件时,确定所述镜像文件的类型;所述镜像文件的类型包括基础镜像文件和导出镜像文件;
根据所述镜像文件的类型以及生成所述镜像文件的计算节点所关联的存储后端,对所述镜像文件进行存储。
在本实施方式中,为所述存储后端设置可用域;相应地,建立所述计算节点与所述至少两个存储后端之间的关联关系包括:
将所述计算节点划分至所述可用域中,使得每个计算节点有且仅划入一个可用域;将各个所述可用域的域值分配给各自的计算节点。
在本实施方式中,所述方法还包括:
当存储后端数量大于两个时,将存储后端两两合并,并为合并后的存储后端设置不同的可用域。
在本实施方式中,所述方法还包括:
当某个可用域中的预设计算节点产生虚拟机变更计算节点操作时,从该可用域中选择可变更的目标计算节点;
将产生所述虚拟机变更计算节点操作的虚拟机从所述预设计算节点变更至所述目标计算节点。
在本实施方式中,对所述镜像文件进行存储包括:
当所述镜像文件为基础镜像文件时,将所述镜像文件在各个所述存储后端中进行存储。
在本实施方式中,在将所述镜像文件在各个所述存储后端中进行存储之前,所述方法还包括:
为所述基础镜像文件添加可用域属性,并将所述可用域属性的数值设置为空。
在本实施方式中,所述方法还包括:
在根据指定镜像文件创建虚拟机时,在计算服务中设置过滤器;
其中,所述过滤器用于确定所述指定镜像文件的类型;当所述指定镜像文
件的类型为基础镜像文件时,选择任一计算节点,并通过选择的所述计算节点创建虚拟机;当所述指定镜像文件的类型为导出镜像文件时,选择可用域的域值与所述指定镜像文件的可用域的域值相同的一个计算节点,并通过选择的所述计算节点创建虚拟机
在本实施方式中,对所述镜像文件进行存储包括:
当所述镜像文件为导出镜像文件时,确定产生所述镜像文件的计算节点所关联的存储后端,并将所述镜像文件存储于确定出的所述存储后端中。
在本实施方式中,在将所述镜像文件存储于确定出的所述存储后端中之前,所述方法还包括:
确定产生所述镜像文件的计算节点对应的可用域的域值;
为所述镜像文件添加可用域属性,并将所述可用域属性的赋值设置为所述可用域的域值。
在本实施方式中,所述方法还包括:
在计算节点创建虚拟机和产生镜像文件时,取消在计算节点校验其所对应存储后端标识是否和所使用镜像在镜像服务指定字段所包含的存储后端标识相一致的步骤。
在本实施方式中,所述方法还包括:
对虚拟机执行导出镜像文件的操作时,由所述虚拟机所处的计算节点对应的计算服务获取所述导出镜像文件的尺寸信息,并由所述计算服务将所述尺寸信息发送至镜像服务。
另一方面,本申请还提供一种云平台,所述云平台包括多个计算节点以及至少两个存储后端,每个所述计算节点上部署有至少一个虚拟机,所述云平台包括:
关联关系建立单元,用于建立所述计算节点与所述至少两个存储后端之间的关联关系,以使得每个计算节点有且仅有一个存储后端与其关联;
镜像文件类型确定单元,用于当计算节点中产生镜像文件时,确定所述镜像文件的类型;所述镜像文件的类型包括基础镜像文件和导出镜像文件;
镜像文件存储单元,用于根据所述镜像文件的类型以及产生所述镜像文件的计算节点所关联的存储后端,对所述镜像文件进行存储。
在本实施方式中,为所述存储后端设置可用域;相应地,所述关联关系建
立单元包括:
可用域划分模块,用于将所述计算节点划分至各个可用域中,使得每个计算节点有且仅划入一个可用域;
域值分配模块,用于将各个所述可用域的域值分配给各自的计算节点。
在本实施方式中,所述云平台还包括:
目标计算节点确定单元,用于当目标可用域中的预设计算节点产生虚拟机变更计算节点操作时,从该可用域中选择可变更的目标计算节点;
变更单元,用于将产生所述虚拟机变更计算节点操作的虚拟机从所述预设计算节点变更至所述目标计算节点处。
在本实施方式中,所述镜像文件存储单元包括:
基础镜像文件存储模块,用于当所述镜像文件为基础镜像文件时,将所述镜像文件在各个所述存储后端中进行存储;
导出镜像文件存储模块,用于当所述镜像文件为导出镜像文件时,确定产生所述镜像文件的计算节点所关联的存储后端,并将所述镜像文件存储于确定出的所述存储后端中。
在本实施方式中,所述云平台还包括:
类型确定单元,用于在根据指定镜像文件创建虚拟机时,确定所述指定镜像文件的类型;
虚拟机创建单元,用于当所述指定镜像文件的类型为基础镜像文件时,选择任一计算节点,并通过选择的所述计算节点创建虚拟机;当所述指定镜像文件的类型为导出镜像文件时,选择可用域的域值与所述指定镜像文件的可用域的域值相同的一个计算节点,并通过选择的所述计算节点创建虚拟机。
由上可见,本申请提供的技术方案,可以在云平台中设置至少两个存储后端,这样,在其中一个存储后端发生故障时,其它的存储后端还能够正常使用,提高了云平台的容灾率。在具备至少两个存储后端的云平台中,首先可以将各个计算节点分别与不同的存储后端进行关联,这样,每一个存储后端可以与各自的计算节点相对应。当计算节点产生镜像文件时,需要根据镜像文件的具体类型,有区分地进行存储。具体地,在本申请中,当镜像文件为基础镜像文件时,需要在各个存储后端中均进行存储;而当镜像文件为导出镜像文件时,需要将该导出镜像文件存储至产生该导出镜像文件的计算节点关联的存储后端
中。这样处理的目的在于,基础镜像只承载出厂状态的操作系统,因此可以由任一计算节点创建虚拟机,从而需要存储于各个存储后端中。而导出镜像文件具备虚拟机运行中的操作系统的某个用户状态,将该导出镜像文件存储在生成该虚拟机的计算节点关联的存储后端,使得当需要创建与导出镜像文件状态相同的虚拟机时,可以利用该导出镜像文件并选择与同一存储后端相关联的计算节点以创建新的虚拟机。这样,导出镜像文件只可以存储于其中一个存储后端中。基于此,通过增加额外的存储后端,可以提高云平台的容灾率,并使以添加新的存储后端对云平台进行存储扩容时不再对线上运行的虚拟机构成影响,从而可以保证云平台的稳定性。
为了更清楚地说明本发明实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本发明实施例一中云平台的构建方法流程图;
图2是本发明实施例一中计算节点与存储后端的关联示意图;
图3是本发明实施例一中镜像文件的存储示意图;
图4是本发明实施例二中云平台的功能模块图。
为使本发明的目的、技术方案和优点更加清楚,下面将结合附图对本发明实施方式作进一步地详细描述。
实施例一
本申请提供的多存储后端的云平台中,可以包括计算节点以及至少两个存储后端。其中,所述计算节点可以是具备数据处理功能的物理设备。为了充分利用计算节点的CPU、内存等资源,在所述计算节点上可以承载零台或多台虚拟机,这些虚拟机可以具备各自的操作系统,以处理不同的计算任务。
在本实施方式中,所述计算节点可以基于OpenStack架构进行工作。所述计
算节点可以与计算服务的子服务nova-compute相对应。所述计算节点上的虚拟机在运行时,可以通过导出镜像操作获取运行中虚拟机某个用户态的镜像文件。
在本实施方式中,所述存储后端可以基于Ceph文件系统进行工作。所述存储后端可以是分布式的结构,其中可以包含多个存储节点。所述存储节点可以是具备数据存储功能的物理设备。
请参阅图1,在本实施方式中,所述多存储后端的云平台的构建方法可以包括以下步骤。
S1:建立所述计算节点与所述至少两个存储后端之间的关联关系,以使得每个计算节点有且仅有一个存储后端与其关联。
在本实施方式中,由于具备至少两个存储后端,可以为每个存储后端关联相应的计算节点。在实际应用中,每个存储后端可以对应各自的可用域(availability_zone)。为了区分不同的可用域,可以预先为各个可用域设置相应的域值。所述域值可以是一个数值,也可以是一个字符串,本申请文件并不做限定。例如,当前具备两个存储后端,这两个存储后端分别对应域值为“AZ1”和“AZ2”的两个可用域。
在本实施方式中,可以将所述计算节点划分至各个可用域中,其中,不同可用域中的计算节点各不相同。具体地,可以通过OpenStack计算服务的内置指令,为各个计算节点设置相应的域值。为计算节点设置的域值可以是当前存储后端对应域值中的一个。例如,当前两个存储后端的域值分别为“AZ1”和“AZ2”,那么可以为计算节点设置域值“AZ1”或者“AZ2”。需要说明的是,一个计算节点仅具备一个域值,因此,不同存储后端关联的计算节点各不相同。由上可见,将各个所述可用域的域值分配给各自关联的计算节点,从而可以实现对计算节点的划分。
请参阅图2,在一个实际应用示例中,当前共计存在m个存储后端以及n个计算节点。其中,m个存储后端对应的可用域的域值依次为AZ1、AZ2直至AZm。如图2所示,n个计算节点可以被关联至对应的存储后端,处于同一个存储后端中的计算节点可以具备相同的域值。例如,存储后端1中的计算节点1至i的域值均为“AZ1”。
在本申请一个实施方式中,在步骤S1之后还可以包括:
S2:当计算节点的虚拟机产生镜像文件时,确定所述镜像文件的类型;所
述镜像文件的类型包括基础镜像文件和导出镜像文件。
在本实施方式中,计算节点中的虚拟机可以产生镜像文件。具体地,所述镜像文件可以被划分为基础镜像文件和导出镜像文件。其中,所述基础镜像文件可以指用原生操作系统(如Centos7和Windows2012等)制作的镜像文件,所述基础镜像文件承载了出厂状态的操作系统,不具备用户的个性化配置(如安装的软件和运行的程序等)。所述导出镜像文件指对运行中的虚拟机通过导出镜像操作获得的镜像文件,由于这一类的镜像文件是针对运行中的虚拟机产生的,因此这一类的镜像文件通常会对应一个系统运行状态。
在本实施方式中,由于基础镜像文件和导出镜像文件的不同,因此对于基础镜像文建和导出镜像文件的存储方式也会存在不同。基于此,在计算节点中产生镜像文件时,要先确定所述镜像文件的类型。
S3:根据所述镜像文件的类型以及产生所述镜像文件的计算节点所关联的存储后端,对所述镜像文件进行存储。
在本实施方式中,基础镜像文件不会带有操作系统的运行状态,因此可以由任一计算节点创建虚拟机,从而需要存储于各个存储后端中。而导出镜像文件具备虚拟机的系统运行状态,因此,只有与同一个存储后端相关联的计算节点才能够根据该导出镜像文件创建虚拟机。这样,导出镜像文件只可以存储于其中一个存储后端中。
在本实施方式中,当所述镜像文件为基础镜像文件时,需要将所述镜像文件在每个所述存储后端中进行存储。具体地,可以在镜像服务(glance)中,为所述镜像文件添加可用域属性,并将所述可用域属性的值设置为空(none)。可用域属性的值为空即表明不为该镜像文件指定可用域,该镜像文件需要被存储于每个存储后端内。
在本实施方式中,当所述镜像文件为导出镜像文件时,可以确定产生所述镜像文件的计算节点所关联的存储后端,并将所述镜像文件存储于确定出的所述存储后端中。例如,处于可用域AZ1中的计算节点产生导出镜像文件时,只将该导出镜像文件存储于域值为AZ1的存储后端内,在其它的存储后端中不存在该镜像的拷贝。具体地,可以确定产生所述镜像文件的计算节点对应的可用域的域值,并在镜像服务(glance)中,为所述镜像文件添加可用域属性,并将所述可用域属性的数值设置为确定出的可用域的域值。例如,处于可用域AZ1
中的计算节点产生导出镜像文件后,计算服务为该导出镜像文件添加可用域属性,并将所述可用域属性的值设置为AZ1。
综上,在本实施方式中,基础镜像文件可用域属性值为空,且在云平台上线时由运维人员在每个存储后端都准备一份拷贝,因此使用基础镜像文件可由任一计算节点创建虚拟机。而导出镜像文件可用域属性值不为空,且只在有相同可用域值的存储后端中存在一份,因此,使用导出镜像文件只能由关联到相同存储后端的计算节点创建虚拟机。这样,导出镜像文件通常只可以存储于其中一个存储后端中。
需要说明的是,在实际应用场景中,为了提高存储后端的存储量,还可能存在当存储后端数量大于两个时,将存储后端两两合并,并设置不同的可用域。因此,在本实施方式中,所述方法还可以包括将至少两个存储后端合并为一个存储后端,并为合并后的存储后端设置可用域的步骤。
请参阅图3,在一个实际应用示例中,当前具备AZ1和AZ2两个存储后端。其中,基础镜像文件1需同时存储于域值为AZ1和域值为AZ2的存储后端中(由运维人员在云平台上线之前实施)。而对于域值为AZ1的计算节点生成的导出镜像文件1,只可以被存储于域值为AZ1的存储后端中(由用户在线上云平台操作产生)。同样的,对于域值为AZ12的计算节点生成的导出镜像文件2,只可以被存储于域值为AZ2的存储后端中。
在本申请一个实施方式中,在建立所述计算节点与所述至少两个存储后端之间的关联关系之后,还需要对可能导致计算节点变更的虚拟机操作固化可用域。具体地,固化可用域的目的在于将计算节点的变更限制于该计算节点所处的可用域内。也就是说,当某个虚拟机需要从一个计算节点变更至另一个计算节点时,变更之前的计算节点和变更之后的计算节点都应当处于同一个可用域中。
在本实施方式中,可能导致计算节点变更的虚拟机操作可以包括变更配置、冷迁移、热迁移、疏散和取消搁置等。具体地,当目标可用域中的预设计算节点产生虚拟机变更操作时,可以先在所述目标可用域中确定目标计算节点。然后可以将产生所述虚拟机变更操作的虚拟机从所述预设计算节点变更至所述目标计算节点处。这样便可以保证变更之前的计算节点和变更之后的计算节点都
处于同一个可用域中。
在本实施方式中,在目标可用域中确定目标计算节点的方式可以包括在所述目标可用域中随机选取一个与所述预设计算节点不同的计算节点,并将选取的计算节点作为所述目标计算节点。当然,为了保证虚拟机在变更之后能够正常运行,还可以将所述目标可用域中除所述预设计算节点之外的计算节点按照当前剩余的CPU资源和内存资源进行排序,并将剩余的CPU资源和内存资源最多的计算节点作为所述目标计算节点。
在本申请一个实施方式中,可以为计算服务(nova)的调度器添加一个过滤器,该过滤器可以在根据指定镜像文件创建虚拟机时,将计算节点的可用域与所述指定镜像文件的可用域进行匹配。具体地,首先可以确定所述指定镜像文件的类型。当所述指定镜像文件的类型为基础镜像文件时,表明其在所有存储后端都存在一份拷贝,此时可以选择任一计算节点,并通过选择的所述计算节点创建虚拟机。然而,当所述指定镜像文件的类型为导出镜像文件时,表明其在仅在某一个存储后端存在一份拷贝,此时可以选择可用域的域值与所述指定镜像文件的可用域的域值相同的一个计算节点,并通过选择的所述计算节点创建虚拟机。例如,所述指定镜像文件为导出镜像文件,计算服务可以查询到该导出镜像文件的可用域的域值为AZ1,那么此时可以从域值为AZ1的计算节点中选取一个计算节点,并通过选取出的该计算节点创建虚拟机。
在本申请一个实施方式中,考虑到在单一存储后端的系统架构中,每当在计算节点创建虚拟机或产生导出镜像文件时,都会在计算节点校验其所对应ceph存储后端的标识是否与其所使用镜像在镜像服务的指定字段所包含的镜像文件所在存储位置的标识一致。例如,通常都会校验计算节点关联的ceph存储后端的“fsid”与镜像服务中location字段所包含的“fsid”是否相等,若相等,则允许创建虚拟机或进行导出镜像操作,否则会拒绝请求。该机制本就只能在单一存储后端情境下保障计算服务和镜像服务使用相同存储后端,在多存储后端场景下显然是不适用的。基于此,在本实施方式中,在计算节点创建虚拟机和产生镜像文件时,取消校验计算节点所关联存储后端标识是否与镜像在镜像服务中的location字段所包含的存储后端标识相等,从而可以使创建虚拟机或产
生导出镜像文件支持多后端场景。
在本申请一个实施方式中,需要说明的是,至少两个存储后端中仅有一个存储后端会与镜像服务相对应,其它的存储后端则无法与镜像服务相对应。而如果按照现有技术中单一存储后端的场景而言,每当虚拟机进行导出镜像文件操作时,通常都会由镜像服务从存储后端处获取或者校验导出镜像文件的尺寸。然而在本申请的多个存储后端的场景下,仅有一个存储后端与镜像服务相对应,如果其它的存储后端关联的计算节点中的虚拟机产生导出镜像文件操作时,由于其它存储后端与镜像服务并不对应,从而导致镜像服务无法从存储后端处获取镜像的尺寸,这样便会导致无法获取镜像尺寸而判定导出操作失败。举例来进行说明,当前具备AZ1存储后端与AZ2存储后端,其中,AZ1存储后端与镜像服务相对应,而AZ2存储后端无法与镜像服务相对应。那么当AZ2存储后端关联的计算节点中的虚拟机产生导出镜像文件操作时,如果按照现有技术中由镜像服务获取镜像尺寸的方式,此时镜像服务便会尝试从AZ1存储后端中获取镜像尺寸(因为镜像服务仅与AZ1存储后端相对应),显然,由于导出镜像文件操作是在AZ2可用域中生成的,镜像服务必然无法从AZ1存储后端处获取镜像尺寸。这样的话,便会导致导出操作失败。因此,在本实施方式中,当虚拟机执行导出镜像文件的操作时,可以由所述虚拟机所处的计算节点对应的计算服务(而不是镜像服务)获取所述导出镜像文件的尺寸信息,并由所述计算服务将所述尺寸信息发送至镜像服务。这样,便可以使得镜像服务可以正常获取到镜像尺寸,保证导出操作的顺利进行。
实施例二
请参阅图2,本申请还提供一种云平台,所述云平台包括多个计算节点以及至少两个存储后端,每个所述计算节点可承载零台或多台虚拟机,所述云平台包括:
关联关系建立单元100,用于建立所述计算节点与所述至少两个存储后端之间的关联关系,以使得每个计算节点有且仅有一个存储后端与其关联;
镜像文件类型确定单元200,用于当计算节点的虚拟机中产生镜像文件时,确定所述镜像文件的类型;所述镜像文件的类型包括基础镜像文件和导出镜像
文件;
镜像文件存储单元300,用于根据所述镜像文件的类型以及产生所述镜像文件的计算节点所关联的存储后端,对所述镜像文件进行存储。
在本实施方式中,每个所述存储后端具备各自的可用域;相应地,所述关联关系建立单元包括:
可用域划分模块,用于将所述计算节点划分至各个可用域中,使得每个计算节点有且仅划入一个可用域;
域值分配模块,用于将各个所述可用域的域值分配给各自的计算节点。
在本实施方式中,所述云平台还包括:
目标计算节点确定单元,用于当目标可用域中的预设计算节点产生虚拟机变更计算节点操作时,从该可用域中选择可变更的目标计算节点;
变更单元,用于将产生所述变更计算节点操作的虚拟机从所述预设计算节点变更至所述目标计算节点处。
在本实施方式中,所述镜像文件存储单元包括:
基础镜像文件存储模块,用于当所述镜像文件为基础镜像文件时,将所述镜像文件在各个所述存储后端中进行存储;
导出镜像文件存储模块,用于当所述镜像文件为导出镜像文件时,确定产生所述镜像文件的计算节点所关联的存储后端,并将所述镜像文件存储于确定出的所述存储后端中。
在本实施方式中,所述云平台还包括:
类型确定单元,用于在根据指定镜像文件创建虚拟机时,确定所述指定镜像文件的类型;
虚拟机创建单元,用于当所述指定镜像文件的类型为基础镜像文件时,选择任一计算节点,并通过选择的所述计算节点创建虚拟机;当所述指定镜像文件的类型为导出镜像文件时,选择可用域的域值与所述指定镜像文件的可用域的域值相同的一个计算节点,并通过选择的所述计算节点创建虚拟机。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
以上所描述的云平台实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元
上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下,即可以理解并实施。
由上可见,本申请提供的技术方案,可以在云平台中设置至少两个存储后端,这样,在其中一个存储后端发生故障时,其它的存储后端还能够正常使用,提高了云平台的容灾率。在具备至少两个存储后端的云平台中,首先可以将各个计算节点分别与不同的存储后端进行关联,这样,每一个存储后端可以与各自的计算节点相对应。当计算节点产生镜像文件时,需要根据镜像文件的具体类型,有区分地进行存储。具体地,在本申请中,当镜像文件为基础镜像文件时,需要在各个存储后端中均进行存储;而当镜像文件为导出镜像文件时,需要将该导出镜像文件存储至产生该导出镜像文件的计算节点关联的存储后端中。这样处理的目的在于,基础镜像只承载出厂状态的操作系统,因此可以由任一计算节点创建虚拟机,从而需要存储于各个存储后端中。而导出镜像文件具备虚拟机运行中的操作系统的某个用户状态,因此,只有与同一个存储后端相关联的计算节点才能够根据该导出镜像文件创建虚拟机,这样,导出镜像文件只可以存储于其中一个存储后端中。基于此,通过增加额外的存储后端,可以提高云平台的容灾率,并使以添加新的存储后端对云平台进行存储扩容时不再对线上运行的虚拟机构成影响,从而可以保证云平台的稳定性。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件。基于这样的理解,上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在计算机可读存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
以上所述仅为本发明的较佳实施例,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (17)
- 一种云平台的构建方法,其特征在于,所述云平台包括多个计算节点以及至少两个存储后端,所述构建方法包括:建立所述计算节点与所述至少两个存储后端之间的关联关系,以使得每个计算节点有且仅有一个存储后端与其关联。
- 根据权利要求1所述的构建方法,其特征在于,每个所述计算节点上部署至少一个虚拟机;当计算节点的虚拟机生成镜像文件时,确定所述镜像文件的类型;所述镜像文件的类型包括基础镜像文件和导出镜像文件;根据所述镜像文件的类型以及生成所述镜像文件的计算节点所关联的存储后端,对所述镜像文件进行存储。
- 根据权利要求1所述的构建方法,其特征在于,为所述存储后端设置可用域;相应地,建立所述计算节点与所述至少两个存储后端之间的关联关系包括:将所述计算节点划分至所述可用域中,使得每个计算节点有且仅划入一个可用域;将各个所述可用域的域值分配给各自的计算节点。
- 根据权利要求3所述的构建方法,其特征在于,所述方法还包括:当存储后端数量大于两个时,将存储后端两两合并,并为合并后的存储后端设置不同的可用域。
- 根据权利要求3所述的构建方法,其特征在于,所述方法还包括:当某个可用域中的预设计算节点产生虚拟机变更计算节点操作时,从该可用域中选择可变更的目标计算节点;将产生所述虚拟机变更计算节点操作的虚拟机从所述预设计算节点变更至所述目标计算节点。
- 根据权利要求2所述的构建方法,其特征在于,对所述镜像文件进行存 储包括:当所述镜像文件为基础镜像文件时,将所述镜像文件在各个所述存储后端中进行存储。
- 根据权利要求6所述的构建方法,其特征在于,在将所述镜像文件在各个所述存储后端中进行存储之前,所述方法还包括:为所述基础镜像文件添加可用域属性,并将所述可用域属性的数值设置为空。
- 根据权利要求2所述的构建方法,其特征在于,所述方法还包括:在根据指定镜像文件创建虚拟机时,在计算服务中设置过滤器;其中,所述过滤器用于确定所述指定镜像文件的类型;当所述指定镜像文件的类型为基础镜像文件时,选择任一计算节点,并通过选择的所述计算节点创建虚拟机;当所述指定镜像文件的类型为导出镜像文件时,选择可用域的域值与所述指定镜像文件的可用域的域值相同的一个计算节点,并通过选择的所述计算节点创建虚拟机。
- 根据权利要求2所述的构建方法,其特征在于,对所述镜像文件进行存储包括:当所述镜像文件为导出镜像文件时,确定产生所述镜像文件的计算节点所关联的存储后端,并将所述镜像文件存储于确定出的所述存储后端中。
- 根据权利要求9所述的构建方法,其特征在于,在将所述镜像文件存储于确定出的所述存储后端中之前,所述方法还包括:确定产生所述镜像文件的计算节点对应的可用域的域值;为所述镜像文件添加可用域属性,并将所述可用域属性的赋值设置为所述可用域的域值。
- 根据权利要求2所述的构建方法,其特征在于,所述方法还包括:在计算节点创建虚拟机和产生镜像文件时,取消在计算节点校验其所对应 存储后端标识是否和所使用镜像在镜像服务指定字段所包含的存储后端标识相一致的步骤。
- 根据权利要求2所述的构建方法,其特征在于,所述方法还包括:对虚拟机执行导出镜像文件的操作时,由所述虚拟机所处的计算节点对应的计算服务获取所述导出镜像文件的尺寸信息,并由所述计算服务将所述尺寸信息发送至镜像服务。
- 一种云平台,其特征在于,所述云平台包括多个计算节点以及至少两个存储后端,每个所述计算节点上部署有至少一个虚拟机,所述云平台包括:关联关系建立单元,用于建立所述计算节点与所述至少两个存储后端之间的关联关系,以使得每个计算节点有且仅有一个存储后端与其关联;镜像文件类型确定单元,用于当计算节点的虚拟机中产生镜像文件时,确定所述镜像文件的类型;所述镜像文件的类型包括基础镜像文件和导出镜像文件;镜像文件存储单元,用于根据所述镜像文件的类型以及产生所述镜像文件的计算节点所关联的存储后端,对所述镜像文件进行存储。
- 根据权利要求13所述的云平台,其特征在于,为所述存储后端设置可用域;相应地,所述关联关系建立单元包括:可用域划分模块,用于将所述计算节点划分至各个可用域中,使得每个计算节点有且仅划入一个可用域;域值分配模块,用于将各个所述可用域的域值分配给各自的计算节点。
- 根据权利要求14所述的云平台,其特征在于,所述云平台还包括:目标计算节点确定单元,用于当目标可用域中的预设计算节点产生虚拟机变更计算节点操作时,从该可用域中选择可变更的目标计算节点;变更单元,用于将产生所述虚拟机变更计算节点操作的虚拟机从所述预设计算节点变更至所述目标计算节点处。
- 根据权利要求13所述的云平台,其特征在于,所述镜像文件存储单元包括:基础镜像文件存储模块,用于当所述镜像文件为基础镜像文件时,将所述镜像文件在各个所述存储后端中进行存储;导出镜像文件存储模块,用于当所述镜像文件为导出镜像文件时,确定产生所述镜像文件的计算节点所关联的存储后端,并将所述镜像文件存储于确定出的所述存储后端中。
- 根据权利要求13所述的云平台,其特征在于,所述云平台还包括:类型确定单元,用于在根据指定镜像文件创建虚拟机时,确定所述指定镜像文件的类型;虚拟机创建单元,用于当所述指定镜像文件的类型为基础镜像文件时,选择任一计算节点,并通过选择的所述计算节点创建虚拟机;当所述指定镜像文件的类型为导出镜像文件时,选择可用域的域值与所述指定镜像文件的可用域的域值相同的一个计算节点,并通过选择的所述计算节点创建虚拟机。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP17875062.6A EP3442201B1 (en) | 2017-06-26 | 2017-07-26 | Cloud platform construction method and cloud platform |
| US15/750,105 US10761869B2 (en) | 2017-06-26 | 2017-07-26 | Cloud platform construction method and cloud platform storing image files in storage backend cluster according to image file type |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710493602.9A CN107124473A (zh) | 2017-06-26 | 2017-06-26 | 云平台的构建方法及云平台 |
| CN201710493602.9 | 2017-06-26 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2019000535A1 true WO2019000535A1 (zh) | 2019-01-03 |
Family
ID=59718752
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2017/094496 Ceased WO2019000535A1 (zh) | 2017-06-26 | 2017-07-26 | 云平台的构建方法及云平台 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US10761869B2 (zh) |
| EP (1) | EP3442201B1 (zh) |
| CN (1) | CN107124473A (zh) |
| WO (1) | WO2019000535A1 (zh) |
Families Citing this family (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109582433B (zh) * | 2017-09-29 | 2022-02-01 | 腾讯科技(深圳)有限公司 | 一种资源调度方法、装置、云计算系统及存储介质 |
| CN108255575A (zh) * | 2017-12-06 | 2018-07-06 | 顺丰科技有限公司 | 一种虚拟机迁移方法及装置 |
| CN109634718B (zh) * | 2018-12-13 | 2020-03-31 | 无锡华云数据技术服务有限公司 | 云平台创建镜像的方法及系统 |
| CN109669762B (zh) * | 2018-12-25 | 2023-03-03 | 深圳前海微众银行股份有限公司 | 云计算资源管理方法、装置、设备及计算机可读存储介质 |
| CN110380894A (zh) * | 2019-06-27 | 2019-10-25 | 苏州浪潮智能科技有限公司 | 云平台中云主机的管理方法和装置 |
| CN111737048B (zh) * | 2020-05-29 | 2022-06-10 | 苏州浪潮智能科技有限公司 | 一种openstack对接存储虚机卷备份处理方法及装置 |
| CN113970998B (zh) * | 2020-07-24 | 2024-08-09 | 中移(苏州)软件技术有限公司 | 一种信息处理方法、装置、终端及存储介质 |
| CN112130955A (zh) * | 2020-09-02 | 2020-12-25 | 中国电子科技网络信息安全有限公司 | 一种基于融合架构云平台的虚拟机调度方法 |
| CN112463170B (zh) * | 2020-10-29 | 2022-08-23 | 苏州浪潮智能科技有限公司 | 云平台上制作镜像的方法、装置、设备及存储介质 |
| CN112711469A (zh) * | 2020-12-29 | 2021-04-27 | 武汉联影医疗科技有限公司 | 云主机迁移方法、装置、计算机设备和存储介质 |
| CN115855333B (zh) | 2022-12-21 | 2023-08-25 | 北京工研精机股份有限公司 | 一种基于临界折射纵波检测的表面应力分布云图构建方法 |
| CN116431278A (zh) * | 2023-03-15 | 2023-07-14 | 航天科工网络信息发展有限公司 | 一种支持多存储的云平台镜像管理系统 |
| CN119892855B (zh) * | 2024-12-03 | 2026-05-26 | 天翼云科技有限公司 | 一种云平台存储系统、方法、设备及介质 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102932415A (zh) * | 2012-09-26 | 2013-02-13 | 东软集团股份有限公司 | 一种镜像文件存储方法及装置 |
| US20130332575A1 (en) * | 2012-06-11 | 2013-12-12 | Zerodesktop, Inc. | Efficient data transfer for cloud storage by centralized management of access tokens |
| CN105306525A (zh) * | 2015-09-11 | 2016-02-03 | 浪潮集团有限公司 | 一种数据布局的方法、装置和系统 |
| CN106201338A (zh) * | 2016-06-28 | 2016-12-07 | 华为技术有限公司 | 数据存储方法及装置 |
| CN106487894A (zh) * | 2016-10-13 | 2017-03-08 | 安徽鼎集信息科技有限公司 | 一种数据共享平台 |
Family Cites Families (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101636722B (zh) * | 2007-03-20 | 2013-01-30 | 李尚奎 | 可移动的虚拟机映像 |
| US8788379B1 (en) * | 2007-12-21 | 2014-07-22 | Amazon Technologies, Inc. | Providing configurable pricing for execution of software images |
| US8352941B1 (en) | 2009-06-29 | 2013-01-08 | Emc Corporation | Scalable and secure high-level storage access for cloud computing platforms |
| CN102035662A (zh) * | 2009-09-27 | 2011-04-27 | 中国移动通信集团公司 | 一种虚拟服务器管理系统、方法及装置 |
| US8381211B2 (en) * | 2010-04-26 | 2013-02-19 | International Business Machines Corporation | Virtual image overloading for solution deployment |
| US8473587B1 (en) * | 2010-05-20 | 2013-06-25 | Gogrid, LLC | System and method for caching server images in a hosting system |
| US8850429B2 (en) * | 2010-10-05 | 2014-09-30 | Citrix Systems, Inc. | Load balancing in multi-server virtual workplace environments |
| US8793684B2 (en) * | 2011-03-16 | 2014-07-29 | International Business Machines Corporation | Optimized deployment and replication of virtual machines |
| US9058196B2 (en) * | 2011-04-12 | 2015-06-16 | Red Hat Israel, Ltd. | Host machine level template caching in virtualization environments |
| US9244933B2 (en) * | 2011-04-29 | 2016-01-26 | International Business Machines Corporation | Disk image introspection for storage systems |
| US9385918B2 (en) * | 2012-04-30 | 2016-07-05 | Cisco Technology, Inc. | System and method for secure provisioning of virtualized images in a network environment |
| US9563480B2 (en) * | 2012-08-21 | 2017-02-07 | Rackspace Us, Inc. | Multi-level cloud computing system |
| US9009705B2 (en) * | 2012-10-01 | 2015-04-14 | International Business Machines Corporation | Authenticated distribution of virtual machine images |
| US9274818B2 (en) * | 2013-02-06 | 2016-03-01 | International Business Machines Corporation | Reliable and scalable image transfer for data centers with low connectivity using redundancy detection |
| US9448826B2 (en) * | 2013-03-15 | 2016-09-20 | Symantec Corporation | Enforcing policy-based compliance of virtual machine image configurations |
| US10089009B2 (en) * | 2013-04-30 | 2018-10-02 | Inuron | Method for layered storage of enterprise data |
| CN104424013B (zh) * | 2013-08-26 | 2018-03-09 | 国际商业机器公司 | 在计算环境中部署虚拟机的方法和设备 |
| US9537745B1 (en) * | 2014-03-07 | 2017-01-03 | Google Inc. | Distributed virtual machine disk image deployment |
| US20160019317A1 (en) * | 2014-07-16 | 2016-01-21 | Commvault Systems, Inc. | Volume or virtual machine level backup and generating placeholders for virtual machine files |
| US20160026492A1 (en) * | 2014-07-24 | 2016-01-28 | Samsung Electronics Co., Ltd. | Electronic apparatus for executing virtual machine and method for executing virtual machine |
| US20160125059A1 (en) * | 2014-11-04 | 2016-05-05 | Rubrik, Inc. | Hybrid cloud data management system |
| US10310880B2 (en) * | 2014-11-25 | 2019-06-04 | Red Hat, Inc. | Hot-swapping storage pool backend functional modules |
| US10705917B2 (en) * | 2015-06-30 | 2020-07-07 | Veritas Technologies Llc | Consolidated full backup of a restored virtual machine |
| US20170024260A1 (en) * | 2015-07-21 | 2017-01-26 | Cisco Technology, Inc. | Workload migration across cloud providers and data centers |
| CN105471986B (zh) * | 2015-11-23 | 2019-08-20 | 华为技术有限公司 | 一种数据中心建设规模评估方法及装置 |
| US9858105B1 (en) * | 2015-11-24 | 2018-01-02 | Amazon Technologies, Inc. | Service for managing custom virtual machine images |
| US10809998B2 (en) * | 2016-02-12 | 2020-10-20 | Nutanix, Inc. | Virtualized file server splitting and merging |
| US10379922B1 (en) * | 2017-03-24 | 2019-08-13 | Intuit Inc. | Error recovery in a virtual machine-based development environment |
-
2017
- 2017-06-26 CN CN201710493602.9A patent/CN107124473A/zh active Pending
- 2017-07-26 EP EP17875062.6A patent/EP3442201B1/en active Active
- 2017-07-26 WO PCT/CN2017/094496 patent/WO2019000535A1/zh not_active Ceased
- 2017-07-26 US US15/750,105 patent/US10761869B2/en not_active Expired - Fee Related
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20130332575A1 (en) * | 2012-06-11 | 2013-12-12 | Zerodesktop, Inc. | Efficient data transfer for cloud storage by centralized management of access tokens |
| CN102932415A (zh) * | 2012-09-26 | 2013-02-13 | 东软集团股份有限公司 | 一种镜像文件存储方法及装置 |
| CN105306525A (zh) * | 2015-09-11 | 2016-02-03 | 浪潮集团有限公司 | 一种数据布局的方法、装置和系统 |
| CN106201338A (zh) * | 2016-06-28 | 2016-12-07 | 华为技术有限公司 | 数据存储方法及装置 |
| CN106487894A (zh) * | 2016-10-13 | 2017-03-08 | 安徽鼎集信息科技有限公司 | 一种数据共享平台 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20190004844A1 (en) | 2019-01-03 |
| EP3442201A1 (en) | 2019-02-13 |
| EP3442201B1 (en) | 2019-11-06 |
| EP3442201A4 (en) | 2019-02-13 |
| US10761869B2 (en) | 2020-09-01 |
| CN107124473A (zh) | 2017-09-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11079966B2 (en) | Enhanced soft fence of devices | |
| US10664492B2 (en) | Replication of data objects from a source server to a target server | |
| EP3442201B1 (en) | Cloud platform construction method and cloud platform | |
| US9558194B1 (en) | Scalable object store | |
| US8484655B2 (en) | Management of copy services relationships via policies specified on resource groups | |
| US10922303B1 (en) | Early detection of corrupt data partition exports | |
| US9948711B2 (en) | Allocating and managing cloud computing resources for disaster recovery | |
| US20150302071A1 (en) | Cloud Based Data Migration and Replication | |
| US20200026786A1 (en) | Management and synchronization of batch workloads with active/active sites using proxy replication engines | |
| US20160342349A1 (en) | Determining adjustments of storage device timeout values based on synchronous or asynchronous remote copy state | |
| US10616134B1 (en) | Prioritizing resource hosts for resource placement | |
| US10515228B2 (en) | Commit and rollback of data streams provided by partially trusted entities | |
| WO2014205357A1 (en) | Resource silos at network-accessible services | |
| CN108319618B (zh) | 一种分布式存储系统的数据分布控制方法、系统及装置 | |
| US10558373B1 (en) | Scalable index store | |
| US20230259431A1 (en) | Quick disaster recovery in distributed computing environment | |
| US10120598B2 (en) | Validation of write data subsequent to destaging to auxiliary storage for completion of peer to peer remote copy | |
| US12141461B2 (en) | Integrating mirrored storage to remote replication site | |
| US11853585B2 (en) | Performing a point-in-time snapshot copy operation within a data consistency application | |
| CN113553314A (zh) | 一种超融合系统的服务处理方法、装置、设备及介质 | |
| US11121981B1 (en) | Optimistically granting permission to host computing resources | |
| CN122019095A (zh) | 空闲计算资源的确定方法、装置及产品 | |
| CN119520531A (zh) | 一种缩量更改云服务器规格的方法、装置及相关组件 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| WWE | Wipo information: entry into national phase |
Ref document number: 2017875062 Country of ref document: EP |
|
| ENP | Entry into the national phase |
Ref document number: 2017875062 Country of ref document: EP Effective date: 20180808 |
|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 17875062 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |