| Oracle® Application Server Best Practices Guide 10g (10.1.4.0.1) Part Number B31762-02 |
|
|
View PDF |
| Oracle® Application Server Best Practices Guide 10g (10.1.4.0.1) Part Number B31762-02 |
|
|
View PDF |
This chapter describes best practices for various highly available configurations and features for OracleAS High Availability Solutions. It contains the following topics:
Section 6.1, "Oracle Application Server Cluster (Identity Management)"
Section 6.3, "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 Identity Management instances in your OracleAS Cluster (Identity Management).
Use the same instance name for the Identity Management instances. The host name prefix the the installer adds ensures that the application server instance is unique.
While Oracle allows the HTTP listen server to listen on different ports in each Oracle Application Server Single Sign-On/Oracle Delegated Administration Services host, Oracle recommends to use the same ports.
It is better to have same ports used for all other components and services, including Application Server Control. Use staticports.ini for all installs to achieve this.
The cluster name you specify in the OracleAS Cluster configuration page in the during OracleAS Cluster (Identity Management) installation is case sensitive. During installation, it is a good practice to always use all upper case or lower case to avoid configuration errors.
See Also:
Chapter 3, "Active-Active Topologies," in the Oracle Application Server High Availability Guide
Chapter 9, "Installing in High Availability Environments: OracleAS Cluster (Identity Management)," in the Oracle Application Server Installation Guide
This section covers the following topics:
Section 6.2.1, "Use Fault-Tolerant Hardware Load Balancers to Avoid Single Points of Failure"
Section 6.2.2, "Use Monitoring of Services to Automatically Disable Traffic to Unavailable Nodes"
Section 6.2.3, "Configure All Idle Time Timeouts to Maximize Time for Unused or Idle Service"
The load balancer is 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:
your load balancer product's documentationThis section covers the following topics:
Installing OracleAS Cold Failover Cluster in a multiple Oracle home configuration will require every administration change to be applied multiple times, 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 8, "Installing in High Availability Environments: OracleAS Cold Failover Cluster," in the Oracle Application Server Installation GuideResize 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.
If you plan to implement the passive node in a machine that is already running other applications, then try to configure the ports for the OracleAS Cold Failover Cluster so that they do not conflict with existing components.
When you perform any new installation or application deployments in the passive node, ensure that the new components do not have port conflict with the passive instance. Often the ports allocated to passive components will appear as free to the operating system.
See Also:
Chapter 8, "Installing in High Availability Environments: OracleAS Cold Failover Cluster," in the Oracle Application Server Installation GuideThis section contains these topics:
Section 6.4.1, "Clean Up Invalid Records to Avoid Instantiation and Synchronization Errors"
Section 6.4.3, "Use Different Labels and Colors in OracleAS Guard Shells to Avoid Errors"
Section 6.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 Guardmay 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 primary and standby 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>
See Also:
Chapter 12, "OracleAS Guard asgctl Command-line Reference," in the Oracle Application Server High Availability GuideThis section contains these topics:
Section 6.5.2, "Use Instance-Level Backup to Guarantee Consistency"
Section 6.5.3, "Perform an Image Backup to Recover from Loss of Host Scenario"
Section 6.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 many 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
See Also:
Section 19.2.4, "Performing an Instance Backup of Oracle Application Server Using Application Server Control Console," in the Oracle Application Server Administrator's GuideThe 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 19, "Backup Strategy and Procedures," in the Oracle Application Server Administrator's Guide for information about the available instance-level backup optionsThe 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>
See Also:
Section 18.6, "OracleAS Backup and Recovery Tool Usage Summary," and Chapter 19, "Backup Strategy and Procedures," in the Oracle Application Server Administrator's GuideThe 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.
See Also:
Section 18.6, "OracleAS Backup and Recovery Tool Usage Summary," and Chapter 19, "Backup Strategy and Procedures," in the Oracle Application Server Administrator's Guide