Migration of complex applications involving multiple virtual machines (VMs) to cloud environment (especially public cloud server) can be a major headache for every IT organisation. That’s why organisations look for automation tool that simplifies the entire process. It not only accelerates cloud migration for multi-tier virtual machines but also helps in large scale migration. One of the highly popular automation tool is known as Velostrata runbook automation, which runs in PowerShell. It aids in complete customisation of –

   Test 

   - Migration of workloads to clouds

This blog post will help to learn how migration of multi-tier application based on multiple virtual machines take place. The entire process is written in a step wise manner –

Step 1 – Runbook Template Creation

The first step involves installation of Velostrata and consequent connection to the cloud. Once this is done and you are ready in starting the migration process, the time has come to create the Runbook. The below mentioned PowerShell command needs to be run for creating the Runbook –

./inventory-export.ps1

In the first step, you will receive a prompt from the system for vCenter address as well as login. You may also enter the same within the following command –

./inventory-export.ps1 vCenterServer -DatacenterName vCenterUser vCenterPassword

When you run the above mentioned PowerShell script, the entire virtual data center environment gets exported to a CSV template, which consists VMs as well as specifications from the source environment.

Step 2: Customisation of the Runbook

Each virtual machine is represented by a RunGroup number. It is followed by many other specifications including –

   - Location of the virtual machine as well as target cloud subnet

   - Type of instance

   - Security group, and many more

Through a validation probe, this will also report on any failed action and whether there is any need of blocking any further processing of the next RunGroup.

An Example of Migration on the Same will Help Understand the Matter Closely –

In the first lot of migration, virtual machines in the 100 RunGroup will be migrated and then started in the cloud environment. Once this first lot’s migration is successful, the process starts for the next 200 RunGroup. The process will go on in this way. Please keep in mind that migration will not take place in case of virtual machines with the default RunGroup.

Integration of Runbook also takes place with linked clones. This helps in customisation through customised tags when in the cloud, the instance is instantiated. This comes as an extremely useful step in addition of tags including cost centre, owner, or department names to the migrated virtual machines.

There are in the Example Two Database Servers –

   - HammerDB-SQL-1

   - SugarCRM

In Fact, there are also two Web Servers and they are –

   - HammerDB_WebTest-1

   - SugarCRM_App

The first requirement is to run the database servers in the cloud and it should be done before the running of web servers dependent on the databases.

Step 3: Migration

Velostrata helps in fast movement of virtual machines in to the cloud environment (public cloud, to be specific). The Runbook migration process is initiated from PowerShell. Only after this, the virtual machines are run by Velostrata in the cloud within 5 to 10 minutes. In the background, data migration takes place. However, immediate validation testing as well as in-cloud performance takes place as virtual machine as well as the application is already running in the cloud. Normal performance of the application is ensured by the WAN optimisations of Velostrata.

It can be seen from vSphere console that the first two things that were brought up first are the two SQL servers. In the PowerShell too these works can be mentioned. Once the servers start running in the cloud, associated data also start migrating in the background. While data migration of the servers takes place in the background, the next set of servers in the Runbook also starts running in the cloud. This process will continue and through the cloud portal you will be able to see which virtual machines have started running in the cloud natively.

Step 4: Detach

All the servers will start to run in the cloud hosting once RunGroups finish. Testing as well as validation of virtual machines and applications associated can be performed by the administrators as and when the migration is taking place. After watching the performance, the administrators can take a decision on detachment and at the same time going cloud-native completely with these applications. In case, the applications are not working in a correct manner then the virtual machines should be rolled back to on-premises and it will take just minutes for resolving the issue. Once completion of data migration happens and virtual machines start to work in the desired manner in the cloud, you can initiate detachment from on-premise. This detachment is nothing but the fact that the shift has been done from Velostrata cloud cache for storage to native cloud disk usage only. If desired by the administrators, they can delete these virtual machines from their vSphere environment.

Interesting Topics To Read:-

Which Are The Leading Cloud Service Providers With Best Uptime And Reliability?