Content Copyright © 2006 Bloor. All Rights Reserved.
xkoto is a relatively new company—it only came to market late last year—however, it has some neat technology. The company’s product, called GRIDIRON, provides dynamic load balancing for DB2 in transaction processing environments.
In particular, what GRIDIRON allows you to do is to build out clustered DB2 environments horizontally, across low-cost Linux (Red Hat and SUSE) boxes, as opposed to having to scale upwards in a more vertical fashion. In other words, it provides high availability, scalability and performance capabilities for DB2 environments that are not dissimilar to Real Application Clusters (RAC) for Oracle.
Now, xkoto is not the first vendor into this market. There are also products from Avokia, Continuent and Resonate. However, there are a number of ways in which these differ from GRIDIRON. For example, Continuent is focused on open source database environments, Avokia has a master-slave architecture while xkoto is peer-to-peer, and other vendors may have consistency issues under certain circumstances whereas xkoto guarantees 100% consistency.
The way that GRIDIRON works is that when a create, update or delete request comes into the system then it is despatched to all of the nodes in the cluster and each starts processing that transaction. The first one that finishes returns the results to the requesting application (so that you get the fastest possible response) while the other nodes conclude in their own time to ensure consistency. In other words, this is an asynchronous load balancing capability. If one node fails to commit, then that node is evicted from the cluster and a queue is established of transactions that need to be processed by the failed node once it comes back on-line. However, the queue will have a user-defined capacity and if that is exceeded then restoring the failed node will require conventional back-up procedures. For this reason, xkoto always recommends at least 3 nodes in a cluster: then if one fails and needs to be restored and synchronised one of the working nodes can be designated for that task.
Read requests are treated differently: GRIDIRON maintains knowledge of the table states on each node and, when a query comes in it is despatched to the node that can best execute that read. Note that clusters do not have to be co-located and disaster recovery (DR) systems can even be included within a cluster, though if the network connection is relatively slow, the DR system can be excluded from read requests.
GRIDIRON physically resides between the application server and the database and it parses all incoming transactions before (in the case of reads) routing them to the relevant node. This, as you may imagine, imposes an overhead, typically of around 15%. In other words, in a three node system performance should be approximately 2.7 (less .15 for each node after the first) times the performance of a single node implementation.
This technology has some significant advantages when compared to both native DB2 and Oracle RAC. For example, it not only provides load balancing but also replication (which would require a separate product in the case of IBM) and native capabilities for both high availability and disaster recovery.
Finally, it is important to note that xkoto is highly competitive in commercial terms: it charges at a flat rate per cluster, which should compare favourably with the CPU-based pricing model adopted by most other vendors.
Put this all together and GRIDIRON is a tool worth investigating. It should help existing DB2 installations. It should also help IBM to compete with Oracle RAC.