Chi-Chung Wong

22 years IT experience with a proven track record and a reputable background.
A Virtualization Architect for Cloud (on-prem and off-prem) and Desktop solutions. Chi has architected solutions and delivered designs for large corporate enterprises in different sectors. These transformation projects typically range to up to 40,000 end users.
Chi has very strong technical expertise and is certified in AWS Architect - (Associate, VMWare VCP (SDDC) and VMWare VCP-DT (EUC).

Connect with Chi.

View articles by Chi-Chung

Let’s migrate to VMware Cloud on AWS!

A lot of organisations are considering VMware Cloud on AWS as an attractive option for their Cloud platform because it enables them to rapidly migrate workloads to the Cloud with minimal or no downtime, as well as leverage Cloud benefits such as agility, scalability and the ability to move to a variable, rather than fixed, infrastructure cost model.

Many times, our customers ask the same questions about this solution. To summarise, here are some facts about VMware Cloud on AWS:

*Cost is based on the number of hosts (minimum three for a production environment) and this is the only current option. It is NOT based on the number of VMs/instances.

*For billing, unlike Amazon AWS where resources could be tagged for categorisation and billing/chargeback purposes, there is no such concept as the whole host is charged to the account. This is like AWS EC2 Dedicated Hosts, where tagging on instances does not translate to a cost.

* An Amazon AWS account must be linked to each VMware Cloud on AWS account. VMware will bill you for VMware Cloud on AWS service. Amazon will bill your AWS account for any additional native Amazon AWS services consumed.

*It offers on-demand, one-year and three-year subscription options. The three-year plan gains a 50% saving over the on-demand option.

* Hosts are dedicated for a single tenant. Your VMware Cloud on AWS hosts will not be shared with other VMware/AWS customers, thus will not be affected by noisy-neighbour syndrome.

* You leverage the same support and management tools as with current on-premises (on-prem) environments and no new toolset for managing your VMware Cloud environment on AWS is required.* It has interoperability with native Amazon AWS services such as S3, Amazon RDS and Amazon FSx for Windows File Server which was announced at Re:Invent 2018. These additional consumed services will be billed to the linked AWS account.

* Hybrid Cloud Extension (HCX) enables stretching of the network between on-prem and VMware Cloud on AWS to allow for workload migration without changing IP addresses. HCX is an add-on service to VMware Cloud on AWS and is included in the price.

* If you already have VMware NSX-T, you can stretch your on-prem network without HCX, but this will require Amazon Direct Connect and the use of VMware vCenter Hybrid Linked Mode (requires VMware vCenter 6.5 U2+) to migrate workloads to VMware Cloud on AWS without downtime.

These additional consumed services will be billed to the linked AWS account.

Hybrid Cloud Extension (HCX) enables stretching of the network between on-prem and VMware Cloud on AWS to allow for workload migration without changing IP addresses. HCX is an add-on service to VMware Cloud on AWS and is included in the price.

If you already have VMware NSX-T, you can stretch your on-prem network without HCX, but this will require Amazon Direct Connect and the use of VMware vCenter Hybrid Linked Mode (requires VMware vCenter 6.5 U2+) to migrate workloads to VMware Cloud on AWS without downtime.

When committing to VMware Cloud on AWS, you can choose how many nodes you require, from three nodes for production to a maximum of 16. A good option is to start off small and then scale up as and when required. The initial setup of the environment takes around 90 minutes, with the addition of further nodes taking around 15 minutes. However, a very important decision to make is to choose whether you want a stretched cluster or not. A stretched cluster basically means that you want your virtual infrastructure to be located across two Amazon AWS availability zones for high availability to protect against an outage of one of the availability zones.

Stretched Cluster or not?

The factors that contribute to the decision are:

* Do you need to be resilient to an outage of a single datacentre or is disaster recovery sufficient?

* There is an additional cost for extra hosts required for Stretched Cluster. Effectively, this will double the number of hosts, therefore doubling the cost. With a stretched cluster, the maximum number of nodes now changes to 28, which is 14 per Availability Zone.

* Scaling up the cluster requires nodes to be added in both Availability Zones (so two nodes at a time).

* Usable storage capacity is effectively halved because both sites will contain full copies of the data.

* You cannot upgrade from a non-stretched cluster to a stretched cluster

* You cannot downgrade from a stretched cluster to a non-stretched cluster

As you cannot change the stretch/non-stretched characteristics after the environment has been created, it is therefore imperative that this decision is made correctly from the start.

How to migrate?

With a VMware Cloud on AWS environment set up and a network stretched with management capabilities linked either via HCX or Hybrid Linked Mode, it will be a typical VMware to VMware migration, without the needing to change IP addresses of your servers. The following migration options are available:

* Cold Migration: powered off

* Bulk Migration: uses VMware vSphere Replication and not available on Hybrid Linked Mode, this is a warm-migration requiring a reboot to complete and is available to on-prem vSphere versions from 5.0

* VMware vMotion: this is a live migration and will not require down time. With HCX, migrating workloads using vMotion to VMware Cloud on AWS is possible with older on-prem versions of VMware vSphere (from 5.5)

Recently, two new methods have been announced that are available with HCX. These are:

* Cloud Motion - using VMware vSphere Replication, Cloud Motion will replicate the virtual disks to VMware Cloud on AWS and then the memory state of the VM is migrated over without downtime. As with Bulk Migration, Cloud Motion of virtual machines can be scheduled.

* Cloud Motion with AWS Snowball - this is not yet available and still under development. This method enables an interesting option to leverage Snowball to migrate up to 72TB of workloads using physical transportation methods, without downtime.

In a state of hybridity, where your infrastructure is in both on-prem and Cloud, where you can easily move workloads between the two, it is important to remember that moving workloads to the Cloud is free, but moving workloads from the Cloud back to on-prem, even if it’s a simple vMotion task, is chargeable per GB of data by AWS.

Once you’re migrated and you’ve ticked the box for Cloud adoption, don’t stop there on your Cloud journey. Being on VMware Cloud on AWS can enable adoption of further Cloud services. For example, without re-architecting your applications you can easily utilise AWS RDS and decommission owned MS SQL Servers and Oracle Database Server and/or move to AWS FSx for Windows and decommission your file servers.

What’s more, if your organisation has moved to a VDI solution for the desktop infrastructure and now your server infrastructure is in VMware Cloud on AWS, it will no longer reside physically with the VDI environment. Client applications that are very chatty with the server backend may now have a performance impact because of the location aspect, and so you may need to consider moving the VDI solution into the cloud as well, such as using VMware Horizon on VMware Cloud on AWS.

At Virtual Clarity, we are great at helping businesses with their migration. If you want to learn more, give us a call.