NFS DataStore on VMware Cloud on AWS using Amazon FSx for NetApp

Featured


Amazon FSx for NetApp ONTAP integration with VMware Cloud on AWS is an AWS-managed external NFS datastore built on NetApp’s ONTAP file system that can be attached to a cluster in your SDDC. It provides customers with flexible, high-performance virtualized storage infrastructure that scales independently of compute resources.

PROCESS

  • Make sure SDDC has been deployed on VMware Cloud on AWS with version 1.20
  • The SDDC is added to an SDDC Group. While creating the SDDC Group, a VMware Managed Transit Gateway (vTGW) is automatically deployed and configured
  • A Multi-AZ file system powered by Amazon FSx for NetApp ONTAP is deployed across two AWS Availability Zones (AZs). (You can also deploy in single AZ but not recommended for production)

DEPLOY VMWARE MANAGED TRANSIT GATEWAY

To use FSx for ONTAP as an external datastore, an SDDC must be a member of an SDDC group so that it can use the group’s vTGW and to configure you must be logged into the VMC console as a user with a VMC service role of Administrator and follow below steps:

  • Log in to the VMC Console and go on the Inventory page, click SDDC Groups
  • On the SDDC Groups tab, click ACTIONS and select Create SDDC Group
  • Give the group a Name and optional Description, then click NEXT
  • On the Membership grid, select the SDDCs to include as group members.The grid displays a list of all SDDCs in your organization. To qualify for membership in the group, an SDDC must meet several criteria:
    • It must be at SDDC version 1.11 or later. Members of a multi-region group must be at SDDC version 1.15 or later.
    • Its management network CIDR block cannot overlap the management CIDR block of any other group member.
    • It cannot be a member of another SDDC Group.
    When you have finished selecting members, click NEXT. You can edit the group later to add or remove members.
  • Acknowledge that you understand and take responsibility for the costs you incur when you create an SDDC group, then click CREATE GROUP to create the SDDC Group and its VMware Transit Connect network.

ATTACH VPC TO VMWARE MANAGED TRANSIT GATEWAY

After the SDDC Group is created, it shows up in your list of SDDC Groups. Select the SDDC Group, and then go to the External VPC tab and click on ADD ACCOUNT button, then provide the AWS account that will be used to provision the FSx file system, and then click Add.

Now it’s time for you to go back to the AWS console and sign in to the same AWS account where you will create Amazon FSx file system. Here navigate to the Resource Access Manager service page and

click on the Accept resource share button.

Next, we need to attach VMC Transit Gateway to the FSX VPC, for that you need to go to:

ATTACH VMWARE MANAGED TRANSIT GATEWAY TO VPC

  • Open the Amazon VPC console and navigate to Transit Gateway Attachments.
  • Choose Create transit gateway attachment
  • For Name tag, optionally enter a name for the transit gateway attachment.
  • For Transit gateway ID, choose the transit gateway for the attachment, make sure you choose a transit gateway that was shared with you.
  • For Attachment type, choose VPC.
  • For VPC ID, choose the VPC to attach to the transit gateway.This VPC must have at least one subnet associated with it.
  • For Subnet IDs, select one subnet for each Availability Zone to be used by the transit gateway to route traffic. You must select at least one subnet. You can select only one subnet per Availability Zone.
  • Choose Create transit gateway attachment.

Accept the Transit Gateway attachment as follows:

  • Navigating back to the SDDC Group, External VPC tab, select the AWS account ID used for creating your FSx NetApp ONTAP, and click Accept. This process takes some time..
  • Next, you need to add the routes so that the SDDC can see the FSx file system. This is done on the same External VPC tab, where you will find a table with the VPC. In that table, there is a button called Add Routes. In the Add Route section, add the CIDR of your VPC where the FSX will be deployed.

In the AWS console, create the route back to the SDDC by locating VPC on the VPC service page and navigating to the Route Table as seen below.

also ensure that you have the correct inbound rules for the SDDC Group CIDR to allow the inbound rules for SDDC Group CIDR. it this case i am using entire SDDC CIDR, Further to this Security Group, the ENI Security Group also needs the NFS port ranges adding as inbound and outbound rules to allow communication between VMware Cloud on AWS and the FSx service.

Deploy FSx for NetApp ONTAP file system in your AWS account

Next step is to create an FSx for NetApp ONTAP file system in your AWS account. To connect FSx to VMware cloud on AWS SDDC, we have two options:

  • Either create a new Amazon VPC under the same connected AWS account and connect it using VMware Transit Connect.
  • or Create a new AWS account in the same region as well as VPC, connect it using VMware Transit Connect.

In this blog, i am deploying in the same connected VPC and for it to deploy, Go to Amazon FSx service page, click on Create File System and on the Select file system type page, select Amazon FSx for NetApp ONTAP,

On Next page, select the Standard create method and enter require details like:

  • Select Deployment type (Multi-AZ) and Storage capacity
  • Select correct VPC, Security group and Subnet

After the file system is created, check the NFS IP address under the Storage virtual machines tab. The NFS IP address is the floating IP that is used to manage access between file system nodes, and this IP we will use to configuring in VMware Transit Connect to allow access volume from SDDC.

we are done with creating the FSx for NetApp ONTAP file system.

MOUNT NFS EXTERNAL STORAGE TO SDDC Cluster

Now it’s time for you to go back to the VMware Cloud on AWS console and open the Storage tab of your SDDC. Click ATTACH DATASTORE and fill in the required values.

  • Select a cluster. Cluster-1 is preselected if there are no other clusters.
  • Choose Attach a new datastore
  • The NFS IP address shown in the Endpoints section of the FSx Storage Virtual Machine tab. Click VALIDATE to validate the address and retrieve the list of mount points (NFS exports) from the server.

  • Pick one from the list of mount points exported by the server at the NFS server address. Each mount point must be added as a separate datastore
  • AWS FSx ONTAP
  • Give the datastore a name. Datastore names must be unique within an SDDC.
    • Click on ATTACH DATASTORE

VMware Cloud on AWS supports external storage starting with SDDC version 1.20. To request an upgrade to an existing SDDC, please contact VMware support or notify your Customer Success Manager.

Cross-Cloud Disaster Recovery with VMware Cloud on AWS and Azure VMware Solution

Featured

Disaster Recovery is an important aspect of any cloud deployment. It is always possible that an entire cloud data center or region of the cloud provider goes down. This has already happened to most cloud providers like Amazon AWS, Microsoft Azure, Google Cloud and will surely happen again in future. Cloud providers like Amazon AWS, Microsoft Azure and Google Cloud will readily suggest that you have a Disaster Recovery and Business Continuity strategy that spans across multiple regions, so that if a single geographic region goes down, business can continue to operate from another region. This only sounds good in theory, but there are several issues in the methodology of using the another region of a single cloud provider. Some of the key reasons which I think that single cloud provider’s Cross-Region DR will not be that effective.

  • A single Cloud Region failure might cause huge capacity issues for other regions used as DR
  • Cloud regions are not fully independent , like AWS RDS allows read replicas in other regions but one wrong entry will get replicated across read replicas which breaks the notion of “Cloud regions are independent
  • Data is better protected from accidental deletions when stored across clouds. For Example what if any malicious code or an employee or cloud providers employee runs a script which deletes all the data but in most cases this will not impact cross cloud.

In this blog post we will see how VMware cross cloud disaster recovery solution can help customers/partners to overcome BC/DR challenges.

Deployment Architecture

Here is my deployment architecture and connectivity:

  • One VMware Cloud on AWS SDDC
  • One Azure VMware Solution SDDC
  • Both SDDC’s are connected over MegaPort MCR

Activate VMware Site Recovery on VMware Cloud on AWS

To configure site recovery on VMware Cloud on AWS SDDC, go to SDDC page, click on the Add Ons tab and under the Site Recovery Add On, Click the ACTIVATE button

