Using Recover Borrowed Resource Allocation

Abstract

Systems and methods for allocating resources are disclosed. Resources such as streams are allocated using recovery borrows. Borrows are distributed to clients in a manner that ensures the system operates in a safe allocation state. Borrows can be used not only to allocate resources, but also to throttle clients when necessary. Borrows can be granted in full, in part, and in an amount greater than requested. Zero or negative borrows can also be distributed to throttle clients. Recovery borrows are associated with reads and can be allocated by determining how many borrows a CPU / core can support. This maximum number can be divided among clients connected to a server.

Description

Technical Field

[0001] Embodiments of the present invention relate to systems and methods for allocating resources. More specifically, embodiments of the present invention relate to systems and methods for allocating flows or resources when performing data protection operations, such as recovery operations. Appendix A constitutes a part of this application and is incorporated by reference into this application in its entirety. Background Art

[0002] Allocating resources can be a challenging task in a single node or distributed / out-of-scale cluster environment. The task becomes more complex when trying to ensure that resources are fairly allocated to all clients using the available resources. For example, no single client should be able to have an unfairly large share of the available resources. At the same time, Quality of Service (QOS) requirements need to be met.

[0003] More specifically, data protection operations (e.g., backup, recovery) are often associated with resource allocation issues and quality of service (QOS) issues. These problems arise when some clients are using too many resources and other clients are therefore being neglected or unable to obtain necessary resources. In addition, QOS is often impaired when the demand for resources exceeds what a node or cluster can sustain. In order to avoid this situation or correct this situation, it is necessary to throttle requests from any particular client at any particular time. Therefore, there is a need for systems and methods for fairly allocating resources while ensuring or meeting quality of service requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] In order to describe the manner in which at least some aspects of the present application can be obtained, a more specific description will be given with reference to the specific embodiments of the present application shown in the accompanying drawings. It should be understood that these drawings only illustrate exemplary embodiments of the present invention and are therefore not to be considered as limiting the scope of the present invention. The embodiments of the present invention will be described and explained with additional particularity and detail through the use of the accompanying drawings, in which:

[0005] Figure 1 An example of a server configured to allocate resources to a client is shown;

[0006] Figure 2 Further illustrated is resource allocation including flow allocation in the case of cluster resources or server resources;

[0007] Figure 3A An example of a method for performing resource allocation in a computing environment, and in particular for allocating flows, is shown;

[0008] Figure 3B An example of a method for evaluating the flow allocation status of a node or server or cluster is shown; and

[0009] Figure 3C It further shows Figure 3B A method for evaluating the state of a flow allocation;

[0010] Figure 4 An example of a system for allocating recovery borrows to requesting clients is shown; and

[0011] Figure 5 is a flow chart illustrating an example of a method for performing resource allocation during a data protection operation, such as a restore operation. DETAILED DESCRIPTION

[0012] Embodiments of the present invention relate to systems and methods for performing data protection operations. Examples of data protection operations include, but are not limited to, resource allocation operations, including stream allocation, read allocation, segment processing allocation, etc. Data protection operations may also include backup operations, recovery operations, deduplication operations, mirror operations, data replication operations, etc., or a combination thereof.

[0013] Embodiments of the present invention relate to systems and methods for allocating resources in a computing environment. Embodiments of the present invention also relate to systems and methods for measuring and improving quality of service and for throttling clients in the context of resource allocation. Embodiments of the present invention also relate to systems and methods for allocating streams to clients, allocating recovery credits, for example, when performing recovery operations.

[0014] In one example, a cluster of servers (or a single server or node) may have resources that can be allocated to a client. These resources include streams, reads, writes, processes, deduplication, etc. A particular server may, for example, provide x streams, or a certain number of reads / writes. In general, a cluster may also provide a large number of streams, reads / writes, and processes. Embodiments of the invention relate to systems and methods for allocating these resources.

[0015] Figure 1 An example of a computing environment is shown in which a client communicates with a server (or cluster). In this example, the resources allocated to the client include streams. The client may be able to establish multiple streams with multiple servers. Similarly, a server may establish multiple streams with multiple clients.

[0016] These resources (and / or other resources including read resources, write resources, processing resources, etc.) are allocated so that the servers of the cluster operate in a safe allocation state. The safe allocation state is a state in which all resource requests can be permitted and all resource requests can be served until completed. This is implemented using a borrowing system. In order to explain a variety of scenarios, there are different types of borrowing that can be permitted. However, each type can be related to the resource being allocated. Different types of borrowing effectively represent different responses to borrowing requests. The borrowing system can be used to allocate different types of resources and / or allocate multiple resources at the same time.

[0017] For example, the number of borrows granted by a server or cluster can be equal to the number of borrows requested, less than the number of borrows requested, greater than the number of borrows requested, zero, or negative. Distributing zero or negative borrows allows a server to fully use resources but throttle when necessary. This also allows a server or cluster to recover from an unsafe state and return to a safe allocation state. For example, a borrow can be described as follows:

[0018] Prefetch borrows: Amount greater than the borrows requested by the client.

[0019] Partial borrow: less than the amount requested by the client (but greater than 0).

[0020] Equal borrows: equal to the amount of borrows requested by the client.

[0021] Zero borrow: equal to zero, indicating that the current client request cannot be processed. The client needs to wait and try again to obtain a borrow.

[0022] Negative borrows: A negative number indicating the number of borrows that the client is releasing from the cache.

[0023] Zero borrow and negative borrow allow the server to throttle requests from clients.

[0024] Figure 1 A server (e.g., a data protection or backup server) 110 is shown providing resources to clients (represented by clients 102, 104, 106, and 108). Server 100 may also represent a cluster of nodes or a cluster of servers. In one example, clients 102, 104, 106, and 108 are sending / receiving data streams (e.g., backup data or streams, recovery streams, streams including data for processing (such as deduplication), etc.) to / from server 110. For example, client 102 may be using stream 112 to back up multiple virtual machines, databases, file systems, or other data types. Similarly, client 104 is associated with stream 114, client 106 is associated with stream 116, and client 108 is associated with stream 118.

[0025] In this example, server 110 is configured to allocate streams to client 102, client 104, client 106, and client 108. In one example, server 102 is configured to use stream borrowing to perform stream allocation. These stream borrowings can be managed using resource allocation table 120, which allows the allocation state (e.g., secure, unsecure) to be determined. Each time a borrow is issued (regardless of type), allocation table 120 is updated so that subsequent requests can be evaluated.

[0026] In one example, a request for a stream borrow is evaluated to determine whether granting the request would result in a safe allocation state. Typically, if the resulting allocation state is safe, the request is granted. If the request results in an unsafe allocation state, the request is denied, such as by issuing a zero borrow or by issuing a negative borrow.

[0027] In the following description and by way of example only, it is assumed that 1 available stream is associated with 1 permitted stream borrowing. In other words and by way of example only, 1 borrowing represents 1 stream. Other borrowings according to the resource allocation scheme may be different. For example, the server may grant x streams to each borrowing. If all streams associated with all clients can be completed for execution, the server 110 may grant a stream borrowing to the requesting client.

[0028] Because server 110 may not know when a particular client's stream will terminate, nor how many additional stream borrows may be requested by clients with different times until that particular client's stream completes, server 110 may assume that all clients will eventually attempt to acquire their maximum allowed stream borrows, use those stream borrows, and then release those stream borrows.

[0029] Based on these assumptions, the server can determine whether the stream allocation state is safe by finding a hypothetical set of stream borrowing requests of the client, which will allow each client to obtain the stream borrowing of its maximum request and use these stream borrowings. If it is a state where there is no such set of stream borrowing requests, this can cause the server 110 to grant zero stream borrowing or negative stream borrowing. This can cause the client that receives these permissions or requests to return any stream borrowing that is being held. In other words, the ability to grant or distribute zero borrowing or negative borrowing allows the client to be throttled. In one example, the client can throttle itself because they may not have enough borrowing or because they may need to return the borrowing to the server 110. In this way, the server then tries to return to the safe stream allocation state, thereby granting the requested borrowing.

[0030] Embodiments of the present invention may allocate resources when the allocation state of the system resulting from a particular allocation is safe. If the proposed allocation results in an unsafe state, an allocation may be made to return the system to a safe allocation state (e.g., by issuing a negative borrow or a zero borrow). The following discussion of stream borrowing includes the following. Figure 3B and Figure 3C This allocation method is described in more detail.

[0031] In one example, let C be the number of clients in the system and N be the number of nodes or servers in the system.

[0032] Total (Maximum Flow) Availability Matrix (TAM): A matrix of length N indicating the maximum number of flow resources available for each node.

[0033] TAM[j]=k, there are k instances of available stream resource Rj.

[0034] Current Allocation Matrix (CALM): A C×N matrix defining the number of streaming resources currently allocated to each client.

[0035] CALM[i,j]=k, so client Ci is currently allocated k instances of stream resource Rj.

[0036] Current Availability Matrix (CAM): A matrix of length N indicating the number of flows currently available for each node type. It is determined by summing the flows currently assigned to all clients on each individual node and subtracting the sum from the total maximum flow for that node.

[0037] CAM[j]=TAM[j]–(CALM[C0]+CALM[C1]+…+CALM[CN]);

[0038] Current Demand Matrix (CDM): A C×N matrix that defines the current demand or maximum requested flows at a point in time.

