Maintaining Oracle HTTP instances

Michael Mikhailidi -

The Oracle HTTP Server (OHS) is essential to any large Oracle Fusion Middleware environment. And despite the most common description for that product being "Apache HTTP server with custom modules," it's not as simple as it sounds. Let's walk around and take a look at how it's made.

Oracle HTTP Server 12c integration with the Oracle Fusion Middleware is so deep you need to bring a big part of the infrastructure to make a standalone installation. So, if you want to run a standalone OHS server, start from the classic domain configuration procedure. The new domain is not an application grade, and the whole purpose of it - accommodate standard Oracle Fusion Middleware Infrastructure components:  

  • Node Manager
  • WLST Processor
  • Components
  • Oracle PKI Tool, aka orapki

The standard NodeManager process controls the domain configuration and deployed components.  So if you need to run OHS lifecycle commands, keep in mind that the corresponding NodeMnager is up and running.

I don't want to walk through OHS instance creation or removal steps. The vendor documents them well, plus hundreds if not thousands of step-by-step instructions on the tip of your finger.  Let's take a closer look at the domain's component, in our case - a pretty standard set of Apache HTTPD configuration files.  

Instance folder and content are buried deep into the domain entrails. I will use environment variables referring to file locations. Let's assume that:

ORACLE_HOME=/opt/oracle/Middleware
DOMAIN_HOME=$ORACLE_HOME/user_projects/domains/ohsdomain
OHS1_INST=$DOMAIN_HOME/config/fmwconfig/components/ohs1
OHS2_INST=$DOMAIN_HOME/config/fmwconfig/components/ohs2
Sample environment variables

Some people prefer pictures over text, so the diagram below displays relations between various components and locations. It's a bit complicated and depicts

  • Two independent installations, which we refer to as the $ORACLE_HOME;
    There are a handful of reasons why you need multiple OHS binaries on the same VM, and the most obvious are: complex migrations and some compatibility requirements.
  • Each $ORACLE_HOME servers to one or more OHS domains, and it's a common practice to assign this to the $DOMAIN_HOME variable. As any WebLogic domain, it has a NodeManager, configuration folders, scripts, and directory structure to accommodate one or more OHS instances.
  • Each $DOMAIN_HOME supports one or more OHS instances or, in domain terms - components. Finally, we reached the level where it is  "same as Apache HTTPD." You find pretty much the same configuration files, well-known folder structure, and instructions of Apache HTTPD 2.4.x. Of course, Oracle's extras are here: webgate (if configured), mod_wl, and Oracle's proprietary security module.
Overcomplicated OHS Installation
?
One significant difference between Apache HTTPD and Oracle OHS is that you can't create a name-based secured virtual host. You still could have port- or address-based virtual hosts, managed by the same instance.

You may already wonder, why each component is duplicated on the diagram above. That's because Oracle has engineered it this way! At any point in time, you have at least two copies of your web server component:

  • $DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1 - is your "master copy" of the component. If you want to update the site certificate, change parameters, or refresh static content this folder is your go-to location for that.
  • $DOMAIN_HOME/config/fmwconfig/components/OHS/instance/ohs1 - is a working replica of your master copy. The Running HTTPD process uses an instance folder for the process configuration and static content serving; NodeManager monitors component changes and replicates them to the instance.  
❗
You can make changes directly on the instance, but NodeManager would never propagate them back to the master copy. Considering the instance/component copy there is no guarantee that your direct instance update would survive some reconfiguration event. 

The commands that make NodeManager check and update components are:

$DOMAIN_HOME/bin/stopComponent.sh  - Script accepts a component name as a parameter and performs shutdown of the HTTPD processes. It will ask for the NodManager password if the credentials weren't stored in the user's home folder.

$DOMAIN_HOME/bin/startComponent.sh  - Script accepts a component name as a parameter and tries to start HTTPD processes for the given component.  It will ask for the NodManager password if the credentials weren't stored in the user's home folder. Additionally, you can instruct this script to store NodeManasger credentials in the users' home folder.

$DOMAIN_HOME/bin/restartComponent.sh  - This script is not a stop/start command combination. HTTPD would make the best effort to serve all existing sessions and relocate them to the updated process.  

To summarize:

  • The standalone Oracle HTTP Server has simplified infrastructure to manage HTTPD instances in the same way as the other non-Java components.
  • Each OHS component is an independent HTTPD configuration, used by NodeManager to maintain the working replica. Never update the component instance, only the component itself, otherwise, your changes could be lost.
  • OHS offers start, stop, and restart commands for OHS components, and restart is not the same as the stop + start combination.