Stream assignment using stream borrowing

Abstract

Systems and methods for allocating resources are disclosed. Resources such as streams are allocated using a stream borrowing system. 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 amounts greater than requested. Zero borrows or negative borrows can also be distributed to throttle clients.

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 flow allocation or resource allocation. Appendix A constitutes a part of the present application and is incorporated by reference in its entirety into the present application. 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 complicated 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. QOS is often impaired when the demand for resources exceeds what a node or cluster can sustain. In order to avoid this situation or to 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 Method for evaluating the state of a stream allocation. DETAILED DESCRIPTION

[0010] 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.

[0011] 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 (e.g., when performing recovery operations), and allocating distributed segment processing (DSP) credits.

[0012] 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.

[0013] 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.

[0014] These stream 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 are served until completion. This is achieved by 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.

[0015] 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.

[0016] For example, borrowing can be described as follows:

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

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

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

[0020] 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.

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

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

[0023] 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.

[0024] 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. Stream borrowing can be managed using resource allocation table 120, which allows allocation status (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.

[0025] 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.

[0026] 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 permit x streams for each borrowing. If all streams associated with all clients can be completed for execution, the server 110 may permit the stream borrowing to the requesting client.

[0027] Since the server 110 may not know when a particular client stream terminates, nor how many more stream borrows different clients may request by the time the particular client stream completes, the server 110 may assume that all clients will eventually attempt to obtain their maximum allowed stream borrows, use the stream borrows, and then release the stream borrows.

[0028] 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 the stream borrowing. 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.

[0029] 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.

[0030] 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.

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

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

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

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

[0035] 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.

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

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

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

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

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

[0041] 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.

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

[0043] 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.

[0044] The following example explains the process in more detail. Figure 2A 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.

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

[0046] N1 N2 N3 N4 60 50 70 60

[0047] 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.

[0048] 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.

[0049] 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.

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

[0051] CALM

[0052] 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:

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

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

[0055] Similarly,

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

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

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

[0059]

[0060] 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.

[0061] 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.

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

[0063] CDM

[0064] 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:

[0065]

[0066] 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.

[0067] 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.

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

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

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

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

[0072] 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.

[0073] 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:

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

[0075] 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, that is, <40 30 30 30><=<60 50 70 60>, so the system state is safe to allocate and process the next client request.

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

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

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

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

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

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

[0082] 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.

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

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

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

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

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

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

[0089] This <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, ie <60 50 70 60><=<60 50 70 60>, so the system state is safe to allocate and process the next client request.

[0090] 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.

[0091] 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.

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

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

[0094] 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:

[0095] CAM or available streams on a node:

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

[0097] The stream CALM currently allocated to client 204 is now as follows (assuming here that C3's request for 10 borrows of N3 is granted):

[0098] CALM

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

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

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

[0102] CDM

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

[0104]

[0105] 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.

[0106] 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.

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

[0108] 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:

[0109] N1 N2 N3 N4 30 10 10 20

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

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

[0112] 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.

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

[0114] 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:

[0115] CAM or available streams on a node:

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

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

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

[0119] CALM

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

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

[0122] CDM

[0123] 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.

[0124]

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

[0126] 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.

[0127] 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.

[0128] 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.

[0129] 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.

[0130] 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.

[0131] 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.

[0132] 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.

[0133] Figure 3A An 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.

[0134] 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.

[0135] 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.

[0136] 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.

[0137] Figure 3B An example of more details of evaluating the flow state is shown. More specifically, Figure 3B Shows Figure 3A Thus, 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.

[0138] 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.

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

[0140] 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.

[0141] 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, a determination is made 352 whether CNM is greater than CDM. Thus, 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.

[0142] 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.

[0143] In one example, stream availability (356) is determined by subtracting the streams acquired by the client to reach the client's maximum demand 360 from the number of currently available streams 358 (this can be done as a whole or on a per server or node basis). The 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.

[0144] 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.

[0145] therefore, Figure 3A-3CAn 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.

[0146] 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.

[0147] 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.

[0148] 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.

[0149] 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.

[0150] 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.

[0151] 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.

[0152] 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.

[0153] 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.

[0154] 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.

Claims

1. A method for allocating resources of a server cluster to a client, the method comprising: include: streaming one or more streams with respect to the client using resources of the cluster, wherein each of the one or more streams consumes some resources of the cluster of servers; receiving, at the cluster, a request for stream borrowing from a client, wherein the stream borrowing is for using a stream provided by the cluster of servers; determining a current allocation matrix identifying flows currently allocated to each client from each server in the cluster of servers; determining a current demand matrix, the current demand matrix specifying a maximum number of streams that each client can request from each server in the cluster of servers at a given point in time; Determining a current need matrix based on the current demand matrix and the current allocation matrix, wherein the current need matrix identifies the number of stream borrowings that each client can request from each server in the cluster of servers to obtain its maximum number of stream borrowings; In response to the request for stream borrowing from the client, the cluster determines, by the cluster, an allocation state of the cluster, wherein determining the allocation state comprises: determining a number of streams available from the server; Assuming that the request for stream borrowing is granted; and determining whether the client and each other client can continuously request and use their maximum stream borrowing based on the current allocation matrix, the current demand matrix, the current need matrix, and the request for stream borrowing from the client; wherein the allocation state is secure when each client including the requesting client is able to request and use their maximum stream borrowing, and wherein the allocation state is unsecure when resources associated with each client's maximum stream borrowing cannot be allocated and used; and In response to the request for a stream borrow, the stream borrow is distributed based on the allocation status.

2. The method of claim 1, further comprising defining a maximum number of flows for allocation.

3. The method according to claim 2, in, The maximum number of streams for allocation is related to the processing capacity of the server, wherein each client can request stream borrowing from any server in the cluster.

4. The method of claim 1, further comprising defining a maximum number of streams to allocate to each server, wherein the maximum number of streams per server is based on a number of write or read parameters.

5. The method according to claim 1, in, Distributing the borrowing based on the allocation status includes at least one of the following: distributing stream borrows in an amount equal to the request; distributing stream borrows in an amount greater than the request; distributing stream borrows in an amount greater than zero and less than the request; Distribute zero stream borrows; as well as Distribute negative flow borrows.

6. The method according to claim 1, further comprising: include: When the allocation state is unsafe, throttling the client until the allocation state is safe.

7. A non-transitory computer-readable medium comprising instructions for implementing a method for allocating resources of a cluster of servers to a client, the method include: streaming one or more streams with respect to the client using resources of the cluster, wherein each of the one or more streams consumes some resources of the cluster of servers; receiving, at the cluster, a request for stream borrowing from a client, wherein the stream borrowing is for using a stream provided by the cluster of servers; determining a current allocation matrix identifying flows currently allocated to each client from each server in the cluster of servers; determining a current demand matrix, the current demand matrix specifying a maximum number of streams that each client can request from each server in the cluster of servers at a given point in time; Determining a current need matrix based on the current demand matrix and the current allocation matrix, wherein the current need matrix identifies the number of stream borrowings that each client can request from each server in the cluster of servers to obtain its maximum number of stream borrowings; In response to the request for stream borrowing from the client, the cluster determines, by the cluster, an allocation state of the cluster, wherein determining the allocation state comprises: determining a number of streams available from the server; Assuming that the request for stream borrowing is granted; and determining whether the client and each other client can continuously request and use their maximum stream borrowing based on the current allocation matrix, the current demand matrix, the current need matrix, and the request for stream borrowing from the client; wherein the allocation state is secure when each client including the requesting client is able to request and use their maximum stream borrowing, and wherein the allocation state is unsecure when resources associated with each client's maximum stream borrowing cannot be allocated and used; and In response to the request for a stream borrow, the stream borrow is distributed based on the allocation status.

8. The non-transitory computer readable medium of claim 7, further comprising defining a maximum number of streams for allocation.

9. The non-transitory computer readable medium of claim 8, in, The maximum number of streams for allocation is related to the processing capacity of the server, wherein each client can request stream borrowing from any server in the cluster.

10. The non-transitory computer readable medium of claim 7, further comprising defining a maximum number of streams to allocate for each server, wherein the maximum number of streams for each server is based on a number of write or read parameters.

11. The non-transitory computer readable medium of claim 7, in, Distributing the borrowing based on the allocation status includes at least one of the following: distributing stream borrows in an amount equal to the request; distributing stream borrows in an amount greater than the request; distributing stream borrows in an amount greater than zero and less than the request; Distribute zero stream borrows; as well as Distribute negative flow borrows.

12. The non-transitory computer readable medium of claim 11, further comprising: include: When the allocation state is unsafe, throttling the client until the allocation state is safe.

Images