| 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-passive, or OracleAS Cold Failover Cluster, topologies. This chapter contains the following sections:
Section 4.1, "Types of OracleAS Cold Failover Cluster Topologies"
Section 4.2, "Common Characteristics of OracleAS Cold Failover Cluster Topologies"
Section 4.5, "Protection Against Process Failures and Node Failures"
With Oracle Application Server, you can create the following OracleAS Cold Failover Cluster topologies:
Distributed OracleAS Cold Failover Cluster (Infrastructure) Topology
OracleAS Cold Failover Cluster (Identity Management) Topology
DistributedOracleAS Cold Failover Cluster (Identity Management) Topology
OracleAS Cold Failover Cluster topologies are active-passive topologies, which mean that only you have one active node that is running the Oracle Application Server components, and another node, the passive node, on standby. If the active node fails, the passive node takes over and runs the Oracle Application Server components.
As with OracleAS Clusters, or active-active, topologies, OracleAS Cold Failover Cluster topologies protect against process failures and node failures. Section 4.5, "Protection Against Process Failures and Node Failures" provides the details.
In the distributed version of the OracleAS Cold Failover Cluster topologies, the Oracle Identity Management components run on different sets of nodes, as follows: the OracleAS Single Sign-On and Oracle Delegated Administration Services components run on one set of nodes, while the Oracle Internet Directory and Oracle Directory Integration Platform components run on another set of nodes.
Also, in the distributed topologies, OracleAS Single Sign-On/Oracle Delegated Administration Services can be installed in either an active-active topology or an active-passive topology.
In the non-distributed version of the topologies, all the Oracle Identity Management components run on the same node.
The following sections describe the topologies in detail.
Figure 4-1 shows an OracleAS Cold Failover Cluster (Infrastructure). It consists of:
two nodes in a hardware cluster. One of the nodes is the active node, and the other node is the passive node. The active node runs all the components and responds to all requests. If the active node goes down for any reason, the passive node takes over: it runs the components and handles all the requests.
shared storage that can be mounted by both nodes. The shared storage contains the single Oracle home for the Oracle Identity Management and OracleAS Metadata Repository. Only one node, the active node, is mounted to the shared storage at any time.
virtual hostname and virtual IP address. The virtual hostname and virtual IP address point to the active node. Because clients use this virtual hostname, instead of the node's physical hostname, to access the OracleAS Infrastructure, clients do not need to know which node in the cluster is running the OracleAS Infrastructure components. You specify this virtual hostname during installation.
On Windows, you also need to install Oracle Fail Safe on the local storage of each of the OracleAS Cold Failover Cluster (Infrastructure) nodes.
Figure 4-1 OracleAS Cold Failover Cluster (Infrastructure): Normal Operation
In a distributed OracleAS Cold Failover Cluster (Infrastructure) topology (see Figure 4-2), you distribute the Oracle Identity Management components to create a more secure environment. You deploy OracleAS Single Sign-On and Oracle Delegated Administration Services separately from the other OracleAS Infrastructure components.
Typically, you run OracleAS Single Sign-On and Oracle Delegated Administration Services between two firewalls (in a DMZ), and Oracle Internet Directory, Oracle Directory Integration Platform, and OracleAS Metadata Repository behind the inner firewall, as shown in Figure 4-2.
Clients from outside the first firewall can access OracleAS Single Sign-On and Oracle Delegated Administration Services using the virtual hostname (sso.mydomain.com in Figure 4-2). The second firewall prevents clients from accessing the OracleAS Metadata Repository and Oracle Internet Directory directly.
To access Oracle Internet Directory, OracleAS Single Sign-On and Oracle Delegated Administration Services use the virtual hostname (oidmr.mydomain.com in Figure 4-2).
The figure also shows Oracle Application Server middle tiers running on the same nodes as OracleAS Single Sign-On and Oracle Delegated Administration Services.
Table 4-1 lists the tiers in this topology:
Table 4-1 Tiers in a Distributed OracleAS Cold Failover Cluster (Infrastructure)
| Tier | Configuration |
|---|---|
|
OracleAS Metadata Repository, Oracle Internet Directory, Oracle Directory Integration Platform |
Active-passive |
|
OracleAS Single Sign-On and Oracle Delegated Administration Services |
Active-active or active-passive |
If you want to run OracleAS Single Sign-On and Oracle Delegated Administration Services in active-active configuration instead of active-passive configuration, you will need a load balancer to distribute requests among the active-active instances. This is similar to the OracleAS Single Sign-On and Oracle Delegated Administration Services tier described in Section 3.1.2, "DistributedOracleAS Cluster (Identity Management) Topology".
On Windows, you have to install Oracle Fail Safe on the local storage of each of the nodes in active-passive configuration, that is, the nodes that are running OracleAS Metadata Repository and Oracle Internet Directory. If you are running OracleAS Single Sign-On and Oracle Delegated Administration Services in active-passive configuration, then these nodes also need to have Oracle Fail Safe.
Only one node of the hardware cluster is active at any time. The virtual hostname (oidmr.mydomain.com) points to the active node. The shared storage is mounted only on the active node.
To access the components running in this tier, clients use the virtual hostname. For example, to access the OracleAS Metadata Repository or Oracle Internet Directory, you use the virtual hostname (oidmr.mydomain.com).
OPMN runs on this tier to manage the Oracle Internet Directory processes.
If the active tier fails, the clusterware fails over the OracleAS Metadata Repository, Oracle Internet Directory, Application Server Control, and OPMN processes to the standby node.
The clusterware also mounts the shared storage on the new active node and associates the virtual hostname and virtual IP address with the new active node.
Failover from the active node to the passive node occurs at the node level. All the components running on the active node (Oracle Internet Directory, Oracle Directory Integration Platform, and OracleAS Metadata Repository) fail over together to the passive node.
On Windows, Oracle Fail Safe performs the failover.
Typically, OPMN monitors the Oracle Application Server processes for you, so you do not have to monitor them yourself. However, if you want to monitor them manually, you can use Application Server Control or commands to monitor the status of OracleAS Infrastructure components running on all the nodes.
See Section 7.4, "Checking the Status of OracleAS Metadata Repository" and Section 3.8.4, "Checking the Status of Oracle Identity Management Components" for a list of commands that you can run. Make sure you run the commands on nodes in the appropriate tier.
Figure 4-2 Distributed OracleAS Cold Failover Cluster (Infrastructure) Topology
In an OracleAS Cold Failover Cluster (Identity Management) topology (see Figure 4-3), you install and run the Oracle Identity Management components in an OracleAS Cold Failover Cluster. For the OracleAS Metadata Repository, you install it in an existing database using the OracleAS RepCA. This database should be a high availability database, such as an Oracle Real Application Clusters (Oracle RAC) database or a cold failover cluster database. Figure 4-3 shows a cold failover cluster database in the topology.
Table 4-2 lists the tiers in this topology:
Table 4-2 Tiers in an OracleAS Cold Failover Cluster (Identity Management)
| Tier | Configuration |
|---|---|
|
OracleAS Metadata Repository |
Installed in an existing database |
|
Oracle Identity Management components |
Active-passive |
The nodes running the Oracle Identity Management components need to be in a hardware cluster. You also need a shared storage for these hardware cluster nodes. You will install the Oracle home for the Oracle Identity Management components on the shared storage.
You need a virtual hostname and virtual IP address for the hardware cluster nodes running the Oracle Identity Management components. Clients, including middle tiers, use the virtual hostname to access the Oracle Identity Management components.
On Windows, you have to install Oracle Fail Safe on the local storage of each node running Oracle Identity Management.
Middle-tier components and applications access Oracle Identity Management services by making LDAP requests to Oracle Internet Directory, and HTTP/HTTPS requests to OracleAS Single Sign-On and Oracle Delegated Administration Services.
Clients can perform single sign-on by making direct HTTP/HTTPS requests to OracleAS Single Sign-On server using the single sign-on URL. This URL uses the virtual hostname configured for Oracle Identity Management.
OracleAS Single Sign-On establishes connection pools to access the OracleAS Metadata Repository database. A connection in the pool uses Oracle Net to communicate with the active database instance(s). Oracle Net is also used by middle-tier components and Oracle Internet Directory to connect to the database.
If the node on which the Oracle Identity Management components are running fails, the components fail over to the other node. The virtual hostname and IP also switch to point to the new active node.
If You Are Using a Cold Failover Cluster Database
If you are using a cold failover cluster database, you can install and run Oracle Identity Management on the same nodes as the database. You can also make each node an active node: one node can be the active node for the Oracle Identity Management components, and the other node can be the active node for the database. For example, in Figure 4-3, Node 1 is the active node for Oracle Identity Management, but Node 2 is the active node for the database containing the OracleAS Metadata Repository. This enables you to use both nodes at the same time. If one node fails, then processes running on that node are failed over to the other node, and that node runs all the processes (database and Oracle Identity Management).
To do this, you need to set up separate virtual hostnames and virtual IP addresses for Oracle Identity Management and the database because they point to different active nodes. In Figure 4-3, the virtual hostname for Oracle Identity Management, im.mydomain.com, points to Node 1, but the virtual hostname for the database, mr.mydomain.com, points to Node 2.
Figure 4-3 OracleAS Cold Failover Cluster (Identity Management) Topology
This topology is similar to the one described in Section 4.1.3, "OracleAS Cold Failover Cluster (Identity Management) Topology" except that you install and run OracleAS Single Sign-On and Oracle Delegated Administration Services on one set of nodes, and Oracle Internet Directory on another set of nodes.
You run the OracleAS Single Sign-On and Oracle Delegated Administration Services nodes in an active-active configuration, which means that you place a load balancer in front of these nodes. The load balancer directs requests to these nodes.
For the Oracle Internet Directory nodes, you run them in an active-passive configuration. If you have an existing cold failover cluster database, you can install Oracle Internet Directory on the same nodes as the database.
For the OracleAS Metadata Repository, you can install it, using OracleAS RepCA, in an existing Oracle RAC database for active-active availability or in a cold failover cluster database for active-passive availability.
You might choose this topology to create a more secure configuration. This topology enables you to run OracleAS Single Sign-On and Oracle Delegated Administration Services in the DMZ, and Oracle Internet Directory and the OracleAS Metadata Repository database in your intranet behind the DMZ.
Figure 4-4 shows a distributed OracleAS Cold Failover Cluster (Identity Management). The OracleAS Metadata Repository is installed in an existing cold failover cluster database. Oracle Internet Directory is installed on the same nodes as the cold failover cluster database.
If you install Oracle Internet Directory on the same cluster as the cold failover database, you need separate virtual hostnames and virtual IP addresses for the database and for Oracle Internet Directory.
Table 4-3 lists the tiers in this topology:
Table 4-3 Tiers in a Distributed OracleAS Cold Failover Cluster (Identity Management)
| Tier | Configuration |
|---|---|
|
OracleAS Metadata Repository |
Installed in an existing database |
|
Oracle Internet Directory and Oracle Directory Integration Platform |
Active-passive |
|
OracleAS Single Sign-On and Oracle Delegated Administration Services |
Active-passive or active-active |
On Windows, you also have to install Oracle Fail Safe on the local storage of each active-passive node.
If You Are Running a Cold Failover Cluster Database
If you are using a cold failover cluster database, you can install and run Oracle Internet Directory on the same hardware cluster nodes as the database. You can also make each node an active node: one node can be the active node for Oracle Internet Directory, and the other node can be the active node for the database. For example, in Figure 4-4, Node 1 is the active node for Oracle Internet Directory, but Node 2 is the active node for the database containing the OracleAS Metadata Repository. This enables you to use both nodes at the same time. If one node fails, then processes running on that node are failed over to the other node, and that node runs all the processes (database and Oracle Internet Directory).
To do this, you need to set up separate virtual hostnames and virtual IP addresses for Oracle Internet Directory and the database because they point to different active nodes. In Figure 4-4, the virtual hostname for Oracle Internet Directory, oid.mydomain.com, points to Node 1, but the virtual hostname for the database, mr.mydomain.com, points to Node 2.
Figure 4-4 Distributed OracleAS Cold Failover Cluster (Identity Management)
OracleAS Cold Failover Cluster topologies run Oracle Application Server components in active-passive mode, but in some topologies you may run some of the components in active-active mode.
OracleAS Cold Failover Cluster topologies have the following characteristics in common:
Each topology includes two nodes in a hardware cluster. One of these nodes is active, and the other node is passive. The active node runs the Oracle Application Server components and handles all the requests from clients. If the active node goes down for any reason, the passive node takes over and runs the components.
In the distributed version of the OracleAS Cold Failover Cluster topologies, you may have multiple tiers of hardware cluster nodes running the Oracle Application Server components. For example, in the distributed OracleAS Cold Failover Cluster (Identity Management) topology (see Figure 4-4), one set of hardware cluster nodes runs OracleAS Single Sign-On and Oracle Delegated Administration Services, while another set of hardware cluster nodes runs Oracle Internet Directory and Oracle Directory Integration Platform.
Each set of hardware cluster nodes is associated with shared storage. You install the Oracle home for Oracle Application Server on the shared storage.
The active node mounts this shared storage during normal operation. If the active node goes down, then the passive node mounts the shared storage.
Each set of hardware cluster nodes is also associated with a virtual hostname and virtual IP address. The virtual hostname and virtual IP address point to the active node. Clients use this virtual hostname, instead of the node's physical hostname, to access the components running on the hardware cluster. Clients do not need to know which node in the hardware cluster is actually processing their requests.
The example topology in Figure 4-5 uses the virtual hostname cfcinfra.mydomain.com and virtual IP 144.25.245.1 are used. When node 1 fails, a failover event occurs, and the virtual hostname and IP are moved to the standby node (node 2), which becomes the active node. The failure of the active node is transparent to the clients.
On Microsoft Windows, the OracleAS Cold Failover Cluster topologies have the characteristics described in the previous section, but it also has these unique features:
The nodes in the hardware cluster need to have Microsoft Cluster Server software for managing high availability for the cluster.
You need to install Oracle Fail Safe on the local storage of each node. Oracle Fail Safe works with Microsoft Cluster Server to manage the following:
The integration of Oracle Fail Safe and Microsoft Cluster Server provides an easy-to-manage environment and automatic failover functionality in the OracleAS Cold Failover Cluster topologies. The OracleAS Metadata Repository database, its TNS listener, and OPMN run as Windows services and are monitored by Oracle Fail Safe and Microsoft Cluster Server. If any of these services fails, Microsoft Cluster Server tries to restart the service three times (the default setting) before failing the group to the standby node. Additionally, OPMN monitors, starts, and restarts the Oracle Internet Directory, OC4J, and Oracle HTTP Server components.
Resource Groups
Central to the Windows OracleAS Cold Failover Cluster topologies is the concept of resource groups. A group is a collection of resources that you set up in Oracle Fail Safe. During failover from the active node to the standby node, the resources associated with the group fail over as a unit. When you install an OracleAS Cold Failover Cluster topology, you create a group for the topology.
The resources in a group depend on the Oracle Application Server components you are running on the hardware cluster nodes. For the OracleAS Cold Failover Cluster (Infrastructure) topology, where the hardware cluster nodes run all the OracleAS Infrastructure components, the group consists of the following:
OracleAS Metadata Repository database
OPMN
Application Server Control Console
Database Console
In other topologies, the resource group contains a subset of the components. For example, on hardware cluster nodes that run only Oracle Internet Directory and Oracle Directory Integration Platform, the resource group contains only the following:
virtual hostname and virtual IP address for the hardware cluster
shared storage
OPMN
Application Server Control Console
|
Note: Only static IP addresses can be used in the OracleAS Cold Failover Cluster (Infrastructure) topology for Windows. |
Figure 4-5 OracleAS Cold Failover Cluster (Infrastructure) on Microsoft Windows
For backing up OracleAS Cold Failover Cluster environments and recovering these backups during failures, use the backup and recovery procedures provided in the Oracle Application Server Administrator's Guide.
Additionally, the following considerations should be noted:
Backup considerations:
Oracle recommends that you place archive logs for the OracleAS Metadata Repository on the shared disk. This ensures that, when failing over from one cluster node to another in the case of media recovery, the archive logs are also failed over and available.
You can generate archive logs to a local file system; however, the same path must be available during runtime on whichever node is hosting the OracleAS Infrastructure instance.
Proper capacity planning is required in order to ensure adequate space is available to store the desired number of archive logs.
Recovery considerations:
If archive logs are stored on a local file system, in the case of media recovery, all archive logs must be made available to the application server instance performing the recovery. Recovery can be performed on either node of the cluster.
In the OracleAS Cold Failover Cluster (Infrastructure) and distributed OracleAS Cold Failover Cluster (Infrastructure) topologies, the OracleAS Metadata Repository and Oracle Identity Management components run on the same tier. The OracleAS Metadata Repository is installed by the installer in a cold failover cluster database.
In the other topologies, OracleAS Cold Failover Cluster (Identity Management) and distributed OracleAS Cold Failover Cluster (Identity Management), the OracleAS Metadata Repository is installed separately from Oracle Identity Management. Typically, you would install the OracleAS Metadata Repository in an existing high availability database, such as an Oracle RAC database.
If you are running the OracleAS Metadata Repository on a cold failover cluster database, you can use the database console to manage it. Note that before starting or stopping the database console, you need to set the ORACLE_HOSTNAME environment variable to the virtual hostname of the hardware cluster. For example, in the topology shown in Figure 4-2, you would set the ORACLE_HOSTNAME environment variable to oidmr.mydomain.com.
On UNIX, you can set the environment variable as follows:
C shell example:
> setenv ORACLE_HOSTNAME oidmr.mydomain.com
Bourne or Korn shell example:
> ORACLE_HOSTNAME=oidmr.mydomain.com > export ORACLE_HOSTNAME
On Windows, you can set the environment variable using the System control panel. Select the Advanced tab to access the environment variable section.
After setting ORACLE_HOSTNAME, you can start or stop the database console (you also need to set the ORACLE_HOME and ORACLE_SID environment variables before starting the database console):
> cd ORACLE_HOME/bin > emctl start dbconsole
If you are using the Automatic Storage Management (ASM) feature of Oracle Database 10g for the OracleAS Metadata Repository, you must configure the Cluster Synchronization Services (CSS) daemon on the standby node. The CSS daemon synchronizes ASM instances with the database instances that use the ASM instances for database file storage. Specific instructions are provided in the OracleAS Cold Failover Cluster chapter in the Oracle Application Server Installation Guide.
OPMN and the hardware cluster protect against process failures and node failures.
To protect against process failures, OPMN runs on the active node to provide process management, monitoring, and notification services for the OC4J_SECURITY, Oracle HTTP Server, and Oracle Internet Directory processes. If any of these processes fails, OPMN detects the failure and attempts to restart it. If the restart is unsuccessful, the clusterware detects the failure and fails over all the processes to the passive node.
To manage Oracle Internet Directory, OPMN monitors the OID Monitor process ("oidmon"), which in turn monitors 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 a node fails, the clusterware detects the failure and fails over all the processes to the passive node.
|
Note: While the hardware cluster framework can start, monitor, or fail over OracleAS Infrastructure processes, these actions are not automatic. You have to do them manually, create scripts to automate them, or use scripts provided by the cluster vendor for OracleAS Cold Failover Cluster. |
If the primary node fails, the virtual IP address is manually enabled on the secondary node (Figure 4-6). All the OracleAS Infrastructure processes are then started on the secondary node. Middle tiers accessing the OracleAS Infrastructure will see a temporary loss of service as the virtual IP and the shared storage are moved over to Node2, and the database, database listener, and all other OracleAS Infrastructure processes are started. Once the processes are up, middle-tier processes that were retrying during this time are reconnected. New connections are not aware that a failover has occurred.
Figure 4-6 OracleAS Cold Failover Cluster (Infrastructure): After Failover
Figure 4-7, Figure 4-8, and Figure 4-9 show the Oracle Fail Safe Manager screens for a failover operation from the active node to the standby node on Windows.
Figure 4-7 Screen 1 Performing Failover for Oracle Identity Management in an Active-Passive Configuration
Figure 4-8 Screen 2 Performing Failover for Oracle Identity Management in an Active-Passive Configuration
Figure 4-9 Screen 3 Performing Failover for Oracle Identity Management in an Active-Passive Configuration
The following shows the steps to failover from the active node to the standby node on Linux systems.
Steps to Perform on the Failed Node
Make sure all processes belonging to the OracleAS Cold Failover Cluster (Infrastructure) instance on the failed node are down.
Login as root.
Use the following command to stop the Oracle Cluster Synchronization Services (CSS) daemon, ocssd, if it is running:
# /etc/init.d/init.cssd stop
Unmount the file system using the following command:
# umount <mount_point>
If the file system is busy, check which processes are using the file system with the following command:
# fuser -muv <Shared Storage Partition>
Stop the processes, if required, using the following command:
# fuser -k <Shared Storage Partition>
If the failed node is usable, execute the following command to release the virtual IP address:
# ifconfig <interface_name> down
For example,
# ifconfig eth1:1 down
Steps to Perform on the New Active Node
Login as root.
Execute the following command to assign the virtual IP address to this node (the new active node):
# ifconfig <interface_name> netmask <subnet_mask> up
For example,
# ifconfig 144.88.27.125 netmask 255.255.252.0 up
Verify that the virtual IP is up and working using telnet from a different host (subnet/domain).
Mount the file system using the following command:
# mount <Shared Storage Partition> <mount_point>
For example:
# mount /dev/sdc1 /oracle
If the Oracle Cluster Synchronization Services (CSS) daemon, ocssd, is required, run the following command as the user that installed the Oracle home:
> /etc/init.d/init.cssd start
Start all OracleAS Infrastructure processes on this new active node with the following commands:
Set the ORACLE_HOME environment variable to the OracleAS Infrastructure's Oracle home.
Set the ORACLE_SID environment variable to the OracleAS Metadata Repository's system identifier.
Start the OracleAS Metadata Repository database:
> ORACLE_HOME/bin/sqlplus /nolog SQL> connect SYS as SYSDBA SQL> startup
Start the OracleAS Infrastructure database listener.
> ORACLE_HOME/bin/lsnrctl start
Start OPMN and all OPMN-managed processes using the following command:
> ORACLE_HOME/opmn/bin/opmnctl startall
Start the Application Server Control Console:
> ORACLE_HOME/bin/emctl start iasconsole
You can use the Application Server Control Console to manage OracleAS Cold Failover Cluster topologies. Figure 4-10 shows a sample screen.
To access the Application Server Control Console that is running on hardware cluster nodes, you specify the virtual hostname instead of the physical hostname in the Application Server Control Console URL.
If you are running OracleAS Single Sign-On and Oracle Delegated Administration Services in an active-active mode, you use the physical hostname of either node in the Application Server Control Console URL, for example, http://sso1.mydomain.com:1156 or http://sso2.mydomain.com:1156.
Figure 4-10 Application Server Control Console for OracleAS Cold Failover Cluster (Infrastructure) Topology
To start Oracle Application Server, you start the components in the following order:
Start the OracleAS Metadata Repository database.
Start the Oracle Identity Management components.
If the Oracle Identity Management components are running on different tiers, start them in the following order:
Start Oracle Internet Directory and Oracle Directory Integration Platform.
Start OracleAS Single Sign-On and Oracle Delegated Administration Services.
Start Application Server Control Console.
For the active-passive tiers in OracleAS Cold Failover Cluster topologies, make sure that you have done the following steps:
Follow these steps to start the OracleAS Infrastructure components in an OracleAS Cold Failover Cluster (Infrastructure) topology:
Set the ORACLE_HOME environment variable to the OracleAS Infrastructure's Oracle home.
Set the ORACLE_SID environment variable to the OracleAS Metadata Repository database's system identifier.
Set the PATH environment variable to include the OracleAS Infrastructure's ORACLE_HOME/bin directory.
On Windows, you can use the following command to set the PATH:
set PATH=%ORACLE_HOME%\bin;%PATH%
|
Note: Specify the path of the Oracle home as the first entry in thePATH environment variable if you have several Oracle homes installed on the computer. Also, ensure that the full paths of the executables you use are specified. |
Start the OracleAS Metadata Repository database listener.
> ORACLE_HOME/bin/lsnrctl start
Start the OracleAS Metadata Repository database:
On UNIX systems:
> $ORACLE_HOME/bin/sqlplus /nolog SQL> connect SYS as SYSDBA SQL> startup
On Windows systems:
> %ORACLE_HOME%\bin\sqlplus /nolog SQL> connect SYS as SYSDBA SQL> startup
Start OPMN and all OPMN-managed processes.
> ORACLE_HOME/opmn/bin/opmnctl startall
Start up Application Server Control Console:
> ORACLE_HOME/bin/emctl start iasconsole
Follow these steps to start the OracleAS Infrastructure components in a distributed OracleAS Cold Failover Cluster (Infrastructure) topology:
On the active node in the OracleAS Metadata Repository and Oracle Internet Directory tier:
Start up the OracleAS Metadata Repository listener and database.
Start up Oracle Internet Directory using OPMN.
> ORACLE_HOME/opmn/bin/opmnctl startall
Start up Application Server Control Console.
> ORACLE_HOME/bin/emctl start iasconsole
Start up OracleAS Single Sign-On and Oracle Delegated Administration Services.
The procedure for starting up these components depends on whether you are running them in an active-active configuration or in an active-passive configuration.
If you are running them in an active-active configuration, you can follow the procedure described in Section 3.8.2.2, "For the Distributed OracleAS Cluster (Identity Management) Topology", step 3.
If you are running them in an active-passive configuration, you can start them up using OPMN:
Set the ORACLE_HOME environment variable to the OracleAS Single Sign-On / Oracle Delegated Administration Services home.
Run OPMN to start up the components.
> ORACLE_HOME/opmn/bin/opmnctl startall
Start up Application Server Control Console.
> ORACLE_HOME/bin/emctl start iasconsole
You start the components in the following order:
Start up the OracleAS Metadata Repository listener and database.
Start up the Oracle Identity Management components using OPMN.
> ORACLE_HOME/opmn/bin/opmnctl startall
Start up Application Server Control.
> ORACLE_HOME/bin/emctl start iasconsole
You start the components in the following order:
Start up the OracleAS Metadata Repository listener and database.
On the active node for Oracle Internet Directory:
Start up Oracle Internet Directory using OPMN.
> ORACLE_HOME/opmn/bin/opmnctl startall
Start up Application Server Control Console.
> ORACLE_HOME/bin/emctl start iasconsole
On each node running OracleAS Single Sign-On and Oracle Delegated Administration Services:
Start up OracleAS Single Sign-On, Oracle Delegated Administration Services, and Oracle HTTP Server using OPMN.
> ORACLE_HOME/opmn/bin/opmnctl startall
Start up Application Server Control Console.
> ORACLE_HOME/bin/emctl start iasconsole
To stop Oracle Application Server, you stop the components in the following order:
Stop Application Server Control Console.
Stop the Oracle Identity Management components.
If the Oracle Identity Management components are running on different tiers, stop them in the following order:
Stop OracleAS Single Sign-On and Oracle Delegated Administration Services.
Stop Oracle Internet Directory and Oracle Directory Integration Platform.
Stop the OracleAS Metadata Repository database.
The next two steps are required only if you are stopping on the current node to fail over to the other node. Otherwise it is not a mandatory part of the stop process.
Use the following steps to stop the OracleAS Infrastructure in an OracleAS Cold Failover Cluster (Infrastructure) topology:
Set the ORACLE_HOME environment variable to the OracleAS Infrastructure's Oracle home.
Set the ORACLE_SID environment variable to the SID of the OracleAS Metadata Repository database.
Stop the Application Server Control Console.
> ORACLE_HOME/bin/emctl stop iasconsole
Stop the Oracle Application Server processes using OPMN.
> ORACLE_HOME/opmn/bin/opmnctl stopall
Stop the OracleAS Metadata Repository database:
On UNIX systems:
> ORACLE_HOME/bin/sqlplus /nolog
SQL> connect SYS as SYSDBA
SQL> shutdown
On Windows systems:
> ORACLE_HOME\bin\sqlplus /nolog
SQL> connect SYS as SYSDBA
SQL> shutdown
Stop the OracleAS Metadata Repository database listener.
> ORACLE_HOME/bin/lsnrctl stop
To stop the processes on the different tiers, you stop them in the following order:
Stop the processes on each node in the OracleAS Single Sign-On and Oracle Delegated Administration Services tier.
Set the ORACLE_HOME environment variable to the OracleAS Single Sign-On / Oracle Delegated Administration Services home.
Run OPMN to stop the components.
> ORACLE_HOME/opmn/bin/opmnctl stopall
Stop Application Server Control Console.
> ORACLE_HOME/bin/emctl stop iasconsole
On the active node in the OracleAS Metadata Repository and Oracle Internet Directory tier:
Set the ORACLE_HOME environment variable to the OracleAS Metadata Repository / Oracle Internet Directory home.
Run OPMN to stop Oracle Internet Directory.
> ORACLE_HOME/opmn/bin/opmnctl stopall
Stop Application Server Control Console.
> ORACLE_HOME/bin/emctl stop iasconsole
Stop the OracleAS Metadata Repository database.
On UNIX systems:
> ORACLE_HOME/bin/sqlplus /nolog
SQL> connect SYS as SYSDBA
SQL> shutdown
On Windows systems:
> ORACLE_HOME\bin\sqlplus /nolog
SQL> connect SYS as SYSDBA
SQL> shutdown
Stop the listener for the OracleAS Metadata Repository database.
> ORACLE_HOME/bin/lsnrctl stop
To stop the processes, you stop them in the following order:
Stop the Oracle Identity Management components using OPMN.
Set the ORACLE_HOME environment variable to the Oracle Identity Management home.
Run OPMN to stop the components.
> ORACLE_HOME/opmn/bin/opmnctl stopall
Stop Application Server Control.
> ORACLE_HOME/bin/emctl stop iasconsole
You stop the processes in the following order:
Stop OracleAS Single Sign-On and Oracle Delegated Administration Services:
Set the ORACLE_HOME environment variable to the OracleAS Single Sign-On / Oracle Delegated Administration Services home.
Run OPMN to stop the components.
> ORACLE_HOME/opmn/bin/opmnctl stopall
Stop Application Server Control.
> ORACLE_HOME/bin/emctl stop iasconsole
Stop Oracle Internet Directory:
Set the ORACLE_HOME environment variable to the Oracle Internet Directory home.
Run OPMN to stop Oracle Internet Directory.
> ORACLE_HOME/opmn/bin/opmnctl stopall
Stop Application Server Control Console.
> ORACLE_HOME/bin/emctl stop iasconsole
For components that run on active-passive tiers, you can use the standard administration techniques described in the Oracle Application Server Administrator's Guide. This is because you are running only one Oracle Application Server instance at any time (only the active node runs the Oracle Application Server instance), and you have only one Oracle home to manage.
Remember that to access the Application Server Control Console, you use the virtual hostname in the Application Server Control Console URL. See Section 4.6.1, "Using Application Server Control Console" for details.
The Oracle Application Server Installation Guide for your platform covers the instructions for configuring the virtual IPs for OracleAS Cold Failover Cluster topologies:
If you are running on UNIX platforms, see section 11.2.2, "Map the Virtual Hostname and Virtual IP Address" in the Oracle Application Server Installation Guide for your platform.
If you are running on Microsoft Windows, see section 11.2.2, "Get a Virtual Address for the Cluster" in the Oracle Application Server Installation Guide for Windows.
