Cloud storage processing method, device, computer equipment, readable storage medium and program product

Abstract

The present application relates to a cloud storage processing method, apparatus, computer equipment, computer-readable storage medium and computer program product, and relates to the field of cloud storage technology. The present application can reduce cloud disk access latency and improve cloud disk storage access performance. The method includes: determining the block storage engine node where the cloud disk server is located; the block storage engine node starts a node optimizer; binding a business scheduling unit to the block storage engine node, and sending the address of the block storage engine node to a redirector; according to a login request of a cloud disk client mounted by the business scheduling unit, providing an address to the cloud disk client through the redirector for login, so that the business scheduling unit can log in to the block storage engine node to perform input and output operations of the cloud disk business; wherein the node optimizer is used to start the kernel service of the extended Berkeley packet filter at the block storage engine node, and forward the input and output requests of the input and output operations at the kernel level.

Description

Technical Field

[0001] The present application relates to the field of cloud storage technology, and in particular to a cloud storage processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Art

[0002] Current cloud storage systems are mostly based on traditional centralized storage architectures. Their default schedulers make the cloud disk network input and output (IO) paths too long, while excessive reliance on third-party network plug-ins can easily increase the complexity and maintenance costs of the cloud storage system.

[0003] Therefore, the current cloud storage processing technology still needs to be improved in terms of cloud disk storage access performance. Summary of the Invention

[0004] Based on this, it is necessary to provide a cloud storage processing method, apparatus, computer equipment, computer-readable storage medium and computer program product to address the above technical issues.

[0005] In a first aspect, the present application provides a cloud storage processing method, comprising:

[0006] Determine the block storage engine node where the cloud disk server is located; wherein the block storage engine node starts a node optimizer;

[0007] Binding a service scheduling unit to the block storage engine node, and sending the address of the block storage engine node to the redirector;

[0008] According to a login request of the cloud disk client mounted by the service scheduling unit, the redirector provides the address to the cloud disk client for login, so that the service scheduling unit can log in to the block storage engine node to perform input and output operations of the cloud disk service;

[0009] The node optimizer is used to start the kernel service of the extended Berkeley packet filter on the block storage engine node, and forward the input and output requests of the input and output operations at the kernel level.

[0010] In one embodiment, determining the block storage engine node where the cloud disk server is located includes: after monitoring the generated cloud disk description record through the cloud disk copy management service, determining the target block storage engine node according to the load information of each node; sending a volume creation request to the block storage engine interface of the target block storage engine node through the cloud disk copy management service; the block storage engine interface is used to call the remote procedure call interface provided by the target block storage engine node to execute volume creation and setting, thereby obtaining the block storage engine node where the cloud disk server is located.

[0011] In one of the embodiments, after the generated cloud disk description record is monitored by the cloud disk copy management service, before the target block storage engine node is determined according to the load information of each node, it also includes: initiating a disk creation request to the management request processing interface through the cluster's persistent storage standard interface; and generating the cloud disk description record according to the disk creation request through the management request processing interface.

[0012] In one of the embodiments, determining the target block storage engine node based on the load information of each node includes: determining a target number of nodes as the target block storage engine nodes based on the load information of each node; binding the service scheduling unit to the block storage engine node includes: binding the service scheduling unit to one of the block storage engine nodes.

[0013] In one embodiment, before determining the block storage engine node where the cloud disk server is located, the method further includes: after the cluster deployment is completed, triggering each block storage engine node of the cluster to start the node optimizer, so that the node optimizer starts the kernel service of the extended Berkeley packet filter.

[0014] In one embodiment, binding the business scheduling unit to the block storage engine node includes: when the cluster creates the business scheduling unit and mounts the persistent volume declaration corresponding to the cloud disk, identifying the business scheduling unit through the scheduling unit scheduler, and binding the business scheduling unit to the block storage engine node where the cloud disk server is located.

[0015] In a second aspect, the present application further provides a cloud storage processing device, comprising:

[0016] A node determination module is used to determine the block storage engine node where the cloud disk server is located; wherein the block storage engine node starts the node optimizer;

[0017] a scheduling binding module, configured to bind a service scheduling unit to the block storage engine node and send the address of the block storage engine node to a redirector;

[0018] a login processing module, configured to provide the address to the cloud disk client for login via the redirector according to a login request of the cloud disk client mounted by the service scheduling unit, so that the service scheduling unit can log in to the block storage engine node to perform input and output operations of the cloud disk service;

[0019] The node optimizer is used to start the kernel service of the extended Berkeley packet filter on the block storage engine node, and forward the input and output requests of the input and output operations at the kernel level.

[0020] In a third aspect, the present application further provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0021] Determine the block storage engine node where the cloud disk server is located; wherein the block storage engine node starts a node optimizer; bind a service scheduling unit to the block storage engine node, and send the address of the block storage engine node to a redirector; according to a login request of a cloud disk client mounted by the service scheduling unit, provide the address to the cloud disk client through the redirector for login, so that the service scheduling unit can log in to the block storage engine node to perform input and output operations of the cloud disk service; wherein the node optimizer is used to start a kernel service of an extended Berkeley packet filter on the block storage engine node, and forward the input and output requests of the input and output operations at the kernel level.

[0022] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the following steps are implemented:

[0023] Determine the block storage engine node where the cloud disk server is located; wherein the block storage engine node starts a node optimizer; bind a service scheduling unit to the block storage engine node, and send the address of the block storage engine node to a redirector; according to a login request of a cloud disk client mounted by the service scheduling unit, provide the address to the cloud disk client through the redirector for login, so that the service scheduling unit can log in to the block storage engine node to perform input and output operations of the cloud disk service; wherein the node optimizer is used to start a kernel service of an extended Berkeley packet filter on the block storage engine node, and forward the input and output requests of the input and output operations at the kernel level.

[0024] In a fifth aspect, the present application further provides a computer program product, comprising a computer program, which, when executed by a processor, implements the following steps:

[0025] Determine the block storage engine node where the cloud disk server is located; wherein the block storage engine node starts a node optimizer; bind a service scheduling unit to the block storage engine node, and send the address of the block storage engine node to a redirector; according to a login request of a cloud disk client mounted by the service scheduling unit, provide the address to the cloud disk client through the redirector for login, so that the service scheduling unit can log in to the block storage engine node to perform input and output operations of the cloud disk service; wherein the node optimizer is used to start a kernel service of an extended Berkeley packet filter on the block storage engine node, and forward the input and output requests of the input and output operations at the kernel level.

[0026] The cloud storage processing method, apparatus, computer device, computer-readable storage medium, and computer program product described above determine the block storage engine node where the cloud disk server is located; the block storage engine node starts a node optimizer; a service scheduling unit is bound to the block storage engine node, and the address of the block storage engine node is sent to a redirector; based on a login request from a cloud disk client mounted by the service scheduling unit, the address is provided to the cloud disk client through the redirector for login, so that the service scheduling unit can log in to the block storage engine node to perform input and output operations for the cloud disk service; wherein the node optimizer is used to start a kernel service of an extended Berkeley packet filter on the block storage engine node, and forward input and output requests for input and output operations at the kernel level. This solution can dispatch the business scheduling unit to the block storage engine node where the cloud disk server is located, and combine it with the kernel service of the extended Berkeley packet filter started by starting the node optimizer at the block storage engine node of the cloud storage system. The requests corresponding to the input and output operations of the cloud disk business from this node and sent to this node are forwarded directly at the kernel level. This can bypass the protocol stack to shorten the network input and output path, reduce the cloud disk access latency, and improve the cloud disk storage access performance. In addition, the kernel service of the extended Berkeley packet filter is integrated in the block storage engine node, which can directly optimize the node without installing a third-party network plug-in, reducing the deployment complexity and maintenance cost of the cloud storage system. Because unnecessary protocol stacks can be bypassed, overall resources are also optimized, which is suitable for various cloud native scenarios that require high-performance storage solutions. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following briefly introduces the drawings required for use in the embodiments of the present application or related technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying any creative work.

