11 Using Oracle Cluster Ready Services

This chapter describes conceptual information as well as configuration procedures for Oracle Cluster Ready Services. It contains the following sections:

Section 11.1, "Introduction to Oracle Clusterware"
Section 11.2, "Cluster Ready Services and Oracle Fusion Middleware"
Section 11.3, "Installing and Configuring Oracle Clusterware with CRS"
Section 11.4, "Using ASCRS to Manage Resources"
Section 11.5, "Example Topologies"
Section 11.6, "Troubleshooting Oracle CRS"

11.1 Introduction to Oracle Clusterware

Oracle Clusterware manages the availability of user applications and Oracle databases in a clustered environment. In an Oracle Real Application Clusters (RAC) environment, Oracle Clusterware manages all of the Oracle Database processes automatically. Anything managed by Oracle Clusterware is known as a cluster resource, which could be a database, an instance, a service, a listener, a virtual IP (VIP) address, or an application process.

Oracle Clusterware was initially created to support Oracle RAC. Its benefits, however, are not limited to the support for Oracle RAC; it can also be used to manage other applications through add-on modules or scripts. It is this flexibility and extensibility that Oracle Clusterware forms the basis of a high availability solution for Oracle Fusion Middleware.

For more information about Oracle Clusterware, see the Oracle Clusterware Administration and Deployment Guide. You can find this guide on the Oracle Technology Network.

11.2 Cluster Ready Services and Oracle Fusion Middleware

Oracle Clusterware includes a high availability framework. This framework provides an infrastructure to protect any resource. In Oracle Clusterware terminology, a resource refers to an object that is created by Oracle Clusterware to identify the entity to be managed, such as an application, a virtual IP or a shared disk. Oracle Clusterware ensures that its managed resources start when the system starts. Oracle Clusterware also monitors the resources to make sure that they are always available.

With this high availability framework, Oracle Clusterware manages resources through an action program supplied by the user when this resource is created. For example, a resource is created for an application running in a single process and the action script knows how to start, and stop this process, and check its state. If an application fails, Oracle Clusterware attempts to restart the process using this script. If the node on which the application is currently running fails, Oracle Clusterware attempts to restart it on another node if the application is configured properly. You can configure application monitoring frequency, starting, and stopping, and the application dependencies.

Oracle Fusion Middleware is a critical application environment and benefits from Oracle Clusterware's high availability feature. Oracle Clusterware includes a add-on component, Application Server Cluster Ready Service (ASCRS) that makes it easier to manage middleware resources.

ASCRS is made up of a frontend and a backend. The frontend is a command line interface, ascrsctl, with which you can perform administrative tasks, such as resource creation, deletion, update, start, stop or switchover between cluster nodes. The backend is the action logic needed for the various supported resources. The frontend and backend have their own separate log files.

ASCRS supports virtual IP, shared disk, database listener, database instance and WebLogic Administration Server. You can create Oracle Clusterware resources from these middleware components, allowing Oracle Clusterware and ASCRS to maintain their high availability within the cluster.

Oracle Clusterware and ASCRS provide a means to improve the survivability of the various resources when their hosting environment is corrupted or lost. They do not protect disk corruption or application malfunctioning caused by disk corruption. In addition, since ASCRS does not do sure-fire validation for some user input, such as Oracle SID, inadvertent user input errors may also cause failure for a successful resource management.

ASCRS supports Oracle Clusterware 10.2.0.4 or 11.1.0.7 and higher.

ASCRS has online help that can be invoked using the following command:

ascrsctl help -c command -t resource_type

For example, to see online help for creating a of virtual IP resource use the following command:

ascrsctl help -c create -t vip

To view the contents of ascrsctl online help, see Appendix H, "ascrsctl Online Help."

11.3 Installing and Configuring Oracle Clusterware with CRS

As an extension of CRS, ASCRS must be installed within each CRS home on each node of the cluster and configured separately before it can be used.

With the ASCRS command line tool ascrsctl, you can give ASCRS control of various middleware components. Once a component is controlled by CRS, its runtime state is closely monitored and CRS takes the proper actions if the component fails. With ascrsctl, you can create a CRS resource on which you can perform start, stop, update, switchover, monitor status, and delete operations.

