|
Distributed Configuration Management Reference Guide
10g (9.0.4) Part No. B12052-01 |
|
|
Distributed Configuration Management Reference Guide
10g (9.0.4) Part No. B12052-01 |
|
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 manage the configurations of multiple Oracle Application Server instances.
Distributed Configuration Management (DCM) features enable you to:
Keep multiple configurations synchronized
Archive and restore versions of configurations
Export and import configurations between Oracle Application Server instances
DCM manages configuration information for the following Oracle Application Server components:
Oracle HTTP Server
Oracle Application Server Containers for J2EE (OC4J)
OC4J Applications
Oracle Process Manager and Notification Server (OPMN)
Oracle Application Server Java Authentication and Authorization Service (JAZN)
Distributed Configuration Management consists of clients, a daemon, and a metadata repository. Figure 1-1 shows the relationship between these and other Oracle Application Server components.
Figure 1-1 Distributed Configuration Management Architecture
The Oracle Enterprise Manager Application Server Control servlet and dcmctl contain the Distributed Configuration Management client JAR file. The Distributed Configuration Management bootstrap sequence is:
The Distributed Configuration Management 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 Distributed Configuration Management client checks to determine whether the Distributed Configuration Management daemon is running.
If not, it starts the daemon.
If yes, it discovers and uses it.
The Distributed Configuration Management daemon checks the configuration file version of Oracle HTTP Server, Oracle Application Server Containers for J2EE, Oracle Process Manager and Notification Server, and Java Authentication and Authorization Service (using the configurable plug-ins shown in Figure 1-1.
The Distributed Configuration Management daemon updates the configuration file versions, if required.
The Distributed Configuration Management daemon restarts Oracle Process Manager and Notification Server, if required.
This section covers the following topics:
Understanding the Distributed Configuration Management Tools and Scope
Understanding the Distributed Configuration Management Metadata Repository
Distributed Configuration Management enables you to:
Manage clusters and farms of Oracle Application Server instances. Manage the configuration of individual components, such as OC4J instances, Oracle HTTP Server, OPMN, or the Java Authentication and Authorization Service (JAZN).
Perform cluster-wide Oracle Application Server Containers for J2EE application deployment.
Manage versions of configurations with archive, save and restore, and import and export functions.
The dcmctl command is the Distributed Configuration Management command-line utility. You can use dcmctl to manage configurations and to deploy applications. Chapter 2, " dcmctl Commands ", contains instructions on using dcmctl and descriptions of the available dcmctl commands.
All configuration and topology data is stored in the Distributed Configuration Management metadata repository, which is optionally stored as part of the Oracle Application Server Metadata Repository. The Distributed Configuration Management metadata repository is a distinct metadata repository that is not dependent on the Oracle Application Server Metadata Repository.
|
See Also: Oracle Application Server 10g High Availability Guide for information on working with Oracle Application Server instances, farms, and clusters. |
The Distributed Configuration Management metadata repository contains the following:
Configuration files for Oracle HTTP Server, Oracle Application Server Containers for J2EE, Oracle Process Manager and Notification Server, and Java Authentication and Authorization Service.
Topology information describing a farm and the instances and clusters that are part of the farm
Deployed J2EE applications
An Oracle Application Server farm is a collection of instances that share the same configuration management metadata repository. A farm can use either a file-based repository or database repository.
There are three types of metadata repository configuration: File-based (standalone instance), File-based (with repository host) and Database:
File-based repository (standalone instance) – Every instance includes a local file- based repository. When an instance is in standalone mode, this repository stores the configuration metadata for the instance. When the instance is associated with a farm, either database or file-based, and the instance is not the repository host, the local file-based repository contains the Bill of Materials (BOM) that DCM uses to validate that the instance is in sync with the configuration metadata in the repository.
File-based repository (with repository host) – When an instance is defined as the repository host for a file-based farm, the file-based repository for the instance contains the configuration metadata for all instances in the farm.
A Database repository – comprised of Distributed Configuration Management schema. Storing the metadata repository in a database may be useful as part of a site’s high availability and backup strategy. Using a database repository, the database serves as the repository host.
For all three types of metadata repository: database repository, file-based repository in standalone mode, or file-based repository host mode, an instance always has a local file based repository. In cases where the instance is not included in a farm this is the sole storage for the configuration metadata for the instance.
You can access each configuration management repository using either Oracle Enterprise Manager Application Server Control (Application Server Control) or the dcmctl utility.
|
See Also: Oracle Application Server 10g High Availability Guide for information on setting up the repository and working with clusters. |
The DCM repository is viewed as the definitive source for configuration information that DCM manages. If there is a difference in the configuration stored in the repository and what is in the associated ORACLE_HOME file system for an instance, the configuration in the file system is updated with the configuration in the repository. When the DCM repository and the file system configuration information have no differences, the configuration is synchronized or "In Sync".
DCM attempts to resynchronize the members of a cluster automatically and immediately after a configuration change. If an instance in a cluster is not available, the resynchronization occurs the next time the DCM daemon on the instance is started. The DCM daemon is started when an application server restarts, or manually using the dcmctl start -admin command.
In a farm or in a cluster, when you make a configuration change, DCM attempts to assure that a configuration change will be successful by applying the change to the local instance before attempting to propagate the change to other instances. If the local configuration change fails, its affects are automatically rolled back. There are cases where a configuration change may be successful on one instance but fail on other instances in the farm or cluster. There are many reasons why this could occur, including issues related to disk space, file system security, or connectivity from the Instance to a dependent services (for example, OID, or the database). In these cases an instance may be marked with the "In Sync" status set to False.
When the "In Sync" status is set to False, this is noted, with details in the DCM log. In this case, when the problem associated with this condition is resolved, you should resynchronize the instance using the dcmctl resyncinstance command. This command instructs DCM to copy the configuration stored in the repository for an instance to the file system for the instance (see resyncInstance).
The updateConfig command is a special kind of 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. Read the guidelines for using the updateConfig command carefully before using this command (see updateConfig).
This section covers the following topics:
The DCM archive feature provides a convenient and easy means of managing "snapshots" of the DCM managed portions of Oracle Application Server system configuration. Archives are useful for staging changes, recovering from errors, and to provision DCM managed configuration information associated with one Oracle Application Server instance to another.
DCM managed system configuration includes configuration for a farm, clusters, Oracle HTTP Server, OPMN, OC4J, and Oracle Application Server Java Authentication and Authorization Service. For OC4J, in addition to configuration information related to the container itself, DCM manages all deployed J2EE applications.
Note that it is often not expensive to take an archive in terms of disk space. Within an Oracle Application Server instance, there are many managed objects (including configuration files and EAR or WAR files). When an archive is taken only one copy of any given version of a managed object is saved in the repository.
You can use archives to restore the state of an Oracle Application Server instance or cluster to a prior state. The DCM system automatically takes an archive when it performs certain administrative operations so that the Administrator has the option to "rollback" undesired administrative changes. The number of automatic archives that are saved is configurable.
Administrators also have the option to explicitly create archives to satisfy the site’s change management or staging policy. For example, when staging groups of changes that an Administrator may want to collectively rollback, or push to other Oracle Application Server instances, it is a good idea to explicitly create an archive.
The state of an Oracle Application Server instance can be rolled back in place to the state of any available archive. An archive can also be applied to another Oracle Application Server Instance in the same farm, or exported and imported to another farm and then applied to an instance in that farm.
If you use DCM clusters, DCM assures that any change to the configuration is automatically distributed to all members of the cluster. As an alternative to using clusters, an archive of a staged configuration can be applied manually to non-clustered instances in a farm.
A hybrid staging solution is to first stage and test changes to a non-clustered instance, archive the changes, and finally apply the archive to a DCM cluster. These changes are then automatically propagated to all members of the cluster.
Note that after applying an archive to an instance other than the one from which it was created, some instance specific configuration data may have to be modified. DCM automates this for IP addresses and hostnames.There are two ways to create archives:
Automatic Archiving creates an archive automatically prior to performing a DCM administrative operation. Use the dcmctl set command to verify that auto-archiving is enabled.
For example:
dcmctl set Verbose: true Sort: false Warning: true Debug: true Default Timeout: 120 Auto Archive Count: 15
The dcmctl set command shows the Auto Archive count value. If the Auto Archive Count is nonzero, then auto-archiving is enabled and an archive will be automatically created prior to issuing a DCM administrative command.
Even when auto-archiving is enabled, the Administrator may want to explicitly create a named version of an archive prior to performing a DCM administrative operation. Explicitly created archives are saved until the Administrator deletes them.
For example, to create an archive prior to deploying a new J2EE application named "foo" use the command,
dcmctl createArchive -arch PriorToDeployingFoo -comment "prior to foo deploy V1"
When using createArchive, it is a good practice to use an archive name and a corresponding comment that identifies the version of configuration that the archive is associated with. Regardless of whether you use automatic or explicit archiving, it is recommended that you create an archive prior to performing any administrative operation.
Oracle Application Server instances grouped in a cluster can be managed using Oracle Enterprise Manager Application Server Control (Application Server Control) or dcmctl from a single point of administration on any instance in the cluster. It is recommended that one instance be used as the administrative point for the entire cluster at any point in time.
When changing instance specific configuration, for example port numbers, host names or virtual hosts, on a particular instance in the cluster, you must ensure that there are no other administrative changes are being made concurrently in the cluster to avoid conflicting changes to configuration resulting in an unusable configuration.
Concurrent administration within a cluster is strongly discouraged. If multiple administrative operations are issued at the same time in a cluster, this can lead to errors and associated confusing error messages. For example, a concurrent attempt to change the configuration of an instance being deleted really does not make sense. Specifying a single instance in a cluster as the management point ensures that operations are executed in the correct order and are properly serialized.
Use of archiving, either auto-archiving or manual archiving, prior to issuing any administrative operation is also recommended. Auto-archiving automatically detects that the Oracle Application Server instance is associated with a cluster and auto-archives are created of the cluster configuration prior to administrative operations.
|
 Copyright © 2003 Oracle Corporation All rights reserved |
|