End-to-end dual-channel storage IO processing method

Abstract

The present application discloses an end-to-end dual-channel storage IO processing method, comprising: performing service identification at a client, and labeling IOs; then, during the creation of RDMA channels, creating two IO channels whose resources are fully isolated, if the IOs are low-latency IOs, using a low-latency IO channel to perform data transmission, and if the IOs are regular IOs, selecting a regular IO channel for transmission; and during IO processing at a backend storage node, preferentially polling all low-latency IOs from the low-latency channel for processing, then retrieving some IOs from the regular IO channel for processing, and when the processing is completed, continuing to poll all the low-latency IOs from the low-latency channel for processing. In this way, end-to-end latency of low-latency IOs is ensured to be controllable.

Description

An end-to-end dual-channel storage I / O processing method

[0001] Related applications

[0002] This application claims priority to Chinese patent application filed on April 29, 2024, application number 202410524416.7, entitled “An End-to-End Dual-Channel Storage I / O Processing Method”, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application belongs to the field of computer storage technology, and in particular relates to an end-to-end dual-channel storage I / O processing method. Background Technology

[0004] With digital transformation, cloud services are gaining increasing popularity. Various IT systems are migrating to the cloud. However, this migration process has encountered numerous problems. A prime example is that previously, systems and storage devices were self-built, with performance primarily dependent on the hardware purchased. After migrating to the cloud, however, the use of shared hardware resources often leads to performance contention between tenants, causing one tenant's business to be affected by the business of another tenant completely unaware of its existence. To mitigate this impact, most cloud vendors have implemented multi-tenant business isolation. However, resource isolation for multi-tenant cloud storage is a challenge because the underlying storage system is a unified storage cluster, making it impossible to allocate different resources to each tenant. Furthermore, cloud providers often rely on overselling to reduce overall operating costs and achieve profitability. This makes it impossible to allocate sufficient storage resources to each tenant, necessitating a content contention mechanism.

[0005] Currently, most systems ensure SLA achievable by reserving sufficient resources and enabling emergency scaling when performance is insufficient. While this approach solves most problems, it doesn't address the issue of customers failing latency verification when multiple tenants are simultaneously verifying latency and IOPS performance. Furthermore, there's the risk of delayed scaling leading to disruptions for VIP customers and critical business operations. Summary of the Invention

[0006] An end-to-end dual-channel storage I / O processing method, implemented based on the LAVA storage system, includes the following steps:

[0007] Step 1: On the client side, identify the business logic and tag the I / O, indicating whether it is low-latency I / O or normal I / O.

[0008] Step 2: When creating an RDMA channel, create two completely isolated IO channels. When the IO is a low-latency IO, use the low-latency IO channel to send data; if it is a normal IO, select the normal IO channel to send data.

[0009] Step 3: During the I / O processing of the backend storage node, all low-latency I / Os are polled out from the low-latency channel for processing, and then some I / Os are taken out from the normal I / O channel for processing. After processing, all low-latency I / Os are polled out from the low-latency channel for processing again, thereby ensuring that the end-to-end latency of low-latency I / Os is controllable.

[0010] In one embodiment, the LAVA storage system comprises three layers: an application layer, an index layer, and a persistence layer.

[0011] In one embodiment, the application layer, index layer, and persistence layer are specifically as follows:

[0012] The application layer is deployed on compute nodes to provide cloud disk services.

[0013] The index layer, deployed on storage nodes, manages the Block Storage LBA indexes and routes data writes based on indexes and views.

[0014] The persistent layer, the management of the underlying disk, and the management of EC and replicas ensure the reliability of data storage;

[0015] By identifying block service layer services and establishing RDMA dual channels between the application layer and the index layer, as well as between the index layer and the persistence layer, end-to-end storage I / O dual channels are achieved, ensuring that low-latency and high-IOPS services do not interfere with each other.

[0016] In one embodiment, in step 2, when creating the RDMA channel, the transport layer RDMA isolated channel is as follows:

[0017] Step 2.1: Establish two completely independent RDMA EP channels between the application layer computing node and the index layer storage node, including the required message header resources and data transmission memory space, to ensure the independence of the transmission channels; after the two channels are established, EP0 needs to be sent first to improve the EP0 data transmission speed; the RDMA EP channel is used for data transmission between nodes.

[0018] Step 2.2: When data needs to be sent, the network protocol layer uses the EP0 channel to send low-latency (high-priority) IO data and the EP1 channel to send high-IOPS (low-priority) IO data, based on the priority flag in the header.

[0019] In one embodiment, a priority tag is added to the header of RDMA data IO transmission. The transport layer selects whether to use the low-latency channel or the high-IOPS channel based on this priority tag. Although the service can obtain different priority IOs by polling different channels, during processing, it also directly determines whether to use the low-latency channel or the high-IOPS channel based on the tag in the header.

[0020] In one embodiment, the application layer specifically comprises the following:

[0021] 1) Block service layer, implements IO channel selection and tags IO:

[0022] 2) Monitor the low-latency channel. If the low-latency channel IO volume reaches a certain level, strengthen the low-latency channel threshold to ensure the low-latency channel IO volume.

[0023] In one embodiment, in step 1), the block service layer implements IO channel selection and tags IO, specifically including the following steps:

[0024] 1.1 Low-concurrency cloud disks, and the cloud disk type is XSSD1 or higher;

[0025] 1.2 For top users' cloud disk I / O, if the I / O volume is not large, then use the low-concurrency channel;

[0026] 1.3 For low-latency cloud disks or cloud disks of customers with strict SLA guarantees, use the low-latency channel for I / O.

[0027] In one embodiment, the index layer specifically comprises the following:

[0028] 1) In each processing session, data is first obtained from the low-latency channel for processing, and then data is obtained from the high-IO channel for processing after the low-latency channel is completed.

[0029] 2) Data acquisition through high-IO channels should be limited;

[0030] 3) For IO obtained through a further low-latency channel, select a higher-performance resource pool for processing.

[0031] In one embodiment, the persistence layer specifically includes the following:

[0032] 1) In each processing session, data is first obtained from the low-latency channel for processing, and then data is obtained from the high-IO channel for processing after the low-latency channel is completed.

[0033] 2) Limit the amount of data retrieved from high I / O channels;

[0034] 3) Further I / O obtained from the low-latency channel is written to a higher-performance storage medium;

[0035] 4) Furthermore, when SSDs support priority scheduling in the future, IOs acquired through low-latency channels will be tagged with priority processing tags.

[0036] In one embodiment, the data transmission process is implemented using an isolated channel:

[0037] Step 1), the block layer receives I / O from the upper layer;

[0038] Step 2), construct the header for data I / O transmission;

[0039] Step 3) Determine which I / O operation to use for data transfer;

[0040] Step 4), set the priority tag in the header to high priority;

[0041] Step 5) Invoke the transport layer to perform data transmission. Based on the priority label, select EP0 as the data transmission channel to perform data transmission.

[0042] Step 6): The index layer receives IO data from the block layer by prioritizing the IO in the high-priority channels and checks the priority label in the header to process it accordingly.

[0043] Step 7): After processing, select the EP0 channel for data transmission according to the priority label;

[0044] Step 8) The persistence layer receives IO data from the index layer by prioritizing the IO in the high-priority channels, and at the same time checks the priority label in the header to process it accordingly.

[0045] Step 9): After processing is complete, select the EP0 channel to reply that the index layer processing is complete, based on the priority label.

[0046] Step 10): The index layer receives the IO information from the persistence layer by prioritizing the IO in the high-priority channels, performs optimization processing, and selects the EP0 channel to reply to the block layer application based on the priority tag.

[0047] Step 11) The block layer receives the IO information from the index layer by prioritizing the IO in the high-priority channels, and then completes the processing to reply to the upper-layer application.

[0048] Details of one or more embodiments of this application are set forth in the following drawings and description. Other features, objects, and advantages of this application will become apparent from the specification, drawings, and claims. Attached Figure Description

[0049] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0050] Figure 1 is a flowchart illustrating an end-to-end dual-channel storage I / O processing method according to an embodiment of this application;

[0051] Figure 2 shows the LAVA storage system architecture in one embodiment of this application;