11.3.1 Installing ASCRS

Install ASCRS on each node of the cluster. To successfully install ASCRS on a particular node, check the following:

Operating system: ASCRS is supported only on Unix platforms. The system version and patch level should be compatible to the CRS version supported on that platform.
CRS and version: CRS is installed on this system, started, and functioning correctly. The CRS version must be 10.2.0.4 or higher. For information about installing Oracle Clusterware and CRS, see the Oracle Clusterware Installation Guide for Linux.
User account: The ASCRS installation user should be the same as the owner of the CRS home.

Note:

To install ASCRS for CRS 10.2.0.4, Sun JDK (or JRE) 1.5 or higher must be installed on the local system. It is needed by ascrsctl, the command line tool.

To install ASCRS:

Login as the CRS owner.
Insert the Oracle Fusion Middleware Companion CD and run the following commands to unzip and install the ascrs.zip file:
```
cd CRS_HOME
unzip Disk1/ascrs/ascrs.zip
cd ascrs/bin
setup
```

If the CRS version is 10.2.0.4, and JDK(JRE) 1.5+ or higher is installed, run the following command:

setup -j JDK/JRE_HOME

When the installation is complete, the following ASCRS directory structure appears:

CRS_HOME/ascrs/bin
CRS_HOME/ascrs/config
CRS_HOME/ascrs/lib
CRS_HOME/ascrs/log
CRS_HOME/ascrs/public
CRS_HOME/ascrs/perl
CRS_HOME/ascrs/sql
CRS_HOME/ascrs/wlst

11.3.2 Configuring ASCRS with Oracle Fusion Middleware

After installing ASCRS, it is ready for use with the default configuration. To customize logging locations, logging levels or the default CRS properties, edit the configuration files config.xml and ascrs.properties files located in the CRS_HOME/ascrs/config directory.

The config.xml file contains the configuration for ascrsctl ASCRS agent logging. To change either of their locations, specify an existing path name or a path name within this CRS home using the ORACLE_HOME prefix. The available logging levels in the decreasing order of verbosity are ALL, FINEST, FINER, FINE, INFO, WARNING and SEVERE.

The following represents the default config.xml file included with ASCRS:

<?xml version="1.0" ?>
<config>
  <ascrsctl>
    <display level="normal"/>
          <log path="${ORACLE_HOME}/ascrs/log/ascrsctl.log"
               level="FINER"/>
  </ascrsctl>
  <agent>
    <log path="${ORACLE_HOME}/ascrs/log" level="FINER"/>
  </agent>
</config>

The ascrs.properties file contains the attributes used in resource creation.

The following represents the default ascrs.properties file:

normal.vip.AUTO_START=1
normal.vip.CHECK_INTERVAL=7
normal.vip.FAILOVER_DELAY=5
normal.vip.FAILOVER_INTERVAL=50
normal.vip.FAILOVER_THRESHOLD=5
normal.vip.RESTART_ATTEMPTS=2
normal.vip.SCRIPT_TIMEOUT=30
normal.vip.START_TIMEOUT=30
normal.vip.STOP_TIMEOUT=30

# vip resource policies
fast.vip.AUTO_START=1
fast.vip.CHECK_INTERVAL=5
fast.vip.FAILOVER_DELAY=4
fast.vip.FAILOVER_INTERVAL=30
fast.vip.FAILOVER_THRESHOLD=5
fast.vip.RESTART_ATTEMPTS=2
fast.vip.SCRIPT_TIMEOUT=30
fast.vip.START_TIMEOUT=30
fast.vip.STOP_TIMEOUT=30
# disk resource policies

normal.disk.AUTO_START=1
normal.disk.CHECK_INTERVAL=7
normal.disk.FAILOVER_DELAY=5
normal.disk.FAILOVER_INTERVAL=50
normal.disk.FAILOVER_THRESHOLD=5
normal.disk.RESTART_ATTEMPTS=2
normal.disk.SCRIPT_TIMEOUT=30
normal.disk.START_TIMEOUT=30
normal.disk.STOP_TIMEOUT=30

