IP Library › Granted Patent US 10,489,255
Granted Patent B2
US 10,489,255 · App. 15/847,261 · Granted Nov 26, 2019

Disaster recovery of containers

Inventors: Balaji Ramamoorthi (Bangalore, IN); Siva Subramaniam Manickam (Bangalore, IN); Vinnarasu Ganesan (Bangalore, IN); Thavamaniraja Sakthivel (Bangalore, IN); Saravana Prabu (Bangalore, IN)
Assignee: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP
G06F11/203G06F11/1662G06F11/2023G06F2201/805G06F2201/82
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 10,489,255
App. No.
15/847,261
Granted
Nov 26, 2019
Kind
B2
Abstract

In one example, mapping information corresponding to a container running on a private data center may be generated in a public cloud by a processor-based disaster recovery manager. Further, volume data associated with the container may be synchronized to the public cloud based on the mapping information by the disaster recovery manager. Furthermore, a failure of the container running on the private data center may be determined by the disaster recovery manager. In response to the failure of the container running on the private data center, the container may be deployed in the public cloud using the synchronized volume data and the mapping information by the disaster recovery manager.

Claims (71)

1. A system comprising:

a first interface;

a second interface; and

a disaster recovery manager to

store mapping information corresponding to a container in a storage repository via the first interface, wherein the container runs on a host computer in a private cloud;

synchronize volume data associated with the container to a public cloud based on the mapping information via the second interface;

determine a failure of the container running on the private cloud; and

initiate a disaster recovery operation to deploy the container in the public cloud using the synchronized volume data and the mapping information in response to determining the failure of the container.

2. The system of claim 1 , wherein the disaster recovery manager is to:

call an external load balancer in the public cloud to create a network routing entry to direct traffic to the container deployed in the public cloud; and

update the mapping information corresponding to the container upon redirecting the traffic to the container deployed in the public cloud.

3. The system of claim 1 , further comprises a third interface in the public cloud to:

create a disaster recovery group in the public cloud; and

assign the container running on the private cloud to the disaster recovery group, wherein the mapping information for the container, corresponding to the disaster recovery group, is maintained in the public cloud.

4. The system of claim 1 , wherein the disaster recovery manager is to synchronize the volume data associated with the container to the public cloud by:

receiving and storing a container image associated with the container to an image store in the public cloud based on the mapping information;

receiving and storing the volume data associated with the container to a volume store in the public cloud based on the mapping information; and

dynamically updating changes in the volume data associated with the container to the volume store.

5. The system of claim 1 , wherein the disaster recovery manager is to initiate the disaster recovery operation by:

retrieving a container image associated with the container from an image store in the public cloud upon detecting the failure based on the mapping information;

retrieving the volume data associated with the container from a volume store in the public cloud based on the mapping information; and

deploying the container on a hardware platform or a virtual machine in the public cloud using the retrieved container image and the retrieved volume data.

6. The system of claim 5 , wherein the disaster recovery manager is to deploy the container on the hardware platform or the virtual machine in the public cloud by:

retrieving mapping information from the storage repository;

creating a raw block storage volume and mounting the raw block storage volume to the hardware platform or the virtual machine in the public cloud;

retrieving the volume data associated with the container from the volume store based on the mapping information and storing the retrieved volume data to the mounted raw block storage volume; and

deploying the container on the hardware platform or the virtual machine in the public cloud using the retrieved container image and the retrieved volume data in the mounted raw block storage volume.

7. The system of claim 1 , wherein the disaster recovery manager is to determine the failure of the container running on the private cloud by detecting a heartbeat loss from a disaster recovery agent residing in the host computer.

8. The system of claim 1 , wherein the mapping information comprises at least one of information associated with a container image, a location of the container image in the public cloud, a location of the volume data in the public cloud, and a location of the volume data in the private cloud.

9. A method comprising: generating, by a processor-based disaster recovery manager, mapping information, in a public cloud, corresponding to a container running on a private data center; synchronizing, by the processor-based disaster recovery manager, volume data associated with the container to the public cloud based on the mapping information; determining, by the processor-based disaster recovery manager, a failure of the container running on the private data center; and deploying, by the processor-based disaster recovery manager, the container in the public cloud using the synchronized volume data and the mapping information in response to the failure of the container running on the private data center.

10. The method of claim 9 , further comprising:

updating a network routing entry in a router in the private data center to redirect traffic to the container deployed in the public cloud; and

