5 Configuring Oracle Fusion Middleware

After installing the Oracle WebLogic software, you must configure Oracle Fusion Middleware for the Oracle Exalogic enterprise deployment topology described in Chapter 2, "Reference Topology and Slicing Diagram". This configuration uses the following Oracle Fusion Middleware components:

This chapter shows how to configure Oracle Fusion Middleware for two machines (referred to as Exalogic compute nodes) ComputeNode1 and ComputeNode2, as illustrated in Figure 5-1.

You can follow this example configuration to create WebLogic domains with clusters of Managed Servers on the remaining compute nodes in the Oracle Exalogic machine, based on your application deployment and management requirements.

Figure 5-1 Example Configuration Scenario for Exalogic x86 Physical Machines

Description of Figure 5-1 follows
Description of "Figure 5-1 Example Configuration Scenario for Exalogic x86 Physical Machines"

In this example configuration, you are creating a single Oracle WebLogic domain including the following:

This chapter discusses the following topics:

5.1 Important Notes Before You Begin

Read the following notes before you start configuring Oracle Fusion Middleware components:

  • If you are an Oracle Solaris user, read Section 3.1, "Important Notes for Oracle Solaris Users" before you configure Oracle Fusion Middleware.

  • The configuration example used in this guide describes how to configure the environment for one department that uses two compute nodes (Dept_1 using ComputeNode1 and ComputeNode2). In this example, WebLogic Managed Servers run on ComputeNode1 and ComputeNode2, the Administration Server runs on ComputeNode1, and separate Node Manager instances run on ComputeNode1 and ComputeNode2.

  • You can extrapolate the information included in these procedures to set up and configure the environment for your remaining departments, as necessary. This configuration depends on your specific application deployment and management requirements as well as the Oracle Exalogic machine configuration.

  • Oracle Exalogic machine full rack includes 30 compute nodes, an Oracle Exalogic machine half rack includes 16 compute nodes, and Oracle Exalogic machine quarter rack includes 8 compute nodes. You should plan your application deployment and infrastructure accordingly.

5.2 Prerequisites

The following are the prerequisites for configuring Oracle Fusion Middleware 11g Release 1 (11.1.1) products for Oracle Exalogic:

5.3 Enabling Floating IP for Administration Server on ComputeNode1

The Administration Server must be configured to listen on a floating IP Address to enable it to seamlessly failover from one host to another. In case of a failure, the Administration Server, along with the virtual IP Address, can be migrated from one host to another.

You are associating the Administration Server with a virtual hostname (ADMINVHN1). This Virtual Host Name must be mapped to the appropriate floating IP (10.0.0.17) by a custom /etc/hosts entry. Check that the floating IP is available per your name resolution system, (/etc/hosts), in the required nodes in your enterprise deployment reference topology. The floating IP (10.0.0.17) that is associated with this Virtual Host Name (ADMINVHN1) must be enabled on ComputeNode1.

To enable the floating IP on ComputeNode1, complete the following steps:

  1. On ComputeNode1, run the ifconfig command as the root user to get the value of the netmask.

    For example:

    [root@ComputeNode1 ~] # /sbin/ifconfig
    bond0     Link encap:Ethernet  HWaddr 00:11:43:D7:5B:06
         inet addr:139.185.140.51  Bcast:139.185.140.255  Mask:255.255.255.224
         inet6 addr: fe80::211:43ff:fed7:5b06/64 Scope:Link
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:10626133 errors:0 dropped:0 overruns:0 frame:0
         TX packets:10951629 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:1000
         RX bytes:4036851474 (3.7 GiB)  TX bytes:2770209798 (2.5 GiB)
         Base address:0xecc0 Memory:dfae0000-dfb00000
    
  2. On ComputeNode1, bind the floating IP Address to the network interface card using ifconfig command as the root user. Use a netmask value that was obtained in Step 1.

    Note:

    For Oracle Solaris, you must plumb the interface: /sbin/ifconfig networkCardInterface plumb

    /sbin/ifconfig networkCardInterface Virtual_IP_Address netmask netMask
    

    For example, on Oracle Linux:

    /sbin/ifconfig bond0:1 10.0.0.17 netmask 255.255.255.224
    

    In this example, bond0:1 is the virtual network interface created for internal, fabric-level InfiniBand traffic.

    For example, on Oracle Solaris:

    /sbin/ifconfig ipmp0:1 plumb
    /sbin/ifconfig ipmp0:1 10.0.0.17 netmask 255.255.255.224 up
    
  3. For Oracle Linux, run the arping command as the root user to update the routing table:

    /sbin/arping -q -U -c 3 -I networkCardInterface Floating_IP_Address
    

    For example:

    /sbin/arping -q -U -c 3 -I bond0 10.0.0.17
    

    Note:

    It is recommended that you run this command several times to update the routing table.

  4. Verify the floating IP address of the Administration Server by running the netstat -nr command on ComputeNode1.

Note:

In this enterprise deployment topology, example IP addresses are used. You must replace them with your own IP addresses that you reconfigured using Exalogic Configuration Utility. Even if the Administration Server for your WebLogic domain does not require a floating IP, it is recommended that you assign a floating IP address if you want to migrate the Administration Server manually from ComputeNode1 to ComputeNode2.

5.4 Running Oracle Fusion Middleware Configuration Wizard on ComputeNode1 to Create an Oracle WebLogic Domain

Run the Oracle Fusion Middleware Configuration Wizard to create a Oracle WebLogic domain as follows:

Note:

Ensure that you do not run the Oracle WebLogic installer as the root user. You can log in as user weblogic with write privileges to the appropriate shares mounted on the Sun ZFS Storage 7320 appliance. For more information, see Section 3.4.2.9, "Creating Groups and Users and Controlling Access to Mounted Shares".

  1. On ComputeNode1, open a terminal window. At the command prompt, use the cd command to move from your present working directory:

    ComputeNode1> cd /u01/app/FMW_Product1/Oracle/Middleware/wlserver_10.3/common/bin
    
  2. Start the Configuration Wizard:

    ComputeNode1> ./config.sh
    

    The Welcome screen is displayed.

  3. Select Create a new WebLogic Domain, and click Next.

    The Select Domain Source screen is displayed.

  4. Select the following components:

    • Basic WebLogic Server Domain - 10.3.4.0 [wlserver_10.3] (this should be selected automatically)

    • Oracle Enterprise Manager - 11.1.1.0 [oracle_common]

    • Oracle JRF - 11.1.1.0 [oracle_common]

    Click Next.

    The Specify Domain Name and Location screen is displayed.

  5. Enter the following:

    • Domain name: Enter base_domain as the name for the Oracle WebLogic domain. This is the default name.

    • Domain location: Click Browse and specify the path /u01/Dept_1/domains/el01cn01 in the shared file system on the Sun ZFS Storage 7320 appliance.

    Ensure that the domain directory matches the directory and shared storage mount point recommended in Chapter 3, "Network, Storage, and Database Preconfiguration".

    Click Next.

    The Configure Administrator User Name and Password screen is displayed.

  6. In this screen, enter the username and password to be used for the domain's administrator.

    Click Next.

    The Configure Server Start Mode and JDK screen is displayed.

  7. Select the following:

    • From WebLogic Domain Startup Mode, select Production Mode.

    • From Available JDKs, select JROCKIT SDK 1.6.0_20 (Oracle Linux) or Sun JDK 1.6.0_23 (Oracle Solaris).

    Click Next.

    The Select Optional Configuration screen is displayed

  8. Select the following:

    • Administration Server

    • Managed Servers, Clusters and Machines

    Click Next.

    The Configure the Administration Server screen is displayed.

  9. Enter the following values:

    • Name: AdminServer

    • Listen address: 10.0.0.17

      Note:

      This address, which is associated with the BOND0 interface, is the example floating IP address assigned to the Administration Server

    • Listen port: 7001

    • SSL listen port: N/A

    • SSL enabled: leave this check box unselected.

    Click Next.

    The Configure Managed Servers screen is displayed.

  10. Click Add, and create eight Managed Servers each for ComputeNode1 and ComputeNode2 as shown in Table 5-2 and Table 5-2. In the Listen address enter the floating IP addresses of the Managed Servers (see Figure 5-2).

    Note:

    In this example, IP addresses are used as listen addresses. However, you can specify host names if they resolve to their corresponding floating IP addresses.

    Table 5-1 Managed Servers on ComputeNode1

    Name Listen Address Using the BOND0 Interface via IPoIB

    WLS1

    10.0.0.1

    WLS2

    10.0.0.2

    WLS3

    10.0.0.3

    WLS4

    10.0.0.4


    Table 5-2 Managed Servers on ComputeNode2

    Name Listen Address Using the BOND0 Interface via IPoIB

    WLS5

    10.0.0.5

    WLS6

    10.0.0.6

    WLS7

    10.0.0.7

    WLS8

    10.0.0.8


    Tip:

    While creating Managed Servers, ensure that the names of the servers are unique across Oracle WebLogic domains in the Oracle Exalogic environment.

    If you want to interoperate two or more domains via JMS or JTA, then you must set unique names for Oracle WebLogic domains, Oracle WebLogic Server, and JMS servers even if they are in different domains.

    Figure 5-2 Configure Managed Servers

    Description of Figure 5-2 follows
    Description of "Figure 5-2 Configure Managed Servers"

    Note:

    In this enterprise deployment topology, floating IP addresses using the BOND0 interface are assigned to Managed Servers and to the Administration Server. You must replace these IP addresses with your own IP addresses that you reconfigured using Oracle Exalogic Configuration Utility.

    Click Next.

    The Configure Clusters screen is displayed.

  11. Click Add to configure clusters of Managed Servers on ComputeNode1 and ComputeNode2.

    Enter a name for the new cluster, such as Dept1_Cluster1 (see Figure 5-3).

    Figure 5-3 Configure Clusters

    Description of Figure 5-3 follows
    Description of "Figure 5-3 Configure Clusters"

    Click Next.

  12. The Assign Servers to Clusters screen is displayed. In this screen, do the following:

    • Select Dept1_Cluster1 in the Cluster pane, and double-click the following Managed Servers you created on ComputeNode1 and ComputeNode2:

      • WLS1

      • WLS2

      • WLS3

      • WLS4

      • WLS5

      • WLS6

      • WLS7

      • WLS8

      The names of the Managed Servers are removed from the Server pane and added below Dept1_Cluster1 in the Cluster pane (see Figure 5-4).

      Figure 5-4 Managed Servers Moved to Dept1_Cluster1

      Description of Figure 5-4 follows
      Description of "Figure 5-4 Managed Servers Moved to Dept1_Cluster1"

    • Click Next.

    The Configure Machines screen is displayed.

  13. The Configure Machines screen is displayed. In this screen, click the Unix Machine tab and then click Add to add the following machines:

    Table 5-3 Machines

    Name Node Manager Listen Address

    ComputeNode1

    el01cn01-priv

    The BOND0 IP address of ComputeNode1 is 192.168.10.1.

    ComputeNode2

    el01cn02-priv

    The BOND0 IP address of ComputeNode2 is 192.168.10.2.

    ADMINHOST

    ADMINVHN1

    The floating IP address of ADMINHOST is 10.0.0.17.


    Leave all other fields to their default values. Please note that the machine name does not need to be a valid host name or listen address; it is just a unique identifier of a Node Manager location (see Figure 5-5).

    Figure 5-5 Configure Machines

    Description of Figure 5-5 follows
    Description of "Figure 5-5 Configure Machines"

    Click Next.

    The Assign Servers to Machines screen is displayed.

  14. Perform the following:

    • Select ADMINHOST in the Machine pane, and double-click the AdminServer.

      The AdminServer is removed from the Machine pane and added below ADMINHOST in the Machine pane (see Figure 5-6).

    • Select ComputeNode1 in the Machine pane, and double-click the Managed Servers you created on ComputeNode1 (See Table 5-2).

      The name of the Managed Server is removed from the Machine pane and added below ComputeNode1 in the Machine pane (see Figure 5-6).

    • Select ComputeNode2 in the Machine pane, and double-click the Managed Servers you created on ComputeNode2.

      The name of the Managed Server is removed from the Server pane and added below ComputeNode2 in the Machine pane (see Figure 5-6).

      Figure 5-6 Assign Servers to Machines

      Description of Figure 5-6 follows
      Description of "Figure 5-6 Assign Servers to Machines"

    • Click Next.

  15. The Configuration Summary screen is displayed. In this screen, review the summary of configuration you have chosen and click Create.

  16. In the Create Domain screen, click Done.

5.5 Creating boot.properties for the Administration Server on ComputeNode1

Create a boot.properties file for the Administration Server on ComputeNode1. The boot.properties file enables the Administration Server to start without prompting you for the administrator username and password. To create a boot.properties file, complete the following steps:

  1. Create the following directory structure:

    mkdir -p /u01/Dept_1/domains/el01cn01/base_domain/servers/AdminServer/security
    
  2. In a text editor, create a file called boot.properties in the directory created in the previous step, and enter the following lines in the file:

    username=<adminuser>
    password=<password>
    

    Note:

    When you start the Administration Server, the username and password entries in the file get encrypted. You start the Administration Server in Section 5.6, "Starting the Administration Server on ComputeNode1."

    For security reasons, you want to minimize the time the entries in the file are left unencrypted: after you edit the file, you should start the server as soon as possible so that the entries get encrypted.

5.6 Starting the Administration Server on ComputeNode1

The Administration Server is started and stopped using Node Manager. However, the first start of the Administration Server with Node Manager requires configuration changes that are not set for Node Manager by the Configuration Wizard. Therefore, use the start script for the Administration Server for the first start.

Note:

  • Open the setDomainEnv.sh file (Located in /u01/Dept_1/domains/el01cn01/base_domain/bin) in a text editor and change the memory allocation (WLS_MEM_ARGS_64BIT="-Xms512m -Xmx512m") to 1024m and 3072m, as shown in the following example:

    WLS_MEM_ARGS_64BIT="-Xms1024m -Xmx3072m"
    
  1. To start the Administration Server on ComputeNode1, run the following script on the command-line:

    ./startWebLogic.sh
    

    startWebLogic.sh is located in /u01/Dept_1/domains/el01cn01/base_domain/bin.

  2. In a browser, go to the following URL:

    http://ADMINVHN1:7001/console
    

    Note:

    Ensure that you have configured the network before performing the domain configuration for the Administration Server and Managed Servers. The network configuration is described in Section 3.3, "Network".

  3. Log in to the Administration Server Console using the WebLogic Administration Server user name and password.

  4. In the banner toolbar region at the top of the right pane of the Console, click Preferences.

    The Preferences page is displayed.

  5. Click Shared Preferences, and then deselect Follow Configuration changes.

  6. Click Save.

5.7 Configuring Java Node Manager

Node Manager is an Oracle WebLogic Server utility that enables you to start, shut down, and restart Administration Server and Managed Server instances. Node manager does the following:

  • Starts a Managed Server through the Administration Console.

  • Monitors Servers that it has started.

  • If a Managed Server shuts down improperly for any reason, then the Automatic restart restarts the Managed Server. Node Manager does not typically kill a server. If you shut down the server using the Administration Console, Node Manager, or WLST, then Node Manager would not automatically restart that server. It starts the server only when the process stops unexpectedly.

Java-based Node Manager runs within a Java Virtual Machine (JVM) process. On UNIX platforms, allowing it to restart automatically when the system is rebooted.

Recommendations

Oracle provides the following recommendations for Node Manager configuration in enterprise deployment topologies:

  1. Place the Node Manager configuration and log file in a location different from the default one (which is inside the Middleware Home where Node Manager resides). See Section 5.7.2, "Changing the Location of Node Manager Configuration Files" for further details.

  2. Set up a dedicated Node Manager for each of the compute nodes.

  3. Every Node Manager instance running on the respective compute nodes must have a dedicated Node Manager home directory.

This section describes how to configure Node Manager for your Oracle Exalogic enterprise deployment implementation. You must complete the following tasks:

5.7.1 Starting Node Manager to Generating the Properties File

You must start the Node Manager to generate the properties file. Perform these steps to start Node Manager:

  1. Start Node Manager:

    ComputeNode1> cd /u01/FMW_Product1/wlserver_10.3/server/bin
    ComputeNode1> ./startNodeManager.sh
    
  2. Open nodemanager.properties (Located at u01/FMW_Product1/wlserver_10.3/common/nodemanager directory), and set the StartScriptEnabled property to true.

    Note:

    You must use the StartScriptEnabled property to avoid class loading failures and other problems.

  3. Stop the Node Manager process by running the following commands:

    ps -eaf |grep NodeManager

    Example output:

    user 10597 472 7 10:40 pts/3 00:00:00 java weblogic.NodeManager

    Run the kill command to stop the Node Manager process, as in the following example:

    kill 10597

  4. Repeat these steps on ComputeNode2.

5.7.2 Changing the Location of Node Manager Configuration Files

You must create a new directory for Node Manager configuration and log files outside the MW_HOME directory, and perform all Node Manager configuration tasks from this directory. Ensure that you do not make any configuration changes to the Node Manager files located in the Oracle WebLogic home directory.

You must complete the following steps:

  1. Create the following directories:

    On ComputeNode1:

    mkdir -p /u01/Dept_1/admin/el01cn01/nodemanager
    

    On ComputeNode2:

    mkdir -p /u01/Dept_1/admin/el01cn02/nodemanager
    
  2. Go to the nodemanager folder in your /u01/FMW_Product1/wlserver_10.3/common/nodemanager directory and copy the nodemanager.properties file to the new nodemanager folder you created for ComputeNode1 and ComputeNode2:

  3. Copy startNodeManager.sh (located in the /u01/FMW_Product1/wlserver_10.3/server/bin directory) and nodemanager.domains files (located in the /u01/FMW_Product1/wlserver_10.3/common/nodemanager directory) to the new nodemanager folder you created for ComputeNode1 and ComputeNode2.

  4. Open startNodeManager.sh for ComputeNode1 and ComputeNode2 (Located in your new nodemanager folder in ComputeNode1 and ComputeNode2) using a text editor, and make the following change:

    On ComputeNode1:

    NODEMGR_HOME="/u01/Dept_1/admin/el01cn01/nodemanager"
    

    On ComputeNode2:

    NODEMGR_HOME="/u01/Dept_1/admin/el01cn02/nodemanager"
    

    Note:

    The startNodeManager.sh script can now be used to start the Node Manager on ComputeNode1 and ComputeNode2.

5.7.3 Editing nodemanager.properties File

Node Manager properties define a variety of configuration settings for a Java-based Node Manager process. You must specify Node Manager properties on the command line or define them in the nodemanager.properties file (Located at /u01/Dept_1/admin/el01cn01/nodemanager on ComputeNode1 and /u01/Dept_1/admin/el01cn02/nodemanager on ComputeNode2). Values supplied on the command line override the values in nodemanager.properties.

Table 5-4 lists the Node Manager properties that you must change for ComputeNode1.

Table 5-4 Node Manager Properties

Properties Value

SecureListener

Set the value to "false".

StartScriptEnabled

Set the value to "true", to start a server. For more information, see the section "Configuring Node Manager to Use Start and Stop Scripts" in the Oracle Fusion Middleware Node Manager Administrator's Guide for Oracle WebLogic Server.

StopScriptEnabled

Set the value to "true", to run a server after a server is stopped, killed, or crashed. For more information, see the section "Configuring Node Manager to Use Start and Stop Scripts" in the Oracle Fusion Middleware Node Manager Administrator's Guide for Oracle WebLogic Server.

StopScriptName

Specify a name for the stop script, for example stopWebLogic.sh. For more information, see the section "Configuring Node Manager to Use Start and Stop Scripts" in the Oracle Fusion Middleware Node Manager Administrator's Guide for Oracle WebLogic Server.

DomainsFile

/u01/Dept_1/admin/el01cn01/nodemanager/nodemanager.domains

ListenAddress

192.168.10.1

NodeManagerHome

/u01/Dept_1/admin/el01cn01/nodemanager

LogFile

/u01/Dept_1/admin/el01cn01/nodemanager/nodemanager.log


You must also edit the nodemanager.properties file for ComputeNode2 as described in Table 5-4, and ensure that you enter the following values:

  • NodeManagerHome: /u01/Dept_1/admin/el01cn02/nodemanager

  • ListenAddress= 192.168.10.2

    Note:

    This IP address is the Bond0 IP address of ComputeNode2.

  • LogFile= /u01/Dept_1/admin/el01cn02/nodemanager/nodemanager.log

  • DomainsFile= /u01/Dept_1/admin/el01cn02/nodemanager/nodemanager.domains

Note:

For more information about nodemanager.properties, see the section "Reviewing nodemanager.properties" in the Oracle Fusion Middleware Node Manager Administrator's Guide for Oracle WebLogic Server.

5.7.4 Specifying Node Manager Username and Password

Use the Administration Console to update the Node Manager credentials for ComputeNode1 and ComputeNode2:

  1. In a browser, go to the following URL:

    http://ADMINVHN1:7001/console

  2. Log in as the administrator.

  3. Click Lock and Edit.

  4. In the left pane of the Console, select base_domain. This is the domain you have created for the Oracle Exalogic enterprise deployment.

    The Settings for base_domain page is displayed.

  5. Click Security tab, and then General tab.

  6. Expand the Advanced options at the bottom.

  7. Enter a new username for Node Manager, or make a note of the existing one and update the Node Manager password.

    Note:

    You need the Node Manager credentials to connect Node Manager with nmconnect.

  8. Click Save.

  9. Click Activate Changes.

5.7.5 Starting Node Manager

To start the Node Manager on ComputeNode1, run startNodeManager.sh (Located at /u01/Dept_1/admin/el01cn01/nodemanager directory for ComputeNode1 and /u01/Dept_1/admin/el01cn02/nodemanager directory for ComputeNode2) command to start Node Manager:

On ComputeNode1:

ComputeNode1> cd /u01/Dept_1/admin/el01cn01/nodemanager
ComputeNode1> ./startNodeManager.sh

On ComputeNode2:

ComputeNode2> cd /u01/Dept_1/admin/el01cn02/nodemanager
ComputeNode2> ./startNodeManager.sh

5.7.6 Controlling and Configuring Node Manager Using WLST

The WebLogic Scripting Tool (WLST) is a command-line scripting interface that system administrators and operators use to monitor and manage WebLogic Server instances and domains. You can start, stop, and restart server instances remotely or locally, using WLST as a Node Manager client. In addition, WLST can obtain server status and retrieve the contents of the server output log and Node Manager log. For more information on WLST commands, see "WLST Command and Variable Reference" in WebLogic Scripting Tool Command Reference.

Using nmConnect in a Production Environment

WLST can connect to a Node Manager that is running on any machine and start one or more WebLogic Server instances on the machine. A domain's Administration Server does not need to be running for WLST and Node Manager to start a server instance using this technique.

However, by default, the nmConnect command cannot be used in a production environment. You must first perform the following procedures to use nmConnect in a production environment.

  1. Start WLST as follows:

    ComputeNode1> cd /u01/app/FMW_Product1/Oracle/Middleware/wlserver_10.3/common/bin
    ComputeNode1> ./wlst.sh
    
  2. Use the connect command to connect WLST to a WebLogic Server instance, as in the following example:

    wls:/offline> connect('username','password','t3://ADMINVHN1:7001')
    
  3. Once you are in the WLST shell, run nmEnroll using the following syntax:

    nmEnroll([domainDir], [nmHome])
    

    For example,

    nmEnroll('/u01/Dept_1/domains/el01cn01/base_domain', '/u01/Dept_1/admin/el01cn01/nodemanager')
    

    Running nmEnroll ensures that the correct Node Manager user and password token are supplied to each Managed Server. Once these are available for each Managed Server, you can use nmConnect in a production environment.

  4. Disconnect WLST from the WebLogic Server instance by entering disconnect(), and exit by entering exit() to exit the WLST shell.

    Note:

    You must run nmEnroll for both ComputeNode1 and ComputeNode2.

5.8 Restarting the Administration Server on ComputeNode1

You must stop the Administration Server, and restart it using the Node Manager. Complete the following steps:

  1. Stop the Administration Server process by using CTRl-C in the shell where it was started, or by process identification and kill in the Operating System. Alternatively, you can stop the Administration Server by using the WebLogic Administration Console.

  2. Start WLST and connect to Node Manager with nmconnect and the credentials set in Section 5.7.4, "Specifying Node Manager Username and Password" and start the Administration Server using nmstart.

    ComputeNode1> cd /u01/FMW_Product1/wlserver_10.3/common/bin
    ComputeNode1> ./wlst.sh
    

    Once you are in the WLST shell:

    wls:/offline>nmConnect('Admin_User','Admin_Password',
    'el01cn01-priv','5556','base_domain','/u01/Dept_1/domains/el01cn01/base_domain','ssl')
     
    wls:/nm/base_domain> nmStart('AdminServer')
    

    Note:

    The username and password are used only to authenticate connections between Node Manager and clients. They are independent of the server admin ID and password. This is the user you specified in Specifying Node Manager Username and Password.

5.9 Validating the Administration Server

Perform these steps to ensure that the Administration Server is properly configured:

  1. In a browser, go to http://ADMINVHN1:7001/console.

  2. Log in as the administrator.

  3. In the left pane of the Console, expand Environment, and then Servers.

    The Summary of Servers page is displayed.

  4. In the Summary of Servers, ensure that the Managed Servers created for ComputeNode1 and ComputeNode2 are listed (Figure 5-7).

    Figure 5-7 Summary of Servers

    Description of Figure 5-7 follows
    Description of "Figure 5-7 Summary of Servers"

5.10 Optional: Creating Oracle HTTP Server Instances in the Exalogic Environment

You should complete this task if you wish to use Oracle HTTP Server to load balance traffic on the private InfiniBand network (BOND0/IPMP0). Before configuring Oracle HTTP Server to handle this load balancing, you should have installed Oracle HTTP Server in the Exalogic environment. This installation is different than the Oracle HTTP Server installation running outside of Exalogic. Be sure to use the "internal" Oracle HTTP Server for load balancing the application traffic on the private network only. For handling external requests in the public DMZ, you should continue to use the Oracle HTTP Server running outside of Exalogic.

