Transparent scaling and workload balancing strategies

HCL OneDB™ servers scale easily and they dynamically balance workloads to ensure optimal use of resources.

HCL OneDB can address these objectives:

Periodically increase capacity

If your business environment experiences peak periods, you might be required to periodically increase capacity. You can increase capacity by adding a remote stand-alone secondary server. That type of secondary server maintains a complete copy of the data, with updates transmitted asynchronously from the primary server over secure network connections. If the amount of data is large and making multiple copies of it is difficult, use shared-disk secondary servers instead of remote stand-alone secondary servers. You can use high-availability data replication (HDR) secondary servers if you want to increase capacity only for reporting (read-only) workloads.

Table 1. Scalability with shared-disk secondary servers
Advantages Potential disadvantages
  • High availability. This secondary server shares disks with the primary server.
  • No failover. The secondary server might be configured to run on the same computer hardware as the primary server.
  • No data redundancy. This secondary server does not maintain a copy of the data. (Use SAN devices for disk storage.)
  • The primary and secondary servers require the same hardware, operating system, and version of the database server product.
Use an SD secondary server for these reasons:
  • Increased reporting capacity

    Multiple secondary servers can offload reporting function without affecting the primary server.

  • Server failure backup

    If a failure of the primary server, an SD secondary can be promoted quickly and easily to a primary server. For example, if you are using SAN (storage area network) devices that provide ample and reliable disk storage but you are concerned with server failure, SD secondary servers can provide a reliable backup.

Table 2. Scalability with remote stand-alone secondary servers
Advantages Potential disadvantages
  • Data redundancy. This secondary server maintains a copy of the data.
  • Failover. The secondary server can be geographically remote from the primary server, such as in another building, another town, or another country.
  • No requirement to change applications. Client connections to primary or secondary server can be automatically switched in the event of server failure.
  • The primary and secondary servers require the same hardware, operating system, and version of the database server product.

Geographically disperse processing and increase capacity

Businesses with offices in various locations might want to use local servers for processing local requests instead of relying on a single, centralized server. In that case, you can set up a network of Enterprise Replication servers. Remote database server outages are tolerated. If database server or network failure occurs, the local database server continues to service local users. The local database server stores replicated transactions in persistent storage until the remote server becomes available. Enterprise Replication on the local server captures transactions to be replicated by reading the logical log, storing the transactions, and reliably transmitting each transaction as replication data to the target servers.

You can also use Enterprise Replication to set up a shard cluster, where your data is horizontally partitioned (sharded) across multiple servers. As your capacity requirements grow, you can add additional database servers to the shard cluster, increasing your overall capacity.

Table 3. Scalability with Enterprise Replication
Advantages Potential disadvantages
  • The servers can be in another building, another town, or another country.
  • The servers can be on different hardware.
  • The servers can run on different operating systems.
  • The servers can run different versions of the database server product.
  • A subset of the data can be replicated (asynchronous, log-based replication).
  • It is possible to add shared-disk secondary servers to assist the replication servers, using multiple Connection Managers for automatic client redirection.
  • You can add additional shard servers to an established shard cluster as your capacity needs increase.
  • Conflicts are possible.
  • Transaction failures are possible. If one occurs, you must repair inconsistent data.
Use an RS secondary server in your environment for the following reasons:
  • Increased server availability

    One or more RS secondary servers provide added assurance by maintaining multiple servers that can be used to increase availability.

  • Geographically distant backup support

    It is often desirable to have a secondary server located at some distance from the site for worst-case disaster recovery scenarios. An RS secondary server is an ideal remote backup solution. The high level of coordination between a primary and secondary HDR pair can cause performance issues if the secondary server is located on a WAN (Wide-Area Network). Keeping the primary and secondary servers relatively close together eases maintenance and minimizes the affect on performance.

  • Improved reporting performance

    Multiple secondary servers can offload reporting function without affecting the primary server. Also, an RS secondary server configuration makes it easier to isolate reporting requirements from the HA requirements, resulting in better solutions for both environments.

  • Availability over unstable networks

    A slow or unstable network environment can cause delays on both the primary and secondary server if checkpoints are achieved synchronously. RS secondary server configurations use fully duplexed networking and require no such coordination. An RS secondary server is an attractive solution if network performance between the primary server and RS secondary server is less than optimal.

Balance workload to optimize resource use

You can configure workload balancing when you create or modify a service level agreement SLA. HCL OneDB gathers information from each server in a cluster and automatically connects the client application to the server that has the least amount of activity.

You can create groups within a cluster that are specific to certain types of applications, such as those for online transaction processing (OLTP) or (warehouse). Applications can choose to connect to the specific group for optimized performance of each type of query.