29 Scaling Enterprise Deployments

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:

• Section 29.1, "Scaling the Topology"

• Section 29.2, "Scaling the LDAP Directory"

• Section 29.3, "Scaling Identity and Access Management Applications"

• Section 29.4, "Scaling the Web Tier"

• Section 29.5, "Post-Scaling Steps for All Components"

29.1 Scaling the Topology

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.

29.2 Scaling the LDAP Directory

This section describes how to scale an LDAP directory.

This section contains the following topics:

• Section 29.2.1, "Mounting the Middleware Home when Scaling Out"

• Section 29.2.2, "Scaling Oracle Unified Directory"

• Section 29.2.3, "Scaling Oracle Internet Directory"

29.2.1 Mounting the Middleware Home when Scaling Out

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 9.11, "Mounting Shared Storage onto the Host."

29.2.2 Scaling Oracle Unified Directory

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 9.11, "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:

1. Assemble information, as listed in Section 29.2.2.1, "Assembling Information for Scaling Oracle Unified Directory."

2. If scaling out, mount the shared storage onto the new LDAPHOST.

3. Follow the steps in Section 29.2.2.2, "Configuring an Additional Oracle Unified Directory Instance."

4. Follow the steps in Section 29.2.2.3, "Validating the New Oracle Unified Directory Instance."

5. Follow the steps in Section 29.2.2.4, "Adding the New Oracle Unified Directory Instance to the Load Balancers."

6. Reconfigure the load balancer with the host and port information of the new Oracle Unified Directory instance, as described in Section 29.4.5, "Reconfiguring the Load Balancer."

29.2.2.1 Assembling Information for Scaling Oracle Unified Directory

Assemble the following information before scaling Oracle Unified Directory.

Description	Variable	Documented Value	Customer Value
New Oracle Unified Directory Host Name	LDAP_HOST	LDAPHOST3.example.com
Oracle Unified Directory Listen Port	LDAP_PORT	1389
Oracle Unified Directory SSL Port	LDAP_SSL_PORT	1636
Oracle Unified Directory Administration Port	LDAP_ADMIN_PORT	4444
Oracle Unified Directory Replication Port	LDAP_REPLIC_PORT	8989
Oracle Instance Location	LDAP_ORACLE_INSTANCE	/u02/private/oracle/config/instances/oudn
Oracle Unified Directory Existing Instance/Component Name	oudn	oud1
Newly Created Instance/Component Name	oudn	oud3
Oracle Unified Directory Administrator Password	COMMON_IDM_PASSWORD
Common Password	COMMON_IDM_PASSWORD

29.2.2.2 Configuring an Additional Oracle Unified Directory Instance

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 (LDAP_REPLIC_PORT). 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 LDAP_ORACLE_INSTANCE.

Change Directory to OUD_ORACLE_HOME

Start the Oracle Unified Directory configuration assistant by executing the command:

./oud-setup

1. On the Welcome screen, click Next.

2. 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.

3. 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.example.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.

4. 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.

5. On the Data Replication Screen. select dc=example,dc=com and click Next.

6. On the Oracle Components Integration screen, click Next.

7. On the Runtime Options Screen Click Next.

8. On the Review Screen, check that the information displayed is correct and click Finish.

9. On the Finished screen, click Close.

29.2.2.3 Validating the New Oracle Unified Directory Instance

After configuration, you can validate that Oracle Unified Directory is working by performing a simple search. To do this issue the following command:

LDAP_ORACLE_INSTANCE/OUD/bin/ldapsearch -h LDAPHOST3.example.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.

29.2.2.4 Adding the New Oracle Unified Directory Instance to the Load Balancers

Add the new Oracle Unified Directory instance to the existing server pool defined on the load balancer for distributing requests across the instances.

29.2.3 Scaling Oracle Internet Directory

This section describes how to scale Oracle Internet Directory.

This section contains the following topics:

• Section 29.2.3.1, "Configuring Oracle Internet Directory on LDAPHOST3"

• Section 29.2.3.2, "Validating the installation of OID on LDAPHOST3"

29.2.3.1 Configuring Oracle Internet Directory on LDAPHOST3

To configure Oracle Internet Directory on LDAPHOST3:

1. Ensure that ports 3060 and 3061 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 "3060"
   netstat -an | grep "3061"
   

   If the ports are in use (the command returns output identifying either port), you must free the port, or choose a different one.

2. Mount the SW_ROOT file system onto the new LDAPHOST (this is the file system which contains the DIR_MW_HOME).

3. Copy the staticports.ini file from the following directory to a temporary directory on the installation media:

   REPOS_HOME/installers/idm/Disk1/stage/Response
   

4. Edit the staticports.ini file that you copied to the temporary directory to assign ports 3060 and 3061, as follows, uncomment the entries in the file corresponding to the entries below and set the values accordingly.

   Table 29-1 Oracle Internet Directory Ports

   Entry	Value
   Oracle Internet Directory Port Number	3060
   Oracle Internet Directory (SSL) Port Number	3061

   
   

5. Start the Oracle Identity Management 11g Configuration Assistant by running:

   DIR_MW_HOME/oid/bin/config.sh 
   

6. On the Welcome screen, click Next.

7. On the Select Domain screen, select Configure without a Domain, and click Next.

8. On the Specify Installation Location screen, specify the following values:

   • Oracle Instance Location: LOCAL_CONFIG_DIR/instances/oid2

   • Oracle Instance Name: oid3

   Click Next.

9. On the Specify Security Updates screen, choose whether to receive security updates from Oracle support, and click Next.

10. On the Configure Components screen, select Oracle Internet Directory, deselect all the other components, and click Next.

11. On the Specify Schema Database screen, select Use Existing Schema and specify the following values:

    • Connect String: igddb-scan.example.com:1521:igddb1^ igddb-scan.example.com:1521:[e-mail]

    • User Name: ODS

    • Password: Enter the password for the OID schema created by RCU, and click Next.

    The ODS Schema in use message appears. The ODS schema chosen is already being used by the existing Oracle Internet Directory instance. Therefore, the new Oracle Internet Directory instance being configured reuses the same schema.

    Click Yes to continue.

    A popup window with this message appears:

    Please ensure that the system time on this Identity Management Node is in sync with the time on other Identity management Nodes that are part of the Oracle Application Server Cluster (Identity Management) configuration. Failure to ensure this may result in unwanted instance failovers, inconsistent operational attributes in directory entries and potential inconsistent behavior of password state policies.
    

    Ensure that the system time between LDAPHOST1, LDAPHOST2 and LDAPHOST3 is synchronized.

    Click OK to continue.

12. On the Specify OID Admin Password screen, specify the Oracle Internet Directory administration password that you specified when creating the first OID instance.

    Click Next.

13. 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. When they are correct, click Configure.

14. On Linux and UNIX systems, a dialog box may appear, that prompts you to run the oracleRoot.sh script. Run the oracleRoot.sh script, as the root user. When prompted:

    Do you want to run oidRoot.sh to configure OID for privileged ports? (yes/no)

    Enter yes.

15. On the Configuration Progress screen, multiple configuration assistants are launched in succession. This process can be lengthy. Wait for the configuration process to finish.

    When it finishes, click Next.

16. On the Installation Complete screen, click Finish to confirm your choice to exit.

29.2.3.2 Validating the installation of OID on LDAPHOST3

To validate the installation of the Oracle Internet Directory instance on LDAPHOST3, issue these commands:

export ORACLE_HOME=OID_ORACLE_HOME
ORACLE_HOME/bin/ldapbind -h ldaphost2.example.com -p 3060 -D "cn=orcladmin" -q
ORACLE_HOME/bin/ldapbind -h ldapdhost2.example.com -p 3061 -D "cn=orcladmin" -q -U 1

You will be prompted for your administrator password.

Note:

You must invoke ldapbind from the OID Oracle Home. Many LINUX systems come with an openldap version of ldapbind, which is incompatible with Oracle Internet Directory.

29.3 Scaling Identity and Access Management Applications

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 29.3.1, "Gathering Information."

• Section 29.3.2, "Mounting Middleware Home and Creating a New Machine when Scaling Out."

• Section 29.3.3, "Creating a New Node Manager when Scaling Out."

• Section 29.3.4, "Running Pack/Unpack."

• Section 29.3.5, "Performing Application-Specific Steps."

• Section 29.3.6, "Adding New WebLogic Managed Server to Oracle HTTP Server Configuration Files."

29.3.1 Gathering Information

Use the following tables to assemble the values you need.

29.3.1.1 Assembling Information for Scaling Access Manager

Assemble the following information before scaling Access Manager.

Description	Variable	Documented Value	Customer Value
Host Name	NEWHOSTn
Existing Access Manager server		WLS_OAM1
New Access Manager server name	WLS_OAMn	WLS_OAM3
Server Listen Port	OAM_PORT	14100
WebLogic Administration Host	WLS_ADMIN_HOST	IADADMINVHN.example.com
WebLogic Administration Port	IAD_WLS_PORT	7001
WebLogic Administration User		weblogic_idm
WebLogic Administration Password

29.3.1.2 Assembling Information for Scaling Oracle Identity Manager

Description	Variable	Documented Value	Customer Value
Host name	NEWHOSTn
SOA virtual server name		SOAHOSTxVHN
Oracle Identity Manager virtual server name		OIMHOSTxVHN
Existing SOA managed server to clone	WLS_SOAn	WLS_SOA1
Existing Oracle Identity Manager managed server to clone	WLS_OIMn	WLS_OIM1
New SOA managed server name	WLS_SOAn	WLS_SOA3
New Oracle Identity Manager managed server name	WLS_OIMn	WLS_OIM3
Numeric extension for new JMS servers	n	3
WebLogic Administration Host	WLS_ADMIN_HOST	IGDADMINVHN.example.com
WebLogic Administration Port	WLS_ADMIN_PORT	7101
WebLogic Administration User		weblogic_idm
WebLogic Administration Password

29.3.1.3 Assembling Information for Scaling Oracle Adaptive Access Manager

Assemble the following information before scaling Oracle Adaptive Access Manager.

Description	Variable	Documented Value	Customer Value
Host Name	NEWHOSTn
Existing OAAM server		WLS_OAAM1
New OAAM server name	WLS_OAAMn	WLS_OAAM3
Server Listen Address
OAAM Managed Server Port	OAAM_PORT	14300
OAAM Administration Managed Server Port	OAAM_ADMIN_PORT	14200
WebLogic Administration Host	WLS_ADMIN_HOST	IDADMINVHN.example.comFoot 1
WebLogic Administration Port	WLS_ADMIN_PORT	7001
WebLogic Administration User		weblogic_idm
WebLogic Administration Password

^Footnote 1 This refers to the domain that you are scaling.

29.3.2 Mounting Middleware Home and Creating a New Machine when Scaling Out

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:

1. 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 9.11, "Mounting Shared Storage onto the Host." for more information.

2. 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.

3. 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.

4. Log in to the WebLogic Administration Console for the IAMAccessDomain at the address listed in Section 31.2, "About Identity and Access Management Console URLs."

5. Create a new machine for the new node to be used, and add the machine to the domain, as follows.

   1. Select Environment -> Machines from the Navigation menu.

   2. Click Lock and Edit.

   3. Click New on the Machine Summary screen.

   4. Enter the following information:

      Name: Name of the machine (NEWHOSTn)

      Machine OS: Select UNIX.

   5. Click Next.

   6. On the Node Manager Properties page, enter the following information:

      Type: SSL.

      Listen Address: NEWHOSTn.

   7. Click Finish.

   8. Click Activate Changes.

29.3.3 Creating a New Node Manager when Scaling Out

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:

1. Create a new directory for the new node manager by copying an existing one. Copy the directory SHARED_CONFIG/nodemanager/oamhost1.example.com to: SHARED_CONFIG/nodemanager/newiamhost.example.com

   For example:

   cp -r $SHARED_CONFIG/nodemanager/oamhost1.example.com $SHARED_CONFIG/nodemanager/newiamhost.example.com
   

2. Change to the newly created directory.

   cd SHARED_CONFIG/nodemanager/NEWHOST3.example.com
   

3. Edit the nodemanager.properties file, changing all the entries for OAMHOST1 to OAMHOST3. For example:

   DomainsFile=/u01/oracle/config/nodemanager/OAMHOST1.example.com/nodemanager.domain
   

   becomes

   DomainsFile=/u01/oracle/config/nodemanager/NEWHOST3.example.com/nodemanager.domain
   

4. Edit the startNodeManagerWrapper.sh file, changing all the entries for OAMHOST1 to OAMHOST3. For example:

   NM_HOME=/u01/oracle/config/nodemanager/oamhost1.example.com
   

   becomes

   NM_HOME=/u01/oracle/config/nodemanager/oamhost3.example.com
   

5. Start the node manager by invoking the command:

   ./startNodeManagerWrapper.sh
   

6. Update the node manager configuration by following the steps in Chapter 29, "Updating Node Manager Configuration" to ensure that certificates are created for the new host.

29.3.4 Running Pack/Unpack

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

1. 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.

2. 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.

3. If you are scaling out, start Node Manager and update the property file.

   1. Start and stop Node Manager as described in Section 31.1, "Starting and Stopping Enterprise Deployment Components."

   2. 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
      

   3. Start Node Manager once again as described in Section 31.1, "Starting and Stopping Enterprise Deployment Components."

29.3.5 Performing Application-Specific Steps

This section contains the following topics:

• Section 29.3.5.1, "Cloning an Existing Managed Server."

• Section 29.3.5.2, "Scaling Oracle Access Management Access Manager."

• Section 29.3.5.2, "Scaling Oracle Access Management Access Manager."

• Section 29.3.5.3, "Scaling Oracle Identity Manager"

