KR20230165571A - Method and system for providing volume to container environment - Google Patents

Abstract

Disclosed is a method and system for providing volumes in a container environment. A volume provision method according to an embodiment includes receiving a volume creation request from a client in a container environment, storing metadata of the volume in a database according to the volume creation request, and a volume node of the backend storage to create the volume. It may include the step of scheduling and requesting the creation of a logical volume (Logical Volume, LV) corresponding to the volume to the volume node selected through the scheduling.

Description

Method and system for providing volume to a container environment {METHOD AND SYSTEM FOR PROVIDING VOLUME TO CONTAINER ENVIRONMENT}

The description below relates to a method and system for providing volumes in a container environment.

In a local computing environment, a CPU (Central Processing Unit) or memory performs input/output with a SATA SSD (solid state drive) through the SATA (Serial Advanced Technology Attachment) protocol, or input/output with an NVMe SSD through the NVMe (Non Volatile Memory express) protocol. Storage and communication can be handled through each communication standard, such as performing .

On the other hand, when a client wants to use the server's NVMe SSD in a client-server environment, NVMe oF (NVMe over Fabrics) technology exists to allow the client to access the server's NVMe SSD through the NVMe protocol through the network.

[Prior document number]

Korean Patent Publication No. 2019-0106680

Provides a volume provision method and system that can provide a volume from a server to a client so that the client can use the server's storage in a client-server environment.

A volume provision method of a computer device implementing backend storage, comprising: receiving a volume creation request from a client in a container environment by at least one processor included in the computer device; storing volume metadata in a database according to the volume creation request, by the at least one processor; scheduling, by the at least one processor, a volume node of the backend storage to create the volume; and requesting, by the at least one processor, the creation of a logical volume (LV) corresponding to the volume to a volume node selected through the scheduling.

According to one side, the volume creation request may be received through an API call from the client as a Persistence Volume Claim (PVC) is created in the client.

According to another aspect, the scheduling step includes calling a module for scheduling the volume node according to a scheduling algorithm and then transmitting a response to the volume creation request to the client regardless of the response from the selected volume node. steps; and selecting one volume node among a plurality of volume nodes through the scheduling using the called module.

According to another aspect, a Persistence Volume (PV) that manages the volume in the client may be created based on the response delivered to the client and bound to the PVC that triggered the volume creation request.

According to another aspect, a logical volume corresponding to the volume may be created in the selected volume node according to a request to the selected volume node.

According to another aspect, the volume providing method includes receiving, by the at least one processor, a volume deletion request from the client; and transmitting, by the at least one processor, the volume deletion request to the selected volume node through a message queue.

According to another aspect, the corresponding logical volume may be deleted from the selected volume node in response to the volume deletion request.

A volume provision method of a computer device implementing backend storage, comprising: receiving a volume export request from a client in a container environment by at least one processor included in the computer device; Requesting, by the at least one processor, creation and export of a target to a volume node that manages a corresponding volume according to the volume export request; Receiving, by the at least one processor, information on a target exported from the volume node; and transmitting, by the at least one processor, the received target information to the client.

According to one side, the volume export request may be received through an API call from the client as a pod is created in the client.

According to another aspect, in response to a request for creation and export of the target, a target corresponding to the logical volume created in the volume node is created and exported at the volume node, and information on the created target is transmitted to the computer device. It can be characterized as:

According to another aspect, the information on the target may include the IP of the host as the volume node, the port, and the identifier of the target.

According to another aspect, the target is mapped to the block device of the client by accessing the target from the client based on the information of the target, and the pod created in the client is bound to the block device and corresponds to the target. It may be characterized in that the logical volume of the volume node becomes accessible.

According to another aspect, the volume providing method includes receiving, by the at least one processor, an export removal request from the client; and transmitting, by the at least one processor, the export removal request to the volume node through a message queue.

According to another aspect, the target may be removed from the volume node according to the export removal request.

A computer program stored on a computer-readable recording medium is provided in conjunction with a computer device to execute the method on the computer device.

Provided is a computer-readable recording medium on which a program for executing the above method on a computer device is recorded.

A computer device comprising: at least one processor configured to execute instructions readable by the computer device, the method comprising: receiving, by the at least one processor, a volume creation request from a client in a container environment; storing volume metadata in a database according to the volume creation request; Scheduling a volume node of the backend storage to create the volume; and requesting the creation of a logical volume (LV) corresponding to the volume to a volume node selected through the scheduling.

