|
|
![]() |
|
|
DataMirror Delivers Full Journaling Support with iCluster 2.0 by Alex Woodie DataMirror followed through on a promise made earlier this year to bring full support for remote journaling to its OS/400 high availability software. Last week at the COMMON conference in Denver, DataMirror announced the latest release of its clustering software for AS/400 and iSeries servers, iCluster 2.0, in which it has implemented full support for remote journaling, as well as its traditional journal scrape method.
DataMirror first launched iCluster in 1999 to enable customers to implement the highest level of OS/400 application availability--clustering, which allows application workloads to be split among two or more remotely located AS/400 or iSeries servers. IBM first brought clustering capabilities to the platform in 1999 with the release of OS/400 V4R4, which featured a framework and a set of APIs that enabled independent software vendors to build support for clustering directly into their applications. In addition to allowing one server to take over for another, in the event of an unscheduled shutdown, clustering was designed to help companies maximize their data processing resources by dynamically moving workloads to underused servers. But clustering has yet to garner the support that IBM and the high availability vendors had hoped. DataMirror introduces three new features with the release of iCluster 2.0. Perhaps the most important new feature is full remote journaling support. With iCluster 2.0, customers can choose between two different methods of transporting data and objects among or between remotely located OS/400 servers: either remote journaling or DataMirror's own journal scrape. With remote journaling, any data or object change that is sent to the local journal on a primary machine is automatically routed to the remote journal on a backup machine, or any number of machines, in broadcast mode. In tests conducted at IBM's labs in Rochester, Minnesota, remote journaling has proved to be substantially faster than other transport methods. DataMirror's own method of checking the local journal on the production box and relaying changed objects and data--which it developed before remote journaling became available--is highly efficient, the company said. DataMirror has also improved iCluster's ability to replicate large image files and other documents commonly found in the insurance and healthcare industries. Many companies in these industries use document management systems to reduce paperwork. These files are often stored as large byte stream files in the OS/400 Integrated File System (IFS). With iCluster 2.0, DataMirror has introduced an efficient way to mirror these files, which, it said, are usually created and deleted but rarely updated, using its in-house journal scrape transport method. The third key enhancement involves iCluster's handling of triggers. DataMirror said that customers who have implemented the advanced external trigger functionality in OS/400 V5R1 can rest assured that all of their trigger information will be replicated in real time. With iCluster 2.0, triggers are kept current on the backup system in a disabled state and can be rapidly activated upon failover, DataMirror said. Earlier this year, DataMirror executives said they would bring full remote journaling support to High Availability Suite, which shares much technology with iCluster but lacks the capability to manage the mirroring of objects and data among multiple nodes. iCluster 2.0 will be available in limited release at the end of November. For more information, go to www.datamirror.com.
|
Editor
Contact the Editors |
|
Last Updated: 10/22/02 Copyright © 1996-2008 Guild Companies, Inc. All Rights Reserved. |