[0052] Figure 3 is a schematic diagram of a transport layer RDMA channel in one embodiment of this application;

[0053] Figure 4 is a schematic diagram of the tag in the header being transmitted along with IO in one embodiment of this application;

[0054] Figure 5 is a business processing flowchart of one embodiment of this application;

[0055] Figure 6 is a flowchart illustrating the implementation of data transmission via an isolated channel in one embodiment of this application. Detailed Implementation

[0056] The technical solution of this application will be further described in detail below with reference to the accompanying drawings:

[0057] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application. The purpose and effects of this application will become clearer below with reference to the accompanying drawings and preferred 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.

[0058] In distributed storage systems, in order to ensure the performance of critical business operations, priority sorting or QoS traffic control is usually used to limit cluster traffic in order to ensure the performance of IO processing.

[0059] Priority sorting can guarantee the processing performance and latency of the I / O modules, but it lacks end-to-end latency guarantees. If other modules or subsystems do not perform priority processing, end-to-end performance cannot be guaranteed.

[0060] QoS (Quality of Service) traffic control ensures that the entire cluster performance is not overloaded, thus guaranteeing the overall service quality of the cluster. This method shifts the pressure from the cluster side to the client. When the client's host machine experiences high I / O pressure, it can lead to I / O queuing on that client's host machine (due to cluster QoS traffic control), increasing latency and impacting the experience of critical services or VIP customers.

[0061] To address the technical problems existing in the prior art, this application proposes an end-to-end dual-channel storage I / O method: based on the LAVA storage system, which is the next-generation storage engine within China Telecom Cloud.

[0062] As shown in Figure 1, the method includes the following steps: S1, at the client end, business identification is performed, and IO is tagged to indicate whether it is low-latency IO or normal IO. S2, when creating an RDMA channel, two completely isolated IO channels are created. When the IO is low-latency IO, the low-latency IO channel is used for data transmission; if it is normal IO, the normal IO channel is selected for transmission. S3, when processing IO at the backend storage node, all low-latency IOs are first polled from the low-latency channel for processing, and then a portion of IOs (e.g., 5) are taken from the normal IO channel for processing. After processing, all low-latency IOs are polled from the low-latency channel again for processing, thereby ensuring end-to-end controllable latency for low-latency IOs. This scheme can effectively ensure that multi-tenants meet performance and latency standards simultaneously during testing, and when expansion is not timely, it can prioritize the protection of VIP customers and critical business resources, thereby reducing the potential business losses due to untimely expansion.

[0063] This application is primarily based on the next-generation LAVA storage system, whose architecture is as follows:

[0064] As shown in Figure 2, the LAVA storage system is divided into three layers. The application layer, deployed on compute nodes, provides cloud disk services upwards. The index layer, deployed on storage nodes, primarily manages the block storage LBA index and routes data writes based on indexes and views. The persistence layer mainly manages the underlying disks and EC and replica management, ensuring data storage reliability. This application primarily achieves end-to-end storage I / O dual-channel by identifying block service layer services and establishing RDMA dual-channels between the application and index layers, and between the index and persistence layers, ensuring that low-latency and high-IOPS services do not interfere with each other.

[0065] 1. Design of RDMA isolation channel in the transport layer:

[0066] 1) As shown in Figure 3, this is a schematic diagram of the channel connection between two nodes via EP. Two completely independent RDMA EP channels are established between the application layer computing node and the index layer storage node (or the index layer storage node and the persistent layer storage node), including the required message header resources, data transmission memory space, etc., to ensure the independence of the transmission channels. After the two channels are established, EP0 needs to be sent first, thereby improving the data transmission speed of EP0 (most network cards and switches support this function; if they do not support it, it only means that the channel cannot send data first, which does not affect the implementation of the isolation channel).

[0067] 2) When data needs to be sent, the network protocol layer uses the EP0 channel to send low-latency (high-priority) IO data and the EP1 channel to send high-IOPS (low-priority) IO data, based on the priority flag in the header.

[0068] 2. Network Layer Service Design:

[0069] In the RDMA data (IO) transmission header (as shown in the diagram), a priority tag is added. The transport layer uses this priority tag to select between the low-latency channel and the high-IOPS channel. Although the service can obtain IOs of different priorities by polling different channels, during processing, the tag in the header is used directly to determine whether the subsequent path is the low-latency channel or the high-IOPS channel. For example, if the KV Server obtains a low-latency IO by polling a high-priority channel and sends it to the Chunk Server for processing, the priority tag in the header needs to be checked to determine whether to use the low-latency channel or the high-IOPS channel. Similarly, when the Chunk Server receives a low-latency IO from the KV Server and completes processing, it also needs to use the priority tag in the header to determine which channel to use for data transmission.

[0070] In this design, as shown in Figure 4, the tags in the header are transmitted along with the IO until the end-to-end IO processing is completed.

[0071] 3. Business Process Design:

[0072] As shown in Figure 5 below, the application process is as follows:

[0073] Block service layer (application layer):

[0074] 1) Block service layer, implements IO channel selection and tags IO:

[0075] 1.1 Low-concurrency cloud disks, and the cloud disk type is XSSD1 or higher; this is a product of China Telecom Cloud called XSSD1. Regarding the patent, it can be written in a more general way, rather than just specifically for XSSD1.

[0076] 1.2 For top users' cloud disk I / O, if the I / O volume is not large, then use the low-concurrency channel;

[0077] 1.3 For low-latency cloud disks or cloud disks of customers with strict SLA guarantees, use the low-latency channel for I / O.

[0078] 2) Monitor the low-latency channel. If the low-latency channel IO volume reaches a certain level, strengthen the low-latency channel threshold to ensure the low-latency channel IO volume.

[0079] Key-Value Service Layer (Index Layer):

[0080] 1) For each processing session, data is first retrieved from the low-latency channel for processing, and then retrieved from the high-IO channel for processing after the low-latency channel is completed.

[0081] 2) Data acquisition through high-IO channels should be limited to no more than 8 IOs and less than 1M of data at a time (this can be adjusted according to the business requirements to ensure that it does not affect the processing of low-latency tasks); 3) For IOs acquired through even lower-latency channels, select a higher-performance resource pool (such as an SCM resource pool) for processing.

[0082] Chunk service layer (persistence layer):

[0083] 1) For each processing session, data is first retrieved from the low-latency channel for processing, and then retrieved from the high-IO channel for processing after the low-latency channel is completed.

[0084] 2) Similar to KV Server, when retrieving data from high IO channels, limits should be imposed, with no more than 4 IOs processed at a time and less than 128K of data (this can be adjusted according to the business requirements to ensure that it does not affect the processing of low-latency tasks).

[0085] 3) Further I / O obtained from the low-latency channel is written to higher-performance storage media, such as PMEM;

[0086] 4) Furthermore, when SSDs support priority scheduling in the future, IOs acquired through low-latency channels will be tagged with priority processing tags.

[0087] 4. The process for sending data using an isolated channel is shown in Figure 6:

[0088] 1) The block layer receives I / O from the upper layer;

[0089] 2) Construct the header for data (IO) transmission;

[0090] 3) Determine which I / O operation to use for data transmission (the logic for this determination is explained in the business processing design section of the previous chapter);

[0091] 4) Set the priority label in the header to high priority (assuming it is determined to be high-priority I / O);

[0092] 5) Invoke the transport layer to perform data transmission. Based on the priority label, select EP0 as the data transmission channel to perform data transmission;

[0093] 6) The index layer receives IO data from the block layer by prioritizing the IO in the high-priority channels, and at the same time checks the priority label in the header to process it accordingly.

[0094] 7) After processing, select the EP0 channel for data transmission according to the priority label;

[0095] 8) The persistence layer receives IO data from the index layer by prioritizing the IO in the high-priority channels, and at the same time checks the priority label in the header to perform priority processing (such as disk persistence);

[0096] 9) After processing is complete, select the EP0 channel to reply that the index layer processing is complete, based on the priority label;

[0097] 10) The index layer receives the IO information from the persistence layer by prioritizing the IO in the high-priority channels, performs optimization processing, and selects the EP0 channel to reply to the block layer application based on the priority tag;

