As I dive deeper into RecoverPoint, I decided to write few words about Consistency Groups (which were mentioned already in Journal Volume explanation) and Replication sets. Basically those two have to be explained to understand RecoverPoint protection concept.
If you want to protect data (represented by volumes) in RecoverPoint you have to use Consistency Groups. Consistency Group ensures that all writes to the production volume(s) are also written to the copy(ies) in correct write-order and in consistent way, so the copy can always be used instead of production volume. What if you want to protect only one Volume and give it CDP (local protection)? Then you create a Consistency Group with one production volume and one secondary volume. Easy example. But there are some examples when one data set is dependent on another one (example: database data and database log). In this case your Consistency Group is a great tool making sure that both database_data_volume and database_log_volume are in consistent state both on production and replicated site.
RecoverPoint copies are all volumes in a Consistency Group that are either:
- a source of replication (Production copy)
- a target (Local copy or Remote copy)
As you can see on above picture, all copies has its own Journal. If you are not sure why is it so, go back to Journal Volume post.
There are some limitations here:
- One production copy can have maximum four non-production copies per Consistency Group
- In local replication – limitation is one production copy for one local copy
- In remote replication – one production copy to four non-production copies (only if there is no local copy!). If local copy exist, up to three remote copy can co-exist in one Consistency Group.
- For RecoverPoint/SE there is a limit of one production + one copy.
Take a look at below picture of Consistency Group with one production copy, one local copy and one remote copy:
RecoverPoint Consistency Group
Consistency group is built from one or more replication sets. Each replication set consist of a production volume plus any local or remote copy volumes to which it is replicating. The number of replication sets in RecoverPoint system is equal to the number of production volumes being replicated. On the above picture (RecoverPoint Consistency Group) we have actually one replication set due to the fact there is only one production Volume. Based on limitations I mentioned above one replication set can have maximum 5 volumes: 1 production volume and up to 4 copy volumes. On above picture we have a replication set of one production volume + 1 local copy + 1 remote copy.
To give you a short summary, basically the RecoverPoint Protection (on already deployed RecoverPoint System) is to:
- define production volume(s)
- define copy volume(s)
- define Journal volumes
- Create at least one Consistency Group with number of replications sets equal to number of production volumes
Of course that’s just high level steps. You also need logical data transfer communication between production and replication copies -> Links.
In my last post I have explained a little bit Journal and Repository Volumes. If you know what those volumes as used for, you are aware that Journal Volumes hold poin-in-time history of the data. And in this short entry I would go a little bit into those point-in-time history.
Snapshot – as you can image, it’s a point-in-time snap, marked by the RecoverPoint system for recovery purposes. Within the EMC RecoverPoint a snapshot include only the data that has changed from the previous snapshot. The first Snapshot has all the changes between the moment of snapshot creation and
- current state – if only one snapshot is created
- next snapshot – if more snapshots are created
In other words – a snapshot is the difference between one consistent image of storage data and the next. In synchronous replication every write is a single snapshot. In asynchronous replication the RPA gathers several writes into a single snapshot (you can actually adjust that within the configuration.
Now, let’s get back for a second to EMC RecoverPoint – Introduction. As you know, the replication can be local or remote (or both!). Now, each Replica has its own Journal, so if you have same customer data replicated both locally and remote, you can have different policies for those two! For example synchronous replication for local protection and async replication for remote one.
Bookmark – a bookmark is a text label that is applied to a snapshot. In other way if you wish to manually create a snapshot and name it – boom, that’s it – you have a bookmark. You can create those if you need to have a specific point-in-time, e.g. right before the application upgrade, or right before the maintenance break etc.
As you can see on above print-screen, we have an example list of Snapshots, some of them have names, which makes them Bookmarks. Simple as that.
Last week I have created a post describing EMC RecoverPoint Architecture – mostly from hardware point of view. This time I would like to go a little bit into software. As you already known, an RPA (RecovePoint Appliance) manages all aspects of data protection for a storage group, such as maintining the images in the Journal Volumes. But what are Journal Volumes? What is the Repository Volume? Let me answer those in this short post
The Repository Volume is a special type of volume which is dedicated on the SAN-attached storage for each RPA Cluster. Important to remember – one Repository Volume for each RPA Cluster. This volume stores configuration information about the RPAs and Consistency Groups. It is used, for example, during one of the RPA failure in a cluster, when rest of RPAs (within same cluster) are taking over its job. Beside the function, Repository Volume, is a normal volume, that can be provisioned from example from VNX. Although it should not be a thin LUN (rather thick, or traditional RAID LUN). In addition – the volume cannot be located on a VPLEX distributed device
Journal Volumes are very much connected with Consistency Group term, that I will describe a little bit better later. For now you can think of Consistency Group as a group of volumes, the CG ensures that updates to the production volumes are also written to the copies in consistent and correct write-order. Consequence: Copies are always consistent. Now – back to the Journal Volumes. Each copy of data in a Consistency Group must contain at least one volume that is dedicated to hold poin-in-time history of the data. Journal volumes hold snapshots of data to be replicated – holding as many poin-in-time images as the capacity allows. There are two types of journal volumes:
- Replica (Copy) Journal(s)
- Production Journal(s) – this one is more-or-less not used during normal operation, however it is necessery and being used when the relationship is promoted to secondary side.
Journal Volume cannot be masked to host(s) – only RPAs in the cluster should have access to it.
In synchronous replication, every write is retained in the replica journal, so you can recover to any point in time. In asynchronous replication, several writes are grouped in a single snapshot. The granularity for async replication can be set to seconds or MBs.
RecoverPoint Consistency Group
Above you see the example of both CPD and CRR replication. As you can see we have three Journal Volumes:
- two Replica (Copy) Journals
- one Production Volume
As I mentioned above, normal operation doesn’t include Production Journal Volume, both CDP Replica Volume and CRR Replica Volume are used for communication between RPA (in this case vRPA) and Storage.