Abacus Solutions uses SAN Replication technology to help companies achieve high availability
No two backup methods are created equal – and that is especially true for IBM i systems. When it comes to data backup management and high availability, Abacus Solutions always advocates for the latest technologies, such as SAN to SAN replication, to provide the most protection.
For insight into the company’s long-standing experience providing IBM i backup solutions we’re speaking with Josh Osborne, Chief Technology Officer at Abacus Solutions. In the first part of our discussion, we talk about how an HA SAN solution provides more robust protection than traditional, software-based replication.
Tell us a little about yourself Josh. How did you get started at Abacus? What are some of the responsibilities you manage as the head of the Abacus Managed Services engineering team?
I’ve been with Abacus in one form or another since 2001, but I actually started out as a customer. I started doing contract work for them around 2002 and then became a full-time employee in 2004. I’ve been CTO for the company for about 4 or 5 years at this point.
I’m in charge of the hardware/infrastructure solutions that we create in our lab, test, and then make available for our customers. For me, the C in CTO stands more for Creative than Chief.
That’s a good one – Creative Technology Officer. Sounds like your team has a lot of fun.
What I enjoy most is working closely with the engineers and testing a lot of the solutions we sell in our technical lab. When a vendor comes in and introduces their newest technology, my team “labs it up,” and then takes it for a run around the track. The joke is that we try to break it. We want to know just how far the solution will go and by doing this we understand the limits of the solutions we sell.
I didn’t realize we had such an established R&D practice at our business.
Yeah – it’s all behind the curtains because there’s no sales opportunity for those solutions until we have thoroughly vetted them. You can’t just take the vendor’s marketing specs and trust that it works. At the end of the day if it doesn’t work, it lands on our shoulders. When the vendors come in with a new product, like a virtual tape library or a new SAN, we test it and decide whether it’s for us or not.
Let’s move on to our main topic: SAN to SAN replication. In a general sense, what is it? What does it involve?
In the past when IBM recognized the need for High Availability and the constant protection of data, they enabled remote journaling. Remote journaling was basically a feature where whenever a change occurred on a Production machine it was written out to a log file, otherwise known as a journal, and then that journal was replicated to the Target HA system. On the Target side, there was a program that read that journal and applied that recorded change to the Target system. So basically, any change that happened in Production, also happened on the backup system in the exact same way, and that’s how the systems were protected.
The downside to that methodology was that it required you to choose specifically what got protected. You couldn’t just have it copy and protect the entire machine. There were parts of the machine and the operating system that could not be replicated using that methodology. It allowed you to protect your data, some of the other areas of the machine, but you couldn’t protect 100% of the machine. Another drawback was that you had a lot of overhead using that method. You had to run two processors, one on each side, and you consumed disk space on both sides. Replication stopped while you were in a restricted state as well, so for example, if you were running backups from the target, and continuing to work in production- replication protection is disabled during that process.
We have a point-in-time copy, a production copy, and the HA copy available at all times. – Joshua Osborne, Chief Technology Officer
With SAN replication, the backup process is at the disk layer and it’s hidden behind everything. The SAN is doing block level replication of the data as it’s changing. We focus on global mirror with change volumes which basically allows for asynchronous changes to be made. With a synchronous method, the Production system tells the Target system what changes have been made and then waits for it to implement those changes, resulting in a potential negative impact on performance. With the SAN replication, every block of data that gets updated on the SAN gets replicated to the Target SAN. 100% of the system that is getting committed to the Production disk gets copied onto the Target and because we use an asynchronous method, the Production system doesn’t have to wait for the Target to sync up.
Another benefit of SAN to SAN replication is reduced overhead. We don’t have a second IBM i operating system running on the Target side – only the disks are on. The Production system doesn’t know that the replication is happening because it’s all occurring behind the scenes. We can then take the backups and use the same methodology to create even more backups.
With the HA SAN, we have two copies of the customer data, one that’s in Production and one at the Target site and replication is happening. We pick a point in time where you want to make a backup and at that moment, we take a flash copy of that data set while the replication stays running, giving us a third copy of the data. That flash copy is then powered on to a different serial number and we take a backup. With that we have a 100% backup of the system taken to virtual tape, resulting in a fourth copy. Then a fifth copy is replicated offsite. So, we have a point-in-time copy, a production copy, and the HA copy available at all times.
Wow, that’s a lot of redundancy.
Yeah, because it gives us, and by extension the customer, the data protection we need. If we need to go back in time 6-7 years, we have data transactions available. It gives the customer all the uptime and access points to the data they need.
It sounds like the biggest advantage of SAN to SAN is its efficiency. Are there other major advantages to that methodology?
Sure, but just to go back to the topic of efficiency, when the customers are paying for processor and the licensing for that processing, and if the system is utilizing processor and memory to manage the replication, those are resources that are going into overhead. They’re having to pay for resources being used for protection versus for production. Whereas with SAN to SAN, that overhead is shifted over to the SAN and becomes our overhead, so they get more efficiency but also cost-effectiveness in their day-to-day operations.
In traditional software-based replication, journaling consumes disk space on both sides of the system, but with SAN replication, disk space isn’t being used on the Target system for journals so that’s less overhead the customer has to worry about. This all feeds into the speed of the backups, which makes the whole HA SAN system better, faster, and more efficient.
When customers do HA SAN with us, we still have processor and memory allocated to that Target side, it’s just powered off. We dedicate resources to that side because in the event of a disaster or if they need to roll swap, we have those resources available to power on for them immediately as opposed to having to look for and allocate them.
So that becomes a completely redundant system that only runs when you need it?
Correct. The way the disks work, only one system can write to them at a time. That’s why the other processor is turned off. The Production system is essentially writing to two sets of disks, one that’s local and one that’s offsite. And all of this is enabled through the HA SAN process. The Production system appears to be writing to only one set of disks, but the SAN is making a copy to the other set.
Abacus prides itself on designing reliable and powerful backup solutions. In part one of our interview, Josh Osborne walks us through why SAN to SAN Replication is not just the preferred method, but also the smartest method, of data backup. If you have questions about our data replication processes or would like to see a demo, contact us today! Be sure to come back next week for part two of our interview.