Sun GlassFish Enterprise Server v2.1.1 Deployment Planning Guide

Design Decisions

Design decisions include whether you are designing the system for peak or steady-state load, and the number of machines in various roles and their sizes.

Designing for Peak or Steady State Load

In a typical deployment, there is a difference between steady state and peak workloads:

How often the system is expected to handle peak load will determine whether you want to design for peak load or for steady state.

If peak load occurs often—say, several times per day—it may be worthwhile to expand capacity to handle it. If the system operates at steady state 90 percent of the time, and at peak only 10 percent of the time, then it may be preferable to deploy a system designed around steady state load. This implies that the system’s response time will be slower only 10 percent of the time. Decide if the frequency or duration of time that the system operates at peak justifies the need to add resources to the system.

System Sizing

Based on the load on the application server instances, the load on the HADB, and failover requirements, you can determine:

Number of Application Server Instances

To determine the number of applications server instances (hosts) needed, evaluate your environment on the basis of the factors explained in Estimating Load on Application Server Instances to each application server instance, although each instance can use more than one Central Processing Unit (CPU).

Number of HADB Nodes

As a general guideline, plan to have one HADB node for each CPU in the system. For example, use two HADB nodes for a machine that has two CPUs.

Note –

If you have more than one HADB node per machine (for example, if you are using bigger machines), then you must ensure that there is enough redundancy and scalability on the machines; for example multiple uninterruptible power supplies and independent disk controllers.

Alternatively, use the following procedure.

ProcedureTo determine the required number of HADB nodes

  1. Determine the following parameters:

    • Maximum number of concurrent users, nusers.

    • Average BLOB size, s.

    • Maximum transaction rate per user, referred to as NTPS.

  2. Determine the size in Gigabytes of the maximum primary data volume, V data.

    Use the following formula:

    Vdata = nusers . s

  3. Determine the maximum HADB data transfer rate, R dt.

    This reflects the data volume shipped into HADB from the application side. Use the following formula:

    Rdt = nusers . s . NTPS

  4. Determine the number of nodes, N NODES,.

    Use the following formula:

    NNODES = Vdata /5GB

    Round this value up to an even number, since nodes work in pairs.

Number of HADB Hosts

Determine the number of HADB hosts based on data transfer requirements. This calculation assumes all hosts have similar hardware configurations and operating systems, and have the necessary resources to accommodate the nodes they run.

ProcedureTo calculate the number of hosts

  1. Determine the maximum host data transfer rate, R max..

    Determine this value empirically, because it depends on network and host hardware. Note this is different from the maximum HADB data transfer rate, R dt, determined in the previous section.

  2. Determine the number of hosts needed to accommodate this data

    Updating a volume of data V distributed over a number of hosts N HOSTS causes each host to receive approximately 4V/N HOSTS of data. Determine the number of hosts needed to accommodate this volume of data with the following formula:

    NHOSTS = 4 . Rdt / Rmax

    Round this value up to the nearest even number to get the same number of hosts for each DRU.

  3. Add one host on each DRU for spare nodes.

    If each of the other hosts run N data nodes, let this host run N spare nodes. This allows for single-machine failure taking down N data nodes.

    Each host needs to run at least one node, so if the number of nodes is less than the number of hosts (NNODES < NHOSTS), adjust NNODES to be equal to NHOSTS. If the number of nodes is greater than the number of hosts, (NNODES \> NHOSTS), several nodes can be run on the same host.

HADB Storage Capacity

The HADB provides near-linear scaling with the addition of more nodes until the network capacity is exceeded. Each node must be configured with storage devices on a dedicated disk or disks. All nodes must have equal space allocated on the storage devices. Make sure that the storage devices are allocated on local disks.

Suppose the expected size session data is x MB. HADB replicates data on mirror nodes, and therefore requires 2x MB of storage. Further, HADB uses indexes to enable fast access to data. The two nodes will require an additional 2x MB for indexes, for a total required storage capacity of 4x. Therefore, HADB’s expected storage capacity requirement is four times the expected data volume.

To account for future expansion without loss of data from HADB, you must provide additional storage capacity for online upgrades because you might want to refragment the data after adding new nodes. In this case, a similar amount (4x) of additional space on the data devices is required. Thus, the expected storage capacity is eight times the expected data volume.

Additionally, HADB uses disk space as follows:

The following table summarizes the HADB storage space requirements for a session data of x MB.

Table 2–3 HADB Storage Space Requirement for Session Size of X MB


HADB Storage Space Required 

Addition or removal of HADB nodes while online is not required.

4x MB + (4*log buffer size) + 1% of device size

Addition or removal of HADB nodes while online is required. 

8x MB + (4*log buffer size) + 1% of device size

If the HADB runs out of device space, it will not accept client requests to insert or update data. However, it will accept delete operations. If the HADB runs out of device space, it returns error codes 4593 or 4592 and writes corresponding error messages to the history files.