We have just released the new XtremIO, 6.3 version with some big enhancements, so let’s dive into each one of them!
XtremIO Remote Protection
XtremIO Metadata-Aware Replication
XtremIO Metadata-Aware Asynchronous Replication leverages the XtremIO architecture to provide the most efficient replication that reduces the bandwidth consumption. XtremIO Content-Aware Storage (CAS) architecture and in-memory metadata allow the replication to transfer only unique data blocks to the target array. Every data block that is written in XtremIO is identified by a fingerprint which is kept in the data block’s metadata information.
- If the fingerprint is unique, the data block is physically written and the metadata points to the physical block.
- If the fingerprint is not unique, it is kept in the metadata and points to an existing physical block.
A non-unique data block, which already exists on the target array, is not sent again (deduplicated). Instead, only the block metadata is replicated and updated at the target array.
The transferred unique data blocks are sent compressed over the wire.
XtremIO Asynchronous Replication is based on Snapshot-shipping method that allows XtremIO to transfer only the changes, by comparing the changes between two subsequent Snapshots, benefiting from write-folding.
This efficient replication is not limited per volume, per replication session or per single source array, but is a global deduplication technology across all volumes and all source arrays.
In a fan-in environment, replicating from four sites to a single target site, as displayed in Figure 14, overall storage capacity requirements (in all primary sites and the target site) are reduced by up to 38 percent, providing the customers with considerable cost savings.
- Global Data Reduction with XtremIO Metadata-Aware Replication
XtremIO Synchronous Replication (new to 6.3)
XtremIO enables to protect the data both asynchronously and synchronously when ‘zero data loss’ data protection policy is required.
XtremIO Synchronous replication is fully integrated with Asynchronous replication, in-memory snapshots and iCDM capabilities, which makes it the most efficient.
The challenge with Synchronous replication arises when the source and target are out of sync. This is true during the initial sync phase as well as when a disconnection occurs due to link failure or a user-initiated operation (for example, pausing the replication or performing failover).
Synchronous replication is highly efficient as a result of using these unique capabilities:
- Metadata-aware replication – For the initial synchronization phase and when the target gets out of sync, the replication is using the metadata-aware replication to efficiently and quickly replicate the data to the target. The replication is using multiple cycles until the gap is minimal and then switches to synchronous replication. This reduces the impact on the production to a minimum and accelerates the sync time.
- Recovery Snapshots – to avoid the need for a full copy or even a full metadata copy, XtremIO leverages the in-memory snapshots capabilities. Every few minutes recovery-snapshots are created on both sides, which can be used as a baseline in case a disconnection occurs. When the connection is resumed, the system only needs to replicate the changes made since the most recent recovery snapshot prior to the disconnection.
- Prioritization – In order to ensure the best performance for the applications using Sync replication, XtremIO automatically prioritizes the I/O of Sync replication over Async replication. Everything is done automatically and no tuning or special definition is required.
Auto-Recovery from link disconnection– The replication resumes automatically when the link is back to normal.
XtremIO Synchronous replication is managed at the same location as the Asynchronous replication and supports all Disaster Recovery operations similarly to Asynchronous replication.
Switching between Async to Sync is simply performed using a single command or via the UI as can be seen below
Once changed, you can also see the new replication mode in the remote session view
XtremIO replication efficiency allows XtremIO to support the replication for All-Flash Arrays (AFA) high performance workloads. The replication supports both Synchronous replication and Asynchronous replication with an RPO as low as 30 seconds and can keep up to 500 PITs.. XtremIO offers simple operations and workflows for managing the replication and integration with iCDM for both Synchronous and Asynchronous replication:
- Test a Copy (Current or specific PIT) at the remote host –
Testing a copy does not impact the production and the replication, which continues to replicate the changes to the target array, and is not limited by time. The “Test Copy” operation is using the same SCSI identity for the target volumes as will be used in case of Failover.
- Failover –
Using the failover command, it is possible to select the current or any PIT at the target and promote it to the remote host. Promoting a PIT is instantaneous.
- Failback –
Fails over back from the target array to the source array.
- Repurposing Copies –
XtremIO offers a simple command to create a new environment from any of the replication PITs.
Refresh a Repurposing Copy –
With a single command, a repurpose copy can be refreshed from any replication PIT. This is very useful when refreshing the data from the production to a test environment that resides on a different cluster or when refreshing the DEV environment from any of the existing build versions.
- Creating a Bookmark on demand –
An ad-hoc PIT can be created when needed. This option is very useful when an application-aware PIT is required or before performing maintenance or upgrades.
- Creating a Bookmark on demand –
Unified View for Local and Remote Protection
A dedicated tab for data protection exists in the XtremIO GUI for managing XtremIO local and remote protection (Sync & Async replication). In the Data Protection Overview screen, a high level view displays the status for all Local and Remote protections, as shown in Figure 15.
- Data Protection Overview Screen
The Overview section includes:
- The minimum RPO compliance for all Local and Protection sessions
- Protection sessions status chart
- Connectivity information between peer clusters
From the overview screen it is easy to drill down to the session
Consistency Group Protection View
With the new unified protection approach in one view it is easy to understand the protection for the consistency group. The Topology View pane displays the local and remote protection topology of the Consistency Group, as shown in Figure 16. Clicking each of the targets displays the detailed information in the Information pane.
The purpose of this feature is to allow a customer to protect snapshots created by a “Local Protection Session” against an accidental user deletion:
- Once a “Local Protection Session” creates the snapshot, it is automatically marked as “Secured”
- The snapshot’s protection will expire once the snapshot is due for deletion by its retention policy
Once a “Local Protection Session” is set as create secured snapshots:
- It cannot be set to create non-secure snapshots
Once a snapshot is set as “Secured”:
- The snapshot cannot be deleted
- The snapshot-set containing this snapshot cannot be deleted
The contents of this snapshot cannot be restored nor refreshed
Secured Snapshots – Override
- Require Case – Legal Obligation
New XMCLI Command
- Tech-Level Command
- To remove the “secured” flag, a formal ticket must be filed to DellEMC.
- This is a legal obligation!
Once filed, a technician level user account can use the new “remove-secured-snap-flag” XMCLI command to release the “secure” flag.
Secured Snapshots – Examples – Create a Protected Local Protection
The following output displays the creation of a new “Local Protection Session” with a “Secured Flag” setting
The following output displays the modification of an existing “Local Protection Session” to start creating snapshots with a “Secured Flag” setting
Secured Snapshots – Examples – Snapshot Query & Release
The first output displays the query of the properties of a “Secured Snapshot”
The second output displays an attempt of deleting a “Secured Snapshot”
The third output displays how to release the “Secured” flag (using a tech level user account)
Below, you can also see how a created protection policy on a consistency group look like when you decide to not allow the option to delete the snapshot
And this is the error you will get if you (or someone else) will try to remove this volume
IPv6 Dual Stack
- Dual IP Versions (4 & 6)
- External IPv4 & IPv6
- Internal IPv4 or IPv6
- iSCSI IPv4 & IPv6
Native Replication IPv4 Only
This feature allows a customer to assign multiple IP addresses (IPv4 and IPv6) to a single interface
Let’s discuss the different network interfaces used in XtremIO and see what changed
XMS Management traffic is used to allow a user to connect to various interfaces (such as WebUI, XMCLI, RestAPI, etc.)
Previously, the user could configure either an IPv4 or an IPv6 IP Address.
The new feature allows assigning two IP Addresses – One of each version
XMS Management traffic is also used internally to connect to clusters (SYM and PM)
The behavior on this interface wasn’t changed – All managed cluster should use the same IP version
Storage Controllers’ iSCSI traffic allows external host connectivity
Previously, the user could only configure IP addresses from a single IP version
The new feature allows assigning multiple IP Addresses with different versions
Native Replication behavior remains the same – These interfaces are limited to IPv4 IP addresses
IPv6 Dual Stack – XMS Management – New XMCLI commands
Multiple parameters were added to the “show-xms” XMCLI command to support this feature:
Figure 1 Two new parameters which determine the IP versions
Figure 2: The “Primary IP Address” parameter names remained as is (to conform with backward-compatibility requirements)
Figure 3: Various new parameters to describe the new “Secondary IP Address”
Two additional XMCLI commands were introduced to support this feature:
Figure 1 The “add-xms-secondary-ip-address” XMCLI command sets the XMS management interface “Secondary IP Address” and “Secondary IP Gateway”
The “remove-xms-secondary-ip-address” XMCLI command removes the XMS management interface “Secondary IP Address” and “Secondary IP Gateway”
Note that there is no “modify” command – To modify the secondary IP address, remove and set it again with its corrected values.
IPv6 Dual Stack – Storage Controller Management – Interfaces
To support the changes made to the Storage Controllers’ iSCSI interfaces settings, the following changes were implemented:
- Per “iSCSI Portals” – The user can now configure multiple iSCSI portals with different IP versions on the same interface
Per “iSCSI Routes” – The user can now configure multiple IPv4 and IPv6 iSCSI routes
As explained earlier, the Storage Controller Native Replication interface behavior remains as is – The interfaces only allow IPv4 IP addresses.
The new 6.3.0 release supports an increased number of objects:
- Number of volumes and copies (per cluster) was increased to 32K
Number of SCSI3 Registrations and Reservations (per cluster) was increased to 32K
Below you can see a demo, showing how to configure Sync Replication from the GUI
And here you can see how Sync replication works with VMware SRM in conjunction with our unique point in time failover in case where you don’t want to failover to the last point in time