Kudos to William Lam for the release of this Fling, a really powerful way to speed up the installation of TKG and go straight to showcase its power and flexibility.
For the scope of the demo I had to deliver, I decided to follow William’s demo script, provided with the Fling’s instructions, as I believe it really fits for my demo purpose.
Tanzu Kubernetes Grid Overview
VMware Tanzu Kubernetes Grid is an enterprise-ready Kubernetes runtime that packages open source technologies and automation tooling to help you get up and running quickly with a scalable, multi-cluster Kubernetes environment.
In VMware Cloud on AWS, the choice has been made to support the “Tanzu Kubernetes Grid Plus” offering. The “Plus” is an addon to a traditional TGK installation which means the customer will get support for several additional open-source products, together with support from a specialized team of Customer Reliability Engineers (CRE) dedicated to support TKG+ customers. In this knowledge base article you can find a detailed comparison between TKG and TKG+.
To setup TKG, we are leveraging a bootstrap environment that can live on your laptop, in a VM, in a Server etc. and it’s based on kind (Kubernetes in Docker). Basically, with kind we are leveraging Kubernetes to deploy our TGK Management Cluster. Using the Demo Appliance for Tanzu Kubernetes Grid, we have all the components required to setup the bootstrap environment ready to be used, and we can simply focus on the TGK deployment itself. I really hope to see the Demo Appliance being productized and as such becoming supported to deploy production environments.
Once the TKG Management Cluster is in place, we will leverage Cluster API through the TKG Command Line Interface to manage the creation and lifecycle of all our TKG Workload Cluster where our applications will live. I believe the following picture could be well descriptive of the concept: we leverage Kubernetes to create a Management Cluster, and we’ll manage all our Workload Clusters from the Management Cluster. (Thanks again to William for the nice diagram).
Now, let’s go straight to the steps needed to implement TKG on VMC and see it in action: from 0 to Kubernetes on VMC in less than 30 minutes!
Setup Content Library to sync all TKG Virtual Appliance templates
Open the SDDC’s vCenter and from the “Home” screen, select “Content Libraries”.
Click on the “+” button to start the “New Content Library” wizard. In the “Name and location” window, we can enter the name of the new Content Library and click “NEXT”.
In the “Configure content library” window, check the “Subscribed content library” radio button, input the following subscription URL: “https://download3.vmware.com/software/vmw-tools/tkg-demo-appliance/cl/lib.json“, check the option to download content immediately, then click “NEXT”.
Accept the authenticity of the subscription Host clicking “YES”.
In the “Add storage” window, select the “WorkloadDatastore”, then click “NEXT”.
In the “Ready to complete” window, review the settings then click “FINISH”.
The new Content Library is now created, select it and move to the “OVF & OVA Templates” tab, where we can wait for our templates to be downloaded.
Once the download is completed, right-click on the “TKG-Demo-Appliance_1.0.0.ova” and select “New VM from This Template”. This will start the new VM creation wizard.
Deploy the Demo Appliance for Tanzu Kubernetes Grid
Select a name for the new Virtual Machine, select a location (VM Folder) then click “NEXT”.
Select the destination Resource Pool (by default, Compute-Resource-Pool in VMC) and click “NEXT”.
Review the details and, if everything is fine, click on “NEXT”.
Select “WorkloadDatastore” as the target storage, optionally choose a specific Storage Policy to apply to the new VM, then click “NEXT”.
Select the destination network for the new VM, then click “NEXT”.
In the “Customize template” window, configure the new VM IP address, Gateway, DNS, NTP, password, optional proxy Server, then click “NEXT”.
Review all the settings, then click “FINISH” to start the TKG Demo Appliance VM creation.
Before moving to the Management Cluster setup, we need to have in place two Virtual Machine Templates that will be used to deploy the environment. Back to the same Content Library we created before, where we have our TKG Demo Appliance template, we must deploy two new VMs by using the templates “photon-3-capv-haproxy-v0.6.3_vmware.1” and “photon-3-v1.17.3_vmware.2” and, once the two VMs are created, convert them to vSphere Templates, as we’ll need these in the next steps. Once done, we are ready to proceed.
TKG Management Cluster Setup
We can locate our newly created Demo Appliance for TKG in the vCenter Inventory, together with all the others VMs and Templates. We need to take note of the IP address or DNS name assigned to the TKG Demo Appliance as we’ll access it with SSH and we’ll configure everything we need by using both the tkg and kubectl CLI.
Now that we have the IP address or the DNS name of the Appliance, let’s connect to it via SSH. Once connected, we can start the setup of our TKG Management Cluster typing the command “tkg init –ui” followed by Enter. This will start the TKG Management Cluster setup. As the Demo Appliance doesn’t have a UI, we’ll need to open a second session to it, setting up SSH port redirection to being able to use our local browser to access the TKG Installer Web UI.
Once port redirection is in place, we can access the TKG Installer wizard by navigating to “http://localhost:8080” on our local machine. Here, we can select the “DEPLOY ON VSPHERE” option.
The first step is to input the vCenter Server IP or DNS name, and credentials, then click “CONNECT”.
We can safely ignore the notification about vSphere 7.0.0 and click “PROCEED”. The reason we are getting this information message is that VMware Cloud on AWS, following a different release cycle than the commercial edition of vSphere, already have vSphere 7 deployed in its SDDCs.
The second step is to select the vSphere Datacenter inventory item where we want to deploy our TKG Management Cluster. I’m not providing a real SSH Public Key in my example, but we should provide a “real” key if we want to easily connect to any Kubernetes node once deployed. Click “NEXT”.
In the “Control Plane Settings”, we can choose between several instance types and sizes based on our requirements. For the goal of this demo, it’s safe to pick the “Development” (single control plane node) flavour and the “medium” instance type. Input a name for the Management Cluster and select the API Server Load Balancer template. This will be the template we’ve created before starting from the “photon-3-capv-haproxy-v0.6.3_vmware.1” image. Click “NEXT” when done.
In the next step we must select the Resource Pool, VM Folder and Datastore where the Management Cluster will be created. Then click “NEXT”.
Select the SDDC network that will host our TKG VMs, leave the default CIDR selected for the Cluster Service CIDR and the Cluster Pod CIDR if you don’t have any specific requirement to change the default values. Click “NEXT” when done.
Select the vSphere Template configured with the required Kubernetes version. This is the template we’ve created before starting from the “photon-3-v1.17.3_vmware.2” image we’ve imported in our Content Library. Click “NEXT” when done.
With all the required fields compiled (green check mark), we can click on “REVIEW CONFIGURATION”.
We can then click on “DEPLOY MANAGEMENT CLUSTER” to start the deployment of our TKG Management Cluster. This will approximately take 6 to 8 minutes.
After all the configuration steps are completed, we will get an “Installation complete” confirmation message. Our TKG Management Cluster is now ready to be accessed. It’s safe to close the browser window and move back to the Demo Appliance for TGK SSH session we have previously opened.
Looking at the vCenter Inventory, we can easily see the Management Cluster VMs we’ve just deployed.
Back in the SSH session, we automatically found ourselves in the context of the TKG Management Cluster. Here, leveraging the TKG Command Line Interface, we can create and manage the lifecycle of our Workload Clusters. Let’s create our first Workload Cluster using the command “tgk create cluster –plan=<dev_or_prod> <cluster-name>“. In my example I’m using the “dev” template and a cluster name of “it-tkg-wlc-01“. You can see in the low right end of the screenshot the VMs being deployed with the chosen name.
Once our Kubernetes Workload Cluster is created, we automatically find ourselves in the context of the new Cluster and we can immediately start deploying our applications.
I would like to leverage the YELB application for this Kubernetes demo, to deploy the application I’m starting by cloning the YELB git repository to my local machine. Then, from the directory where we cloned the git repository (in my case “~/demo/yelb“), I create a new namespace with the command “kubectl create namespace yelb” followed by the resource creation with the command “kubectl apply -f yelb.yaml“.
As we have chosen to deploy a Kubernetes Cluster with only a single Control Plane and a single Node, it’s easy to get the IP address needed to access our application as the Control Plane doesn’t host running pods. With the command “kubectl get nodes -o wide” we can obtain the external IP address of our single node, which for sure is hosting the running yelb pods.
Once we have the external IP address of the node hosting the application, we can point our browser to that IP on port 30001, and here we can see our application is working and ready for the demo.
This concludes this post, we’ve seen how we can quickly deploy Tanzu Kubernetes Grid on top of our VMware Cloud on AWS Infrastructure. This enables us to have a very powerful solution where Virtual Machines, Containers (orchestrated by Kubernetes) and native AWS services can coexist and be very well integrated to design your application modernization strategy.
In one of the next blog posts, I’ll show you how we can leverage such an integrated solution to quickly lift and shift an application, and subsequently modernize it.
Cloud-based iSCSI block storage volumes for Workloads in VMware Cloud on AWS
In this follow-up article I’d like to show you again how the native integration between AWS Services and VMware Cloud on AWS can provide you a lot of powerful capabilities.
We can leverage the AWS Storage Gateway – Volume Gateway to provide our workloads with Cloud-based iSCSI block storage volumes. This enables us to re-think our approach to the Cloud when it comes to migrate storage and store backups.
The most common use cases for the Volume Gateway are: Hybrid File Services, Backup to Cloud, DR to Cloud, Application migration.
Architecture and Service Description
In the following picture you can see the Architecture of the solution we are about to implement. AWS Storage Gateway is a Virtual Appliance that exposes iSCSI block volumes to VMware workloads. It has been historically deployed on-premises, but now that we have VMware Cloud on AWS, we can take advantage of the high speed and low latency connection provided by the ENI that connects our SDDC with all the native AWS services in the Connected VPC. AWS Volume Gateway comes in two modes: stored and cached. In stored mode, the entire data volume is available locally and asynchronously copied to the cloud. In cached mode, the entire data volume is stored in the cloud and frequently accessed portions of the data are cached locally by the Volume Gateway appliance. By “stored in the Cloud” in this context I mean S3. Volume Gateway is a Managed Platform Service that is using S3 in the backend, even if S3 is completely abstracted from the customer. For this reason, we’ll not be able to see which bucket is in use by the Volume Gateway nor to manipulate in any way the S3 objects. If you’re looking for a solution that maps your files 1:1 with S3 objects, check out my previous blog post about the File Gateway.
Basically, with the Volume Gateway we are providing iSCSI block storage volumes backed by S3 to our workloads hosted in VMware Cloud on AWS.
This is the High Level Architecture of the solution we are implementing:
Get the VPC Subnet and Availability Zone where the SDDC is deployed
We need to accomplish some preliminary steps to gather some information about our SDDC, that we’ll need later. In addition, we need to configure some Firewall Rules to enable communication between our SDDC and the Connected VPC where we’ll configure our Gateway Endpoint.
As a first step, we need to access our VMware Cloud Services console and access VMware Cloud on AWS.
The second step is to access our SDDC clicking on “View Details”. Alternatively, you can click on the SDDC name.
Once in our SDDC, we need to select the “Networking & Security” tab.
In the “Networking & Security” tab, we must head to the “Connected VPC” section, where we can find the VCP subnet and AZ that we did choose upon deployment of the SDDC. Our SDDC resides there, therefore every AWS service we will configure in this same AZ will not cause us any traffic charge. We need to keep note of the VPC subnet and AZ as we’ll need this information later.
Create SDDC Firewall Rules
The second preliminary step we need to perform is to enable bi-directional communication between our SDDC and the Connected VPC through the Compute Gateway (CGW). I’ll not go through the details of the Firewall Rules creation in this post, but simply highlight the result: for the sake of simplicity, in this example we have a rule allowing any kind of traffic from the Connected VPC Prefixes and S3 Prefixes to any destination, and vice-versa. As you can see, both rules are applied to the VPC Interface which actually is the cross-Account ENI connecting the SDDC to the Connected VPC. If we would like to configure more granular security, we could do this leveraging the information highlighted in the AWS documentation here: https://docs.aws.amazon.com/storagegateway/latest/userguide/Resource_Ports.html
Let’s now have a look at the actual implementation of the Volume Gateway in VMC and how it works.
Create the Storage Gateway VPC Endpoint
First, we need to access the AWS Management Console for the AWS Account linked to the VMware Cloud on AWS SDDC and select “Storage Gateway” from the AWS Services (hint: start typing in the “Find Services” field and the relevant services will be filtered for you). Make sure you are connecting to the right Region where your SDDC and Connected VPC are deployed.
If you don’t have any Storage Gateway already deployed, You will be presented with the Get Started page. Click on “Get Started” to create your Storage Gateway. (hint: if you already have one or more Storage Gateways deployed, simply click on “Create Gateway” in the landing page for the service).
You will be presented with the Create Gateway wizard. The first step is to choose the Gateway type. In this scenario, we are focusing on iSCSI block volumes and we will select “Volume Gateway”. We’ll additionally select “Cached Volumes” to benefit from low-latency local access to our most frequently accessed data, and then click “Next”.
The next step is to download the OVA image to be installed on our vSphere Environment in VMC. Click on “Download Image”, then click “Next”.
Deploy the Storage Gateway Virtual Appliance in VMware Cloud on AWS
Now that we have download the ESXi image, we’ll momentarily leave the AWS Console and move to our vSphere Client, to install the Storage Gateway Virtual Appliance. I’m assuming here that we have the VMware Cloud on AWS SDDC already deployed and we have access to our vCenter in the Cloud. SDDC deployment is covered in detail in one of my previous posts here. Head to the Inventory Object where you want to deploy the Virtual Appliance (e.g. Compute-ResourcePool), right click and select “Deploy OVF Template…”
Select the previously downloaded Virtual Appliance. This is named “aws-storage-gateway-latest.ova” at the time of this writing. Click “Next”.
Provide a name for the new Virtual Machine, then click “Next”.
Confirm the Compute Resource where you want to deploy the Virtual Appliance (e.g. Compute-ResourcePool). Then, click “Next”.
In the “Review details” page, click “Next”.
Select the Storage that will host our Virtual Appliance. In VMware Cloud on AWS this will be “WorkloadDatastore”. Click “Next”.
Select the destination network for the Virtual Appliance and click “Next”.
In the “Ready to Complete” window, click “Finish” to start the creation of the Storage Gateway Virtual Appliance.
We now have our Storage Gateway Appliance in the SDDC’s vCenter inventory. Let’s edit the VM to add some storage to be used for caching. To clarify, in addition to the 80 GB base VMDK, the Storage Gateway Appliance must have at least two additional VMDKs of at least 150 GB in size each, one to be used for caching and another one to be used as an upload buffer. You can see all the Storage Gateway requirements here: https://docs.aws.amazon.com/storagegateway/latest/userguide/Requirements.html Select the Volume Gateway VM, select “ACTIONS” then “Edit Settings…”.
In the “Edit Settings…” window, under Virtual Hardware, add two new hard disk devices by clicking on “ADD NEW DEVICE” and selecting “Hard Disk”.
Select a size of at least 150 GB for each of the new disks. Then click “OK”.
Create VPC Endpoint for Storage Gateway
We can now switch back to the AWS Console, where we should be in the “Service Endpoint” page of the Storage Gateway deployment wizard. In case we’re still in the “Select Platform” window, we can simply click “Next”. As we want to have a private, direct connection between the Storage Gateway vApp and the Storage Gateway Endpoint, we will select “VPC” as our Endpoint Type. Click on the “Create a VPC endpoint” button to open a new window where we can create our endpoint. A VPC Endpoint is a direct private connection from a VPC to a native AWS Service. With a VPC Endpoint in place, we don’t need an Internet Gateway, NAT Gateway or VPN to access AWS Services from inside our VPC, and instances in the VPC do not require public IP addresses. A VPC Endpoint for Storage Gateway is based on the PrivateLink networking feature and it is an Interface-based (ENI) Endpoint. If you have already created a Storage Gateway Endpoint based on my previous blog post on File Gateway integration with VMware Cloud on AWS, you can skip the next steps and input directly the VPC endpoint IP address or DNS name in the “VPC endpoint” field.
In the “Create Endpoint” wizard, we have a couple of choices we must make for our Storage Gateway Endpoint: Service category will be “AWS Services”, then we’ll select the same AZ and subnet where our SDDC is deployed (note: we could select more than one AZ and subnet for better resilience of the endpoint, but we would potentially incur in cross-AZ charges and it could make no sense to have cross-AZ resiliency of the Volume Gateway, unless we also deploy our SDDC in a Stretched Cluster configuration between two AZs). Lastly, we can leave the default security group selected and click on “Create endpoint”.
Once the deployment is finished, we’ll be able to see our VPC Endpoint available in the AWS Console. You can see here that the Endpoint type is “Interface”.
We can now switch back to the Volume Gateway creation wizard, but before that we must take note of the IP address assigned to our Storage Endpoint. We could use either the DNS name or the IP address to configure our Storage Gateway, I’m choosing to use the IP address in this example, let’s see where we can find the IP address assigned to the ENI (Storage Endpoint). This is visible in the “Subnets” tab, where one ENI is created for each Subnet the VPC Endpoint is attached to.
We can now input the IP address of our VPC Endpoint in the Storage Gateway creation wizard. Then, click “Next”.
This brings us to the “Connect to Gateway” window. Here, we can input the IP address assigned to the Storage Gateway VM deployed in VMC. Then, click on “Connect to gateway”.
The next step in the wizard is to activate our Gateway. We can review the pre-compiled fields and optionally assign a Tag to our Gateway. When done, click on “Activate Gateway”.
We’ll get a confirmation message that our Storage (Volume) Gateway is now active. Additionally, we are presented with the local disk configuration window. In this window we must ensure that one or more disks are allocated to cache the most frequently accessed files locally on the Volume Gateway itself, and at least one disk must be configured as the upload buffer. When done, click on “Configure logging”.
In this example we are not configuring Cloudwatch logging for this Volume Gateway, for this reason we can leave the default of “Disable Logging”. We can now click on “Verify VMware HA” to verify that our Volume Gateway can be correctly protected by VMware HA. In VMC we have both VM level and Host level protection, and all the settings are already pre-configured based on best practices. In VMC, vSphere HA is perfectly configured out-of-the-box to provide high availability to our Volume Gateway. Let’s click on “Verify VMware HA” to actually see this in action.
We are now getting a message asking us to confirm that we want to test VMware HA and also providing us with a reminder that this step is only needed if the Volume Gateway is deployed on a VMware HA enabled Cluster. Click on “Verify VMware HA”.
This starts the HA test, simulating a failure inside the Volume Gateway VM causing it to be restarted by VMware HA. We are immediately notified that the test is in progress.
When the test completes, we are notified that it has completed successfully. We can now click on “Save and continue” to close the wizard.
This brings us back to the AWS Console where we can see that our Volume Gateway (note that the type is reported as “Volume cached”) has been successfully created.
Create a new iSCSI Volume
The next step is to create a Storage Volume to be mounted as block storage by one of our workloads hosted in VMC. We’ll set 10 GiB as the capacity for this example, and check the “New empty volume” radio button. We’ll set a name for our volume in the “iSCSI target name” field, then click “Create volume”.
The wizard automatically brings us to the “Configure CHAP authentication” window. We can skip this configuration if it’s safe for us to accept connections from any iSCSI initiator. If we want to be more accurate, we can add the list of iSCSI initiators authorized to mount this volume, with a shared secret.
Our new iSCSI volume is now ready to be mounted inside a Guest Operating System running in a VM hosted in VMC. We will use the Target Name (iqn), Host IP and Host port to connect to the iSCSI Target exposed by the Volume Gateway VM, and we will then discover the available volume and mount it. Take note of the Host IP as we are going to use it in a moment.
Mount the iSCSI volume inside a Windows VM
Let’s now move to a Windows Server VM hosted in VMC, in which we’ll enable to ISCSI Initiator service. Open Server Manager, and from the “Tools” Menu select “iSCSI Initiator”.
A dialog window will inform us that the Microsoft iSCSI service is not running. Click “Yes” to enable and start the service.
Once the iSCSI Initiator service is running, we can open the iSCSI Initiator management console by selecting Start (the Windows logo) – Windows Administrative Tools – iSCSI Initiator.
In the iSCSI Initiator Management Console, move to the “Discovery” tab and click on “Discover Portal”. In the “Discovery Target Portal” window, we can enter the IP address we’ve previously noted in the AWS Console, the one assigned to the volume we’ve just created. We can leave the default TCP Port 3260 and click “OK”.
Switching to the “Targets” tab, the iSCSI target iqn of the previously created volume will appear in the list of discovered targets, showing as “Inactive”. This means that we can reach the iSCSI target exposed by the Volume Gateway VM. We must click on “Connect” to actually connecting to the volume.
In the “Connect To Target” window we can accept the default settings and click “OK”.
The discovered target will now be shown as “Connected”. At this point, we are able to mount the volume and create a File System on it.
The iSCSI Initiator Management Console can be safely closed. To create a new volume based on the iSCSI device we just discovered, we must open the Disk Management Console. Right click on “Start” and select “Disk Management”.
In the Disk Management Console, click on the “Actions” menu, then on “Rescan Disks”. This will rescan the storage subsystem at the VM’s Operating System level, and will detect any new attached device, such as the volume “presented” by the Volume Gateway VM via iSCSI protocol.
The iSCSI volume will appear in the list of available disks and it will appear as “Offline”. We can assume it’s the right volume looking at its size, exactly 10 GB as we originally create it in the AWS Console. We must complete some additional steps to make the disk available to our Windows users or applications to host their data.
As a first step, we must bring online the disk. Right Click on it and select “Online”.
The second step in to initialize the disk to make it usable by Windows. Right click on it and select “Initialize Disk”.
In the “Initialize Disk” window, ensure the disk is selected and choose a partition style option based on your requirements. As we only need a single partition and our volume is quite small, in this scenario it’s safe to leave the MBR (Master Boot Record) option selected. You can read more here about the GPT partition style, and here about the MBR partition style. When done, click on “OK”.
Now that our disk in online and initialized, we must create a volume on it, formatted with a File System supported by Windows. Right click on the disk we’ve just initialized and select “New Simple Volume…”
We are presented with the “New Simple Volume Wizard” welcome page, here we can click on “Next”.
In the second step of the wizard, we are required to assign a drive letter to our volume. I’m choosing “X” as the drive letter in this example. Click “Next” when done.
The third step of the wizard requires us to format our volume, we can select “NTFS” as the File System type, leaving “allocation unit size” at its default value, and choosing (optionally) a Volume Label for the volume. Additionally, it is safe to flag the “Perform a quick format” checkbox. When done, click on “Next”.
On the “Completing the New Simple Volume Wizard” page, click “Finish” to complete the creation of the new volume.
Our new volume will now be visible in the Windows File Explorer, highlighted by the Label and Drive Letter we set during the creation wizard. In this example, we have our “X:” drive labelled as “FileShare”.
Configure vSAN Policy for the Volume Gateway VM
The last step we should make to follow AWS best practices is to reserve all disk space for the Volume Gateway cache and upload buffer disks. AWS recommends to create cache and upload buffer disks with Thick Provisioned format. As we are leveraging vSAN in VMC we don’t have Thick Provisioning available in the traditional sense. We must use Storage Policies to reserve all disk space for the disks. The first step is to go into our vSphere Client and select “Policies and Profiles” from the main Menu.
In the “Policies and Profiles” page, under “VM Storage Policies”, select “Create VM Storage Policy”.
In the “Create VM Storage Policy”, select a name for the policy and click “Next”.
In the “Policy Structure” window, set the flag on “Enable rules for vSAN storage”, then click “Next”.
In the vSAN window, under “Availability” configuration, we can leave the default settings and switch to the “Advanced Policy Rules” tab.
Once in the “Advanced Policy Rules” tab, we can change the “Object space reservation” field to “Thick provisioning”, leaving all the other fields at their defaults. Then, click “Next”.
Select the “WorkloadDatastore” and click “Next”.
In the next window we can review all the settings we have made and click “Finish”.
We can now move to our Volume Gateway Virtual Machine and select “Edit Settings…” under the “ACTIONS” Menu.
Under the “Virtual Hardware” tab, we can now select the hard disks we assigned to the Volume Gateway as the cache and upload buffer volumes, and assign these the newly created Storage Policy. Once done, click “OK”. This will pre-assign all the configured disk space to both disks, replacing the default thin provisioning based policy.
One last important thing to mention is how we can save the data hosted in Volumes we create and expose through the Volume Gateway. All the options we have are available in the AWS Console, Storage Gateway services, under “Volumes”. Selecting the Volume we want to work on, under the “Actions” menu we have the option to create an on-demand backup with the AWS Backup managed service, to create a Backup plan with AWS Backup, or to create EBS snapshot (hosted in S3). Snapshots enable us to restore a Volume to a specific point in time, or to create a new Volume based on an existent snapshot.
This concludes this post. We have created a Volume Gateway in VMware Cloud on AWS, delivering block disk devices based on iSCSI to our workloads, leveraging S3 as the backend storage. A volume gateway provides cloud-backed storage volumes that you can mount as Internet Small Computer System Interface (iSCSI) devices from your application servers hosted in VMware Cloud on AWS. Stay tuned for future content! #ESVR
Back to basics – VMware Cloud on AWS 101 on a blackboard
Finally back to blogging, and back to the basics.
In this video I use the old classic blackboard to discuss about the Hybrid Cloud challenges and how VMware Cloud on AWS can help you to overcame these challenges.
The first approach to the Cloud is often a lift and shift approach, and VMware Cloud on AWS, paired with HCX, is the solution for a real lift and shift. No downtime, no code changes, all Cloud benefits.
In this second post about vCloud Director Extender, I’ll guide you through the necessary steps to configure the vCloud Director Extender Service from a Customer (Tenant) perspective.
vCloud Director Extender enables a Tenant to cold or warm migrate its workloads from vSphere to a vCloud Director based Public Cloud. All the easy steps are wizard-driven and the Tenant also has the option to leverage the automatic creation of a L2VPN connection that can stretch the networking between on premises and the vCloud Director Cloud.
You can read vCloud Director Extender release notes here.
vCloud Director Extender Tenant deployment
All the initial steps needed on the Tenant side are the same we’ve seen on the Service Provider side, first you download the vCloud Director Extender OVA file, then you deploy it in your source vCenter. See the Service Provider Setup paragraph in my previous post to view all the steps.
The only difference you must pay attention to is to choose “cx-connector” as the deployment type.
vCloud Director Extender Tenant configuration
Once deployed, you can access the vCloud Director Extender Virtual Appliance via https on the configured IP Address.
You will be presented with the OnPrem Setup page.
Enter your Local or vCenter (SSO) credentials to access the application and start the configuration wizard.
Select “SETUP WIZARD” to start the Service configuration.
In Step 1, you’ll enter the parameters needed to connect to the source vCenter. Then click “Next”.
Wait for the confirmation message, then click “next”
In Step 2, you confirm the registration of the vCloud Director Extender as a plugin in the source vCenter, then click “Next”.
Wait for the confirmation message, then click “Next”.
In Step 3, provide the parameters needed to configure the Tenant Replicator service, then click “Next”.
Wait for the confirmation message, then click “Next”.
In Step 4, you provide the parameters needed to activate the Replicator, then click “Next”.
Wait for the confirmation message, then click “Next”.
In Step 5, we’ve finished the OnPrem Setup. Click “Finish”.
After the initial Wizard that provides the connection to the source vCenter and the Replicator Service setup, you must access the “DC Extensions” tab to provide necessary parameters to deploy the L2VPN Appliance.
If NSX Manager is deployed on Premises, it is mandatory to choose “ADD NSX CONFIGURATION”.
In our scenario, we don’t have NSX on Premises so we’ll choose “ADD APPLIANCE CONFIGURATION” in the L2 Appliance Configuration section.
Provide the needed parameters to deploy the L2VPN Appliance. Pay attention to the following fields: Uplink Network, which maps to the PortGroup that grants Internet connectivity to the appliance, and Uplink Network Pool IP, which is the source IP Address used to connect to the L2VPN Server. Click “Create”.
Wait for the confirmation message that confirms the L2 Appliance configuration.
This concludes the configuration steps for the L2VPN appliance.
Accessing the Web Client, the Tenant can now configure L2 Extensions and manage workloads migration to the Cloud.
vCloud Director Extender Tenant operations
After the configuration steps ends, you can find a new Service registered in the source vCenter inventory: vCloud Director Extender. Click on the icon to launch the Management page for the Service.
On the vCloud Director Extender management page, you can find two dashboard that show you the overall Migration Health and the DC Extension Status for the L2VPNs.
Select “New Provider Cloud” to connect to your Service Provider.
Provide a descriptive name for the target Cloud, the URL of the target vCloud Director Organization for the Tenant, the URL of the target Extender Cloud Service (provided by the Service Provider) and finally your Org Admin credentials. Click “Test” to test the connection, wait for the confirmation message then click “Add”
You can now see your target vCloud Director Organization appearing in the Provider Clouds tab.
We’ll now create a new L2 Extension from onPrem to the Cloud. Access the DC Extensions tab and click on “New Extension”.
Enter a name for this extension, select the source Datacenter, the source Network, the target Provider Cloud, vDC and Org Network. The “Enable egress” option enables you to have a local default gateway in each site with the same IP address, to optimize Egress traffic. With Egress optimization enabled, packets sent towards the Egress optimization IP will be routed locally by the Edge, everything else will be sent thru the bridge.
Click “Start” to enable the connection and make the L2 extension.
In the vSphere Web Client task console, you can view the “Trunk” Port Group being created with a SINK port. You can also see the Standalone Edge deployment is in progress.
After the tasks complete, you can see the L2VPN status as “Connected”. L2 Extension beetween the source and the target network is in place, so you can safely migrate your workloads to the Cloud without change in IP addressing, keeping the same connectivity you have on Premises. This is really Hybrid Cloud!
In the vCloud Director Extender Home, you can now see the DC Extension Status dashboard showing the L2VPN Tunnel is in place.
If we look at the L2VPN Statistics in vCloud Director, we can see the Tunnel Status as “up”.
It’s now time to migrate a workload to the Cloud leveraging this new L2VPN Tunnel to keep connectivity with on Premises. Access the Migrations tab and click on “NEW MIGRATION”.
Select the type of migration you want to perform: Cold migration requires the source VM to be powered off while Warm migration enables you to keep your VM runnning on Premises, starting a continuous file sync to the Cloud and completing the cutover when replica is completed. As the wizard highlight, Warm migration is not a vMotion. Click “Next” after the selection.
Select the source VM(s), then click “Next”. You can select more than one VM for each migration job.
Specify the target Cloud parameters: target Cloud, vDC, Storage Profile, Org. Network and vApp layout to create if you are migrating more than one VM. Click “Next” when finished.
Specify when you want to start the synchronization, the target RPO and the disk type (thin, thick). You can additionally specify a Tag for this migration job. When finished, click “Start”.
When the synchronization finishes, the workload will have a Status named “Cutover Ready”. This means that you can start the cutover process, that will Power Off the source VM and will Power On the VM in the Cloud. Click “Start Cutover” to specify the cutover parameters and start the process .
Specify the target cloud, the desired final power status of the target VM after cutover, then click “Start”.
The workload Status will became “Completed” once the Cutover finishes.
The migrated VM will be powered off on Premises.
On the target vCloud Director, we’ll find the migrated VM powered on.
Let’s use PING to test connectivity between VM1, still on Premises, and VM2, migrated to the Cloud. The connection will leverage the L2 Extension between on Premises and the Cloud. (Note: DUP! packets message occurs because I’m working in a nested environment).
There’s a 1:1 mapping between source VLAN and target VXLAN when you configure Datacenter Extension in vCloud Director Extender.
To stretch multiple VLANs you must create different Extensions in vCD Extender.
To show this let’s create a new PortGroup on Premises and a new Org vDC Network in the Cloud to see what happens when we need to create an additional network extension.
We configure a new Extension, mapping a local VLAN to the target Org vDC Network. The Status will show as “Connected” when the creation process finishes.
Looking at the changes automatically made in vCloud Director, we’ll find the new Org Network added as a stretched interface to the existing Site Configuration.
This concludes the CX Service On Prem configuration.
Soon after the release of vCloud Director 9.0, VMware has released the replacement for vCloud Connector, a new tool named vCloud Director Extender.
vCloud Director Extender enables a Tenant to cold or warm migrate its workloads from vSphere to a vCloud Director based Public Cloud. All the easy steps are wizard-driven and the Tenant has also the option to leverage the automatic creation of a L2VPN connection that can stretch the networking between on premises and the vCloud Director Cloud.
vCloud Director Extender works with vCloud Director 8.20.x and vCloud Director 9.0
You can read the Release Notes for version 1.0 here.
In this first post about vCloud Director Extender, I’ll guide you through the necessary steps to configure the vCloud Director Extender Service from a Service Provider perspective.
vCloud Director Extender Architecture
Before to start, I want to show you the architecture of the Service:
On the Provider Side, we have the following components:
vCloud Director Extender: the Virtual Appliance that you download and deploy, known as “CX Cloud Service”. After its deployment and configuration, it is used to provide setup and configuration of the overall CX Service.
Cloud Continuity Manager (aka “Replication Manager”): this Virtual Appliance is deployed by the CX Cloud Service and its role is to oversee the work done by the Replicator.
Cloud Continuity Engine (aka “Replicator”): this Virtual Appliance is deployed by the CX Cloud Service and its role is to manage the VMs replication between the Tenant’s vSphere environment and the Service Provider’s vCloud Director. The Replicator leverages the new H4 Replication Engine.
On the Tenant side, we only need vCloud Director Extender and the Cloud Continuity Engine.
Let’s start now with the installation and configuration steps on the Service Provider side.
vCloud Director Extender Service Provider Setup
The first step is to access myVMware Website and to download the vCloud Director Extender OVA file, located under the “Drivers & Tools” section of the VMware vCloud Director 9.0 download page.
Following the “Go to Downloads” link you’ll find the vCloud Director Extender 1.0.0 download page.
The next step is to deploy the OVA file we just downloaded. Select the target vCenter (tipically the Management Cluster vCenter) and select “Deploy OVF Template”.
Choose “Browse” to select a local file.
Choose the OVA file you download previously from the myVMware Website and select “Open”. Once you’re back on the Select Template page, click “Next”.
Choose a name for the vCloud Director Extender Virtual Appliance as you want it to appear in your vCenter inventory, then click “Next”.
Select a Target Cluster/Host and click “Next”.
Click “Next” on the Review details page.
Click “Accept” on the EULA page after reading it, then click “Next”.
Select a virtual disk format, a VM storage policy and a target datastore for the Virtual Appliance, then click “Next”.
Select a destination Network (PortGroup) for the Virtual Appliance, then click “Next”.
In the “Customize Template” tab, you’ll set all the Virtual Appliance Parameters.
In the Service Provider environment, based on vCloud Director, you must choose the deployment type “cx-cloud-service“.
Click “Finish” after having reviewed your configuration, to deploy the Virtual Appliance.
vCloud Director Extender Service Provider Setup
Once deployed, you can access the vCloud Director Extender Virtual Appliance via https on the configured IP Address.
You will be presented with the Cloud Service Setup page.
Enter your Local or vCenter (SSO) credentials to access the application and start the configuration wizard.
Select “SETUP WIZARD” to start the Service configuration.
In Step 1, you’ll enter the parameters needed to connect to the Management vCenter. Then click “Next”.
In Step 2, provide the parameters needed to connect to your vCloud Director instance, then click “Next”.
In Step 3, provide the parameters needed to connect to your Resource vCenter(s), then click “Next”.
Wait for the “Successfully linked Resource vCenter” confirmation message, then click “Next”.
In Step 4, specify the parameters needed to create the Replication Manager Virtual Appliance, then click “Next”.
You will see a progress bar indicating the Replication Manager creation status.
In Step 5, set the Root password for the Replication Manager Appliance, specify the Public Endpoint URL needed to reach the Service (optional, only needed if the Appliance is behind a Proxy/NAT), then click “Next”.
Wait for the activation confirmation message, then click “Next”.
In Step 6, specify the parameters needed to create the Replicator Virtual Appliance, then click “Next”.
You will see a progress bar indicating the Replicator creation status.
In Step 7, set the Root password for the Replicator Appliance, specify Lookup Service URL and credentials for the Resource vCenter and the Public Endpoint URL needed to reach the Service (optional, only needed if the Appliance is behind a Proxy/NAT), then click “Next”.
Step 8 will conclude the Wizard. Click “Finish”.
vCloud Director Extender – Service Provider L2VPN Server Setup
The last step to enable the Service, only necessary if L2 stretching is needed between the on premises environment and vCloud Director, is to configure the L2VPN Service on the target Organization Virtual Datacenter(s) Edge Gateway(s).
To create L2VPN connections, you need to convert the Edge Services Gateway(s) to Advanced and grant the needed rights to the vCloud Organization.
You can read one of my previous posts, Self Service NSX Services in vCloud Director, to understand how this works and how to complete this part of the configuration, if needed.
At this stage you can configure the L2VPN Server on the Tenant Edge Gateway (this can be done by the Service Provider or can be delegated to the Customer).
When you configure an L2VPN Server, you must configure a Peer Site. You’ll configure a dummy Peer Site at this stage, just to conclude the Setup on the Tenant side. We’ll could leave this Peer site disabled because we won’t use it, it will be vCloud Director Extender on the Tenant side to configure the needed Peer Sites on this Edge Gateway.
This concludes the Service Provider side of the vCloud Director Extender Service configuration.
In the next post I’ll show you how to configure the CX Service on the Tenant side.