Devblog #1 - XO Proxy
We are currently developing Xen Orchestra proxies, a tool that will make your distant XenServer and XCP-ng backups easier and faster.
In this new series of blogposts, we will introduce some of the major upcoming features from our development team perspective. In this first Devblog, we will talk about XO proxy, also known as Backup Proxy, one of the most requested features for Xen Orchestra. Our beta version for these proxies should be released at the end of May.
Backup today
When created, Xen Orchestra was designed to be deployed and used as a central management tool. That's still the case, and today, more and more people are using Xen Orchestra to manage distant locations or datacenters. This centralized model is a strength because you have only one UI to rule all your XenServer or XCP-ng hosts!
All our backup features work in a similar way: Xen Orchestra is performing a request to the Xen API, which then will listen to be streamed from XO itself. Indeed, XAPI isn't able to push data, it's only working via a pull model. So XO will fetch (pull) this data, and push it to the remote destination. In other words, a stream will flow from the host, through XO and finally to the remote.
This is a really efficient and secure way to proceed, as long as your hosts, your Xen Orchestra appliance and your remote are all in the same location.
However, when you are managing multiple sites, in different locations, using only one Xen Orchestra instance, it won't be optimal in terms of network traffic for your backup. Indeed, all the backups are streamed through Xen Orchestra! So you'll have a "back and forth" stream between your 2 sites (A and B) despite the "remote" also being near the host on the B side too: this will consume time and bandwidth.
XO proxy
This is where proxies enter the spotlight. Backup proxies are intended to provide the ability to keep backup streams in a remote site instead of going back and forth from your distant site to your XOA site.
What does the proxy look like?
Xen Orchestra Proxy will be an appliance by itself, a "lighter Xen Orchestra" you could say. Therefore, it will be a VM created from your main Xen Orchestra appliance and deployed in your distant pool. Once deployed, you will have the ability to add remotes to the proxy and to select the proxy in your backup job options during a backup job creation.
What we are doing
In XO proxy, we are using part of the existing code in Xen Orchestra. This is an opportunity for us to improve and make it stronger. This code will benefit not only the proxies, but also our classic backup code as well.
On the other hand, Backup through proxies is just the first step in what we want to achieve with proxies, other things may benefit from the proxy appliance as well. As an example, we could also use them to improve the patching system in Xen Orchestra or even spread some load to manage very large and distributed infrastructures.
When developing XO proxy, these are the things we are already thinking about, in order to create a solution that will be able to evolve in the future without needing a complete rewrite.
We are also investigating a solution to be able to convert a current Xen Orchestra Appliance into an XO proxy. This way, we would like to provide people currently using multiple XO appliances a way to convert their current job instead of recreating it from scratch.
When will XO proxies be available
The solution is currently in its final development phase. We are expecting a public beta available at the end of May. If you are interested in this beta, please subscribe via this form and we will contact you as soon as we have more details about the best way to proceed.