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.
Based on the load on the application server instances, the load on the HADB, and failover requirements, you can determine:
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).
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.
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.
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.
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.
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
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.