|
Oracle® Application Server 10g Advanced Topologies for Enterprise Deployments
10g (9.0.4) Part No. B12115-01 |
|
|
|
|
Oracle® Application Server 10g Advanced Topologies for Enterprise Deployments
10g (9.0.4) Part No. B12115-01 |
|
|
|
|
This chapter provides information on managing an enterprise deployment:
Enterprise Data Center Topology: Multiple Departments Sharing the Same Data Center
Departmental Topology: Departments Hosting Their Applications
Regardless of the type of topology you are managing, here are some general considerations:
Many services and components generate their own log files that need to be maintained regularly. This need for maintenance varies on the size and scale of an enterprise topology.
Log files in Oracle Application Server have a maximum limit of 2 gigabytes before application server performance becomes adversely affected. You need to make sure that log files are archived and reset before they near the 2 gigabyte limit. This task may have to be performed daily or several times per week.
One way of managing log files is by using a "waterfall" approach, i.e. working on one server or component at a time during non-peak load times. This approach allows a data center to maintain high availability when a server is taken off-line, or when it is not brought down properly. Then, when that server or component has restarted, you can bring down the next server for log file maintenance, for example, one hour later.
You can also automate these tasks with "chron" jobs as a way to ensure this task is done. For more information, see the Oracle Application Server 10g Administrator's Guide.
For increased performance of OC4J, Oracle recommends regular restarting of OC4J. Sometimes memory leaks from applications or from the virtual machine (VM) within OC4J itself can degrade application server performance. You determine how often you need to restart OC4J based on daily observation and if automatic restarting does not happen. Your business needs may also affect how often you’ll have to restart OC4J.
Starting and stopping servers and any applications depends on which servers are involved and the needs of users and the applications they use. Starting and stopping servers and applications can be automated through shell scripts and chron jobs as necessary.
When implementing automated starting and stopping of servers, you should take into account any applications that need to be started with the server. You should also consider the effects on high availability while a server is brought down for restarting, or if a server or application fails to start correctly.
You can also plan stopping and restarting procedures on a tier-by-tier basis. For example, you may only need to restart the application server, but not the database, in the case of rolling out patches.
When rolling out configuration changes for upgrade and patching purposes, you do it once for each virtual host in httpd.conf. For information on configuring httpd.conf, see Oracle HTTP Server Administrator's Guide.
You can use the Archive feature in Oracle Application Server as part of the disaster and backup and recovery strategies for your enterprise topology. Possible daily strategies include:
Making a complete operating system TAR of the entire code tree.
Backup of the file repository (database) for all installation types.
You can also use archives in a development environment where a new server comes online and you need data for research and development.
Your actual backup and recovery strategies should also take into account your business needs and security issues.
You can take advantage of NFS in your data center to:
Keep static content on NFS partitions and mount it as needed to a server or application as needed
Deploy static content quickly
Resynch data across an enterprise topology quickly (sometimes minutes versus hours without NFS)
Sometimes it can get difficult to track ports and port conflicts in a large enterprise topology, especially when specialized port configurations are implemented. It can also be difficult to figure out what the next available port to assign is.
You can associate many ports with one IP address as necessary.
Use Oracle Enterprise Manager to view information and manage port usage in your enterprise topology.
Choosing and using static and dynamic IP addresses can be influenced by:
The virtual IP structure in your enterprise topology
How the hardware or software load balancer controls IP addressing
Firewall configurations and implementations
A new feature in Oracle Application Server is the ability to reassociate a middle tier with a new SSO/OID instance (infrastructure).
For example, you could point a middle tier instance to an SSO/OID instance that is strictly for development purposes, allowing you to develop, test, or upgrade before rolling out, then reassociate that middle tier to its original SSO/OID instance. For more information about joining or leaving an infrastructure, see Oracle Application Server 10g Administrator's Guide.
The following sections provide information that is relevent to the type of topology you may be managing.
Mining the log files in an enterprise topology has several advantages:
Assists development teams in debugging before deploying to production environments
Provides security information such as hacker attempts
Provides information about errors at many different levels
Provides information about automated processes
The following sections describe considerations for managing an enterprise deployment topology:
Use the monitoring and alerting capabilities of Oracle Enterprise Manager to ensure you are notified of any potential performance problems in your system(s). Use the default alerting thresholds or configure custom thresholds if needed for monitoring and alerts. Use historical data collected by Oracle Enterprise Manager to specify baselines for thresholds.
Create Web applications for monitoring availability and response for applications deployed.
Use Oracle Enterprise Manager Application Server Control for application server administration. It’s installed automatically with the application server. You access this console from the Administer link in the Application Server Control.
Use Oracle Enterprise Manager Application Server Control for:
Starting and Stopping components as needed
Enable/Disabling unused components so they do not consume system resources
Setting or changing configuration parameters for any of the application server components
Deploying and configuring applications
Managing application security
Monitoring application and component performance and resource consumption in real-time
Viewing and setting ports
Browsing and searching log files
Managing infrastructure schemas
Command line utilities are available for scripting and automation.
Use this checklist to ensure that:
J2EE applications are deployed on Oracle Application Server clusters with or without Web Cache
Portal application are using Web Cache, even on a single node environment
Forms applications are working against an OLTP system with no Single Sign-On
Business Intelligence (BI) applications are working against a data warehouse with tighter security
All applications are accessible by Portal and Wireless devices
Self Service Applications are using IP and Workflow
The following sections describe considerations for managing a departmental topology:
Use the monitoring and alerting capabilities of Enterprise Manager to ensure you are notified of any potential performance problems in your system. Use the out-of-box alerting thresholds or configure custom thresholds if needed for monitoring and alerts. Use historical data collected by Enterprise Manager to specify baselines for thresholds.
Create Web Applications for monitoring availability and response for applications deployed.
Use Oracle Enterprise Manager Application Server Control for application server administration. Oracle Enterprise Manager Application Server Control is installed automatically with the application server.
Use the Oracle Enterprise Manager Application Server Control for these tasks:
Starting and Stopping components as needed
Enable/Disabling unused components so they do not consume system resources
Setting or changing configuration parameters for any of the application server components
Deploying and configuring applications
Managing application security
Monitoring application and component performance and resource consumption in real-time
Viewing and setting ports
Browsing and searching log files
Managing infrastructure schemas
Command line utilities are available for scripting and automation
OHS used as load balancer for multiple OC4J instances
J2EE applications deployed on Oracle Application Server clusters with or without Web Cache
Portal applications using Web Cache
Monitor application performance and availability using the Oracle Enterprise Manager Application Server Control.
Test Environment: For application server installation use Oracle Enterprise Manager Application Server Control. For standalone components use command line tools.
Staging Environment: For application server installation use Oracle Enterprise Manager Application Server Control. For standalone components use command line tools.
Production Environment: For application server installation use Oracle Enterprise Manager Application Server Control. For standalone components use command line tools.
|
 Copyright © 2003, Oracle Corporation All rights reserved |
|