9 - Unity My Guide

This module focuses on the Snapshots and Replication features of Unity that provide data protection.
It
provides an overview of the Snapshots and Replication features, examines their architectures, use cases
and capabilities. Snapshot and replication creation of LUNs and file systems are covered and their specific
operations are performed.
Copyright © 2017 Dell Inc. Data Protection 1

This lesson covers an overview of the Snapshots feature of Unity. It provides information on what a
Snapshot is, what storage resources can be snapped, how Snapshots are used, the feature architecture
and its capabilities on the various Unity models.

The Unity Snapshots feature is enabled with the Local Copies license for Unity that enables space efficient
point-in-time snapshots of storage resources for Block, File and VMware. The snap images can be read-
only or read/write and used in a variety of ways. They can provide an effective form of local data
protection to restore the production data to a known point-in-time data state should data be mistakenly
corrupted or deleted by the users. Images can be accessed by hosts for data backup operations, data
mining operations, application testing, or decision analysis tasks. In the upcoming slides we will dive into
the details of its architecture, capabilities, benefits, and specifics of its operations and uses.
Note: Snapshots are not full copies of the original data. It is recommended that you do not rely on
snapshots for mirrors, disaster recovery, or high-availability tools. Because snapshots of storage
resources are partially derived from the real-time data in the relevant storage resource, snapshots can
become inaccessible (not readable) if the primary storage becomes inaccessible.

Snapshots of storage resources (block LUNs, file systems, and VMware Datastores) are architected using
Redirect on Write technology. This architecture avoids a performance penalty that Copy on First Write
technology has when existing data is changed. With Redirect on Write technology, (click) when a
snapshot is taken, the existing data on the storage object remains in place and provides the snapshot
point-in-time view of the data. (click) Production data access also uses this view to read existing data.
Another benefit of Redirect on Write is that no storage resource is needed to create a snapshot. With
Copy on First Write technology, a storage resource had to be reserved to hold original data that changed
to preserve the point-in-time view. As its name implies, with Redirect on Write technology, (click) when
writes are made to the storage object, those writes are redirected to a new location allocated as needed
from the parent pool in 256 megabyte stripes. New writes are stored in 8 kilobyte chunks on the newly
allocated stripe. (click) Reads of the new writes are serviced from this new location as well.
If the snapshot is writable, (click) any writes are handled in a similar manner; stripe space is allocated
from the parent pool and the writes are redirected in 8 kilobyte chunks to the new space. (click) Reads of
newly written data are also services from the new space.
(click) Storage space is needed in the pool to support snapshots as stripes are allocated for redirected
writes. (click) Because of the on-demand stripe allocation from the pool, snapped thick file systems will
transition to thin file system performance characteristics.

A LUN Consistency Group (CG) (click) is a grouping of multiple LUNs to form a single instance of LUN
storage. They are primarily designed for a host application that will access multiple LUNs, like a database
application. Snapshots (click) provide a mechanism for capturing a snapshot of the multiple LUNs within a
consistency group. When a Consistency Group Snapshot is taken, the system will complete any
outstanding IO to the group of LUNs, then suspend writes to the LUNs until the snap operation completes.
This allows the snapshot to capture a write-order consistent image of the group of LUNs.

With Unity Snapshots, it is possible to create multiple snapshots of a LUN to capture multiple point-in-time
data states. (click) In this example the 3 o’clock and the 4 o’clock snapshots are two different “child”
snapshots of a common parent; meaning they capture two different data states of a common storage
object.
It is also possible to copy a snapshot. (click) In this example, the 4 o’clock snapshot is copied and other
than having a unique name, the copy will be indistinguishable from the source snapshot and both capture
identical data states.
(click) Multiple hosts can be attached to any specific LUN Snapshot or multiple snapshots within the tree.
When a host is attached to a Snapshot for access to its data, the attach can be defined for read-only
access or read/write access. In the example, a host attaches to the 3 o’clock Snapshot for read-only
access and will remain unmodified from it’s original snapped data state. A different host will be attached to
the 4 o’clock Snapshot copy for read/write access. By default, the system will optionally create a copy of
the snapshot to preserve its original data state. (click) When the snap is read/write attached, its data state
is marked as modified from its source.
(click) It is also possible to nest copied read/write attached snapshots that form a hierarchy of snapshots
to a maximum of 10 levels deep.

As with LUN snapshots, it is possible to create multiple snapshots of a file system to capture multiple
point-in-time data states. (click) The 3 o’clock and the 4 o’clock snapshots in this example are two
different “child” snapshots of the same file system parent and capture its two different point-in-time data
states.
(click) Snapshots of a file system can be created either as read-only or read/write and are accessed in
different manners which will be covered later.
(click) Copies of snapshots are always created as read/write snapshots. The read/write snapshots can be
shared by creating an NFS export or SMB share to them. When shared, they are marked as modified to
indicate their data state is different from the parent object.
(click) It is also possible to nest copied and shared snapshots that form a hierarchy of snapshots to a
maximum of 10 levels deep.

The table defines a variety of combined Snapshot capabilities for each of the Unity models. These
combined limits have an interaction between each other. For example, if a Unity 300 system had 20 LUNs
and 20 file systems, each LUN and file system could not have 256 user snapshots because that would
exceed the maximum user snapshots of 8000 for the system.

This lesson covers the creation of block and file Snapshots. It also details using a schedule for creating
Snapshots. The operations that can be performed on Snapshots are also shown.

Snapshots are created on storage resources for Block, File and VMware. And all are done in a similar
manner.
For Block, the snapshot is created on a LUN or a group of LUNs in the case of a Consistency Group. For
File, the snapshot is configured on a file system. For VMware the storage resource is either going to be a
LUN for a VMFS datastore or a file system for an NFS datastore. When creating each of these storage
resources, the Unity system provides a wizard for their creation. Each wizard provides an option to
automatically create snapshots on the storage resource. Each resource snapshot creation is nearly
identical to the other resources.
For storage resources already created, snapshots can be manually created for them from their Properties
page. As with the wizard, the snapshot creation from the storage resource Properties page is nearly
identical to the other resources. The following few slides will show snapshot creation within the Block
storage LUN creation wizard and the File storage file system creation wizard. It will also show creating
manual snapshots from the LUN and file system Properties pages.
Video demonstrations will be provided showing all forms of storage resource snapshot creation.