In the pop up window Click ACTIVATE again

This will deploy SRM on SDDC, wait for it to finish.

Deploy VMware Site Recovery Manager on Azure VMware Solution

In your Azure VMware Solution private cloud, under Manage, select Add-ons > Disaster recovery and click on “Get Started”

From the Disaster Recovery Solution drop-down, select VMware Site Recovery Manager (SRM) and provide the License key, select agree with terms and conditions, and then select Install

After the SRM appliance installs successfully, you’ll need to install the vSphere Replication appliances. Each replication server accommodates up to 200 protected VMs. Scale in or scale out as per your needs.

Move the vSphere server slider to indicate the number of replication servers you want based on the number of VMs to be protected. Then select Install

Once installed, verify that both SRM and the vSphere Replication appliances are installed.After installing VMware SRM and vSphere Replication, you need to complete the configuration and site pairing in vCenter Server.

  1. Sign in to vCenter Server as cloudadmin@vsphere.local.
  2. Navigate to Site Recovery, check the status of both vSphere Replication and VMware SRM, and then select OPEN Site Recovery to launch the client.

Configure site pairing in vCenter Server

Before starting site pair, make sure firewall rules between VMware cloud on AWS and Azure VMware solution has been opened as described Here and Here

To start pairing select NEW SITE PAIR in the Site Recovery (SR) client in the new tab that opens.

Enter the remote site details, and then select FIND VCENTER SERVER INSTANCES and select then select Remote vCenter and click on NEXT, At this point, the client should discover the VRM and SRM appliances on both sides as services to pair.

Select the appliances to pair and then select NEXT.

Review the settings and then select FINISH. If successful, the client displays another panel for the pairing. However, if unsuccessful, an alarm will be reported.

After you’ve created the site pairing, you can now view the site pairs and other related details as well as you are ready to plan for Disaster Recovery.

Planning

Mappings allow you to specify how Site Recovery Manager maps virtual machine resources on the protected site to resources on the recovery site, You can configure site-wide mappings to map objects in the vCenter Server inventory on the protected site to corresponding objects in the vCenter Server inventory on the recovery site.

  • Network Mapping
  • IP Customization
  • Folder Mapping
  • Resource Mapping
  • Storage Policy Mapping
  • Placeholder Datastores

Creating Protection Groups

A protection group is a collection of virtual machines that the Site Recovery Manager protects together. Protection group are per SDDC configuration and needs to be created on each SDDC if VMs are replicated in bi-directionally.

Recovery Plan

A recovery plan is like an automated run book. It controls every step of the recovery process, including the order in which Site Recovery Manager powers on and powers off virtual machines, the network addresses that recovered virtual machines use, and so on. Recovery plans are flexible and customizable.

A recovery plan runs a series of steps that must be performed in a specific order for a given workflow such as a planned migration or re-protection. You cannot change the order or purpose of the steps, but you can insert your own steps that display messages and run commands.

A recovery plan includes one or more protection groups. Conversely, you can include a protection group in more than one recovery plan. For example, you can create one recovery plan to handle a planned migration of services from the protected site to the recovery site for the whole SDDC and another set of plans per individual departments. Thus, having multiple recovery plans referencing one protection group allows you to decide how to perform recovery.

Steps to add a VM for replication:

there are multiple ways, i am explaining here one:

  • Choose VM and right click on it and select All Site Recovery actions and click on Configure Replication
  • Choose Target site and replication server to handle replication
  • VM validation happens and then choose Target datastore
  • under Replication setting , choose RPO, point in time instances etc..
  • Choose protection group to which you want to add this VM and check summary and click Finish

Cross-cloud disaster recovery ensures one of the most secure and reliable solutions for service availability, reason cross-cloud disaster recovery is often the best route for businesses is that it provides IT resilience and business continuity. This continuity is of most important when considering how companies operate, how customers and clients rely on them for continuous service and when looking at your company’s critical data, which you do not want to be exposed or compromised.

Frankly speaking IT disasters happen and happens everywhere including public clouds and much more frequently than you might think. When they occur, they present stressful situations which require fast action. Even with a strategic method for addressing these occurrences in place, it can seem to spin out of control. Even when posed with these situations, IT leaders must keep face, remain calm and be able to fully rely on the system they have in place or partner they are working with for disaster recovery measures.

Customer/Partner with VMware Cloud on AWS and Azure VMware Solution can build cross cloud disaster recovery solution to simplify disaster recovery with the only VMware-integrated solution that runs on any cloud. VMware Site Recovery Manager (SRM) provides policy-based management, minimizes downtime in case of disasters via automated orchestration, and enables non-disruptive testing of your disaster recovery plans.

Persistent Volumes for Tanzu on VMware Cloud on AWS using Amazon FSx for NetApp ONTAP

Featured

Amazon FSx for NetApp ONTAP provides fully managed shared storage in the AWS Cloud with the popular data access and management capabilities of ONTAP and this blog post we are going to use these volumes mount as Persistent Volumes on Tanzu Kubernetes Clusters running on VMware Cloud on AWS

With Amazon FSx for NetApp ONTAP, you pay only for the resources you use. There are no minimum fees or set-up charges. There are five Amazon FSx for NetApp ONTAP components to consider when storing and managing your data: SSD storage, SSD IOPS, capacity pool usage, throughput capacity, and backups.

The Amazon FSx console has two options for creating a file system – Quick create option and Standard create option. To rapidly and easily create an Amazon FSx for NetApp ONTAP file system with the service recommended configuration, I use the Quick create option.

The Quick create option creates a file system with a single storage virtual machine (SVM) and one volume. The Quick create option configures this file system to allow data access from Linux instances over the Network File System (NFS) protocol.

In the Quick configuration section, for File system name – optional, enter a name for your file system.

For Deployment type choose Multi-AZ or Single-AZ.

  • Multi-AZ file systems replicate your data and support failover across multiple Availablity Zones in the same AWS Region.
  • Single-AZ file systems replicate your data and offer automatic failover within a single Availability Zone, for this post i am creating in Single AZ
  • SSD storage capacity, specify the storage capacity of your file system, in gibibytes (GiBs). Enter any whole number in the range of 1,024–196,608.
  • For Virtual Private Cloud (VPC), choose the Amazon VPC that is associate with your VMware Cloud on AWS SDDC.

Review the file system configuration shown on the Create ONTAP file system page. For your reference, note which file system settings you can modify after the file system is created.

Choose Create file system.

Quick create creates a file system with one SVM (named fsx) and one volume (named vol1). The volume has a junction path of /vol1 and a capacity pool tiering policy of Auto.

For us to use this SVM, we need to get the IP address of SVM for NFS , Click on SVM ID and take a note of this IP, we will use this IP in our NFS configurations for Tanzu.

Kubernetes NFS-Client Provisioner

NFS subdir external provisioner is an automatic provisioner that use your existing and already configured NFS server to support dynamic provisioning of Kubernetes Persistent Volumes via Persistent Volume Claims. Persistent volumes are provisioned as ${namespace}-${pvcName}-${pvName}.

More Details – Explained here in detail https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner 

I am deploying this on my Tanzu Kubernetes cluster which is deployed on VMware Cloud on AWS.

  • Add the helm repo –
#helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/
  • Install using as below:
#helm install nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \
    --set nfs.server=<IP address of Service> \
    --set nfs.path=/<Volume Name>
#My command will be like this#
#helm install nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \
    --set nfs.server=172.31.1.234 \
    --set nfs.path=/vol1

Post installation of chart, you can check the status of Pod, it is not in running state then describe and see where it stuck

Finally, Test Your Environment!

Now we’ll test your NFS subdir external provisioner by creating a persistent volume claim and a pod that writes a test file to the volume. This will make sure that the provisioner is provisioning and that the Amazon FSx for NetApp ONTAP service is reachable and writable.

As you can see deployed application created an PV and PVC successfully on Amazon FSx for NetApp ONTAP

