CN107707620B

CN107707620B - Method and device for processing IO (input/output) request

Info

Publication number: CN107707620B
Application number: CN201710761359.4A
Authority: CN
Inventors: 蒋立新
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Cloud Computing Technologies Co Ltd
Priority date: 2017-08-30
Filing date: 2017-08-30
Publication date: 2020-09-11
Anticipated expiration: 2037-08-30
Also published as: CN107707620A

Abstract

The application discloses a method and a device for processing an IO request, and belongs to the technical field of computer storage. The method comprises the following steps: when the communication sub-component in the first node determines that the service sub-component in the first node is currently upgraded, the communication sub-component in the first node selects a second node from a partner group where the first node is located, sends the target IO request to the communication sub-component in the second node, and sends the target IO request to the server through the communication sub-component in the second node and the service sub-component in the second node. That is, in the present application, since nodes in the partner group may communicate with each other, when a communication sub-component in the first node is currently being upgraded, other nodes in the partner group where the first node is located may be used to process the target IO request instead, so as to avoid interruption of the target IO request being processed due to the fact that a function called when the service sub-component is upgraded cannot be replaced with a hot patch.

Description

Method and device for processing IO (input/output) request

Technical Field

The present disclosure relates to the field of computer storage technologies, and in particular, to a method and an apparatus for processing an Input/Output (IO) request.

Background

At present, a System for processing an IO request mainly includes a service System and a storage System, where the service System includes a service cluster, the storage System includes a client cluster (client) and a server (server), both the service cluster and the client cluster are formed by a plurality of nodes (nodes), and each node in the client cluster includes a Virtual Small Computer System Interface Control (VSC) component and a Virtual Block storage System (VBS) component based on a Small Computer System Interface.

If the protocol for transmitting the IO request is a Small Computer System Interface (SCSI) protocol, when a node in a service cluster initiates the IO request, the node in the service cluster sends the IO request to a VSC component of a node corresponding to a client cluster, the VSC component sends the IO request to the VBS component when receiving the IO request, and the VBS component sends the IO request to a server, so that the server reads or writes data according to the IO request. If the protocol for transmitting the IO request is an Internet small computer System Interface (iSCSI) protocol, when a node in a service cluster initiates the IO request, the node in the service cluster sends the IO request to a VBS component of a node corresponding to a client cluster, and the VBS component sends the IO request to a server, so that the server reads or writes data according to the IO request.

In the system for processing the IO request, when a node in a client cluster needs to be upgraded, in order to avoid interruption of the IO request being processed by the node due to the upgrade of the node, in the process of upgrading the node, if the IO request sent by the node in the service cluster is received, a hot patch is used for replacing a function being called in the current upgrade process, and the hot patch allows the node to process the IO request in the upgrade process, so the node can continue to use the hot patch for upgrading and process the IO request at the same time.

However, in the node upgrade process in the client cluster, not all functions may be replaced with the hot patch, for example, a function called when an component in the VBS component responsible for processing the IO request is upgraded, so if the function being called in the current upgrade process cannot be replaced with the hot patch, the IO request being processed at this time is still interrupted.

Disclosure of Invention

In order to solve the problem that in the related art, if a function being called in a current upgrading process cannot be replaced by a hot patch, the currently processed IO request is still interrupted, the application provides a method and a device for processing the IO request. The technical scheme is as follows:

in a first aspect, a method for processing an IO request is provided, where a client cluster includes multiple partner groups, each partner group includes at least two nodes, the nodes in the partner groups allow communication with each other, a VBS component of any node in the client cluster includes a communication subcomponent and a service subcomponent, the communication subcomponent is used to manage communication between the nodes in the partner groups, and the service subcomponent is a subcomponent in the VBS component that is responsible for processing the IO request, and the method includes:

when a target IO request from a node in a service cluster is received and a communication sub-component in a first node determines that a service sub-component in the first node is currently upgraded, selecting a second node from a partner group where the first node is located, wherein the first node is any node in the client cluster;

and the communication sub-component in the first node sends the target IO request to the communication sub-component in the second node, and the communication sub-component in the second node sends the target IO request to the service sub-component in the second node, so that the service sub-component in the second node sends the target IO request to the server.

In the application, when the service subcomponent in the first node is currently being upgraded, the communication subcomponent in the first node may forward the target IO request to other nodes of the partner group where the first node is located, instead of processing, so that interruption of the target IO request may be avoided.

Optionally, the target IO request is an IO request transmitted in a SCSI protocol, and the first node further includes a VSC component based on a small computer system interface;

the receiving a target IO request from a node in a service cluster, and determining, by a communication subcomponent in a first node, that a service subcomponent in the first node is currently being upgraded includes:

a VSC component in the first node receives the target IO request sent by the node in the service cluster;

when the VSC component in the first node determines that the VSC component is not upgraded, judging whether an upgrade notification sent by a service subcomponent in the first node is received or not, wherein the upgrade notification is used for indicating that the service subcomponent in the first node is being upgraded;

determining that a service subcomponent in the first node is currently being upgraded when the VSC component in the first node has received the upgrade notification;

the VSC component in the first node sends the target IO request to a communication subcomponent in the first node;

and when the communication sub-component in the first node receives the target IO request, determining that the service sub-component in the first node is currently upgraded.

When the target IO request is an IO request transmitted in a SCSI protocol, at this time, the VSC component in the first node receives the target IO request sent by the node in the service cluster, and in order to ensure that the first node can smoothly process the target IO request, the VSC component in the first node needs to determine whether the service subcomponent in the first node is currently upgraded on the premise that the VSC component does not upgrade itself.

