Tag Archives: AWS

VMware Cloud on AWS Migration Planning

This post pulls together the notes I have made during the planning of VMware Cloud (VMC) on AWS (Amazon Web Serivces) deployment, and migration planning of virtual machines from traditional on-premise vSphere infrastructure. It is intended as a list of considerations and not a comprehensive guide. For more information on VMware Cloud on AWS review the following resources:

VMware Cloud on AWS Demo | VMware Cloud on AWS VideosVMware Cloud on AWS Operations Docs | YouTube PlaylistsRoadmap | VMworld 2018 Recorded Sessions | AWS FAQs

Capacity Planning

  • At the time of writing up to 10 SDDC’s can be deployed per organisation, each SDDC supporting up to 10 vSphere clusters and each cluster up to 16 physical nodes.
  • The standard I3 bare metal instance currently offers 2 sockets, 36 cores, 512 GiB RAM, 10.7 TB vSAN storage, a 16-node cluster provides 32 sockets, 576 cores, 8192 GiB RAM, 171.2 TB.
  • New R5 bare metal instances are deployed with 2.5 GHz Intel Platinum 8000 series (Skylake-SP) processors; 2 sockets, 48 cores, 768 GiB RAM and AWS Elastic Block Storage (EBS) backed capacity scaling up to 105 TB for 3-node resources and 560 TB for 16-node resources.
  • When deploying the number of hosts in the SDDC consider the pay as you go pricing model and ability to scale out later on-demand; either manually or using Elastic DRS which can optimised for performance or cost.
  • A really useful tool for VMC planning is the VMware Cloud on AWS Sizer and TCO calculator.
  • The What-If analysis in both vRealize Business and vRealize Operations can also help with capacity planning and cost comparisons for migrations to VMware Cloud on AWS. Use Network Insight to understand network egress costs and application topology in your current environment, see Calculate AWS Egress Fees Proactively for VMware Cloud on AWS for more information.

 

 

Highly Available Deployments

  • An SDDC can be deployed to a single Availability Zone (AZ) or across multiple AZ’s, otherwise known as a stretched cluster. For either configuration if a problem is identified with a host in the cluster High Availability (HA) evacuation takes place as normal, an additional host is then automatically provisioned and added as a replacement.
  • The recommendation for workload availability is to use a stretched cluster which distributes workloads across 2 Availability Zones with a third hosting a witness node. In this setup data is written to both Availability Zones (synchronous write replication) in an active active setup; in the event of an outage to an entire Availability Zone vSphere HA brings virtual machines back online in the alternative AZ.
  • Stretched clusters provide a Recovery Point Objective (RPO ) of zero by using synchronous data replication. Note that there may be additional cross-AZ charges for stretched clusters.
  • The decision on whether to use single or multiple Availability Zones needs to be taken at the time of deployment. An existing SDDC cannot be upgraded to multi-AZ or downgraded to a single AZ.

 

Placement Planning

  • VMware Cloud on AWS links with your existing AWS account to provide access to native services. During provisioning a Cloud Formation template will grant AWS permissions using the Identity Access Management (IAM) service. This allows your VMC account to create and manage Elastic Network Interfaces (ENI’s) as well as auto-populate Virtual Private Cloud (VPC) route tables when NSX subnets are created. It is good practise to enable Multi-Factor Authentication (MFA) for your accounts in both VMC and AWS.
  • Cloud Formation can also be used to deploy your SDDC if desired, review VMware Cloud on AWS Integrations with CloudFormation and the VMware Cloud on AWS Dev Center for more information.
  • An Elastic Network Interface (ENI) dedicated to each physical host connects the VMware Cloud to the corresponding Availability Zone in the native AWS VPC. There is no charge for data crossing the 25 Gbps ENI between the VMware Cloud VPC and the native AWS VPC.
  • Data that crosses Availability Zones however is charged at $0.01 per GB (at the time of writing), therefore it is good practise to deploy the SDDC to the same region and AZ as your current or planned native AWS services.
  • Microsoft SQL Server Workloads and VMware Cloud on AWS: Design, Migration, and Configuration is aimed at migrating SQL into VMC but also contains some useful architectural and operational guidelines so is worth a read.
  • Compute policies can be used to control the placement of virtual machines, see VMWARE CLOUD ON AWS – COMPUTE POLICIES – THE START OF SOMETHING GREAT! for more information.
  • An example architecture of a stretched cluster SDDC is shown below.

vmc_aws_part

Connectivity Planning