[0039] If CDM[i,j]=k, then client Ci can request at most k instances of stream resource Rj.

[0040] Current Need Matrix (CNM): A C x N matrix indicating the stream borrowing needs of each client (need = demand - allocated).

[0041] CNM[i,j]=CDM[i,j]-CALM[i,j].

[0042] At any point in time, the server determines whether it is safe to allocate a stream borrow in response to a borrow requested by a client. If at a given point in time, the system is in a safe state, then all client borrow requests can be satisfied, i.e., for all clients, their stream resources need to be less than the current stream availability for all nodes in the system.

[0043] CNM[i,j] <CAM[j]

[0044] If the client's flow needs are greater than the available flow (CNM[i,j]>CAM[j]), the system is considered unsafe (unsafe allocation state) and a negative borrow or zero borrow is granted to the client, and efforts are made to bring the system to a safe / stable allocation state.

[0045] The following example explains the process in more detail. Figure 2 A cluster is shown including nodes or servers 202 and clients 204. More specifically, Figure 2 Four nodes or servers are shown: N1, N2, N3, and N4. Figure 2 Also shown are clients Cl, C2, and C3 (client 204) using resources of server 202. In this example, the resources of server 202 allocated to clients 204 include stream 206. Stream 206 may include a backup stream, a restore stream, or other data stream.

[0046] As an example, suppose that Figure 2 In , the TAM or total maximum flow available at each node is expressed as follows:

[0047] N1 N2 N3 N4 60 50 70 60

[0048] Thus, N1 has 60 streams for allocation to clients. Similarly, N2, N3, and N4 have 50, 70, and 60 streams for allocation to clients, respectively.

[0049] The total maximum flow can be determined by taking into account the number of processors and cores on the server and by determining how much processing power the flow consumes. The total maximum flow can be determined in other ways, such as by testing or by user input.

[0050] The CALM matrix below indicates the stream borrowings that have been allocated to clients C1-C3. In this example, assume that clients C1, C2, and C3 have the following stream borrowings already allocated to them.

[0051] N1 N2 N3 N4 C1 10 20 20 10 C2 10 00 30 30 C3 10 20 10 00

[0052] CALM

[0053] The CAM or currently available flows (or flows that have not yet been allocated) can be calculated based on the above TAM and CALM. For example: According to the above TAM matrix, node N1 has a maximum of 60 flows that it can allocate. Node N1 has been allocated 10 flows each to C1, C2, and C3. Therefore, the total flows currently available on N1 are:

[0054] CAM[N1]=TAM[N1]–(CALM[0,C1]+CALM[0,C2]+CALM[0,C3]), that is

[0055] CAM[N1]=60–(10+10+10)=30.

[0056] Similarly,

[0057] CAM[N2]=50–(20+0+20)=10.

[0058] CAM[N3]=70–(20+30+10)=10.

[0059] CAM[N4]=60–(10+30+0)=20.

[0060]

[0061] More generally, the CAM indicates which nodes or servers are providing the streams assigned to the client 204. As previously described, the client 204 can connect to any server 202 and can therefore request to borrow from any server 202 in the cluster.

[0062] The following CDM defines the maximum client stream borrowing request at a given point in time. In other words, the following matrix defines how many streams each client can request from each server at a given point in time. These numbers or maximum values ​​can be predetermined or set by an administrator. In addition, these numbers can be dynamic and can be based on the number of clients and / or the number of servers. When the number of servers and clients changes, the number of stream borrowing requests at that point in time may change.

[0063] N1 N2 N3 N4 C1 30 30 20 20 C2 10 20 30 40 C3 10 30 50 00

[0064] CDM

[0065] By subtracting the current allocated flow matrix (CALM) from the current demand matrix (CDM), the total flow borrowing or CNM required for C1, C2, and C3 can be determined as follows:

[0066]

[0067] Using the above information, it can be determined whether each client can obtain and use its maximum requested stream borrow. The following format is used in the following discussion,<xx xx xx xx> Represents the flows associated with nodes N1, N2, N3, and N4, respectively.

[0068] For example, according to the CNM, C1 requests and obtains 20 stream borrows from N1, 10 stream borrows from N2, and 10 stream borrows from N4 to reach its maximum requested borrows. The server can perform this determination before actually granting the request.

[0069] After C1 requests and obtains it, the available streams are now determined as follows:

[0070] <30 10 10 20> (CAM or available stream) –

[0071] <20 10 00 10> (the flow obtained by C1 to reach the maximum value of C1) =

[0072] <10 00 10 10> (stream still available)

[0073] Therefore, the cluster still has 10 available flows for N1, 00 available flows for N2, 10 available flows for N3, and 10 available flows for N4.

[0074] Next, C1 terminates the processes associated with the flows and returns 30 flow borrows of N1, 30 flow borrows of N2, 20 flow borrows of N3, and 20 flow borrows of N4 to the system. These are the flows associated with the C1 row in the CDM. Add them to the currently available flows:

[0075] <10 00 10 10>+<30 30 20 20>=<40 30 30 30>

[0076] Therefore, the cluster now has 40 total available flows for N1, 30 total available flows for N2, 30 total available flows for N3, and 30 total available flows for N4. This <40 30 30 30> is less than or equal to the TAM <60 50 70 60> or the total maximum flows for each node of the cluster, i.e. <40 30 30 30><=<60 50 70 60>, so the system state is safe to allocate and process the next client request.

[0077] Now C2 requires 20 flows from N1 and 10 flows from N4. Then C2 terminates and returns all its flow borrows. In this example and after these steps, the available flows are or equal to:

[0078] <40 30 30 30> (Currently available streams before C2’s request) –

[0079] <00 20 00 10> (Flow required by C2 to reach the maximum value of C2) =

[0080] <40 30 30 30>-<00 20 00 10>=<40 10 30 20>(stream still available)+

[0081] <10 20 30 40> (the flow associated with row C2 in the CDM)

[0082] <10 20 30 40>+<40 10 30 20>=<50 30 60 60> (available stream after C2 returns the stream borrowing).

[0083] The <50 30 60 60> is less than or equal to the TAM <60 50 70 60> or the total maximum flow for each node of the cluster, i.e.

[0084] <50 30 60 60><=<60 50 70 60>, so the system state is safe to allocate and process the next client request.

[0085] Next, C3 asks for 10 flows from N2 and 40 flows from N3, terminating and returning all flows (returning the flow borrow). This results in the following:

[0086] <50 30 60 60> (currently available streams before C3’s request) –

[0087] <00 10 40 00> (Flow required by C3 to reach the maximum value of C3) +

[0088] <10 30 50 00> (stream returned by C3) =

[0089] <60 50 70 60>(Can be borrowed by stream).

[0090] The <60 50 70 60> is less than or equal to the TAM <60 50 70 60> or the total maximum flow for each node of the cluster, i.e.

[0091] <60 50 70 60><=<60 50 70 60>, so the system state is safe to allocate and process the next client request.

[0092] This shows that because each client can obtain the maximum stream borrowing it requests and use the stream borrowing, the stream allocation state is safe and can grant stream borrowing to all clients as described above.

[0093] The stream allocation security state indicates that stream borrowing may be granted or distributed. Embodiments of the invention contemplate a variety of different borrowings that may be requested and granted.

[0094] The following examples illustrate these types of borrowing and whether borrowing is permitted.

[0095] Example 1: Server license "equal" borrowing.

[0096] Starting in the same state as the previous example, assume that C3 requests 10 streams to borrow on node N3. In this example, there are enough available streams so that the borrow request can be granted. After the grant, the new stream allocation state is as follows:

[0097] CAM or available streams on a node:

[0098] N1 N2 N3 N4 Available streams 30 10 00 20

[0099] The stream CALM currently allocated to client 204 is now as follows (assuming here that 10 borrowing requests of N3 of C3 are granted):

[0100] N1 N2 N3 N4 C1 10 20 20 10 C2 10 00 30 30 C3 10 20 20 00

[0101] CALM

[0102] Now, the maximum requested streams for the client are as follows:

[0103] N1 N2 N3 N4 C1 30 30 20 20 C2 10 20 30 40 C3 10 30 50 00

[0104] CDM

[0105] Using this information, it can be determined whether the new stream allocation state is safe.

[0106]

[0107] In the above example, C1 can obtain 20 flows of N1, 10 flows of N2, and 10 flows of N4, use these flows and release these flows. Then, C2 can obtain 20 flows of N2 and 10 flows of N4, use these flows and release these flows. Finally, C3 can obtain 10 flows of N2 and 30 flows of N3, use these flows and release these flows. Therefore, this new allocation state is safe.

[0108] Because the new state is safe, the request from C3 for 10 stream borrows on node N3 is granted. This is an example where the number of stream borrows granted by the server is equal to the number of stream borrows requested by the client.

[0109] Example 2: Server License "Partial" Borrowing

[0110] Starting in the same state as the previous example, assume that C3 requests 20 stream borrows on N3. In this example, the available streams before the requested stream borrows are granted are as follows:

[0111]

[0112]

[0113] The available streams after the license stream is borrowed are as follows:

[0114] N1 N2 N3 N4 30 10 <![CDATA[ -10 ]]> 20

[0115] Since the total number of available streams after the grant is less than zero, the server may decide to grant 10 stream borrows (this is a partial grant since 20 stream borrows were requested). As previously described with respect to the previous example, granting 10 stream borrows from N3 to C3 results in a secure allocation state. This shows an example of partially granting stream borrows.

