Since my blog entry on XtremIO last month, I have continued to work with an XtremIO storage array to drive snapshot and volume management commands. XtremIO has proven to be quite modern and sensible when it comes to management utilities, providing a few different intuitive solutions such as the GUI and REST API.
The logical constructs for the system make a lot of sense, with many familiar terms: volumes, snapshots, luns, consistency groups and initiators. Command verbs such as create, add, list, and delete makes management quick and easy too. But there is one command, Snapshot refresh, which is handled in a way that may be unfamiliar to those who have expertise with other arrays. Snapshot refresh with XtremIO is quite clever, fast, and easy to drive once you know the command required. Let’s take a look at how this works.
How a “Restore” is done in XtremIO
In many hard disk or partial-flash storage arrays, you will find software for creating snapshots which involves a source volume and a target volume or snapshot which is either pre-defined or created automatically. Creating a volume could take seconds or minutes, and when used for a snapshot the volume will contain pointers to the data represented by the point in time of the snapshot. When it is time to do a restore operation, a common technique is to have the data from that point in time copied back to the source volume, while access to that data during copying is provided through the snapshot’s pointer. Simply, you can think of a typical restore as being a copy from a volume which holds snapshot data back to the original volume.
On the XtremIO, users can go back to the point in time represented by a snapshot, but the action is a bit different than a restore. Because the XtremIO is an all-flash array and stores metadata entirely in memory, snapshot creation is instantaneous. Due to this, rather than running a copy operation to restore data from a snapshot to a volume, to “restore” from a snapshot you instead create a new snapshot, and set identifying information. With this operation, the snapshot that is associated with the point-in-time you want gets the SCSI ID and NAA of the source volume such that the hosts will see the data change while believing it is on the same volume.
Create Snapshot and Reassign
Whether using XtremIO’s REST API or CLI, the command and parameters are the same. Rather than calling a command such as “Snapshot Restore”, because the XtremIO creates a new snapshot and changes identifying information, the command to use is instead create-snapshot-and-reassign. Let’s look at the help output from the CLI on how to use this.
Similar in concept to a restore operation, we will be moving back to the data from a point-in-time, represented by a snapshot, by selecting which snapshot’s data we want with the “From” properties, and which volume’s identifying information we want with the “To” properties. When running create-snapshot-and-reassign you also get the added benefit of having the source data from right before the restore be preserved as another snapshot. If that is not needed, it can be automatically removed with the no-backup parameter.
Here’s an example of this same command (In the documentation it is also called Create Snapshot and Reassign) being used in the REST API.
POST https://<xtremio array>/api/json/v2/types/snapshots
Authorization: Basic YWRtaW46WHRyZW0xMA==
So, while the command’s name may be different from what you expect, as we “create” rather than “restore”, the naming makes sense when you consider what the operation actually does. In day-to-day use this task is no more complex than a restore operation from other arrays. Instead, you get lightening-fast volume refreshes and benefit from a new snapshot that holds the state of the volume from right before the refresh.