Thought this was impossible? IP address failover across cloud/provider networks(blog.vcider.com)
blog.vcider.com
Thought this was impossible? IP address failover across cloud/provider networks
http://blog.vcider.com/2012/04/multi-cloud-ip-address-failover-with-heartbeat-and-vcider/
3 comments
I wouldn't exactly say the title is misleading, because it still is an address failover between cloud networks. But your points about the public addresses is of course correct.
The key application here is for those who wish to establish hybrid clouds, want to "cloud burst" their enterprise capabilities, or - as the opening sentence of the article explains - about "[organizations] moving part of [their] network and server infrastructure into the cloud".
And especially for those internal enterprise applications, running an HTTP proxy is not always possible.
The key application here is for those who wish to establish hybrid clouds, want to "cloud burst" their enterprise capabilities, or - as the opening sentence of the article explains - about "[organizations] moving part of [their] network and server infrastructure into the cloud".
And especially for those internal enterprise applications, running an HTTP proxy is not always possible.
You're right. I read the article through a public-internet lens -- a difficult bias for me to shake. :) I can definitely see the value for enterprises. I do very much like that the application servers are using the same tools they would if they were neighbors in a rack.
Am I misunderstanding, or does this still have a single point of failure at the gateway machine?
In this simple example, you would have a single point of failure for the enterprise machines. But not any more than your enterprise's routers or Internet connection represent single points of failure.
However, you can have multiple gateways (and thus alternative routes). Furthermore, the IP address failover will instantly be noticeable to any other machine you have in the virtual network.
However, you can have multiple gateways (and thus alternative routes). Furthermore, the IP address failover will instantly be noticeable to any other machine you have in the virtual network.
There is still the issue of replicating content, but that's something that can be handled in a number of different ways, depending on the requirements.
This is the failover of a private IP behind a virtual network gateway. The failover happens at layer 2 using the same gratuitous ARP you might send to a local switch but over a virtual network. The resulting network has properties that might be interesting to a private network service (especially one that cannot easily be proxied) but less so for public-facing services.
If your application speaks HTTP, a health-checking proxy server like haproxy on the gateway could perform the same service.
If your application is used by the public internet, your gateway machine(s) and network(s) between the gateway and application become the weak links. The traditional fallback would be low-TTL DNS.