[0098] 11) The block layer receives the IO information from the index layer by prioritizing the IO in the high-priority channel, and then completes the processing and replies to the upper-layer application to indicate that the processing is complete.

[0099] This embodiment mainly focuses on RDMA connection implementation. Similarly, in TCP network or other modes, multiple channels can be established for receiving and sending storage IO priority tasks.

[0100] Furthermore, this embodiment is primarily designed for dual-channel operation. However, it can also be extended to a multi-priority channel design to accommodate more priority tasks, enabling finer-grained identification and priority transmission of services. But more priorities mean more physical connection channels, which consumes more resources. Therefore, this application focuses on describing the implementation of dual-channel operation.

[0101] Compared with existing QoS control and network I / O priority schemes, this scheme completely isolates communication resources by using service tags and independent I / O passage. At the same time, during service processing, low-latency (or high-priority) channel tasks are processed by prioritizing polling, thereby ensuring that low-latency I / O can be processed in a timely manner no matter how busy the service is, and avoiding the situation where low-latency I / O is blocked by other low-priority services.

[0102] The new dual-channel solution firstly completely isolates the resources requested by the two channels when establishing the RDMA channel, and the channel connection is not reused, avoiding mutual interference of services with different priorities due to IO channel blocking (in the previous solution, even if services were prioritized, they could still be blocked by low-priority IO in the channel because the channels were not isolated); secondly, by setting different polling strategies for the low-latency channel and the normal channel, the low-latency channel IO can be processed in a timely manner without starving the normal IO channel.

[0103] Because of the deferred channel, the IO communication volume is not large. Although it will occupy the resources of the ordinary IO channel, it is mostly less than 5% (less than 1.5% when verifying millions of IOPS and single concurrent latency at the same time). Therefore, it can support customers to verify latency and IOPS at the same time, and achieve the goal of verifying millions of IOPS and 100us at the same time.

[0104] The beneficial technical effects of this application are as follows:

[0105] This application can effectively solve the problem that when different tenants are verifying IOPS and latency at the same time, the single concurrent latency cannot meet the standard, and the SLA is not met.

[0106] This application can effectively guarantee the IO latency and timeliness of IO processing for critical business and VIP customers, thereby ensuring the quality of critical business and VIP customer experience even under high cluster pressure.

[0107] This end-to-end dual-channel storage I / O technology is a general-purpose technology that can be used for different storage services such as files, objects, and blocks. It enables the differentiation and limited processing of high and low priority tasks, ensuring storage I / O latency for critical storage services.

[0108] It will be understood by those skilled in the art that the above descriptions are merely preferred examples of the invention and are not intended to limit the invention. Although the invention has been described in detail with reference to the foregoing examples, those skilled in the art can still modify the technical solutions described in the foregoing examples or make equivalent substitutions for some of the technical features. All modifications and equivalent substitutions made within the spirit and principles of the invention should be included within the scope of protection of the invention. All technical features in this embodiment can be freely combined according to actual needs.

[0109] Finally, it should be noted that the above description is only a preferred embodiment of this application and is not intended to limit this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. An end-to-end dual-channel storage I / O processing method, implemented based on the LAVA storage system, the method comprising: Step 1: On the client side, identify the business logic and tag the I / O, indicating whether it is low-latency I / O or normal I / O. Step 2: When creating an RDMA channel, create two completely isolated IO channels. When the IO is low-latency IO, use the low-latency IO channel to send data; if it is normal IO, select the normal IO channel to send data. Step 3: During the I / O processing of the backend storage node, all low-latency I / Os are polled out from the low-latency channel for processing, and then some I / Os are taken out from the normal I / O channel for processing. After processing is complete, continue polling out all low-latency I / O from the low-latency channels for further processing. Polling is a method of continuously reading network packets in a round-robin fashion, indicating that data should be repeatedly pulled from the data channels and processed, and that after all data has been processed, other data channels should be pulled to check for any remaining data.

2. The method according to claim 1, wherein the LAVA storage system comprises three layers: an application layer, an index layer, and a persistence layer.

