Maxava Gooses IFS Replication Performance for HA

November 18, 2014 Alex Woodie

Maxava is gearing up to give its high availability customers a significant boost in how quickly they can replicate and apply changes to data stored in the IFS. The move from a single-threaded apply process to a multi-threaded apply process should give customers sufficient performance overhead to ensure that IFS replication doesn’t become a bottleneck as IFS data volumes continue to grow.

IBM i shops are being swept up into the big data explosion that’s currently rippling across our world and our data centers. Today they’re generating, processing, storing, and reporting on much larger volumes than they did just a decade ago. Most of this data is stored in the DB2 for i database, which is the heart of the IBM i platform.

But increasingly the Windows-like Integrated File System (IFS) is getting a piece of the big data action, and not just for archival but core transactional workloads too. Customers that used to move 5 GB of IFS data are now moving 100 GB. It’s not just PDFs that need to be stored for archiving purposes but actual inflight transaction data.

Maxava has always supported a multi-threaded apply process when it comes to DB2 for i data and IBM i objects. This helped ensure that any changes made to database files and IBM i objects on the primary server are quickly applied to the secondary server, keeping both systems in sync as much as possible.

But until now, the company has relied on a single-threaded apply process for IFS data. After data is replicated to the secondary machine–which is handled by IBM‘s remote journaling technology–the process of applying those changes to the secondary server was bound by a single-threaded job for each journal.

At some Maxava sites, growing IFS volumes were getting too close to creating IFS backlog issues, says Maxava technical services and development director Peter Kania. “People were having periods of time where they are dealing with much larger volumes of changes in a very short period of time on their source machines,” he says. “The source system is able to handle that quite well. Then you’ve got the COMs [communication lines] push it across, and the target has to do the catch up.”

If the Maxava customer needed to perform an unexpected failover during one of those periods of high IFS data flows, it could mean waiting for several minutes for the secondary server to finish making all the applies on the target IFS. That’s several minutes too long for some businesses.

“Even though it catches up–and it catches up pretty quick–everybody wants as close to real time all the time, as is humanly possible, so that’s what we’re trying to give to customers,” Kania tells IT Jungle. “We don’t have anyone who was struggling or couldn’t keep up. It was more about [ensuring that] no matter what the time of day was, if somebody had an outage, that they have the fastest possible replication on their target systems, so they didn’t have to wait five minutes to cut over. That’s obviously the Holy Grail for any HA provider for their customers, to keep them as close to real time as humanly possible.”

Exactly how much faster the new multi-threaded apply process is compared to the old single-threaded apply process? It’s tough to say. That’s because there are so many other factors that can come into play that making any sort of prediction or promise is just asking for trouble.

“We’re loathe to turn around and say it’s 80 percent or 50 percent or 120 percent faster because each customer is going to have a different experience, due to makeup of their environments,” including the number CPW, DASD, memory, I/O they have on the primary and secondary machines, as well as how many disk arms they have, Kania says.

“Every customer’s footprint is different, the way the actual objects are updated, the number of updates that go in each file, where those files are placed and which libraries [are involved] can impact the speed of applies,” he says. “All we can say is that the multi-threaded apply process is obviously going to be faster than single-threaded apply process. We believe people are going to get very good benefit from this.”

Customers will be able to change the number of IFS apply processes on the fly in response to changing workloads. All things being equal, the more apply processes you have running, the faster the IFS data will get applied on the target system. But, of course, all things are not equal.

“A customer may not want to have 50 jobs running on the system applying data . . . because his CPW will only let him to be running five on his target system,” Kania says. “You don’t want to overload customers’ machines by running too many [apply processes]. You really want to find a happy medium, so we provide the ability for customer to really fine tune the apply processes.”

How many apply processes can the application run simultaneously? That is not something that Maxava feels comfortable sharing at the moment. But the company says the maximum number of threads is considerably higher than any reasonable administrator would want to run at the current time. So for all intents and purposes, your chances of getting short-sheeted in the IFS apply department by the product previously known as *noMAX is slim to none.

The new multi-threaded apply process will be available later this quarter in the high-end offering, Maxava HA Enterprise+. For more info see www.maxava.com.