Pages

Friday, 11 February 2022

Registering VMware Cloud Disaster Recovery to vCenter with a restricted user account

A customer who is currently looking to deploy VMware Cloud Disaster Recovery (VCDR) globally recently asked about using a single active directory account with the minimum required permissions within vCenter as the account used to register their VCDR connectors to vCenter. For those who are new to VCDR, this is VMware's Disaster Recovery as a Service solution that offers on-demand disaster recovery with a very compelling total cost of ownership in comparison to on-premises.

The customer in question wanted to use a single active directory account across all their vCenters globally and didn't want to add the active directory

Wednesday, 9 February 2022

Routing to a connected VPC when attached to VMware Transit Connect

Recently there was an internal discussion around a customer request to access an Amazon FSx for Windows File Servers that was currently running in a connected VPC from another SDDC. The topology that the customer was looking at was as follows:

The customer had two SDDC's with one of the SDDC's (SDDC 01) being connected to a VPC that was running Amazon FSx for Windows File Servers. They also wanted

Wednesday, 26 January 2022

VMware Transit Connect default route and the impact on VPN and HCX Connectivity

I recently had a query from a customer who was implementing intra-region peering between a VMware Transit Gateway and a native AWS Transit Gateway which would then be attached to a security VPC. Their requirement was to ensure that all VM connectivity from the SDDC would traverse the security VPC before egressing out to the internet or back to on-premises. This would require them to add a static route into the vTGW to point all traffic (0.0.0.0/0) to the peering attachment which connected the vTGW to the TGW. From there they

Tuesday, 27 April 2021

HCX Service Mesh and Route Based VPN with default route advertised

I've been asked a few times around whether or not HCX can be used if the customer has a route-based VPN into VMware Cloud on AWS and is advertising the default route 0.0.0.0/0 into the SDDC. The short answer is Yes, this is supported and works.

The long answer as to why this question comes up is that when we advertise the default route of 0.0.0.0/0 into the SDDC then all traffic from the SDDC will flow via on-premises, this includes traffic destined for the internet. Some customers prefer to do this to ensure all outbound internet traffic routes via their perimeter firewall so they can ensure that all security and logging policies are applied. The confusion comes around HCX. Since HCX is unable to use an existing IPSEC VPN tunnel to send traffic from on-premises into the SDDC as per the KB article it needs to establish its own. The HCX-IX Interconnect and HCX Network Extension Appliances both establish an IPSEC VPN tunnel from on-premises to their peer appliances in the SDDC using UDP/4500. So the question is, if we are advertising 0.0.0.0/0 into the SDDC so all traffic traverses the IPSEC VPN tunnel back to on-premises, then how can the HCX-IX Interconnect and HCX Network Extension Appliances communicate?

Monday, 22 February 2021

HCX Mobility Optimized Networking Policy Routes

With the R145 release of HCX on 30th October 2020, VMware Cloud on AWS customers were treated to some great new functionality at no additional cost. New features such as Replication Assisted vMotion, Application Path Resiliency, TCP Flow Conditioning, Mobility Groups and my personal favourite, Mobility Optimized Networking. I'm not going to go into too much detail around Mobility Optimized Network (MON) since Patrick Kremer (Blog | Twitter) has covered it extensively here.

On an internal slack channel the following question was asked:


When we migrate a VM from on-premises into VMC that resides on a stretched layer 2 network without enabling MON, any traffic that needs to egress that network either destined to VMs on-premises, within VMC or out to the internet

Tuesday, 19 January 2021

Migrating back from Amazon FSx to on-premises file servers

In a previous article, I showed how AWS DataSync could be used to copy data from an on-premises file server (Either physical or virtual) into an Amazon FSx Windows file server. Amazon FSx is a fully managed, highly reliable, and scalable file storage that is accessible over the industry-standard Service Message Block (SMB) protocol. This is ideal for customers who are looking to migrate workloads to VMware Cloud on AWS and start taking advantage of native cloud services to improve resiliency and cost. When it comes to customers who want to utilise VMware Cloud Disaster Recovery to failover their environment into VMware Cloud on AWS but then failback to on-premises once the on-premises environment has been recovered things start to get a little tricky. AWS DataSync does not support copying data back from AWS (FSx, EFS or S3) to on-premises so this has to be performed manually. This post will showcase the steps required to copy the data back from Amazon FSx to on-premises which can be incorporated into your failback process to ensure that there is no data loss.

We first need to ensure we change the existing AWS DataSync task to either run manually or delete it completely to avoid having old data copied (If available) back into FSx which could potentially cause some inconsistencies. Navigate to the AWS DataSync service and either delete the task:


Or change the task schedule to Not Scheduled which means you have to start it manually:


Typically I would recommend stopping the share to 100% confirm

Monday, 18 January 2021

AWS DataSync via VPC Endpoints instead of Public Endpoints

In my previous article, I walked through the steps of replicating an on-premises file server into Amazon FSx using the AWS DataSync service. Since I didn't have a VPN between my on-premises and the VPC where the FSx service was deployed to I had to use the public endpoint whereby all communication from the DataSync agent to AWS occurs over the public internet. Within this article, I'm just going to quickly show you the process of setting this up using VPC Endpoints so communication goes over a VPN or Direct Connect directly into the VPC. This will allow for reverse replication which will be a topic for a future article. 

I currently the AWS DataSync agent deployed with a routable static IP address on-premises and a VPN established into my VPC. I first need to create a VPC endpoint in my VPC for the AWS DataSync Service. Ensure you are in the correct region and navigate to the VPC service. From within there, you will see the option to add Endpoints:


Search for the AWS DataSync service and ensure you select the correct VPC it needs to be created in. I've left the default options to