Method for controlling quality of service of cloud disk and electronic device

Abstract

This application discloses a service quality control method and electronic device for cloud diskless systems, relating to the field of cloud technology. The method includes receiving a disk read / write request from a diskless client, adding it to a pending request task within the user request information, and adding its identifier to a client scheduling queue. When scheduling is triggered, the scheduling thread sequentially reads the client identifier from the scheduling queue and reads the pending request task corresponding to that identifier. If the thread bound to the corresponding client reaches its processing limit and the task is not empty or the request failed to be sent, the identifier is returned to the scheduling queue. If the processing limit is not reached, the request is read from its pending request task and sent to the thread for disk processing. This application can solve the problem that related technologies cannot provide stable service quality for different types of clients, enabling supported clients to fairly use cloud diskless service resources when cloud diskless server resources are insufficient.

Description

Technical Field

[0001] This application relates to the field of cloud technology, and in particular to a cloud diskless service quality control method and electronic device. Background Technology

[0002] Cloud diskless is a centralized storage service implementation that allows clients to access storage resources on remote servers over the network without configuring a local system disk, and where the server centrally handles all disk read and write requests.

[0003] Due to the varying performance of clients supported by cloud diskless services, the cloud diskless server technology cannot guarantee stable service quality for different types of clients when providing image and write-back services to diskless clients.

[0004] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] This application provides a service quality control method and electronic device for cloud diskless systems, which provides stable service quality for different types of clients and enables the supported clients to use cloud diskless service resources fairly when cloud diskless server resources are insufficient.

[0006] To solve the above-mentioned technical problems, this application provides the following technical solution: This application provides a method for quality of service control in cloud diskless systems, including: When a disk read / write request is received from a diskless client, the disk read / write request is added to the user request information, and the client identifier is sent to the client scheduling queue used for round-robin scheduling; the user request information stores the disk read / write request in the pending request task of the corresponding client, and updates the mapping relationship between the client and the pending request task; When a request scheduling signal is detected, the request scheduling thread reads the target client identifier from the client scheduling queue in the scheduling order, and determines the corresponding target request task to be processed through the mapping relationship. If the target disk processing thread bound to the target client reaches the preset data processing limit, and the target pending request task contains at least one disk read / write request, then the target client identifier will be returned to the last scheduling position of the client scheduling queue. If the target disk processing thread has not reached the preset data processing limit, the target disk read / write request is read from the target pending request task and sent to the target disk processing thread. If the target disk read / write request is not sent successfully, the target disk read / write request is put back into the target pending request task, and the target client identifier is put back into the last scheduling position of the client scheduling queue; if the target disk read / write request is sent successfully, it is sent to the corresponding target disk through the target disk processing thread.

[0007] Another aspect of this application provides an electronic device, including: The network interface is used to receive disk read / write requests from diskless clients and return the execution results of the request to the target disk to the client. Memory, used to store computer programs; The processor deployed on the cloud diskless server implements the steps of the above-described cloud diskless service quality control method when executing the computer program.

[0008] The advantage of the technical solution provided in this application is that when the cloud diskless server receives disk read / write requests concurrently initiated by at least one client, it stores these disk read / write requests in a client-based pending request task and adds the client identifier to the client scheduling queue for unified scheduling. The request scheduling thread retrieves the client identifier from the client scheduling queue one by one in the scheduling order for processing, so that disk read / write requests from different clients can be processed in a round-robin fashion, rather than being continuously occupied by a single client, thereby achieving a balanced distribution of cloud diskless service resources among multiple clients. When processing a request from a single client, if the target disk processing thread bound to that client has reached the preset data processing limit, the client identifier is returned to the last scheduling position in the client scheduling queue, waiting for subsequent rounds for processing. This prevents processing threads that have already received a large number of requests from receiving new requests and prevents the internal pending requests of that processing thread from accumulating continuously. If the processing thread has not reached its limit, the disk read / write request is retrieved from the client's pending request task and sent. For disk read / write requests that fail to be sent, the request is returned to the client's pending request task, and the client's identifier is added to the end of the client's scheduling queue. This allows unsuccessfully delivered requests to be retried in subsequent scheduling rounds, preventing them from being lost or blocked from other requests from the same client due to immediate delivery failure. Successfully sent disk read / write requests are sent to the corresponding disk for read / write operations via the target disk processing thread, achieving an orderly connection between request scheduling and request execution. Through this process, under high concurrency load, disk read / write requests from various clients can be scheduled in a round-robin fashion, and the request delivery volume to a single processing thread is limited. This reduces the problem of uneven server resource consumption caused by differences in request arrival rates among different clients, ensuring service stability for disk read / write processing for clients with different performance levels. In addition, this application also provides corresponding electronic devices for the cloud diskless service quality control method, further enhancing the practicality of the method. The electronic devices have corresponding advantages.

[0009] The technical features mentioned above, those to be mentioned below, and those shown individually in the accompanying drawings can be arbitrarily combined, as long as the combined technical features are not contradictory. All feasible combinations of features are the technical content explicitly described in this application. Any one of the multiple sub-features contained in the same statement can be applied independently, without necessarily being applied together with other sub-features.

[0010] It should be understood that the above general description and the following detailed description are merely exemplary and do not limit this application. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of this application or related technologies, the drawings used in the description of the embodiments or related technologies 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.

[0012] Figure 1 A flowchart illustrating a cloud-based diskless service quality control method provided in this application; Figure 2 A schematic diagram of the user request information provided in this application in an exemplary application scenario; Figure 3 A schematic diagram of the client scheduling queue provided in this application in an exemplary application scenario; Figure 4 A schematic diagram of the client-side deduplication set provided in this application in an exemplary application scenario; Figure 5 A flowchart illustrating another cloud-based diskless service quality control method provided in this application; Figure 6 A structural diagram of an exemplary embodiment of the electronic device provided in this application; Figure 7 This is a schematic diagram of the service quality control interaction process for cloud diskless systems in an exemplary application scenario provided in this application. Detailed Implementation

[0013] To enable those skilled in the art to better understand the technical solutions of this application, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. The terms "first," "second," "third," "fourth," etc., used in the specification and the aforementioned drawings are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. The term "exemplary" means "serving as an example, embodiment, or illustration." Any embodiment described herein as "exemplary" is not necessarily to be construed as superior to or better than other embodiments.