A computer device, comprising: at least one processor configured to execute instructions readable by the computer device; receiving, by the at least one processor, a volume export request from a client in a container environment; and responding to the volume export request. A computer device that requests the creation and export of a target to a volume node that manages the corresponding volume, receives information on the exported target from the volume node, and delivers the received target information to the client. provides.

In a client-server environment, volumes can be provided from the server to the clients so that the clients can use the server's storage.

1 is a diagram illustrating an example of a network environment according to an embodiment of the present invention.
Figure 2 is a block diagram showing an example of a computer device according to an embodiment of the present invention.
Figure 3 is a diagram illustrating an example of a cloud storage environment according to an embodiment of the present invention.
Figure 4 is a diagram illustrating an example of a volume creation process according to an embodiment of the present invention.
Figure 5 is a diagram showing an example of a volume attachment process in one embodiment of the present invention.
Figure 6 is a diagram illustrating an example of a volume detachment process in one embodiment of the present invention.
Figure 7 is a diagram illustrating an example of a volume deletion process according to an embodiment of the present invention.
Figure 8 is a diagram illustrating an example of a volume creation process from a back-end storage perspective, according to an embodiment of the present invention.
Figure 9 is a diagram illustrating an example of a volume attachment process from a back-end storage perspective, according to an embodiment of the present invention.
Figure 10 is a diagram illustrating an example of a volume detachment process from a back-end storage perspective, according to an embodiment of the present invention.
Figure 11 is a diagram illustrating an example of a volume deletion process from a back-end storage perspective, according to an embodiment of the present invention.

Hereinafter, embodiments will be described in detail with reference to the accompanying drawings.

The volume provision system according to embodiments of the present invention may be implemented by at least one computer device. At this time, the computer program according to an embodiment of the present invention may be installed and driven in the computer device, and the computer device may perform the volume provision method according to the embodiment of the present invention under the control of the driven computer program. . The above-described computer program can be combined with a computer device and stored on a computer-readable recording medium to enable the computer to execute the volume provision method.

1 is a diagram illustrating an example of a network environment according to an embodiment of the present invention. The network environment in FIG. 1 shows an example including a plurality of electronic devices 110, 120, 130, and 140, a plurality of servers 150 and 160, and a network 170. Figure 1 is an example for explaining the invention, and the number of electronic devices or servers is not limited as in Figure 1. In addition, the network environment in FIG. 1 only explains one example of environments applicable to the present embodiments, and the environment applicable to the present embodiments is not limited to the network environment in FIG. 1.

The plurality of electronic devices 110, 120, 130, and 140 may be fixed terminals or mobile terminals implemented as computer devices. Examples of the plurality of electronic devices 110, 120, 130, and 140 include smart phones, mobile phones, navigation devices, computers, laptops, digital broadcasting terminals, PDAs (Personal Digital Assistants), and PMPs (Portable Multimedia Players). ), tablet PC, etc. For example, in FIG. 1, the shape of a smartphone is shown as an example of the electronic device 110. However, in embodiments of the present invention, the electronic device 110 actually communicates with other devices through the network 170 using a wireless or wired communication method. It may refer to one of various physical computer devices capable of communicating with electronic devices 120, 130, 140 and/or servers 150, 160.

The communication method is not limited, and may include not only a communication method utilizing a communication network that the network 170 may include (for example, a mobile communication network, wired Internet, wireless Internet, and a broadcast network), but also short-range wireless communication between devices. For example, the network 170 may include a personal area network (PAN), a local area network (LAN), a campus area network (CAN), a metropolitan area network (MAN), a wide area network (WAN), and a broadband network (BBN). , may include one or more arbitrary networks such as the Internet. Additionally, the network 170 may include any one or more of network topologies including a bus network, star network, ring network, mesh network, star-bus network, tree or hierarchical network, etc. Not limited.

Each of the servers 150 and 160 is a computer device or a plurality of computers that communicate with a plurality of electronic devices 110, 120, 130, 140 and a network 170 to provide commands, codes, files, content, services, etc. It can be implemented with devices. For example, the server 150 provides services (e.g., cloud services, instant messaging services, transactions (e.g., remittance) to a plurality of electronic devices (110, 120, 130, and 140) connected through the network 170. ) services, payment services, virtual exchange services, risk monitoring services, gaming services, group call services (or voice conference services), messaging services, mail services, social network services, map services, translation services, search services and/or content provision. It may be a system that provides services, etc.).

