For the vast majority of companies, having two or more of their own sites is still an unaffordable luxury. And what to do with ensuring the continuity of the provision of IT services in this situation? The conclusion is obvious: if for some reason it is not possible to use the public cloud as the main site - it can be successfully used as a backup!
')
With the development of cloud technologies, an increasing number of organizations are ready to abandon their own infrastructure in favor of high-available services for
hosting virtual machines in the public cloud .
However, there are situations arising from the specifics of the companyâs activities, the presence of projects already in place to
build a private cloud , specific performance, security, etc. requirements that may be temporary, but do not allow using the public cloud to host their IT services.
Is there a technical possibility to place a backup site in a public cloud? What difficulties will you have to face in project implementation? Such questions increasingly arise both in the open spaces of the network and among potential consumers of cloud services. Service providers add questions about multi-tenancy, resource efficiency, compatibility, and network infrastructure requirements.
Classic DRS Solutions
Classic solutions for creating backup sites or Data Recovery sites have always amazed the man in the street with its complexity. In the first place, this concerned data replication, which was to be carried out by means of storage systems, which, in turn:
ďź
- greatly raised the bar for storage requirements,
- impose restrictions on the choice of storage vendors to ensure compatibility,
- required the purchase of expensive licenses.
Yes, and the software itself to manage the backup and recovery had (and has at the moment) a significant cost. A vivid example of such a solution is VMware Site Recovery Manager. However, technology does not stand still, and increasing competition in the market forces manufacturers to open new opportunities to solve old problems.
New approach - replication at the hypervisor level
One of these new features was
VMware vSphere Replication technology, which debuted as part of VMware Site Recovery Manager version 5.0, and then included in the vSphere 5.1 virtualization platform,
free of charge and in almost all editions!
This technology has provided the ability to replicate data between sites
at the hypervisor level , without using the special storage capabilities. And almost immediately there was an interest of companies with their own virtual infrastructures based on vSphere, to the potential to organize a backup copy of their information systems with âlittle bloodâ.
But the decoupling from the storage system did not only reduce the cost and simplify the replication systems, it also provided an important opportunity for replication between the âuncoordinatedâ across the storage systems and independently managed infrastructures. And, in fact, opened the way to a simple and effective implementation of the backup platform in the cloud.
VSphere Replication technology
The vSphere Replication technology from the user's point of view is very simple. Changes made to the virtual machine disks on the main site are monitored by the hypervisor, and then synchronized with the backup site in accordance with the specified RPO (Recovery point objective) policies. In this case, the synchronization is managed by the virtual appliance virtual machines of the VR Appliance located in both sites, and the data between the sites is transferred from the hypervisor on the primary site to the VR Appliance on the backup.
At the same time, this technology is available to both ordinary users of the vSphere platform for organizing data replication with manual control, and as part of the Site Recovery Manager, which allows flexible management of the failover and giveback process, with appropriate automated network reconfiguration, periodic non-destructive testing, and more .P.
Using vSphere Replication in practice
When another client approached us with a proposal to organize a backup site, less than a month had passed since vSphere 5.1 was released. But almost immediately, this technology of replication became the main option considered in this project.
Using vSphere as a virtualization platform on both sides, differences in the used storage systems all determined the choice of replication technology, and the lack of business need to implement automatic failover made it possible to avoid the extra cost of using SRM.
The first stage of the project was the formation and implementation of a network diagram that ensures the secure and fast transfer of replicated data over dedicated channels, and in the case of a failover, a painless transition of users to work with a backup site.
The channels were organized on the basis of a provider who already provided the client with services for merging branches based on a âvirtual switchâ, to which a new link to the service provider was added, to provide routing and âintegrationâ of the reserve site into the existing infrastructure of the customer.
When replication is functioning (direct or reverse) in such a scheme, traffic is routed to the service providerâs site or clientâs headquarters using routers; in the event of a failover, client gateways change to the clientâs server networks in which virtual machines are located. Thus, the entire infrastructure is working at the site of the service provider without reconfiguring the network on the virtual machines.
The second stage of the project was the configuration and testing of the vSphere Replication itself in relation to this task. It must be said that the technology, which in fact has already experienced its second release, is successfully operating out of the box, in standard configurations. However, the specifics of this implementation â independent infrastructures on both sides of the replication âlinkâ, the need to differentiate users' rights to the service provider's infrastructure â required considerable time to tinker with the settings and even make some changes in the infrastructure to enable the previously unused technology to function.
During testing, attention was paid not only to functional testing of the circuit, but also to load testing on real data â it was necessary to ensure that the RPO was maintained at the selected channel width. As a result, it was decided to expand the previously configured 100Mbps channel to 1Gbps to ensure the replication rate margin when conducting regular maintenance operations on client servers â for example, reindexing and database rebuilding, generating an increased amount of changes.
The third and final stage of the project was the initial replication of more than 10TB of data to the service provider's site and the launch of the system for industrial use. At the same time, in order to conduct periodic testing of the possibility of restoring the infrastructure, an additional routing scheme was created, in which only the artificial user group performs the work with the infrastructure raised in the private network located at the service providerâs infrastructure.
Conclusion
Is it possible to
organize a backup site in the cloud now?
The principal answer is yes, it is possible.
Customers still have to reckon with some assumptions - with incomplete compliance of such solutions with the ideology of âcloudinessâ - for example, with insufficient elasticity and the need to use the service providerâs support service instead of self-service interfaces in some cases. Service providers, in turn, have to reckon with the limited applicability of technologies in a multi-tenant environment, while there are still restrictions on the compatibility of various virtualization platforms.
However, the world does not stand still, and the first project is usually followed by new ones, and with the support of vendors, I am sure that the practice of organizing backup sites in the cloud will soon become ubiquitous.