fast.disk.AUTO_START=1
fast.disk.CHECK_INTERVAL=5
fast.disk.FAILOVER_DELAY=4
fast.disk.FAILOVER_INTERVAL=30
fast.disk.FAILOVER_THRESHOLD=5
fast.disk.RESTART_ATTEMPTS=2
fast.disk.SCRIPT_TIMEOUT=30
fast.disk.START_TIMEOUT=30
fast.disk.STOP_TIMEOUT=30

# Oracle database listener resource policies
normal.dblsnr.AUTO_START=1
normal.dblsnr.CHECK_INTERVAL=50
normal.dblsnr.FAILOVER_DELAY=20
normal.dblsnr.FAILOVER_INTERVAL=300
normal.dblsnr.FAILOVER_THRESHOLD=5
normal.dblsnr.RESTART_ATTEMPTS=4
normal.dblsnr.SCRIPT_TIMEOUT=60
normal.dblsnr.START_TIMEOUT=60
normal.dblsnr.STOP_TIMEOUT=60

fast.dblsnr.AUTO_START=1
fast.dblsnr.CHECK_INTERVAL=40
fast.dblsnr.FAILOVER_DELAY=20
fast.dblsnr.FAILOVER_INTERVAL=250
fast.dblsnr.FAILOVER_THRESHOLD=5
fast.dblsnr.RESTART_ATTEMPTS=4
fast.dblsnr.SCRIPT_TIMEOUT=60
fast.dblsnr.START_TIMEOUT=60
fast.dblsnr.STOP_TIMEOUT=60

# Oracle database resource policies
normal.db.AUTO_START=1
normal.db.CHECK_INTERVAL=120
normal.db.FAILOVER_DELAY=30
normal.db.FAILOVER_INTERVAL=700
normal.db.FAILOVER_THRESHOLD=5
normal.db.RESTART_ATTEMPTS=4
normal.db.SCRIPT_TIMEOUT=300
normal.db.START_TIMEOUT=300
normal.db.STOP_TIMEOUT=300

fast.db.AUTO_START=1
fast.db.CHECK_INTERVAL=60
fast.db.FAILOVER_DELAY=20
fast.db.FAILOVER_INTERVAL=400
fast.db.FAILOVER_THRESHOLD=5
fast.db.RESTART_ATTEMPTS=4
fast.db.SCRIPT_TIMEOUT=300
fast.db.START_TIMEOUT=300
fast.db.STOP_TIMEOUT=300

# Oracle WebLogic server resource policies
normal.as.AUTO_START=1
normal.as.CHECK_INTERVAL=50
normal.as.FAILOVER_DELAY=20
normal.as.FAILOVER_INTERVAL=350
normal.as.FAILOVER_THRESHOLD=5
normal.as.RESTART_ATTEMPTS=4
normal.as.SCRIPT_TIMEOUT=600
normal.as.START_TIMEOUT=600
normal.as.STOP_TIMEOUT=600

fast.as.AUTO_START=1
fast.as.CHECK_INTERVAL=40
fast.as.FAILOVER_DELAY=10
fast.as.FAILOVER_INTERVAL=300
fast.as.FAILOVER_THRESHOLD=5
fast.as.RESTART_ATTEMPTS=4
fast.as.SCRIPT_TIMEOUT=600
fast.as.START_TIMEOUT=600
fast.as.STOP_TIMEOUT=600

Consult Oracle Clusterware documentation for the definitions of these properties before editing their values.

Since computing environments vary in speed, Oracle recommends measuring the application's start and stop latency before setting the script, start, and stop timeout values. These values may be twice as much as the observed latencies.

11.4 Using ASCRS to Manage Resources

With the ascrsctl command line you manage CRS resources created for Fusion Middleware components. With this tool you can create, update, start, stop, switch and delete resources.

11.4.1 Creating CRS Managed Resources

ASCRS supports WebLogic Administration Server, Oracle database, Oracle database listener, virtual IP and shared disk. After a CRS managed resource is created for one of these components, it can be controlled by CRS.

