A method, system, device and storage medium for a cloud host to use a cloud hard disk

Abstract

The application provides a cloud host using a cloud hard disk method, system, device and storage medium, the method comprises formulating an automatic formatting method of the cloud hard disk; the automatic formatting method is used for formatting the cloud hard disk into a partition if the value of a formatting string is not empty when a hard disk is created in cinder; a volume creation workflow is used for executing mounting the cloud hard disk in the cloud host; the cloud hard disk is formatted according to the automatic formatting method when mounting, and then mounted on the cloud host after formatting is completed. Based on the cloud host using the cloud hard disk method, a cloud host using a cloud hard disk system, device and storage medium are also provided, the application connects the mounting and creation processes in series through the formation of a preset scheme, the reading preset scheme is used for creating sensitive operations of the hard disk, and the mounting reading preset scheme is used for completing automatic mounting; and the experience of the user using the cloud hard disk on the cloud host is optimized.

Description

Technical Field

[0001] This invention belongs to the field of server storage technology, and specifically relates to a method, system, device and storage medium for cloud hosts to use cloud hard drives. Background Technology

[0002] For a block device to be used by the operating system and mounted to a directory, it must be formatted with a file system, for example, using `mkfs.xfs` to format the block device and then using `mount` to mount it to a directory. When Cinder creates a disk, if the source is a new type, the cloud disk does not yet have a file system. When OpenStack connects the cloud disk created by Cinder to the host, it only connects the cloud disk to the target cloud host. The cloud disk seen on the cloud host is still a block device without a file system, which means it cannot be used directly. Formatting the cloud disk is necessary for proper mounting and use. Users do not want to manually format the cloud disk; they want the cloud disk to be automatically formatted with a file system and mounted automatically when connected to the cloud host, with a declarative declaration that the cloud disk will be mounted to a specific directory, and this information stored in Cinder's metadata. Cinder: OpenStack Block Storage Service (Cinder) adds persistent storage to virtual machines. Block storage provides an infrastructure for managing volumes and interacting with OpenStack compute services to provide volumes for instances. This service also activates the ability to manage volume snapshots and volume types.

[0003] Currently, users must partition and create a file system on the hard drive before using it. This process is quite cumbersome. First, a cloud hard drive needs to be created using Cinder. Then, this empty cloud hard drive needs to be mounted to the target cloud host. Next, the user needs to access the cloud host, locate the corresponding block device, and format it as desired. Only after formatting is complete can the cloud hard drive be used normally. (See below.) Figure 1 The flowchart of the existing cloud server using cloud disk is presented. The whole process requires users to be very familiar with the relevant operations of the file system. Some users are not familiar with these operations, and formatting the disk is a high-risk and sensitive operation. If users rashly perform these actions without understanding these operations, it will cause devastating damage to the data on the disk. In order to avoid these high-risk actions, it is hoped that OpenStack can assist in the process. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention proposes a method, system, device, and storage medium for using cloud disks on cloud servers. This avoids accidental data loss caused by manual operation of cloud disks, optimizes the user experience of using cloud disks on cloud servers, and reduces the number of times users need to perform sensitive operations on cloud disks on cloud servers.

[0005] To achieve the above objectives, the present invention adopts the following technical solution:

[0006] A method for using cloud disks on a cloud server includes the following steps:

[0007] Define an automatic formatting method for cloud disks; the automatic formatting method is to format the cloud disk as a partition if the value of the format string is not empty when the disk is created in Cinder;

[0008] The workflow for creating a volume is used to mount a cloud disk on a cloud host; during mounting, the disk is formatted according to the automatic formatting method described above, and then mounted onto the cloud host after formatting is complete.

[0009] Furthermore, the process of formulating the automatic formatting method for the cloud disk includes: pre-setting the automatic formatting method in the metadata of the Cinder volume, setting the key value of the metadata to a fixed formatting character, and determining whether a formatting operation is needed by judging whether the value of the formatting character is empty.

[0010] Furthermore, the method for formatting the cloud disk as a partition is to use the parted command to format the disk as a partition.

[0011] Furthermore, the process of creating a volume includes: parsing the parsing response request sent by the client via API, and invoking the Cinder scheduler via a remote procedure call protocol; the Cinder scheduler generates a workflow for creating the volume using information about the scheduling node.

[0012] Furthermore, the process of mounting a cloud disk on a cloud host includes:

[0013] Cinder requests a cloud disk from the backend storage cluster. If the cloud disk has a source, it checks whether the format string in the cloud disk metadata field is empty. If it is not empty, it reads the file system in the pre-defined automatic formatting method of the cloud disk.

[0014] Determine whether the host operating system supports the file system. If it does, mount the cloud disk to the host machine.

[0015] Then, the cloud disk is formatted using the automatic formatting method described above, and the cloud disk is uninstalled.