• Section 29.3.5.4, "Updating Oracle Adaptive Access Manager Integration"

29.3.5.1 Cloning an Existing Managed Server

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.

1. Log in to the Oracle WebLogic Administration Console for the domain whose managed server you are cloning, at the address listed in Section 31.2, "About Identity and Access Management Console URLs." For this example the domain is IAMAccessDomain.

2. 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.

3. Click Lock & Edit from the Change Center menu.

4. Select an existing server on the host you want to extend, for example: WLS_OAM1.

5. Click Clone.

6. 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.

7. Click OK.

8. Click the newly created server WLS_OAM3

9. Set Machine to be the machine you created in Section 29.3.2, "Mounting Middleware Home and Creating a New Machine when Scaling Out""

10. Click Save.

11. 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:

    1. In Oracle Enterprise Manager Fusion Middleware Control, select Oracle WebLogic Server Administration Console.

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

    3. Click Servers. The Summary of Servers page appears.

    4. Select WLS_OAM3 in the Names column of the table. The Settings page for server appears.

    5. Click the SSL tab.

    6. Click Advanced.

    7. Set Hostname Verification to None.

    8. Click Save.

12. Click Activate Changes from the Change Center menu.

29.3.5.2 Scaling Oracle Access Management Access Manager

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:

• Section 29.3.5.2.1, "Running Pack/Unpack"

• Section 29.3.5.2.2, "Register Managed Server with Oracle Access Management Access Manager"

• Section 29.3.5.2.3, "Updating WebGate Profiles"

• Section 29.3.5.2.4, "Updating the Web Tier"

29.3.5.2.1 Running Pack/Unpack

Run pack and unpack as described in Section 29.3.4, "Running Pack/Unpack".

29.3.5.2.2 Register Managed Server with Oracle Access Management Access Manager

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:

1. Log in to the Access Management console at http://IADADMIN.example.com/oamconsole as the user you specified during response file creation.

2. Click the System Configuration tab.

3. Click Server Instances.

4. Select Create from the Actions menu.

5. 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.

6. Click Coherence tab.

   Set Local Port to a unique value on the host.

7. Click Apply.

8. Restart the WebLogic Administration Server as described in Section 31.1, "Starting and Stopping Enterprise Deployment Components"

29.3.5.2.3 Updating WebGate Profiles

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.example.com/oamconsole

Then proceed as follows:

1. Log in as the Access Manager Administrative User.

2. Click the System Configuration tab.

3. Expand Access Manager Settings - SSO Agents - OAM Agents.

4. Click the open folder icon, then click Search.

   You should see the WebGate agent Webgate_IDM.

5. Click the agent Webgate_IDM.

6. Select Edit from the Actions menu.

7. Click + in the Primary Server list (or the Secondary Server list if this is a secondary server).

8. Select the newly created managed server from the Server list.

9. Set Maximum Number of Connections to 10.

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 31.1, "Starting and Stopping Enterprise Deployment Components"

29.3.5.2.4 Updating the Web Tier

Add the newly added Managed Server host name and port to the list WebLogicCluster parameter, as described in Section 29.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 31.1, "Starting and Stopping Enterprise Deployment Components"

29.3.5.3 Scaling Oracle Identity Manager

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 29.3.5.3.1, "Configuring New JMS Servers"

• Section 29.3.5.3.2, "Performing Pack/Unpack When Scaling Out"

• Section 29.3.5.3.3, "Configuring Oracle Coherence for Deploying Composites"

• Section 29.3.5.3.4, "Enabling Communication for Deployment Using Unicast Communication"

• Section 29.3.5.3.5, "Specifying the Host Name Used by Oracle Coherence"

• Section 29.3.5.3.6, "Completing the Oracle Identity Manager Configuration Steps"

29.3.5.3.1 Configuring New JMS Servers

Create JMS Servers for SOA, Oracle Identity Manager, UMS, and BPM on the new Managed Server. You do this as follows:

1. Log in to the WebLogic Administration Server in the IAMGovernanceDomain, as described in Section 31.2, "About Identity and Access Management Console URLs," and navigate to Services -> Messaging -> JMS Servers.

2. Click New.

3. Enter a value for Name, such as BPMJMSServer_auto_3.

4. Click Create New Store.

5. Select FileStore from the list

6. Click Next.

7. Enter a value for Name, such as BPMJMSFileStore_auto_3

8. Enter the following values:

   Target: The new server you are creating.

   Directory: IGD_ASERVER_HOME/jms/BPMJMSFileStore_auto_3

9. Click OK.

10. When you are returned to the JMS Server screen, select the newly created file store from the list.

11. Click Next.

12. On the next screen set the Target to the server you are creating.

13. 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	IGD_ASERVER_HOME/jms/BPMJMSFileStore_auto_n	WLS_SOAn
WLS_SOAn	SOAJMSServer_auto_n	SOAJMSFileStore_auto_n	IGD_ASERVER_HOME/jms/SOAJMSFileStore_auto_n	WLS_SOAn
WLS_SOAn	UMSJMSServer_auto_n	UMSJMSFileStore_auto_n	IGD_ASERVER_HOME/jms/UMSJMSFileStore_auto_n	WLS_SOAn
WLS_OIMn	JRFWSAsyncJmsServer_auto_n	JRFWSAsyncFileStore_auto_n	IGD_ASERVER_HOME/jms/RFWSAsyncFileStore_auto_n	WLS_OIMn
WLS_OIMn	OIMJMSServer_auto_n	OIMJMSFileStore_auto_n	IGD_ASERVER_HOME/jms/OIMJMSFileStore_auto_n	wls_OIMn
WLS_SOAn	PS6SOAJMSServer_auto_n	PS6SOAJMSFileStore_auto_n	IGD_ASERVER_HOME/jms/PS6SOAJMSFileStore_auto_n	wls_SOAn

Add the newly created JMS Queues to the existing JMS Modules by performing the following steps:

1. Log in to the WebLogic Administration Console in the IAMGovernanceDomain, at the address listed in Section 31.2, "About Identity and Access Management Console URLs."

2. Navigate to Services -> Messaging -> JMS Modules

3. Click a JMSModule, such as SOAJMSModule

4. Click the Sub Deployments tab.

5. 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.

6. Assign the newly created JMS server, for example SOAJMSServer_auton.

7. Click Save.

8. 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

   
   

9. Click Activate Configuration from the Change Center menu.

29.3.5.3.2 Performing Pack/Unpack When Scaling Out

This section is necessary only when you are scaling out.

Run pack and unpack as described in Section 29.3.4, "Running Pack/Unpack"

29.3.5.3.3 Configuring Oracle Coherence for Deploying Composites

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.

29.3.5.3.4 Enabling Communication for Deployment Using Unicast Communication

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).

29.3.5.3.5 Specifying the Host Name Used by Oracle Coherence

Use the Administration Console to specify a host name used by Oracle Coherence.

To add the host name used by Oracle Coherence:

1. Log into the Oracle WebLogic Server Administration Console.

2. In the Domain Structure window, expand the Environment node.

3. Click Servers. The Summary of Servers page appears.

4. 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.

5. Click Lock & Edit.

6. Click the Server Start tab.

7. 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.

8. 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.

29.3.5.3.6 Completing the Oracle Identity Manager Configuration Steps

1. 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 > Configuration > 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.

2. 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:

   1. In the Oracle Enterprise Manager Console, select Oracle WebLogic Server Administration Console.

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

   3. Click Servers. The Summary of Servers page appears.

   4. Select WLS_SOAn in the Names column of the table. The Settings page for the server appears.

   5. Click the SSL tab.

   6. Click Advanced.

   7. Set Hostname Verification to None.

   8. Click Save.

3. 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.

4. Click Activate Changes from the Change Center menu.

5. Restart the WebLogic Administration Server as described in Section 31.1, "Starting and Stopping Enterprise Deployment Components"