LUN snapshots can easily be created in a number of ways. Within the wizard to create LUNs, (click) there
is an option to automatically create snapshots for the LUN based on a schedule.
(click) The wizard contains a dropdown selection that has three different system defined schedules to
select from to create the LUN snapshots. Within each schedule there is also a snapshot retention value.
(click) A customized schedule can also be created for use. The scheduler provides the ability to configure
a snapshot frequency by the hour, day or week. A snapshot retention policy can also be defined.
Note: fields annotated with a red asterisk are required for the configuration.

For existing LUNs, snapshots are easily created from the LUN Properties page by (click) selecting the
Snapshots tab.
(click) Select the + icon to create a snapshot of the LUN. The snapshot must be configured with a name;
by default the system provides a name having a year, month, day, hour, minute, second format.
Customized names can also be configured. A Description field for the snapshot can optionally be
annotated. One of three Retention Policies must be configured. The default retention configuration is the
Pool Automatic Deletion Policy which will automatically delete the snapshot if Pool space reaches a
specified capacity threshold. A customized retention time can alternately be selected and configured for
snapshot deletion on a specified calendar day and time. The other alternative is to select the No Automatic
Deletion option should the snapshot need to be kept for an undetermined amount of time.

Similar to LUNs, file system snapshots can easily be created in a number of ways. Within the wizard to
create a file system, (click) there is an option to automatically create snapshots for the file system based
on a schedule. File system snapshots created by a schedule are read-only.
(click) The wizard contains a dropdown selection that has three different system defined schedules to
select from to create the file system snapshots. Within each schedule there is also a snapshot retention
value.
(click) A customized schedule can also be created for use. The scheduler provides the ability to configure
a snapshot frequency by the hour, day or week. A snapshot retention policy can also be defined.
As noted before, fields annotated with a red asterisk are required for the configuration.

Similar to the LUN snapshot seen earlier, existing file systems snapshots are easily created from the file
system Properties page by (click) selecting the Snapshots tab. A manually created file system snapshot
can be read-only or read/write.
(click) Select the + icon to create a snapshot of the file system. The snapshot must be configured with a
name; the system by default provides a name based on the creation time in a year, month, day, hour,
minute, second format. Customized names can also be configured. An optional Description field for the
snapshot can be annotated. One of three Retention Policies must be configured. The default retention
configuration is the Pool Automatic Deletion Policy which will automatically delete the snapshot if Pool
space reaches a specified capacity threshold. A customized retention time can alternately be selected and
configured for snapshot deletion on a specified calendar day and time within a year of creation. The other
alternative is to select the No Automatic Deletion option should the snapshot need to be kept for an
undetermined amount of time.
The Access Type section requires configuration by selecting one of the two options for the snapshot to be
created read-only or read/write.

The system’s user interface provides a Snapshot Schedule page that lists all the system and user defined
schedules and if they are in use. The user defined schedules can be edited from this page but the system
defined schedules cannot be edited. User defined schedules can be created using a frequency granularity
of hours, daily or weekly and be retained for 31 days.
(click) Additional user defined schedules can be created as shown here. This example shows a schedule
that will create weekend snapshots that will be created at midnight and retained for two weeks.

To apply a snapshot schedule to a storage resource, (click) simply go to the Snapshots tab on the
Properties page of the resource and (click) select the Schedule Snapshot option. (click) From the
Snapshot schedule dropdown list select the desired schedule to apply to the resource.

The operations that can be performed on a snapshot differ based on the type of storage resource the
snapshot is on. (click) Operations on LUN-based snapshots are Restore, Attach to host, Detach from
host, and Copy. (click) Operations on file system-based snapshots are Restore and Copy.

The Snapshot Restore operation will roll back the storage resource to the point-in-time data state that the
snapshot captures. In this Restore example, a LUN is at a 5 o’clock data state and is going to be Restored
from a snapshot with a 4 o’clock data state.
(click) Before performing a restore operation, detach hosts attached to any of the LUN snapshots. (click)
Also ensure that all hosts have completed all read and write operations to the LUN you want to restore.
(click) Finally disconnect any host accessing the LUN. This may require disabling the host connection on
the host-side.
(click) Now the Restore operation can be performed. From the 4 o’clock snapshot select the Restore
operation. (click) The system will automatically create a snapshot of the current 5 o’clock data state of the
LUN to capture its current data state before the restoration operation begins. (click) The LUN is restored
to the 4 o’clock data state of the snapshot.
The hosts can now be reconnected to the resources they were connected to prior to the restore and
resume normal operations.

The Restore operation is accessed from the Properties page of the storage resource. (click) Select its
Snapshots tab then select the snapshot to restore from. (click) The Restore operation is accesses from
the More Actions dropdown list. (click) The system will create a restore point snapshot of the current data
state of the LUN prior to the restoration operation. (click) Once complete the new restore point snapshot
is listed.

The Snapshot Attach to Host operation will attach a connected host to a LUN snapshot. In this Attach
example, a secondary host is going to Attach to the 3 o’clock snapshot of the LUN.
(click) Before performing an Attach to host operation, the host being attached will need to have
connectivity to the Unity array.
Now the Attach operation can be performed. (click) The first step is to select a snapshot to attach to.
(click) The next step is to select an Access Type, either Read-Only or Read/Write. (click) Then the host
or hosts are selected to be attached. (click) Next, the system will optionally create a copy of the snapshot
if a Read/Write Access Type was selected. Thus preserving the data state of the snapshot prior to attach.
(click) Finally, the selected host is attached to the snapshot with the Access Type selected.

