Application transparency

Getting started with the IBM Db2 pureScale Feature is quick and simple: Applications do not have to be aware of the topology of your database environment when you deploy the feature. This means that applications work just as they did before, yet they can benefit from the extreme capacity and continuous availability from the moment that you start your Db2 pureScale instance for the first time.

Increasing capacity

Capacity planning with the Db2 pureScale Feature is simple. You can start small and add members to your database environment as your needs grow, scaling out from the most basic highly available configuration all the way to the maximum supported configuration, which provides extreme processing capacity. Scaling is near linear in efficiency and highly predictable.

When you scale out, no application changes or repartitioning of your data is required. No performance tuning is required to scale efficiently. If you need more capacity, you simply add more members.

Maintaining availability

Maintaining database availability means both compliance with service level agreements (SLAs) and high tolerance to component failures. To maximize hardware utilization rates and help keep response times consistent for your applications, incoming database requests are automatically load balanced across all active members in your Db2 pureScale instance. To minimize the impact of component failures, the automated restart and recovery process of the Db2 pureScale Feature runs quickly and without affecting most database requests. Only those database requests that were being processed by a failed member must be resubmitted by the originating application; the resubmitted requests are then processed by the next available member.

In the example in the following diagram, several events take place in short succession. Multiple component failures require automated, internal recovery, and a scale-out operation increases the capacity of the Db2 pureScale instance. None of these events requires any application awareness. The box containing the components of the Db2 pureScale Feature is shaded to indicate application transparency.
Figure 1. A Db2 pureScale environment encountering multiple component failures and being scaled out. Applications connecting to the database need not be aware of these events.
An image showing a Db2 pureScale instance where multiple components have failed but a new component is being added to scale out.

Planning made simple

The ability to easily add and remove resources helps you to manage challenges such as the following ones:

  • Cyclical workloads. If some of your workloads are cyclical (for example, seasonal), you can add resources before they are required, and then move the extra capacity somewhere else later on.
  • Sudden increases in workloads. An SLA might dictate minimum response times for completing database requests. If you discover sudden workload surges from some applications that are threatening response times, you can help meet your SLA by quickly moving additional members to the database that is experiencing the peak demand.
  • Maintenance-related slowdowns. To help negate the effect of system maintenance on the overall throughput of your Db2 pureScale environment, you can add a member to your environment before commencing maintenance on an existing member. After you complete the system maintenance and the original member rejoins the instance, you can remove the additional resource or perform maintenance on other members.