Prepare the Web-tier on OCI
Provision and configure your secondary site on Oracle Cloud Infrastructure (OCI) to be consistent with your primary on-premises site.
Note:
You can find Terraform code to create the resources described in this section (the OCI Load Balancer, the SSL certificate, the backend sets and backends, the routing policies, the listeners and the rule sets) in Download Code.
(Optional) Prepare the Oracle HTTP Server Hosts
Note:
Creating and configuring Oracle HTTP Server is optional. You can configure the web-tier on OCI using only the OCI Load Balancer (without using Oracle HTTP Server).
Provision the Oracle HTTP Server Hosts
Each Oracle HTTP Server running in OCI must have a valid License and support contract in addition to the License and support contract used to cover the Oracle HTTP Server running on-premises. You can use Oracle WebLogic Server for OCI images to create compute instances for Oracle HTTP Server on Oracle Cloud. The compute instances created with these images include the entitlement to run Oracle HTTP Server and are billed per OCPU/Hour for the entitlement to run WebLogic software when they are in running state. When creating the compute instances with Oracle WebLogic Server for OCI, you can use the Compute Instance Console or the Marketplace. These images are available for Oracle Linux 7.9 and Oracle Linux 8.5 operating systems.
This example uses two compute instances in a single availability domain within the compartment, as shown in the table.
Name | Compartment | Availability Domain | Image | Shape | VCN | Subnet |
---|---|---|---|---|---|---|
hydrohs1 | HyDRCompmt | AD1 | Oracle WebLogic Enterprise Edition UCM Image (Oracle Linux 7.9) | VM.Standard2.2 | hydrvcn | webTierSubnet |
hydrohs2 | HyDRCompmt | AD1 | Oracle WebLogic Enterprise Edition UCM Image (Oracle Linux 7.9) | VM.Standard2.2 | hydrvcn | webTierSubnet |
Perform the following to provision the compute instances using the Compute Instance Console:
Prepare the Operating System Users and Groups
The same user and group used by the primary on-premises Oracle software are needed in the secondary compute instances.
Oracle WebLogic Server for
Oracle Cloud Infrastructure images already have an oracle user and group. However, these values (user name,
group name, uid
, and gid
) might not match the
values that you have in your primary instance and you'll need to configure the
secondary hosts to match the values of the primary oracle user and group. The
following examples show how to configure the secondary hosts in this tier to match
the values of the primary oracle user and group.
Prepare the Operating System Requirements
runinstaller
in
the secondary hosts. Because the Oracle WebLogic Server for
Oracle Cloud Infrastructure images are prepared for the WebLogic software, you do not need to manually add
packages for WebLogic. However, these Oracle HTTP Server hosts will run the Oracle HTTP Server product. Make sure that the secondary hosts meet the requirements for Oracle HTTP Server.Prepare the Host Name Aliases for Oracle HTTP Server
This can be implemented in 2 ways:
- Add the host names as aliases to the
/etc/hosts
files of the Oracle WebLogic Server for OCI compute instances. - Use a private DNS view in the secondary OCI VCN.
Use /etc/hosts
Files
/etc/hosts
files of
the secondary hosts, pointing to the IP addresses of the secondary hosts.
This mode is valid in all scenarios when the DNS server is the same in the
primary on-premises and on the secondary Oracle Cloud
Infrastructure (OCI) sites, and also when separated DNS servers are used in the primary and secondary
sites. The entries in the /etc/hosts
file have precedence over the DNS
resolution, because this is the precedence defined out-of-the-box in the directive “hosts”
of the /etc/nsswitch.conf
file.
However, this method requires that you manually add the entries to all of the Oracle HTTP Server hosts:
Use the Domain Name System (DNS)
/etc/hosts
files of
all of the hosts.
Add the entries for the Oracle HTTP Server virtual host names to the Private View created in OCI in the step Prepare the Mid-tier on OCI:
Open the Required Ports in the OCI Host's Firewalls
ssh
, dhcp
). You must open the
ports used by Oracle HTTP Server.
Create the
oracle
User Environment Variables for Oracle HTTP Server
oracle
user’s profile
in the Oracle HTTP Server hosts. For example, ORACLE_HOME
, JDK_HOME
,
PATH
, WEB_DOMAIN_HOME
, and others.
Replicate the Oracle HTTP Server Product and Configuration from the Primary
rsync
to copy the binaries and Oracle HTTP Server configuration from the primary Oracle HTTP Server nodes.
Alternatively, you can download the Oracle HTTP Server software, install and configure it from zero in the OCI Oracle HTTP Server compute instances. This approach is out of the scope of this document. However, you must use this approach when the Oracle HTTP Server OCI compute instances have a different operating system than the primary Oracle HTTP Server hosts.
Oracle HTTP Server binaries and configuration files normally reside in private storage. In OCI, you can use the block volume that the compute instance has by default. Alternatively, you can create a new block volume for each Oracle HTTP Server compute (as described in the Prepare the OCI Block Volumes), and mount each one in the Oracle HTTP Server compute instances (as described in Mount the OCI Block Volumes).
This example uses the default block volume of the Oracle HTTP Server compute instances without creating any additional block volumes.
The Oracle HTTP Server configuration and binaries do not change frequently overtime. After this initial replication, you can repeat the same replication during the lifecycle. Alternatively, you can manually maintain the configuration of the Oracle HTTP Server in the primary and secondary by implementing the Oracle HTTP Server configuration changes in both sites.
Prepare OCI Load Balancer
Create and configure the Oracle Cloud Infrastructure Load Balancer on the cloud.
Note:
You can find Terraform code to create the resources described in this section (the OCI Load Balancer, the SSL certificate, the backend sets and backends, the routing policies, the listeners and the rule sets) in Download Code.
Provision the OCI Load Balancer
To be consistent with the primary on-premises site, provision a load balancer on your secondary site on Oracle Cloud Infrastructure (OCI) as the entry point to the system.
Create the Backend Sets
A backend set is a logical entity that contains a list of backend servers that run the same applications. When you define a backend set, you must specify a load balancing policy and a health check test. Then you can add the list of backend servers.
The configuration of the backend sets depends on whether or not you're using Oracle HTTP Server in front of the WebLogic Server hosts.
If you're using Oracle HTTP Server, then the Oracle Cloud Infrastructure (OCI) Load Balancer sends the requests to the HTTPS servers. Create a backend set for each port exposed by the HTTPS servers. For example: create one backend set for the Oracle HTTP Server listener that provides access to the applications, and another backend set for the Oracle HTTP Server listener that provides access to each Oracle WebLogic Server Administration Console.
If you're not using Oracle HTTP Server, then the OCI Load Balancer sends the requests to the WebLogic servers directly. Create a backend set for each Oracle WebLogic Server Cluster and another backend set for the Admin Server.
- Log into the OCI Console.
- Select the proper region and compartment.
- In the navigation menu, click Networking, and then click Load Balancers.
- Click the load balancer to which you want to add a backend.
- Click Backend Sets under the Resources menu, then click Create Backend Set.
- Enter the following in the Create Backend Set dialog box:
- Click Create.
If your Oracle HTTP Server listens in additional ports for other services, create a backend set for each service in a similar way.
The following is an example of the backend sets when you use Oracle HTTP Server.
Component | Backend Set Name | Traffic Distribution Policy | Session Persistence | Cookie name (example) | Attribute: secure | Health Check |
---|---|---|---|---|---|---|
Admin Server | OHS_Admin_backendset |
Weighted Round Robin | Enable load balancer cookie persistence | X-Oracle-LBR-ADMIN-Backendset |
Unchecked | TCP or HTTP |
All SOA components
|
OHS_HTTP_backendset |
Weighted Round Robin | Enable load balancer cookie persistence | X-Oracle-LBR-OHS-HTTP-Backendset |
Checked | TCP or HTTP |
Oracle Web Services Manager | OHS_HTTP_internal_backendset |
Weighted Round Robin | Enable load balancer cookie persistence | X-Oracle-LBR-OHS-Internal-HTTP-Backendset |
Unchecked | TCP or HTTP |
If your Oracle HTTP Server listens in additional ports for other services, create a backend set for each service in a similar way.
The following is an example of the backend sets when you do not use Oracle HTTP Server.
Component | Backend Set Name | Traffic Distribution Policy | Session Persistence | Cookie name (example) | Attribute: secure | Health Check |
---|---|---|---|---|---|---|
All products (admin) | Admin_backendset |
Weighted Round Robin | Enable load balancer cookie persistence | X-Oracle-LBR-ADMIN-Backendset |
Unchecked | TCP or HTTP |
Oracle Web Services Manager | WSM_backendset |
Weighted Round Robin | Enable load balancer cookie persistence | X-Oracle-LBR-WSM-Backendset |
Unchecked | TCP or HTTP |
Oracle SOA Suite, Business Process Management, and Oracle B2B | SOA_backendset |
Weighted Round Robin | Enable load balancer cookie persistence | X-Oracle-LBR-SOA-Backendset |
Checked | TCP or HTTP |
Oracle Service Bus | OSB_backendset |
Weighted Round Robin | Enable load balancer cookie persistence | X-Oracle-LBR-OSB-Backendset |
Checked | TCP or HTTP |
Oracle Enterprise Scheduler (ESS) | ESS_backendset |
Weighted Round Robin | Enable load balancer cookie persistence | X-Oracle-LBR-ESS-Backendset |
Checked | TCP or HTTP |
Business Activity Monitoring (BAM) | BAM_backendset |
Weighted Round Robin | Enable load balancer cookie persistence | X-Oracle-LBR-BAM-Backendset |
Checked | TCP or HTTP |
If you have additional WebLogic clusters, create a backend set for each cluster in a similar way.
Define the Backends for Each Backend Set
Define the backends for each backend set in the Oracle Cloud Infrastructure (OCI) Load Balancer.
If you are using Oracle HTTP Server, then add the Oracle HTTP Server nodes and appropriate ports as backends in each backend set.
If you are not using Oracle HTTP Server, then add the Oracle WebLogic Server nodes and appropriate ports as backends in each backend set.
- In the Console, select a Backend Set. Click Backends, then click Add Backends.
- Enter the IP address and port for the server that is the backend.
The table shows the backend sets created in the example of this document when using Oracle HTTP Server:
Backend Set Name | Backends |
---|---|
OHS_Admin_backendset |
Compute Instances:
|
OHS_HTTP_backendset |
Compute Instances:
|
OHS_HTTP_internal_backendset |
Compute Instances:
|
The table shows the backend sets created in the example of this document when NOT using Oracle HTTP Server:
Backend Set Name | Backends |
---|---|
Admin_backendset |
IP Addresses:
|
WSM_backendset |
Compute Instances:
|
SOA_backendset |
Compute Instances:
|
OSB_backendset |
Compute Instances:
|
ESS_backendset |
Compute Instances:
|
BAM_backendset |
Compute Instances:
|
Define the Routing Policies and Configure the Rules
The routing policies are used to dispatch the incoming
requests to the correct backend set. For example, a request to /console
is dispatched to the Admin backend set, and a request to the /app1
is
dispatched to the backend set of the Cluster where app1
is
running.
If you are using Oracle HTTP Server, then you normally define the routes (such as /app1
,
/app2
, /console
, and so on) in the Oracle HTTP Server configuration. In this case, you don’t need to define the routing policies and
rules in the Oracle Cloud
Infrastructure (OCI) Load Balancer.
If you are not using Oracle HTTP Server, then you need to define the routing policies and rules in the OCI Load Balancer, to dispatch the requests to the appropriate backend set.
Component | Routing Policy Name | Rule | Conditions: If Any Match Path starts with | Action: Route to Backend Set |
---|---|---|---|---|
All products (admin) | Admin_Rules |
Admin_routerule |
|
Admin_backendset |
Oracle Service Bus (admin) | Admin_Rules |
Admin_routerule |
|
Admin_backendset |
Oracle Web Services Manager | Internal_Rules |
WSM_routerule |
|
WSM_backendset |
Oracle Service Bus | SOA_Rules |
OSB_routerule |
|
OSB_backendset |
Oracle SOA Suite | SOA_Rules |
SOA_routerule |
(*) more custom alias maybe required for custom tasks |
SOA_backendset |
Business Process Management | SOA_Rules |
SOA_routerule |
|
SOA_backendset |
Oracle Enterprise Scheduler (ESS) | SOA_Rules |
ESS_routerule |
|
ESS_backenset |
Business Activity Monitoring (BAM) | SOA_Rules |
BAM_routerule |
|
BAM_backendset |
Oracle B2B | SOA_Rules |
B2B_routerule |
|
SOA_backendset |
You can create as many routing policies, rules and conditions as you need for your environment.
Create the Listeners
Create the listeners for each combination of front-end name and port that is used to access the system. You must use the same host names (virtual front-end names) and ports that are used by the primary load balancer.
- Add the virtual front-end host name as host name in the Oracle Cloud Infrastructure Load Balancer.
- Create the listeners.
The following table is a summary of the listeners created in the example of this document, and their associated protocol, port, backend sets, routing policy, host name, and SSL usage. This is just as a reference example. If your system uses additional front-end host names, ports, or protocols in the primary Oracle WebLogic Server system, then you must create the corresponding listeners and host names according to your needs. For example, if you use an alternate front-end to access the Oracle WebLogic Server Console and Oracle Enterprise Manager Console.
Listener | Protocol | Port | Backend Set | Routing Policy | HostName | Use SSL |
---|---|---|---|---|---|---|
Admin_listener |
HTTP | 7001 |
|
Admin_Rules |
mysoa.example.com | No |
HTTPS_listener |
HTTPS | 443 |
|
SOA_Rules |
mysoa.example.com | Yes |
HTTP_listener |
HTTP | 80 | N/A* | N/A | mysoa.example.com | No |
Internal_listener |
HTTP | 8888 |
|
Internal_Rules |
mysoa.example.com | No |
* The HTTP_listener
in this example is used only for
redirecting requests to the HTTPS_listener
(HTTPS). The backend
assigned to it will not be used. But, since it is mandatory to provide one, you need
to provide one that has no SSL checked (use a default empty backend set).
Create the Rule Set for SSL Headers
Create a rule set for SSL headers in the Oracle Cloud Infrastructure (OCI) Load Balancer and associate it to the HTTPS listener.
Create the Rule Set to Redirect the HTTP Protocol to HTTPS
Create a redirect rule and associate it with the HTTP_listener to redirect port 80 to port 443. For the EDG topology, all requests that reach port 80 (HTTP) in the Load Balancer must be redirected to port 443 (HTTPS).
Add the Virtual Front-end Name and IP to the SOA Compute Instances
In a disaster recovery topology, the clients must access the system using a front-end FQDN (usually referred to as virtual front-end name or vanity URL) that is agnostic to the data center. This virtual front-end name should resolve to the Load Balancer IP address of the current active (primary) site.
The primary system should already be using a front-end virtual name that
is resolved by the DNS with the IP of the primary Load Balancer. However, the Oracle SOA Suite hosts of each site should always resolve the front-end name with its
local load balancer, regardless of client-facing resolution with DNS. For this, the
virtual front-end name is added to their /etc/hosts
file with
the appropriate IP address in each site. You can also achieve this by using
different DNS servers in each site. In that case, the local DNS server would resolve
the front-end name with the appropriate load balancer IP in each site.
Use /etc/hosts
Files
/etc/hosts
file of the primary and secondary Oracle WebLogic Server hosts must not be altered when there is a switchover or failover. The Oracle WebLogic Server hosts will always resolve the virtual front-end name with its front-end IP.
The DNS update that is needed during the switchover and failover procedures is
performed in the DNS or host files used by the Oracle WebLogic Server clients.
Use the Domain Name System (DNS)
If you are following this approach, you can add the front-end name (pointing to the secondary load balancer IP) to the DNS service used by the secondary mid-tiers. In primary, it is expected that the front-end name is already resolved pointing to the primary load balancer IP.
In the primary, it is expected that the front-end name is already resolved pointing to the primary load balancer IP.