AWS Database Blog

Getting started with Amazon RDS managed databases in your on-premises VMware environment

Amazon RDS on VMware extends the managed database experience of AWS Relational Database Service (RDS) to your on-premises VMware environment using the Amazon RDS technology that hundreds of thousands of customers enjoy.

This post demonstrates how VMware administrators and database administrators can deploy RDS on VMware environments. It discusses how to prepare your on-premises vSphere clusters for RDS on VMware deployment and how to onboard RDS on VMware to your cluster.

RDS on VMware architecture

RDS on VMware uses the RDS connector with software appliances for your VMware vSphere environment. With the RDS connector, you can manage on-premises relational DB instances through a dedicated virtual private network (VPN) tunnel from the AWS Region. This allows the control plane for Amazon RDS to stay in the AWS Cloud in the Region.

Amazon RDS provisions and manages DB instances on the VMware environment on-premises through local components that deploy to your VMware vSphere cluster during setup—these make up the local control plane. These components deploy as virtual appliances into your on-premises cluster. These components are also called control virtual machines (VMs). The components are as follows:

  • Edge router – Deploys into your vSphere cluster to provide routes to the AWS Cloud and your vCenter Server. This appliance also runs DNS Server and DHCP service for the cluster control network. It also manages the VPN tunnel that connects your on-premises environment to the AWS Cloud.
  • RDS connector – Executes data management operations on-premises.
  • Datastore (control VM) – Stores your Amazon RDS metadata in a local database within your VMware cluster and runs on the virtual appliance.
  • Snapshot manager and object store (control VM) – Initiates snapshot operations and stores them locally using your provisioned datastores on-premises.
  • Event processor (control VM) – Monitors database health and triggers replacements of defective RDS instances when needed.
  • Event service aggregator (control VM) – Pushes metrics and events to the connected AWS Region.
  • VDME (Control VM) – Provides the interface for vCenter operations to Amazon RDS. Two of these appliances are deployed into the cluster during the setup.

The following diagram illustrates the high-level architecture for RDS on VMware.

The Amazon RDS control plane in the AWS Cloud communicates with the local control plane in your on-premises VMware cluster though the AWS VPN tunnel. This allows Amazon RDS to issue operational commands such as provisioning, delete, power operations, patching, and backup to the on-premises RDS DB instances. This architecture allows your DB instances to still function if your on-premises VMware environment loses connectivity to Amazon RDS in the AWS Cloud. You can use Amazon CloudWatch to monitor the DB instances on your VMware vSphere cluster on-premises.

Use vSphere High Availability and Distributed Resource Scheduler (DRS) within the VMware cluster to provide additional protection for the preceding appliances in a hardware failure scenario. If any of the components crash due to host or storage hardware failure, vSphere High Availability attempts to restart it on another healthy host. If that fails, an RDS on VMware event processor automatically replaces the component by deploying a new appliance to a healthy host.

Prerequisites

Before you use RDS on VMware, you must have the following prerequisites:

  • Your vCenter Server and ESXi must be versions 6.5 or higher.
  • Your vSphere should be Enterprise Plus at the minimum due to the need for Distributed Resource Scheduler (DRS) and Distributed Switches.
  • A vCenter service account is required. This user account must be added to the ADMINISTRATORS, CAADMINS, SYSTEMCONFIGURATION.ADMINISTRATORS, LICENSESERVICE.ADMINISTRATORS,COMPONENTMANAGER.ADMINISTRATORS, SYSTEMCONFIGURATION.BASHSHELLADMINISTRATORS groups within the same single sign-on domain. You can use all types of users supported on vCenter as long as they belong to the above mentioned groups. Note that this account is only used to on-board RDS to your on-premises vSphere cluster so this account can be disabled or removed after the on-boarding process. Active Directory account with the correct permissions on vCenter is also supported.
  • You need a vSphere resource pool with adequate resources available in your vCenter because you must deploy all the management VMs and DB instances for RDS on VMware in the same cluster within the same resource pool. There should be at least 24vCPUs, 24-GB RAM, and 180 GB of storage available for the control virtual machines within the resource pool so you must allocate more CPU and memory resources to the resource pool and configure the reservation properties to be expandable in the resource pool. This allows the resource pool to get more resources as needed in case of resource contention within the resource pool. Therefore you must have this base capacity plus capacity for your database instance VMs.
  • The distributed switch you use must span across all hosts that are part of the cluster RDS on VMware uses. The Dynamic Host Configuration Protocol (DHCP) broadcast from the cluster control network port group must reach all the hosts that are part of the cluster that hosts RDS on VMware.
  • An AWS account with an IAM user and access key that allows you to start the deployment process from the RDS console. To do this, see setting up AWS account.

