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:
Oracle WebLogic Server 11g Release 1 (10.3.4)
Oracle Coherence 3.6.0.4
Oracle JRockit JVM 28.1.0 (For Oracle Linux)
Oracle Sun JDK 1.6.0_23 (For Oracle Solaris)
Oracle HTTP Server 11g Release 1 (11.1.1.4.0)
Note:
In this guide, Oracle HTTP Server is used as the web server in the Web tier of the enterprise deployment reference topology.
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
In this example configuration, you are creating a single Oracle WebLogic domain including the following:
Four Managed Servers each on ComputeNode1
and on ComputeNode2
in a WebLogic cluster
Node Manager on each compute node
Two optional Oracle HTTP Server instances per compute node for load balancing traffic on the BOND0
(IPoIB) network
An OPMN process on each compute node to monitor the optional Oracle HTTP Server instances
Oracle WebLogic Administration Server running on one of the compute nodes, such as ComputeNode1
An Oracle Coherence cluster comprising four storage-enabled Coherence Servers spanning ComputeNode1
and ComputeNode2
Note:
In Figure 5-1, Coh1
and Coh2
represent Coherence nodes that are configured to run on ComputeNode1
. Coh3
and Coh4
run on ComputeNode2
. These are used as example names only. The nodes have their own end point (BOND0
IP addresses of the machines as the host addresses). In the example scenario discussed in this guide, the BOND0
IP of ComputeNode1
is 192.168.10.1
. ComputeNode2
uses 192.168.10.2
.
This chapter discusses the following topics:
Section 5.3, "Enabling Floating IP for Administration Server on ComputeNode1"
Section 5.5, "Creating boot.properties for the Administration Server on ComputeNode1"
Section 5.6, "Starting the Administration Server on ComputeNode1"
Section 5.8, "Restarting the Administration Server on ComputeNode1"
Section 5.10, "Optional: Creating Oracle HTTP Server Instances in the Exalogic Environment"
Section 5.12, "Configuring Network Channels for HTTP and T3 Clients via EoIB"
Section 5.14, "Specifying Node Manager Type for ComputeNode1 and ComputeNode2"
Section 5.15, "Disabling Host Name Verification for Managed Servers"
Section 5.16, "Starting Managed Servers on ComputeNode1 and ComputeNode2"
Section 5.17, "Disabling Host Name Verification for the Administration Server"
Section 5.19, "Configuring a Default Persistence Store for Transaction Recovery"
Section 5.20, "Manually Failing Over the Administration Server to ComputeNode2"
Section 5.21, "Failing the Administration Server Back to ComputeNode1"
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.
The following are the prerequisites for configuring Oracle Fusion Middleware 11g Release 1 (11.1.1) products for Oracle Exalogic:
Preconfiguring the environment, including database, storage, and network, as described in Chapter 3, "Network, Storage, and Database Preconfiguration".
Installing Oracle WebLogic Server 11g Release 1 (10.3.4) and creating a Middleware Home on a shared file system on Sun ZFS Storage 7320 appliance. This file system should be accessible by both ComputeNode1
and ComputeNode2
, as described in Section 4.1, "Installing Oracle WebLogic Software and Creating the Middleware Home".
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 (ADMINVHN
1) must be enabled on ComputeNode1
.
To enable the floating IP on ComputeNode1
, complete the following steps:
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
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
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.
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
.
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".
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
Start the Configuration Wizard:
ComputeNode1> ./config.sh
The Welcome screen is displayed.
Select Create a new WebLogic Domain, and click Next.
The Select Domain Source screen is displayed.
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.
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.
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.
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
Select the following:
Administration Server
Managed Servers, Clusters and Machines
Click Next.
The Configure the Administration Server screen is displayed.
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.
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.
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.
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).
Click Next.
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
Click Next.
The Configure Machines screen is displayed.
The Configure Machines screen is displayed. In this screen, click the Unix Machine tab and then click Add to add the following machines:
Name | Node Manager Listen Address |
---|---|
|
The |
|
The |
|
The floating IP address of |
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).
Click Next.
The Assign Servers to Machines screen is displayed.
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).
Click Next.
The Configuration Summary screen is displayed. In this screen, review the summary of configuration you have chosen and click Create.
In the Create Domain screen, click Done.
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:
Create the following directory structure:
mkdir -p /u01/Dept_1/domains/el01cn01/base_domain/servers/AdminServer/security
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.
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"
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
.
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".
Log in to the Administration Server Console using the WebLogic Administration Server user name and password.
In the banner toolbar region at the top of the right pane of the Console, click Preferences.
The Preferences page is displayed.
Click Shared Preferences, and then deselect Follow Configuration changes.
Click Save.
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.
Oracle provides the following recommendations for Node Manager configuration in enterprise deployment topologies:
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.
Set up a dedicated Node Manager for each of the compute nodes.
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:
You must start the Node Manager to generate the properties file. Perform these steps to start Node Manager:
Start Node Manager:
ComputeNode1> cd /u01/FMW_Product1/wlserver_10.3/server/bin ComputeNode1> ./startNodeManager.sh
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.
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
Repeat these steps on ComputeNode2
.
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:
Create the following directories:
On ComputeNode1
:
mkdir -p /u01/Dept_1/admin/el01cn01/nodemanager
On ComputeNode2
:
mkdir -p /u01/Dept_1/admin/el01cn02/nodemanager
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
:
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
.
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
.
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 |
---|---|
|
Set the value to " |
|
Set the value to " |
|
Set the value to " |
|
Specify a name for the stop script, for example |
|
|
|
|
|
|
|
|
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.
Use the Administration Console to update the Node Manager credentials for ComputeNode1
and ComputeNode2
:
In a browser, go to the following URL:
http://ADMINVHN1:7001/console
Log in as the administrator.
Click Lock and Edit.
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.
Click Security tab, and then General tab.
Expand the Advanced options at the bottom.
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
.
Click Save.
Click Activate Changes.
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
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.
Start WLST as follows:
ComputeNode1> cd /u01/app/FMW_Product1/Oracle/Middleware/wlserver_10.3/common/bin ComputeNode1> ./wlst.sh
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')
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.
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
.
You must stop the Administration Server, and restart it using the Node Manager. Complete the following steps:
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.
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.
Perform these steps to ensure that the Administration Server is properly configured:
In a browser, go to http://ADMINVHN1:7001/console
.
Log in as the administrator.
In the left pane of the Console, expand Environment, and then Servers.
The Summary of Servers page is displayed.
In the Summary of Servers, ensure that the Managed Servers created for ComputeNode1
and ComputeNode2
are listed (Figure 5-7).
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:
Ensure that Oracle HTTP Server is installed, as described in Section 4.3, "Installing Oracle HTTP Server".
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.
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.
Click Next.
The Configure Components Screen is displayed.
Select Oracle HTTP Server and Select Associate Selected Components with WebLogic Domain.
Click Next.
The Specify WebLogic Domain Screen is displayed.
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.
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.
Select Auto Port Configuration to automatically assign the default port.
Click Next.
The Specify Security Updates Screen is displayed.
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.
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.
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.
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.
Edit the configuration files for the OHS1
instance as follows:
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
.
Save the httpd.conf
file and close.
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"/>
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"/>
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".
You have created the domain (base_domain
) on ComputeNode1
. You must propagate the domain configuration to ComputeNode2
as follows:
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
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
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:
Section 5.12.1, "Using BOND1 Floating IP Addresses for EoIB Communication"
Section 5.12.2, "Configuring the Administration Server Network Channel"
Section 5.12.3, "Configuring Network Channels for Managed Servers on ComputeNode1 and ComputeNode2"
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)".
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:
To create the HTTP network channel for the Administration Server, complete the following steps:
In a browser, go to http://ADMINVHN1:7001/console
.
Log in as the administrator.
If you have not already done so, click Lock & Edit in the Change Center.
In the left pane of the Console, expand Environment, and then Servers.
The Summary of Servers page is displayed.
In the Servers table, click AdminServer(admin).
The Settings for AdminServer page is displayed.
Select Protocols, and then Channels.
Click New.
Enter AdminHTTPClient as the name of the new network channel and select http as the protocol, then click Next.
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
Click Next, and select Enabled on the Network Channel Properties page.
Click Finish.
To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
To create the t3 network channel for the Administration Server, complete the following:
In a browser, go to http://ADMINVHN1:7001/console
.
Log in as the administrator.
If you have not already done so, click Lock & Edit in the Change Center.
In the left pane of the Console, expand Environment, and then Servers.
The Summary of Servers page is displayed.
In the Servers table, click AdminServer(admin).
The Settings for AdminServer page is displayed.
Select Protocols, and then Channels.
Click New.
Enter AdminT3 as the name of the new network channel and select t3 as the protocol, then click Next.
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
Click Next, and select the following in the Network Channel Properties page:
Enabled
HTTP Enabled for This Protocol
Click Finish.
To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
For Managed Servers, you must create the following network channels using Ethernet over InfiniBand (EoIB
):
To create a HTTP network channel for a Managed Server such as WLS1, complete the following steps:
In a browser, go to http://ADMINVHN1:7001/console
.
Log in as the administrator.
If you have not already done so, click Lock & Edit in the Change Center.
In the left pane of the Console, expand Environment, and then Servers.
The Summary of Servers page is displayed.
In the Servers table, click WLS1.
The Settings for WLS1 page is displayed.
Select Protocols, and then Channels.
Click New.
Enter HTTPClient as the name of the new network channel and select http as the protocol, then click Next.
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
Click Next, and select the following in the Network Channel Properties page:
Enabled
HTTP Enabled for This Protocol
Click Finish.
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 |
To create the t3 network channel for a Managed Server server such as WLS1
, complete the following steps:
In a browser, go to http://ADMINVHN1:7001/console
.
Log in as the administrator.
If you have not already done so, click Lock & Edit in the Change Center.
In the left pane of the Console, expand Environment, and then Servers.
The Summary of Servers page is displayed.
In the Servers table, click AdminServer(admin).
The Settings for AdminServer page is displayed.
Select Protocols, and then Channels.
Click New.
Enter T3ClientChannel as the name of the new network channel and select t3 as the protocol, then click Next.
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
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
Click Finish.
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 |
This section describes how to configure Oracle Coherence for Oracle Exalogic enterprise deployment. You must complete the following tasks:
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
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
:
Log in to the Oracle WebLogic Administration Console, using the following URL in a browser:
http://ADMINVHN1:7001/console
If you have not already done so, click Lock & Edit in the Change Center.
In the left pane of the Console, expand Environment and select Coherence Clusters.
The Summary of Coherence Clusters page is displayed.
Click New.
The Create Coherence Cluster Configuration page is displayed.
Enter CoherenceCluster1 as the name of the Coherence cluster configuration and click Next.
The Coherence Cluster Addressing page is displayed.
Accept the default values, and click Next.
The Coherence Cluster Targets page is displayed.
Select Dept1_Cluster1, and then All servers in the cluster (Figure 5-8) to deploy this Coherence cluster configuration.
Click Finish.
The Summary of Coherence Clusters page is displayed, displaying the Coherence Cluster you created for Dept1_Cluster1
(Figure 5-9).
You must deploy the following shared library files:
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:
Log in to the Oracle WebLogic Administration Console.
If you have not already done so, click Lock & Edit in the Change Center.
In the left pane of the Console, click Deployments.
The Summary of Deployments page is displayed.
Click Install. The Install Application Assistant screen is displayed.
Use the Install Application Assistant to deploy coherence-web-spi.war
as a library to Dept1_Cluster1
. Do the following:
Locate and select the coherence-web-spi.war
file. It resides in the /u01/app/FMW_Product1/Oracle/Middleware/coherence_3.6/lib
directory.
Click Next.
The Choose targeting style page is displayed.
Ensure that Install this deployment as a library is selected.
Click Next.
The Select deployment targets page is displayed.
Select Dept1_Cluster1 as the deployment target.
Click Next.
In Optional Settings page, select Copy this application onto every target for me option in the Source accessibility section.
Click Finish.
The Summary of Deployments page is displayed, displaying the coherence-web-spi.war
file you have installed.
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
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:
Log in to the Oracle WebLogic Administration Console.
If you have not already done so, click Lock & Edit in the Change Center.
In the left pane of the Console, click Deployments.
The Summary of Deployments page is displayed.
Click Install.
The Install Application Assistant screen is displayed.
Use the Install Application Assistant to deploy active-cache-1.0.jar
as a library to Dept1_Cluster1
. Do the following:
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.
Click Next.
The Choose targeting style page is displayed.
Ensure that Install this deployment as a library is selected.
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.
Select Dept1_Cluster1 as the deployment target.
Click Next.
The Optional Settings page is displayed.
Select I will make the deployment accessible from the following location option in the Source accessibility section.
Click Finish.
The Summary of Deployments page is displayed, displaying the active-cache-1.0.jar
file you have installed.
Click Activate Changes.
You must deploy the coherence.jar
file to Dept1_Cluster1
. To do so, complete the following steps:
Log in to the Oracle WebLogic Administration Console.
If you have not already done so, click Lock & Edit in the Change Center.
In the left pane of the Console, click Deployments.
The Summary of Deployments page is displayed.
Click Install.
The Install Application Assistant screen is displayed.
Use the Install Application Assistant to deploy coherence.jar
as a library to Dept1_Cluster1
. Do the following:
Locate and select the coherence.jar
file. It resides in the /u01/app/FMW_Product1/Oracle/Middleware/coherence_3.6/lib
directory.
Click Next.
The Choose targeting style page is displayed.
Ensure that Install this deployment as a library is selected.
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.
Select Dept1_Cluster1 as the deployment target.
Click Next.
The Optional Settings page is displayed.
Select Copy this application onto every target for me option in the Source accessibility section.
Click Finish.
The Summary of Deployments page is displayed, displaying the coherence.jar
file you have installed.
Click Activate Changes.
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:
Create a standard Web application directory as follows:
/ /WEB-INF
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>
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>
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.
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>
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.
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
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.
To deploy the counter.war
application:
Open the Summary of Deployments page by clicking Deployments in the Domain Structure menu in the Oracle WebLogic Server Administration Console.
Click Install. The Install Application Assistant wizard opens.
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.
You must create four Coherence servers across ComputeNode1
and ComputeNode2
, as illustrated in Figure 5-1:
If you have not already done so, click Lock & Edit in the Change Center of the Administration Console.
In the left pane of the Console, expand Environment and select Coherence Servers.
The Summary of Coherence Servers page is displayed.
Click New.
The Create Coherence Server Configuration page is displayed.
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.
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.
The Summary of Coherence Servers page is displayed, displaying the Coherence Servers you have created for ComputeNode1
and ComputeNode2
(Figure 5-10).
To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
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:
If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.
In the left pane of the Console, expand Environment and select Coherence Servers.
In the Coherence Servers table, select Coh1.
Select Configuration tab and then select Server Start tab.
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
Repeat these steps for the remaining Coherence Servers.
To start the Coherence Servers on ComputeNode1
and ComputeNode2
, complete the following steps:
In the WebLogic Administration Server Console, from the Domain Structure menu, expand Environment and select Coherence Servers.
In the right pane, select Control.
Select the check box next to Coh1, and click Start.
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.
Repeat the above steps to start the remaining seven Coherence Servers.
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.
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.
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.
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.
You must specify the Node Manager type for ComputeNode1
and ComputeNode2
as follows:
Log in to the Oracle WebLogic Administration Console, using the following URL in a browser:
http://ADMINVHN1:7001/console
From the Domain Structure menu, expand Environment and select Machines.
The Summary of Machines page is displayed.
Select ComputeNode1
. The Settings for ComputeNode1 page is displayed.
Click the Node Manager tab.
Ensure that Plain
is selected as the Type. Click Save.
Repeat these steps for ComputeNode2
.
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:
Log in to Oracle WebLogic Server Administration Console.
Click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page is displayed.
Select WLS1
in the Names column of the table. The settings page for WLS1 is displayed.
Click the SSL tab.
Expand the Advanced section of the page.
Set host name verification to None
.
Click Save.
Repeat steps 4 through 8 for the remaining Managed Servers in your WebLogic cluster.
Save and activate the changes.
Restart Node Manager:
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.
Start Node Manager.
You must start the Managed Servers on ComputeNode1
and ComputeNode2
as follows:
Log in to the Oracle WebLogic Administration Console, using the following URL in a browser:
http://ADMINVHN1:7001/console
From the Domain Structure menu, expand Environment and select Servers.
The Summary of Servers page is displayed.
Select Control.
In the Servers table, click WLS1 Managed Server instance.
Click Start.
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.
Repeat the above steps to start remaining Managed Servers on ComputeNode1
and ComputeNode2
.
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:
Log in to the Oracle WebLogic Administration Console, using the following URL in a browser:
http://ADMINVHN1:7001/console
Click Lock and Edit.
From the Domain Structure menu, select Environment, and then Servers.
The Summary of Servers page is displayed.
Select AdminServer(admin) in the Names column of the table. The settings page for the server is displayed.
Select the SSL tab.
Expand the Advanced section.
Set Hostname Verification to None.
Click Save.
Click Activate Changes.
The change will not take effect until the Administration Server is restarted (Node Manager must be up and running):
In the Summary of Servers screen, select the Control tab.
Select AdminServer(admin) in the table and then click Shutdown.
Start the Administration Server again from the command line, as described in Section 5.6, "Starting the Administration Server on ComputeNode1."
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:
If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.
In the left pane of the Console, expand Services node and then select Persistence Stores.
The Summary of Persistence Stores page is displayed.
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.
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.
Select the file store created in steps 2-3.
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.
Click Save.
Click Activate Changes.
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:
"Tuning WebLogic JMS" in the Oracle Fusion Middleware Performance and Tuning for Oracle WebLogic Server
"Best Practices for JMS Beginners and Advanced Users" in the Oracle Fusion Middleware Configuring and Managing JMS for Oracle WebLogic Server
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:
Log in to the Oracle WebLogic Server Administration Console.
In the left pane of the Console, expand Environment and select Servers.
The Summary of Servers page is displayed.
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.
Open the Services tab.
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.
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.
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).
Stop the Administration Server.
Migrate IP to the second node.
Run the following command as root on ComputeNode1
(where bond0
:Y
is the current interface used by ADMINVHN1
):
ComputeNode1> /sbin/ifconfig bond0:Y down
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
.
On Linux, update routing tables through arping
, for example:
ComputeNode2> /sbin/arping -b -A -c 3 -I bond0 10.0.0.17
Start the Administration Server on ComputeNode2
using the startWebLogic.sh
script, as described in Section 5.6, "Starting the Administration Server on ComputeNode1.".
Test that you can access the Administration Server on ComputeNode2
as follows:
Ensure that you can access the Oracle WebLogic Server Administration Console at http://10.0.0.17:7001/console
.
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.
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:
Run the following command on ComputeNode2
.
ComputeNode2> /sbin/ifconfig bond0:N down
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
.
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
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')
Test that you can access the Oracle WebLogic Server Administration Console at http://10.0.0.17:7001/console
.
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