Describe the Persistent Volume to see the source of it, as you can see below it is created on NFS running on SVM having IP – 172.31.1.234

This is the power of VMware Cloud on AWS and AWS native services, customers can use any AWS native service without worrying about egress charges as well as security as everything is being configured and accessed over the private connections.

Building Windows Custom Machine Image for Creating Tanzu Workload Clusters

Featured

If your organisation is building an application based on Windows components (such as .NET Framework) and willing to deploy Windows containers on VMware Tanzu, this blog post is on how to build a Windows custom machine image and deploy windows Kubernetes cluster.

Windows Image Prerequisites 

  • vSphere 6.7 Update 3 or greater
  • A macOS or Linux workstation, Docker Desktop and Ansible must be installed on workstation
  • Tanzu Kubernetes Grid v1.5.x or greater
  • Tanzu CLI
  • A Recent Image of Windows 2019 (newer than April 2021) and must be downloaded from Microsoft Developer Network (MSDN) or Volume Licensing (VL) account.
  • The latest VMware Tools Windows ISO image. Download from VMware Tools
  • on vCenter, Inside a data store create a folder such as iso and upload windows ISO and VMware Tools iso

Build a Windows Image 

  • Deploy Tanzu Management Cluster with Ubuntu 2004 Kubernetes v1.22.9 OVA
  • Create a YAML file named builder.yaml with the following configuration, On my local system I have saved this yaml as builder.yaml
apiVersion: v1
kind: Namespace
metadata:
 name: imagebuilder
---
apiVersion: v1
kind: Service
metadata:
 name: imagebuilder-wrs
 namespace: imagebuilder
spec:
 selector:
   app: image-builder-resource-kit
 type: NodePort
 ports:
 - port: 3000
   targetPort: 3000
   nodePort: 30008
---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: image-builder-resource-kit
 namespace: imagebuilder
spec:
 selector:
   matchLabels:
     app: image-builder-resource-kit
 template:
   metadata:
     labels:
       app: image-builder-resource-kit
   spec:
     nodeSelector:
       kubernetes.io/os: linux
     containers:
     - name: windows-imagebuilder-resourcekit
       image: projects.registry.vmware.com/tkg/windows-resource-bundle:v1.22.9_vmware.1-tkg.1
       imagePullPolicy: Always
       ports:
         - containerPort: 3000

Connect the Kubernetes CLI to your management cluster by running:

#kubectl config use-context MY-MGMT-CLUSTER-admin@MY-MGMT-CLUSTER

Apply the builder.yaml file as below:

To ensure the container is running run below command:

List the cluster’s nodes, with wide output and take note of Internal IP address value of the node with ROLE listed as control-plane,master

#kubectl get nodes -o wide

Retrieve the containerd component’s URL and SHA, Query the control plane’s  nodePort  endpoint:

#curl http://CONTROLPLANENODE-IP:30008

Take note of containerd.path and containerd.sha256 values. The containerd.path value ends with something like containerd/cri-containerd-v1.5.9+vmware.2.windows-amd64.tar.

Create a JSON file in an empty folder named windows.json with the following configuration:

{
 "unattend_timezone": "WINDOWS-TIMEZONE",
 "windows_updates_categories": "CriticalUpdates SecurityUpdates UpdateRollups",
 "windows_updates_kbs": "",
 "kubernetes_semver": "v1.22.9",
 "cluster": "VSPHERE-CLUSTER-NAME",
 "template": "",
 "password": "VCENTER-PASSWORD",
 "folder": "",
 "runtime": "containerd",
 "username": "VCENTER-USERNAME",
 "datastore": "DATASTORE-NAME",
 "datacenter": "DATACENTER-NAME",
 "convert_to_template": "true",
 "vmtools_iso_path": "VMTOOLS-ISO-PATH",
 "insecure_connection": "true",
 "disable_hypervisor": "false",
 "network": "NETWORK",
 "linked_clone": "false",
 "os_iso_path": "OS-ISO-PATH",
 "resource_pool": "",
 "vcenter_server": "VCENTER-IP",
 "create_snapshot": "false",
 "netbios_host_name_compatibility": "false",
 "kubernetes_base_url": "http://CONTROLPLANE-IP:30008/files/kubernetes/",
 "containerd_url": "CONTAINERD-URL",
 "containerd_sha256_windows": "CONTAINERD-SHA",
 "pause_image": "mcr.microsoft.com/oss/kubernetes/pause:3.5",
 "prepull": "false",
 "additional_prepull_images": "mcr.microsoft.com/windows/servercore:ltsc2019",
 "additional_download_files": "",
 "additional_executables": "true",
 "additional_executables_destination_path": "c:/k/antrea/",
 "additional_executables_list": "http://CONTROLPLANE-IP:30008/files/antrea-windows/antrea-windows-advanced.zip",
 "load_additional_components": "true"
}

update the values in file as below:

Add the XML file that contains the Windows settings by following these steps:

  • Go to the autounattend.xml file on VMware {code} Sample Exchange.
  • Select Download.
  • If you are using the Windows Server 2019 evaluation version, remove <ProductKey>...</ProductKey>.
  • Name the file autounattend.xml.
  • Save the file in the same folder as the windows.json file and change permission of file to 777.

From your client VM run following command from folder containing your windows.json and autounattend.xml file:

#docker run -it --rm --mount type=bind,source=$(pwd)/windows.json,target=/windows.json --mount type=bind,source=$(pwd)/autounattend.xml,target=/home/imagebuilder/packer/ova/windows/windows-2019/autounattend.xml -e PACKER_VAR_FILES="/windows.json" -e IB_OVFTOOL=1 -e IB_OVFTOOL_ARGS='--skipManifestCheck' -e PACKER_FLAGS='-force -on-error=ask' -t projects.registry.vmware.com/tkg/image-builder:v0.1.11_vmware.3 build-node-ova-vsphere-windows-2019

NOTE: Before you run below command, make sure your workstation is running “Docker Desktop” as well “Ansible”

To ensure the Windows image is ready to use, select your host or cluster in vCenter, select the VMs tab, then select VM Templates to see the Windows image listed.

Use a Windows Image for a Workload Cluster

Use a Windows Image for a Workload Cluster, below yaml shows you how to deploy a workload cluster that uses your Windows image as a template. (This windows cluster is using NSX Advance LB)

#! ---------------------------------------------------------------------
#! non proxy env configs
#! ---------------------------------------------------------------------
CLUSTER_CIDR: 100.96.0.0/11
CLUSTER_NAME: tkg-workload02
CLUSTER_PLAN: dev
ENABLE_CEIP_PARTICIPATION: 'true'
IS_WINDOWS_WORKLOAD_CLUSTER: "true"
VSPHERE_WINDOWS_TEMPLATE: windows-2019-kube-v1.22.5
ENABLE_MHC: "false"

IDENTITY_MANAGEMENT_TYPE: oidc

INFRASTRUCTURE_PROVIDER: vsphere
SERVICE_CIDR: 100.64.0.0/13
TKG_HTTP_PROXY_ENABLED: false
DEPLOY_TKG_ON_VSPHERE7: 'true'
VSPHERE_DATACENTER: /SDDC-Datacenter
VSPHERE_DATASTORE: WorkloadDatastore
VSPHERE_FOLDER: /SDDC-Datacenter/vm/tkg-vmc-workload
VSPHERE_NETWORK: /SDDC-Datacenter/network/tkgvmc-workload-segment01
VSPHERE_PASSWORD: <encoded:T1V3WXpkbStlLUlDOTBG>
VSPHERE_RESOURCE_POOL: /SDDC-Datacenter/host/Cluster-1/Resources/Compute-ResourcePool/Tanzu/tkg-vmc-workload
VSPHERE_SERVER: 10.97.1.196
VSPHERE_SSH_AUTHORIZED_KEY: ssh-rsa....loudadmin@vmc.local

