Cheetah2 Cheetah 2 is Released




By now you probably have heard about the release of IDS 11.50 (Cheetah 2).  The release was announced at the recent IIUG user conference which was held in Lenexa, Kansas  on April 28 - April 30.

I have been heavily involved in the development of Cheetah2, which is the main reason that I have not been active in the blobsphere world recently.

There are many cool features which are part of Cheetah2, not the least of which is the expansion of work done in  IDS 11 as part of MACH11.  I will be describing many of these new features in detail over the next few weeks, but though that I'd do a quick overview in this blog entry.

Check out some of the new functionality at the web site ....  http://publib.boulder.ibm.com/infocenter/idshelp/v115/index.jsp


Expanded Ports

IDS 11.50 has now been ported to the MAC.  This was announced at Mac-World - held in January.  

New Communication Protocols

We have extended support for SSL.  In the past we supported encrypted communications, but now support the complete SSL suite.  Also, we now have support for DRDA and JCC.  This will enable IDS to more easily support the same clients as is currently supported by DB2.

Single Sign On

We now have the ability to support a common authentication for multiple IDS servers.

Updatable Secondary Nodes

With IDS 11, we expanded the secondary types from the single HDR secondary node to include multiple secondary nodes (RSS)  as well as a secondary running on top of a shared disk (SDS).  This created the MACH11 cluster.  In IDS 11.50, we have added to the usability of the secondary node by making it possible to perform update activity on those secondary nodes - be they HDR, RSS, or SDS nodes.  This means that the  investment that has been made in availability solutions can  be used in much the same way as the normal primary node.

Expanding the Isolation of the Secondary Node

In the past, the read isolation on the secondary node was restricted to dirty-read isolation.  With IDS 11.50, we have expanded this to include committed read and last committed read isolation.  With the release, this is restricted to SDS nodes only, but will be expanded to RSS and HDR in the near future as more testing is done.

Connection Virtualization

We have added support for connection virtualization by implementing a connection manager.  The connection manager monitors the various nodes within the MACH11 cluster to determine the type of node, workload, availability, etc.  The customer can configure the connection manager by describing a class of service.  When the client application connects to the cluster, it connects to the defined class of service rather than to a specific server.  The connection manager will then route the connection to the best choice for that classification , based on current workload.  

Failover Arbitrator

Part of the connection manager is to perform failover detection and transfer of functionality.  This is done by a simple set of rules which are part of the Connection Manager configuration.

OAT Enhancements

The Open Admin Tool has had quite a few new enhancements.  It has had an design-makeover of the overall layout and presentation.  It really looks a lot better than in the past.  In addition to the normal monitoring interfaces, it also now has some autonomics such as update statistics automation and alert management

Addition to SQL

There are several new things which we have added to the SQL engine.  One of the key things is a row versioning indicator which can be used to support optimistic locking techniques.  Also we have added the ability to support dynamic query construction within basic SPL.    




We have extended support for SSL.  In the past we supported encrypted communications, but now support the complete SSL suite.  Also, we now have support for DRDA and JCC.  This will enable IDS to more easily support the same clients as is currently supported by DB2.

Single Sign On

We now have the ability to support a common authentication for multiple IDS servers.

Updatable Secondary Nodes

With IDS 11, we expanded the secondary types from the single HDR secondary node to include multiple secondary nodes (RSS)  as well as a secondary running on top of a shared disk (SDS).  This created the MACH11 cluster.  In IDS 11.50, we have added to the usability of the secondary node by making it possible to perform update activity on those secondary nodes - be they HDR, RSS, or SDS nodes.  This means that the  investment that has been made in availability solutions can  be used in much the same way as the normal primary node.

Expanding the Isolation of the Secondary Node

In the past, the read isolation on the secondary node was restricted to dirty-read isolation.  With IDS 11.50, we have expanded this to include committed read and last committed read isolation.  With the release, this is restricted to SDS nodes only, but will be expanded to RSS and HDR in the near future as more testing is done.

Connection Virtualization

We have added support for connection virtualization by implementing a connection manager.  The connection manager monitors the various nodes within the MACH11 cluster to determine the type of node, workload, availability, etc.  The customer can configure the connection manager by describing a class of service.  When the client application connects to the cluster, it connects to the defined class of service rather than to a specific server.  The connection manager will then route the connection to the best choice for that classification , based on current workload.  

Failover Arbitrator

Part of the connection manager is to perform failover detection and transfer of functionality.  This is done by a simple set of rules which are part of the Connection Manager configuration.

OAT Enhancements

The Open Admin Tool has had quite a few new enhancements.  It has had an design-makeover of the overall layout and presentation.  It really looks a lot better than in the past.  In addition to the normal monitoring interfaces, it also now has some autonomics such as update statistics automation and alert management

Addition to SQL

There are several new things which we have added to the SQL engine.  One of the key things is a row versioning indicator which can be used to support optimistic locking techniques.  Also we have added the ability to support dynamic query construction within basic SPL.    

MACH11 on a single server Setting up MACH11 on a Single Server

 
Well I owe everyone an apology.  It's been way too long since my last post.  I've been rather busy lately trying to get all of the stuff into Cheetah2 (the upcoming release), but still I should have posted something.  Sorry...

