As with all of the pureSystem family the use of patterns to automate repeatable tasks is a feature of pureData systems.

With pureData here are two types of patterns available:1) Topology Patterns. Topology patterns will install all of the software required to run pureScale and create the pureScale instance on a number of compute nodes. You can deploy a topology pattern of 2, 4, or 6 nodes. The 2 node topology pattern consists of an instance of 2 members with a cluster caching facilities (CFs) co-located on each of two compute nodes. This is the smallest practical HA installation of Db2. The 4 nodes topology pattern consists of 2 members and 2 CFs on separate compute nodes. The 6 node topology pattern is a 4 member cluster with 2 CFs on separate compute nodes. Of course the more nodes you deploy to the higher the performance and resilience.2) Database Patterns. A database pattern is essentially a method of storing and reusing database configuration settings. Databases patterns are used to create and configure a database within the instance topology. PureData systems will come with an IBM transaction processing database pattern. You can also "roll your own".

The use of topology and database patterns allows instances and databases can be deployed in a matter of minutes repeatably and dependably.

We have heard that a “tens of kilometres” limit applies to
the distance between the two sides of a Geographically Dispersed pureScale Cluster (GDPC).Buy why?

This is based on a physical
limitation i.e. the speed of light in glass (fibre) which is about 5 µs / km.From this we can calculate a round-trip times
from member to CF as follows at these distances:

3km = 30 µs

10km = 100 µs

50 km = 500 µs

100 km = 100 µs (or 1 ms)

300km = 3000 µs (or 3 ms)

This will have a significant effect on the performance of
the cluster, especially when we start to get into tens of kilometres.The
“normal” times for RDMA actions are of the order of 15 µs so to those we need
to add this latency for the distance.Compared
to a normal pureScale cluster (all in one location) anRDMA action will be slower at a distance as
follows.

I am at the pureSystems booth at the Innovate 2013 conference in Orlando. http://www-01.ibm.com/software/rational/innovate/ This is my first big conference and I have to say I am very impressed by the scale of things! Below a rendering of our setup and we are just a tiny part of this conference!

We have three touchscreen monitors loaded with the TouchScope application. These are pretty cool. We have experts in each of the types of pureSystems at the booth also who can give a great insight into the different types of pureSystems: i.e. pureFlex, PureApp and pureData.

The more I talk to people about pureSystems the more I think that the old way of provisioning systems is nuts. Do people really need to design a solution, buy various "bits" like storage, networking, servers seperately from different vendors with different support agreements, cable it all up and put a stack of software on there "manually" themselves?

If you went to buy a car and they said you had to do this: figure out what parts you need, then buy the engine from one company, the wheels from another, the chassis from yet another etc and then put it together yourself and hope it all works ok you would think they were crazy, right?

Today I saw that the status of one of our testing pureScale instances was red.

Yes, red, it had a red sign, as this instance is on a PureData System for Transactions. The DB2 pureScale instances panel lets you have a quick look at the status of your instances and the databases deployed on them.

Connecting via ssh to the instance, and trying to run db2instance -list shown that this particular instance was not in a good shape:

db2vr1@compute05:/home/db2vr1> db2instance -list
The member, CF, or host information could not be obtained. Verify the cluster manager resources are valid by entering db2cluster -cm -verify -resources. Check the db2diag.log for more information.

Following the tip, I ran db2cluster -cm -verify -resources and it shown that the cluster state was inconsistent. At this point, I had a look at the db2diag.log and I could see that there were some errors related to cluster resources.

After seeing that the issue was due to the cluster resources for pureScale, I decided to try to stop and restart the cluster services with the following commands:

db2vr1@compute05:/home/db2vr1/sqllib/bin> ./db2cluster -cfs -start -all
All specified hosts have been started successfully.

2) Verifying and repairing the instance

At this point, I tried to verify again the status of the cluster with db2instance command:

db2vr1@compute05:/home/db2vr1/sqllib/bin> db2instance -list
The member, CF, or host information could not be obtained. Verify the cluster manager resources are valid by entering db2cluster -cm -verify -resources. Check the db2diag.log for more information.

Now, trying again to repair the cluster resources with the db2cluster command:

Last week during some performance tests on one of our PureData for Transactions Systems, we were looking at the CPU load for the system during workload execution.

In pureScale you know that the CPU stats from command line tools like top or vmstat could be not accurate to the DB2 member real load. This is due to the Cache Facility (CF) process being colocated to the DB2 member, on the same host. The process for the CF will shows most of the CPU usage even if there is not to worry about this.

To clarify this, we were using a small instance on PureData for Transactions, so 2 members and 2 CFs on two physical hosts.

Back to our CPU load... How can we measure that?

db2top? There are some CPU metrics in db2top, but can show 100% CPU load even if this is not exactly true.

Optim Performance Manager? Yes, we can check the CPU load for the system using OPM, in the Performance - Overview - Key indicators panel. We can also look at Performance - System to get the CPU usage. In PureData for Transactions this is useful as it has Optim Performance Manager already integrated into the management console.

An useful query to check the CPU load from DB2 itself and also valid for pureScale is the following:

select MEMBER, varchar(HOST_NAME,32) as HOST_NAME,
CPU_USAGE_TOTAL from
table(SYSPROC.ENV_GET_SYSTEM_RESOURCES()) order by MEMBER;

pureScale can now be deployed on virtual machines using sockets (on VMware ESXi and KVM)

Incremental backup support

DB2 Spatial Extender support

Online (inplace) REORG now supported

Federated two-phase commit

Some of these features are really useful to get started with pureScale like having the possibility to run pureScale using just a basic TCP/IP network or using virtual machines under KVM or VMware ESXi. This is great for who wants to explore pureScale technology just using a basic network or a virtualized environment!

But also, for actual pureScale users, two great enhancements like incremental backups and online REORG will be a huge improvement in terms of system and database maintenance and administration.

If you like me are really looking forward to try all these new features, just go and download the just released DB2 Cancun Release 10.5 FP4 at this link: