DISASTER RECOVERY OF CONTAINERS

• US 20190188094A1
• Filed: 12/19/2017
• Published: 06/20/2019
• Est. Priority Date: 12/19/2017
• Status: Active Grant

• Current Assignee: Hewlett Packard Enterprise Development LP (Hewlett-Packard Enterprise Company)
• Original Assignee: Hewlett Packard Enterprise Development LP (Hewlett-Packard Enterprise Company)
• Inventors: Ramamoorthi, Balaji, Manickam, Siva Subramaniam, Ganesan, Vinnarasu, Sakthivel, Thavamaniraja, Prabu, Saravana
• Granted Patent: US 10,489,255 B2
• Time in Patent Office: Days
• CPC Class Codes: G06F 11/1662 the resynchronized component or unit being a persistent storage device re-synchronization of failed mirror storage G06F11/2082; rebuild or reconstruction of parity RAID storage G06F11/1008
• CPC Class Codes: G06F 11/2023 Failover techniques
• CPC Class Codes: G06F 11/203 using migration
• CPC Class Codes: G06F 2201/805 Real-time
• CPC Class Codes: G06F 2201/82 Solving problems relating to consistency

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

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 disaster recovery manager, volume data associated with the container to the public cloud based on the mapping information;

determining, by the disaster recovery manager, a failure of the container running on the private data center; and

deploying, by the 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.