CN114020457A - OpenStack deployment method and device and electronic equipment - Google Patents
OpenStack deployment method and device and electronic equipment Download PDFInfo
- Publication number
- CN114020457A CN114020457A CN202111272797.7A CN202111272797A CN114020457A CN 114020457 A CN114020457 A CN 114020457A CN 202111272797 A CN202111272797 A CN 202111272797A CN 114020457 A CN114020457 A CN 114020457A
- Authority
- CN
- China
- Prior art keywords
- storage
- back end
- openstack
- target
- service
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 57
- 238000003860 storage Methods 0.000 claims abstract description 322
- 238000003032 molecular docking Methods 0.000 claims abstract description 49
- 238000012384 transportation and delivery Methods 0.000 claims abstract description 40
- 238000004519 manufacturing process Methods 0.000 claims abstract description 38
- 238000012545 processing Methods 0.000 claims description 13
- 238000002955 isolation Methods 0.000 abstract description 12
- 210000001503 joint Anatomy 0.000 abstract description 4
- 230000008569 process Effects 0.000 description 9
- 238000010586 diagram Methods 0.000 description 7
- 238000007726 management method Methods 0.000 description 7
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 239000011230 binding agent Substances 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 239000003818 cinder Substances 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000004069 differentiation Effects 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000013439 planning Methods 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
- G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
- G06F9/44526—Plug-ins; Add-ons
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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/5072—Grid computing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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/4557—Distribution of virtual machine instances; Migration and load balancing
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Mathematical Physics (AREA)
- Stored Programmes (AREA)
Abstract
The application provides an OpenStack deployment method, an OpenStack deployment device and electronic equipment, wherein the method comprises the following steps: acquiring production delivery environment information of OpenStack to be deployed; determining a target storage back end to be docked of each block storage service component in OpenStack to be deployed according to production delivery environment information; and configuring the corresponding block storage service component of the target storage back end according to the storage type and the docking configuration parameters of the target storage back end, so that the target storage back end is only accessed by the block storage service component. According to the method provided by the scheme, the block storage service components are configured differently according to the production delivery environment information of the OpenStack to be deployed, so that the butt joint relation between the block storage service components and the target storage back end is established, the deployed OpenStack is suitable for the production delivery environment with network isolation, and a foundation is laid for further improving the information security of the storage back end.
Description
Technical Field
The application relates to the technical field of cloud computing, in particular to an OpenStack deployment method, an OpenStack deployment device and electronic equipment.
Background
With the continuous development of cloud computing technology, various large enterprises have gradually used private clouds to replace traditional data centers, and meanwhile, OpenStack has been widely applied as a cloud computing management platform, so how to deploy the OpenStack cloud computing management platform becomes a hotspot research content.
In the prior art, a block storage service shader component in OpenStack is generally deployed with configuration information of all storage backend of cloud computing, that is, a user can access all storage backend of cloud computing based on any block storage service shader component.
However, since information security is increasingly emphasized nowadays, there may be a requirement for network isolation between different storage back ends in the current OpenStack production delivery environment, and in such a production delivery environment, if an OpenStack cloud computing management platform is deployed based on the prior art, a large number of block storage service circular components may have a storage back end access error.
Disclosure of Invention
The application provides an OpenStack deployment method, an OpenStack deployment device and electronic equipment, and aims to overcome the defects that an OpenStack cloud computing management platform deployment method in the prior art is not suitable for a production delivery environment with network isolation and the like.
A first aspect of the present application provides an OpenStack deployment method, including:
acquiring production delivery environment information of OpenStack to be deployed;
determining a target storage back end to be docked of each block storage service component in the OpenStack to be deployed according to the production delivery environment information;
and configuring the corresponding block storage service component of the target storage back end according to the storage type and the docking configuration parameters of the target storage back end, so that the target storage back end is only accessed by the block storage service component.
Optionally, before configuring the block storage service component corresponding to the target storage back-end according to the storage type and the docking configuration parameter of the target storage back-end, the method further includes:
containerization processing is performed on each chunk store service component to deploy the chunk store service component as a chunk store service POD for K8S on top of K8S.
Optionally, the configuring, according to the storage type and the docking configuration parameter of the target storage back end, the block storage service component corresponding to the target storage back end includes:
installing a target client tool and a target storage driver to a corresponding block storage service (POD) according to the storage type of the target storage back end;
and according to the docking configuration parameters of the target storage back end, docking configuration is carried out on the block storage service POD and the target storage back end, so that a to-be-deployed block storage service POD which is in docking configuration with the target storage back end is obtained.
Optionally, the performing, according to the docking configuration parameter of the target storage backend, docking configuration on the block storage service POD and the target storage backend includes:
acquiring global default configuration parameters of the POD;
and adjusting the global default configuration parameters of the POD according to the docking configuration parameters of the target storage back end.
Optionally, the method further includes:
acquiring a container mirror image of the storage service POD of the block to be deployed;
starting the storage service POD to be deployed at a target node based on the container image of the storage service POD to be deployed so as to deploy the storage service POD to the target node.
Optionally, the method further includes:
and performing containerization processing on other service components except the block storage service component in the OpenStack to be deployed so as to deploy the other service components on the K8S as other service PODs of K8S.
Optionally, the method further includes:
acquiring a container image of the other service PODs;
and starting the other service PODs at the target nodes based on the container images of the other service PODs so as to deploy the other service PODs to the target nodes.
A second aspect of the present application provides an OpenStack deployment device, including:
the acquiring module is used for acquiring the production delivery environment information of OpenStack to be deployed;
the determining module is used for determining a target storage back end to be docked of each block storage service component in the OpenStack to be deployed according to the production delivery environment information;
and the deployment module is used for configuring the block storage service component corresponding to the target storage back end according to the storage type and the docking configuration parameters of the target storage back end, so that the target storage back end is only accessed by the block storage service component.
Optionally, the apparatus further comprises:
and the containerization processing module is used for carrying out containerization processing on each chunk storage service component so as to deploy the chunk storage service component on the K8S as a chunk storage service POD of K8S.
Optionally, the deployment module is specifically configured to:
installing a target client tool and a target storage driver to a corresponding block storage service (POD) according to the storage type of the target storage back end;
and according to the docking configuration parameters of the target storage back end, docking configuration is carried out on the block storage service POD and the target storage back end, so that a to-be-deployed block storage service POD which is in docking configuration with the target storage back end is obtained.
Optionally, the deployment module is specifically configured to:
acquiring global default configuration parameters of the POD;
and adjusting the global default configuration parameters of the POD according to the docking configuration parameters of the target storage back end.
Optionally, the deployment module is specifically configured to:
acquiring a container mirror image of the storage service POD of the block to be deployed;
starting the storage service POD to be deployed at a target node based on the container image of the storage service POD to be deployed so as to deploy the storage service POD to the target node.
Optionally, the deployment module is further configured to:
and performing containerization processing on other service components except the block storage service component in the OpenStack to be deployed so as to deploy the other service components on the K8S as other service PODs of K8S.
Optionally, the deployment module is further configured to:
acquiring a container image of the other service PODs;
and starting the other service PODs at the target nodes based on the container images of the other service PODs so as to deploy the other service PODs to the target nodes.
A third aspect of the present application provides an electronic device, comprising: at least one processor and memory;
the memory stores computer-executable instructions;
the at least one processor executes computer-executable instructions stored by the memory to cause the at least one processor to perform the method as set forth in the first aspect above and in various possible designs of the first aspect.
A fourth aspect of the present application provides a computer-readable storage medium having stored thereon computer-executable instructions that, when executed by a processor, implement a method as set forth in the first aspect and various possible designs of the first aspect.
This application technical scheme has following advantage:
the application provides an OpenStack deployment method, an OpenStack deployment device and electronic equipment, wherein the method comprises the following steps: acquiring production delivery environment information of OpenStack to be deployed; determining a target storage back end to be docked of each block storage service component in OpenStack to be deployed according to production delivery environment information; and configuring the corresponding block storage service component of the target storage back end according to the storage type and the docking configuration parameters of the target storage back end, so that the target storage back end is only accessed by the block storage service component. According to the method provided by the scheme, the block storage service components are configured differently according to the production delivery environment information of the OpenStack to be deployed, so that the butt joint relation between the block storage service components and the target storage back end is established, the deployed OpenStack is suitable for the production delivery environment with network isolation, and a foundation is laid for further improving the information security of the storage back end.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present application, and other drawings can be obtained by those skilled in the art according to these drawings.
Fig. 1 is a schematic structural diagram of an OpenStack deployment system based on the embodiment of the present application;
fig. 2 is a schematic flowchart of an OpenStack deployment method according to an embodiment of the present application;
fig. 3 is a schematic structural diagram of an OpenStack deployment device according to an embodiment of the present application;
fig. 4 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
With the above figures, there are shown specific embodiments of the present application, which will be described in more detail below. These drawings and written description are not intended to limit the scope of the disclosed concepts in any way, but rather to illustrate the concepts of the disclosure to those skilled in the art by reference to specific embodiments.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
Furthermore, the terms "first", "second", etc. are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. In the description of the following examples, "plurality" means two or more unless specifically limited otherwise.
In the prior art, a block storage service shader component in OpenStack is generally deployed with configuration information of all storage backend of cloud computing, that is, a user can access all storage backend of cloud computing based on any block storage service shader component. However, since information security is increasingly emphasized nowadays, there may be a requirement for network isolation between different storage backend in the current OpenStack production delivery environment, and in such a production delivery environment, if an OpenStack cloud computing management platform is deployed based on the prior art, a current block storage service component may access a storage backend provided with network isolation, and at this time, a storage backend access error report situation will occur for the current block storage service component. In addition, the OpenStack block storage service component binder needs to interface a storage back end to provide a virtual machine and data storage for cloud computing, Ceph distributed storage and FC centralized storage are commonly stored in a data center production delivery scene, storage devices purchased by a large-scale data center may come from multiple companies and have different types, and thus, a set of OpenStack cloud platform is required to support flexible configuration of multiple sets of back end storage and to achieve differentiated configuration.
In order to solve the above problems, the OpenStack deployment method, the OpenStack deployment device, and the electronic device provided in the embodiments of the present application acquire production delivery environment information of an OpenStack to be deployed; determining a target storage back end to be docked of each block storage service component in OpenStack to be deployed according to production delivery environment information; and configuring the corresponding block storage service component of the target storage back end according to the storage type and the docking configuration parameters of the target storage back end, so that the target storage back end is only accessed by the block storage service component. According to the method provided by the scheme, the block storage service components are configured differently according to the production delivery environment information of the OpenStack to be deployed, so that the butt joint relation between the block storage service components and the target storage back end is established, the deployed OpenStack is suitable for the production delivery environment with network isolation, and a foundation is laid for further improving the information security of the storage back end.
The following several specific embodiments may be combined with each other, and details of the same or similar concepts or processes may not be repeated in some embodiments. Embodiments of the present invention will be described below with reference to the accompanying drawings.
First, a structure of an OpenStack deployment system based on the present application is described:
the OpenStack deployment method, the OpenStack deployment device, and the electronic device provided in the embodiments of the present application are suitable for deploying OpenStack for a cloud computing platform, and as shown in fig. 1, the OpenStack deployment system based on the embodiments of the present application is a schematic structural diagram, and mainly includes an OpenStack to be deployed, a storage backend, and an OpenStack deployment device, where the OpenStack deployment device may be deployed at an OpenStack deployment node of the cloud computing platform. Specifically, the OpenStack deployment device performs differential docking deployment on the block storage service component in the OpenStack and the storage backend according to the production delivery environment information of the OpenStack to be deployed, so that the deployed OpenStack can be applicable to the current production delivery environment.
The embodiment of the application provides an OpenStack deployment method, which is used for deploying OpenStack for a cloud computing platform. The execution subject of the embodiment of the present application is an electronic device, such as a server, a desktop computer, a notebook computer, a tablet computer, and other electronic devices that can be used to deploy OpenStack.
As shown in fig. 2, a schematic flow diagram of an OpenStack deployment method provided in an embodiment of the present application is shown, where the method includes:
It should be noted that an OpenStack production delivery environment generally has a requirement that one cluster interfaces multiple sets of storage back ends, where different storage back ends may have a requirement for network isolation, and the generated delivery environment information at least includes network isolation information of an OpenStack to be deployed.
For example, different storage backend may correspond to different enterprises, and in order to ensure confidentiality of cloud computing data of an enterprise, network isolation of the storage backend corresponding to the enterprise may be preset, such as opening only all block storage service components of the enterprise.
Specifically, the target storage back end to be docked with each block storage service component in the OpenStack to be deployed may be determined according to the correspondence between the storage back end and the block storage service component reflected by the production delivery environment information.
Specifically, the corresponding block storage service component of the target storage back end is configured according to the storage type and the docking configuration parameters of the target storage back end, so that the block storage service component has an access interface of the target storage back end, and it is ensured that only the block storage service component of all the block storage service components has the access interface of the target storage back end at this time, that is, the data storage of other block storage service components does not fall to the target storage back end, and the condition that the access of the storage back end fails due to network isolation does not occur.
Illustratively, after the OpenStack deployment work is completed, one OpenStack may simultaneously support interfacing multiple sets of storage, for example, simultaneously support interfacing Ceph distributed storage 01, Ceph distributed storage 02, FC centralized storage 01, and FC centralized storage 02, a block storage service component at Node01 may only access Ceph distributed storage 01, Ceph distributed storage 02, and FC centralized storage 01, and a block storage service component at Node02 may only access FC centralized storage 02. At this time, the Node01 Node block stores docking configuration information of the service POD configuration Ceph01, Ceph02, and FC01, and the Node02 Node block stores docking configuration information of the service POD configuration FC 01.
On the basis of the foregoing embodiments, in order to ensure the security of the OpenStack deployment process, as an implementable manner, on the basis of the foregoing embodiments, in an embodiment, before configuring a corresponding block storage service component according to a storage type and a docking configuration parameter of a target storage backend, a containerization process may be performed on each block storage service component, so as to deploy the block storage service component as a block storage service POD of K8S on the K8S.
It should be noted that K8S is fully called kubernets, and is an application for managing containerization on multiple hosts in a cloud computing platform, and the goal of kubernets is to simply and efficiently deploy containerization applications, which provides a mechanism for application deployment, planning, updating, and maintenance. The POD is the smallest schedulable atomic unit in kubernets, one POD can contain a plurality of containers, and the block storage service POD refers to a block storage service component subjected to containerization processing, namely an application container corresponding to the block storage service component.
The specific containerization process may refer to the prior art, which is not limited in the embodiments of the present application.
On the basis of the foregoing embodiment, as an implementable manner, in an embodiment, configuring a block storage service component corresponding to a target storage backend according to a storage type and a docking configuration parameter of the target storage backend includes:
step 2031, according to the storage type of the target storage back end, installing the target client tool and the target storage driver to the corresponding block storage service POD;
step 2032, according to the docking configuration parameters of the target storage back end, docking configuration is performed on the block storage service POD and the target storage back end, so as to obtain a to-be-deployed block storage service POD which completes the docking configuration with the target storage back end.
The client tool is typically an rmp installation package, and the storage driver is typically python code.
Specifically, it may be determined whether a corresponding client tool needs to be installed according to the storage type of the target storage backend, for example, when the storage type of the target storage backend is Ceph distributed storage, install the corresponding Ceph client tool to the chunk storage service POD; when the storage type of the target storage backend is FC storage, the client tool is not needed, but whatever the storage type is, the corresponding storage driver (target driver) needs to be installed to the block storage service POD.
Specifically, in an embodiment, a global default configuration parameter of a block storage service POD may be acquired; and adjusting the global default configuration parameters of the POD according to the docking configuration parameters of the target storage back end.
It should be noted that the sender service (block storage service) specifies that the storage backend can read corresponding backend configuration information (docking configuration parameters), and can implement docking between the storage driver and the docking configuration, and the configuration information of the block storage service includes global default configuration parameters and custom storage configuration block parameters, and controls which storage backend the node POD (block storage service POD) docks by changing the global default configuration parameters.
For example, if a global default configuration default _ backups is defined, and the value of which configures Ceph01 to enable storage of backend parameters, then custom storage configuration block parameters can be maintained under the Ceph01 configuration module, wherein the enabled _ backups values are separated by commas when multiple sets of storage backend are interfaced. Wherein, the global default configuration default _ enabled _ backings _ node01 is defined as the differentiated configuration of node01 node POD (current block storage service POD), and other nodes are configured similarly. The priority of the enabled _ backups _ node01 is higher than that of the enabled _ backups, and when the POD of the node is started, the enabled _ backups _ node01 value is used for replacing the enabled _ backups value, so that the differential configuration of different nodes is completed. Otherwise, if there is a storage cluster with access failure, it may cause a failure of OpenStack creating storage resources, the OpenStack creating storage resources may specify a storage backend type, and the purpose of the differential configuration is to ensure that a task of OpenStack creating storage resources can only be issued to a POD configured with a modified backend type by the node POD service enabled _ backups parameter, and the configuration is as follows:
on the basis of the foregoing embodiment, in order to improve the deployment efficiency of OpenStack, as an implementable manner, on the basis of the foregoing embodiment, in an embodiment, a container mirror image of a to-be-deployed block storage service POD may be acquired; and starting the storage service POD to be deployed at the target node based on the container image of the storage service POD to be deployed so as to deploy the storage service POD to the target node.
It should be noted that each component deployment process will pull the corresponding component image to start the corresponding service POD, and the container image management may use a hardor or registration tool, etc.
Similarly, in an embodiment, other service components except for the block storage service component in the OpenStack to be deployed may be subjected to containerization processing, so that the other service components are deployed on the K8S as other service PODs of K8S.
Further, container images of other service PODs may be obtained as well; and starting the other service PODs at the target node based on the container images of the other service PODs so as to deploy the other service PODs to the target node.
In order to further improve the deployment efficiency of the OpenStack, multi-storage hell characters files, idle playlist files and the like can be deployed and docked in a one-click mode. The device comprises a help files, a backup files, a storage server, a container, a POD (container management server), a storage script and a docking storage configuration, wherein the help files are deployment files written by OpenStack On K8s and used for deploying K8s application, the ansable files are used for abstracting and assigning charts variables and one-key deployment, the types of a chunk storage server volume and a backup component POD controller are deployment files, the hostpath mode in the POD pulling process loads a storage client and drives the storage client to the container from a host, the initialization script is executed after the POD is pulled up, a corresponding target client tool and a corresponding target storage driver are installed to the POD, and the docking storage configuration is hung to the corresponding POD in a K8s Secrets object mode. Meanwhile, a back-end parameter enabled _ backups _ node01 can be configured and stored according to the differentiation of the node host names: and the 'Ceph 01' executes an initialization script after the POD is pulled up to determine whether the differentiated configuration is available according to the configuration parameter of the node name matching enabled _ backups _ node01 where the POD is located, wherein the 'Ceph 01' represents that the storage rear end of the POD of the node01 in the differentiated configuration is Ceph01, and other PODs without the differentiated configuration take the storage rear end configured by the enabled _ backups parameter as the reference.
For example, perform deployment and configuration change order:
bash deploy.sh-m openstack-t cinder
specifically, in an embodiment, in order to ensure that OpenStack to be deployed can be deployed normally, in the process of deploying service PODs, the deployment condition of each service POD may be monitored to determine whether all service PODs are deployed normally, and if a service POD that fails to be deployed occurs, corresponding alarm information is generated.
According to the OpenStack deployment method, production delivery environment information of OpenStack to be deployed is obtained; determining a target storage back end to be docked of each block storage service component in OpenStack to be deployed according to production delivery environment information; and configuring the corresponding block storage service component of the target storage back end according to the storage type and the docking configuration parameters of the target storage back end, so that the target storage back end is only accessed by the block storage service component. According to the method provided by the scheme, the block storage service components are configured differently according to the production delivery environment information of the OpenStack to be deployed, so that the butt joint relation between the block storage service components and the target storage back end is established, the deployed OpenStack is suitable for the production delivery environment with network isolation, and a foundation is laid for further improving the information security of the storage back end. Moreover, the OpenStack deployment and configuration storage back end can be more flexible and convenient, the storage back end is configured for the POD of the block storage service of different nodes in a differentiated mode, and the working efficiency of deployment delivery is effectively improved.
An OpenStack deployment device is provided in an embodiment of the present application, and is configured to execute the OpenStack deployment method provided in the foregoing embodiment.
Fig. 3 is a schematic structural diagram of an OpenStack deployment device provided in the embodiment of the present application. The OpenStack deployment device 30 includes an obtaining module 301, a determining module 302, and a deploying module 303.
The system comprises an acquisition module, a deployment module and a deployment module, wherein the acquisition module is used for acquiring the production delivery environment information of OpenStack to be deployed; the determining module is used for determining a target storage back end to be docked of each block storage service component in OpenStack to be deployed according to the production delivery environment information; and the deployment module is used for configuring the block storage service component corresponding to the target storage back end according to the storage type and the docking configuration parameters of the target storage back end, so that the target storage back end is only accessed by the block storage service component.
Specifically, in one embodiment, the apparatus further comprises:
and the containerization processing module is used for carrying out containerization processing on each chunk storage service component so as to deploy the chunk storage service component on the K8S as a chunk storage service POD of K8S.
Specifically, in an embodiment, the deployment module is specifically configured to:
installing a target client tool and a target storage driver to a corresponding block storage service (POD) according to the storage type of the target storage back end;
and according to the docking configuration parameters of the target storage back end, docking configuration is carried out on the block storage service POD and the target storage back end, so that a to-be-deployed block storage service POD which is in docking configuration with the target storage back end is obtained.
Specifically, in an embodiment, the deployment module is specifically configured to:
acquiring global default configuration parameters of a block storage service (POD);
and adjusting the global default configuration parameters of the POD according to the docking configuration parameters of the target storage back end.
Specifically, in an embodiment, the deployment module is specifically configured to:
acquiring a container mirror image of a storage service (POD) of a block to be deployed;
and starting the storage service POD to be deployed at the target node based on the container image of the storage service POD to be deployed so as to deploy the storage service POD to the target node.
Specifically, in an embodiment, the deployment module is further configured to:
and performing containerization processing on other service components except the block storage service component in the OpenStack to be deployed so as to deploy the other service components as other service PODs of K8S on K8S.
Specifically, in an embodiment, the deployment module is further configured to:
acquiring container images of other service PODs;
and starting the other service PODs at the target node based on the container images of the other service PODs so as to deploy the other service PODs to the target node.
With regard to the OpenStack deployment device in the present embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment related to the method, and will not be elaborated here.
The OpenStack deployment device provided in the embodiment of the present application is configured to execute the OpenStack deployment method provided in the above embodiment, and an implementation manner and a principle of the OpenStack deployment device are the same and are not described again.
An embodiment of the present application provides an electronic device, which is configured to execute the OpenStack deployment method provided in the foregoing embodiment.
Fig. 4 is a schematic structural diagram of an electronic device according to an embodiment of the present application. The electronic device 40 includes: at least one processor 41 and memory 42;
the memory stores computer-executable instructions; the at least one processor executes the memory-stored computer-executable instructions to cause the at least one processor to perform the OpenStack deployment method provided by the above embodiments.
The electronic device provided in the embodiment of the present application is configured to execute the OpenStack deployment method provided in the above embodiment, and an implementation manner and a principle of the electronic device are the same and are not described again.
An embodiment of the present application provides a computer-readable storage medium, where a computer execution instruction is stored in the computer-readable storage medium, and when a processor executes the computer execution instruction, the OpenStack deployment method provided in any embodiment above is implemented.
The storage medium containing the computer-executable instructions of the embodiments of the present application may be used to store the computer-executable instructions of the OpenStack deployment method provided in the foregoing embodiments, and an implementation manner and a principle thereof are the same, and are not described again.
In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, a division of a unit is merely a logical division, and an actual implementation may have another division, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
Units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, or in a form of hardware plus a software functional unit.
The integrated unit implemented in the form of a software functional unit may be stored in a computer readable storage medium. The software functional unit is stored in a storage medium and includes several instructions to enable a computer device (which may be a personal computer, a server, or a network device) or a processor (processor) to execute some steps of the methods according to the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.
It is obvious to those skilled in the art that, for convenience and simplicity of description, the foregoing division of the functional modules is merely used as an example, and in practical applications, the above function distribution may be performed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to perform all or part of the above described functions. For the specific working process of the device described above, reference may be made to the corresponding process in the foregoing method embodiment, which is not described herein again.
Finally, it should be noted that: the above embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.
Claims (10)
1. An OpenStack deployment method, comprising:
acquiring production delivery environment information of OpenStack to be deployed;
determining a target storage back end to be docked of each block storage service component in the OpenStack to be deployed according to the production delivery environment information;
and configuring the corresponding block storage service component of the target storage back end according to the storage type and the docking configuration parameters of the target storage back end, so that the target storage back end is only accessed by the block storage service component.
2. The method of claim 1, wherein before configuring the corresponding block storage service component of the target storage backend according to the storage type and the docking configuration parameters of the target storage backend, the method further comprises:
containerization processing is performed on each chunk store service component to deploy the chunk store service component as a chunk store service POD for K8S on top of K8S.
3. The method of claim 2, wherein the configuring the block storage service component corresponding to the target storage backend according to the storage type and the docking configuration parameters of the target storage backend comprises:
installing a target client tool and a target storage driver to a corresponding block storage service (POD) according to the storage type of the target storage back end;
and according to the docking configuration parameters of the target storage back end, docking configuration is carried out on the block storage service POD and the target storage back end, so that a to-be-deployed block storage service POD which is in docking configuration with the target storage back end is obtained.
4. The method according to claim 3, wherein the docking configuration of the block storage service POD with the target storage backend according to the docking configuration parameters of the target storage backend comprises:
acquiring global default configuration parameters of the POD;
and adjusting the global default configuration parameters of the POD according to the docking configuration parameters of the target storage back end.
5. The method of claim 3, further comprising:
acquiring a container mirror image of the storage service POD of the block to be deployed;
starting the storage service POD to be deployed at a target node based on the container image of the storage service POD to be deployed so as to deploy the storage service POD to the target node.
6. The method of claim 1, further comprising:
and performing containerization processing on other service components except the block storage service component in the OpenStack to be deployed so as to deploy the other service components on the K8S as other service PODs of K8S.
7. The method of claim 6, further comprising:
acquiring a container image of the other service PODs;
and starting the other service PODs at the target nodes based on the container images of the other service PODs so as to deploy the other service PODs to the target nodes.
8. An OpenStack deployment device, comprising:
the acquiring module is used for acquiring the production delivery environment information of OpenStack to be deployed;
the determining module is used for determining a target storage back end to be docked of each block storage service component in the OpenStack to be deployed according to the production delivery environment information;
and the deployment module is used for configuring the block storage service component corresponding to the target storage back end according to the storage type and the docking configuration parameters of the target storage back end, so that the target storage back end is only accessed by the block storage service component.
9. An electronic device, comprising: at least one processor and memory;
the memory stores computer-executable instructions;
the at least one processor executing the computer-executable instructions stored by the memory causes the at least one processor to perform the method of any of claims 1-7.
10. A computer-readable storage medium having computer-executable instructions stored thereon which, when executed by a processor, implement the method of any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111272797.7A CN114020457A (en) | 2021-10-29 | 2021-10-29 | OpenStack deployment method and device and electronic equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111272797.7A CN114020457A (en) | 2021-10-29 | 2021-10-29 | OpenStack deployment method and device and electronic equipment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114020457A true CN114020457A (en) | 2022-02-08 |
Family
ID=80058945
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111272797.7A Pending CN114020457A (en) | 2021-10-29 | 2021-10-29 | OpenStack deployment method and device and electronic equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114020457A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117032905A (en) * | 2023-10-09 | 2023-11-10 | 天津卓朗昆仑云软件技术有限公司 | Method and system for associating container cluster with block storage and virtual machine |
-
2021
- 2021-10-29 CN CN202111272797.7A patent/CN114020457A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117032905A (en) * | 2023-10-09 | 2023-11-10 | 天津卓朗昆仑云软件技术有限公司 | Method and system for associating container cluster with block storage and virtual machine |
| CN117032905B (en) * | 2023-10-09 | 2024-01-23 | 天津卓朗昆仑云软件技术有限公司 | Method and system for associating container cluster with block storage and virtual machine |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20230138736A1 (en) | Cluster file system-based data backup method and apparatus, and readable storage medium | |
| US8843717B2 (en) | Maintaining consistency of storage in a mirrored virtual environment | |
| CN104142847B (en) | Stateless virtual machine and its application under cloud computing environment | |
| CN104866391B (en) | A kind of end message backup method and device based on increment information system | |
| WO2021097397A1 (en) | Container-based application data protection method and system | |
| CN113626286B (en) | Multi-cluster instance processing method and device, electronic equipment and storage medium | |
| US10061665B2 (en) | Preserving management services with self-contained metadata through the disaster recovery life cycle | |
| CN109271172B (en) | Host performance expansion method and device of sweep cluster | |
| CN110377314B (en) | System upgrading method, device, equipment and medium for distributed storage system | |
| US12112187B2 (en) | Scalable visualization of a containerized application in a multiple-cluster environment | |
| CN105635311A (en) | Method for synchronizing resource pool information in cloud management platform | |
| CN110520844A (en) | Cloud management platform, virtual machine management method and its system | |
| CN110941393A (en) | Logical volume management-based LV supply method, device, equipment and medium | |
| CN111371891B (en) | Service processing method, device, equipment and storage medium | |
| CN111290712A (en) | Block device creating method and device, cloud computing management system and storage medium | |
| CN105095103A (en) | Storage device management method and device used for cloud environment | |
| CN115834608B (en) | System and method for realizing stateful service storage data sharing | |
| CN110008004B (en) | Electric power system calculation analysis application virtualization method, device and equipment | |
| CN104517067A (en) | Method, device and system for data access | |
| CN114020457A (en) | OpenStack deployment method and device and electronic equipment | |
| CN115454333A (en) | Docking method and device for cloud computing platform and storage system | |
| CN114490189A (en) | Cloud platform database backup method and device, electronic equipment and storage medium | |
| CN116166413A (en) | Lifecycle management for workloads on heterogeneous infrastructure | |
| CN110058925A (en) | A method of creating virtual machine in cloud computing system | |
| CN117632374A (en) | Container mirror image reading method, medium, device and computing equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |