| Oracle® Application Server High Availability Guide 10g (10.1.4.0.1) Part Number B28186-01 |
|
|
View PDF |
| Oracle® Application Server High Availability Guide 10g (10.1.4.0.1) Part Number B28186-01 |
|
|
View PDF |
This chapter describes the active-active, or OracleAS Cluster (Identity Management), topologies. This chapter contains the following sections:
For Oracle Application Server, there are two active-active topologies:
OracleAS Cluster (Identity Management), shown in Figure 3-1
Distributed OracleAS Cluster (Identity Management), shown in Figure 3-2
In active-active topologies all the nodes in the topology are active, meaning that they are ready to process requests from clients. An external load balancer directs requests to these nodes. To access the components running on these nodes, clients use the appropriate virtual server name configured on the load balancer. For example, clients trying to access OracleAS Single Sign-On or Oracle Delegated Administration Services use the virtual server name for the HTTP protocol, while clients trying to access Oracle Internet Directory use the virtual server name for the LDAP protocol.
The main difference between the two active-active topologies is that in the distributed topology the OracleAS Single Sign-On and Oracle Delegated Administration Services components run on one set of nodes, and Oracle Internet Directory and Oracle Directory Integration Platform run on a different set of nodes. In the OracleAS Cluster (Identity Management) topology, all these components run on the same set of nodes.
For an overview of these topologies, see Chapter 2, "Overview of Oracle Application Server High Availability Topologies".
Oracle Directory Integration Platform and Replication Server Notes
In active-active topologies, there is only one active instance of Oracle Directory Integration Platform server (odisrv) and the replication server (oidrepld) running at any given time. In other words, they run on only one node, although you install them on multiple nodes in an active-active topology.
If the node running odisrv or oidrepld fails, OID Monitor detects the failure and starts them up on another node. See Section 3.7.2, "OID Monitor Details" for details.
OracleAS Certificate Authority Not Supported
OracleAS Certificate Authority is not supported in OracleAS Cluster (Identity Management) topologies. You can install and run OracleAS Certificate Authority separately.
Special Requirements
To run OracleAS Cluster (Identity Management) topologies, you need to meet the following special requirements:
Load balancers: In order to distribute requests to the nodes, you need a load balancer in front of each set of nodes. The load balancer receives requests from clients and directs each request to a node using a load balancing algorithm.
Synchronized Time: You need to ensure that the time on all nodes are synchronized using Greenwich Mean Time so that there is a discrepancy of no more than 250 seconds between them.
Installation of the OracleAS Cluster (Identity Management) topologies is covered in the Oracle Application Server Installation Guide.
This topology, shown in Figure 3-1, consists of two main tiers:
On one tier, you run the Oracle Identity Management components (Oracle Internet Directory, OracleAS Single Sign-On, Oracle Delegated Administration Services, and Oracle Directory Integration Platform) on two or more nodes. Each node runs the Oracle Identity Management components mentioned above.
These nodes provide active-active availability for Oracle Identity Management services. OracleAS Single Sign-On and Oracle Delegated Administration Services run on a single OC4J_SECURITY instance in each Oracle home. Oracle Internet Directory also runs on each node.
A load balancer manages traffic to these nodes. To access the components running on these nodes, clients use the appropriate virtual server name configured on the load balancer.
The nodes running the Oracle Identity Management components should be functionally equivalent.
OracleAS Single Sign-On and Oracle Delegated Administration Services are configured in an OracleAS Cluster. This means that they are configured identically on all nodes. For example, if you have two nodes, OracleAS Single Sign-On instances running on both nodes have the same configuration, and all Oracle Delegated Administration Services instances have the same configuration. The load balancer can send requests to either instance. If you want to modify the Oracle Delegated Administration Services or OracleAS Single Sign-On configuration, see Section 3.8.5, "Changing Configuration for Components in Active-Active Topologies".
On another tier, you install and run the OracleAS Metadata Repository on an existing database. This database should already be configured for high availability, such as an Oracle RAC database.
You configure the load balancer with three virtual server names, as shown in Figure 3-1:
one for OracleAS Single Sign-On and Oracle Delegated Administration Services. Clients use this virtual server name to access these components. For example, in Figure 3-1, this virtual server name is sso.mydomain.com.
one for Oracle Internet Directory. LDAP and JNDI requests from middle tiers and OracleAS Single Sign-On use this virtual server name to access Oracle Internet Directory. For example, in Figure 3-1, this virtual server name is oid.mydomain.com.
one for the middle tiers. Clients use this virtual server name to access the middle tiers. In Figure 3-1, this virtual server name is mt.mydomain.com.
OracleAS Single Sign-On, Oracle Delegated Administration Services, and Oracle Internet Directory access the OracleAS Metadata Repository database through Oracle Net load balancing. OracleAS Single Sign-On establishes connection pools to access the database. A connection in the pool can be to any of the database instances in the Oracle RAC system.
Figure 3-1 OracleAS Cluster (Identity Management) Topology
This topology is a variation of the OracleAS Cluster (Identity Management) Topology. Instead of running all the Oracle Identity Management components on each of the OracleAS Cluster (Identity Management) nodes, you separate out OracleAS Single Sign-On and Oracle Delegated Administration Services to run them on another set of OracleAS Cluster (Identity Management) nodes. Figure 3-2 shows a diagram of the distributed OracleAS Cluster (Identity Management) topology.
The advantage of the distributed topology is that you can deploy the nodes running OracleAS Single Sign-On and Oracle Delegated Administration Services in the DMZ, and deploy the nodes running Oracle Internet Directory inside your intranet, protected by the firewalls, as shown in Figure 3-2.
This topology provides flexibility in placing your components. In this topology:
You install the OracleAS Metadata Repository in an existing high availability database.
Oracle Internet Directory and Oracle Directory Integration Platform run on active-active nodes. Typically these nodes are in the same tier as the database.
These nodes are fronted by a load balancer which directs requests to them. To access Oracle Internet Directory, clients use the LDAP virtual server name configured on the load balancer.
OracleAS Single Sign-On and Oracle Delegated Administration Services are configured in an OracleAS Cluster. This means that they are configured identically on all nodes. For example, if you have two nodes, OracleAS Single Sign-On instances running on both nodes have the same configuration, and all Oracle Delegated Administration Services instances have the same configuration. The load balancer can send requests to either instance. If you want to modify the Oracle Delegated Administration Services or OracleAS Single Sign-On configuration, see Section 3.8.5, "Changing Configuration for Components in Active-Active Topologies".
The nodes running OracleAS Single Sign-On and Oracle Delegated Administration Services are active-active nodes. These nodes are placed in the DMZ.
OracleAS Single Sign-On and Oracle Delegated Administration Services run in the OC4J_SECURITY instance on each node.
These nodes are also fronted by a load balancer which directs requests to them. Oracle Application Server middle tiers and clients access OracleAS Single Sign-On and Oracle Delegated Administration Services through the HTTP virtual server name configured on this load balancer (sso.mydomain.com in Figure 3-2).
Running Middle Tiers on the Same Tier as OracleAS Single Sign-On / Oracle Delegated Administration Services
You can run Oracle Application Server middle tiers on different nodes on the same tier as OracleAS Single Sign-On and Oracle Delegated Administration Services (see Figure 3-2). If there is no firewall separating the middle tier and OracleAS Single Sign-On and Oracle Delegated Administration Services, you can use the same load balancer to load balance the middle tiers also. In this case, you need to configure the load balancer with two virtual server names: one for clients to access OracleAS Single Sign-On and Oracle Delegated Administration Services (sso.mydomain.com in Figure 3-2) and one for clients to access the middle tiers (mt.mydomain.com in Figure 3-2).
Figure 3-2 Distributed OracleAS Cluster (Identity Management) Topology
In OracleAS Cluster (Identity Management) and distributed OracleAS Cluster (Identity Management) topologies, you need a load balancer to load balance requests among many Oracle Application Server instances.
When several Oracle Application Server instances are grouped to work together, they present themselves as a single virtual entry point to the system, which hides the multiple instance topology from the client. External load balancers can send requests to any Oracle Application Server instance in a cluster, as any instance can service any request.
Active-active topologies are scalable: you can increase the capacity of the system by introducing additional Oracle Application Server instances to the topology. These instances can be installed on separate nodes to allow for redundancy in case of node failure.
Load balancing also improves availability by routing requests to the most available instances. If one instance goes down, or is particularly busy, the external load balancer can send requests to another active instance.
|
Note: You cannot use a load balancer to load balance requests to Oracle Access Manager servers because these servers use a proprietary protocol. |
In Figure 3-1 and Figure 3-2, you can see the location of the load balancer in the topologies.
You can use different types of external load balancers with Oracle Application Server. Table 3-1 describes the different types.
Table 3-1 Types of External Load Balancers
The Oracle Identity Management tier uses an external load balancer. This external load balancer should have the following features:
virtual server name and port configuration
process failure detection
persistence configuration for HTTP URLs
Table 3-2 describes these features.
If you are using the same external load balancer for middle tiers, you may need additional features depending on which middle tier components you are running.
Oracle does not provide external load balancers. You can get external load balancers from other companies.
To ensure that your external load balancer can work with Oracle Application Server, check that your external load balancer meets the requirements listed in Table 3-2.
Note that you may not need all the requirements listed in the table. The requirements that you need depend on the topology being considered and on the Oracle Application Server components that are being load balanced.
Table 3-2 External Load Balancer Requirements
The Oracle Application Server Installation Guide provides details on how to install the OracleAS Cluster (Identity Management) and distributed OracleAS Cluster (Identity Management) topologies. Some highlights:
You need to configure the virtual server names on the load balancers before running the installer.
For the OracleAS Cluster (Identity Management) topology, you install the components in the following order:
Install OracleAS Metadata Repository on an existing database. This database should be a high availability database, such as an Oracle RAC database or a cold failover cluster database.
Install Oracle Internet Directory, Oracle Directory Integration Platform, OracleAS Single Sign-On, and Oracle Delegated Administration Services on each node. During installation, you enter the LDAP virtual server name and SSL port configured on the external load balancer.
For the distributed OracleAS Cluster (Identity Management) topology, you install the components in the following order:
Install OracleAS Metadata Repository on an existing database. This database should be a high availability database, such as an Oracle RAC database or a cold failover cluster database.
Install Oracle Internet Directory and Oracle Directory Integration Platform on each node.
Install OracleAS Single Sign-On and Oracle Delegated Administration Services on each node. During installation, you enter the LDAP virtual server name and LDAP SSL port configured on the load balancer.
In an OracleAS Cluster (Identity Management) topology, the port number used by all the Oracle Internet Directory instances must be the same. You should use the staticports feature during installation to enforce this. For example, you can configure the SSL port to be 636 and the non-SSL port to be 389 for all the Oracle Internet Directory instances in the topology.
The LDAP ports (SSL and non-SSL) configured on the load balancer can be different from the corresponding SSL and non-SSL Oracle Internet Directory ports. However, managing the components might be easier if you use the same port numbers for Oracle Internet Directory and the LDAP ports on the load balancer.
When managing the Oracle Internet Directory instances, using tools such as the Oracle Directory Manager tool or command-line tools, you typically need to specify connect information such as the name of the host running Oracle Internet Directory and the Oracle Internet Directory port number. If you have configured different LDAP port numbers on the load balancer and on Oracle Internet Directory itself, be sure you use the appropriate hostname:port number pair (that is, use the LDAP virtual hostname with the LDAP port configured on the load balancer, or use the physical hostname with the physical port number).
You can back up and recover files for all the nodes in the OracleAS Cluster (Identity Management) and distributed OracleAS Cluster (Identity Management) topologies using the OracleAS Backup and Recovery Tool. This tool is described in the Oracle Application Server Administrator's Guide.
The nodes on this tier run an Oracle database configured for high availability, such as an Oracle RAC database or a cold failover cluster database. You manage this database as you would any other Oracle database.
If you installed the OracleAS Metadata Repository in an existing Oracle RAC database, node failures are managed by Oracle Net and Oracle RAC. Oracle Net redirects requests to remaining active database instances if any of the other database instances fail.
If you installed the OracleAS Metadata Repository in a cold failover cluster database, node failure is performed by switching the virtual hostname and IP to the standby node and starting the database processes on that node. Section 7.1.5, "Failing Over a Cold Failover Cluster Database" provides instructions on how to accomplish these tasks.
This section contains the following topics:
Section 3.7.1, "Protection Against Process and Node Failures"
Section 3.7.3, "Oracle Internet Directory Metadata Synchronization"
OPMN and the load balancer protect against process failures and node failures.
OPMN runs on each node to provide process management, monitoring, and notification services for OC4J_SECURITY, Oracle HTTP Server, and Oracle Internet Directory processes. If any of these processes fails, OPMN detects the failure and attempts to restart the process.
For managing the Oracle Internet Directory processes, OPMN manages the OID Monitor process ("oidmon"), which in turn manages the oidldapd, oidrepld, and odisrv Oracle Internet Directory processes. If oidldapd, oidrepld, or odisrv fails, oidmon attempts to restart it locally. Similarly, if oidmon fails, OPMN tries to restart it locally.
If the restart is unsuccessful (for example, if OPMN fails to restart oidmon, or if oidmon fails to restart the Oracle Internet Directory processes), the load balancer detects the failure (usually through a non-response timeout) and directs requests to an active process running on another node in the topology.
|
Note: Only oneodisrv process and one oidrepld process can be active at any time in an OracleAS Cluster (Identity Management) or distributed OracleAS Cluster (Identity Management) topology. However, you can have multiple oidldapd processes running in the same cluster. See the Oracle Internet Directory Administrator's Guide for details. |
If OC4J_SECURITY is down on a node, the active Oracle HTTP Servers direct traffic to a surviving OC4J_SECURITY instance (this is by virtue of the fact that they are clustered). If Oracle HTTP Server is down on a node, then the surviving Oracle HTTP Servers on the other nodes service the requests.
If a node fails, the load balancer detects the failure and redirects requests to a remaining active node. Because each node provides identical services as the other nodes, all requests can be fulfilled by the remaining active nodes.
|
Note: If a node goes down or if the processes on a node are brought down due to planned maintenance, you should reconfigure the load balancer not to send traffic to this node. |
For information on running Oracle Internet Directory in an OracleAS Cluster (Identity Management) topology, and how directory replication can provide additional high availability, see Chapter 10, "Deploying Identity Management with Multimaster Replication".
In the OracleAS Cluster (Identity Management) and distributed OracleAS Cluster (Identity Management) topologies, the OID Monitor ("oidmon") on each node reports to the other nodes that it is running by sending a message to the Oracle Database every 60 seconds. When it does this, it also polls the database server to verify that all other directory server nodes are also running. If an OID Monitor on one of the nodes has not reported that it is running after a configurable amount of time, the other directory server nodes regard it as having failed. At this point, the following occurs on one of the other nodes that are still running:
The OID Monitor on that node brings up the processes that were running on the failed node.
The Oracle Directory Integration Platform server (odisrv) and the replication server (oidrepld) on that node continue processing the operations that were previously underway on the failed node.
The directory server itself (oidldapd) will not be failed over to the other node. This is because oidldapd by nature runs in an active-active mode. On the other hand, the Oracle Directory Integration Platform server and the replication server run in an active-passive mode, in the sense that there is only one instance of these servers running at any given time.
The OID Monitor on that node logs that it has brought up the processes that were previously running on the failed node.
Figure 3-3 and the accompanying text exemplify this process on two nodes, Node A and Node B.
The Oracle Internet Directory failover process follows these steps (shown in Figure 3-3):
Every 60 seconds, the OID Monitor on Node A reports that it is running by sending a message to the database.
The OID Monitor on Node B polls the database to learn which, if any, of the other nodes may have failed.
If the OID Monitor on Node B learns that Node A has not responded for the configured amount of time (see below for how this is set), it regards Node A as having failed. It then retrieves from the database the necessary information about the Oracle Internet Directory servers that were running on Node A. In this example, it learns that the directory replication server had been running on Node A.
The failover time is specified in the orclfailoverenabled attribute in the DSA config entry ("cn=dsaconfig, cn=configsets, cn=oracle internet directory"). By default, the orclfailoverenabled attribute is set to 5; the value is specified in minutes.
If your deployment requires a longer failover time, then you need to increase the value of the orclfailoverenabled attribute.
If you set the orclfailoverenabled attribute to 0, it means that Oracle Internet Directory processes will not fail over to another node. For example, assume Node A is running a directory replication server and its orclfailoverenabled attribute is set to 0. If Node A fails, the OID Monitor on Node B will not start up the directory replication server on Node B because on Node A, the orclfailoverenabled attribute is set to 0.
Because a directory replication server was not already running on Node B, the OID Monitor on Node B starts a directory replication server that corresponds to the directory replication server previously running on Node A.
|
See Also:
|
Unlike process failures, normal shutdowns are not treated as failovers. After a normal shutdown of Node A, the OID Monitor on Node B does not start the Oracle Internet Directory processes automatically on Node B. Here are two examples to show the differences:
Remember that in OracleAS Cluster (Identity Management) and distributed OracleAS Cluster (Identity Management) topologies, only one host runs the Oracle Directory Integration Platform server process (odisrv).
Example of a process failure: Assume Node A runs the directory replication server (oidrepld) and/or the Oracle Directory Integration Platform server (odisrv). If Node A fails, OID Monitor on Node B starts these processes on Node B after the configured time set in the orclfailoverenabled attribute. When Node A is restarted, the OID Monitor on Node A starts the servers automatically and requests the OID Monitor on Node B to stop the servers that were started on Node A.
Note that if the orclfailoverenabled attribute is set to 0, the OID Monitor on Node B will not start up any of the processes that were running on Node A. The orclfailoverenabled attribute is described in Section 3.7.2, "OID Monitor Details".
Example of a normal shutdown for odisrv: If you stop odisrv normally (for example, using the oidctl command), it is not considered a failure. This means that the odisrv process will not be started up automatically on the other node. You will need to start it up manually using the oidctl command. For information on starting odisrv through the oidctl command, see section 6.3.5, "Configuring an Oracle Directory Integration Platform Server Instance", in the Oracle Internet Directory Administrator's Guide.
The time on all nodes should be synchronized using Greenwich Mean Time so that there is a discrepancy of no more than 250 seconds between them.
If OID Monitor detects a time discrepancy of more than 250 seconds between the two nodes, the OID Monitor on the node that is behind stops all servers on its node. To correct this problem, synchronize the time on the node that is behind in time. The OID Monitor automatically detects the change in the system time and starts the Oracle Internet Directory servers on its node.
In OracleAS Cluster (Identity Management) and distributed OracleAS Cluster (Identity Management) topologies, it is necessary to synchronize Oracle Internet Directory metadata—for example, definitions of object classes, attributes, matching rules, ACPs, and password policies—on all the directory server nodes. Figure 3-4 and the accompanying text exemplify the process in which directory server metadata is synchronized between two directory server nodes, Host A and Host B, in an OracleAS Cluster (Identity Management) topology.
In Figure 3-4, directory server metadata in an OracleAS Cluster (Identity Management) topology is synchronized as follows:
On Host A, the directory server writes metadata changes to the shared memory on that same host.
OID Monitor on Host A polls the shared memory on that same host. When it discovers a change in the metadata, it retrieves the change.
OID Monitor sends the change to the Oracle Database, which is the repository for the directory server metadata in the OracleAS Cluster (Identity Management) environment.
OID Monitor on Host B polls the Oracle Database for changes in directory server metadata, and retrieves those changes.
OID Monitor on Host B sends the change to the shared memory on that same host.
The directory server on Host B polls the shared memory on that same host for metadata changes. It then retrieves and applies those changes.
This section describes the following procedures:
Section 3.8.4, "Checking the Status of Oracle Identity Management Components"
Section 3.8.5, "Changing Configuration for Components in Active-Active Topologies"
Section 3.8.6, "Changing the Password of the ODS Schema (Used by Oracle Internet Directory)"
You can use Application Server Control Console to manage the Oracle Identity Management components in OracleAS Cluster (Identity Management) topologies. To access Application Server Control Console for the OracleAS Cluster (Identity Management) nodes, you use the physical hostname in the Application Server Control Console URL, for example: http://im1.mydomain.com:1156 (assuming Application Server Control is running on port 1156).
For the OracleAS Metadata Repository, you manage the database using database management tools, such as Oracle Enterprise Manager.
The steps are slightly different, depending on whether you are running the OracleAS Cluster (Identity Management) or the distributed OracleAS Cluster (Identity Management) topology.
Start up the processes on the different tiers in the following order:
Start up the OracleAS Metadata Repository database.
On each node in the OracleAS Cluster (Identity Management), run OPMN to start up the Oracle Identity Management components:
ORACLE_HOME/opmn/bin/opmnctl startall
ORACLE_HOME refers to the Oracle Identity Management's Oracle home.
On each node, start up Application Server Control.
ORACLE_HOME/bin/emctl start iasconsole
Start up the processes on the different tiers in the following order:
Start up the OracleAS Metadata Repository database.
On each node in the Oracle Internet Directory tier:
Start up Oracle Internet Directory. You can do this using OPMN.
ORACLE_HOME/opmn/bin/opmnctl startall
ORACLE_HOME refers to the directory where you installed Oracle Internet Directory.
Start up Application Server Control.
ORACLE_HOME/bin/emctl start iasconsole
On each node in the OracleAS Single Sign-On and Oracle Delegated Administration Services tier:
Start up OracleAS Single Sign-On, Oracle Delegated Administration Services, and Oracle HTTP Server. You can do this using OPMN.
ORACLE_HOME/opmn/bin/opmnctl startall
ORACLE_HOME refers to the OracleAS Single Sign-On / Oracle Delegated Administration Services Oracle home.
Start up Application Server Control.
ORACLE_HOME/bin/emctl start iasconsole
The steps are slightly different, depending on whether you are running the OracleAS Cluster (Identity Management) or the distributed OracleAS Cluster (Identity Management) topology.
Stop the processes on the different tiers in the following order:
On each node in the OracleAS Cluster (Identity Management), run OPMN to stop the Oracle Identity Management components:
ORACLE_HOME/opmn/bin/opmnctl stopall
ORACLE_HOME refers to the Oracle Identity Management's Oracle home.
Stop the OracleAS Metadata Repository database.
Stop Application Server Control.
ORACLE_HOME/bin/emctl stop iasconsole
Stop the processes on the different tiers in the following order:
On each node in the OracleAS Single Sign-On and Oracle Delegated Administration Services tier:
Stop OracleAS Single Sign-On, Oracle Delegated Administration Services, and Oracle HTTP Server. You can do this using OPMN.
ORACLE_HOME/opmn/bin/opmnctl stopall
ORACLE_HOME refers to the OracleAS Single Sign-On / Oracle Delegated Administration Services Oracle home.
Stop Application Server Control.
ORACLE_HOME/bin/emctl stop iasconsole
On each node in the Oracle Internet Directory tier:
Stop Oracle Internet Directory. You can do this using OPMN.
ORACLE_HOME/opmn/bin/opmnctl stopall
ORACLE_HOME refers to the directory where you installed Oracle Internet Directory.
Stop Application Server Control.
ORACLE_HOME/bin/emctl stop iasconsole
Stop the OracleAS Metadata Repository database.
Use the following commands to check the status of Oracle Identity Management components:
Check the status of OPMN and OPMN-managed processes:
ORACLE_HOME/opmn/bin/opmnctl status
Check the status of Application Server Control.
ORACLE_HOME/bin/emctl status iasconsole
Check the status of Oracle Internet Directory:
ORACLE_HOME/ldap/bin/ldapcheck
Verify that you can log in to Oracle Internet Directory:
ORACLE_HOME/bin/oidadmin
Use the following login and password:
Login: orcladmin
Password: <orcladmin_password>
After installation, the orcladmin_password is the same as the ias_admin password.
Verify you can log in to OracleAS Single Sign-On:
http://host:HTTP_port/pls/orasso
For host, you specify the virtual hostname.
Login: orcladmin
Password: orcladmin_password
Verify you can log in to Oracle Delegated Administration Services:
http://host:HTTP_port/oiddas
For host, you specify the virtual hostname.
Login: orcladmin
Password: orcladmin_password
The OracleAS Single Sign-On and Oracle Delegated Administration Services instances in active-active topologies need to be configured identically. This means that if you change the configuration for one instance, you also need to make the same change in all the other instances in the topology.
To ensure that configuration stays consistent across the topology, note the following:
After you make a configuration change to OPMN, Oracle HTTP Server, or OC4J_SECURITY, run the following DCM command to upload the configuration information to the OracleAS Metadata Repository and propagate the change to all instances in the OracleAS Clusters.
ORACLE_HOME/dcm/bin/dcmctl updateConfig
Configuration changes to Oracle Internet Directory are not automatically managed across the OracleAS Clusters. If you make changes to configuration files, primarily the wallet files, you need to make the same changes manually to all nodes in the OracleAS Clusters.
If you change the password to the Oracle Internet Directory-designated database, then you must update each of the other nodes in the OracleAS Cluster (Identity Management) topology. You can change the ODS database user account password using the oidpasswd utility.
To change the ODS database user password, invoke the following command on one of the Oracle Internet Directory nodes:
oidpasswd connect=db-conn-str change_oiddb_pwd=true
On all other Oracle Internet Directory nodes, invoke the following command to synchronize the password wallet:
oidpasswd connect=db-conn-str create_wallet=true
|
Note: If you are running Oracle Internet Directory in an Oracle RAC environment, see Section 9.6, "About Changing the ODS Password on an Oracle RAC System". In an Oracle RAC environment, you have to ensure that theoidpwdlldap1 file is the same on all your Oracle RAC nodes. |
|
See Also:
|