To set up Oracle HTTP Server instances in the Exalogic environment, complete the following steps:

  1. Ensure that Oracle HTTP Server is installed, as described in Section 4.3, "Installing Oracle HTTP Server".

  2. On an Exalogic compute node (for example, ComputeNode1), create Oracle HTTP Server instances as follows:

    Note:

    In the physical topology, you may create two Oracle HTTP Server instances on an Exalogic compute node.

    1. From the Oracle HTTP Server Home directory (/u01/app/FMW_Product1/Oracle/Middleware/Oracle_WT1), run the following command to start the Configuration Wizard:

      # cd /bin/config.sh

      The Welcome screen is displayed.

    2. Click Next.

      The Configure Components Screen is displayed.

    3. Select Oracle HTTP Server and Select Associate Selected Components with WebLogic Domain.

      Click Next.

      The Specify WebLogic Domain Screen is displayed.

    4. Specify the following WebLogic Domain credentials:

      • Domain Host Name: base_domain

      • Domain Port No: 7001

      • User Name: Specify the user name. The default user name is weblogic.

      • Password: Specify the Administration Server password.

      Click Next.

      The Specify Component Details Screen is displayed.

    5. Specify the following component details:

      • Instance Home Location: /u01/app/FMW_Product1/Oracle/Middleware/Oracle_WT1/instances/

      • Instance Name: asinst_1

      • OHS Component Name: OHS1

      Click Next.

      The Configure Ports Screen is displayed.

    6. Select Auto Port Configuration to automatically assign the default port.

      Click Next.

      The Specify Security Updates Screen is displayed.

    7. Enter your E-mail address if you want to receive the latest product information and security updates. If you have a My Oracle account and wish to receive updates via this mechanism, select I wish to receive security updates via My Oracle Support, then enter your account password.

      If you do not wish to register for security updates, leave all the fields on this screen blank. You will be prompted to confirm your selection. Click Yes to confirm that you do not want to register for any security updates.

      Click Next.

      The Installation Summary Screen is displayed.

    8. Review the information on this screen. The operations summarized on this page will be performed when you click Configure.

      The Configuration Progress Screen is displayed.

    9. Click Next.

      The Installation Complete Screen is displayed.

      You can also save this summary information to a file for future reference by clicking Save. You will be prompted to specify a name and location for your summary file.

    10. Click Finish to dismiss the screen.

      An Oracle HTTP Server instance named OHS1 is created under the /u01/app/FMW_Product1/Oracle/Middleware/Oracle_WT1/instances directory.

  3. Edit the configuration files for the OHS1 instance as follows:

    1. Open the /u01/app/FMW_Product1/Oracle/Middleware/Oracle_WT1/instances/OHS1/config/OHS/httpd.conf file in a text editor. search for the Listen directive, which is usually commented out. Uncomment the Listen entry and specify a BOND0/IPMP0 private IP address, such as 10.0.0.18.

    2. Save the httpd.conf file and close.

    3. Open the /u01/app/FMW_Product1/Oracle/Middleware/Oracle_WT1/instances/OHS1/config/OPMN/opmn/opmn.xml file in a text editor. Add the following property in the opmn.xml file:

      <ipaddr remote="ip" request="ip"/>

    4. Specify the BOND0/IPMP0 private IP address, such as 10.0.0.19, for the request attribute as follows:

      <ipaddr remote="ip" request="10.0.0.19"/>

    5. Save the opmn.xml file and close.

Note:

You must repeat these steps to create Oracle HTTP Server instances to run on the remaining compute nodes, such as ComputeNode2, in the example configuration scenario.

For load balancing application traffic in a round-robin fashion on the BOND0/IPMP0 private network, you must configure Oracle HTTP Server, as described in Section 6.4, "Optional: Configuring Oracle HTTP Server for Load Balancing on the Private InfiniBand Network".

5.11 Propagating Domain Configuration from ComputeNode1 to ComputeNode2 Using pack and unpack Utilities

You have created the domain (base_domain) on ComputeNode1. You must propagate the domain configuration to ComputeNode2 as follows:

  1. Run the pack command on ComputeNode1 to create a template pack using the following commands:

    ComputeNode1> cd /u01/app/FMW_Product1/Oracle/Middleware/wlserver_10.3/common/bin
    
    ComputeNode1> ./pack.sh -managed=true -domain=/u01/Dept_1/domains/el01cn01/base_domain -template=basedomaintemplate.jar -template_name=basedomain_template
    
  2. Run the unpack command on ComputeNode2 to unpack the template.

    ComputeNode2> cd /u01/app/FMW_Product1/Oracle/Middleware/wlserver_10.3/common/bin
    
    ComputeNode2> ./unpack.sh -domain=/u01/Dept_1/domains/el01cn02/base_domain -template=basedomaintemplate.jar
    

5.12 Configuring Network Channels for HTTP and T3 Clients via EoIB

If your HTTP clients and T3 clients use the 10 Gb Ethernet network, you must create additional network channels for the Administration Server and Managed Servers on ComputeNode1 and ComputeNode2. For more information, see Section 3.3.3.2, "Determining Network Interface and Channel Requirements for a WebLogic Managed Server and the Administration Server".

Complete the following steps:

5.12.1 Using BOND1 Floating IP Addresses for EoIB Communication

For Ethernet over InfiniBand (EoIB) communication, you must log in as a root user and assign floating IP addresses to the Administration Server and to Managed Servers. These addresses are associated with the BOND1 interface. In this guide, an IP subnet (10.1.0.0) is used as an example only. For more information, see Section 3.3.3.4, "IP Addresses for WebLogic Clusters When HTTP or T3 Traffic Is Via Ethernet over InfiniBand (EoIB)".

5.12.2 Configuring the Administration Server Network Channel

You must create two network channels for the Administration Server on ComputeNode1. The network channels are necessary for routing HTTP traffic and T3 traffic (TCP-based protocol used by WebLogic Server) coming in from external data center via Ethernet over InfiniBand (EoIB). You must create the following network channels:

5.12.2.1 HTTP Client Channel

To create the HTTP network channel for the Administration Server, complete the following steps:

  1. In a browser, go to http://ADMINVHN1:7001/console.

  2. Log in as the administrator.

  3. If you have not already done so, click Lock & Edit in the Change Center.

  4. In the left pane of the Console, expand Environment, and then Servers.

    The Summary of Servers page is displayed.

  5. In the Servers table, click AdminServer(admin).

    The Settings for AdminServer page is displayed.

  6. Select Protocols, and then Channels.

  7. Click New.

  8. Enter AdminHTTPClient as the name of the new network channel and select http as the protocol, then click Next.

  9. Enter the following information in the Network Channel Addressing page:

    • Listen address: 10.1.0.17

      Note:

      This address is the floating IP assigned to the Administration Server using the BOND1 interface.

    • Listen port: 7001

  10. Click Next, and select Enabled on the Network Channel Properties page.

  11. Click Finish.

  12. To activate these changes, in the Change Center of the Administration Console, click Activate Changes.

5.12.2.2 T3 Client Channel

To create the t3 network channel for the Administration Server, complete the following:

  1. In a browser, go to http://ADMINVHN1:7001/console.

  2. Log in as the administrator.

  3. If you have not already done so, click Lock & Edit in the Change Center.

  4. In the left pane of the Console, expand Environment, and then Servers.

    The Summary of Servers page is displayed.

  5. In the Servers table, click AdminServer(admin).

    The Settings for AdminServer page is displayed.

  6. Select Protocols, and then Channels.

  7. Click New.

  8. Enter AdminT3 as the name of the new network channel and select t3 as the protocol, then click Next.

  9. Enter the following information in the Network Channel Addressing page:

    • Listen address: 10.1.0.17

      Note:

      This address is the floating IP assigned to the Administration Server using the BOND1 interface.

    • Listen port: 7001

  10. Click Next, and select the following in the Network Channel Properties page:

    • Enabled

    • HTTP Enabled for This Protocol

  11. Click Finish.

  12. To activate these changes, in the Change Center of the Administration Console, click Activate Changes.

5.12.3 Configuring Network Channels for Managed Servers on ComputeNode1 and ComputeNode2

For Managed Servers, you must create the following network channels using Ethernet over InfiniBand (EoIB):

5.12.3.1 HTTP Client Channel

To create a HTTP network channel for a Managed Server such as WLS1, complete the following steps:

  1. In a browser, go to http://ADMINVHN1:7001/console.

  2. Log in as the administrator.

  3. If you have not already done so, click Lock & Edit in the Change Center.

  4. In the left pane of the Console, expand Environment, and then Servers.

    The Summary of Servers page is displayed.

  5. In the Servers table, click WLS1.

    The Settings for WLS1 page is displayed.

  6. Select Protocols, and then Channels.

  7. Click New.

  8. Enter HTTPClient as the name of the new network channel and select http as the protocol, then click Next.

  9. Enter the following information in the Network Channel Addressing page:

    • Listen address: 10.1.0.1

      Note:

      This address is the floating IP assigned to a Managed Server using the BOND1 interface.

    • Listen port: 7003

    • External Listen Address: exalogic.mycompany.com

      Note:

      This is the IP address or DNS name to access application on the server.

    • External Listen Port: 80

  10. Click Next, and select the following in the Network Channel Properties page:

    • Enabled

    • HTTP Enabled for This Protocol

  11. Click Finish.

  12. To activate these changes, in the Change Center of the Administration Console, click Activate Changes.

