11
Installation Best Practices

This chapter describes installation best practices. It features the following sections:

• General Installation Best Practices

• Hosting Installation Best Practices

11.1 General Installation Best Practices

This section describes general installation best practices. It features the following topics:

• Understand the Various Configuration Tools Available with Oracle9iAS

• Try Standard Demos and Associated Applications Before Running Your Applications

• Turn Off Unused Services to Reduce Oracle9iAS Memory Requirement

• Check Metalink Regularly for Updates to Keep Your Installation Current

• Periodically Check the Log Files for Restarts/Errors That Are Masked by Auto Restart Capability

• System Administrator and Oracle9iAS Administrator Should Be Different

• Use the Appropriate Administration User Accounts

• Install All Mid-Tiers on Multiple Smaller Machines, the Infrastructure on Clustered Larger Machines

• For a 3-Tier Environment, Install the Infrastructure Instance Twice and Configure Each Tier Differently

• Recommendation for Installing Oracle9iAS Portal

11.1.1 Understand the Various Configuration Tools Available with Oracle9iAS

The appendices of your Oracle9i Application Server Installation Guide Release2 (9.0.3) provide detailed documentation of the Oracle9iAS Configuration Assistants. Different installations will use different configuration assistants depending on configuration options. For more information, also look at the "Troubleshooting" appendix in these guides.

11.1.2 Try Standard Demos and Associated Applications Before Running Your Applications

This helps segregate the installation time problems from the application problems clearly. Additionally, these demos may be a good way to verify your setup on an ongoing basis before debugging application specific issues.

11.1.3 Turn Off Unused Services to Reduce Oracle9iAS Memory Requirement

Oracle9iAS supports a wide variety of applications and services. However, your particular deployment or use may not need all of them. Hence, it is a good idea to turn off the unused services. This reduces the memory requirement of Oracle9iAS and is a recommended security best practice.

11.1.4 Check Metalink Regularly for Updates to Keep Your Installation Current

Oracle Metalink contains a wealth of support related information and also includes the patches that may be released from time to time. These updates will ensure that you do not run into the same issues that Oracle may have already resolved. While there is benefit to not perturbing a working system and thus, some inertia in updating with the latest patches, at the least, security patches should be applied immediately. Another good source of information is the installation FAQ on Oracle Technology Network.

11.1.5 Periodically Check the Log Files for Restarts/Errors That Are Masked by Auto Restart Capability

With Release 2, Oracle9iAS includes improved fault monitoring and recovery capabilities. The monitoring processes automatically restart a failed component. This capability is extremely useful for high availability. However, it could mask the application failures that should be looked at and fixed. Hence, it is an important practice to periodically scan for these auto-restart logs within the log file.

11.1.6 System Administrator and Oracle9iAS Administrator Should Be Different

In most deployment scenarios, the operating system and hardware are managed by different teams. Since almost all tasks associated with Oracle9iAS installation and configuration can be performed by a user account without acquiring a systems 'root' privileges, it is required to have a separate account to install and configure Oracle9iAS.

Moreover, as you look ahead to install multiple instances of Oracle9iAS on the same machine, it is prudent to have a separate user for each. This further makes it easier to segregate errors and delegate management for each instance to a different user ID. Ensure that the second or subsequent install users have privileges to write to targets.xml file in the first installation. (Note: The Oracle Enterprise Manager user is per node. Thus, having different system users (for example, on UNIX) does not help the cause of having different users manage the different instances over the web. This feature is targeted for a future release.)

11.1.7 Use the Appropriate Administration User Accounts

