Release 2 (9.0.3)
Part Number B10578-02
 Core |
Platform |
 Contents |
| Oracle9i Application Server Best Practices Release 2 (9.0.3) Part Number B10578-02 |
|
This chapter describes deployment best practices. The topics include:
The Oracle9iAS J2EE and Web Cache install type provides several choices for deployment. These are different and there are trade-offs. Thus, there is no single recommended way to deploy the components.
This section covers a few deployment architectures. It is not possible to cover all possible scenarios, but the discussion associated with each architecture will allow you to create a deployment architecture best suited to your environment.
This section contains the following topics:
This is the most common deployment scenario and has the least setup overhead.
It is also the only available option for Oracle9iAS instances based on install types other than J2EE.
In this scenario, independent Oracle9iAS instances are installed on independent (identical) machines. These installations share the same infrastructure database. These multiple installs are glued together with a (fault tolerant) load balancer in the front, which routes the request to the different back-end servers on a round robin basis. Sticky session based routing will be required on the load balancer.
The biggest benefit of this approach is that everything works out-of-the-box, and the only task is application deployment on the back-end machines. The load balancer provides balancing across machines, the Oracle9iAS Web Cache on each Oracle9iAS instance provides the basic caching for each instance, and the Oracle HTTP Server load balancing component (mod_oc4j) provides load balancing across the individual OC4J processes on each machine.
There are few drawbacks, such as:
However, this option is attractive due to its simplicity. And if you practice state-safe programming as recommended in this document, some of the drawbacks become even less relevant.
You can however do some non-standard manual tweaks to remove this restriction, as documented in the mod_oc4j Technical Overview paper at:
http://technet.oracle.com/products/ias/ohs/collateral/r2/mod_oc4j_wp.pdf.
Let us say you have the earlier deployment architecture working right, and now you want to gain the benefits of Oracle9iAS Web Cache clustering and/or introduce an additional security zone.
The architecture shown in Figure 12-2 allows that. You just need to shutdown the Oracle9iAS Web Cache service on the individual instances on the back-end machines, and move those instances onto separate suitable machines. These could then be clustered, so that the different Oracle9iAS Web Cache instances can provide added fault tolerance and scalability, along with the ease of configuration.
The load balancer and the Oracle9iAS Web Cache instances have been moved into a security zone of their own: providing added security check before the backend systems (Oracle HTTP Server and OC4J) can be reached. This architecture is shown in Figure 12-3.
Another variation, as shown above is the removal of load balancer, and using a single Oracle9iAS Web Cache instance to balance across the multiple back-end origin servers. This is a cost-effective option since it does not require an expensive load balancer in front. However, although it violates one of the best practices discussed in the Oracle9iAS Web Cache chapter.
Oracle9iAS Release 2 introduces powerful clustering technology, that allows for session replication across OC4J instances, dynamic restarts, cluster-wide configuration updates, etc.
In Figure 12-4 above, the previous architecture was modified such that all the Oracle HTTP Server and OC4J are clustered together. Within this cluster, you can select groups of OC4J processes (instances) to be part of the same island so that they can provide failover for each other.
It is recommended that this island size be 2 to 3 which is much smaller than the overall cluster size. It reduces the session replication overhead. This scenario provides better fault tolerance than any of the earlier scenarios and is the best option of all recommendations, especially for J2EE and Web Cache deployments.
Sometimes it is desirable to separate Oracle HTTP Server from OC4J (the application server component) into different security zones. This scenario is shown in the following Figure 12-5.
It contains two clusters: a cluster containing only Oracle HTTP Server instances and a cluster containing only OC4J components.
If desired, Oracle9iAS Web Cache can also be clustered, but that will necessitate a load balancer in front of the Web cache servers.
This scenario requires a fair amount of hand modifying configuration files, so that the two clusters (Oracle HTTP Server and OC4J) can communicate with each other. Moreover, it also requires opening of sql*net and LDAP ports on FW-2, in addition to FW-3.
This scenario also does not benefit from the distributed deployment due to the required manual edits.
These drawbacks make this option less appealing - simply to move Oracle HTTP Server out into its own security zone. Hence, we recommend the architecture shown in Figure 12-4 as the preferred method.
This section describes general deployment best practices. It contains the following topics:
Oracle9iAS supports applications to be deployed on a production system without taking the system down.
However, some applications (e.g. EJB-based EAR files) may put additional load on the production system by requiring compilations, JAR file updates, and Web server restarts. While this doesn't result in any lost requests directly, it does introduce some additional load on the system.
Hence, it is a good practice to avoid deploying during high traffic periods.
Oracle9iAS clustering allows the ability to mix-and-match different hardware in the same cluster. While this may be attractive and allow for some innovative solutions, it makes overall manageability and operations harder. Hence, it should be avoided.
Having identical hardware allows for ease of stocking spare parts, better reproducibility of problems (both software and hardware), and reduces the per-platform testing cost. This cost, in many cases, will surpass the savings from re-using existing disparate hardware.
Oracle9iAS with its distributed configuration management capability makes it easy for several machines in the cluster to have the same configuration.
However, there is a performance and possible downtime cost associated with deploying applications to a cluster. To reduce the impact of this, starting a new cluster is recommended in the following scenarios:
Specifically, the recommendation is:
This practice allows you to make major changes to the system without impacting all machines in the cluster at once. It also results in changes being applied more reliably.
Load balancers like Cisco's CSS 11000 and F5's BigIP can quickly detect and route around failed mid-tier servers. For greatest failure isolation, each server should be an independent computer, although if the availability of the computer and its operating system is very high, multiple servers may run on the same computer. Load balancers can also quiescence and take a mid-tier server off-line, so that it can be restarted or reconfigured without having to handle incoming requests at the same time.
Ideally, N+2 mid-tier machines should be used, where N is the number of mid-tier computers needed to serve peak load. One extra computer is a ready-to-go spare, should one of the N fail. The other extra computer hosts a server that is off-line for restart or maintenance.
Load balancers have failover configurations to prevent themselves from becoming single points of failure.
Load balancers can also be used to balance traffic across multiple firewall computers for scalability and availability. This can be a complex and expensive option, because you must have a load balancer in each security zone. Most commercial firewalls have a failover solution that does not require use of a load balancer, so unless scalability is a concern, use the availability solution recommended by the firewall vendor.
This section describes the Oracle Internet Directory deployment best practices. It includes the following topics:
There is a bulkload utility ($ORACLE_HOME/ldap/bin/bulkload.sh) that can be used for loading large amounts of data, for example, from existing third party directories. The utility also has a schema check option, to avoid difficult to trace errors. For smaller amounts of data (less than 10,000 entries), use the ldapadd utility as it is adequate for the job. If bulkload utility is not used, you should execute $ORACLE_HOME/ldap/admin/oidstats.sh to collect database statistics so that the LDAP search operations perform optimally.
The bulkload utility takes a ldif file as input data file. When generating these files from third party directories, you will have to scrub out some of the operational attributes as these are generated by Oracle Internet Directory during bulkload. However, if the input ldif file is from another Oracle Internet Directory instance, then you must use the restore option in bulkload.sh to preserve these operational attributes as-is during bulkload.
To hide multiple Oracle Internet Directory nodes from client applications, a BIG-IP or similar device can be used to load balance or provide a single IP and port to the client applications. If a replicated node goes down, the client applications do not see the failure, because the BIG-IP device re-routes requests transparently.
Additionally, each Oracle Internet Directory node can run on Oracle9i Real Application Clusters (RAC). This further improves availability regardless of whether a BIG-IP set up is used or not. The RAC instances provide increased database and data availability while presenting the same data via a shared disk mechanism.
Other high availability solutions deployable with Oracle Internet Directory are hardware cluster failover and Oracle Data Guard.
SSL is considered de facto Internet standard protocol for highly secure transportation of data. In addition to the strong PKI authentication using digital certificates, SSL also provides multiple data integrity and data encryption layers to protect your communication channels. SSL provides multiple cipher suites with varieties of encryption algorithms for many security levels.
Oracle Internet Directory supports 3 SSL authentication modes:
In this mode, SSL cipher suites use the Diffie-Hellman algorithm to generate a session key for client or server at run time. The session key will be used to encrypt the communication channel. No server or user SSL wallet is necessary. In SSL no authentication mode, the channel will be encrypted using a Diffie-Hellman key.
This mode essentially uses certificates for authentication. The client needs to verify the server certificate. This mode is most commonly used in the Internet environment since any client that needs to talk to a SSL server does not require a certificate. A client can use its user/password to authenticate itself to the server. The username and password are protected by SSL encryption when being transferred on the wire.
In this mode, both client and server use RSA certificates to authenticate each other. First, the client authenticates the server by validating its certificate. In return, the server also requires the client to send its certificate to prove its authenticity.
In addition to choosing an authentication mode, one should choose appropriate security algorithms. Following are the strong security algorithms supported in Oracle Internet Directory:
Oracle Internet Directory supports two backup and restore mechanisms for this: database export import based mechanism, and LdifWriter and bulkloader based mechanisms.
The former is faster, but it is not flexible - you have to backup/restore the entire directory, and this cannot be done incrementally. The latter utilities, LdifWriter and bulkloader provide more control to restore/backup subsets of the directory. However, they are slower and require more manual steps.
Hence the recommendation is to use the database-based utility when doing a complete backup-restore, and use the other utilities when you intend to backup and restore a subset of the directory.
No matter which mechanism is used, make sure the backup-restore is used for the same versions. For migration purposes - to a different version of Oracle Internet Directory - ensure you follow the appropriate instructions before bulkloading or restoring the directory data.
You can monitor and audit Oracle Internet Directory in one of three ways:
Oracle recommends that you perform, at the very least, a weekly review of the audit and error logs. System administrators can do a more regular review via the EM health check to provide better availability.
While it is possible to install Oracle9iAS as an Oracle Internet Directory super user, we highly recommend that this not be done as it provides the user installing Oracle9iAS more privileges than required.
To install Oracle9iAS, a user needs to be a member of Oracle9iAS Administrator's group and should also be an owner of that group.
While installing Oracle9iAS, the directory administrator should add the installation user as a member and owner of the Administrator's group, and then remove him/her as the owner once the installation has completed so that the user does not have privileges to perform any more installations.
By default, Oracle Internet Directory is installed with the following privileges for the Oracle Internet Directory administrator: create new users, delete existing users, and modify user attributes.
The access control setup on a user's container specifies the default access control policies regarding user administration. Oracle Internet Directory administrators should change the default access control policies to better control user administration as per required.
Oracle Internet Directory supports both password value policies and state policies. The password policies can be enforced on a per-subscriber basis in a hosted environment. If a given subscriber does not have any applicable policy, the policy under the root Oracle context will be applied to that subscriber.
The value policies are: password minimum length, minimum number of numeric characters, disallow the use of current password as new password, and disallow the use of common words and attribute values as passwords.
The state policies supported are: password expiration, account lockout, expiration warning, and grace logins.
The best practice password policy is to have a password minimum length of 5 characters with at least one numeric character. Also, it is recommended to have a password expiration duration of 60 days and lock user accounts after 10 consecutive login failures. The user account must stay locked for a duration of 24 hours. Additionally, users must be sent password expiration warnings at least 3 days prior to expiration and should be allowed a maximum of only three grace logins after their passwords have expired.
This section features the following topics:
Directory Integration Platform (DIP) should be used to build connectivity between Oracle Internet Directory and third party directories so that other Oracle products can seamlessly work in presence of third party directories in the enterprise and can also share the same identities with other directories.
The different identities for the same enterprise user from multiple LDAP directories can be joined/unified into a single global identity in Oracle Internet Directory using DIP, which would facilitate a true single sign-on environment in an enterprise using Oracle Internet Directory/Oracle9iAS Single Sign-On.
Oracle Internet Directory supports representation of multiple applications and multiple subscribers (administration Contexts) in the Oracle Internet Directory DIT. Various enterprise applications can be provisioned for a single or multiple subscriber(s). There are automated tools to create new Subscribers (administrative Contexts) and to provision applications for various subscribers. These tools setup the various levels of access required by the application to manage the Subscriber.
Data from third party directories should be synchronized with Oracle Internet Directory into the appropriate subscriber (administrative context) area so that identity management and group management required by all enterprise applications can be done without any extra overhead.
The scheduling interval of the profiles, which decides the frequency of synchronization, should be set to a value based on the enterprise policy in supporting new users in different environments.
If only selective containers within a domain need to be synchronized, then it will be better to specify the selective container names in the domain mapping rules rather than specifying that top level domain name.
The number of attributes to be synchronized needs to be decided based on the purpose of synchronization. It's better to specify the minimal set of attributes to have a minimal network and system loads. If the main purpose is to enable the users for using applications such as Oracle9iAS Portal, a minimal set of attributes containing the essential user information to be displayed in DAS should be configured for synchronization.
A synchronization Profile has to be DISABLED before altering any STATUS attributes through the ODM. After the change, it needs to be ENABLED once again.
Since the "Last Successful Execution Time" is used to fetch changes from the Oracle HR Database, to get the entire user population, this attribute should be set to some old date. Then the profile needs to be ENABLED.
It is a good idea to synchronize user data from the HR database to the public users container in the subscriber area in the Oracle Internet Directory DIT. This way, all the users are immediately accessible to the Oracle9iAS Single Sign-On and DAS.
The User Nickname Attribute should be synchronized from the Oracle HR Database or derived from some other attribute (by mapping) which is unique in the HR database in order to uniquely identity a user to Oracle9iAS Single Sign-On.
Since the HR Synchronization Profile needs privilege to read write the public users area under the subscriber, the HR profile DN should be added to the DASCreateUserGroup, DASEditUserGroup, DASDeleteUserGroup groups for that subscriber.
Oracle9iAS provides an Oracle Internet Directory instance as part of its infrastructure installation. However, some organizations may already have an existing Oracle Internet Directory installation that houses corporate data or they may have been running the previous versions of Oracle9iAS that already have some of the information duplicated. In this case, if it is desired that Oracle9iAS should point to the different Oracle Internet Directory, the following should be adhered to:
In case the corporate directory is replicated, some special steps need to be taken by administrators to create a test replica of the production Oracle Internet Directory. Then, migrate and verify the components against the test replica before switching to use the production Oracle Internet Directory.
Like the upgrade case, the presence of a corporate directory in a deployment influences the process by which the deployment can roll out new services using Oracle9iAS. The following steps should be considered when deploying an Oracle9iAS component that uses Oracle Internet Directory:
|
 Copyright © 2003 Oracle Corporation. All Rights Reserved. |
|