You must repeat the above steps to create a network channel each for the remaining Managed Servers on ComputeNode1 and ComputeNode2 and enter the required properties as described in Table 5-5.

Note:

In this example, IP addresses are used as listen addresses. However, you can specify host names if they resolve to their corresponding floating IP addresses.

Table 5-5 Network Channels Properties

Managed Server Name Protocol Listen Address Listen Port External Listen Address External Listen Port

WLS2

HTTPClient

http

10.1.0.2

7003

exalogic.mycompany.com

80

WLS3

HTTPClient

http

10.1.0.3

7003

exalogic.mycompany.com

80

WLS4

HTTPClient

http

10.1.0.4

7003

exalogic.mycompany.com

80

WLS5

HTTPClient

http

10.1.0.5

7003

exalogic.mycompany.com

80

WLS6

HTTPClient

http

10.1.0.6

7003

exalogic.mycompany.com

80

WLS7

HTTPClient

http

10.1.0.7

7003

exalogic.mycompany.com

80

WLS8

HTTPClient

http

10.1.0.8

7003

exalogic.mycompany.com

80


5.12.3.2 T3 Client Channel

To create the t3 network channel for a Managed Server server such as WLS1, complete the following steps:

  1. In a browser, go to http://ADMINVHN1:7001/console.

  2. Log in as the administrator.

  3. If you have not already done so, click Lock & Edit in the Change Center.

  4. In the left pane of the Console, expand Environment, and then Servers.

    The Summary of Servers page is displayed.

  5. In the Servers table, click AdminServer(admin).

    The Settings for AdminServer page is displayed.

  6. Select Protocols, and then Channels.

  7. Click New.

  8. Enter T3ClientChannel as the name of the new network channel and select t3 as the protocol, then click Next.

  9. Enter the following information in the Network Channel Addressing page:

    • Listen address: 10.1.0.1

      Note:

      This address is the floating IP assigned to a Managed Server or to the Administration Server using the BOND1 interface.

    • Listen port: 7005

  10. Click Next, and select the following in the Network Channel Properties page:

    • Enabled

    • If you want to allow both HTTP and T3 traffic on T3ClientChannel1, then select the following option:

      HTTP Enabled for This Protocol

  11. Click Finish.

  12. To activate these changes, in the Change Center of the Administration Console, click Activate Changes.

You must repeat the above steps to create a network channel each for the remaining Managed Servers and enter the required properties as described in Table 5-6.

Note:

In this example, IP addresses are used as listen addresses. However, you can specify host names if they resolve to their corresponding floating IP addresses.

Table 5-6 Network Channels Properties

Managed Server Name Protocol Listen Address Listen Port External Listen Address External Listen Port

WLS2

T3ClientChannel

t3

10.1.0.2

7005

exalogic.mycompany.com

80

WLS3

T3ClientChannel

t3

10.1.0.3

7005

exalogic.mycompany.com

80

WLS4

T3ClientChannel

t3

10.1.0.4

7005

exalogic.mycompany.com

80

WLS5

T3ClientChannel

t3

10.1.0.5

7005

exalogic.mycompany.com

80

WLS6

T3ClientChannel

t3

10.1.0.6

7005

exalogic.mycompany.com

80

WLS7

T3ClientChannel

t3

10.1.0.7

7005

exalogic.mycompany.com

80

WLS8

T3ClientChannel

t3

10.1.0.8

7005

exalogic.mycompany.com

80


5.13 Configuring Oracle Coherence

This section describes how to configure Oracle Coherence for Oracle Exalogic enterprise deployment. You must complete the following tasks:

5.13.1 Configuring Socket Buffer Sizes

To help minimization of packet loss, the operating system socket buffers should be large enough to handle the incoming network traffic while your Java application is paused during garbage collection. By default Coherence will attempt to allocate a socket buffer of 2MB. If your operating system is not configured to allow for large buffers Coherence will use smaller buffers. Most versions of UNIX have a very low default buffer limit, which should be increased to at least 2MB.

If the operating system fails to allocate the full size buffer, the following error message is displayed:

Example 5-1 Message Indicating OS Failed to Allocate the Full Buffer Size

UnicastUdpSocket failed to set receive buffer size to 1428 packets (2096304 bytes); actual size is 89 packets (131071 bytes). Consult your OS documentation regarding increasing the maximum socket buffer size. Proceeding with the actual value may cause sub-optimal performance.

Although it is safe to operate with the smaller buffers, it is recommended that you configure your operating system to allow for larger buffers.

On Oracle Linux, execute (as root):

sysctl -w net.core.rmem_max=4192608
sysctl -w net.core.wmem_max=4192608

You may configure Coherence to request alternate sized buffers for packet publishers and unicast listeners by using the coherence/cluster-config/packet-publisher/packet-buffer/maximum-packets and coherence/cluster-config/unicast-listener/packet-buffer/maximum-packets elements. For more information, see "packet-buffer" in the Oracle Coherence Developer's Guide.

On Oracle Solaris, execute (as root):

ndd -set /dev/udp udp_max_buf 2096304

5.13.2 Creating Coherence Clusters on ComputeNode1 and ComputeNode2

You must enable applications to share data management and caching services among Managed Server instances and clusters hosting the applications that require access to them.

In the example configuration scenario discussed in this guide, one Oracle Coherence Cluster (CoherenceCluster1) and one Oracle WebLogic Cluster (Dept1_Cluster1) are used. You should determine the number of Coherence clusters, based on your application deployment requirements. If you decide to use multiple Coherence clusters, you may want to configure a well-known address (WKA) for the clusters, see "Configure well known addresses" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help.

This example procedure uses default values only.

Note:

The configuration example used in this guide uses two compute nodes for Coherence clusters as a canonical example only. Oracle recommends that you determine the number of physical machines (compute nodes) based on your specific application deployment requirements. For more information, see the "Production Checklist" in the Oracle Coherence Developer's Guide for recommendations about deploying Oracle Coherence in a production environment.

To create a Coherence cluster across Dept1_Cluster1:

  1. Log in to the Oracle WebLogic Administration Console, using the following URL in a browser:

    http://ADMINVHN1:7001/console
    
  2. If you have not already done so, click Lock & Edit in the Change Center.

  3. In the left pane of the Console, expand Environment and select Coherence Clusters.

    The Summary of Coherence Clusters page is displayed.

  4. Click New.

    The Create Coherence Cluster Configuration page is displayed.

  5. Enter CoherenceCluster1 as the name of the Coherence cluster configuration and click Next.

    The Coherence Cluster Addressing page is displayed.

  6. Accept the default values, and click Next.

    The Coherence Cluster Targets page is displayed.

  7. Select Dept1_Cluster1, and then All servers in the cluster (Figure 5-8) to deploy this Coherence cluster configuration.

    Figure 5-8 Coherence Cluster Targets

    Description of Figure 5-8 follows
    Description of "Figure 5-8 Coherence Cluster Targets "

  8. Click Finish.

The Summary of Coherence Clusters page is displayed, displaying the Coherence Cluster you created for Dept1_Cluster1 (Figure 5-9).

Figure 5-9 Summary of Coherence Clusters

Description of Figure 5-9 follows
Description of "Figure 5-9 Summary of Coherence Clusters"

5.13.3 Deploying the Coherence Shared Library Files

You must deploy the following shared library files:

coherence-web-spi.war

Oracle Coherence provides a deployable shared library named coherence-web-spi.war that contains a native plug-in to WebLogic Server's HTTP Session Management interface. You must deploy this file as follows:

  1. Log in to the Oracle WebLogic Administration Console.

  2. If you have not already done so, click Lock & Edit in the Change Center.

  3. In the left pane of the Console, click Deployments.

    The Summary of Deployments page is displayed.

  4. Click Install. The Install Application Assistant screen is displayed.

  5. Use the Install Application Assistant to deploy coherence-web-spi.war as a library to Dept1_Cluster1. Do the following:

    1. Locate and select the coherence-web-spi.war file. It resides in the /u01/app/FMW_Product1/Oracle/Middleware/coherence_3.6/lib directory.

    2. Click Next.

      The Choose targeting style page is displayed.

    3. Ensure that Install this deployment as a library is selected.

    4. Click Next.

      The Select deployment targets page is displayed.

    5. Select Dept1_Cluster1 as the deployment target.

    6. Click Next.

    7. In Optional Settings page, select Copy this application onto every target for me option in the Source accessibility section.

    8. Click Finish.

      The Summary of Deployments page is displayed, displaying the coherence-web-spi.war file you have installed.

    9. Click Activate Changes.

    Note:

    You must extract the contents of the coherence-web-spi.war file to a directory using the following command:

    jar -xvf coherence-web-spi.war
    

    In this example procedure, create a directory named coherenceweb in the following directory:

    /u01/app/FMW_Product1/Oracle/Middleware/coherence_3.6/lib

