Deploy Oracle REST Data Services with high availability on Oracle Cloud Infrastructure

Deploy Oracle REST Data Services (ORDS) with high availability in Oracle Cloud Infrastructure and REST to enable your database.

ORDS bridges HTTPS and your Oracle database. As a mid-tier Java application, it provides a Database Management REST API, SQL Developer Web, a PL/SQL Gateway, SODA for REST, and the ability to publish RESTful Web Services for interacting with the data and stored procedures in your Oracle Database.

ORDS also provides increased flexibility by supporting deployments using Oracle WebLogic Server, Apache Tomcat, and a standalone mode. ORDS further simplifies the deployment process because there is no Oracle home required, as connectivity is provided using an embedded JDBC driver.

This reference architecture outlines how you can deploy ORDS across multiple VM Compute instances, creating a highly available mid-tier for your Oracle database instances.

Architecture

This architecture describes how you can deploy Oracle REST Data Services with high availability on Oracle Cloud Infrastructure.

The architecture starts with a Virtual Cloud Network (VCN) within a single region. While this VCN can span multiple Availability Domains (ADs), for this reference architecture, we'll use a single AD. That AD contains multiple Fault Domains, areas within an AD that have grouped hardware and infrastructure. We will deploy the compute VMs with ORDS across multiple fault domains to help in our high availability goals.

In this VCN, there are multiple subnets that contain specific components of our architecture. We start with an Internet Gateway which will allow only traffic over our specified port to the Load Balancers that are on the front end of this VCN in a public subnet. The load balancers will also have a public facing IP we can later use to apply custom domain names if needed. The Load Balancer will talk to the subnet containing our ORDS compute mid-tiers. Communication is secured by subnet-wide security lists as well as Network Security Groups (NSG). These NSGs can be applied to a set of VNICs on the compute and load balancers to provide granular security rules for communication between these resources.

Finally, again employing Security Lists and NSGs, the ORDS mid-tiers can access an Oracle database in a private subnet. resources using private subnets are not given public facing IPs. This way, we can use the NSGs for a secure communication layer between the public and private subnets. The Oracle database instance in this private subnet can be a VM DB instance, an autonomous database, or an Exadata Cloud Service database.

The following diagram illustrates this reference architecture.

Description of the illustration ha-ords-oci2-old.png

ha-ords-oci2-oracle.zip

This architecture has the following components:

• Region

  An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

• Availability domains

  Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region. The resources in this architecture are deployed in a single availability domain.

• Fault domains

  A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain. The resources in this architecture are deployed in multiple fault domains.

• Virtual cloud network (VCN) and subnets

  A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.

  In this reference architecture, the compute instances with ORDS are attached to a public subnet along with the load balancer while the databases can use either a private or public subnet. Database Security best practices put database instances in private subnets whenever possible.

• Load Balancer

  The Oracle Cloud Infrastructure Load Balancing service provides automated traffic distribution from a single entry point to multiple servers in the back end. This Load Balancer's public IP will also serve as where we can register custom domain names if needed.

• Compute Instances/ORDS Hosts

  Oracle Cloud Infrastructure Compute lets you provision and manage compute hosts. You can launch compute instances with shapes that meet your resource requirements (CPU, memory, network bandwidth, and storage). After creating a compute instance, you can access it securely, restart it, attach and detach volumes, and terminate it when you don't need it. The web servers in this architecture run on compute virtual machines using either an x86 or ARM CPU architecture

• Database Instances

  The Database service offers autonomous and co-managed Oracle Database cloud solutions. Autonomous databases are preconfigured, fully-managed environments that are suitable for either transaction processing or for data warehouse workloads. Co-managed solutions are bare metal, virtual machine, and Exadata DB systems that you can customize with the resources and settings that meet your needs.

  This reference architecture can be used for either Autonomous Databases or Co-Managed Database instances.