[0016] Furthermore, the process of mounting the formatted data to the cloud server includes:

[0017] If the value of the format character is not empty, determine whether mounting is required based on the mount directory;

[0018] Determine if the cloud server supports the gqa tool. If it does, find the corresponding drive letter of the cloud disk and mount the cloud disk.

[0019] This invention also proposes a system for cloud hosts to use cloud disks, including a design module and a mounting module;

[0020] The specified module is used to specify the automatic formatting method for the cloud disk; the automatic formatting method is to format the cloud disk as a partition if the value of the format string is not empty when the disk is created in Cinder.

[0021] The mounting module is used to create volumes and executes the process of mounting cloud disks on cloud hosts. During mounting, the disks are formatted according to the automatic formatting method, and then mounted to the cloud host after formatting is complete.

[0022] Furthermore, the process executed by the formulation module is as follows: the automatic formatting method is set in the metadata of cindervolume in advance, the key value of the metadata is set to a fixed formatting character, and whether a formatting operation is needed is determined by judging whether the value of the formatting character is empty.

[0023] The present invention also proposes an apparatus comprising:

[0024] Memory, used to store computer programs;

[0025] A processor for implementing the steps of the method when executing the computer program.

[0026] The present invention also proposes a readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the method described.

[0027] The effects described in the invention are merely those of the embodiments, and not all the effects of the invention. One of the above technical solutions has the following advantages or beneficial effects:

[0028] This invention proposes a method, system, device, and storage medium for using cloud disks on a cloud host. The method includes defining an automatic formatting method for the cloud disk; the automatic formatting method involves formatting the cloud disk as a partition when the disk is created in Cinder if the format string value is not empty; the volume creation workflow is used to mount the cloud disk on the cloud host; during mounting, the disk is formatted according to the automatic formatting method, and then mounted to the cloud host after formatting. The process of defining the automatic formatting method for the cloud disk includes: pre-setting the automatic formatting method in the metadata of the Cinder volume, setting the metadata key value to a fixed formatting character, and determining whether a formatting operation is needed by checking if the formatting character value is empty. This invention links the mounting and creation processes through a preset scheme. Creation reads the preset scheme to complete sensitive disk operations, and mounting reads the preset scheme to complete automatic mounting. This eliminates the need for users to format the disk again after mounting, reducing the complexity of understanding and operating disk partitions and file systems, and lowering the possibility of problems arising from manual disk handling.

[0029] This invention avoids accidental data loss caused by manual operation of cloud disks, optimizes the user experience of using cloud disks on cloud hosts, and reduces the number of times users need to perform sensitive operations on cloud disks on cloud hosts.

[0030] This invention provides a quick and convenient way for non-system administrators to use cloud disks, solving the problem that non-system administrators cannot operate the partitions and file systems of cloud disks. Attached Figure Description

[0031] like Figure 1 Flowchart of methods for using cloud disks on cloud servers in existing technologies

[0032] like Figure 2 This is a flowchart of a method for using cloud disks on a cloud host according to Embodiment 1 of the present invention;

[0033] like Figure 3 This is a schematic diagram of a cloud server using a cloud disk according to Embodiment 2 of the present invention;

[0034] like Figure 4 This is a schematic diagram of a device according to Embodiment 3 of the present invention. Detailed Implementation

[0035] To clearly illustrate the technical features of this solution, the invention will be described in detail below through specific embodiments and in conjunction with the accompanying drawings. The following disclosure provides many different embodiments or examples for implementing different structures of the invention. To simplify the disclosure of the invention, components and arrangements of specific examples are described below. Furthermore, reference numerals and / or letters may be repeated in different examples. This repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed. It should be noted that the components illustrated in the drawings are not necessarily drawn to scale. Descriptions of well-known components, processing techniques, and processes are omitted in this invention to avoid unnecessarily limiting the invention.

[0036] Example 1

[0037] Embodiment 1 of the present invention proposes a method for cloud hosts to use cloud disks. The mounting and creation processes are linked by the formation of a preset scheme. The creation process reads the preset scheme to complete the sensitive operations of the disk, and the mounting process reads the preset scheme to complete the automatic mounting.

[0038] This application addresses the problem in existing technologies where cloud disk mounting requires formatting; otherwise, the cloud disk seen on the cloud host remains a block device without a file system. A computer file system is a method for storing and organizing computer data, facilitating access and retrieval. It uses the abstract logical concepts of files and tree-like directories to replace the data block concept of physical devices like hard drives and optical discs. Users using a file system to save data don't need to worry about the specific data block address on the hard drive (or optical disc); they only need to remember the file's directory and filename. Before writing new data, users don't need to worry about which block address on the hard drive is unused; the file system automatically manages the storage space (allocation and release), and users only need to remember which file the data was written to.