active-cache.jar

To employ ActiveCache functionality in your applications, you must also deploy the active-cache-1.0.jar file to Dept1_Cluster1. To do so, complete the following steps:

  1. Log in to the Oracle WebLogic Administration Console.

  2. If you have not already done so, click Lock & Edit in the Change Center.

  3. In the left pane of the Console, click Deployments.

    The Summary of Deployments page is displayed.

  4. Click Install.

    The Install Application Assistant screen is displayed.

  5. Use the Install Application Assistant to deploy active-cache-1.0.jar as a library to Dept1_Cluster1. Do the following:

    1. Locate and select the active-cache-1.0.jar file. It resides in the /u01/app/FMW_Product1/Oracle/Middleware/wlserver_10.3/common/deployable-libraries directory.

    2. Click Next.

      The Choose targeting style page is displayed.

    3. Ensure that Install this deployment as a library is selected.

    4. Click Next.

      The Select deployment targets page is displayed.

      Note:

      You may get the following warning message, Issues were encountered while parsing this deployment to determine module type. Assuming this is a library deployment. This message will appear if the Choose targeting style page is skipped automatically by the console. You must ignore this message and proceed.

    5. Select Dept1_Cluster1 as the deployment target.

    6. Click Next.

      The Optional Settings page is displayed.

    7. Select I will make the deployment accessible from the following location option in the Source accessibility section.

    8. Click Finish.

      The Summary of Deployments page is displayed, displaying the active-cache-1.0.jar file you have installed.

    9. Click Activate Changes.

coherence.jar

You must deploy the coherence.jar file to Dept1_Cluster1. To do so, complete the following steps:

  1. Log in to the Oracle WebLogic Administration Console.

  2. If you have not already done so, click Lock & Edit in the Change Center.

  3. In the left pane of the Console, click Deployments.

    The Summary of Deployments page is displayed.

  4. Click Install.

    The Install Application Assistant screen is displayed.

  5. Use the Install Application Assistant to deploy coherence.jar as a library to Dept1_Cluster1. Do the following:

    1. Locate and select the coherence.jar file. It resides in the /u01/app/FMW_Product1/Oracle/Middleware/coherence_3.6/lib directory.

    2. Click Next.

      The Choose targeting style page is displayed.

    3. Ensure that Install this deployment as a library is selected.

    4. Click Next.

      The Select deployment targets page is displayed.

      Note:

      You may get the following warning message, Issues were encountered while parsing this deployment to determine module type. Assuming this is a library deployment. This message will appear if the Choose targeting style page is skipped automatically by the console. You must ignore this message and proceed.

    5. Select Dept1_Cluster1 as the deployment target.

    6. Click Next.

      The Optional Settings page is displayed.

    7. Select Copy this application onto every target for me option in the Source accessibility section.

    8. Click Finish.

      The Summary of Deployments page is displayed, displaying the coherence.jar file you have installed.

    9. Click Activate Changes.

5.13.4 Create the Counter Web Application

The Counter Web application is a simple counter implemented as a JSP. The counter is stored as an HTTP session attribute and increments each time the page is accessed.

To create the Counter Web application:

  1. Create a standard Web application directory as follows:

    /
    /WEB-INF
    
  2. Copy the following code to a text file and save it as a file named web.xml in the /WEB-INF directory.

    <?xml version = '1.0' encoding = 'windows-1252'?>
    <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" 
     xmlns="http://java.sun.com/xml/ns/j2ee" version="2.5">
       <description>Empty web.xml file for Web Application</description>       
    </web-app>
    
  3. Create a weblogic.xml file in the /WEB-INF directory.

    • Add a library reference for the coherence-web-spi.war file.

    • Reference the Coherence Cluster in a coherence-cluster-ref stanza.

    Example 5-2 illustrates a sample weblogic.xml file.

    Example 5-2 Sample weblogic.xml File

    <weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-web-app http://www.oracle.com/technology/weblogic/weblogic-web-app/1.1/weblogic-web-app.xsd">
          <library-ref>
               <library-name>coherence-web-spi</library-name>
          </library-ref>
         <coherence-cluster-ref>
            <coherence-cluster-name>CoherenceCluster1</coherence-cluster-name>
         </coherence-cluster-ref> 
    </weblogic-web-app>
    
  4. Bundle the coherence.jar file with the application by copying coherence.jar from the /u01/app/FMW_Product1/wlserver_1034/coherence_3.6/lib directory to the WEB-INF/lib directory.

  5. Copy the following code for the counter JSP to a text file and save the file as counter.jsp in the root of the Web application directory.

    <html>
        <body>
    
    <h3>
          Counter :
          <%
             Integer counter = new Integer(1);
             HttpSession httpsession = request.getSession(true);
             if (httpsession.isNew()) {
                    httpsession.setAttribute("count", counter);
                    out.println(counter);
             } else {
                    int count = ((Integer) httpsession.getAttribute("count")).intValue();
                    httpsession.setAttribute("count", new Integer(++count));
                    out.println(count);
             }
          %>
          </h3>
     
        </body>
    </html>
    
  6. Create a manifest.mf file in the META-INF directory. Add references to the active-cache JAR file. Example 5-3 illustrates a sample manifest.mf file.

    Example 5-3 Sample manifest.mf File

    Extension-List: active-cache
    active-cache-Extension-Name: active-cache
    active-cache-Specification-Version: 1.0
    active-cache-Implementation-Version: 1.0
    
  7. The Web application directory appears as follows:

    /
    /counter.jsp
    /META-INF/manifest.mf
    /WEB-INF/web.xml
    /WEB-INF/weblogic.xml
    /WEB-INF/lib/coherence.jar
    
  8. ZIP or JAR the Web application directory and save the file as counter.war.

    Tip:

    To create an executable JAR file, run the following command from the application's root directory:

    jar cmf META-INF/manifest.mf ../counter.war

    This command is an example only.

5.13.5 Deploy the Application

To deploy the counter.war application:

  1. Open the Summary of Deployments page by clicking Deployments in the Domain Structure menu in the Oracle WebLogic Server Administration Console.

  2. Click Install. The Install Application Assistant wizard opens.

  3. Use the Install Application Assistant to deploy the counter.war file to Dept1_Cluster1 (all servers in the cluster). In the Optional Settings page, select the Copy this application onto every target for me option in the Source accessibility section.

5.13.6 Creating Coherence Servers on ComputeNode1 and ComputeNode2

You must create four Coherence servers across ComputeNode1 and ComputeNode2, as illustrated in Figure 5-1:

  1. If you have not already done so, click Lock & Edit in the Change Center of the Administration Console.

  2. In the left pane of the Console, expand Environment and select Coherence Servers.

    The Summary of Coherence Servers page is displayed.

  3. Click New.

    The Create Coherence Server Configuration page is displayed.

  4. On the Coherence Server Properties page, enter the following:

    • Enter Coh1 as the name of the server in the Name field.

      The server name is not used as part of the URL for applications that are deployed on the server. It is for your identification purposes only. The server name displays in the Administration Console, and if you use WebLogic Server command-line utilities or APIs, you use this name to identify the server.

    • Select ComputeNode1 as the name of the Machine from the drop-down list.

      In order to use Node Manager to start this Coherence server, you must assign the server to a machine.

    • Select CoherenceCluster1 as the name of the Cluster from the drop-down list.

    • Unicast Listen Address: Enter 192.168.10.1

      Note:

      This IP address is the BOND0 IP of the compute node on which the Oracle Coherence Server is configured to run. Alternatively, you can use the host name of the compute node, such as el01cn01, if the host name resolves to the IP address correctly.

      For more information, see Section 3.3.3, "Enterprise Deployment Network Configuration".

    • Unicast Listen Port: Enter 8888

      Note:

      Ensure that the Coherence cluster Unicasting Listen Port number specified is different from Coherence Server Unicasting Listen Port number.

    • Ensure that Unicast Port Auto Adjust is selected.

    • Click Finish.

  5. Repeat the above steps to create seven Coherence Servers on ComputeNode1 and ComputeNode2 with the following properties described in Table 5-7:

    Note:

    In this example, IP addresses are used as listen addresses. However, you can specify host names if they resolve to their corresponding floating IP addresses.

    Table 5-7 Coherence Server Properties

    Name Machine Clusters Unicast Listen Address Unicast Listen Port

    Coh2

    ComputeNode1

    CoherenceCluster1

    192.168.10.1

    8890

    Coh3

    ComputeNode2

    CoherenceCluster1

    192.168.10.2

    8888

    Coh4

    ComputeNode2

    CoherenceCluster1

    192.168.10.2

    8890


The Summary of Coherence Servers page is displayed, displaying the Coherence Servers you have created for ComputeNode1 and ComputeNode2 (Figure 5-10).

