|
Oracle® Application Server Best Practices Guide
10g Release 2 (10.1.2) B28654-01 |
|
 Previous |
 Next |
|
Oracle® Application Server Best Practices Guide
10g Release 2 (10.1.2) B28654-01 |
|
|
Previous |
Next |
This chapter describes best practices for various highly available configurations and features for OracleAS High Availability Solutions. It contains the following topics:
Section 10.1, "Oracle Application Server Cluster (Identity Management)"
Section 10.2, "Oracle Application Server Cold Failover Clusters"
Use a consistent and standardized configuration for the instances that participate in an OracleAS Cluster (Identity Management). From the OracleAS Single Sign-On perspective, all the instances in the cluster are seen as a single entity that provide a single service. To avoid errors in updates to the configuration, follow these tips:
Use the same Oracle home path for the instances in your OracleAS Cluster (Identity Management).
Use the same basic name for the instances. The host name prefix would ensure that the application server instance is unique.
While Oracle allows the HTTP listen server to be different on each SSP/Oracle Delegated Administration Services host, Oracle recommends to use the same ports.
It is better to have same ports used for all other services. Use staticports.ini for all installs to achieve this.
Standardize on the port for Application Server Control for all Identity Management installs.
The Distributed Configuration Management cluster name used in an OracleAS Cluster (Identity Management) installation is case sensitive. During installation, it is a good practice to use always upper case or lower case to avoid possible configuration errors.
|
See Also:
|
This section contains these topics:
Installing OracleAS Cold Failover Cluster in a multiple Oracle home configuration will require every administration change to be applied twice, including the deployment of J2EE applications. Oracle recommends using a shared drive for all install types, including the ones where non-shared is possible.
An OracleAS Cold Failover Cluster installation updates the oraInventory directory in a local file system unless the installer is specifically pointed to an oraInventory directory in a shared location. If you install additional software from the node in the hardware cluster that was not used for the OracleAS Cold Failover Cluster installation, the cold failover cluster installation will not be detected. Use Oracle Universal Installer to attach your OracleAS Cold Failover Cluster Oracle home with the oraInventory directory on the non-install nodes.
Implementation Details
In order to associate and attach the Oracle home to the oraInventory directory, use the following command:
./runInstaller -silent -attachHome -invPtrLoc <oraInst.loc location> ORACLE_HOME="<Oracle_Home_Location>" ORACLE_HOME_NAME="<Oracle_Home_Name>" CLUSTER_NODES="{}" LOCAL_NODE="<node_name>"
|
See Also: Chapter 11, "Installing in High Availability Environments: OracleAS Cold Failover Cluster," in the Oracle Application Server Installation Guide |
Resize the disk to hold all application deployments, maximum JMS messages persisted, and hold OracleAS Portal and Oracle Identity Management data when applicable. It is critical to use some kind of disk redundancy to secure all the binaries, data and metadata used by an OracleAS Cold Failover Cluster. If you are using Automatic Storage Management (ASM) and co-existing with other databases that use ASM, upgrade to clustered ASM for the entire cold failover cluster
If the ports are not available when the active instances fails over to the passive node, Oracle Application Server will not be able to start. Keep record of the ports used by your active-passive installations and use staticports.ini to install any other Oracle Application Server instances so that those ports remain free.
|
See Also:
|
This section contains these topics:
Section 10.3.1, "Use Fault-Tolerant Hardware Load Balancers to Avoid Single Points of Failure"
Section 10.3.2, "Use Monitoring of Services to Automatically Disable Traffic to Unavailable Nodes"
Section 10.3.3, "Configure All Idle Time Timeouts to Maximize Time for Unused or Idle Service"
The load balancer will be the entry point to many different services. Independent of providing redundancy for these services, the load balancer itself must be highly available. Use load balancers that can be configured for automatic failover in case of load-balancer failures.
It is common in most load balancer products not to detect the failure of a service through one of its monitors. For these products, connections will remain idle and requests will hang.
Implementation Details
Make sure that the load balancer has been configured to monitor the services and fails over all the traffic to other nodes immediately in case of a failure.
Set the idle timeouts to the maximum time you expect a service to be unused or idle. Otherwise, the load balancer will cut the connections even when they appear as available to the invocation clients
|
See Also: Load balancer product documentation |
This section contains these topics:
Section 10.4.1, "Clean Up Invalid Records to Avoid Instantiation and Synchronization Errors"
Section 10.4.3, "Use Different Labels and Colors in OracleAS Guard Shells to Avoid Errors"
Section 10.4.4, "Enable High-Logging Level to Troubleshoot OracleAS Guard Operations"
Remove all invalid Oracle software (invalid Oracle Databases or Oracle Application Server installation) from the oraInventory directory. You can accomplish this task by using the Oracle Universal Installer. For example, an instance is installed and later removed manually by deleting an Oracle home. Manually remove this instance's information from the Inventory.xml file; otherwise, OracleAS Guard may fail to perform the instantiation and synchronization operations.
Try to use the same OracleAS Guard ports in the primary and standby sites. Otherwise, you will have to manually edit the dsa.conf file to enable the communication between production and standby site peers.
Due to the host name symmetry requirements for OracleAS Guard, shells in both environments may appear under the same host name and prompt. It is a very common mistake to perform operations in a standby shell that were intended to be preferred in the production site, causing errors and inconsistent configuration changes. Use a fixed and standard way to label and position command shells to make sure that operations are issued in the correct site.
You can trace OracleAS Guard operations to a great detail by using the set trace on all command. By default, the trace level is set to off. Use this type of logging when trying to solve issues with OracleAS Guard.
Implementation Details
From the OracleAS Guard prompt, enter:
set trace on | off <traceflags>
This section contains these topics:
Section 10.5.2, "Use Instance-Level Backup to Guarantee Consistency"
Section 10.5.3, "Perform an Image Backup to Recover from Loss of Host Scenario"
Section 10.5.4, "Use Incremental Backups to Save Time and Disk Space"
Application Server Control provides an easy and convenient way to configure Oracle Application Server Backup and Recovery Tool and perform backup and recovery operations. You can view the OracleAS Backup and Recovery Tool operational log files through Application Server Control. This interface is less error prone than the command line.
Implementation Details
The instance-level backup includes the configuration and repository backup. The repository can be database-based or file-based. This functionality offers consistency between configuration and repository backups. You should try to use this option as much as possible as opposed to backing up configuration and repository separately.
Implementation Details
|
See Also: Chapter 21, "Backup Strategy and Procedures," in the Oracle Application Server Administrator's Guide for information about the available instance-level backup options |
The OracleAS Backup and Recovery Tool offers recovery from loss of host scenarios. After doing an install, make sure to take an image backup that includes the Oracle home, OraInventory directory, Registry entries, instance backup, and so on. You can use this information to recover from a loss of host.
Implementation Details
In order to create an image backup, use the following commands
On UNIX:
bkp_restore.sh -m node_backup -o image_backup -P <archive path>
On Windows:
bkp_restore.bat -m node_backup -o image_backup -P <archive path>
The OracleAS Backup and Recovery Tool offers incremental backup both for configuration files and database, by which only the modified data gets backed up. You should choose this option if you do not want to backup redundant data every time and you like the backups to be small in size.