Optionally, after determining whether an upgrade notification sent by a service subcomponent in the first node has been received, the method further includes:

when the VSC assembly in the first node does not receive the upgrade notification, determining that a service subcomponent in the first node is not upgraded currently;

the VSC component in the first node sends the target IO request to a service subcomponent in the first node;

and when the service sub-component in the first node receives the target IO request, sending the target IO request to a server.

Further, when the VSC component in the first node determines that the serving subcomponent in the first node is not currently upgraded, the target IO request may be processed directly by the serving subcomponent of the first node.

Optionally, after the VSC component in the first node receives the target IO request sent by the node in the service cluster, the method further includes:

caching the target IO request when the VSC component in the first node determines that the VSC component is currently upgraded;

when the VSC component in the first node determines that the upgrading of the VSC component is completed, the operation of judging whether the upgrading notice sent by the service subcomponent in the first node is received or not is carried out.

Because the probability of upgrading the VSC component is small, and the time required for upgrading the VSC component is short, when the VSC component in the first node is currently upgraded, the target IO request can be temporarily interrupted, and when the upgrading of the VSC component in the first node is completed, the target IO request is reprocessed.

Optionally, the target IO request is an IO request transmitted in an iSCSI protocol of a network-based small computer system interface;

a communication sub-component in the first node receives the target IO request sent by the node in the service cluster;

the communication sub-component in the first node judges whether an upgrade notification sent by a service sub-component in the first node is received or not, wherein the upgrade notification is used for indicating that the service sub-component in the first node is upgrading;

when the communication subcomponent in the first node has received the upgrade notification, determining that a service subcomponent in the first node is currently upgrading.

When the target IO request is an IO request transmitted in an iSCSI protocol, at this time, a communication subcomponent in the first node receives the target IO request transmitted by a node in the service cluster, and in order to ensure that the first node can smoothly process the target IO request, the communication subcomponent in the first node needs to determine whether a service subcomponent in the first node is currently upgraded or not on the premise that the communication subcomponent in the first node is not upgraded.

when the communication sub-component in the first node does not receive the upgrade notification, determining that a service sub-component in the first node is not upgraded currently;

a communication subcomponent in the first node sends the target IO request to a service subcomponent in the first node;

Further, when the communication subcomponent in the first node determines that the service subcomponent in the first node is not currently upgraded, the target IO request may be processed directly by the service subcomponent of the first node.

Optionally, the selecting a second node from a buddy group in which the first node is located includes:

for other nodes except the first node in a partner group where the first node is located, a communication subcomponent in the first node determines a node with the minimum IO request processing pressure in the other nodes as the second node; alternatively, the first and second electrodes may be,

and for other nodes except the first node in the buddy group where the first node is located, the communication subcomponent in the first node determines the node with the highest priority in the other nodes as the second node according to the stored correspondence between the priority and the node.

In order to relieve the stress of each node in the client cluster in processing the IO request, the communication subcomponent in the first node may select the second node from the buddy group in which the first node is located according to the above method.

In a second aspect, an apparatus for processing an IO request is provided, where the apparatus for processing an IO request has a function of implementing the behavior of the method for processing an IO request in the first aspect. The device for processing the IO request includes at least one module, and the at least one module is configured to implement the method for processing the IO request provided by the first aspect.

In a third aspect, an apparatus for processing an IO request is provided, where the apparatus for processing an IO request structurally includes a processor and a memory, and the memory is used to store a program that supports the apparatus for processing an IO request to execute the method for processing an IO request provided in the first aspect, and store data used to implement the method for processing an IO request provided in the first aspect. The processor is configured to execute programs stored in the memory. The operating means of the memory device may further comprise a communication bus for establishing a connection between the processor and the memory.

In a fourth aspect, a computer-readable storage medium is provided, which has instructions stored therein, and when the instructions are executed on a computer, the instructions cause the computer to execute the method for processing an IO request according to the first aspect.

In a fifth aspect, a computer program product containing instructions is provided, which when run on a computer, causes the computer to perform the method for handling IO requests according to the first aspect.

The technical effects obtained by the above second, third, fourth and fifth aspects are similar to the technical effects obtained by the corresponding technical means in the first aspect, and are not described herein again.

The beneficial effect that technical scheme that this application provided brought is:

in the application, when the communication subcomponent in the first node determines that the service subcomponent in the first node is currently upgraded, the communication subcomponent in the first node selects a second node from a partner group where the first node is located, and sends the target IO request to the communication subcomponent in the second node, and the communication subcomponent in the second node sends the target IO request to the service subcomponent in the second node, so that the service subcomponent in the second node sends the target IO request to the server. That is, in the present application, since nodes in the partner group may communicate with each other, when a communication sub-component in the first node is currently being upgraded, other nodes in the partner group where the first node is located may be used to process the target IO request instead, so as to avoid interruption of the target IO request being processed due to the fact that a function called when the first service sub-component is upgraded cannot be replaced with a hot patch.

Drawings

Fig. 1A is a schematic diagram of a system for processing an IO request according to an embodiment of the present invention;

fig. 1B is a schematic path diagram of an IO request according to an embodiment of the present invention;

FIG. 2 is a schematic structural diagram of a computer device according to an embodiment of the present invention;

fig. 3 is a flowchart of a method for processing an IO request according to an embodiment of the present invention;

fig. 4 is a flowchart of another method for processing an IO request according to an embodiment of the present invention;

fig. 5 is a flowchart of another method for processing an IO request according to an embodiment of the present invention;