Migration Planning

  • If possible your migration team should be made up of the following: Infrastructure administrators for compute, storage, network, and data protection. Networking and Security teams for security and compliance. Application owners for applications, development, and lifecycle management. Support and Operations for automation, lifecycle, and change management.
  • Group services together based on downtime tolerance, as this could determine how the workload is moved: prolonged downtime, minimal downtime, and zero downtime.
  • Consider migration paths for any physical workloads, whether that be P2V, AWS Bare Metal instances, or co-locating equipment.
  • Consider any load balancing and edge security requirements. The AWS Elastic Load Balancer (ELB) can be used or alternative third party options can be deployed through virtual appliances. NSX load balancing as a service in VMC is planned for future releases.
  • You will likely still need Active Directory, DNS, DHCP, time synchronisation, so use native cloud services where possible, or migrate these services as VMs to VMC on AWS.
  • Remember Disaster Recovery (DR) still needs to be factored in. DR as a Service (DRaaS) is offered through Site Recovery Manager (SRM) between regions in the cloud or on-premise.
  • Make sure any existing monitoring tools are compatible with the new environment and think about integrating cloud monitoring and management with new or existing external tools.
  • Move backup tooling to the cloud and perform full backups initially to create a new baseline. Consider native cloud backup products that will backup straight to S3, or traditional backup methods that connect into vCenter. The reference architecture below has been updated to include Elastic Block Storage (EBS) backed Elastic Compute Cloud (EC2) instances running Veeam; which will backup virtual machines from the VMC vCenter into Simple Storage Service (S3) and Glacier.

vmc_aws_full

For up to date configuration maximums and the latest features and information visit the VMware Cloud on AWS FAQs page. Up to date pricing for AWS services can be found at AWS Pricing. Most of the major compliance certification has been achieved at VMC on AWS data centres, see the VMware Cloud on AWS Meets Industry-Standard Security and Compliance Standards blog post for more information.

In addition, if you are working towards the VMware Cloud on AWS Management exam then review 5V0-31.19: VMware Cloud on AWS Management Exam 2019 – Study tips.

VMware Site Recovery Manager 8.x Upgrade Guide

This post will walk through an inplace upgrade of VMware Site Recovery Manager (SRM) to version 8.1, which introduces support for the vSphere HTML5 client and recovery / migration to VMware on AWS. Read more about what’s new in this blog post. The upgrade is relatively simple but we need to cross-check compatibility and perform validation tests after running the upgrade installer.

SRM81

Planning

  • The Site Recovery Manager upgrade retains configuration and information such as recovery plans and history but does not preserve any advanced settings
  • Protection groups and recovery plans also need to be in a valid state to be retained, any invalid configurations or not migrated
  • Check the upgrade path here, for Site Recovery Manager 8.1 we can upgrade from 6.1.2 and later
  • If vSphere Replication is in use then upgrade vSphere Replication first, following the steps outlined here
  • Site Recovery Manager 8.1 is compatible with vSphere 6.0 U3 onwards, and VMware Tools 10.1 and onwards, see the compatibility matrices page here for full details
  • Ensure the vCenter and Platform Services Controller are running and available
  • In Site Recovery Manager 8.1 the version number is decoupled from vSphere, however check that you do not need to perform an upgrade for compatibility
  • For other VMware products check the product interoperability site here
  • If you are unsure of the upgrade order for VMware components see the Order of Upgrading vSphere and Site Recovery Manager Components page here
  • Make a note of any advanced settings you may have configured under Sites > Site > Manage > Advanced Settings
  • Confirm you have Platform Services Controller details, the administrator@vsphere.local password, and the database details and password

Download the VMware Site Recovery Manager 8.1.0.4 self extracting installer here to the server, and if applicable; the updated Storage Replication Adapter (SRA) – for storage replication. Review the release notes here, and SRM upgrade documentation centre here.

Database Backup

Before starting the upgrade make sure you take a backup of the embedded vPostgres database, or the external database. Full instructions can be found here, in summary:

  • Log into the SRM Windows server and stop the VMware Site Recovery Manager service
  • From command prompt run the following commands, replacing the db_username and srm_backup_name parameters, and the install path and port if they were changed from the default settings
cd C:\Program Files\VMware\VMware vCenter Site Recovery Manager Embedded Database\bin
pg_dump -Fc --host 127.0.0.1 --port 5678 --username=db_username srm_db > srm_backup_name
  • If you need to restore the vPostgres database follow the instructions here