[0014] Diskless cloud storage is a storage service implementation based on network storage and centralized computing. Clients do not configure physical hard drives locally for mounting the operating system. Instead, during the network boot phase, firmware (such as a pre-boot execution environment) retrieves the operating system image from a remote server and reads and writes data stored on the remote server via high-speed network during runtime. The diskless cloud server can be provided, for example, by a server cluster deployed in a data center. These servers centrally store the operating system image, application data, and user write-back data, and uniformly schedule, process, and respond to disk read / write requests initiated by various clients.

[0015] The cloud-based diskless server provides the initial system disk content to the client through an image service and temporarily stores the data modified on the system disk during client operation through a write-back service. Disk read / write requests initiated by the client must be sent to the server via the network, and the server's processing thread completes the reading or writing of the corresponding storage area. In actual deployment environments, the network card transmission rates of different clients vary from 2.5Gbps to 20Gbps, and their processor and graphics processing capabilities also differ. This difference in hardware capabilities results in some clients generating and issuing a greater number of disk read / write requests per unit of time.

[0016] The relevant technology, upon receiving a request from the cloud diskless server, follows a first-come, first-served (FROM) processing approach. Clients with high request rates fill the server's processing queue first, while subsequent requests from other clients must wait in the queue. Because processing threads and storage bandwidth are heavily consumed by earlier requests, later-entered requests often experience longer waiting times, resulting in increased read / write completion times and slower operation responses. This difference is not necessarily due to variations in client workloads, but solely stems from the order in which requests arrive.

[0017] In view of this, in order to solve the problem that related technologies cannot guarantee that all clients can use server resources fairly, this application can schedule the processing opportunities of disk read and write requests from multiple clients. This allows each client to obtain disk read and write processing capabilities in a relatively balanced manner under conditions of high concurrency and limited processing resources, avoiding long-term skewness in processing resources due to differences in arrival time, and enabling clients to use cloud diskless service resources fairly. The various non-limiting embodiments of this application are described in detail below with reference to the accompanying drawings and specific implementation details.

[0018] Please see first. Figure 1 According to the cloud diskless service quality control method provided in this application, it can be implemented as a computer program product, installed and run in the cloud diskless server to control the service quality of the cloud diskless system. In some embodiments of the method, the method includes the following steps: S101: When a disk read / write request is received from a diskless client, the disk read / write request is added to the user request information, and the client identifier is sent to the client scheduling queue used for round-robin scheduling.

[0019] Diskless clients refer to computing terminals that do not have a physical hard drive locally for loading the operating system, but instead obtain the operating system image and runtime data from a remote server via a network. User request information stores disk read / write requests in the corresponding client's pending request task and updates the mapping relationship between the client and the pending request task. For example... Figure 2As shown, user request information is a collective term for a set of data organizations, which at least includes pending request tasks and the mapping relationship between clients and pending request tasks. Pending request tasks are used to store disk read / write requests belonging to the same client that have been received but not yet dispatched to the disk processing thread. The mapping relationship is used to find the pending request task corresponding to a client based on the client identifier; for example, it can be implemented using a key-value mapping table, where the key is the client identifier and the value is a reference or pointer to the corresponding pending request task. The client scheduling queue is a data structure used for round-robin scheduling, such as... Figure 3 As shown, the client identifiers to be scheduled are stored sequentially. This client identifier is information that uniquely distinguishes different diskless clients; for example, it can be an identifier obtained by processing the client's network card physical address, client IP address, or a unique number assigned by the server.

[0020] In this step, after the server device's network interface receives a disk read / write request from the diskless client, it obtains the client identifier and specific read / write parameters carried in the request, such as the starting position of the data to be read / written on the target disk, the data length, the memory address used to store the results, and optional latency statistics placeholder information. The processor stores this disk read / write request as a pending entry in the pending request task corresponding to the client identifier. Simultaneously, it updates the mapping relationship between the client identifier and the pending request task; for example, if the client identifier does not previously exist in the mapping relationship, a new pending request task is created first, and then the mapping relationship is established. Furthermore, the client identifier is sent to the client scheduling queue used for round-robin scheduling, typically appended to the end of the queue to indicate that the client has a request waiting to be scheduled.

[0021] S102: When a request scheduling signal is detected, the request scheduling thread reads the target client identifier from the client scheduling queue in the scheduling order, and determines the corresponding target request task to be processed through the mapping relationship.

[0022] The request scheduling signal is a notification or status flag used to trigger the request scheduling thread to perform a scheduling action. The request scheduling thread is a continuously running execution flow in the server, used to execute the round-robin scheduling logic. The target client identifier is the identification information of the client being processed in the current round of scheduling; for ease of description, it can be defined as the target client. The pending request tasks that write all disk read / write requests to the target client are the target pending request tasks.

[0023] In this step, when a request scheduling signal is detected, the request scheduling thread is started or woken up. The request scheduling thread reads a client identifier from the head of the client scheduling queue in scheduling order and uses this identifier as the target client identifier for this round of scheduling. The request scheduling thread determines the target pending request task corresponding to this target client identifier through the above mapping relationship. Next, the request scheduling thread determines whether the target disk processing thread bound to the target client has reached the preset data processing limit. This determination is achieved by reading the pending request count currently maintained by the target disk processing thread; when the count value is equal to or greater than the preset data processing limit, it is determined that the limit has been reached.

[0024] S103: If the target disk processing thread bound to the target client reaches the preset data processing limit, and the target pending request task contains at least one disk read / write request, then the target client identifier is returned to the last scheduling position in the client scheduling queue. If the target disk processing thread has not reached the preset data processing limit, the target disk read / write request is read from the target pending request task and sent to the target disk processing thread.

[0025] The target disk processing thread refers to a disk processing thread pre-bound to the target client, specifically designed to execute tasks for the target client. The preset data processing limit is a configurable value used to limit the number of requests waiting to be processed simultaneously within the target disk processing thread. The target disk processing thread is the execution flow that actually performs disk read / write operations on the target client. Each diskless client can be pre-configured to bind to one or more target disk processing threads.

