{"id":96767,"date":"2020-10-14T14:43:02","date_gmt":"2020-10-14T12:43:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/hystax-cloud-migration-skachem-po-oblakam"},"modified":"2020-10-14T14:43:02","modified_gmt":"2020-10-14T12:43:02","slug":"hystax-cloud-migration-skachem-po-oblakam","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/hystax-cloud-migration-skachem-po-oblakam","title":{"rendered":"Hystax Cloud Migration: jumping through the clouds","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

One of the young players in the Disaster Recovery solutions market is Hystax \u2013 a Russian startup founded in 2016. Given the high popularity of disaster recovery solutions and the intense competition in the market, the startup decided to focus on migration between various cloud infrastructures. A product that enables simple and quick cloud migration would be very beneficial for the clients of \"Onlanta\" \u2013 the users. Oncloud.ru<\/a><\/noindex>. That's how I got acquainted with Hystax and started testing its capabilities. What came out of this, I will share in this article.<\/p>\n

\"Hystax<\/a><\/noindex>
\nThe main feature of Hystax is its broad functionality for supporting various virtualization platforms, guest operating systems, and cloud services, which enables you to transfer your workloads from anywhere to anywhere.<\/p>\n

This allows not only to create DR solutions for increasing the resilience of services but also to quickly and flexibly migrate resources between various sites and hyperscalers for cost efficiency and to choose the best solution for any service at a given moment. In addition to the platforms listed in the header image, the company also actively collaborates with Russian cloud providers: Yandex.Cloud, KROK \"Cloud Services\", Mail.ru, and many others. It is also worth noting that in 2020, the company established an R&D center located in Skolkovo.\u00a0<\/p>\n

The choice of a single solution by many players in the market indicates a good pricing policy and high applicability of the product, which we decided to verify in practice.<\/p>\n

So, our testing task will consist of migrating from my test VMware environment and physical machines to the provider's site also running VMware. Yes, there are many solutions that can carry out such migration, but we consider Hystax as a universal tool, and testing migration in all possible combinations is simply an unrealistic task. Moreover, the Oncloud.ru cloud is built on VMware, hence this platform is of particular interest to us as a target. Next, I'll describe the main principle of operation, which is generally independent of the platform, and VMware can be replaced on any side by a platform from another vendor.\u00a0<\/p>\n

At the first stage, it is necessary to deploy Hystax Acura, which serves as the management panel for the system.<\/p>\n

\"Hystax<\/a><\/noindex>
\nIt is deployed from a template. For some reason, in our case, it was not quite correct and instead of the recommended 8CPU, 16Gb, it deployed with half the resources. Therefore, do not forget to change them, otherwise the containers in the infrastructure within the VM, on which everything is built, simply will not start and the portal will be unavailable. In Deployment requirements<\/a><\/noindex> the required resources as well as the ports for all system components are detailed.\u00a0<\/p>\n

And we also encountered difficulties assigning the IP address through the template, so we changed it from the console. After that, you can go to the web interface of the admin panel and fill out the initial configuration wizard.\u00a0<\/p>\n

\"Hystax<\/a><\/noindex>
\n\"Hystax<\/a><\/noindex>
\nEndpoint \u2013 the IP or FQDN of our vCenter.\u00a0
\nLogin and Password \u2013 this is straightforward.\u00a0
\nTarget ESXi hostname \u2013 one of the hosts in our cluster where replication will take place.\u00a0
\nTarget datastore \u2013 one of the datastores in our cluster where replication will occur.
\nHystax Acura Control Panel Public IP \u2013 the address through which the control panel will be accessible.<\/p>\n

A small clarification about the host and datastore is required. The thing is, Hystax replication works at the host and datastore level. I will explain how to change the host and datastore for the tenant, but the problem lies elsewhere. Hystax does not support working with resource pools, i.e., replication will always occur at the root of the cluster (at the time of writing this material, the folks at Hystax released an updated version where they quickly implemented my feature request regarding support for resource pools). It also does not support vCloud Director, i.e., if, as in my case, the tenant does not have admin rights to the entire cluster, only to a specific resource pool, and we granted access to Hystax, then they will be able to replicate and start these VMs independently, but they will not be able to see them in the VMware infrastructure to which they have access and, accordingly, cannot further manage the virtual machines. It is necessary for the cluster administrator to move the VM to the required resource pool or import it into vCloud Director.<\/p>\n

Why do I emphasize these points? Because, as I understand the product concept, the customer should be able to execute any migration or DR independently using the Acura panel. However, the support for VMware is somewhat lagging behind the support for OpenStack, where such mechanisms have already been implemented.\u00a0<\/p>\n

But let's return to deployment. First, after the initial setup of the panel, we need to create the first tenant in our system.<\/p>\n

\"Hystax<\/a><\/noindex>
\nAll fields here are clear, I will only explain the Cloud field. We already have a \"default\" cloud that we created during the initial configuration. However, if we want to have the ability to place each tenant on its own datastore and in its own resource pool, we can achieve this by creating separate clouds for each of our customers.<\/p>\n

\"Hystax<\/a><\/noindex>
\nIn the form for adding a new cloud, we specify the same parameters as during the initial configuration (we can even use the same host), indicate the datastore needed for a specific customer, and now in the additional parameters we can individually specify the required resource pool {\"resource_pool\": \"YOUR_POOL_NAME\"}.\u00a0<\/p>\n

As you might have noticed, there is nothing in the tenant creation form regarding resource allocation or any quotas \u2013 none of this exists in the system. It is impossible to limit a tenant in terms of 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 something that seems illogical but is mandatory \u2013 the installation of the Cloud agent. It seems illogical because the agent is downloaded from the specific customer\u2019s page.<\/p>\n

\"Hystax<\/a><\/noindex>
\nIt does not get tied to the created tenant, and all our customers will work through it (or through several, if we deploy them). One agent supports 10 simultaneous sessions. One session is counted as one machine, regardless of how many disks it has. Currently, there is no mechanism for scaling agents within Acura under VMware. There's also one more unpleasant moment \u2013 we cannot see the 'utilization' of this agent from the Acura panel to determine if we need to deploy more or if the current installation is sufficient. As a result, the setup looks as follows:<\/p>\n

\"Hystax<\/a><\/noindex>
\nThe next step to access our customer's portal is to create an account (and also first create a role that will be applied to this user).<\/p>\n

\"Hystax<\/a><\/noindex>
\n\"Hystax<\/a><\/noindex>
\nNow our customer can use the portal independently. All they need to do is download the agents from the portal and install them on their side. There are three types of agents: Linux, Windows, and VMware.<\/p>\n

\"Hystax<\/a><\/noindex>
\nThe first two can be installed on physical machines or on virtual machines on any hypervisor other than VMware. No additional configuration is required; the agent downloads and already knows where to connect, and within minutes, the machine will be visible in the Acura panel. The situation with the VMware agent is slightly more complicated. The problem is that the agent for VMware is also downloaded from the portal pre-configured with the necessary settings. However, in addition to knowing about our Acura portal, the VMware agent needs to know about the virtualization system on which it will be deployed.<\/p>\n

\"Hystax<\/a><\/noindex>
\nSpecifically, this data is what the system will ask us to specify when downloading the VMware agent for the first time. The issue is that in our age of universal love for security, not everyone will want to enter their admin password on someone else's portal, which is quite understandable. Once deployed, the agent cannot be configured further (only its network settings can be changed). Here, I foresee difficulties with particularly cautious customers.\u00a0<\/p>\n

So, after installing the agents, we can return to the Acura panel and see all our machines.<\/p>\n

\"Hystax<\/a><\/noindex>
\nSince I've been working with the system for quite some time, I have machines in various states. All of them are in the Default group, but there is an option to create separate groups and move machines into them as needed. This doesn\u2019t affect anything \u2013 it's just a logical representation and grouping of data for more convenient use. The first and most important thing we need to do after this is to initiate the migration process. We can do this either manually or set up a schedule, including for all machines simultaneously.<\/p>\n

\"Hystax<\/a><\/noindex>
\nI remind you that Hystax was positioned as a migration product. Therefore, it's not surprising that to launch our replicated machines, we need to create a DR plan. The plan can be created for machines that are already in Synced state. It can be generated for a specific VM or for all machines at once.<\/p>\n

\"Hystax<\/a><\/noindex>
\nThe set of parameters when generating the DR plan will vary depending on the infrastructure you are migrating to. A minimum set of parameters is available for VMware environments. Re-IP for machines is also not supported. In this plan, we are interested in the following points: in the VM description, the parameter 'subnet': 'VMNetwork', where we associate the VM with a specific network in the cluster. Rank is relevant when migrating multiple VMs and determines the launch sequence. Flavor describes the VM configuration, in this case \u2013 1CPU, 2GB RAM. In the subnets section, we specify that 'subnet': 'VMNetwork' is associated with the 'VM Network' VMware network.\u00a0<\/p>\n

When creating a DR plan, there is no option to 'distribute' disks across different datastores. They will reside on the same datastore that was defined for this customer cloud, and if you have disks of different classes, this may cause some difficulties when starting the machine. After the machine starts and is 'disconnected' from Hystax, it will require a separate migration of the disks to the appropriate datastores. All that remains is to launch our DR plan and wait for our machines to come up. The P2V\/V2V conversion process also takes time. On my largest test machine with 100GB and three disks, it took a maximum of 10 minutes.<\/p>\n

\"Hystax<\/a><\/noindex>
\nAfter this, the running VM should be checked, along with the services on it, data consistency, and other verifications.\u00a0<\/p>\n

Next, we have two paths:\u00a0<\/p>\n

    \n
  1. Delete \u2013 remove the running DR plan. This action will simply shut down the running VM. The replica data will not go anywhere.\u00a0<\/li>\n
  2. Detach \u2013 disconnect the replicated machine from Acura, effectively completing the migration process.\u00a0<\/li>\n<\/ol>\n

    \nAdvantages of the solution:<\/strong>\u00a0<\/p>\n