In addition to backing up the database check the health of the SRM servers and confirm there are no pending reboots. Log into the vSphere web client and navigate to the Site Recovery section, verify there are no pending cleanup operations or configuration issues, all recovery plans and protection groups should be in a Ready state.

Process

As identified above, vSphere Replication should be upgraded before Site Recovery Manager. In this instance we are using Nimble storage replication, so the Storage Replication Adapter (SRA) should be upgraded first. Download and run the installer for the SRA upgrade, in most cases it is a simple next, install, finish.

We can now commence the Site Recovery Manager upgrade, it is advisable to take a snapshot of the server and ensure backups are in place. On the SRM server run the executable downloaded earlier.

  • Select the installer language and click Ok, then Next
  • Click Next on the patent screen, accept the EULA and click Next again
  • Double-check you have performed all pre-requisite tasks and click Next
  • Enter the FQDN of the Platform Services Controller and the SSO admin password, click Next
  • The vCenter Server address is auto-populated, click Next
  • The administrator email address and local host ports should again be auto-populated, click Next
  • Click Yes when prompted to overwrite registration
  • Select the appropriate certificate option, in this case keeping the existing certificate, click Next
  • Check the database details and enter the password for the database account, click Next
  • Configure the service account to run the SRM service, again this will be retain the existing settings by default, click Next
  • Click Install and Finish once complete

Post-Upgrade

After Site Recovery Manager is upgraded log into the vSphere client. If the Site Recovery option does not appear immediately you may need to clear your browser cache, or restart the vSphere client service.

SRM_81

On the summary page confirm both sites are connected, you may need to reconfigure the site pair if you encounter connection problems.

SRM_81_1

Validate the recovery plan and run a test to confirm there are no configuration errors.

SRM_81_2

The test should complete successfully.

SRM_81_5

I can also check the replication status and Storage Replication Adapter status.

SRM_81_4

VMware Cloud on AWS Demo

This opening post will give an overview and demo of VMware Cloud on AWS. VMware Cloud on AWS provides on-demand, scalable cloud environments based on existing vSphere Software-Defined Data Center (SDDC) products. VMware and AWS have worked together to optimise running vSphere, vSAN and NSX, directly on dedicated, elastic, bare-metal AWS infrastructure without the need for nested virtualization. A SDDC cloud can be deployed in a few hours and then capacity scaled up and down within minutes; either manually or automatically using elastic DRS.

Key Benefits

There are a number of benefits and use cases for extending on-premise data centers to the cloud with VMware Cloud on AWS:

  • VMware maintains software updates, emergency software patches, and auto-remediation of hardware failures
  • Increasing capacity in the cloud is generally quicker, easier, and sometimes more cost effective than increasing physical capacity in the data center
  • Scale capacity to protect services when met with temporary or unplanned demand
  • Improve business continuity by using the cloud for Disaster Recovery (DR) with Site Recovery
  • Consistent operating environments allows for simplified cloud migrations with minimal re-training for system administrators
  • Transfer your existing operating system and third party licensing to the cloud and make use of existing support contracts with VMware
  • Expand into additional geographical locations without needing to provision new data centers

Key Details

Update 18/01/2019 – see also VMware Cloud on AWS Migration Planning. As with all cloud services functionality and limitations are constantly changing, I have updated some of this content but make sure you review the links below for the most up to date information.

VMware FAQ | AWS FAQRoadmap | AWS Pricing

The following links contain enough reading to plan your VMware Cloud on AWS implementation and cloud migration strategy, the points below should also be enough to get you started.

Product Documentation | Technical Overview | VMware Product Page | AWS Product Page | | Case Study | Try first @ VMware Cloud on AWS – Getting Started Hands-on Lab

  • At the time of writing up to 10 SDDC’s can be deployed per organisation, each SDDC supporting up to 10 vSphere clusters and each cluster up to 16 physical nodes.
  • The standard I3 bare metal instance currently offers 2 sockets, 36 cores, 512 GiB RAM, 10.7 TB vSAN storage, a 16-node cluster therefore provides 32 sockets, 576 cores, 8192 GiB RAM, 171.2 TB.
  • New R5 metal instances are deployed with 2.5 GHz Intel Platinum 8000 series (Skylake-SP) processors; 2 sockets, 48 cores, 768 GiB RAM and AWS Elastic Block Storage (EBS) backed capacity scaling up to 105 TB for 3-node resources and 560 TB for 16-node resources.
  • Each ESXi host is connected to an Amazon Virtual Private Cloud (VPC) through Elastic Networking Interfaces (ENI’s), which supports throughput up to 25 Gbps
  • Hybrid Cloud Extension allows stretched subnets between on-premise and cloud data centers for live migration of virtual machines
  • Hybrid Linked Mode allows administrators to connect vCenter Server running in VMware Cloud on AWS to an on-premises vCenter server to view both cloud and on-premises resources from a single interface
  • VMware Cloud on AWS complies with ISO 27001, ISO 27017, ISO 27018, SOC 1, SOC 2, SOC 3, HIPAA, and GDPR, find the full list of compliance certification here
  • VMware Cloud on AWS is managed from a web-based console or RESTful API
  • At the time of writing VMware Cloud on AWS is available in the AWS Europe (Frankfurt and London), AWS US East (N. Virginia) and AWS US West (Oregon) Regions
  • Basic pricing before discount can be calculated here

