One difference between IBM PureApplication System and IBM PureData System for Transactions

Looking into the hardware stack, we can realize that most hardware components are the same inside IBM PureApplication System and IBM PureData System for Transactions.

However, there is just one interesting difference with the network adapter in each of the computer nodes. Basically, computer nodes have a network adapter card that supports Remote Data Memory Access (RDMA) in IBM PureData System for Transactions.

02_01_rdma_card copy.jpg

So why do we need to use the network adapters?

The official name of the network adapter is a little bit long: IBM Flex System EN4132 2-port 10 Gb Ethernet Adapter with RoCE support. Some people in the field call it “Mellanox card” for short.

RoCE stands for “RDMA over Converged Ethernet,” and we can simply think of this as a kind of network adapter that supports RDMA. RDMA is an important technology for accessing memory between different systems without interrupting the CPU of another system that some applications need to handle memory information.
Even though PureApplication System has hundreds of system patterns including web application servers (WAS) and simple databases, and though PureData System is based on the architecture of PureApplication, PureData System for Transactions has just one database pattern called “DB2 pureScale,” and RDMA is the main necessary technology for pureScale architecture.  

To help you understand the pureScale architecture, let me give you an overall explanation in basic terms. The pureScale consists of two main parts—members and cluster caching facilities (CF)—with different physical systems and roles:

  • Members
    • Process the transactions in front of client applications
    • Have their own buffer pool memories and transaction log files
    • Can be configured with two or more members depending on the transaction volume

  • CF (cluster caching facilities)
    • DB2 members keep critical state information and data synchronously up to date in primary and secondary CF
    • For preventing single point of failure, these are configured with two CFs


Even for those who are not familiar with database and DB2 pureScale, it is very easy to guess that all members have to communicate with each other in order to maintain the same information and the status of shared data.

For example, while some transactions in one member make changes on relevant memory buffer pages, other members have to check to see if the pages were updated before they handle the same pages.

In the same way, once a transaction hold locks on some data to make a change, other members also have to know that. CFs fulfill the role of mediating between members, and these communications have to be done very quickly and efficiently based on RDMA. 

In this blog, my point is that one simple difference in the hardware stack can help us understand the architecture and pattern of IBM PureApplication System and PureData System for Transactions.

As you might see, it’s a simple fact but nevertheless a key difference.







Recent Stories
An Introduction to IBM Data Studio

The Basics of SQL Performance and Performance Tuning

Index Decluttering Opportunities in DB2 for Linux, UNIX, and Windows