6. Start and test the new Managed Server from the Administration Console.

   1. Shut down the existing Managed Servers in the cluster.

   2. Ensure that the newly created Managed Server, WLS_SOAn, is up.

   3. Access the application on the newly created Managed Server (http://vip:port/soa-infra). The application should be functional.

7. Configure the newly created managed server for server migration. Follow the steps in Chapter 21, "Configuring Server Migration for an Enterprise Deployment." 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.

8. Test server migration for this new server. Follow these steps from the node where you added the new server:

   1. 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
      

   2. Watch the Node Manager Console. You should see a message indicating that the floating IP address for WLS_SOA1 has been disabled.

   3. 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.

   4. 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.

   5. Repeat Steps a-d for WLS_OIMn.

29.3.5.4 Updating Oracle Adaptive Access Manager Integration

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.

29.3.6 Adding New WebLogic Managed Server to Oracle HTTP Server Configuration Files

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 igdinternal_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.example.com:14100,OAMHOST2.example.com:14100
</Location>
 
<Location /oamfed>
   SetHandler weblogic-handler
   WebLogicCluster OAMHOST1.example.com:14100,OAMHOST2.example.com:14100
</Location>

to:

<Location /oam>
   SetHandler weblogic-handler
   WebLogicCluster OAMHOST1.example.com:14100,OAMHOST2.example.com:14100,OAMHOST1.example.com:14101
</Location>
 
<Location /oamfed>
   SetHandler weblogic-handler
   WebLogicCluster OAMHOST1.example.com:14100,OAMHOST2.example.com:14100,OAMHOST3.example.com:14100
</Location>

Once you have updated the configuration file, restart the Oracle HTTP server(s) as described in Section 31.1, "Starting and Stopping Enterprise Deployment Components." Oracle recommends that you do this sequentially to prevent loss of service.

29.4 Scaling the Web Tier

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 29.4.1, "Assembling Information for Scaling the Web Tier."

• Section 29.4.2, "Mounting Middleware Home and Copying Oracle HTTP Server Files when Scaling Out."

• Section 29.4.3, "Running the Configuration Wizard to Configure the HTTP Server."

• Section 29.4.4, "Registering Oracle HTTP Server with WebLogic Server."

• Section 29.4.5, "Reconfiguring the Load Balancer."

29.4.1 Assembling Information for Scaling the Web Tier

Assemble the following information before scaling the Web Tier.

Description	Variable	Documented Value	Customer Value
Host name		WEBHOST1.example.com
OHS port	WEB_HTTP_PORT	7777
Instance Name	webn	web1 or web2
Component Name	webn	web1 or web2
WebLogic Administration Host, IAMAccessDomain	IADADMINVHN	IADADMINVHN.example.com
Access Management WLS Server Port	IAD_WLS_PORT	7001
WebLogic Administrative User		weblogic_idm
WebLogic Administrative Password

29.4.2 Mounting Middleware Home and Copying Oracle HTTP Server Files when Scaling Out

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.

29.4.3 Running the Configuration Wizard to Configure the HTTP Server

Perform these steps to configure the Oracle Web Tier:

1. 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.

2. Change the directory to the location of the Oracle Fusion Middleware Configuration Wizard:

   cd WEB_ORACLE_HOME/bin
   

3. Start the Configuration Wizard:

   ./config.sh
   

Enter the following information into the configuration wizard:

1. On the Welcome screen, click Next.

2. 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.

3. On the Specify WebLogic Domain Screen, enter

   • Domain Host Name: IADADMINVHN.example.com

   • Domain Port No: 7001, where 7001 is IAD_WLS_PORT in Section 8.1, "Summary of Virtual IP Addresses Required."

   • User Name: Weblogic Administrator User (For example: weblogic)

   • Password: Password for the Weblogic Administrator User account

   Click Next.

4. 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.

5. 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.

   1. Select Specify Ports using a Configuration File.

   2. In the file name field specify ohs_ports.ini.

   3. Click Save, then click Next.

6. 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.

7. 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.

29.4.4 Registering Oracle HTTP Server with WebLogic Server

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.example.com \
   -adminPort WLS_ADMIN_PORT -adminUsername weblogic

29.4.5 Reconfiguring the Load Balancer

Add the new Oracle HTTP Server instance to the existing server pool defined on the load balancer for distributing requests across the HTTP instances.

29.4.6 Scaling Up Oracle Traffic Director

To scale up Oracle traffic director:

1. Install Oracle Traffic Director on the new host as described in Section 11.2.2, "Installing Oracle Traffic Director."

2. Create a new instance of Oracle Traffic Director on the new host as described in Section 14.2.2, "Registering WEBHOST2 with the Administration Node."

3. Deploy the configuration to the new node by following the instructions in Section 14.2.9, "Deploying the Configuration and Testing the Virtual Server Addresses."

4. Create a new failover group for the new Oracle Traffic Director instance as described in Section 14.2.10, "Creating a Failover Group for Virtual Hosts."

5. Add the new Oracle Traffic Director failover group to the hardware load balancer pool.

29.4.7 Scaling Oracle Mobile Security Access Server

This section describes how to scale the Oracle Mobile Security Access Server.

This section contains the following topics:

• Section 29.4.7.1, "Installing Oracle Mobile Security Access Server"

• Section 29.4.7.2, "Configuring MSAS Gateway Instance"

• Section 29.4.7.3, "Creating an MSAS Configuration Property File"

• Section 29.4.7.4, "Configuring the MSAS Instance Using configMSAS.sh"

• Section 29.4.7.5, "Validating the MSAS Configuration"

• Section 29.4.7.6, "Integrating MSAS with the Identity Store"

• Section 29.4.7.7, "Starting MSAS Instances on OHSHOST1 and OHSHOST2"

29.4.7.1 Installing Oracle Mobile Security Access Server

This section explains how to install Oracle Mobile Security Access Server (MSAS) on OHSHOST1 and OHSHOST2.

As described in Preparing File System Chapter, you install the Oracle MSAS onto a private disk.

Before Starting the install, ensure that the following environment variables are not set on Linux platforms:

• LD_ASSUME_KERNEL

• ORACLE_INSTANCE

To start the Oracle Universal Installer:

1. On Linux, run the following command:

   ./runInstaller -jreLoc JAVA_HOME
   

2. On the Specify Inventory Directory screen, do the following:

   1. Enter HOME/oraInventory, where HOME is the home directory of the user performing the installation (this is the recommended location).

   2. Enter the OS group for the user performing the installation and click Next.

   3. Follow the instructions on screen to execute createCentralInventory.sh as root and click OK.

3. On the Welcome screen, click Next.

4. On the Install Software Updates Screen choose to either search for updates, and click OK, or select Skip Software Updates and click Next.

5. On the Prerequisite Checks screen, if all the pre-checks have completed successfully, click Next.

6. On the Specify Installation Location screen, specify the following values:

   • Fusion Middleware Home Location (Installation Location): For example: /u01/oracle/products/web

   • Oracle Home Location Directory: omsas

   Click Next.

7. 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), and click Install.