VSPHERE_USERNAME: cloudadmin@vmc.local
WORKER_MACHINE_COUNT: 3
VSPHERE_INSECURE: 'true'
ENABLE_AUDIT_LOGGING: 'true'
ENABLE_DEFAULT_STORAGE_CLASS: 'true'
ENABLE_AUTOSCALER: false
AVI_CONTROL_PLANE_HA_PROVIDER: 'true'
OS_ARCH: amd64
OS_NAME: photon
OS_VERSION: 3

WORKER_SIZE: small
CONTROLPLANE_SIZE: large
REMOVE_CP_TAINT: "true"

if your cluster yaml file is correct, you should see that new windows cluster has been started to deploy.

and after some time if should deploy cluster sucessfully.

In case if you are using NSX-ALB AKO or Pinniped and see that those pods are not running, please refer Here

NOTE – if you see this error during image build process : Permission denied: ‘./packer/ova/windows/windows-2019/autounattend.xml, check the permission of file autounattend.yaml

Tanzu Service on VMware Cloud on AWS – Installing Tanzu Application Platform

Featured

VMware Tanzu Application Platform is a modular, application detecting platform that provides a rich set of developer tools and a paved path to production to build and deploy software quickly and securely on any compliant public cloud or on-premises Kubernetes cluster.

Tanzu Application Platform delivers a superior developer experience for enterprises building and deploying cloud-native applications on Kubernetes. It enables application teams to get to production faster by automating source-to-production pipelines. It clearly defines the roles of developers and operators so they can work collaboratively and integrate their efforts.

Operations teams can create application scaffolding templates with built-in security and compliance guardrails, making those considerations mostly invisible to developers. Starting with the templates, developers turn source code into a container and get a URL to test their app in minutes.

Pre-requisite

  1. You should have created an account on Tanzu Network to download Tanzu Application Platform packages.
  2. Servers should have Network access to https://registry.tanzu.vmware.com
  3. A container image registry and access from K8s cluster, in my case i have installed “Harbor” with let’s encrypt certificate.
  4. Registry credentials with read and write access made available to Tanzu Application Platform to store images.
  5. Git repository for the Tanzu Application Platform GUI’s software catalogs, along with a token allowing read access.

Kubernetes cluster requirements

Installation requires Kubernetes cluster v1.20, v1.21, or v1.22 on Tanzu Kubernetes Grid Service on VMware Cloud on VMC as well as pod security policies must be configured so that Tanzu Application Platform controller pods can run as root. To set the pod security policies, run:

#kubectl create clusterrolebinding default-tkg-admin-privileged-binding --clusterrole=psp:vmware-system-privileged --group=system:authenticated

Install Cluster Essentials for VMware Tanzu

The Cluster Essentials for VMware Tanzu package simplifies the process of installing the open-source Carvel tools on your cluster. It includes a script that uses the Carvel CLI tools to download and install the server-side components kapp-controller and secretgen-crontroller on the targeted cluster. Currently, only MacOS and Linux are supported for Cluster Essentials for VMware Tanzu.

  • Sign in to Tanzu Network.
  • Navigate to Cluster Essentials for VMware Tanzu on VMware Tanzu Network.
  • on Linux, download tanzu-cluster-essentials-linux-amd64-1.0.0.tgz.
  • Unpack the TAR file into the tanzu-cluster-essentials directory by running:
#mkdir $HOME/tanzu-cluster-essentials
#tar -xvf tanzu-cluster-essentials-linux-amd64-1.0.0.tgz -C $HOME/tanzu-cluster-essentials
  • Configure and run install.sh using below commands:
#export INSTALL_BUNDLE=registry.tanzu.vmware.com/tanzu-cluster-essentials/cluster-essentials-bundle@sha256:82dfaf70656b54dcba0d4def85ccae1578ff27054e7533d08320244af7fb0343
#export INSTALL_REGISTRY_HOSTNAME=registry.tanzu.vmware.com
#export INSTALL_REGISTRY_USERNAME=TANZU-NET-USER Name
#export INSTALL_REGISTRY_PASSWORD=TANZU-NET-USER PASSWORD
#cd $HOME/tanzu-cluster-essentials
#./install.sh

now Install kapp & imgpkg CLI onto your $PATH using below commands:

sudo cp $HOME/tanzu-cluster-essentials/kapp /usr/local/bin/kapp
sudo cp $HOME/tanzu-cluster-essentials/imgpkg /usr/local/bin/imgpkg

For Linux Client VM: Install the Tanzu CLI and Plugins

To install the Tanzu Tanzu command line interface (CLI) on a Linux operating system, Create a directory named Tanzu and download tanzu-framework-bundle-linux from Tanzu Net and unpack the TAR file into the Tanzu directory and install using below commands:

#mkdir $HOME/tanzu 
#tar -xvf tanzu-framework-linux-amd64.tar -C $HOME/tanzu
#export TANZU_CLI_NO_INIT=true
#cd $HOME/tanzu 
#sudo install cli/core/v0.11.1/tanzu-core-linux_amd64 /usr/local/bin/tanzu
#tanzu version
#cd $HOME/tanzu
#tanzu plugin install --local cli all
#tanzu plugin list

Ensure that you have the acceleratorappspackagesecret, and services plug-ins installed. You need these plug-ins to install and interact with the Tanzu Application Platform.

Installing the Tanzu Application Platform Package and Profiles

VMware recommends install of Tanzu Application Platform packages by relocating the images to your registry from VMware Tanzu Network registry, this will ease the deployment process, so lets do it by logging in to Tanzu Net Registry, setting some env variables and relocate images.

#docker login registry.tanzu.vmware.com
#export INSTALL_REGISTRY_USERNAME=MY-REGISTRY-USER
#export INSTALL_REGISTRY_PASSWORD=MY-REGISTRY-PASSWORD
#export INSTALL_REGISTRY_HOSTNAME=MY-REGISTRY
#export TAP_VERSION=VERSION-NUMBER
#imgpkg copy -b registry.tanzu.vmware.com/tanzu-application-platform/tap-packages:1.0.2 --to-repo ${INSTALL_REGISTRY_HOSTNAME}/TARGET-REPOSITORY/tap-packages

This completes the download and upload on images to local registry.

Create a registry secret by running below command:

#tanzu secret registry add tap-registry \
  --username ${INSTALL_REGISTRY_USERNAME} --password ${INSTALL_REGISTRY_PASSWORD} \
  --server ${INSTALL_REGISTRY_HOSTNAME} \
  --export-to-all-namespaces --yes --namespace tap-install

Add the Tanzu Application Platform package repository to the cluster by running:

#tanzu package repository add tanzu-tap-repository \
  --url ${INSTALL_REGISTRY_HOSTNAME}/TARGET-REPOSITORY/tap-packages:$TAP_VERSION \
  --namespace tap-install

Get the status of the Tanzu Application Platform package repository, and ensure the status updates to Reconcile succeeded by running:

#tanzu package repository get tanzu-tap-repository --namespace tap-install

Tanzu Application Platform profile

The tap.tanzu.vmware.com package installs predefined sets of packages based on your profile settings. This is done by using the package manager you installed using Tanzu Cluster Essentials.Here is my full profile sample file:

buildservice:
  descriptor_name: full
  enable_automatic_dependency_updates: true
  kp_default_repository: harbor.tkgsvmc.net/tbs/build-service
  kp_default_repository_password: <password>
  kp_default_repository_username: admin
  tanzunet_password: <password>
  tanzunet_username: tripathiavni@vmware.com
ceip_policy_disclosed: true
cnrs:
  domain_name: tap01.tkgsvmc.net
grype:
  namespace: default
  targetImagePullSecret: tap-registry
learningcenter:
  ingressDomain: learningcenter.tkgsvmc.net
metadata_store:
  app_service_type: LoadBalancer
ootb_supply_chain_basic:
  gitops:
    ssh_secret: ""
  registry:
    repository: tap
    server: harbor.tkgsvmc.net/tap