[0026] In this step, if the target disk processing thread has reached its preset data processing limit, and the target pending request task still contains at least one disk read / write request, the request scheduling thread will not retrieve the request from the target pending request task. Instead, it will place the target client identifier back into the last scheduling position in the client scheduling queue, such as the tail. The advantage of this is that when a disk processing thread has already handled a sufficient number of pending requests, continuing to submit requests to it will cause requests to accumulate within that thread, increasing processing latency. Placing the client back to the tail allows for scheduling opportunities to be given to other clients, waiting for the processing thread to release its processing capacity before scheduling. If the target disk processing thread has not reached its preset data processing limit, it means that the processing thread still has the ability to receive new requests. The request scheduling thread reads a target disk read / write request from the target pending request task and sends it to the target disk processing thread's pending receiving area. During the sending process, due to possible brief queue fullness or insufficient memory during inter-thread communication, the sending operation may succeed or fail.

[0027] S104: If the target disk read / write request is not successfully sent, the target disk read / write request is returned to the target pending request task, and the target client identifier is returned to the last scheduling position in the client scheduling queue; if the target disk read / write request is successfully sent, it is sent to the corresponding target disk through the target disk processing thread.

[0028] The target disk refers to the physical storage device or virtual storage volume targeted by the target disk read / write request. If the target disk read / write request is successfully sent, the target disk processing thread receives the request and, according to the starting position and data length carried in the request, initiates a read or write instruction to the corresponding target disk. After the target disk completes the operation, it can return the operation result to the target disk processing thread via callback or event notification, and then return it to the diskless client that made the request via the network interface. If the target disk read / write request fails to be sent, for example, because the internal receive area of ​​the target disk processing thread is momentarily filled by other deliveries, the request scheduling thread will not discard this request. Instead, it will put the target disk read / write request back into the target pending request task, usually at the beginning of the task, to maintain the priority retry order of the request. At the same time, the request scheduling thread will put the target client identifier back into the last scheduling position in the client scheduling queue, so that the client that failed to be delivered in this round can have a chance to be scheduled again in subsequent rounds.

[0029] In the technical solution provided in this application embodiment, when the cloud diskless server receives disk read / write requests concurrently initiated by at least one client, these disk read / write requests are stored in a pending request task on a client-by-client basis, and the client identifier is added to the client scheduling queue for unified scheduling. The request scheduling thread retrieves the client identifier from the client scheduling queue one by one in the scheduling order for processing, so that the disk read / write requests of different clients can be processed in a round-robin fashion, rather than being continuously occupied by a single client, thereby achieving a balanced distribution of cloud diskless service resources among multiple clients. When processing a request from a single client, if the target disk processing thread bound to the client has reached the preset data processing limit, the client identifier is returned to the last scheduling position in the client scheduling queue, waiting for subsequent rounds for processing, so that the processing thread that has already received a large number of requests avoids receiving new requests and prevents the internal pending requests of the processing thread from accumulating continuously; if the processing thread has not reached the limit, the disk read / write request is retrieved from the pending request task of the client and sent. For disk read / write requests that fail to be sent, the request is returned to the client's pending request task, and the client's identifier is added to the end of the client's scheduling queue. This allows unsuccessfully delivered requests to be retried in subsequent scheduling rounds, preventing them from being lost or blocked from other requests from the same client due to immediate delivery failure. Successfully sent disk read / write requests are then sent to the corresponding disk for read / write operations via the target disk processing thread, achieving an orderly connection between request scheduling and request execution. Through this process, under high concurrency load, disk read / write requests from various clients can be scheduled in a round-robin fashion, and the request delivery volume to a single processing thread is limited. This reduces the problem of uneven server resource consumption caused by differences in request arrival rates among different clients, ensuring service stability for disk read / write processing for clients with different performance levels.

[0030] Based on the above embodiments, in order to further ensure the scheduling fairness of each client, this application further adds a step of deduplicating client identifiers through hash operation, which may include the following: The client identifier is hashed to obtain the client hash value. If the client hash value does not exist in the client deduplication set, the client identifier is sent to the client scheduling queue used for round-robin scheduling, and the client identifier and its corresponding client hash value are stored in the client deduplication set. After the target client identifier is read from the client scheduling queue in the scheduling order by the request scheduling thread, the target client identifier and its corresponding client hash value are deleted from the client deduplication set. After the target client identifier is put back into the last scheduling position of the client scheduling queue, the target client identifier and its corresponding client hash value are added to the client deduplication set again.

[0031] The client deduplication set is a collection used to record client identifiers that already exist in the client scheduling queue, such as... Figure 4 As shown, elements are located internally using hash values ​​to ensure the uniqueness of elements in the set and prevent the same client identifier from being added repeatedly to the client scheduling queue. The client hash value is the numerical value obtained by hashing the client identifier, and it serves as the basis for storing and comparing the client identifier in the client deduplication set. The hash operation can use any hash algorithm that maps variable-length inputs to fixed-length values.

[0032] like Figure 5 As shown, in this embodiment, before sending a client identifier to the client scheduling queue, a hash operation is performed on the client identifier to obtain a client hash value. It is then checked whether the client hash value already exists in the client deduplication set. If the client hash value does not exist in the client deduplication set, it means that the client identifier is not currently in the client scheduling queue. The client identifier is then appended to the tail of the client scheduling queue, and the client identifier and its corresponding client hash value are stored as a pair in the client deduplication set. If the client hash value already exists in the client deduplication set, it means that the client identifier is already in the client scheduling queue waiting for scheduling, and the client identifier is not added to the queue again. After a target client identifier is read from the client scheduling queue in scheduling order by the request scheduling thread, the client identifier has left the queue, and its corresponding deduplication protection is also released. At this time, the record of the target client identifier and its corresponding client hash value is deleted from the client deduplication set. During subsequent scheduling, if the requesting scheduling thread needs to put the target client identifier back to the last scheduling position in the client scheduling queue due to reasons such as the disk processing thread reaching its limit or the request sending failing, after the putback operation is completed, the hash operation will be performed on the target client identifier again, and the target client identifier and its corresponding client hash value will be added back to the client deduplication set to reflect the status that the client identifier has re-entered the queue.

[0033] As shown above, this embodiment, through deduplication, ensures that the same client identifier has at most one valid position in the client scheduling queue. This avoids the situation where a client's identifier is repeatedly queued in the scheduling queue due to a single client continuously initiating multiple disk read / write requests. Duplicate queuing would cause the client to receive more processing opportunities than its fair share in scheduling rounds, disrupting the balance of round-robin scheduling. The deduplicated set is checked when a client is enqueued, cleared when it is dequeued, and re-registered when it is re-enqueued, ensuring the uniqueness of identifiers within the client scheduling queue and maintaining scheduling fairness among clients.