8. On the Installation Complete Screen, click Finish.

29.4.7.2 Configuring MSAS Gateway Instance

After installation, you must configure the MSAS gateway instance. Each instance must be configured exactly the same, with the same instance ID, so that they can function as a cluster. While this can be done interactively, it is better to do so by using a property file, which can then be used to configure each instance.

29.4.7.3 Creating an MSAS Configuration Property File

You can use the file created by provisioning at the following location:

LCM_HOME/provisioning/logs 

Create a property file called msas_instance.props with the following information:

MSM_URL: http://iadinternal.example.com:80
MSM_USER_NAME:  weblogic
MSAS_INSTANCE_ID: gateway1
MSAS_INSTANCE_DIR:  LOCAL_CONFIG_DIR/instances/
MSAS_INSTANCE_SSL_PORT: 14191
OAM_HOST: iadadminvhn.example.com
OAM_PORT: 7001
OAM_USER_NAME: iadadmin
OAM_PROTECT: / 
OAUTH_HOST: login.example.com
OAUTH_PORT: 443
OAUTH_IS_SSL: true
OAUTH_SP_ENDPOINT: /oauthservice
OAM_COOKIE_DOMAIN: .example.com
MSAS_LBR_URL: https://msas.example.com

Property Descriptions:

• MSM_URL is the URL of the Oracle HTTP Server which directs requests to the MSM managed servers. For example:

  http://iadinternal.example.com:80 
  

  This is the URL which is used for internal call backs.

• MSM_USER_NAME is the domain administrator name. For example: weblogic.

• MSAS_INSTANCE_ID is the collective name of the instance. It can be any string, but must be consistent across instances. This must be the same as the value provided as input to the provisioning wizard.

• MSAS_INSTANCE_DIR is where the instance configuration files are created. For example:

  LOCAL_CONFIG_DIR/instances
  

• MSAS_INSTANCE_PORT is the port on which MSAS listens for requests. This port is SSL enabled.

• OAM_HOST is the IAMAccessDomain Administration Server Virtual Host. For example:

  IADADMINVHN.example.com
  

• OAM_PORT is the Port used by the IAMAccessDomain Administration Server. For example: 7001

• OAM_USER_NAME This is the OAMAdmin account you created previously.

• OAM_PROTECT Specifies the resource pattern for each protected application, for example, /myapp/login. The pattern you enter is relative to the host and port of the OAM gateway. This entry must begin with a /.

  You can enter /, which means that any requesting URL ending in / is protected.

• OAUTH_HOST is the OAUTH entry point in an enterprise deployment. This is the load balancer name. For example, login.example.com.

• OAUTH_PORT is the port that OAM Managed Servers use in an enterprise deployment. This is the load balancer port. For example, 443.

• OAUTH_IS_SSL specifies where OAUTH is using the SSL or non SSL port. Valid values are: true/false. In an enterprise deployment the value is true.

• OAUTH_SP_ENDPOINT is the endpoint where you access clients from the OAUTH server, for example: /oauthservice

• MSAS_LBR_URL is the load balancer entry point for MSAS. For example, https://msas.example.com:443

29.4.7.4 Configuring the MSAS Instance Using configMSAS.sh

Once you have created the property file, run the configMSAS.sh script to configure the instance. This script is located in the following directory:

MSAS_ORACLE_HOME/bin

To execute the script use the following command:

MSAS_ORACLE_HOME/bin/configMSAS.sh -properties msas_instance.props

You are prompted for the following:

• The mobile security manager password. This is the WebLogic Administrator password of the IAMAccessDomain

• The OAM Administrator password.

29.4.7.5 Validating the MSAS Configuration

