Understand the Oracle E-Business Suite Topology

Before You Begin

Before you begin planning to deploy or migrate your Oracle E-Business Suite application, identify if Oracle Cloud Infrastructure supports the version of the Oracle E-Business Suite application that you want to deploy. Oracle Cloud Infrastructure supports Oracle E-Business Suite release 12.2 and 12.1.3.

About Logical Host Names

Oracle recommends that you use logical host names, not physical host names, when you set up the Oracle E-Business Suite database tier and application tier. The advantages of using logical host names are:

Provide the capability of moving the database and application tiers to other machines or data centers without running a clone and reconfiguration.
Reduce the amount of reconfiguration required on failover for high availability by using the same host name on the active and standby site.
Avoid rewiring or recloning the database and application tiers due to network configuration changes, such as a host name change.

About the Bastion Host

A bastion host is an optional component that you can use with firewall policies to protect the management interfaces of database and application servers from external access. A bastion host is an Oracle Cloud Infrastructure Compute instance that uses Linux or Windows as its operating system.

Place the bastion host in a public subnet and assign it a public IP address to access it from the internet.

To provide an additional level of security, you can set up security lists to access the bastion host only from the public IP address of your on-premises network. You can access Oracle Cloud Infrastructure instances in the private subnet through the bastion host. To do this, enable ssh-agent forwarding, which allows you to connect to the bastion host, and then access the next server by forwarding the credentials from your computer. You can also access the instances in the private subnet by using dynamic SSH tunneling. SSH tunneling is a way to access a web application or other listening service. The dynamic tunnel provides a SOCKS proxy on the local port, but the connections originate from the remote host.

About the Load Balancer Tier

Use Oracle Cloud Infrastructure Load Balancing to distribute traffic to your application instances across availability domains within a VCN. This service provides a primary and standby instance of the load balancer to ensure that if the primary load balancer goes down, the standby load balancer forwards the requests. The load balancer ensures that requests are routed to the healthy application instances. If there’s a problem with an application instance, then the load balancer removes that instance and starts routing requests to the remaining healthy application instances.

Based on your requirements, you can place load balancers in a public or private subnet.

For internal endpoints, that aren’t accessible from the internet, use a private load balancer. A private load balancer has a private IP address, and it isn’t accessible from the internet. Both the primary and the standby instances of a load balancer reside in the same private subnet. You can access private load balancers in the VCN or in your data center over the IPSec VPN through a DRG. The private load balancer accepts traffic from your data center, and distributes the traffic to underlying application instances.
For internet-facing endpoints, use a public load balancer. A public load balancer has a public IP address, and it’s accessible from the internet. You can access the public load balancers from the internet through the internet gateway.
For accessing internal endpoints and internet-facing endpoints, set up private load balancers and public load balancers. Set up private load balancers to serve the internal traffic, and set up public load balancers to serve the traffic from the internet.

Register the public or private IP address of Oracle Cloud Infrastructure Load Balancing instances in your on-premises or public domain name server (DNS) for domain resolution of your application endpoint.

About the Application Tier

The application tier is in a subnet, that’s separate from the subnets for the load balancer and database instances. You must deploy at least two application instances in an availability domain to ensure to that the application instances in the availability domain are highly available.

You can deploy Oracle E-Business Suite with multiple application tier nodes that work with an Oracle E-Business Suite database. Oracle recommends that you deploy Oracle E-Business Suite multitier setup with shared application binaries. When you use a shared application tier file system, the Oracle E-Business Suite application tier file system is shared with each node in the multinode environment. Use Oracle Cloud Infrastructure File Storage to create a shared file system to share and synchronize Oracle E-Business Suite application binaries among multiple application hosts. When you use a shared file system for multiple application hosts, it reduces disk space requirements and eliminates the need to apply patches to each application host in the environment.

Traffic flows from the load balancer to the application instances through specific ports that you define in the security rules. Set up security rules to permit traffic only from the load balancer over port 8000 and from the bastion host over port 22.

You can use the policy based backup feature of Oracle Cloud Infrastructure Block Volumes to back up Oracle E-Business Suite application instances.

About the Database Tier

Oracle Cloud Infrastructure offers several options to set up an Oracle Database System (DB System). Place DB Systems in a separate subnet. Oracle recommends the the database service on Oracle Cloud Infrastructure to be created in a private subnet. Use security lists to restrict access to the database servers only from the bastion host, application servers, and on-premises servers.

You can deploy the database using a single-node Oracle Compute virtual machine, a single–node virtual machine DB system, a two node Oracle Real Application Clusters (RAC) virtual machine DB system, or an Oracle Exadata DB system. To provide high availability within an availability domain, Oracle recommends using 2-node virtual machine DB system or an Oracle Exadata DB system. Either of the 2-node virtual machine DB system or the Oracle Exadata DB system leverages Oracle RAC and deploys a 2-node cluster for high availability. In either case, both instances of the database in an availability domain are active. Requests received from the application tier are load balanced across the database instances. Even if one database instance is down, the other database instance services requests.

For the database tier, it is recommended that you set up security lists to ensure that communication occurs only over port 22, through the bastion host, and over port 1521, through the application server. You can use Oracle Cloud Infrastructure Object Storage to back up the Oracle E-Business Suite database by using Oracle Recovery Manager (RMAN).

If you deploy Oracle E-Business Suite in multiple availability domains for high availability, you must setup Oracle Data Guard or Oracle Active Data Guard in synchronous mode to replicate database changes across the database in the two availability domains.

About the Security Lists

