DB2 on Beowulf Cluster

There are two possible scenarios for the installation of db2 in a beowulf cluster: a) share nothing and b) share everything, with some intermediate solutions also being explored by other research groups.

Solution a) is the simplest to implement, and does not require a beowulf scenario, as none of the resources is shared between different implementations of DB2 in a set of hosts. Data is split amongst the "nodes" and a special DB2 organizer distributes the load amongst them. DB2 Extended Enterprise Edition provides this feature.

Solution b) assumes sharing of resources, disk, memory, whatever amongst the nodes running DB2.

In our case DB2 has been installed in the master only, but the kernels of all computers in the cluster have been upgraded to support the running of DB2. DB2 installation is fairly straightforward, and should be fast. Currently it is possible to rsh to all nodes from the accoutn db2inst1, and minor links need to be made in the /usr partition to have DB2 running in all nodes.

A very simplistic approach would be to go for the share nothing solution and let DB2 see how things run, our problem is that the disks attached to each node are not particularly large, prompting for let DB2 run in the share everything mode (in our case, disk space in the RAID). Tests that I've run in the nodes and the master show, however, that I/O is much faster on local disks than what it is using the RAID. See the following example:


pfo.pfo@hydra(10:54)_44 just_read RA
Read 48931556 of 48931556 bytes
Tic-Tac.... ending 1570310 micro-seconds


pfo.pfo@node2(10:54)_2 cd /data/pfo/
b0208.cat  b0605.cat  RA
pfo.pfo@node2(10:54)_5 just_read RA
Read 52407504 of 52407504 bytes
Tic-Tac.... ending 133296 micro-seconds


pfo.pfo@node2(10:57)_9 cd /home/data/USNOB1/dz0001/
pfo.pfo@node2(10:57)_11 just_read RA
Read 52407504 of 52407504 bytes
Tic-Tac.... ending 4546726 micro-seconds

If I/O were the only consideration, I would prefer DB2 to work on locally stored data in each node and not work on shared disks. Notice that the just_read command opens the file and reads its contents into an array. I've run these tests after hours of having accessed the files, so no memory should remain in the OS regarding these files (linux does buffer some files upon opening them, so that further I/O is much faster). The reason in our case seems to be that communication lines run from each node to the master and to the RAID, in a heavy application I would expect this situation to worsen.

In summary, DB2 is capable of running in our cluster without much effort. Fine tuning the system to get it to perform as fast as possible may take extra effort and it could possibly imply modifying the interconection between the nodes, the master and the RAID.

-- PatricioOrtiz - 31 Jan 2003

Topic revision: r1 - 2003-01-31 - 11:27:09 - ClivePage
 
AstroGrid Service Click here for the
AstroGrid Service Web
This is the AstroGrid
Development Wiki

This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback