The Four Hundred

When IBM introduced remote journaling as a new function within OS/400 V4R2, in 1998, it was viewed as a technology that would impact AS/400 disaster recovery and high availability strategies. Four years later, that has yet to happen on a large scale. Today, only a handful of companies have instituted remote journaling along with traditional OS/400 high availability middleware. However, two newcomers to the field are hoping to capitalize on remote journaling's capabilities with a new generation of OS/400 high availability programs.

Remote journaling refers to a transport method used to move data from one AS/400 or iSeries to another. It was built into the operating system--with substantial influence from the iSeries high availability business partners--primarily with the notion that it would be used to increase the integrity of data movement during data replication and mirroring processes and to cut down on processing overhead.

Remote journaling begins with the concept of the local journal. Local journals were already a key element of OS/400 when remote journaling debuted, and they are heavily relied on by all OS/400 high availability programs to begin their data replication or mirroring processes. Remote journaling builds on the local journaling function by making sure that every piece of data that's put into the local journal also gets sent to the remote journal, which must be placed on another machine. When the remote journal receives the data, it's then up to a third-party high availability application to make sure that data gets to where it needs to go.

Remote journaling duplicates a process that all OS/400 high availability software vendors around in 1998 had already designed into their products, which they call a "journal scrape." Because remote journaling is actually controlled below OS/400, down in the SLIC layer of the platform, remote journaling is quite a bit faster than a typical journal scrape. High availability vendors will dispute the extent to which remote journaling is faster than their journal scrapes, but all will admit that it is, in fact, faster.

There are two forms of remote journaling: synchronous and asynchronous. Synchronous remote journaling provides a higher degree of data integrity, because it verifies that the target machine has received the data being sent from the local journal to the remote journal. Asynchronous remote journaling does not perform this real-time verification and is, therefore, faster than synchronous remote journaling, as well as the traditional journal scrape transport method. The prior generations of high availability software from vendors who were in the market before V4R2 used an asynchronous process to update target machines.

Today, all of the OS/400 high availability software vendors support remote journaling--both synchronous and asynchronous--in their products. However, the extent to which they support it, rely on it, and pay homage to it varies significantly. To the newcomers, remote journaling is a technological silver bullet that makes anything else in its class unworthy of a modern high availability infrastructure. To the established guard, remote journaling is just another tool in the high availability toolbox.

Here's the lowdown on where the five players in the OS/400 high availability field stand on remote journaling.

DataMirror has supported remote journaling in its High Availability Suite for the last year and currently has about five to 10 customers using it in production, sources at the company say. Later this year, DataMirror will release an updated version of its High Availability Suite that will include more remote journaling features. DataMirror executives say they encourage customers to use remote journaling where it makes sense, such as with some mission-critical applications, and to use DataMirror's existing journal scrape transport method in other areas, or a mix of both.

iTera released its high availability product, called Echo2, last year. Echo2 was built on the remote journaling technology and does not feature any other alternatives for the data transport method. Sources at iTera say there are about 20 Echo2 users today.

Lakeview Technology has supported remote journaling in its MIMIX high availability software for about two years and currently has about 15 to 20 customers using remote journaling. Lakeview sources say they highly recommend remote journaling to customers where it is appropriate, such as with very active applications with large records, but most customers will need a mix of remote journaling and Lakeview's journal scrape transport method. Lakeview sources say they expect the number of Lakeview customers using remote journaling to double in the next year.

Maximum Availability released its high availability software, called *noMAX, in 2000. Like iTera's Echo2, *noMAX is built upon the remote journaling technology and does not offer other transport methods. Maximum Availability has landed customers in England, Iceland, and Canada, as well as in its home country of New Zealand, and is reportedly close to landing its first deals in the United States.

Vision Solutions has supported remote journaling in its high availability software, called the Vision Suite, since OS/400 V4R5 and currently has about 10 customers using it in production. Sources at Vision say they encourage customers to use remote journaling in certain instances, but that most customers will want to implement a high availability infrastructure that uses a mix of remote journaling and Vision's proprietary journal scrape transport method.

DataMirror, Lakeview, and Vision all give similar reasons for why remote journaling has not caught on and should not be used as the basis for a complete high availability solution. They say that remote journaling--especially synchronous remote journaling--requires more processing power and more network bandwidth than the non-remote journaling versions of their software. Another commonly heard reason why remote journaling is incomplete is that it does not support all of the different file and data types that their existing products do, including security objects, user profiles, configuration objects, and spool files, which are not supported by journaling.

Larry Youngren, who works in Rochester, Minnesota, as IBM's leader of journal microcode development, questions the high availability business partners' claim that remote journaling uses more processing power. "Remote journaling is better plumbing. It's efficient because it's microcode to microcode, transferred below the machine interface," he says. "Inherently, technology that doesn't use remote journaling has to cross the machine interface multiple times before anything gets on the wire."

IBM and the high availability software vendors actually did benchmark tests at Rochester last fall concerning just this very topic, and published the results this May in an IBM Redbook called Striving for Optimal Journal Performance on DB2 Universal Database for iSeries. Youngren says the benchmarks discussed in the Redbook show that when you compare asynchronous remote journaling with established high availability software products--what he calls an "apples to apples" comparison-- remote journaling shows a latency of about 5 milliseconds, which is considerably less than the other products. Synchronous remote journaling has zero latency by its nature, but can cause a slowdown in application response time. However, with proper network connections, the benchmark studies showed that the slowdown in response time using synchronous remote journaling was minimal and never exceeded the slowdown caused by asynchronous remote journaling by more than 18 percent.

In terms of the bandwidth question, Youngren says an improvement in remote journaling with OS/400 V5R1 should improve network utilization. The new feature, called journal minimal data, allows only the portions of a record that have changed to be sent to the journal; hence the remote journal.

As far as the data types are concerned, Youngren acknowledges that not every data type is supported by journaling. However, remote journaling does support what he calls the "Big Five," which include database files, access paths, and, since the release of OS/400 V5R1, Integrated File System data, data areas, and data queues. Additionally, both Maximum Availabilty and iTera--the two vendors that rely on remote journaling--say they have ways to access and send files such as security objects and user profiles.

The established high availability vendors all say there's a place for remote journaling in their solutions. "We highly recommend remote journaling, but it's the customers who make the ultimate decision," says Glenn VanBenschoten, Lakeview's MIMIX solution architect. "It's a good technology that needs to be used in the right scenario."

"Synchronous remote journaling is useful when you have to make sure every single journal transaction goes through," says David Wegman, Vision Solutions' executive vice president of marketing and business development. "But remote journaling has a CPU and a bandwidth cost to it. Sometimes using our technology is superior."

"Remote journaling uses up bandwidth on the communication line and uses processing power on the source system. . . . Synchronous remote journaling sells more hardware," said Nigel Stokes, chief executive of DataMirror. "Two-phase commit is theoretically a good idea but practically a bad one."

The two vendors that rely on remote journaling, iTera and Maximum Availability, discount these comments, and say remote journaling is the real deal. "What our competition says is, 'Remote journaling brings over too much information; it uses more bandwidth; it's slower," says Simon O'Sullivan, director of sales at Maximum Availability. "Our experience is, it's got to be faster because it's happening in the operating system. . . . We've seen it be incredibly fast."