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

Deploy Oracle REST Data Services (ORDS) with high availability on Oracle Cloud Infrastructure (OCI) and REST to enable your database and expose the benefits of microservices architecture and capabilities.

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 that use Oracle WebLogic Server or Apache Tomcat, or are in a standalone mode. ORDS further simplifies the deployment process because there is no Oracle home required, as an embedded JDBC driver provides connectivity.

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

Architecture

This architecture shows you how to deploy Oracle REST Data Services with high availability on OCI.

The architecture starts with a Virtual Cloud Network (VCN) within a single region. While this VCN can span multiple Availability Domains (AD), for this reference architecture, it uses a single AD. That AD contains multiple fault domains—areas within an AD that have grouped hardware and infrastructure. Compute VMs with ORDS are deployed across multiple fault domains to help in attaining high availability.

In the VCN, multiple subnets contain specific architectural components. It starts with an Internet gateway, which only allows traffic over a specified port to the load balancers on the front end of this VCN in a public subnet. The load balancers also have a public facing IP you can later use to apply custom domain names, if needed. The load balancer will talk to the subnet containing the ORDS compute mid-tiers. Communication is secured by subnet-wide security lists as well as network security groups (NSG). You can apply these NSGs 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, you 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 ha-ords-oci3.png follows
Description of the illustration ha-ords-oci3.png

ha-ords-oci3.zip

This architecture has the following components:

Region
An OCI 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 OCI 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.
API Gateway
Oracle Cloud Infrastructure API Gateway enables you to publish APIs with private endpoints that are accessible from within your network, and which you can expose to the public internet, if required. The endpoints support API validation, request and response transformation, CORS, authentication and authorization, and request limiting.
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 OCI, 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
Security list are a set of ingress and egress rules that specify the types of traffic allowed in and out for all VNICs/instances in a subnet. Security Lists are applied at subnet level vs NSGs are applied at a VNIC level. Both effectively act as a firewall for a VNIC. With OCI's zero-trust security model, all traffic to a VNIC is denied. Both SL and NSG need to allow the traffic explicitly, for the traffic to be permitted to the VNIC.
Zero-Trust Packet Routing (ZPR)
In addition to SL and NSG, OCI has a network security construct called Zero-Trust Packet Routing. ZPR is intent-based secure networking acting at layer 4 and can be implemented in human readable policy language. By assigning security attributes ("tags" for ZPR) to your resources, you can create granular access controls to ensure that only authorized entities can communicate with sensitive components, such as databases and application servers. This approach not only reduces the risk of unauthorized access but also simplifies policy management as your application evolves. ZPR operates alongside existing NSGs and SLs, providing a more comprehensive security posture that adapts to changes in your network architecture. Here you can assign security attributes (special ZPR tags) to nodes in each subnet, in such a way that only required traffic is permitted (flow direction, protocol and ports), no matter how the network architecture changes/shifts in future.

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.
Load Balancing
OCI offers flexible load balancing. You can create load balancers with upper and lower bounds so that they can scale based on the number of requests coming in. Bounds can range from as small as 10mbps up to 8000mbps. For instances where multi-AD or multi-region load balancing is needed, use DNS Cloud Service with traffic management steering capability.
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 adhere to Oracle's 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 Oracle Cloud Infrastructure Database services, both co-managed and autonomous. Data Guard, GoldenGate, RAC and automatic backups are immediately available and should be used for production environment where applicable.

When using RAC with Oracle Cluster Registry (OCR)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)

Shape

Maximum OCPUs

Minimum Memory

Maximum Memory

VM.Standard3.Flex