[0039] In this application's solution: First, the process of creating a cloud disk using Cinder is expanded, and the operations for partitioning and formatting files on a blank cloud disk are completed. The purpose of this is to enable users to directly use the disk for read and write operations on the cloud host, avoiding accidental formatting (partitioning) of the disk by non-professionals. When creating a disk in Cinder, we start to partition and plan the file system for the empty disk, and automatically format the newly created disk according to this plan. In this way, users do not need to format the disk again after mounting it, which reduces the complexity of understanding and operating the disk partitioning and file system to a certain extent, and reduces the possibility of manual disk handling problems.

[0040] Hard drive partitioning refers to dividing the entire storage space of a hard drive into multiple independent areas, used for installing the operating system, installing applications, and storing data files, respectively. However, before partitioning, some preparation and planning should be done, including determining how many partitions to create, the size of each partition, and the file system to use for each partition. For some operating systems, the hard drive must be partitioned before it can be used; otherwise, it cannot be recognized. Generally, for the convenience, ease, and speed of file storage and management, it is recommended to divide the hard drive into multiple partitions to store different types of files, such as the operating system, applications, and data files.

[0041] Second: The process of mounting cloud disks in Nova has been expanded. In Nova, if the cloud host being started supports QGA, we will automatically scan the metadata information of the cloud disk after the mounting action is completed. If it specifies the mounting directory, we will directly mount the disk to the specified directory of the cloud host. If QGA is not supported or the metadata information of the cloud disk does not specify the mounting directory, the mounting action will be abandoned.

[0042] Among them, qga is a regular application running inside the virtual machine (the executable file name is qemu-ga by default, and the service name is qemu-guest-agent by default). Its purpose is to realize a way for the host machine and the virtual machine to interact. This way does not rely on the network, but on virtio-serial (the default preferred method) or isa-serial. QEMU provides the simulation of serial port devices and the channel for data exchange. In the end, what is presented is a serial port device (inside the virtual machine) and a Unix socket file (on the host machine).

[0043] The prerequisites for this application are: an OpenStack environment with full functionality of Cinder and Nova. Cinder: OpenStack Block Storage Service (Cinder) adds persistent storage to virtual machines. Block storage provides an infrastructure for managing volumes and interacting with OpenStack compute services to provide volumes for instances. This service also activates the functionality of managing volume snapshots and volume types. Nova is the core service of OpenStack, responsible for maintaining and managing the computing resources of the cloud environment. As an IaaS cloud operating system, OpenStack's virtual machine lifecycle management is implemented through Nova. Cinder needs to be able to use backend storage; the type and provider of the backend storage are not important here, even LVM local disks can be used as backend storage, and Nova must be able to create cloud hosts normally. Secondly, the file system in the automatic formatting scheme must also support this type of file system on both the host machine and the cloud host. This is a prerequisite for the file system. For example, if a Btrfs file system is mounted on a cloud host that does not support Btrfs, the cloud host can discover the hard drive, but due to the lack of support for the corresponding Btrfs file system, it cannot mount or perform read / write operations on the discovered hard drive.

[0044] like Figure 2 This is a flowchart of a method for using cloud disks on a cloud host, as proposed in Embodiment 1 of the present invention.

[0045] First: Define the automatic formatting method for the cloud disk. The process of defining the automatic formatting method for the cloud disk includes: pre-setting the automatic formatting method in the metadata of the Cinder volume, setting the key value of the metadata to a fixed formatting character, and determining whether a formatting operation is needed by checking whether the value of the formatting character is empty.

[0046] The automatic formatting method for cloud disks can be created as a template. This template primarily comes from two sources: system presets and user-configured settings. Essentially, this template is a JSON object containing an array of partition information and scheme names. The partition information consists of three parts: file system type, the percentage of disk space occupied by the partition, and the partition's mount point on the host machine. In system presets, because the preset partitions don't truly reflect the user's desired file system size for each partition, we only provide a single-partition mode. Single-partition mode means formatting the entire cloud disk into a single partition and pre-setting this partition to the specified file system.

[0047] Secondly, create a cloud disk and select an automatic formatting scheme. When creating the cloud disk, we selected a source, which can be a snapshot, image, backup, etc. If the cloud disk has a source at creation time, Cinder can write this data to the cloud disk during creation. If we want to write data to the cloud disk, it must have a file system. If we then format the cloud disk, the data on the cloud disk will be lost. To protect the original data on the disk, we pre-disallow sensitive and dangerous operations such as deleting, modifying, and formatting data on disks containing data. The selected automatic formatting scheme will be stored in the Cinder volume's metadata information. This metadata information is a map data field. We set the map key to a fixed `format_plan`, and its value is a JSON object of the preset scheme. When Cinder processes the creation of the cloud disk, it will determine whether formatting is needed based on whether the `format_plan` value is empty. Simultaneously, Cinder's underlying automatic formatting will also format according to this preset scheme.