updating the mapping information corresponding to the container in the public cloud.

11. The method of claim 9 , wherein generating the mapping information comprises:

creating, via an interface of the public cloud, a disaster recovery group in the public cloud;

assigning, via the interface, the container running on the private data center to the disaster recovery group in the public cloud; and

generating the mapping information for the container in the public cloud corresponding to the disaster recovery group.

12. The method of claim 9 , wherein synchronizing volume data associated with the container to the public cloud comprises:

receiving and storing a container image associated with the container to an image store in the public cloud;

receiving and storing the volume data associated with the container to a volume store in the public cloud based on the mapping information; and

dynamically updating changes in the volume data associated with the container to the volume store in the public cloud.

13. The method of claim 9 , wherein deploying the container in the public cloud comprises:

retrieving a container image associated with the container from an image store upon detecting the failure;

retrieving the volume data associated with the container from a volume store based on the mapping information; and

deploying the container on a hardware platform or a virtual machine in the public cloud using the retrieved container image and the retrieved volume data.

14. The method of claim 9 , further comprising initiating a failback operation to deploy the container from the public cloud to the private data center, the failback operation comprising:

receiving a failback request via a disaster recovery agent in the private data center;

verifying the failback request from the private data center;

enabling to deploy the container in the private data center based on a container image and the mapping information upon successful verification;

copying the volume data associated with the container from the public cloud to the private data center; and

enabling to update a network routing entry in a router to redirect traffic to the container deployed in the private data center.

15. The method of claim 9 , wherein the mapping information comprises at least one of information associated with a container image, a location of the container image in the public cloud, a location of the volume data in the public cloud, and a location of the volume data in the private data center.

16. A non-transitory machine-readable storage medium encoded with instructions that, when executed by a processor, cause the processor to:

receive and store a container image of a container running on a private cloud to an image store in a public cloud;

synchronize volume data of the container running on the private cloud with an object storage service in the public cloud;

determine a failure of the container running on the private cloud;

initiate a disaster recovery operation to deploy the container in the public cloud using the synchronized volume data and the container image in response to the failure of the container running on the private cloud; and

update a network routing entry in a router to redirect traffic to the container deployed in the public cloud.

17. The non-transitory machine-readable storage medium of claim 16 , wherein initiating the disaster recovery operation comprises:

retrieving the container image associated with the container from the image store upon detecting the failure;

creating a raw block storage volume and mounting the raw block storage volume to a hardware platform or a virtual machine in the public cloud;

retrieving the volume data associated with the container from the object storage service and storing the retrieved volume data to the mounted raw block storage volume; and

deploying the container on the hardware platform or the virtual machine in the public cloud using the retrieved container image and the retrieved volume data.

18. The non-transitory machine-readable storage medium of claim 16 , further comprising instructions to:

receive a failback request via a disaster recovery agent in the private cloud;

verify the failback request from the private cloud;

transmit the volume data associated with the container from the public cloud to the private cloud upon successful verification; and

terminate the container running on the public cloud upon successfully transmitting the volume data.

19. The non-transitory machine-readable storage medium of claim 16 , comprising instructions to:

maintain mapping information corresponding to the container in the public cloud, wherein the mapping information comprises at least one of information associated with the container image, a location of the container image in the public cloud, a location of the volume data in the public cloud, and a location of the volume data in the private cloud.

20. The non-transitory machine-readable storage medium of claim 17 , wherein the container is deployed in the public cloud by retrieving the volume data and the container image associated with the container based on the mapping information.

Assignments (2)
CORRECTIVE ASSIGNMENT TO CORRECT THE SPELLING OF THE FIFTH INVENTORS NAME PREVIOUSLY RECORDED AT REEL: 044439 FRAME: 0591. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT. Recorded Apr 22, 2021
From: RAMAMOORTHI, BALAJI; MANICKAM, SIVA SUBRAMANIAM; GANESAN, VINNARASU; SAKTHIVEL, THAVAMANIRAJA; PRABU, SARAVANA
To: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP
Reel/Frame 056004/0292 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Dec 19, 2017
From: RAMAMOORTHI, BALAJI; MANICKAM, SIVA SUBRAMANIAM; GANESAN, VINNARASU; SAKTHIVEL, THAVAMANIRAJA; PRABHU, SARAVANA
To: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP
Reel/Frame 044439/0591 →
Continuity (1)
Related Publication 20190188094A1 · Jun 20, 2019