As the number of installations in an environment grows, it is important to either use similar user names on different machines or, have an algorithm to determine the same. Moreover, each instance has a number of user accounts required by Oracle9iAS itself, such as orcladmin, ias_admin, portal admin, sso admin, web cache admin, etc. (refer to the Oracle9i Application Server Administrator's Guide for details of these accounts). Hence, it is a good idea to have an internal matrix covering these different user types.

11.1.8 Install All Mid-Tiers on Multiple Smaller Machines, the Infrastructure on Clustered Larger Machines

Oracle9iAS mid-tier supports clustering smaller machines into a larger unit. While these machines can coordinate process state and routing information with each other, an individual machine is self-sufficient in processing the requests routed to it. It has no physical dependency on other mid-tier machines. Thus, several of these machines can effectively be used to satisfy a larger number of requests providing a better alternative to more expensive hardware clustering.

On the other hand, the infrastructure installation contains the repository - physical data store that has to be shared across several mid-tier instances. This metadata service needs to present the same data to all mid-tier instances and needs to be up all the time. Hence, it is recommended that the infrastructure installation be carried out on a hardware cluster (for example, Sun cluster, HP Service Guard).

11.1.9 For a 3-Tier Environment, Install the Infrastructure Instance Twice and Configure Each Tier Differently

Most security policies will prevent the Oracle9iAS metadata service and repository from being implemented in the DMZ in a 3-tier installation: Web server, J2EE tier, and data store. However, Oracle9iAS Infrastructure includes a security service for single-sign on that has to be accessible from the external world.

Hence, we recommend that you install Oracle9iAS Infrastructure both behind the firewall and in the DMZ. Only the security service will need to be configured in the DMZ layer, while only the metadata repository Oracle Internet Directory needs to be configured in the layer behind the DMZ. This setup requires some manual steps since, by default, the management console assumes both are deployed on the same Infrastructure instance.

11.1.10 Recommendation for Installing Oracle9iAS Portal

When installing Oracle9iAS Portal through the Portal and Wireless or Business Intelligence and Forms install types, Oracle9iAS Web Cache is installed and configured. If you do not use an Oracle9iAS Infrastructure for your Oracle9iAS Portal metadata and use another existing database, then de-select Oracle9iAS Portal during the installation process. After installation, launch the Oracle9iAS Portal Configuration Assistant. Instructions for doing this are in the Oracle9iAS Portal Configuration Guide.

11.2 Hosting Installation Best Practices

This section describes hosting installation best practices. It includes the following topics:

• Install as Different Users When Installing Multiple Instances on the Same Machine

• Share the Same Security Service Across Multiple Installations But Split the Metadata Service

• Recommendations for Having Large Number of Groups Run the Applications on a Given Instance

11.2.1 Install as Different Users When Installing Multiple Instances on the Same Machine

While this is a relevant installation practice, it is particularly important in a hosting environment. Doing so lets you provide the hosting customers (who "own" this installation) to access their log files or deploy their own applications. You can always prevent the configuration files from being edited by making them read-only.

11.2.2 Share the Same Security Service Across Multiple Installations But Split the Metadata Service

In most hosting environments, enterprises provide similar capabilities of certain applications to both their intranet and Internet users. This requires some consolidation of services that can be shared to reduce the workload. Security service is one such example. The different deployments can all point to the common single sign-on security service, thus avoiding the need to maintain distinct or similar user IDs in the different security services. Hence, an intranet user may log into the Internet system by using the same username/password although this user's privileges for the application is governed by the Internet application metadata.

11.2.3 Recommendations for Having Large Number of Groups Run the Applications on a Given Instance

Most large enterprises have a separate organization providing the application server runtime environment as a service to individual organizations in the enterprise. The latter in turn own the applications running on top of the environment.

In this scenario, multiple application server instances can be installed and provided to each target group. However, this increases the maintenance overhead and should be avoided unless security or resources sharing is of paramount concern (as is the case for an external ASP). The concerns here are:

• One organization's bad application should not take down the servers hosting other divisions' applications.

• Each division should be able to control its applications.

Oracle recommends that you have several independent OC4J instances within an Oracle9iAS instance and dedicate each instance to an organization. Depending on the organization's needs, the number of processes within the OC4J instance can be varied. Since the J2EE configuration is OC4J instance specific, this gives a fair amount of leeway to each organization for their applications.