Overview of High Availability Database

This section introduces the high availability database (HADB) and describes how to set up and configure HADB for use with the Application Server.

This section contains the following topics:

• HADB and Application Server

• HADB Server Architecture

• HADB Nodes

HADB and Application Server

HADB is a horizontally-scalable database that can be run and managed independently of the application server tier. It is designed to support up to 99.999% service and data availability with load balancing, failover, and state recovery capabilities.

Application Server uses HADB to store HTTP and stateful session bean (SFSB) session data. Without a session persistence mechanism, the HTTP or SFSB session state data is lost when a web or EJB container fails over.

Keeping state management separate from Application Server has significant benefits. Application Server instances spend their cycles performing as a scalable and high performance Java™ 2 Platform, Enterprise Edition (J2EE™ platform) containers delegating state replication to an external high availability state service. Due to this loosely coupled architecture, you can easily add application server instances to and remove instances from a cluster. You can independently scale HADB state replication service for optimum availability and performance.

HADB Server Architecture

High availability means availability despite planned outages for upgrades or unplanned outages caused by hardware or software failures. HADB is based on a simple data model and redundant, scalable, and high performance technology. HADB offers an ideal platform for delivering all types of session state persistence within a high performance enterprise application server environment.

The following figure shows the architecture of a database with four active nodes and two spare nodes. Nodes 0 and 1 are a mirror node pair, as are nodes 2 and 3.

Figure 2–1 HADB Architecture

HADB achieves high data availability through fragmentation and replication of data. All tables in the database are partitioned to create subsets of approximately the same size called fragments. Fragmentation is based on a hash function that evenly distributes the data among the nodes of the database. Each fragment is stored twice in the database, in mirror nodes. This ensures fault tolerance and fast recovery of data. In addition, if a node fails, or is shut down, a spare node can take over until the node is active again.

HADB nodes are organized into two Data Redundancy Units (DRUs), which mirror each other. Each DRU consists of half of the active and spare nodes, and contains one complete copy of the data. To ensure fault tolerance, the computers that support one DRU must be completely self-supported with respect to power (use of uninterruptible power supplies is recommended), processing units, and storage. If a power failure occurs in one DRU, the nodes in the other DRU can continue servicing requests until the power returns.

Without a session persistence mechanism, the HTTP or SFSB session state, including the passivated session state, is lost when one web or EJB container fails over to another. Use of the HADB for session persistence overcomes this situation. The HADB stores and retrieves state information in a separate but well-integrated persistent storage tier.

HADB reclaims space when session data is deleted. HADB places session data records in fixed size blocks. When all records of a block are deleted, the block is freed. Records of a block can be deleted randomly, creating holes in the block. When a new record is inserted into a block and contiguous space is needed, the holes are removed and thus the block is compacted.

This is a brief summary of the architecture. For more information, see Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Deployment Planning Guide.

HADB Nodes

A database node consists of a set of processes, a dedicated area of shared memory, and one or more secondary storage devices. The database stores, updates, and retrieves session data. Each node has a mirror node, therefore nodes occur in pairs. In addition, to maximize availability, include two or more spare nodes, one in each DRU, so if a node fails a spare can take over while the node is repaired.

For an explanation of node topology alternatives, see Chapter 3, Selecting a Topology, in Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Deployment Planning Guide.

New Features and Improvements

The version of HADB provided with Sun Java System Application Server Enterprise Edition 8.1 has many new features and improvements.

HADB management is improved by changing the underlying components of the management system. The old hadbm interface functions are maintained with minor modifications. These changes also remove the dependency on SSH/RSH.

The management agent server process (ma) constitutes a domain and keeps the database configuration in a repository. The repository information is distributed among all agents.

The following topics provide more details:

• General Improvements

• Specific Changes

General Improvements

This version of HADB has the following general improvements:

• HADB no longer requires SSH/RSH.

• Administrator password for HADB management enhances security.

• Automatic online upgrade to future versions.

• Dependency on a single host is removed.

• Heterogeneous configurations of the database is supported. The device paths and history paths can be set individually.

• Ability to manage multiple platforms uniformly.

Specific Changes

This version of HADB includes the following changes from the previous version.

• UDP multicast is now required for network configuration.

• The management agent, ma, is now required to be running on all HADB hosts.

• New hadbm commands for domain management: hadbm createdomain, hadbm deletedomain, hadbm extenddomain, hadbm reducedomain, hadbm listdomain, hadbm disablehost. New commands for package management: hadbm registerpackage, hadbm unregisterpackage, hadbm listpackage

• All hadbm commands have the following new options:

  • adminpassword

  • adminpasswordfile

  • no-adminauthentication

  • agent

  • javahome

  Changes made to hadbm create:

  • New options:

    • no-clear

    • no-cleanup

    • package

    • packagepath

    • agent

    Extended options

    • hosts (registers hosts in the domain).

    • set

    Options removed:

    • inetd

    • inetdsetupdir

    • configpath

    • installpath

    • set TotalDataDevideSizePerNode

    • set managementProtocol

    Modified: devicesize is now optional, not required.

  The hadbm startnode and hadbm restartnode commands' startlevel option has a new value, clear .

  Changes made to hadbm addnodes: New options: set, historypath, devicepath. The inetdsetupdir option was removed.

  Changes made to hadbm get and hadbm set: New attributes are historypath (heterogeneous path for history files) and packagename. Attributes eliminated are: managementProtocol, TotalDeviceSizePerNode, installpath, and syslogging.

Using Customer Support for HADB

Before calling customer support about HADB issues, gather as much of the following information as possible:

• System use profile:

  • Number of active concurrent users

  • Number of passive users

  • Number of users entering the system per second

  • Average session size

  • Session state timeout period (SessionTimeout value)

  • Transaction rate per user per second

  Machine properties:

  • RAM

  • Number of CPUs

  • CPU speed

  • Operating system version

  • Number of physical disks

  • Total disk size

  • Available disk space

  • Data transfer capacity

  Network properties:

  • Transfer capacity

  • Number of host names (network interfaces) per node

  HADB data:

  • History files

  • cfg and meta files, located in dbconfigpath/databasename /nodeno directory. dbconfigpath is defined in the variable ma.server.dbconfigpath in the management agent configuration file.

  • Version information (hadbm --version)