Google Cloud VMware Engine Part One: Deployment
This blog series will look at how you can leverage GCVE to migrate and then modernise your applications in Google Cloud. This first post focuses on the deployment of a core environment within Google Cloud VMware Engine (GCVE).
In future posts, we will look at how we can migrate apps to the GCVE environment, with the aim of then modernising them to leverage Google Cloud managed services.
See more articles
Senior VMware Platform Engineer
Introducing the GCVE product
GCVE is hands down the leading VMWare Cloud based platform, deployed through Google Cloud. It is enterprise ready and perfect for anyone looking to either mass migrate their datacenter to the cloud, extend their existing footprint or build out a disaster recovery site.
Before we get into the details, it’s worth a short overview to GCVE and why it’s interesting to our customers. Google Cloud VMware Engine (GCVE) was released in mid-2020. It allows customers to extend or migrate their existing VMWare IT estate into Google’s Cloud in minutes, requiring minimal alteration to any of their existing systems by using a dedicated cloud based VMware environment. CTS were the first partner outside of the US to adopt the GCVE platform and expect this to provide many new opportunities in the EMEA area
This ‘Hybrid-Cloud’ concept opens up a whole new area of possibilities and opportunities not previously available. Arguably one of the primary reasons for many businesses’ reticence in moving to the cloud is the level of system restructuring combined with the adoption of perceived alien platforms that would entail. Equally many years of their own IT engineers experience in the standard technical stack (Wintel, virtualisation, storage, networking, etc), would be largely washed away in a short time. GCVE eliminates all of these concerns in a single stroke.
In addition to this, the highly capable HCX migration tool is fully integrated into the system making migration to and from the cloud a relatively painless exercise. This incurs minimal to zero downtime and can predominantly be undertaken in normal working hours. This is of course in stark contrast to the many traditional datacenter migrations I’ve been involved in during my career over the years, often working into the middle of the night, for days on end, and regularly consuming whole weekends.
The building of a new GCVE sandbox environment allows for its look & feel, functionality and its usability to be demonstrated first hand to new potential customers during the online meetings. The demonstrations will give our customers an insight into the cloud side hosting of VMware as a cloud service API and the basic configuration and networking involved. In addition, the HCX migration tool can be demonstrated, showing the ease in which migration to the cloud can be performed for existing customers who use VMware as their primary infrastructure platform. This will likely be the first time of viewing for many customers considering the relative new release period of the product.
The Technical Layout of GCVE
GCVE design is a standard vCenter deployment utilising NSX networking with vSAN for storage (so no additional storage hardware is required). The VMware version has been upgraded to the latest iteration of VMware version 7.0 as of early December 2020. The most minimal deployment of GCVE is three nodes (the vSAN minimum) but more nodes can be added later if required for capacity. The costing model is largely on a node by node basis with all infrastructure software licensing fully included. All patches and updates are automatically handled in the background on your behalf.
The basic 3-node GCVE cluster however still makes for one fairly impressively datacentre spec:
The Initial Requirements and the Deployment
Having joined CTS in mid-autumn of last year it was immediately apparent that a useful first step would be to deploy a sandbox test environment to trial and demonstrate the new product both internally and to potential early customers. For a test environment to be usable however requires two distinct datacenters acting as both the source vCenter and the GCVE as the target vCenter. To achieve this a second dummy ‘customer site’ would first need to be built in order for the GCVE platform to have an external site to connect to. This was achieved through the use of a relatively inexpensive bare-metal provider featuring a single server running the VMware ESXi operating system. Upon this a vCenter instance and some test VMs can then be deployed for migration purposes.
The basic deployment path is as follows:
- Download the various software items required including, vSphere 6.7, ESXi 6.7, OpenVPN and the standard OS ISO’s for the test VMs, Windows 2012/2016 and Ubuntu 20, etc. The HCX installer can be downloaded directly from the GCVE deployment at a later point.
- Build out an external vCenter site to act as the source ‘customer site’.
- Deploy GCVE in the cloud.
- Configure at least one virtual network in NSX for the VMs to run on/access the internet.
- Configure the GCVE firewall to allow appropriate traffic in/out on the various subnets.
- Deploy the management VPN connection.
- Download and deploy the HCX client back on the source site.
- Configure the site connection, then create the source compute and network profiles. Then finally setup the all-important ‘service mesh’ connecting the two sites and allowing for migration and replications (this is detailed later).
The Objectives for the new Sandbox Environment
The principle goal for the sandbox was clearly to gain more knowledge and experience in both the GCVE product and its deployment, with the following being the key aims:
- Deploy a functioning target vCenter with running test VMs on the network/internet.
- Successfully deploy and configure HCX on the source site.
- Demonstrable deployment to show to potential customers.
The credits obtained for about one month runtime for the sandbox came through in mid-November 2020, the core nodes required to deploy GCVE take ~2 working days to be created. Once the three nodes are made available in your given region (in this case Europe-West 2) the deployment of the GCVE typically takes half an hour in the background for the vCenter to come online with the NSX and HCX deployments then taking an additional half an hour to fully complete in the background. When the subsequent 7-8 HCX plugins have installed on the vCenter, the environment is then fully ready to use.
Configuring HCX is one of the more important and challenging steps. Once the HCX has been deployed and the base configuration completed on the source side, the HCX link can then be setup. This entails creating a site pairing between the two sites, then creating the network and compute profiles for the source site. The target GCVE side is already auto-configured at deployment. The final step is then to create the ‘Service Mesh’ which allows for VM migrations to and from the cloud. The service mesh was then successfully created correctly pointing to the source environment, this allowed cold migration to be undertaken. Certain technical issues later prevented HCX hot or bulk migrations from completing (this will be discussed in more detail later).
The site pairing in place joining the source and target vCenters together:
Create the source side ‘Compute Profile’:
Create the source side ‘Network Profile’:
And then finally create the ‘Service Mesh’:
This then allows for VM migrations to be undertaken on chosen VMs:
There are three migration options available:
- vMotion - Direct live migration to/from the cloud, no downtime.
- Bulk Migration - For mass migration of many VMs, results in short downtime.
- Replication-assisted vMotion - Uses pre-replicated data seeding for shorter migration times.
Overall Experience, Issues Encountered and Outcome
Overall the test environment has been a great asset both in terms of internal experience and providing a platform for demonstrations to potential customers. Some technical challenges were inevitably encountered during the course of the deployment, overcoming these of course only increases the level of knowledge and awareness of the behaviour and potential pitfalls in view of smoother deployments in the future.
The largest challenge was the initially chosen bare-metal provider’s network setup did not suit the virtual appliance style deployments used by HCX, this was due to the requirement to override the virtual machine MAC addresses. This provider ultimately had to be abandoned and replaced with a different bare-metal provider to be used going forward, this required a full re-deployment on the source side.
Another issue was that the original option was taken to connect the two sites using public IPs for quick setup and simplicity, this mostly worked correctly bar the requirement for NATing on the target HCX IPs. So an alternative site-to-site VPN connection was tried. Officially HCX is only supported on full interconnects between the customer site and the cloud, so going forward this should not be an issue on future production level site deployments.
Arguably the greatest benefit of GCVE is the speed with which a new datacenter can be stood up. With GCVE it only takes effectively a few days of setup and configuration in order to have a fully functioning VMware estate ready for immediate use. From experience, in comparison it can take many weeks if not months to fully setup a traditional on-premise or colocation based datacenter environment. The procurement of the physical tin and confirming the allocation of hired rack space would in itself take many weeks to months, this of course precludes all of the manual installation, networking and configuration then required. In direct contrast, all of this is handled entirely in the background rapidly by the Google cloud platform over the timeframe of a few days including all maintenance and patching.
If you're thinking of getting started on GCVE or need assistance moving your VMware workloads to the cloud, get in touch. Our experts are here to help accelerate your modernisation journey
Google Cloud Opens the Door to Microsoft Workloads
Cloud technology has come a long way in the past few years with three players coming at it...
Kubernetes Part 2: Continuous Deployment and GitOps
The first post in this series discussed securing your cluster and the workloads running inside of...