VMware_AWS

Product Demo

The demo below creates a SDDC in the cloud for lab purposes. Before deploying your own environment you should review all the above linked documentation and do your own research to plan your cloud strategy as well as the following:

  • Identify or create an AWS account and ensure that all technical personnel have access to the account
  • Identify a VPC and subnet by cross-linking the AWS account to the SDDC
  • Allocate IP ranges for the SDDC, and determine a DNS strategy
  • Identify the authentication model for the SDDC
  • Plan connectivity to the SDDC
  • Develop a network security policy for the SDDC

Browse to the VMware Cloud Services portal (https://console.cloud.vmware.com) and login using your VMware ID. At the time of writing to access VMware Cloud on AWS you need to be invited or you can register for a 30 day single host trial here.

VMware_Cloud

Select VMware Cloud on AWS. If you have not used the service before you will be prompted to create a new organisation. Enter a name for your new organisation and accept the terms of service, click Continue.

AWS_1

Add a credit card to be billed if you use the service.

aws_2.png

After you have created the organisation and added payment information you will be sent to the VMware Cloud on AWS dashboard. The first step is to create our SDDC in the cloud, click Create SDDC.

Billing: annual subscriptions are listed under the Subscriptions tab, you can see other billing information from the drop-down menu next to your organisation name: select Organisation Settings, View Organisation. From here you have services, identity and access management, billing and subscriptions, and support options.

AWS_3

Select a region and deployment model for the SDDC, enter a name and the number of hosts if you are not using the single host deployment. Click Next.

AWS_4

Follow the instructions to connect an AWS account and assign the relevant capabilities.

AWS_5

Once the connection is successfully established click Next.

AWS_7

Select the VPC and subnet to use then click Next.

AWS_8

Specify a private subnet range for the management subnet or leave blank to use default addressing. As mentioned above ensure you have planned accordingly and are not using any ranges that will conflict with other networks you may connect in the future. Click Deploy SDDC.

AWS_9

The SDDC will now be deployed, it takes around 2 hours to provision the ESXi hosts and all management components.

AWS_10

Once the deployment is complete the dashboard will show the new SDDC and assigned resources. Click View Details (you can toggle the web portal theme using the Dark/Light options in the top right hand corner).

AWS_14

From either the SDDC Summary tab or back on the SDDC dashboard you can seamlessly add additional hosts or clusters at any time.

AWS_15

If needed the chat bubble in the bottom right hand corner of the screen will take you through to support.

AWS_Support

The Network tab shows the network topology and is where you can configure firewall rules, NAT rules, VPN, Direct Connect, etc.

AWS_12

To access the vCenter Server through the vSphere client the port needs opening, a VPN can also be used. Under Management Gateway select Firewall Rules, click Add Rule. Configure the rule to allow access to the vCenter on port 443 and click Save.

AWS_11

Click Open vCenter from either the Summary or Network tab, if access is in place you are given the cloudadmin@vmc.local credentials to open vCenter. Active Directory can also be configured as an identity source later on.

Once you are logged into the vSphere client you will see the familiar vSphere layout.

vCenter_AWS

It is also possible to see your on-premise vCenter Server(s) in the same pane of glass using Hybrid Linked Mode, click here for more information.

Back in the VMware Cloud on AWS portal the Add Ons tab features Site Recovery and Hybrid Cloud Extension for protecting and migrating workloads to your SDDC in the cloud.

AWS_16

You can delete a SDDC from the Actions drop-down menu in either the SDDC Summary tab or the SDDC dashboard. Once a SDDC is deleted all workloads, data, and interfaces are destroyed and any public IP addresses released.

AWS_17