One of the young players in the Disaster Recovery solutions market is Hystax, a Russian startup in 2016. Since the topic of disaster recovery is very popular and the market is extremely competitive, the startup decided to focus on migration between different cloud infrastructures. A product that allows you to organize a simple and quick migration to the cloud would be very useful for Onlanta's customers - users . That's how I got to know Hystax and started testing its features. And what came of it, I will tell in this article.
The main feature of Hystax is its wide functionality to support various virtualization platforms, guest OS and cloud services, which makes it possible to move your workloads from anywhere and anywhere.
This allows you to create not only DR solutions to improve the fault tolerance of services, but also quickly, flexibly migrate resources between different sites and hyperscalers to increase cost savings and select the best solution for a particular service at the moment. In addition to the platforms listed in the title picture, the company also actively cooperates with Russian cloud providers: Yandex.Cloud, CROC Cloud Services, Mail.ru and many others. It is also worth noting that in 2020 the company opened an R&D center located in Skolkovo.
The choice of one solution by a large number of players on the market indicates a good pricing policy and high applicability of the product, which we decided to test in practice.
So, our test task will consist of migrating from my VMware test site and physical machines to the provider's site also running VMware. Yes, there are many solutions that can implement such a migration, but we consider Hystax as a universal tool, and testing the migration in all possible combinations is simply an unrealistic task. Yes, and the Oncloud.ru cloud is built specifically on VMware, so this platform, as a target, interests us to a greater extent. Next, I will describe the basic principle of operation, which as a whole does not depend on the platform, and VMware can be replaced from any side with a platform from another vendor.
The first step is to deploy Hystax Acura, which is the system's control panel.
It expands from the template. For some reason, in our case, it was not entirely correct and instead of the recommended 8CPU, 16Gb was deployed with half the resources. Therefore, you must not forget to change them, otherwise the infrastructure inside the VM, on which everything is built, simply will not start with containers and the portal will be unavailable. IN the required resources are described in detail, as well as ports for all system components.
And there were also difficulties with setting the IP address through the template, so we changed it from the console. After that, you can go to the admin web interface and complete the initial configuration wizard.
Endpoint - IP or FQDN of our vCenter.
Login and Password - it's clear here.
Target ESXi hostname is one of the hosts in our cluster that will be replicated to.
Target datastore is one of the datastores of our cluster to which replication will be performed.
Hystax Acura Control Panel Public IP - the address where the control panel will be available.
A little clarification on the host and datastore is required. The fact is that Hystax replication works at the host and datastore levels. Next, I will tell you how you can change the host and datastore for the tenant, but the problem is different. Hystax does not support resource pooling, i.e. the replica will always happen to the root of the cluster (at the time of writing this material, the guys from Hystax released an updated version, where they quickly implemented my feature request regarding support for resource pools). Also vCloud Director is not supported, ie. if, as in my case, the tenant does not have admin rights to the entire cluster, but only to a specific resource pool, and we have given access to Hystax, then he will be able to independently replicate and run these VMs, but he will not be able to see them in the VMware infrastructure , to which he has access and, accordingly, further manage virtual machines. The cluster administrator needs to move the VM to the correct resource pool or import it into vCloud Director.
Why do I focus so much on these moments? Because, as far as I understand the concept of the product, the customer should be able to independently implement any migration or DR using the Acura panel. But so far, VMware support is slightly behind the level of support for the same OpenStack, where such mechanisms have already been implemented.
But back to deployment. First of all, after the initial setup of the panel, we need to create the first tenant in our system.
All the fields here are clear, I will only tell you about the Cloud field. We already have a "default" cloud that we created during the initial configuration. But if we want to be able to put each tenant on its own datastore and in its own resource pool, we can implement this by creating separate clouds for each of our customers.
In the form of adding a new cloud, we specify the same parameters as during the initial configuration (we can even use the same host), specify the datastore required for a particular customer, and now in the additional parameters we can already individually specify the required pool resource {"resource_pool" :"YOUR_POOL_NAME"}
As you may have noticed, in the form of creating a tenant there is nothing about the allocation of resources or some kind of quota - there is nothing of this in the system. You cannot limit the tenant in the number of simultaneous replicas, the number of machines for replication, or by any other parameters. So, we have created the first tenant. Now there is a not entirely logical, but mandatory thing - installing a Cloud agent. It is illogical, because the agent is downloaded on the page of a specific customer.
At the same time, it is not tied to the created tenant, and all our customers will work through it (or after several, if we deploy them). One agent supports 10 simultaneous sessions. One session counts as one car. It doesn't matter how many disks it has. To date, there is no mechanism for scaling agents in Acura itself for VMware. There is one more unpleasant moment - we are not able to look at the "utilization" of this agent from the Acura panel in order to conclude whether we need to deploy more or the current installation is enough. As a result, the stand looks like this:
The next step to access our customer's portal is to create an account (and first, also a role that will be applied to this user).
Now our customer can use the portal independently. All he needs to do is download agents from the portal and install them on his side. There are three types of agents: Linux, Windows, and VMware.
The first two are put on physics or on virtual machines on any non-VMware hypervisor. There is no additional configuration required here, the agent downloads and already knows where to knock, and literally in a minute the car will be visible in the Acura panel. With the VMware agent, the situation is a little more complicated. The problem is that Agent for VMware is also downloaded from the portal already prepared and having the necessary configuration. But the VMware agent, in addition to knowing about our Acura portal, also needs to know about the virtualization system on which it will be deployed.
Actually, the system will ask us to specify this data when downloading the VMware agent for the first time. The problem is that in our age of universal love for security, not everyone will want to indicate their admin password on someone else's portal, which is quite understandable. From the inside, after deployment, the agent cannot be configured in any way (you can only change its network settings). Here I foresee difficulties with especially cautious customers.
So, after installing the agents, we can go back to the Acura panel and see all of our cars.
Since I have been working with the system for more than a day, I have machines in various states. All of them are in the Default group, but it is possible to create separate groups and transfer machines to them, as you need. This does not affect anything - only the logical representation of the data and their grouping for more convenient work. The first and most important thing we need to do after that is to start the migration process. We can do this both forcibly manually, and set up a schedule, including in bulk for all machines at once.
Let me remind you that Hystax was positioned as a product for migration. Therefore, it is not surprising that in order to run our replicated machines, we need to create a DR plan. You can create a plan for machines that are already in the Synced state. You can generate both for one specific VM, and for all machines at once.
The set of parameters when generating a DR plan will differ depending on the infrastructure to which you will be migrating. A minimal set of options is available for a VMware environment. Re-IP for machines is also not supported. In this regard, we are interested in the following points: in the description of the VM, the “subnet” parameter: “VMNetwork”, where we bind the VM to a specific network in the cluster. Rank - relevant when migrating several VMs, determines the order in which they are launched. Flavor - describes the configuration of the VM, in this case - 1CPU, 2GB RAM. In the subnets section, we define that "subnet": "VMNetwork" is associated with the "VM Network" of VMware.
When creating a DR plan, there is no way to “split” disks across different datastores. They will be located on the same datastore that was defined for this client cloud, and if you have disks of different classes, this may cause some difficulties when starting the machine, and after starting and “separating” the VM from Hystax, it will also require a separate migration disks to the required datastores. Then we just have to run our DR plan and wait for our cars to rise. The P2V/V2V conversion process also takes time. On my largest 100GB test machine with three disks, this took a maximum of 10 minutes.
After that, you should check the running VM, services on it, data consistency and other checks.
We then have two options:
- Delete - delete a running DR plan. This action will simply shut down the running VM. These replicas are not going anywhere.
- Detach - tear off the replicated car from Acura, i.e. actually complete the migration process.
Advantages of the solution:
- ease of installation and configuration both on the client side and on the provider side;
- ease of setting up migration, creating a DR plan and launching replicas;
- support and developers respond quite quickly to the problems found and fix them with platform or agent updates.
Cons
- Insufficient Vmware support.
- The absence of any quota for tenants from the platform.
I also made a Feature Request, which we handed over to the vendor:
- usage monitoring and deployment from the Acura Management Console for Cloud Agents;
- availability of quotas for tenants;
- the ability to limit the number of simultaneous replications and speed for each tenant;
- support for VMware vCloud Director;
- support for resource pools (was implemented during testing);
- the ability to configure the VMware agent from the side of the agent itself, without entering credentials from the client infrastructure in the Acura panel;
- "Visualization" of the process of starting a VM when starting a DR plan.
The only thing that caused me big complaints was the documentation. I don't really like "black boxes" and prefer when there is detailed documentation on how the product works inside. And if for AWS and OpenStack the product is described even more or less, then for VMware there is very little documentation.
There is an Installation Guide that describes only the deployment of the Acura panel, and where there is not a word about the need for a Cloud agent. There is a full set of specifications for the product, which is good. There is documentation that describes the setup "from and to" using AWS and OpenStack as an example (although it reminds me more of a blog post), and there is a very small Knowledge Base.
In general, this is not quite the documentation format that I am used to, say, from larger vendors, so I was not entirely comfortable. At the same time, I did not find answers about some of the nuances of the system’s operation “inside” in this documentation - I had to clarify a lot of questions with technical support, and this rather dragged out the process of deploying the stand and testing.
Summing up, I can say that in general I liked the product and the company's approach to the implementation of the task. Yes, there are flaws, there is a really critical lack of functionality (in conjunction with VMware). It can be seen that, first of all, the company still focuses on public clouds, in particular AWS, and for some this will be enough. Having such a simple and convenient product today, when many companies choose a multi-cloud strategy, is extremely important. Given the much lower price compared to competitors, this makes the product extremely attractive.
We are looking for a team . Maybe it's you?
Source: habr.com