This chapter provides instructions on how to plan, set up, and configure Sun Cluster HA for BroadVision One-To-One Enterprise on your cluster nodes.
This chapter includes the following procedures.
"How to Install and Configure the BroadVision One-To-One Enterprise Software"
"How to Install Sun Cluster HA for BroadVision One-To-One Enterprise Packages"
"How to Register and Configure Sun Cluster HA for BroadVision One-To-One Enterprise"
"How to Verify the Sun Cluster HA for BroadVision One-To-One Enterprise Installation"
Configure Sun Cluster HA for BroadVision One-To-One back-end servers as a failover data service. Configure Sun Cluster HA for BroadVision One-To-One Interaction Managers as a scalable data service. See the Sun Cluster 3.0 12/01 Concepts document and Chapter 1, Planning for Sun Cluster Data Services for general information about data services, resource groups, resources, and other related topics.
The following table lists the sections that describe the installation and configuration tasks.
Table 11-1 Task Map: Installing and Configuring Sun Cluster HA for BroadVision One-To-One Enterprise
Sun Cluster HA for BroadVision One-To-One Enterprise provides fault monitoring and automatic failover for the BroadVision One-To-One Enterprise servers. This data service uses fault monitoring and automatic failover to eliminate single points of failure in a BroadVision One-To-One Enterprise site. The following table lists the data services that best protect BroadVision One-To-One Enterprise site components in a Sun Cluster configuration.
Table 11-2 Protection of BroadVision One-To-One Enterprise Site Components
BroadVision One-To-One Enterprise site component |
Protected by |
---|---|
BroadVision One-To-One Enterprise database |
Sun Cluster HA for Oracle or Sun Cluster HA for Sybase |
BroadVision One-To-One Interaction Managers |
Sun Cluster HA for BroadVision One-To-One Enterprise (scalable configuration) |
BroadVision One-To-One back-end servers |
Sun Cluster HA for BroadVision One-To-One Enterprise (failover configuration) |
HTTP servers |
Sun Cluster HA for iPlanet Web Server or Sun Cluster HA for Apache |
Use the scinstall(1M) command to install Sun Cluster HA for BroadVision One-To-One Enterprise. Sun Cluster HA for BroadVision One-To-One Enterprise requires a functioning cluster with the initial cluster framework already installed. See the Sun Cluster 3.0 12/01 Software Installation Guide for details about initial installation of cluster software. Register Sun Cluster HA for BroadVision One-To-One Enterprise after you successfully install the basic components of the Sun Cluster and BroadVision One-To-One Enterprise software.
When you design a Sun Cluster HA for BroadVision One-To-One Enterprise configuration, consider the following guidelines.
Use a BroadVision One-To-One Enterprise software version that is qualified with Sun Cluster 3.0.
Install the BroadVision One-To-One Enterprise software on the cluster file system.
Create a BroadVision user that is identical on all of the cluster nodes.
Install all of the necessary patches that are supplied by BroadVision to enable the BroadVision One-To-One Enterprise software to run in the Sun Cluster environment.
Configure the Interaction Managers, back-end servers, and root hosts in the $BV1TO1_VAR/etc/bv1to1.conf configuration file, as shown in "Supported Configurations".
Start your database before you start the BroadVision One-To-One Enterprise servers.
See your Enterprise Services representative for the most current information about BroadVision One-To-One Enterprise versions and configurations that are supported.
BroadVision One-To-One Enterprise configurations that are supported include the following.
For all of the supported configurations, set up your highly available database and HTTP server to match "Sun Cluster HA for DBMS and HTTP Server Configuration".
Configure Sun Cluster HA for DBMS and HTTP server as follows.
Configure Sun Cluster HA for Oracle or Sun Cluster HA for Sybase ASE to use a logical hostname.
Configure Sun Cluster HA for iPlanet Web Server or Sun Cluster HA for Apache to use a logical hostname (for failover configuration) or to use a shared address (for scalable configuration).
Configure the BroadVision One-To-One Enterprise root host, back-end, and Interaction Manager processes as follows.
Configure the root host resource to use one logical hostname in one resource group.
Configure back-end resources to use the remaining logical hostnames in multiple resource groups.
Configure the Interaction Manager resource on one of the following locations.
All of the cluster nodes.
All of the cluster private hostnames. See the Sun Cluster 3.0 12/01 Software Installation Guide for details on cluster interconnect and private hostnames.
Figure 11-1 illustrates a sample configuration that meets these guidelines.
Configure Interaction Manager resources on all of the cluster nodes or on all of the cluster private hostnames. If you configure the Interaction Managers on all of the cluster private hostnames, set up the HTTP servers on the same cluster. Alternatively, if you configure the Interaction Managers on all of the cluster nodes, the HTTP servers can be set up outside of the cluster.
Depending on the flexibility and granularity of administration that you require for each back-end resource, you can configure Sun Cluster HA for BroadVision One-To-One back-end servers to use only one resource group. To set up this alternative configuration, configure the BroadVision One-To-One Enterprise root host, back-end, and Interaction Manager processes as follows.
Configure root host and all of the back-end resources to use n logical hostnames inside of the same failover resource group.
Configure the Interaction Manager resource on one of the following locations.
All of the cluster nodes.
All of the cluster private hostnames. See the Sun Cluster 3.0 12/01 Software Installation Guide for details on cluster interconnect and private hostnames.
This configuration, which Figure 11-2 illustrates, requires alternative steps. See "Alternative Configuration" for more information.
Configure Interaction Manager resources on all of the cluster nodes or on all of the cluster private hostnames. If you configure the Interaction Managers on all of the cluster private hostnames, set up the HTTP servers on the same cluster. Alternatively, if you configure the Interaction Managers on all of the cluster nodes, the HTTP servers can be set up outside of the cluster.
See "Installing and Configuring the BroadVision One-To-One Enterprise Software, the Database, and the HTTP Server" and specifically, "Supported Configurations", before you install the BroadVision One-To-One Enterprise software. Additionally, consider the following cluster-related tasks.
BroadVision user home directory - Create an identical BroadVision user (bvuser) on all of the cluster nodes. Place the BroadVision user home directory on the cluster file system. Direct all of the BroadVision users on all of the cluster nodes to the same home directory.
BroadVision One-To-One Enterprise software - Install the BroadVision One-To-One Enterprise software on the cluster file system so that all of the cluster nodes can access the same BroadVision One-To-One Enterprise binaries and configuration files.
Use the procedures in this section to perform the following tasks.
Install and configure your database software to run in a Sun Cluster environment.
Install and configure your HTTP software to run in a Sun Cluster environment.
Install and configure the BroadVision One-To-One Enterprise software to run in a Sun Cluster environment.
Verify the BroadVision One-To-One Enterprise, database, and HTTP server installation.
Before you install the BroadVision One-To-One Enterprise, database, and HTTP server software in the Sun Cluster environment, run the scstat(1M) command to verify that the Sun Cluster software is fully operational.
See Chapter 2, Installing and Configuring Sun Cluster HA for Oracle to install Sun Cluster HA for Oracle or Chapter 10, Installing and Configuring Sun Cluster HA for Sybase ASE to install Sun Cluster HA for Sybase ASE.
If iPlanet Web Server is your HTTP server, follow the instructions in Chapter 3, Installing and Configuring Sun Cluster HA for iPlanetTM Web Server to configure Sun Cluster HA for iPlanet Web Server. If Apache Web Server is your HTTP server, follow the instructions in Chapter 5, Installing and Configuring Sun Cluster HA for Apache to configure Sun Cluster HA for Apache.
This procedure describes how to install and configure the BroadVision One-To-One Enterprise software and how to enable the BroadVision One-To-One Enterprise software to run in the Sun Cluster environment.
Follow the guidelines that are listed in "Configuration Guidelines for Sun Cluster HA for BroadVision One-To-One Enterprise" and "Pre-Installation Considerations".
Follow the instructions in the BroadVision One-To-One Enterprise Installation and Administration Guide to install the BroadVision One-To-One Enterprise software on the cluster file system.
Install the BroadVision One-To-One Enterprise software only once, on the cluster file system, from any cluster node.
Configure the $BV1TO1_VAR/etc/bv1to1.conf file.
Table 11-3 summarizes possible configurations in the $BV1TO1_VAR/etc/bv1to1.conf file for the BroadVision One-To-One Enterprise components. See "Supported Configurations" and the instructions in the BroadVision One-To-One Enterprise Installation and Administration Guide for details.
Table 11-3 Configuring the $BV1TO1_VAR/etc/bv1to1.conf File
If you configure the Interaction Managers on all of the cluster private hostnames, set up the HTTP servers on the same cluster. Alternatively, if you configure the Interaction Managers on all of the cluster nodes, the HTTP servers can be set up outside of the cluster.
Configure your cluster so that BroadVision One-To-One back-end servers can access the database from any cluster node.
Depending on the flexibility and granularity of administration that you require for each back-end resource, you can set up your failover resource groups in one of the following ways.
Set up multiple failover resource groups to use multiple logical hostnames. If you plan to use this option, go to "How to Verify the Sun Cluster HA for BroadVision One-To-One Enterprise Installation".
Set up one failover resource group to use n logical hostnames and to contain all of the back-end and root host resources. If you plan to use this option, proceed to "Alternative Configuration". Follow the procedures throughout "Alternative Configuration" to complete the installation.
See "Supported Configurations" for more information.
Perform this procedure to test starting and stopping the back-end processes on all of the nodes on which the back-end host and root host can run in a failover configuration. Additionally, perform this procedure to test the BroadVision One-To-One Enterprise Interaction Managers that you configured in the cluster.
Depending on the flexibility and granularity of administration that you require for each back-end resource, you can set up your failover resource groups in one of the following ways.
Set up multiple failover resource groups to use multiple logical hostnames. If you plan to use this option, proceed to Step 1.
Set up one failover resource group to use n logical hostnames and to contain all of the back-end and root host resources. If you plan to use this option, go to "Alternative Configuration". Follow the procedures throughout "Alternative Configuration" to complete the installation.
See "Supported Configurations" for more information.
To contain the BroadVision One-To-One Enterprise root host resource, create a failover resource group that uses the root host logical hostname.
# scrgadm -a -g root-host-resource-group [-h nodelist] |
Specifies the name of the resource group that uses the root host logical hostname and contains the BroadVision root host resource. The name of the root host resource group can be your choice but must be unique for resource groups within the cluster.
Specifies an optional, comma-separated list of physical node names or IDs that identify potential masters. The order here determines the order in which the Resource Group Manager (RGM) considers primary nodes during failover.
Create failover resource groups for the root host and back-end processes.
Run the scrgadm(1M) command to configure n failover resource groups for back-end processes that are configured on n logical hostnames.
# scrgadm -a -g back-end-resource-group-1 [-h nodelist] # scrgadm -a -g back-end-resource-group-2 [-h nodelist] # scrgadm -a -g back-end-resource-group-3 [-h nodelist] ... # scrgadm -a -g back-end-resource-group-n [-h nodelist] |
Specifies the name of the resource group that contains the back-end logical hostname and resource. The name of the back-end resource group can be your choice but must be unique for resource groups within the cluster.
Verify that you have added all of the logical hostnames that you use to your name service database.
Additionally, add all of the logical hostnames that you use to the /etc/inet/hosts file on each cluster node. Therefore, if the name service goes down, the nodes can still find the name-to-address mapping on their local hosts file.
Run the scrgadm command to add the logical hostname that each of the resource groups that you have created can use.
# scrgadm -a -L -g root-host-resource-group -l root-host-logical-hostname-1 [-n netiflist] # scrgadm -a -L -g back-end-resource-group-1 -l back-end-logical-hostname-1 [-n netiflist] # scrgadm -a -L -g back-end-resource-group-2 -l back-end-logical-hostname-2 [-n netiflist] ... # scrgadm -a -L -g back-end-resource-group-n -l back-end-logical-hostname-n [-n netiflist] |
Specifies the logical hostname (failover IP address) that the root host resource group uses.
Specifies the logical hostname that each back-end resource group uses.
Specifies an optional, comma-separated list that identifies the NAFO groups that are on each node. All of the nodes in the resource group's node list must be represented in netiflist. If you do not specify this option, the scrgadm command attempts to discover a net adapter on the subnet that the hostname list identifies for each node that is in the node list. For example, -n nafo0@nodename, nafo0@nodename2.
Create a scalable resource group for the Interaction Managers.
# scrgadm -a -g im-resource-group -y Maximum_primaries=m -y Desired_primaries=n |
Specifies the name of the scalable resource group that contains the Interaction Managers. This name can be your choice but must be unique for resource groups within the cluster.
Specifies the maximum number of active primary nodes allowed for this resource group. If you do not assign a value to this property, the default is 1.
Specifies the desired number of active primary nodes allowed for this resource group. If you do not assign a value to this property, the default is 1.
From one cluster node, run the scswitch(1M) command to move the failover resource groups into the managed state and bring them online.
# scswitch -Z -g root-host-resource-group # scswitch -Z -g back-end-resource-group-1 # scswitch -Z -g back-end-resource-group-2 ... # scswitch -Z -g back-end-resource-group-n |
You do not need to bring the scalable resource group online because the scalable resource group does not yet contain resources. You must bring failover resource groups online because the BroadVision One-To-One Enterprise back-end processes cannot start if the logical hostname resource is unavailable.
Check that the database is accessible.
See your database documentation for details.
Ensure that you have configured the database to enable BroadVision One-To-One back-end servers to access the database from any cluster node.
See your database documentation for details.
As the BroadVision user, log in to the cluster node that hosts the root host resource group.
Follow the steps in the BroadVision One-To-One Enterprise Installation and Administration Guide to run the following BroadVision commands.
Set the BV_LOCAL_HOST environment variable as root-host-logical-hostname.
Source the bv1to1.conf.sh file or the bv1to1.conf.csh file, depending on the shell that you use.
Run the bvconf bootstrap command on the root host to initialize the BroadVision One-To-One Enterprise installation.
Do not run the bvconf command as superuser.
% bvconf bootstrap -r root-host-logical-hostname |
Set the BV_LOCAL_HOST environment variable as back-end-logical-hostname or im-hostname.
Source the bv1to1.conf.sh file or the bv1to1.conf.csh file, depending on the shell that you use.
Ensure that the /etc/opt/BVSNsmgr directory exists and has write and execute permissions.
For each back-end host and Interaction Manager host, run the bvconf execute command to configure and start the BroadVision One-To-One Enterprise processes.
% bvconf execute -local -var shared -r root-host-logical-hostname |
Run the BroadVision command bvconf gateway to generate gateway configuration files for the HTTP gateway applications.
This command generates the files and writes them to the $BV1TO1_VAR/etc/appName.cfg file.
% bvconf gateway -A appName |
Specifies the gateway application name, which is defined in the $BV1TO1_VAR/etc/bv1to1.conf configuration file. See the BroadVision One-To-One Enterprise Installation and Administration Guide for details.
Copy the gateway application configuration file to the /etc/opt/BVSNsmgr directory on each of the cluster nodes that runs HTTP instances.
Ensure that you copy the gateway application configuration file with the extension .cfg.
See the BroadVision One-To-One Enterprise Installation and Administration Guide for details.
Configure and start the HTTP servers.
See your HTTP server documentation for details. Additionally, see the BroadVision One-To-One Enterprise Installation and Administration Guide for information on HTTP server configuration.
From a BroadVision client, connect to the BroadVision site, and check the installation.
If the BroadVision One-To-One Enterprise software is functioning correctly, perform the following steps to shut down the Interaction Managers, back-end processes, and root host processes.
Run the scswitch command to switch the resource groups to another cluster node, such as node2.
# scswitch -z -g root-host-resource-group -h node2 # scswitch -z -g back-end-resource-group-1 -h node2 # scswitch -z -g back-end-resource-group-2 -h node2 ... # scswitch -z -g back-end-resource-group-n -h node2 |
Restart the BroadVision One-To-One Enterprise software on node2.
Connect to the cluster from a BroadVision client, and check that the BroadVision One-To-One Enterprise software functions correctly.
Repeat Step 15 through Step 18 on all of the potential primaries of the BroadVision One-To-One Enterprise resource groups.
After you verify the BroadVision One-To-One Enterprise, database, and HTTP server installation, go to "How to Install Sun Cluster HA for BroadVision One-To-One Enterprise Packages".
Use the scinstall(1M) utility to install SUNWscbv, the Sun Cluster HA for BroadVision One-To-One Enterprise package, on a cluster. If you installed the SUNWscbv data service package as part of your initial Sun Cluster installation, proceed to "Registering and Configuring Sun Cluster HA for BroadVision One-To-One Enterprise". Otherwise, use the following procedure to install the SUNWscbv package.
You need the Sun Cluster 3.0 Agents 12/01 CD-ROM to complete this procedure. Perform this procedure on all of the cluster nodes that run Sun Cluster HA for BroadVision One-To-One Enterprise.
Load the Sun Cluster 3.0 Agents 12/01 CD-ROM into the CD-ROM drive.
Run the scinstall utility with no options.
This step starts the scinstall utility in interactive mode.
Choose the menu option, Add Support for New Data Service to This Cluster Node.
The scinstall utility prompts you for additional information.
Provide the path to the Sun Cluster 3.0 Agents 12/01 CD-ROM.
The utility refers to the CD as the "data services cd."
Specify the data service to install.
The scinstall utility lists the data service that you selected and asks you to confirm your choice.
Exit the scinstall utility.
Unload the CD from the drive.
When you finish the Sun Cluster HA for BroadVision One-To-One Enterprise package installation, go to "How to Register and Configure Sun Cluster HA for BroadVision One-To-One Enterprise".
Use the procedures in this section to perform the following tasks.
Register and configure Sun Cluster HA for BroadVision One-To-One Enterprise.
Verify the Sun Cluster HA for BroadVision One-To-One Enterprise installation.
To register and configure Sun Cluster HA for BroadVision One-To-One Enterprise, perform the following steps.
Before you start Sun Cluster HA for BroadVision One-To-One Enterprise, check that your database is accessible.
Shut down all of the BroadVision One-To-One Enterprise servers, including the root host, back-end, and Interaction Manager servers.
Perform this step after you test the BroadVision One-To-One Enterprise installation.
Run the ps(1) command to check that all of the BroadVision One-To-One Enterprise processes and the orbix daemon (orbixd) are stopped on all of the cluster nodes.
Become superuser on one cluster node.
Run the scrgadm command to register the resource type for Sun Cluster HA for BroadVision One-To-One Enterprise.
# scrgadm -a -t SUNW.bv |
Adds the resource type for the data service.
Specifies the resource type name that is predefined for your data service.
Run the scrgadm command to create the root host, back-end, and Interaction Manager resources.
Create root host and back-end resources in the failover resource groups that you created in Step 2 of "How to Configure and Verify the BroadVision One-To-One Enterprise, Database, and HTTP Server Installation".
The bvuser and BV1TO1_VAR should be the same for all of the resources.
# scrgadm -a -j root-host-resource -g root-host-resource-group -t SUNW.bv -x BVUSER=bvuser -x BV1TO1_VAR=path-to-bv1to1_var-directory # scrgadm -a -j back-end-resource-1 -g back-end-resource-group-1 -t SUNW.bv -x BVUSER=bvuser -x BV1TO1_VAR=path-to-bv1to1_var-directory # scrgadm -a -j back-end-resource-2 -g back-end-resource-group-2 -t SUNW.bv -x BVUSER=bvuser -x BV1TO1_VAR=path-to-bv1to1_var-directory ... # scrgadm -a -j back-end-resource-n -g back-end-resource-group-n -t SUNW.bv -x BVUSER=bvuser -x BV1TO1_VAR=path-to-bv1to1_var-directory |
Specifies the name of the root host resource.
Specifies your BroadVision username.
Specifies the path to the $BV1TO1_VAR directory.
Specifies the name of the back-end resource.
Create the Interaction Manager resource in the scalable resource group.
The bvuser and BV1TO1_VAR should be the same for all of the resources.
# scrgadm -a -j im-resource -g im-resource-group -t SUNW.bv -x BVUSER=bvuser / -x BV1TO1_VAR=path-to-bv1to1_var-directory |
Specifies the name of the Interaction Manager resource.
Run the scswitch command to enable and bring online the resource groups that now include the BroadVision One-To-One Enterprise resources.
# scswitch -Z -g root-host-resource-group # scswitch -Z -g back-end-resource-group-1 # scswitch -Z -g back-end-resource-group-2 ... # scswitch -Z -g back-end-resource-group-n # scswitch -Z -g im-resource-group |
Perform the following steps to verify the Sun Cluster HA for BroadVision One-To-One Enterprise installation.
From a web browser, log in to an application that you have configured with the BroadVision One-To-One Enterprise software.
Log in to the node that hosts the root host resource group.
Become the BroadVision user.
Shut down the root host processes.
Set the BV_LOCAL_HOST environment variable as root-host-logical-hostname.
Source the bv1to1.conf.sh file or the bv1to1.conf.csh file, depending on the shell that you use.
Run the following BroadVision command.
# bvconf shutdown -local |
The Sun Cluster HA for BroadVision One-To-One Enterprise fault monitors will restart the root host.
Ensure that your web browser connection to BroadVision One-To-One Enterprise is still active.
Run the scswitch command to switch the root host resource group to another cluster node, such as node2.
# scswitch -z -g root-host-resource-group -h node2 |
Ensure that your web browser connection to BroadVision One-To-One Enterprise is still active.
Repeat Step 2 through Step 7 for each back-end resource group.
You have completed your Sun Cluster HA for BroadVision One-To-One Enterprise installation and configuration. See the following sections for supplemental information.
"Sun Cluster HA for BroadVision One-To-One Enterprise Extension Properties"
"Sun Cluster HA for BroadVision One-To-One Enterprise Fault Monitor"
"Example One - Installation and Configuration" and "Example Two - Administration Commands" show how to install, configure, and administer Sun Cluster HA for BroadVision One-To-One Enterprise. The following tables list cluster information and BroadVision configuration information. This information applies to both of the examples.
Table 11-4 Examples - Cluster Information
Node names |
phys-schost-1, phys-schost-2 |
Logical hostnames |
schost-1, schost-2 |
Resource groups |
root-host-resource-group (for root host resources), back-end-resource-group (for back-end resources), im-resource-group (for Interaction Manager resources) |
Resources |
root-host-resource (the BroadVision root host resource), back-end-resource (the BroadVision back-end resource), im-resource (BroadVision Interaction Manager resource) |
Table 11-5 Examples - BroadVision Configuration Information
BV User |
BVUSER (on all of the cluster nodes) |
BV1TO1_VAR directory |
/global/broadvision/bvuser/bv1to1_var |
Root host |
schost-1 |
Back-end host |
schost-2 |
Interaction Manager 1 |
phys-schost-1 |
Interaction Manager 2 |
phys-schost-2 |
This example illustrates how to install and configure the data service.
(Register the BroadVision resource type.) phys-schost-1:> scrgadm -a -t SUNW.bv (Create failover resource groups for the back-end and root host processes.) phys-schost-1:> scrgadm -a -g root-host-resource-group phys-schost-1:> scrgadm -a -g back-end-resource-group (Create a scalable resource group for the Interaction Manager processes.) phys-schost-1:> scrgadm -a -g im-resource-group -y Maximum_primaries=2 / -y Desired_primaries=2 (Add logical hostnames to the failover resource groups.) phys-schost-1:> scrgadm -a -L -g root-host-resource-group -l schost-1 phys-schost-1:> scrgadm -a -L -g back-end-resource-group -l schost-2 (Create root host, back-end, and Interaction Manager resources.) phys-schost-1:> scrgadm -a -j root-host-resource -g root-host-resource-group / -t SUNW.bv -x BVUSER=bvuser -x BV1TO1_VAR=/global/broadvision/bvuser/bt1to1_var phys-schost-1:> scrgadm -a -j back-end-resource -g back-end-resource-group / -t SUNW.bv -x BVUSER=bvuser -x BV1TO1_VAR=/global/broadvision/bvuser/bt1to1_var phys-schost-1:> scrgadm -a -j im-resource -g im-resource-group -t SUNW.bv / -x BVUSER=bvuser -x BV1TO1_VAR=/global/broadvision/bvuser/bt1to1_var (Bring all of the resource groups online.) phys-schost-1:> scswitch -Z -g root-host-resource-group phys-schost-1:> scswitch -Z -g back-end-resource-group phys-schost-1:> scswitch -Z -g im-resource-group |
This example lists some common administration commands that you might wish to run.
(Check the status of the resource groups.) phys-schost-1:> scstat -g (Note: All of the BroadVision Interaction Manager 1, root host, and back-end processes should run on phys-schost-1. Interaction Manager 2 processes must run on phys-schost-2.) (Test failover. Switch the root-host-resource-group and the back-end-resource-group to another node.) phys-schost-1:> scswitch -z -g root-host-resource-group -h phys-schost-2 phys-schost-1:> scswitch -z -g back-end-resource-group -h phys-schost-2 (Note: All of the BroadVision root host and back-end processes should now run on phys-schost-2.) (Because the Maximum and Desired primaries are set to 2, the Interaction Manager runs on the two cluster nodes. Shut down Interaction Manager 2, which runs on phys-schost-2.) phys-schost-1:> scswitch -z -g im-resource-group -h phys-schost-1 (Shut down all of the resource groups.) phys-schost-1:> scswitch -F -g root-host-resource-group phys-schost-1:> scswitch -F -g back-end-resource-group phys-schost-1:> scswitch -F -g im-resource-group (Remove and disable all of the BroadVision resources and resource groups.) phys-schost-1:> scswitch -n -j root-host-resource phys-schost-1:> scswitch -n -j back-end-resource phys-schost-1:> scswitch -n -j im-resource phys-schost-1:> scswitch -n -j schost-1 phys-schost-1:> scswitch -n -j schost-2 phys-schost-1:> scrgadm -r -j root-host-resource phys-schost-1:> scrgadm -r -j back-end-resource phys-schost-1:> scrgadm -r -j im-resource phys-schost-1:> scrgadm -r -j schost-1 phys-schost-1:> scrgadm -r -j schost-2 phys-schost-1:> scrgadm -r -j root-host-resource-group phys-schost-1:> scrgadm -r -j back-end-resource-group phys-schost-1:> scrgadm -r -j im-resource-group (Remove the resource type.) phys-schost-1:> scrgadm -r -t SUNW.bv |
Depending on the flexibility and granularity of administration that you require for each back-end resource, you can set up only one failover resource group to use n logical hostnames and to contain all of the back-end and root host resources.
See "Alternative Configuration: Cluster With One Resource Group for the BroadVision One-To-One Back-End and Root Host Servers" for an illustration of this alternative configuration.
To set up this alternative configuration, perform the following procedures.
With these procedures, you set up two resource groups. One failover resource group contains root host and back-end resources. One scalable resource group contains the Interaction Manager resource. Throughout the alternative configuration procedures, the failover resource group that contains root host and back-end resources is denoted as failover-resource-group.
Perform this procedure to test starting and stopping the back-end processes on all of the nodes on which the back-end host and root host can run in a failover configuration. Additionally, perform this procedure to test the BroadVision One-To-One Enterprise Interaction Managers that you configured in the cluster.
Create a failover resource group to contain the BroadVision One-To-One Enterprise back-end and root host resources.
# scrgadm -a -g failover-resource-group [-h nodelist] |
Specifies the name of the resource group that contains the back-end and root host logical hostnames and resources. The name of the failover resource group can be your choice but must be unique for resource groups within the cluster.
Specifies an optional, comma-separated list of physical node names or IDs that identify potential masters. The order here determines the order in which the Resource Group Manager (RGM) considers primary nodes during failover.
Verify that you have added all of the logical hostnames that you use to your name service database.
Additionally, add all of the logical hostnames that you use to the /etc/inet/hosts file on each cluster node. Therefore, if the name service goes down, the nodes can still find the name-to-address mapping on their local hosts file.
Run the scrgadm(1M) command to add the logical hostnames that the failover resource group will use.
# scrgadm -a -L -g failover-resource-group -l root-host-logical-hostname-1 [-n netiflist] # scrgadm -a -L -g failover-resource-group -l back-end-logical-hostname-1 [-n netiflist] # scrgadm -a -L -g failover-resource-group -l back-end-logical-hostname-2 [-n netiflist] ... # scrgadm -a -L -g failover-resource-group -l back-end-logical-hostname-n [-n netiflist] |
Specifies the logical hostname that the root host resource uses.
Specifies the logical hostname that each back-end resource uses.
Specifies an optional, comma-separated list that identifies the NAFO groups that are on each node. The netiflist must represent all of the nodes in the resource group's nodelist. If you do not specify this option, the scrgadm command attempts to discover a network adapter on the subnet that the hostname list identifies for each nodelist node.
Create a scalable resource group for the Interaction Managers.
# scrgadm -a -g im-resource-group -y Maximum_primaries=n -y Desired_primaries=n |
Specifies the name of the scalable resource group that contains the Interaction Managers. This name can be your choice but must be unique for resource groups within the cluster.
Specifies the maximum number of active primary nodes allowed for this resource group. If you do not assign a value to this property, the default is 1.
Specifies the desired number of active primary nodes allowed for this resource group. If you do not assign a value to this property, the default is 1.
From one cluster node, run the scswitch(1M) command to move the failover resource group into the managed state and bring it online.
# scswitch -Z -g failover-resource-group |
You do not need to bring the scalable resource group online because the scalable resource group does not yet contain resources. You must bring the failover resource group online because the BroadVision One-To-One Enterprise back-end processes cannot start if the logical hostname resource is unavailable.
Check that the database is accessible.
See your database documentation for details.
Ensure that you have configured the database to enable BroadVision One-To-One back-end servers to access the database from any cluster node.
See your database documentation for details.
As the BroadVision user, log in to the cluster node that hosts the failover resource group.
Follow the steps in the BroadVision One-To-One Enterprise Installation and Administration Guide to run the following BroadVision commands.
Set the BV_LOCAL_HOST environment variable as root-host-logical-hostname.
Source the bv1to1.conf.sh file or the bv1to1.conf.csh file, depending on the shell that you use.
Run the bvconf bootstrap command on the root host to initialize the BroadVision One-To-One Enterprise installation.
Do not run the bvconf command as superuser.
% bvconf bootstrap -r root-host-logical-hostname |
Set the BV_LOCAL_HOST environment variable as back-end-logical-hostname or im-hostname.
Source the bv1to1.conf.sh file or the bv1to1.conf.csh file, depending on the shell that you use.
For each back-end host and Interaction Manager host, run the bvconf execute command to configure and start the BroadVision One-To-One Enterprise installation.
% bvconf execute -local -var shared -r root-host-logical-hostname |
Run the BroadVision command bvconf gateway to generate gateway configuration files for the HTTP gateway applications.
This command generates the files and writes them to the $BV1TO1_VAR/etc/appName.cfg file.
% bvconf gateway -A appName |
Specifies the gateway application name, which is defined in the $BV1TO1_VAR/etc/bv1to1.conf configuration file. See the BroadVision One-To-One Enterprise Installation and Administration Guide for details.
Copy the gateway application configuration file to the /etc/opt/BVSNsmgr directory on each of the cluster nodes that runs HTTP instances.
Ensure that you copy the gateway application configuration file with the extension .cfg.
See the BroadVision One-To-One Enterprise Installation and Administration Guide for details.
Configure and start the HTTP servers.
See your HTTP server documentation for details. Additionally, see the BroadVision One-To-One Enterprise Installation and Administration Guide for information on HTTP server configuration.
From a BroadVision client, connect to the BroadVision site, and check the installation.
If the BroadVision One-To-One Enterprise software is functioning correctly, perform the following steps to shut down the Interaction Managers, back-end processes, and root host processes.
Run the scswitch command to switch the failover resource group to another cluster node, such as node2.
# scswitch -z -g failover-resource-group -h node2 |
Restart the BroadVision One-To-One Enterprise software.
Connect to the cluster from a BroadVision client, and check that the BroadVision One-To-One Enterprise software functions correctly.
Repeat Step 15 through Step 18 on all of the potential primaries of the BroadVision One-To-One Enterprise resource groups.
You need the Sun Cluster 3.0 Agents 12/01 CD-ROM to complete this procedure. Perform this procedure on all of the cluster nodes that run Sun Cluster HA for BroadVision One-To-One Enterprise.
Load the Sun Cluster 3.0 Agents 12/01 CD-ROM into the CD-ROM drive.
Run the scinstall utility with no options.
This step starts the scinstall utility in interactive mode.
Choose the menu option, Add Support for New Data Service to This Cluster Node.
The scinstall utility prompts you for additional information.
Provide the path to the Sun Cluster 3.0 Agents 12/01 CD-ROM.
The utility refers to the CD as the "data services cd."
Specify the data service to install.
The scinstall utility lists the data service that you selected and asks you to confirm your choice.
Exit the scinstall utility.
Unload the CD from the drive.
To register and configure Sun Cluster HA for BroadVision One-To-One Enterprise, perform the following steps.
Before you start Sun Cluster HA for BroadVision One-To-One Enterprise, check that your database is accessible.
Shut down all of the BroadVision One-To-One Enterprise servers, including the root host, back-end, and Interaction Manager servers.
Perform this step after you test the BroadVision One-To-One Enterprise installation.
Run the ps(1) command to check that all of the BroadVision One-To-One Enterprise processes and the orbix daemon (orbixd) are stopped on all of the cluster nodes.
Become superuser on one cluster node.
Run the scrgadm command to register the resource type for Sun Cluster HA for BroadVision One-To-One Enterprise.
# scrgadm -a -t SUNW.bv |
Adds the resource type for the data service.
Specifies the resource-type name that is predefined for your data service.
Run the scrgadm command to create the root host, back-end, and Interaction Manager resources.
Set the Network_resources_used property for each resource to point to the proper logical hostname.
If you created two or more back-end resources in one resource group, and you do not set the Network_resources_used property, the validate method will fail.
# scrgadm -a -j root-host-resource -g failover-resource-group -t SUNW.bv -y Network_resources_used=root-host-logical-hostname -x BVUSER=bvuser -x BV1TO1_VAR=path-to-bv1to1_var-directory # scrgadm -a -j back-end-resource-1 -g failover-resource-group -t SUNW.bv -y Network_resources_used=back-end-logical-hostname-1 -x BVUSER=bvuser -x BV1TO1_VAR=path-to-bv1to1_var-directory ... # scrgadm -a -j back-end-resource-n -g failover-resource-group -t SUNW.bv -y Network_resources_used=back-end-logical-hostname-n -x BVUSER=bvuser -x BV1TO1_VAR=path-to-bv1to1_var-directory |
Specifies the name of the root host resource.
Specifies your BroadVision username.
Specifies the path to the $BV1TO1_VAR directory.
Specifies the name of the back-end resource.
You should have created all of the logical hostnames that were defined in the Network_resource_used property in the failover resource group (see Step 3 of the procedure, "Alternative Configuration: How to Configure and Verify the BroadVision One-To-One Enterprise, Database, and HTTP Server Installation").
Create the Interaction Manager resource in the scalable resource group that you created in Step 4 of the procedure, "Alternative Configuration: How to Configure and Verify the BroadVision One-To-One Enterprise, Database, and HTTP Server Installation".
# scrgadm -a -j im-resource -g im-resource-group -t SUNW.bv -x BVUSER=bvuser -x BV1TO1_VAR=path-to-bv1to1_var-directory |
Specifies the name of the Interaction Manager resource.
Run the scswitch command to enable the resource group that now includes the BroadVision One-To-One back-end and root host resources.
# scswitch -Z -g failover-resource-group # scswitch -Z -g im-resource-group |
Perform the following steps to verify the Sun Cluster HA for BroadVision One-To-One Enterprise installation.
From a web browser, log in to an application that you have configured with the BroadVision One-To-One Enterprise software.
Log in to the node that hosts the failover resource group.
Become the BroadVision user.
Shut down the root host processes.
Set the BV_LOCAL_HOST environment variable as root-host-logical-hostname.
Source the bv1to1.conf.sh file or the bv1to1.conf.csh file, depending on the shell that you use.
Run the following BroadVision command.
# bvconf shutdown -local |
The Sun Cluster HA for BroadVision One-To-One Enterprise fault monitors will restart the root host.
Ensure that your web browser connection to BroadVision One-To-One Enterprise is still active.
Run the scswitch command to switch the failover resource group to another cluster node, such as node2.
# scswitch -z -g failover-resource-group -h node2 |
Ensure that your web browser connection to BroadVision One-To-One Enterprise is still active.
This section describes how to configure Sun Cluster HA for BroadVision One-To-One Enterprise extension properties. Typically, you use the command-line scrgadm -x parameter=value to configure the extension properties when you create the BroadVision One-To-One Enterprise resources.
See the r_properties(5) and the rg_properties(5) man pages for details on all of the Sun Cluster extension properties.
Table 11-6 describes the Sun Cluster HA for BroadVision One-To-One Enterprise extension properties that you can set for all of the BroadVision One-To-One Enterprise resources. You can update some extension properties dynamically. You can update others, however, only when you create the BroadVision One-To-One Enterprise resources. The Tunable entries in the following table indicate when you can update each property.
Table 11-6 Sun Cluster HA for BroadVision One-To-One Enterprise Extension Properties
Property Category |
Property Name |
Description |
---|---|---|
BroadVision One-To-One Enterprise configuration
|
BVUSER |
The BroadVision user UNIX ID. Replace bvuser with your preferred username.
Default: None Tunable: At creation |
BV1TO1_VAR |
The environment variable that is set as bvuser.
Default: None Tunable: At creation |
|
Probe
|
Monitor_retry_interval |
The time (in minutes) over which the Resource Group Manager (RGM) counts fault monitor failures. The number of times that the fault monitor fails can exceed the value that the extension property Monitor_retry_count specifies. If the number of failures exceeds the value of Monitor_retry_count within the time period that Monitor_retry_interval specifies, the Process Monitor Facility (PMF) does not restart the fault monitor.
Default: 2 Tunable: Any time |
Monitor_retry_count |
The number of PMF restarts that the Sun Cluster software allows for the fault monitor.
Default: 4 Tunable: Any time |
|
Probe_timeout |
The time-out value in seconds for the probes.
Default: 180 Tunable: Any time |
|
Daemons |
START_ORB_SERVERS |
Type Boolean. By default, the data service starts the orbix daemon and all of the BroadVision daemons in the resource. The orbix daemon starts the orbix servers whenever needed. If you want the data service to start the orbix servers, set this property to TRUE.
Default: FALSE Tunable: Any time |
The Sun Cluster HA for BroadVision One-To-One Enterprise fault monitor checks BroadVision One-To-One back-end and Interaction Manager process health. BroadVision One-To-One Enterprise process health impacts BroadVision One-To-One Enterprise resources' failure history, which in turn drives the fault monitor's actions. For each BroadVision One-To-One Enterprise resource, fault monitor actions include no action, restart, or failover.
For Interaction Manager resources, failover happens only when both of the following conditions are met.
The value of the desired primaries is less than the value of the maximum primaries.
One of the nodes is unavailable.
After failover, the fault monitor will not restart the resource on any cluster node if both of the following conditions occur.
The values of the maximum primaries and desired primaries of the Interaction Manager resource group are the same.
The fault monitor has completed restarting the Interaction Manager resource the number of times that the Retry_count property specifies.
The fault monitors for each BroadVision One-To-One Enterprise resource (root host, back-end host, and Interaction Manager host) monitor the following processes.
The orbix daemon (orbixd), which is common for all of the BroadVision One-To-One Enterprise resources - The probes use the ps(1) command to ensure that orbixd is functioning. If orbixd is not functioning, the probe considers the failure as complete, and the Resource Group Manager (RGM) restarts the orbix daemon.
The orbix daemon is started with the checkpoint feature. Therefore, the BroadVision One-To-One Enterprise servers, which the previous instance of orbixd started, continue to run with the new instance of orbixd.
The BroadVision One-To-One Enterprise daemons that you have configured in the resource - If orbixd is healthy, the probe uses the BroadVision command bvconf ps to ensure that the BroadVision One-To-One Enterprise daemons are functioning. If BroadVision One-To-One Enterprise daemons are not functioning, the RGM restarts the resource, which restarts all of the configured daemons.
The following issues and behaviors can occur with Sun Cluster HA for BroadVision One-To-One Enterprise.
Error creating a user when the One-To-One database fails and restarts - If the database fails when all of the BroadVision One-To-One Enterprise resources are running, you can create a new user after the database comes back online. However, only the third attempt at creating the new user will succeed. Contact BroadVision support for more information on this bug.
The One-To-One database fails and the back-end hosts fail over - If the database fails and the back-end hosts fail over before the database comes back online, the BroadVision One-To-One Enterprise resources cannot come online on any cluster node. When you successfully restart the database, start the BroadVision One-To-One Enterprise resources again.
The hosts in the startup order are offline - BroadVision One-To-One Enterprise resources must be started in a particular order. The BroadVision command bvconf bootstrap lists this order. If both of the following conditions occur, the BroadVision One-To-One Enterprise processes that are configured on the hostname in the resource group will not start.
Any of the resources in the startup order are offline.
You start a BroadVision One-To-One Enterprise resource that is listed after the offline resources in the startup order.
If both of these conditions occur, the resource group will come online, but the processes will not start. The probe will wait for the resource group in the startup order to come online before the probe starts the BroadVision One-To-One processes for this resource.
The One-To-One Command Center connection - To connect the Command Center to BroadVision One-To-One Enterprise servers that are configured on a cluster, try one of the following options.
Force the Dynamic Control Center (DCC) to use POOP instead of IIOP. To do so, set the value of the My Computer/HKEY_CURRENT_USER/Software/BroadVision/Dynamic Control Center/4.2/Options/Use IIOP Windows registry entry to 0.
Set the IT_LOCAL_ADDR_LIST property to include the IP addresses of all of the cluster nodes and logical hostnames that will run the orbix daemon. The following list identifies sample IP addresses to add to the bv1to1.conf file.
10.10.102.225
10.10.102.226
10.10.102.222
10.10.102.223
In this example, add the following line to the bv1to1.conf file, under the global export section, before the IT_DAEMON_PORT property.
IT_LOCAL_ADDR_LIST = "127.0.0.1" + "10.10.102.222" + "10.10.102.223" + "10.10.102.225" + "10.10.102.226" ; |
DCC cannot recover from failover. Contact BroadVision support for more information.
Server-port conflict - By default, the orbix daemon chooses an available port number that the IT_DAEMON_SERVER_BASE and IT_DAEMON_SERVER_RANGE properties specify for use by a server that the daemon launches. When a client attempts to connect to a server for the first time, the client asks the orbix daemon for the port number. Then the client connects to the port that the orbix daemon specifies. If failover occurs after the client asks the orbix daemon for the port number but before the client connects to that port, the client might connect to the wrong server. To protect from a server-port conflict, try one of the following options.
Configure the IT_LOCAL_SERVER_BASE property for each host so that ports that the orbix daemon assigns on different nodes will never overlap. For example, if you configure BroadVision One-To-One Enterprise servers and the Interaction Manager to run on cluster nodes A, B, and C, the bv1to1.conf file will have the following entries.
export ... IT_DAEMON_SERVER_RANGE = "200"; ... site bv { ... node A { export IT_LOCAL_SERVER_BASE = "1300"; ... } node B { export IT_LOCAL_SERVER_BASE = "1500"; # 1300 + 200 ... } node C { export IT_LOCAL_SERVER_BASE = "1700"; # 1500 + 200 ... } ... } |
Add the iiop_port parameter to each process entry in the bv1to1.conf file, and ensure that no two server-port entries conflict. The iiop_port is an undocumented parameter of the BroadVision One-To-One Enterprise server that specifies which port a server should use. For example, the following process entry defines the cntdb server on port 1305.
process cntdb { parameter iiop_port = "1305"; } |
C++ CORBA servers support the iiop_port parameter. For Java servers, you must upgrade to BroadVision One-To-One Enterprise 6.0AB or later versions.
The BroadVision and Oracle resource groups fail over at the same time - If you use Oracle, and the BroadVision One-To-One Enterprise backend resource groups and the Oracle resource group fail over at the same time, some BroadVision daemons might fail to restart. These daemons will fail to restart while the Oracle database is restarting. The BroadVision One-To-One Enterprise resource will attempt to restart the failed daemons until it succeeds.