• Network security groups (NSG)

  NSGs act as virtual firewalls for your compute instances. With the zero-trust security model of Oracle Cloud Infrastructure, all traffic is denied, and you can control the network traffic inside a VCN. An NSG consists of a set of ingress and egress security rules that apply to only a specified set of VNICs in a single VCN. In this architecture, separate NSGs are used for the load balancer, web servers, and the database.

• Route Tables

  Virtual route tables contain rules to route traffic from subnets to destinations outside a VCN, typically through gateways.

• Internet Gateway

  The internet gateway allows traffic between the public subnets in a VCN and the public internet.

• Security Lists

  A security list acts as a virtual firewall for an instance, with ingress and egress rules that specify the types of traffic allowed in and out.

Recommendations

Use the following recommendations as a starting point. Your requirements might differ from the architecture described here.

• VCN

  When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.

  Select CIDR blocks that don't overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or another cloud provider) to which you intend to set up private connections.

  After you create a VCN, you can change, add, and remove its CIDR blocks.

  When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.

  Use regional subnets.

• Security

  Use Oracle Cloud Guard to proactively monitor and maintain the security of your resources in Oracle Cloud Infrastructure. Cloud Guard uses detector recipes that you can define to examine your resources for security weaknesses and to monitor operators and users for risky activities. When any misconfiguration or insecure activity is detected, Cloud Guard recommends corrective actions and assists with taking those actions, based on responder recipes that you can define.

  For resources that require maximum security, Oracle recommends that you use security zones. A security zone is a compartment associated with an Oracle-defined recipe of security policies that are based on best practices. For example, the resources in a security zone must not be accessible from the public internet and they must be encrypted using customer-managed keys. When you create and update resources in a security zone, Oracle Cloud Infrastructure validates the operations against the policies in the security-zone recipe, and denies operations that violate any of the policies.

• Database Instances

  For production applications, the Oracle database instance should be adhering to Oracle Maximum Availability Architecture (MAA) deployment model in OCI. Following these guidelines ensures that the database is not only highly available, but also protected from outages and disasters should they occur. These architectures also gain the benefit of reporting databases that utilize the DR instance.

  The MAA architecture is built right into the OCI Database Services, both co-managed and autonomous. Data Guard, GoldenGate, RAC and automatic backups are available right from the start and should be used for production environment where applicable.

  When using RAC with the Oracle Database, ensure that the database connection information used by ORDS is pointing to the SCAN listener and not an individual node.

• Compute/ORDS instances

  When sizing your compute mid-tiers, refer to the following chart for recommendations:

  Reference Architecture Sizes (Virtual Machines)

  Size	Compute Shape	CPU/Memory	Number of Compute Instances
  Extra Small Free	VM.Standard.E2.1.Micro	1 CPU/1 GB	1
  Extra Small Free HA	VM.Standard.E2.1.Micro	1 CPU/1 GB	2
  Small Free	VM.Standard.A1.Flex	4 CPU/24 GB	1
  Small Free HA	VM.Standard.A1.Flex	2 CPU/12 GB	2
  Small	VM.Standard.E4.Flex	1 CPU/16 GB	1
  Small HA	VM.Standard.E4.Flex	1 CPU/16 GB	2
  Medium	VM.Standard.E4.Flex	16 CPU/256 GB	1
  Medium	VM.Standard.A1.Flex	20 CPU/ 128GB	1
  Medium HA	VM.Standard.E4.Flex	16 CPU/256 GB	2+
  Medium HA	VM.Standard.A1.Flex	20 CPU/ 128 GB	2+
  Medium Large	VM.Standard.E4.Flex	32 CPU/512 GB	1
  Medium Large	VM.Standard.A1.Flex	40 CPU/256 GB	1
  Medium Large HA	VM.Standard.E4.Flex	32 CPU/512 GB	3+
  Medium Large HA	VM.Standard.A1.Flex	40 CPU/256 GB	3+
  Large	VM.Standard.E4.Flex	48 CPU/768 GB	1
  Large	VM.Standard.A1.Flex	60 CPU/384 GB	1
  Large HA	VM.Standard.E4.Flex	48 CPU/768 GB	3+
  Large HA	VM.Standard.A1.Flex	60 CPU/384 GB	4+
  Extra Large	VM.Standard.E4.Flex	64 CPU/1024 GB	1
  Extra Large	VM.Standard.A1.Flex	80 CPU/512 GB	1
  Extra Large HA	VM.Standard.E4.Flex	64 CPU/1024 GB	4+
  Extra Large HA	VM.Standard.A1.Flex	80 CPU/512 GB	6+

  Reference Architecture Sizes (Bare Metal)

  Size	Compute Shape	CPU/Memory	Number of Compute Instances
  Medium/Large	BM.Standard2.52	52 CPU/768 GB	1
  Medium/Large HA	BM.Standard2.52	52 CPU/768 GB	2+
  Medium/Large	BM.Standard.E4.128	128 CPU/2048 GB	1
  Medium/Large HA	BM.Standard.E4.128	128 CPU/2048 GB	2+
  Medium/Large	BM.Standard.A1.160	160 CPU/1024 GB	1
  Medium/Large HA	BM.Standard.A1.160	160 CPU/1024 GB	2+

