Post on 12-Sep-2021
Siebel CRM 8.0/8.1 Applications protected by Oracle Clusterware 11gR2 An Oracle Technical White Paper
June 2012
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 2
Introduction ....................................................................................................... 3
Overview of A Simple Siebel Architecture .................................................... 4
What is Oracle Clusterware? ............................................................................ 6
High Availability for the Siebel Gateway– Introduction ............................. 6
Software Installation and Configuration ........................................................ 7
Step 1a: Create an Application VIP for the Siebel Gateway ................ 10
Step 1b: Create an Siebel Server Application VIP per node ................ 12
Configuration of the Siebel Gateway and Siebel Servers ................. 12
Step 2a: Create and Test the Action Script for the Siebel Gateway .... 13
Step 2b: Create and Test the Action Script for each Siebel Server ..... 15
Step 3a: Create a Siebel Resource Type With Oracle Clusterware ...... 16
Step 3b: Add the Siebel Gateway Application to Oracle Clusterware 16
Step 4: Add the Siebel Server to Oracle Clusterware ............................ 17
Step 5: Test the Siebel High Availability Environment ......................... 18
Summary ........................................................................................................... 20
Appendix A – Siebel Gateway Resource create script ............................... 22
Appendix B – Siebel Gateway Scripts .......................................................... 25
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 3
INTRODUCTION
High availability for Siebel means that a user can access key system services even
when the underlying hardware or software for those services fails.
For example, if a Siebel remote user synchronization session was interrupted by a
failure of the Siebel Server to which it was connected; users can reconnect to a
failover system and restart the synchronization process without any data loss.
This paper documents the setup and configuration on both Siebel and Oracle
Clusterware 11gR2 to achieve High Availability (HA) for the Siebel CRM
Applications.
The scripts used in this document, noted in the appendix, are meant to be sample
scripts. These scripts register Siebel application resources under Oracle Clusterware
control and implement control actions for the Oracle Clusterware script agent HA.
Before using these scripts, customization may be required in order to meet the
needs of your environment. The Oracle Clusterware and Siebel APIs invoked
within these scripts are fully supported by Oracle. The scripts and subsequent
modifications are not supported by Oracle. Care must be taken to build and test
these scripts.
Prior to Oracle Clusterware 11gR2, application resources were configured using the
crs_* utilities such as crs_register, crs_start, crs_stop, crs_profile, etc. Oracle
Clusterware 11gR2 has deprecated this crs_* interface in favor of the singular crsctl
interface1. As a consequence, the way the application resources are configured and
controlled is by means of the common crsctl interface. In addition, Oracle
Clusterware 11gR2 introduces a simplified application VIP interface, appvipcfg.
This interface simplifies the creation and management of the application VIP. This
paper will only describe these interfaces2.
The scripts included in this document have been tested on Oracle Enterprise Linux
5 (OEL5) using Oracle Clusterware 11gR2. The scripts are expected to work on all
Linux and Unix platforms which supports Oracle Clusterware 11g Release 2 or
later.
These scripts are composed of start, stop, check, clean, and abort entry points using
Siebel application primitives and the Oracle Clusterware 11gR2 script agent
1 For a complete list of deprecated crs_* commands, refer to the Oracle Clusterware Administration and Deployment Guide 11gRelease 2(11.2) Part Number E16794-16, Appendix E 2 For Oracle Clusterware pre-11gR2, please see the document ‘Siebel CRM Applications protected by Oracle Clusterware 11gR1’.
Providing High Availability for Siebel
Applications ensures minimal user
interruptions in case of an application
or node failure.
This paper explains how to use Oracle
Clusterware to protect Siebel Applications.
The resources to be protected are the
Siebel Gateway and Siebel Server
Services.
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 4
framework3. These action primitives are invoked in a parent script commonly
referred to as the agent action script. It is the action script that is presented to
Oracle Clusterware to control the HA of the application components using the
Oracle Clusterware 11gR2 script agent. Other scripts noted in the appendix will
create the necessary resources required for Siebel HA including any inter-resource
dependencies. Siebel HA using Oracle Clusterware 11gR2 as defined by the
attached scripts may include the Siebel Gateway Name Server or both the Siebel
Gateway Name Server and Siebel Servers. To implement the Siebel HA required
you simply run the scripts relevant to the Siebel component.
OVERVIEW OF A SIMPLE SIEBEL ARCHITECTURE
Siebel CRM Applications are composed of the following main server elements:
Siebel Gateway, Siebel Server and Siebel Web Server Extension (SWSE).
Both the Siebel Gateway Server and the Siebel Server run as services in the system.
SWSE is a plug-in to the web server. For web servers High Availability, set up a
load balancing configuration using one of the Oracle certified HTTP load balancers
which also allow user requests to fail over between web servers. This paper will not
discuss Oracle Clusterware high availability for the SWSE plug-in but will focus on
high availability for the Siebel Gateway Server and the Siebel Server.
The figure1 below illustrates a high level description Siebel work flow describing
Siebel Gateway and Siebel Server communication.
3 For a complete description of application HA using Oracle Clusterware, please see chapter 6, Making Applications Highly Available Using Oracle Clusterware in Oracle® Clusterware Administration and Deployment Guide 11g Release 2 (11.2) Part Number E16794-17
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 5
Figure 1: Example of Simple Siebel Deployment
The Siebel Gateway Name Server coordinates the Siebel Enterprise Server and
Siebel Servers. It also is a persistent backing store for the Siebel Enterprise Server
configuration information, including definitions and assignments of component
groups and components, operational parameters and connectivity information.
The Siebel Server is the middle-tier platform that supports both back-end and
interactive processes for every Siebel client. It supports both multi-process and
multithreaded components, and can operate components in background, batch, and
interactive modes.
Note that there can be only one instance of the Siebel Gateway per Enterprise but
there can be multiple Siebel Servers configured for one Siebel Enterprise server.
For each Siebel Server, different components such as Call Center Object Manager,
EIM or Siebel Remote, can be configured to run on each node. Oracle Clusterware
11gR2 can provide HA for each of these components following the guidelines
documented in this paper. However, this paper describes the basic steps to
configure HA focusing on a single Siebel Gateway Server and a single Siebel Server.
You would use these same steps, configuring for network and Siebel Server
resource uniqueness using the same steps below. If configuring HA for each Siebel
Server, best practice suggests that you map a unique VIP to each Siebel Server
resource as defined in the Oracle Clusterware and noted below.
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 6
WHAT IS ORACLE CLUSTERWARE?
Oracle Clusterware is portable cluster software that allows clustering of single
servers so that they cooperate as a single system. Oracle Clusterware also provides
the required infrastructure for Oracle Real Application Clusters (RAC), a multi-
instance active/active clustered RDBMS. In addition, Oracle Clusterware enables
the protection of any application within the cluster. Oracle Clusterware is
supported on all major operating systems4.
Figure 2: Oracle Clusterware Topology Overview
HIGH AVAILABILITY FOR THE SIEBEL GATEWAY– INTRODUCTION
This paper describes Oracle Clusterware 11gR2 to enable high availability for the
Siebel Gateway Name Server and the Siebel Server Services. Note that since there
can be only one Siebel Gateway running per Enterprise Server, the Gateway can
only be configured to run in Active/Passive mode. Siebel Servers can be configured
to run in Active/Active mode to fully utilize all available resources in the
environment.
Oracle Clusterware must be installed and configured to manage the application and
application dependent resources. The start, stop and check and clean of the
application and dependent resources will be managed by the Oracle Clusterware
software solution. If there is an application failure, Oracle Clusterware will attempt
to restart the application. The number of attempted restarts of the resource is user
configurable. Once the number of configured restart attempts for a particular
resource is reached, Oracle Clusterware will perform failover of this process and
4 For more information on Oracle Clusterware, see: http://otn.oracle.com/clusterware
The Siebel Gateway Server serves as the
dynamic address registry for Siebel
Servers and components.
At startup, every Siebel Server within the
Siebel Enterprise stores its network
address in the non-persistent address
registry of the Siebel Gateway.
Hence, it is important for the Gateway
Server to be highly available.
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 7
dependent resources, such as the Application Virtual IP (VIP)5, to another
available node in the cluster.
In case of a node failure, Oracle Clusterware will failover a Virtual IP (VIP) to
another node in the cluster. Once the relocation of the VIP to another node has
been established, Oracle Clusterware will restart the Siebel resource on the new
node. Siebel CRM users are now able to re-connect back to the application with
minimal interruptions.
When server or software maintenance is required, leverage Oracle Clusterware
11gR2 online resource relocation functionality to move the application resource,
such as the Siebel Gateway Name Server, to another available node in the cluster
with no interruption of service.
SOFTWARE INSTALLATION AND CONFIGURATION
This paper assumes that Oracle Clusterware 11gR2 has been installed and the
Oracle Clusterware users and user groups specific to the operating system have
been created on all nodes in the cluster in advance, as per the Oracle Clusterware
installation and configuration guide.
It is required that all nodes have access to the Siebel software. This can either be
achieved by using a shared installation based on ASM Cloud File System (ACFS)
shipped with the Oracle Clusterware, or a shared NFS mount, or by using a local
node installation of the software (default for Oracle Clusterware) where the binary
tree and absolute path is identical on all nodes.
For more information on the installation and setup, please consult the Oracle
Clusterware Administration and Deployment Guide6 and the Siebel Installation
Guide which is available for download on edelivery.oracle.com or the Siebel
Support Web7.
5 Application Virtual IPs allow autonomous client connect to the application and an expedient notification if the network stack fails. 6 For the Oracle Clusterware Administration and Deployment Guide refer to: http://docs.oracle.com/cd/E11882_01/rac.112/e16794/title.htm 7 The Siebel Installation guide can be downloaded for free from http://edelivery.oracle.com A login is required for the Siebel Support Web
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 8
Figure 3: Siebel Configuration where 2 instances of Call Center OM, 2 Siebel Remote Servers and 1 instance of the Siebel Gateway Server are protected by Oracle Clusterware for Siebel. The RAC database is also protected by another instantiation of the Oracle Clusterware.
CONFIGURING SIEBEL IN A HIGH AVAILABILITY ENVIRONMENT
In order to run the Siebel Gateway and the Siebel Server in a High Availability
configuration, highly available network resources are required. In addition to
redundant network adapters, Oracle Clusterware 11gR2 will be used to provide the
virtual IP addresses or virtual hostnames for those components. These network
resources are essential for external client communication to the application and as a
consequence, the Siebel components will have defined dependencies on these
network resources managed by the Oracle Clusterware stack.
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 9
As noted earlier, Oracle Clusterware 11gR2 will be used to start, stop, check and
clean the application and dependent resources. These operations are presented to
the Clusterware as management entry points to control application and are invoked
by an Oracle Clusterware entity called the script agent. This paper provides generic
action scripts for these entry points based on primitives provided by the Siebel
CRM software. The check action is used to monitor and detect fault of the
application and dependent resources. Upon detecting an application or resource
failure Oracle Clusterware will perform the appropriate restart, failover and clean
operations. It is imperative that the check action is coded, tested and functioning
properly. Failure of the check action triggers failover.
The following abbreviated steps outline how the Siebel application and dependent
network resources are configured with the Oracle Clusterware 11gR2 HA
Framework. The following section provides detailed syntax and examples, however
the appendix has operational action scripts and Siebel application scripts to create
the necessary resources.
These steps assume that the Oracle Clusterware 11gR2 and the Siebel software
binary trees are correctly installed and functionally tested:
1. Create, customize if necessary and test the action scripts for
a. The Siebel Gateway b. Every Siebel Server to be deployed on a cluster node.
2. Create an Application VIP for
a. The Siebel Gateway b. One for Every Siebel Server to be deployed on a cluster node.
3. Register the application with Oracle Clusterware
a. The Siebel Gateway b. Every Siebel Server to be deployed on a cluster node.
4. Define Role Management
a. assign the appropriate owner, access and execution privileges to the application resources
5. Test the Siebel High Availability environment for a. The Siebel Gateway
b. Every Siebel Server to be deployed on a cluster node.
When registering resources with Oracle Clusterware 11gR2, resource dependencies can be defined. Dependencies dictate whether other resources must be started or stopped with the registered resource, for example the application VIP must be started before the application resource and stopped after the application resource.
In this paper, the Siebel Gateway and
Siebel Server High Availability
configuration assumes a 2 node cluster.
In a active/passive setup, one server
actively runs applications and services.
The other is usually idle. If the active
server fails, its workload is switched to the
idle server, which then takes over
application processing.
The Siebel Server Gateway and the Siebel
Server can be placed on different nodes to
utilize all available resources.
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 10
Oracle Clusterware 11gR2 start and stop dependencies offer a rich dependency model with hard, weak, pullup, dispersion and attraction attributes8. The following steps illustrate the configuration and deployment of Siebel Servers and the Siebel Gateway Server in the Oracle Clusterware HA framework.
Step 1a: Create an Application VIP for the Siebel Gateway
Go to: $GRID_HOME/bin (/u01/app/11.2.0/grid/bin by default) and issue
the following as superuser, a.k.a, the root user:
In this example, the Siebel Gateway application VIP named sieb_gtwy_vip is
created on the primary public network, Oracle Clusterware resource
ora.net1.network (network=1), with a user configurable virtual IP address. The
application VIP is a local root owned resource and as such, must be created as root.
Note that ‘network 1’ is the default public network created at the time the Oracle
Clusterware was configured. This network will use the same network interface and
defined subnet as the default public network. If you require a dedicated network
resource, you will need to define a different network resource using a separate
network interface and separate subnet. To determine and validate network
configurations use the command ‘crsctl status resource ora.net<N>.network’
where <N> represents the network number (1 being the default). This command
will provide you the current and available network attribute settings for a given
network known to the Oracle Clusterware. Note: This command and all
commands illustrated in this paper assume single line syntax.
The subnet for the sieb_gtw_vip VIP must be the same as the subnet defined for
the physical NIC defined for ora.net1.network (here: eth0). In LINUX and UNIX
environments the subnet can be determined using the command ‘/sbin/ifconfig –a
<IF>’, where <IF> represents the network interface, such as eth0. The CIDR
addressing can be derived using the “mask” parameter value and the inet address
defined.
The IP address must either be registered in the DNS used in the environment or be
defined in the local hosts file on all nodes in the cluster prior to issuing this
command.
8 Idem, Oracle® Clusterware Administration and Deployment Guide 11g Release 2 (11.2)
# $GRID_HOME/bin/appvipcfg create –network=1 \ –ip=<VIP ADDRESS> -vipname=sieb_gtwy_vip –user=root \ –group=<GROUPID>
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 11
When the Application VIP is created it is automatically registered with Oracle
Clusterware. When creating the application VIP sieb_gtwy_vip, you should see the
following echoed to stdout:
Executing cmd: /u01/app/11.2.0/grid/bin/crsctl add resource sieb_gtwy_vip -type app.appvip_net1.type –attr “USR_ORA_VIP=<VIP ADDRESS>, START_DEPENDENCIES=hard(ora.net1.network) pullup(ora.net1.network,STOP_DEPENDENCIES=hard(ora.net1.network),ACL=’owner:root:rwx,pgrp:root:r-x,other::r–,user:root:r-x’,HOSTING_MEMBERS=<HOSTNAME WHERE THE VIP STARTED>, APPSVIP_FAILBACK=”
To confirm the resource registration and to check status with the Oracle Clusterware issue the command:
Which results in the following status:
NAME=sieb_gtwy_vip TYPE=app.appvip_net1.type TARGET=OFFLINE STATE=OFFLINE
TARGET is to be online, STATE is currently offline as the resource has not been
started yet.
Application VIPs are local resources created and owned by root. Oracle
Clusterware provides UNIX like ACL control over any defined resource9. If the
sieb_gtwy_vip will need to be executed by non-root users, define the correct ACL
accordingly. It is common that the execution permissions would be granted to the
owner of the Siebel binaries as in this example, the user orasiebel.
To set or modify permissions on the sieb_gtwy_vip execute, as root:
The Siebel software owner (orasiebel) is explicitly granted permission to start, stop
and relocate the sieb_gtwy_vip application VIP resource that runs with root
privileges. Note that this is distinct from the Oracle Clusterware core VIP resources
used by the Real Application Clusters database which may be running in the same
environment.
9 See the ACL list and owner in the execution output for appvipcfg above
# $GRID_HOME/bin/crsctl setperm resource sieb_gtwy_vip –u user:orasiebel:r-x
# $GRID_HOME/bin/crsctl status resource sieb_gtwy_vip
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 12
Step 1b: Create an Siebel Server Application VIP per node
Similarly to Step 1a, create an Application VIP for each Siebel Server.
As root execute:
Where <VIP ADDRESS> is the virtual IP address for the Siebel Server which is
different from the sieb_gtwy_vip address. Note that the default public network is
used here as with the Siebel Gateway Server.
Once the resource is created, check the resource registration and status by
executing the command:
This command should return with:
NAME=sieb_srv_vip TYPE=app.appvip_net1.type TARGET=OFFLINE STATE=OFFLINE
TARGET is offline, STATE is currently offline as the resource has not been
started yet.
As noted earlier application VIPs are created and run as root. In order for non-root users to manage the VIP resource, correct permissions must be set for the user on that resource:
where ‘\’ represents a command line break for single line command syntax.
A single Siebel Server VIP can be configured to be shared by multiple Siebel Servers running on a specific server. If you require individual Siebel Server HA, a unique VIP should be configured for each of the Siebel Servers running in the environment. In our example, we will create a single Siebel Server VIP per server to be shared by the Siebel Servers running on the server.
Configuration of the Siebel Gateway and Siebel Servers
The Siebel Gateway needs to be configured to run on the VIP just created in step
1a (sieb_gtwy_vip). Therefore, Oracle strongly recommends using a name resolution
# $GRID_HOME/bin/appvipcfg create –network=1 –ip=<VIP ADDRESS> -vipname=sieb_srv_vip –user=root
# $GRID_HOME/bin/crsctl setperm sieb_srv1_vip –u \ user:orasiebel:r-x
# $GRID_HOME/bin/crsctl status resource sieb_srv_vip
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 13
for this VIP. The name resolution can either be performed using a DNS or by
adding an alias to the hosts files of all the nodes in the cluster.
When configuring the Siebel Gateway, the virtual IP and virtual host name should
then be used as the Gateway Name Server Host Name.
Figure 4: Siebel Gateway Configuration
Similarly, the Siebel Server host parameter needs to be configured to use the virtual
host name of the Gateway Name Server Host and not the physical host name of
the server.
Step 2a: Create and Test the Action Script for the Siebel Gateway
In this step, the script that will be used to start, stop, and check the status of the
Siebel Gateway Server is created and tested. However, this step will not go into
details on how to create the script. Instead, use the sample script “sieb_gtwy.scr”
provided in Appendix B as an example.
From the Oracle Clusterware point of view, there needs to be one script accepting
“start”, “check”, “stop”, and “clean” as command line arguments, since Oracle
Clusterware will call this script for each of those actions, passing the respective
argument.
The Siebel Gateway is configured to run on the virtual host name for the server,
which resolves to the VIP created in step 1a (sieb_gtwy_vip). Therefore, the VIP
needs to active before the Siebel Gateway can be started.
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 14
For our example, as the orasiebel user execute:
Upon a successful execution of this command, the following message is displayed:
Attempting to start `sieb_gtwy_vip` on member `node1` Start of `sieb_gtwy_vip` on member `node1` succeeded.
Due to explicit startup dependencies between the Siebel Gateway and the Siebel
Gateway VIP defined in the script supplied when the Siebel Gateway resource is
created, the Siebel Gateway will be started on the node where the assigned
sieb_gtwy_vip is running. If the VIP is not running, it will be started implicitly. In
this example, Siebel application resources and their dependencies are not restricted
to run on specific nodes in the cluster. A PLACEMENT resource attribute can be
defined when the Siebel application resource or VIPs are created, controlling the
start, failover or relocation eligibility of a server in the cluster. This topic will be
addressed in subsequent versions of this document. If interested, details on
PLACEMENT and other Oracle Clusteware 11gR2 resource attributes can be
found in the earlier referenced Oracle Clusterware 11gR2 Admin. Guide.
Regardless of placement policy, crsctl commands to start, stop, and relocate any
resource can be executed from any node in the cluster.
Once the VIP has been started successfully, the start function of the action Script
for the Siebel Gateway can be tested. Since the Siebel Gateway itself has not been
registered with Oracle Clusterware yet, any action of the action script needs to be
tested manually.
Therefore, change to the Siebel software owner (here: orasiebel), go to the directory
where the action script for the Siebel Gateway has been stored and issue:
On the next prompt, enter:
Note: a successful execution of the script would result in echo $? and must return
the value 0. However, in order to make sure that the script returns the right value
depending on the operation performed, check the successful execution using the
$ $GRID_HOME/bin/crsctl start sieb_gtwy_vip
sieb_gtwy.scr start
echo $?
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 15
operating system command “ps” to list running processes. As the orasiebel user
issue:
At this stage, this command should list a running Siebel Gateway.
In order to test the check action for the Siebel Gateway, issue the command listed
below as the orasiebel user. Similarly to the test above, issue echo $? after calling
the action script with the appropriate parameter (check). Make sure that “0” is
returned, indicating a successful execution:
Once the start and check is functioning as expected, the sieb_gtwy.scr should be
called with the stop parameter to test the shutdown of the Siebel Gateway process.
As before, issue ‘echo $?’ to verify the result. Again, a zero value should be returned
upon a successful shutdown of the Siebel Gateway.
Step 2b: Create and Test the Action Script for each Siebel Server
Similarly to Step 2a, create the script that will be used to start, stop and check the
status of each Siebel Servers deployed. See Appendix C for an example of the
sieb_srvr.scr script.
Test the script (see examples in step 2a for the sieb_gtwy_scr tests) and ensure it is
working before creating the application profile in step 3.
NOTE: ONCE THE SIEBEL APPLICATIONS ARE CREATED AND
ADDED TO THE ORACLE CLUSTERWARE, DO NO EXECUTE THE
START, STOP, CHECK AND CLEAN ACTIONS OUTSIDE OF THE
ORACLE CLUSTERWARE HA FRAMEWORK. ALL CONTROL OF
THE APPLICATION MUST NOW BE EXECUTED USING CRSCTL.
ps –ef |grep siebsvc | grep gtwyns
sieb_gtwy.scr check
echo $?
sieb_gtwy.scr stop
echo $?
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 16
Step 3a: Create a Siebel Gateway Resource Type With Oracle
Clusterware
Generally, all resources are unique but some resources may have common
attributes. Oracle Clusterware uses resource types to organize these similar
resources. Benefits that resource types provide are:
• Manage only necessary resource attributes
• Manage all resources based on the resource type To create a Siebel resource type to more easily manage Siebel application resources, issue the following:
where $GRID_HOME is the absolute path for the Oracle Clusterware binary install and $DIRPATH = the absolute path location of the script files, for example, /opt/siebel_HA_scripts/siebel_gtwy.scr
Step 3b: Add the Siebel Gateway Application to Oracle Clusterware
After creating and thoroughly testing the action scripts for the Siebel Gateway and
the Siebel Servers, insure that there are no instances of the Siebel Gateway and
associated processes running on any server in the cluster. Only then, register the
Siebel Gateway resource with the Oracle Clusterware. When you register an
application with the Oracle Clusterware, the relevant information about the
application for the management of the application and relevant resources of the
application as well as the execution profile of the application are stored in the
Oracle Clusterware Repository (OCR). This information includes the absolute path
the the action script described above, the defined permissions (ACL) for the
application resource as well as any required start/stop resource dependencies.
To add and ‘register’ the Siebel Gateway application with the Oracle Clusterware,
As the orasiebel user, issue:
where $GRID_HOME is the absolute path of the Oracle Clusterware binary install,
$SIEBEL_HOME is the absolute path for the Siebel Gateway Name Server binary
install and $LOG_DIR is a user defined logging directory.
# $GRID_HOME/bin/crsctl add type siebel_gtwy_type \ -basetype cluster_resource \ -attr "ATTRIBUTE=ACTION_SCRIPT, \ TYPE=string,DEFAULT_VALUE=$DIRPATH/siebel_gtwy.scr, \ ATTRIBUTE=SIEBEL_HOME,TYPE=string, \ FLAGS=REQUIRED,ATTRIBUTE=LOG_DIR, \ TYPE=string,FLAGS=REQUIRED"
$ $GRID_HOME/bin/crsctl add resource siebel_gtwy_app -type siebel_type -attr \ "ACL='owner:orasiebel:rwx,pgrp:siebel:r-x,other::r--', \ SIEBEL_HOME=$SIEBEL_HOME,LOG_DIR=$LOG_DIR, \ CHECK_INTERVAL=30,RESTART_ATTEMPTS=10,START_TIMEOUT=300, \ STOP_TIMEOUT=300,AUTO_START=restore, \ START_DEPENDENCIES=hard(siebel_gtwy_vip)pullup:always(siebel_gtwy_vip), \ STOP_DEPENDENCIES=hard(intermediate:siebel_gtwy_vip)"
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 17
This command adds the siebel_gtwy_app as a defined type siebel_type and
subsequently defines a number of resource attributes associated with the
siebel_gtwy_app. These attributes include the ACTION_SCRIPT with the
application control entry points, ACL read, write, execute permissions for the
orasiebuser and siebel group members, the SIEBEL_HOME, a user defined
LOG_DIR, CHECK_INTERVAL indicating the frequency of the check action,
application restart attempts, and related timeout if the application does not start, in
addition to stop timeouts and the AUTO_START attribute indicating whether the
application should be restarted when the server comes up. The
START_DEPENDENCIES and STOP_DEPENDENCIES are directives for
associated relationships with the siebel_gtwy_vip, whereby, the sieb_gtwy_app
cannot start unless the siebel_gtwy_vip is started, and, if it is not running, an
attempt will be made to pull the siebel_gtwy_vip up and put the state online.
Similarly, the STOP_DEPENDENCY will take down the siebel_gtwy_app when
the siebel_gtwy_vip resource is stopped. The siebel_gtwy_vip is a required resource
for the siebel_gtwy_app.
Step 4a: Create a Siebel Server Resource Type With Oracle Clusterware
As mentioned, generally, all resources are unique but some resources may have
common attributes. Oracle Clusterware uses resource types to organize these
similar resources. Configuring a Siebel Server Resource Type with a common
action script allows for simple and efficient resource grouping of common
resources that invoke the same actions. This avoids having to maintain multiple
action scripts or script definitions associated with each resource. In addition Oracle
Clusterware status commands and execution can filter on resource type.
To create a Siebel Server resource type to more easily manage Siebel Server application resources, issue the following:
where $GRID_HOME is the absolute path of the Oracle Clusterware binary install
and $DIRPATH is the absolute path location of the script files, as in the previous
example.
Step 4b: Add the Siebel Server to Oracle Clusterware
As with the Siebel Gateway, the Siebel Server needs to be added and ‘registered’
with Oracle Clusterware and permissions correctly set to run as the Siebel operating
system user (here: orasiebel). Execute the following command as the Oracle
Clusterware software owner (here: oracle):
# $GRID_HOME/bin/crsctl add type siebel_srv_type -basetype cluster_resource \ -attr "ATTRIBUTE=ACTION_SCRIPT,TYPE=string, \ DEFAULT_VALUE=$DIRPATH/siebel_srv.scr, \ ATTRIBUTE=SIEBEL_HOME,TYPE=string, \ FLAGS=REQUIRED,ATTRIBUTE=LOG_DIR, \ TYPE=string,FLAGS=REQUIRED"
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 18
where $GRID_HOME is the absolute path of the Oracle Clusterware binary install,
$SIEBEL_HOME is the absolute path for the Siebel Server binary install and
LOG_DIR is a user defined logging directory.
As with the Siebel Gateway resource the CHECK_INTERVAL,
RESTART_ATTEMPTS, START_TIMEOUT, STOP_TIMEOUT,
AUTO_START and start/stop dependencies are defined as attributes of the
siebel_srv_app resource and are managed by the Oracle Clusterware. These settings
have been tested and optimal for Siebel component high availability.
Step 5: Test the Siebel High Availability Environment
Before deploying the Siebel HA environement, testing is required. This step will be
used to outline some basic tests that should be performed. Depending on the
production environment, additional tests may be required.
The tests should emphasize:
1. Use of Oracle Clusterware commands to operate on registered resources
a. To ensure that dependencies are maintained and executed
correctly.
b. To validate that Siebel application components under Oracle
Clusterware control are not executed outside of the HA
framework.
2. To validate reaction to failure scenarios such as
a. Process failures
b. Node failures
c. Network failures
3. To practice maintenance operations which require relocation of resources
among nodes
Suitable scenarios should begin with tests which start and stop the registered Siebel
applications using Oracle Clusterware commands. These commands must work
properly before continuing with any other tests. When the start and stop of the
application is executed outside of the Oracle Clsuterware HA framework,
unpredictable results may occur.
To test the start of the Siebel Gateway issue:
$ $GRID_HOME/bin/crsctl add resource siebel_srv_app -type siebel_srv_type -attr \ "ACL='owner:orasiebel:rwx,pgrp:siebel:r-x,other::r--', \ SIEBEL_HOME=$SIEBEL_HOME,LOG_DIR=$LOG_DIR, \ CHECK_INTERVAL=30,RESTART_ATTEMPTS=10, \ START_TIMEOUT=300, STOP_TIMEOUT=300,AUTO_START=restore, \ START_DEPENDENCIES=hard(siebel_srv_vip)pullup:always(siebel_srv_vip), \ STOP_DEPENDENCIES=hard(intermediate:siebel_srv_vip)" NEED DEPENDENCY ON GTWY
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 19
Logically, the Siebel Gateway needs to run before any Siebel Server should be
started, since necessary configuration information is required from the Siebel
Gateway by each starting Siebel Server.
Therefore, the start action of the Siebel Server action script (sieb_srvr.scr – see
Appendix C) checks whether or not a Siebel Gateway is running in the cluster. If
no Siebel Gateway is running, it will start a Siebel Gateway using the defined pullup
dependency on the sieb_gtwy_vip resource. Nevertheless, it makes sense to test this
scenario during production testing.
Following the test steps in this paper, stop the Siebel Gateway and try starting the
whole stack by starting the Siebel Server as the high level application:
Then start the Siebel Server:
The start of the Siebel Server should also start the Siebel Gateway on one of the
nodes in the cluster. Proper startup of the Siebel Gateway and Siebel Servers should
be confirmed using `crsctl stat resource –t`.
It should also be noted that based on the dependency settings the VIPs for the
Siebel Gateway and the Siebel Servers should have been started implicitly, too.
Those VIPs will always run on the same node as the associated Siebel Services
(Gateway or Server).
However, starting those Siebel Services in this way (using a Siebel Server startup to
start the Siebel Gateway) may start all components on the same node. While this is
generally not a problem and certain application profile settings (or starting the
Siebel Servers using the –c <nodename> when issuing the crs_start command)
might prevent that, there might still be scenarios in which a relocation of one of
those components is desirable.
Therefore, suitable relocation tests using the `crsctl relocate resource <RES>`
command should be performed. When running those tests, it should be also
ensured that dependencies will follow the root resource. E.g. one can only relocate
a resource that other recourses are not dependent on.
If there are dependencies to the resource, the ‘force’ (-f) option must be used to
relocate the respective resource. However, appropriate error messages will be given
in this case. If the force option is used, all resources (including the dependent ones)
$ $GRID_HOME/bin/crsctl start sieb_gtwy_app
$ $GRID_HOME/bin/crsctl start sieb_srv_app
$ $GRID_HOME/bin/crsctl stop sieb_gtwy_app
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 20
will be relocated.
To test the relocation of the Siebel Gateway go to and issue:
In the above example the Siebel Gateway is relocated to ‘node2’, which assumes
that it was running on ‘node1’ before. Further relocation tests can be performed for
each Siebel component registered in the cluster as well as for VIPs.
After suitable tests have shown that Oracle Clusterware commands can successfully
be used to start, stop, and relocate all the registered resources, tests should be
performed for the check operations. Those tests should include all plausible failure
scenarios. Note, the viability of the process protected by Oracle Clusterware
depends on the correct execution and resulting return codes in order to take the
necessary corrective action. If the check action does not execute, or executes
incorrectly, you may experience unpredictable results. It is well worth the effort to
evaluate the check action in various scenarios. See the appendix for the Siebel
Check action scripts invoked for all of the Siebel resources.
Oracle does not generally recommend on how those failure scenarios should be
tested. Suitable test scenarios should be developed and performed in accordance to
the production environment.
SUMMARY
The information presented assumed that the following steps have been completed:
• Oracle Clusterware is installed10
• Oracle Real Application Clusters is installed11
• Siebel Gateway is installed
• Siebel Server is installed
• Oracle HTTP Server is installed12
• Siebel Siebel Web Server Extention (SWSE) is installed13
10 For the Oracle Clusterware Installation and Configuration guides refer to: http://www.oracle.com/pls/db111/portal.portal_db?selected=11&frame= 11 For the Oracle Real Application Clusters Installation and Configuration guides refer to: http://www.oracle.com/pls/db111/portal.portal_db?selected=11&frame= 12 For installation of the Oracle HTTP Server, refer to: http://download.oracle.com/docs/cd/B25221_04/nav/docindex.htm
$ $GRID_HOME/bin/crsctl relocate -c node2 sieb_gtwy_app
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 21
Based on this software infrastructure, Oracle Clusterware can be used to protect
the Siebel Gateway and the Siebel Servers in a High Availability environment.
This paper does not claim to be complete in its instructions. Instead, the general
procedure is outlined and respective cross-references and recommendations have
been made in regards to the required steps to deploy in production environments.
The sample scripts and application profiles provided in Appendix A-D can be used
to implement this High Availability environment for Siebel applications discussed
in this paper. But customization will be required before using them in production.
NOTE: Oracle Clusterware has pre-packaged agents for many applications. A pre-
packaged agent for Siebel CRM will be available soon. Please see:
http://www.oracle.com/technetwork/products/clusterware/overview/index.html
For up-to-date release status for the Siebel agents.
13 For documentation on the installation of all Siebel Components refer to http://edelivery.oracle.com and download the “Siebel Business Applications Media Pack 8.0 Release for Linux x86” (when working on Linux x86).
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 22
APPENDIX A – SIEBEL GATEWAY RESOURCE CREATE SCRIPT
#!/bin/ksh # # This script: # Creates Siebel GATEWAY VIP, sieb_gtwy_vip. # Sets the correct ACLs on sieb_gtwy_vip # Creates the Siebel Resource TYPE siebel_type. # Adds the Siebel GATEWAY APP, seib_gtwy_app # Executes status on these two resources, sieb_gtwy_vip and sieb_gtwy_app # after this script exits. # create_sieb_gtwy_res.sh # SCRIPT=$0 ACTION=$1 IP="" SIEBEL_HOME="" LOG_DIR="" USER="" GROUP="" usage2() { echo "Creates Siebel Virtual IP, resource type, and gateway resource " echo "Root privilege is required" echo " " } usage() { echo "Usage: $0 " echo " --siebel_home <siebel_home> Siebel home directory" echo " --log_dir <log_dir> Location of the log file" echo " --ip <ip_address> IP address" echo " --user <user> Operating System user name that owns the instance" echo " --group <group> (Optional) Name of the group to which the " echo " Operating System user belongs" exit 1 } if [ $(whoami) != "root" ]; then echo "User doesn't have root privilege to execute the script." echo "Ensure that user have root privilege and then reissue the command." exit 1 fi # check for empty arguments NBR_ARG=$# if [ $NBR_ARG -eq 0 ] then usage fi # check for help if [ $1 = "-h" ] then
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 23
usage2 usage fi # get option siebel_home if [ $1 = "--siebel_home" ] then if [ X$2 = "X" ] then echo "Option 'siebel_home' must be followed by a value" usage else if [ -d "$2" ] then SIEBEL_HOME=$2 else echo "Directory $2 does not exists" exit 1 fi fi else echo "Missing mandatory option 'siebel_home'" usage fi # get option nodes if [ $NBR_ARG -ge 3 ] && [ $3 = "--log_dir" ] then if [ X$4 = "X" ] then echo "Option 'log_dir' must be followed by a value" usage else LOG_DIR=$4 fi else echo "Missing mandatory option 'log_dir'" usage fi # get option ip if [ $NBR_ARG -ge 5 ] && [ $5 = "--ip" ] then if [ X$6 = "X" ] then echo "Option 'ip' must be followed by a value" usage else IP=$6 fi else echo "Missing mandatory option 'ip'" usage fi # get option user if [ $NBR_ARG -ge 7 ] && [ $7 = "--user" ] then if [ X$8 = "X" ] then
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 24
echo "Option 'user' must be followed by a value" usage else USER=$8 fi else echo "Missing mandatory option 'user'" usage fi # get option group if [ $NBR_ARG -ge 9 ] then if [ $9 = "--group" ] then if [ X${10} = "X" ] then echo "Option 'group' must be followed by a value" usage else GROUP=${10} fi else echo "Invalide option $9" usage fi fi # check if action script exists case $SCRIPT in /*) DIRPATH=$(dirname $SCRIPT) ;; *) DIRPATH=$(dirname $(pwd -P $0)/${0#\.\/}) ;; esac if ! [ -f "$DIRPATH/siebel_gtwy.scr" ]; then echo "The action script $DIRPATH/siebel_gtwy.scr file does not exist." echo "Ensure the action script file exists in the current directory and reissue the command." exit 1 fi # find crs_home CRS_HOME=`awk /crs_home/ /etc/oracle/olr.loc | awk -F"=" '{print $2}'` # Add gtwy-vip # as root if [ X$GROUP = "X" ] then $CRS_HOME/bin/appvipcfg create -network=1 -ip=$IP -vipname=siebel_gtwy_vip -user=$USER >/dev/null 2>&1 else $CRS_HOME/bin/appvipcfg create -network=1 -ip=$IP -vipname=siebel_gtwy_vip -user=$USER -group=$GROUP>/dev/null 2>&1 fi # Set gtwy-vip perms
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 25
# The VIP is a root resource. ACLs must be defined to manage the resource # SYNTAX: crsctl setperm resource resource_name -u user:oracle:r-x $CRS_HOME/bin/crsctl setperm res siebel_gtwy_vip -u user:oracle:r-x # add siebel_type $CRS_HOME/bin/crsctl add type siebel_type -basetype cluster_resource -attr "ATTRIBUTE=ACTION_SCRIPT,TYPE=string,DEFAULT_VALUE=$DIRPATH/siebel_gtwy.scr,ATTRIBUTE=SIEBEL_HOME,TYPE=string,FLAGS=REQUIRED,ATTRIBUTE=LOG_DIR,TYPE=string,FLAGS=REQUIRED" # add siebel_gtwy_app if [ X$GROUP = "X" ] then GROUP="root" fi $CRS_HOME/bin/crsctl add resource siebel_gtwy_app -type siebel_type -attr "ACL='owner:$USER:rwx,pgrp:$GROUP:r-x,other::r--',SIEBEL_HOME=$SIEBEL_HOME,LOG_DIR=$LOG_DIR,CHECK_INTERVAL=30,RESTART_ATTEMPTS=10,START_TIMEOUT=300,STOP_TIMEOUT=300,AUTO_START=restore,START_DEPENDENCIES=hard(siebel_gtwy_vip)pullup:always(siebel_gtwy_vip),STOP_DEPENDENCIES=hard(intermediate:siebel_gtwy_vip)" # status resource $CRS_HOME/bin/crsctl stat res siebel_gtwy_app siebel_gtwy_vip -t echo " " echo "To start Siebel gateway VIP, as root execute:" echo " crsctl start resource siebel_gtwy_vip" echo " " echo "To start Siebel gateway resource, as the Siebel owner execute:" echo " crsctl start resource siebel_gtwy_app" echo " " echo "NOTE: starting the siebel_gtwy_app may pull up the siebel_gtwy_vip" echo " "
APPENDIX B – SIEBEL GATEWAY ACTION SCRIPT SCRIPT
#!/bin/ksh # # This script executes the start, stop, check and clean actions # for the Siebel Gateway Name Server # sieb_gtwy.scr # SCRIPT=$0 ACTION=$1 # Actions (start/stop/check/clean) RET1=1 RETVAL=1 # get SIEBEL_HOME attr CRS_HOME=`awk /crs_home/ /etc/oracle/olr.loc | awk -F"=" '{print $2}'` OUT=`$CRS_HOME/bin/crsctl stat res siebel_gtwy_app -f` SIEBEL_HOME=`echo $OUT | awk -F"SIEBEL_HOME=" '{print $2}'|awk '{print $1;}'` # get LOG_DIR attr LOGDIR=`echo $OUT | awk -F"LOG_DIR=" '{print $2}'|awk '{print $1;}'` LOGDIR="$LOGDIR/siebel_gtwy.log"
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 26
case $1 in # Start the gtwysrv process 'start') . $SIEBEL_HOME/siebenv.sh $SIEBEL_HOME/bin/start_ns 1>>/$LOGDIR 2>&1 RET1=$? if [ ${RET1:-0} -eq 0 ]; then RETVAL=0 else RETVAL=1 fi ;; # Stop the gtwysrv process 'stop') . $SIEBEL_HOME/siebenv.sh $SIEBEL_HOME/bin/stop_ns 1>>/$LOGDIR 2>&1 RET1=$? if [ ${RET1:-0} -eq 0 ]; then RETVAL=0 else RETVAL=1 fi ;; # Check for gtwyns process is running 'check') . $SIEBEL_HOME/siebenv.sh $SIEBEL_HOME/bin/check_ns 1>>/$LOGDIR 2>&1 exit $? ;; # Clean gtwyns process 'clean') . $SIEBEL_HOME/siebenv.sh $SIEBEL_HOME/bin/stop_ns 1>>/$LOGDIR 2>&1 RET1=$? if [ ${RET1:-0} -eq 0 ]; then RETVAL=0 elif [ ${RET1:-0} -eq 1 ]; then RETVAL=0 fi ;; # invalid action *) echo "usage: $0 {start | stop | check | clean}" ;; esac if [ $RETVAL -eq 0 ]; then exit 0 else exit 1 fi
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 27
APPENDIX C – SIEBEL GATEWAY CHECK ACTION SCRIPT
#!/bin/ksh # # This is the check action script called by sieb_gtwy.scr # This script executes a light weight check action based # on process ps output existence of siebsvc and-or gtwyns # check_ns called from sieb_gtwy.scr action script. # This script should be placed in the $SIEBEL_HOME # directory defined for the sieb_gtwy.scr action script # USAGE="usage: check_ns [-r <siebel root>] " PS=/bin/ps ## set variables used in siebctl command below ## SVCNAME=gtwyns CLSAGFW_ONLINE=0; CLSAGFW_UNPLANNED_OFFLINE=1; CLSAGFW_PLANNED_OFFLINE=2; CLSAGFW_UNKNOWN=3; ## make sure that SIEBEL_ROOT is set (either from command line or ## environment) ## if [ "X$SIEBEL_ROOT" = "X" ] then print "The Siebel root directory must be specified using the \"-r\" switch" print "or the SIEBEL_ROOT environment variable" print "$USAGE" exit 1 fi ## make sure no more arguments were specified ## if [ "X$*" != "X" ] then print "Unexpected argument(s): $*" print "$USAGE" exit 1 fi # check if the gateway is already running running_gtwy=`$PS -ef | grep siebsvc | grep gtwyns 2> /dev/null` if [ "X$running_gtwy" = "X" ] then print "Gateway resoure=$_CRS_NAME is UNPLANNED_OFFLINE" print "service=$SVCNAME is UNPLANNED_OFFLINE" return $CLSAGFW_UNPLANNED_OFFLINE else print "Gateway resoure=$_CRS_NAME is ONLINE" print "service=$SVCNAME is ONLINE" return $CLSAGFW_ONLINE fi
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 28
APPENDIX D – SIEBEL SERVER RESOURCE CREATE SCRIPT
#!/bin/ksh # # This script: # Creates Siebel SERVER VIP, sieb_srv_vip. # Sets the correct ACLs on sieb_srv_vip # Creates the Siebel Server Resource TYPE siebel_srv_type. # Adds the Siebel SERVER APP, seib_srv_app # Executes status on these two resources, sieb_srv_vip and sieb_srv_app # after this script exits. # create_sieb_srv_res.sh # SCRIPT=$0 ACTION=$1 IP="" SIEBEL_HOME="" LOG_DIR="" USER="" GROUP="" usage2() { echo "Creates Siebel Virtual IP, resource type, and server resource " echo "Root privilege is required" echo " " } usage() { echo "Usage: $0 " echo " --siebel_home <siebel_home> Siebel home directory" echo " --log_dir <log_dir> Location of the log file" echo " --ip <ip_address> IP address" echo " --user <user> Operating System user name that owns the instance" echo " --group <group> (Optional) Name of the group to which the " echo " Operating System user belongs" exit 1 } if [ $(whoami) != "root" ]; then echo "User doesn't have root privilege to execute the script." echo "Ensure that user have root privilege and then reissue the command." exit 1 fi # check for empty arguments NBR_ARG=$# if [ $NBR_ARG -eq 0 ] then usage fi # check for help if [ $1 = "-h" ]
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 29
then usage2 usage fi # get option siebel_home if [ $1 = "--siebel_home" ] then if [ X$2 = "X" ] then echo "Option 'siebel_home' must be followed by a value" usage else if [ -d "$2" ] then SIEBEL_HOME=$2 else echo "Directory $2 does not exists" exit 1 fi fi else echo "Missing mandatory option 'siebel_home'" usage fi # get option nodes if [ $NBR_ARG -ge 3 ] && [ $3 = "--log_dir" ] then if [ X$4 = "X" ] then echo "Option 'log_dir' must be followed by a value" usage else LOG_DIR=$4 fi else echo "Missing mandatory option 'log_dir'" usage fi # get option ip if [ $NBR_ARG -ge 5 ] && [ $5 = "--ip" ] then if [ X$6 = "X" ] then echo "Option 'ip' must be followed by a value" usage else IP=$6 fi else echo "Missing mandatory option 'ip'" usage fi # get option user if [ $NBR_ARG -ge 7 ] && [ $7 = "--user" ] then if [ X$8 = "X" ]
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 30
then echo "Option 'user' must be followed by a value" usage else USER=$8 fi else echo "Missing mandatory option 'user'" usage fi # get option group if [ $NBR_ARG -ge 9 ] then if [ $9 = "--group" ] then if [ X${10} = "X" ] then echo "Option 'group' must be followed by a value" usage else GROUP=${10} fi else echo "Invalide option $9" usage fi fi # check if action script exists case $SCRIPT in /*) DIRPATH=$(dirname $SCRIPT) ;; *) DIRPATH=$(dirname $(pwd -P $0)/${0#\.\/}) ;; esac if ! [ -f "$DIRPATH/siebel_gtwy.scr" ]; then echo "The action script $DIRPATH/siebel_srv.scr file does not exist." echo "Ensure the action script file exists in the current directory and reissue the command." exit 1 fi # find crs_home CRS_HOME=`awk /crs_home/ /etc/oracle/olr.loc | awk -F"=" '{print $2}'` # Add srv-vip # as root if [ X$GROUP = "X" ] then $CRS_HOME/bin/appvipcfg create -network=1 -ip=$IP -vipname=siebel_srv_vip -user=$USER >/dev/null 2>&1 else $CRS_HOME/bin/appvipcfg create -network=1 -ip=$IP -vipname=siebel_srv_vip -user=$USER -group=$GROUP>/dev/null 2>&1 fi
Siebel CRM Applications protected by Oracle Clusterware 11gR2 Page 31
# Set srv-vip perms # The VIP is a root resource. ACLs must be defined to manage the resource # SYNTAX: crsctl setperm resource resource_name -u user:oracle:r-x $CRS_HOME/bin/crsctl setperm res siebel_srv_vip -u user:oracle:r-x # add siebel_type $CRS_HOME/bin/crsctl add type siebel_srv_type -basetype cluster_resource -attr "ATTRIBUTE=ACTION_SCRIPT,TYPE=string,DEFAULT_VALUE=$DIRPATH/siebel_srv.scr,ATTRIBUTE=SIEBEL_HOME,TYPE=string,FLAGS=REQUIRED,ATTRIBUTE=LOG_DIR,TYPE=string,FLAGS=REQUIRED" # add siebel_srv_app if [ X$GROUP = "X" ] then GROUP="root" fi $CRS_HOME/bin/crsctl add resource siebel_srv_app -type siebel_type -attr "ACL='owner:$USER:rwx,pgrp:$GROUP:r-x,other::r--',SIEBEL_HOME=$SIEBEL_HOME,LOG_DIR=$LOG_DIR,CHECK_INTERVAL=30,RESTART_ATTEMPTS=10,START_TIMEOUT=300,STOP_TIMEOUT=300,AUTO_START=restore,START_DEPENDENCIES=hard(siebel_srv_vip)pullup:always(siebel_srv_vip),STOP_DEPENDENCIES=hard(intermediate:siebel_srv_vip)" NEED DEPENDENCY ON GTWY
# status resource $CRS_HOME/bin/crsctl stat res siebel_srv_app siebel_srv_vip -t echo " " echo "To start Siebel Server VIP, as root execute:" echo " crsctl start resource siebel_srv_vip" echo " " echo "To start Siebel gateway resource, as the Siebel owner execute:" echo " crsctl start resource siebel_srv_app" echo " " echo "NOTE: starting the siebel_srv_app may pull up the siebel_srv_vip" echo " "
Providing High Availability for Siebel CRM Applications
December 2007, Version 1.6
Author: John P. McHugh
Contributing Authors: Jonathan Pham, Andrey Gusev, Philip Newlan, Roland Knapp
Kelly Tan, Markus Michalewicz, Bhaskar Gupta
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com
Copyright © 2007, Oracle Corporation and/or its affiliates. All rights reserved.
This document is provided for information purposes only and the
contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to any
other warranties or conditions, whether expressed orally or implied
in law, including implied warranties and conditions of merchantability
or fitness for a particular purpose. We specifically disclaim any
liability with respect to this document and no contractual obligations
are formed either directly or indirectly by this document. This document
may not be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without our prior written permission.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.