Amazon Relational Database Service (Amazon RDS) recently announced support of highly available configurations with Multi-AZ instance deployments for PostgreSQL and MySQL on AWS Outposts. In this post, we go over the process for creating an RDS database instance with Multi-AZ instance deployments.
Overview of Multi-AZ deployments
With Multi-AZ instance deployments on Outposts, Amazon RDS creates two database instances across two Outposts. Each Outpost runs on its own distinct physical infrastructure and connects to different Availability Zones in a Region for high availability. With two Outposts connected with a customer-managed local connection, Amazon RDS manages synchronous replication between the primary and standby database instances. In case of a software or infrastructure failure, Amazon RDS automatically promotes the standby to the primary role and updates the DNS record to point to the new primary. This event is referred to as a failover. The database service resumes as soon as failover is complete. Application traffic is automatically directed to the new primary with the changes in the DNS record. The old primary is demoted to the standby role after undergoing repair actions and is back in operation. The following diagram illustrates this setup.
In a Multi-AZ configuration, the primary and standby instances each have their own copy of data. When a database write request comes in, data is first written to the Amazon Elastic Block Store (Amazon EBS) volume of the primary instance, then replicated to the EBS volume of the standby instance over the replication local network. When data is properly written to the EBS volumes of both database instances, a successful response is sent back to the calling application. See the following diagram for the database write operation data flow.
The performance of interconnection between the Outposts plays a critical role in the latency of remote write and acknowledgement. With Multi-AZ instance deployments on Outposts, database write latency is equal to the cumulative latency of local write plus local acknowledgement and latency of remote write plus remote acknowledgement.
Replication local network
RDS Multi-AZ instance deployments on Outposts requires a customer-managed local connection between two Outposts to serve as replication local network. During the Outposts installation process, AWS uses information that you provide about your local network to create an address pool, known as a customer-owned IP address pool (CoIP pool). AWS then assigns it to the local gateway (LGW) for use and advertisement back to your local network through Border Gateway Protocol (BGP). A CoIP pool must meet the requirements of the followings.
You must be able to route the address in your network.
The CIDR block must be a minimum of /26.
For more information, see Local network connectivity for Outposts Racks.
Customer-owned IP (CoIP) addresses provide local or external connectivity to resources in your Outpost subnets through your local network. Amazon RDS allocates CoIP addresses from your CoIP pools for replication across your local network. It uses CoIP routing to transmit replication traffics between primary and standby database instances. When setting up the customer-managed replication local network, consider the following:
The roundtrip time (RTT) latency between the Outpost hosting your primary DB instance and the Outpost hosting your standby DB instance directly affects write latency. Keep the RTT latency between the Outposts in the low single-digit milliseconds. We recommend not more than 5 milliseconds, but your requirements might vary.
You can find the net impact to network latency in the Amazon CloudWatch metrics for WriteLatency. For more information, see Amazon CloudWatch metrics for Amazon RDS.
The availability of the connection between the Outposts affects the overall availability of your DB instances. Have redundant network connectivity between the Outposts.
Prerequisites
We assume that you’re familiar with working with the AWS Management Console. You should also have the following prerequisites:
Two Outposts, each with its own LGW, homed to different Availability Zones in an AWS Region
Each LGW should have available CoIP pool configured for the LGW route table
Two Outposts connected to a customer-managed local network over a LGW, with LGW route tables configured to use CoIP routing
An AWS account with access to the Outposts
One customer VPC
For more information about the prerequisites for Multi-AZ deployments, see Prerequisites.
Create subnets on Outposts
The first step to deploying Amazon RDS on Outposts is to create the Outpost subnets your database runs on. You can extend a VPC in the Region to Outposts by adding an Outpost subnet.
On the Outposts console, choose Outposts in the navigation pane.
Your two prerequisite Outposts should be installed and have networking configured.
Select your first Outpost and on the Actions menu, choose Create subnet.
For VPC ID, choose your VPC. For this post, we use an existing VPC called wanhe-demo-vpc.
For Subnet name¸ enter a name (for this post, wanhe-demo-snOutpost1).
For IPv4 CIDR block, enter your CIDR block.
Under Tags, add the key Name with the subnet as the value.
Choose Create subnet.
Repeat these steps to create a subnet on the second Outpost, called wanhe-demo-snOutpost2.
Associate your VPC to LGW route tables
Amazon RDS requires you to associate your VPC to the LGW route tables, because it uses this association to determine which CoIP pools to allocate CoIP addresses for replication.
On the Outposts console, choose Local gateway route tables in the navigation pane.
Select the Outpost, and choose Associate VPC on the Actions menu.
For VPC ID, choose the VPC you want to deploy your database to.
Choose Associate VPC.
Repeat these steps to associate the VPC to the second Outpost.
Create a DB subnet group
To create Amazon RDS with Multi-AZ instance deployments on Outposts, you must supply a DB subnet group with Outpost subnets that has a minimum Availability Zone coverage of two. This makes sure that at least two Outposts are specified (an Outpost is homed to one and only one Availability Zone).
On the Amazon RDS console, choose Subnet groups in the navigation pane.
Choose Create DB subnet group.
Enter a name and description.
For VPC, choose your VPC.
For Availability Zones¸ choose the Availability Zones to add.
For Subnets, choose the subnets you created.
Choose Create.
Deploy the database with Multi-AZ
To deploy your database, complete the following steps:
On the Amazon RDS console, choose Databases in the navigation pane.
Choose Create databases.
For Database location options, select On-premises.
For On-premises database options, select RDS on Outposts.
For Virtual private cloud, choose your VPC.
For Subnet group, select Choose existing and choose your subnet group.
For Database port, enter your port.
For Engine type, select your engine (for this post, we select PostgreSQL).
For Version, choose your PostgreSQL version.
For DB instance identifier, enter a name (for this post, we use wanhe-demo-maz).
Under Credential Settings, enter your primary user name and password.
For Multi-AZ deployments, select Create a standby instance.
For Backup target, select AWS Cloud.
Local backups are not supported in Multi-AZ deployments. When the Multi-AZ feature is enabled, the local backup option is disabled.
Leave all remaining settings at their default and choose Create database.
It may take several minutes for the database to be created.
Verify database
To verify the database you created, complete the following steps:
On the Amazon RDS console, choose Databases in the navigation pane.
Choose your database to see its details.
On the Connectivity & security tab, check the endpoint and Availability Zone information.
On the Configuration tab, check the Multi-AZ settings.
Conclusion
In this post, we walked you through the steps for deploying Amazon RDS on Outposts with Multi-AZ instance high availability. With Multi-AZ support, Amazon RDS monitors, detects, and manages any software or hardware failures of the database environment on Outposts, and performs automatically failover with zero data loss for high availability.
For more information, see Amazon RDS Multi-AZ deployments on AWS Outposts.
About the Author
Wanda He is a Sr. Database Specialist Solutions Architect at Amazon Web Services. She works with customers on design, deploy, and optimize relational databases on AWS.
Read MoreAWS Database Blog