Figure 2 is a block diagram showing an example of a computer device according to an embodiment of the present invention. Each of the plurality of electronic devices 110, 120, 130, and 140 described above or each of the servers 150 and 160 may be implemented by the computer device 200 shown in FIG. 2.

As shown in FIG. 2, this computer device 200 may include a memory 210, a processor 220, a communication interface 230, and an input/output interface 240. The memory 210 is a computer-readable recording medium and may include a non-permanent mass storage device such as random access memory (RAM), read only memory (ROM), and a disk drive. Here, non-perishable large-capacity recording devices such as ROM and disk drives may be included in the computer device 200 as a separate permanent storage device that is distinct from the memory 210. Additionally, an operating system and at least one program code may be stored in the memory 210. These software components may be loaded into the memory 210 from a computer-readable recording medium separate from the memory 210. Such separate computer-readable recording media may include computer-readable recording media such as floppy drives, disks, tapes, DVD/CD-ROM drives, and memory cards. In another embodiment, software components may be loaded into the memory 210 through the communication interface 230 rather than a computer-readable recording medium. For example, software components may be loaded into memory 210 of computer device 200 based on computer programs installed by files received over network 170.

The processor 220 may be configured to process instructions of a computer program by performing basic arithmetic, logic, and input/output operations. Commands may be provided to the processor 220 by the memory 210 or the communication interface 230. For example, processor 220 may be configured to execute received instructions according to program code stored in a recording device such as memory 210.

The communication interface 230 may provide a function for the computer device 200 to communicate with other devices (eg, the storage devices described above) through the network 170. For example, a request, command, data, file, etc. generated by the processor 220 of the computer device 200 according to a program code stored in a recording device such as memory 210 is transmitted to the network ( 170) and can be transmitted to other devices. Conversely, signals, commands, data, files, etc. from other devices may be received by the computer device 200 through the communication interface 230 of the computer device 200 via the network 170. Signals, commands, data, etc. received through the communication interface 230 may be transmitted to the processor 220 or memory 210, and files, etc. may be stored in a storage medium (as described above) that the computer device 200 may further include. It can be stored as a permanent storage device).

The input/output interface 240 may be a means for interfacing with the input/output device 250. For example, input devices may include devices such as a microphone, keyboard, or mouse, and output devices may include devices such as displays and speakers. As another example, the input/output interface 240 may be a means for interfacing with a device that integrates input and output functions, such as a touch screen. At least one of the input/output devices 250 may be configured as one device with the computer device 200. For example, like a smart phone, a touch screen, microphone, speaker, etc. may be included in the computer device 200.

Additionally, in other embodiments, computer device 200 may include fewer or more components than those of FIG. 2 . However, there is no need to clearly show most prior art components. For example, the computer device 200 may be implemented to include at least some of the input/output devices 250 described above, or may further include other components such as a transceiver, a database, etc.

Figure 3 is a diagram illustrating an example of a cloud storage environment according to an embodiment of the present invention. Figure 3 shows a client end 310 in a container environment implemented with Kubernetes and a storage server end 320 in a cloud environment implemented with OpenStack Cinder. Here, both Kubernetes and OpenStack Cinder are already well known as open source.

At this time, embodiments of the present invention can provide a method and system for how to provide storage (NVMe SSDs) distributed among the storage servers of the storage server stage 320 to clients in a container environment. Storage can create a logical volume (LV) of variable size. In the volume provision method according to one embodiment, when the client's container requests a volume of a desired size, the server provides a logical volume of the requested size to the container, so that the volume can be provided to the client in the container environment. At this time, the Container Storage Interface (CSI) can be used to provide the OpenStack Cinder volume to Kubernetes. The specific process of this volume provision method will be described in more detail later.

Figure 4 is a diagram illustrating an example of a volume creation process according to an embodiment of the present invention. Figure 4 shows a client end 310 in a container environment implemented with Kubernetes and a storage server end 320 in a cloud environment implemented with OpenStack Cinder. A plurality of client end 310 and/or storage server end 320 may be implemented and used.