fig. 6A is a block diagram of an apparatus for processing an IO request according to an embodiment of the present invention;

fig. 6B is a block diagram of another apparatus for processing an IO request according to an embodiment of the present invention;

fig. 6C is a block diagram of another apparatus for processing an IO request according to an embodiment of the present invention.

Detailed Description

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

Before explaining the method for processing the IO request provided by the embodiment of the present invention in detail, a system for processing the IO request according to the embodiment of the present invention is introduced.

As shown in fig. 1A, the system 100 for processing IO requests includes a service system 101 and a storage system 102, where the service system 101 includes a service cluster 1011, and the storage system 102 includes a client cluster 1021 and a server 1022. The service cluster 1011 and the client cluster 1021 are both composed of a plurality of nodes.

The nodes in the service cluster and the nodes in the client cluster are communicated in a wired or wireless mode, and the nodes in the client cluster and the server are also communicated in a wired or wireless mode.

In addition, as shown in fig. 1A, a plurality of buddy groups are included in the client cluster, each buddy group includes at least two nodes, the nodes in the buddy groups allow communication with each other, and the VBS component of any node in the client cluster includes a communication subcomponent and a service subcomponent. The communication sub-component is used for managing communication between nodes in the partner group, and the service sub-component is a sub-component in the VBS component and is responsible for processing IO requests. That is, in the system for processing an IO request shown in fig. 1A, nodes in a buddy group may communicate with each other, and for convenience of description, any node in a client cluster is referred to as a first node. In practice, the communication sub-component may be labeled as VBS-COMM and the Service sub-component may be labeled as VBS-Service.

When a certain node in the service cluster 1011 initiates an IO request, the IO request is sent to a node corresponding to the client cluster 1021 according to a predetermined path, and the node corresponding to the client cluster 1021 sends the IO request to the server. The process of sending the IO request to the server by the node corresponding to the client cluster 1021 will be explained in the following method embodiment, which will not be described in detail herein. For the convenience of description, the process of transmitting the IO request from the service cluster to the server is referred to as a path of the IO request.

It should be noted that the node in the client cluster and the node in the service cluster may be deployed on the same object entity, and may be deployed on different physical entities. When the nodes in the client cluster and the nodes in the service cluster are deployed on the same physical entity, the protocol for transmitting the IO request is a SCSI protocol. When the nodes in the client cluster and the nodes in the service cluster are deployed on different physical entities, the protocol for transmitting the IO request is an iSCSI protocol.

It should be further noted that, for the VSC component and the VBS component included in each node in the client cluster, the VSC component is a core-state component, and the VBS component is a user-state component. The kernel mode and the user mode refer to the right of the program in running, that is, the program running in the kernel mode can be completed only by the help of the operating system, and the program running in the user mode cannot access the kernel data structure and the program of the operating system.

Therefore, when an IO request is transmitted in a different protocol, the path of the IO request is also different. Specifically, as shown in fig. 1B, for the IO request transmitted by the SCSI protocol, because the node in the client cluster and the node in the service cluster in the SCSI protocol are disposed on the same physical entity, the IO request sent by the node in the service cluster must first pass through the VSC component in the kernel state, and then can pass through the VBS component in the user state. That is, the path of the IO request at this time is: a node in the traffic cluster → a VSC component of a corresponding node in the client cluster → a VBS component of a corresponding node in the client cluster → a server.

For the IO request transmitted by the iSCSI protocol, because the node in the client cluster and the node in the service cluster in the iSCSI protocol are deployed on different physical entities, the IO request does not need to pass through the VSC component in the kernel state, and can directly pass through the VBS component in the user state. That is, at this time, the path of the IO request is: node in the traffic cluster → VBS component of the corresponding node in the client cluster → server.

It is worth noting that when the server receives the IO request, the server reads/writes data according to the IO request, generates IO return information corresponding to the IO request, and returns the IO return information to the node in the service cluster that initiated the IO request according to the path original path of the IO request. That is, the path for transmitting the IO return information from the server to the node in the service cluster is identical to the path for transmitting the IO request from the node in the service cluster to the server, and will not be described in detail herein.

In addition, both the nodes in the service cluster and the nodes in the client may be deployed on an object entity, and the physical entity may be any computer device, such as a computer, a tablet computer, a notebook, and the like.

Fig. 2 is a schematic structural diagram of a computer device according to an embodiment of the present invention. The nodes in the service cluster and the nodes in the client cluster shown in fig. 1A and 1B may be deployed in the computer device shown in fig. 2. Referring to fig. 2, the computer device comprises at least one processor 201, a communication bus 202, a memory 203 and at least one communication interface 204.

The processor 201 may be a general-purpose Central Processing Unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more ics for controlling the execution of programs in accordance with the present invention.

The communication bus 202 may include a path that conveys information between the aforementioned components.