To attach a host to a snapshot of a LUN, from the Snapshots tab of the LUN Properties page (click) select
a snapshot to attach to. In this example the Monday_AM_snap is selected. From the (click) More Actions
dropdown, select the Attach to host operation. (click) The Attach to Host window opens, (click) use its +
icon to add hosts and configure the access to the snap. (click) Configure the snapshot Access Type which
can be Read-Only or Read/Write. In this example Read/Write will be selected. (click) Next select the host
or hosts to be attached to the snapshot. In this example WIN10B will be selected for access.

The attach configuration is displayed. (click) In this example WIN10B will be attached to the
Monday_AM_snap with Read/Write access. (click) By default, the system will optionally create a copy of
the snapshot being attached with Read/Write access to preserve its original point-in-time data state.
(click) The snapshot will be attached to the host and its attach status is displayed.

The Snapshot Detach operation will detach a connected host from a LUN snapshot. In this Detach
example, a secondary host is going to Detach from the 3 o’clock snapshot of the LUN.
(click) Before performing an Detach operation, allow any outstanding read/write operations of the
snapshot attached host to complete.
(click) Now the Detach operation can be performed. From the 3 o’clock snapshot, select the Detach from
host operation. (click) The secondary host is detached from the 3 o’clock snapshot of the LUN.

The Detach from host operation is accessed from the Snapshots tab on the Properties page of the storage
resource. (click) Select the snapshot to detach from. (click) The action for Attach to host and Detach from
host are mutually exclusive operations. (click) The Detach from host operation is only available for
snapshots that are attached. Perform the Detach from host operation by selecting it from the More Actions
dropdown list. (click) In the Detach confirmation window, confirm the detach operation to complete the
operation.

The Snapshot Copy operation (click) will make a copy of an existing snapshot that is either attached or
detached from a host. The copy will capture the existing data state of the snapshot it copies. In this Copy
example, (click) a copy of an existing 4 o’clock snapshot is being made (click). The copy inherits the
parent snapshot data state of 4 o’clock and its retention policy.

The Copy operation is accessed from the Snapshots tab on the Properties page of the storage resource.
(click) Select the snapshot to copy. (click) Perform the Copy operation by selecting it from the More
Actions dropdown list. (click) The system will provide a unique name for the snapshot copy based on the
time of creation or optionally a customized name can be assigned.

The Snapshot Restore operation for a file system is similar to the Restore operation of a LUN. It will roll
back the file system to a point-in-time data state that a read-only or read/write snapshot captures. In this
Restore example, a file system is at a 5 o’clock data state and is going to be Restored from a read-only
snapshot with a 4 o’clock data state.
(click) Before performing a restore operation, disconnect clients from any of the file system snapshots.
(click) Also quiesce IO to the file system being restored.
(click) Now the Restore operation can be performed. From the 4 o’clock snapshot select the Restore
operation. (click) The system will automatically create a snapshot of the current 5 o’clock data state of the
file system to capture its current data state before the restoration operation begins. (click) The file system
is restored to the 4 o’clock data state of the snapshot.
The connections and IO to the resources can now be resumed for normal operations.

The Restore operation is accessed from the Properties page of the storage resource. (click) Select its
Snapshots tab then select the snapshot to restore from. (click) The Restore operation is accesses from
the More Actions dropdown list. (click) The system will create a restore point snapshot of the current data
state of the file system prior to the restoration operation. (click) Once complete the new restore point
snapshot is listed.

The Snapshot Copy operation (click) will make a copy of an existing file system snapshot that is either
read-only or read/write shared or unshared. The copy will capture the existing data state of the snapshot it
copies. In this Copy example, (click) a copy of an existing 4 o’clock read-only snapshot is being made
(click). The copy will be read/write and inherits the parent snapshot data state of 4 o’clock and its
retention policy.

The Copy operation is accessed from the Properties page of the storage resource. (click) Select its
Snapshots tab then select the snapshot to copy. (click) Perform the Copy operation by selecting it from
the More Actions dropdown list. (click) The system will provide a unique name for the snapshot copy
based on the time of creation or optionally a customized name can manually assigned.

This lesson covers the use of Snapshots. It details accessing block and file snapshots. It also shows how
the Checkpoint Virtual File System is accessed by Windows and NFS users to restore corrupted or
deleted files.

The process of accessing a LUN snapshot requires performing tasks on the storage system and on the
host that will access the snapshot.
(click) A host has to have connectivity to the storage, either via fibre channel or iSCSI, and be registered.
(click) Next, from the Snapshots tab, a snapshot is selected and the snapshot operation Attach to host
needs to be performed.
Now tasks from the host will need to be done. (click) The host will need to discover the disk device that
the snapshot presents to it. (click) Once discovered, then the host can access the snapshot as a disk
device.
A short video follows that demonstrates a host accessing a LUN snapshot.

The process of accessing a file system read/write snapshot (click) requires performing tasks on the
storage system and on the client that will access the snapshot.
(click) On the storage system an NFS and/or SMB share will have to be configured on the read/write
snapshot of the file system. This task is done from their respective pages.
Now tasks from the client will need to be done. (click) The client will need to be connected to the
NFS/SMB share of the snapshot. (click) Once connected, then the client can access the snapshot shared
resource.
A short video follows that demonstrates client access to a file system snapshot.