profile: full
supply_chain: basic
tap_gui:
  app_config:
    app:
      baseUrl: http://tap-gui.tap01.tkgsvmc.net
    backend:
      baseUrl: http://tap-gui.tap01.tkgsvmc.net
      cors:
        origin: http://tap-gui.tap01.tkgsvmc.net
    catalog:
      locations:
        - target: https://github.com/avnish80/tap/blob/main/catalog-info.yaml
          type: url
  ingressDomain: tap01.tkgsvmc.net
  ingressEnabled: "true"
  service_type: LoadBalancer

save this file with modified values as per your environment, for more details about details of settings, check Here.

Install Tanzu Application Platform

finally lets install TAP, to install the Tanzu Application Platform package run below commands:

#tanzu package install tap -p tap.tanzu.vmware.com -v $TAP_VERSION --values-file tap-values.yml -n tap-install

to verify the packages installed, you can go to TMC and check there

or you an run below command to verify too

#tanzu package installed get tap -n tap-install

This completes the installation of Tanzu Application platform, now developer can: Develop and promote an application, Create an application accelerator, Add testing and security scanning to an application, Administer, set up, and manage supply chains.

Getting Started with Tanzu Service on VMware Cloud on AWS

VMware Tanzu Kubernetes Grid (TKG) is a multi-cloud Kubernetes footprint that customers/partners can run both on-premises in vSphere, VMware Cloud on AWS and the public cloud on Amazon EC2 and Microsoft Azure VMs.

TKG provides a Container orchestration through Kubernetes is now built into the vSphere 7 platform.As a VMware Cloud on AWS customer you can take advantage of this new functionality to build Kubernetes clusters in the same platform you’ve grown accustomed to using to manage your virtual infrastructure.

Take control of Cloud Resources and give freedom to Developers based on Personas

Virtualization Administrator: They will be able to define resource allocations and permissions for your users to create their own Kubernetes clusters according to their own specifications.Define access policies, storage policies, memory and CPU restrictions for teams needing Kubernetes access.

Developer or Platform Administrator: They can create new Kubernetes clusters within the defined access policies, upgrade those clusters and scale clusters within the approved resource allocations.

VMware recognizes that not all environments are running on top of vSphere. Tanzu Kubernetes Grid(TKG) leverages the same ClusterAPI engine as VMware Tanzu to manage cluster lifecycles, and can run on any infrastructure. VMware provides three variants of the TKG:

  • Tanzu Kubernetes Grid Multi-Cloud (TKGm): Installer driven wizard to set up Kubernetes environment to run across multi clouds for example: on AWS EC2 or Azure Native VMs
  • Tanzu Kubernetes grid Service (TKGS) aka vSphere With Tanzu: Natively integrated with vSphere7+ and available to customers at no extra cost for basic version on VCF on-prem as well as VMware Cloud on AWS
  • Tanzu Kubernetes Grid Integrated Edition: VMware Tanzu Kubernetes Grid Integrated Edition (formerly known as VMware Enterprise PKS) is a Kubernetes-based container solution with advanced networking, a private container registry, and life cycle management.

Enable Tanzu Service on VMware Cloud on AWS

Pre-requisite:

  • Make sure we have at-least three node SDDC is deployed and running with enough available resources (at least 112 GB of available memory, and has sufficient free resources to support 16 vCPUs)
  • Get Three CIDR blocks for the deployment. These three needs to be ranges that does not overlap with the Management CIDR or any other networks used on-prem or in the VMware Cloud on AWS SDDC.
  • You can activate Tanzu Kubernetes Grid in any SDDC at version 1.16 and later.
  •  If Edge cluster has been configured with medium configuration, then a SDDC cluster requires a minimum of three hosts for activation.
  • If Edge cluster has been configured with Large configuration, then a SDDC cluster requires a minimum of four hosts for activation.

Once pre-requisites are ready, go to VMware Cloud on AWS SDDC and click on “Activate the Tanzu Kubernetes Service”

Activation process will check required resources and will only move ahead if you have pre-requisite completed.

on the next screen:

  • Leave the Service CIDR as default or pick of your choice but non-overlapping and used for Tanzu supervisor services for the cluster
  • Enter the “namespace Network CIDR”, non-overlapping
  • Enter an ‘Ingress CIDR”, non-overlapping
  • Enter an “Egress CIDR”, non-overlapping
  • next Click on “Validate and Proceed”

NOTE: CIDR blocks of size 16, 20, 23, or 26 are supported, and must be in one of the “private address space” blocks defined by RFC 1918 (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16). 

and finally once validation is done, click on Activate Tanzu Kubernetes Grid

this will start activation process and you should be seeing “Activating Tanzu Kubernetes Grid” on your SDDC tile.This process should get completed within 20-30 minutes.

Such an easy process to make your SDDC enabled for running VMs and Containers together. When activation is completed, login to SDDC vCenter and click on Workload Management

Persona (Virtualization/vSphere Administrator) – vSphere Administrator create a vSphere Namespace on the Supervisor Cluster, sets resource limits to the namespace and permissions so that DevOps engineers can access it. he/she provide the URL of the Kubernetes control plane to DevOps engineers where they can run create their own Kubernetes clusters and run their workloads.

Step -1: Set permissions so that DevOps engineers can access the namespace.

From the Permissions pane, select Add Permissions.

Select an identity source, a user or a group, and a role, and click OK.

Step-2: Set persistent storage to the namespace.Storage policies that you assign to the namespace control how persistent volumes and Tanzu Kubernetes cluster nodes are placed within datastores in the SDDC environment.

From the Storage pane, select Add Storage.

Select a storage policy to control datastore placement of persistent volumes and click OK

The VM class is a VM specification that can be used to request a set of resources for a VM. The VM class is controlled and managed by a vSphere administrator, and defines such parameters as the number of virtual CPUs, memory capacity, and reservation settings. The defined parameters are backed and guaranteed by the underlying infrastructure resources of a Supervisor Cluster.

Workload Management offers several default VM classes. Generally, each default class type comes in two editions: guaranteed and best effort. A guaranteed edition fully reserves resources that a VM specification requests. A best effort class edition does not and allows resources to be overcommitted. Typically, a guaranteed type is used in a production environment.

vSphere Administrator can setup additional limits based on use cases and requirements.

Copy NameSpace URL by clicking on “Copy link” and give it to your DevOps/Platfrom admin)

Persona (DevOps/Platform Administrator)

How to Access and Work ?

Install a new VM (clientvm) or from their desktop/laptop, he/she can access this newly created “Namespace” and then create new Kubernetes cluster. When the new VM is provisioned, power it on and and ssh to it and Download the command line tools from vCenter, make sure the item below in red box is changed to your supervisor cluster address that you copied earlier by running:

#wget https://k8s.Cluster-1.vcenter.sddc-18-139-9-54.vmwarevmc.com/wcp/plugin/linux-amd64/vsphere-plugin.zip

Unzip using below command

Now lets login to the supervisor cluster by entering the following :

kubectl vsphere login --vsphere-username cloudadmin@vmc.local --server=https://k8s.Cluster-1.vcenter.sddc-18-139-9-54.vmwarevmc.com
enter the password for cloudadmin or any other user to complete the login

From here onwards, Devops can create their own K8s clusters and deploy applications, they can also utlize VMware’s multi-cloud mamagement platfrom to spin up kubernetes clusters using GUI.

For Devops to use GUI, vSphere Administrator need to Register VMware Cloud on AWS management cluster with Tanzu Mission Control. lets do that:

Register This Management Cluster with Tanzu Mission Control

Tanzu service ships with a namespace for Tanzu Mission Control. This namespace exists on the Supervisor Cluster where you install the Tanzu Mission Control agent.

The vSphere Namespace provided for Tanzu Mission Control is identified as svc-tmc-cXX

