This chapter provides information about managing the Identity Management enterprise deployment you have set up.
This chapter includes the following topics:
This section describes how to start, stop and restart the various components of the Oracle Enterprise Deployment for Identity Management.
Start system components such as Oracle Virtual Directory by typing:
ORACLE_INSTANCE/bin/opmnctl startall
You can verify that the system components have started by executing:
ORACLE_INSTANCE/bin/opmnctl status -l
Stop system components such as Oracle Virtual Directory by executing the following command:
ORACLE_INSTANCE/bin/opmnctl stopall
Start system components such as Oracle Internet Directory by typing
ORACLE_INSTANCE/bin/opmnctl startall
You can verify that the system components have started by executing:
ORACLE_INSTANCE/bin/opmnctl status -l
Stop system components such as Oracle Internet Directory by executing the following command:
ORACLE_INSTANCE/bin/opmnctl stopall
Prior to starting/stopping the Oracle HTTP server ensure that the environment variables ORACLE_HOME and ORACLE_INSTANCE are defined and that ORACLE_HOME/opmn/bin appears in the PATH. For example:
export ORACLE_HOME=/u01/app/oracle/product/fmw/web export ORACLE_INSTANCE=/u01/app/oracle/admin/web[1-2] export PATH=$ORACLE_HOME/opmn/bin:$PATH
Start the Oracle web tier by issuing the command:
opmnctl startall
Stop the web tier by issuing the command
opmnctl stopall
to stop the entire Web tier or
opmnctl stoproc process-type=OHS
to stop Oracle HTTP Server only.
You can restart the web tier by issuing a Stop followed by a Start as described in the previous sections.
To restart the Oracle HTTP server only, use the following command.
opmnctl restartproc process-type=OHS
Start and stop the Node Manager as follows:
To start Node Manager, issue the commands:
IDMHOST> cd ORACLE_BASE/product/fmw/wlserver_10.3/server/bin
IDMHOST> ./startNodeManager.sh
To stop node manager, kill the process started in the previous section
Start and stop the WebLogic Administration Server as follows:
The recommended way to start the Administration server is to use WLST and connect to Node Manager:
IDMHOST1> cd ORACLE_BASE/product/fmw/oracle_common/common/bin
IDMHOST1> ./wlst.sh
Once in wlst shell, execute
wls:/offline>nmConnect(Admin_User,'Admin_Password,ADMINHOST1,'5556',
'IDMDomain','/u01/app/oracle/admin/domain_name/aserver/IDMDomain'
wls:/nm/domain_name> nmStart('AdminServer')
Alternatively, you can start the Administration server by using the command:
DOMAIN_HOME/bin/startWeblogic.sh
To stop the administration server, log in to the WebLogic console using the URL: http://admin.mycompany.com:7001/console.
Then proceed as follows:
Select Environment - Servers from the Domain Structure menu
Click on the Control tab
Select AdminServer(admin)
Click Shutdown and select Force Shutdown now.
Click Yes when asked to confirm that you wish to shutdown the administration server.
Restart the server by following the Stop and Start procedures in the previous sections.
Start and stop Oracle Identity Manager as follows:
To start the OIM managed server(s), log in to the WebLogic console using the URL: http://admin.mycompany.com:7001/console.
Then proceed as follows:
Select Environment - Servers from the Domain Structure menu
Click on the Control tab
Select OIM Servers WLS_SOA1 and/or WLS_SOA2
Note:
Start the SOA managed servers (WLS_SOA1/WLS_SOA2) before starting the OIM managed servers (WLS_OIM1/WLS_OIM2).Click on the Start button.
Click Yes when asked to confirm that you wish to start the server(s).
After WLS_SOA1 and/or WLS_SOA2 have started, select WLS_OIM1 and/or WLS_OIM2
Click Start.
Click Yes when asked to confirm that you wish to start the server(s).
To stop the OIM managed server(s), log in to the WebLogic console using the URL: http://admin.mycompany.com:7001/console. Then proceed as follows:
Select Environment - Servers from the Domain Structure menu
Click the Control tab
Select OIM Servers (WLS_OIM1 and/or WLS_OIM2) and WLS_SOA1 and/or WLS_SOA2)
Click the Shutdown button and select Force Shutdown now.
Click Yes when asked to confirm that you wish to shutdown the server(s).
Restart the server by following the Stop and Start procedures in the previous sections.
Start and stop Oracle Access Manager Managed Servers as follows:
To start the OAM managed server(s), log in to the WebLogic console using the URL: http://admin.mycompany.com:7001/console.
Then proceed as follows:
Select Environment - Servers from the Domain Structure menu
Click on the Control tab
Select OAM Servers (WLS_OAM1 and/or WLS_OAM2)
Click on the Start button.
Click Yes when asked to confirm that you wish to start the server(s).
To stop the OAM managed server(s), log in to the WebLogic console using the URL: http://admin.mycompany.com:7001/console. Then proceed as follows:
Select Environment - Servers from the Domain Structure menu
Click the Control tab
Select OAM Servers (WLS_OAM1 and/or WLS_OAM2)
Click the Shutdown button and select Force Shutdown now.
Click Yes when asked to confirm that you wish to shutdown the server(s).
Restart the server by following the Stop and Start procedures in the previous sections.
Start and stop Oracle Adaptive Access Manager as follows:
To start the OAAM managed server(s), log in to the WebLogic console using the URL: http://admin.mycompany.com:7001/console. Then proceed as follows:
Select Environment - Servers from the Domain Structure menu
Click the Control tab
Select OAAM Servers (WLS_OAAM1 and/or WLS_OAAM2)
Click the Start button.
Click Yes when asked to confirm that you wish to start the server(s).
To stop the OAM managed server(s), log in to the WebLogic console using the URL: http://admin.mycompany.com:7001/console. Then proceed as follows:
Select Environment - Servers from the Domain Structure menu
Click the Control tab
Select OAAM Servers (WLS_OAAM1 and/or WLS_OAAM2)
Click Shutdown and select Force Shutdown now.
Click Yes when asked to confirm that you wish to shutdown the server(s).
Restart the server by following the Stop and Start procedures above.
This section provides information about monitoring the Identity Management enterprise deployment described in this manual.
You can use the Oracle Enterprise Manager Fusion Middleware Control to monitor Oracle Internet Directory, as follows:
On the Farm home page for an Identity Management domain, view the Fusion Middleware pie chart. This chart shows the status of Oracle Fusion Middleware components. Green sections of the chart indicate components that are up and running properly, and red sections indicate components that are down.
The Identity and Access section below the chart includes the name of each individual Oracle Internet Directory instance (for example, oid1, oid2), its status, host name, and CPU usage percentage. A green arrow in the Status column indicates that the instance is up and running properly, and a red arrow indicates the instance is down. Click the name of an individual Oracle Internet Directory instance to view the home page for that instance.
The home page for an instance displays metrics for the instance such as performance, load, security, response, CPU utilization %, and memory utilization %.
When you perform an Oracle Internet Directory installation using Oracle Identity Management 11g Installer, the default component name that the installer assigns to the Oracle Internet Directory instance is oid1. You cannot change this component name.
The instance specific configuration entry for this Oracle Internet Directory instance is cn=oid1, cn=osdldapd, cn=subconfigsubentry.
If you perform a second Oracle Internet Directory installation on another computer and that Oracle Internet Directory instance uses the same database as the first instance, the installer detects the previously installed Oracle Internet Directory instance on the other computer using the same Oracle database, so it gives the second Oracle Internet Directory instance a component name of oid2.
The instance specific configuration entry for the second Oracle Internet Directory instance is cn=oid2, cn=osdldapd, cn=subconfigsubentry. Any change of properties in the entry cn=oid2, cn=osdldapd, cn=subconfigsubentry will not affect the first instance (oid1).
If a third Oracle Internet Directory installation is performed on another computer and that instance uses the same database as the first two instances, the installer gives the third Oracle Internet Directory instance a component name of oid3, and so on for additional instances on different hosts that use the same database.
Note that the shared configuration for all Oracle Internet Directory instances is cn=dsaconfig, cn=configsets,cn=oracle internet directory. Any change in this entry will affect all the instances of Oracle Internet Directory.
This naming scheme helps alleviate confusion when you view your domain using Oracle Enterprise Manager by giving different component names to your Oracle Internet Directory instances.
You can use the Oracle Enterprise Manager Fusion Middleware Control to monitor Oracle Virtual Directory, as follows:
On the Farm home page for an Identity Management domain, view the Fusion Middleware pie chart. This chart shows the status of Oracle Fusion Middleware components. Green sections of the chart indicate components that are up and running properly, and red sections indicate components that are down.
The Identity and Access section below the chart includes the name of each instance of the Oracle Virtual Directory application (for example, ovd1, ovd2), its status, and host name. A green arrow in the Status column indicates that the Oracle Virtual Directory instance is up and running properly, and a red arrow indicates the instance is down. Click the name of an individual Oracle Virtual Directory instance to view the home page for that instance.
The home page for an instance displays metrics and configurations for the instance such as:
Oracle Virtual Directory status - A green arrow next to the Oracle Virtual Directory instance name at the top of the page indicates that the instance is up and running properly and a red arrow indicates that the instance is down.
Current Load - This indicates the current work load of this Oracle Virtual Directory instance. It includes three metrics: Open Connections, Distinct Connected Users, and Distinct Connected IP Addresses.
Average Response Time Metric - This displays the average time (in milliseconds) to complete an LDAP search request.
Operations Metric - This displays the average number of LDAP search requests finished per millisecond.
Listeners - This table lists the listeners configured for this Oracle Virtual Directory instance to provide services to clients.
Adapters - This table lists existing adapters configured with the Oracle Virtual Directory instance. Oracle Virtual Directory uses adapters to connect to different underlying data repositories.
Resource Usage - On the right hand side of the page, the CPU and memory utilization metrics are displayed to indicate the system resources consumed by the Oracle Virtual Directory instance.
You can use the Oracle Enterprise Manager Fusion Middleware Control to monitor Oracle Directory Integration Platform, as follows:
On the Farm home page for an Identity Management domain, view the Fusion Middleware pie chart. This chart shows the status of Oracle Fusion Middleware components. Green sections of the chart indicate components that are up and running properly, and red sections indicate components that are down.
The Identity and Access section below the chart includes the name of each instance of the Oracle Directory Integration Platform application (all have the name DIP (11.1.1.1.0)), its status, and host name. Each Oracle Directory Integration Platform instance is deployed in a different Managed Server). A green arrow in the Status column indicates that the Oracle Directory Integration Platform instance is up and running properly, and a red arrow indicates the instance is down. Click the name of an individual Oracle Directory Integration Platform instance to view the home page for that instance.
The home page for an instance displays metrics for the instance such as:
Oracle Directory Integration Platform status - A green arrow next to the Oracle Directory Integration Platform instance name at the top of the page indicates that the instance is up and running properly and a red arrow indicates that the instance is down.
DIP Component Status - This table includes these metrics:
Quartz Scheduler - This indicates whether tasks can be scheduled for synchronization or not. A green arrow indicates the scheduler is up and a red arrow indicates that the scheduler is down.
Mbeans - This indicates whether profile management is available to the user or not. A green arrow indicates profile management is available and a red arrow indicates profile management is unavailable.
Synchronization Profiles - This shows registered profiles and their execution status. In a high availability deployment, all the instances will show the same list of profiles.
Provisioning Profiles- This shows registered provisioning profiles and their execution status. In a high availability deployment, all the instances will show the same list of profiles.
Resource Usage - On the right hand side of the page, the CPU and memory utilization metrics are displayed to indicate the resource usage by the Oracle Directory Integration Platform instance.
Oracle Enterprise Manager Grid Control can be used to perform monitoring of Oracle Access Manager. For details, see the "Identity Management" chapter of Oracle Enterprise Manager Concepts.
The reference enterprise topology discussed in this manual is highly scalable. It can be scaled up and or scaled out. When the topology is scaled up, a new server instance is added to a node already running one or more server instances. When the topology is scaled out, new servers are added to new nodes.
The Oracle Identity Management topology described in the guide has three tiers: the directory tier, application tier and web tier. The components in all the three tiers can be scaled up by adding a new server instance to a node that already has one or more server instances running.
The directory tier consists of the two Oracle Internet Directory nodes (OIDHOST1 and OIDHOST2), each running an Oracle Internet Directory instance and the two Oracle Virtual Directory nodes (OVDHOST1 and OVDHOST2), each running an Oracle Virtual Directory instance. The Oracle Internet Directory or Oracle Virtual Directory instances can be scaled up on one or both the nodes.
The directory tier has two Oracle Internet Directory nodes (OIDHOST1 and OIDHOST2), each running an Oracle Internet Directory instance. The existing Oracle Identity Management binaries on either node can be used for creating the new Oracle Internet Directory instance.
To add a new Oracle Internet Directory instance to either Oracle Internet Directory node, follow the steps in Section 7.2.2, "Configuring an Additional Oracle Internet Directory Instance" with the following variations:
In step 2 and step 4, choose ports other than 389 and 636 since these ports are being used by the existing Oracle Internet Directory instance on the node.
In step 5, instead of running the Oracle Identity Management 11g Installer, use the Oracle Fusion Middleware 11g Identity Management Configuration Wizard since the ORACLE_HOME already exists. Run the config.sh script under the ORACLE_HOME/bin directory to bring up the configuration wizard and follow the remaining steps to add a new Oracle Internet Directory instance to the node.
The screens in steps 6, 8, 9, 18, and 19 in Section 7.2.2, "Configuring an Additional Oracle Internet Directory Instance" are related to a new install and will not be shown since the ORACLE_HOME is being shared.
Follow the steps in Section 7.3.1, "Registering Oracle Internet Directory with the Oracle WebLogic Server Domain" to register the new Oracle Internet Directory instance with the WebLogic Domain. Use the location for the new Oracle Internet Directory instance as the value for ORACLE_INSTANCE.
Reconfigure the load balancer with the host and port information of the new Oracle Internet Directory instance.
The directory tier has two nodes (OVDHOST1 and OVDHOST2), each running an Oracle Virtual Directory instance. The existing Oracle Identity Management binaries on either node can be used for creating the new Oracle Virtual Directory instance.
To add a new Oracle Virtual Directory instance to either Oracle Virtual Directory node, follow the steps in Section 7.3.1, "Registering Oracle Internet Directory with the Oracle WebLogic Server Domain" with the following variations:
In step 2 and step 4, choose ports other than 6501 and 7501 since these ports are being used by the existing Oracle Virtual Directory instance on the node.
In step 6, instead of running the Oracle Identity Management 11g Installer, use the Oracle Fusion Middleware 11g Identity Management Configuration Wizard since the ORACLE_HOME already exists. Run the config.sh script under the ORACLE_HOME/bin directory to bring up the configuration wizard and follow the remaining steps to add a new Oracle Virtual Directory instance to the node.
The screens in steps 7, 9, 10, 16 and 17 in Section 7.2.2, "Configuring an Additional Oracle Internet Directory Instance" are related to a new install and will not be shown since the ORACLE_HOME is being shared.
Follow the steps in Section 7.3.1, "Registering Oracle Internet Directory with the Oracle WebLogic Server Domain" to register the new Oracle Virtual Directory instance with the WebLogic Domain. Use the location for the new Oracle Virtual Directory instance as the value for ORACLE_INSTANCE.
Reconfigure the load balancer with the host and port information of the new Oracle Virtual Directory instance.
The application tier has two nodes (IDMHOST1 and IDMHOST2) running Managed Servers for Oracle Directory Integration Platform and Oracle Directory Services Manager, two nodes (OAMHOST1 and OAMHOST2) running the Oracle Access Manager Identity Server and Access Server, and an Administration node (OAMADMINHOST) running an instance of the Oracle Access Manager WebPass, Policy Manager, WebGate and Oracle HTTP Server.
The application tier already has a node (IDMHOST2) running a Managed Server configured with Oracle Directory Integration Platform and Oracle Directory Services Manager components. The node contains a WebLogic Server home and an Oracle Fusion Middleware Identity Management Home on the local disk.
The existing installations (WebLogic Server home, Oracle Fusion Middleware home, and domain directories) can be used for creating a new Managed Server for the Oracle Oracle Directory Integration Platform and Oracle Directory Services Manager components.
Follow the steps in Section 9.2, "Expanding the Oracle Directory Integration Platform and ODSM Cluster," with the following variations to scale up the topology for Oracle Directory Integration Platform and Oracle Directory Services Manager:
Use the Oracle Identity Management Configuration Assistant to scale up the topology. Run the config.sh script under the ORACLE_HOME/bin directory to bring up the configuration assistant.
Reconfigure the Oracle HTTP Server module with the new Managed Server. Follow the instructions in Chapter 5, "Configuring the Web Tier" to complete this task.
With Oracle Access Manager, the new server instances need to be installed under a separate ORACLE_HOME location. Sharing ORACLE_HOMEs between instances of Oracle Access Manager components is not supported.
To scale up the Identity Server, follow the instructions in Section 10.3.1.2, "Installing the Second Identity Server on OAMHOST2."
To scale up the Access Server, follow the instructions in Section 10.4.2.2, "Starting the Access Server Installation."
To scale up the WebPass, follow the instructions in Section 10.3.3, "Installing WebPass on OAMADMINHOST."
To scale up the WebGate, follow the instructions in Section 10.4.3, "Installing WebGate on OAMADMINHOST, WEBHOST1, and WEBHOST2."
Scale up OAM as follows:
Log in to the Oracle WebLogic Server Administration Console at http://admin.mycompany.com/console.
From the Domain Structure window of the Oracle WebLogic Server Administration Console, expand the Environment node and then Servers. The Summary of Servers page appears.
Click on Lock & Edit from the Change Center menu.
Select an existing server on the host you wish to extend, for example: WLS_OAM1.
Click Clone.
Enter the following information:
Server Name: A new name for the server, for example: WLS_OAM3.
Server Listen Address: The name of the host on which the managed server will run.
Server Listen Port: The port the new managed server will use, this port must be unique within the host.
Click OK.
Click on the newly created server WLS_OAM3
Set the SSL listen port. This should be unique on the host that the managed server will be running on.
Click Save.
Disable host name verification for the new managed server. Before starting and verifying the WLS_OAM3 managed server, you must disable host name verification. You can re-enable it after you have configured server certificates for the communication between the Oracle WebLogic Administration Server and the Node Manager in OAMHOSTn.
If the source server from which the new one was cloned had already disabled hostname verification, these steps are not required, as the hostname verification settings were propagated to the cloned server. To disable host name verification:
In Oracle Enterprise Manager Fusion Middleware Control, select Oracle WebLogic Server Administration Console.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page appears.
Select WLS_OAM3 in the Names column of the table. The Settings page for server appears.
Click the SSL tab.
Click Advanced.
Set Hostname Verification to None.
Click Save.
Click Activate configuration from the Change Center menu.
Register the new managed server with OAM. You now need to configure the new managed server now as an OAM server. You do this from the Oracle OAM console. Proceed as follows:
Log in to the OAM console at http://admin.mycompany.com/oamconsole as the oamadmin user.
Click the System Configuration tab.
Click Server Instances.
Select Create from the Actions menu.
Enter the following information:
Server Name: WLS_OAM3
Host: Host that the server will run on
Port: Listen port that was assigned when the managed server was created
OAM Proxy Port: Port you want the OAM proxy to run on. This is unique for the host
Proxy Server ID: AccessServerConfigProxy
Mode: Open
Click Coherence tab.
Set Local Port to a unique value on the host.
Click Apply.
Click Apply.
You can now start the new managed server.
To scale up OAAM, use the same procedure for both the OAAM server and the OAAM Administration Server.
Log in to the Oracle WebLogic Server console at: http://admin.mycompany.com/console. Then proceed as follows:
From the Domain Structure window of the Oracle WebLogic Server Administration Console, expand the Environment node and then Servers. The Summary of Servers page appears.
Click Lock & Edit from the Change Center menu.
Select an existing server on the host that you want to extend, for example: WLS_OAAM1 or WLS_OAAM_ADMIN1.
Click Clone.
Enter the following information:
Server Name: A new name for the server, for example: WLS_OAAM3.
Server Listen Address: The name of the host on which the managed server will run.
Server Listen Port: The port the new managed server will use. This port must be unique within the host.
Click OK.
Click the newly-created server WLS_OAAM3.
Set the SSL listen port. This should be unique on the host that the managed server will be running on.
Click Save.
Disable host name verification for the new managed server. Before starting and verifying the WLS_OAAM3 managed server, you must disable host name verification. You can re-enable it after you have configured server certificates for the communication between the Oracle WebLogic Administration Server and the Node Manager in OAAMHOSTn.
If the source server from which the new one was cloned had already disabled hostname verification, these steps are not required, as the hostname verification settings were propagated to the cloned server. To disable host name verification:
In the Oracle Fusion Middleware Enterprise Manager Console, select Oracle WebLogic Server Administration Console.
Expand the Environment node in the Domain Structure pane.
Click Servers. The Summary of Servers page appears.
Select WLS_OAAM3 in the Names column of the table. The Settings page for server appears.
Click the SSL tab.
Click Advanced.
Set Hostname Verification to None.
Click Save.
Click Activate configuration from the Change Center menu.
You must now configure the new managed server now as an OAM server. You do this from the Oracle OAM console. Proceed as follows:
Log in to the OAM console at http://admin.mycompany.com/oamconsole as the oamadmin user.
Click the System Configuration tab.
Click Server Instances.
Select Create from the Actions Menu.
Enter the following information:
Server Name: WLS_OAM3
Host: Host that the server will be running on
Port: Listen port that was assigned when the managed server was created.
OAM Proxy Port: Port you want the OAM proxy to run on. This is unique for each host.
Proxy Server ID: AccessServerConfigProxy.
Mode: Open
Click Apply.
Click Coherence tab.
Set Local Port to a unique value on the host.
Click Apply.
You can now start the Access server. In order for the server to be used, however, you must inform any Webgates of its existence. You do this as follows:
Log in to the OAM console at http://admin.mycompany.com/oamconsole as the oamadmin user.
Click the System Configuration tab
Expand Agents -> OAM Agents -> 10g Agents.
Double click the Webgate you want to change.
Add the new server to either the Primary or Secondary server list by clicking the Add + symbol.
Select the server name from the list.
Click Apply.
In this case, you already have a node that runs a managed server configured with SOA components. The node contains a Middleware home, an Oracle home (SOA) and a domain directory for existing managed servers.
You can use the existing installations (the Middleware home, and domain directories) for creating new WLS_OIM and WLS_SOA servers. There is no need to install the Oracle Identity Manager and Oracle SOA Suite binaries in a new location, or to run pack and unpack.
Follow these steps for scaling up the topology:
Using the Administration Console, clone either the WLS_OIM1 or the WLS_SOA1 into a new managed server. The source managed server to clone should be one that already exists on the node where you want to run the new managed server.
To clone a managed server:
Select Environment -> Servers from the Administration Console.
Select the managed server that you want to clone (for example, WLS_OIM1 or WLS_SOA1).
Select Clone.
Name the new managed server WLS_OIMn or WLS_SOAn, where n is a number to identify the new managed server.
The rest of the steps assume that you are adding a new server to OIMHOST1, which is already running WLS_SOA1 and WLS_OIM1.
For the listen address, assign the host name or IP address to use for this new managed server. If you are planning to use server migration as recommended for this server, this should be the VIP (also called a floating IP) to enable it to move to another node. The VIP should be different from the one used by the managed server that is already running.
Create JMS Servers for SOA, OIM and UMS on the new managed server.
Use the Oracle WebLogic Server Administration Console to create a new persistent store for the new SOAJMSServer and name it, for example, SOAJMSFileStore_N. Specify the path for the store. This should be a directory on shared storage, as recommended in Section 2.4, "Shared Storage and Recommended Directory Structure."
Note:
This directory must exist before the managed server is started or the start operation fails.
ORACLE_BASE/admin/DOMAIN_NAME/cluster_name/jms/SOAJMSFileStore_N
Create a new JMS server for SOA, for example, SOAJMSServer_N. Use the SOAJMSFileStore_N for this JMSServer. Target the SOAJMSServer_N server to the recently created managed server ( WLS_SOAn).
Create a new persistence store for the new UMSJMSServer, for example, UMSJMSFileStore_N Specify the path for the store. This should be a directory on shared storage as recommended in Section 2.4, "Shared Storage and Recommended Directory Structure."
ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_N.
Note:
This directory must exist before the managed server is started or the start operation fails. You can also assignSOAJMSFileStore_N as store for the new UMS JMS servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.Create a new JMS Server for UMS, for example, UMSJMSServer_N. Use the UMSJMSFileStore_N for this JMSServer. Target the UMSJMSServer_N server to the recently created Managed Server (WLS_SOAn).
Create a new persistence store for the new OIMJMSServer, for example, OIMJMSFileStore_N Specify the path for the store. This should be a directory on shared storage as recommended in Section 2.4, "Shared Storage and Recommended Directory Structure."
ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_N
Note:
This directory must exist before the managed server is started or the start operation fails. You can also assignSOAJMSFileStore_N as store for the new OIM JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.Create a new JMS Server for OIM, for example, OIMJMSServer_N. Use the OIMJMSFileStore_N for this JMSServer. Target the OIMJMSServer_N server to the recently created Managed Server (WLS_OIMn).
Update the SubDeployment targets for the SOA JMS Module to include the recently created SOA JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Oracle WebLogic Server Administration Console. The JMS Modules page appears. Click SOAJMSModule (represented as a hyperlink in the Names column of the table). The Settings page for SOAJMSModule appears. Click the SubDeployments tab. The subdeployment module for SOAJMS appears.
Note:
This subdeployment module name is a random name in the form ofSOAJMSServerXXXXXX resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).Click the SOAJMSServerXXXXXX subdeployment. Add the new JMS Server for SOA called SOAJMSServer_N to this subdeployment. Click Save.
Update the SubDeployment targets for the UMSJMSSystemResource to include the recently created UMS JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Oracle WebLogic Server Administration Console. The JMS Modules page appears. Click UMSJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for UMSJMSSystemResource appears. Click the SubDeployments tab. The subdeployment module for UMSJMS appears.
Note:
This subdeployment module name is a random name in the form ofUCMJMSServerXXXXXX resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).Click the UMSJMSServerXXXXXX subdeployment. Add the new JMS Server for UMS called UMSJMSServer_N to this subdeployment. Click Save.
Update the SubDeployment targets for OIMJMSModule to include the recently created OIM JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Oracle WebLogic Server Administration Console. The JMS Modules page appears. Click OIMJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for OIMJMSSystemResource appears. Click the SubDeployments tab. The subdeployment module for OIMJMS appears.
Note:
This subdeployment module name is a random name in the form ofOIMJMSServerXXXXXX resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_OIM1 and WLS_OIM2).Click the OIMJMSServerXXXXXX subdeployment. Add the new JMS Server for OIM called OIMJMSServer_N to this subdeployment. Click Save.
Configure Oracle Coherence for deploying composites, as described in Section "Configuring Oracle Coherence for Deploying Composites."
Note:
Only the localhost field needs to be changed for the server. Replace the localhost with the listen address of the new server added, for example:Dtangosol.coherence.localhost=SOAHOST1VHNnConfigure TX persistent store for the new server. This should be a location visible from other nodes as indicated in the recommendations about shared storage.
From the Administration Console, select the Server_name > Services tab. Under Default Store, in Directory, enter the path to the folder where you want the default persistent store to store its data files.
Disable host name verification for the new managed server. Before starting and verifying the WLS_SOAn managed server, you must disable host name verification. You can re-enable it after you have configured server certificates for the communication between the Oracle WebLogic Administration Server and the Node Manager in SOAHOSTn. If the source server from which the new one has been cloned had already disabled hostname verification, these steps are not required (the hostname verification settings is propagated to the cloned server).
To disable host name verification:
In the Oracle Enterprise Manager Console, select Oracle WebLogic Server Administration Console.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page appears.
Select WLS_SOAn in the Names column of the table. The Settings page for the server appears.
Click the SSL tab.
Click Advanced.
Set Hostname Verification to None.
Click Save.
Start and test the new managed server from the Administration Console.
Shut down the existing managed servers in the cluster.
Ensure that the newly created managed server, WLS_SOAn, is up.
Access the application on the newly created managed server (http://vip:port/soa-infra). The application should be functional.
Test server migration for this new server. Follow these steps from the node where you added the new server:
Stop the WLS_SOAn managed server.
To do this, run:
kill -9 pid
on the process ID (PID) of the managed server. You can identify the PID of the node using
ps -ef | grep WLS_SOAn
Watch the Node Manager Console. You should see a message indicating that the floating IP address for WLS_SOA1 has been disabled.
Wait for the Node Manager to try a second restart of WLS_SOAn. Node Manager waits for a fence period of 30 seconds before trying this restart.
Once Node Manager restarts the server, stop it again. Now Node Manager should log a message indicating that the server will not be restarted again locally.
The web tier already has a node running an instance of the Oracle HTTP Server. The existing Oracle HTTP Server binaries can be used for creating the new Oracle HTTP Server instance. To scale up the Oracle HTTP Server, follow the steps in Chapter 5, "Configuring the Web Tier."
In addition copy any files created in ORACLE_INSTANCE/config/OHS/component/moduleconf from the existing web tier configuration to the new one.
Use the Oracle Fusion Middleware 11g Web Tier Utilities Configuration Wizard to scale up the topology. Run the config.sh script under the ORACLE_HOME/bin directory to bring up the configuration wizard and follow the remaining steps to create a new instance of the Oracle HTTP Server.
Reconfigure the load balancer with the host and port information of the new Oracle HTTP Server instance.
In scaling out a topology, new servers are added to new nodes. The components in all three tiers of the Oracle Identity Management topology described in this manual can be scaled out by adding a new server instance to a new node.
The directory tier consists of the two Oracle Internet Directory nodes (OIDHOST1 and OIDHOST2), each running an Oracle Internet Directory instance and the two Oracle Virtual Directory nodes (OVDHOST1 and OVDHOST2), each running an Oracle Virtual Directory instance. The Oracle Internet Directory or Oracle Virtual Directory instances can be scaled out by adding new nodes to the directory tier.
The directory tier has two Oracle Internet Directory nodes (OIDHOST1 and OIDHOST2), each running an Oracle Internet Directory instance. The OID instances can be scaled out by adding a new node to the existing Oracle Internet Directory cluster. To scale out Oracle Internet Directory instances, follow these steps:
Follow the steps in Section 7.2.2, "Configuring an Additional Oracle Internet Directory Instance" to add a new node running Oracle Internet Directory.
Follow the steps in Section 7.3.1, "Registering Oracle Internet Directory with the Oracle WebLogic Server Domain" to register the new Oracle Internet Directory instance with the WebLogic domain.
Reconfigure the load balancer with the host and port information of the new Oracle Internet Directory instance.
The directory tier has two nodes (OVDHOST1 and OVDHOST2), each running an Oracle Virtual Directory instance. Oracle Virtual Directory can be scaled out by adding a new node configured to run Oracle Virtual Directory to the directory tier. To scale out Oracle Virtual Directory instances, follow these steps:
Follow the steps in Section 8.2.2, "Configuring an Additional Oracle Virtual Directory" to add a new node running Oracle Virtual Directory.
Follow the steps in Section 8.3.1, "Registering Oracle Virtual Directory with the Oracle WebLogic Server Domain" to register the new Oracle Virtual Directory instance with the WebLogic domain.
Reconfigure the load balancer with the host and port information of the new Oracle Virtual Directory instance.
The application tier has two nodes (IDMHOST1 and IDMHOST2) running Managed Servers for Oracle Directory Integration Platform and Oracle Directory Services Manager, two nodes (OAMHOST1 and OAMHOST2) running the Oracle Access Manager Identity Server and Access Server, and an Administration node (OAMADMINHOST) running an instance of the Oracle Access Manager WebPass, Policy Manager, WebGate and Oracle HTTP Server.
The application tier has two nodes (IDMHOST1 and IDMHOST2) running a Managed Server configured with Oracle Directory Integration Platform and Oracle Directory Services Manager. The Oracle Directory Integration Platform and Oracle Directory Services Manager instances can be scaled out by adding a new node with a Managed Server to the existing cluster. To scale out DIP and ODSM instances, follow the steps below:
Follow the steps in Section 9.2, "Expanding the Oracle Directory Integration Platform and ODSM Cluster" to scale out the Oracle Directory Integration Platform and Oracle Directory Services Manager instances in the topology.
Reconfigure the Oracle HTTP Server module with the new Managed Server. See ???? for the instructions to complete this task.
With Oracle Access Manager, the new server instances need to be installed under a separate ORACLE_HOME location. Sharing ORACLE_HOMEs between instances of Oracle Access Manager components is not supported.
To scale out the Access Server, follow the instructions in Section 10.4.2.2, "Starting the Access Server Installation."
To scale out the WebPass, follow the instructions in Section 10.3.3, "Installing WebPass on OAMADMINHOST."
To scale out the WebGate, follow the instructions in Section 10.4.3, "Installing WebGate on OAMADMINHOST, WEBHOST1, and WEBHOST2."
Scale out is very similar to scale up but first requires the software to be installed on the new node.
Install Oracle WebLogic Server on the new host as described in Section 4.5.3, "Installing Oracle WebLogic Server."
Install Oracle Fusion Middleware Identity Management components on the new host as described in Section 4.5.4, "Installing the Oracle Identity Management Platform and Directory Services Suite."
Log in to the Oracle WebLogic Server Administration Console at http://admin.mycompany.com/console.
From the Domain Structure window of the Oracle WebLogic Server Administration Console, expand the Environment node and then Servers. The Summary of Servers page appears.
Click Lock & Edit from the Change Center menu.
Select an existing server on the host you want to extend, for example: WLS_OAM1.
Click Clone.
Enter the following information:
Server Name: A new name for the server, for example: WLS_OAM3.
Server Listen Address: The name of the host on which the managed server will run.
Server Listen Port: The port the new managed server will use. This port must be unique within the host.
Click OK.
Click the newly created server WLS_OAM3.
Set the SSL listen port. This should be unique on the host that the managed server will run on.
Click Save.
Disable host name verification for the new managed server. Before starting and verifying the WLS_OAM3 managed server, you must disable host name verification. You can re-enable it after you have configured server certificates for the communication between the Oracle WebLogic Administration Server and the Node Manager in IDMHOSTn.
If the source server from which the new one was cloned had already disabled hostname verification, these steps are not required, as the hostname verification settings was propagated to the cloned server. To disable host name verification, proceed as follows:
In Oracle Enterprise Manager Fusion Middleware Control, select Oracle WebLogic Server Administration Console.
Expand the Environment node in the Domain Structure pane.
Click Servers. The Summary of Servers page appears.
Select WLS_OAM3 in the Names column of the table. The Settings page for server appears.
Click the SSL tab.
Click Advanced.
Set Hostname Verification to None.
Click Save.
Click Activate Configuration from the Change Center menu.
Pack the domain on IDMHOST1 using the command:
pack.sh -domain=ORACLE_BASE/admin/IDMDomain/aserver/IDMDomain -template =/tmp/IDMDomain.jar -template_name="OAM Domain" -managed=true
The pack.sh script is located in MW_HOME/oracle_common/common/bin.
Unpack the domain on the new host using the command:
unpack.sh -domain=ORACLE_BASE/admin/IDMDomain/mserver/IDMDomain -template=/tmp/IDMDomain.jar -template_name="OAM Domain" -app_dir=ORACLE_BASE/admin/IDMDomain/mserver/applications
The unpack.sh script is located in MW_HOME/oracle_common/common/bin.
Before you can start managed servers from the console, you must create a node manager properties file on IDMHOST3. You do this by running the script setNMProps.sh, which is located in MW_HOME/oracle_common/common/bin. Type:
MW_HOME/oracle_common/common/bin/setNMProps.sh
Register the new managed server with OAM. The new managed server now needs to be configured as an OAM server. You do this from the Oracle OAM console, as follows:
Log in to the OAM console at http://admin.mycompany.com/oamconsole as the oamadmin user.
Click the System Configuration tab.
Click Server Instances.
Select Create from the Actions menu.
Enter the following information:
Server Name: WLS_OAM3
Host: Host that the server will be running on, IDMHOST3.
Port: Listen port that was assigned when the managed server was created.
OAM Proxy Port: Port you want the OAM proxy to run on. This is unique for the host.
Proxy Server ID: AccessServerConfigProxy
Mode: Open
Click Apply.
You can now start the Access Server. In order for the server to be used, however, you must inform any Webgates of its existence. You do that as follows:
Log in to the OAM console at http://admin.mycompany.com/oamconsole as the oamadmin user.
Click the System Configuration tab.
Expand Agents -> OAM Agents ->10g Agents.
Double click the Webgate you want to change.
Add the new server to either the primary or secondary server list by clicking the Add [+] icon.
Select the server name from the list.
Click Apply.
Update the Web Tier. Now that the new managed server has been created and started, the web tier will start to direct requests to it. Best practice, however, is to inform the web server that the new managed server has been created.
You do this by updating the file OAM.conf on each of the web tiers. This file resides in the directory: ORACLE_INSTANCE/config/OHS/component name/moduleconf.
Add the new server to the WebLogicCluster directive in the file, for example, change:
<Location /OAM_admin>
SetHandler weblogic-handler
WebLogicCluster
OAMhost1.mycompany.com:14200,OAMhost2.mycompany.com:14200
</Location>
to:
<Location /OAM_admin>
SetHandler weblogic-handler
WebLogicCluster
OAMhost1.mycompany.com:14200,OAMhost2.mycompany.com:14200,OAMhsot3.mycompany.com:14300
</Location>
Scale out is very similar to scale up, but first requires the software to be installed on the new node. Proceed as follows:
Install Oracle WebLogic Server on the new host as described in Section 4.5.3, "Installing Oracle WebLogic Server."
Install Oracle Fusion Middleware Identity Management components on the new host as described in Section 4.5.4, "Installing the Oracle Identity Management Platform and Directory Services Suite."
Log in to the WebLogic console at http://admin.mycompany.com/console.
From the Domain Structure pane of the Oracle WebLogic Server Administration Console, expand the Environment node and then Servers. The Summary of Servers page appears.
Click Lock & Edit from the Change Center menu.
Select an existing server on the host you want to extend, for example: WLS_OAAM1 or WLS_OAAM_ADMIN1.
Click Clone.
Enter the following information:
Server Name: A new name for the server, for example: WLS_OAAM3
Server Listen Address: The name of the host on which the managed server will run.
Server Listen Port: The port the new managed server will use. This port must be unique within the host.
Click OK.
Click the newly-created server WLS_OAAM3.
Set the SSL listen port. This should be unique on the host that the managed server will be running on.
Click Save.
Disable host name verification for the new managed server. Before starting and verifying the WLS_OAAM3 managed server, you must disable host name verification. You can re-enable it after you have configured server certificates for the communication between the Oracle WebLogic Administration Server and the Node Manager in OAAMHOSTn.
If the source server from which the new one was cloned had already disabled hostname verification, these steps are not required, as the hostname verification settings were propagated to the cloned server. To disable host name verification:
In the Oracle Fusion Middleware Enterprise Manager Console, select Oracle WebLogic Server Administration Console.
Expand the Environment node in the Domain Structure pane.
Click Servers. The Summary of Servers page appears.
Select WLS_OAAM3 in the Names column of the table. The Settings page for server appears.
Click the SSL tab.
Click Advanced.
Set Hostname Verification to None.
Click Save.
Click Activate configuration from the Change Center menu.
Pack the domain on IDMHOST1 using the command:
pack.sh -domain=ORACLE_BASE/admin/IDMDomain/aserver/IDMDomain -template =/tmp/IDMDomain.jar -template_name="OAAM Domain" -managed=true
The pack.sh script is located in MW_HOME/oracle_common/common/bin.
Unpack the domain on the new host using the command:
unpack.sh -domain=ORACLE_BASE/admin/IDMDomain/mserver/IDMDomain -template=/tmp/IDMDomain.jar -template_name="OAAM Domain" -app_dir=ORACLE_BASE/admin/IDMDomain/mserver/applications
The unpack.sh script is located in MW_HOME/oracle_common/common/bin.
Before you can start managed servers from the console, you must create a node manager properties file on OAAMHOST2 by running the script setNMProps.sh. The setNMProps.sh script is located in MW_HOME/oracle_common/common/bin. Type:
OAAMHOST2> $MW_HOME/oracle_common/common/bin/setNMProps.sh
Start Node Manager and the new managed server on the new host
Now that the new managed server has been created and started, the web tier will start to direct requests to it. Best practice, however, is to inform the web server that the new managed server has been created.
You do this by updating the file oaam.conf on each of the web tiers. This file resides in the directory: ORACLE_INSTANCE/config/OHS/component_name/moduleconf.
Add the new server to the WebLogicCluster directive in the file. For example, change:
<Location /oaam_admin>
SetHandler weblogic-handler
WebLogicCluster oaamhost1.mycompany.com:14200,oaamhost2.mycompany.com:14200
</Location>
to:
<Location /oaam_admin>
SetHandler weblogic-handler
WebLogicCluster
oaamhost1.mycompany.com:14200,oaamhost2.mycompany.com:14200,oaamhsot3.mycompany.com:14300
</Location>
When you scale out the topology, you add new managed servers configured with SOA to new nodes.
Before performing the steps in this section, check that you meet these requirements:
There must be existing nodes running managed servers configured with SOA within the topology.
The new node can access the existing home directories for WebLogic Server and SOA.
Use the existing installations in shared storage for creating a new WLS_SOA or WLS_WSM managed server. You do not need to install WebLogic Server or SOA binaries in a new location but you do need to run pack and unpack to bootstrap the domain configuration in the new node.
Notes:
If there is no existing installation in shared storage, installing WebLogic Server and SOA in the new nodes is required as described in Section xxx, "Configuring High Availability for Oracle SOA Service Infrastructure and Component Service Engines.
When an ORACLE_HOME or WL_HOME is shared by multiple servers in different nodes, Oracle recommends keeping the Oracle Inventory and Middleware home list in those nodes updated for consistency in the installations and application of patches. To update the oraInventory in a node and "attach" an installation in a shared storage to it, use:
ORACLE_HOME/oui/bin/attachHome.sh
To update the Middleware home list to add or remove a WL_HOME, edit the user_home/bea/beahomelist file. See the following steps.
Follow these steps for scaling out the topology:
On the new node, mount the existing Middleware home, which should include the SOA installation and the domain directory, and ensure that the new node has access to this directory, just like the rest of the nodes in the domain.
To attach ORACLE_HOME in shared storage to the local Oracle Inventory, execute the following command:
SOAHOSTn> cd ORACLE_BASE/product/fmw/soa/ SOAHOSTn> ./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_17_R28.0.0-655
To update the Middleware home list, create (or edit, if another WebLogic installation exists in the node) the MW_HOME/bea/beahomelist file and add ORACLE_BASE/product/fmw to it.
Log in to the Oracle WebLogic Administration Console.
Create a new machine for the new node that will be used, and add the machine to the domain.
Update the machine's Node Manager's address to map the IP address of the node that is being used for scale out.
Use the Oracle WebLogic Server Administration Console to clone WLS_SOA1 into a new managed server. Name it WLS_SOAn, where n is a number.
Note:
These steps assume that you are adding a new server to node n, where no managed server was running previously.Assign the host name or IP address to use for the new managed server for the listen address of the managed server.
If you are planning to use server migration for this server (which Oracle recommends) this should be the VIP address (also called a floating IP address) for the server. This VIP address should be different from the one used for the existing managed server.
Create JMS servers for SOA, OIM (if applicable), and UMS on the new managed server.
Use the Oracle WebLogic Server Administration Console to create a new persistent store for the new SOAJMSServer and name it, for example, SOAJMSFileStore_N. Specify the path for the store. This should be a directory on shared storage as recommended in Section 2.4, "Shared Storage and Recommended Directory Structure." For example:
ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_N
Note:
This directory must exist before the managed server is started or the start operation fails.Create a new JMS Server for SOA, for example, SOAJMSServer_N. Use the SOAJMSFileStore_N for this JMSServer. Target the SOAJMSServer_N Server to the recently created managed server (WLS_SOAn).
Create a new persistence store for the new UMSJMSServer, and name it, for example, UMSJMSFileStore_N. Specify the path for the store. This should be a directory on shared storage as recommended in Section 2.4, "Shared Storage and Recommended Directory Structure."
ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore _N
Notes:
This directory must exist before the managed server is started or the start operation fails.
It is also possible to assign SOAJMSFileStore_N as the store for the new UMS JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.
Create a new JMS server for UMS: for example, UMSJMSServer_N. Use the UMSJMSFileStore_N for this JMS server. Target the UMSJMSServer_N server to the recently created managed server (WLS_SOAn).
Create a new persistence store for the new OIMJMSServer, and name it, for example, OIMJMSFileStore_N. Specify the path for the store. This should be a directory on shared storage as recommended in Section 2.4, "Shared Storage and Recommended Directory Structure."
ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_N
Notes:
This directory must exist before the managed server is started or the start operation fails.
It is also possible to assign SOAJMSFileStore_N as the store for the new OIM JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.
Create a new JMS Server for OIM: for example, OIMJMSServer_N. Use the OIMJMSFileStore_N for this JMS Server. Target the OIMJMSServer_N Server to the recently created managed server (WLS_SOAn).
Update the SubDeployment targets for the SOA JMS Module to include the recently created SOA JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Oracle WebLogic Server Administration Console. The JMS Modules page appears. Click SOAJMSModule (represented as a hyperlink in the Names column of the table). The Settings page for SOAJMSModule appears. Open the SubDeployments tab. The subdeployment module for SOAJMS appears.
Note:
This subdeployment module name is a random name in the form ofSOAJMSServer resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).Click the SOAJMSServerXXXXXX subdeployment. Add the new JMS Server for SOA called SOAJMSServer_N to this subdeployment. Click Save.
Update the SubDeployment targets for UMSJMSSystemResource to include the recently created UMS JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Oracle WebLogic Server Administration Console. The JMS Modules page appears. Click UMSJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for UMSJMSSystemResource appears. Open the SubDeployments tab. The subdeployment module for UMSJMS appears
Note:
This subdeployment module is a random name in the form ofUMSJMSServerXXXXXX resulting from the Config Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).Click the UMSJMSServerXXXXXX subdeployment. Add the new JMS Server for UMS called UMSJMSServer_N to this subdeployment. Click Save.
Update the SubDeployment Targets for OIMJMSModule to include the recently created OIM JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Oracle WebLogic Server Administration Console. The JMS Modules page appears. Click OIMJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for OIMJMSSystemResource appears. Click the SubDeployments tab. The subdeployment module for OIMJMS appears.
Note:
This subdeployment module is a random name in the form ofOIMJMSServerXXXXXX resulting from the Config Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).Click the OIMJMSXXXXXX subdeployment. Add the new JMS Server for OIM called OIMJMSServer_N to this subdeployment. Click Save.
Run the pack command on SOAHOST1 to create a template pack as follows:
SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
SOAHOST1> ./pack.sh -managed=true -domain=MW_HOME/user_projects/domains/soadomain/ -template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale
Run the following command on SOAHOST1 to copy the template file created to SOAHOSTN:
SOAHOST1> scp soadomaintemplateScale.jar oracle@SOAHOSTN:/ ORACLE_BASE/product/fmw/soa/common/bin
Run the unpack command on SOAHOSTN to unpack the template in the managed server domain directory as follows:
SOAHOSTN> cd ORACLE_BASE/product/fmw/soa/common/bin SOAHOSTN> ./unpack.sh -domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/ -template=soadomaintemplateScale.jar
Configure Oracle Coherence for deploying composites, as described in Section xxxx, "Configuring Oracle Coherence for Deploying Composites."
Note:
Only thelocalhost field needs to be changed for the server. Replace the localhost with the listen address of the new server added, for example: Dtangosol.coherence.localhost=SOAHOSTnVHN1Configure TX persistent store for the new server. This should be a location visible from other nodes as indicated in the recommendations about shared storage.
From the Administration Console, select Server_name > Services tab. Under Default Store, in Directory, enter the path to the folder where you want the default persistent store to store its data files.
Disable host name verification for the new managed server. Before starting and verifying the WLS_SOAn managed server, you must disable host name verification. You can re-enable it after you have configured server certificates for the communication between the Oracle WebLogic Administration Server and the Node Manager in SOAHOSTn. If the source server from which the new one has been cloned had already disabled hostname verification, these steps are not required (the hostname verification setting is propagated to the cloned server).
To disable host name verification:
Expand the Environment node in the Domain Structure window.
In the Oracle Enterprise Manager Console, select Oracle WebLogic Server Administration Console.
Click Servers. The Summary of Servers page appears.
Select WLS_SOAn in the Names column of the table.
The Settings page for server appears.
Click the SSL tab.
Click Advanced.
Set Hostname Verification to None.
Click Save.
Start the Node Manager on the new node. To start the Node Manager, use the installation in shared storage from the existing nodes, and start Node Manager by passing the host name of the new node as a parameter as follows:
SOAHOSTN> WL_HOME/server/bin/startNodeManager new_node_ip
Start and test the new managed server from the Oracle WebLogic Server Administration Console:
Shut down all the existing managed servers in the cluster.
Ensure that the newly created managed server, WLS_SOAn, is running.
Access the application on the newly created managed server (http://vip:port/soa-infra). The application should be functional.
Configure server migration for the new managed server.
Note:
Since this new node is using an existing shared storage installation, the node is already using a Node Manager and an environment configured for server migration that includes netmask, interface,wlsifconfig script superuser privileges. The floating IP address for the new SOA Managed Server is already present in the new node.Configure server migration following these steps:
Log into the Administration Console.
In the left pane, expand Environment and select Servers.
Select the server (represented as hyperlink) for which you want to configure migration from the Names column of the table. The Setting page for that server appears.
Click the Migration tab.
In the Available field, in the Migration Configuration section, select the machines to which to allow migration and click the right arrow.
Note:
Specify the least-loaded machine as the migration target for the new server. The required capacity planning must be completed so that this node has enough available resources to sustain an additional managed server.Select the Automatic Server Migration Enabled option. This enables the Node Manager to start a failed server on the target node automatically.
Click Save.
Restart the Administration Server, managed servers, and Node Manager.
Test server migration for this new server. Follow these steps from the node where you added the new server:
1. Abruptly stop the WLS_SOAn managed server.
2. To do this, run:
kill -9 pid
on the (PID) of the managed server. You can identify the PID of the node using:
ps -ef | grep WLS_SOAn
3. Watch the Node Manager Console. You should see a message indicating that floating IP address for WLS_SOA1 has been disabled.
4. Wait for the Node Manager to try a second restart of WLS_SOAn. Node Manager waits for a fence period of 30 seconds before trying this restart.
5. Once Node Manager restarts the server, stop it again. Now Node Manager should log a message indicating that the server will not be restarted again locally.
The web tier has two nodes each running an instance of the Oracle HTTP Server. The Oracle HTTP Server components can be scaled out by adding a new node configured to run Oracle HTTP Server to the web tier. To scale out Oracle HTTP Server, follow the steps in these sections:
Section 4.4, "Installing Oracle HTTP Server on WEBHOST1 and WEBHOST2."
Copy any files created in ORACLE_INSTANCE/config/OHS/component/moduleconf from the existing web tier configuration to the new one.
Table 18-1 shows the static artifacts to back up in the 11g Oracle Identity Management enterprise deployment.
Table 18-1 Static Artifacts to Back Up in the Identity Management Enterprise Deployment
| Type | Host | Location | Tier |
|---|---|---|---|
|
Oracle Home (database) |
RAC database hosts: INFRADBHOST1 INFRADBHOST2 |
User Defined |
Directory Tier |
|
MW_HOME (OID) |
OIDHOST1 OIDHOST2 |
MW HOME:
ORACLE HOME:
|
Directory Tier |
|
MW_HOME (OVD) |
OVDHOST1 OVDHOST2 |
MW HOME:
ORACLE HOME:
|
Directory Tier |
|
MW_HOME (DIP, ODSM, Admin Server) |
IDMHOST1 IDMHOST2 |
FMW HOME:
DIP/ODSM ORACLE HOME:
ADMIN SERVER ORACLE HOME:
|
Application Tier |
|
MW_HOME (OHS) |
WEBHOST1 WEBHOST2 |
MW HOME:
ORACLE HOME:
ORACLE HOME:
|
Web Tier |
|
OAMADMINHOST (used for OAM administration) |
OAMADMINHOST |
MW HOME:
OHS ORACLE HOME:
WEBPASS HOME:
POLICY MANAGER HOME:
WEBGATE HOME:
|
Application Tier |
|
OAM |
OAMHOST1 OAMHOST2 |
ORACLE ACCESS MANAGER HOME:
IDENTITY SERVER HOME:
ACCESS SERVER HOME:
|
Application Tier |
|
Install Related Files |
Each host |
OraInventory:
Windows registry: (HKEY_LOCAL/MACHINE/Oracle) |
Not applicable. |
Table 18-2 shows the runtime artifacts to back up in the 11g Oracle Identity Management enterprise deployment:
Table 18-2 Runtime Artifacts to Back Up in the Identity Management Enterprise Deployments
| Type | Host | Location | Tier |
|---|---|---|---|
|
DOMAIN HOME |
IDMHOST1 IDMHOST2 |
|
Application Tier |
|
Application Artifacts (ear and war files) |
IDMHOST1 IDMHOST2 |
Look at all the deployments, including Oracle Directory Integration Platform and Oracle Directory Services Manager, through the WebLogic Server Administration Console to identity all the application artifacts. |
Application Tier |
|
INSTANCE HOME (OHS) |
WEBHOST1 WEBHOST2 |
OHS INSTANCE HOME on WEBHOST1:
OHS INSTANCE HOME on WEBHOST2:
|
Web Tier |
|
INSTANCE HOME (OHS) |
OAMADMINHOST |
OHS INSTANCE HOME on WEBHOST1: /u01/app/oracle/admin/ohs_inst/oamAdmin_ohs |
Application Tier |
|
OID INSTANCE HOME |
OIDHOST1 OIDHOST2 |
OID INSTANCE HOME on OIDHOST1: /u01/app/oracle/admin/oid_inst1
OID INSTANCE HOME on OIDHOST2: /u01/app/oracle/admin/oid_inst2 |
Directory Tier |
|
OVD INSTANCE HOME |
OVDHOST1 OVDHOST2 |
OVD INSTANCE HOME on OVDHOST1:
OVD INSTANCE HOME on OVDHOST2:
|
Directory Tier |
|
RAC Databases |
INFRADBHOST1 INFRADBHOST2 |
User defined |
Directory Tier |
|
OAM |
OAMHOST1 OAMHOST2 OAMADMINHOST |
All the configurations are within the respective home directories described in this table. There are no instance homes. |
Application Tier |
For more information on backup and recovery of Oracle Fusion Middleware components, see Oracle Fusion Middleware Administrator's Guide.
This section describes how to patch an Oracle Fusion Middleware patch file and how to patch Oracle Identity Management components with minimal down time.
For information on patching an Oracle Fusion Middleware source file, see the Oracle Fusion Middleware Administrator's Guide.
To patch Oracle Identity Management components with minimal down time, it is recommended that you follow these guidelines:
Route the LDAP traffic from OIDHOST1 and OVDHOST1 to OIDHOST2 and OVDHOST2.
Bring down the Oracle Internet Directory or Oracle Virtual Directory server on the host on which you are applying the patch (OIDHOST1 or OVDHOST1).
Apply the Oracle Internet Directory patch or Oracle Virtual Directory patch on the host.
Start the Oracle Internet Directory or Oracle Virtual Directory server on the host.
Test the patch.
Route the traffic to OIDHOST1 or OVDHOST1 again.
Verify the applications are working properly.
Route the LDAP traffic on OIDHOST2 and OVDHOST2 to OIDHOST1 and OVDHOST1.
Bring down the Oracle Internet Directory or Oracle Virtual Directory server on the host on which you are applying the patch (OIDHOST2 or OVDHOST2).
Apply the Oracle Internet Directory patch or Oracle Virtual Directory patch on the host.
Start the Oracle Internet Directory or Oracle Virtual Directory server on the host.
Test the patch.
Route the traffic to both hosts on which the patch has been applied (OIDHOST1 and OIDHOST2, or OVDHOST1 and OVDHOST2).
This section describes how to troubleshoot common issues that can arise with the Identity Management enterprise deployment described in this manual.
This section describes some of the common problems that can arise with Oracle Internet Directory and the actions you can take to resolve the problem.
The Oracle Internet Directory server is not responsive. When the load balancing router is configured to send an ICMP message to the LDAP SSL port for monitoring, the Oracle Internet Directory server starting SSL negotiation sometimes hangs, and thus it is required that the load balancing router not use ICMP messages for monitoring the LDAP SSL port.
Use an alternative such as TCP or the LDAP protocol itself.
Also, monitoring the LDAP non-SSL port is sufficient to detect LDAP availability.
The SSO/LDAP Application connection is lost to Oracle Internet Directory server
Verify the load balancing router timeout and SSO/Application timeout configuration parameter. The SSO/LDAP application timeout value should be less than LBR IDLE time out.
The LDAP application is receiving LDAP Error 53 (DSA Unwilling to Perform). When one of the database nodes goes down during the middle of the LDAP transaction, the Oracle Internet Directory server sends error 53 to the LDAP client
To see why the Oracle Internet Directory database node went down, see the Oracle Internet Directory logs in this location:
ORACLE_INSTANCE/diagnostics/logs/OID/oidldapd01s*.log
Issues involving TNSNAMES.ORA, TAF configuration, and related issues.
See the Oracle Database High Availability Overview manual.
This section describes some of the common problems that can arise with Oracle Virtual Directory and the actions you can take to resolve the problem:
The Oracle Virtual Directory server is not responsive. When the load balancing router is configured to send an ICMP message to the LDAP SSL port for monitoring, the Oracle Virtual Directory server starting SSL negotiation sometimes hangs, and thus it is required that the load balancing router not use ICMP messages for monitoring the LDAP SSL port.
Use an alternative such as TCP or the LDAP protocol itself.
Also, monitoring the LDAP non-SSL port is sufficient to detect LDAP availability.
The SSO/LDAP Application connection is lost to the Oracle Virtual Directory server.
Verify the load balancing router timeout and SSO/Application timeout configuration parameter. The SSO/LDAP application timeout value should be less than LBR IDLE time out.
Issues involving TNSNAMES.ORA, TAF configuration, and related issues.
See the Oracle Database High Availability Overview manual.
This section describes some of the common problems that can arise with Oracle Directory Integration Platform and the actions you can take to resolve the problem.
The instance is not working properly.
Check the respective log of the instance. For example, if the instance deployed in wls_ods1 is not running, then check the wls_ods1-diagnostic.log file.
Exceptions similar to the following are seen in Managed Server log files running the Oracle Directory Integration Platform application during a RAC failover:
RuntimeException:
[2008-11-21T00:11:10.915-08:00] [wls_ods] [ERROR] []
[org.quartz.impl.jdbcjobstore.JobStoreTX] [tid: 25] [userId: <anonymous>]
[ecid: 0000Hqy69UiFW7V6u3FCEH199aj0000009,0] [APP: DIP] ClusterManager: Error
managing cluster: Failed to obtain DB connection from data source
'schedulerDS': java.sql.SQLException: Could not retrieve datasource via JNDI
url 'jdbc/schedulerDS' java.sql.SQLException: Cannot obtain connection:
driverURL = jdbc:weblogic:pool:schedulerDS, props =
{EmulateTwoPhaseCommit=false, connectionPoolID=schedulerDS,
jdbcTxDataSource=true, LoggingLastResource=false,
dataSourceName=schedulerDS}.[[
Nested Exception: java.lang.RuntimeException: Failed to setAutoCommit to true
for pool connection
AuthenticationException while connecting to OID:
[2008-11-21T00:12:08.812-08:00] [wls_ods] [ERROR] [DIP-10581] [oracle.dip]
[tid: 11] [userId: <anonymous>] [ecid: 0000Hqy6m54FW7V6u3FCEH199apO000000,0]
[APP: DIP] DIP was not able to get the context with the given details {0}[[
javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid
Credentials]
Most of the exceptions will be related to the scheduler or LDAP, for example:
1. Could not retrieve datasource via JNDI url 'jdbc/schedulerDS' java.sql.SQLException.
2. javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials]
During a RAC failover, exceptions are seen in the Managed Server log files running the Oracle Directory Integration Platform application. These errors are thrown when the multi data sources configured on the WebLogic Server platform try to verify the health of the RAC database instances during failover. These are innocuous errors and can be ignored. The Oracle Directory Integration Platform application will recover and begin to operate normally after a lag of one or two minutes. For a RAC failover, there will be no Oracle Directory Integration Platform down time if one instance is running at all times.
This section describes some of the common problems that can arise with Oracle Directory Services Manager and the actions you can take to resolve the problem.
After you have logged into Oracle Directory Services Manager, you can connect to multiple directory instances from the same browser window.
Avoid using multiple windows of the same browser program to connect to different directories at the same time. Doing so can cause a Target unreachable error.
You can log into the same Oracle Directory Services Manager instance from different browser programs, such as Internet Explorer and Firefox, and connect each to a different directory instance.
If you change the browser language setting, you must update the session in order to use the new setting. To update the session, either disconnect the current server connection, refresh the browser page (either reenter the Oracle Directory Services Manager URL in the URL filed and press enter or press F5) and reconnect to the same server, or quit and restart the browser.
You attempt to invoke Oracle Directory Services Manager from Oracle Enterprise Manager Fusion Middleware Control by selecting Directory Services Manager from the Oracle Internet Directory menu in the Oracle Internet Directory target, then Data Browser, Schema, Security, or Advanced.
Oracle Directory Services Manager does not open. You might see an error message.
This is probably an installation problem. See Oracle Fusion Middleware Installation Guide for Oracle Identity Management.
When you perform an Oracle Directory Services Manager failover using Oracle HTTP Server, the failover is not transparent. You will see this behavior when you perform the following steps:
Oracle Directory Services Manager is deployed in a High Availability active-active configuration using Oracle HTTP Server.
Display an Oracle Directory Services Manager page using the Oracle HTTP Server name and port number.
Make a connection to an Oracle Internet Directory server.
Work with the Oracle Internet Directory server using the current Oracle Directory Services Manager Oracle HTTP Server host and port.
Shut down one Managed Server at a time using the WebLogic Server Administration Console.
Go back to the Oracle Directory Services Manager page and port, and the connection which was established earlier with Oracle Internet Directory.
When you do, a message is displayed advising you to re-establish a new connection to the Oracle Directory Services Manager page.
If you encounter this problem, perform the following steps:
In your web browser, exit the current Oracle Directory Services Manager page.
Launch a new web browser page and specify the same Oracle Directory Services Manager Oracle HTTP Server name and port.
Re-establish a new connection to the Oracle Internet Directory server you were working with earlier.
Oracle Directory Services Manager temporarily loses its connection to Oracle Internet Directory and displays the message LDAP Server is down.
In a High Availability configuration where Oracle Directory Services Manager is connected to Oracle Internet Directory through a load balancer, Oracle Directory Services Manager reports that the server is down during failover from one instance of Oracle Internet Directory to another. In other configurations, this message might indicate that Oracle Internet Directory has been shut down and restarted. In either case, the connection will be reestablished in less than a minute, and you will be able to continue without logging in again.
Oracle Directory Services Manager temporarily loses its connection to an Oracle Internet Directory instance that is using a RAC database. Oracle Directory Services Manager might display the message
LDAP error code 53 - Function not implemented.
This error can occur during failover of the Oracle Database that the Oracle Internet Directory instance is using. The connection will be reestablished in less than a minute, and you will be able to continue without logging in again.
You must perform the steps below to configure Oracle HTTP Server to route Oracle Directory Services Manager requests to multiple Oracle WebLogic Servers in a clustered Oracle WebLogic Server environment.
Perform these steps:
Create a backup copy of the Oracle HTTP Server's httpd.conf file. The backup copy will provide a source to revert back to if you encounter problems after performing this procedure.
Add the following text to the end of the Oracle HTTP Server's httpd.conf file and replace the variable placeholder values with the host names and Managed Server port numbers specific to your environment. Be sure to use the <Location /odsm/ > as the first line in the entry. Using <Location /odsm/faces > or <Location /odsm/faces/odsm.jspx > can distort the appearance of the Oracle Directory Services Manager interface.
<Location /odsm/ >
SetHandler weblogic-handler
WebLogicCluster host-name-1:managed-server-port,host-name_2:managed_server_port
</Location>
Stop, then start the Oracle HTTP Server as described in Section 18.1, "Starting and Stopping Oracle Identity Management Components" to activate the configuration change.
Note:
Oracle Directory Services Manager loses its connection and displays a session time-out message if the Oracle WebLogic Server in the cluster that it is connected to fails. Oracle Directory Services Manager requests will be routed to the secondary Oracle WebLogic Server in the cluster that you identified in the httpd.conf file after you log back in to Oracle Directory Services Manager.Attempting to access Oracle Directory Services Manager using a web browser fails.
Verify the Oracle Virtual Directory server is running. The Oracle Virtual Directory server must be running to connect to it from Oracle Directory Services Manager.
Verify you entered the correct credentials in the Server, Port, User Name and Password fields. You can execute an ldapbind command against the target Oracle Virtual Directory server to verify the server, user name, and password credentials.
Verify you are using a supported browser. Oracle Directory Services Manager supports the following browsers:
Internet Explorer 7
Firefox 2.0.0.2 and 3.0
Safari 3.1.2 (desktop)
Google Chrome 0.2.149.30
Note:
While Oracle Directory Services Manager supports all of the preceding browsers, only Internet Explorer 7 and Firefox 2.0.0.2 are certified.Oracle Directory Services Manager does not open after you attempt to invoke it from Oracle Enterprise Manager Fusion Middleware Control by selecting one of the options from the Directory Services Manager entry in the Oracle Virtual Directory menu in the Oracle Virtual Directory target.
This is probably an installation problem. See the Oracle Fusion Middleware Installation Guide for Oracle Identity Management.
When you perform an Oracle Directory Services Manager failover using Oracle HTTP Server, the failover is not transparent. You will see this behavior when you perform the following steps:
Oracle Directory Services Manager is deployed in a High Availability active-active configuration using Oracle HTTP Server.
Display an Oracle Directory Services Manager page using the Oracle HTTP Server name and port number.
Make a connection to an Oracle Virtual Directory server.
Work with the Oracle Virtual Directory server using the current Oracle Directory Services Manager Oracle HTTP Server host and port.
Shut down one Managed Server at a time using the WebLogic Server Administration Console.
Go back to the Oracle Directory Services Manager page and port, and the connection which was established earlier with Oracle Virtual Directory. When you do, a message is displayed advising you to re-establish a new connection to the Oracle Directory Services Manager page.
If you encounter this problem, perform the following steps:
In your web browser, exit the current Oracle Directory Services Manager page.
Launch a new web browser page and specify the same Oracle Directory Services Manager Oracle HTTP Server name and port.
Re-establish a new connection to the Oracle Virtual Directory server you were working with earlier.
Oracle Directory Services Manager temporarily loses its connection to an Oracle Virtual Directory instance that is using an Oracle RAC Database. Oracle Directory Services Manager might display the message LDAP error code 53 - Function not implemented.
This error can occur during failover of the Oracle Database that the Oracle Virtual Directory instance is using. The connection will be reestablished in less than a minute, and you will be able to continue without logging in again.
Most of the manuals in the Oracle Access Manager 10.1.4.3 documentation set include a Troubleshooting appendix.
For troubleshooting information about a particular Oracle Access Manager component or feature, refer to the appropriate manual in the Oracle Access Manager 10.1.4.3 documentation set. See the "Road Map to Manuals" section in the Oracle Access Manager Introduction manual for a description of each manual in the Oracle Access Manager documentation set.
After configuring Oracle HTTP Server and the load balancing router to access the Oracle WebLogic Administration console, some activation changes cause redirection to the login screen for the WebLogic Server Administration Console.
This is the result of the Administration Console tracking changes made to ports, channels, and security settings made using the Administration Console. For certain changes the Console may redirect the user's browser to the Administration Server's listen address. Activation is completed regardless of the redirection. It is not required to log in again; users can simply update the URL to the following and then access the Home page for the Administration Console directly:
admin.mycompany.com/console/console.portal
After configuring Oracle Access Manager, some activation changes cause redirection to the Administration Console Home page (instead of the context menu where the activation was performed).
This is expected when Oracle Access Manager single sign-on is configured and is a result of the redirections performed by the Administration Server. Activation is completed regardless of the redirection. If required, user should manually navigate again to the desired context menu.
If the policy domain has an invalid or incorrect URL, running the OAM Configuration Tool with the correct URLs will not update the Policy Manager, even though the tool completes successfully.
The OAM Configuration Tool adds new URLs to an existing policy domain when run using an existing app_domain name. It does not remove any of the existing URLs. The Policy Manager Console must be used to remove any invalid URLs. Follow these steps to update the URLs in an existing policy domain:
Access the Policy Manager Console using the following URL:
http://hostname:port/access/oblix
For example, enter the following URL in your web browser:
http://oamadminhost.mycompany.com:7777/access/oblix
When prompted, log in using the administrator user credentials.
On the landing page, click the Policy Manager link.
On the Policy Manager Console, click the My Policy Domains link.
On the My Policy Domains page, click the link for the appropriate policy domain.
On the Policy Domain page, select the Resources tab.
On the Resources page, select the valid or incorrect URLs and delete them.
This section describes some other recommendations for the Oracle Identity Management enterprise deployment.
Most of the production deployment involves firewalls. Because database connections are made across firewalls, Oracle recommends that the firewall be configured so that the database connection is not timed out. For Oracle Real Application Clusters (RAC), the database connections are made on Oracle RAC VIPs and the database listener port. You must configure the firewall so it does not time out these connections. If such a configuration is not possible, set the SQLNET.EXPIRE_TIME=n parameter in the ORACLE_HOME/network/admin/sqlnet.ora file on the database server, where n is the time in minutes. Set this value to less than the known value of the timeout for the network device (that is, a firewall). For RAC, set this parameter in all of the Oracle home directories.