[0116] Example 3: "Zero" or "Negative" Stream Borrow Assignment

[0117] From the previous start state, suppose client C2 requests 10 streams to borrow from node N2. In this example, there are enough streams to allow the streams to borrow. Assuming the request is granted, the new state will be:

[0118] CAM or available streams on a node:

[0119] N1 N2 N3 N4 Available streams 30 00 10 20

[0120] Depending on the initial state of CALM or the currently assigned stream:

[0121] N1 N2 N3 N4 C1 10 20 20 10 C2 10 10 30 30 C3 10 20 10 00

[0122] CALM

[0123] The CDM or maximum requested flow at that point in time is determined as follows:

[0124] N1 N2 N3 N4 C1 30 30 20 20 C2 10 20 30 40 C3 10 30 50 00

[0125] CDM

[0126] A determination is now made to determine whether the new allocation state is safe. Assume that clients C1, C2, and C3 request more stream borrowing from N2 and N3.

[0127]

[0128] In this case, C1 cannot obtain enough flows from N2, that is, from the above CNM, and C1 requires 10 flows from N2. However, according to the above CAM, the number of available flows of N2 is 0. In addition, C2 cannot require enough flows from N2, and C3 cannot obtain enough flows from N2.

[0129] In this example, no client can obtain enough stream borrows to reach its maximum allowed stream borrows. Therefore, the state is unsafe and the server 202 can throttle one or more of the clients 204 and recover from the unsafe allocation state by distributing negative borrows. In other words, the server 202 recovers from the unsafe state by throttling and distributing negative borrows.

[0130] For example, server N2 may grant minus 20 stream borrows to C1. Alternatively, N2 grants zero borrows to clients C2 and C3 (i.e., clients C2 and C3 throttle and retry their requests after a period of time). Client C1 returns the 20 stream borrows it holds to N2, and performs a secure allocation state check to determine if the state is secure.

[0131] Stream borrowing is used to perform resource allocation. The stream allocation method can be applied to many types of streams. The stream allocation method can maintain a stable stream allocation state by granting negative borrowing / zero borrowing to various clients. In addition, embodiments of the present invention allow different types of borrowing permissions as described above.

[0132] More specifically, stream borrowing can be pre-fetched. If the client does not hold a stream borrowing (or even if the client holds some stream borrowings) and if there are enough idle streams on the server, the server can grant the client more borrowings when the client requests.

[0133] Prefetch borrowing may be requested, for example, based on the expected workload. This may be applied, for example, during a restore operation, where stream borrowing is expected to be used to restore the stream by reading a backup.

[0134] Borrowing of permissions can also be used to make decisions related to setting the size of client-sized caches. This is related to, for example, using stream borrowing for recovery operations to read ahead, perform smart read ahead, or use borrowing to manage the cost of the solution.

[0135] Partially granted borrows can allow partial completion of operations. In addition, streaming borrows can be retrieved from clients by issuing negative borrows and flushing the negative number of borrows from the client's cache. In other words, if the number of granted borrows is zero or negative, the client can be throttled. More different borrow allocation methods can be implemented based on the type of borrow requested.

[0136] Figure 3AAn example of a method for performing resource allocation is shown. In one example, various parameters associated with resource allocation may be defined 302 or determined. For example, a determination may be made regarding how many streams each node or server can safely support. This may be based on the number of processors / cores, memory, write / read parameters, etc. For example, the relationship between writes, processor or core consumption may be determined. If a predetermined number of writes or data transfer rate consumes 1% of the CPU, a stream at that transfer rate may correspond to 1 borrow. Additionally, a maximum number of streams allowed per client may also be determined.

[0137] This aspect of method 300 can be performed once. However, when nodes are added / removed in the system or when clients are added / removed in the system, this aspect of method 300 can be re-evaluated. These values ​​can also be considered for other functions performed by server 202 that may not involve streams or specific resources being allocated. In addition, these values ​​can also be able to change based on other factors, such as time of day. For example, when the processor is not required by other tasks, such as in a slower period, it can temporarily increase the number of available streams.

[0138] Once resource allocation has been defined and the server is allocating resources to clients, method 300 implements or executes the allocation method. For example, a request for a stream borrow may be received 304. As previously discussed, the request is evaluated to determine whether the requested allocation will result in a secure allocation state. Thus, the server may evaluate 306 the stream state or allocation state by assuming that the request is granted. This involves considering whether other clients may also be allocated their maximum borrows. As previously described, in one embodiment, it is assumed that the client may eventually request, use, and release its maximum allowed borrow. Thus, the evaluation determines what the allocation state will be if the request is granted.

[0139] The server then distributes borrows 308 to the requesting client (and / or other clients) based on the result (determined allocation state). If the allocation state is safe, the server may distribute borrows equal to or greater than the request. If the allocation state is unsafe, a partial grant may occur, which still results in a safe allocation state. If the allocation state is unsafe, the server may distribute zero or negative borrows. In one example, zero and / or negative borrows may be distributed to any client.

[0140] Figure 3B An example of more details of evaluating the flow state is shown. More specifically, Figure 3B Shows Figure 3AThus, method 320 illustrates an example of evaluating server flow state 306. In an example of method 320, the server may calculate TAM 322, which determines the total available flows. The server may then look up CALM 324. CALM identifies the flows currently assigned to the client.

[0141] Next, the time point CAM is determined 326. This is determined by subtracting CALM from TAM (CAM=TAM-CALM). This allows the server to determine how many streams are available for allocation. This can be determined from the perspective of the entire system and / or on a per-node or per-server basis. As discussed above, the number of available streams can be determined on a per-server basis. In one example, this ensures that the resources of a particular server are not overburdened. In addition, in one embodiment, this can give the server or cluster the flexibility to determine which servers provide or allocate resources. For example, if the redirection can result in a safe allocation state, the server can redirect the request to a different server.

[0142] Next, CDM is determined 328 and CNM is determined 330 by subtracting CALM from CDM (CNM=CDM−CALM).

[0143] After this information has been determined, a determination is made 332 whether the stream allocation state is secure or unsecure. If the stream allocation state is unsecure, a zero or negative borrow is granted 340. If the stream allocation state is secure, a borrow is granted. For example, a partial borrow may be granted 334, an equal borrow may be granted 336, or a prefetch borrow may be granted 338. The borrow is then distributed 308. In one example, the distribute borrow 308 may be part of the method 320 and incorporated into the grant borrow 334, 336, 338, or 340.

[0144] Figure 3C An example of determining the flow allocation state is shown. More specifically, Figure 3C Shows Figure 3B 332. Method 348 may be performed for each client 350. Starting with the first client 350, it is determined 352 whether CNM is greater than CDM. Therefore, if the current need is not greater than the current demand, the state is unsafe 354 and a negative borrow or zero borrow is distributed or granted, such as Figure 3B shown.

[0145] When CNM is greater than CDM, then the stream availability after granting the client's maximum stream request is determined 356. This calculation can be performed as if the requested borrowing is granted to determine whether the resulting state is secure. In addition, in one embodiment, all clients are evaluated as a whole to determine whether the stream allocation state is secure.

[0146] In one example, stream availability (356) is determined by the number of currently available streams 358 (this can be done as a whole or on a per server or node basis) minus the streams acquired by the client to reach the client's maximum demand 360. This result is then added to the streams returned by the client after the demand is processed 362. In other words, in one example, the system makes an evaluation assuming that the maximum possible stream requested by the client is granted.

[0147] Based on this determination 356, a determination is made 364 as to whether the available streams are less than the total available matrix. If not, the state is unsafe 366. If so and all clients have been processed 368, the state is safe 372 and if Figure 3B As shown, borrowing can be permitted. If all clients have not been processed, the next client 370 is processed.

[0148] therefore, Figure 3A-3C An example of a method for allocating resources is shown so that the allocation state of the system is safe. When a proposed resource allocation (e.g., a request from a client) results in an unsafe allocation state, then the allocation can be zero or negative, which allows the system to avoid the unsafe allocation state or return to a safe allocation state.

[0149] In addition to stream borrowing, embodiments of the present invention also relate to recovery borrowing, which is another example of borrowing. A recovery operation may include reading data from a backup maintained by a backup server and transferring or sending the data read from the backup to a recovery location or device. In one example, the resource allocation system and method may rely only on recovery borrowing that can be defined according to data (e.g., 1 borrow = 256MG or 500MB, or 1GB of read data, etc.), and / or stream borrowing as previously described.

[0150] Recovery borrowing improves the operation of a client or server by helping the client with read-ahead cache allocation / sizing, helping the client perform intelligent read-ahead, and improving the performance of recovery operations. In addition, embodiments of the present invention help to recover only the required data. This can avoid the costs associated with data that does not require recovery operations.

[0151] More specifically, clients often implement a read-ahead cache and may read more data as needed. This may become a concern, for example, in a cloud environment where costs are determined per recovered byte. In other words, reading more data than is needed may be expensive. Embodiments of the present invention allow the size of a client's read-ahead cache or buffer to be set or adjusted based on the size of the data being recovered. This is useful because, in one example, the client may not know the size of the data to be recovered. The server can help allocate and set the size of the client's read-ahead cache by providing pre-fetched recovery borrows.