To integrate the Tanzu Kubernetes Grid Service with Tanzu Mission Control, install the agent on the Supervisor Cluster.

Register the Supervisor Cluster with Tanzu Mission Control and obtain the Registration URL. See Register a Management Cluster with Tanzu Mission Control.

On the client-vm, create a .yaml file with below content:

apiVersion: installers.tmc.cloud.vmware.com/v1alpha1
kind: AgentInstall
metadata:
  name: tmc-agent-installer-config
  namespace: <NAMESPACE captured in above step>
spec:
  operation: INSTALL
  registrationLink: <TMC-REGISTRATION-URL captured from TMC console>

Run this yaml file on using:

#kubectl create -f tmc.yaml

you can also check the status of TMC registration by running below command:

#kubectl get pods -n <ns name>

Now go back to Tanzu Mission Control and after some time you should see your Supervisor cluster ready

Devops/Platform admins are now ready to deploy your TKC clustes as well they can deploy containers, this completes this part of blog, in the next part i will write how to create TKC clusters, run applications within containers and how to expose to internet.

Configuring Ingress Controller on Tanzu Kubernetes Grid

Featured

Contour is an open source Kubernetes ingress controller providing the control plane for the Envoy edge and service proxy.​ Contour supports dynamic configuration updates and multi-team ingress delegation out of the box while maintaining a lightweight profile.In this blog post i will be deploying Ingress controller along with Load Balancer (LB was deployed in this post).you can also expose Envoy proxy as node port which will allow you to access your service on each k8s node.

What is Ingress in Kubernetes

“NodePort” and “LoadBalancer”  let you expose a service by specifying that value in the service’s type. Ingress, on the other hand, is a completely independent resource to your service. You declare, create and destroy it separately to your services.

Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource.An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name based virtual hosting

13

Pre-requisite

Before we begin we’ll need to have a few pieces already in place:

  • A Kubernetes cluster (See Here on How to Deploy TKG)
  • kubectl configured with admin access to your cluster
  • You have downloaded and unpacked the bundle of Tanzu Kubernetes Grid extensions which can be downloaded from here

Install Contour Ingress Controller

Contour is an Ingress controller for Kubernetes that works by deploying the Envoy proxy as a reverse proxy and load balancer.To install Contour follow below steps:

  • Downloaded VMware Tanzu Kubernetes Grid Extensions Manifest 1.1.0 in the pre-requisite stage ,move that to your Client VM and unzip it.
    • 1
  • You deploy Contour and Envoy directly on Tanzu Kubernetes clusters. You do not need to deploy Contour on management clusters.
  • Set the context of kubectl to the Tanzu Kubernetes cluster on which to deploy Contour.
    • #kubectl config use-context avnish-admin@avnish
  • First Install Cert-Manager on the k8 cluster
    • kubectl apply -f tkg-extensions-v1.1.0/cert-manager/
    • 2
  • Deploy Contour and Envoy on the cluster using:
    • #kubectl apply -f tkg-extensions-v1.1.0/ingress/contour/vsphere/
    • 3

This completes installation of Contour Ingress Controller on Tanzu Kubernetes Cluster.let’s deploy an application and test the functionality.

Deploy a Sample Application

Next we need to deploy at least one Ingress object before Contour can serve traffic. Note that as a security feature, Contour does not expose a port to the internet unless there’s a reason it should. A great way to test your Contour installation is to deploy the application

In this example we will deploy a simple web application and then configure load balancing for that application using the Ingress resource and will access it using load balancer IP/FQDN.This application is available within the same folder which we have downloaded from VMware inside example folder. Let’s deploy the application:

  • Run below command to deploy application which will create a new namespace named “test-ingress” , 2 services and one deployment.
    • #kubectl apply -f tkg-extensions-v1.1.0/ingress/contour/examples/common
    • 4

Very simple way of installing the application, now lets create Ingress resource.

Create Ingress Resource

Let’s imagine a scenario where the “foo” team owns http://www.foo.bar.com/foo and “bar” team owns http://www.foo.bar.com/bar. considering this scenario:

  • Here is Ingress Resource Definition for our example application:
    • apiVersion: extensions/v1beta1
      kind: Ingress
      metadata:
        name: https-ingress
        namespace: test-ingress
        labels:
          app: hello
      spec:
        tls:
        - secretName: https-secret
          hosts:
            - foo.bar.com
        rules:
        - host: foo.bar.com
          http:
            paths:
            - path: /foo
              backend:
                serviceName: s1
                servicePort: 80
            - path: /bar
              backend:
                serviceName: s2
                servicePort: 80
  • Lets deploy it using below command:
    • #kubectl apply -f tkg-extensions-v1.1.0/ingress/contour/examples/https-ingress
    • 5
    • Check the status and grub the External IP address of Contour “envoy” proxy.
    • 8
    • Add an /etc/hosts entry to above IP addresses to foo.bar.com

Test the Application

To access the application, browse the foo and the bar services from your desktop which has access to service network.

  • if you browse bar, you will get bar service responding
    • 9
  • if you browse foo, you will get foo service responding
    • 7

This completes the installation and configuration of Ingress on VMware Tanzu Kubernetes Grid K8 cluster. Contour is VMware’s open source version of Ingress controller and offers rich feature to consume and can be found Here and when customer chooses to Taznu portfolio , they get Contour as supported version from VMware.

Configure HCX for Cloud to Cloud Migrations

VMware HCX is an application mobility platform that is designed for simplifying application migration across cloud, workload rebalancing, and business continuity across data centers and across clouds.

Application migration

You can schedule and migrate thousands of vSphere virtual machines within and across data centers or Clouds without requiring a reboot.

Change platforms or upgrade vSphere versions

With HCX, you can migrate workloads from vSphere 5.x and non-vSphere (KVM and Hyper-V) environments within and across data centers or clouds to current vSphere versions without requiring an upgrade.

Workload rebalancing

Workload rebalancing provides a mobility platform across cloud regions and cloud providers to allow customers to move applications and workloads at any time to meet scale, cost management, compliance, and vendor neutrality goals.

HCX Deployment Types

  • Legacy vSphere to SDDC

    • In this deployment type, the HCX Manager at the Legacy site initiates Site Pairing, and the Service Mesh appliances initiate the Interconnect tunnels. The HCX Manager and Service Mesh appliances at the SDDC site are the receivers.
  • Legacy vSphere to Public Cloud

    • In this deployment type, the HCX Manager at the Legacy site initiates Site Pairing, and the Service Mesh appliances initiate the Interconnect tunnels. The HCX Manager and Service Mesh appliances at the Public Cloud are the receivers.
  • Cloud-to-Cloud

    • In this deployment type, the HCX Manager at the SDDC or Public Cloud can initiate or receive Site Pairing requests and act as the initiator or receiver during the HCX Interconnect tunnel creation.

In this post we are going to configure HCX cloud to cloud between two SDDC deployed on VMware Cloud on AWS

3Pre-requisite

  • Deploy SDDC on Site A
  • Deploy SDDC on Site B
  • Deploy HCX on Site A
  • Deploy HCX on Site B

Connectivity Options

  • Over EIP
  • Over Direct Connect

In this post i will be configuring HCX cloud to cloud migration over EIP as HCX sets up its own secure tunnel with military grade encryption, so it is secure to migrate over EIP but you can also setup using VPN connection for management network or you can setup using direct connect between two clouds also.

Open Firewall

Once both the SDDC and HCX has been deployed , go ahead inside “Network & Security” section and create firewall rules for HCX as below inside management gateway.

4

with above firewall rules , you should be able to access HCX over the public IP.

Site Pairing

  • On HCX console , go to “Site Pairing” and enter the second site HCX server name and credential.

This slideshow requires JavaScript.

  • if you want to do reverse migration then again do pairing from second site to primary site.

This slideshow requires JavaScript.