[0034] Based on the above embodiments, this embodiment further refines the implementation process of reading the target client identifier from the client scheduling queue, which may include the following: Whenever a disk read / write request is sent to the corresponding client task queue, a new task enqueue signal is triggered as a request scheduling signal. If the request scheduling thread is in a blocked waiting state, a new task enqueue signal is sent to the request scheduling thread, and the request scheduling thread changes from the blocked waiting state to the normal execution state. The request scheduling thread reads the target client identifier from the client scheduling queue in the scheduling order.

[0035] The pending request tasks are specifically implemented as a client task queue, which uses a first-in, first-out (FIFO) data structure. Each received disk read / write request is appended to the tail of the queue in the order of arrival. The target disk processing thread has its own pending queue, which receives requests from the request scheduling thread and waits for the thread to actually execute them. The new task enqueue signal is a notification signal used to wake up the request scheduling thread, triggered by the event of adding a request to the client task queue. The blocked waiting state refers to the state where the request scheduling thread relinquishes processor resources, pauses execution, and waits to be woken up by a signal when there are no schedulable tasks or all threads are fully loaded. The normal execution state refers to the state where the request scheduling thread, after being woken up, resumes execution from the blocked point and begins the next round of scheduling.

[0036] In this embodiment, whenever a disk read / write request is sent to the corresponding client task queue (i.e., a new request is enqueued), a new task enqueue signal is generated. If the request scheduling thread is currently in a blocked waiting state, for example, because all schedulable clients have finished processing or all target disk processing threads are at full capacity, the new task enqueue signal is passed to the request scheduling thread. Upon receiving this signal, the request scheduling thread transitions from the blocked waiting state to the normal execution state, and then reads the client identifier from the client scheduling queue according to the scheduling order, entering the subsequent request dispatch process.

[0037] As can be seen from the above, this embodiment avoids the problem of the request scheduling thread continuously idling and polling and occupying processor resources when there are no tasks by using the blocking and wake-up operation mode. At the same time, it ensures that scheduling can be started immediately once a new request is enqueued, thus taking into account both the processor utilization efficiency and the timeliness of scheduling response.

[0038] Based on the above embodiments, this embodiment further defines an exemplary method for generating a request scheduling signal, which may include the following: When the queue to be processed is detected to change from a full threshold state to a non-full threshold state, a scheduling notification signal is generated as a request scheduling signal. The scheduling notification signal is sent to the request scheduling thread that is in a blocked waiting state. The request scheduling thread changes from the blocked waiting state to the normal execution state, continues to extract disk read and write requests from the client task queue, and forwards them to the corresponding disk processing thread.

[0039] The "full threshold" state refers to the state where the number of requests in the target disk processing thread's queue has reached or exceeded the preset data processing limit. The "non-full threshold" state refers to the state where the number of requests has fallen from the full threshold state to below the preset data processing limit. The scheduling notification signal is a signal triggered by a change in the capacity status of the queue, used to convey information to the request scheduling thread that processing capacity has been released.

[0040] In this embodiment, after each target disk processing thread completes processing a request, the number of requests in its pending queue decreases by one, potentially changing from a full threshold state to a non-full threshold state. When a pending queue is detected to have switched from a full threshold state to a non-full threshold state, a scheduling notification signal is generated. If the request scheduling thread is in a blocked waiting state, the scheduling notification signal is sent to it, and upon receiving it, the request scheduling thread transitions from a blocked waiting state to a normal execution state. After resuming execution, the request scheduling thread continues to extract disk read / write requests from each client task queue and attempts to send them to the corresponding target disk processing thread.

[0041] As can be seen from the above, this embodiment actively wakes up the scheduling thread when the disk processing thread releases processing capacity, enabling the scheduling system to promptly detect changes in downstream processing capacity. Client identifiers that were previously placed back into the client scheduling queue due to thread overload also have the opportunity to be rescheduled promptly once the corresponding processing thread has free capacity, reducing unnecessary waiting delays and improving the overall request flow efficiency.

[0042] Based on the above embodiments, this embodiment further defines the data organization method within a disk read / write request, which may include the following: Read the client identifier, the starting position of the data to be processed on the target disk, the length of the data to be processed, the result storage location, and the delay information from the disk read / write request; based on the client identifier, the starting position of the data to be processed on the target disk, the length of the data to be processed, the result storage location, and the delay information, encapsulate the disk read / write request into a request packet according to the preset encapsulation structure.

[0043] Here, the starting position of the data to be processed on the target disk refers to the starting sector number or byte offset of the disk read / write operation; the length of the data to be processed refers to the number of bytes to be read or written in this operation; the result storage location refers to the memory address used to store the read data or the status information after the write operation is completed; and the latency information refers to the placeholder variable used to measure the processing time of the request. The preset encapsulation structure is a pre-configured or set data field arrangement format, which facilitates the parsing and transmission of requests in a unified format by each processing stage.

[0044] In this embodiment, upon receiving a disk read / write request, the client identifier, starting position, data length, result storage location, and latency information are parsed from the request. These five fields correspond to the source, spatial location parameters, data volume parameters, target storage pointer, and performance metric parameters required for a single disk read / write operation, respectively. The request is then reassembled into a request packet according to a preset encapsulation structure, which sequentially includes the disk number, offset, length, result storage pointer, and latency statistics. Specifically, the disk number identifies the target disk in a multi-disk environment, the offset corresponds to the starting position, the length corresponds to the data length, the result storage pointer corresponds to the result storage location, and the latency statistics correspond to the latency information.

[0045] As can be seen from the above, this embodiment encapsulates the request into a unified structure, so that the subsequent scheduling thread and processing thread do not need to parse the data packets in the original network protocol stack one by one. They can directly read the required fields at the agreed offset position, which reduces the overhead of format conversion and also reduces the probability of data transmission errors between different processing stages.

[0046] Furthermore, based on the above embodiments, this embodiment, through the control of the service quality control function, ensures that the supported clients can fairly use cloud diskless service resources when server resources are insufficient, and that the clients can achieve optimal performance when resources are sufficient. This may include the following: If the service quality control function is enabled, the client identifier and request packet of the disk read request will be added to the user request information; if the service quality control function is disabled, the request packet will be sent to the task processing thread.