The Memory 203 may be a Read-Only Memory (ROM) or other type of static storage device that can store static information and instructions, a Random Access Memory (RAM) or other type of dynamic storage device that can store information and instructions, an Electrically Erasable Programmable Read-Only Memory (EEPROM), a compact disc Read-Only Memory (CD-ROM) or other optical disc storage, optical disc storage (including compact disc, laser disc, optical disc, digital versatile disc, blu-ray disc, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited to these. The memory 203 may be self-contained and coupled to the processor 201 via the communication bus 202. The memory 203 may also be integrated with the processor 201.

Communication interface 204, using any transceiver or the like, is used for communicating with other devices or communication Networks, such as ethernet, Radio Access Network (RAN), Wireless Local Area Network (WLAN), etc.

In particular implementations, processor 201 may include one or more CPUs, as one embodiment.

In particular implementations, a computer device may include multiple processors, as one embodiment. Each of these processors may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. A processor herein may refer to one or more devices, circuits, and/or processing cores for processing data (e.g., computer program instructions).

In particular implementations, a computer device may also include an output device and an input device, as one embodiment. An output device, which is in communication with the processor 201, may display information in a variety of ways. For example, the output device may be a Liquid Crystal Display (LCD), a Light Emitting Diode (LED) display device, a Cathode Ray Tube (CRT) display device, a projector (projector), or the like. The input device is in communication with the processor 201 and may receive user input in a variety of ways. For example, the input device may be a mouse, a keyboard, a touch screen device, or a sensing device, among others.

The computer device may be a general purpose computer device or a special purpose computer device. In a specific implementation, the computer device may be a desktop computer, a laptop computer, a network server, a Personal Digital Assistant (PDA), a mobile phone, a tablet computer, a wireless terminal device, a communication device, or an embedded device. The embodiment of the invention does not limit the type of the computer equipment.

The memory 203 is used for storing program codes for executing the scheme of the application, and the processor 201 controls the execution. The processor 201 is used to execute program code stored in the memory 203. One or more software modules (e.g., a feature extraction engine, a feature transformation engine, a similarity calculation engine, a similarity iterative alignment engine, a user interface presentation module, etc.) may be included in the program code. The nodes in the client clusters shown in fig. 1A and 1B may process IO requests through one or more software modules in program code in processor 201 and memory 203.

Next, a method for processing an IO request according to an embodiment of the present invention is explained, and as shown in fig. 3, the embodiment of the present invention provides a method for processing an IO request, which is applied to the system for processing an IO request shown in fig. 1A, and specifically, the method includes the following two steps:

step 301: when a target IO request from a node in a service cluster is received and a communication sub-component in a first node determines that a service sub-component in the first node is currently upgraded, a second node is selected from a partner group where the first node is located, wherein the first node is any node in the client cluster.

In the embodiment of the present invention, since the nodes in the buddy group can communicate with each other, when the communication subcomponent in the first node determines that the service subcomponent in the first node is currently being upgraded, a second node may be selected from the buddy group where the first node is located, so as to implement the processing of the target IO request by the second node instead, through the following step 302.

The implementation of the communication subcomponent in the first node to select the second node will be described in detail in the following embodiments, which will not be explained first.

Step 302: and the communication sub-component in the first node sends the target IO request to the communication sub-component in the second node, and the communication sub-component in the second node sends the target IO request to the service sub-component in the second node, so that the service sub-component in the second node sends the target IO request to the server.

Through step 302, the communication subcomponent in the first node may send the target IO request to the second node, which processes the target IO request instead, so as to avoid interruption of the target IO request.

It should be noted that, because the protocol for transmitting the IO request may be a SCSI protocol or an iSCSI protocol, and the paths through which the IO request is transmitted in the two protocols are different, the method for processing the IO request provided in the embodiment of the present invention includes two aspects, that is, a process for processing the IO request in the SCSI protocol and a process for processing the IO request in the iSCSI protocol. The following examples will explain these two cases separately.

As shown in fig. 4, an embodiment of the present invention provides a method for processing an IO request, where the method is applied to the system for processing an IO request shown in fig. 1A, and the protocol for transmitting an IO request is a SCSI protocol, and specifically, the method includes the following steps:

step 401: and the VSC component in the first node receives the target IO request sent by the node in the service cluster.

When the protocol for transmitting the IO request is the SCSI protocol, the node in the service cluster and the node in the client cluster corresponding to the node in the service cluster are deployed on the same physical entity, so when the node in the service cluster initiates the target IO request, the node in the service cluster sends the target IO request to the VSC component of the node in the client cluster, that is, the VSC component of the first node receives the target IO request sent by the node in the service cluster.

When the VSC component of the first node receives the target IO request, if the VSC component of the first node is upgrading, the VSC component of the first node cannot continue to process the target IO request.

Specifically, when the VSC component in the first node determines that it is not upgraded, the target IO request may continue to be processed through steps 402 to 406 described below. When the VSC component in the first node determines that it is currently upgrading, the target IO request may continue to be processed through step 407 described below.

Step 402: when the VSC component in the first node determines that the VSC component does not upgrade, whether an upgrade notification sent by a service subcomponent in the first node is received or not is judged.

When the VSC component in the first node determines that the VSC component itself is not upgraded, since the service subcomponent is a subcomponent in the VBS component that is responsible for processing the IO request, if the service subcomponent in the first node is currently being upgraded, the service subcomponent in the first node cannot process the target IO request. Therefore, in the embodiment of the present invention, when the VSC component in the first node determines that it is not upgraded, the VSC component of the first node further needs to determine whether the upgrade notification sent by the service subcomponent in the first node has been received, so as to determine whether the service subcomponent in the first node is upgrading.

Wherein the upgrade notification is used to indicate that the service subcomponent in the first node is upgrading, that is, when the service subcomponent in the first node is upgrading, the service subcomponent in the first node will send the upgrade notification to the VSC component in the first node. In addition, when the upgrade of the service subcomponent in the first node is completed, the service subcomponent in the first node sends an upgrade end notification to the VSC component in the first node to prompt the VSC component in the first node that the upgrade of the service subcomponent in the first node is completed.

Optionally, since the communication subcomponent is used to manage communications between nodes within the buddy group, when the service subcomponent in the first node is upgrading, the service subcomponent in the first node also sends an upgrade notification to the communication subcomponent in the first node. Accordingly, when the upgrade of the service subcomponent in the first node is completed, the service subcomponent in the first node sends an upgrade end notification to the communication subcomponent in the first node to prompt the communication subcomponent in the first node that the upgrade of the service subcomponent in the first node is completed.

Since the VSC component in the first node may or may not have received the upgrade notification sent by the service subcomponent in the first node, when the VSC component in the first node has received the upgrade notification sent by the service subcomponent in the first node, the target IO request may be processed continuously through the following steps 403 to 405, and when the VSC component in the first node does not receive the upgrade notification, the target IO request may be processed continuously through the following step 406.

Step 403: when the VSC component in the first node receives an upgrade notification sent by a service subcomponent in the first node, determining that the service subcomponent in the first node is currently being upgraded, sending the target IO request to a communication subcomponent in the first node by the VSC component in the first node, and determining that the service subcomponent in the first node is currently being upgraded when the target IO request is received by the communication subcomponent in the first node.

When the VSC component in the first node determines that the service subcomponent in the first node is currently being upgraded, it indicates that the first node cannot process the target IO request, and at this time, in order to avoid interruption of the target IO request, the target IO request may be processed by another node in the partner group where the first node is located. Because the first node and the other nodes in the buddy group where the first node is located are deployed on different physical entities, if the first node needs to communicate with the other nodes in the buddy group where the first node is located, the first node needs to communicate through the user-mode component in the node, that is, the first node needs to communicate through the first node and the communication subcomponents in the other nodes in the buddy group where the first node is located.

Therefore, when the VSC component in the first node determines that the service subcomponent in the first node is currently being upgraded, the VSC component in the first node sends the target IO request to the communication subcomponent in the first node, and the communication subcomponent in the first node forwards the target IO request to other nodes in the buddy group where the first node is located to perform processing instead of the target IO request. In particular, the communication subcomponent in the first node may implement this process by steps 404 to 405 described below.

Step 404: when the communication sub-component in the first node determines that the service sub-component in the first node is currently upgrading, a second node is selected from a partner group in which the first node is located.

In particular, the communication subcomponent in the first node may implement step 404 in two possible ways, as described below.

In a first possible manner, for other nodes except the first node in the buddy group where the first node is located, the communication subcomponent in the first node determines, as the second node, a node with the smallest IO request processing pressure in the other nodes.

That is, the communication subcomponent in the first node stores the IO request processing pressure of the other node, and in order to increase the speed of processing the target IO request, the communication subcomponent in the first node may forward the target IO request to the node with the minimum IO request processing pressure in the other node, instead of processing, that is, forward the target IO request to the second node, instead of processing.

The IO request processing pressure of the node is used for representing the size of the IO request processing capacity of the node, and the IO request processing pressure is related to the size of the disk space of the physical entity deployed by the node. That is, the larger the disk space of the physical entity deployed by the node is, the smaller the pressure of the node for processing the IO request is, and the smaller the disk space of the physical entity deployed by the node is, the larger the pressure of the node for processing the IO request is.

In a second possible manner, for other nodes except the first node in the buddy group where the first node is located, the communication subcomponent in the first node determines, according to the stored correspondence between the priority and the node, the node with the highest priority among the other nodes as the second node.

That is, the communication subcomponent in the first node stores the priority of each node in the buddy group where the first node is located, for example, there are four nodes, which are respectively marked as A, B, C and D, in the buddy group where the first node is located, the priority corresponding to the node a is 1, the priority corresponding to the node B is 2, the priority corresponding to the node C is 3, and the priority corresponding to the node D is D. Assuming that the first node is node a, the first node may determine node D as the second node because node D has the highest priority among node B, node C, and node D.

It should be noted that, after the communication subcomponent in the first node determines the second node according to the two possible manners, if the second node is currently processing other IO requests, the second node cannot process the target IO request instead, and at this time, the first node needs to determine the second node again from other nodes except the first node and the second node in the buddy group where the first node is located. In this embodiment, the first node may determine the second node again in two possible ways, which are not described in detail herein.

For example, the first node determines the node D with the highest priority as the second node, and if the node D is currently processing other IO requests, the first node reselects a node with the highest priority from the nodes C and B, that is, determines the node C as the second node again.

In order to enable a communication subcomponent in a first node to timely know whether other nodes in a partner group where the first node is located are currently processing an IO request, for any partner group in a client cluster, when a certain node in the partner group is processing the IO request, the communication subcomponent of the certain node sends prompt information to the other nodes in the partner group, wherein the prompt information is used for indicating that the certain node is currently processing the IO request, and when the other nodes in the partner group receive the prompt information, it is determined that the certain node is currently processing the IO request. That is, for any node in the buddy group, the communication subcomponent of that node masters the dynamics of the processing of IO requests by other nodes in the buddy group in real time.

In addition, in addition to the above two possible manners, the first node may also determine the second node through other possible manners, for example, the first node may randomly select one node from a buddy group where the first node is located as the second node, and the embodiment of the present invention is not specifically limited herein.

Step 405: and the communication sub-component in the first node sends the target IO request to the communication sub-component in the second node, and the communication sub-component in the second node sends the target IO request to the service sub-component in the second node, so that the service sub-component in the second node sends the target IO request to the server.

Since the first node and the second node are deployed on different physical entities, the first node and the second node need to communicate through respective communication subcomponents. That is, the communication subcomponent of the second node will receive the target IO request sent by the communication subcomponent connected to the first node. Since the target IO request is actually processed as a service subcomponent in the second node, the communication subcomponent in the second node needs to send the target IO request to the service subcomponent in the second node, and when the service subcomponent in the second node receives the target IO request, the information carried in the target IO request is identified, so that the target IO request is sent to the corresponding server.

Step 406: when the VSC component in the first node does not receive the upgrade notification, determining that the service subcomponent in the first node is not upgraded currently, sending the target IO request to the service subcomponent in the first node by the VSC component in the first node, and when the service subcomponent in the first node receives the target IO request, sending the target IO request to the server.

When the VSC component in the first node does not receive the update notification, it indicates that the service subcomponent in the first node is not currently updated, and at this time, the target IO request does not need to be forwarded to the second node for processing instead, that is, at this time, the service subcomponent in the first node directly processes the target IO request.

It is worth noting that, because the VSC component in the first node and the service subcomponent in the first node belong to the same node component, communication does not need to be performed through a user-mode communication subcomponent, that is, the VSC component in the first node directly sends the target IO request to the service subcomponent in the first node, and the service subcomponent in the first node processes the target IO request. The way of processing the target IO request by the service subcomponent in the first node is the same as the way of processing the target IO request by the service subcomponent in the second node in step 405, and is not described in detail here.

In the above steps 402 to 406, when the VSC component in the first node determines that the VSC component itself is not upgraded, the VSC component in the first node may process the target IO request in the following step 407.

Step 407: when the VSC component in the first node determines that the VSC component is currently upgrading, the target IO request is cached, and when the VSC component in the first node determines that the upgrading of the VSC component is completed, the operation of judging whether the upgrading notice sent by the service subcomponent in the first node is received or not is executed.

It should be noted that, for the VSC component of the node in the client cluster, the main function of the VSC component is to provide virtual Logical Unit Number (LUN) management to the upper layer application, so that for different nodes in the client cluster, the VSC component is the same component, that is, the VSC component is a fixed component. When a node in a client cluster is upgraded, the probability of upgrading a fixed component, that is, a VSC component is low, for example, in the process of upgrading the node 1000 times, the VSC component of the node may only need to be upgraded 1 time. Also, the time required to upgrade the VSC components of the node is short relative to upgrading the service subcomponents of the node.

Therefore, when the VSC component in the first node determines that the VSC component is currently upgrading, the target IO request may be temporarily interrupted in step 407, and when the VSC component in the first node determines that the self upgrading is completed, the target IO request is reprocessed, that is, when the VSC component in the first node determines that the self upgrading is completed, the target IO request is processed according to the above steps 402 to 406.

In the embodiment of the present invention, when the communication subcomponent in the first node determines that the service subcomponent in the first node is currently being upgraded, the communication subcomponent in the first node selects a second node from a partner group where the first node is located, and sends the target IO request to the communication subcomponent in the second node, and the communication subcomponent in the second node sends the target IO request to the service subcomponent in the second node, so that the service subcomponent in the second node sends the target IO request to the server. That is, since the nodes in the partner group can communicate with each other, when the communication subcomponent in the first node is currently being upgraded, the target IO request can be processed by another node in the partner group where the first node is located, so as to avoid interruption of the target IO request being processed due to the fact that the function called when the first service subcomponent is upgraded cannot be replaced by the hot patch.

As shown in fig. 5, an embodiment of the present invention provides another method for processing an IO request, where the method is applied to the system for processing an IO request shown in fig. 1A, and the method is applied to a scenario where a protocol for transmitting an IO request is an iSCSI protocol, and specifically, the method includes the following steps:

step 501: and a communication sub-component in the first node receives a target IO request sent by a node in the service cluster.

When the protocol for transmitting the IO request is an iSCSI protocol, the nodes in the service cluster and the nodes in the client cluster corresponding to the nodes in the service cluster are deployed on different physical entities, and therefore the nodes in the service cluster and the nodes in the client cluster need to communicate through respective user-state communication subassemblies. That is, when a node in the service cluster initiates a target IO request, the node in the service cluster sends the target IO request to a communication subcomponent of a corresponding node in the client cluster, that is, the communication subcomponent of the first node receives the target IO request sent by the node in the service cluster.

When the communication subcomponent of the first node receives the target IO request, processing of the target IO request may continue through steps 502 to 506 described below.

Step 502: the communication subcomponent in the first node determines whether an upgrade notification sent by the service subcomponent in the first node has been received.

Since the service subcomponent is a subcomponent in the VBS component responsible for processing the IO request, if the service subcomponent in the first node is currently being upgraded, the service subcomponent in the first node cannot process the target IO request. Therefore, in the embodiment of the present invention, the communication subcomponent of the first node needs to determine whether an upgrade notification sent by the service subcomponent in the first node has been received, so as to determine whether the service subcomponent in the first node is upgrading.

Wherein the upgrade notification is used to indicate that the service subcomponent in the first node is upgrading, that is, when the service subcomponent in the first node is upgrading, the service subcomponent in the first node will send an upgrade notification to the communication subcomponent in the first node. In addition, when the upgrade of the service subcomponent in the first node is completed, the service subcomponent in the first node sends an upgrade end notification to the communication subcomponent in the first node to prompt the communication subcomponent in the first node that the upgrade of the service subcomponent in the first node is completed.

Since the communication subcomponent in the first node may or may not have received the upgrade notification sent by the service subcomponent in the first node, when the communication subcomponent in the first node has received the upgrade notification sent by the service subcomponent in the first node, the target IO request may be processed continuously through the following steps 503 to 505, and when the communication subcomponent in the first node does not receive the upgrade notification, the target IO request may be processed continuously through the following step 506.

Step 503: when the communication sub-component in the first node has received the upgrade notification sent by the service sub-component in the first node, determining that the service sub-component in the first node is currently upgrading.

When the communication subcomponent in the first node determines that the service subcomponent in the first node is currently being upgraded, it indicates that the first node cannot process the target IO request, and at this time, in order to avoid interruption of the target IO request, the target IO request may be processed by another node in the partner group where the first node is located. In particular, the communication subcomponent in the first node may implement this process by steps 504 to 505 described below.

Step 504: when the communication sub-component in the first node determines that the service sub-component in the first node is currently upgrading, a second node is selected from a partner group in which the first node is located.

The implementation of step 504 is the same as that of step 404 in the embodiment shown in fig. 4, and will not be described in detail here.

Step 505: and the communication sub-component in the first node sends the target IO request to the communication sub-component in the second node, and the communication sub-component in the second node sends the target IO request to the service sub-component in the second node, so that the service sub-component in the second node sends the target IO request to the server.

The implementation of step 503 is the same as that of step 405 in the embodiment shown in fig. 4, and will not be described in detail here.

Step 506: when the communication sub-component in the first node does not receive the upgrade notification, determining that the service sub-component in the first node is not upgraded currently, sending the target IO request to the service sub-component in the first node by the communication sub-component in the first node, and sending the target IO request to a server when the service sub-component in the first node receives the target IO request.

When the communication subcomponent in the first node does not receive the upgrade notification, it indicates that the service subcomponent in the first node is not upgraded currently, and at this time, the target IO request does not need to be forwarded to the second node for processing instead, that is, at this time, the service subcomponent in the first node directly processes the target IO request.

The way of processing the target IO request by the service subcomponent in the first node is the same as the way of processing the target IO request by the service subcomponent in the second node in step 505, and is not described in detail here.

The above steps 502 to 506 are processes for the target IO request when the communication subcomponent in the first node determines that the communication subcomponent itself is not upgraded, and when the communication subcomponent in the first node determines that the communication subcomponent itself is currently upgraded, the target IO request may be processed through the following step 507.

It should be noted that when the communication subcomponent in the first node is currently being upgraded, the communication subcomponent of the first node will no longer receive the IO request, and when the communication subcomponent in the first node is upgraded, the communication subcomponent of the first node continues to receive the IO request and performs the operations of steps 501 to 506.

In the embodiment of the present invention, in addition to providing the method for processing the IO request described in the above embodiment, an apparatus for processing the IO request is also provided, and the following embodiment is used to describe in detail the apparatus for processing the IO request provided in the embodiment of the present invention.

Referring to fig. 6A, an embodiment of the present invention provides an apparatus 600 for processing an IO request, where the apparatus 600 is applied to the system for processing an IO request shown in fig. 1A, and as shown in fig. 6A, the apparatus 600 includes a communication subcomponent 601 in a first node:

a communication subcomponent 601 in the first node is used to perform step 404 in the fig. 4 embodiment or step 504 in the fig. 5 embodiment.

The communication subcomponent 601 in this first node is also used to perform step 405 in the embodiment of fig. 4 or step 505 in the embodiment of fig. 5.

Optionally, referring to fig. 6B, the apparatus further comprises a VSC component 602 in the first node:

a VSC component 602 in the first node for performing step 401 in the embodiment of fig. 4;

the VSC component 602 in the first node is further configured to perform step 402 in the embodiment of fig. 4;

the VSC component 602 in the first node is further configured to perform step 403 in the embodiment of fig. 4.

Optionally, referring to fig. 6C, the apparatus further comprises a service subcomponent 603 in the first node:

the VSC component 602 in the first node and the service subcomponent 603 in the first node are also used to perform step 406 in the embodiment of fig. 4.

Optionally, the VSC component in the first node is further configured to perform step 407 in the embodiment of fig. 4.

Optionally, the communication subcomponent 601 in the first node is further configured to perform step 501 in the embodiment of fig. 5;

the communication subcomponent 601 in this first node is also used to perform step 502 in the embodiment of fig. 5.

The communication subcomponent 601 in this first node is also used to perform step 503 in the embodiment of fig. 5.

Optionally, the communication subcomponent 601 in the first node and the service subcomponent 603 in the first node are further used to perform step 506 in the embodiment of fig. 5.

Optionally, the communication subcomponent 601 in the first node is specifically configured to:

for other nodes except the first node in the partner group where the first node is located, determining a node with the minimum IO request processing pressure in the other nodes as the second node; alternatively, the first and second electrodes may be,

and for other nodes except the first node in the buddy group where the first node is located, determining the node with the highest priority in the other nodes as the second node according to the stored correspondence between the priority and the node.

It should be noted that: in the device for processing an IO request according to the foregoing embodiment, when the IO request is processed, only the division of each functional module is illustrated, and in practical applications, the function distribution may be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules, so as to complete all or part of the functions described above. In addition, the device for processing the IO request and the method embodiment for processing the IO request provided by the above embodiments belong to the same concept, and specific implementation processes thereof are detailed in the method embodiment and are not described herein again.

In the above embodiments, the implementation may be wholly or partly realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with embodiments of the invention, to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored on a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, from one website, computer, server, or data center to another website, computer, server, or data center via wire (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., Digital Versatile Disk (DVD)), or a semiconductor medium (e.g., Solid State Disk (SSD)), among others.

It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program instructing relevant hardware, where the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a magnetic disk or an optical disk, etc.

The above-mentioned embodiments are provided not to limit the present application, and any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims

1. A method for processing input/output (IO) requests, wherein a plurality of partner groups are included in a client cluster, each partner group includes at least two nodes, the nodes in the partner groups allow communication with each other, a virtual block storage system (VBS) component of any node in the client cluster includes a communication subcomponent for managing communication between the nodes in the partner groups and a service subcomponent which is a subcomponent of the VBS component responsible for processing IO requests, and the any node further includes a Small Computer System Interface (SCSI) -based virtual control (VSC) component which is a component in a kernel state, and the VBS component is a component in a user state, and the method includes:

when a target IO request from a node in a service cluster is received through a communication subcomponent or a VSC component in a first node, and the communication subcomponent in the first node determines that a service subcomponent in the first node is currently upgraded, selecting a second node from a partner group where the first node is located, wherein the first node is any node in the client cluster;

2. The method of claim 1, wherein the target IO request is an IO request transmitted in a small computer system interface SCSI protocol, the first node further comprising a small computer system interface based virtual control VSC component;

the receiving a target IO request from a node in a service cluster, and a communication subcomponent in a first node determining that a service subcomponent in the first node is currently being upgraded, includes:

3. The method of claim 2, wherein after determining whether an upgrade notification sent by a service subcomponent in the first node has been received, further comprising:

4. The method of claim 2 or 3, wherein after the VSC component in the first node receives the target IO request sent by the node in the traffic cluster, further comprising:

5. The method of claim 1, wherein the target IO request is an IO request transmitted in a network-based small computer system interface iSCSI protocol;

6. The method of claim 5, wherein after determining whether an upgrade notification sent by a service subcomponent in the first node has been received, further comprising:

7. The method of any of claims 1 to 3, 5 to 6, wherein selecting the second node from the buddy group in which the first node is located comprises:

8. An apparatus for processing an IO request, wherein a plurality of buddy groups are included in a client cluster, each buddy group includes at least two nodes, the nodes in the buddy groups allow communication with each other, a VBS component of a virtual block storage system of any node in the client cluster includes a communication subcomponent for managing communication between the nodes in the buddy group and a service subcomponent which is a subcomponent of the VBS component responsible for processing the IO request, and the any node further includes a VSC component for virtual control based on a small computer system interface, the VSC component being a component in a kernel state, the VBS component being a component in a user state, the apparatus comprising a communication subcomponent in a first node:

a communication subcomponent in the first node is configured to select a second node from a partner group where the first node is located when it is determined that a service subcomponent in the first node is currently being upgraded, where the first node is any node in the client cluster;

the communication subcomponent in the first node is further configured to send a target IO request received from a node in a service cluster through the communication subcomponent or the VSC component in the first node to the communication subcomponent in the second node, and the communication subcomponent in the second node sends the target IO request to the service subcomponent in the second node, so that the service subcomponent in the second node sends the target IO request to the server.

9. The apparatus of claim 8, wherein the target IO request is an IO request transmitted in a small computer system interface, SCSI, protocol, the first node further comprising a small computer system interface based virtual control, VSC, component;

the apparatus further comprises a VSC component in the first node:

the VSC component in the first node is used for receiving the target IO request sent by the node in the service cluster;

the VSC component in the first node is further used for judging whether an upgrade notification sent by a service subcomponent in the first node is received or not when the VSC component in the first node is determined not to be upgraded, and the upgrade notification is used for indicating that the service subcomponent in the first node is being upgraded;

a VSC component in the first node, further configured to determine that a service subcomponent in the first node is currently being upgraded when the upgrade notification has been received;

the VSC component in the first node is further used for sending the target IO request to a communication subcomponent in the first node;

the communication subcomponent in the first node is further configured to determine that the service subcomponent in the first node is currently being upgraded when the target IO request is received.

10. The apparatus of claim 9, wherein the apparatus further comprises a service subcomponent in the first node:

the VSC component in the first node is further used for determining that the service subcomponent in the first node is not upgraded currently when the upgrade notification is not received;

the VSC component in the first node is further used for sending the target IO request to a service subcomponent in the first node;

and the service subcomponent in the first node is used for sending the target IO request to a server when receiving the target IO request.

11. The apparatus of claim 9 or 10, wherein:

the VSC component in the first node is further used for caching the target IO request when determining that the VSC component is currently upgraded;

and the VSC component in the first node is further used for executing the operation of judging whether the upgrade notification sent by the service subcomponent in the first node is received or not when the upgrade of the VSC component is determined to be completed.

12. The apparatus of claim 8, wherein the target IO request is an IO request transmitted in a network-based small computer system interface iSCSI protocol;

a communication subcomponent in the first node is further configured to receive the target IO request sent by the node in the service cluster;

the communication sub-component in the first node is further configured to determine whether an upgrade notification sent by a service sub-component in the first node has been received, where the upgrade notification is used to indicate that the service sub-component in the first node is upgrading;

a communication subcomponent in the first node further configured to determine that a service subcomponent in the first node is currently upgrading when the upgrade notification has been received.

13. The apparatus of claim 12, wherein the apparatus further comprises a service subcomponent in the first node:

the communication sub-component in the first node is further used for determining that the service sub-component in the first node is not upgraded currently when the upgrade notification is not received;

a communication subcomponent in the first node further configured to send the target IO request to a service subcomponent in the first node;

14. The apparatus according to any of claims 8-10, 12-13, wherein the communication subcomponent in the first node is specifically configured to:

for other nodes except the first node in a partner group where the first node is located, determining a node with the minimum IO request processing pressure in the other nodes as the second node; alternatively, the first and second electrodes may be,