Create Service Mesh

  • Click Create Service Mesh
  • Select Sites:
    • Click each drop-down and select a source and destination site. Only connected Site Pairs are displayed
    • Click Continue.
  • Select Compute Profiles: 
    • Click the Select Source Compute Profile drop-down and select a Compute Profile.
    • Click the Select Remote Compute Profile drop-down and select a Compute Profile.
    • Click Continue.

NOTE – you can pickup existing compute profile or you can create a new profile.

  • By default, the HCX interconnect uses the Uplink Network Profiles defined in the Compute Profile for the source and destination sites. You can override the default As an example, an override can be useful in vCloud Director-based deployments where an uplink network that deviates from a common configuration created for an Organization to consume during the Service Mesh creation.
    • Click the Select Source Uplink Network Profile drop-down.
    • In VMC case we will choose “External Network” which is already having two public IPs.
    • Click Close.
    • Click Continue.
  • Configure the Network Extension appliances deployed per switch and click Continue.
  • Optionally Configure HCX Traffic Engineering features such as Traffic bandwidth control etc..
  • Review the topology and name the service Mesh and click Finish.
  • Wait for few minutes , this will deploy all the appliances and show connectivity across site is up.

This slideshow requires JavaScript.

if everything is done correctly , you should show all the HCX services are up and running.

7

Configure Network Extension

  • In the HCX dashboard, select Network Extension.
  • At the top of the page, select Extend Network.
  • Select one or more Distributed Port Groups or NSX Logical Switches.
  • Specify network segment which need to be extended.

This slideshow requires JavaScript.

Live Migrate a VM from one Cloud to another Cloud

  • Choose a VM which you want to migrate from one Cloud to another Cloud
  • Specify destination resource pool , storage , network etc and click on Migrate
  • check the progress of migration in vCenter , your application user even will not come to know that their application has been migrated to another cloud/sddc.

This slideshow requires JavaScript.

If you see with this HCX can easily migrate application based on requirement across cloud like AWS, IBM, Oracle or Azure or VCPP based or back to on-prem or hosted  clouds. Most important is that HCX solves problem of Cloud lock in. it gives freedom to customer to move VM across cloud with maximum security , most faster and without impact to applications.

11

please share feedback 🙂

 

 

 

Connect AWS Transit Gateway to VMware Cloud on AWS

This post is to deploy AWS transit Gateway and connect with VMware Cloud on AWS.

AWS Transit Gateway 

AWS Transit Gateway is a service that helps customers to connect their AWS VPC and their on-premises networks to a single gateway. As customers grow the number of workloads running on Native AWS or VMware Cloud on AWS , Customer need to be able to scale your networks across multiple accounts and Amazon VPCs/VMC to keep up with the growth.

With AWS TGW, you only have to create and manage a single connection from the central gateway in to each Amazon VPC , VMware Cloud on AWS , on-premises data center or even remote office across your network. Transit Gateway acts as a hub that controls how traffic is routed among all the connected networks which act like spokes

Now to setup Transit Gateway let’s go to VPC Dashboard inside your region where you want to deploy Transit Gateway and Click on create Transit Gateway:

3.png

Enter Required details like:

  • Name & Description
  • Amazon side ASN ( in between 64512 to 65535)
  • leave other as default or select/unselect based on your requirement.

1.png

This is will create a TGW, once TGW is created, wait for few minutes , it will show “available” in AWS console.

4.png

Connect TGW to VMware Cloud on AWS

Pervious step we created TGW and to attach to VMware Cloud on AWS or any other VPC , you need to go to “Transit Gateway  Attachment” and Click on “Create Transit Gateway Attachment”

6.png

On the new Transit Gateway Attachment page , input parameters as below:

  1. Transit Gateway ID – Choose TGW which you have created in previous step
  2. Attachment Type – VPN
  3. IP Address – get Public IP address from your VMC SDDC
  4. ASN – get ASN from your VM SDDC
  5. you can leave other things “Default” or enter based on specific requirement

7.png

Once created attachment , it will look like this:8.png

Once attachment is created , you can see it under “Site-to-Site VPN Connections” , from there follow below steps to download VPN config file:

  1. Go to Site-to-Site VPN Connections
  2. Select VPN Attachment which we created in previous step
  3. Click on “Download Configuration”
  4. Select “Generic”
  5. Click Download

9.png

Open downloaded config file and go to VMware Cloud on AWS SDDC and create a route based tunnel by input information from config file which we have downloaded in previous step.

  1. IKE Version – match in SDDC as per config file
  2. Copy the “Pre-shared Key” and paste in to SDDC “Preshared Key”
  3. Enter “Virtual Private Gateway” IP as “Remote Public IP” in side SDDC VPN config.
  4. Enter “Customer Gateway” as “BGP Local IP/Prefix Length” inside SDDC VPN config.
  5. Enter “Neighbor IP address” as “BGP Remote IP” inside SDDC VPN config.
  6. Enter “Virtual Private Gateway ASN” inside “BGP Remote ASN” inside SDDC VPN.

10.png

If every thing entered correctly , you will see , Tunnel and BGP is up and if tunnel is not up ensure Compute gateway firewall is configured appropriate as default Firewall rule for VPN in VMware cloud on AWS SDDC is “Drop”.

11.png

So tunnel and BGP is up. you can check connectivity between a VPC attached to TGW and SDDC, this should be up if you have populated proper routes in AWS route table.

 

 

Features of VMware Cloud on AWS

VMware Cloud on AWS enables operational consistency for customers of all sizes whether their workloads operate on-premises or in the public cloud. here i would be covering some of the great feature which i like most and will give you opportunity to understand and explore more..

Automated Cluster Remediation:

Let’s suppose in our on-prem environment we have 8 node cluster , one of the node goes down because of hardware failure , that’s where our struggle start to get required hardware from hardware vendor etc.. but most importantly we loose one host in our HA cluster and if this cluster was highly utilised then your application VM might start facing resource crunch and in my experience this might go for at least 3-4 days by the time you get hardware fix and put back the host in to the cluster.

Now see the power of VMware Cloud on AWS – failed hosts in a VMware SDDC are automatically detected by VMware and replaced with healthy hosts and process runs as below:

  • VMware Team detects Host failure or problem identified
  • New Host will be added in to the cluster and data from problematic host will be either rebuild or migrated.
  • Old host evacuated from the cluster and replaced by new host.

Scale as per your convenience:

One of the major challenges in traditional data centers is finding the right balance between hardware and workload utilization.

VMware Cloud on AWS enables you to quickly scale up to ensure that you always have enough capacity to run your workloads during volume spikes and quickly scale down to ensure that you are not paying for hardware that is not being used. This feature provides higher availability with lower overall costs.

aws4

you have option to add and remove cluster as well as Host or you can enable Elastic Distributed Resources Scheduler (EDRS) , which is a policy-based solution that automatically scales a vSphere Cluster in VMware Cloud on AWS based on utilization. EDRS monitors CPU, memory, and storage resources for scaling operations. EDRS monitors the vSphere cluster continuously, and each 5 minutes EDRS runs the algorithm to determine if scale-out or scale-in operations is required.

vCenter Hybrid Linked Mode:

Hybrid Linked Mode allows you to link your VMware Cloud on AWS vCenter Server instance with an on-premises vCenter Single Sign-On domain and If you link your cloud vCenter Server to a domain that contains multiple vCenter Server instances linked using Enhanced Linked Mode, all of those instances are linked to your cloud SDDC.

You have two options for configuring Hybrid Linked Mode. You can use only one of these options at a time.

  • You can install the Cloud Gateway Appliance and use it to link from your on-premises data center to your cloud SDDC. In this case, Active Directory groups are mapped from your on-premises environment to the cloud.

  • you can link from your cloud SDDC to your on-premises data center. In this case, you must add Active Directory as an identity source to the cloud vCenter Server.

