Backups, snapshots, cloning and replication are all valuable ways of protecting the organisation’s data.
In this article, we’ll look at replication, in particular between storage arrays. Key to this will be to define it and present the pros and cons of replication with reference to other methods of data protection.
All too often in IT there’s a lack of clarity over what exactly a technology is, or does. The latter is the important bit, because it’s how different technologies function that can determine how they fit together.
Replication is fundamentally a method of producing a clone of a unit of storage. In other words, it is a replica of a drive, volume or logical unit number (LUN), for example. In most cases, what is being strived for is an exact copy – maybe almost immediately, maybe just eventually.
That makes a clone or replica different from a snapshot, because snapshots in most cases can only become a usable replica following some sort of rebuilding process. That’s because snapshots comprise an original copy of the drive or volume plus updates to it, as well as perhaps deleted blocks that have to be reincorporated to create an accurate copy from a previous point in time.
The idea is that snapshots can be re-built and rolled back pretty quickly, but they’re not there as an alternative, usable copy of the source media. Meanwhile, clones and replicas often are.
The simplest clone/replica of all is when, for example, a developer needs a database to run some test queries on. They can clone an exact copy of an existing production database and do what they want with it in the test environment. That clone will be an exact replica of the database at the point in time it was created, but it will not likely ever reflect any further changes to the source copy.
But at the other end of the scale in terms of creating an available, working clone is synchronous replication. This sees data written to two or more units of storage as near to simultaneously as possible to provide a working copy that can be failed over to on-the-fly.
Obviously this comes at a price in terms of cost and technical complexity and there are limitations, as we shall see. But this is often what we mean when we talk about replication.
Can replication replace backups? The simple answer is no. Backups and replication (and maybe snapshots too) have to complement each other.
Because replication can be almost continuous and creates a near real-time copy, it can also make a replica of corrupted or infected files. In that case, you need a version to roll back to.
That could be derived from a snapshot, but then they also need to be underpinned by backups – and replication is often costly, so it may be that only certain datasets are replicated while everything is backed up.
In synchronous replication, data can be written to the second site as soon as it hits cache in the primary site. On receipt, the second site sends an acknowledgement to the primary site storage and the host where the change originated. It’s the method of replication that comes as close to writing multiple copies of data as near to simultaneously as possible.
Synchronous replication is often the preserve of the most high-end block storage arrays.
Asynchronous replication adds a stage to the process, by acknowledging the host at the primary site when the data is written. Then the write is sent to the second site, which acknowledges that write back to the primary site array. Asynchronous replication is found in a wider range of storage products, such as iSCSI storage, network-attached storage (NAS), and so on.
Replication over great distances starts to suffer from about 1 millisecond of latency per 100 miles, and suppliers often recommend no more than a few hundred miles round trip.
For that reason, synchronous replication can have more of an impact on application performance. It demands acknowledgement before the next input/output (I/O) can take place, whereas asynchronous replication acknowledges locally so the next change can take place, with movement of data delayed. Of course, that also means the two data sets will differ for a longer time.
A real-world replication strategy might use a combination of synchronous replication – for the most critical elements of an application such as redo logs – while less critical data that could be restored goes via asynchronous. Snapshots could form part of the mix too, but it would all need to be underpinned with regular backups.
Here we have dealt primarily with synchronous and asynchronous replication in storage arrays.
Other forms of replication exist, such as:
07 May 2020