New availability zone released

New availability zone released

Next week, we’re finally fulfilling a promise long overdue. We’re delivering a new availability zone for the Fuga platform. As part of the preparation of a new Fuga region in our second data center, we’ve done a lot of work on our network configuration. Part of these changes is a rename of the current region to eu-west-1 and creating two new availability zones: eu-west-1a and eu-west-1b. These will replace the current zone ams, which will be phased out.

The new zones will be made available on 23 January. On that day, we will start moving all instances from the ams zone to either of the new availability zones. This might take a couple of days. Relocation of the instances should be seamless with no impact to connectivity or services.

If you were waiting to expand your Fuga setup to make it more robust and highly available…now you can. Here’s how it works.

Why use two availability zones?

In short: high availability. During scheduled maintenance, we’ll perform the work in only one availability zone in a region at a time. If you’re running a (load balanced) second instance in a different zone, you won’t suffer any downtime.

A second scenario is unexpected problems or maintenance on a hardware node. If a host becomes unavailable, you’ll have a back-up instance running that can immediately take over. Strictly speaking, your second instance doesn’t need to be in a different zone for this, but why not benefit from both scenarios?

How to check the current zone?

You can see which availability zones your instances are in in your instance overview in Compute -> Instances.

How to launch instances across different zones?

When launching a new instance through Horizon, you can select the availability zone and host of your choice. You can add an optional parameter if you wish to launch an instance in a specific zone (and host) if you’re using the CLI tools or the Nova API.

How to really benefit?

As mentioned before, to really benefit from using multiple availability zones, you’ll want to use load balancing. If your load balancing monitor detects downtime, it will reroute all traffic to the instance in the other zone and restore the load balanced situation when connectivity has been restored.

See our tutorial on how to set it up: How to create and configure a load balancer

What will happen to the current ams zone?

After we’ve moved all workloads to the new zone, the old ams zone will be made unavailable. So, if you’ve hardcoded the ams zone in your Fuga automation, be sure to update this to either of the new zones.

Was this article helpful?


Next article:

Happy Holidays from the Fuga team!

It’s been a fantastic year for us at Fuga. Ever since launching in September 2015, we’ve managed to grow steadily throughout 2016. We are very happy with the stability and performance of the Fuga platform. One of the main goals we set ourself when we started out, was keeping up with OpenStack’s six-monthly release cycle. We never want to be more than one version behind of the most current stable release.