Triton Consulting

By James Gill

We were lucky enough to get an opportunity to spend a week in the IBM Boeblingen Labs in Germany, to get some hands on experience with DB2 9.8 – pureScale – or Data Sharing on mid-range. 

The platform that we were working with was a five node configuration – two coupling facilities (CFs) and three DB2 member nodes. This was all implemented in three partitioned pSeries p550 servers, with 1TB of disk supporting it. 

On z/OS, the performance and behaviour of the CFs in a Data Sharing Group (DSG) can have an enormous impact on the overall viability of the solution – both in terms of availability and performance. 

In DB2 for z/OS, the CF configuration works as a client-server model. Members in the DSG request actions from the CF, which manages the structures, as well as the client requests.

These requests are delivered to the CF by scheduling them through XES, which queues them for delivery to the CF over XCF. The CF receives the request and can potentially queue them depending on its current workload. The request is dispatched, the answer is resolved and the response is returned to the requester through the XCF transport and XES interface. 

The model is different with pureScale, where the CF is used as a remote data cache – the intelligence being retained in the group members. 

On DB2 pureScale, the CF structures are accessed using the Infiniband (IB) remote direct memory access (RDMA) protocol. This allows a requester on one box to directly interact with a preconfigured data area on another box. Further, the protocol and data access is all managed by the IB cards, without having to interrupt the CPUs to complete any of the operations. This is extremely efficient, especially when coupled with the low latency of IB. So whilst the CFs are presented as simple data areas, the performance of the member interactions is limited only by the capacity in the IB network and horsepower in the IB cards required to access the data areas.

CF implementation in DB2 pureScale has been achieved with three processes:

• ca-server
• ca-mgmnt-lwd
• ca-wdog

These are not currently covered in the DB2 pureScale documentation, but it seems reasonable that one owns the CF structures, one provides restart monitoring and the other provides operational information and management capabilities to the member nodes.

Assessing the performance of the CF is tricky, as the IB network performance is difficult to directly diagnose. As the network stack is not directly involved in the RDMA conversation, tools like netstat do not provide any insight. Further, it does not currently seem possible to detect queuing depths for RDMA requests in the CF IB card.

Having said that, there is a wealth of information available relating to the CF structures themselves and usage levels through enhancements to the db2pd tool. The following are example commands that we used to understand the impact of our workload on the CFs:

db2pd –cfinfo

db2pd –db sample –cfinfo gbp

db2pd –db sample –cfinfo lock

db2pd –db sample –cfinfo lockv

db2pd –db sample –cfinfo list

db2pd –db sample –cfinfo sca

db2pd –db sample –cfinfo 128 perf

We’re looking forwards to the documentation update so that some of the information produced will make more sense!

Note that a lot of the basic information returned by these commands is also available in the SYSIBMADM views implemented in DB2 pureScale. More on these in the following blogs.

We were very impressed by the performance and resilience of DB2 pureScale whilst working in the Labs. These are the main focus of the next two blogs.

Last month we were delighted to be given the opportunity to visit IBM’s research and development centre in Boeblingen, Germany.  Before I get on to what exactly we were doing there I’d like to share a little information about the centre itself as it’s quite a place!  Opened in 1953, Boeblingen is host to a whopping 2000 IT specialists, electrical engineers and physicists working on over 40 projects!  Their focus is on the development of next generation microprocessors, mainframes and supercomputers and enterprise software to control business processes.  In addition, Boeblingen is one of the largest LINUX and SAP integration centres within IBM.  So we were rightly excited about the visit. 

The reason for the trip was to carry out our own research and development work on IBM’s newest technology release – IBM DB2 pureScale.  Ever since hearing the first announcement last year, our team of DB2 experts have been itching to get their hands on the software and see what it can do.  The most exciting thing about this trip was that we were to be the first IBM Business Partners in Europe to get a look at DB2 pureScale in action – what a fantastic opportunity!