[0028] Figure 1 This is an application environment diagram of a cloud storage processing method in one embodiment;

[0029] Figure 2 1 is a flow chart of a cloud storage processing method according to an embodiment;

[0030] Figure 3 A schematic diagram of the kernel services for extending the Berkeley packet filter;

[0031] Figure 4 A schematic flow chart of a cloud storage processing method according to another embodiment;

[0032] Figure 5 is a structural block diagram of a cloud storage processing device in one embodiment;

[0033] Figure 6 FIG. 1 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0034] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0035] Introduction to some terms involved in this application:

[0036] K8s (Kubernetes): A distributed architecture solution and cluster management system based on container technology.

[0037] K8s Operator: A Kubernetes extension that helps users manage applications and services in a customized manner using Kubernetes' declarative API (application programming interface) style.

[0038] CSI (Container Storage Interface): is a standard interface for providing persistent storage for Kubernetes clusters.

[0039] CRD (Custom Resource Definition): Custom resource definition is one of the Kubernetes extension mechanisms.

[0040] CR (Custom Resource): is a specific instance of a custom resource.

[0041] iSCSI (Internet Small Computer System Interface): Internet Small Computer System Interface is a storage protocol based on TCP / IP network.

[0042] SPDK (Storage Performance Development Kit): Storage Performance Development Kit.

[0043] eBPF (extended Berkeley Packet Filter): Extended Berkeley Packet Filter, a program that runs on the Linux kernel to efficiently process network packets.

[0044] The cloud storage processing method provided in the embodiments of the present application can be applied to a server. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides cloud computing services. The server can communicate with the terminal through a network. The terminal can be, but is not limited to, various personal computers, laptops, smartphones, tablets, Internet of Things devices, and portable wearable devices. The Internet of Things devices can be smart speakers, smart TVs, smart air conditioners, smart car devices, projection devices, etc. Portable wearable devices can be smart watches, smart bracelets, head-mounted devices, etc. The head-mounted devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc.

[0045] The cloud storage processing method provided in the embodiment of the present application can be based on the following Figure 1 The application environment implementation shown can be used as a system architecture topology for implementing a cloud storage processing method.

[0046] Among them, the main metadata may include:

[0047] XBSDisk: Cloud disk description record, which can include some basic metadata of the cloud disk.

[0048] XBSDiskReplicas: Cloud disk replica information, which can describe which block storage engine XBSTarget nodes the replicas of this cloud disk are allocated to.

[0049] Among them, the main components may include:

[0050] XBSMangerAPI: A management and control request processing interface that is responsible for handling management and control requests, including operations such as cloud disk creation, deletion, modification, query, expansion, cloning, and backup. It can also update cloud disk metadata to the custom resource definition (CRD) of the cloud disk description record XBSDisk.

[0051] XBSRedirector: Redirector that can provide input and output (IO) redirection function. When the input and output request of the cloud disk client fails, it can be redirected to the available block storage engine XBSTarget copy.

[0052] Keepalived: Keep alive, providing high availability services, ensuring the high availability of the management request processing interface XBSMangerAPI and the redirector XBSRedirector.

[0053] XBSReplica: Cloud disk replica management, responsible for the management of cloud disk replicas. It can select the optimal block storage engine XBSTarget node based on the load of the storage node, and create or modify cloud disk replica information XBSDiskReplicas records.

[0054] XBStorAPI: Block storage engine interface, which can receive actual business requests from the management request processing interface XBSMangerAPI and convert them into remote procedure call (RPC) operations on the block storage engine XBSTarget.

[0055] XBSTarget: A block storage engine developed based on SPDK (High-Performance Storage Development Kit). It can receive remote procedure call (RPC) control requests from the block storage engine interface XBStorAPI, and provide input and output (IO) services for actual data volumes through the iSCSI (Internet Small Computer System Interface) protocol.