[0047] In this embodiment, the Quality of Service (QoS) control function is used to determine whether to enable the client scheduling queue and round-robin scheduling. When the QoS control function is enabled, the request enters the processing path with scheduling control; when the QoS control function is disabled, the request bypasses scheduling control and is directly sent to the processing thread for execution. The task processing thread refers to the worker thread that actually performs disk read / write operations, and can be in the same thread group as the aforementioned target disk processing thread or a separate thread group.

[0048] In this embodiment, before adding the client identifier and request packet of the disk read / write request to the user request information, the current enabling status of the service quality control function is first determined. If the service quality control function is enabled, the request packet along with the client identifier is sent to the client task queue and the client scheduling queue, and the complete scheduling process is followed. If the service quality control function is disabled, the client enqueueing and round-robin scheduling operations are not performed. Instead, the request packet is directly sent to the task processing thread, which immediately executes the disk read / write operation.

[0049] As shown above, in this embodiment, when the cloud diskless service is under low overall load and has sufficient processing resources, the service quality control function can be disabled to eliminate the steps of queuing, round-robin processing, and capacity judgment. This allows requests to reach the processing thread via the shortest path, reducing the scheduling latency of individual requests and achieving a response speed close to the theoretical minimum. When the load increases and resource contention occurs, the service quality control function is then activated to ensure fairness. The two modes can be switched according to the actual operating status, ensuring that the service exhibits matching response characteristics under different loads.

[0050] Based on the above embodiments, this embodiment further defines the specific maintenance operations for user request information, client scheduling queue, and client task queue under different conditions, which may include the following: If the target disk processing thread bound to the target client reaches the preset data processing limit, and the target client task queue corresponding to the target pending request task is empty, then the target client task queue is deleted from the user request information. If the target disk processing thread bound to the target client reaches the preset data processing limit, and the target client task queue is not empty, then the target client identification information is added to the tail of the client scheduling queue. If the target disk processing thread bound to the target client does not reach the preset data processing limit, and the target client task queue is not empty, then if the target disk read / write request is not successfully sent, the target disk read / write request is placed back at the head of the target client task queue, and the target client identification information is added to the tail of the client scheduling queue.

[0051] In this embodiment, during each scheduling process, different processing actions are taken based on whether the target disk processing thread bound to the target client has reached the preset data processing limit and whether the target client task queue is empty. If the target disk processing thread has reached the preset data processing limit and the target client task queue corresponding to the target pending request task is empty, it means that the client currently has no pending disk read / write requests. At this time, the target client task queue and its corresponding mapping relationship are deleted from the user request information, releasing the occupied storage resources. If the target disk processing thread has reached the preset data processing limit, but the target client task queue is not empty, it means that the client still has requests waiting to be processed, but due to the downstream threads being full, requests cannot be retrieved and sent in this round. The target client identifier is added to the tail of the client scheduling queue, retaining its position in the round-robin sequence, waiting for subsequent scheduling signals to trigger for processing again. If the target disk processing thread has not reached the preset data processing limit and the target client task queue is not empty, a target disk read / write request is retrieved from the queue and attempted to be sent. If the transmission fails, the target disk read / write request is placed back at the head of the target client task queue to maintain its priority for retrying. At the same time, the target client identifier is added to the tail of the client scheduling queue, so that the client must wait for the next scheduling round before trying to send the same request again.

[0052] As can be seen from the above, this embodiment ensures the accurate consistency between the mapping relationship and the queue content by performing operations such as cleaning up empty queues, reordering non-empty queues, and requesting to return to the head of the queue when sending fails. This avoids the invalid scheduling overhead caused by the client continuously occupying the scheduling position without making a request, and also ensures the relevance of each scheduling operation and the space efficiency of the scheduling data structure.

[0053] Furthermore, this embodiment also provides an implementation method for dynamically adjusting scheduling parameters and automatically disabling service quality control functions based on waiting time statistics, which may include the following: Remove the target disk read / write request from the pending request task and record it as the dequeue time; obtain the enqueue time when the target disk read / write request is added to the pending request task; determine the waiting time for the target disk read / write request based on the enqueue time and dequeue time, synchronously update the historical waiting time data of the target client, and re-determine the cumulative waiting time and maximum waiting time based on the historical waiting time data; if the cumulative waiting time or maximum waiting time of the target client exceeds the preset waiting time threshold, reduce the number of disk read / write requests read from the pending request task in a single instance, and reduce the preset data processing limit of the target disk processing thread. Calculate the average waiting time based on the historical waiting time data; if the average waiting time is lower than the first preset low load threshold or the maximum waiting time is lower than the second preset low load threshold, the cloud diskless service is currently in a resource-sufficient state, and the service quality control function is automatically disabled.

[0054] The enqueue time refers to the moment a disk read / write request is added to the pending request task, and the dequeue time refers to the moment the request is removed from the pending request task. Historical wait time data is a collection of records of the wait times for successfully sent requests by the client, which may include the individual wait time value for each request. Cumulative wait time is the sum of the wait times for all successfully sent requests by the client, and the maximum wait time is the maximum value of any single wait time. The preset wait time threshold is a preset reference time value used to determine if there are excessively long wait times. The number of disk read / write requests per read refers to the maximum number of requests that the scheduling thread can retrieve and send from a single client's task queue in each round. The average wait time is the arithmetic mean of the historical wait time data. The first and second preset low load thresholds are two preset reference time values ​​used to determine if the server is in a resource-sufficient state.

[0055] In this embodiment, after a target disk read / write request is successfully sent, the request is removed from the pending request task, and the deletion time is recorded as the dequeue time. The enqueue time recorded when the request was added to the pending request task is read, and the enqueue time is subtracted from the dequeue time to obtain the waiting processing time for this request. This waiting processing time is synchronously updated to the historical waiting time data corresponding to the target client, and the cumulative waiting time and maximum waiting time are recalculated based on the updated data. Periodically or whenever the cumulative waiting time or maximum waiting time is updated, it is compared with a preset time threshold. If the cumulative waiting time or maximum waiting time exceeds the preset time threshold, at least one of two adjustment actions is performed: reducing the number of disk read / write requests read from the pending request task in a single session, thus reducing the number of requests processed by the client in each scheduling round and slowing down its resource consumption rate; and reducing the preset data processing upper limit of the target disk processing thread, causing the processing thread to trigger full-load rollback logic earlier, suppressing the delivery speed from the entry point. These two adjustments can be performed individually or simultaneously to achieve dual rate limiting control for the client and its corresponding processing thread. When the load is high, the processing scale is proactively reduced to maintain stable overall service response. Simultaneously, the average waiting time is calculated based on the target client's historical waiting time data. When the average waiting time is lower than the first preset low-load threshold, or the maximum waiting time is lower than the second preset low-load threshold, the cloud diskless service is determined to be in a resource-sufficient state. At this time, the service quality control function is automatically disabled, allowing subsequent new disk read / write requests to be directly sent to the task processing thread, bypassing the client scheduling queue and round-robin processing flow. After automatic disabling, historical waiting time data can still be monitored. If the waiting time indicator subsequently rises again above the aforementioned threshold, the service quality control function will be automatically restarted.

