21 February, 2024
December 19, 2022
A valued TeraSky client offers a continuous data protection solution for disaster recovery and data protection across on-prem, hybrid, and multi-cloud environments that replicate VM objects from one vCenter to another or from a vCenter to any public cloud (Azure, AWS, etc.). In order to test their solution and to develop in the correct environments, this client needed integration into all possible versions of – and combinations of – vSpheres and vCenters. They approached TeraSky to request a VMware vRA customization and automation solution to efficiently and effectively deploy these combinations.
The company used vRA to deploy every version of vSphere, which enabled them to install their solution and replicate their data from one deployment to another, demonstrating the full vSphere environment and allowing them to test any version of their solution on any version of vSphere. To do this, they had two types of labs: most contained one vCenter and three corresponding ESXi servers, while the largest contained two vCenters with three corresponding ESXi servers each. They used the single vCenter deployments to replicate data to one of the public clouds and the double vCenter deployment to test applications between two vCenters. This way, users could request a lab by logging into vRA, opening the portal, and choosing the version or versions of vSphere to be provisioned for testing the company’s solution inside it.
In order to prepare the vRA environment for this concept, our client pre-installed all of the versions of all of the vCenters and vSpheres and saved each as a template. vRA then accessed the template with the environment preinstalled and provisioned the VMs behind NSX (behind the bubble network). This way, they are able to demonstrate a fully independent lab without any conflict with or even awareness of other labs, which helps users isolate and identify any issues without causing any impact on other users’ labs during the testing process.
However, their communication method to all of these labs was based on a jump host with RDP session. TeraSky decided to give each lab its own additional OpenSSL configuration. Once each requested lab was provisioned, the user would receive an email notification with the VPN configuration file. This way, the user could download the file and log into their deployment and lab to install the solution and complete any required tests or tasks. This approach increased the user experience by adding an additional method to communicate with the user labs other than RDP session to the jump host. The users were able to use local communication with their isolated labs by using the lab’s dedicated SSL VPN solution.
To automate and create these labs efficiently, TeraSky employed linked clones as a provisioning method. Linked clones take a snapshot of the VM and then instantly provision a VM inside the same vCenter. At that point, vSphere begins to save the delta, or the changes between the template snapshots, and the new VM that gets provisioned. Each deployment takes approximately 5 minutes to provision, followed by a post-configuration phase that configures the NSX DHCP and the VPN solution that adjusts the IP addresses for each one of the labs. This open VPN solution met our client’s requirements to enable a command line or API approach and multi-method authentication. Plus, from start to finish, the process now took only ten minutes, rather than the 2-3 days it would take to complete manual provisioning for vCenter, ESXi servers in any version, and SSL VPN in isolated networks.
Written by: Sagi Ilan, Hybrid Cloud & Automation Senior Consultant