Almost after a year of the announcement, VMware Cloud on AWS is available to customers. At VMWorld 2017, both the companies highlighted the benefits of the partnership. Existing businesses using VMware stack can easily extend their virtualized data center to Amazon’s public cloud. When it comes to infrastructure, VMware can ride on top of Amazon’s global footprint. Customers across the globe can choose a region closer to their data center for public cloud migration. When Amazon announces a new region, VMware can piggyback on it without the CapEx and the management expertise. This comes as a huge win to VMware and its ecosystem. But this write up is about the nuts and bolts of the solution and how it affects our day to day operations. VMware Cloud on AWS comes with three components to it:
- Compute (Virtualized) – ESXi
- Storage (Virtualized) – vSAN
- Network (Virtualized) – NSX
All of these are managed by vSphere. This is an On-demand service which delivers software defined Data Centers (SDDC) as a cloud service. Click a button in console or make an API call and you can deploy a complete running VMware cloud in AWS with all above mentioned Software defined components which are installed, configured and ready to use. VMware maintains and manages these components for you, so it will patch, upgrade all of these components. So if you add a new host to a cluster, ESXi is already configured on the host, same goes for vSAN and NSX. Since this is running on AWS infrastructure, it has dynamic capacity in terms of compute, storage and network.
VMware cloud on AWS is deployed directly on Bare Metal inside in an AWS EC2 environment. So its not a nested virtualization, its all ESXi sitting directly on Bare Metal servers. Hardware servers being used have below specifications:
- I3.16XL Equivalent
- 36 cores / 72 vCPUs
- 512 GiB RAM
- 15 TiB NVMe All Flash Memory Storage
- 25 Gb ENA (network)
This is almost the same ESXi software that you would run on-premise, however you can start as low as 4 host cluster and go up to 32 host cluster. A single customer can have multiple clusters. These are maintained by VMware and there is no direct SSH / root access to ESXi host or a VIBs or third party plugins to ESXi host.
From a storage perspective, VMware is using vSAN which actually aggregates the local storage of each host and after a suitable RF setting provides the necessary usable capacity for VMs. We cannot attach EBS or EFS to the existing hosts, from a data store perspective. The existing NVMe drives are used for the aggregate storage of vSAN pool. We can however add EFS volumes to the VMs as NAS shares if need be. All necessary VMware storage policies still apply as per requirement, so you can create individual VMware storage policies to choose the number of parity bits that are set for each VM.
NSX is being used for virtualization of Network, which basically creates logical networks. This is not running directly inside AWS subnet. So VMs are not attached to a AWS subnet, but to an overlay network, you can create Layer -2 networks which are connected into Compute and Management Gateways. The Compute Gateway is basically a VM running to provide gateway services for all your compute nodes and Management Gateway manages and controls the NSX control center and vCentre traffic. Gateways actually act as an IGW (if you are not familiar what an IGW is in AWS click here.) except in this case, there are a few additional things which they do. They also act as IP-sec termination points for IP-sec VPN tunnels, they perform NAT and perform the North-South fire walling.
This is the best part about VMware cloud on AWS, since an IT administrator does not need to learn a new tool, since its vSphere, which he or she has been managing for ages now. It is managed by VMware, it is its own single sign on domain and you are delegated rights to an account that allows you to actually manage your workload. VMware introduced a new feature called Hybrid Linked Mode, which allows you to connect the single sign on domain which is running inside of VMware Cloud on AWS into your on-premises environment.
So if, you look at the big picture, the whole setup looks like a much awaited #HybridCloud. This has three pillars namely, Customer DC (on-premises), VMware Cloud on AWS, and AWS Cloud, see image below.
Lets talk a little bit about accounts, since there are two different accounts in play when you manage VMware Cloud on AWS. When you sign up for the service, VMware is going to create a brand new AWS account, this will be owned and operated by VMware, they will pay for this account and you as a customer will have no visibility to this. They use this account to create and run all the SDDC resources which are needed to run VMware Cloud on AWS environment. This account is called VMware Cloud SDDC Account. There is a second account which is your own AWS account. This is owned, operated and paid by you as a customer, this can have a private connectivity to VMware Cloud on AWS. This runs all native AWS services and its bill is paid by you to AWS, when compared to VMware Cloud SDDC Account for which you pay the bill to VMware.
- Go to https://vmc.vmware.com/ , this is the VMware Cloud on AWS console.
- Login using my.vmware.com credentials and you can create organizations.
- VMware also has Identity and Access Management (not the same as AWS IAM but similar to it), here you can go ahead your users and groups. Assign permissions to users etc.
- Create a new SDDC, by giving a new SDDC name.
- Choose number of hosts (4 – 32).
- Choose the AWS region in which the SDDC will run. (AWS EU (London) Region, AWS US East (N. Virginia)region and AWS US West (Oregon) region)
- Connect VMware Cloud on AWS to your existing AWS account.
- Connect VMware Cloud on AWS to your existing on-premise VMware account.
Once this is all done, we can manage the resources in our SDDC in VMware Cloud on AWS via vmc.vmware.com or even via vSphere HTML 5 Web Client. Remember, the whole SDDC is delivered as a service, so
- AWS manages the physical resources (servers, DC, hardware, cooling, power etc.).
- VMware manages the hypervisor and management components.
- You manage the VMs and applications running on them.
Access via vCentre is through a delegated permission model, so you do not have root access, you will have a cloud admin account which will have delegated rights.
- Expansion of Current DC’s without buying new hardware – Disaster recovery, backup and continuity of operations.
- Consolidation and Migration – data center consolidation and migration, application migration, getting out of on-premise DC completely.
- Workload Flexibility – Prod, Dev, Test, Lab and Training, Burst Capacity for new application and workloads.