Setup a excessive availability design for Oracle Knowledge Guard (Quick-Begin Failover) utilizing Amazon Route 53

Many purchasers use Oracle Database deployed on Amazon Elastic Compute Cloud (Amazon EC2) to run their Oracle E-Enterprise Suite purposes. They depend on Oracle Knowledge Guard for top availability databases, with a standby database working in a unique availability zone. Oracle Knowledge Guard can swap a standby database to the first function in case a manufacturing database turns into unavailable on account of deliberate/unplanned outage.

Oracle E-Enterprise Suite has AutoConfig Database Context information that factors to Area Identify System (DNS), like a non-public IP DNS identify or IP handle on Amazon EC2. In case of switchover/failover, Database Context information in Oracle E-Enterprise Suite must be up to date. With this resolution, database context information don’t must be up to date in case of switchover/failover. That is achieved by offering a single DNS identify hosted on Amazon Route 53, all the time pointing to a main database regardless of working on any node.

This put up demonstrates establishing a Route 53 hosted zone that factors to main and standby databases and can route requests to the database having a main function. We’ll setup Route 53 well being checks to watch Amazon CloudWatch alarms, primarily based on Oracle Knowledge Guard Quick-Begin Failover (FSFO) logs pushed from Oracle Database utilizing CloudWatch agent.

Conditions

Earlier than getting began, it’s essential to have the next:

• Oracle databases working on two separate EC2 cases for 1Primary and 2Standby node
• EC2 occasion for 3Observer node, with both Oracle Shopper Administrator software program or the complete Oracle Database software program stack
• Oracle Knowledge Guard configured to keep up standby databases as transactional constant copy of the first database
• Oracle Knowledge Guard Command-Line Interface (DGMGRL) configured with observer course of to facilitate FSFO
• FSFO enabled with observer configuration

Answer overview

Determine 1 depicts AWS providers which can be used construct an structure utilizing a single Area Identify System (DNS) and Route 53 to have requests path to the first database for Oracle Knowledge Guard deployed on EC2 cases.

Determine 1. Utilizing a single DNS and Amazon Route 53 to route requests

We encourage you to discover these articles previous to launching this structure:

Structure parts

• Main node: An Oracle Knowledge Guard configuration comprises one manufacturing database (main database) that capabilities within the main function. That is the database that’s accessed by most of your purposes.
• Standby node: A standby database is a transactional constant copy of the first database. As soon as created, Oracle Knowledge Guard mechanically maintains every standby database by transmitting redo information from the first database and making use of it to the standby database.
• Observer node: A part of DGMGRL that’s configured on a separate server with Oracle Shopper Interface exterior the methods working the Oracle Knowledge Guard configuration, which displays the supply of the first database. We suggest it’s in a separate availability zone than the first and standby databases. Ought to it detect that the first database is unavailable or the connection can’t be made, it would concern a failover after ready for the 30 seconds or specified by the FastStartFailoverThreshold property.

Be aware: This resolution was examined on Oracle Database 19c Enterprise Version Launch 19.0.0.0.0 and Oracle Enterprise Linux OL7.5-x86_64. Choose the required mixture of working system and database by referring to E-Enterprise Suite Database Certifications. Lively Oracle Knowledge Guard configuration just isn’t used on this resolution; subsequently, the database stays in mount state and unavailable for buyer reads. Nonetheless, this resolution can be utilized with an energetic Oracle Knowledge Guard configuration as properly.

Infrastructure setup

This desk particulars the lab setting and the database occasion names used all through this put up.

Answer implementation

1. IAM coverage

To configure the CloudWatch agent on an EC2 occasion, create an IAM function through the console, AWS Command Line Interface, or AWS API. By default, an IAM function doesn’t have any privileges and can’t entry AWS sources. Earlier than creating an IAM function, create an IAM coverage with the permissions required to entry CloudWatch logs, specifying the CloudWatch sources you wish to monitor or *, which is able to enable entry to CloudWatch logs.

Create the IAM coverage utilizing the next JSON and provides it a reputation, like dgpolicy, which grants particular permissions. On this case, the permissions embrace creating log teams and log streams, inputting log occasions, and describing log stream for all logs.