[0056] XBSNodeOptimizer: A node optimizer that uses eBPF (Extended Berkeley Packet Filter) technology to optimize input and output (IO) requests directly at the kernel layer, bypassing the protocol stack and shortening the network input and output (IO) path.

[0057] XBSScheduler: A custom Pod scheduler that prioritizes scheduling Pods to nodes where cloud disk replicas are located, notifies the redirector XBSRedirector to adjust input and output (IO) paths, and collaborates with the node optimizer XBSNodeOptimizer to significantly improve storage performance.

[0058] like Figure 1 As shown, the above components, including the control request processing interface XBSMangerAPI, the redirector XBSRedirector, and the keepalived, can be deployed in different containers of the scheduling unit pod named the control node XBSController, and can be hosted using k8s's statefulset (stateful set), and can be configured with two copies of the master and the backup. The cloud disk replica management XBSReplica and the scheduling unit pod scheduler XBSScheduler can be hosted by an independent deployment (a resource object used to manage the deployment and update of applications), and a replica set can be set. The block storage engine interface XBStorAPI, the block storage engine XBSTarget, and the node optimizer XBSNodeOptimizer can be deployed in different containers of the scheduling unit pod named the data node XBSNode. This scheduling unit pod will be pulled up on each data node.

[0059] The following is based on Figure 1 The system architecture shown is combined with various embodiments and corresponding drawings to illustrate the cloud storage processing method of the present application.

[0060] In an exemplary embodiment, Figure 2 As shown, a cloud storage processing method is provided, combined with Figure 1 , the method may include the following steps:

[0061] Step S201: Determine the block storage engine node where the cloud disk server is located.

[0062] In this step, after the cloud disk server is deployed, the block storage engine XBSTarget node where the cloud disk server is located is determined. The block storage engine XBSTarget node starts the node optimizer XBSNodeOptimizer.

[0063] Step S202: Bind the service scheduling unit to the block storage engine node, and send the address of the block storage engine node to the redirector.

[0064] In this step, the business scheduling unit pod can be bound to the above-mentioned block storage engine XBSTarget node, and the address of the bound block storage engine XBSTarget node is sent to the redirector XBSRedirector, so that the business scheduling unit pod can be bound and allocated to the same data node (as the cloud disk server).

[0065] Step S203: According to the login request of the cloud disk client mounted by the business scheduling unit, the redirector provides an address to the cloud disk client for login, so that the business scheduling unit can log in to the block storage engine XBSTarget node to perform input and output operations of the cloud disk business.

[0066] In this step, the cloud disk client mounted on the business scheduling unit pod can log in to the same block storage engine XBSTarget node (as the cloud disk server) through iscsi (Internet Small Computer System Interface) and make the final data input and output (IO) request. Among them, according to the login request of the cloud disk client mounted on the business scheduling unit pod, the address of the above-mentioned bound block storage engine XBSTarget node can be provided by XBSRedirector and returned to the cloud disk client for login, so that the business scheduling unit pod can log in to the block storage engine XBSTarget node to perform the input and output (IO) operation of the cloud disk business. Figure 1 and Figure 3As shown, the node optimizer XBSNodeOptimize is started on the block storage engine XBSTarget node. The node optimizer XBSNodeOptimizer is used to start the kernel service of the extended Berkeley packet filter eBPF on the block storage engine XBSTarget node, and forward the input and output requests of the above-mentioned input and output operations at the kernel level. Specifically, the block storage engine XBSTarget input and output io requests from this node and sent to this node can be forwarded directly in the kernel, bypassing the protocol stack. Among them, the node optimizer XBSNodeOptimize uses the extended Berkeley packet filter eBPF program to forward data packets directly at the socket level inside the kernel. After the extended Berkeley packet filter eBPF redirect function (the main function is to redirect data packets to a specific processing path during data packet processing), the data packets can bypass the relevant devices and protocol stack of the local machine and be directly forwarded to the socket socket monitored by the destination process.