[0048] Again: The workflow for creating a volume is used to mount a cloud disk on a cloud host; during mounting, the disk is formatted according to the automatic formatting method described above, and then mounted to the cloud host after formatting is complete.

[0049] The volume creation workflow includes: API parsing of the response request sent by the client, and invoking the Cinder scheduler via the Remote Procedure Call protocol; the Cinder scheduler generates the volume creation workflow based on the scheduling node. The workflow consists of several core tasks, the core of which is: Cinder requests a cloud disk from the backend storage cluster; if the cloud disk has a source, it needs to be mounted to the host machine; then, the data from the source is written to the cloud disk; after writing is complete, the cloud disk is unmounted, the database is updated, and the entire creation process is completed. Since we added an automatic formatting process, this process needs to be completed within the entire creation process and is added to the end of the creation process.

[0050] The specific logic of the automatic formatting task is as follows: 1. Check if the cloud disk has a source. If it does, delete the `format_plain` information from the metadata field of the volume. Disks with data cannot be formatted. After deletion, return directly without formatting. 2. Read the preset formatting scheme. 3. Obtain the file system in the preset formatting scheme and determine if the host operating system supports the file system. If it does not support the file system, delete the `format_plain` information from the metadata field of the volume and end the automatic formatting process. 4. Mount the disk to the host machine and start formatting the cloud disk according to the preset formatting scheme. Here, we use the system command `parted` to format the disk. `parted` is a program for operating disk partitions. It supports multiple partition table types, including MS-DOS and GPT. `parted` allows users to create disk partitions on disks larger than 2TB, but the `fdisk` command does not support it. It supports more partition table types, including GPT (Globally Unique Identifier Partition Table). It allows users to resize partitions, but when shrinking partition space, it does not work as expected, and in most cases, I get error messages. Therefore, I would advise users not to use parted to reduce partition size. This description uses our system default scheme. Let's assume the hard drive is / dev / vdb. The command is: parted mkpart ext4 0 100%. This completes a formatting operation. After formatting, we unmount the cloud hard drive and end the automatic formatting process.

[0051] Finally, the process of mounting the cloud server after formatting includes: if the format string value is not empty, determining whether mounting is necessary based on the mount directory; determining whether the cloud server supports the gqa tool; if it does, finding the corresponding drive letter of the cloud disk and mounting the cloud disk.

[0052] The present invention, in Embodiment 1, proposes a method for using cloud disks on a cloud host. This method links the mounting and creation processes through a preset scheme. The creation process reads the preset scheme to complete sensitive disk operations, while the mounting process reads the preset scheme to complete automatic mounting. This eliminates the need for users to re-format the disk after mounting, reducing the complexity of understanding and operating disk partitions and file systems, and lowering the likelihood of problems arising from manual disk handling.

[0053] The method for using cloud disks on a cloud host proposed in Embodiment 1 of this invention avoids accidental data loss caused by manual operation of cloud disks, optimizes the user experience of using cloud disks on cloud hosts, and reduces the number of times users need to perform sensitive operations on cloud disks on cloud hosts.

[0054] The present invention provides a method for using cloud disks on cloud hosts, which is designed for non-system administrators and offers a fast and convenient way to use cloud disks, solving the problem that non-system administrators cannot operate the partitions and file systems of cloud disks.

[0055] Example 2

[0056] Based on the method for using cloud disks on a cloud host proposed in Embodiment 1 of the present invention, Embodiment 2 of the present invention also proposes a system for using cloud disks on a cloud host, such as... Figure 3 This is a schematic diagram of a cloud server using a cloud disk according to Embodiment 2 of the present invention. The system includes: a design module and a mounting module.

[0057] The specification module is used to specify the automatic formatting method for the cloud disk; the automatic formatting method is to format the cloud disk as a partition when the disk is created in Cinder if the value of the format string is not empty;

[0058] The mounting module is used to create volumes and executes the process of mounting cloud disks on cloud hosts. During mounting, the disks are formatted according to the automatic formatting method, and then mounted to the cloud host after formatting is complete.

[0059] The module execution process is as follows: the automatic formatting method is set in the metadata of the Cinder volume in advance, the key value of the metadata is set to a fixed formatting character, and the formatting operation is determined by whether the value of the formatting character is empty.

[0060] The automatic formatting method for cloud disks can be created as a template. This template primarily comes from two sources: system presets and user-configured settings. Essentially, this template is a JSON object containing an array of partition information and scheme names. The partition information consists of three parts: file system type, the percentage of disk space occupied by the partition, and the partition's mount point on the host machine. In system presets, because the preset partitions don't truly reflect the user's desired file system size for each partition, we only provide a single-partition mode. Single-partition mode means formatting the entire cloud disk into a single partition and pre-setting this partition to the specified file system.

