Redundant storage solution

1. A method of switching between a first node communicatively coupled to a virtual cloud controller and a second node coupled to the first node, each located within a virtual cloud, the nodes each comprising pools and volumes, the method comprising:

determining, at the second node, that the first node has experienced a failure to send or receive data;

determining the second node has proper connectivity;

fencing off the first node;

creating a new local route table by the second node;

flushing the previous local route table;

transmitting a request to a virtual cloud controller to update a virtual internet protocol address to point to the second node; and

receiving, at the second node, data via the updated virtual internet protocol address.

2. The method according to claim 1 , further comprising:

initiating, at the first node, a boot sequence;

querying a third party witness for a current role of the first node;

determine the current role of the first node; and

begin processing at the first node based on the current role.

3. The method according to claim 2 , wherein the third party witness is a flat file including one or more source and target nodes, associated roles of the one or more source and target nodes and timestamps.

4. The method according to claim 2 , wherein the third party witness is a timestamp representing a last takeover time of the first node.

5. The method according to claim 2 , wherein a timestamp of the third party witness is compared at the second node to verify status as the primary node by determining the timestamp of the third party witness matches a locally stored timestamp on the second node.

6. The method according to claim 2 , wherein a value of the third party witness is stored within a shared object or file t accessible by the first node and the second node.

7. The method according to claim 1 , wherein the third party witness is a low processor virtual server configured to store, transmit and receive the roles associated with the one or more source and target nodes and timestamps.

8. The method according to claim 1 , further comprising automatically discovering network information present on both nodes necessary to achieve communication between both nodes, including:

automatically discovering a plurality of candidate nodes in the virtual cloud;

receiving an indication of a first node and a second node from the plurality of candidate nodes; and

configuring one or more route tables and virtual internet protocol address to configure the first node as a source and the second node as a target.

9. The method according to claim 1 , further comprising:

configuring a third node to communicatively couple to the second node, wherein the third node replaces the first node; and

updating the third node with the pools and volumes.

10. The method according to claim 1 , further comprising automatically discovering information present on both nodes necessary to achieve replication, including at least determining which storage pools and volumes need to be replicated, the determination including:

automatically discovering storage pools on the nodes that have a same name;

automatically discovering the volumes in each such storage pool;

automatically configuring tasks necessary for each volume to be replicated;

automatically determining whether a full back-up or synchronization from the first node to the second node of all storage pools and volumes in the source node is necessary; and

upon such determination, executing the full back-up or synchronization from the first node to the second node of all storage pools and volumes in the source node.

11. The method according to claim 1 , wherein the determining that the first node has experienced the failure to send or receive data is performed at a high availability controller independent of the second node.

12. The method according to claim 1 , wherein fencing off the first node further comprising:

sending, from the second node to the first node, a shut down command.

13. The method according to claim 1 , wherein fencing off the first node further comprising:

powering off a virtual machine on which the first node is operating.

14. A controller for switching between a first node communicatively coupled to a virtual cloud controller and a second node coupled to the first node, each located within a virtual cloud, the first and the second node each comprising pools and volumes, the controller comprising:

a processor; and

a memory storing instructions, which when executed by the processor, causes the processor to:

determine that the first node has experienced a failure to send or receive data;

determine the second node has proper connectivity;

fence off the first node;

create a new local route table;

flush the previous local route table;

transmit a request to a virtual cloud controller to update a virtual internet protocol address to point to the second node; and

receive at the second node data via the updated virtual internet protocol address.

15. The controller according to claim 14 , further comprising instructions, which when executed by the processor, causes the processor to:

initiate, at the first node, a boot sequence;

query a third party witness for a current role of the first node;

determine the current role of the first node; and

begin processing at the first node based on the current role.

16. The controller according to claim 15 , wherein the third party witness is a flat file including one or more source and target nodes, associated roles of the one or more source and target nodes and timestamps.

17. The controller according to claim 15 , wherein the third party witness is a timestamp representing a last takeover time of the first node.

18. The controller according to claim 15 , wherein a timestamp of the third party witness is compared at the second node to verify status as the primary node by determining the timestamp of the third party witness matches a locally stored timestamp on the second node.

19. The controller according to claim 15 , wherein a value of the third party witness is stored within a shared object or file t accessible by the first node and the second node.

20. The controller according to claim 14 , wherein the third party witness is a low processor virtual server configured to store, transmit and receive the roles associated with the one or more source and target nodes and timestamps.