[0056] As shown above, this embodiment dynamically adjusts the single-transmission volume and the upper limit of processing thread capacity by comparing the request waiting time with a preset threshold, thus achieving the adaptive response of the scheduling system to load changes. When the waiting time increases, the scheduling parameters actively shrink to reduce backlog; when the waiting time remains low, it indicates that processing resources are sufficient, and the scheduling system automatically bypasses to reduce latency. This allows the cloud diskless service to achieve near-direct-transmission low-latency performance when resources are sufficient, and maintains the stability of read and write responses from each client through rate limiting when resources are scarce.

[0057] It should be noted that there is no strict order of execution for the steps in this application. As long as they conform to a logical order, these steps can be executed simultaneously or in a certain preset order. Figure 1 This is just an illustrative example and does not mean that this is the only possible execution order.

[0058] This application also provides a corresponding apparatus for the cloud diskless service quality control method, further enhancing the practicality of the method. The apparatus can be described from both a functional module perspective and a hardware perspective. The following describes the cloud diskless service quality control apparatus provided in this application. This apparatus is used to implement the cloud diskless service quality control method provided in this application. In this embodiment, the cloud diskless service quality control apparatus may include or be divided into one or more program modules. These one or more program modules are stored in a storage medium and executed by one or more processors, thus completing the cloud diskless service quality control method disclosed in Embodiment 1. The program module referred to in this embodiment refers to a series of computer program instruction segments capable of performing specific functions, which are more suitable than the program itself for describing the execution process of the cloud diskless service quality control apparatus in the storage medium. The following description will specifically introduce the functions of each program module in this embodiment. The cloud diskless service quality control apparatus described below can be referred to in correspondence with the cloud diskless service quality control method described above.

[0059] From the perspective of functional modules, the cloud diskless service quality control device provided in this embodiment may include: The request enqueue module is used to add disk read / write requests from diskless clients to the user request information and send the client identifier to the client scheduling queue used for round-robin scheduling when a disk read / write request is received. The user request information stores the disk read / write request in the corresponding client's pending request task and updates the mapping relationship between the client and the pending request task.

[0060] The task determination module is used to determine the corresponding target request task to be processed by reading the target client identifier from the client scheduling queue in the scheduling order through the request scheduling thread when a request scheduling signal is detected, and by using the mapping relationship.

[0061] The task execution module is used to: If the target disk processing thread bound to the target client reaches its preset data processing limit, and the target pending request task contains at least one disk read / write request, then return the target client identifier to the last scheduling position in the client scheduling queue. If the target disk processing thread has not reached its preset data processing limit, read the target disk read / write request from the target pending request task and send it to the target disk processing thread. If the target disk read / write request fails to send, return the target disk read / write request to the target pending request task, and simultaneously return the target client identifier to the last scheduling position in the client scheduling queue; if the target disk read / write request is successfully sent, send it to the corresponding target disk through the target disk processing thread.

[0062] The cloud diskless service quality control device mentioned above is described from the perspective of functional modules. Furthermore, this application also provides an electronic device, which is described from the perspective of hardware. Figure 6 This is a schematic diagram of the electronic device provided in one embodiment of the present application. The electronic device includes a network interface 61, a memory 62, and a processor 63. The network interface is used to receive disk read / write requests from diskless clients and return the execution result of the target disk request to the client, such as read data blocks or confirmation information of write completion. The transmission rate of the network interface 61 can be selected according to the deployment environment; for example, it can use Ethernet interfaces of different specifications such as 2.5Gbps, 10Gbps, or 20Gbps to accommodate different sizes of client groups. The memory 62 stores computer programs and runtime data required during operation, such as data structures like client task queues, client scheduling queues, client deduplication sets, and mapping tables. The memory can be a medium with sufficient read / write speed, such as Dynamic Random Access Memory (DRAM) or solid-state storage. The processor 63 is deployed on the cloud diskless server and is configured to run computer programs to execute the steps in any of the above-described cloud diskless service quality control method embodiments.

[0063] The cloud diskless service is deployed on a server cluster to uniformly handle disk read / write requests from various diskless clients, including reading operating system files, application data, and writing temporarily modified data. This server cluster typically contains one or more server-side devices that receive requests via a network interface. Each server-side device may be equipped with a processor and memory, and may be further connected to a disk array or distributed storage system. The processor is used to execute scheduling and control programs, and the memory is used to maintain various data structures and queues required during the scheduling process.

[0064] To make the technical solution of this application clearer to those skilled in the art, this embodiment also incorporates... Figure 7 An exemplary method for implementing service quality control in a cloud-based diskless system is provided, which may include the following: The cloud diskless server has added user request information as a client queue mapping to its existing request processing module. This information records the mapping relationship between client identifiers and their corresponding request queues. A client scheduling queue, also known as a round-robin queue of client identifiers, stores client identifiers of requests awaiting scheduling in a first-in, first-out (FIFO) order. A pending request queue, corresponding to each client identifier, stores disk read / write requests received by that client but not yet dispatched to the disk processing thread. A service quality control switch controls whether the scheduling process is enabled. Additionally, a request scheduling thread has been added to the IO management module to uniformly schedule the processing order of client requests. Figure 7 As shown, the objects involved in the complete interactive process from the arrival of a disk read / write request to its completion and return can include: a dispatcher, configured to receive requests and perform preprocessing; an IO management module, configured for request scheduling and dispatch control; a disk processing thread io_thread[k], which is the thread that the client pre-binds and actually performs disk read / write operations, where k is the thread index or number, and different clients can be fixedly bound to different disk processing threads; and a disk processing module, configured to initiate read or write commands to physical or virtual disks.