• Flexible Load Balancing

  You can now create load balancers with upper and lower bounds so that they can scale based on the number of requests coming in. It can be as small as 10mbps up to 8000mbps.

Considerations

Consider the following points when deploying this reference architecture.

• Performance

  Compute, load balancers and Database Cloud Instances can all scale to handle increased load. With the compute/ORDS tier, additional instances can be quickly created and added to the Load Balancer configuration. For the Database tier, the Autonomous Database can be set to auto-scale the CPU/Memory when it experiences an increase in load. For co-managed instances, the VM-based service can scale the number of CPUs used on the VM. In the case of the Exadata Cloud Service, the X8M platform can not only scale CPU, but nodes can be added to the RAC cluster to add additional computing power.

• Security

  Be sure to use very granular rules in your subnet and NSG ingress/egress rules. You only want traffic over the expected ports to specific IPs of instances in your subnets. If access is needed to a compute or database tier, use the Bastion as a Service for access. This ensures that only authorized users can access these instances and only to the specific instances they are granted access to. Using the Bastion as a Service is a much more secure method than exposing SSH ports to the public internet.

• Availability

  Adhere to the Oracle Maximum Availability Architecture (MAA) guide for database deployments. For ORDS, multiple mid-tiers with a load balancer is recommended. Again, as a reminder, when using RAC with the Oracle Database, ensure that the database connection information used by ORDS is pointing to the SCAN listener and not an individual node.

• Cost

  Using auto-scaling and scaling in general of each compute and database tier will aid in controlling costs enabling you to pay for only what is being used with no excess or wasted CPU, memory or instances. Costs can also be controlled using a flexible load balancer.

Deploy

With a single click, you can pull the code for this architecture into Oracle Cloud Infrastructure Resource Manager, create the stack, and deploy it.

The architecture available via Oracle Cloud Infrastructure Resource Manager uses a single autonomous database whereas, in the above architecture, we recommend a disaster recovery database in production scenarios. It is used in this sample reference architecture to enable cost savings, speed and more attention centered on the compute/ORDS high availability deployment.

Deploy this architecture by using the sample stack in Oracle Cloud Infrastructure Resource Manager:

1. Click .

   If you aren't already signed in, enter the tenancy and user credentials.

2. Select the region where you want to deploy the stack.
3. Follow the on-screen prompts and instructions to create the stack.
4. After creating the stack, click Terraform Actions, and select Plan.
5. Wait for the job to be completed, and review the plan.

   To make any changes, return to the Stack Details page, click Edit Stack, and make the required changes. Then, run the Plan action again.

6. If no further changes are necessary, return to the Stack Details page, click Terraform Actions, and select Apply.

Explore More

Learn more about using Oracle Cloud Infrastructure.

• Best practices framework for Oracle Cloud Infrastructure
• Oracle Maximum Availability Architecture (MAA)
• Oracle REST Data Services
• Oracle Database Development Tools

.