3. The method according to claim 2, wherein the application layer, index layer, and persistence layer are specifically as follows: The application layer is deployed on compute nodes to provide cloud disk services. The index layer, deployed on storage nodes, manages the Block Storage LBA indexes and routes data writes based on indexes and views. The persistent layer, the management of the underlying disk, and the management of EC and replicas ensure the reliability of data storage; By identifying block service layer services and establishing RDMA dual channels between the application layer and the index layer, as well as between the index layer and the persistence layer, end-to-end storage I / O dual channels are achieved, ensuring that low-latency and high-IOPS services do not interfere with each other.

4. The method according to claim 2, wherein in step 2, when creating the RDMA channel, the transport layer RDMA isolating the channel as follows: Step 2.1: Establish two completely independent RDMA EP channels between the application layer computing node and the index layer storage node, including the required message header resources and data transmission memory space, to ensure the independence of the transmission channels; after the two channels are established, EP0 needs to be sent first to improve the data transmission speed of EP0. Step 2.2: When data needs to be sent, the network protocol layer uses the EP0 channel to send low-latency (high-priority) IO data and the EP1 channel to send high-IOPS (low-priority) IO data, based on the priority flag in the header.

5. The method according to claim 4, wherein a priority tag is added to the header of the RDMA data IO transmission, and the transport layer selects whether to use the low-latency channel or the high-IOPS channel based on the priority tag; although the service can obtain different priority IOs by polling different channels, in processing, it also directly determines whether the subsequent channel is the low-latency channel or the high-IOPS channel by the tag in the header.

6. The method according to claim 3, wherein the application layer specifically comprises the following: 1) Block service layer, implements IO channel selection and tags IO: 2) Monitor the low-latency channel. If the low-latency channel IO volume reaches a certain level, strengthen the low-latency channel threshold to ensure the low-latency channel IO volume.

7. The method according to claim 6, wherein in step 1), the block service layer implements IO channel selection and tags IO, specifically including the following steps: 1.1, Low-concurrency cloud storage; 1.2 For top users' cloud disk I / O, if the I / O volume is not large, then use the low-concurrency channel; 1.3 For low-latency cloud disks or cloud disks of customers with strict SLA guarantees, use the low-latency channel for I / O.

8. The method according to claim 3, wherein the index layer specifically comprises the following: 1) In each processing session, data is first obtained from the low-latency channel for processing, and then data is obtained from the high-IO channel for processing after the low-latency channel is completed. 2) Data acquisition through high-IO channels should be limited; 3) For IO obtained through a further low-latency channel, select a higher-performance resource pool for processing.

9. The method according to claim 3, wherein the persistent layer specifically comprises the following: 1) In each processing session, data is first obtained from the low-latency channel for processing, and then data is obtained from the high-IO channel for processing after the low-latency channel is completed. 2) Limit the amount of data retrieved from high I / O channels; 3) Further I / O obtained from the low-latency channel is written to a higher-performance storage medium; 4) Furthermore, when SSDs support priority scheduling in the future, IOs acquired through low-latency channels will be tagged with priority processing tags.

10. The method of claim 1, wherein sending data using an isolated channel comprises: Step 1), the block layer receives I / O from the upper layer; Step 2), construct the header for data I / O transmission; Step 3) Determine which I / O operation to use for data transfer; Step 4), set the priority tag in the header to high priority; Step 5) Invoke the transport layer to perform data transmission. Based on the priority label, select EP0 as the data transmission channel to perform data transmission. Step 6): The index layer receives IO data from the block layer by prioritizing the IO in the high-priority channels and checks the priority label in the header to process it accordingly. Step 7): After processing, select the EP0 channel for data transmission according to the priority label; Step 8) The persistence layer receives IO data from the index layer by prioritizing the IO in the high-priority channels, and at the same time checks the priority label in the header to process it accordingly. Step 9): After processing is complete, select the EP0 channel to reply that the index layer processing is complete, based on the priority label. Step 10): The index layer receives the IO information from the persistence layer by prioritizing the IO in the high-priority channels, performs optimization processing, and selects the EP0 channel to reply to the block layer application based on the priority tag. Step 11) The block layer receives the IO information from the index layer by prioritizing the IO in the high-priority channel, and completes the processing to reply to the upper-layer application.

Images