Using Hybrid Linked Mode, you can:

  • View and manage the inventories of both your on-premises and VMware Cloud on AWS data centers from a single vSphere Client interface, accessed using your on-premises credentials.

  • Migrate workloads between your on-premises data center and cloud SDDC.

  • Share tags and tag categories across vCenter Server instances.

Well Defined Separation of Duty for VMware and Customer Teams:

Amazon in discussion with VMware performs the following  tasks:

Hardware refresh , failed component replacement , bios upgrade and underline firmware patching will be done by AWS based on VMware compatibility list and this allow customer not to worry about this tedious exercise, compatibility issues and dedicated skill resources.

VMware Experts perform the following maintenance tasks:

  • Backup and restore of VMware appliances and infrastructure  like vCenter, NSX Manager,PSC etc…
  • Patching VMware Cloud on AWS components like vSphere, ESXi drivers, vSAN, NSX, SDDC console etc…this helps customers to just focus of App VM and their business , leave their virtual infrastructure maintenance to experts.
  • Providing VMware Tools patches through vSphere and will be available to your virtual machines , now customer is free to
  • Host and infrastructure VM monitoring

Customer’s Administrator are responsible for the following tasks:

  • Customer administrator manages backup and restoration of your workload VMs and applications.
  • Patching inside VM like guest OS, applications etc..
  • Upgrading VMware Tools installed on workload VMs
  • Monitoring of the your workload VMs and applications
  • Keeping VM templates and content library files updated so that new vms are deployed with latest/updated/patched updated master templates.
  • Manage and monitoring user access and monitoring of resource utilization and charges of integrated AWS if consuming.

Outages, Scheduled Maintenance, and Health Service Information:

VMware has hosted a separate website to display the current status of VMware Cloud services at https://status.vmware-services.io/ , you can subscribe to updates.

Apart from VMware Cloud on AWS service, this website reports for below services also:

  • VMware AppDefense
  • VMware Cost Insight
  • VMware Discovery
  • VMware Kubernetes Engine
  • Log Intelligence
  • VMware Network Insight

NSX Hybrid Connect

NSX Hybrid Connect enables cloud on-boarding without retrofitting source infrastructure and supports migration from vSphere 5.1 or later to VMware Cloud on AWS without introducing application risk and complex migration assessments.NSX Hybrid Connect includes:

  • vSphere vMotion
  • bulk migration
  • high throughput network extension
  • WAN optimization
  • traffic engineering
  • load balancing
  • automated VPN with strong encryption
  • secured data center interconnectivity with built-in hybrid abstraction and hybrid interconnects.

aws1.png

VMware Site Recovery

VMware Site Recovery for VMware Cloud on AWS is separately purchased item that communicates with separately licensed VMware Site Recovery Manager and VMware vSphere Replication instances. Recovery can occur from on-premises to AWS or AWS SDDC to AWS SDDC. VMware Site Recovery can protect vCenter Server version 6.7, 6.5, and 6.0 U3.

aws2.png

Consumption of AWS Native Services with VMware Cloud on AWS

The partnership between VMware and Amazon increases the catalog of solutions readily available to all VMware Cloud on AWS users. Some of the popular AWS solutions are listed below:

  • Simple Storage Service (S3): Highly available, highly durable object storage service.
  • Glacier: Highly durable, high latency archive storage used mostly for backup.
  • EC2: AWS flagship compute platform.
  • VPC: Networking solution of AWS solutions both internal and external.
  • CloudWatch: Monitoring for AWS solutions.
  • IAM: Identity and Access Management solution of AWS.
  • AWS Database Services: Wide range of  DB service like: Relational Database Service (RDS), DynamoDB (NoSQL Database Service), RedShift (data warehouse for data from relational databases for analytics)
  • Simple Queue Service (SQS): Fully managed message queues for microservices, distributed systems, and server-less applications.
  • Route 53: (DNS) Domain name provider and services.
  • Elasti-Cache: Managed, in-memory data store services.

Simple and feature-rich Web Interface for Network Services

Customer can easily consume Network services with few clicks , you need not to be network expert and strong command line hands-on experience. just few clicks and your IPsec VPN, L2 VPN , NAT , Edge FW rules , getting public IP from amazon all are ready to consume.

aws3.png

i have covered few features of VMware Cloud on AWS , if you wants to dirty your hands , go ahead and login to http://labs.hol.vmware.com  and if your organisation wants to test the feature and ease of consumption , there is one host option is there , By deploying a 1-node SDDC, you will be able to test out the features and functionality of VMware Cloud on AWS at a fraction of the cost. These 1-node SDDC’s are fully self-service, paid for by credit card (or HPP/SPP credits), and deployed in just under two hours.

Hope this helps you in understanding feature of VMware Cloud on AWS  better 🙂

 

 

Getting Started with VMware Cloud on AWS

What is VMware Cloud on AWS ?

VMware Cloud on AWS allows the use of familiar VMware products while leveraging the benefits of a public cloud. A hybrid infrastructure can be created between an on-premises VMware vSphere software-defined data center (SDDC) and a VMware Cloud on AWS SDDC.

VMware Cloud on AWS allows you to create vSphere data centers on Amazon Web Services and these vSphere data centers include vCenter Server for managing your data center, vSAN for storage, and VMware NSX for networking. you can use Hybrid Linked Mode, if you want to connect an on-premises data center to your cloud SDDC, and manage both from a single vSphere Client interface. Hybrid Linked Mode is like existing Enhanced Linked mode additionally it support cross SSO connection and vMotion.

VMware Cloud on AWS offers the following benefits:

  • It reduces capital and operational expenditures.
  • It reduces time to market for new applications.
  • It helps in enhanced scalability of applications in reduced time frames.
  • It helps in achieving greater availability of applications.
  • Your Application will have reduced recovery time objective (RTO).
  • and the most important one , it helps you to reduce staff time performing maintenance operations.

VMware Cloud Foundation

VMware Cloud Foundation is the unified SDDC platform that bundles vSphere, vSAN, and VMware NSX into a natively integrated stack to deliver enterprise-ready cloud infrastructure for the private and public cloud.

Secret sauce behind cloud foundation is VMware SDDC Manager which manages the initial configuration of the Cloud Foundation system, creates and manages workload domains, and performs life cycle management to ensure that the software components remain up to date. SDDC Manager also monitors the logical and physical resources of Cloud Foundation.

VMware Cloud on AWS is powered by VMware Cloud Foundation.

So in nutshell VMware Cloud on AWS uses VMware Cloud Foundation and VMware Validated Design to provide VMware SDDC and other migration solution on the hardware of AWS.

All components of this solution are delivered, operated, and supported by VMware Global Support Services. VMware fully certifies and supports all hardware and software components of this service. The customers are facing issue around managing firmware , patches , upgrades of underline infrastructure, now with VMware Cloud on AWS , VMware removed the burden of managing software patches, updates, or upgrades.  all this will be managed and maintained by VMware itself.

Use Cases

Data Center Extension:

  • DC extension of the on-premises data center to the public cloud to expand resource capacity, increase disaster avoidance and recovery options, or localize application instances to new geographic regions. For Example, one Organisation which is successful in one particular region and wants to grow their foot print across another region, in-stead of arranging data center space , hardware etc , this organisation can focus on core business and order IT infrastructure on VMware on AWS and just clone / migrate application vms to this localized data center.

Data Center Consolidation:

  • Maintaining a Datacenter is not easy, you have to take care of multi-source power , cooling , power backups , people , access management,BMS operations, Real state etc.., so instead of you managing Data Center , let VMware maintain your data center by consolidation of the on-premises data center costs by migrating applications from on-premises data center to the public cloud to reduce data center costs, prevent costs from growing, or close data centers entirely.

Data Center Peering:

  • Peering private and public cloud to allow for moving workloads between clouds. For example, moving applications from development or test to production or vice versa. or running CI/CD across private and public cloud.

This gives you basic understanding about what is VMware on AWS , in next few posts i will be covering how to install and configure this service.