In Oracle Cloud Infrastructure, firewall rules are configured through security lists. A separate security list is created for each subnet.

Oracle recommends that you create separate subnets for the database, application, load balancer, and bastion hosts to ensure that the appropriate security list is assigned to the instances in each subnet. Use security lists to permit traffic between different tiers and between the bastion host and external hosts. Security lists contain ingress and egress rules to filter traffic at the subnet level. They also contain information about communication ports through which data transfer is permitted. Those ports (or in some cases, the protocols that will need open ports in the security rules) are shown on each security rule line in the architecture diagrams.

Each security list is enforced at the instance level. However, when you configure your security lists at the subnet level, all instances in a particular subnet are subject to the same set of rules. Each subnet can have multiple security lists associated with it, and each list can have multiple rules. The transfer of a data packet is permitted if a rule in any of the lists allows traffic (or if the traffic is part of an existing connection that’s being tracked). In addition to security lists, use iptables to implement another layer of security at the instance level.

For deployments in a public subnet, you can provide an additional level of security by preventing access to the application and database instances from the internet. Use a custom security list to prevent access to the application and database instances from the internet, and permit access to the database and application hosts over port 22 from the bastion host for administration purposes. Don’t enable SSH access to the application and database instances from the internet, but you can permit SSH access to these instances from the subnet that contains the bastion host.

You can access your instances in the private subnet through the bastion server.

Security List for the Bastion Host

The bastion security list allows the bastion host to be accessible from the public Internet over port 22.

To permit SSH traffic from the on-premises network to the bastion host over Internet:

Stateful ingress: Allow TCP traffic from the source CIDR 0.0.0.0/0 and all source ports to the destination port 22 (SSH).

Source Type = CIDR, Source CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = 22

You can also restrict bastion host to be accessible over the Internet on port 22 only from your data center instead of public Internet (0.0.0.0/0). To achieve this, use your edge router IP instead of the source CIDR as 0.0.0.0/0 in the stateful ingress rule.
To permit SSH traffic from the bastion host to Oracle Cloud Infrastructure Compute instances:

Stateful egress: Allow TCP traffic to the destination CIDR 0.0.0.0/0 from all source ports to the destination port 22 (SSH).

Destination Type = CIDR, Destination CIDR = <CIDR block of VCN>, IP Protocol = TCP, Source Port Range = All, Destination port range = 22

Security List for the Load Balancer Tier

The architecture diagrams show private load balancers, which are placed in private subnets. If you place the load balancer instances in a public subnet, then you’re permitting traffic from the Internet (0.0.0.0/0) to the load balancer instances.

To permit traffic from the Internet to the load balancer:

Stateful ingress: Allow TCP traffic from source CIDR (Internet) 0.0.0.0/0 and all source ports to the destination port 8888 (HTTP) or 443 (HTTPS).

Source Type = CIDR, Source CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = 8888 or 443
To permit traffic from the on-premises network to the load balancer:

Stateful ingress: Allow TCP traffic from the on-premises network CIDR block and all source ports to the destination port 8888 (HTTP) or 443 (HTTPS)

Source Type = CIDR, Source CIDR = <CIDR block for onpremises network>, IP Protocol = TCP, Source Port Range = All, Destination port range = 8888 or 443
To permit traffic from the load balancer tiers to the application tiers:

Stateful egress: Allow TCP traffic to destination CIDR 0.0.0.0/0 from all source ports to the destination port 8000 (HTTP)

Destination Type = CIDR, Destination CIDR = <CIDR block for application subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 8000

Security List for the Application Tier

The security list for the application tier permits traffic from the load balancer tier to the application tier.

To permit traffic from the bastion host to the application tier:

Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of bastion subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 22
To permit traffic from the load balancer tier to the application tier:

Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of load balancer subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 8000
To permit traffic across application instances in the application tier:

Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of application subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = All
To permit traffic from the application tier to the database tier and across application instances in the application tier:

Stateful egress: Destination Type = CIDR, Destination CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = All

For communication across application tiers in a multiple application tier configuration (This is required for Oracle E-Business Suite EBS 12.2 only):

Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of application subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 7001-7002
Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of application subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 7201-7202
Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of application subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 7401-7402
Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of application subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 7601-7602

Security List for the Database Tier

To permit traffic from the bastion host to the database tier:

Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of bastion subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 22
To permit traffic from the application tiers to the database tier:

Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of application subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range =1521
To permit traffic from the database tier to the application tier:

Stateful egress: Destination Type = CIDR, Destination 0.0.0.0/0 on TCP, source port = All, destination port = All
To permit traffic for backup of database to Oracle Cloud Infrastructure Object Storage:

Stateful egress: Destination Type = Service, Destination OCI <region> Object Storage, source port = All, destination port = 443

For multiple availability domain architecture, to permit traffic between the database tiers across availability domains for Oracle Active Data Guard:
- Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of database subnet in availability domain 1>, IP Protocol = TCP, Source Port Range = All, Destination port range =1521
- Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of database subnet in availability domain 2>, IP Protocol = TCP, Source Port Range = All, Destination port range =1521

For Oracle Database Exadata Cloud Service system provisioning, the following additional rules are required:

Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of exadata client subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range =All
Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of exadata client subnet>, IP Protocol = ICMP, Type and Code = All
Stateful egress: Destination Type = CIDR, Destination CIDR = <CIDR block of exadata client subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = All
Stateful egress: Destination Type = CIDR, Destination CIDR = <CIDR block of exadata client subnet>, IP Protocol = ICMP, Type and Code = All