M09res01 Federated Tiered Storage

This module focuses on Federated Tiered Storage.
Copyright 2013 EMC Corporation. All rights reserved Module 9: Federated Tiered Storage 1
This lesson covers an overview of FTS.
Federated Tiered Storage (FTS) is a and free feature available with Enginuity 5876. This
feature allows VMAX 10K, VMAX 20K and VMAX 40K arrays to use the storage capacity of an
external array.
Federated Tiered Storage (FTS) allows LUNs that exist on external arrays to be used to
provide physical storage for Symmetrix VMAX array. The external LUNs can be used as raw
storage space for the creation of Symmetrix devices in the same way internal Symmetrix
physical drives are used. These devices are referred to as eDisks. Data on the external LUNs
can also be preserved and accessed through Symmetrix devices. This allows the use of
Symmetrix Enginuity functionality such as local replication, remote replication, storage
tiering, data management, and data migration with data that resides on external arrays.
FTS simplifies management of virtualized multi-vendor or EMC storage by allowing
heterogeneous arrays to be managed by Solutions Enabler and Unisphere for VMAX. It allows
data mobility and migration between heterogeneous storage arrays and between
heterogeneous arrays and VMAX. FTS offers Virtual Provisioning benefits to external arrays
and allows VMAX enterprise replication technologies such as SRDF and TimeFinder to be
used to replicate storage that exists on an external array. It also extends the value of existing
disk arrays by allowing them to be used as an additional storage tier.
VAMX customers can continue to use external disk arrays while taking advantage of most
VMAX Enginuity features. They can protect data on external arrays using Symmetrix local and
remote replication technologies. They can also migrate data between Symmetrix and
external storage as part of a tiering or asset management strategy and provide a pool of
extra VMAX storage in a Virtual Provisioning environment.
An emulation, referred to as DX, (for DA eXternal) adapts the traditional DA emulation model
to act on external logical units as though they were physical drives. The fact that a DX is using
external LUNs instead of a DA using internal LUNs is transparent to other director emulations
and to the Enginuity infrastructure in general. With respect to most non-drive-specific
Enginuity functions, a DX behaves the same as a DA.
An eDisk is a virtual external disk that is created when an external LUN is brought into the
configuration. The terms eDisk and external spindle both refer to this external LUN once
it has been placed in an external disk group and a virtual RAID group.
External disk groups are virtual disk groups that are created by the user to contain eDisks.
Exclusive disk group numbers for external disk groups start at 512. External spindles and
internal physical spindles cannot be mixed in a disk group.
An unprotected virtual RAID group gets created for each eDisk that gets added to the system.
The RAID group is virtual because eDisks are not protected locally by the VMAX; they rely on
the protection provided by the external array.
DX directors are configured in dual initiator (DI) pairs, like traditional DAs. They are fully
redundant like DAs and a failing director will fail over when necessary to the other fully
functioning director in the DI pair.
DX directors must be configured by EMC. Once the DX emulation has been loaded on the
processors, FTS is completely user-configurable. EMC requires a minimum of 4 paths to
external devices, meaning that at least 4 ports belonging to a single DX dual initiator pair
must be configured.
The recommended practice for maximum redundancy in a single fabric environment will be achieved
by using single initiator/multiple target zoning. This is accomplished by creating individual zones that
contain each DX port and all external ports that the external devices are available on. Single initiator
zoning is recommended.
As an example, take an FTS environment configured as follows:
A single engine VMAX with DX emulation running on directors 7G and 8G.
An external array with LUNs mapped to Storage ports 1 and 2. This FTS configuration would require
the following 4 zones for maximum redundancy:
Zone 1: 7G:0 -> SP1, SP2; Zone 2: 7G:1 -> SP1, SP2, Zone 3: 8G:0 -> SP1, SP2, Zone 4: 8G:1 -> SP1, SP2
The following zoning configuration is also compliant with FTS requirements:

Zone 1: 7G:0, SP1, Zone 2: 7G:1, SP2, Zone 3: 8G:0, SPA, Zone 4: 8G:1, SP2
Best practice for maximum redundancy will be achieved by using dual fabrics. One DX initiator port
from each DX director pair must connect to one fabric, while the other DX initiator port connects to
the other fabric to provide redundancy. The LUNs must be reachable from at least one storage port
on at least two external array controllers or directors.
Single initiator zoning is recommended. Using the same assumptions for VMAX and remote arrays:
This FTS configuration across a dual switch Fabric would require a minimum of 4 zones (2 per fabric):
Fabric A: Zone1: 7G:0 -> SP1 Fabric A: Zone2: 8G:0 -> SP1
Fabric B: Zone3: 7G:1 -> SP2 Fabric A: Zone4: 8G:0 -> SP 2
FTS has two modes of operation depending on whether the external LUN will be used as raw
storage space or has data that must be preserved and accessed through a VMAX device.
External Provisioning allows the user to access LUNs existing on external storage as raw
capacity for new Symmetrix devices. These devices are called externally provisioned devices.
Encapsulation allows the user to preserve existing data on external LUNs and access it
through Symmetrix volumes. These devices are called encapsulated devices.
External Provisioning:
When using FTS to configure an external LUN, Enginuity creates an eDisk and adds it to the
specified external disk group. External disk groups are separate from disk groups containing
internal physicals and start at disk group number 512. Because RAID protection is provided
by the external array, eDisks are added to unprotected virtual RAID groups.
Virtual Provisioning can be configured using external provisioning by creating data devices
(TDATs) using an external disk group. Other than the fact that the TDATs are created on
eDisks, the process for configuring VP is otherwise the same.
There are two different options with encapsulation:
With standard encapsulation the external spindle is created and added to the specified
external disk group and unprotected RAID group. Symmetrix devices are also created at the
same time, allowing access to the data that has been preserved on the external LUN.
Virtual Provisioning encapsulation and standard encapsulation share the fact that the
external spindle is created and added to the specified external disk group and to an
unprotected RAID group. However, they differ in that with Virtual Provisioning encapsulation,
data devices (TDATs) are then created and added to a specified thin pool. Fully, non-
persistently allocated thin devices (TDEVs) are also created and bound to the pool. Extents
are allocated to the external LUN through the TDAT.
Shown here is a subset of the information about the external disk that is reported by the
output of the symdev show command.
For the most up to date list of supported arrays, please refer to the EMC Simple Support
Matrix EMC Federated Tiered Storage P/N 300-014-066 on https://support.emc.com.
Symmetrix devices can then be created from the external disk group to present to users.
External provisioning should only be used with external LUNs that contain no data or
unwanted data. These devices will be VTOCed as part of the eDisk configuration process, and
any data residing on the LUN prior to adding it as an eDisk will be lost.
Symmetrix devices created on eDisks can be used as any other Symmetrix disk with a few
restrictions.
With standard encapsulation, the external spindle is created and added to the specified
external disk group and unprotected RAID group. Symmetrix devices are also created at the
same time, allowing access to the data that has been preserved on the external LUN.
Virtual Provisioning encapsulation and standard encapsulation share the fact that the
external spindle is created and added to the specified external disk group and to an
unprotected RAID group. However, they differ in that with Virtual Provisioning encapsulation,
data devices (TDATs) are then created and added to a specified thin pool. Fully, non-
persistently allocated thin devices (TDEVs) are also created and bound to the pool. Extents
are allocated to the external LUN through the TDAT.
When encapsulating an external LUN, Enginuity must create Symmetrix volumes that are at
least equal to the size of the external LUN in order to be able to access the preserved data.
Individual VMAX devices have a size limit of approximately 240 GB, which holds true in an
FTS environment as well.
When an eDisk must be configured that is larger than the maximum Symmetrix device size,
metadevices must be created. The symconfigure command file syntax for the addition of
external disks offers has several choices that govern how this is handled by Enginuity. The
meta_member_size parameter determines what size each member of the metadevice is, and
the member_size_equal parameter governs whether all meta members should be of equal
size, or if the meta tail should be smaller.
Symmetrix Enginuity creates Symmetrix devices in units of fifteen, 64K tracks. Because of
this, capacity of Symm devices may not exactly match raw capacity of the eDisk.
Encapsulated devices will have a geometry set by Enginuity to reflect the raw capacity of the
eDisk.
Due to its native geometry and size, when the last block of an encapsulated external LUN
does not fall on a Symmetrix cylinder boundary, Enginuity sets the custom geometry on the
device to ensure that the size of the eDisk matches the size of the external LUN. When this
causes its reported size of the eDisk to be smaller than its actual size, the device is said to be
geometry limited.
The status of a device and whether it is geometry limited or not, is noted in the output of
commands like symdev show or sympd show.
Because organizations may have specific configuration rules in place regarding Symmetrix
device size and meta device member size, the potential exists for meta devices to be
geometry limited.
The user encapsulates a 22GB external device with meta_member_size configured to 9GB
and member_size_equal set to yes. Enginuity creates three 9GB Symmetrix devices and
concatenates them into a meta device. Enginuity sets the user defined geometry to reflect
the encapsulated 22GB capacity. This device is considered geometry limited because the
Symmetrix device size reported on the meta head (27GB) is larger than the meta head
custom geometry size of 22GB.
The user encapsulates a 27GB external device instead of a 22GB device as in the previous
example. The meta_member_size option is also configured to 9GB and member_size_equal
set to yes. Enginuity creates three 9GB Symmetrix devices and concatenates them into a
meta device. Enginuity sets the user defined geometry to reflect the encapsulated 27GB
capacity. This device is not geometry limited because the Symmetrix device size reported on
the meta head (27GB) is equal to the meta head custom geometry size of 27GB.
The user encapsulates a 22GB external device. The meta_member_size option is configured
to 9GB and member_size_equal set to no. Enginuity creates two 9GB Symmetrix devices and
one 4GB Symmetrix device and concatenates them into a meta device. Enginuity sets the
user defined geometry to reflect the encapsulated 22GB capacity. This device is not
geometry limited because the Symmetrix device size reported on the meta head (22GB) is
equal to the meta head custom geometry size of 22GB.
The following restrictions apply to geometry-limited devices:
No support for TimeFinder/Snap or TimeFinder/Mirror
Can only be used as source devices for TimeFinder/Clone operations
The rules for operations to larger target devices apply (See the Solutions Enabler
Symmetrix TimeFinder Family CLI Product Guide for details)
Does not support SRDF/Star or SRDF/AR
Can only be used as R1 devices for SRDF operations
This means that a geometry limited device can be configured for dynamic SRDF as an R1 only
(DR1) but not as an R1 or R2 (DRX) or an R2 (DR2). The rules for operations to larger R2
devices apply (See the EMC Solutions Enabler Symmetrix SRDF Family CLI Product Guide for
details about copying data from an R1 device to a larger R2 device).
These general restrictions apply to all FTS environments.
The following limitations apply to all FTS environments.
This table is an excerpt from the Array Controls Guide V 7.5. Refer to the manual for more
detail.
This table is a continuation of the excerpt from the Array Controls Guide V 7.5 shown on the
previous slide. Refer to the manual for more detail.
This table is a continuation of the excerpt from the Array Controls Guide V 7.5 shown on the
previous slide. Refer to the manual for more detail.
This lesson demonstrates the implementation of FTS using a remote Clariion as the external
array.
The first step in deploying FTS is to perform an online FA to DX conversion of 2 FA directors
into DX directors using SymmWin. Two RF directors could also be converted to DX directors.
DX director pairs can only be configured on Symmetrix VMAX 20K or VMAX 40K arrays. Each
FA director (2 ports) that will form a DX director pair must reside on the same engine on
separate physical directors for redundancy. The online conversion cannot be accomplished
using Solutions Enabler and must be done using SymmWin. DX emulation can be configured
on a set of 4 FA director ports that span an engine. To deploy FTS, the customer has the
option of purchasing new FAs or converting existing FAs or RFs to DXs.
The Symmetrix FA ports should be free of mapped devices. Any assigned volumes should
therefore be unmapped prior to conversion.
The proper bits must be set on the external array storage ports so that Symmetrix can
communicate with the external array. Please see the FTS Tech note or the simple Support
Matrix on e-Lab Navigator for the required external array storage port bit settings.
The command symcfg list dx all displays all configured DX directors.
If federating a LUN as an Encapsulated eDisk, the host application accessing the LUN must be
halted prior to encapsulation and access to the LUN through the external array must be
removed. The application must not be able to access the same storage from the external
array and also through the Symmetrix FTS array.
The host does not have to take an outage with if the eDisk is not encapsulated.
FTS can utilize storage from symmetrical and asymmetrical (ALUA) storage arrays. An
asymmetrical storage array is an array that provides two different levels of access per port
for a given storage LUN. A typical asymmetrical array with two controllers could have an
active-optimized path through controller 0/port 0 and an active non-optimized path through
controller 1/port 0 to a LUN. The multi-pathing software on the host accessing the LUN will
see the active optimized path and will choose to use the better path. A symmetrical storage
array is an array that provides the same level of access per port for a given storage LUN as
every port is active and optimized.
It is best to connect one DX initiator port from each DX director to one fabric while the other
DX initiator port connects to the other fabric to provide redundancy. The LUNs must be
reachable from at least one storage port on at least two external array controllers or
directors. Each external array controller or director should connect to a separate fabric or
switch.
The LUNs must also be presented to the DX director ports through the external arrays
masking procedures.
To federate an eDisk, Symmetrix must be able to access the external LUNs through the
external array storage ports. The external array storage ports that are accessible from the
local DX director ports can be identified by running the symsan command. This command will
display not only the storage port WWNs, but also the number of LUNs presented from each
storage port, the array vendor and serial number, and the local DX director port that is able
to see the external array storage port. This command will help to validate the zoning and the
LUNs that are accessible.
The symsan list sanluns command can be used to display the LUN WWNs that are
being presented from the external array storage ports. The command also displays LUN state,
block size, capacity, and the volume or device number. The LUN state must be
Read/Write(RW) accessible to the VMAX 20K or VMAX 40K array.
In order to federate a LUN as an eDisk, an external disk group must exist prior to federation.
External disk groups can be created using the symconfigure command. A name supplied by
the user is used to create the disk group. Enginuity will assign a number to the disk group.
The disk group location must be external. External disk groups can contain either externally
provisioned or encapsulated eDisks.
The information on this page explains the difference between LUNs on Symmetrix and non-
Symmetrix arrays.
When an unencapsulated eDisk is created, there is a difference between the actual and free
capacities. The free capacity is what is used by Enginuity to create a Symmetrix device. The
remainder of the storage space is not available for use by a host.
While there are four paths to each eDisk, as shown on this display, there is only one active
path. In case that path becomes unavailable, one of the other paths will become active.
As mentioned before, the largest Symmetrix device that can be created on an
unencapsulated eDisk equals the amount of free space reported by the symdisk list -
sid 17 -disk_group 512 command.
Some of the interesting fields in the output from the symdev show command are shown
here.
Apart from standard devices, other types of devices, such as data devices, can be created on
eDisks. These data devices can be used as any other data devices that might be created
inside the Symmetrix. However, they cannot be added to a pool containing Symmetrix
internal data devices.
In this example, an external Clariion LUN containing host data is encapsulated and configured
for standard provisioning. When the device is encapsulated a Symmetrix device will be
created on the VMAX that will enable access to the encapsulated data that exists on the
external LUN.
An external disk group can be created for the eDisk. This step is not required. An existing
external disk group can be used.
The eDisk can be added and encapsulate_data can be set to YES without specifying a thin
pool. By not specifying a thin pool in the symconfigure syntax, the eDisk will be added for
standard encapsulation. This will create the eDisk, RAID group, and a thick Symmetrix device
on the VMAX through which the data on the external LUN will be accessible.
The VMAX thick device (181) is now ready to be mapped and masked to a host. The capacity
of the device, as far as the Symmetrix is concerned, is 1093 cylinders. However, the exact
capacity is 2097152 blocks.
If this device is paired with another device for replication the target device has to be 1093
cylinders or larger. The SRDF and TimeFinder manuals list the restrictions associated with
pairing of unequal size devices.
Creating a separate external disk group is not required for creating TDATs (DATA devices). An
existing disk group could be used; however, in this example, the newly configured eDisk
device will be put into its own disk group so that the disk group number can be specified
when creating the TDATs.
When encapsulating a device for Virtual Provisioning, a thin pool name must be specified.
Encapsulated data devices cannot belong to thin pools with other types of data devices
(either internally or externally provisioned). If an appropriate thin pool does not already
exist, one must be created.
Adding the eDisk, choosing to encapsulate the data, and choosing a thin pool will cause the
eDisk to be created along with the TDAT (DATA device) that will be added to the pool and the
corresponding TDEV (thin device) that will be bound to the pool.
Only two operations are permitted on the thin pool: VLUN migration VP to an internal pool
and addition of further data and thin device pairs to the pool.
Shown here are actions that are permitted on normal thin pools but prohibited on
encapsulated thin pools.
The thin device cannot be unbound. The data device cannot be disabled or removed. No
reclaim operation is permitted. Other data devices cannot be added to the thin pool unless
theyre also encapsulated eDisks.
These are the key points covered in this module. Please take a moment to review them.

M09res01 Federated Tiered Storage

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

M09res01 Federated Tiered Storage

Transféré par

Droits d'auteur :

Formats disponibles

This module focuses on Federated Tiered Storage.

The following zoning configuration is also compliant with FTS requirements:

Vous aimerez peut-être aussi