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:

If the system is designed to handle peak load, it can sustain
the expected maximum load of users and requests without degrading response
time. This implies that the system can handle extreme cases of expected system
load. If the difference between peak load and steady state load is substantial,
designing for peak loads can mean spending money on resources that are often
idle.

If the system is designed to handle steady state load, it
does not have all the resources required to handle the expected peak load.
Thus, the system has a slower response time when peak load occurs.

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.

To determine the required number of HADB nodes

Determine the following parameters:

Maximum number of concurrent users, nusers.

Average BLOB size, s.

Maximum transaction rate per user, referred to as NTPS.

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

Use the following formula:

Vdata = nusers .s

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

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.

To calculate the number of hosts

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.

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.

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:

Space for temporary storage of log buffer. This space is four
times the log buffer size. The log buffer keeps track of operations related
to data. The default value of the log buffer size is 48 MB.

Space for internal administration purpose. This space is one
percent of the storage device size.

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

Condition

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.