In this embodiment, the container storage interface of NVMe oF (NVMe over Fabrics) may be deployed in Kubernetes (K8s). Components of the container storage interface can largely be composed of a controller plug-in (411) as shown in node 1 (node 1, 410) and a node plug-in (Node Plugin, 412) included in each node. At this time, the controller plug-in 411 is a component responsible for creating and deleting volumes at the client end 310, and the node plug-in 412 is a component that imports volumes to each node and binds and mounts the volumes to containers. You can.

In addition, the manager node (420) of the storage server stage (320), which is the backend storage managed by OpenStack Cinder, has cinder-api (421) and cinder-scheduler (cinder-scheduler). 422) may be included. Cinder-api 421 and cinder-scheduler 422 may be daemons used for volume management in the manager node 420. Volume node 1 (430) of the storage server end (320) may include a cinder-volume (431). Cinder-Volume 431 may be a daemon that manages storage (eg, NVMe SSDs) included in Volume Node 1 (430). Here, a plurality of volume nodes may exist in the storage server end 320, and each of the plurality of volume nodes may include its own cinder-volume. Additionally, a daemon may be a software module. 4 illustrates an example in which the manager node 420 includes the cinder-api 421 and the cinder-scheduler 422, but the cinder-api 421 and the cinder-scheduler 422 are different from each other. It may also be included in a node. For example, node 1 includes cinder-api (421) and cinder-volume 1, node 2 includes cinder-scheduler (422) and cinder-volume 2, and node 3 includes cinder-volume 3. You can. In other words, an embodiment in which at least one volume node among a plurality of volume nodes includes a cinder-api 421 and a cinder-scheduler 422 may be considered.

The entity that manages the volume in Kubernetes is PV (Persistence Volume, 440), and users do not directly access PV (440), but create an object called PVC (Persistence Volume Claim, 450) (1. create PVC) to claim the user's information. You can enter the specifications of the desired volume into PVC (450). For example, a specification to use a volume of 100 gigabytes of NVMe SSDs may be entered into PVC 450. At this time, the embodiment of FIG. 4 shows an example in which a PVC 450 named “testpvc” is created through “StorageClass” of NVMe oF. For example, there is an object called “StorageClass” for NVMe-oF, and the PVC 450 can write this “StorageClass” into the specification.

Meanwhile, the controller plug-in 411 can monitor the creation of the PVC 450, and as it confirms that the PVC 450 is created, it is connected to the endpoint between the client side 310 and the storage server side 320. A volume creation (2. cinder API: create volume) request can be sent. At this time, the volume creation request may be transmitted to the cinder-api (421). In other words, the volume creation request may be transmitted to the Cinder-api (421) as the PVC (450) is created in the client and the client makes an API call to the Cinder-api (421). Depending on the embodiment, the controller plug-in 411 may directly send a volume creation request to the cinder-api 421 or set a DNS (Domain Name System) to transmit the volume creation request. At this time, the volume creation request may include the name of the PVC (“testpvc” in this embodiment).

