| Oracle® Collaboration Suite High Availability Configuration Release 2 (9.0.4) for UNIX and Linux Part Number B15612-01 |
|
|
View PDF |
| Oracle® Collaboration Suite High Availability Configuration Release 2 (9.0.4) for UNIX and Linux Part Number B15612-01 |
|
|
View PDF |
This chapter provides instructions on installing and configuring Oracle Collaboration Suite for high availability. It contains the following sections:
Section 3.1, "Overview of Installation and Configuration for High Availability"
Section 3.3, "Installing the Infrastructure in a Cold Failover Cluster"
Section 3.5, "Configuring the Oracle9iAS Single Sign-On Server to Use a Load Balancer"
Section 3.8, "Installing and Configuring Oracle Calendar Server and Oracle Files Domain Controller"
Section 3.9, "Installing and Configuring Oracle Collaboration Suite Middle Tiers"
Section 3.10, "Setting Up a Load Balancer for the Oracle Collaboration Suite Middle Tiers"
Section 3.12, "Addressing Firewall Configuration Considerations"
At a high level, the deployment of Oracle Collaboration Suite involves the following steps:
Implementing preinstallation recommendations
Installing the Infrastructure in an Oracle9iAS Cold Failover Cluster high-availability configuration
Installing and configuring Oracle9iAS Single Sign-On, Oracle Internet Directory, and Oracle Delegated Administration Services on the Middle Tiers
Installing and configuring the Information Storage database
Installing and configuring Oracle Calendar Server and Oracle Files Domain Controller using Oracle9iAS Cold Failover Cluster
Deploying the Oracle Collaboration Suite Middle Tiers
|
Note: Step 3 and Step 6 refer to different middle tiers. The Oracle9iAS Single Sign-On server and Oracle Delegated Administration Services are relocated to middle tiers that are different from the Oracle Collaboration Suite Middle Tiers. The applications are deployed on the Oracle Collaboration Suite Middle Tiers. |
Each of these steps involves multiple setup and configuration changes. To reduce the effort required to rectify any mistake you may make, back up your work after every step before proceeding to the next step.
To back up your work, first shut down each tier in the reverse order of deployment. This means that you must first shut down the Oracle Collaboration Suite Middle Tiers, then shut down the Oracle Calendar Server and Oracle Files Domain Controller tier, and so on. To shut down these tiers, use the scripts provided in Appendix B.
Then, as displayed in the example in Appendix C, log in as root, and back up the entire file system. You must log in as root when you back up the file system so that root permissions and setuid bits on certain binaries are preserved.
For the Information Storage database on store1 and store2, use the script listed in Appendix C to perform an Oracle Database Recovery Manager backup to disk.
|
Note: In the remaining sections of this document, the Infrastructure host and the Oracle Calendar Server and Oracle Files Domain Controller host are referred to by their virtual host namesinfraha and caldcha, respectively. This indicates the node in the cluster, either infra1 or infra2, on which the addressed component is running.
For example, if the Infrastructure is deployed on |
Before you start installing and setting up the architecture, it is important to prepare the various elements that constitute the Oracle Collaboration Suite system, such as the load balancers and firewalls. You also need to determine the system kernel configuration, the amount of space required for each installation, and the amount of space required to back up each installation.
|
See Also: For information about platform-specific installation planning requirements, refer to the platform-specific installation and configuration guides at |
Implementing preinstallation recommendations involves the following steps:
Section 3.2.1, "Preparing Information to Be Specified During the Installation"
Section 3.2.4, "Configuring Information Storage and Raw Volumes"
Use Table 3-1 as a reference during the installation. You will need to provide this information at various points during the installation.
Table 3-1 Information to Be Specified During the Installation
| Role | Physical Host Name | Virtual Host Name or Load Balancer Virtual Server Name | Port Number |
|---|---|---|---|
| Infrastructure hosts | infra1.oracle.com and infra2.oracle.com |
infraha.oracle.com |
Oracle Internet Directory port 4032 |
| Oracle9i Application Server Single Sign-On and Oracle Delegated Administration Services hosts | ssomt1.oracle.com and ssomt2.oracle.com |
ssolb.oracle.com (load balancer) |
80 |
| Information Storage hosts | store1.oracle.com and store2.oracle.com |
Database listener 1521 | |
| Oracle Files Domain Controller |
infra2.oracle.com and infra1.oracle.com |
caldcha.oracle.com |
|
| Oracle Calendar Server |
infra2.oracle.com and infra1.oracle.com |
caldcha.oracle.com |
Oracle Calendar Server 5730 |
| Middle Tiers | ocsmt1.oracle.com and ocsmt2.oracle.com |
ocslb.oracle.com (load balancer) |
80 |
Before starting the installation, it is important to plan the storage requirements for all the tiers in the setup. When using hardware clusters, you also need to plan the requirements for the underlying disk groups and volumes that are used by the file systems for the software.
Review the kernel parameter settings to ensure that they meet Oracle Collaboration Suite installation requirements. If these requirements are not met, then you may encounter errors during installation or operational errors after installation.
|
See Also: For information about system kernel configuration, refer to the section on preparing for installation in Oracle Collaboration Suite Installation and Configuration Guide for Solaris. |
In the configuration described in this document, the Information Storage database is deployed on a two-node cluster that is based on Oracle Real Application Clusters. The Oracle Real Application Clusters database on Solaris requires raw or shared volumes for storing data files. On some platforms, such as Linux, you can use a supported cluster file system instead of raw volumes.
If a cluster file system is not used, then depending on the shared storage attached to the cluster and the volume manager on the system, you must create the volumes that will be required later for the Oracle Real Application Clusters database. The Information Storage installer relies on the existence of certain volumes. Before you install Information Storage, you must create the following volumes:
You must create the volumes required for Oracle Real Application Clusters. The names and sizes of the required tablespaces are listed in Appendix D.The Information Storage installer does not create all the tablespaces that are required. Before you can start the Middle Tier installation, you must run certain SQL scripts to create the missing tablespaces.
If you are creating locally managed custom tablespaces, then the default options are recommended. You must not specify automatic segment space management for the tablespaces, because almost all Oracle Files data is stored as large objects (LOBs) and automatic segment space management does not support LOBs. In the installation described in this document, a single tablespace, ofiles, is used. The command for creating this tablespace is as follows:
CREATE TABLESPACE ofiles
DATAFILE '/dev/vx/rdsk/ocsstore-dg/ifs.dbf' SIZE 1000m REUSE;
The names of Information Storage tablespaces and their default storage parameters are mentioned in the $ORACLE_HOME/oes/install/sql/tblspc.sql script. The corresponding CREATE commands for Oracle Email tablespace raw volumes are given in Appendix D.
For instructions about implementing the Oracle9iAS Cold Failover Cluster solution on Solaris, Linux, or HP-UX, refer to the corresponding Oracle9i Application Server Infrastructure: Improved Availability with Hardware Clusters document at
http://www.oracle.com/technology/products/ias/hi_av/9ias_cfc.pdf
For the Infrastructure installation, note the following exceptions to the setup procedure:
Follow the instructions given in Oracle9i Application Server Infrastructure: Improved Availability with Hardware Clusters up to the step that precedes the step involving running the root.sh script.
Before you run the root.sh script, perform the following steps:
Run the following command to stop all processes managed by opmn:
$ORACLE_HOME/opmn/bin/opmnctl stopall
|
Note: At this stage of the installation, only theopmn and dcm daemons should be running. These daemons are shut down when you perform this step. |
Edit the $ORACLE_HOME/Apache/Apache/bin/apachectl file.
In this file, add the entries for LD_PRELOAD and LHOSTNAME as described in Oracle9iAS Infrastructure: Improved Availability with Hardware Clusters.
For example:
LHOSTNAME=infraha LD_PRELOAD=libloghost.so.1 export LHOSTNAME LD_PRELOAD
Edit the $ORACLE_HOME/opmn/conf/opmn.xml file.
In this file, add the lines for dcm-daemon as displayed in the following example.
<custom gid="dcm-daemon" numProcs="1" noGidWildcard="true"> <start path="/infracfc/oracle/902infra/dcm/bin/dcmctl daemon -logdir /infracfc/oracle/902infra/dcm/logs/daemon_logs"/> <stop path="/infracfc/oracle/902infra/dcm/bin/dcmctl shutdowndaemon"/> <environment> <prop name="DISPLAY" value="infraha.oracle.com:0.0"/> <prop name="LD_LIBRARY_PATH" value="/infracfc/oracle/902infra/lib"/> <prop name="LHOSTNAME" value="infraha"/> <prop name="LD_PRELOAD" value="libloghost.so.1"/> </environment> </custom>
In this example: ORACLE_HOME=/infracfc/oracle/902infra
Change the following environment values:
DISPLAY=virtual_hostname:display.screenLD_LIBRARY_PATH=$ORACLE_HOME/libLHOSTNAME=virtual_hostname (short name, not fully qualified)|
Note: Depending on your platform, you also need to perform the following steps:
|
Run the following command to start the opmn daemon:
$ORACLE_HOME/opmn/bin/opmnctl start
Run the following command to start the dcm daemon :
$ORACLE_HOME/opmn/bin/opmnctl startproc type=custom gid=dcm-daemon
Run the root.sh script as instructed by the installer, and proceed with the installation.
After the installation is completed, run the following command to stop everything:
$ORACLE_HOME/opmn/bin/opmnctl stopall
This command will stop Oracle Internet Directory, shut down the database, and stop the listener.
Edit the $ORACLE_HOME/opmn/conf/opmn.xml file.
In this file, add lines for OC4J_DAS as displayed in the following example:
<oc4j maxRetry="3" instanceName="OC4J_DAS" gid="OC4J_DAS" numProcs="1">
<config-file path="/u01/app/orainf/product/infra904/j2ee/OC4J_DAS/config/server.xml"/>
<java-option value="-server -Xincgc -Xnoclassgc -Xmx256m "/>
<oc4j-option value="-properties"/>
<port ajp="3001-3100" jms="3201-3300" rmi="3101-3200"/>
<environment>
<prop name="DISPLAY" value="infraha.oracle.com:0.0"/>
<prop name="LD_LIBRARY_PATH" value="/infracfc/oracle/902infra/lib"/>
<prop name="LHOSTNAME" value="infraha"/>
<prop name="LD_PRELOAD" value="libloghost.so.1"/>
</environment>
</oc4j>
In this example: ORACLE_HOME=/infracfc/oracle/902infra
Restart the listener, database, Oracle Internet Directory, and the processes managed by opmn.
|
Note: The Oracle9iAS Cold Failover Cluster document mentions the use of a reregistration script,reregister.sh, to reregister a node after a cold cluster node failover. Each time this script is run, it creates a new partner application. This buildup of partner applications is harmless, but it can clutter things. You can prevent this buildup of partner applications by saving a copy of the $ORACLE_HOME/Apache/Apache/conf/osso/osso.conf file after the initial registration for each node. |
The following is an example of the steps to be performed before starting Oracle Internet Directory and the opmn processes:
Make a copy of the $ORACLE_HOME/Apache/Apache/conf/osso/osso.conf file on node 1 (infra1).
To do this, run the following command:
cp $ORACLE_HOME/Apache/Apache/conf/osso/osso.conf \ $ORACLE_HOME/Apache/Apache/conf/osso/osso.conf.infra1
Follow the complete procedure for setting up the environment, and then test the Infrastructure failover process. When the first failover occurs, follow the reregistration steps given in the Oracle9iAS Cold Failover Cluster document.
After node 2, infra2, is failed over to and the new osso.conf file is re-created by the reregistration procedure, save a copy of this osso.conf file.
To do this, run the following command:
cp $ORACLE_HOME/Apache/Apache/conf/osso/osso.conf \ $ORACLE_HOME/Apache/Apache/conf/osso/osso.conf.infra2
For subsequent failovers, use the Infrastructure startup script given in Appendix B. This script includes the command for copying the saved osso.conf file.
Test the Oracle9i Application Server Single Sign-On administration application and the partner application Oracle Delegated Administration Services by using the following URLs:
http://virtualhostname:port/pls/orassohttp://infraha.oracle.com:7777/pls/orassohttp://virtualhostname:port/oiddashttp://infraha.oracle.com:7777/oiddasAfter testing the pls/orasso URL, log in to the Oracle9iAS Single Sign-On server, click SSO Server Administration, and then click Administer Partner Application. Check the partner applications that have been registered.
There should be two partner applications: the Oracle9iAS Single Sign-On server and the HTTP Oracle9iAS Single Sign-On (mod_osso) module on the Infrastructure. Note the site_id of the HTTP partner application.
After failover takes place, reset the Oracle9iAS Single Sign-On instance password and reregister the mod_osso partner application.
The steps for doing this are defined in the Oracle9iAS Cold Failover Cluster document. After the reregistration, log in to pls/orasso and delete the old HTTP partner application whose site_id you had recorded in the previous step.
|
Note: If theorasso.conf file was saved after the initial reregistration, then instead of reregistering and deleting the old partner application, replace the current osso.conf file with the saved osso.conf file, osso.conf.infra1. |
Perform Step 10 to test the Oracle9iAS Single Sign-On (orasso) and Oracle Delegated Administration Services (oiddas) logins.
When you perform the instructions described in Section 3.3, the Infrastructure and all of its components are installed in an Oracle9iAS Cold Failover Cluster environment. You must move the Oracle9iAS Single Sign-On server and Oracle Delegated Administration Services to separate nodes in the DMZ.
In the setup described in this chapter, the nodes for hosting the Oracle9iAS Single Sign-On server and Oracle Delegated Administration Services are ssomt1.oracle.com and ssomt2.oracle.com. A load-balancer virtual server ssolb.oracle.com forms the front end of these nodes.
This part of the deployment involves installing the Infrastructure and Middle Tier on ssomt1.oracle.com and on ssomt2.oracle.com.
During the installation, deselect all the components. This will install the application server with minimum features, such as the HTTP Server and the mods (mod_osso, modplsql, and mod_oc4j) on the two nodes.
When prompted for the location of Oracle9i Application Server Single Sign-On and Oracle Internet Directory during the installation of the Middle Tiers, specify the virtual host name infraha.oracle.com. This host name is the same as that used for the Infrastructure cold failover cluster installation.After you complete both installations, reconfigure Oracle9iAS Single Sign-On and Oracle Delegated Administration Services to be accessed from the two Middle Tiers in the DMZ through the load balancer virtual server ssolb.oracle.com. To do this, you must first move the Oracle9iAS Single Sign-On server to the Middle Tier. Note that this changes access to the Oracle9iAS Single Sign-On server from the Infrastructure, infraha.oracle.com, to the Middle Tier. However, the database still resides on the Infrastructure host and can be accessed through modplsql at infraha.oracle.com:1521:iasdb by using orasso/password.
The following are additional steps that you need to perform for moving Oracle9iAS Single Sign-On and Oracle Delegated Administration Services to the DMZ:
The installation can be done with the HTTP port set to the default port, 7777. However, in this setup, you need to change the default port from 7777 to 80. Also, because the HTTP Server will be accessed through the load balancer, change the ServerName value to the load balancer virtual server name. In this example, this virtual server name is ssolb.oracle.com.
To change the default port, first stop the HTTP Server on the two Middle Tiers by running the following command:
$ORACLE_HOME/opmn/bin/opmnctl stopall
Next, make the following changes in the $ORACLE_HOME/Apache/Apache/conf/httpd.conf file:
| Original | Change To |
|---|---|
| Port 7777 | Port 80 |
ssomt1.oracle.com
|
ssolb.oracle.com |
| Listen 7778 | Listen 80 |
This step configures the HTTP Servers on the Oracle9iAS Single Sign-On Middle Tiers to listen at the effective URL, which is ssolb.oracle.com.
To update Distributed Configuration Management, run the following command:
$ORACLE_HOME/dcm/bin/dcmctl updateConfig -ct ohs
For the Oracle9iAS Single Sign-On Middle Tiers, you will not be using Oracle9i Application Server Web Cache. Shut down Web Cache by running the following command:
webcachectl stop
On the two Oracle9iAS Single Sign-On Middle Tiers, set up database access for modplsql in the $ORACLE_HOME/Apache/modplsql/conf/dads.conf file. This file is used by the HTTP Server through modplsql to access the Oracle9iAS Single Sign-On server database.
To set up database access for modplsql:
Determine the Infrastructure database orasso password.
This step requires the use of the orasso schema password, which is in the dads.conf file. To get this password, first connect to Oracle Internet Directory and then search for the orasso password entry. This can be done through the oidadmin GUI interface or by running the following command (all on one line):
ldapsearch -h host -p oid-port -D "cn=orcladmin" -w oidpwd \ -b "cn=IAS Infrastructure Databases,cn=IAS,cn=Products,cn=OracleContext" \ -s sub "orclResourceName=orasso" orclpasswordattribute
In this command:
host=infraha.oracle.comoid-port=4032oidpwd=orcladmin password, which you specified during installationTest the orasso password by running the following command to log in to the database on the Infrastructure host:
sqlplus orasso/password # This is the password returned by the ldapsearch command
Copy the dads.conf file from the Infrastructure to the Oracle9i Application Server Single Sign-On Middle Tiers.
Copy the contents of the $ORACLE_HOME/Apache/modplsql/conf/dads.conf file on the Infrastructure host to the dads.conf file on ssomt1.oracle.com and ssomt2.oracle.com.
Replace the password in the dads.conf file.
In each Oracle9i Application Server Single Sign-On Middle Tier dads.conf file, which is located in the $ORACLE_HOME/Apache/modplsql/conf/ directory, replace the value of PlsqlDatabasePassword with the orasso password retrieved in Step 1.
The procedure for configuring the Oracle9iAS Single Sign-On server to use a load balancer can be divided into the following steps:
Because the two Oracle9iAS Single Sign-On Middle Tiers will each have a load balancer as their front end, these load balancers will provide the URLs used to access Oracle9iAS Single Sign-On server.
To modify the Oracle9iAS Single Sign-On settings of the Oracle9iAS Single Sign-On URL:
Check the partner application entries in Oracle9iAS Single Sign-On.
Before changing the Oracle9iAS Single Sign-On server URL, check the partner application entries in Oracle9iAS Single Sign-On. To do this, log in to the database as the orasso user and run the following query on the Infrastructure host:
SQL> SELECT SITE_NAME,SUCCESS_URL,FAILURE_URL,HOME_URL,LOGOUT_URL FROM wwsso_papp_configuration_inf_t ORDER BY site_id;
The following entries should be displayed as the results of this query:
mod_osso) entry for the Infrastructure installationmod_osso)entry for ssomt1.oracle.commod_osso)entry for ssomt2.oracle.comThe entry for the Oracle9iAS Single Sign-On server will have the URLs pointing to infraha.oracle.com.
Run the following command to change the Oracle9iAS Single Sign-On server URL to point to the load balancer URL:
$ORACLE_HOME/sso/bin/ssocfg.sh http ssolb.oracle.com 80
|
Note: On HP-UX, setSHLIB_PATH=$ORACLE_HOME/lib32 before running the command. |
Log in to the database as the orasso user, and run the following query to verify that the Oracle9iAS Single Sign-On server URL has been modified:
SQL> SELECT SITE_NAME,SUCCESS_URL,FAILURE_URL,HOME_URL,LOGOUT_URL FROM wwsso_papp_configuration_inf_t ORDER BY site_id;
The first entry for the Oracle9iAS Single Sign-On server will be modified with the URL containing the load balancer virtual server name, ssolb.oracle.com, that was used with the ssocfg.sh script.
As mentioned in the preceding section, there are four partner applications registered with the Oracle9iAS Single Sign-On server. After running the ssocfg.sh script to relocate the Oracle9iAS Single Sign-On server, you must reregister the partner applications with Oracle9iAS Single Sign-On. To do this:
Modify the partner application in the database.
Because Oracle9iAS Single Sign-On on both the Middle Tiers will be accessed through the load balancer, only one entry needs to exist in the database. To make this change, run the following Oracle9iAS Single Sign-On registrar script (all on one line):
$ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/sso/lib/ossoreg.jar \ -oracle_home_path /ssomid/app/oracle/product/sso \ -host infraha.oracle.com \ -port 1521 \ -sid iasdb \ -site_name sso.ssolb.oracle.com \ -success_url http://ssolb.oracle.com:80/osso_login_success\ -logout_url http://ssolb.oracle.com:80/osso_logout_success \ -cancel_url http://ssolb.oracle.com:80 \ -home_url http://ssolb.oracle.com:80 \ -config_mod_osso TRUE -u root \ -sso_server_version v1.2
|
Note: On HP-UX, setSHLIB_PATH=$ORACLE_HOME/lib32 before running this script. |
Run this script from one of the Middle Tiers. This will create a new partner application in the database with the load balancer URL and update the $ORACLE_HOME/Apache/Apache/conf/osso/osso.conf file on that Middle Tier. This file must also be updated for the second Middle Tier. However, there is no need to reregister with the database, because an entry with the load balancer has already been created.
Check the mod_osso.conf file in the Middle Tiers.
Log in to the database with orasso/password and check the partner application table of the Oracle9iAS Single Sign-On server. There should be an additional entry for HTTP/mod_osso with the virtual server name of the load balancer.
To verify that the additional entry is created, run the following query:
SQL> SELECT * FROM wwsso_papp_configuration_inf_t ORDER BY site_id;
Start the HTTP Server.
To start the HTTP Server on the first Middle Tier, where it was reregistered with the load balancer URL, run the following commands:
$ORACLE_HOME/opmn/bin/opmnctl start $ORACLE_HOME/opmn/bin/opmnctl startproc type=ohs
Set up the load balancer and shut down ssomt2.oracle.com, so that the load balancer does not direct any traffic to that node.
Create the osso_clear.txt file.
To do this:
Log in to Oracle9iAS Single Sign-On at
http://ssolb.oracle.com/pls/orasso
Click SSO Server Administration.
Click Administer Partner Applications.
All the partner applications will be listed on this page.
Click the Edit icon for the partner application that was registered with the load balancer URL in the previous steps to display the following values in a clear-text file:
cipher_key=Value of the encryption key for this partner applicationsite_id=value of IDsite_token=value of Tokenlogin_url=value of login URLcancel_url=value of HOME URLsso_server_version=1.2sso_timeout_cookie_name=SSO_ID_TIMEOUTCopy these values into a clear-text file named osso_clear.txt in the $ORACLE_HOME/Apache/Apache/conf/osso/ directory on ssomt2.
The following are sample contents of the osso_clear.txt file after the required changes have been made:
cipher_key=2419FEED96D8FA4B site_id=1326 site_token=K1H0R45Y1326 login_url=http://ssolb.oracle.com/pls/orasso/orasso.wwsso_app_admin.ls_login logout_url=http://ssolb.oracle.com:80/osso_logout_success cancel_url=http://ssolb.oracle.com:80 sso_timeout_cookie_name=SSO_ID_TIMEOUT
Regenerate an obfuscated osso.conf file from the osso_clear.txt file by running the following command:
$ORACLE_HOME/Apache/Apache/bin/iasobf oss_clear.txt osso.conf root
The iasobf utility enables you to generate an obfuscated wallet password from a clear-text password.
Log in to Oracle9iAS Single Sign-On, and delete the entries for ssomt1 and ssomt2.
Only one partner application entry with ssolb is required.
Log in to the Oracle9iAS Infrastructure database as the orasso user, and update the Oracle9iAS Single Sign-On server configuration table so that a request coming from ssomt1 or ssomt2 is accepted, even though the URL is ssolb.oracle.com.
To do this, run the following commands:
SQL> UPDATE wwsec_enabler_config_info$ SET url_cookie_ip_check='N' ; SQL> commit;
Close down access to ssomt1 so that the load balancer points to ssomt2.
Log in to the Oracle9iAS Single Sign-On server at http://ssolb.oracle.com/pls/orasso as the orcladmin user.
The load balancer will divert this request to ssomt2. This request will access the pls/orasso directive in the dads.conf file and connect to the Oracle9iAS Single Sign-On server (Infrastructure database) through the entries in the dads.conf file and the orasso login.
Enable both the Oracle9iAS Single Sign-On Middle Tiers, ssomt1.oracle.com and ssomt2.oracle.com, from the load balancer.
Test the Oracle9iAS Single Sign-On logins from both the nodes.
After you move the Oracle9iAS Single Sign-On server to the middle tiers ssomt1 and ssomt2, you also need to move the OC4J_DAS instance from the Infrastructure tier to these middle tiers.
Just as you changed access to the Oracle9iAS Single Sign-On server through the load balancer and modplsql, this procedure involves changing the access to the OC4J_DAS instance residing on the Infrastructure. To do this:
Configure $ORACLE_HOME/Apache/Apache/conf/mod_oc4j.conf for oiddas access in the Oracle9iAS Single Sign-On middle tier.
To change the mount configuration OC4J_DAS directive in the mod_oc4j.conf file to point to the OC4J_DAS instance on the Infrastructure, you need to change:
Oc4jMount /oiddas OC4J_DAS Oc4jMount /oiddas/* OC4J_DAS
to:
Oc4jMount /oiddas instance://iasdb.infraha.oracle.com:OC4J_DAS Oc4jMount /oiddas/* instance://iasdb.infraha.oracle.com:OC4J_DAS
Here, iasdb.infraha.oracle.com is the instance name of the Infrastructure as listed in the Enterprise Manager targets or displayed by running the dcmctl listInstances command.
Log in to Oracle Directory Manager (oidadmin) as orcladmin/password. Then:
Click cn=Entry Management.
Click cn=OracleContext.
Click cn=Products.
Click cn=DAS.
Click cn=OperationURLs.
Change the orcldasurlbase attribute from the Infrastructure HTTP URL and port to the load balancer URL and port, which is 80 in this example.
Edit the opmn.xml file on the Infrastructure.
Update the Apache Java Protocol (AJP) port numbers for the specific ones that will be opened in the firewall, instead of the range of ports that are used by default.
Restart the Infrastructure and Oracle9iAS Single Sign-On Middle Tiers.
To validate the Oracle Delegated Administration Services URL change, access the partner application oiddas from the Middle Tier by using the following URL:
http://ssolb.oracle.com/oiddas
This connects to the OC4J_DAS instance on the Infrastructure through the Oc4jMount directive in the mod_oc4j.conf file.
By performing steps 2 through 5, you are updating the Oracle Internet Directory entry for the location of Oracle Delegated Administration Services.
During the installation, Information Storage is based on Oracle9i Database Release 2 (9.2.0.3) and contains the schemas and tablespaces for all the Oracle Collaboration Suite applications. Setting up Information Storage involves configuring the Information Storage database on Oracle Real Application Clusters and outlining the preparation for the two nodes of the cluster for the Information Storage installation.
Remember that Oracle Calendar Server does not store any data in this database. Instead, it uses the file system on the Oracle Calendar Server node, caldcha.oracle.com, for its database.
Before you perform the steps described in this section, verify that you have performed all the preinstallation steps. It is also recommended that you upgrade the Information Storage database to Oracle9i Database Release 2 (9.2.0.5). Note that this upgrade has not been tested, and you must read the instructions on the MetaLink Web site before performing the upgrade.
The information within this section is meant for use on the Solaris platform. For information about the steps to install Information Storage in Oracle Real Application Clusters on Linux, refer to MetaLink note 281677.1.
In Oracle Collaboration Suite Release Notes Release 2 (9.0.4.1) for Solaris, it is mentioned that Oracle Real Application Clusters cannot be enabled with a pre-seeded Oracle Collaboration Suite Release 2 Information Storage database. However, you can enable Oracle Real Application Clusters with a pre-seeded Oracle Collaboration Suite Release 2 Information Storage database by performing the steps described in this section.
This section discusses the following high-level steps involved in enabling Oracle Real Application Clusters with a pre-seeded Oracle Collaboration Suite Release 2 Information Storage database:
Section 3.7.2, "Creating the Database with the Required Tablespaces"
Section 3.7.3, "Unlocking the Oracle Web Conferencing Real-Time Collaboration Schemas"
Section 3.7.4, "Creating Tablespaces That Are Not Created by the Database Configuration Assistant"
Section 3.7.5, "Setting the MAX_COMMIT_PROPAGATION_DELAY Parameter"
During installation, the installer uses the Database Configuration Assistant for creating the Oracle Real Application Clusters database. Unless you are using a cluster file system , this assistant will require raw volumes for the data files. Verify that you have created the required volumes as described in Section 3.2. Then create a file with the tablespace name and the corresponding data file name, dbca.txt, as follows:
dbca.txt (TABLESPACE_NAME=file-name)
system=/dev/vx/rdsk/ocsstore-dg/system01.dbf temp=/dev/vx/rdsk/ocsstore-dg/temp01.dbf undotbs1=/dev/vx/rdsk/ocsstore-dg/undotbs01.dbf undotbs2=/dev/vx/rdsk/ocsstore-dg/undotbs02.dbf control1=/dev/vx/rdsk/ocsstore-dg/control01.dbf control2=/dev/vx/rdsk/ocsstore-dg/control02.dbf control3=/dev/vx/rdsk/ocsstore-dg/control03.dbf redo1_1=/dev/vx/rdsk/ocsstore-dg/redo01_01.log redo1_2=/dev/vx/rdsk/ocsstore-dg/redo01_02.log redo1_3=/dev/vx/rdsk/ocsstore-dg/redo01_03.log redo2_1=/dev/vx/rdsk/ocsstore-dg/redo02_04.log redo2_2=/dev/vx/rdsk/ocsstore-dg/redo02_05.log redo2_3=/dev/vx/rdsk/ocsstore-dg/redo02_06.log tools=/dev/vx/rdsk/ocsstore-dg/tools01.dbf users=/dev/vx/rdsk/ocsstore-dg/users01.dbf xdb=/dev/vx/rdsk/ocsstore-dg/xdb01.dbf cwmlite=/dev/vx/rdsk/ocsstore-dg/cwmlite01.dbf drsys=/dev/vx/rdsk/ocsstore-dg/drsys01.dbf EXAMPLE=/dev/vx/rdsk/ocsstore-dg/example01.dbf INDX=/dev/vx/rdsk/ocsstore-dg/indx01.dbf ODM=/dev/vx/rdsk/ocsstore-dg/odm01.dbf spfile=/dev/vx/rdsk/ocsstore-dg/spfilestr.ora
|
See Also: For the names of Information Storage e-mail tablespaces and their default storage parameters, refer to the following script:$ORACLE_HOME/oes/install/sql/tblspc.sql |
Set up the environment variable DBCA_RAW_CONFIG to point to the dbca.txt file. You can use the following command to do this:
export DBCA_RAW_CONFIG=$ORACLE_HOME/dbca.txt
Then run the installer. This will create a database with the tablespaces covered in the preceding section.
During the installation, you must specify the primary Oracle Real Application Clusters node, which is store1 in this case. Later, you will need to modify the database Oracle Internet Directory registration to make it Oracle Real Application Clusters aware.
During the installation, unlock the RTC and RTC_APP schemas. To unlock these schemas, use the Password management tab of the Database Configuration Assistant. If this cannot be done, then connect to the database as sysdba after the installation, and run the following command:
ALTER USER [rtc|rtc_app] ACCOUNT UNLOCK
Note down the SYS and SYSTEM passwords during the installation, because you will need to use these passwords later.
You must create the tablespaces that are not created by the Database Configuration Assistant. This section provides information about these tablespaces.
RTC_BIG_DATA=/dev/vx/rdsk/ocsstore-dg/RTC_BIG_DATA.dbf RTC_DATA=/dev/vx/rdsk/ocsstore-dg/RTC_DATA.dbf RTC_INDEX=/dev/vx/rdsk/ocsstore-dg/RTC_INDEX.dbf RTC_LARGE_DATA=/dev/vx/rdsk/ocsstore-dg/RTC_LARGE_DATA.dbf
For the names of Information Storage tablespaces and their default storage parameters refer to the $ORACLE_HOME/oes/install/sql/tblspc.sql script.
esbigtbl=/dev/vx/rdsk/ocsstore-dg/esbigtbl.dbf esfreqidx=/dev/vx/rdsk/ocsstore-dg/esfreqidx.dbf esfreqtbl=/dev/vx/rdsk/ocsstore-dg/esfreqtbl.dbf ESFREQIDX=/dev/vx/rdsk/ocsstore-dg/esinfreqidx.dbf ESMRLMNR=/dev/vx/rdsk/ocsstore-dg/eslmmr.dbf ESNEWS=/dev/vx/rdsk/ocsstore-dg/esnews.dbf ESORATEXT=/dev/vx/rdsk/ocsstore-dg/esoratext.dbf ESPERFTBL=/dev/vx/rdsk/ocsstore-dg/esperftbl.dbf ESSMLTBL=/dev/vx/rdsk/ocsstore-dg/essmltbl.dbf ESTERSTORE=/dev/vx/rdsk/ocsstore-dg/esterstore.dbf ESTEMP=/dev/vx/rdsk/ocsstore-dg/estemp.dbf
The following is a sample script for creating Oracle Email storage tablespaces:
CREATE TABLESPACE ESBIGTBL DATAFILE '/dev/vx/rdsk/ocsstore-dg/esbigtbl.dbf' SIZE 100m REUSE; CREATE TABLESPACE ESSMLTBL DATAFILE '/dev/vx/rdsk/ocsstore-dg/essmltbl.dbf' SIZE 20m REUSE; CREATE TABLESPACE ESFREQTBL DATAFILE '/dev/vx/rdsk/ocsstore-dg/esfreqtbl.dbf' SIZE 20m REUSE; CREATE TABLESPACE ESFREQIDX DATAFILE '/dev/vx/rdsk/ocsstore-dg/esfreqidx.dbf' SIZE 10m REUSE; CREATE TABLESPACE ESINFREQIDX DATAFILE '/dev/vx/rdsk/ocsstore-dg/esinfreqidx.dbf' SIZE 10m REUSE; CREATE TABLESPACE ESTERSTORE DATAFILE '/dev/vx/rdsk/ocsstore-dg/esterstore.dbf' SIZE 20m REUSE; CREATE TABLESPACE ESPERFTBL DATAFILE '/dev/vx/rdsk/ocsstore-dg/esperftbl.dbf' SIZE 20m REUSE; CREATE TABLESPACE ESORATEXT DATAFILE '/dev/vx/rdsk/ocsstore-dg/esoratext.dbf' SIZE 20m REUSE; CREATE TABLESPACE ESNEWS DATAFILE '/dev/vx/rdsk/ocsstore-dg/esnews.dbf' SIZE 10m REUSE; CREATE TABLESPACE ESMRLMNR DATAFILE '/dev/vx/rdsk/ocsstore-dg/eslmmr.dbf' SIZE 50m REUSE; CREATE TEMPORARY TABLESPACE ESTEMP TEMPFILE '/dev/vx/rdsk/ocsstore-dg/estemp.dbf' SIZE 50M;
You can use the default USERS tablespace that is listed during the Oracle Files installation. However, it is recommended that you create separate tablespaces for the Oracle Files installation.
|
See Also: Oracle Files Planning Guide for information about the recommended Oracle Files tablespace configuration |
To ensure that commits made by one connection to one database instance are immediately visible to a connection against the other database instance, you must set the MAX_COMMIT_PROPAGATION_DELAY parameter to 1. The default setting of 700, which is 7 seconds, needs to be changed because it will not work. Resetting this parameter requires restarting the Information Storage database instances.
|
See Also: MetaLink note 259454.1 |
Due to a known issue documented under bug 3098122, three files do not get copied to the remote Oracle Real Application Clusters nodes. You must manually transfer these files to the remote Oracle Real Application Clusters nodes. These files are in the $ORACLE_HOME/bin directory. On Solaris, these files are named dbsnmp, oidpasswd, and oradism. You can use either a remote copy command or perform a binary FTP operation.
Set up the Oracle Calendar Server and the Oracle Files Domain Controller components on the same cluster as the Infrastructure but on the second node, infra2, as displayed in Figure 2-1. Use a mount point that is different from the Infrastructure Oracle home mount point. You must use a different operating system user, for example, calendar.
To install Oracle Calendar Server and Oracle Files Domain Controller:
Set up Library Interpositioning.
Follow the Oracle9iAS Cold Failover Cluster document to set up Library Interpositioning, exactly the way it was done for the Infrastructure installation. Because Oracle Calendar Server and Oracle Files Domain Controller use the same cluster that was used for the Infrastructure, Library Interpositioning should have already been set up on this node. Note that a different virtual host name, caldcha.oracle.com, is used for this node.
When setting up Library Interpositioning, you must apply the following changes to the instructions given in Section 3.3:
ORACLE_HOME=/caldccfc/oracle/902caldc
The virtual host name is caldcha, instead of infraha
OPMN is not required on this node
Verify the Library Interpositioning setup.
Leave only a single instance of the Information Storage database running. Shut down all other Information Storage database instances.
If there is more than one instance of the Information Storage database, then the Files Configuration Assistant, ifsca, will fail. This is because the assistant uses the JDBC thin driver.
Install Oracle Calendar Server and Oracle Files Domain Controller in the same Oracle home. Use the virtual host name, caldcha.oracle.com, for the host name during this installation.
During the installation, select Oracle Calendar Server and Oracle Files on the Select Components screen.
Select the default node ID of 1 for Oracle Calendar Server. Enter values for the Host (virtual host name, for example, caldcha.oracle.com), Port (usually 5730), and Node-ID (1) for Oracle Calendar Server.
During the Oracle Files installation, select Domain Controller, and deselect HTTP node and Regular node.
During the Oracle Files Domain Controller installation, specify the schema and tablespace for Oracle Files. It is recommended that you do not use the default tablespace, USERS, when prompted by ifsca. Select the Oracle Files tablespace, which is ofiles in the example in this document, for all objects, such as tables and indexes. The tablespaces must exist so that they can be selected during the installation.
|
See Also: Oracle Files Planning Guide for more information about Oracle Files database sizing recommendations |
For a cold failover of Oracle Calendar Server to work correctly, you must ensure that the virtual host name is used in the main configuration file of Oracle Calendar Server, $ORACLE_HOME/ocal/misc/unison.ini. During the installation, the unidas section of the unison.ini file is set to the local host. To change the local host name to the virtual host name:
Shut down Oracle Calendar Server by running the following command:
$ORACLE_HOME/ocal/bin/unistop
In the local-host.unidas line of the unison.ini file, replace the local host name with the virtual host name. The following illustrates these changes for the configuration described in this document:
| Original | Change To |
|---|---|
[infra1,unidas] |
[caldcha,unidas] |
numconnect = 50 |
numconnect = 50 |
enable = TRUE |
enable = TRUE |
Restart Oracle Calendar Server by running the following command:
$ORACLE_HOME/ocal/bin/unistart
Add a line for the DatabaseUrl element in the $ORACLE_HOME/ifs/common/registry.xml file, as displayed in the following example:
<Instances>
<Instance>
<Domain>ifs://store1.oracle.com:1522:str.oracle.com:IFS</Domain>
<DomainType>files</DomainType>
<Registered>1099611880481</Registered>
<LastModified>1099612384746</LastModified>
<LastStarted>1099682252758</LastStarted>
<DatabaseUrl>jdbc:oracle:oci8:@str.oracle.com</DatabaseUrl>
<Ports/>
</Instance>
</Instances>
In this example, the line added for the DatabaseUrl element points to the database connection string str.oracle.com. This connection string must include the names of both instances of the Oracle Real Application Clusters database. It must also exist in the tnsnames.ora file as displayed in the following entry from the file:
STR.ORACLE.COM =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = store1.oracle.com)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = store2.oracle.com)(PORT = 1521))
(LOAD_BALANCE = yes)
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = str)
)
(FAILOVER_MODE=
(TYPE=select)
(METHOD=basic)
(RETRIES=20)
(DELAY=15)
)
)
Before proceeding to install the Middle Tier components, you must verify whether Oracle Calendar Server and Oracle Files Domain Controller have been installed successfully. To do this:
Ensure that the environment is set properly by checking the values of variables such as ORACLE_HOME, PATH, LHOSTNAME, and LD_PRELOAD.
Run the following commands:
# Determine the status of the calendar server and nodes $ORACLE_HOME/ocal/bin/unistatus # Shut down all calendar server daemons and services. $ORACLE_HOME/ocal/bin/unistop # Start all calendar server daemons or services that are not already started. $ORACLE_HOME/ocal/bin/unistart
Log in as root, set LD_PRELOAD because the original value will be lost, and then check files status:
LD_PRELOAD=libloghost.so.1; export LD_PRELOAD $ORACLE_HOME/ifs/files/bin/ifsctl status -n $ORACLE_HOME/ifs/files/bin/ifsctl [start|stop]
|
Note: On HP-UX, uselibloghost.sl instead of libloghost.so.1. |
Check the $ORACLE_HOME/install/portlist.ini file, and note the port number for Oracle Calendar Server. This port number will be required later for the Oracle Calendar Server Middle Tier installation.
In the setup described in this document, the ocsmt1.oracle.com and ocsmt2.oracle.com hosts form the Middle Tiers. The load-balancer virtual server ocslb.oracle.com serves as the front end of these Middle Tiers.
This part of the deployment covers the installation of all the Oracle Collaboration Suite components, except Oracle Calendar Server and Domain Controller. These components have already been installed in a high-availability configuration.
This section discusses the following steps involved in installing and configuring the Middle Tiers:
Perform the following steps on both the Middle Tier nodes, ocsmt1 and ocsmt2:
Verify the kernel configuration for the Middle Tiers.
Stop Sendmail if it is running.
Sendmail runs on port 25. Remove Sendmail from the system startup sequence for future system restarts.
Leave only a single instance of the Information Storage database running. Shut down all other Information Storage database instances.
If there is more than one instance of the Information Storage database, then the Files Configuration Assistant, ifsca, will fail. This is because the assistant uses the JDBC thin driver.
Start the installer.
Deselect Calendar Server, and enter the Oracle Calendar Server host, caldcha.oracle.com, and port during the interview phase of the installation.
For Oracle Files, select only Regular Node and HTTP Node. Specify caldcha.oracle.com as the Oracle Files Domain Controller host.
For Oracle9iAS Single Sign-On, specify ssolb.oracle.com:80 as the host:port.
For Oracle Internet Directory, specify infraha.oracle.com:4032 as the host:port.
Enter store1.oracle.com:1521 as the host:port for Information Storage and the SID or the Service that was created when the Information Storage was installed.
At the end of the installation, all the Middle Tier components are installed. Installing the second Middle Tier causes the portlet provider URLs in the portlet repository to be overwritten. When the two Middle Tiers are configured with a load balancer, these URLs will be changed to the load balancer URL.
The remaining topics of this section cover the steps related to Oracle Files and Oracle Email.
To verify the Middle Tier login:
Stop the Oracle Collaboration Suite Middle Tier and Oracle Files Domain Controller domain.
To do this, first running the following command:
$ORACLE_HOME/opmn/bin/opmnctl stopall
Then log in as root, and run the following command:
$ORACLE_HOME/ifs/bin/ifsctl stop
Update the Oracle9iAS Single Sign-On server configuration table for orasso and portal. This involves the following steps:
Get the orasso and portal passwords from Oracle Internet Directory by running the ldapsearch command.
For the portal password, run the following ldapsearch command, which uses portal as the value of orclResourceName:
ldapsearch -h host -p oid-port -D "cn=orcladmin" \ -w oidpwd -b "cn=IAS Infrastructure Databases,\ cn=IAS,cn=Products,cn=OracleContext" \ -s sub "orclResourceName=portal" orclpasswordattribute
Log in to the Infrastructure database as the orasso and portal user, and update the WWSEC_ENABLER_CONFIG_INFO$ table by running the following commands:
SQL> UPDATE wwsec_enabler_config_info$ SET url_cookie_ip_check = 'N'; SQL> commit;
Log in to the Middle Tier URLs, and check sign on.
To configure Oracle Email Information Storage:
From the first Middle Tier, run the $ORACLE_HOME/oes/bin/umconfig.sh script to display the Unified Messaging Configuration screen.
Select the Configure Mail Store option in the installer.
This will configure the mail schemas in the database. The database information must be provided in host:port:sid format. In this case, it is store1:1521:str.
Check the alert.log file on the mail store instance for any database errors. These would be mostly "Lack of database space" errors or "Out of rollback or temp space" errors. Fix these database errors, and rerun the umconfig.sh script.
After the database is populated with mail objects, rerun umconfig.sh on the first Middle Tier and select the Configure the mail middle tier option to configure the Oracle Email Middle Tier.
To configure e-mail, rerun the umconfig.sh script on the second Middle Tier. Because the database is already populated, the umconfig.sh script needs to be run only once on the second Middle Tier.
The Middle Tier configuration will create a listener entry in the listener.ora file. By default this will be in the $ORACLE_HOME/network/admin/listener.ora file. This entry will be for a listener named LISTENER_ES to listen for mail protocols.
Start LISTENER_ES by running the following commands:
id # Get the userid and group id of the Middle Tier user su # switch to root cd $ORACLE_HOME/bin tnslsnr LISTENER_ES -user userid -group group_id &
In this command, userid and group_id are the values returned by the id command.
Check whether the listener is running and listening for all mail protocols by running the following command:
lsnrctl status LISTENER_ES
Modify the database connection string ID in Oracle Internet Directory to enable Oracle Real Application Clusters access. To do this:
Start the oidadmin tool on the Infrastructure host.
Log in as orcladmin.
Click Entry Management, click cn=OracleContext, and then click cn=dbname. Here, dbname is the name of the Information Storage database.
On the right side, the properties of this database are displayed.
One of the properties listed is the connection descriptor for the database, orclnetdescstring, which will have the following format:
(DESCRIPTION=(ADDRESS_LIST= (ADDRESS=(PROTOCOL=TCP)(HOST=store1.oracle.com)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=str)))
Change this to:
(DESCRIPTION=(ADDRESS_LIST= (ADDRESS=(PROTOCOL=TCP)(HOST=store1.oracle.com)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=store2.oracle.com)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=str)))
|
Note: In this example,str is the same as the SERVICE_NAMES database parameter of the store database. It is usually the same as DB_NAME. |
Alternatively, you can use the ldapmodify command to modify this property.
|
See Also: For information about using theldapmodify command to modify this property, refer to MetaLink note 257949.1 |
Install the Oracle Email libraries on the Information Storage database nodes.
The following tasks need to be performed for each of the Information Storage database nodes:
Copy the $ORACLE_HOME/oes/umbackend.tar file from the Middle Tier to a temporary directory on the Information Storage database nodes.
If the Middle Tier and Information Storage servers are not running on the same operating system, then you must obtain the umbackend.tar file for your Information Storage servers.
Extract the files from the umbackend.tar file.
Run the runInstaller program, which is located in Disk1 of the extracted directory tree.
This will launch Oracle Universal Installer.
Follow the installer prompts to install the libraries.
Oracle Files is installed and set up after the completion of the Oracle Collaboration Suite Middle Tier installation. After the first Middle Tier is installed, perform the following steps to create the default subscriber:
Browse to the Administrator Login page, which is at
http://ocsmt1.oracle.com:7777/files/app/AdminLogin
Log in by using the SITE_ADMIN account.
Click New Subscriber to create a new subscriber.
Select all the default settings for this subscriber.
Select a high value for the quota.
Specify that this subscriber can allocate more space.
Select the maximum number of users for this subscriber. For example, select 256 or 1024.
Specify that the administrator can increase the maximum number of users.
Specify a value that is far off in the future as the end date for this subscriber.
Set Subscriber Administrator User ID to filesadmin.
|
Note: Do not use an existing Oracle Internet Directory user. This administrator is specific to Oracle Files and does not need to log in. If you select an Oracle Internet Directory user as the Oracle Files administrator, then the synchronization process tries to create that user as a duplicate, because the user already exists in Oracle Files as an administrator. |
Specify the e-mail address of the subscriber.
Specify that the status of the subscriber must be changed to inactive after 365 days.
Set the default user quota to 100 MB.
Specify that this subscriber must always be prompted for a password.
Specify that you do not want to enable user control for password prompt.
Set Public Folder to On.
Enable user control of public folders.
Select your default display language.
Select your default document language.
Select your default document character set.
Select your default time zone.
Set your default workspace quota to 100MB.
Set Public Folder to On.
Enable workspace administration control of public folders.
Review the information you have provided, and then submit it.
Modify the registry.xml file for Oracle Files by following the instructions given in Section 3.8.3.
After installing the Middle Tiers, you need to set up the load balancer virtual server, ocslb.oracle.com, as the front end of the Middle Tiers. The HTTP Server and Web Cache components require reconfiguring for the load balancer. These are the access points for the Middle Tier components and the Oracle9i Application Server Portal. This section details the steps required to reconfigure the HTTP Server and Oracle9iAS Portal for access through the load balancer.
As mentioned in the earlier section, each HTTP Server/mod_osso module is a partner application of Oracle9iAS Single Sign-On. When installing the two Middle Tiers, there is an HTTP Server installed on each Middle Tier, which is registered as a partner application with the Oracle9iAS Single Sign-On server. In addition, Oracle9iAS Portal on each Middle Tier is registered with the Oracle9iAS Single Sign-On server as a partner application.
Setting up a load balancer for the Oracle Collaboration Suite Middle Tiers involves the following steps:
Section 3.10.2, "Configuring HTTP Server and Web Cache to Use Load Balancer URL and Port 80"
Section 3.10.7, "Updating the Oracle9iAS Single Sign-On Server Configuration Table"
Validate the partner applications by logging in to Oracle9iAS Single Sign-On administration pages as the Oracle9iAS Single Sign-On administrator. To do this:
Log in to
http://ssolb.oracle.com/pls/orasso
Click SSO Server Administration.
Click Administer Partner Applications.
On this page, in addition to the Oracle9iAS Single Sign-On server, HTTP Server on the Infrastructure, and the Oracle9iAS Single Sign-On Middle Tiers, the following partner applications should be listed:
http://ocsmt1.oracle.com URLhttp://ocsmt2.oracle.com URLhttp://ocsmt1.oracle.com URLhttp://ocsmt2.oracle.com URLMake the following changes in the $ORACLE_HOME/Apache/Apache/conf/httpd.conf file:
| Original | Change To |
|---|---|
| Port 7777 | Port 80 |
ssomt1.oracle.com
|
ocslb.oracle.com |
| Listen 7778 | Listen 80 |
Run the registration script to reregister the two Middle Tiers with Oracle9iAS Single Sign-On. The following is a sample registration script. Before you run this script from the first node, ocsmt1.oracle.com, substitute values appropriate to your installation.
$ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/sso/lib/ossoreg.jar \
-oracle_home_path /ocsmid/app/oracle/product/mid \
-host infraha.oracle.com \
-port 1521 \
-sid iasdb \
-site_name mid.ocslb.oracle.com \
-success_url http://ocslb.oracle.com:80/osso_login_success \
-logout_url http://ocslb.oracle.com:80/osso_logout_success \
-cancel_url http://ocslb.oracle.com:80 \
-home_url http://ocslb.oracle.com:80 \
-config_mod_osso TRUE \
-u root \
-sso_server_version v1.2
To obfuscate the osso.conf file:
Log in to Oracle9iAS Single Sign-On administration.
Determine the values of the following parameters for the new partner application:
sso_server_versioncipher_keysite_idsite_tokenlogin_urllogout_urlcancel_urlsso_timeout_cookie_namePut these values in a clear-text file on the second Middle Tier, ocsmt2.oracle.com.
The following is a sample clear-text file that can be used for iasobf:
sso_server_version=v1.2 cipher_key=A4051CF38030DF54 site_id=1333 site_token=2WI395111333 login_url=http://ssolb.oracle.com/pls/orasso/orasso.wwsso_app_admin.ls_login logout_url=http://ocslb.oracle.com:80/osso_logout_success cancel_url=http://ocslb.oracle.com:80 sso_timeout_cookie_name=SSO_ID_TIMEOUT
Obfuscate the osso.conf file on ocsmt2 by running the following command:
$ORACLE_HOME/Apache/Apache/bin/iasobf oss_clear.txt osso.conf root
This will create the new osso.conf file on ocsmt2.
After you perform these steps, a new partner application for the HTTP Server is created with Oracle9iAS Single Sign-On and the two mod_osso modules are reconfigured.
Oracle9iAS Portal is also registered as a partner application with Oracle9iAS Single Sign-On and needs to be reconfigured with the URL of the load balancer. The Web Cache invalidation specification is included in this reconfiguration. The Web Cache clustering must be completed for the reconfiguration to work correctly. You can ensure this by running the Oracle9iAS Portal Configuration Assistant, opca. Oracle9iAS Portal provides the ptlasst.csh file as a wrapper to opca. Run the following command from one of the Middle Tiers:
$ORACLE_HOME/assistants/opca/ptlasst.csh -mode SSOPARTNERCONFIG \ -i typical -sdad portal -host ocslb.oracle.com \ -port 80 -silent -verbose \ -chost ocslb.oracle.com -cport_i 4001 -cport_a 4000
After the earlier steps, two new partner applications will be created with Oracle9iAS Single Sign-On, one each for the HTTP Server and Oracle9iAS Portal through the load balancer URL. To delete the old partner applications:
Log in to Oracle9iAS Single Sign-On at
http://ssolb.oracle.com/pls/orasso
Click SSO Server Administration.
Click Administer Partner Applications.
All the partner applications are listed on this page.
There are four old entries for HTTP Server and Oracle9iAS Portal with the actual host names, ocsmt1 and ocsmt2, that can be deleted.
Click the Delete icon for each old partner application.
Update the Oracle9iAS Single Sign-On server configuration table WWSEC_ENABLER_CONFIG_INFO$ in portal and orasso, and set URL_COOKIE_IP_CHECK to N. This table stores configuration information that enables the application to identify the Oracle9iAS Single Sign-On server to which it must connect. To get the password for portal, use the ldapsearch command described in Section 3.4.3. On the Infrastructure host, run the following commands:
SQL> UPDATE wwsec_enabler_config_info$ SET url_cookie_ip_check='N' SQL> commit;
All the Oracle Collaboration Suite Middle Tier components appear as portlets when logged in to Oracle9iAS Portal. Each portlet has a portlet provider URL, which is used to render the portlet. The portlet provider URL is in the portal schema. It is the URL of the most recently installed Middle Tier. For example, if ocsmt1.oracle.com is the first installed Middle Tier, then the portlet provider URLs will be ocsmt1.oracle.com. However, when ocsmt2.oracle.com is installed, these URLs are overwritten by ocsmt2.oracle.com.
In the deployment example covered in this document, because a load balancer is used as a front end for the Middle Tiers, these URLs must be updated to the URL of the load balancer.
To change all the portlet URLs, edit the webclient.properties file on both the Middle Tiers and change all occurrences of the physical host name, ocsmt1 or ocsmt2, to the load balancer URL, ocslb. In addition, because you changed the HTTP and Web Cache port to 80, you must change all occurrences of the default port to 80. The webclient.properties file is located at
$ORACLE_HOME/webclient/classes/oracle/collabsuite/webclient/resources/webclient.properties
After editing the webclient.properties file, rerun the Web Client Command Line Installer to update all the portlet URLs. To do this, run the following command:
$ORACLE_HOME/webclient/bin/webclient_installer.sh
Restart all the Middle Tiers by using the start and stop scripts given in Appendix B.
To increase the availability and scalability of your Web site, you can configure multiple instances of Web Cache to run as members of a cache cluster. A cache cluster is a loosely coupled collection of Web Cache instances working together to provide a single logical cache.
Cache clusters provide failure detection and failover of caches. If a cache fails, then other members of the cache cluster detect the failure and take over ownership of the cached content of the failed cluster member. This increases the availability of your Web site.
By distributing the content of the Web site across multiple Web caches, more content can be cached and more client connections can be supported. This improves the scalability of your Web site.
You may need to enable access to some ports on the firewall. The $ORACLE_HOME/install/portlist.ini file contains a list of the default ports used on each node. Remember that because there is a portlist.ini file for each component, you must look for the portlist.ini file on each node.
|
See Also: For a comprehensive list of default ports, refer to Oracle9i Application Server Administrator's Guide |
If you are going to use Oracle Calendar Client, then you need to determine the Oracle Calendar Engine port setting, which is 5730 by default. This is mentioned in the ENG section of the $ORACLE_HOME/ocal/misc/unison.ini file.
The Oracle Files Domain Controller talks to the NodeGuardian and NodeManager ports. Similarly, NodeManager talks to the Oracle Files Domain Controller on the Oracle Files Domain Controller port, which is 53140 by default. You need to open all these ports between the DMZ and the intranet. You can find these port values in the $ORACLE_HOME/ifs/common/registry.xml file on the Middle Tiers in the DMZ and the Oracle Files Domain Controller server on the intranet. These port numbers are automatically generated, so they may be different for each deployment.
