IP Library Granted Patent US 9,645,811
Granted Patent B2
US 9,645,811 · App. 14/242,655 · Granted May 9, 2017

Fault tolerance for a distributed computing system

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 9,645,811
App. No.
14/242,655
Granted
May 9, 2017
Kind
B2
Abstract

In one embodiment, a method detects a failure of a container in a controller node where the container includes a service being performed and isolated from other services being performed in other containers on the controller node. The controller node terminates the container including the service and determines a known state for the service. The known state is known to be operational without including a cause of the failure and the service operated from the known state saving changes to the known state during operation separately from the known state. The controller node restarts the service in a new container that replaces the terminated container where the restarted service starts from the known state without using the changes.

Claims (75)

1. A method comprising:

detecting a failure of a container, of a set of containers, in a controller node, the container executing a service being performed and isolated from at least one other service being performed in at least one other container on the controller node;

terminating, by the controller node, the container executing the service;

determining, by the controller node, a particular known state for the service, wherein the particular known state is known to be operational without including one or more changes that caused the failure, and wherein the service saves the changes to the particular known state during operation separately from the particular known state;

restarting, by the controller node, the service in a new container that replaces the terminated container, wherein the restarted service starts from the particular known state without using the changes;

wherein an orchestration service, configured to manage the set of containers, detects the failure;

wherein the orchestration service detects the failure via monitoring a communication service in which a status of the service is input; and

wherein the method is performed by at least one device including a hardware processor.

2. The method of claim 1 , wherein the particular known state comprises a full image of the service required to start the service from the new container.

3. The method of claim 1 , wherein the failure of the container is not resolved.

4. The method of claim 1 , wherein detecting comprises:

determining from a communication service that a presence of the service has been lost; and

determining the failure based on the presence being lost.

5. The method of claim 1 , wherein restarting comprises:

restarting an orchestration service instance that manages the service in the new container.

6. A method comprising:

detecting a failure of a container, of a set of containers, in a controller node, the container executing a service being performed and isolated from at least one other service being performed in at least one other container on the controller node;

terminating, by the controller node, the container executing the service;

determining, by the controller node, a particular known state for the service, wherein the particular known state is known to be operational without including one or more changes that caused the failure, and wherein the service saves the changes to the particular known state during operation separately from the particular known state;

restarting, by the controller node, the service in a new container that replaces the terminated container, wherein the restarted service starts from the particular known state without using the changes;

upon restarting with the particular known state, determining, by the service, configuration data or state data for the service from storage; and

wherein the method is performed by at least one device including a hardware processor.

7. A method comprising:

detecting a failure of a container, of a set of containers, in a controller node, the container executing a service being performed and isolated from at least one other service being performed in at least one other container on the controller node;

terminating, by the controller node, the container executing the service;

determining, by the controller node, a particular known state for the service, wherein the particular known state is known to be operational without including one or more changes that caused the failure, and wherein the service saves the changes to the particular known state during operation separately from the particular known state;

restarting, by the controller node, the service in a new container that replaces the terminated container, wherein the restarted service starts from the particular known state without using the changes;

wherein:

the particular known state is included in a file system,

the service with the failure records differences to the file system without changing the file system,

the changes are not used in restarting the service in the new container, and

the method is performed by at least one device including a hardware processor.

8. A system comprising:

at least one device including a hardware processor;

the system being configured to perform operations comprising:

detecting a failure of a container, in a set of containers, in a controller node, the container executing a service being performed and isolated from at least one other service being performed in at least one other container on the controller node;

terminating, by the controller node, the container executing the service;

determining, by the controller node, a particular known state for the service, wherein the particular known state is known to be operational without including one or more changes that caused the failure, and wherein the service saves the changes to the particular known state during operation separately from the particular known state;

restarting, by the controller node, the service in a new container that replaces the terminated container, wherein the restarted service starts from the known state without using the changes; and

wherein an orchestration service, configured to manage the set of containers, detects the failure;

wherein the orchestration service detects the failure via monitoring a communication service in which a status of the service is input.

9. The system of claim 8 , wherein the particular known state comprises a full image of the service required to start the service from the new container.

10. The system of claim 8 , wherein the failure of the container is not resolved.

11. The system of claim 8 , wherein detecting comprises:

determining from a communication service that a presence of the service has been lost; and

determining the failure based on the presence being lost.

12. The system of claim 8 , wherein restarting comprises:

restarting an orchestration service instance that manages the service in the new container.

13. A system comprising:

at least one device including a hardware processor;

The system being configured to perform operations comprising:

detecting a failure of a container, in a set of containers, in a controller node, the container executing a service being performed and isolated from at least one other service being performed in at least one other container on the controller node;

terminating, by the controller node, the container executing the service;

determining, by the controller node, a particular known state for the service, wherein the particular known state is known to be operational without including one or more changes that caused the failure, and wherein the service saves the changes to the particular known state during operation separately from the particular known state;

restarting, by the controller node, the service in a new container that replaces the terminated container, wherein the restarted service starts from the particular known state without using the changes; and

upon restarting with the particular known state, determining, by the service, configuration data or state data for the service from storage.

14. A system comprising:

at least one device including a hardware processor;

the system being configured to perform operations comprising:

detecting a failure of a container, in a set of containers, in a controller node, the container executing a service being performed and isolated from at least one other service being performed in at least one other container on the controller node;

terminating, by the controller node, the container executing the service;

determining, by the controller node, a particular known state for the service, wherein the particular known state is known to be operational without including one or more changes that caused the failure, and wherein the service saves the changes to the particular known state during operation separately from the particular known state;

restarting, by the controller node, the service in a new container that replaces the terminated container, wherein the restarted service starts from the particular known state without using the changes;

wherein:

the particular known state is included in a file system,

the service with the failure records differences to the file system without changing the file system, and

the changes are not used in restarting the service in the new container.

15. A non-transitory computer-readable storage medium containing instructions, that when executed, control a computer system to be configured for:

detecting a failure of a container, in a set of containers, in a controller node, the container executing a service being performed and isolated from at least one other service being performed in at least one other container on the controller node;

terminating, by the controller node, the container executing the service;

determining, by the controller node, a particular known state for the service, wherein the particular known state is known to be operational without including one or more changes that caused the failure, and wherein the service saves changes to the particular known state during operation separately from the particular known state;

restarting, by the controller node, the service in a new container that replaces the terminated container, wherein the restarted service starts from the particular known state without using the changes; and

wherein an orchestration service, configured to manage the set of containers, detects the failure;

wherein the orchestration service detects the failure via monitoring a communication service in which a status of the service is input.

16. The non-transitory computer-readable storage medium of claim 15 , wherein the particular known state comprises a full image of the service required to start the service from the new container.

Assignments (5)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jan 26, 2018
From: OC ACQUISITION LLC
To: ORACLE INTERNATIONAL CORPORATION
Reel/Frame 044743/0466 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded May 27, 2015
From: NEBULA, INC.
To: OC ACQUISITION LLC
Reel/Frame 035721/0158 →
RELEASE OF SECURITY INTEREST Recorded May 27, 2015
From: SILICON VALLEY BANK
To: NEBULA, INC.
Reel/Frame 035725/0872 →
SECURITY INTEREST Recorded Mar 24, 2015
From: NEBULA, INC.
To: SILICON VALLEY BANK
Reel/Frame 035241/0914 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jul 17, 2014
From: CARLEN, DEVIN; HECK, JOE; SZILAGYI, MIKE; GIUS, MARK; CARUSO, KEN; MANKIN, YONA BENJAMIN
To: NEBULA, INC.
Reel/Frame 033338/0249 →