Besides these general prerequisites, there are specific prerequisites that must be configured before you can successfully deploy RDS on VMware. These specific requirements revolve around networking and storage, and the next sections discuss these:

Networking

An important prerequisite to your network configuration is to configure your local DNS servers to forward all requests for *rdsonvmware.rds.amazonaws.com to the IP addresses of the RDS Edge Router VM. This involves using a wildcard record. For more information, see Wildcard DNS record on Wikipedia. To connect to the DNS endpoints of your DB instance VMs running on-premises, use the Edge Router VM to resolve your DNS requests. That means using the Edge Router VM as a DNS resolver for your local DNS servers.

There are four different networks, as well as port groups that you must create within your distributed switch in addition to your existing ESXi Management network. You may also decide to create a separate management network only for use with RDS on VMware. You should have a port group for the ESXi management or your custom management network in your distributed switch.

Internet/Public network

The internet/public network is a port group within your cluster that has outbound internet access. This is a hard requirement and you must have one implemented in your environment. Provide one public IP to serve as the originator IP that you use to establish a VPN tunnel between the vSphere cluster and the Amazon RDS website during the setup. This is an external IP address that is used for outgoing traffic from the vSphere cluster to the RDS website.

To allow automatic IP allocation for the virtual appliance components that RDS on VMware uses, you must have DHCP on your on-premises networks that the VMware cluster uses.

Work with your network team to configure DHCP services for the public network with a default gateway. Your network administrator should make sure that your DHCP traffic is confined to the VLAN ID for the Public network. The port group for this network must be tagged with the correct VLAN ID depending on how the uplink switch ports are configured, either in access mode or trunk mode. For more information, see VLAN configuration on virtual switches, physical switches, and virtual machines on the VMware Knowledge Base.

The originator IP of the internet network port group should have outbound and related inbound traffic to ports 50, 500, and 4500 (IKE/IPsec for the VPN tunnel, UDP or TCP, no need for both), and you must allow TCP access to port 443 (this allows HTTPS access to the public Amazon RDS endpoint).

Set the port allocation type on the distributed switch port group to Elastic to allow it to scale out automatically when appliances are connected to the port group.

Cluster control network

Your cluster control network should be a network on a new VLAN backed port group with a unique VLAN ID from that of the internet, management, and application networks. This VLAN should only be dedicated to the cluster control VMs. This network runs DHCP server and a DNS resolver from the connected Edge Router appliance. RDS on VMware assigns IP addresses in a pre-defined 54.239.236.0/22 public address range in this network. You must properly isolate your networks by tagging with VLANS to avoid impacting cluster operations. The distributed port group should have port allocation type set to Elastic to allow it to scale out automatically, especially when you start to deploy DB instance VMs into the cluster. Each DB instance requires a new port on the port group in this case.

Application network

Your application network can be an existing or new network in which the Amazon RDS instances are connected. It should be a network on a new VLAN backed port group with a unique VLAN ID, meaning the application network should not have traffic from other networks running on it. Within this network, DHCP service must be provided. The DHCP must be confined to the VLAN ID associated with the Application Network. The port group for this network must be tagged with the correct VLAN ID depending on how you configure the uplink switch ports, either in access mode or trunk mode.

The distributed port group should have port allocation type set to Elastic to allow it to scale out automatically as you create and scale DB instances in your custom Availability Zone.

Corporate network

Your corporate network is the port group for your internal production network for your application servers that communicate with the RDS databases. Provision a unique VLAN ID for this network. DHCP is not required for this network; however, if you choose to use DHCP, make sure it is confined to the VLAN of this network only using the right VLAN tagging depending on how you configure the uplink switch ports.

The following diagram provides a logical representation of a configured and connected environment with the preceding components. This diagram shows how the DB instances connect to the various components through the networks described in this section.

RDS on VMware supports NSX. For more information about configuring DHCP for your networks, see the VMware Docs website. If you are using NSX-T on-premises, see DHCP. If you are using NSX-V, see Managing DHCP Service.

To further enhance layer two network security across the port groups, set the security policies on the port group respecting Promiscuous mode, MAC address changes, and forged transmits to REJECT. For more information, see Configure the Security Policy for a Distributed Port Group or Distributed Port on VMware Docs.

Storage