[0065] When a request arrives at the server, the dispatcher receives the request packet from the cloud diskless client, parses out the client identifier and read / write parameters, and encapsulates the request into a fixed structure. This fixed structure includes: a request disk identifier to indicate the target disk; an offset to indicate the starting position of the read / write operation on the disk; a length to indicate the amount of data in the read / write operation; a result storage pointer to the memory address where the read / write result is stored; and a latency statistics variable to record the time information from when the request enters the scheduler to when it leaves the scheduler. After encapsulation, the dispatcher delivers the request to the IO management module.

[0066] In the IO management module, the first step is to determine whether the service quality control switch is enabled. If the switch is disabled, the encapsulated request is directly delivered to the task processing thread, which then sends the request to the disk processing module for read / write operations. The execution result is returned to the client via a callback function. If the switch is enabled, the client identifier and the encapsulated request are added to the client queue mapping, meaning the request is stored in the client request queue corresponding to that client identifier. Subsequently, the IO management module determines whether the request scheduling thread is currently working: if it is, the request delivery is complete, and the dispatcher continues to receive and process the next request; if it is not working, the IO management module wakes up the request scheduling thread, causing it to transition from a blocked waiting state to a normal execution state.

[0067] After the request scheduling thread is awakened, it enters the scheduling loop. First, it enters the waiting for a schedulable signal state: the request scheduling thread blocks here and waits until one of two conditions is met before continuing execution. The first condition is receiving a new task enqueue signal, that is, a new disk read / write request has been added to a client request queue; the second condition is receiving a schedulable notification, that is, the pending queue of a disk processing thread io_thread[k] changes from a full threshold state to a non-full threshold state.

[0068] Upon receiving the schedulable signal, the request scheduling thread performs a polling operation to obtain clients: it takes a client identifier from the head of the client scheduling queue as the current scheduled client, and only processes the time slice of this client in this round of scheduling, that is, at most a preset number of requests are taken from the request queue of this client in a single round for processing.

[0069] Next, the request scheduling thread retrieves tasks one by one from the request queue of the currently scheduled client. For each task retrieved, it attempts to send the task to the disk processing thread io_thread[k] pre-bound to that client. This binding relationship is established when the client first connects or initializes, and each client identifier corresponds to a specific disk processing thread.

[0070] When sending a request, it checks if the queue of the disk processing thread `io_thread[k]` is full. If the queue is not full, the delivery is successful, and the task leaves the client request queue and enters the disk processing thread's queue to await execution. If the task count in the disk processing thread's queue drops from the full threshold to a non-full threshold, the IO management module generates a schedulable notification, waking up the request scheduling thread to continue processing subsequent client requests. If the queue is full, the task is immediately placed back at the head of the client request queue, and the current round stops sending tasks from that queue to avoid delivering invalid requests to a fully loaded processing thread and wasting scheduling resources.

[0071] After completing the time slice processing for the current scheduled client, the request scheduling thread maintains the round-robin state: if there are still remaining tasks in the client request queue, the client identifier is put back to the tail of the client scheduling queue to wait for subsequent scheduling rounds; if the client request queue is empty, the client identifier is removed from the client scheduling queue, and the request queue record corresponding to the client is deleted from the client queue mapping.

[0072] The request scheduling thread updates the statistics for each successfully sent task. The statistics include: the number of successfully distributed requests, i.e., the cumulative number of requests successfully delivered to the disk processing thread; and the waiting time from when a request enters the client request queue to when it leaves the client request queue, including the cumulative waiting time and the maximum waiting time.

[0073] After this round of scheduling ends, the request scheduling thread checks the current state: if there are still clients in the client scheduling queue that can continue to be processed, and at least one disk processing thread's queue is not full, then the next round of round-robin scheduling continues; if all requests from currently schedulable clients are limited by capacity due to the corresponding disk processing thread's queue being full, then the request scheduling thread enters the waiting state again, waiting for subsequent schedulable notifications to arrive before continuing to work.

[0074] The disk processing thread io_thread[k] retrieves a request from its queue and sends it to the disk processing module. The disk processing module converts the request into a read or write instruction for the target disk. After the disk operation is completed, the disk processing module returns the execution result to the corresponding cloud diskless client via the IO management module through a callback function.

[0075] As shown above, the cloud diskless server adds round-robin scheduling based on client identifiers and capacity limiting for each disk processing thread (io_thread[k]) in its IO management module. Disk read / write requests from clients with different performance levels no longer directly preempt processing resources based on arrival time. Instead, after entering the IO management module via the dispatcher, they enter the round-robin queue according to client identifiers and receive processing opportunities sequentially. Each client sends a maximum of a preset number of requests in a single round, after which the queue moves to the next client, ensuring fair access to server processing resources for all clients. Simultaneously, when the disk processing thread's queue reaches its limit, requests are stopped being submitted to it. The request scheduling thread is then awakened to continue working once the queue level drops. This avoids a situation where a single client submits a large number of tasks to the same processing thread in a short period, causing task backlog and forcing subsequent requests from other clients to be queued at the end of the queue. Under high pressure scenarios, this ensures that different types of clients can obtain relatively stable disk read / write responses.

[0076] It is understood that if the cloud-based diskless service quality control method in the above embodiments is implemented as a software functional unit and sold or used as an independent product, it can be stored in a non-volatile storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the related technology, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes, but is not limited to, various media capable of storing program code, such as USB flash drives, mobile hard drives, read-only memory (ROM), random access memory (RAM), electrically erasable programmable ROM, registers, hard disks, multimedia cards, card-type memories (such as SD or DX memories), magnetic memories, removable disks, CD-ROMs, magnetic disks, or optical disks. Based on this, this application also provides a non-volatile storage medium storing a computer program, which, when executed by a processor, performs the steps of the cloud-based diskless service quality control method as described in any of the above embodiments.

[0077] It is understood that if the cloud-based diskless service quality control method in the above embodiments is implemented as a software functional unit and sold or used as an independent product, the computer software product may not need to be stored in a physical storage medium. For example, it can be directly transmitted to a computer or other device with information processing capabilities via a wired or wireless network to execute all or part of the steps of the methods in the various embodiments of this application. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the related technology, or all or part of the technical solution, can be embodied in the form of a software product. Based on this, this application also provides a computer program product storing a computer program, which, when executed by a processor, performs the steps of the cloud-based diskless service quality control method as described in any of the above embodiments.