Figure 5-10 Summary of Coherence Servers

Description of Figure 5-10 follows
Description of "Figure 5-10 Summary of Coherence Servers"

To activate these changes, in the Change Center of the Administration Console, click Activate Changes.

5.13.7 Configuring Startup Arguments for Coherence servers

You must configure the startup settings for the Coherence Servers created on ComputeNode1 and ComputeNode2. This setup enables the Node Manager to start a Coherence server. To configure startup options for a Coherence server such as Coh1, complete the following steps:

  1. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.

  2. In the left pane of the Console, expand Environment and select Coherence Servers.

  3. In the Coherence Servers table, select Coh1.

  4. Select Configuration tab and then select Server Start tab.

  5. Specify the following startup settings:

    • Java Home - Specify the Java home directory (path on the machine running Node Manager) to use when starting this server. Specify the parent directory of the JDK's bin directory. For example: /u01/app/FMW_Product1/Oracle/Middleware/jrockit_160_20_D1.1.0-15.

    • Java Vendor - Specify the Java vendor value to use when starting this server. For example: Oracle.

    • BEA Home - Specify the directory on the Node Manager machine under which all of Oracle's WebLogic products were installed. For example, /u01/app/FMW_Product1/Oracle/Middleware.

    • Root Directory - Specify the directory that this server uses as its root directory. This directory must be on the computer that hosts the Node Manager. If you do not specify a Root Directory value, the domain directory is used by default. For example: /u01/Dept_1/domains/el01cn01/base_domain.

    • Class Path - Specify the classpath (path on the machine running Node Manager) to use when starting this server. For example:

      Note:

      You must run setWLSEnv.sh (Located at /u01/app/FMW_Product1/Oracle/Middleware/wlserver_10.3/server/bin) and copy its classpath properties to the Coherence Server classpath.

      For example:

      /u01/app/FMW_Product1/Oracle/Middleware/coherence_3.6/lib/coherence.jar:/u01/app/FMW_Product1/Oracle/Middleware/coherence_3.6/lib/coherenceweb/WEB_INF/lib/coherence-web.jar:/u01/app/FMW_Product1/Oracle/Middleware/modules/features/weblogic.server.modules.coherence.server_10.3.4.0.jar
      

      You must append this classpath to the Class Path field.

    • Arguments - Specify the arguments to use when starting this server. For example:

      Oracle Linux:

      -Xms1024m -Xmx3072m -Dtangosol.coherence.cacheconfig=session-cache-config.xml -Dtangosol.coherence.session.localstorage=true
      -Dtangosol.coherence.cluster=CoherenceCluster1 
      

      Oracle Solaris:

      -Xms1024m -Xmx3072m -Dtangosol.coherence.cacheconfig=session-cache-config.xml -Dtangosol.coherence.session.localstorage=true
      -Dtangosol.coherence.cluster=CoherenceCluster1 
      -Djava.net.preferIPv4Stack=true
      
  6. Repeat these steps for the remaining Coherence Servers.

5.13.8 Starting Coherence Servers on ComputeNode1 and ComputeNode2

To start the Coherence Servers on ComputeNode1 and ComputeNode2, complete the following steps:

  1. In the WebLogic Administration Server Console, from the Domain Structure menu, expand Environment and select Coherence Servers.

  2. In the right pane, select Control.

  3. Select the check box next to Coh1, and click Start.

  4. Click Yes to confirm.

    The Node Manager starts the server on the target machine. When the Node Manager finishes its start sequence, the server's state is indicated in the State column in the Server Status table.

  5. Repeat the above steps to start the remaining seven Coherence Servers.

5.13.9 Verify the Example

To verify the example:

Note:

Before you verify the example, ensure that you start your managed server, as described in Section 5.16, "Starting Managed Servers on ComputeNode1 and ComputeNode2". In addition, copy coherence.jar to the counter.war file's WEB-INF/lib directory.

  1. Open a browser and access the application, as in the following example:

    http://Managed_Server_host:port/counter/counter.jsp

    Managed_Server_host and port represent the host and the port of any Managed Server in Dept1_Cluster1. For example, the host and the port of WLS1.The counter.war application was deployed to this cluster.

    The counter page displays and the counter is set to 1, as illustrated in Figure 5-11.

    Figure 5-11 Counter Page with Counter Set to 1

    Counter Page with Counter Set to 1
  2. In a new browser (or new browser tab), access the ServerB counter instance using the following URL:

    http://Managed_Server_host:port/counter/counter.jsp

    Managed_Server_host and port represent the host and the port of a Managed Server in Dept1_Cluster1. For example, the host and the port of WLS2. The WLS2 Managed Server should be listening on the same IP address as that of WLS1. However, the ports of WLS1 and WLS2 are different. The counter.war application was deployed to this cluster.

    The counter page is displayed, and the counter increments to 2 based on the session data, as shown in Figure 5-12.

    Figure 5-12 Counter Page with Counter Set to 2

    Counter Page with Counter Set to 4
  3. If you refresh the page, the counter increments to 3. Return to the original browser (or browser tab), refresh the instance, and the counter displays 4.

5.14 Specifying Node Manager Type for ComputeNode1 and ComputeNode2

You must specify the Node Manager type for ComputeNode1 and ComputeNode2 as follows:

  1. Log in to the Oracle WebLogic Administration Console, using the following URL in a browser:

    http://ADMINVHN1:7001/console
    
  2. From the Domain Structure menu, expand Environment and select Machines.

    The Summary of Machines page is displayed.

  3. Select ComputeNode1. The Settings for ComputeNode1 page is displayed.

  4. Click the Node Manager tab.

  5. Ensure that Plain is selected as the Type. Click Save.

  6. Repeat these steps for ComputeNode2.

5.15 Disabling Host Name Verification for Managed Servers

You will receive errors when managing the different WebLogic Servers if you have not configured the server certificates. To avoid these errors, disable host name verification while setting up and validating the topology.

To disable host name verification for Managed Servers, such as WLS1, complete the following steps:

  1. Log in to Oracle WebLogic Server Administration Console.

  2. Click Lock & Edit.

  3. Expand the Environment node in the Domain Structure window.

  4. Click Servers. The Summary of Servers page is displayed.

  5. Select WLS1 in the Names column of the table. The settings page for WLS1 is displayed.

  6. Click the SSL tab.

  7. Expand the Advanced section of the page.

  8. Set host name verification to None.

  9. Click Save.

  10. Repeat steps 4 through 8 for the remaining Managed Servers in your WebLogic cluster.

  11. Save and activate the changes.

  12. Restart Node Manager:

    1. Stop Node Manager by stopping the process associated with it.

      If it is running in the foreground in a shell, simply use Ctrl+c.

      If it is running in the background in the shell, find the associate process and use the kill command to stop it.

    2. Start Node Manager.

5.16 Starting Managed Servers on ComputeNode1 and ComputeNode2

You must start the Managed Servers on ComputeNode1 and ComputeNode2 as follows:

  1. Log in to the Oracle WebLogic Administration Console, using the following URL in a browser:

    http://ADMINVHN1:7001/console
    
  2. From the Domain Structure menu, expand Environment and select Servers.

    The Summary of Servers page is displayed.

  3. Select Control.

  4. In the Servers table, click WLS1 Managed Server instance.

  5. Click Start.

  6. On the Server Life Cycle Assistant page, click Yes to confirm.

    The Node Manager starts the server on the target machine. When the Node Manager finishes its start sequence, the server's state is indicated in the State column in the Servers Status table.

  7. Repeat the above steps to start remaining Managed Servers on ComputeNode1 and ComputeNode2.

5.17 Disabling Host Name Verification for the Administration Server

This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server. If you have not configured the server certificates, you will receive errors when managing the different WebLogic servers. To avoid these errors, disable host name verification while setting up and validating the topology.

Perform these steps to disable host name verification:

  1. Log in to the Oracle WebLogic Administration Console, using the following URL in a browser:

    http://ADMINVHN1:7001/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 AdminServer(admin) in the Names column of the table. The settings page for the server is displayed.

  5. Select the SSL tab.

  6. Expand the Advanced section.

  7. Set Hostname Verification to None.

  8. Click Save.

  9. Click Activate Changes.

  10. The change will not take effect until the Administration Server is restarted (Node Manager must be up and running):

    1. In the Summary of Servers screen, select the Control tab.

    2. Select AdminServer(admin) in the table and then click Shutdown.

    3. Start the Administration Server again from the command line, as described in Section 5.6, "Starting the Administration Server on ComputeNode1."

5.18 Creating a JMS Persistence Store