The process of accessing a file system read-only snapshot is very different than accessing a read/write
snapshot. The read-only file system snapshot is exposed to the client through a checkpoint virtual file
system (CVFS) mechanism that Snapshots provides. The read-only snapshot access does not require
performing any tasks on the storage system. (click) All the tasks are performed on the client through its
access directly to the file system. The tasks for NFS clients are slightly different than the tasks for SMB
clients.
(click) The first task for an NFS client is to connect to an NFS share on the file system. (click) Access to
the read-only snapshot is established by accessing the snapshot’s hidden .ckpt data path. This path will
redirect the client to the point-in-time view that the read-only snapshot captures.
(click) Similarly, the first task for an SMB client is to connect to an SMB share on the file system. (click)
Access to the read-only snapshot is established by the SMB client accessing the SMB share’s Previous
Versions tab. This will redirect the client to the point-in-time view that the read-only snapshot captures.
(click) Because the read-only snapshot is exposed to the clients through the CVFS mechanism, the
clients are able to directly recover data from the snapshot without any administrator intervention. For
example, if a user either corrupted or deleted a file by mistake, that user could directly access the read-
only snapshot and get an earlier version of the file from the snapshot and copy it to the file system to
recover from.
A short video follows that demonstrates client access to a file system read-only snapshot.

In this lesson, an overview of Unity Replication is provided. The architectures of Asynchronous and
Synchronous Replications are discussed and the benefits and capabilities are listed for Unity Replication.

Unity Replication, a feature enabled with the Replication license, enables replication of Unity storage
resources; block storage LUNs, VMware Datastores, file storage file systems, VMware NFS Datastores
and NAS Servers. Remote replication, shown here, provides storage resource replication between Unity
systems for storage resources. The file-based storage resources of VMware NFS Datastores, NAS
Servers, and file systems are replicated to a remote Unity system asynchronously. The block-based
storage resources of VMware VMFS datastores, LUNs and LUN Consistency Groups are replicated to a
remote Unity system in either an asynchronous or synchronous manner.
Remote Replication is one method that enables data centers to avoid disruptions in operations. In a
disaster recovery scenario, if the source site becomes unavailable, the replicated data will still be available
for access from the remote site. Remote Replication uses a Recovery Point Objective (RPO) which is an
amount of data, measured in units of time to perform automatic data synchronization between the source
and remote systems. The RPO for asynchronous replication is configurable. The RPO for synchronous
replication is set to zero. The RPO value represents the acceptable amount of data that may be lost in a
disaster situation. The remote data will be consistent to the configured RPO value. The minimum and
maximum RPO values are 5 minutes and 1440 minutes (24 hours).
Remote Replication is also beneficial for keeping data available during planned downtime scenarios. If a
production site has to be brought down for maintenance or testing the replica data can be made available
for access from the remote site. In a planned downtime situation, the remote data is synchronized to the
source before being made available and there is no data loss.

With Unity Replication, it is possible to asynchronously replicate storage resources locally within the same
Unity system as shown here. The storage resources are replicated from one storage Pool to another
within the same Unity system. The feature can be helpful should a storage resource need to be moved for
Pool capacity reasons or for changing the type of storage the resource uses. For example, a resource
could be moved from a Pool having performance disks to a Pool having capacity disks for archival
reasons.
The main focus of this training is with remote replication since it has more elements to configure, create
and manage.

The architecture for Unity Asynchronous Remote Replication is shown here. The graphic illustrates a
remote asynchronous replication session for a file system. The architecture is the same for replicating any
other file or block-based storage resource asynchronously.
Fundamental to remote replication is connectivity and communication between the source and destination
systems. A data connection is required to carry the replicated data and it is formed from Replication
Interfaces. They are IP-based connections established on each system. A communication channel is also
required to manage the replication session. The management channel is established on Replication
Connections. It defines the management interfaces and credentials for the source and destination
systems.
Asynchronous Replication architecture utilizes Unified Snapshots. The system creates two snapshots for
the source storage resource and two corresponding snapshots on the destination storage resource. These
system created snapshots cannot be modified. Based on the replication RPO value the source snapshots
are updated in an alternating fashion to capture the source data state differences, known as deltas. The
data delta for the RPO timeframe is replicated to the destination. After the data is replicated the
corresponding destination snapshot is updated. The two corresponding snapshots capture a common data
state, known as a common base. The common base can be used to restart a stopped or interrupted
replication session.

The architecture for Unity Asynchronous Local Replication is shown here. The difference between the
local and remote architecture seen previously is that the local architecture does not require the
communications to a remote peer. The management and data replication paths are all internal within the
single system. Otherwise, local replication uses Snapshots in the same manner. Local replication uses
source and destination objects on the two different Pools similar to how remote replication uses source
and destination on two different systems.

The asynchronous replication process is the same for local and remote replication. Shown here is remote
replication. The asynchronous replication of a storage resource has an initial process followed by an
ongoing synchronization process. The starting point is a data populated storage resource on the source
system that is available to production and has a constantly changing data state.
(click) The first step of the initial process for asynchronous replication is to create a storage resource of
the exact same capacity on the destination system. The storage resource is created automatically by the
system and contains no data.
(click) In the next step, corresponding snapshot pairs are created automatically on the source and
destination systems. They capture point-in-time data states of their storage resource.
(click) The first snapshot on the source system is used to perform an initial copy of its point-in-time data
state to the destination storage resource. This initial copy can take a significant amount of time if the
source storage resource contains a large amount of existing data.
(click) Once the initial copy is complete, the first snapshot on the destination system is updated. The data
states captured on the first snapshots are now identical and form a common base.
(click) Because the source storage resource is constantly changing, its data state is no longer consistent
with the first snapshot point-in-time. (click) In the synchronization process, the second snapshot on the
source system is updated, capturing the current data state of the source.
(click) A data difference, or delta is calculated from the two source system snapshots and a differential
copy is made from the second snapshot to the destination storage resource.
(click) After the differential copy is complete, the second snapshot on the destination system is updated
to form a common base with its corresponding source system snapshot.
(click) The cycle of differential copies continues for the session by alternating between the first and
second snapshot pairs based on the RPO value. The first source snapshot is updated, the data delta is

calculated and copied to the destination, the first destination snapshot is updated forming a
new common base. The cycle repeats using the second snapshot pair.
Copyright © 2017 Dell Inc. Data Protection ‹#›

