Does Db2 Mirror Kill The Market for Third Party HA?
May 6, 2019 Alex Woodie
IBM launched Db2 Mirror for i two weeks ago to great acclaim, as the clustering technology puts IBM i on par with how most other major systems provide continuous availability. But will Db2 Mirror destroy the platform’s heritage of high availability solutions? IT Jungle asked IBM and the biggest providers of logical replication solutions, and the answer is no. Here’s why.
The first thing to understand about Db2 Mirror is that, at heart, it’s a database clustering technology. IBM figured out a way to make a single instance of Db2 for i run on two separate systems, in an active-active configuration, without ending up with a “two brain” situation. That was a real trick, especially with IBM i’s single level storage architecture, which was the biggest stumbling block to creating this technology, according to IBM.
If one of the systems hosting a database in the Db2 Mirror cluster goes down, the other one automatically picks up the workload from the application servers, which must be hosted on a separate system if active-active mode is being used (the applications and database can be co-located if the cluster is set up in an active-passive mode).
This redirection of I/O occurs immediately, giving Db2 Mirror a recovery time objective (RTO) of zero, which is as good as it gets. This gives IBM i shops the same type of continuous availability that users of Windows and Linux systems have enjoyed for years.
However, there are some important caveats to Db2 Mirror works – at least as the technology currently works – and these caveats mean that traditional HA is far from dead on IBM i. Let’s go through these caveats in order of most impactful to least.
No Disaster Recovery
Db2 Mirror doesn’t provide complete protection from disasters. It’s strictly a way to ensure continuous availability of applications running in a single data center, so if the entire data center is taken out, Db2 Mirror can’t help you.
This limitation is a result of the way this first iteration of Db2 Mirror was architected. Because the database writes and updates in Db2 Mirror occur in a synchronous manner – that is, the writes or updates must be completed on each node before the application receives confirmation that the transaction has been completed – there is a need for high speed connection to keep latency low.
IBM keeps the latency low by using high-speed Remote Direct Memory Access (RDMA) over Converged Ethernet (RoCE) network links to connect the two database nodes. The RoCE (pronounced “rocky”) connections are super fast – in fact, the data moves faster than if the two databases were housed in the same physical box.
But there are strict distance limitations in implanting a RoCE network architecture in this configuration. And that means that the two nodes must be physically located in the same data center – or at the very least, on the same campus, with no more than a 200 meters separating them. Without that physical separation, there’s no way to prevent an IBM i application from going offline when tornadoes, earthquakes, or zombies come calling.
IBM i chief architect Steve Will is upfront about this limitation in Db2 Mirror. “There’s still plenty of room for these other solutions that want to have a disaster recovery site,” Will tells IT Jungle. “But for the core continuous availability inside your data center, this is the answer.”
The folks at Syncsort – the largest provider of IBM i HA solutions – agree that Db2 Mirror provides a new level of continuous availability for the most demanding IBM i shops. But they’re also aware of the limitations in the technology as it now exists, which is why Syncsort announced its latest product, MIMIX for Db2 Mirror, on April 23, the day of IBM’s big announcement.
“IBM Db2 Mirror provides a high-end solution for organizations with the most stringent requirements for Db2 data availability,” Becky Hjellming, senior director of product marketing at Syncsort, tells IT Jungle.
“However, since the systems on which the two databases reside must be near one another in the same data center, the data is exposed to loss in the event of regional disaster, site failure, or data center outage,” she continues. “MIMIX for Db2 Mirror replicates data to one or more recovery servers located anywhere in the world, whether on-premises or in the cloud, to assure data protection from all disaster scenarios.”
Db2 Mirror is great, says Simon O’Sullivan, senior vice president with Maxava, a provider of IBM i HA software and cloud services.
“But 95 percent of Maxava customers replicate their data over long distances in real-time to achieve geographic separation,” he says. “Most disaster recovery specialists recommend at least 100 miles between primary and DR boxes, which is the ideal distance (e.g. to use separate power grids).”
No Integrated File System
The second biggest limitation of Db2 Mirror is its lack of direct support for the Integrated File System (IFS).
Db2 Mirror is focused on providing synchronous replication of Db2 for i databases, whether they’re stored in SYSBASE or iASP. Db2 Mirror supports both storage locations (it’s also completely agnostic to whether native record-level access or SQL is being used, which is great). Since objects in the IFS are, by definition, not database objects and not stored in Db2 for i, they’re essentially left out of the equation with Db2 Mirror.
The current IBM documentation is a little bit fuzzy on IFS support. IBM states: “Db2 Mirror is completely compatible with iASPs and, in fact, exploits iASPs for IFS support within the Db2 Mirror configuration.”
However, a little further down, one reads: “Support for IFS and IFS journals is accomplished through deployment into an iASP, which can be configured as a switchable LUN or in a mirrored pair of iASPs through storage replication.” In other words, you need to use one of the replication methods offered in PowerHA, or switchable LUNs, or a separate logical replication solution to replicate the IFS files.
Considering how much IBM i shops are using the IFS these days, the lack of IFS support is a concern. Pretty much any application that wasn’t written in RPG or COBOL, including Java, PHP, Node.js applications, uses the IFS to store files, which makes it a big deal.
That caught the eye of Robert Seal, the managing member of iSam Blue, which develops a remote journaling-based IBM i high availability product.
“DB2 Mirror doesn’t handle IFS. Instead it recommends that you put your IFS on iASPs dedicated to IFS objects and use Power HA to mirror the objects,” he writes. “With IFS becoming a bigger and bigger part of the IBM i world, not handling them seems to be a huge drawback.”
Chris Hird, the CEO of Shield Advanced Solutions, says he is impressed by Db2 Mirror and its potential to address the need for an active-active availability solution. But he raised a similar point as Seal about the IFS support.
“The fact that the IFS again seems to be the one area were special consideration has to be made may affect a growing number of customers as we move towards the other IBM i goal of open source software, which relies heavily on the IFS,” Hird writes. “Again we are not sure of the actual impact or restrictions imposed for the IFS as the online manuals have a lot of ‘this section to be updated later’ type comments. That may be something IBM addresses in more detail at a later time.”
The lack of IFS is a downside in the eyes of HelpSystems, which develops the Robot HA product. “Businesses continue to leverage the IFS for a variety of reasons, and in order to replicate the IFS, Db2 customers will need to leverage PowerHA,” says Tom Huntington, the company’s EVP of technical solutions. “Having to implement and manage both Db2 Mirror and PowerHA in order to manage your applications and data could be both time and cost prohibitive.”
Not All Objects
The third biggest drawback of Db2 Mirror is that it doesn’t support all IBM i objects.
The IBM i operating system is unique in how it treats almost everything like an object. There are dozens of object types supported on the system, and in order to provide high availability across two or more replicated systems, IBM i HA vendors have worked to ensure their replication, apply, and synchronizations methods and techniques can fully support most (if not all) of those objects.
Db2 Mirror supports the most important objects, including physical and logical files with native DDS record-level access, and an array of other objects when using SQL (including aliases, functions, indexes, permissions, procedures, schemas, etc.). It also supports user profiles, data areas, data queues, journals, job queues, and spool files (OUTQ). But there are some IBM i objects that didn’t make the Db2 Mirror cut.
“While IBM Db2 Mirror replicates the objects required to ensure data availability, not all the critical objects commonly needed for complete server failover are replicated, such as device descriptions, user index objects and others,” Syncsort’s Hjellming says. “MIMIX for Db2 Mirror replicates the critical objects not supported by IBM Db2 Mirror between database nodes, in an active-active configuration, to ensure worry-free failover in the event of a planned or unplanned server outage.”
Maxava’s O’Sullivan spotted the same limitations. “There are some critical objects that are not catered for in Db2 Mirror — user index objects, user queues, user spaces, and more,” he says. “Maxava can be used to make sure these are replicated.”
High Cost
The license fee for Db2 Mirror is $20,000 per core. Running this on a pair of large machines will quickly put the cost for the software into the six-figure range. Of course, customers get some extra benefits out of this, including the capability to power production workloads off multiple machines, with built-in load balancing too. But that’s a hefty fee compared to traditional HA.
The software is just the start, though. For reasons that aren’t yet clear, Db2 Mirror does not work with servers configured with internal storage – external SANs are a requirement, and SANs are pricey. Users must also shell out for RoCE cards, which cost about $4,000 each.
O’Sullivan says Db2 Mirror has the potential to deliver that heralded five 9s of availability – or 99.999 percent uptime – which corresponds with five or six minutes of unplanned downtime per year.
“It’s always that final ‘9’ that costs the most though,” he points out. “Two SAN-driven IBM i boxes in the same location connected by a big communication pipe and a license fee of $20,000 per core. It’s going to be adopted by the absolute top tier of IBM i users who can afford that type of budget spend for their HA.”
Conclusion: HA Not Going Anywhere
These four limitations – no DR capability, no IFS support, no support for some objects, and high cost – mean that the HA vendors aren’t quaking in their boots, at least not yet, anyway.
“We’re pleased to see this solution solve the needs of these very large, business-critical applications, particularly in banking and healthcare,” HelpSystems’ Huntington says. “We’re impressed by the speed of data transfer over the 100-meter distance and its ability to do load balancing. However, we do see some downsides.”
Those downsides mean there is “definitely a place for logical replication in the IBM i marketplace,” Huntington continues. “Not every business is going to be able to afford the cost of this implementation or have the need to meet extreme uptime requirements.”
“Anything new and exciting for IBM i is a good thing,” Shield’s Hird says. “We feel it will address a requirement that has been floating around for a long time and one which logical replication struggles to resolve which is active-active replication. However, the impact on Shield will be pretty minimal at this time as far as I can tell.”
“I think it’s pretty exciting,” Maxava’s O’Sullivan says. “It’s great to see IBM leading the field on availability and this will be another strong reason for enterprise users to remain on the IBM i. But logical replication leads the market and will continue to do so. Customers that are serious about HA and invest in this type of technology will also be serious about disaster recovery. That means they will also require the ability to replicate their database out of a single datacenter to another city, state or country. This is Maxava’s expertise along with our monitoring, data capture and security solutions.”
“Db2 Mirror seems to be a good product,” iSam Blue’s Seal says. “But its limitations require users to buy a second product if they want to use Db2 Mirror as part of their HA plan.”
“It is exciting to see another solution in the industry validate the critical nature of active-active replication solutions for environments that require near-zero downtime,” Syncsort’s Hjellming says. “It is important to recognize the scope of the solution, though. IBM Db2 Mirror is a high-end solution that provides continuous Db2 data availability between two active databases in close proximity to one another by preventing downtime due to planned maintenance or database node failure. However, it does not protect those solutions from disaster scenarios through replication to remote or cloud-based servers, and it is not a full-server high availability solution.