[0152] For example, Figure 4 An example of a client performing a recovery operation using recovery borrowing and / or stream borrowing is shown. A server (or cluster) can support multiple clients using recovery borrowing and / or stream borrowing.

[0153] In Figure 4 In the example of FIG. 4 , client 402 is restoring restored data 406 to storage 404 (or other device / machine). Restored data 406 may be a database, a virtual machine, a file system, etc. When a restore operation is performed, restored data 4006 is restored from backup 412 (e.g., a specific backup). Data read from backup 412 is thus read by server 408 and transmitted to client 402. The client then writes data to restored data 406.

[0154] In this example, client 402 may request a restore borrow from server 408 (e.g., a backup server). Server 408 may maintain allocation table 414 that allows tracking of restore borrows and / or stream borrows. In this example, client 402 does not know the size of the data set to be restored. However, server 408 may know the size of the data set because its context exists on server 408.

[0155] As an example only, assuming that 256MB of data is associated with one restore borrow, the following scenario may occur. Client 402 wants to read 1GB of data, so 4 restore borrows may be requested from server 408. The client may also set a "prefetch" flag, which indicates to server 408 that this is a sequential restore and that the server may grant more borrows than requested. If the data set to be restored is 4GB, server 408 may grant 16 restore borrows to client 402, even though only 4 restore borrows were requested.

[0156] The number of restored borrows granted to client 402 can be used to adjust the size of the client's read-ahead cache or buffer 416. For example, a large number of borrows can cause client 402 to increase the size of the read-ahead buffer or cache to a size that can accommodate the amount of data associated with the granted borrows. Alternatively, the size of buffer 416 can be set in a manner that takes into account the rate at which cached data is restored to restored data 406. In one example, the size of buffer 416 can be dynamically adapted to the number of borrows held by client 402.

[0157] If the restore operation occurs in a cloud environment, the server 408 can ignore the pre-fetch flag and choose to grant the number of restore borrows with the amount requested by the client. This can be done because it may be expensive to read ahead and restore or read more data than required in a cloud environment.

[0158] The number of resume borrows granted by the server 408 may be granted in a manner similar to that of stream borrowing. The amount of resume borrows granted may be equal to the number of resume borrows requested by the client, less than the number of resume borrows requested, greater than the number of resume borrows requested, zero, or a negative number.

[0159] According to the number of recovery borrows received by the client 402, the client 402 will use the recovery borrows to perform the recovery operation. The recovery borrows are used to read data, and as the data is read, the recovery borrows are used or returned accordingly. Each use of the read of a data block will result in the use of a recovery borrow.

[0160] If the number of restore borrows granted is zero or negative, the client is instructed to throttle. Thus, the restore request cannot be executed (or may only be partially executed) and the restore borrow is returned to the server by the client. This allows the server to achieve a safe allocation state.

[0161] If the restore operation has completed and if client 402 has additional restore borrows cached in its connection structure, client 402 may choose to eventually release those restore borrows. Server 408 may update its internal borrow accounting database, allocation table 414, to account for restore borrows released from a particular client.