[0067] The cloud storage processing method of this embodiment determines the block storage engine node where the cloud disk server is located; the block storage engine node starts a node optimizer; the service scheduling unit is bound to the block storage engine node, and the address of the block storage engine node is sent to a redirector; according to a login request of a cloud disk client mounted by the service scheduling unit, the address is provided to the cloud disk client through the redirector for login, so that the service scheduling unit can log in to the block storage engine node to perform input and output operations of the cloud disk service; wherein the node optimizer is used to start a kernel service of the extended Berkeley packet filter on the block storage engine node, and forward input and output requests of the input and output operations at the kernel level. This solution can dispatch the business scheduling unit to the block storage engine node where the cloud disk server is located, and combine it with the kernel service of the extended Berkeley packet filter started by starting the node optimizer at the block storage engine node of the cloud storage system. The requests corresponding to the input and output operations of the cloud disk business from this node and sent to this node are forwarded directly at the kernel level. This can bypass the protocol stack to shorten the network input and output path, reduce the cloud disk access latency, and improve the cloud disk storage access performance. In addition, the kernel service of the extended Berkeley packet filter is integrated in the block storage engine node, which can directly optimize the node without installing a third-party network plug-in, reducing the deployment complexity and maintenance cost of the cloud storage system. Because unnecessary protocol stacks can be bypassed, overall resources are also optimized, which is suitable for various cloud native scenarios that require high-performance storage solutions.

[0068] In an exemplary embodiment, determining the block storage engine XBSTarget node where the cloud disk server is located in step S201 may include:

[0069] After the cloud disk copy management service monitors the generated cloud disk description record, it determines the target block storage engine node based on the load information of each node; it sends a volume creation request to the block storage engine interface of the target block storage engine node through the cloud disk copy management service; the block storage engine interface is used to call the remote procedure call interface provided by the target block storage engine node to execute volume creation and settings, and obtain the block storage engine node where the cloud disk server is located.

[0070] In this embodiment, the cloud disk replica management XBSReplica service can monitor whether a cloud disk description record XBSDisk is generated. After the cloud disk replica management XBSReplica service monitors the generated cloud disk description record XBSDisk, it can determine the target block storage engine XBSTarget node (as the storage backend) based on the load information of each node in the cluster. One or more target block storage engine XBSTarget nodes can be determined. The cloud disk replica management XBSReplica service can then send a volume creation request to the block storage engine interface XBStorAPI of each target block storage engine XBSTarget node. The block storage engine interface XBStorAPI calls the remote procedure call RPC interface provided by the target block storage engine XBSTarget node to execute volume creation and configuration, thereby obtaining the block storage engine XBSTarget node where the cloud disk server is located.

[0071] In an exemplary embodiment, further, after the generated cloud disk description record XBSDisk is monitored by the cloud disk replica management XBSReplica service, before the target block storage engine XBSTarget node is determined according to the load information of each node, the following may also be included:

[0072] Initiate a disk creation request to the management request processing interface through the cluster's persistent storage standard interface; generate a cloud disk description record based on the disk creation request through the management request processing interface.

[0073] In this embodiment, a disk creation request can be initiated to the management request processing interface XBSMangerAPI through the persistent storage standard interface CSI of the K8s cluster. After the management request processing interface XBSMangerAPI receives the disk creation request from the management request processing interface XBSMangerAPI, it can generate a cloud disk description record XBSDisk according to the disk creation request.

[0074] In an exemplary embodiment, further, the above-mentioned determining the target block storage engine node based on the load information of each node may include: determining a target number of nodes as the target block storage engine nodes based on the load information of each node; binding the business scheduling unit to the block storage engine node in step S202 may include: binding the business scheduling unit to one of the block storage engine nodes.

[0075] In this embodiment, based on the load information of each node in the K8s cluster, two (target number) nodes can be selected as target block storage engine XBSTarget nodes. During the binding phase, the service scheduling unit pod can be bound to one of the block storage engine XBSTarget nodes.

[0076] In an exemplary embodiment, before determining the block storage engine node where the cloud disk server is located in step S201, the method of the present application may further include:

[0077] After the cluster deployment is completed, each block storage engine node of the cluster is triggered to start the node optimizer, so that the node optimizer starts the kernel service of the extended Berkeley packet filter.

[0078] In this embodiment, after the storage cluster is deployed, each block storage engine XBSTarget node of the cluster can be triggered to start the node optimizer XBSNodeOptimizer, and the node optimizer XBSNodeOptimizer will start the kernel service of the extended Berkeley packet filter eBPF on the respective block storage engine XBSTarget node.

[0079] In an exemplary embodiment, binding the service scheduling unit to the block storage engine node in step S202 may include:

[0080] When the cluster creates a business scheduling unit and mounts the persistent volume declaration corresponding to the cloud disk, the scheduling unit scheduler identifies the business scheduling unit and binds the business scheduling unit to the block storage engine node where the cloud disk server is located.

[0081] In this embodiment, when the K8s cluster creates a business scheduling unit pod and mounts the persistent volume declaration PVC corresponding to the cloud disk, the corresponding business scheduling unit pod can be identified by the scheduling unit scheduler XBSScheduler, and then the business scheduling unit pod can be bound to the block storage engine XBSTarget node where the corresponding cloud disk server is located. If there are two block storage engine XBSTarget nodes, for example, it can be bound to one of them.

[0082] Combine Figure 1 and Figure 4The overall process of the cloud storage processing method of this application is described as follows:

[0083] After the storage cluster is deployed, the system starts the node optimizer XBSNodeOptimizer on the block storage engine XBSTarget node. This service starts the kernel service of the extended Berkeley packet filter eBPF on the block storage engine XBSTarget node, and forwards the block storage engine XBSTarget input and output IO requests from and to this node directly in the kernel, bypassing the protocol stack.

[0084] The K8s cluster initiates a disk creation operation through the persistent storage standard interface CSI. After the control request processing interface XBSMangerAPI receives the request from the persistent storage standard interface CSI, it generates a cloud disk description record XBSDisk.

[0085] After the cloud disk copy management XBSReplica service monitors the newly generated cloud disk description record XBSDisk, it selects two optimal block storage engine XBSTarget nodes as the storage backend based on the storage node load, and sends the volume creation request to the block storage engine interface XBStorAPI of the corresponding node.

[0086] The block storage engine interface XBStorAPI calls the remote procedure call (RPC) interface provided by the block storage engine XBSTarget to complete volume creation and configuration.

[0087] When the K8s cluster creates a business scheduling unit pod and mounts the persistent volume declaration PVC corresponding to the cloud disk, the scheduling unit scheduler XBSScheduler identifies the corresponding business scheduling unit pod, binds the business scheduling unit pod to one of the nodes where the block storage engine XBSTarget of the corresponding cloud disk backend is located, and sends the block storage engine XBSTarget address corresponding to the bound node to the redirector XBSRedirector, so that the business scheduling unit pod is bound and assigned to the same data node;

[0088] The cloud disk client mounted on the business scheduling unit pod logs in to the block storage engine XBSTarget on the same node through the Internet Small Computer System Interface (iscsi) and performs the final data input and output io request.

[0089] Because the node optimizer XBSNodeOptimizer optimizes message forwarding at the kernel level by extending the Berkeley Packet Filter (eBPF), shortening the cloud disk input and output IO paths, the entire process achieves the optimization goal.

