Sun Java System Application Server Enterprise Edition 8.1 2005Q2 High Availability Administration Guide

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 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 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

This version of HADB has the following general improvements:

Specific Changes

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

Using Customer Support for HADB

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