The architecture for Unity Synchronous Replication is shown here. The graphic illustrates a remote
synchronous replication session for a LUN. The architecture is the same for replicating any other block-
based storage resource synchronously.
The same fundamental remote replication connectivity and communication between the source and
destination systems seen earlier for asynchronous remote replication are also required for synchronous
replication. A data connection to carry the replicated data is required and is formed using fibre channel
connections between the replicating systems. A communication channel is also required to manage the
replication session. For synchronous replication, part of the management is provided using Replication
Interfaces that are IP based interfaces for SPA and SPB using specific Sync Replication Management
Ports. The management communication between the replicating systems is established on a Replication
Connection. It defines the management interfaces and credentials for the source and destination systems.
Synchronous Replication architecture utilizes Write Intent Logs (WIL) on each of the systems involved in
the replication. These are internal LUNs created automatically by each system. There is a WIL for SPA
and one for SPB on each system. They hold fracture logs that are designed to track changes to the source
LUN should the destination LUN become unreachable. When the destination becomes reachable again it
will automatically recover synchronization to the source using the fracture log, thus avoiding the need for a
full synchronization.

The synchronous replication of a storage resource has an initial process followed by an ongoing
synchronization process. The starting point is a data populated storage resource on the source system
that is available to production and has a constantly changing data state.
(click) The first step of the initial process for synchronous replication is to create a storage resource of the
exact same capacity on the destination system. The storage resource is created automatically by the
system and contains no data.
(click) In the next step, SPA and SPB Write Intent Logs are automatically created on the source and
destination systems.
(click) An initial synchronization of the source data is then performed. It copies all of the existing data from
the source to the destination. The source resource is available to production during the initial
synchronization but the destination will be unusable until the synchronization completes.
Once the initial synchronization is complete, the process to maintain synchronization begins. (click)
When a primary host writes to the source the system delays the write acknowledgement back to the host.
(click) The write is replicated to the destination system. Once the destination system has verified the
integrity of the data write (click) it sends an acknowledgement back to the source system. (click) At that
point, the source system sends the acknowledgement of the write back to the host. The data state is
synchronized between the source and destination. Should recovery be needed from the destination, its
RPO would be zero.
(click) Should the destination become unreachable, the replication session will be out of synchronization.
The source Write Intent Log for the SP owning the resource will track the changes. (click) When the
destination becomes available the systems will automatically recover synchronization using the WIL.

Synchronous replications will have states for describing the session and its associated synchronization.
An Active session state indicates normal operations and the source and destination are In Sync.
A Paused session state indicates the replication has been stopped and will have a Sync State of
Consistent indicating the WIL will be used to perform synchronization of the destination.
A Failed Over session will have one of two Sync States. It can show Inconsistent meaning the Sync State
was not In Sync or Consistent prior to the Failover. If the Sync State was In Sync prior to Failover, it will be
Out of Sync after session Failover.
A Lost Sync Communications session state indicates the destination is unreachable. It can have any of the
following Sync States: Out of Sync, Consistent or Inconsistent.
A Sync State of Syncing indicates a transition from Out of Sync, Consistent or Inconsistent due to the
session changing to an Active state from one of its other states; for example if the system has been
recovered from the Lost Sync Communications state.

The table details the various maximum capabilities for Asynchronous Replication based on specific Unity
models.

The table details the various maximum capabilities for Synchronous Replication based on specific Unity
models.

This lesson focuses on creating the replication communications between the two replicating systems. It
also details the process steps for creating Asynchronous and Synchronous Replication sessions.

Replication sessions are created on storage resources for Block, File and VMware. And all are done in a
similar manner.
For Block, the replication is created on a LUN or a group of LUNs in the case of a Consistency Group. For
File, the replication is configured on a NAS server and file systems. For VMware the storage resource is
either going to be a LUN-based VMFS datastore or a file system-based NFS datastore. When creating
each of these storage resources, the Unity system provides a wizard for their creation. Each wizard
provides an option to automatically create the replication on the resource. Each resource replication
creation is nearly identical to the other resources.
For resources already created, replications can be created manually from their Properties page. As with
the wizard, the replication creation from the resource Properties page is nearly identical to the other
resources. The following few slides will show replication creation within the Block storage LUN creation
wizard and the File storage file system creation wizard. It will also show replications created manually
from the LUN and file system Properties pages.
Video demonstrations will also be provided for the resource replication creation.

Because file system access is (click) dependent on a NAS Server, to remotely replicate a file system, the
associated NAS Server (click) will need to be replicated first. When a NAS Server is replicated, (click)
any file systems associated with the NAS server will also be replicated as separate replication sessions; a
session for the NAS Server and a session for each associated file system.

Before you create a remote replication session, you first need to configure active communications
channels between the two systems. (click) This involves first creating Replication Interfaces on the source
and destination systems. (click) Then a Replication Connection is created between the systems.
For Asynchronous Replication, (click) the Replication Interfaces are dedicated IP-based connections
between the systems (click) that will carry the replicated data. The interfaces are defined on each SP
using IPv4 or IPv6 addressing and will establish the required network connectivity between the
corresponding SPs of the source and destination systems. (click) The Replication Connection pairs
together the Replication Interfaces between the source and destination systems. (click) It also defines the
replication mode between the systems; Asynchronous, Synchronous or both. (click) The connection is
also configured with the management interface and credentials for both of the replicating systems.

The active communication channels required for Synchronous Replication are significantly different from
the previously discussed communications for Asynchronous Replication. (click) The first communications
configuration required for Synchronous Replication are the Fibre Channel connections between the
corresponding SPs of the source and destination systems. (click) The Fibre Channel connectivity can be
zoned fabric or direct connections. (click) This connectivity will carry the replicated data between the
systems. (click) Next configured are the Replication Interfaces which are IP-based connections configured
on specific Sync Replication Management Ports on the SPs of each system. These interfaces are part of
the replication management channel. (click) The Replication Connection is configured next and is the
same as discussed for Asynchronous Replication; (click) it defines the replication mode, the management
interface and credentials for both of the replicating systems, (click) and completes the configuration of the
management channel.