[0090] In this embodiment, at the node where each storage engine is located, linux eBPF can be used to first forward the cloud disk network input and output io requests from this node and sent to this node directly at the kernel level, bypassing the protocol stack to shorten the network input and output io; secondly, based on the K8s extended scheduler capability, a custom scheduler can be implemented, and the scheduling unit pod can be scheduled to the node where the cloud disk server is located as much as possible through a custom strategy, combined with the extended Berkeley packet filter eBPF technology optimization, thereby achieving an improvement in the cloud disk input and output io performance. At the same time, because unnecessary protocol stacks are bypassed, overall resource utilization is also optimized, which is suitable for various cloud-native scenarios that require high-performance storage solutions. Among them, the storage system component node optimizer XBSNodeOptimizer integrates the kernel network optimization services related to the extended Berkeley packet filter eBPF, which can directly optimize the node without installing a third-party network plug-in, reducing the system deployment complexity and maintenance costs. Among them, through the custom scheduler, the application is scheduled to the node where the storage volume copy is located first. The storage system can schedule the business scheduling unit pod according to the location of the cloud disk server node copy. Combined with the node optimization service, it can shorten the network input and output I / O path of the cloud disk, reduce the cloud disk access latency, and improve storage access performance. Among them, the optimized input and output I / O path is opened through the redirection service. The scheduler is linked with the redirection service. The scheduler writes the address of the target block storage engine XBSTarget node that can achieve input and output I / O path optimization to the redirection service. When the persistent storage standard interface CSI actually mounts the cloud disk, it obtains the target address from the redirection service to mount the cloud disk copy of this node.

[0091] It should be understood that, although the various steps in the flowcharts involved in the various embodiments described above are displayed in sequence according to the instructions of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowcharts involved in the various embodiments described above can include multiple steps or multiple stages, and these steps or stages are not necessarily executed and completed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0092] Based on the same inventive concept, embodiments of the present application also provide a cloud storage processing device for implementing the aforementioned cloud storage processing method. The solution provided by this device is similar to the solution described in the aforementioned method. Therefore, the specific limitations of one or more cloud storage processing device embodiments provided below can be found in the above-described limitations of the cloud storage processing method and will not be further elaborated here.

[0093] In an exemplary embodiment, Figure 5 As shown, a cloud storage processing device is provided, and the device 500 may include:

[0094] The node determination module 501 is used to determine the block storage engine node where the cloud disk server is located; wherein the block storage engine node starts the node optimizer;

[0095] A scheduling binding module 502 is configured to bind a service scheduling unit to the block storage engine node and send the address of the block storage engine node to a redirector;

[0096] A login processing module 503 is configured to provide the address to the cloud disk client for login through the redirector according to a login request of the cloud disk client mounted by the service scheduling unit, so that the service scheduling unit can log in to the block storage engine node to perform input and output operations of the cloud disk service;

[0097] The node optimizer is used to start the kernel service of the extended Berkeley packet filter on the block storage engine node, and forward the input and output requests of the input and output operations at the kernel level.

[0098] In an exemplary embodiment, the node determination module 501 is used to determine the target block storage engine node according to the load information of each node after monitoring the generated cloud disk description record through the cloud disk copy management service; send a volume creation request to the block storage engine interface of the target block storage engine node through the cloud disk copy management service; the block storage engine interface is used to call the remote procedure call interface provided by the target block storage engine node to execute volume creation and setting, and obtain the block storage engine node where the cloud disk server is located.

[0099] In an exemplary embodiment, the node determination module 501 is further used to initiate a disk creation request to the management request processing interface through the cluster's persistent storage standard interface; and generate the cloud disk description record according to the disk creation request through the management request processing interface.

[0100] In an exemplary embodiment, the node determination module 501 is used to determine a target number of nodes as the target block storage engine nodes based on the load information of each node; the scheduling binding module 502 is used to bind the business scheduling unit to one of the block storage engine nodes.

[0101] In an exemplary embodiment, the device 500 may also include: a service triggering module, which is used to trigger each block storage engine node of the cluster to start the node optimizer after the cluster deployment is completed, so that the node optimizer starts the kernel service of the extended Berkeley packet filter.

[0102] In an exemplary embodiment, the scheduling binding module 502 is used to identify the business scheduling unit through the scheduling unit scheduler when the cluster creates the business scheduling unit and mounts the persistent volume declaration corresponding to the cloud disk, and bind the business scheduling unit to the block storage engine node where the cloud disk server is located.

