Components of the Db2 pureScale Feature

Db2 members

When a Db2 client connects to a database, the connection is routed to a member, which then processes the request. The workload of members is balanced automatically by directing requests from Db2 clients to the member with the lowest workload. How individual requests are workload balanced depends on whether you use the less frequent connection-level workload balancing or the more frequent transaction-level workload balancing. All members read from and write to the same database on shared disk; the full set of data is shared among them. Each member runs its own db2sysc process and threads, and each member includes its own buffer pools, memory regions, and log files.

The recommended configuration is one member per host. A host can be either a computer or a logical partition (LPAR). To take advantage of the design for a continuously available environment and to help provide optimum performance, create a minimum of two Db2 members, each on its own computer. The Db2 pureScale Feature supports up to 128 members. In general, to ensure each that member is capable of handling the additional workload when one or more members are out of commission, the best practice is to have a homogeneous configuration (processors and memory) across all members. The exception is when an exclusive member subsetting is configured to handle a different type of workload. In that scenario, members within the same subset should have the same hardware specification, but members in different subsets may have different ones.

You should not use Db2 member hosts for any other purpose.

Cluster caching facility (CF )

The Db2 pureScale Feature includes a cluster caching facility, also known as the CF component in a Db2 pureScale environment. This facility is used to coordinate locking through a global lock manager to prevent conflicting access to the same table data by different members. The cluster caching facility is also used to keep page caching consistent across all members through a shared group buffer pool. The group buffer pool coordinates copies of pages that might exist across the (local) buffer pools of members.

The cluster caching facility also provides a shared communication area (SCA). Members can use this shared communication area to emulate cluster wide shared memory.

At least one cluster caching facility must be online for a database to be available while Db2 members are online. To take advantage of the design for a continuously available environment, use multiple cluster caching facilities. Duplexing of both metadata and database data to a secondary cluster caching facility ensures that while it is active, it remains in peer state with the primary CF. If the primary CF fails, a secondary one can take over to maintain database availability.

CFs can run on their own computers or they can share hosts with members by running on their own logical partitions (LPARs). You should not use the cluster caching facility hosts for anything other than the Db2 pureScale Feature. If you must run other software on the cluster caching facility hosts, additional manual tuning of your database configuration might be required.

Db2 cluster services

Db2 cluster services is software that provides automatic heartbeat failure detection and automatically initiates the necessary recovery operations after a failure is detected. It also provides the cluster file system that gives each host in a Db2 pureScale instance access to a common file system. Db2 cluster services includes technology from IBM Tivoli® System Automation for Multiplatforms (Tivoli SA MP) software, IBM Reliable Scalable Clustering Technology (RSCT) software, and IBM General Parallel File System (GPFS) software. This technology is packaged as an integral part of the Db2 pureScale Feature.

If a component in your Db2 pureScale environment fails to respond to the heartbeat detection protocol, Db2 cluster services alerts the members and cluster caching facilities, fences the failed component from shared storage (if necessary) and initiates a component restart. This restart process is designed to be automatic and does not require your intervention. While the recovery of the failed component is underway, the rest of the instance remains available and can continue to process incoming database requests. Applications that are connected to a member that fails will be automatically rerouted to other members, via automatic Db2 client reroute support.

The installation process of the Db2 pureScale Feature uses integrated the IBM General Parallel File System software to create the Db2 cluster file system on the shared disk.

Shared disk storage

• To store the database data itself.
• To store instance configuration and other database information, such as logs, metadata, log archives, and backups.
• To store problem determination information from members and cluster caching facilities, such as db2diag log files and first occurrence data capture (FODC) information.
• To assist Db2 cluster services in arbitrating which members and cluster caching facilities will remain operational in the event that a severe communication failure prevents one half of the hosts from communicating with the other half. This arbitration process prevents sets of hosts from processing database requests independent of each other. In the event of a severe communication failure where one set of hosts is unable to communicate with another, Db2 cluster services will automatically allow the larger set to remain operational. If the sets are equal, a tiebreaker shared disk is used to arbitrate which set remains operational.

Network connectivity

• A storage area network (SAN) for access to the shared disk, used by both members and cluster caching facilities. Db2 pureScale Feature takes advantage of certain value-add functions that are built into the AIX® operating system running on IBM Power Systems computers, such as Fiber Channel-based storage area network SCSI-3 Persistent Reserve support. This support allows for fast detection of failing members and fencing of those members from the shared disk, so that the consistency of the data is preserved and the member recovery time is reduced.
• A low latency, high-speed interconnect for communication between Db2 members and cluster caching facilities. The performance of this network is critical, because it is used to communicate locking and caching information across the cluster. All hosts in the instance must use the same type of interconnect, and the Db2 pureScale Feature requires the use of:
  • Remote Direct Memory Access (RDMA) protocol over InfiniBand (IB) network,
  • RDMA protocol over Converged Ethernet (RoCE) network, or
  • TCP/IP protocol over Ethernet (TCP/IP) network.
  InfiniBand is an industry standard communications link that provides quality-of-service and failover support, and is designed for scalability. The use of RDMA enables direct updates in member host memory without requiring member processor time. Starting in Db2 Cancun Release 10.5.0.4 and later fix packs, you can run Db2 pureScale Feature on a TCP/IP over an Ethernet network without requiring special RDMA capable adapters. However, unlike RDMA capable adapters, the TCP/IP adapters used on each member and CF must be bonded together.
• A corporate network that allows Db2 clients to connect with the Db2 pureScale instance, such as EtherChannel or Network Interface Backup technology. The Db2 pureScale Feature automatically routes connection requests to the member with the lowest workload. Alternatively, you can specify that Db2 clients are to connect to specific active members in the Db2 pureScale instance. After the first connection to a member is made, a list of available members with their IP addresses and current workloads is sent back to the Db2 client. The Db2 client can subsequently connect to any of these members by using the IP address.