A method for realizing shared volumes based on FC protocol

Abstract

The application provides a method for realizing shared volumes based on an FC protocol, a host computer and an underlying storage device are connected through the FC protocol, a cloud host disk driver uses virtio-scsi, an SCSI locking mechanism is used, and the cloud host computer that is mounted with the shared volume needs to have forced non-affinity and be distributed on different host computers.The application has the beneficial effects that the method for realizing shared volumes based on the FC protocol is used to realize shared volume mounting; the cloud host computer no longer depends on an ISCSI protocol, and a special network card and a network segment need not be configured; the cloud host computer is mounted with the shared volume through the host computer, and is no longer directly connected with the underlying shared storage device, direct exposure is avoided, and the method is safer.

Description

Technical Field

[0001] This invention belongs to the field of cloud computing technology, and in particular relates to a method for implementing shared volumes based on the FC protocol. Background Technology

[0002] Currently, in the cloud computing field, shared volumes are generally achieved by directly installing iSCSI components on multiple cloud hosts and then directly connecting to storage devices via a storage network. The specific process is as follows: ① The shared volume is exported and mapped on the storage device to a cloud host with a unique identifier, binding the shared volume to the cloud host; ② The shared volume device is scanned on the cloud host using the LUN number specified during the export mapping in step S01; ③ The block device scanned in step S02 is formatted, and then the shared volume is used on the cloud host with the mounted volume, in conjunction with a high-availability cluster or shared file system. This current method of implementing shared volumes has two problems: First, the storage device and the cloud host must rely on the iSCSI protocol, so the cloud host and the underlying storage device need to be connected via a storage network, requiring dedicated network cards and network segment planning for the cloud host; second, the underlying storage device is directly connected to the cloud host, exposing the underlying storage device to the cloud host users, posing a significant security risk.

[0003] Meanwhile, some users' data nodes uniformly use the FC protocol on the storage side, which requires the implementation of shared volume mounting based on the FC protocol. According to the current direct connection method, the cloud host that mounts the shared volume must have an HBA card. This requires the cloud host to directly pass through the host machine's HBA card, and each host machine can only pass through to one cloud host on it. This is not only a cumbersome process, but also poses security risks. Summary of the Invention

[0004] In view of this, the present invention aims to propose a method for implementing a shared volume based on the FC protocol, so as to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the technical solution of the present invention is implemented as follows:

[0006] A method for implementing shared volumes based on the FC protocol is proposed. The host machine and the underlying storage device are connected via the FC protocol. The cloud host disk driver uses virtio-scsi and employs the SCSI locking mechanism. The cloud host that mounts the shared volume needs to have forced non-affinity and is distributed across different host machines.

[0007] Furthermore, this includes the following steps:

[0008] S01. Cloud host verification enforces non-affinity, ensuring that all cloud hosts mounting shared volumes are in the same enforced non-affinity group;

[0009] S02. Export the shared volume to the host machine with a unique identifier on the underlying storage device, and bind the shared volume to the host machine;

[0010] S03. On the host machine, scan for the shared volume device based on the LUN number specified when exported in S02, and form a multipath;

[0011] S04. Based on the multipath generated in step S03, mount the shared volume device to the specified cloud host by calling the libvirt interface, and write the disk driver virtio-scsi and related configuration to the cloud host.

[0012] S05. Format the shared volume block device in the cloud host, and then use the shared volume in conjunction with a high-availability cluster or shared file system in the cloud host on which the shared volume is mounted.

[0013] Furthermore, in step S01, it is necessary to ensure that all cloud hosts mounting shared volumes are in the same mandatory non-affinity group to prevent virtual machines with the same storage access requirements from being deployed on the same physical host, thereby improving redundancy and availability.

[0014] Furthermore, in step S02, the shared volume is exported to a host machine with a unique identifier on the underlying storage device. Each host machine can only access the shared volume allocated to it to ensure the security and isolation of storage resources.

[0015] Furthermore, in step S03, on the host machine, the shared volume device is scanned using a command or API based on the LUN number specified when exported in S02, and multipath access is set for the shared volume device. Multipath access allows the host machine to communicate with the shared volume through multiple physical paths, thereby improving redundancy and performance.

[0016] Furthermore, in step S04, the scanned shared volume device is mounted to the specified cloud host using the libvirt interface. During the mounting process, the disk driver and related parameters need to be configured for the cloud host, and the configuration information will be written to the cloud host's XML description file.

[0017] Furthermore, in step S05, the mounted shared volume device is formatted on the cloud host. After formatting, the shared volume is used on the cloud host with the shared volume mounted, in conjunction with a high-availability cluster or a shared file system, to achieve secure data storage and access.

[0018] Furthermore, this solution discloses an electronic device, including a processor and a memory communicatively connected to the processor and used to store executable instructions of the processor, wherein the processor is used to execute a method for implementing a shared volume based on the FC protocol.

[0019] Furthermore, this solution discloses a server, including at least one processor and a memory communicatively connected to the processor, the memory storing instructions executable by the at least one processor, the instructions being executed by the processor to cause the at least one processor to perform a method for implementing a shared volume based on the FC protocol.

[0020] Furthermore, this solution discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, implements a method for implementing a shared volume based on the FC protocol.

[0021] Compared with existing technologies, the method for implementing shared volumes based on the FC protocol described in this invention has the following advantages:

[0022] The present invention describes a method for implementing shared volumes based on the FC protocol. The method uses the FC protocol to mount shared volumes. Cloud hosts no longer rely on the iSCSI protocol, do not need to configure dedicated network cards or plan network segments, and the cloud hosts mount shared volumes through the host machine, no longer directly connected to the underlying shared storage devices, thus avoiding direct exposure and making the system more secure. Attached Figure Description

[0023] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings:

[0024] Figure 1 This is a schematic diagram of a traditional shared volume implementation scheme according to an embodiment of the present invention;

[0025] Figure 2 This is a schematic diagram of the shared volume implementation scheme of the present invention as described in an embodiment of the present invention. Detailed Implementation

[0026] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0027] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0028] In existing technologies, dedicated network cards and network segments are configured for cloud hosts. Shared volumes are directly mounted to the cloud hosts via the iSCSI protocol. This process is then repeated for multiple cloud hosts to share a single storage volume. This not only requires additional configuration and planning for the cloud hosts but also exposes the underlying storage devices to the user, posing significant security risks. Furthermore, if the direct connection method is based on the FC protocol, all cloud hosts mounting the shared volume must have HBA cards, which also presents security risks.

[0029] A scheme for implementing shared volumes based on the FC protocol includes the following technical points:

[0030] 1. The host machine and the underlying storage device are connected via the FC protocol;

[0031] 2. The cloud server disk driver uses virtio-scsi;

[0032] 3. Using the SCSI locking mechanism, cloud hosts that mount shared volumes need to have forced non-affinity and be distributed across different host machines;

[0033] A scheme for implementing a shared volume based on the FC protocol includes the following steps:

[0034] S01. Cloud host verification enforces non-affinity; cloud hosts that need to mount shared volumes must all be in the same enforced non-affinity group.

[0035] S02. Export the shared volume to the host machine with a unique identifier on the underlying storage device, and bind the shared volume to the host machine;

[0036] S03. On the host machine, scan for the shared volume device based on the LUN number specified when exported in S02, and form a multipath;

[0037] S04. Based on the multipath generated in S03, mount the shared volume device to the specified cloud host by calling the libvirt interface, and write the disk driver virtio-scsi and related configuration to the cloud host.

[0038] S05. Format the shared volume block device in the cloud host, and then use the shared volume in conjunction with a high-availability cluster or shared file system in the cloud host on which the shared volume is mounted.

[0039] This invention allows shared volumes to be mounted using the FC protocol, without relying on the iSCSI protocol, and without requiring additional configuration and network planning for cloud hosts. At the same time, the underlying storage devices are no longer directly exposed to users, eliminating the security risks of the original solution.

[0040] In the specific implementation process, this solution provides the following specific implementation methods:

[0041] S01: Cloud server verification enforces non-affinity

[0042] When creating or configuring virtual machines, ensure that all cloud hosts mounting shared volumes are in the same mandatory non-affinity group. This prevents virtual machines with the same storage access requirements from being deployed on the same physical host, thereby improving redundancy and availability.

[0043] S02: Export the shared volume to the host machine and bind it.

[0044] On the underlying storage device, shared volumes are exported to host machines with unique identifiers. This means that each host machine can only access the shared volumes allocated to it. This binding mechanism ensures the security and isolation of storage resources.

[0045] S03: Scan shared volume devices and form multiple paths

[0046] On the host machine, the shared volume device is scanned using commands or API based on the LUN number specified when exported in S02, and multipath access is configured for the shared volume device. Multipath access allows the host machine to communicate with the shared volume through multiple physical paths, thereby improving redundancy and performance.

[0047] S04: Mount the shared volume to the specified cloud host and write the configuration.

[0048] Use the libvirt interface to mount the scanned shared volume device to the specified cloud host. During the mounting process, you need to configure the disk driver (such as virtio-scsi) and related parameters for the cloud host. This configuration information will be written to the cloud host's XML description file.

[0049] <disk type='block'device='disk'>

[0050] <driver name='qemu'type='raw'cache='none'io='native' / >

[0051] <source dev＝' dev mapper mpathX'>

[0052] <target dev='sdb'bus='scsi' / >

[0053] <address type＝'drive'controller＝'0'bus＝'0'target＝'0'unit＝'1'>< / address>

[0054]

[0055] S05: Format the shared volume and use it in conjunction with a high-availability cluster or shared file system.

[0056] On a cloud host, the mounted shared volume device is formatted, for example, using an ext4 or xfs file system. After formatting, the shared volume can be used on the cloud host with the shared volume mounted, in conjunction with a high-availability cluster (such as Pacemaker, Corosync, etc.) or a shared file system (such as NFS, GFS2, etc.) to achieve secure data storage and access.

[0057] #Format the shared volume

[0058] mkfs.ext4 / dev / sdb

[0059] #Mount the shared volume to the local file system

[0060] mount / dev / sdb / mnt / shared_volume

[0061] The above steps demonstrate how to export and mount a shared volume to a cloud host for use in conjunction with a high-availability cluster or shared file system. This helps improve data access speed and redundancy between cloud hosts, ensuring the stable operation of applications.

[0062] Those skilled in the art will recognize that the units and method steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0063] In the several embodiments provided in this application, it should be understood that the disclosed methods and systems can be implemented in other ways. For example, the division of units described above is merely a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. The aforementioned units may or may not be physically separated. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments of the present invention according to actual needs.

[0064] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be covered within the scope of the claims and specification of the present invention.

[0065] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for implementing a shared volume based on the FC protocol, characterized in that: The host machine and the underlying storage device are connected via the FC protocol. The cloud host disk driver uses virtio-scsi and the SCSI locking mechanism. Cloud hosts that mount shared volumes need to have forced non-affinity and are distributed on different host machines. Includes the following steps: S01. Cloud host verification enforces non-affinity, ensuring that all cloud hosts mounting shared volumes are in the same enforced non-affinity group; S02. Export the shared volume to the host machine with a unique identifier on the underlying storage device, and bind the shared volume to the host machine; S03. On the host machine, scan for the shared volume device based on the LUN number specified when exported in S02, and form a multipath; S04. Based on the multipath generated in step S03, mount the shared volume device to the specified cloud host by calling the libvirt interface, and write the disk driver virtio-scsi and related configuration to the cloud host. S05. Format the shared volume block device in the cloud host, and then use the shared volume in conjunction with a high-availability cluster or shared file system in the cloud host on which the shared volume is mounted. In step S02, the shared volume is exported to the host machine with a unique identifier on the underlying storage device. Each host machine can only access the shared volume allocated to it to ensure the security and isolation of storage resources. In step S03, on the host machine, the shared volume device is scanned using a command or API based on the LUN number specified when exported in S02, and multipath access is set for the shared volume device. Multipath access allows the host machine to communicate with the shared volume through multiple physical paths, thereby improving redundancy and performance.

2. The method for implementing a shared volume based on the FC protocol according to claim 1, characterized in that, In step S01, it is necessary to ensure that all cloud hosts mounting shared volumes are in the same forced affinity group to prevent virtual machines with the same storage access requirements from being deployed on the same physical host, thereby improving redundancy and availability.

3. The method for implementing a shared volume based on the FC protocol according to claim 1, characterized in that, In step S04, the scanned shared volume device is mounted to the specified cloud host using the libvirt interface. During the mounting process, the disk driver and related parameters need to be configured for the cloud host, and the configuration information will be written to the cloud host's XML description file.

4. The method for implementing a shared volume based on the FC protocol according to claim 1, characterized in that, In step S05, the mounted shared volume block device is formatted on the cloud host. After formatting, the shared volume is used on the cloud host with the shared volume mounted, in conjunction with a high-availability cluster or a shared file system, to achieve secure data storage and access.

5. An electronic device, comprising a processor and a memory communicatively connected to the processor and used for storing processor-executable instructions, characterized in that: The processor is used to execute a method for implementing a shared volume based on the FC protocol as described in any one of claims 1-4.

6. A server, characterized in that: The system includes at least one processor and a memory communicatively connected to the processor, the memory storing instructions executable by the at least one processor, the instructions being executed by the processor to cause the at least one processor to perform a method for implementing a shared volume based on the FC protocol as described in any one of claims 1-4.

7. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by the processor, it implements the method for implementing a shared volume based on the FC protocol as described in any one of claims 1-4.

Images