|
Distributed Configuration Management Administrator's Guide
10g Release 2 (10.1.2) B13997-02 |
|
 Previous |
 Next |
|
Distributed Configuration Management Administrator's Guide
10g Release 2 (10.1.2) B13997-02 |
|
|
Previous |
Next |
This chapter briefly describes the Distributed Configuration Management (DCM) architecture and functionality.
This chapter covers the following topics:
Distributed Configuration Management is a management framework that enables you to create and manage multiple Oracle Application Server Instances that you can manage as a single Oracle Application Server Instance. Multiple Oracle Application Server Instances enable the application server to handle large volumes of traffic reliably, since the workload is distributed among multiple Oracle Application Server Instances.
Distributed Configuration Management enables you to:
Keep a configuration synchronized across multiple Oracle Application Server Instances
Archive and restore versions of configurations
Export and import configurations between Oracle Application Server Instances
With DCM, you can manage configuration information for the following Oracle Application Server components and applications:
Oracle HTTP Server (OHS)
Oracle Application Server Containers for J2EE (OC4J)
Oracle Process Manager and Notification Server (OPMN)
Oracle Application Server Java Authentication and Authorization Service (JAAS) Provider (JAZN)
J2EE Applications
Log Loader
Distributed configuration management enables you to synchronize the configuration of, archive, and import and export multiple Oracle Application Server Instances as if they were a single Oracle Application Server Instance. This guide refers to such configurations as "DCM-configured". To provide the management functionality, DCM keeps information about an Oracle Application Server Instance's configuration in the DCM Metadata Repository. The repository and the Oracle Application Server Instances comprise the distributed configuration. In this section, each element of the distributed configuration and its relationship to other elements is described in detail.
The fundamental element of the distributed configuration is the Oracle Application Server Instance: the set of processes required to operate the components that are configured. The terms "instance" and "installation" are sometimes used interchangeably, but note the distinction: an instance is the set of processes that operate the components, whereas an installation is the set of files installed into an Oracle home. The distinction is important in the context of DCM management, because the DCM management scope does not extend to all files installed in the Oracle home—only those related to the set of processes that are needed to operate the configured components.
A DCM-Managed OracleAS Cluster is a collection of Oracle Application Server Instances with identical configuration and application deployment characteristics. To become members of a DCM-Managed OracleAS Cluster, Oracle Application Server Instances must be of the same installation type and version, reside on a like operating system (for example, UNIX and Linux) and contain only Oracle HTTP Server, OC4J, OPMN, and JAZN components.
An Oracle Application Server Farm is a collection of OracleAS Clusters and Oracle Application Server Instances that share the same DCM Metadata Repository. The shared repository is called the repository host. Section 1.1.1.4.2, "File-based Repository (Repository Host)" describes the repository host and its use.
An Oracle Application Server Farm may be of one of the following types: an OracleAS File-Based Farm or an OracleAS Database-based Farm.
In order to manage configurations, DCM stores information about the configuration (called configuration metadata in this guide) in the DCM Metadata Repository.
All configuration data is stored in the DCM Metadata Repository. The DCM Metadata Repository is a distinct metadata repository that is not dependent on the Oracle Application Server Metadata Repository.
The DCM Metadata Repository contains:
Configuration files for Oracle HTTP Server, OC4J, OPMN, and JAZN components
Deployed J2EE applications
Information about the Oracle Application Server Instance or OracleAS Cluster
A DCM Metadata Repository is stored in the file system or in the database, in one of the following configurations:
Oracle Application Server File-Based Farm with a standalone Oracle Application Server Instance (described in Section 1.1.1.4.1, "File-based Repository (Standalone Oracle Application Server Instance)")
Oracle Application Server File-Based Farm with repository host (described in Section 1.1.1.4.2, "File-based Repository (Repository Host)")
Oracle Application Server Database-based Farm (described in Section 1.1.1.4.3, "Database-based repository")
A single Oracle Application Server Instance that is not part of an OracleAS Cluster or Farm is called a standalone Oracle Application Server Instance. Every Oracle Application Server Instance has a local file-based repository. When an Oracle Application Server Instance is associated with an OracleAS File-Based Farm, but is not the repository host, the local file-based repository contains the Bill of Materials (BOM) that DCM uses to validate that the Oracle Application Server Instances's configuration is synchronized with the configuration metadata in the repository. When the Oracle Application Server Instance is not associated with an Oracle Application Server Farm, the local file-based repository is the only stored representation of the Oracle Application Server Instance's configuration information.
When an Oracle Application Server Instance is defined as the repository host for an OracleAS File-Based Farm, the repository for that Oracle Application Server Instance contains the configuration metadata for all Oracle Application Server Instances in the OracleAS File-Based Farm.
Since the repository host Oracle Application Server Instance stores configuration information on its file system, the repository host Oracle Application Server Instance should use mirrored or RAID disks to increase availability. However, when the repository host Oracle Application Server Instance is unavailable:
OracleAS Clusters using it still function normally, but cannot update any configuration information.
Read-only configuration operations are not affected on any running Oracle Application Server Instance (the Oracle Application Server Farm's cluster-wide configuration information is distributed and managed through the local repository.
Operations that attempt to change configuration information in the repository will cause an error. These operations must be delayed until the repository host Oracle Application Server Instance is available, or until the repository host Oracle Application Server Instance is relocated to another Oracle Application Server Instance within the Oracle Application Server Farm (see repositoryRelocated).
A Database-based repository is comprised of DCM schema. Storing the DCM Metadata Repository in a database may be useful as part of a site's high availability and backup strategy. Using a Database-based repository, the database serves as the repository host.
For all three types of DCM Metadata Repository: Database-based repository, file-based repository in standalone mode, or file-based repository host mode, an Oracle Application Server Instance always has a local file-based repository. In cases in which the Oracle Application Server Instance is not included in an OracleAS Farm, the local file-based repository is the sole persistent storage for that Oracle Application Server Instance's configuration metadata.
When you make configuration changes using either Oracle Enterprise Manager 10g Application Server Control Console or the dcmctl utility, the configuration management system updates the DCM Metadata Repository to reflect your changes.
|
See Also: Section 2.2.1, "Designating the OracleAS File-Based Farm Repository Host" , Section 2.2.2, "Adding Instances to an OracleAS Farm" and Section 2.2.3, "Creating a DCM-Managed OracleAS Cluster" for information on setting up the file-based repository and working with Oracle Application Server Instances and OracleAS Clusters. |
The DCM Metadata Repository is the definitive source for DCM-managed configuration information. If there is a difference between the Oracle Application Server Instance configuration stored in the repository and the Oracle Application Server Instance configuration in the associated ORACLE_HOME file system, the configuration in the file system is updated with the configuration in the repository. When the DCM repository and the file system configuration information are identical, the configuration is synchronized; its In Sync Status is true. (See getState and resyncInstance.)
Immediately after a configuration change, DCM automatically attempts to resynchronize the members of an OracleAS Cluster. If an Oracle Application Server Instance in an OracleAS Cluster is not available, the resynchronization occurs the next time the DCM daemon on the Oracle Application Server Instance is started. The DCM daemon can be started manually with the opmnctl startproc ias-component="dcm-daemon" command.
When a configuration change is made in a Oracle Application Server Farm or in a OracleAS Cluster, DCM attempts to ensure that the change will be successful by first applying the change to the local Oracle Application Server Instance, before attempting to propagate the change to other Oracle Application Server Instances. If the configuration change fails in the local Oracle Application Server Instance, its effects are automatically rolled back; no changes are made to any Oracle Application Server Instance.
In some cases, a configuration change may succeed on the local Oracle Application Server Instance, but fail on other Oracle Application Server Instances in the Oracle Application Server Farm or OracleAS Cluster. This could occur for many reasons, including insufficient disk space, file system security, or connectivity from the Oracle Application Server Instance to a dependent service such as Oracle Internet Directory or the database. In these cases, the In Sync status of the Oracle Application Server Instance is set to false.
When the In Sync status is set to false, the event is recorded, with details, in the DCM log file. When the problem that caused the status to be set to false is resolved, you should resynchronize the Oracle Application Server Instance, using the dcmctl resyncinstance command to copy the configuration stored in the repository for an Oracle Application Server Instance to the file system for the Oracle Application Server Instance (see resyncInstance).
The updateConfig command is another synchronization command that requires special handling. The updateConfig command takes configuration information from the file system and places this configuration information in the DCM repository. Ensure that you understand the guidelines for using the updateConfig command before you use it (see updateConfig).
Distributed Configuration Management consists of clients, a daemon, and the DCM Metadata Repository. Figure 1-1 shows the relationship between these and other Oracle Application Server components. The clusterable plugin's configuration is managed within the DCM Metadata Repository; clusterable plugins have a copy of persistent data stored in the DCM Metadata Repository. Non-clusterable plugins do not.
Figure 1-1 Distributed Configuration Management Architecture
The Oracle Enterprise Manager 10g Application Server Control Console and dcmctl contain the DCM client JAR file.
It is helpful at times to understand the order in which components are started upon initialization. The DCM bootstrap sequence is as follows:
The DCM client checks to determine whether Oracle Process Manager and Notification Server is running.
If not, it starts Oracle Process Manager and Notification Server.
If yes, it discovers and uses it.
The DCM client checks to determine whether the DCM daemon is running.
If not, it starts the daemon.
If yes, it discovers and uses it.
The DCM daemon checks the configuration file version of Oracle HTTP Server, OC4J, Oracle Process Manager and Notification Server, and Java Authentication and Authorization Service (using the configurable plug-ins shown in Figure 1-1).
The DCM daemon updates the configuration file versions, if required.
The DCM daemon restarts Oracle Process Manager and Notification Server, if required.
