When the first publication was published on Habré on DRaaS and migration from VMware , organized on the basis of OpenStack, a thought was voiced in the user’s comment mikkisse : the only obvious advantage of solutions based on OpenStack is their relatively low cost compared to commercial offers . Other users (for example, AntonVirtual ) carefully (and not very) hinted that the lack of royalties would have to be compensated by paying for support that would ensure the stability of the cloud . And if so, noted by others (such as omnimod ), it is better not to experiment, but to surrender to the good old vendor . We, in turn, promised in the comments a detailed account of how exactly migration and / or DR is implemented with Hystax Acura technology in exchange for the favorable attention of mikkisse and other readers who gave us meaningful feedback. We fulfill the undertaken obligation.

DRaaS (Disaster Recovery as a Service): what is it and why?

This service is needed by most modern companies that automate business processes . If your server is flooded, the UPS burns, and a hurricane hits the city, and only the data center lights will serve as landmarks in pitch darkness , you will obviously be pleased to know that backup copies of data that you probably do will be deployed in a certain order in a cool the comfort of the server room of one of these data centers. Disaster Recovery includes both the infrastructure recovery plan (which is created jointly by the service provider and the customer company), and the backup site itself, and the recovery mechanism .





Technically, the Disaster Recovery process is also organized as a data migration service. On the side of the service provider, a backup platform is created, duplicating (but not copying!) The client's infrastructure — virtual machines, the connections between them, and network settings are copied. But the platform itself is changing. At the same time, the data and settings that are changed on the main site are also updated on the backup. Synchronization is carried out with a predetermined by the client frequency. Thus, the use of DR on OpenStack allows the client to both look at the data transfer process itself and appreciate the functionality of the OpenStack platform . It is important that while the main site continues to work normally.

')

Of course, we expect that the customer, having received a backup site at his disposal, will actively test its capabilities and, probably, at some point will come to the conclusion that it is not inferior in performance to VMware (or any other proprietary platform). ), which means it can become an alternative to the commercial platform of virtualization already existing on the client. In addition, if the cloud service company is based on OpenStack, then, obviously, the provider does not make royalties to the vendor. For the customer, this means that the cost of the final service for him will be much lower. In this scenario, the client has the opportunity to save - for less money, he gets a functioning infrastructure without having to administer it. Plus, open source solutions allow you to integrate the existing functionality of the platform with the company's own developments.



Before proceeding to the description of the phased data transfer, we note another important detail. If a customer has already acquired a data recovery service, then in order to release a backup site into a production site, he simply needs to shut down VMware. It's all. Go!

How it works: step by step

The first step is to create a DR plan.

Service provider experts examine the customer's infrastructure and, following the results, create a draft recovery plan after a failure. Further, together with the client, the plan is adjusted, taking into account the individual needs of the company. On average, the entire process of preparing a plan for an enterprise using 300 virtual machines takes about two and a half weeks. Actually, the same plan is being prepared for migration. We explore the features of the client's existing architecture: network topology, settings, communications, and application dependencies in order to fully recreate it in the same form on OpenStack.

The second step is the initial transfer of data to the cloud (full replication) and test launch of the backup site.

The client has the opportunity to make sure that the infrastructure is working properly, and only after that we consider the project agreed.

Specific example

For clarity, we will operate with specific figures. Let's say we have a virtualization platform running VMware vSphere, on which 22 virtuals are spinning. The task is to transfer data from them to the backup site in ATLEX Virtual Datacenter .



We install the agent on the main infrastructure of the client (namely, on the host where the virtual machines are to be protected). This is a Linux virtual machine, which, in fact, will replicate client virtuals - the development of our partners, the Russian startup Hystax. In fact, we give the customer a link to the file that he uploads to vSphere, after which the agent begins to work.



It runs and examines all the virtual machines around it. After a couple of minutes in the Hystax Acura interface (the so-called solution described), information about them appears, which the agent updates with a certain periodicity.



The main control of the agent occurs through the administrative panel, in which you can see the names of the replicated machines, their IP addresses, the last replication date, size, etc. Here you can, if desired, manually cancel the protection of a particular machine.





After all the necessary data has been collected, we run full replication. The time it takes to transfer all data to the cloud depends on the channel width and the size of the replicated machines. But on average, this process takes from half an hour to several hours.



Important: when we first put the agent on the infrastructure, all devices appear in the interface as unprotected. We choose which machines (all or several) we want to replicate, and run the first full replication. She, by the way, we spend at least once a month for security reasons.



Obviously, one complete replication is not enough, because the data on the main site is constantly changing. Therefore, from time to time, according to the schedule that the customer chooses, we perform incremental replication - the agent tracks all changes on the client's infrastructure and sends snapshots to the repository. You can choose interval replication or continuous - it all depends on the task and client preferences.



Until the time of claim, all replicated data lies in the cloud storage . Here the deduplication method is applied, which allows to reduce the amount of data, which means - the final cost for the client. That is, if we were given 200 terabytes, then in fact only 100 can be stored, and the customer only pays for the space actually occupied. It is more efficient to use this method if replicated machines run on the same operating system or store duplicate data - then they will be sent and saved only once.

If an accident occurs on the main infrastructure, the client (note, drumming!) Simply presses the green button, and the data is deployed at the backup site. Yes, it is really green.

Do you think that fell, then disappeared? Then we go to you!

If the client has a “falling” infrastructure, he really needs to click on the button labeled “Recover”. At the same time, he can either choose a recovery according to a DR-plan prepared in advance (if the entire infrastructure needs to be restored), or create a new plan for several cars directly in the recovery process (if several machines fail, for example, only they need to be restored). Here you can specify the date and time - to what point in time you need to restore the infrastructure.





The next process is automated - the system will automatically select the closest successful snapshot of each virtual machine in the past and “get” the data from the storage. If the client wants to restore information, say, a month ago - no problem, you can select this option in the settings.



After the virtual machines are restored at the backup site, they will receive the corresponding status in the interface. The administrator can start the virtual machine and vice versa - complete its work or delete it altogether.



This is how a data recovery service works. When migrating, one more step is added - this is the switching of the main site. After data backups are made, and the backup infrastructure is running, the customer simply disconnects the VMware virtual machines and gets direct access to the new infrastructure.

Conclusion

There are things that show - it is easier than to talk about them. Nevertheless, we tried to show you a theoretical model of data migration from VMware to OpenStack. Returning to the concept of service: moving to OpenStack allows you to get the same functionality and performance that customers value in commercial solutions, but pay only for the resources actually used (according to the pay-as-you-go model). At the same time, there is no need to torture your own IT department with the implementation of such a project, because the service provider assumes all obligations for data migration.



If the client is not so much interested in the issue of cost reduction, as the reliability of the existing infrastructure, then perhaps the ideal solution would be Disaster Recovery. The customer gets the opportunity to synchronize processes at two sites: the core virtualization platform running on a commercial platform, and the backup platform on OpenStack. In case of an accident in the data center, an external virus attack or an earthquake, you will have a ready DR plan. Pressing a single button - and all your data will unfold on the backup infrastructure with minimal downtime, and this, in turn, will save you money. In your spare time, you can, for example, test your new applications on the backup site.



If you have any questions, we will be happy to answer them in the comments.