11 Managing the Topology

11.3.1 Scaling Up the Topology (Adding Managed Servers to Existing Nodes)

In this case, you already have a node that runs a managed server configured with WebCenter components or a managed server with WSM-PM. The node contains a WebLogic Server home and an Oracle Fusion Middleware WebCenter home in shared storage.

You can use the existing installations (WebLogic Server home, Oracle Fusion Middleware home, and domain directories) for creating new Oracle WebCenter and WLS_WSM servers. There is no need to install WLS or WebCenter binaries in a new location, or to run pack and unpack.

Follow these steps for scaling up the topology:

1. Using the Administration Console, clone WLS_Spaces1 or WLS_Portlet1 or WLS_Services1 or WLS_WSM1 into a new managed server. The source managed server to clone should be one that already exists on the node where you want to run the new managed server.

   To clone a managed server, complete these steps:

   1. Select Environment and then Servers from the Administration Console.

   2. Select the managed server to clone (for example, WLS_Spaces1 or WLS_Portlet1).

   3. Select Clone.

   Name the new managed server (SERVER_NAME)n, where n is a number to identify the new managed server.

2. For the listen address, assign the host name or IP to use for this new managed server.

3. If the Managed Server being scaled out is WLS_Services, then follow these extra steps:

   1. Start the Managed Server at least once, to create the Managed Servers deployment directories for Oracle Wiki. The Managed Server can then be shut down.

   2. Create a soft link from this new servers config directories to that of the shared Wiki Server directories:

      $ ln -s <DOMAIN_HOME>/servers/WLS_ServicesN/stage/owc_wiki/11.1.1.1.0/owc_wiki/attachments/ /shared/owc_wiki/attachments
      $ ln -s <DOMAIN_HOME>/servers/WLS_ServicesN/stage/owc_wiki/11.1.1.1.0/owc_wiki/templates/ /shared/owc_wiki/templates
      

4. Reconfigure the Oracle HTTP Server module with the new member in the cluster. See Oracle HTTP Server configuration.

5. Add the New Managed Server to the Java Object Cache Cluster (see Section 6.13, "Setting Up the Java Object Cache").

11.3.2 Scaling Out the Topology (Adding Managed Servers to New Nodes)

In scaling out your topology, you add new managed servers configured with Oracle WebCenter applications and or WSM-PM to new nodes.

Before performing the steps in this section, check that you meet these requirements:

• In your topology, there are existing nodes running managed servers configured with Oracle WebCenter applications and or WSM-PM.

• The new node can access the existing home directories for WebLogic Server and Oracle WebCenter. You use the existing installations in shared storage for creating a new managed server. You do not need to install WebLogic Server or WebCenter binaries in a new location but you do need to run pack and unpack to bootstrap the domain configuration in the new node.

Follow these steps for scaling out the topology:

1. On the new node, mount the existing FMW Home, which should include the WebCenter 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.

2. To attach ORACLE_HOME in shared storage to the local Oracle Inventory, execute the following command:

   SOAHOSTn>cd ORACLE_BASE/product/fmw/soa/
   SOAHOSTn>./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_05_R27.6.2-20
   

   To update the Middleware home list, create (or edit, if another WebLogic installation exists in the node) the $HOME/bea/beahomelist file and add ORACLE_BASE/product/fmw to it.

3. Log in to the Oracle WebLogic Administration Console.

4. Create a new machine for the new node that will be used, and add the machine to the domain.

5. Update the machine's Node Manager's address to map the IP of the node that is being used for scale out.

6. Using the Administration Console, clone WLS_Spaces1/WLS_Portlet1/WLS_Services1/WLS_WSM1 into a new managed server and name it WLS_(SERVER_TYPE)n, where n is a number.

   The steps assume that you are adding a new server to node n, where no managed server was running.

7. For the listen address of the managed server, assign the host name or IP to use for the new managed server.

