Dynamic allocation of compute resources at a recovery site

Patent metadata

Field	Value
Publication number	US-12164398-B2
Application number	US-202318151350-A
Country	US
Kind code	B2
Filing date	Jan 6, 2023
Priority date	Apr 18, 2018
Publication date	Dec 10, 2024
Grant date	Dec 10, 2024

Abstract

Examples of systems are described herein which may dynamically allocate compute resources to recovery clusters. Accordingly, a recovery site may utilize fewer compute resources in maintaining recovery clusters for multiple associate clusters, while ensuring that, during use, compute resources are allocated to a particular cluster. This may reduce and/or avoid vulnerabilities arising from a use of shared resources in a virtualized and/or cloud environment.

First claim

What is claimed is:

1. A system comprising:
a first cluster comprising a plurality of first nodes and a first storage pool, each of the plurality of first nodes configured to manage input/output (I/O) requests to the first storage pool;
a recovery cluster comprising a plurality of second nodes configured for distributed access to a second storage pool, wherein the first cluster is configured to communicate a snapshot comprising storage data for the first storage pool of the first cluster to the recovery cluster to maintain the second storage pool in preparation for a recovery event;
and

a cluster manager, in communication with the recovery cluster, the cluster manager configured to receive an indication of the recovery event, the cluster manager further configured to, based at least on receipt of the indication of the recovery event, add an unallocated node the recovery cluster.

2. The system of claim 1 , wherein the unallocated node added to the recovery cluster by the cluster manager is a compute-only node comprising storage configured to remain independent from the second storage pool of the recovery cluster.

3. The system of claim 1 , wherein the first cluster is located at an operational site that is different from a recovery site where the recovery cluster is located.

4. The system of claim 1 , wherein the cluster manager is further configured to de-allocate the unallocated node from the recovery cluster and allocate the unallocated node to an available resource pool in response to an indication that the first cluster is restored.

5. The system of claim 4 , wherein the cluster manager is further configured to reassign the unallocated node to another recovery cluster based at least on receipt of another indication of another recovery event.

6. The system of claim 1 , wherein the cluster manager is further configured to select the unallocated node to dynamically add to the recovery cluster based at least in part on a rack location of the unallocated node.

7. The system of claim 1 , wherein the cluster manager is further configured to select the unallocated node to dynamically add to the recovery cluster based at least in part on a rack location of at least a portion of the recovery cluster.

8. The system of claim 1 , wherein the cluster manager is further configured to select the unallocated node to dynamically add to the recovery cluster based at least in part on a comparison between an amount of compute resources provided by the unallocated node and an amount of compute resources used by the first cluster.

9. The system of claim 1 , wherein the first cluster is located on a cloud computing system, and the recovery cluster is located on premise.

10. A method comprising:
communicating, by a at least one node of a plurality of first nodes each in communication with a first storage pool, a snapshot comprising storage data for the first storage pool, to at least one node of a plurality of recovery nodes, each in communication with a second storage pool, to maintain the second storage pool in preparation for a recovery event, wherein each of the plurality of first nodes are configured to access the first storage pool and wherein each of the recovery nodes is configured for distributed access to the second storage pool;
receiving, by a manager in communication with a recovery cluster, an indication of a recovery event associated with the plurality of first nodes; and
adding an unallocated node to the plurality of recovery nodes based at least on receipt of the indication of the recovery event associated with the plurality of first nodes.

11. The method of claim 10 , wherein the unallocated node added to the plurality of recovery nodes by the manager is a compute-only node comprising storage configured to remain independent from the second storage pool of the plurality of recovery nodes.

12. The method of claim 10 , wherein the plurality of first nodes is located at an operational site different than a recovery site where the plurality of recovery nodes is located.

13. The method of claim 10 , the method further comprising de-allocating, by the manager, the unallocated node from the plurality of recovery nodes and to an available resource pool in response to an indication that the plurality of first nodes is restored.

14. The method of claim 13 , the method further comprising reassigning, by the manager, the unallocated node to another recovery site based at least on receipt of another indication of another recovery event.

15. The method of claim 10 , the method further comprising selecting, by the manager, the unallocated node to dynamically add to the plurality of recovery nodes based at least in part on a rack location of the unallocated node.

16. The method of claim 10 , the method further comprising selecting, by the manager, the unallocated node to dynamically add to the plurality of recovery nodes based at least in part on a rack location of at least a portion of the plurality of recovery nodes.

17. The method of claim 10 , the method further comprising selecting, by the manager, the unallocated node to dynamically add to the plurality of recovery nodes based at least in part on a comparison between an amount of compute resources provided by the unallocated node and an amount of compute resources used by the plurality of first nodes.

18. The method of claim 10 , wherein the plurality of first nodes is located on a cloud computing system, and the plurality of recovery nodes is located on premise.

19. At least one non-transitory computer readable medium comprising instructions which, when executed, cause a computing system to:
receive an indication of a recovery event for an operational cluster, wherein the operational cluster comprises a plurality of operational nodes and a first storage pool, each of the plurality of operational nodes are configured to manage input/output (I/O) requests to the first storage pool and wherein a recovery cluster comprises a plurality of recovery nodes configured for distributed access to a second storage pool, wherein the operational cluster is configured to communicate a snapshot comprising redundant storage data for the first storage pool of the operational cluster, to the recovery cluster to maintain the second storage pool in preparation for the recovery event; and
add an unallocated node to the recovery cluster based at least on receipt of the indication of the recovery event.

20. The non-transitory computer readable medium of claim 19 , wherein the unallocated node added to the recovery cluster is a compute-only node comprising storage configured to remain independent from the second storage pool of the recovery cluster.

21. The non-transitory computer readable medium of claim 19 , wherein the operational cluster is located at an operational site that is different from a recovery site where the recovery cluster is located.

22. The non-transitory computer readable medium of claim 19 , wherein the instructions when executed, further cause the computing system to:
de-allocate the unallocated node from the recovery cluster and to an available resource pool in response to an indication that the operational cluster is restored.

23. The non-transitory computer readable medium of claim 21 , wherein the instructions when executed, further cause the computing system to:
reassign the unallocated node to another recovery site based at least on receipt of another indication of another recovery event.

24. The

Assignees

• Nutanix Inc

Inventors

• Gill Binny Sher
• Olderdissen Jan
• Mirani Rajiv
• Cui Miao

Classifications

• G06F9/45558 Primary

  Hypervisor-specific management and integration aspects · CPC title

• G06F2201/815

  Virtual · CPC title

• G06F2009/45583

  Memory management, e.g. access or allocation · CPC title

• G06F11/2046

  where the redundant components share persistent storage (G06F11/2043 takes precedence) · CPC title

• G06F11/2041

  with more than one idle spare processing component · CPC title