Cinder-api 421 can create a volume 460 (3. create volume) according to a volume creation request. Volume 460 may be created in the form of metadata stored in a database. At this time, the name of the created volume 460 may be the same as the name of the PVC 450. In addition, the cinder-api 421 schedules the cinder-scheduler 422 to find a node (volume node as a storage server) that will actually create the LV (Logical Volume) according to the created volume 460. Send request (4. scheduling). At this time, since the communication between Cinder-api (421) and Cinder-Scheduler (422) is asynchronous, the controller plug-in 411 sends a response to the volume creation request to the controller plug-in 411 immediately after the scheduling request ( 5. You can return after calling scheduling. At this time, the cinder-api 421 immediately responds to the volume creation request regardless of the response from the cinder-scheduler 422 or the response from the cinder-volume 431 or volume node 1 430, which will be described later. It can be passed on to the client.

The cinder-scheduler 422 may schedule the node that will generate the actual LV according to the volume 460 created by the cinder-api 421 according to the scheduling algorithm. For example, the cinder-scheduler 422 may select one volume node among a plurality of volume nodes existing in the back-end storage as the node that will actually generate the LV. The embodiment of FIG. 4 shows an example in which volume node 1 430 is scheduled as a node that will actually generate LV. At this time, the cinder-volume 431 of volume node 1 430 can create the LV 470 for the volume 460 through storage (NVMe SSDs). The scheduling algorithm can use a simple algorithm that finds and schedules the node with the largest capacity as the basic algorithm, but other factors for scheduling may be further considered depending on the actual implementation.

Meanwhile, the controller plug-in 411 that receives a response from the cinder-api 421 can create the PV 440 and then bind the PV 440 and the PVC 450. In this case, the user may be able to use the actual volume through the PVC 450.

The kubelet (480) shown in FIG. 4 may be responsible for creating and processing pods and volumes of Kubernetes, which will be described later. In each embodiment, the cubelet 480 is indicated by the same reference number for convenience of explanation, but in reality, it may be different instance modules included in each node of Kubernetes. This cubelet 480 will be described in more detail later.

Figure 5 is a diagram showing an example of a volume attachment process in one embodiment of the present invention. The embodiment of Figure 5 shows an example of a process for connecting a volume to a container using PVC 450.

Meanwhile, the embodiment of FIG. 5 shows an example in which the pod 510 that mounts the PV 440 is scheduled to node 2 520 and created (1. create Pod) according to the user's request. In this case, the node plugin 521 of node 2 520 can request export of the volume by calling the export volume (2. cinder API: export volume) with cinder-api 421 as it checks the pod 510. there is. More specifically, the entity that confirms the creation of the pod 510 may be the agent daemon of the worker node used in K8s of Kubernetes. In this case, the cubelet 480 may be responsible for the actual creation and processing of the pod 510 and volume. At this time, if the created pod 510 uses an NVMe-oF volume, the cubelet 480 requests a volume attachment from the node plug-in 521, so that the node plug-in 521 delivers information about this pod 510. You can receive it. In other words, the node plugin 521 can forward a volume export request to the cinder-api 421 through an API call as the pod is created. In this case, the cinder-api (421) can issue a command (3. create target and export) to create and export the target (530) to the cinder-volume (431) of volume node 1 (430). In this case, communication between the cinder-api 421 and the cinder-volume 431 for the corresponding command may be performed in a synchronous manner. Through this, as the cinder-api 421 creates the target 530 in the cinder-volume 431, the host IP, port, and subsystem NQN (target 530) are based on the response delivered by the cinder-volume 431. ) can be returned to the node plug-in 521 (4. return with host IP, port, subsystem NQN).

In this case, the node plugin 521 uses the delivered information (host IP, port, and identifier of the target 530) to call an NVMe connection to the target 530 based on the exported LV 470 (5. nvme connect )can do. In this case, the target 530 may be mapped to the NVMe type block device 550 of node 2 520, and when the target 530 is attached to node 2 520, the volume ( By changing the status of 460) to in-use (6. change volume status to in-use), the user can use the NVMe volume. To this end, the node plugin 521 can change the state of the volume 460 to in-use by sending a query to the cinder-api 421, similar to a request for export creation. Afterwards, the node plugin 521 bind mounts the block device 550 to which the pod 510 and the target 530 are mapped (6. bind mount), allowing the user application to use the NVMe volume through the pod 510. There will be. While the regular mount command creates a new directory tree, a bind mount can be used to attach a node's volume to a container using an existing directory tree. In other words, the pod 510 created in the client may be bind mounted on the block device 550 to enable access to the LV of volume node 1 (430) corresponding to the target (530).

Figure 6 is a diagram illustrating an example of a volume detachment process in one embodiment of the present invention. When the Pod 510 that mounts the PV 440 is deleted (1. delete Pod), the node plugin 521 deletes the backend storage server (volume node 1 (430)) of the target 530 mounted with the PV 440. )), you can issue an NVMe disconnect command (2. Nvme disconnect). The host IP, port, and identifier of the target 530 as server information of the target 530 can be received through a request to the cinder-api (421). Even in this case, the entity that confirms the deletion of the pod 510 may be the agent daemon of the worker node used in K8s of Kubernetes. In other words, the cubelet 480 monitors the deletion of the pod 510 and requests volume detachment from the node plug-in 521, so that the node plug-in 521 transmits information about the deletion of the pod 510. You can receive it.

After the NVMe connection is disconnected, the node plugin 521 may request the cinder-api 421 to delete the export (3. cinder API: remove export). In this case, the cinder-api 421 may transmit a message to remove the export (4. remove export) to the cinder-volume 431 of the corresponding host (volume node 1 430). Cinder-volume 431 may delete the export to target 530 according to the delivered message.

