Deploy Oracle databases with high availability instances on AWS
This Guidance helps customers set up high availability for Oracle databases using Amazon RDS Custom for Oracle service, a managed cloud data service that makes it easier to operate and scale relational databases. It addresses the challenges for those who want to utilize Amazon RDS Custom for Oracle, but don't have an automated way to implement those instances. This hinders their ability to meet application service level agreements and requires manually configuring high availability instances. This Guidance can help customers streamline their high availability setup, offload complex configuration tasks, and ensure maximum availability, thanks to the integration of Oracle Data Guard with Fast-Start Failover monitoring.
Please note: [Disclaimer]
Architecture Diagram
[text]
Step 1
Upload Oracle Database 19c Client into an Amazon Simple Storage Service (Amazon S3) bucket and provide that bucket name as an input to the AWS CloudFormation script.
Step 2
Deploy the CloudFormation script using the CloudFormation console or command line interface (CLI) by passing the required input parameters.
Step 3
CloudFormation creates the required AWS Identity and Access Management (IAM) roles and permissions. AWS Lambda functions help support the operations performed by the CloudFormation script.
Step 4
CloudFormation provisions an Amazon Elastic Compute (Amazon EC2) instance, copies the Oracle client media from the Amazon S3 bucket, installs it on the Amazon EC2 instance, and sets up the Oracle client.
This Amazon EC2 instance acts as the Oracle Data Guard observer instance that observes, monitors, and initiates failover from primary to standby.
Step 5
CloudFormation then invokes the creation of an Amazon Relational Database Service (Amazon RDS) Custom for Oracle read replica for the primary instance provided by the customer. This replica acts as the standby instance for this high availability setup.
Step 6
The Oracle clients communicate with the database using the Transparent Network Substrate (TNS) protocol. TNS connectivity is set up and verified from the Oracle Data Guard observer instance to both the primary and the standby instances.
The Oracle Data Guard user password is fetched from AWS Secrets Manager to make the connection. In this architecture, we use AWS Systems Manager document (SSM document) to perform this automation.
Step 7
Oracle Data Guard makes configuration changes, sets up synchronous log shipping, and enables Data Guard Fast-Start Failover that is automated through the SSM document.
Step 1
Upload Oracle Database 19c Client into an Amazon Simple Storage Service (Amazon S3) bucket and provide that bucket name as an input to the AWS CloudFormation script.
Step 2
Deploy the CloudFormation script using the CloudFormation console or command line interface (CLI) by passing the required input parameters.
Step 3
CloudFormation creates the required AWS Identity and Access Management (IAM) roles and permissions. AWS Lambda functions help support the operations performed by the CloudFormation script.
Step 4
CloudFormation provisions an Amazon Elastic Compute (Amazon EC2) instance, copies the Oracle client media from the Amazon S3 bucket, installs it on the Amazon EC2 instance, and sets up the Oracle client.
This Amazon EC2 instance acts as the Oracle Data Guard observer instance that observes, monitors, and initiates failover from primary to standby.
Step 5
CloudFormation then invokes the creation of an Amazon Relational Database Service (Amazon RDS) Custom for Oracle read replica for the primary instance provided by the customer. This replica acts as the standby instance for this high availability setup.
Step 6
The Oracle clients communicate with the database using the Transparent Network Substrate (TNS) protocol. TNS connectivity is set up and verified from the Oracle Data Guard observer instance to both the primary and the standby instances.
The Oracle Data Guard user password is fetched from AWS Secrets Manager to make the connection. In this architecture, we use AWS Systems Manager document (SSM document) to perform this automation.
Step 7
Oracle Data Guard makes configuration changes, sets up synchronous log shipping, and enables Data Guard Fast-Start Failover that is automated through the SSM document.
Well-Architected Pillars
The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.
The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.
-
Operational ExcellenceRead the Operational Excellence whitepaper
CloudFormation and Systems Manager documents were deployed throughout this Guidance to enhance operational excellence. These services help automate post-instance creation tasks in Amazon RDS Custom for Oracle databases, enabling users to quickly set up, monitor, and understand the state and achievement of business outcomes for their environment. The use of CloudFormation and Systems Manager streamlines the process of integrating and deploying changes to the high availability setup, ensuring efficient and controlled modifications to the database stack.
-
SecurityRead the Security whitepaper
Amazon EC2 security groups, IAM, and AWS Key Management Service (AWS KMS) work collectively to enhance security in this Guidance. Using Amazon EC2 security groups and IAM policies, access is granted to the Amazon EC2 observer instance based on the principal of least privilege. Only the required ports for the database listener and the Oracle Data Guard communication are open between the Amazon EC2 instance and the Amazon RDS Custom database instance. Also, infrastructure protection is prioritized by restricting access through the Amazon EC2 security group settings. Finally, data protection is ensured by requiring an AWS KMS key for encryption in Amazon RDS Custom for Oracle, and by scoping IAM policies to the minimum permissions required, with only authorized access allowed.
-
ReliabilityRead the Reliability whitepaper
CloudFormation and AWS CloudTrail work in tandem to enhance reliability throughout this Guidance. CloudTrail monitors and tracks changes, and CloudFormation streamlines deployment. These measures collectively contribute to ensure failover management, effective monitoring, and consistent deployments. When it comes to monitoring and tracking changes, Amazon RDS Custom for Oracle automatically generates a CloudTrail entry that is crucial for Amazon RDS Custom for Oracle automation logs. This ensures effective monitoring of actions that may impact the system's reliability. To streamline the deployment process and ensure consistency, the script is built on CloudFormation. This script simplifies the deployment of the entire stack, reducing the chances of errors and ensuring reliable deployments.
-
Performance EfficiencyRead the Performance Efficiency whitepaper
Amazon RDS Custom for Oracle was deployed throughout this Guidance to enhance performance efficiency. This service is designed for privileged access to databases and operating systems, making it ideal for critical workloads that require high availability. It offers a streamlined deployment option, allowing users to implement, test, and easily customize configuration settings such as an Amazon RDS instance size, observer instance size, Oracle Data Guard configuration parameters, and Fast-Start Failover parameters.
Also, Amazon RDS Custom for Oracle can be customized to meet the requirements of older, custom, and packaged applications. Implementing this Guidance in multiple Availability Zones within the same Region ensures maximum availability and optimal performance. And, the streamlined deployment option allows for easy customization of your configuration settings.
-
Cost OptimizationRead the Cost Optimization whitepaper
Amazon EC2 and a Virtual Private Cloud (VPC) are used throughout this Guidance to optimize the cost of your workloads. An Amazon EC2 instance evaluates the cost by leveraging the pay-as-you-go model. This Guidance also uses an Amazon EC2 T3 instance, which are the low-cost general purpose instance types. This Guidance also uses Amazon RDS Custom for Oracle within the same VPC, which further eliminates data charges across VPCs.
By utilizing the managed service capabilities in this Guidance, you can benefit from scalable compute and storage options, ensuring that resources are scaled to match the demand dynamically. This approach also ensures that only the minimum resources required are provisioned, effectively optimizing costs.
-
SustainabilityRead the Sustainability whitepaper
Amazon EC2, Lambda, and Amazon RDS Custom for Oracle enhance sustainability in this Guidance. These services can easily scale up or down to match the load, using the scale compute feature, for sustainable utilization of resources. Lambda offers automatic scaling based on demand, and being a serverless service, it reduces the chances of overprovisioning your resources. This helps ensure maximum utilization of resources. Finally, Amazon EC2 and Amazon RDS Custom for Oracle can also be configured to scale up or down based on demand.
Implementation Resources
The sample code is a starting point. It is industry validated, prescriptive but not definitive, and a peek under the hood to help you begin.
Related Content
[Title]
Disclaimer
The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.
References to third-party services or organizations in this Guidance do not imply an endorsement, sponsorship, or affiliation between Amazon or AWS and the third party. Guidance from AWS is a technical starting point, and you can customize your integration with third-party services when you deploy the architecture.