Before you create the JMS persistence store, ensure that you have created a directory for the file store on your file system. Perform these steps to create a shared JMS persistence Store:

  1. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.

  2. In the left pane of the Console, expand Services node and then select Persistence Stores.

    The Summary of Persistence Stores page is displayed.

  3. Click New, and then Create File Store.

    Note:

    Once you create a file store, you cannot rename it. Instead, you must delete it and create another one that uses the new name.

  4. On the Create a new File Store page, enter the following:

    • Name: Name for the File Store.

    • Target: WLS1.

      Note:

      In a clustered environment, a recommended best practice is to target a custom file store to the same migratable target as the migratable JMS service, so that a member server will not be a single point of failure. A file store can also be automatically migrated from an unhealthy server instance to a healthy server instance, with the help of the server health monitoring services. In addition, configure a reasonable maximum message count quota on each JMS server. Assume each message header uses approximately 1K.

    • Directory: Pathname to the directory on the file system where the file store is kept. This directory must exist on your system, so be sure to create it before completing this tab. Enter the location of the persistent storage on the Sun ZFS Storage 7320 appliance that is available to other servers in the cluster. Specifying this location enables pending JMS messages to be sent. The location should follow the following directory structure:

      /u01/Dept_1/jmsjta/base_domain/Dept1_Cluster1/jms

      Where Dept1_Cluster1 is the name of the WebLogic cluster.

      Note:

      This location maps to /export/Dept_1/jmsjta share on the Sun ZFS Storage 7320 appliance. Both ComputeNode1 and ComputeNode2 must be able to access this directory. Ensure that you mount this directory from both ComputeNode1 and ComputeNode2, as described in Section 3.4.2, "Setting Up Enterprise Deployment Storage Configuration". This directory must also exist before you restart the server.

      You must configure the location for all of the persistence stores as a directory that is visible from both ComputeNode1 and ComputeNode2. Oracle recommends that you create and maintain separate shares for JMS logs under the Dept_1 project, as shown in the Figure 3-5. See Section 3.4, "Shared Storage and Recommended Project and Share Structure" for more information.

      You must change all of the persistent stores to use this shared base directory.

      When a custom file store is targeted to a migratable target, the specified directory must be accessible from all candidate server members in the migratable target. For highest reliability, use a shared storage solution that is itself highly available—for example, a storage area network (SAN) or a dual-ported SCSI disk.

    • Click OK.

  5. Select the file store created in steps 2-3.

  6. On the File Store, Configuration tab, update any additional Advanced parameters as required:

    • Logical Name: Optional name that can be used by subsystems that need a way to refer to different stores on different servers using the same name.

    • Synchronous Write Policy: Specifies how this file store writes data to disk. Choose Direct-Write, which is the default value.

  7. Click Save.

  8. Click Activate Changes.

  9. Restart the servers to make the change in the persistent stores take effect.

Note:

Each Managed Server, such as WLS1, gets a default file store.

If you are leveraging WebLogic JMS, Oracle recommends that you to follow additional configuration and tuning guidelines as described in: the following guides:

5.19 Configuring a Default Persistence Store for Transaction Recovery

Each server has a transaction log that stores information about committed transactions that are coordinated by the server that may not have been completed. Oracle WebLogic Server uses this transaction log for recovery from system crashes or network failures. To leverage the migration capability of the Transaction Recovery Service for the servers within a cluster, store the transaction log in a location accessible to a server and its backup servers. In this example procedure, we describe how to configure a default persistence store for transaction recovery for the WLS1 Managed Server to which the sample application is deployed. Follow the same procedure to configure a default persistence store for transaction recovery on the remaining Managed Servers, if required.

Note:

This location should be on a shared file system the Sun ZFS Storage 7320 appliance.

Perform these steps to set the location for the default persistence store:

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

  2. In the left pane of the Console, expand Environment and select Servers.

    The Summary of Servers page is displayed.

  3. Click the name of the server, such as WLS1 (represented as a hyperlink) in the Name column of the table.

    The settings page for the selected server is displayed, and defaults to the Configuration tab.

  4. Open the Services tab.

  5. In the Default Store section of the page, enter the path to the folder where the default persistent stores will store its data files. The directory structure of the path is as follows:

    /u01/Dept_1/jmsjta/base_domain/Dept1_Cluster1/tlogs

    Where Dept1_Cluster1 is the name of the WebLogic cluster.

    For more information, see Figure 3-5.

  6. Click Save.

Note:

To enable migration of the Transaction Recovery Service, specify a location on a persistent storage solution that is available to other servers in the cluster. Both ComputeNode1 and ComputeNode2 must be able to access this directory. Ensure that you mount this directory from both ComputeNode1 and ComputeNode2, as described in Section 3.4.2, "Setting Up Enterprise Deployment Storage Configuration". This directory must also exist before you restart the server.

5.20 Manually Failing Over the Administration Server to ComputeNode2

In case the compute node (ComputeNode1) hosting the Administration Server fails, you can fail over the Administration Server to ComputeNode2. This section describes how to fail over the Administration Server from ComputeNode1 to ComputeNode2.

Assumptions:

  • The Administration Server is configured to listen on 10.0.0.17. This address is the floating IP assigned to the Administration Server using the BOND0 interface.

  • The Administration Server is failed over from ComputeNode1 to ComputeNode2, and the two nodes have these IPs (BOND0):

    • ComputeNode1: 192.168.10.1

    • ComputeNode2: 192.168.10.2

    • 10.0.0.17: This is the floating IP where the Administration Server is running, assigned to bond0:Y, available in ComputeNode1 and ComputeNode2.

  • The domain directory where the Administration Server is running in ComputeNode1 is on shared storage.

The following procedure shows how to fail over the Administration Server to a different node (ComputeNode2), but the Administration Server will still use the same WebLogic Server machine (which is a logical machine, not a physical machine).

  1. Stop the Administration Server.

  2. Migrate IP to the second node.

    1. Run the following command as root on ComputeNode1 (where bond0:Y is the current interface used by ADMINVHN1):

      ComputeNode1> /sbin/ifconfig bond0:Y down
      
    2. Run the following command on ComputeNode2:

      ComputeNode2> /sbin/ifconfig <interface:index> <IP_Address> netmask <netmask>
      

      For example:

      /sbin/ifconfig bond0:1 10.0.0.17 netmask 255.255.255.0
      

      Note:

      Ensure that the netmask and interface to be used to match the available network configuration in ComputeNode2.

  3. On Linux, update routing tables through arping, for example:

    ComputeNode2> /sbin/arping -b -A -c 3 -I bond0 10.0.0.17
    
  4. Start the Administration Server on ComputeNode2 using the startWebLogic.sh script, as described in Section 5.6, "Starting the Administration Server on ComputeNode1.".

  5. Test that you can access the Administration Server on ComputeNode2 as follows:

    1. Ensure that you can access the Oracle WebLogic Server Administration Console at http://10.0.0.17:7001/console.

    2. Check that you can access and verify the status of components in the Oracle Enterprise Manager at http://ADMINVHN1:7001/em.

      Note:

      The Administration Server does not use Node Manager for failover. After a manual failover, the machine name that appears in the Current Machine field in the Administration Console for the server is ComputeNode1, and not the failover machine, ComputeNode2. Since Node Manager does not monitor the Administration Server, the machine name that appears in the Current Machine field, is not relevant and you can ignored it.

      If you created a boot.properties file for the Administration Server on ComputeNode1, the username and password values in the file get encrypted. When the Administration Server is failed over to ComputeNode2, you must edit the username and password values in the boot.properties file on ComputeNode2 manually.

5.21 Failing the Administration Server Back to ComputeNode1

This step checks that you can fail back the Administration Server, that is, stop it on ComputeNode2 and run it on ComputeNode1. To do this, migrate Administration Server back to ComputeNode1 as follows:

  1. Run the following command on ComputeNode2.

    ComputeNode2> /sbin/ifconfig bond0:N down
    
  2. Run the following command on ComputeNode1:

    ComputeNode1> /sbin/ifconfig bond0:Y 10.0.0.17 netmask 255.255.255.0
    

    Note:

    Ensure that the netmask and interface to be used match the available network configuration in ComputeNode1.

  3. On Linux, update routing tables through arping. Run the following command from ComputeNode1.

    ComputeNode1> /sbin/arping -b -A -c 3 -I bond0 10.0.0.17
    
  4. Start WLST and connect to Node Manager with nmconnect and start the Administration Server using nmstart.

    ComputeNode1> /u01/app/FMW_Product1/Oracle/Middleware/wlserver_10.3/common/bin
    ComputeNode1> ./wlst.sh
    

    Once you are in the WLST shell:

    wls:/offline>nmConnect('Admin_User','Admin_Password',
    'ComputeNode1','5556','domain_name','/u01/Dept_1/domains/el01cn01/base_domain','ssl')
     
    wls:/nm/base_domain> nmStart('AdminServer')
    
  5. Test that you can access the Oracle WebLogic Server Administration Console at http://10.0.0.17:7001/console.

5.22 Backing Up Domain Configuration

Perform a backup to save your domain configuration (make sure that you stop the Administration Server and Managed Servers first). The configuration files all exist under the /u01/Dept_1/domains/el01cn01/base_domain directory.

tar -cvzf base_domainback.tar /u01/app/Dept_1/domain_home/base_domain