[0061] When creating a cloud disk, select an automatic formatting scheme. When creating the cloud disk, you choose a source, which can be a snapshot, image, backup, etc. If the cloud disk has a source at creation time, Cinder can write this data to the cloud disk during creation. If you want to write data to the cloud disk, it must have a file system. If you then format the cloud disk, the data on the cloud disk will be lost. To protect the original data on the disk, we pre-disallow sensitive and dangerous operations such as deleting, modifying, and formatting data on disks containing data. The selected automatic formatting scheme will be stored in the Cinder volume's metadata information. This metadata information is a map data field. We set the map key to a fixed `format_plan`, and its value is a JSON object of the preset scheme. When Cinder processes the cloud disk creation, it will determine whether formatting is needed based on whether the `format_plan` value is empty. Simultaneously, Cinder's underlying automatic formatting will also format according to this preset scheme.

[0062] The mounting module execution process includes: API parsing of the parsing response request sent by the client, and invoking the Cinder scheduler via the remote procedure call protocol; the Cinder scheduler generates a workflow for creating volumes using the scheduling node. The workflow consists of several core tasks, the core of which is: Cinder requests a cloud disk from the backend storage cluster; if the cloud disk has a source, it needs to be mounted to the host machine; then, the data from the source is written to the cloud disk; after writing is complete, the cloud disk is unmounted, the database is updated, and the entire creation process is completed. Since we added an automatic formatting process, this process needs to be completed within the entire creation process and is added to the end of the creation process.

[0063] The specific logic of the automatic formatting task is as follows: 1. Check if the cloud disk has a source. If it does, delete the `format_plain` information from the metadata field of the volume. Disks with data cannot be formatted. After deletion, return directly without formatting. 2. Read the preset formatting scheme. 3. Obtain the file system in the preset formatting scheme and determine if the host operating system supports the file system. If it does not support the file system, delete the `format_plain` information from the metadata field of the volume and end the automatic formatting process. 4. Mount the disk to the host machine and start formatting the cloud disk according to the preset formatting scheme. Here, we use the system command `parted` to format the disk. `parted` is a program for operating disk partitions. It supports multiple partition table types, including MS-DOS and GPT. `parted` allows users to create disk partitions on disks larger than 2TB, but the `fdisk` command does not support it. It supports more partition table types, including GPT (Globally Unique Identifier Partition Table). It allows users to resize partitions, but when shrinking partition space, it does not work as expected, and in most cases, I get error messages. Therefore, I would advise users not to use parted to reduce partition size. This description uses our system default scheme. Let's assume the hard drive is / dev / vdb. The command is: parted mkpart ext4 0 100%. This completes a formatting operation. After formatting, we unmount the cloud hard drive and end the automatic formatting process.

[0064] Finally, the process of mounting the cloud server after formatting includes: if the format string value is not empty, determining whether mounting is necessary based on the mount directory; determining whether the cloud server supports the gqa tool; if it does, finding the corresponding drive letter of the cloud disk and mounting the cloud disk.

[0065] Embodiment 2 of this invention proposes a system for cloud hosts using cloud disks. This system links the mounting and creation processes through a preset scheme. The creation process reads the preset scheme to complete sensitive disk operations, while the mounting process reads the preset scheme to automatically mount the disk. This eliminates the need for users to re-format the disk after mounting, reducing the complexity of understanding and operating disk partitions and file systems, and lowering the likelihood of problems arising from manual disk handling.

[0066] The system for using cloud disks on cloud hosts proposed in Embodiment 2 of this invention avoids accidental data loss caused by manual operation of cloud disks, optimizes the user experience of using cloud disks on cloud hosts, and reduces the number of times users need to perform sensitive operations on cloud disks on cloud hosts.

[0067] The present invention, embodiment 2, proposes a system for cloud hosts to use cloud disks, which provides a fast and convenient way for non-system administrators to use cloud disks, and solves the problem that non-system administrators cannot operate the partitions and file systems of cloud disks.

[0068] Example 3

[0069] The present invention also proposes a device, such as Figure 4 This is a schematic diagram of a device according to Embodiment 3 of the present invention. The device includes: a memory for storing a computer program; and a processor for executing the computer program to implement the following method steps:

[0070] like Figure 2 This is a flowchart of a method for using cloud disks on a cloud host, as proposed in Embodiment 1 of the present invention.

[0071] First: Define the automatic formatting method for the cloud disk. The process of defining the automatic formatting method for the cloud disk includes: pre-setting the automatic formatting method in the metadata of the Cinder volume, setting the key value of the metadata to a fixed formatting character, and determining whether a formatting operation is needed by checking whether the value of the formatting character is empty.

[0072] The automatic formatting method for cloud disks can be created as a template. This template primarily comes from two sources: system presets and user-configured settings. Essentially, this template is a JSON object containing an array of partition information and scheme names. The partition information consists of three parts: file system type, the percentage of disk space occupied by the partition, and the partition's mount point on the host machine. In system presets, because the preset partitions don't truly reflect the user's desired file system size for each partition, we only provide a single-partition mode. Single-partition mode means formatting the entire cloud disk into a single partition and pre-setting this partition to the specified file system.