Afterwards, the node plugin 521 may transmit a request to enable the volume 460 (6. cinder API: enable volume) to the cinder-api 421, and the cinder-api 421 responds to the request. The status of the corresponding volume 460 can be changed to available (7. make volume status available).

Figure 7 is a diagram illustrating an example of a volume deletion process according to an embodiment of the present invention. When the PVC (450) of the NVMe oF is deleted (1. delete PVC), the controller plug-in (411) can request volume deletion (2. cinder API: delete volume) to the cinder-api (421). In this case, cinder-api 421 can delete volume 460 information from the database (3. Delete volume). Afterwards, the cinder-api 421 may send a message (4. remove volume) to remove the actual LV 470 to the cinder-volume 431 that manages the volume. The cinder-volume 431 may delete the LV 470 (5. delete LV) according to the received message.

Meanwhile, the controller plug-in 411 may request volume deletion through the cinder-api 421 and then delete the PV 440 (6. delete PV).

Figure 8 is a diagram illustrating an example of a volume creation process from a back-end storage perspective, according to an embodiment of the present invention. Figure 8 is an example of back-end storage corresponding to the storage server stage 320, including cinder-api (cinder-api, 810), authentication manager (Auth manager, 820), cinder-scheduler (830), and cinder. It represents a database (Cinder DB, 840), a message queue (Message Queue, 850), cinder-volume 1 (860), and cinder-volume 2 (cinder-volume 2, 870). Here, cinder-api (810), cinder-scheduler (830), and cinder-volume (860, 870) correspond to the cinder-api (421), cinder-scheduler (422), and cinder-volume (431) described above, respectively. You can. Meanwhile, the authentication manager 820, Cinder database 840, and message queue 850 may be components managed separately from OpenStack Cinder according to the microservice architecture.

When a volume creation request from a client is transmitted, the cinder-api (810) can check the authentication/authorization of the user request (1. Auth user, project and role) through the authentication manager (820). For example, the cinder-api 810 can check information about the user who called the API, information about the project to which the user belongs, and role information about whether the user can create a volume.

After authentication is completed, the cinder-api 810 can store the name, size, creation type, etc. of the volume as metadata of the volume in the cinder database 840 (2. Create volume metadata). For example, updates to the Cinder database 840 may be performed using SQL (Structured Query Language).

Additionally, the cinder-api 810 may request scheduling for volume creation from the cinder-scheduler 830 through the message queue 850. At this time, the cinder-api 810 may transmit a message to request volume scheduling to the message queue 850 (3. Request volume scheduling). Afterwards, the Cinder-Scheduler 830 can receive messages asynchronously through the message queue 850.

The cinder-scheduler 830 can determine the cinder-volume to create a volume (in this embodiment, cinder-volume 2 870) according to the received message, and sends a command to create an NVMe volume (4. Schedule nvme volume) can be entered into the message queue 850. At this time, the scheduling standard can be established by considering the remaining capacity of the disk handled by the cinder-volume.

Meanwhile, after scheduling the cinder-volume, the cinder-scheduler 830 may update the volume identifier and host information of the cinder-volume in the cinder database 840.

Cinder-Volume 2 (870) can receive commands through the message queue (850), and can create an NVMe volume as an LV according to the received command (5. Create nvme volume).

Figure 9 is a diagram illustrating an example of a volume attachment process from a back-end storage perspective, according to an embodiment of the present invention.

During volume attachment, when a volume export (target export) request from a client arrives at Cinder-api (810), Cinder-api (810) verifies the authentication/authorization of the user request through the authentication manager (820) (1. Auth user, project and role). Afterwards, the cinder-api (810) transmits a request (2. Request nvme target export and wait response) to export the NVMe target to the cinder-volume (in this embodiment, cinder-volume 2 (870)) in charge of the volume. You can. As already explained, the request is delivered asynchronously using the message queue 850, but since the cinder-api (810) has to wait for a response from the cinder-volume 2 (870), the cinder-api (810) has a cinder-api (810). It may include logic to wait for a response from volume 2 (870).

Cinder-Volume 2 (870) can perform the NVMe target export operation (3. Export nvme volume target) according to the request delivered through the message queue (850). For example, Cinder-Volume 2 (870) can process target export using the kernel module “nvmet-tcp”. Additionally, Cinder-Volume 2 (870) can transmit information (ip, port, host nqn) of the exported target to Cinder-API (810) through the message queue (850). Here, ip may correspond to the host IP described above, and host nqn may correspond to the subsystem NQN described as the identifier of the target.