8. If the Managed Server being scaled out is WLS_Services then follow these extra steps:

   1. Start the Managed Server at least once, to create the Managed Servers deployment directories for Oracle Wiki. The Managed Server can then be shut down.

   2. Create a soft link from this new servers config directories to that of the shared Wiki Server directories:

      $ ln -s <DOMAIN_HOME>/servers/WLS_ServicesN/stage/owc_wiki/11.1.1.1.0/owc_wiki/attachments/ /shared/owc_wiki/attachments
      $ ln -s <DOMAIN_HOME>/servers/WLS_ServicesN/stage/owc_wiki/11.1.1.1.0/owc_wiki/templates/ /shared/owc_wiki/templates
      

9. Reconfigure the Oracle HTTP Server module with the new member in the cluster (see Oracle HTTP Server configuration).

10. Start Node Manager on the new node: using the installation in shared storage from the already existing nodes, start Node Manager passing as parameter the host name of the new node:

    NEW_NODE> WL_HOME/server/bin/startNodeManager <new_node_ip>
    

    If you used the paths shown in Section 4.1.1, "Installing Oracle WebLogic Server," WL_HOME would be ORACLE_BASE/wls.

11. Start and test the just added managed server from the Administration Console.

    Access the application on the newly created managed server (http://HOST:port/webcenter or http://host:port/wsm-pm). The application should be functional.

12. Add the new managed server to the Java Object Cache Cluster (see Section 6.13, "Setting Up the Java Object Cache").

11.3.3 Scaling Out the Oracle Content Server (OCS) Topology

Each Content Server node is installed using the cluster installer which can be found in <content_server_dir>/bin on the shared disk.

Installing Another Content Server Node

From the new node (SOAHOSTn), run the command (all on one line):

Installer
-set-ClusterNodeIntradocDir=<ocs-stub>
-set-ClusterNodeName=<nodename>
-set-ClusterNodeAddress=<ip_of_node>
-set-ClusterBinDirRule=<local|shared>
ConfigureClusterNode
ConfigureAdminClusterNode

For <nodename>, specify SOAHOSTn.

For <stellent-stub>, use a local directory, for example, /u01/app/oracle/product/ucm.

For Set-ClusterBinDirRule, specify local.

Post-Installation Steps

After setting up the nodes, add the following lines to the intradoc.cfg file in the <stellent-stub>/bin and <stellent-stub>/admin/etc directories:

DisableSharedCacheChecking=true 
ClusterNodeName=<nodename> 
ClusterGroup=<cluster_name> 
SocketServerAddress=<server_IP_address>

<nodename> is the identifier for the node.

<cluster_name> is the identifier for the cluster.

All nodes should have a different node name, but should have the same cluster group name; for example, the lines on SOAHOSTn might look like the following:

DisableSharedCacheChecking=true
ClusterNodeName=SOAHOSTn
ClusterGroup=ucmcluster
SocketServerAddress=<IP_of_SOAHOSTn>

Starting the Servers

Start Oracle Content Server and Admin Server on each node using the binaries in <ocs-stub>/bin.

Verify that the log and PID files are created in the <ocs-stub>/admin/etc and <ocs-stub>/etc directories.

Configuring the Load Balancer

You must reconfigure the load balancer to act as a socket load balancer to this new host as well. This will be used to make socket connections from the Oracle HTTP Server as well as WebCenter. Example:

Virtual host on load balancer: wcinternal.mycompany.com:9054

Maps to: WCHOST1:9054, WCHOST2:9054, SOAHOSTn:9054

Load-balancing method: round-robin

11.6.1 Preventing Timeouts for SQLNet Connections

Much of the EDG production deployment involves firewalls. Because database connections are made across firewalls, Oracle recommends that the firewall be configured so that the database connection is not timed out. For Oracle Real Application Clusters (RAC), the database connections are made on Oracle RAC VIPs and the database listener port. You must configure the firewall to not time out such connections. If such a configuration is not possible, set the*SQLNET.EXPIRE_TIME=n* parameter in the ORACLE_HOME/network/admin/sqlnet.ora file on the database server, where n is the time in minutes. Set this value to less than the known value of the timeout for the network device (that is, a firewall). For RAC, set this parameter in all of the Oracle home directories.

11.6.2 Setting AUTOEXTEND for Tablespaces for Processing More Than 30,000 Files

After processing more than 30,000 files, tablespace does not extend. You must enable AUTOEXTEND for the tablespace when it reaches its limit. The best practice is to set AUTOEXTEND for tablespace before you commence a process to the recommended value. See also Oracle Database Administrator's Guide for more information on autoextending tablespaces.

11.6.3 Auditing

Oracle Fusion Middleware Audit Framework is a new service in Oracle Fusion Middleware 11g, designed to provide a centralized audit framework for the middleware family of products. The framework provides audit service for platform components such as Oracle Platform Security Services (OPSS) and Oracle Web Services. It also provides a framework for JavaEE applications, starting with Oracle's own JavaEE components. JavaEE applications will be able to create application-specific audit events. For non-JavaEE Oracle components in the middleware such as C or JavaSE components, the audit framework also provides an end-to-end structure similar to that for JavaEE applications.

Figure 11-1 is a high-level architectural diagram of the Oracle Fusion Middleware Audit Framework.

Figure 11-1 Audit Event Flow

Description of "Figure 11-1 Audit Event Flow"

The Oracle Fusion Middleware Audit Framework consists of the following key components:

• Audit APIs

  These are APIs provided by the audit framework for any audit-aware components integrating with the Oracle Fusion Middleware Audit Framework. During runtime, applications may call these APIs where appropriate to audit the necessary information about a particular event happening in the application code. The interface allows applications to specify event details such as username and other attributes needed to provide the context of the event being audited.

• Audit Events and Configuration

  The Oracle Fusion Middleware Audit Framework provides a set of generic events for convenient mapping to application audit events. Some of these include common events such as authentication. The framework also allows applications to define application-specific events.

  These event definitions and configurations are implemented as part of the audit service in Oracle Platform Security Services. Configurations can be updated through Enterprise Manager (UI) and WLST (command-line tool).

• Audit Bus-stop

  Bus-stops are local files containing audit data before they are pushed to the audit repository. In the event where no database repository is configured, these bus-stop files can be used as a file-based audit repository. The bus-stop files are simple text files that can be queried easily to look up specific audit events. When a DB-based repository is in place, the bus-stop acts as an intermediary between the component and the audit repository. The local files are periodically uploaded to the audit repository based on a configurable time interval.

• Audit Loader

  As the name implies, audit loader loads the files from the audit bus-stop into the audit repository. In the case of platform and JavaEE application audit, the audit loader is started as part of the JavaEE container start-up. In the case of system components, the audit loader is a periodically spawned process.

• Audit Repository

  Audit Repository contains a pre-defined Oracle Fusion Middleware Audit Framework schema, created by Repository Creation Utility (RCU). Once configured, all the audit loaders are aware of the repository and upload data to it periodically. The audit data in the audit repository is expected to be cumulative and will grow overtime. Ideally, this should not be an operational database used by any other applications - rather, it should be a standalone RDBMS used for audit purposes only. In a highly available configuration, Oracle recommends that you use an Oracle Real Application Clusters (RAC) database as the audit data store.

• Oracle Business Intelligence Publisher

  The data in the audit repository is exposed through pre-defined reports in Oracle Business Intelligence Publisher. The reports allow users to drill down the audit data based on various criteria. For example:

  • Username

  • Time Range

  • Application Type

  • Execution Context Identifier (ECID)

For more introductory information for the Oracle Fusion Middleware Audit Framework, see the "Introduction to Oracle Fusion Middleware Audit Framework" chapter in the Oracle Fusion Middleware Security Guide.

For information on how to configure the repository for Oracle Fusion Middleware Audit Framework, see the "Configuring and Managing Auditing" chapter in the Oracle Fusion Middleware Security Guide.

The EDG topology does not include Oracle Fusion Middleware Audit Framework configuration. The ability to generate audit data to the bus-stop files and the configuration of the audit loader will be available once the products are installed. The main consideration is the audit database repository where the audit data is stored. Because of the volume and the historical nature of the audit data, it is strongly recommended that customers use a separate database from the operational store or stores being used for other middleware components.