One of several Fibre Channel ports on each SP of the Unity system is configured and used for
Synchronous Replication. (click) If available, the system will use Fibre Channel Port 4 of SPA and SPB.
(click) If not available, then the system uses Fibre Channel Port 0 of IO module 0. (click) If that is not
available, then Port 0 of IO module 1 is used.
(click) The CLI console command can be used to verify the Fibre Channel port that the system has
specified as the Synchronous FC Ports on the SPs. The slide shows an example of running the UEMCLI
command “/remote/sys show –detail” command. In the abbreviated example output, Fibre Channel
Port 4 is specified by the system as the Synchronous FC port for SPA and SPB.
Once the Synchronous FC Ports on the source and destination systems have been verified, Fibre Channel
connectivity can be established between the corresponding ports on the SPs of each system. Direct
connect or zoned fabric connectivity is supported.
Although the Synchronous FC ports will also support host connectivity, it is recommended that they be
dedicated to Synchronous Replication.

The steps for creating remote replication sessions are somewhat different depending upon the replication
mode; either Asynchronous or Synchronous. Asynchronous remote replication steps are covered here.
The Synchronous replication steps will be covered in a later section.
Before an Asynchronous Replication session can be created, communications need to be established

between the replicating systems. (click) The first step for establishing communications is to create
Replication Interfaces on both the source and destination systems. The interfaces will form the connection
for replicating the data between the systems. (click) The next step is to create a Replication Connection
between the systems. This is done on either the source or the destination. It establishes the management
channel for replication. (click) After it is created, the connection should be verified from the peer system.
With these steps complete, communications are now in place for a session to be created for a storage
resource. (click) A session can be defined for a storage resource during the resource creation or if the
storage resource already exists, it can be selected as a source for replication. (click) The replication
settings are defined which include the replication mode, RPO and the destination. The system will
automatically create the destination resource and the Unified Snapshot pairs on both systems. (click)
Then the replication session is established.

The creation of Replication Interfaces for remote asynchronous replication is covered here. Replication
Interfaces are not required for local asynchronous replication.
From the system’s interface, the Protection and Mobility tree includes an Interfaces option. (click) From
the Interfaces page new Replication Interfaces can be created. On the creation screen, an available
Ethernet Port from the system must be selected. An IP address and subnet mask must be provided for
both SPs. Gateway addressing is optional and a VLAN ID configuration is also provided if needed.
As noted before, Replication Interfaces need to be created on both of the replicating systems. The
creation of Replication Interfaces needs to be repeated on the peer system.

After the Replication Interfaces are created, a Replication Connection is created (click) between the two
systems for remote asynchronous replication and is not required for local replication. The Replication
Connection only needs to be created on one of the replicating systems. The requirements of the
connection include the remote system management IP address and its management credentials. The local
system management password is also required. (click) Finally a replication mode must be selected from
the drop-down. Choices are Asynchronous, Synchronous or Both. (click) For Asynchronous replication
the Mode must be set Asynchronous or Both. If Both is selected, Asynchronous and Synchronous
sessions can be configured between the two systems.

After the Replication Connection between systems has been created, (click) the connection can be
verified from the peer system using the Verify and Update option. This option can also be used to update
Replication Connections if anything has been modified with the connection or the interfaces. (click) The
updated Connection status will be displayed.

Asynchronous Replication sessions can be created as part of the wizard that creates any Unity storage
resource. From the NAS Server creation wizard example, (click) the Replication step within the wizard is
shown. (click) Checking the Enable Replication option will (click) expose the “Replication Mode”, “RPO”,
and “Replicate To” fields required to configure the session. The mode must be set to Asynchronous to
create an Asynchronous replication session. To create a remote replication session, select the remote
system from the “Replicate To” drop-down. Select Local if configuring a local replication session. (click) A
“Destination Configuration” button is also exposed to provide information concerning the destination
resources to be used for the session.
As noted before; there is a dependency between a NAS Server and a file system. The NAS server must
be replicated prior to any associated file system.

Asynchronous Replication sessions can also be created from the storage resource Properties page; a
VMware NFS Datastore, a NAS Server or a file system. From the NAS Server Properties page example,
(click) the “Configure Replication” button is presented to create a replication session. (click) It starts a
wizard with a number of steps to configure the replication session. (click) The Replication Settings step
requires the “Replication Mode”, “RPO”, and “Replicate To” settings for the session. The mode must be
set to Asynchronous to create an Asynchronous replication session.

The next step defines what (click) resources on the destination system the replicated item will use. (click)
The Name, Pool and Storage Processor settings are required.
In the example NAS Server replication shown, the NAS Server has an associated file system and a
separate replication session will be created for it. The table details the destination resources that will be
used for the file system. (click) It can be selected and edited to further define its destination resources.

The wizard presents a (click) Summary screen for the configured replication.
In the example, sessions for the (click) NAS Server and its associated file system will be created.

The creation Results page displays (click) the progress of the destination resource creation and the
session creation.
When it is complete the created sessions (click) can be viewed from the Replications page by selecting
the Sessions section.

As mentioned previously, the steps for creating a Synchronous replication session are different than for
Asynchronous replication.
Before a Synchronous Replication session can be created, communications need to be established

between the replicating systems. (click) The first step is to verify the Synchronous FC Ports on the source
and destination systems and establish FC connectivity to form the connections for replicating data. (click)
The next step is to create Replication Interfaces on both the source and destination systems. The
interfaces must be created on the Sync Replication Management Ports and will form a portion of the
management channel for replication. (click) A Replication Connection between the systems is created
next. This is done on either the source or the destination. It establishes the management channel for
replication. (click) After it is created, the connection should be verified from the peer system. With these
steps complete, communications are now in place for a session to be created for a storage resource.
(click) A storage resource can now be selected for replication. It can be selected during the resource
creation wizard. Or if the storage resource already exists, it can be selected from the storage resource
Properties page. (click) The next step is to define the replication settings which define the replication
mode and destination system. The system will automatically create the destination resource and the Write
Intent Logs on both systems. (click) Then the replication session is established.