Cinder-api (810) waits for a response from Cinder-Volume 2 (870), and when the response from Cinder-Volume 2 (870) is received through the message queue (850) after the export is completed, it returns the corresponding information to the client ( 4. Return nvme volume target info (ip, port, host nqn)).

Figure 10 is a diagram illustrating an example of a volume detachment process from a back-end storage perspective, according to an embodiment of the present invention.

During volume detachment, when a request to remove export is received from a client, Cinder-api (810) verifies authentication/authorization of the user request through the authentication manager (820) (1. Auth user, project and role )can do. Afterwards, Cinder-api (810) may send a request (2. Request remove nvme target) to delete the NVMe target to Cinder-Volume 2 (870) in charge of the volume through the message queue (850). At this time, Cinder-Volume 2 (870) may perform the task of deleting the NVMe target (3. Remove nvme target) according to the request delivered through the message queue (850).

Figure 11 is a diagram illustrating an example of a volume deletion process from a back-end storage perspective, according to an embodiment of the present invention.

When deleting a volume, if a volume delete request is received from the client, the cinder-api (810) verifies the authentication/authorization of the user request (1. Auth user, project and role) through the authentication manager (820). You can. Afterwards, the cinder-api 810 can delete information about the volume for which a deletion request has been received from the cinder database 840 (2. Delete volume metadata).

Additionally, Cinder-api (810) may send a request (3. Request volume delete) to delete the LV to Cinder-Volume 2 (870) in charge of the corresponding volume through the message queue (850). At this time, Cinder-Volume 2 (870) can perform the task of removing the LV (4. Delete LV) according to the request transmitted through the message queue (850).

The components described in the previous embodiments may be implemented in the form of software modules and may be functional expressions of operations performed by at least one processor (eg, processor 220). For example, the processor 220 of the computer device 200 that implements a client or back-end storage executes control instructions according to the code of an operating system or at least one computer program included in the memory 210. It can be implemented. Here, the processor 220 may control the computer device 200 so that the computer device 200 performs the operations according to the above-described embodiments according to control instructions provided by the code stored in the computer device 200. there is.

As such, according to embodiments of the present invention, in a client-server environment, a volume can be provided from the server to the client so that the client can use the server's storage.

The system or device described above may be implemented with hardware components or a combination of hardware components and software components. For example, devices and components described in embodiments may include, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), etc. , may be implemented using one or more general-purpose or special-purpose computers, such as a programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications running on the operating system. Additionally, a processing device may access, store, manipulate, process, and generate data in response to the execution of software. For ease of understanding, a single processing device may be described as being used; however, those skilled in the art will understand that a processing device includes multiple processing elements and/or multiple types of processing elements. It can be seen that it may include. For example, a processing device may include a plurality of processors or one processor and one controller. Additionally, other processing configurations, such as parallel processors, are possible.

Software may include a computer program, code, instructions, or a combination of one or more of these, which may configure a processing unit to operate as desired, or may be processed independently or collectively. You can command the device. Software and/or data may be used on any type of machine, component, physical device, virtual equipment, computer storage medium or device to be interpreted by or to provide instructions or data to a processing device. It can be embodied in . Software may be distributed over networked computer systems and stored or executed in a distributed manner. Software and data may be stored on one or more computer-readable recording media.

The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc., singly or in combination. The medium may continuously store a computer-executable program, or may temporarily store it for execution or download. In addition, the medium may be a variety of recording or storage means in the form of a single or several pieces of hardware combined. It is not limited to a medium directly connected to a computer system and may be distributed over a network. Examples of media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical recording media such as CD-ROMs and DVDs, magneto-optical media such as floptical disks, And there may be something configured to store program instructions, including ROM, RAM, flash memory, etc. Additionally, examples of other media include recording or storage media managed by app stores that distribute applications, sites that supply or distribute various other software, or servers. Examples of program instructions include machine language code, such as that produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc.

As described above, although the embodiments have been described with limited examples and drawings, various modifications and variations can be made by those skilled in the art from the above description. For example, the described techniques are performed in a different order than the described method, and/or components of the described system, structure, device, circuit, etc. are combined or combined in a different form than the described method, or other components are used. Alternatively, appropriate results may be achieved even if substituted or substituted by an equivalent.