[0078] The foregoing provides a detailed description of a cloud-based diskless service quality control method and electronic device. The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. Whether the units and algorithm steps of the various examples described in the disclosed embodiments are executed by electronic hardware or computer software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, and such implementations should not be considered beyond the scope of this application. Several improvements and modifications can be made to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A cloud-diskless quality of service control method, characterized by, include: When a disk read / write request is received from a diskless client, the disk read / write request is added to the user request information, and the client identifier is sent to the client scheduling queue used for round-robin scheduling. The user request information stores disk read / write requests to the pending request task of the corresponding client and updates the mapping relationship between the client and the pending request task. When a request scheduling signal is detected, the request scheduling thread reads the target client identifier from the client scheduling queue in the scheduling order, and determines the corresponding target request task to be processed through the mapping relationship. If the target disk processing thread bound to the target client reaches the preset data processing limit, and the target pending request task contains at least one disk read / write request, then the target client identifier will be returned to the last scheduling position of the client scheduling queue. If the target disk processing thread has not reached the preset data processing limit, the target disk read / write request is read from the target pending request task and sent to the target disk processing thread. If the target disk read / write request is not sent successfully, the target disk read / write request is put back into the target pending request task, and the target client identifier is put back into the last scheduling position of the client scheduling queue; if the target disk read / write request is sent successfully, it is sent to the corresponding target disk through the target disk processing thread.

2. The cloud-disk service quality control method of claim 1, wherein, Also includes: Perform a hash operation on the client identifier to obtain the client hash value; If the client hash value does not exist in the client deduplication set, the client identifier is sent to the client scheduling queue used for round-robin scheduling, and the client identifier and its corresponding client hash value are stored in the client deduplication set. After the target client identifier is read from the client scheduling queue in the scheduling order by the request scheduling thread, the target client identifier and its corresponding client hash value are deleted from the client deduplication set. After the target client identifier is put back into the last scheduling position of the client scheduling queue, the target client identifier and its corresponding client hash value are added to the client deduplication set again.

3. The cloud-disk service quality control method of claim 1, wherein, The pending request tasks are client task queues, and the target disk processing thread is configured with a corresponding pending queue. When a request scheduling signal is detected, the request scheduling thread reads the target client identifier from the client scheduling queue according to the scheduling order, including: Whenever a disk read / write request is sent to the corresponding client task queue, a new task enqueue signal is triggered as a request scheduling signal. If the request scheduling thread is in a blocked waiting state, a new task enqueue signal is sent to the request scheduling thread, and the request scheduling thread changes from the blocked waiting state to the normal execution state. The request scheduling thread reads the target client identifier from the client scheduling queue in the scheduling order.

4. The cloud-disk service quality control method of claim 1, wherein, The target disk processing thread is configured with a queue of pending data. If the target disk processing thread bound to the target client reaches the preset data processing limit, the following steps are also included: When the queue to be processed is detected to change from a full threshold state to a non-full threshold state, a scheduling notification signal is generated as a request scheduling signal. The scheduling notification signal is sent to the request scheduling thread that is in a blocked waiting state. The request scheduling thread then transitions from the blocked waiting state to the normal execution state, continues to extract disk read / write requests from the client task queue, and forwards them to the corresponding disk processing thread.

5. The cloud-disk service quality control method of claim 1, wherein, After receiving a disk read / write request from a diskless client, the following is also included: Read the client identifier, the starting position of the data to be processed on the target disk, the length of the data to be processed, the result storage location, and the delay information from the disk read / write request; Based on the client identifier, the starting position of the data to be processed on the target disk, the length of the data to be processed, the result storage location, and the delay information, the disk read / write request is encapsulated into a request packet according to a preset encapsulation structure. The preset encapsulation structure includes a disk number, offset, length, result storage pointer, and delay statistics variable.

6. The cloud-disk service quality control method of claim 5, wherein, Add the disk read / write request to the user request information and send the client identifier to the client scheduling queue used for round-robin scheduling, including: If the service quality control function is activated, the client identifier and request packet of the disk read request will be added to the user request information; If the service quality control function is disabled, the request packet will be sent to the task processing thread.

7. The cloud-disk service quality control method of claim 1, wherein, The pending request task is a client task queue, and the target disk processing thread is configured with a corresponding pending queue, further including: If the target disk processing thread bound to the target client reaches the preset data processing limit, and the target client task queue corresponding to the target pending request task is empty, then the target client task queue is deleted from the user request information. If the target disk processing thread bound to the target client reaches the preset data processing limit and the target client task queue is not empty, then the target client identification information is added to the tail of the client scheduling queue. If the target disk processing thread bound to the target client has not reached the preset data processing limit and the target client task queue is not empty, then if the target disk read / write request is not successfully sent, the target disk read / write request will be placed back at the head of the target client task queue, and the target client identification information will be added to the tail of the client scheduling queue.

8. The cloud-disk service quality control method according to any one of claims 1 to 7, characterized in that, After the target disk read / write request is successfully sent, the following steps are also included: Remove the target disk read / write request from the pending request task and record it as the dequeue time; Obtain the enqueue time when the target disk read / write request is added to the pending request task; Based on the enqueue time and the dequeue time, determine the waiting time for the target disk read / write request, synchronously update the historical waiting time data of the target client, and redetermine the cumulative waiting time and the maximum waiting time based on the historical waiting time data; If the cumulative time or maximum waiting time of the target client exceeds the preset time threshold, the number of disk read / write requests read from the pending request task in a single instance will be reduced, and the preset data processing limit of the target disk processing thread will be reduced.

9. The cloud-disk service quality control method of claim 8, wherein, Also includes: Calculate the average waiting time based on the historical waiting time data; If the average waiting time is lower than the first preset low load threshold or the maximum waiting time is lower than the second preset low load threshold, then the cloud diskless service is currently in a resource-sufficient state and the service quality control function is automatically turned off.

10. An electronic device, comprising: include: The network interface is used to receive disk read / write requests from diskless clients and return the execution results of the request to the target disk to the client. Memory, used to store computer programs; A processor deployed on a cloud diskless server is used to implement the steps of the cloud diskless service quality control method as described in any one of claims 1 to 9 when executing the computer program.

Images