[0103] Each module in the aforementioned cloud storage processing device may be implemented in whole or in part through software, hardware, or a combination thereof. Each module may be embedded in or independent of a processor in a computer device in the form of hardware, or may be stored in a memory in the computer device in the form of software, so that the processor can call and execute the corresponding operations of each module.

[0104] In an exemplary embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Figure 6 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, abbreviated as I / O) and a communication interface. The processor, memory and input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the computer device can be used to store data such as input and output requests. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a cloud storage processing method is implemented.

[0105] Those skilled in the art will understand that Figure 6The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0106] In one embodiment, a computer device is further provided, including a memory and a processor. The memory stores a computer program, and the processor implements the steps in the above method embodiments when executing the computer program.

[0107] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0108] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0109] Those skilled in the art will understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. In particular, any reference to memory, database, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The databases involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the various embodiments provided herein may be, but are not limited to, general-purpose processors, central processing units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), programmable logic devices (PLDs), quantum computing-based data processing logic devices, artificial intelligence (AI) processors, and the like.

[0110] The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0111] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A cloud storage processing method, characterized in that: The method comprises: Determine the block storage engine node where the cloud disk server is located; wherein the block storage engine node starts a node optimizer; Binding a service scheduling unit to the block storage engine node, and sending the address of the block storage engine node to the redirector; According to a login request of the cloud disk client mounted by the service scheduling unit, the redirector provides the address to the cloud disk client for login, so that the service scheduling unit can log in to the block storage engine node to perform input and output operations of the cloud disk service; The node optimizer is used to start the kernel service of the extended Berkeley packet filter on the block storage engine node, and forward the input and output requests of the input and output operations at the kernel level.

2. The method according to claim 1, characterized in that Determining the block storage engine node where the cloud disk server is located includes: After the cloud disk replica management service monitors the generated cloud disk description record, it determines the target block storage engine node based on the load information of each node; A volume creation request is sent to the block storage engine interface of the target block storage engine node through the cloud disk copy management service; the block storage engine interface is used to call the remote procedure call interface provided by the target block storage engine node to execute volume creation and setting, and obtain the block storage engine node where the cloud disk server is located.

3. The method according to claim 2, characterized in that After the generated cloud disk description record is monitored by the cloud disk copy management service, and before the target block storage engine node is determined according to the load information of each node, the method further includes: Initiate a disk creation request to the management request processing interface through the cluster's persistent storage standard interface; The cloud disk description record is generated according to the disk creation request through the control request processing interface.

4. The method according to claim 2, characterized in that Determining the target block storage engine node according to the load information of each node includes: Determine a target number of nodes as the target block storage engine nodes based on the load information of each node; Binding the service scheduling unit to the block storage engine node includes: Bind the service scheduling unit to one of the block storage engine nodes.

5. The method according to claim 1, wherein Before determining the block storage engine node where the cloud disk server is located, the method further includes: After the cluster deployment is completed, each block storage engine node of the cluster is triggered to start the node optimizer, so that the node optimizer starts the kernel service of the extended Berkeley packet filter.

6. The method according to any one of claims 1 to 5, characterized in that Binding the service scheduling unit to the block storage engine node includes: When the cluster creates the business scheduling unit and mounts the persistent volume declaration corresponding to the cloud disk, the scheduling unit scheduler identifies the business scheduling unit and binds the business scheduling unit to the block storage engine node where the cloud disk server is located.

7. A cloud storage processing device, characterized in that: The device comprises: A node determination module is used to determine the block storage engine node where the cloud disk server is located; wherein the block storage engine node starts the node optimizer; a scheduling binding module, configured to bind a service scheduling unit to the block storage engine node and send the address of the block storage engine node to a redirector; a login processing module, configured to provide the address to the cloud disk client for login via the redirector according to a login request of the cloud disk client mounted by the service scheduling unit, so that the service scheduling unit can log in to the block storage engine node to perform input and output operations of the cloud disk service; The node optimizer is used to start the kernel service of the extended Berkeley packet filter on the block storage engine node, and forward the input and output requests of the input and output operations at the kernel level.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images