RDS on VMware utilizes your existing vSphere storage in your environment. However, you must meet the following prerequisites before deploying the solution:

  • All ESXi hosts on the cluster that RDS on VMware uses must be connected to the same datastore
  • One dedicated datastore is presented to the vSphere cluster
  • Datastore type must be VSAN, VMFS, or NFS

Onboarding Amazon RDS to your VMware cluster on-premises

After you prepare your on-premises cluster, you are ready to onboard RDS on VMware to your local on-premises vSphere cluster.

During the onboarding process, select the correct port groups of the respective networks described previously: internet/public, cluster control, and application. These are required by the appliances.

To onboard RDS on VMware to your environment, complete the following steps:

  1. On the Amazon RDS console, choose the applicable Region where you want to deploy your RDS instance.
  2. From the Amazon RDS console, choose Custom Availability Zones
  3. In the Custom AZs section, choose Download installer.
  4. Read the terms of the RDS on VMware service agreement, and if acceptable, click Agree and the RDS installer download begins.
  5. Unzip the downloaded file and save it to your computer.
  6. In the Custom AZs section, choose Create custom AZ.
  7. For Custom AZ details, enter a name for your Availability Zone.
  8. For VPN settings, enter a tunnel name and originator IP.
  9. Choose Create custom AZ.
  10. Log in to your vCenter.
  11. Deploy the downloaded OVA file for the RDS on VMware Installer.
    For more information, see Deploy an OVF or OVA Template.
    The following screenshot shows the OVA deployment dialogue.
  12. Power up your installer appliance.
    The appliance is allocated two IPs automatically. Make sure to allow pop-ups in your browser.
  13. Connect to the console using https://installer-ip/ui.
    The following screenshot shows the page that appears.
  14. Provide AWS Access Key ID and AWS Secret Access Key that you created at the prerequisites.
  15. Choose VALIDATE WITH AWS CREDENTIALS.
  16. Choose AWS Configuration.
  17. For Select Region, choose the Region that contains the custom Availability Zone you previously created.
  18. Choose RETRIEVE AZs.
  19. From the drop-down menu, choose your customer Availability zone.
  20. Choose Next.
  21. In the Network Configuration section, enter your ESXi Management network details.The ESXi Management static IP address is the single IP address from the management network, either an existing or a custom management network you create. This IP is set aside for RDS on VMware for the entire lifetime of your custom Availability Zone.
  22. Click on Next.
  23. In the vCenter Configuration section, enter vCenter server details.
    The FQDN is the DNS URL for your vCenter server on-premises. The administrator name and password are for the vCenter user you created in the prerequisites section. This user must have all the permissions mentioned previously.
  24. Choose TEST CONNECTION.
    This makes sure that your on-premises VM is successfully connected to the vCenter.
  25. Choose Next.
  26. In the Placement Details section, specify the placement of the RDS on VMware control VMs and DB instances.
    All RDS on VMware VMs must be deployed on and must remain in the same cluster or resource pool and Datastore.
  27. Click Next.
  28. In the Summary section, verify all your onboarding configurations and choose INSTALL.
    It could take several hours for the control virtual machines to be deployed. In most cases between 2–4 hours.
  29. Log in to the Amazon RDS console.
  30. Check the status of your custom Availability Zones.
    The status for the custom Availability Zone should be Active to show that the installation is successful and that your vSphere cluster has been onboarded and registered.
  31. Log on to your vCenter server.
    You can see that your control VMs have been deployed. Alternatively, a new VMs folder that contains all the control appliances is located on the VMs & Templates tab.
    Your installer virtual machine is powered off once the onboarding process is completed. You may delete the installer VM now.
    You are now ready to create your first RDS instance to run on your on-premises VMware cluster. You may also reference the AWS Documentation page, Creating an On-Premises DB Instance, for more information.

Conclusion

This post provided concise instructions on how to prepare your cluster for use with RDS on VMware and how to create your first RDS instance in your on-premises vSphere cluster. You can deploy your first RDS database using any supported engine of your choice via AWS CLI, Amazon RDS API, or via the AWS Management Console.

 


About the Author

 

Schneider Larbi is a Specialist Solutions Architect with Amazon Web Services who specializes in helping our World Wide Public Sector customers to design and build secure, scalable and resilient workloads on AWS Outposts and VMWare Cloud on AWS. He also specializes in helping our customers to migrate all types of workloads onto VMware Cloud on AWS and AWS Outposts. He has been working in the IT industry for nearly 14 years across different enterprises across different industries such as telecom, MSPs, enterprises etc. You can connect with him on LinkedIin from here: linkedin.com/in/schneiderl.