In general, you can install HADB on the same system as Application Server (co-located topology) or on separate hosts (separate tier topology). For more information on these two options, see Chapter 3, Selecting a Topology, in Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Deployment Planning Guide. However, you must install the HADB management client to be able to set up high availability with the asadmin ha-config-cluster command. When using the Java Enterprise System installer, you must install an entire HADB instance to install the management client, even if the nodes are to be installed on a separate tier.
On a single or dual CPU system, you can install both HADB and Application Server if the system has at least two Gbytes of memory. If not, install HADB on a separate system or use additional hardware. To use the asadmin ha-configure-cluster command , you must install both HADB and Application Server.
Each HADB node requires 512 Mbytes of memory, so a machine needs one Gbyte of memory to run two HADB nodes. If the machine has less memory, set up each node on a different machine. For example, you can install two nodes on:
Two single-CPU systems, each with 512 Mbytes to one Gbyte of memory
A single or dual CPU system with one Gbyte to two Gbytes of memory
You can install HADB with either the Java Enterprise System installer or the Application Server standalone installer. In either installer, choose the option to install HADB (called High Availability Session Store in Java ES) in the Component Selection page. Complete the installation on your hosts. If you are using the Application Server standalone installer, and choose two separate machines to run HADB, you must choose an identical installation directory on both machines.
Throughout this manual, HADB_install_dir represents the directory in which HADB is installed. The default installation directory depends on whether you install HADB as part of the Java Enterprise System. For Java Enterprise System, the default installation directory is /opt/SUNWhadb/4. For the standalone Application Server installer, it is /opt/SUNWappserver/hadb/4 .
The node supervisor processes (NSUP) ensure the availability of HADB by exchanging “I’m alive” messages with each other. The NSUP executable files must have root privileges so they can respond as quickly as possible. The clu_nsup_srv process does not consume significant CPU resources, has a small footprint, and so running it with real-time priority does not affect performance.
The Java Enterprise System installer automatically sets the NSUP privileges properly, so you do not need to take any further action. However, with the standalone Application Server (non-root) installer, you must set the privileges manually before creating a database.
If NSUP executables do not have the proper privileges, you might notice symptoms of resource starvation such as:
Performance issues or HIGH LOAD messages in the HADB history log.
False network partitioning and node restarts, preceded by a warning “Process blocked for x seconds” in HADB history files.
Aborted transactions and other exceptions.
If NSUP cannot set the real-time priority errno is set to EPERM on Solaris and Linux. On Windows it issues the warning “Could not set realtime priority”. The error is written to the ma.log file, and the process continues without real-time priority.
Setting real-time priorities is not possible when:
HADB is installed in Solaris 10 non-global zones
PRIV_PROC_LOCK_MEMORY (allow a process to lock pages in physical memory) and/or PRIV_PROC_PRIOCNTL privileges are revoked in Solaris 10
Users turn off setuid permission
Users install the software as tar files (the non-root installation option for the Application Server)
Log in as root.
Change your working directory to HADB_install_dir/lib/server.
The NSUP executable file is clu_nsup_srv .
Set the file’s suid bit with this command:
chown root clu_nsup_srv
Set the file’s ownership to root with this command:
chmod u+s clu_nsup_srv
This starts the clu_nsup_srv process as root, and enables the process to give itself realtime priority.
To avoid any security impact, the real-time priority is set immediately after the process is started and the process falls back to the effective UID once the priority has been changed. Other HADB processes run with normal priority.