{
    "Model": "2012-10-17",
    "Assertion": [
        {
            "Action": [
                "logs:DescribeLogGroups",
                "logs:DescribeLogStreams",
                "logs:GetLogEvents",
                "s3:GetBucketLocation"
            ],
            "Impact": "Enable",
            "Useful resource": "*"
        }
    ]
}

2. IAM function

Create the IAM function (for instance, dgrole) and fix the coverage created in Step 1.

3. Affiliate IAM function with Amazon EC2 having FSFO observer node working on it

Affiliate the IAM function with Amazon EC2 from AWS console:

1. Open the Amazon EC2 console.
2. Within the navigation pane, select Cases.
3. Choose the occasion, and select Motion, Safety, Modify IAM function.
4. Choose the IAM function to connect to your occasion; select Save.

You can also use the associate-iam-instance-profile command to connect the IAM function to the occasion by specifying the occasion profile:

aws ec2 associate-iam-instance-profile 
    --instance-id i-1234567890lmnopq1 
    --iam-instance-profile Identify=" dgrole"

4. Set up CloudWatch log agent on observer node

Set up CloudWatch Logs agent on the observer node that already has FSFO log configuration setup on it. After set up is full, logs will mechanically stream from the occasion to the log stream you created whereas putting in the agent, as depicted in Figures 2 and three.

$curl https://s3.amazonaws.com/aws-cloudwatch/downloads/newest/awslogs-agent-setup.py -O
$sudo python ./awslogs-agent-setup.py --region ap-southeast-2

Determine 2. Steps to put in Amazon CloudWatch agent

Determine 3. Instance of output

At this level, FSFO logs are seen in CloudWatch logs. Carry out a database switchover to verify that logs are being printed to CloudWatch logs.

5. Create CloudWatch metric filter

Create main metric filter

• Create metric filter on “Standby database has modified to orclviq” and set worth to “1”.
• Open the CloudWatch log group and seek for “Standby database has modified to orclviq“. As soon as outcomes are displayed, “Create Metric Filter” button will seem at prime proper (as demonstrated in Determine 4).

Determine 4. Amazon CloudWatch log group

• “Filter identify” and “Filter sample” are crammed mechanically, as we already filtered that whereas accessing the CloudWatch log. Create a brand new identify area within the metric, which we’ll later use in second metric filter. Specify “Metric namespace”, which can even be the identical for the second metric filter. “Metric worth” is “1”, as detailed in Determine 5.

Determine 5. Amazon CloudWatch metric filter

Create secondary metric filter

• To create a second metric filter, observe steps to create the first metric filter however the filter sample might be “Standby database has modified to orclstd“. The one distinction on this step might be setting the “Metric worth” to “0”.
• Confirm the metric filter is working and capable of finding desired entries within the FSFO logs that can determine which occasion is the first database by:
  • Click on on one of many metric filters
  • Choose log information to check, and select and EC2 occasion ID
  • Testing the sample to confirm if metric filters are working correctly
  • Choose “Subsequent”
  • Save modifications

6. Create a CloudWatch alarm

Create a CloudWatch alarm that can monitor CloudWatch metrics and carry out actions primarily based on the worth of the metric.

• Inside CloudWatch Alarms part (Step 1), choose “Create alarm” after which choose “Metric”, as in Determine 6.
• In Step 2, you possibly can create a brand new matter and specify the e-mail handle the place you wish to obtain notifications relating to modifications in main or standby database.
• In Step 3, you possibly can specify the alarm identify and non-obligatory alarm description.

Determine 6. Amazon CloudWatch alarm

• To configure Circumstances, as detailed in Determine 7, ensure the brink sort is about to “Static”, the alarm situation is “Better/Equal”, and the brink worth is “1”.

Determine 7. Amazon CloudWatch alarm situation

• Determine 8 demonstrates the abstract of the prepared CloudWatch metrics and configured alarm.  At this level, “orclviq” is the first database, so the alarm state might be “Inadequate information”. Attempt to do a switchover and the alarm state must be modified to “In alarm”.
• Swap it again to unique main earlier than continuing additional

Determine 8. Remaining view of each metric filters mixed

7. Create Route 53 well being checks

