The reference enterprise topology discussed in this guide is highly scalable. It can be scaled up and or scaled out. This chapter explains how to do so.
To scale up the topology, you add a new component instance to a node already running one or more component instances. To scale out the topology, you add new component instances to new nodes.
This chapter contains the following topics:
The Oracle Identity and Access Management topology described in the guide has three tiers: the Directory Tier, Application Tier and Web Tier. The components in all three tiers of the Oracle Identity and Access Management topology described in this guide can be scaled up or scaled out.
In this release, the Identity and Access Management Deployment tool cannot be used to scale out or scale up components. Scaling up or out is a manual process, as described in this chapter.
You scale up a topology by adding a new server instance to a node that already has one or more server instances running. You scale out a topology by adding new components to new nodes.
Scale the LDAP Directory as follows.
Oracle Binaries are shared among the LDAP hosts. When scaling out, you must mount the shared binary directory onto the new host.To do this, perform the steps in Section 5.7, "Mounting Shared Storage onto the Host."
The binaries for Oracle Unified Directory are located in IDM_TOP, which is shared among the LDAPHOSTs. When scaling out Oracle Unified Directory to a new host, ensure that this directory is mounted to the new host. See Section 5.7, "Mounting Shared Storage onto the Host."
The directory tier has two Oracle Unified Directory nodes, LDAPHOST1 and LDAPHOST2, each running an Oracle Unified Directory instance. The Oracle Unified Directory binaries on either node can be used for creating the new Oracle Unified Directory instance.
Proceed as follows:
Assemble information, as listed in Section 14.2.2.1, "Assembling Information for Scaling Oracle Unified Directory."
If scaling out, mount the shared storage onto the new LDAPHOST.
Follow the steps in Section 14.2.2.2, "Configuring an Additional Oracle Unified Directory Instance."
Follow the steps in Section 14.2.2.3, "Validating the New Oracle Unified Directory Instance."
Follow the steps in Section 14.2.2.4, "Adding the New Oracle Unified Directory Instance to the Load Balancers."
Reconfigure the load balancer with the host and port information of the new Oracle Unified Directory instance, as described in Section 14.4.5, "Reconfiguring the Load Balancer."
Assemble the following information before scaling Oracle Unified Directory.
| Description | Variable | Documented Value | Customer Value |
|---|---|---|---|
|
New Oracle Unified Directory Host Name |
|
LDAPHOST3.mycompany.com |
|
|
Oracle Unified Directory Listen Port |
|
1389 |
|
|
Oracle Unified Directory SSL Port |
|
1636 |
|
|
Oracle Unified Directory Administration Port |
|
4444 |
|
|
Oracle Unified Directory Replication Port |
|
8989 |
|
|
Oracle Instance Location |
|
|
|
|
Oracle Unified Directory Existing Instance/Component Name |
|
|
|
|
Newly Created Instance/Component Name |
|
|
|
|
Oracle Unified Directory Administrator Password |
|
||
|
Common Password |
|
If you are scaling out to another machine, you can use ports 1389 (LDAP_PORT), 1636 (LDAP_SSL_PORT), 4444 (LDAP_ADMIN_PORT), and 8989. If you are scaling up, those ports are already in use and you must choose unique ports. Ensure that the ports you plan to use are not in use by any service on the computer by issuing these commands for the operating system you are using. If a port is not in use, no output is returned from the command.
netstat -an | grep "1389"
If the ports are in use (that is, if the command returns output identifying either port), you must free the port.
Remove the entries for the ports you freed from the /etc/services file and restart the services or restart the computer.
Set the environment variable JAVA_HOME
Set the environment variable INSTANCE_NAME to a new instance value, such as: ../../../../u02/private/oracle/config/instances/oud3
Note the tool creates the instance home relative to the OUD_ORACLE_HOME, so you must include previous directories to get the instance created in OUD_ORACLE_INSTANCE.
Change Directory to OUD_ORACLE_HOME
Start the Oracle Unified Directory configuration assistant by executing the command:
./oud-setup
On the Welcome screen, click Next.
On the Server Settings screen, enter:
Host Name: The name of the host where Oracle Unified Directory is running, for example: LDAPHOST3
LDAP Listener Port: 1389 (LDAP_PORT) if scaling out, unique port if scaling up.
Administration Connector Port: 4444 (LDAP_ADMIN_PORT)
LDAP Secure Access
Click Configure
Select SSL Access
Enable SSL on Port: 1636 (LDAP_SSL_PORT)
Certificate: Generate Self Signed Certificate OR provide details of your own certificate.
Click OK
Root User DN: Enter an administrative user for example cn=oudadmin
Password: Enter the password you want to assign to the ouadmin user. Using the COMMON_IDM_PASSWORD is recommended.
Password (Confirm): Repeat the password.
Click Next.
On the Topology Options screen, enter
This server will be part of a replication topology
Replication Port: (LDAP_REPLIC_PORT) 8989
Select Configure As Secure, if you want replication traffic to be encrypted.
There is already a server in the topology: Selected.
Enter the following:
Host Name: The name of the Oracle Unified Directory server host for this instance, for example: LDAPHOST1.mycompany.com
Administrator Connector Port: 4444 (LDAP_ADMIN_PORT)
Admin User: Name of the Oracle Unified Directory administrative user on LDAPHOST1, for example: cn=oudadmin
Admin Password: Administrator password. Using the COMMON_IDM_PASSWORD is recommended.
Click Next.
If you see a certificate Not Trusted Dialogue, it is because you are using self signed certificates. Click Accept Permanently.
Click Next.
On The Create Global Administrator Screen Enter:
Global Administrator ID: The name of an account you want to use for managing Oracle Unified Directory replication, for example: oudmanager
Global Administrator Password / Confirmation: Enter a password for this account. Using the COMMON_IDM_PASSWORD is recommended.
Click Next.
On the Data Replication Screen. select dc=mycompany,dc=com and click Next.
On the Oracle Components Integration screen, click Next.
On the Runtime Options Screen Click Next.
On the Review Screen, check that the information displayed is correct and click Finish.
On the Finished screen, click Close.
After configuration, you can validate that Oracle Unified Directory is working by performing a simple search. To do this issue the following command:
OUD_ORACLE_INSTANCE/OUD/bin/ldapsearch -h LDAPHOST3.mycompany.com -p 1389 -D cn=oudadmin -b "" -s base "(objectclass=*)" supportedControl
If Oracle Unified Directory is working correctly, you will see a list supportedControl entries returned.
Add the new Oracle Unified Directory instance to the existing server pool defined on the load balancer for distributing requests across the instances.
The Application Tier has two nodes (OAMHOST1 and OAMHOST2) running Managed Servers for Oracle Access Management Access Manager, and two nodes (OIMHOST1 and OIMHOST2) running Managed Servers for Oracle Identity Manager. Optionally, the Application Tier might have two nodes (OAMHOST1 and OAMHOST2) running Managed Servers for Oracle Adaptive Access Manager.
This section contains the following topics:
Section 14.3.2, "Mounting Middleware Home and Creating a New Machine when Scaling Out."
Section 14.3.3, "Creating a New Node Manager when Scaling Out."
Section 14.3.6, "Adding New WebLogic Managed Server to Oracle HTTP Server Configuration Files."
Use the following tables to assemble the values you need.
Assemble the following information before scaling Access Manager.
| Description | Variable | Documented Value | Customer Value |
|---|---|---|---|
|
Host Name |
|
||
|
Existing Access Manager server |
|
||
|
New Access Manager server name |
|
|
|
|
Server Listen Port |
|
14100 |
|
|
WebLogic Administration Host |
|
IADADMINVHN.mycompany.com |
|
|
WebLogic Administration Port |
|
7001 |
|
|
WebLogic Administration User |
weblogic_idm |
||
|
WebLogic Administration Password |
| Description | Variable | Documented Value | Customer Value |
|---|---|---|---|
|
Host name |
|
||
|
SOA virtual server name |
SOAHOSTxVHN |
||
|
Oracle Identity Manager virtual server name |
OIMHOSTxVHN |
||
|
Existing SOA managed server to clone |
|
|
|
|
Existing Oracle Identity Manager managed server to clone |
|
|
|
|
New SOA managed server name |
|
|
|
|
New Oracle Identity Manager managed server name |
|
|
|
|
Numeric extension for new JMS servers |
|
3 |
|
|
WebLogic Administration Host |
|
IGDADMINVHN.mycompany.com |
|
|
WebLogic Administration Port |
|
7101 |
|
|
WebLogic Administration User |
weblogic_idm |
||
|
WebLogic Administration Password |
Assemble the following information before scaling Oracle Adaptive Access Manager.
| Description | Variable | Documented Value | Customer Value |
|---|---|---|---|
|
Host Name |
|
||
|
Existing OAAM server |
|
||
|
New OAAM server name |
|
|
|
|
Server Listen Address |
|||
|
OAAM Managed Server Port |
|
14200 |
|
|
OAAM Administration Managed Server Port |
|
14300 |
|
|
WebLogic Administration Host |
|
IADADMINVHN.mycompany.comFoot 1 |
|
|
WebLogic Administration Port |
|
7001 |
|
|
WebLogic Administration User |
weblogic_idm |
||
|
WebLogic Administration Password |
Footnote 1 This refers to the domain that you are scaling.
Before scaling out a component of the OAM application tier, mount the Middleware home and create a new machine.
To mount the Middleware home and create a new machine:
On the new node, mount the existing Middleware home, which should include the Oracle Fusion Middleware 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. See Section 5.7, "Mounting Shared Storage onto the Host." for more information.
To attach IAD_ORACLE_HOME in shared storage to the local Oracle Inventory, execute the following command:
cd IAD_ORACLE_HOME/oui/bin ./attachHome.sh -jreLoc JAVA_HOME
Note:
This section uses IAD_ORACLE_HOME as an example. Use the same procedure for IGD_ORACLE_HOME.
To update the Middleware home list, create (or edit, if another WebLogic installation exists in the node) the HOME/bea/beahomelist file and add IAD_MW_HOME/oui/bin to it.
Log in to the WebLogic Administration Console for the IAMAccessDomain at the address listed in Section 15.2, "About Identity and Access Management Console URLs."
Create a new machine for the new node to be used, and add the machine to the domain, as follows.
Select Environment -> Machines from the Navigation menu.
Click Lock and Edit.
Click New on the Machine Summary screen.
Enter the following information:
Name: Name of the machine (NEWHOSTn)
Machine OS: Select UNIX.
Click Next.
On the Node Manager Properties page, enter the following information:
Type: SSL.
Listen Address: NEWHOSTn.
Click Finish.
Click Activate Changes.
Node Manager is used to start and stop WebLogic managed servers on the new host. In order to create a new node manager for the new host perform the following steps:
Create a new directory for the new node manager by copying an existing one. Copy the directory SHARED_CONFIG/nodemanager/oamhost1.mycompany.com to: SHARED_CONFIG/nodemanager/newiamhost.mycompany.com
For example:
cp -r $SHARED_CONFIG/nodemanager/oamhost1.mycompany.com $SHARED_CONFIG/nodemanager/newiamhost.mycompany.com
Change to the newly created directory.
cd SHARED_CONFIG/nodemanager/NEWHOST3.mycompany.com
Edit the nodemanager.properties file, changing all the entries for OAMHOST1 to OAMHOST3. For example:
DomainsFile=/u01/oracle/config/nodemanager/OAMHOST1.mycompany.com/nodemanager.domain
becomes
DomainsFile=/u01/oracle/config/nodemanager/NEWHOST3.mycompany.com/nodemanager.domain
Edit the startNodeManagerWrapper.sh file, changing all the entries for OAMHOST1 to OAMHOST3. For example:
NM_HOME=/u01/oracle/config/nodemanager/oamhost1.mycompany.com
becomes
NM_HOME=/u01/oracle/config/nodemanager/oamhost3.mycompany.com
Start the node manager by invoking the command:
./startNodeManagerWrapper.sh
Update the node manager configuration by following the steps in Chapter 14, "Updating Node Manager Configuration" to ensure that certificates are created for the new host.
Whenever you extend a domain to include a new managed server, you must extract the domain configuration needs from the ASERVER_HOME location to the MSERVER_HOME location. This applies whether you are scaling up or out. To do this perform the following steps.
Note:
The following steps are an example of packing and unpacking the IAMAccessDomain
Pack the domain on the host where the administration server is located, for example: OAMHOST1:
pack.sh -domain=IAD_ASERVER_HOME -template =/templates/managedServer.jar -template_name="template_name" -managed=true
The pack.sh script is located in ORACLE_COMMON_HOME/common/bin.
Unpack the domain on the new host for scale out, or on the existing host for scale up, using the command:
unpack.sh -domain=IAD_MSERVER_HOME -template=/templates/managedServer.jar -app_dir=IAD_MSERVER_HOME/applications
The unpack.sh script is located in ORACLE_COMMON_HOME/common/bin.
If you are scaling out, start Node Manager and update the property file.
Start and stop Node Manager as described in Section 15.1, "Starting and Stopping Components."
Run the script setNMProps.sh, which is located in ORACLE_COMMON_HOME/common/bin, to update the node manager properties file, for example:
cd ORACLE_COMMON_HOME/common/bin
./setNMProps.sh
Start Node Manager once again as described in Section 15.1, "Starting and Stopping Components."
This section contains the following topics:
Section 14.3.5.2, "Scaling Oracle Access Management Access Manager."
Section 14.3.5.2, "Scaling Oracle Access Management Access Manager."
Section 14.3.5.4, "Updating Oracle Adaptive Access Manager Integration"
Create a new managed server by cloning an existing managed server of the same type. To scale out/up Access Manager, clone wls_oam1. Similarly, to scale out/up Identity Manager, clone wls_oim1.
The following example is for cloning an Access Manager managed server, although the procedure is the same for all products.
Log in to the Oracle WebLogic Administration Console for the domain whose managed server you are cloning, at the address listed in Section 15.2, "About Identity and Access Management Console URLs." For this example the domain is IAMAccessDomain.
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 runs.
Server Listen Port: The port the new Managed Server uses. This port must be unique within the host.
If you are scaling out, you can use the default port, 14100 (OAM_PORT in Table 7–1). If you are scaling up, choose a unique port.
Click OK.
Click the newly created server WLS_OAM3
Set Machine to be the machine you created in Section 14.3.2, "Mounting Middleware Home and Creating a New Machine when Scaling Out""
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 NEWHOST.
If the source server from which the new one was cloned had already disabled host name verification, these steps are not required, as the host name 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 Changes from the Change Center menu.
This section contains steps specific to scaling Access Manager.
Note:
If you are using shared storage, allow the new host access to that shared storage area.
Scale Oracle Access Management Access Manager by performing the steps in the following subsections:
Run pack and unpack as described in Section 15.3.4, "Running Pack/Unpack."
Register the new Managed Server with Oracle Access Management Access Manager. You now must configure the new Managed Server now as an Access Manager server. You do this from the Oracle Access Management Console. Proceed as follows:
Log in to the Access Management console at http://IADADMIN.mycompany.com/oamconsole as the user identified by the entry in Section 8.9, "Set User Names and Passwords"
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 runs on
Port: Listen port that was assigned when the Managed Server was created
OAM Proxy Port: Port you want the Access Manager proxy to run on. This is unique for the host
Proxy Server ID: AccessServerConfigProxy
Mode: Set to same mode as existing Access Manager servers.
Click Coherence tab.
Set Local Port to a unique value on the host.
Click Apply.
Restart the WebLogic Administration Server as described in Section 15.1, "Starting and Stopping Components"
Add the newly created Access Manager server to all WebGate Profiles that might be using it, such as Webgate_IDM, Webgate_IDM_11g, and IAMSuiteAgent
For example, to add the Access Manager server to Webgate_IDM, access the Access Management console at: http://IADADMIN.mycompany.com/oamconsole
Then proceed as follows:
Log in as the Access Manager Administrative User.
Click the System Configuration tab.
Expand Access Manager Settings - SSO Agents - OAM Agents.
Click the open folder icon, then click Search.
You should see the WebGate agent Webgate_IDM.
Click the agent Webgate_IDM.
Select Edit from the Actions menu.
Click + in the Primary Server list (or the Secondary Server list if this is a secondary server).
Select the newly created managed server from the Server list.
Set Maximum Number of Connections to 10.
Click Apply.
Repeat Steps 5 through 10 for Webgate_IDM_11g, IAMSuiteAgent, and all other WebGates that might be in use.
You can now start the new Managed Server, as described in Section 15.1, "Starting and Stopping Components"
Add the newly added Managed Server host name and port to the list WebLogicCluster parameter, as described in Section 14.3.6, "Adding New WebLogic Managed Server to Oracle HTTP Server Configuration Files"
Save the file and restart the Oracle HTTP server, as described in Section 15.1, "Starting and Stopping Components"
You already have a node that runs a Managed Server configured with Oracle SOA Suite and Oracle Identity Manager components. The node contains a Middleware home, a SOA Oracle home, an Oracle Identity Manager Oracle home, and a domain directory for existing Managed Servers. Use the existing installations in shared storage for creating a new WLS_SOA and WLS_OIM managed server. There is no need to install the Oracle Identity and Access Management or Oracle SOA Suite binaries in a new location
When scaling up, you add WLS_SOA and WLS_OIM managed servers to existing nodes.
In either case, you must run pack and unpack.
When you scale out the topology, you add new Managed Servers configured with Oracle Identity Manager and SOA to new nodes. First check that the new node can access the existing home directories for WebLogic Server, Oracle Identity Manager, and SOA. You do need to run pack and unpack to bootstrap the domain configuration in the new node.
Follow the steps in the following subsections to scale the topology:
Section 14.3.5.3.2, "Performing Pack/Unpack When Scaling Out"
Section 14.3.5.3.3, "Configuring Oracle Coherence for Deploying Composites"
Section 14.3.5.3.4, "Enabling Communication for Deployment Using Unicast Communication"
Section 14.3.5.3.5, "Specifying the Host Name Used by Oracle Coherence"
Section 14.3.5.3.6, "Completing the Oracle Identity Manager Configuration Steps"
Create JMS Servers for SOA, Oracle Identity Manager, UMS, and BPM on the new Managed Server. You do this as follows:
Log in to the WebLogic Administration Server in the IAMGovernanceDomain, as described in Section 15.2, "About Identity and Access Management Console URLs," and navigate to Services -> Messaging -> JMS Servers.
Click New.
Enter a value for Name, such as BPMJMSServer_auto_3.
Click Create New Store.
Select FileStore from the list
Click Next.
Enter a value for Name, such as BPMJMSFileStore_auto_3
Enter the following values:
Target: The new server you are creating.
Directory: IGD_ASERVER_HOME/jms/BPMJMSFileStore_auto_3
Click OK.
When you are returned to the JMS Server screen, select the newly created file store from the list.
Click Next.
On the next screen set the Target to the server you are creating.
Click Finish.
Create the following JMS Queues depending on the managed server you are creating:
| Server | JMS Server Name | File Store Name | Directory | Target |
|---|---|---|---|---|
|
WLS_SOAn |
BPMJMSServer_auto_n |
BPMJMSFileStore_auto_n |
|
WLS_SOAn |
|
WLS_SOAn |
SOAJMSServer_auto_n |
SOAJMSFileStore_auto_n |
|
WLS_SOAn |
|
WLS_SOAn |
UMSJMSServer_auto_n |
UMSJMSFileStore_auto_n |
|
WLS_SOAn |
|
WLS_OIMn |
JRFWSAsyncJmsServer_auto_n |
JRFWSAsyncFileStore_auto_n |
|
WLS_OIMn |
|
WLS_OIMn |
OIMJMSServer_auto_n |
OIMJMSFileStore_auto_n |
|
wls_OIMn |
|
WLS_SOAn |
PS6SOAJMSServer_auto_n |
PS6SOAJMSFileStore_auto_n |
|
wls_SOAn |
Add the newly created JMS Queues to the existing JMS Modules by performing the following steps:
Log in to the WebLogic Administration Console in the IAMGovernanceDomain, at the address listed in Section 15.2, "About Identity and Access Management Console URLs."
Navigate to Services -> Messaging -> JMS Modules
Click a JMSModule, such as SOAJMSModule
Click the Sub Deployments tab.
Click the listed sub deployment.
Note:
This subdeployment module name is a random name in the form of JMSServerNameXXXXXX resulting from the Configuration Wizard JMS configuration.
Assign the newly created JMS server, for example SOAJMSServer_auton.
Click Save.
Perform this for each of the JMS modules listed in the following table:
| JMS Module | JMS Server |
|---|---|
|
BPMJMSModule |
BPMJMSServer_auto_n |
|
JRFWSAsyncJmsModule |
JRFWSAsyncJmServer_auto_n |
|
OIMJMSModule |
OIMJMSServer_auto_n |
|
SOAJMSModule |
SOAJMSServer_auto_n |
|
UMSJMSSystemResource |
UMSJMSServe_auto_n |
Click Activate Configuration from the Change Center menu.
This section is necessary only when you are scaling out.
Run pack and unpack as described in Section 14.3.4, "Running Pack/Unpack"
Although deploying composites uses multicast communication by default, Oracle recommends using unicast communication in SOA enterprise deployments. Use unicast if you disable multicast communication for security reasons.
Unicast communication does not enable nodes to discover other cluster members in this way. Consequently, you must specify the nodes that belong to the cluster. You do not need to specify all of the nodes of a cluster, however. You need only specify enough nodes so that a new node added to the cluster can discover one of the existing nodes. As a result, when a new node has joined the cluster, it is able to discover all of the other nodes in the cluster. Additionally, in configurations such as SOA enterprise deployments where multiple IPs are available in the same system, you must configure Oracle Coherence to use a specific host name to create the Oracle Coherence cluster.
Note:
An incorrect configuration of the Oracle Coherence framework used for deployment may prevent the SOA system from starting. The deployment framework must be properly customized for the network environment on which the SOA system runs. Oracle recommends the configuration described in this section.
Specify the nodes using the tangosol.coherence.wkan system property, where n is a number between 1 and 9. You can specify up to 9 nodes. Start the numbering at 1. This numbering must be sequential and must not contain gaps. In addition, specify the host name used by Oracle Coherence to create a cluster through the tangosol.coherence.localhost system property. This local host name should be the virtual host name used by the SOA server as the listener addresses, for example: SOAHOST3VHN. Set this property by adding the -Dtangosol.coherence.localhost parameters to the Arguments field of the Oracle WebLogic Server Administration Console's Server Start tab. You will also need to add the new server to the existing entries.
Tip:
To guarantee high availability during deployments of SOA composites, specify enough nodes so that at least one of them is running at any given time.
Note:
SOAHOST3VHN is the virtual host name that maps to the virtual IP where WLS_SOA3 listening (in SOAHOST3).
Use the Administration Console to specify a host name used by Oracle Coherence.
To add the host name used by Oracle Coherence:
Log into the Oracle WebLogic Server Administration Console.
In the Domain Structure window, expand the Environment node.
Click Servers. The Summary of Servers page appears.
Click the name of the server (WLS_SOA1 or WLS_SOA2, which are represented as hyperlinks) in Name column of the table. The settings page for the selected server appears.
Click Lock & Edit.
Click the Server Start tab.
Enter the following for WLS_SOA1, WLS_SOA2, and WLS_SOA3 into the Arguments field.
For WLS_SOA1, enter the following:
-Dtangosol.coherence.wka1=SOAHOST1VHN -Dtangosol.coherence.wka2=SOAHOST2VHN -Dtangosol.coherence.wka3=SOAHOST3VHN -Dtangosol.coherence.localhost=SOAHOST1VHN
For WLS_SOA2, enter the following:
-Dtangosol.coherence.wka1=SOAHOST1VHN -Dtangosol.coherence.wka2=SOAHOST2VHN -Dtangosol.coherence.wka3=SOAHOST3VHN -Dtangosol.coherence.localhost=SOAHOST2VHN
For WLS_SOA3, enter the following:
-Dtangosol.coherence.wka1=SOAHOST1VHN -Dtangosol.coherence.wka2=SOAHOST2VHN -Dtangosol.coherence.wka3=SOAHOST3VHN -Dtangosol.coherence.localhost=SOAHOST3VHN
Note:
There should be no breaks in lines between the different -D parameters. Do not copy or paste the text to your Administration Console's arguments text field. It may result in HTML tags being inserted in the Java arguments. The text should not contain other text characters than those included the example above.
Note:
The Coherence cluster used for deployment uses port 8088 by default. This port can be changed by specifying a different port (for example, 8089) with the -Dtangosol.coherence.wkan.port and -Dtangosol.coherence.localport startup parameters. For example:
WLS_SOA1 (enter the following into the Arguments field on a single line, without a carriage return):
-Dtangosol.coherence.wka1=SOAHOST1VHN -Dtangosol.coherence.wka2=SOAHOST2VHN -Dtangosol.coherence.wka3=SOAHOST3VHN -Dtangosol.coherence.localhost=SOAHOST1VHN -Dtangosol.coherence.localport=8089 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089 -Dtangosol.coherence.wka3.port=8089
WLS_SOA2 (enter the following into the Arguments field on a single line, without a carriage return):
-Dtangosol.coherence.wka1=SOAHOST1VHN -Dtangosol.coherence.wka2=SOAHOST2VHN -Dtangosol.coherence.wka3=SOAHOST3VHN -Dtangosol.coherence.localhost=SOAHOST2VHN -Dtangosol.coherence.localport=8089 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089 -Dtangosol.coherence.wka3.port=8089
WLS_SOA3 (enter the following into the Arguments field on a single line, without a carriage return):
-Dtangosol.coherence.wka1=SOAHOST1VHN -Dtangosol.coherence.wka2=SOAHOST2VHN -Dtangosol.coherence.wka3=SOAHOST3VHN -Dtangosol.coherence.localhost=SOAHOST3VHN -Dtangosol.coherence.localport=8089 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089 -Dtangosol.coherence.wka3.port=8089
For more information about Coherence Clusters see the Oracle Coherence Developer's Guide.
Click Save and Activate Changes.
Note:
You must ensure that these variables are passed to the managed server correctly. (They should be reflected in the server's output log.) Failure of the Oracle Coherence framework can prevent the soa-infra application from starting.
Note:
The multicast and unicast addresses are different from the ones used by the WebLogic Server cluster for cluster communication. SOA guarantees that composites are deployed to members of a single WebLogic Server cluster even though the communication protocol for the two entities (the WebLogic Server cluster and the groups to which composites are deployed) are different.
Configure 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 WebLogic 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 OIMHOSTn. If the source server from which the new one has been cloned had already disabled host name verification, these steps are not required (the host name 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.
Repeat Steps 6a through 6h to disable host name verification for the WLS_OIMn Managed Servers. In Step d, select WLS_OIMn in the Names column of the table.
Click Activate Changes from the Change Center menu.
Restart the WebLogic Administration Server as described in Section 15.1, "Starting and Stopping Components"
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.
Configure the newly created managed server for server migration. Follow the steps in Section 13.6, "Configuring Server Migration Targets"to configure server migration.
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 addresses for the new Managed Servers are already present in the new node.
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.
Repeat Steps a-d for WLS_OIMn.
If you have extended your domain with Oracle Adaptive Access Manager and have integrated Oracle Identity Manager with Oracle Adaptive Access Manager, you must update Oracle Adaptive Access Manager so that it is aware of the new Oracle Identity Manager server. See Section 12.13.3, "Setting Oracle Adaptive Access Manager Properties for Oracle Identity Manager" for details.
Scaling an Application Tier component typically requires you to create a new WebLogic managed server. If you add a new managed server to your topology, after adding the managed server you must update your Oracle HTTP Server configuration files (on all nodes) and add the new server to the existing WebLogic cluster directives.
In the Web tier, there are several configuration files under WEB_ORACLE_INSTANCE/config/OHS/componentname/moduleconf, including admin_vh.conf, sso_vh.conf and idminternal_vh.conf. Each contain a number of entries in location blocks. If a block references two server instances and you add a third one, you must update that block with the new server.
For example if you add a new Access Manager server, you must update sso_vh.conf to include the new managed server. You add the new server to the WebLogicCluster directive in the file, for example, change:
<Location /oam> SetHandler weblogic-handler WebLogicCluster OAMHOST1.mycompany.com:14100,OAMHOST2.mycompany.com:14100 </Location> <Location /oamfed> SetHandler weblogic-handler WebLogicCluster OAMHOST1.mycompany.com:14100,OAMHOST2.mycompany.com:14100 </Location>
to:
<Location /oam>
SetHandler weblogic-handler
WebLogicCluster OAMHOST1.mycompany.com:14100,OAMHOST2.mycompany.com:14100,OAMHOST1.mycompany.com:14101
</Location>
<Location /oamfed>
SetHandler weblogic-handler
WebLogicCluster OAMHOST1.mycompany.com:14100,OAMHOST2.mycompany.com:14100,OAMHOST3.mycompany.com:14100
</Location>
Once you have updated the configuration file, restart the Oracle HTTP server(s) as described in Section 15.1, "Starting and Stopping Components." Oracle recommends that you do this sequentially to prevent loss of service.
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 the Oracle HTTP Server, perform the steps in the following subsections:
Section 14.4.1, "Assembling Information for Scaling the Web Tier."
Section 14.4.2, "Mounting Middleware Home and Copying Oracle HTTP Server Files when Scaling Out."
Section 14.4.3, "Running the Configuration Wizard to Configure the HTTP Server."
Section 14.4.4, "Registering Oracle HTTP Server with WebLogic Server."
Assemble the following information before scaling the Web Tier.
| Description | Variable | Documented Value | Customer Value |
|---|---|---|---|
|
Host name |
WEBHOST1.mycompany.com |
||
|
OHS port |
|
7777 |
|
|
Instance Name |
|
|
|
|
Component Name |
|
|
|
|
WebLogic Administration Host, IAMAccessDomain |
|
IADADMINVHN.mycompany.com |
|
|
Access Management WLS Server Port |
|
7001 |
|
|
WebLogic Administrative User |
weblogic_idm |
||
|
WebLogic Administrative Password |
On the new node, mount the existing Middleware home.
Copy all files created in ORACLE_INSTANCE/config/OHS/component/moduleconf from the existing Web Tier configuration to the new one.
Perform these steps to configure the Oracle Web Tier:
Create a file containing the ports used by Oracle HTTP Server. On Disk1 of the installation media, locate the file stage/Response/staticports.ini. Copy it to a file called ohs_ports.ini. Delete all entries in ohs_ports.ini except for OHS PORT and OPMN Local Port. Change the value of OPMN Local Port to 6700. If you are scaling out, you can use the default value, 7777, for OHS PORT. If you are scaling up, you must choose a unique value for that instance on the machine.
Note:
If the port names in the file are slightly different from OHS PORT and OPMN Local Port, use the names in the file.
Change the directory to the location of the Oracle Fusion Middleware Configuration Wizard:
cd WEB_ORACLE_HOME/bin
Start the Configuration Wizard:
./config.sh
Enter the following information into the configuration wizard:
On the Welcome screen, click Next.
On the Configure Component screen, select: Oracle HTTP Server.
Ensure that Associate Selected Components with WebLogic Domain is selected.
Ensure Oracle Web Cache is NOT selected.
Click Next.
On the Specify WebLogic Domain Screen, enter
Domain Host Name: IADADMINVHN.mycompany.com
Domain Port No: 7001, where 7001 is IAD_WLS_PORT in Section 7.1, "Assembling Information for Identity and Access Management Deployment."
User Name: Weblogic Administrator User (For example: weblogic)
Password: Password for the Weblogic Administrator User account
Click Next.
On the Specify Component Details screen, specify the following values:
Enter the following values for WEBHOSTn, where n is the number of the new host, for example, 3:
Instance Home Location: WEB_ORACLE_INSTANCE, for example: /u02/local/oracle/config/instances/ohs1
Instance Name: webn
OHS Component Name: webn
Click Next.
On the Configure Ports screen, you use the ohs_ports.ini file you created in Step 1to specify the ports to be used. This enables you to bypass automatic port configuration.
Select Specify Ports using a Configuration File.
In the file name field specify ohs_ports.ini.
Click Save, then click Next.
On the Specify Security Updates screen, specify these values:
Email Address: The email address for your My Oracle Support account.
Oracle Support Password: The password for your My Oracle Support account.
Select: I wish to receive security updates via My Oracle Support.
Click Next.
On the Installation Summary screen, review the selections to ensure that they are correct. If they are not, click Back to modify selections on previous screens.
Click Configure.
On the Configuration screen, the wizard launches multiple configuration assistants. This process can be lengthy. When it completes, click Next.
On the Installation Complete screen, click Finish to confirm your choice to exit.
For Oracle Enterprise Manager Fusion Middleware Control to be able to manage and monitor the new Oracle HTTP server, you must register the Oracle HTTP server with IAMAccessDomain. To do this, register Oracle HTTP Server with WebLogic Server by running the following command on the host where the new server is running:
cd WEB_ORACLE_INSTANCE/bin ./opmnctl registerinstance -adminHost IADADMINVHN.mycompany.com \ -adminPort WLS_ADMIN_PORT -adminUsername weblogic
Add the new Oracle HTTP Server instance to the existing server pool defined on the load balancer for distributing requests across the HTTP instances.
Perform the following post-scaling steps.
During deployment, a topology store is created which contains details of the deployed topology. When patching the environment, the Lifecycle Tools read the store in order to build and execute the patch plan. If you scale out/up the topology you must add new entries to the store covering the new additions to the deployment.
To do this follow the steps in Appendix C, "Topology Tool Commands for Scaling."
Deployment creates a set of scripts to start and stop managed servers defined in the domain. When you create a new managed server in the domain you need to update the domain configuration so that these start and stop scripts can also start the newly created managed server.
To update the domain configuration, edit the file serverInstancesCustom.txt, which is located in the directory: SHARED_CONFIG/scripts
Update the node manager configuration, as described in the following sections:
If you want to start a node manager on a new machine, add an entry which looks like this:
newmachine.mycompany.com NM nodemanager_pathname nodemanager_port
For example:
OAMHOST3.mycompany.com NM /u01/oracle/config/nodemanager/oamhost3.mycompany.com 5556
If you want to start a managed server called WLS_OIM3 add an entry which looks like this:
newmachine.mycompany.com OIM ManagedServerName
For example:
OAMHOST3 OIM WLS_OIM3
Save the file.
If you added a new node manager, you must enable it for SSL as described in Section 14.5.3.2, "Setting Up Node Manager for an Enterprise Deployment."
This section describes how to configure Node Manager in accordance with Oracle best practice recommendations. It contains the following subsections:
Section 14.5.3.2.1, "Enabling Host Name Verification Certificates for Node Manager."
Section 14.5.3.2.2, "Generating Self-Signed Certificates Using the utils.CertGen Utility."
Section 14.5.3.2.3, "Creating an Identity Keystore Using the utils.ImportPrivateKey Utility."
Section 14.5.3.2.4, "Creating a Trust Keystore Using the Keytool Utility."
Section 14.5.3.2.5, "Configuring Node Manager to Use the Custom Keystores."
Section 14.5.3.2.6, "Configuring Managed WebLogic Servers to Use the Custom Keystores."
Section 14.5.3.2.7, "Changing the Host Name Verification Setting for the Managed Servers."
This section describes how to set up host name verification certificates for communication between Node Manager and the Administration Server.
The certificates added in this chapter (as an example) address a configuration where Node Manager listens on a physical host name (HOST.mycompany.com) and a WebLogic Managed Server listens on a virtual host name (VIP.mycompany.com). Whenever a server is using a virtual host name, it is implied that the server can be migrated from one node to another. Consequently, the directory where keystores and trust keystores are maintained ideally must reside on a shared storage that is accessible from the failover. If additional host names are used in the same or different nodes, the steps in this example must be extended to:
Add the required host names to the certificate stores (if they are different from HOST.mycompany.com and VIP.mycompany.com).
Change the identity and trust store location information for Node Manager (if the additional host names are used by Node Manager) or for the servers (if the additional host names are used by Managed Servers).
Follow these steps to create self-signed certificates on HOST. These certificates should be created using the network name or alias. For information on using trust CA certificates instead, see "Configuring Identity and Trust" in Oracle Fusion Middleware Securing Oracle WebLogic Server. The following examples configure certificates for HOST.mycompany.com and VIP.mycompany.com; that is, it is assumed that both a physical host name (HOST) and a virtual host name (VIP) are used in HOST. It is also assumed that HOST.mycompany.com is the address used by Node Manager and VIP.mycompany.com is the address used by a Managed Server or the Administration Server. This is the common situation for nodes hosting an Administration Server and a Fusion Middleware component, or for nodes where two Managed Servers coexist with one server listening on the physical host name and one server using a virtual host name (which is the case for servers that use migration servers).
Set up your environment by running the WL_HOME/server/bin/setWLSEnv.sh script. In the Bourne shell, run the following commands:
cd WL_HOME/server/bin
. ./setWLSEnv.sh
Verify that the CLASSPATH environment variable is set:
echo $CLASSPATH
Create a user-defined directory for the certificates. For example, create a directory called 'keystores' under the ASERVER_HOME directory. Note that certificates can be shared across WebLogic domains.
cd SHARED_CONFIG
mkdir keystores
Note:
The directory where keystores and trust keystores are maintained must be on shared storage that is accessible from all nodes so that when the servers fail over (manually or with server migration), the appropriate certificates can be accessed from the failover node. Oracle recommends using central or shared stores for the certificates used for different purposes (like SSL set up for HTTP invocations, for example).
Change directory to the directory that you just created:
cd keystores
Using the utils.CerGen tool, create certificates for each Physical and Virtual Host in the topology.
Syntax (all on a single line):
java utils.CertGen Key_Passphrase Cert_File_Name Key_File_Name [export | domestic] [Host_Name]
Examples are:
java utils.CertGen Key_Passphrase NEWHOST.mycompany.com_cert NEWHOST.mycompany.com_key domestic NEWHOST.mycompany.com
Also create certificates for any new virtual hosts.
java utils.CertGen Key_Passphrase NEWVHN.mycompany.com_cert NEWVHN.mycompany.com_key domestic NEWVHN.mycompany.com
Follow these steps when adding a new host:
Create a new identity keystore called appIdentityKeyStore using the utils.ImportPrivateKey utility. Create this keystore under the same directory as the certificates (that is, ASERVER_HOME/keystores).
Note:
The Identity Store is created (if none exists) when you import a certificate and the corresponding key into the Identity Store using the utils.ImportPrivateKey utility.
Import the certificate and private key for each of the certificates created above into the Identity Store. Ensure that you use a different alias for each of the certificate/key pairs imported.
Syntax (all on a single line):
java utils.ImportPrivateKey Keystore_File Keystore_Password Certificate_Alias_to_Use Private_Key_Passphrase Certificate_File Private_Key_File [Keystore_Type]
Examples:
java utils.ImportPrivateKey appIdentityKeyStore.jks Key_Passphrase appIdentityNEWHOST Key_Passphrase SHARED_CONFIG/keystores/NEWHOST.mycompany.com_cert.pem SHARED_CONFIG/keystores/NEWHOST.mycompany.com_key.pem
Follow these steps to create a new Keystore for each new host.
Copy the standard Java keystore to create the new trust keystore since it already contains most of the root CA certificates needed. Oracle does not recommend modifying the standard Java trust keystore directly. Copy the standard Java keystore CA certificates located under the WL_HOME/server/lib directory to the same directory as the certificates. For example:
cp WL_HOME/server/lib/cacerts SHARED_CONFIG/keystores/appTrustKeyStoreNEWHOST.jks
The default password for the standard Java keystore is changeit. Oracle recommends always changing the default password. Use the keytool utility to do this. The syntax is:
keytool -storepasswd -new New_Password -keystore Trust_Keystore -storepass Original_Password
For example:
keytool -storepasswd -new Key_Passphrase -keystore appTrustKeyStoreNEWHOST.jks -storepass changeit
The CA certificate CertGenCA.der is used to sign all certificates generated by the utils.CertGen tool. It is located in the WL_HOME/server/lib directory. This CA certificate must be imported into the appTrustKeyStore using the keytool utility. The syntax is:
keytool -import -v -noprompt -trustcacerts -alias Alias_Name -file CA_File_Location -keystore Keystore_Location -storepass Keystore_Password
For example:
keytool -import -v -noprompt -trustcacerts -alias clientCACert -file WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStoreNEWHOST.jks -storepass Key_Passphrase
After adding a new node manager you need to configure it to use the new custom keystones described in Section 14.5.3.2.4, "Creating a Trust Keystore Using the Keytool Utility.". To configure Node Manager to use the custom keystores, add the following lines to the end of the nodemanager.properties file located in the SHARED_CONFIG/nodemanager/hostname directory, where hostname is the name of the host where nodemanager runs:
KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=Identity_Keystore CustomIdentityKeyStorePassPhrase=Identity_Keystore_Password CustomIdentityAlias=Identity_Keystore_Alias CustomIdentityPrivateKeyPassPhrase=Private_Key_Used_When_Creating_Certificate
For example:
KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=SHARED_CONFIG/keystores/appIdentityKeyStore.jks CustomIdentityKeyStorePassPhrase=Key_Passphrase CustomIdentityAlias=appIdentityNEWHOST CustomIdentityPrivateKeyPassPhrase=Key_Passphrase
The passphrase entries in the nodemanager.properties file get encrypted when you start Node Manager as described in Section 15.1, "Starting and Stopping Components." For security reasons, minimize the time the entries in the nodemanager.properties file are left unencrypted. After you edit the file, start Node Manager as soon as possible so that the entries get encrypted.
Follow these steps to configure the identity and trust keystores for WLS_SERVER:
Log in to Oracle WebLogic Server Administration Console for the for the domain which is being extended at: the address specified in Section 15.2, "About Identity and Access Management Console URLs."
Click Lock and Edit.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page is displayed.
Click the name of the server for which you want to configure the identity and trust keystores (WLS_SERVER). The settings page for the selected server is displayed.
Select Configuration, then Keystores.
In the Keystores field, select the Custom Identity and Custom Trust method for storing and managing private keys/digital certificate pairs and trusted CA certificates.
In the Identity section, define attributes for the identity keystore:
Custom Identity Keystore: The fully qualified path to the identity keystore:
SHARED_CONFIG/keystores/appIdentityKeyStore.jks
Custom Identity Keystore Type: Leave blank; it defaults to JKS.
Custom Identity Keystore Passphrase: The password (Keystore_Password) you provided in Section 14.5.3.2.4, "Creating a Trust Keystore Using the Keytool Utility." This attribute is optional or required depending on the type of keystore. All keystores require the passphrase to write to the keystore. However, some keystores do not require the passphrase to read from the keystore. WebLogic Server only reads from the keystore, so whether you define this property depends on the requirements of the keystore.
In the Trust section, define properties for the trust keystore:
Custom Trust Keystore: The fully qualified path to the trust keystore:
SHARED_CONFIG/keystores/appTrustKeyStoreNEWHOST.jks
Custom Trust Keystore Type: Leave blank; it defaults to JKS.
Custom Trust Keystore Passphrase: The password you provided as New_Password in Section 14.5.3.2.4, "Creating a Trust Keystore Using the Keytool Utility" This attribute is optional or required depending on the type of keystore. All keystores require the passphrase to write to the keystore. However, some keystores do not require the passphrase to read from the keystore. WebLogic Server only reads from the keystore, so whether you define this property depends on the requirements of the keystore.
Click Save.
Click Activate Changes in the Administration Console's Change Center to make the changes take effect.
Select Configuration, then SSL.
Click Lock and Edit.
In the Private Key Alias field, enter the alias you used for the host name the Managed Server listens on, for example: appIdentityNEWHOST
In the Private Key Passphrase and the Confirm Private Key Passphrase fields, enter the password for the keystore that you created in Section 14.5.3.2.3, "Creating an Identity Keystore Using the utils.ImportPrivateKey Utility."
Click Save.
Click Activate Changes in the Administration Console's Change Center to make the changes take effect.
Restart the server for which the changes have been applied, as described in Section 15.1, "Starting and Stopping Components."
Once the previous steps have been performed, set host name verification for the affected Managed Servers to Bea Hostname Verifier. To do this, perform the following steps in both the IAMAccessDomain and IAMGovernanceDomain:
Log in to Oracle WebLogic Server Administration Console. (Console URLs are provided in Section 15.2, "About Identity and Access Management Console URLs.")
Select Lock and Edit from the change center.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page is displayed.
Select the Managed Server in the Names column of the table. The settings page for the server is displayed.
Open the SSL tab.
Expand the Advanced section of the page.
Set host name verification to Bea Hostname Verifier.
Click Save.
Click Activate Changes.
Run the following commands to start Node Manager.
cd SHARED_CONFIG/nodemanager/hostname
./startNodeManagerWrapper.sh
Note:
Verify that Node Manager is using the appropriate stores and alias from the Node Manager output. You should see the following when Node Manager starts.:
<Loading identity key store:
FileName=ASERVER_HOME/keystores/appIdentityKeyStore.jks, Type=jks, PassPhraseUsed=true>
Host name verification works if you apply a test configuration change to the servers and it succeeds without Node Manager reporting any SSL errors.