The configMSAS.sh command creates an MSAS instance in the following directory:

LOCAL_CONFIG_DIR/instances/gateway-id

Where the gateway-id is the value you provided in the property file. Validate that this directory exists.

If the directory exists you can validate that the instance has been registered with MSM by doing the following:

1. Log in to the Access Console as the oamadmin user.

2. On the Launch Pad, click the Mobile Security button at the top of the screen.

3. Click Environments in the Mobile Security Access Server section, the MSAS instances appear.

4. Click the MSAS title.

   The EDGMSAS instance appears.

   Note:

   Due to a known issue, once you have registered the second instance, only one MSAS instance appears, which is the second instance. This is a cosmetic error and has no impact on system functionality.

29.4.7.6 Integrating MSAS with the Identity Store

This section describes how to integrate MSAS with the Identity Store.

To integrate MSAS with the Identity Store on OAMHOST1:

1. Set the environment variables MW_HOME, JAVA_HOME, ORACLE_HOME and WL_HOME

   • Set MW_HOME to IAD_MW_HOME.

   • Set JAVA_HOME to JAVA_HOME.

   • Set ORACLE_HOME to IAD_ORACLE_HOME.

   • Set WL_HOME to IAD_MW_HOME/wlserver_10.3

2. Run the idmConfigTool utility to perform the integration.

   The syntax of the command on Linux is:

   cd IAD_ORACLE_HOME/idmtools/bin
   idmConfigTool.sh -configOMSS mode=OMSAS input_file=configfile 
   

   For example:

   idmConfigTool.sh -configOMSS mode=OMSAS input_file=msas.props
   

   When the command runs, you are prompted to enter the password of the account with which you are connecting to the Identity Store. You are also asked to specify the passwords you want to assign to:

   • OMSS Keystore: This is the password that is assigned to the OMSS keystore when it is created.

   • SCEP Dynamic Challenge Password

   • The schema password for the RCU schema EDGIAD_OMSM.

3. Check the log file for any errors or warnings and correct them. A file named automation.log is created in the directory where you run the tool.

4. This process creates objects in the domain, in order for these objects to be visible the Administration Server must be restarted.

5. Pack and unpack the IAMAccessDomain as described in Section 29.3.4, "Running Pack/Unpack". Creating a Separate Domain Directory for Managed Servers. Unpack to both OAMHOST1 and OAMHOST2.

6. Restart WebLogic Administration console, WLS_OAM1, WLS_OAM2, WLS_AMA1, WLS_AMA2.

29.4.7.7 Starting MSAS Instances on OHSHOST1 and OHSHOST2

Once you have configured the instances, you can start them. To start the instances issue the following command:

MSAS_INSTANCE_HOME/bin/startServer.sh

The MSAS instances should start without error.

29.5 Post-Scaling Steps for All Components

Perform the following post-scaling steps.

• Section 29.5.1, "Adding a New Managed Server to the Oracle Traffic Director Server Pool."

• Section 29.5.2, "Updating the Topology Store."

• Section 29.5.3, "Updating Stop/Start Scripts."

• Section 29.5.4, "Updating Node Manager Configuration."

29.5.1 Adding a New Managed Server to the Oracle Traffic Director Server Pool

The procedures described in this section show you how to add a new managed server or directory instance to an existing OTD server pool.The following example is for OAM, but the process is the same for all managed servers/directory instances.

To add a third instance to the Oracle Traffic Director Access Manager server pool:

1. Log into the Oracle Traffic Director Administration Console.

2. Click Server Pools on the left panel.

3. Click the pool name, for example: origin-server-pool-1.

4. On the right panel, click New Origin Server.

5. Add the new Managed Server/Directory Instance, for example: IAMHOST3, 14100 of the Origin Server.

   Click Next.

6. Click New Origin Server, and then Close.

7. Click Deploy Changes on the top of the panel.

29.5.2 Updating the Topology Store

During deployment, a topology store is created which contains details of the deployed topology. When patching the environment, the Life Cycle 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.

29.5.3 Updating Stop/Start Scripts

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

29.5.4 Updating Node Manager Configuration

Update the node manager configuration, as described in the following sections:

• Section 29.5.4.1, "Starting and Stopping Node Manager."

29.5.4.1 Starting and Stopping Node Manager

If you want to start a node manager on a new machine, add an entry which looks like this:

newmachine.example.com NM nodemanager_pathname nodemanager_port

For example:

OAMHOST3.example.com NM /u01/oracle/config/nodemanager/oamhost3.example.com 5556

If you want to start a managed server called WLS_OIM3 add an entry which looks like this:

newmachine.example.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 Chapter 16, "Setting Up Node Manager for an Enterprise Deployment".