Disaster recovery is more important than HTTPS SNI support...

Disaster recovery is more important than HTTPS SNI support...

High Availability Published on 2 mins Last updated

What would you prefer us to work on? Making sure that you get zero downtime, or reducing the amount of manual configuration required?
Here at Loadbalancer.org we've been working hard (i.e. drinking lots of coffee) and we are very relieved to announce, that v8.2.1, is now available - finally.

We are actually a bit embarrassed by this but...

We've only just got around to adding SNI matching to the web user interface. For those who don't know, SNI is an extension to the TLS protocol which enables the client to broadcast its hostname when it tries to connect to your server. This allows you to use multiple SSL certificates on a single IP. SNI is similar to name-based virtual hosting, but for HTTPS. A large number of customers told us that the existing manual configuration was a real pain, and we're very sorry it took so long to fix.

The reason for the delay is because we've been devoting most of our time to making disaster recovery as simple as possible - How so you might ask?
stuck_to_server_release2

Well, in about 3 years time when you realise that one of your load balancers has died…You will see that the fail-over to the slave has been successful - great.

But how do we recover the cluster with no down time?

Well, you simply need to install a new load balancer, and run setup from the console.
Fill in the dead load balancers old IP address and subnet + gateway.
Then you get the new option to recover all settings from the active appliance:

Now punch in the IP address and password for the active appliance, confirm, and then ALL of the original settings & SSH keys will be restored and heartbeat reloaded - WITH NO DOWNTIME.
We hope you like how simple this makes the whole recovery process.

So what other changes have we made?

HAProxy has been given a polish and is now running version 1.7 out of the box on our appliances, and Openssl and Stunnel have been updated too, running versions 1.0.1t and 5.33 respectively. We've added a whole host of new features and fixes to LBCLI (the command line interface) and exposed the functionality through the HTTP based API.

We've spent a lot of time oiling the various cogs and gears in the great Loadbalancer machine, you'll notice that the appliance now performs better than the England Football Team, which isn't exactly difficult, but you get the idea. A full announcement with a complete list of changes and fixes will be announced on the usual mailing list, and published on the support portal news section.

So what’s next?

V9.0 will get full web user interface support for complex backend configurations (multiple-VS), this should finally remove the need for 99% of manual configurations.

Check out our roadmap blog here to see what we've got planned for future releases.