News

How you can increase availability using Floating IPs

It will happen sooner or later: a process crashes, a limit is reached or there is maintenance work to be done. Therefore, many sysadmins are operating the same service on several servers and change DNS records when needed in order to move requests from one server to another. Even with a short TTL this causes additional overhead or even service interruptions – and it is another source of errors and subsequent problems.

You can move our new Floating IPs between your virtual servers at will; a new server can transparently take all requests giving you time to update, restart, scale or debug the previously active server.

The example of keepalived shows how easy it is to achieve high-availability: Two servers periodically check the state of their respective counterpart. When a problem occurs on the active server, the standby server automatically takes over by assigning itself the Floating IP using our API. Of course, you can also assign Floating IPs to a different server manually by using our cloud control panel.

Update: If you run your servers on Ubuntu 18.04 or 20.04, please also see the revised example of keepalived.

Ideally, you should combine Floating IPs with our Anti-Affinity feature to achieve the highest level of availability. This ensures that two servers, that can cover for each other, always run on separate physical machines. Even though we already have redundancy in place on many different levels, by doing so you can further reduce the risk of a hardware failure.

Which further benefits Floating IPs offer

Even if you do not plan to dynamically move IP addresses between servers, you can still benefit from the new Floating IPs: You now have the possibility to add additional IP addresses to your servers as needed. By adding up to five additional IPv4 and IPv6 addresses you can separate services or customers from each other without having to create or maintain separate servers.

Since Floating IPs are not hard-wired to a virtual server, they will be retained in your user account when you delete the server. This prevents your "Service IP" from being lost when replacing servers – given, of course, that your customers are communicating with this Floating IP exclusively.

What happens in the background

From a technical point of view, each Floating IP is representing a separate, small IP range – hence the netmask "/128", "/32" or "255.255.255.255" respectively. When you create a Floating IP or assign it to a new server, our routers receive corresponding instructions: Traffic directed to the Floating IP is to be sent immediately to that server. These instructions are being processed via a separate, redundant setup consisting of two ExaBGP speakers, which communicate with our routers via multiple BGP sessions.

At the SwiNOG meeting in Berne, André Keller from VSHN AG and our CEO Manuel Schweizer presented more detailed background information on this particular approach; the slides can be found at http://www.swinog.ch/meetings/swinog30/. As usual, we hid the technical details behind a self-explanatory user interface – our cloud control panel. To use Floating IPs via API you can find all the needed information in the API documentation at https://www.cloudscale.ch/en/api/v1.

Let it float!
Your cloudscale.ch team