
HA4i Version 6.1 is now packaged and ready to ship! We had hoped to get the packaging complete about a month ago but a number of client requests had to be added so it put us back a number of weeks while we developed the new features and put the product back through testing. This will be the first release of HA4i which is a replacement for our existing RAP V4R1 product. We have made a lot of changes to the product which are all aimed at making HA4i a simpler and easier to manage High Availability Product for the SMB market.
While some of the features have been removed because they just added clutter and provided little use to the majority of our users we have added many new features which make this a very attractive High Availability solution for those customers who felt they could not afford one previously.
One of the most important aspects of this release is the simplification of the product, we have removed many of the sub menu’s and created intelligent start up processes to reduce the opportunity for error when controlling the product. We have also added some new features which provide a more granular approach to the apply process while ensuring we did not add complexity for the user in the start up process. As part of the new interface we have created a PHP based interface for the product which we can install if the customer needs it, if you have been following the blog for sometime you will have seen some screen shots from this interface. As usual we have not stopped and will continue to add features to the PHP interface as we move forward which will enhance the users experience when using the product. Here is the latest version of the main monitoring interface.
Another area we took a good look at was the role swap process. When the user carries out a role swap there can be a number of problems which occur due to the availability of some information when systems are down or when a role swap is carried out with all of the processes up and running. We do request that the users end all activity before running the request on both systems but we have found a few just ignore that request and then complain bitterly when everything gets confused about what stage it should be in. So we have added more checking and data verification as part of the role swap process including the changing of the journal receivers and ending remote journal links automatically once the user has been asked for permission to carry it out. This has made the role swap process a lot more robust even when the rules are ignored… As with all programming tasks I am sure this will not be the end, I am sure there are some actions we have not considered and some user will prove just how stupid we can be…
Auditing has been included in the product from the beginning but as usual we are constantly trying to improve our processes to make them pick up more discrepancies and provide better checking of the objects. One area we just didn’t consider was the auditing of the profiles on the system, as the replication is totally automatic we had never seen any issues with profiles not being in sync. As usual a customer wanted to run audits against the profiles because he had been changing the profiles on the target by mistake and needed to bring everything back into line. The profile replication process only reacts to change notifications so unless he went through every profile and changed them we would not pick up the change. His request was quite simple, he wanted all of the profiles to be checked on the source and if they differ the differences noted to allow recovery at some later stage. As they have over 800 profiles on the system the thought of going through every profile manually did not please him..
So this release now has a profile audit function which will check the profile on each system logging any differences it finds. We did have to add a couple of exclusion such as the system profiles and the option to ignore the UID/GID settings which reduces the errors returned which have little bearing on the profile state.
Granularity was another concern we needed to address, in the previous version every receiver change was passed through a single apply processor. This version has added some granularity by allowing each remote journal to be controlled by an individual apply processor. Now you can have multiple journal receivers being applied at the same time which will also adds some improvements in the role swap times in those environments where multiple journals are configured between the systems. As you can see from the above monitoring screen we do allow the individual apply processes to be controlled via the PHP interface as well.
The replication of source files has been a problem for sometime, if you use the IBM journalling function to journal the files to your user journal and you have an active development environment with lots of code changes being worked on regularly the user journals can become very bloated very quickly. Every time you change a member even if its only a single line every line in the member will be added as a change in the user journal. RAP always provided the ability to replicate these objects at the object (FILE) level through the use of the tools we provided but it never had a trigger mechanism which would allow this to occur automatically. This release now uses the audit journal to capture the member changes and replicates the individual member on change. While this seems a bit similar to the bloating of the user journals it does offer a benefit in that the user journals are only applied occasionally, we restore the objects immediately which provides a smaller foot print for the DASD used to hold these changes on the target and the source. A couple of other objects have also been added to the support object list such as USRIDX and SAVF, as users ask for more objects we will continue to add them.
If you are interested in a demo of the product and its capabilities or would like to know more about it let us know, we could save you a lot of money on your existing installed HA product or surprise you at just how affordable HA really is.
Chris…