[0073] Secondly, create a cloud disk and select an automatic formatting scheme. When creating the cloud disk, we selected a source, which can be a snapshot, image, backup, etc. If the cloud disk has a source at creation time, Cinder can write this data to the cloud disk during creation. If we want to write data to the cloud disk, it must have a file system. If we then format the cloud disk, the data on the cloud disk will be lost. To protect the original data on the disk, we pre-disallow sensitive and dangerous operations such as deleting, modifying, and formatting data on disks containing data. The selected automatic formatting scheme will be stored in the Cinder volume's metadata information. This metadata information is a map data field. We set the map key to a fixed `format_plan`, and its value is a JSON object of the preset scheme. When Cinder processes the creation of the cloud disk, it will determine whether formatting is needed based on whether the `format_plan` value is empty. Simultaneously, Cinder's underlying automatic formatting will also format according to this preset scheme.

[0074] Again: The workflow for creating a volume is used to mount a cloud disk on a cloud host; during mounting, the disk is formatted according to the automatic formatting method described above, and then mounted to the cloud host after formatting is complete.

[0075] The volume creation workflow includes: API parsing of the response request sent by the client, and invoking the Cinder scheduler via the Remote Procedure Call protocol; the Cinder scheduler generates the volume creation workflow based on the scheduling node. The workflow consists of several core tasks, the core of which is: Cinder requests a cloud disk from the backend storage cluster; if the cloud disk has a source, it needs to be mounted to the host machine; then, the data from the source is written to the cloud disk; after writing is complete, the cloud disk is unmounted, the database is updated, and the entire creation process is completed. Since we added an automatic formatting process, this process needs to be completed within the entire creation process and is added to the end of the creation process.

[0076] The specific logic of the automatic formatting task is as follows: 1. Check if the cloud disk has a source. If it does, delete the `format_plain` information from the metadata field of the volume. Disks with data cannot be formatted. After deletion, return directly without formatting. 2. Read the preset formatting scheme. 3. Obtain the file system in the preset formatting scheme and determine if the host operating system supports the file system. If it does not support the file system, delete the `format_plain` information from the metadata field of the volume and end the automatic formatting process. 4. Mount the disk to the host machine and start formatting the cloud disk according to the preset formatting scheme. Here, we use the system command `parted` to format the disk. `parted` is a program for operating disk partitions. It supports multiple partition table types, including MS-DOS and GPT. `parted` allows users to create disk partitions on disks larger than 2TB, but the `fdisk` command does not support it. It supports more partition table types, including GPT (Globally Unique Identifier Partition Table). It allows users to resize partitions, but when shrinking partition space, it does not work as expected, and in most cases, I get error messages. Therefore, I would advise users not to use parted to reduce partition size. This description uses our system default scheme. Let's assume the hard drive is / dev / vdb. The command is: parted mkpart ext4 0 100%. This completes a formatting operation. After formatting, we unmount the cloud hard drive and end the automatic formatting process.

[0077] Finally, the process of mounting the cloud server after formatting includes: if the format string value is not empty, determining whether mounting is necessary based on the mount directory; determining whether the cloud server supports the gqa tool; if it does, finding the corresponding drive letter of the cloud disk and mounting the cloud disk.

[0078] The device proposed in Embodiment 3 of this invention links the mounting and creation processes through a preset scheme. The creation process reads the preset scheme to complete sensitive hard drive operations, while the mounting process reads the preset scheme to complete automatic mounting. This eliminates the need for users to re-format the hard drive after mounting, reducing the complexity of understanding and operating hard drive partitions and file systems, and lowering the likelihood of problems arising from manual hard drive handling.

[0079] The device proposed in Embodiment 3 of the present invention avoids accidental data loss caused by manual operation of cloud disks, optimizes the user experience of using cloud disks on cloud hosts, and reduces the number of times users need to perform sensitive operations on cloud disks on cloud hosts.

[0080] The device proposed in Embodiment 3 of the present invention provides a fast and convenient way for non-system administrators to use cloud disks, solving the problem that non-system administrators cannot operate the partitions and file systems of cloud disks.

[0081] It should be noted that the present invention also provides an electronic device, including: a communication interface capable of interacting with other devices such as network devices; and a processor connected to the communication interface to enable information interaction with other devices, used to execute a method for using a cloud hard drive provided by one or more of the above technical solutions when running a computer program, wherein the computer program is stored in a memory. In practical applications, the various components of the electronic device are coupled together through a bus system. It is understood that the bus system is used to realize the connection and communication between these components. In addition to a data bus, the bus system also includes a power bus, a control bus, and a status signal bus. The memory in the embodiments of this application is used to store various types of data to support the operation of the electronic device. Examples of this data include any computer program used to operate on the electronic device. It is understood that the memory can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache.By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), SyncLink Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM). The memories described in the embodiments of this application are intended to include, but are not limited to, these and any other suitable types of memory. The methods disclosed in the embodiments of this application can be applied to or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by integrated logic circuits in the processor hardware or by instructions in software. The processor can be a general-purpose processor, a DSP (Digital Signal Processing, i.e., a chip capable of implementing digital signal processing technology), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. A general-purpose processor can be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software modules can be located in a storage medium, which is located in memory. The processor reads the program from the memory and, in conjunction with its hardware, completes the steps of the aforementioned method. When the processor executes the program, it implements the corresponding processes in the various methods of the embodiments of this application; for simplicity, these will not be elaborated further here.

[0082] Example 4

[0083] The present invention also proposes a readable storage medium on which a computer program is stored, wherein the computer program, when executed by a processor, implements the following method steps:

[0084] like Figure 2 This is a flowchart of a method for using cloud disks on a cloud host, as proposed in Embodiment 1 of the present invention.

[0085] First: Define the automatic formatting method for the cloud disk. The process of defining the automatic formatting method for the cloud disk includes: pre-setting the automatic formatting method in the metadata of the Cinder volume, setting the key value of the metadata to a fixed formatting character, and determining whether a formatting operation is needed by checking whether the value of the formatting character is empty.

[0086] The automatic formatting method for cloud disks can be created as a template. This template primarily comes from two sources: system presets and user-configured settings. Essentially, this template is a JSON object containing an array of partition information and scheme names. The partition information consists of three parts: file system type, the percentage of disk space occupied by the partition, and the partition's mount point on the host machine. In system presets, because the preset partitions don't truly reflect the user's desired file system size for each partition, we only provide a single-partition mode. Single-partition mode means formatting the entire cloud disk into a single partition and pre-setting this partition to the specified file system.

[0087] Secondly, create a cloud disk and select an automatic formatting scheme. When creating the cloud disk, we selected a source, which can be a snapshot, image, backup, etc. If the cloud disk has a source at creation time, Cinder can write this data to the cloud disk during creation. If we want to write data to the cloud disk, it must have a file system. If we then format the cloud disk, the data on the cloud disk will be lost. To protect the original data on the disk, we pre-disallow sensitive and dangerous operations such as deleting, modifying, and formatting data on disks containing data. The selected automatic formatting scheme will be stored in the Cinder volume's metadata information. This metadata information is a map data field. We set the map key to a fixed `format_plan`, and its value is a JSON object of the preset scheme. When Cinder processes the creation of the cloud disk, it will determine whether formatting is needed based on whether the `format_plan` value is empty. Simultaneously, Cinder's underlying automatic formatting will also format according to this preset scheme.

[0088] Again: The workflow for creating a volume is used to mount a cloud disk on a cloud host; during mounting, the disk is formatted according to the automatic formatting method described above, and then mounted to the cloud host after formatting is complete.

[0089] The volume creation workflow includes: API parsing of the response request sent by the client, and invoking the Cinder scheduler via the Remote Procedure Call protocol; the Cinder scheduler generates the volume creation workflow based on the scheduling node. The workflow consists of several core tasks, the core of which is: Cinder requests a cloud disk from the backend storage cluster; if the cloud disk has a source, it needs to be mounted to the host machine; then, the data from the source is written to the cloud disk; after writing is complete, the cloud disk is unmounted, the database is updated, and the entire creation process is completed. Since we added an automatic formatting process, this process needs to be completed within the entire creation process and is added to the end of the creation process.

[0090] The specific logic of the automatic formatting task is as follows: 1. Check if the cloud disk has a source. If it does, delete the `format_plain` information from the metadata field of the volume. Disks with data cannot be formatted. After deletion, return directly without formatting. 2. Read the preset formatting scheme. 3. Obtain the file system in the preset formatting scheme and determine if the host operating system supports the file system. If it does not support the file system, delete the `format_plain` information from the metadata field of the volume and end the automatic formatting process. 4. Mount the disk to the host machine and start formatting the cloud disk according to the preset formatting scheme. Here, we use the system command `parted` to format the disk. `parted` is a program for operating disk partitions. It supports multiple partition table types, including MS-DOS and GPT. `parted` allows users to create disk partitions on disks larger than 2TB, but the `fdisk` command does not support it. It supports more partition table types, including GPT (Globally Unique Identifier Partition Table). It allows users to resize partitions, but when shrinking partition space, it does not work as expected, and in most cases, I get error messages. Therefore, I would advise users not to use parted to reduce partition size. This description uses our system default scheme. Let's assume the hard drive is / dev / vdb. The command is: parted mkpart ext4 0 100%. This completes a formatting operation. After formatting, we unmount the cloud hard drive and end the automatic formatting process.

[0091] Finally, the process of mounting the cloud server after formatting includes: if the format string value is not empty, determining whether mounting is necessary based on the mount directory; determining whether the cloud server supports the gqa tool; if it does, finding the corresponding drive letter of the cloud disk and mounting the cloud disk.

[0092] The storage medium proposed in Embodiment 3 of this invention links the mounting and creation processes through a preset scheme. The creation process reads the preset scheme to complete sensitive hard drive operations, while the mounting process reads the preset scheme to complete automatic mounting. This eliminates the need for users to re-format the hard drive after mounting, reducing the complexity of understanding and operating hard drive partitions and file systems, and lowering the likelihood of problems arising from manual hard drive handling.

[0093] The storage medium proposed in Embodiment 3 of this invention avoids accidental data loss caused by manual operation of cloud disks, optimizes the user experience of using cloud disks on cloud hosts, and reduces the number of times users need to perform sensitive operations on cloud disks on cloud hosts.

[0094] The storage medium proposed in Embodiment 3 of this invention provides a fast and convenient way for non-system administrators to use cloud disks, solving the problem that non-system administrators cannot operate the partitions and file systems of cloud disks.

[0095] This application also provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, such as a memory that stores a computer program, which can be executed by a processor to complete the steps described in the aforementioned method. The computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface memory, optical disc, or CD-ROM.

[0096] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks. Alternatively, if the integrated units of this application are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0097] For a description of the relevant parts of the processing device and storage medium for a cloud host using a cloud hard disk provided in this application embodiment, please refer to the detailed description of the corresponding part in the method for a cloud host to use a cloud hard disk provided in embodiment 1 of this application, and will not be repeated here.

[0098] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that the elements inherent in a process, method, article, or apparatus that includes a list of elements are included. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element. Additionally, portions of the technical solutions provided in the embodiments of this application that are consistent with the implementation principles of corresponding technical solutions in the prior art have not been described in detail to avoid excessive elaboration.

[0099] While specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art can make other modifications or variations based on the above description. It is neither necessary nor possible to exhaustively describe all embodiments here. Various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.

Claims

1. A method for a cloud host to use a cloud hard disk, characterized in that, Includes the following steps: An automatic formatting method for cloud disks is defined; the automatic formatting method is to format the cloud disk as a partition when the disk is created in Cinder if the value of the format string is not empty; the process of defining the automatic formatting method for cloud disks includes: setting the automatic formatting method in the metadata of the Cinder volume in advance, setting the key value of the metadata to a fixed format character, and determining whether a formatting operation is needed by judging whether the value of the format character is empty; The workflow for creating a volume is used to mount a cloud disk in a cloud host; During mounting, the disk is formatted according to the automatic formatting method, and then mounted to the cloud host. The process of mounting the cloud disk to the cloud host includes: Cinder requests a cloud disk from the backend storage cluster. If the cloud disk has a source, it checks whether the format string in the cloud disk metadata field is empty. If it is not empty, it reads the file system in the pre-defined automatic formatting method of the cloud disk; it determines whether the host operating system supports the file system. If it does, it mounts the cloud disk to the host; then it formats the cloud disk using the automatic formatting method and unmounts the cloud disk. The process of mounting the cloud server after formatting includes: if the formatting character value is not empty, determining whether mounting is needed based on the mount directory; determining whether the cloud server supports the gqa tool; if it does, finding the corresponding drive letter of the cloud disk and mounting the cloud disk. 2.The method of claim 1, wherein, The method for formatting a cloud disk into a partition is to use the parted command to format the disk into a partition. 3.The method of claim 1, wherein, The process of creating a volume includes: parsing the parsing response request sent by the client via API, invoking the Cinder scheduler via the remote procedure call protocol; and the Cinder scheduler generating a workflow for creating the volume using information about the scheduling node.

4. A system for a cloud host to use a cloud hard disk, configured to perform the method for a cloud host to use a cloud hard disk according to any one of claims 1 to 3. This includes defining modules and mounting modules; The specified module is used to specify the automatic formatting method for the cloud disk; the automatic formatting method is to format the cloud disk as a partition if the value of the format string is not empty when the disk is created in Cinder. The mounting module is used to create volumes and executes the process of mounting cloud disks on cloud hosts. During mounting, the disks are formatted according to the automatic formatting method, and then mounted to the cloud host after formatting is complete. 5.The cloud host using cloud disk system according to claim 4, characterized in that, The process of the specified module is as follows: the automatic formatting method is set in the metadata of the Cinder volume in advance, the key value of the metadata is set to a fixed formatting character, and the formatting operation is determined by whether the value of the formatting character is empty.

6. An apparatus, comprising: include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the method as described in any one of claims 1 to 3.

7. A readable storage medium, characterized by, The readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method as described in any one of claims 1 to 3.

Images