Many of you may have heard in a recent "Chat with the Labs" that we are in the beta process for Cheetah2.  Also, Jerry Keesee (the director of IDS development) mentioned that we would be starting an open beta shortly.  Some of you may have even already joined the open beta and are currently testing with Cheetah2.  So I thought that I'd spend a bit of time today describing how you can setup the MACH11 environment on a single server, be it HDR, RSS, or SDS.  This might be a good thing to discuss at this time because there is some new functionality for the MACH11 environment in Cheetah2.

I do most of my development on a Linux workstation.  It does not have a fancy shared disk subsystem.  It simply has the factory installed IDE disk.  I also do quite a bit of development on http://www-128.ibm.com/developerworks/blogs/page/roundrepmy laptop using VMWare running RedHat 4.  (Yes - you can run a MACH11 cluster on a virtual server.)  I can guarantee you that my laptop doesn't have any shared disk subsystem.

OK - what it the trick to make this work?  Well it's fairly simple - use relative path names.  The same technique will work on basic HDR on IDS versions released prior to IDS 11.

Let's see how I set up my environment for a primary node which supports an SDS node and an HDR secondary.

First of all, let's look at the directory layout.  On my development system, all of my chunks are located   under /db/IDS.  Under that directory, I set up a different directory for each of my servers.  In my case, I name my servers  serv1, serv2, serv3,  serv4, etc.  That means that I have a directory /db/IDS/serv1, /db/IDS/serv2,  /db/IDS/serv3, etc.  Then within each of these directories, I set up my chunk files.  For instance, /db/IDS/serv1 would look something like what is displayed to the right.  (Of course I'm lazy and have a script which sets all of the up.)

So far there doesn't appear to be anything unusual about this. This is pretty much how most people will have set up a testing system.  But then let's examine the onconfig and see what it looks like.



The first thing that we might notice is the ROOTPATH parameter..  I'm not using the fully qualified path name /db/IDS/serv1/rootchk.  Instead I'm only using the name of the file.   OK - so what does this mean?  Well to make this work, the only restriction is that when starting onlinit, I must first be in the instance's  directory of /db/IDS/serv1.  So in order to bring up the server, I first execute cd /db/IDS/serv1 and then execute oninit -iyv.  By using relative path names, I'm able to run with any of the MACH11 server types, be it HDR, RSS, or SDS.




Now let's examine some of the other key parameters which might need to be modified.  To support shared disk secondary nodes (SDS), we might want to  modify SDS_TEMPDBS and SDS_PAGING to use relative path names.  In this example, I'm using the file sdstemp as my temporary DBSpace for shared disks and the files page1/page2 for my SDS paging files.  Also notice that I set my message log file to the file name log.  

OK - now let's see how the shared disk is set up.  I actually have the option to simply use the exact same path name on the SDS node as I use on the primary.  If all I want to do is to set up a primary and SDS nodes, then there is no reason to use relative path names.  I simply have to use the same entry for ROOTPATH on the SDS node as I do on the primary.  On Windows, this might be the easiest way to set up a MACH11 cluster.  However in my environment, I want to be able to set up both SDS and HDR/RSS.  Since running HDR and RSS on the same machine will require using relative paths, then I will also set up SDS using relative path name.  So let's see how the 'instance directory' of the SDS node is set up.


Basically the only thing that we have to do to use relative path names for the SDS node and to have a SDS instance directory is to use links to point to where the primary chunks are located.  The SDS temporary dbspace chunks, paging file, and message log files are dynamically created as the SDS node is started.




It is a little more tricky to use relative path name on Windows because then the database server is run as a Windows service.  So what must be done is to bring up the instance by using the starts command in the correct directory rather than using the auto start functionality of the Windows service manager.  You can use the Windows instance manager to get things set up, but will not want to actually initialize the server.  Instead you will want to edit the instances onconfig file to use the relative path names, get into the correct instance directory, and then run starts <instance_name> -iy.  This will result in the same effect as having run oninit -iy on a UNIX type of system.

Additionally, on Windows there an issue with setting up HDR and/or RSS because the physical recovery of the server will try to also startup the engine.  Physical recovery is performed by running ontape -p and is a normal step used to initialize the HDR/RSS secondary.  Since ontape -p will automatically start the server, there can be a problem with oninit not being in the correct directory because it is not started in quite the same way on Windows as on UNIX.  To get around this issue, I've used the following technique in the past to instantiate the HDR secondary on Windows.

On the Primary On the Secondary onmode -d primary <secondary node> onmode -c onmode -ky Copy chunks from primary instance directory  to the secondary instance directory Perform a physical recovery (oninit -PHY) onmode -d secondary <primary node>
We don't document the oninit -PHY option and don't encourage it's usage in a normal production environment.  It performs a physical recovery of the server which means that we only recover up to the checkpoint.  We do not perform any roll forward of the logical logs.  So in normal production environments, it's misuse can cause problems and possible loss of data - so if you should attempt to use this technique to set up an HDR environment on Windows, be aware of this.