CRS resources created with the ascrsctl command line follow a naming convention. Follow this naming convention to ensure that the components function correctly. Oracle also recommends using the CRS installation exclusively Oracle Fusion Middleware, so that all the manageable CRS resources are created with ascrsctl to avoid errors caused by naming inconsistencies.

Under this naming convention, the resource name follows the following format:

ora.name.cfctype

The name refers to the short name of the resource, for example, sharedisk, or myvip. The type refers to one of the resource types, such as vip, disk, db, dblsnr or as.

For example, to create a virtual IP resource from the virtual IP 192.168.1.10 on network interface eth0 with netmask 255.255.255.0, use the following command:

ascrsctl create -name myvip -type vip -ipAddr 192.168.1.10 -netmask 255.255.255.0 -interface eth0

11.4.1.1 Creating a Virtual IP Resource

Oracle Cluster Ready Services includes a high availability framework that provides an infrastructure to protect any resource. In Oracle Clusterware terminology, a resource refers to an object that is created by Oracle Clusterware to identify the entity to be managed such as an application, a virtual IP or a shared disk. If the auto start for each resource is set to 1, Oracle Clusterware ensures that resources that it manages start when CRS starts. Oracle Clusterware also monitors the resources to make sure that they are always available.

Virtual IP resource is a system resource. The create or update command generates a script to be executed as root user to complete the operation.

See Section 11.4.1, "Creating CRS Managed Resources" for detailed syntax and complete command line options for virtual IP resources.

11.4.1.2 Creating a Shared Disk Resource

In a Fusion Middleware environment, shared disks are those disk storages that are used to hold Oracle database software, the database data files, and WebLogic servers. Shared disks allow the use of the same data when the database or WebLogic instance is switched among the nodes within a cluster.

To create a shared disk resource, run the following ascrsctl command that includes a valid mount point, a mount command, and an unmount command:

ascrsctl create -n sharedisk -type disk -path /asdisk -mc "/bin/mount
 /dev/sda /asdisk" -umc "/bin/umount /asdisk"

When creating a shared disk resource, carefully consider the following:

Before creating a shared disk resource, create an empty signature file named .ascrssf on the root of the shared disk. This file is used by CRS after the resource is created.
You can specify a special no operation, or nop command for either the mount or unmount commands. You can use it for the mount command if the shared disk is never offline. If the disk does go off line for some reason, CRS will detects it and mark it as down. The nop command can be used for the unmount command the disk does not need to be unmounted by CRS. In such a case, be absolutely sure that the disk does not need to be unmounted. There are potential disk corruption issues if the shared disk is mounted on two nodes without protection. Again, the signature file is always needed on the shared disk.
The unmount command, may fail if there are active processes using the shared disk. To prevent this command failure, avoid accessing this disk from other applications while this disk resource is in online state.
For complex mount and unmount commands, encapsulate the logic in executable scripts and specify the full path of these scripts as the mount and unmount commands. A proper unmount script is capable of killing other processes that are using this disk to ensure a successful and clean disk unmount. If the unmount command is in a script, do some basic file system checking, such as running a fsck command.
A shared disk resource is a system resource. Create, update, or delete commands generate scripts that must be executed as root to complete the create operation. Follow the instructions from the screen output.
If the signature file is at the mount point of the shared disk, the start/stop operation may fail. Having the signature file on the mount point signals ASCRS that the disk is mounted, even if its not.
Validate the mount/unmount command before using it in the mc or umc parameters or in the script file. There is no validation from ASCRS for the commands.

11.4.1.3 Creating an Oracle Database Listener Resource

To create an Oracle database listener resource, the following is required:

A valid Oracle database home
The listener name
The virtual IP resource name for the listen address
The disk resource name for the Oracle home

To create an Oracle database listener resource, use the following ascrsctl command:

ascrsctl create -n mydblsnr -type dblsnr -loh /cfcdb -ln LISTENER -disk ohdisk -vip myvip

Before creating the database listener resource, carefully consider the following:

The database listener home is installed on a shared disk. A CRS resource has been created for the shared disk with an ascrsctl command, and the resource is started.
A CRS resource has been created for the virtual IP with an ascrsctl command, and the resource is started.
The listener Cold Failover Cluster (CFC) enabled. See Section 10.2.4, "Transforming an Oracle Database" for details.
Ensure that the listener name and Oracle home are valid database sid and database home. ASCRS does not do exhaustive validation on this type of information.

11.4.1.4 Creating an Oracle Database Resource

Creating an Oracle database resource requires the following:

A valid Oracle database home
The database sid name
Disk resource names for the Oracle home
Data files
The listener resource name

To create an Oracle database resource, run the following ascrsctl command:

ascrsctl create -name string -type db -oraHome string -oraSID string -disk string [string...]

-lsnr string [-pfile string] [options]

For online help information for creating an Oracle database resource, use the following command:

ascrsctl help -c create -t db

Before creating the Oracle database resource, carefully consider the following:

The database is installed on a shared disk. The data files of this database are on the same or different shared disk(s). CRS resources have been created for all these shared disks with ascrsctl and started.
A CRS resource has been created for the database listener with an ascrsctl command, and the resource is started.
The database needs to be CFC enabled. See Section 10.2.4, "Transforming an Oracle Database" for details.
Ensure the database sid and Oracle home are valid. ASCRS does not do extensive validation of this information.

11.4.2 Updating Resources

You can update resources created with ascrsctl using the update command. Depending on the resource type, you can update the resource profile by specifying the appropriate parameter through the update command line. Some updates can only be performed when the resource is taken offline.

For example, to update the virtual IP resource created in the last section with a new IP address and a different interface, use the following command:

ascrsctl update -n myvip -type vip -ip 192.168.1.20 -if eth1

11.4.3 Starting Up Resources

When a resource is started, it is put under the control of CRS and its runtime status is monitored continuously by CRS. If the resource depends on other resources, starting this resource automatically starts the dependent resources. Refer to Oracle Clusterware documentation for information about the role of resource placement policy during resource start up. The ascrsctl start command maps to the CRS command crs_start.

For example, to start the virtual IP resource, use the following command:

ascrsctl start -n ora.myvip.cfcvip

Note:

If a resource depends on more than one resource, while starting that resource, be sure that the resources, if online, are targeted on the same node.

For example, if AS resource depends on VIP and Disk resource. While starting AS resource, make sure that if VIP and Disk resources are online, they are targeted to the same node.

11.4.4 Shutting Down Resources

When a resource is stopped, it is brought down and put in offline state and CRS stops monitoring its runtime status. If the resource is depended on other resources that are in online status, the dependent resources are not stopped unless the -f option is specified. This option forces the resource and all of its dependents to stop. Refer to Oracle Clusterware documentation for more information about the implications of resource dependency during resource stop. The ascrsctl stop command maps to CRS command crs_stop.

For example, to stop the virtual IP resource, run the following command:

ascrsctl stop -n ora.myvip.cfcvip

11.4.5 Resource Switchover

Resource switchover is a process of shutting down the resource on the node on which it is running and restarting it on another node. The new node, if not specified, is determined by CRS, based on the placement policy. If the resource to be switched depends on other resources, or there are resources that are online and depend on it, this resource must be switched with -f flag.

To switch over a resource to another available node in the cluster, run the following command:

ascrsctl switch -n ora.myvip.cfcvip

11.4.6 Deleting Resources

You can remove a resource from CRS control. Once this association is removed, the corresponding application or component's functionality are not affected. CRS no longer monitors that resource's state. If a resource has dependent resources, it can not be removed.

To delete a resource from CRS control, run the following command:

ascrsctl delete -n ora.myvip.cfcvip

11.4.7 Checking Resource Status

You can check resource status with the ascrsctl status command. With this command, you can view the states of all resources and their dependents. If a particular resource is specified, the status command show its CRS profile, its direct and indirect dependency relationships, and its current state information.

For example, to check the status of a resource, run the following command:

ascrsctl status -n ora.myvip.cfcvip

Assuming the virtual IP resource is used by a database listener resource and the listener resource is in turn required by a database resource, all the dependency information is shown in a tree structure, along with other status information in the following status output:

Basic information
------------------------+------------------------
          Name                  |  ora.myvip.cfcvip
          Target state          |  OFFLINE
          Resource state        |  OFFLINE
          Hosting members       |  stajz11, stajz12
------------------------+------------------------
  Common CRS parameters
------------------------+------------------------
          Auto start            | No
          Check interval        | 60 sec
          Failover delay        | 10 sec
          Script timeout        | 50 sec
          Start timeout         | 100 sec
          Stop timeout          | 100 sec
------------------------+------------------------
  Resource specific parameters
------------------------+------------------------
          Interface(s)          | eth2
          Netmask               | 255.255.252.0
          Virtual IP address    | 140.87.27.48
        ------------------------+------------------------
          Resource dependency tree(s)
 -------------------------------------------------
ora.mydb.cfcdb
|
+->ora.mydblsnr.cfcdblsnr
| |
| +->ora.mydisk.cfcvip
| |
| +->ora.myvip.cfcvip
|
+->ora.mydisk.cfcdisk

11.4.8 Configuring Oracle WebLogic Administration Server

Creating a WebLogic Administration Server CRS resource requires more preparation than other resource types. Due to its complexity, the procedure for creating a WebLogic Administration Server CRS resource is divided into the following sections:

Basic Setup
Node Manager Setup
Administration Server Setup
Creating a Resource

Basic Setup

Before starting the basic setup, be sure that WebLogic Server is installed on shared disk(s). WebLogic Server software and the administration server domain instance can be installed on the same or separate shared disk.

In addition, ensure that the WebLogic Server is CFC enabled. See Section 10.2.2.1, "Administration Server Topology 1" for details on enabling WebLogic Server for CFC. Once CFC is enabled, you can manually start and stop the Administration Server, the original node, and the failover node(s) without noticeable difference.

The steps for the basic setup section of the procedure for creating a WebLogic Server CSR resource:

Create a CRS resource for each shared disk and start it on the node on which it was created.
Create a CRS resource for the virtual IP with the ascrsctl command and start it on the same cluster node.

Node Manager Setup

To set up the Node Manager

If you have not yet done so, change Node Manager's username and password. The initial password is randomly generated. To change the Node Manager password, in the WebLogic Server Administration Console, select Domain, Security, General, and then Advanced. Enter the new password and click Save.
If you have changed anything in steps 1 or 2, restart the Node Manager using the following command from the WLS_HOME/server/bin directory:
```
startNodemanager.sh
```

Start the WebLogic scripting tool in the WLS_HOME/common/bin/wlst.sh directory. To persist Node Manager's user login information in the ascrscf.dat and ascrskf.dat files, use the following commands:

nmConnect('nmUser','nmPasswd','hostname','nmPort','domainName','domainDir')
storeUserConfig(WLS_HOME/common/nodemanager/ascrscf.dat,
                   WLS_HOME/common/nodemanager/ascrskf.dat,'true')
nmDisconnect()
exit()

Copy CRS_HOME/ascrs/public/cfcStartNodeManager.sh to the WLS_HOME/server/bin directory, and make the script executable.

Note:

To keep the setup consistently in sync, step 3 must be performed whenever the Node Manager passwords or usernames are changed.

After you have started Node Manager for the first time, you can edit the nodemanager.properties file to set the StartScriptEnabled property. The nodemanager.properties file does not exist until Node Manager is started for the first time.

In the WLS_HOME/common/nodemanager directory, set the StartScriptEnabled property in the nodemanager.properties file to true.

StartScriptEnabled=true

Check the nodemanager.properties file to ensure no value is assigned to ListenAddress, and that a valid port number is assigned to ListenPort.

When this property is set in the nodemanager.properties file, you no longer need to define it in the JAVA_OPTIONS environment variable.

Administration Server Setup