Creating Route 53 well being checks primarily based on the CloudWatch alarm identifies DNS failover. Well being checks might be created on public IP instantly with out creating above metric filters and alarms, however it’s unlikely that prospects may have a public IP on database servers. Route 53 can’t examine the well being of an IP handle endpoint regardless of whether it is native, personal, non-routable, or multi-cast ranges. Due to this fact, well being checks must be created on the state of CloudWatch alarm (Determine 9):

• Throughout the Route 53 console, choose “Configure well being examine”.
• Choose “State of CloudWatch alarm”, then choose the area of your CloudWatch metrics and select the CloudWatch alarm that was created earlier from the dropdown menu.
• Skip creating an alarm for well being examine, because the alarm is already configured for CloudWatch metric filter.

Determine 9. Amazon Route 53 well being examine parameters

• The well being examine is now prepared and standing might be “Unknown”. It’s going to change to “Wholesome”, as it’s presently having main orclviq, which suggests it’s satisfying “Standby database has modified to orclstd“.
• At this level, attempt doing a failover and observe if well being examine standing modifications to “Unhealthy”. Swap it again to the unique main earlier than continuing.
• The well being examine ought to return to “Wholesome” state.
• Examine the standing of the alarm:
  • OK: the standing is wholesome
  • ALARM: the standing is unhealthy
  • INSUFFICIENT: use final recognized standing

8. Create Route 53 hosted zone

A Route 53 hosted zone on this resolution may have failover routing primarily based on data pointing to IP addresses of main and standby database server. When the Route 53 well being examine is in an “Unhealthy” state, failover routing kicks in and the hosted zone begins routing requests to the IP handle of the standby database server.

• A Route 53 hosted zone may have data of your main and standby database occasion personal IP. As a result of it’s a personal hosted zone, it would use the identical VPC because the observer node on which we deployed the CloudWatch agent (Determine 10).

Determine 10. Amazon Route 53 hosted zone

• As soon as the Route 53 hosted zone is prepared, the final step is to create data by including personal IP addresses of main and secondary database servers (Figures 11 and 12). Routing coverage is about as a failover. Which means, if the Route 53 well being examine fails, the hosted zone does a DNS failover to standby server IP.

Determine 11. Amazon Route 53 hosted zone file for main servers

Determine 12. Amazon Route 53 hosted zone file for secondary servers

As soon as the data are created, the hosted zone may have an IP handle of main and secondary database servers, as demonstrated in Determine 13.

Determine 13. Remaining view of Amazon Route 53 hosted zone

Answer testing

To check the answer, do a telnet utility check to judge community connectivity on the Route 53 hosted zone that was created. It ought to show the IP handle of the first database server: 172.31.10.89.

[ec2-user@ip-172-xx-xx-xx ~]$ telnet dataguardviq.com 1522
Making an attempt 172.31.10.89…
Related to dataguardviq.com.
Escape character is ‘^]’.

Subsequent, carry out a switchover or failover of the first to secondary database server. This may be finished with the DGMGRL command “switchover to orclstd”. Output might be:

DGMGRL> switchover to orclstd;
Performing switchover NOW, please wait…
Operation requires a connection to database “orclstd”
Connecting …
Related to “orclstd”
Related as SYSDBA.
New main database “orclstd” is opening…
Oracle Clusterware is restarting database “orclviq” …
Related to an idle occasion.
Related to an idle occasion.
Related to an idle occasion.
Related to an idle occasion.
Related to “orclviq”
Related to “orclviq”
Switchover succeeded, new main is “orclstd”

Now, the brand new main is “orclstd”. Within the backend, the Route 53 well being examine might be initiated and trigger a failover. This implies the telnet Route 53 hosted zone will give the IP handle of the brand new main (outdated secondary), which is 172.31.36.241.

[ec2-user@ip-172-xx-xx-xx ~]$ telnet dataguardviq.com 1522
Making an attempt 172.31.36.241…
Related to dataguardviq.com.
Escape character is ‘^]’.

Cleanup

To cleanup, take away:

• Route 53 host zone
• CloudWatch metric filter
• CloudWatch alarm
• CloudWatch agent from observer node
• IAM function and coverage created particularly for this resolution

Conclusion

This resolution demonstrated easy methods to use a Route 53 hosted zone to route requests to the energetic main node for Oracle Knowledge Guard on Amazon EC2.