The replication Interfaces for Synchronous replication are created in a similar fashion as seen with
Asynchronous replication. (click) The requirement for Synchronous replication is that the Interfaces are
created on the Sync Replication Management Port of each SP. This is a virtual device that uses the same
physical network connection as the SP Management port. The interfaces are configured on the same
network as the SP Management but can use a different network if VLANs are used.
The Replication Interfaces need to be configured on both the source and destination systems.

After the Replication Interfaces are created, a Replication Connection is created (click) between the two
systems. This only needs to be created on one of the replicating systems. The requirements of the
connection include the remote system management IP address and its management credentials. The local
system management password is also required. (click) Finally a replication mode must be selected from
the drop-down. Choices are Asynchronous, Synchronous or Both. (click) For Synchronous replication the
Mode must be set Synchronous or Both. If Both is selected, Synchronous and Asynchronous sessions can
be configured between the two systems.

After the Replication Connection between systems has been created, (click) the connection can be
verified from the peer system using the Verify and Update option. This option can also be used to update
Replication Connections if anything has been modified with the connection or the interfaces. (click) The
updated Connection status will be displayed.

Synchronous Replication sessions can be created as part of the wizard that creates the storage resource;
a Block LUN or a VMware VMFS Datastore. From the LUN creation wizard example, (click) the
Replication step within the wizard is shown. (click) Checking the Enable Replication option will (click)
expose the “Replication Mode” and “Replicate To” fields required to configure the session. The Mode must
be set to Synchronous to create a Synchronous replication session. (click) A “Destination Configuration”
button is also exposed to provide information concerning the destination resources to be used for the
session.

Synchronous Replication sessions can also be created from the storage resource Properties page; a
VMware VMFS datastore or a Block LUN. From the LUN Properties page example, (click) the “Configure
Replication” button is presented to create a replication session. (click) It starts a wizard with a number of
steps to configure the replication session. (click) The Replication Settings step requires the “Replication
Mode” and “Replicate To” settings for the session. The Mode must be set to Synchronous to create a
Synchronous replication session.

The next step defines what (click) resources on the destination system the replicated item will use. (click)
The Name and Pool settings are required. Additional options are available based on the destination
system. In this example, the destination is an All Flash model that supports LUN compression.

The wizard presents a (click) Summary screen for the configured replication.
In the example, the session (click) settings for the replication and destination are displayed.

The creation Results page displays (click) the progress of the destination resource creation and the
session creation.
When it is complete the created sessions (click) can be viewed from the Replications page by selecting
the Sessions section.

This lesson focuses on the operations for Remote Replication. Replication operations of Failover with
Sync, Failover, Resume, and Failback are performed. Also detailed is data access from the remote site
during failover.

Replication sessions can be managed within Unisphere from two areas. The Replications page Sessions
selection provides a list of all the replication sessions. (click) When a specific session is selected it can be
deleted, edited or by using the More Actions drop-down a variety of replication operations can be
performed.
(click) Similar management of a session can also be done from the Properties page of the replicated
object. The Replication tab displays information about the session, provides certain editable fields and
(click) buttons to delete or perform various replication operations.

Replication sessions can be managed from the source or destination systems. The operations possible
will differ between source or destination. The operations will also differ based on the type of replication,
Asynchronous or Synchronous, and the state of the session.
The example is from an asynchronous file system replication that is in a normal state. From the source it is
possible to perform session Pause, Sync or Failover with Sync operations. From the destination it is only
possible to perform a session Failover operation.

The table provides a list of replication operations, a brief description of it, and which replication mode
supports the operation.

Because a NAS Server has a network interface associated with it, (click) when the server is replicated its
network configuration is also replicated. During replication, the source NAS Server interface is active and
the destination NAS Server interface is not active. Having the source and destination interfaces the same
for the two NAS Servers is fine for an environment where there is similar networking in place for both the
source and destination sites. For an environment where the source and destination sites have different
networking, it is important to modify the network configuration of the destination NAS Server to ensure it
will operate correctly in a failover event. (click) This is performed from the NAS Server’s Properties page
on the destination system. Select the Override option and configure the destination NAS Server for the
networking needs of the destination site. Because the NAS Server effectively changes its IP address when
failed over, clients may need to flush their DNS client cache to connect to the NAS Server when failed
over.

Because of the file system dependence on the NAS Server, replication operations must be done on the
NAS Server first then to the associated file system.
The example illustrates the order of failover for a NAS Server and an associated file system. (click)
Failover must be done first to the NAS Server, (click) then to its associated file system. The same is true
for the Resume operation after Failover. The Resume operation is initiated first on the NAS Server then
the associated file system. Failback is done in the same order; first to the NAS Server then to the
associated file system.

Failover with Sync is an operation available to Asynchronous replication sessions. It is used for a planned
event, either scheduled maintenance or disaster recovery testing when both the primary and secondary
sites are available. It provides data availability from the secondary site.
The example illustrates the process of the operation. (click) It starts with issuing the Failover with Sync
operation from Site A which is the primary production site. (click) The operation will remove access to the
replicated object on Site A. (click) A synchronization from the Site A object to the Site B object happens
next and when it completes the replication session is paused. (click) The operation then makes the Site B
object available for access.

Failover is an operation available to replication sessions of either mode; Asynchronous or Synchronous. It
is used for an unplanned event when the primary production site is unavailable. It provides access to the
replicated data from the secondary site.
The example illustrates the process of the operation. (click) The primary production site becomes
unavailable and all its operations cease. Data is not available and replication between the sites can no
longer proceed. A Failover operation is issued from Site B which is the secondary production site. (click)
The operation Pauses the existing replication session so that the session will not start again should Site A
become available. (click) The operation then makes the Site B object available for access and production
can resume.

