Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
DETECTING NETWORK PARTITIONS IN CLOUD
Document Type and Number:
WIPO Patent Application WO/2019/158979
Kind Code:
A1
Abstract:
We can consider the cloud as a undirected graph of nodes as there are bi-directional links between any nodes in the cloud. We perform a depth-first search over the graph. As each traversal starts, we create a new component for the graph. All nodes reached during the traversal belong to that component. The number of traversals done during the depth-first search is the number of components in the graph. After this we list to the user on a graphical dashboard all possible links to connect all the connected components of the graph so that every node in the graph is reachable to every other node. The user then selects one of the optional links to connect two connected components in the graph and continue to select links for other pair of connected components till all nodes are connected to each other.

Inventors:
SHARMA PRATIK (IN)
Application Number:
PCT/IB2018/050962
Publication Date:
August 22, 2019
Filing Date:
February 16, 2018
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
SHARMA PRATIK (IN)
International Classes:
G06Q50/00; G06F15/16; H04L29/06
Domestic Patent References:
WO2017136144A12017-08-10
Foreign References:
US20050157659A12005-07-21
Download PDF:
Claims:
Claims

Following is the claim for this invention l. In this invention we consider a set of nodes interconnected to each other as part of our cloud setup. After all the nodes in the cloud have finished booting up, we look out for network partitions or connected components of the cloud. We can consider the cloud as a undirected graph of nodes (where nodes here are virtual machines) as there are bi-directional links between any nodes in the cloud. We perform a depth-first search over the graph. As each traversal starts, we create a new component for the graph. All nodes reached during the traversal belong to that component. The number of traversals done during the depth-first search is the number of components in the graph. After this we list to the user on a graphical dashboard all possible links to connect all the connected components of the graph so that every node in the graph is reachable to every other node. The user then selects one of the optional links to connect two connected components in the graph and we trigger a command for the two nodes in two different connected components of the graph to turn on the interface and have an active link between the two nodes. If there is a link failure or no physical link between two nodes then user can select other optional links to connect the two connected components of the graph or if all options are exhausted and there is no possible connection between the two connected components in the graph then a high severity alarm is raised to the user to manually activate a link between the two connected components of the graph. The above procedure is repeated till all connected components are reachable to each other and only then we start serving the client connection requests. Also periodically we monitor the active links connecting the nodes in the cloud and if any link goes down we again retry with different optional links or raise a high severity alarm notifying the user if the above is not possible. The above novel technique of handling network partitions in the cloud is the claim for this invention.

Description:
Detecting Network Partitions in Cloud

In this invention we consider a set of nodes interconnected to each other as part of our cloud setup. After all the nodes in the cloud have finished booting up, we look out for network partitions or connected components of the cloud. We can consider the cloud as a undirected graph of nodes (where nodes here are virtual machines) as there are bi-directional links between any nodes in the cloud. We perform a depth-first search over the graph. As each traversal starts, we create a new component for the graph. All nodes reached during the traversal belong to that component. The number of traversals done during the depth-first search is the number of components in the graph. After this we list to the user on a graphical dashboard all possible links to connect all the connected components of the graph so that every node in the graph is reachable to every other node. The user then selects one of the optional links to connect two connected components in the graph and we trigger a command for the two nodes in two different connected components of the graph to turn on the interface and have an active link between the two nodes. If there is a link failure or no physical link between two nodes then user can select other optional links to connect the two connected components of the graph or if all options are exhausted and there is no possible connection between the two connected components in the graph then a high severity alarm is raised to the user to manually activate a link between the two connected components of the graph. The above procedure is repeated till all connected components are reachable to each other and only then we start serving the client connection requests. Also periodically we monitor the active links connecting the nodes in the cloud and if any link goes down we again retry with different optional links or raise a high severity alarm notifying the user if the above is not possible.