[0162] When a borrow is granted (regardless of type), the server 408 may execute a borrow allocation method. Embodiments of the invention contemplate that many indicators may be used to determine a borrow allocation or borrow allocation state. Examples include machine capabilities (connections, processors, cores, memory size, memory type, client connections, existing streams, available resources, etc. or a combination thereof.

[0163] Figure 5An example of a method for allocating recovery borrowing is shown. Method 500 may include steps or actions that are not performed every time the method is performed. Figure 5 In the example of FIG50 , an amount or number of reads that consumes 1% of a processor or core (e.g., a CPU or central processing unit) on average is determined or defined 502. Although this number is generally an approximation, statistics gathered by performing empirical recovery of data can be used to limit this number. The percentage of CPU utilization during various recovery runs or operations of different sizes and / or data types can be obtained or measured. For example, the average of these observations can be used to calculate the number of reads that consume 1% of the data. For example, if it is observed that restoring 1GB of data consumes 10% of the CPU and results in an average of 10,000 read requests, it can be estimated that 1,000 read requests to the server consume 1% of the CPU. This result can be used to determine the number of recovery borrows to be allocated to the requesting client.

[0164] Next, the average number of reads allowed per core is determined 504. In one example, this is determined by multiplying the number of reads that consume 1% of the CPU by the average percentage of idle CPU per core. If the average percentage of idle CPU per core is less than a threshold (e.g., 2%), then all clients are granted zero or negative borrows.

[0165] Next, the maximum borrow per client is determined 506. This can be determined by multiplying the average allowed reads per core by the number of CPU cores and then dividing by the number of client connections. The maximum borrow per client represents the maximum number of borrows that a client can obtain.

[0166] The allocation table keeps track of borrows that have been issued to clients. For example, if a client's maximum borrow is 100 and 60 have been granted, a request to restore 50 borrows may result in a partial borrow being granted, or a zero borrow, or a negative borrow. The allocation table is updated as borrows are granted, released, etc.

[0167] In one example, the amount of each client borrow is determined 508. This is different from the maximum borrow because the action or step can take into account a tuning factor that can be adjusted or configurable. The tuning factor allows embodiments of the present invention to factor the reservation value into the resources being allocated. The tuning factor can be 50%-70% of the maximum recovery borrow.

[0168] The borrows may then be distributed to the requesting clients 510. For example, the number of borrows distributed may be determined by simply using the minimum of the restore borrows requested by each client and the calculated borrows. If the client has requested prefetch, the number of restore borrows distributed may be the maximum of the restore borrows requested by each client and the calculated borrows.

[0169] Consider the following example. If the number of reads that consume 1% of the CPU on average is 1000 and the average percentage of idle CPU per core is 50%, then the average allowed reads per core is ((1000*0.5)=500). If the number of CPU cores is 4 and the number of clients is 10, then the maximum borrow per client is ((500*4) / 10=200). If the tuning factor is 50%, then the calculated borrow per client is (200*0.5=100). Therefore, the maximum borrow per client is different from the tuned or calculated borrow per client.

[0170] If the client then requests 40 restore borrows, the restore borrows granted are MIN(40, 100) = 40. Therefore 40 borrows are granted. If the client requests prefetch, the borrows granted are MAX(40, 100) = 100. Therefore 100 borrows are granted. If restoring from the cloud, prefetch can be omitted, in which case the borrows granted in this example can be 40.

[0171] Each time a request is made to resume a borrow, embodiments of the present invention can ensure that the grant does not result in an unsafe allocation state. For example, requesting a borrow that exceeds the client's maximum borrow may result in an unsafe allocation state. In addition, borrows already used by the client and other clients may also be considered when granting borrows. In addition, when determining the allocation state, the average percentage of idle CPU for each core may be determined. If a grant reduces the average percentage of idle CPU to below a threshold, the grant may be a zero borrow or a negative borrow.

[0172] In another example, resumption borrowing may be managed in a manner similar to stream borrowing such that each request for resumption borrowing is considered within the context of all resumption borrows available rather than within the context of the maximum borrow allowed per client or a resumption borrow calculated based on a tuning factor.

[0173] In one example, a resume borrow is an example of a stream borrow, at least because the data being resumed is also a stream from the server to the client. However, these borrow types can also be used together. For example, a stream borrow can be used to manage the number of streams, while a resume borrow can determine how much data a particular client can read for all of the client's streams.

[0174] It should be understood that the present invention can be implemented in many ways, including processes, devices, systems, equipment, methods or computer readable media or computer networks such as computer readable storage media, in which computer program instructions are sent via optical communication links or electrical communication links. Application programs can take the form of software executed on a general-purpose computer or can be hard-wired or hard-coded in hardware. In the present application, these implementations or any other form that the present invention can take can be referred to as technology. Typically, the order of steps in the disclosed process can be changed and still within the scope of the present invention.

[0175] The embodiments disclosed herein may include the use of a special or general purpose computer including various computer hardware or software modules, as discussed in more detail below. The computer may include a processor and a computer storage medium carrying instructions that, when executed by the processor and / or cause the instructions to be executed by the processor, perform any one or more of the methods disclosed herein.

[0176] As mentioned above, embodiments within the scope of the present invention also include computer storage media, which are physical media for carrying or carrying computer executable instructions or data structures stored thereon. Such computer storage media can be any available physical media that can be accessed by a general or special purpose computer.

[0177] By way of example and not limitation, such computer storage media may include hardware such as a solid state drive (SSD), RAM, ROM, EEPROM, CD-ROM, flash memory, phase change memory ("PCM"), or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other hardware storage device that can be used to store program code in the form of computer-executable instructions or data structures that can be accessed and executed by a general or special-purpose computer system to implement the functions disclosed in the present invention. Combinations of the above should also be included in the scope of computer storage media. These media are also examples of non-transitory storage media, although the scope of the present invention is not limited to these examples of non-transitory storage media, but non-transitory storage media also include cloud-based storage systems and structures.

[0178] Computer executable instructions include, for example, instructions and data that cause a general-purpose computer, a special-purpose computer, or a special-purpose processing device to perform a function or a group of functions. Although the subject matter has been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Instead, the specific features and actions disclosed herein are disclosed as example forms of implementing the claims.

[0179] As used herein, the term "module" or "component" may refer to a software object or program executed on a computing system. The different components, modules, engines, and services described herein may be implemented as objects or processes executed on a computing system, for example, as separate threads. Although the systems and methods described herein may be implemented in software, it is also possible and expected to be implemented in hardware or a combination of software and hardware. In this application, a "computing entity" may be any computing system as previously defined herein, or any module or combination of modules running on a computing system.

[0180] In at least some instances, a hardware processor is provided that is operable to execute executable instructions for performing a method or process, such as the methods and processes disclosed herein. The hardware processor may or may not include other hardware, such as elements of the computing devices and systems disclosed herein.

[0181] In terms of computing environment, embodiments of the present invention can be performed in a client-server environment, a network environment or a local environment, or any other suitable environment. Suitable operating environments for at least some embodiments of the present invention include cloud computing environments, in which one or more of the client, server, and target virtual machine can reside and operate in the cloud environment.

[0182] The present invention can be implemented in other specific forms without departing from its spirit or essential characteristics. The described embodiments are considered to be illustrative and non-restrictive in all respects. Therefore, the scope of the present invention is indicated by the appended claims rather than by the previous description. All changes falling within the equivalent meanings and equivalent ranges of the claims are included in the scope of the claims.

[0183] Appendix A

[0184]

[0185]

[0186]

[0187]

[0188]

[0189]

[0190]

[0191] result:

[0192] Available streams

[0193]

[0194] Stream allocation matrix for each client (current allocation)

[0195]

[0196] Maximum flow requirement matrix for each client

[0197]

[0198]

[0199] Each client's stream requires a matrix

[0200]

[0201] The system is in a safe state.

[0202] Stream distribution is in a stable state.

[0203] --------------

[0204] Experiment 1: Client C0 requests 10 streams from server N0.

[0205] --------------

[0206] Available streams

[0207]

[0208] Stream allocation matrix for each client (current allocation)

[0209]

[0210] Maximum flow requirement matrix for each client

[0211]

[0212] Each client's stream requires a matrix

[0213]

[0214] The system is in a safe state.

[0215] Stream distribution is in a stable state.

[0216] --------------

[0217] Experiment 2: Client C0 requests 20 streams from server N0.

[0218] --------------

[0219] Available streams

[0220]

[0221] Stream allocation matrix for each client (current allocation)

[0222]

[0223] Maximum flow requirement matrix for each client

[0224]

[0225] Each client's stream requires a matrix

[0226]

[0227] The system is in a safe state.

[0228] Stream distribution is in a stable state.

[0229] --------------

[0230] Experiment 3: Client C0 requests 30 streams from server N0.

[0231] --------------

[0232] Available streams

[0233]

[0234] Stream allocation matrix for each client (current allocation)

[0235]

[0236] Maximum flow requirement matrix for each client

[0237]

[0238] Each client's stream requires a matrix

[0239]

[0240] The system is in a safe state.

[0241] Stream distribution is in a stable state.

[0242] --------------

[0243] Experiment 4: Client C0 requests 40 streams from server N0.

[0244] --------------

[0245] Available streams

[0246]

[0247] Stream allocation matrix for each client (current allocation)

[0248]

[0249] Maximum flow requirement matrix for each client

[0250]

[0251] Each client's stream requires a matrix

[0252]

[0253] The system is in a safe state.

[0254] Stream distribution is in a stable state.

[0255] --------------

[0256] Experiment 5: Client C0 requests 10 streams from server N1.

[0257] --------------

[0258] Available streams

[0259]

[0260] Stream allocation matrix for each client (current allocation)

[0261]

[0262] Maximum flow requirement matrix for each client

[0263]

[0264] Each client's stream requires a matrix

[0265]

[0266] The system is in a safe state.

[0267] Stream distribution is in a stable state.

[0268] --------------

[0269] Experiment 6: Client C0 requests 20 streams from server N1.

[0270] --------------

[0271] Available streams

[0272]

[0273] Stream allocation matrix for each client (current allocation)

[0274]

[0275] Maximum flow requirement matrix for each client

[0276]

[0277] Each client's stream requires a matrix

[0278]

[0279] The system is in a safe state.

[0280] System allocation is in a stable state.

[0281] --------------

[0282] Experiment 7: Client C0 requests 30 streams from server N1.

[0283] --------------

[0284] Available streams

[0285]

[0286] Stream allocation matrix for each client (current allocation)

[0287]

[0288] Maximum flow requirement matrix for each client

[0289]

[0290] Each client's stream requires a matrix

[0291]

[0292]

[0293] The system is in a safe state.

[0294] Stream distribution is in a stable state.

[0295] --------------

[0296] Experiment 8: Client C0 requests 40 streams from server N1.

[0297] --------------

[0298] Available streams

[0299]

[0300] Stream allocation matrix for each client (current allocation)

[0301]

[0302] Maximum flow requirement matrix for each client

[0303]

[0304] Each client's stream requires a matrix

[0305]

[0306] The system is in a safe state.

[0307] Stream distribution is in a stable state.

[0308] --------------

[0309] Experiment 9: Client C0 requests 10 streams from server N2.

[0310] --------------

[0311] Available streams

[0312]

[0313]

[0314] Stream allocation matrix for each client (current allocation)

[0315]

[0316] Maximum flow requirement matrix for each client

[0317]

[0318] Each client's stream requires a matrix

[0319]

[0320] The system is in a safe state.

[0321] Stream distribution is in a stable state.

[0322] --------------

[0323] Experiment 10: Client C0 requests 20 streams from server N2.

[0324] --------------

[0325] Available streams

[0326]

[0327] Stream allocation matrix for each client (current allocation)

[0328]

[0329] Maximum flow requirement matrix for each client

[0330]

[0331] Each client's stream requires a matrix

[0332]

[0333] The system is in a safe state.

[0334] Stream distribution is in a stable state.

[0335] --------------

[0336] Experiment 11: Client C0 requests 30 streams from server N2.

[0337] --------------

[0338] Available streams

[0339]

[0340] Stream allocation matrix for each client (current allocation)

[0341]

[0342] Maximum flow requirement matrix for each client

[0343]

[0344] Each client's stream requires a matrix

[0345]

[0346] The system is in a safe state.

[0347] Stream distribution is in a stable state.

[0348] --------------

[0349] Experiment 12: Client C0 requests 40 streams from server N2.

[0350] --------------

[0351] Available streams

[0352]

[0353] Stream allocation matrix for each client (current allocation)

[0354]

[0355] Maximum flow requirement matrix for each client

[0356]

[0357] Each client's stream requires a matrix

[0358]

[0359] The system is in a safe state.

[0360] Stream distribution is in a stable state.

[0361] --------------

[0362] Experiment 13: Client C0 requests 10 streams from server N3.

[0363] --------------

[0364] Available streams

[0365]

[0366] Stream allocation matrix for each client (current allocation)

[0367]

[0368] Maximum flow requirement matrix for each client

[0369]

[0370]

[0371] Each client's stream requires a matrix

[0372]

[0373] The system is in a safe state.

[0374] Stream distribution is in a stable state.

[0375] --------------

[0376] Experiment 14: Client C0 requests 20 streams from server N3.

[0377] --------------

[0378] Available streams

[0379]

[0380] Stream allocation matrix for each client (current allocation)

[0381]

[0382] Maximum flow requirement matrix for each client

[0383]

[0384] Each client's stream requires a matrix

[0385]

[0386] The system is in a safe state.

[0387] Stream distribution is in a stable state.

[0388] --------------

[0389] Experiment 15: Client C0 requests 30 streams from server N3.

[0390] --------------

[0391] Available streams

[0392]

[0393] Stream allocation matrix for each client (current allocation)

[0394]

[0395] Maximum flow requirement matrix for each client

[0396]

[0397] Each client's stream requires a matrix

[0398]

[0399] The system is in a safe state.

[0400] Stream distribution is in a stable state.

[0401] --------------

[0402] Experiment 16: Client C0 requests 40 streams from server N3.

[0403] --------------

[0404] Available streams

[0405]

[0406] Stream allocation matrix for each client (current allocation)

[0407]

[0408]

[0409] Maximum flow requirement matrix for each client

[0410]

[0411] Each client's stream requires a matrix

[0412]

[0413] The system is in a safe state.

[0414] Stream distribution is in a stable state.

[0415] --------------

[0416] Experiment 17: Client C1 requests 10 streams from server N0.

[0417] --------------

[0418] Available streams

[0419]

[0420] Stream allocation matrix for each client (current allocation)

[0421]

[0422] Maximum flow requirement matrix for each client

[0423]

[0424] Each client's stream requires a matrix

[0425]

[0426] The system is in a safe state.

[0427] Stream distribution is in a stable state.

[0428] --------------

[0429] Experiment 18: Client C1 requests 20 streams from server N0.

[0430] --------------

[0431] Available streams

[0432]

[0433] Stream allocation matrix for each client (current allocation)

[0434]

[0435] Maximum flow requirement matrix for each client

[0436]

[0437] Each client's stream requires a matrix

[0438]

[0439] Self-security check by granting negative borrow = (10) from server = 0 to client = 0

[0440] Self-security check by granting negative borrowing = (10) from server = 1 to client = 1

[0441] Self-security check by granting negative borrowing = (30) from server = 2 to client = 2

[0442] The system is not in a secure state.

[0443] After granting negative borrows, recalculate the stream allocation state....

[0444] Available streams

[0445]

[0446] Stream allocation matrix for each client (current allocation)

[0447]

[0448]

[0449] Maximum flow requirement matrix for each client

[0450]

[0451] Each client's stream requires a matrix

[0452]

[0453] Self-security check by granting negative borrow = (10) from server = 0 to client = 0

[0454] The system is in a safe state.

[0455] Stream distribution is in a stable state.

[0456] --------------

[0457] Experiment 19: Client C1 requests 30 streams from server N0.

[0458] --------------

[0459] Available streams

[0460]

[0461] Stream allocation matrix for each client (current allocation)

[0462]

[0463] Maximum flow requirement matrix for each client

[0464]

[0465] Each client's stream requires a matrix

[0466]

[0467]

[0468] Self-security check by granting negative borrow = (20) from server = 0 to client = 0

[0469] Self-security check by granting negative borrowing = (10) from server = 1 to client = 1

[0470] Self-security check by granting negative borrowing = (30) from server = 2 to client = 2

[0471] The system is not in a secure state.

[0472] After granting negative borrows, recalculate the stream allocation state....

[0473] Available streams

[0474]

[0475] Stream allocation matrix for each client (current allocation)

[0476]

[0477] Maximum flow requirement matrix for each client

[0478]

[0479] Each client's stream requires a matrix

[0480]

[0481] Self-security check by granting negative borrow = (10) from server = 0 to client = 0

[0482] The system is in a safe state.

[0483] Stream distribution is in a stable state.

[0484] --------------

[0485] Experiment 20: Client C1 requests 40 streams from server N0.

[0486] --------------

[0487] Available streams

[0488]

[0489] Stream allocation matrix for each client (current allocation)

[0490]

[0491] Maximum flow requirement matrix for each client

[0492]

[0493] Each client's stream requires a matrix

[0494]

[0495] Self-security check by granting negative borrow = (20) from server = 0 to client = 0

[0496] Self-security check by granting negative borrowing = (10) from server = 1 to client = 1

[0497] Self-security check by granting negative borrowing = (30) from server = 2 to client = 2

[0498] The system is not in a secure state.

[0499] After granting negative borrows, recalculate the stream allocation state....

[0500] Available streams

[0501]

[0502] Stream allocation matrix for each client (current allocation)

[0503]

[0504] Maximum flow requirement matrix for each client

[0505]

[0506] Each client's stream requires a matrix

[0507]

[0508]

[0509] Self-security check by granting negative borrow = (10) from server = 0 to client = 0

[0510] The system is in a safe state.

[0511] Stream distribution is in a stable state.

[0512] --------------

[0513] Experiment 21: Client C1 requests 10 streams from server N1.

[0514] --------------

[0515] Available streams

[0516]

[0517] Stream allocation matrix for each client (current allocation)

[0518]

[0519] Maximum flow requirement matrix for each client

[0520]

[0521] Each client's stream requires a matrix

[0522]

[0523] Self-security check by granting negative borrow = (10) from server = 1 to client = 0

[0524] Self-security check by granting negative borrowing = (10) from server = 1 to client = 1

[0525] Self-security check by granting negative borrowing = (10) from server = 1 to client = 2

[0526] The system is not in a secure state.

[0527] After granting negative borrows, recalculate the stream allocation state....

[0528] Available streams

[0529]

[0530] Stream allocation matrix for each client (current allocation)

[0531]

[0532] Maximum flow requirement matrix for each client

[0533]

[0534] Each client's stream requires a matrix

[0535]

[0536] The system is in a safe state.

[0537] Stream distribution is in a stable state.

[0538] --------------

[0539] Experiment 22: Client C1 requests 20 streams from server N1.

[0540] --------------

[0541] Available streams

[0542]

[0543] Stream allocation matrix for each client (current allocation)

[0544]

[0545] Maximum flow requirement matrix for each client

[0546]

[0547] Each client's stream requires a matrix

[0548]

[0549]

[0550] Self-security check by granting negative borrow = (10) from server = 1 to client = 0

[0551] The system is in a safe state.

[0552] Stream distribution is in a stable state.

[0553] --------------

[0554] Experiment 23: Client C1 requests 30 streams from server N1.

[0555] --------------

[0556] Available streams

[0557]

[0558] Stream allocation matrix for each client (current allocation)

[0559]

[0560] Maximum flow requirement matrix for each client

[0561]

[0562] Each client's stream requires a matrix

[0563]

[0564] Self-security check by granting negative borrow = (10) from server = 1 to client = 0

[0565] The system is in a safe state.

[0566] Stream distribution is in a stable state.

[0567] --------------

[0568] Experiment 24: Client C1 requests 40 streams from server N1.

[0569] --------------

[0570] Available streams

[0571]

[0572] Stream allocation matrix for each client (current allocation)

[0573]

[0574] Maximum flow requirement matrix for each client

[0575]

[0576] Each client's stream requires a matrix

[0577]

[0578] Self-security check by granting negative borrow = (10) from server = 1 to client = 0

[0579] The system is in a safe state.

[0580] Stream distribution is in a stable state.

[0581] --------------

[0582] Experiment 25: Client C1 requests 10 streams from server N2.

[0583] --------------

[0584] Available streams

[0585]

[0586] Stream allocation matrix for each client (current allocation)

[0587]

[0588] Maximum flow requirement matrix for each client

[0589]

[0590]

[0591] Each client's stream requires a matrix

[0592]

[0593] The system is in a safe state.

[0594] Stream distribution is in a stable state.

[0595] --------------

[0596] Experiment 26: Client C1 requests 20 streams from server N2.

[0597] --------------

[0598] Available streams

[0599]

[0600] Stream allocation matrix for each client (current allocation)

[0601]

[0602] Maximum flow requirement matrix for each client

[0603]

[0604] Each client's stream requires a matrix

[0605]

[0606] The system is in a safe state.

[0607] Stream distribution is in a stable state.

[0608] --------------

[0609] Experiment 27: Client C1 requests 30 streams from server N2.

[0610] --------------

[0611] Available streams

[0612]

[0613] Stream allocation matrix for each client (current allocation)

[0614]

[0615] Maximum flow requirement matrix for each client

[0616]

[0617] Each client's stream requires a matrix

[0618]

[0619] The system is in a safe state.

[0620] Stream distribution is in a stable state.

[0621] --------------

[0622] Experiment 28: Client C1 requests 40 streams from server N2.

[0623] --------------

[0624] Available streams

[0625]

[0626] Stream allocation matrix for each client (current allocation)

[0627]

[0628]

[0629] Maximum flow requirement matrix for each client

[0630]

[0631] Each client's stream requires a matrix

[0632]

[0633] The system is in a safe state.

[0634] Stream distribution is in a stable state.

[0635] --------------

[0636] Experiment 29: Client C1 requests 10 streams from server N3.

[0637] --------------

[0638] Available streams

[0639]

[0640] Stream allocation matrix for each client (current allocation)

[0641]

[0642] Maximum flow requirement matrix for each client

[0643]

[0644] Each client's stream requires a matrix

[0645]

[0646] The system is in a safe state.

[0647] Stream distribution is in a stable state.

[0648] --------------

[0649] Experiment 30: Client C1 requests 20 streams from server N3.

[0650] --------------

[0651] Available streams

[0652]

[0653] Stream allocation matrix for each client (current allocation)

[0654]

[0655] Maximum flow requirement matrix for each client

[0656]

[0657] Each client's stream requires a matrix

[0658]

[0659] Self-security check by granting negative borrow = (10) from server = 3 to client = 0

[0660] Self-security check by granting negative borrowing = (10) from server = 1 to client = 1

[0661] Self-security check by granting negative borrowing = (30) from server = 2 to client = 2

[0662] The system is not in a secure state.

[0663] After granting negative borrows, recalculate the stream allocation state....

[0664] Available streams

[0665]

[0666] Stream allocation matrix for each client (current allocation)

[0667]

[0668]

[0669] Maximum flow requirement matrix for each client

[0670]

[0671] Each client's stream requires a matrix

[0672]

[0673] Self-security check by granting negative borrow = (10) from server = 3 to client = 0

[0674] The system is in a safe state.

[0675] Stream distribution is in a stable state.

[0676] --------------

[0677] Experiment 31: Client C1 requests 30 streams from server N3.

[0678] --------------

[0679] Available streams

[0680]

[0681] Stream allocation matrix for each client (current allocation)

[0682]

[0683] Maximum flow requirement matrix for each client

[0684]

[0685] Each client's stream requires a matrix

[0686]

[0687]

[0688] Self-security check by granting negative borrow = (10) from server = 3 to client = 0

[0689] Self-security check by granting negative borrowing = (10) from server = 1 to client = 1

[0690] Self-security check by granting negative borrowing = (30) from server = 2 to client = 2

[0691] The system is not in a secure state.

[0692] After granting negative borrows, recalculate the stream allocation state....

[0693] Available streams

[0694]

[0695] Stream allocation matrix for each client (current allocation)

[0696]

[0697] Maximum flow requirement matrix for each client

[0698]

[0699] Each client's stream requires a matrix

[0700]

[0701] Self-security check by granting negative borrow = (10) from server = 3 to client = 0

[0702] The system is in a safe state.

[0703] Stream distribution is in a stable state.

[0704] --------------

[0705] Experiment 32: Client C1 requests 40 streams from server N3.

[0706] --------------

[0707] Available streams

[0708]

[0709] Stream allocation matrix for each client (current allocation)

[0710]

[0711] Maximum flow requirement matrix for each client

[0712]

[0713] Each client's stream requires a matrix

[0714]

[0715] Self-security check by granting negative borrow = (10) from server = 3 to client = 0

[0716] Self-security check by granting negative borrowing = (10) from server = 1 to client = 1

[0717] Self-security check by granting negative borrowing = (30) from server = 2 to client = 2

[0718] The system is not in a secure state.

[0719] After granting negative borrows, recalculate the stream allocation state....

[0720] Available streams

[0721]

[0722] Stream allocation matrix for each client (current allocation)

[0723]

[0724] Maximum flow requirement matrix for each client

[0725]

[0726] Each client's stream requires a matrix

[0727]

[0728]

[0729] Self-security check by granting negative borrow = (10) from server = 3 to client = 0

[0730] The system is in a safe state.

[0731] Stream distribution is in a stable state.

[0732] --------------

[0733] Experiment 33: Client C2 requests 10 streams from server N0.

[0734] --------------

[0735] Available streams

[0736]

[0737] Stream allocation matrix for each client (current allocation)

[0738]

[0739] Maximum flow requirement matrix for each client

[0740]

[0741] Each client's stream requires a matrix

[0742]

[0743] The system is in a safe state.

[0744] Stream distribution is in a stable state.

[0745] --------------

[0746] Experiment 34: Client C2 requests 20 streams from server N0.

[0747] --------------

[0748] Available streams

[0749]

[0750]

[0751] Stream allocation matrix for each client (current allocation)

[0752]

[0753] Maximum flow requirement matrix for each client

[0754]

[0755] Each client's stream requires a matrix

[0756]

[0757] Self-security check by granting negative borrow = (10) from server = 0 to client = 0

[0758] Self-security check by granting negative borrowing = (10) from server = 1 to client = 1

[0759] Self-security check by granting negative borrowing = (30) from server = 2 to client = 2

[0760] The system is not in a secure state.

[0761] After granting negative borrows, recalculate the stream allocation state....

[0762] Available streams

[0763]

[0764] Stream allocation matrix for each client (current allocation)

[0765]

[0766] Maximum flow requirement matrix for each client

[0767]

[0768] Each client's stream requires a matrix

[0769]

[0770]

[0771] Self-security check by granting negative borrow = (10) from server = 0 to client = 0

[0772] The system is in a safe state.

[0773] Stream distribution is in a stable state.

[0774] --------------

[0775] Experiment 35: Client C2 requests 30 streams from server N0.

[0776] --------------

[0777] Available streams

[0778]

[0779] Stream allocation matrix for each client (current allocation)

[0780]

[0781] Maximum flow requirement matrix for each client

[0782]

[0783] Each client's stream requires a matrix

[0784]

[0785] Self-security check by granting negative borrow = (20) from server = 0 to client = 0

[0786] Self-security check by granting negative borrowing = (10) from server = 1 to client = 1

[0787] Self-security check by granting negative borrowing = (30) from server = 2 to client = 2

[0788] The system is not in a secure state.

[0789] After granting negative borrows, recalculate the stream allocation state....

[0790] Available streams

[0791]

[0792] Stream allocation matrix for each client (current allocation)

[0793]

[0794] Maximum flow requirement matrix for each client

[0795]

[0796] Each client's stream requires a matrix

[0797]

[0798] Self-security check by granting negative borrow = (10) from server = 0 to client = 0

[0799] The system is in a safe state.

[0800] Stream distribution is in a stable state.

[0801] --------------

[0802] Experiment 36: Client C2 requests 40 streams from server N0.

[0803] --------------

[0804] Available streams

[0805]

[0806] Stream allocation matrix for each client (current allocation)

[0807]

[0808] Maximum flow requirement matrix for each client

[0809]

[0810] Each client's stream requires a matrix

[0811]

[0812] Self-security check by granting negative borrow = (20) from server = 0 to client = 0

[0813] Self-security check by granting negative borrowing = (10) from server = 1 to client = 1

[0814] Self-security check by granting negative borrowing = (30) from server = 2 to client = 2

[0815] The system is not in a secure state.

[0816] After granting negative borrows, recalculate the stream allocation state....

[0817] Available streams

[0818]

[0819] Stream allocation matrix for each client (current allocation)

[0820]

[0821] Maximum flow requirement matrix for each client

[0822]

[0823] Each client's stream requires a matrix

[0824]

[0825] Self-security check by granting negative borrow = (10) from server = 0 to client = 0

[0826] The system is in a safe state.

[0827] Stream distribution is in a stable state.

[0828] --------------

[0829] Experiment 37: Client C2 requests 10 streams from server N1.

[0830] --------------

[0831] Available streams

[0832]

[0833] Stream allocation matrix for each client (current allocation)

[0834]

[0835] Maximum flow requirement matrix for each client

[0836]

[0837] Each client's stream requires a matrix

[0838]

[0839] Self-security check by granting negative borrow = (10) from server = 1 to client = 0

[0840] Self-security check by granting negative borrow = (20) from server = 1 to client = 1

[0841] Self-security check by granting negative borrowing = (30) from server = 2 to client = 2

[0842] The system is not in a secure state.

[0843] After granting negative borrows, recalculate the stream allocation state....

[0844] Available streams

[0845]

[0846] Stream allocation matrix for each client (current allocation)

[0847]

[0848] Maximum flow requirement matrix for each client

[0849]

[0850] Each client's stream requires a matrix

[0851]

[0852] The system is in a safe state.

[0853] Stream distribution is in a stable state.

[0854] --------------

[0855] Experiment 38: Client C2 requests 20 streams from server N1.

[0856] --------------

[0857] Available streams

[0858]

[0859] Stream allocation matrix for each client (current allocation)

[0860]

[0861] Maximum flow requirement matrix for each client

[0862]

[0863] Each client's stream requires a matrix

[0864]

[0865] Self-security check by granting negative borrow = (10) from server = 1 to client = 0

[0866] Self-security check by granting negative borrow = (20) from server = 1 to client = 1

[0867] Self-security check by granting negative borrowing = (30) from server = 2 to client = 2

[0868] The system is not in a secure state.

[0869] After granting negative borrows, recalculate the stream allocation state....

[0870] Available streams

[0871]

[0872]

[0873] Stream allocation matrix for each client (current allocation)

[0874]

[0875] Maximum flow requirement matrix for each client

[0876]

[0877] Each client's stream requires a matrix

[0878]

[0879] The system is in a safe state.

[0880] Stream distribution is in a stable state.

[0881] --------------

[0882] Experiment 39: Client C2 requests 30 streams from server N1.

[0883] --------------

[0884] Available streams

[0885]

[0886] Stream allocation matrix for each client (current allocation)

[0887]

[0888] Maximum flow requirement matrix for each client

[0889]

[0890] Each client's stream requires a matrix

[0891]

[0892] Self-security check by granting negative borrow = (10) from server = 1 to client = 0

[0893] Self-security check by granting negative borrow = (20) from server = 1 to client = 1

[0894] Self-security check by granting negative borrowing = (30) from server = 2 to client = 2

[0895] The system is not in a secure state.

[0896] After granting negative borrows, recalculate the stream allocation state....

[0897] Available streams

[0898]

[0899] Stream allocation matrix for each client (current allocation)

[0900]

[0901] Maximum flow requirement matrix for each client

[0902]

[0903] Each client's stream requires a matrix

[0904]

[0905] The system is in a safe state.

[0906] Stream distribution is in a stable state.

[0907] --------------

[0908] Experiment 40: Client C2 requests 40 streams from server N1.

[0909] --------------

[0910] Available streams

[0911]

[0912]

[0913] Stream allocation matrix for each client (current allocation)

[0914]

[0915] Maximum flow requirement matrix for each client

[0916]

[0917] Each client's stream requires a matrix

[0918]

[0919] Self-security check by granting negative borrow = (10) from server = 1 to client = 0

[0920] Self-security check by granting negative borrow = (20) from server = 1 to client = 1

[0921] Self-security check by granting negative borrowing = (30) from server = 2 to client = 2

[0922] The system is not in a secure state.

[0923] After granting negative borrows, recalculate the stream allocation state....

[0924] Available streams

[0925]

[0926] Stream allocation matrix for each client (current allocation)

[0927]

[0928] Maximum flow requirement matrix for each client

[0929]

[0930] Each client's stream requires a matrix

[0931]

[0932]

[0933] The system is in a safe state.

[0934] Stream distribution is in a stable state.

[0935] --------------

[0936] Experiment 41: Client C2 requests 10 streams from server N2.

[0937] --------------

[0938] Available streams

[0939]

[0940] Stream allocation matrix for each client (current allocation)

[0941]

[0942] Maximum flow requirement matrix for each client

[0943]

[0944] Each client's stream requires a matrix

[0945]

[0946] The system is in a safe state.

[0947] Stream distribution is in a stable state.

[0948] --------------

[0949] Experiment 42: Client C2 requests 20 streams from server N2.

[0950] --------------

[0951] Available streams

[0952]

[0953] Stream allocation matrix for each client (current allocation)

[0954]

[0955] Maximum flow requirement matrix for each client

[0956]

[0957] Each client's stream requires a matrix

[0958]

[0959] The system is in a safe state.

[0960] Stream distribution is in a stable state.

[0961] --------------

[0962] Experiment 43: Client C2 requests 30 streams from server N2.

[0963] --------------

[0964] Available streams

[0965]

[0966] Stream allocation matrix for each client (current allocation)

[0967]

[0968] Maximum flow requirement matrix for each client

[0969]

[0970] Each client's stream requires a matrix

[0971]

[0972] The system is in a safe state.

[0973] Stream distribution is in a stable state.

[0974] --------------

[0975] Experiment 44: Client C2 requests 40 streams from server N2.

[0976] --------------

[0977] Available streams

[0978]

[0979] Stream allocation matrix for each client (current allocation)

[0980]

[0981] Maximum flow requirement matrix for each client

[0982]

[0983] Each client's stream requires a matrix

[0984]

[0985] The system is in a safe state.

[0986] Stream distribution is in a stable state.

[0987] --------------

[0988] Experiment 45: Client C2 requests 10 streams from server N3. --------------

[0989] Available streams

[0990]

[0991] Stream allocation matrix for each client (current allocation)

[0992]

[0993] Maximum flow requirement matrix for each client

[0994]

[0995] Each client's stream requires a matrix

[0996]

[0997] The system is in a safe state.

[0998] Stream distribution is in a stable state.

[0999] --------------

[1000] Experiment 46: Client C2 requests 20 streams from server N3.

[1001] --------------

[1002] Available streams

[1003]

[1004] Stream allocation matrix for each client (current allocation)

[1005]

[1006] Maximum flow requirement matrix for each client

[1007]

[1008] Each client's stream requires a matrix

[1009]

[1010] Self-security check by granting negative borrow = (10) from server = 3 to client = 0

[1011] Self-security check by granting negative borrowing = (10) from server = 1 to client = 1

[1012] Self-security check by granting negative borrowing = (30) from server = 2 to client = 2

[1013] The system is not in a secure state.

[1014] After granting negative borrows, recalculate the stream allocation state....

[1015] Available streams

[1016]

[1017] Stream allocation matrix for each client (current allocation)

[1018]

[1019] Maximum flow requirement matrix for each client

[1020]

[1021] Each client's stream requires a matrix

[1022]

[1023] Self-security check by granting negative borrow = (10) from server = 3 to client = 0

[1024] The system is in a safe state.

[1025] Stream distribution is in a stable state.

[1026] --------------

[1027] Experiment 47: Client C2 requests 30 streams from server N3.

[1028] --------------

[1029] Available streams

[1030]

[1031] Stream allocation matrix for each client (current allocation)

[1032]

[1033] Maximum flow requirement matrix for each client

[1034]

[1035] Each client's stream requires a matrix

[1036]

[1037] Self-security check by granting negative borrow = (10) from server = 3 to client = 0

[1038] Self-security check by granting negative borrowing = (10) from server = 1 to client = 1

[1039] Self-security check by granting negative borrowing = (30) from server = 2 to client = 2

[1040] The system is not in a secure state.

[1041] After granting negative borrows, recalculate the stream allocation state....

[1042] Available streams

[1043]

[1044] Stream allocation matrix for each client (current allocation)

[1045]

[1046] Maximum flow requirement matrix for each client

[1047]

[1048]

[1049] Each client's stream requires a matrix

[1050]

[1051] Self-security check by granting negative borrow = (10) from server = 3 to client = 0

[1052] The system is in a safe state.

[1053] Stream distribution is in a stable state.

[1054] --------------

[1055] Experiment 48: Client C2 requests 40 streams from server N3.

[1056] --------------

[1057] Available streams

[1058]

[1059] Stream allocation matrix for each client (current allocation)

[1060]

[1061] Maximum flow requirement matrix for each client

[1062]

[1063] Each client's stream requires a matrix

[1064]

[1065] Self-security check by granting negative borrow = (10) from server = 3 to client = 0

[1066] Self-security check by granting negative borrowing = (10) from server = 1 to client = 1

[1067] Self-security check by granting negative borrowing = (30) from server = 2 to client = 2

[1068] The system is not in a secure state.

[1069] After granting negative borrows, recalculate the stream allocation state....

[1070] Available streams

[1071]

[1072] Stream allocation matrix for each client (current allocation)

[1073]

[1074] Maximum flow requirement matrix for each client

[1075]

[1076] Each client's stream requires a matrix

[1077]

[1078] Self-security check by granting negative borrow = (10) from server = 3 to client = 0

[1079] The system is in a safe state.

[1080] Stream distribution is in a stable state.

Claims

1. A method for allocating resources of a server to a client connected to the server, the method comprising: receiving requests for stream borrows from clients, wherein each of said stream borrows corresponds to an amount of data read from said server; determining a number of stream borrowings available to the client, wherein the number of stream borrowings available to the client takes into account stream borrowings already distributed to the client; If the request for stream borrowing is granted to the client, determining whether granting the request for stream borrowing results in a secure allocation state for the at least one other client by considering a capability of the at least one other client to obtain stream borrowing; and Stream borrowings are distributed to the clients based on the requests and the number of stream borrowings available to the clients.

2. The method according to claim 1, further comprising at least one of the following: Distributing a number of stream borrows equal to the number of stream borrows requested by the client; Distributing a number of stream borrowings greater than the number of stream borrowings requested by the client; Distributing a number of stream borrowings that is less than the number of stream borrowings requested by the client; Distributing zero-stream borrowing to the client; or Distribute negative flow borrows to the clients.

3. The method according to claim 2, wherein: Dispatching a negative stream borrow causes a stream borrow held by the client to be released, and wherein causing the client to release the stream borrow results in the secure allocation state. 4 . The method of claim 1 , further comprising determining a number of reads that consume 1% of the CPU on average.

5. The method according to claim 4, further comprising: The average reads allowed per core are determined based on the number of reads that consume 1% of the CPU and the average idle percentage of the CPU, and the maximum recovery borrow for each client is determined based on the number of client connections, wherein each client is also associated with a recovery borrow, and the recovery borrow is configured to perform recovery operations and to read data.

6. The method according to claim 5, further comprising: The calculated amount of restoration borrowing for each client is determined based on a tuning factor applied to the maximum restoration borrowing for each client.

7. The method according to claim 6, further comprising: The restoration borrows are distributed in an amount equal to the minimum of the requested amount of restoration borrows and the calculated amount of restoration borrows.

8. The method according to claim 1, wherein: Each client is associated with a restore borrow for facilitating a restore operation by reading data from a backup maintained by a backup server and transmitting the data read from the backup maintained by the backup server to restore the device, and, The method also includes finally releasing the restore borrow by the client that completes the restore operation.

9. The method according to claim 1, further comprising: When the average idle percentage of each core of the processor is less than a predetermined threshold, all clients are throttled.

10. A non-transitory computer-readable medium comprising computer-executable instructions for, when executed, implementing a method for allocating resources of a server to a client connected to the server, the method comprising: receiving requests for stream borrows from clients, wherein each of said stream borrows corresponds to an amount of data read from said server; determining a number of stream borrowings available to the client, wherein the number of stream borrowings available to the client takes into account stream borrowings already distributed to the client; If the request for stream borrowing is granted to the client, determining whether granting the request for stream borrowing results in a secure allocation state for the at least one other client by considering a capability of the at least one other client to obtain stream borrowing; and Stream borrowings are distributed to the clients based on the requests and the number of stream borrowings available to the clients.

11. The non-transitory computer-readable medium of claim 10, further comprising at least one of: Distributing a number of stream borrows equal to the number of stream borrows requested by the client; Distributing a number of stream borrowings greater than the number of stream borrowings requested by the client; Distributing a number of stream borrowings that is less than the number of stream borrowings requested by the client; Distributing zero-stream borrowing to the client; or Distribute negative flow borrows to the clients.

12. The non-transitory computer-readable medium of claim 10, further comprising dynamically determining a size of a client cache based on a number of stream borrows distributed to the client.

13. The non-transitory computer readable medium of claim 10, further comprising: A prefetch flag is included in the request, wherein the prefetch flag indicates that data on the server is accessed continuously by the client.

14. The non-transitory computer readable medium of claim 10, further comprising determining a number of reads that consume 1% of the CPU on average.

15. The non-transitory computer readable medium of claim 14, further comprising: The average allowed reads per core are determined based on the number of reads that consume 1% of the CPU and the average idle percentage of the CPU, and the maximum recovery borrow per client is determined based on the number of client connections, wherein each client is associated with a stream borrow and a recovery borrow, and the recovery borrow is configured to perform a recovery operation and to read data.

16. The non-transitory computer readable medium of claim 15, further comprising: The calculated amount of restoration borrowing for each client is determined based on a tuning factor applied to the maximum restoration borrowing for each client.

17. The non-transitory computer readable medium of claim 16, further comprising: The restoration borrows are distributed in an amount equal to the minimum of the requested amount of restoration borrows and the calculated amount of restoration borrows.

18. The non-transitory computer readable medium of claim 17, further comprising: The restoration borrows are distributed in an amount equal to the maximum of the requested amount of restoration borrows and the calculated amount of restoration borrows.

19. The non-transitory computer readable medium of claim 11, wherein: The safe allocation state allows all clients to acquire their maximum stream borrows, use the stream borrows, and release the stream borrows when all other clients are considered individually, and wherein issuing a negative stream borrow causes a stream borrow held by the client to be released, and wherein causing the client to release the stream borrow results in the safe allocation state.

Images