So, three of our DB2 experts set off for five days in the labs.  After a warm welcome from the pureScale team in Boeblingen, it was soon down to business.  As an R&D team the brief was to gain practical experience in the installation, operation and use of a DB2 pureScale environment, as well as testing DB2 pureScale for scalability and resilience.

Meet the team

Iqbal Goralwalla – Head of DB2 Midrange Solutions
Specialist DB2 pureScale subject – DB2 Self-Tuning Memory Manager (STMM), Bufferpools and Workload Balancing

James Gill – DB2 for z/OS and data sharing expert
Specialist DB2 pureScale subject – Coupling Facility

Clair Ross – DB2 Midrange expert
Specialist DB2 pureScale subject – Insert Load & Replication

Over the next few weeks the team will be blogging about their specialist subjects and what they have learned during their five days in the labs.

We’re delighted to announce that we are the first IBM Busuiness partners in Europe to work with pureScale!

Arguably IBM’s most important new feature for DB2 LUW, pureScale was anounced in October last year and quickly caught the attention of the industry.  Based on elading System z data sharing technology, DB2 pureScale integrate IBM technologies to keep critical systems available 24/7.

Triton’s team of DB2 experts spent a week at IBM Labs in Boeblingen, Germany on a research and development project.  During their time there Triton’s consultants gained practical experience in the installation, operation and use of a pureScale environment as well as testing DB2 pureScale for scalability and resilence.

“It’s certainly been an interesting week here in Boeblingen and we have really been able to take a deep dive into pureScale.  IN terms of scalability and resilence, pureScale really is second to non in the marketplace” Says Iqbal Goralwalla, Principal Consultant – DB2 Midrange.

Despite a very “interesting” journey back to the UK over the weekend due to cancelled flights the team are eager to continue with the DB2 pureScale research project and plans to produce a series of blogs, podcasts and technical briefings over the next few months so watch this space!

In our first Confessions of a DB2 Geek podcast we chat to two of our DB2 experts about pureScale and what this important new release means for organisations running DB2 on midrange platforms.

An ideal fit for the retail sector, pureScale is going to allow organisations to increase capacity when they need it at the really busy times like Christmas and the January sales and scale back at times of less demand.  Our DB2 LUW expert Clair says “If you’re a retailer with a high volume online transaction environment then pureScale is going to be absolutely ideal for you”

Just how important is this release to the midrange market?�
“For those needing true 24/7 availability this is an enormous release and has plugged a gaping hole that has been in the architecture of DB2 on midrange for some time.”  James Gill, DB2 z/OS Expert

Read the article and download the podcast.

I had to set up 10 TWS batch schedules this week, and baulked a bit at the idea of going through the admin tool and clicking them all in. Following a discusion with a colleague, I came across a TWS utility called “composer” which I hadn’t previously known about. This allows you to export job and schedule definitions to a file, and then re-import them again. Using this, I was able to create the first set of jobs and schedule and then export to a file using:

    composer create file.txt from job=WORKSTATION#JOBNAME

and

   composer create file2.txt from sched=WORKSTATION#SCHEDNAME

Then, using some dodgy shell, sed and awk scripting, I cloned all of these for each of the environments and reloaded them using:

   composer replace file.txt

What could be simpler? The text files produced are fairly self explanatory, although – no doubt – with a little rummaging there’s bound to be a manual somewhere about the syntax.

The front end has been modified to include updates to the report presentation:

• Colour coding of the grid report to show which columns are chartable.
• Charting support using Dojo.  The charts are presented in a “dialog box” (another Dojo widget).
• Tooltips have been applied to the report grid headers to provide a little (tiny) amount of explanation.

 Things to focus on this week include:

• Support for multiple capture (snapper) engines delivering to a single data save (snapsave).
• Modifications to the report / viewer to support multiple (customer) database monitoring sources.
• Add the memory pool report for the instance, complete with charting.