Snapshot Changes in XtremIO X2

I've written previously about how Snapshots (and snapshot refresh) works in XtremIO.  With XtremIO X2 we changed the way a few of the snapshot-related concepts work in order to simplify things, as well as to add some additional use cases that were not possible previously.

XtremIO X1 Snapshots

First, some history. As per the blog post listed above, taking a snapshot on X1 always resulted in a "Snapshot Set" being created.  This Snapshot Set could then be used to create a new snapshot, or as a part of a snapshot refresh.  A "Consistency Group" in X1 was only used as the source of a snapshot or refresh.  Refresh was allowed between Consistency Group and Snapshot Sets, or between Snapshots Sets and other Snapshot Sets (as long as they were both taken from the same CG tree).

When taking a snapshot with X1, you had the choice of a read-only or a read-write snapshot.  The two acted basically the same, except that a read-only snapshot couldn't be refreshed (and obviously, was read-only when presented to a host).

XtremIO X2 Snapshots

In X2, the general terms remain the same.  We still have "Consistency Groups" and we still have "Snapshot Sets", but their use is a little different.

A Consistency Group is still a group of one or more volumes.  It's now used for more than just snapshots (such as Native Replication and QoS), but fundamentally it's similar to in X1.

Snapshot Sets still exist, but their use has changed a little, and they are now generally only used for "Protection" copies.

The most obviously change when you come to take a snapshot of a Consistency Group is that the term "snapshot" has been removed from the GUI, and instead you have the option of a "Protection Copy" or a "Repurpose Copy", which correspond to a read-only snapshot and a read-write snapshot respectively.  However there are more differences between the two than just that...

Protection Copy

As the name implies, a protection copy creates a copy of your volumes that can be used for "protection" - a read-only "backup"-style copy of your volumes.  As with in previous versions, taking a protection copy of a CG will result in a Snapshot Set being created for the resulting volumes, and you will be able to specify the name of that Snapshot Set during the process.

As we're taking a Protection Copy, the resulting volumes will be read-only (displayed as "Read-Access" in the GUI)

As this is a read-only copy, there is no option to refresh the snapshot - refreshing really only make sense when the volumes have been mapped to a host and you want to update the data on them, which generally won't be a how a protection copy is used.  If you want to update a protection copy, you can just take a new protection copy of the volumes.

Repurpose Copy

A Repurpose Copy is a copy of data you are going to "repurpose" for a new use, such as a development copy. As a result, it's a full read-write copy of the volumes, and is exactly equivalent (at the volume/snapshot level) to taking a read-write snapshot in previous versions.

The big difference between Repurpose Copy and a read-write snapshot is that instead of the resulting snapshots being grouped into a Snapshot Set as in previous versions, they are instead put into a new Consistency Group, or what is sometimes referred to as a "Linked Consistency Group" on the grounds that it is "linked" to the original CG that it was taken from.

After creating the Repurpose Copy we will have 2 Consistency groups - the one we took the snapshot of (OracleProd), and the new one (OracleDev1) containing the newly created read-write snapshots.

Refreshing a Snapshot

Repurpose copies can be refreshed just like read-write snapshot sets could be previously - just select the Consistency Group you want to refresh, and select "Refresh Selected" from the Repurpose menu.

When doing a refresh, you will by default only be given the option to refresh FROM another Consistency Group - either the original source CG, or another repurpose copy.  If instead you want to refresh from a read-only Protection Copy it's just matter of selecting the "Enable advance mode" checkbox during the wizard at which point you'll also be given the option of refreshing from a Snapshot Set.

In X2 when refreshing a Consistency Group, the name of the CG is NOT changed as a part of the process.  This is different to X1, where the name of the snapshot set was changed with each refresh, and additional steps - such as renaming the resulting snapshots set - were often required to keep the name the same.  This makes programmatically refreshing a snapshot much easier than before, as you will always be refreshing the same objects, without the need to use tags or rename the resulting objects as was required with X1.

CLI

New CLI commands have been added to match the above operations :

create-protection-copy - Creates a new read-only Protection Copy, along with a new Snapshot Set

create-repurpose-copy - Creates a new repurpose copy, along with a new (Linked) Consistency Group

refresh-data - Refreshes a read-write snapshot (Consistency Group) from either a another consistency group (original volume or another repurpose copy) or from a snapshots set (protection copy)

REST API

There have been a number of changes to the REST API, so I'll cover those in another post (coming soon...)

Backwards Compatibility

As a part of these changes, we wanted to maintain backwards compatibility for any CLI or REST API scripts that people were using on X1 systems.

In order to do this, X2 systems will act in a 'backwards compatible' mode if the older X1 CLI or REST API commands are used to create or manipulate snapshots.  For example, the X1 'create-snapshots' CLI command continues to exist and acts exactly as it did in X1 - a new snapshots set will be created even when creating a read-write snapshot (and NOT a new consistency group as would be created when using the new create-repurpose-copy command).  The same is true for the 'create-snapshot-and-reassign' command that was previously used for refreshing snapshots, which continues to work exactly as it did previously.

In order to get this backwards compatibility, it's important to use ONLY the old-style commands with these copies, and not jump between the old and new mechanisms.  Where this can be a little difficult is when creating the initial snapshot.  Many people will use the GUI to create a snapshot, but then use the CLI or REST API to refresh it (normally as a part of an automated workflow). This will NOT work with X2, as the GUI will follow the new mechanism for creating the snapshot (resulting in a CG being created rather than a snapshots set).  The workaround is simply to create the original snapshot using the create-snapshot CLI command rather than using the GUI, in order to get the old-style functionality.