Skip Headers
Oracle® Fusion Middleware Exalogic Enterprise Deployment Guide
Release EL X2-2 and EL X3-2

Part Number E18479-10
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

6 Configuring Oracle HTTP Server

This chapter describes how to configure Oracle HTTP Server 11g Release 1 (11.1.1.5.0) to support the Oracle Exalogic enterprise deployment.

To configure Oracle HTTP Server, you must complete the following steps:

6.1 Important Notes Before You Begin

If you are an Oracle Solaris user, read Section 3.1, "Important Notes for Oracle Solaris Users" before you configure Oracle HTTP Server.

6.2 Prerequisites

The following are the prerequisites for configuring Oracle HTTP Server 11g Release 1 (11.1.1.5.0) for Oracle Exalogic:

6.3 Mandatory: Configuring Oracle HTTP Server for Administration Server and Managed Servers

You must complete this procedure to enable Oracle HTTP Server to route traffic to the Administration Server and to the Oracle WebLogic cluster . This Oracle HTTP Server installation is outside of Exalogic. Dept1_Cluster1 is the cluster to which the application will be deployed, and you must set the WebLogicCluster parameter to the list of Managed Servers in the cluster as follows:

Note:

WEBHOST1 and WEBHOST2 are used as the example hosts for the Oracle HTTP Server instances (OHS1 and OHS2) in these procedures.

  1. On WEBHOST1 and WEBHOST2, add the following lines to the ORACLE_BASE/admin/<instance_name>/config/OHS/<component_name>/mod_wl_ohs.conf file:

    # Dept1_Cluster1
    <Location /shopping-cart-webapp>
      SetHandler weblogic-handler
    WebLogicCluster 10.1.0.1:7003,10.1.0.2:7003,10.1.0.3:7003,10.1.0.4:7003,10.1.0.9:7003,10.1.0.10:7003,10.1.0.11:7003,10.1.0.12:7003</Location>
    

    Note:

    In the <Location /shopping-cart-webapp entry>, ensure that you enter the relevant context paths to the web application that you will deploy.

  2. Make sure that the httpd.conf file located in the same directory as the mod_wl_ohs file contains the following lines:

    NameVirtualHost *:7777
    <VirtualHost *:7777>
        ServerName https://exalogic.mycompany.com:443
        ServerAdmin you@your.address
        RewriteEngine On
        RewriteOptions inherit
    </VirtualHost>
    
    NameVirtualHost *:7777
    <VirtualHost *:7777>
        ServerName http://exalogicinternal.mycompany.com:80
        ServerAdmin you@your.address
        RewriteEngine On
        RewriteOptions inherit
    </VirtualHost>
    
    NameVirtualHost *:7777
    <VirtualHost *:7777>
        ServerName admin.mycompany.com:80
        ServerAdmin you@your.address
        RewriteEngine On
        RewriteOptions inherit
    # Admin Server and EM
    <Location /console>
        SetHandler weblogic-handler
        WebLogicHost 10.1.0.17
        WeblogicPort 7003
    </Location>
    <Location /consolehelp>
        SetHandler weblogic-handler
         WebLogicHost 10.1.0.17
        WeblogicPort 7003
     </Location>
    <Location /em>
        SetHandler weblogic-handler
        WebLogicHost 10.1.0.17
        WeblogicPort 7003
    </Location>
    </VirtualHost>
    

    Note:

    Values such as exalogic.mycompany.com:443, 7777, admin.mycompany:80, and you@youraddress that are noted in this document serve as examples only. Enter values based on the actual environment.

    The Administration Server uses a BOND1 EoIB floating IP address, such as 10.1.0.17. Access to the Administration Console is restricted to requests coming in from admin.mycompany.com.

  3. Restart Oracle HTTP Server on both WEBHOST1 and WEBHOST2.

    WEBHOST1> ORACLE_BASE/admin/<instance_name>/bin/opmnctl restartproc ias-component=ohs1
    
    WEBHOST2> ORACLE_BASE/admin/<instance_name>/bin/opmnctl restartproc ias-component=ohs2
    

The servers specified in the WebLogicCluster parameter are only important at startup time for the plug-in. The list needs to provide at least one running cluster member for the plug-in to discover other members of the cluster. Note that the listed cluster member must be running when Oracle HTTP Server is started. Oracle WebLogic Server and the plug-in work together to update the server list automatically with new, failed, and recovered cluster members.

The method of specifying the parameter, and the required format vary by plug-in. See the following examples in Oracle Fusion Middleware Using Web Server 1.1 Plus-Ins with Oracle WebLogic Server:

"Installing and Configuring the Apache HTTP Server Plug-In"

The plug-in does a simple round-robin between all available servers. The server list specified in this property is a starting point for the dynamic server list that the server and plug-in maintain. WebLogic Server and the plug-in work together to update the server list automatically with new, failed, and recovered cluster members.

The plug-in directs HTTP requests containing a cookie, URL-encoded session, or a session stored in the POST data to the server in the cluster that originally created the cookie.

Note:

For more information about these parameters, see the "Parameters for Web Server Plug-Ins" topic in the Oracle Fusion Middleware Using Web Server 1.1 Plus-Ins with Oracle WebLogic Server.

6.4 Optional: Configuring Oracle HTTP Server for Load Balancing on the Private InfiniBand Network

You should complete this procedure if you are using Oracle HTTP Server to load balance traffic on the BOND0/IPMP0 private network. This Oracle HTTP Server installation is inside the Exalogic environment. Dept1_Cluster1 is the cluster to which the application will be deployed, and you must set the WebLogicCluster parameter to the list of Managed Servers in the cluster as follows:

Note:

ComputeNode1 and ComputeNode2 are used as the example compute nodes that are hosting the Oracle HTTP Server instances (OHS1 and OHS2) in these procedures.

  1. On ComputeNode1 and ComputeNode2, add the following lines to the /u01/app/FMW_Product1/Oracle/Middleware/Oracle_WT1/instances/OHS1/config/OHS/ohs1/mod_wl_ohs.conf file:

    # Dept1_Cluster1
    <Location /shopping-cart-webapp>
      SetHandler weblogic-handler
    WebLogicCluster 10.0.0.1:7003,10.0.0.2:7003,10.0.0.3:7003,10.0.0.4:7003,10.0.0.9:7003,10.0.0.10:7003,10.0.0.11:7003,10.0.0.12:7003</Location>
    

    Notes:

    • In the <Location /shopping-cart-webapp entry>, ensure that you enter the relevant context paths to the web application that you will deploy.

    • The above example includes entries for the cluster Dept1_Cluster1. These floating IP addresses use the BOND0 interface via IP over InfiniBand (IPoIB).

  2. Restart Oracle HTTP Server on both ComputeNode1 and ComputeNode2, as in the following example:

    # /u01/app/FMW_Product1/Oracle/Middleware/Oracle_WT1/opmn/bin/opmnctl restartproc ias-component=OHS1

    If you are using the second Oracle HTTP Server instance, such as OHS2, on the same compute node, restart both OHS1 and OHS2.

The servers specified in the WebLogicCluster parameter are only important at startup time for the plug-in. The list needs to provide at least one running cluster member for the plug-in to discover other members of the cluster. Note that the listed cluster member must be running when Oracle HTTP Server is started. Oracle WebLogic Server and the plug-in work together to update the server list automatically with new, failed, and recovered cluster members.

The method of specifying the parameter, and the required format vary by plug-in. See the following example in Oracle Fusion Middleware Using Web Server 1.1 Plus-Ins with Oracle WebLogic Server:

"Installing and Configuring the Apache HTTP Server Plug-In"

The plug-in does a simple round-robin between all available servers. The server list specified in this property is a starting point for the dynamic server list that the server and plug-in maintain. WebLogic Server and the plug-in work together to update the server list automatically with new, failed, and recovered cluster members.

The plug-in directs HTTP requests containing a cookie, URL-encoded session, or a session stored in the POST data to the server in the cluster that originally created the cookie.

Note:

For more information about these parameters, see the "Parameters for Web Server Plug-Ins" topic in the Oracle Fusion Middleware Using Web Server 1.1 Plus-Ins with Oracle WebLogic Server.

6.5 Setting the Frontend URL for the Administration Console

The Oracle WebLogic Server Administration Console application tracks changes made to ports, channels and security using the console. When changes made through the console are activated, the console validates its current listen address, port and protocol. If the listen address, port and protocol are still valid, the console redirects the HTTP request replacing the host and port information with the Administration Server's listen address and port. When the Administration Console is accessed using a load balancing router (LBR), it is required to change the Administration Server's frontend URL, so that the user's web browser is redirected to the appropriate LBR address. To do this, complete these steps:

  1. Log in to the Oracle WebLogic Server Administration Console.

  2. Click Lock and Edit.

  3. From the Domain Structure menu, select Environment, and then Servers.

    The Summary of Servers page is displayed.

  4. Select Admin Server in the Names column of the table.

    The settings page for AdminServer(admin) is displayed.

  5. Click the Protocols tab.

  6. Click the HTTP tab.

  7. Set the Front End Host field to admin.mycompany.com (your LBR address).

  8. Save and activate the changes.

To eliminate redirections, it is recommended that you disable the Administration Console's "Follow changes" feature. To do this, log in to the Administration Console, click Preferences and then Shared Preferences. Clear the 'Follow Configuration Changes' check box, and click Save.

6.6 Validating Access to ComputeNode1 Through Oracle HTTP Server

Verify that the server status is reported as "Running" in the Administration Console. If the server is shown as "Starting" or "Resuming," wait for the server status to change to "Started." If another status is reported (such as "Admin" or "Failed"), check the server output log files for errors.

Validate Administration Console and Enterprise Manager through both Oracle HTTP Server instances using the following URLs:

For information on configuring system access through the load balancer, see Section 3.3.5, "Load Balancers."

6.7 Validating Access to ComputeNode2 Through Oracle HTTP Server

Perform the same steps as in Section 6.6, "Validating Access to ComputeNode1 Through Oracle HTTP Server". This is to check that you can access the Administration Server when it is running on ComputeNode2.