The administration server listens on the virtual IP. To ensure this is configured correctly, log in to the WebLogic Server Administration Console and navigate to the administration server listen address page and verify that the virtual IP and the port number are both set correctly and click Save.
The administration server must also listen on the localhost. To ensure this is configured correctly, login WebLogic Server Administration Console and do the following:
1. In the Domain tree, select Environment, Servers, AdminServer, Protocols, and then Channels.
2. Click the Lock and Edit button.
3. Click New, select a channel name, and protocol t3, and continue to the next screen.
4. Enter the localhost for both the Listen Address and External ListenAddress.
5. Enter the port number to the Listen Port and External ListenPort. This port number must be exactly the same as the port number used for the virtual IP.
6. Continue to the next screen and verify that Enabled is selected.
7. Click Finish.
8. Click Activate Changes.
Ensure the DOMAIN_HOME/servers/AdminServer/security directory exists. This directory should contain the boot.properties file. If this file does not exist, create it and include the following properties:
```
username=<admin server user name>
password=<admin server user password>
```
If DOMAIN_HOME/servers/AdminServer/data/nodemanager/startup.properties exists, ensure the property AutoRestart defined in this file is set to false.
Restart the administration server.
Shutdown all WebLogic processes and kill the Node Manager.

Note:

To keep the setup consistently in sync, Step 3 must be performed whenever the administration server password is changed.

Create the Resource

After Basic Setup, Node Manager Setup, and Administration Server Setup, create the CRS resource using the following command:

ascrsctl create -n adminserver -type as -ch /cfcas -disk sharedisk -vip myvip

Note:

The WebLogic component home argument (-ch) must be valid. ASCRS does not perform extensive validation for this information.

Note:

For Oracle Portal, Forms, Reports, and Discoverer, the administration server cannot be separated from the Managed Server. ASCRS supports management of only the administration server in this release. As a result, the Managed Server running in the same MWOH and Domain Directory as the administration server must be down for ASCRS managed deployments.

11.5 Example Topologies

The following two examples illustrate how to use ASCRS to manage Fusion Middleware resources.

Figure 11-1 CRS Topology Example 1

Description of "Figure 11-1 CRS Topology Example 1"

Figure 11-1 illustrates the CRS Example 1 topology. In the example topology, Oracle WebLogic Server is installed on a two-node cluster. Of all the WebLogic servers in the same domain, WebLogic Administration Server is the only one running on this cluster. The goal is to provide a failover solution for the WebLogic Administration Server that runs in a Java EE container, as well as Oracle Enterprise Manager. Both the WebLogic software and the Domain home reside on the same shared disk.

Assumptions:

Operating Environment: This is a Linux, two-node cluster with node1.company.com and node2.company.com as its members. Node 1 is designated as the primary node and node2 is the failover node. CRS has been installed on both nodes in the /crshome directory and is started. ASCRS has been installed on both nodes and has been configured.
One shared disk has been allocated for the WebLogic software and the Domain home of the administration server. It is a SCSI drive identified with /dev/sda1 and has ext2 file system on it. It is mounted on /sharedisk1.
The WebLogic Server uses virtual IP 192.168.1.10 for its public listen address and 7001 for its listen port. One each node, two network interface controllers, eth0 and eth1 are available for binding the virtual IP. The netmask is 255.255.255.0.
WebLogic Server is installed on the shared disk on the /sharedisk1/fmw directory and the domain directory is /sharedisk1/fmw/user_projects/domains/asdomain.

After creating resources for the shared disk as described in Section 11.4.1.2, "Creating a Shared Disk Resource,"and configuring a resource for the WebLogic Administration Server as described in Section 11.4.8, "Configuring Oracle WebLogic Administration Server,", perform the following steps to create all the resources:

Shutdown WebLogic server and its node manager completely.
Unmount the shared disk with command /bin/unmount.
Unbind the virtual IP with command /sbin/ifconfig.
CD to the /CRS_HOME/ascrs/bin directory.

Create the virtual IP resource using the following command:

ascrsctl create -n asvip -t vip -if "eth0|eth1" -ip 192.168.1.10 -nm 255.255.255.0

Create the shared disk resource using the following command:

ascrsctl create -n asdisk -t disk -path /sharedisk1
-mc "/bin/mount /dev/sda1 /sharedisk1"
-umc "/bin/umount /sharedisk1"

Create the administration server resource using the following command:

ascrsctl create -n wlas -t as -vip asvip -disk asdisk
-ch /sharedisk1/fmw/user_projects/domains/asdomain

Start all the database related resources using the following command:
```
ascrsctl start -n ora.wlas.cfcas
```

Figure 11-2 CRS Topology Example 2

Description of "Figure 11-2 CRS Topology Example 2"

Figure 11-2 illustrates the CRS Example 2 topology. In this example topology, WebLogic Server and the Oracle database are installed on a two-node cluster with the following characteristics:

The WebLogic Administration Server is the only server running on this cluster. The WebLogic software and the Domain home reside on the same shared disk.
The administration server, along with Oracle Enterprise Manager, run in a WebLogic Java EE container with the first node as its primary node.
The database software and its data files reside on two other shared disks with the second node as its primary node.

The goal of this topology is to provide a failover solution for both the WebLogic Administration Server and the database instance.

Assumptions:

Operating Environment: This is a Linux two-node cluster with node1.company.com and node2.company.com as its members. Node 1 is designated as the primary node for WebLogic Server and Node 2 as its failover node. Node 2 is designated as the primary node for the Oracle database, and node 1 as its failover node. CRS is installed on both nodes in the /crshome directory and is started. ASCRS is installed on both nodes and is configured.
Three shared disks are allocated. They are all SCSI drives identified with /dev/sda1, /dev/sda2, /dev/sda3 and have ext2 file system on it. They are used for WebLogic software and the Domain home, the Oracle database software and the data files. They are mounted on /sharedisk2, /sharedisk2 and /sharedisk2 respectively.
The WebLogic server uses virtual IP 192.168.1.10 for its public listen address, and 7001 for its listen port. On each node, two network interface controllers, eth0 and eth1 are available for binding this virtual IP.

The database listener uses virtual IP 192.168.1.20 for its listen address, and 1521 for its listen port. On each node, network interface controller eth2 is available for binding this virtual IP.

The netmask is 255.255.255.0 for both virtual IPs.
WebLogic Server is installed on the shared disk in the /sharedisk1/fmw directory, and the domain directory is /sharedisk1/fmw/user_projects/domains/asdomain.
The Database is installed on the shared disk in the /sharedisk2/dbhome directory, and the data files are located in the /sharedisk3/dbdata directory. Assume orcl is the Oracle SID name and LISTENER is the listener name.

The WebLogic resource is created just as the Example 1 topology. The database resource is created with the following steps:

Shutdown the database and its listener.
Unmount the shared disks /sharedisk2 and /sharedisk3 with the /bin/unmount command.
Unbind the virtual IP with the /sbin/ifconfig command.

Create the virtual IP resource for the listener using the following command:

./ascrsctl create -n dbvip -t vip -if eth2
-ip 192.168.1.20 -nm 255.255.255.0

Create the shared disk resource for the Oracle home using the following command:

./ascrsctl create -n dbdisk -t disk -path /sharedisk2
-mc "/bin/mount /dev/sda2 /sharedisk2"
-umc "/bin/umount /sharedisk2"

Create the shared disk resource for the data files using the following command:

./ascrsctl create -n dfdisk -t disk -path /sharedisk3
-mc "/bin/mount /dev/sda3 /sharedisk3"
-umc "/bin/umount /sharedisk3"

Create the database listener resource using the following command:

./ascrsctl create -n asdblsnr -t lsnr -vip dbvip 
          -disk dbdisk -loh /sharedisk2/dbhome -ln LISTENER

Create the database resource using the following command:

./ascrsctl create -n asdb -t db -lsnr asdblsnr -sid orcl
         -oh /sharedisk2/dbhome -disk dbdisk dfdisk

Start all the database related resources on node2 using the following command
```
./ascrsctl start -n ora.asdb.cfcdb 
```

11.6 Troubleshooting Oracle CRS

ASCRS relies on logging for diagnosing unexpected issues. To get more diagnostic information, you can increasing the verbosity of the log level by changing the ASCRS configuration file config.xml.

In addition, you can also check CRS daemon logs for basic CRS issues.