Therefore, other implementations, other embodiments, and equivalents of the claims also fall within the scope of the following claims.

Claims (20)

In a method of providing a volume of a computer device implementing backend storage,
Receiving, by at least one processor included in the computer device, a volume creation request from a client in a container environment;
storing volume metadata in a database according to the volume creation request, by the at least one processor;
scheduling, by the at least one processor, a volume node of the backend storage to create the volume; and
Requesting, by the at least one processor, the creation of a logical volume (LV) corresponding to the volume to a volume node selected through the scheduling
How to provide a volume containing. According to paragraph 1,
The volume creation request is received through an API call from the client as a Persistence Volume Claim (PVC) is created in the client. According to paragraph 1,
The scheduling step is,
After calling a module for scheduling the volume node according to a scheduling algorithm, delivering a response to the volume creation request to the client regardless of a response from the selected volume node; and
Selecting one volume node among a plurality of volume nodes through the scheduling using the called module.
How to provide a volume containing. According to paragraph 3,
A volume provision method characterized in that a PV (Persistence Volume) that manages the volume in the client is created based on the response delivered to the client and bound to the PVC that triggered the volume creation request. According to paragraph 1,
A volume provision method characterized in that a logical volume corresponding to the volume is created at the selected volume node according to a request to the selected volume node. According to paragraph 1,
Receiving, by the at least one processor, a volume delete request from the client; and
Forwarding, by the at least one processor, the volume deletion request to the selected volume node through a message queue.
A method of providing a volume further comprising: According to clause 6,
A volume provision method characterized in that the corresponding logical volume is deleted from the selected volume node in response to the volume deletion request. In a method of providing a volume of a computer device implementing backend storage,
Receiving, by at least one processor included in the computer device, a volume export request from a client in a container environment;
Requesting, by the at least one processor, creation and export of a target to a volume node that manages a corresponding volume according to the volume export request;
Receiving, by the at least one processor, information on a target exported from the volume node; and
Transferring the received target information to the client by the at least one processor
How to provide a volume containing. According to clause 8,
A volume provision method, characterized in that the volume export request is received by an API call from the client as a pod is created in the client. According to clause 8,
In response to a request for creation and export of the target, a target corresponding to the logical volume created in the volume node is created and exported at the volume node, and information on the created target is transmitted to the computer device. How to provide. According to clause 8,
The target information includes the IP of the host serving as the volume node, the port, and the identifier of the target. According to clause 8,
The target is mapped to the block device of the client by accessing the target from the client based on the information on the target,
A volume provision method, wherein the pod created in the client is bound to the block device and becomes accessible to the logical volume of the volume node corresponding to the target. According to clause 8,
receiving, by the at least one processor, an export removal request from the client; and
Forwarding, by the at least one processor, the export removal request to the volume node through a message queue.
A volume providing method further comprising: According to clause 13,
A volume provision method characterized in that the target is removed from the volume node according to the export removal request. A computer program stored in a computer-readable recording medium for executing the method of any one of claims 1 to 14 on the computer device. In computer devices,
At least one processor implemented to execute readable instructions on the computer device
Including,
By the at least one processor,
Receiving a volume creation request from a client in a container environment;
storing volume metadata in a database according to the volume creation request;
Scheduling a volume node of backend storage to create the volume; and
Requesting the creation of a logical volume (Logical Volume, LV) corresponding to the volume to the volume node selected through the scheduling.
A computer device characterized by a. According to clause 16,
The volume creation request is received by an API call from the client as a PVC (Persistence Volume Claim) is created in the client.
A computer device characterized by a. According to clause 16,
For the scheduling, by the at least one processor,
After calling a module for scheduling the volume node according to a scheduling algorithm, a response to the volume creation request is delivered to the client regardless of the response from the selected volume node,
Selecting one volume node among a plurality of volume nodes through the scheduling using the called module.
A computer device characterized by a. In computer devices,
At least one processor implemented to execute readable instructions on the computer device
Including,
By the at least one processor,
Receive volume export requests from clients in the container environment,
Request creation and export of a target to the volume node that manages the corresponding volume according to the volume export request,
Receive information about the target exported from the volume node,
Transferring the received target information to the client
A computer device characterized by a. According to clause 19,
The volume export request is received by the client's API call as a pod is created in the client.
A computer device characterized by a.

Images