Resume is an operation available to replication sessions of either mode; Asynchronous or Synchronous. It
is used to restart a Paused replication session. When a failed over session is resumed from its Paused
state the direction of replication is reversed.
The example illustrates the process of a Resume operation for a session that is failed over. (click) The
Site A replicated object must be available before the replication session can be resumed. (click) The
Resume operation is issued from Site B. (click) The operation will restart the Paused session in the
reverse direction. This will update the Site A object with any changes that may have been made to the Site
B object during the failover. This results in the session resuming in the reverse direction and returned to a
normal state. One may use this method of restarting replication rather that a Failback operation if
production had been serviced from the Site B object for a significant amount of time and thus has
accumulated a significant amount of change from the Site A object. Replication in the reverse direction will
synchronize the Site A object to the data state of the Site B object. To return production to the Site A
object would require a session Failover operation followed by another Resume operation.

Failback is an operation available to replication sessions that have failed over, either Asynchronous or
Synchronous. As its name implies it is used to return a replication session to its state prior to the failover
operation.
The example illustrates the process of a Failback operation. (click) The Site A replicated object must be
available before the Failback operation can be initiated on a session. (click) The Failback operation is
issued from Site B. (click) The operation will remove access to the Site B object and synchronize the Site
A object to the data state of the Site B object. (click) The operation then allows access to the Site A object
for production. (click) Replication is restarted using the Site A object as a source and the Site B object as
a destination. This single operation returns the object’s replication state as it was prior to the failover. One
would use this operation to fail back from failovers lasting for only short time periods. It is important to note
that if the Site B object had accumulated a significant amount of change due to long periods of failover, the
resync time can take a significant amount of time.

This module covered the Snapshots and Replication data protection features of Unity. It provided an
overview of the Snapshots and Replication features, their architectures and capabilities. The creation of
Snapshots for Unity storage resources was detailed and demonstrated. The creation and configuration of
Synchronous replication sessions for LUNs, Consistency Groups and VMware datastores were detailed.
Asynchronous replication sessions for LUNs, NAS Servers and file systems were also covered.
Operations for Snapshots and Replications were also presented.

9 - Unity My Guide

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

9 - Unity My Guide

Hochgeladen von

Copyright:

Verfügbare Formate

This module focuses on the Snapshots and Replication features of Unity that provide data protection.

Copyright © 2017 Dell Inc. Data Protection 1

Copyright © 2017 Dell Inc. Data Protection 2

Copyright © 2017 Dell Inc. Data Protection 3

Copyright © 2017 Dell Inc. Data Protection 4

Copyright © 2017 Dell Inc. Data Protection 5

Copyright © 2017 Dell Inc. Data Protection 6

Copyright © 2017 Dell Inc. Data Protection 7

Copyright © 2017 Dell Inc. Data Protection 8

Copyright © 2017 Dell Inc. Data Protection 9

Copyright © 2017 Dell Inc. Data Protection 10

Copyright © 2017 Dell Inc. Data Protection 11

Copyright © 2017 Dell Inc. Data Protection 12

Copyright © 2017 Dell Inc. Data Protection 13

Copyright © 2017 Dell Inc. Data Protection 14

Copyright © 2017 Dell Inc. Data Protection 15

Copyright © 2017 Dell Inc. Data Protection 16

Copyright © 2017 Dell Inc. Data Protection 17

Copyright © 2017 Dell Inc. Data Protection 18

Copyright © 2017 Dell Inc. Data Protection 19

Copyright © 2017 Dell Inc. Data Protection 20

Copyright © 2017 Dell Inc. Data Protection 21

Copyright © 2017 Dell Inc. Data Protection 22

Copyright © 2017 Dell Inc. Data Protection 23

Copyright © 2017 Dell Inc. Data Protection 24

Copyright © 2017 Dell Inc. Data Protection 25

Copyright © 2017 Dell Inc. Data Protection 26

Copyright © 2017 Dell Inc. Data Protection 27

Copyright © 2017 Dell Inc. Data Protection 28

Copyright © 2017 Dell Inc. Data Protection 29

Copyright © 2017 Dell Inc. Data Protection 30

Copyright © 2017 Dell Inc. Data Protection 31

A short video follows that demonstrates a host accessing a LUN snapshot.

Copyright © 2017 Dell Inc. Data Protection 32

Copyright © 2017 Dell Inc. Data Protection 33

Copyright © 2017 Dell Inc. Data Protection 34

Copyright © 2017 Dell Inc. Data Protection 35

Copyright © 2017 Dell Inc. Data Protection 36

Copyright © 2017 Dell Inc. Data Protection 37

Copyright © 2017 Dell Inc. Data Protection 38

Copyright © 2017 Dell Inc. Data Protection 39

Copyright © 2017 Dell Inc. Data Protection 40

Copyright © 2017 Dell Inc. Data Protection ‹#›

Copyright © 2017 Dell Inc. Data Protection 41

Copyright © 2017 Dell Inc. Data Protection 42

Copyright © 2017 Dell Inc. Data Protection 43

Copyright © 2017 Dell Inc. Data Protection 44

Copyright © 2017 Dell Inc. Data Protection 45

Copyright © 2017 Dell Inc. Data Protection 46

Copyright © 2017 Dell Inc. Data Protection 47

Copyright © 2017 Dell Inc. Data Protection 48

Copyright © 2017 Dell Inc. Data Protection 49

Copyright © 2017 Dell Inc. Data Protection 50

Copyright © 2017 Dell Inc. Data Protection 51

Before an Asynchronous Replication session can be created, communications need to be established

Copyright © 2017 Dell Inc. Data Protection 52

Copyright © 2017 Dell Inc. Data Protection 53

Copyright © 2017 Dell Inc. Data Protection 54

Copyright © 2017 Dell Inc. Data Protection 55

Copyright © 2017 Dell Inc. Data Protection 56

Copyright © 2017 Dell Inc. Data Protection 57

Copyright © 2017 Dell Inc. Data Protection 58

Copyright © 2017 Dell Inc. Data Protection 59