Welcome to Cloud Tiering Appliance Fundamentals.

Copyright ©2014 EMC Corporation. All Rights Reserved. Published in the USA. EMC believes the information in this publication is accurate as
of its publication date. The information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF
ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. The trademarks,
logos, and service marks (collectively "Trademarks") appearing in this publication are the property of EMC Corporation and other parties.
Nothing contained in this publication should be construed as granting any license or right to use any Trademark without the prior written
permission of the party that owns the Trademark.

Acartus, Access Logix, AdvantEdge, AlphaStor, ApplicationXtender, ArchiveXtender, Atmos, Authentica, Authentic Problems, Automated
Resource Manager, AutoStart, AutoSwap, AVALONidm, Avamar, Captiva, Catalog Solution, C-Clip, Celerra, Celerra Replicator, Centera,
CenterStage, CentraStar, ClaimPack, ClaimsEditor, CLARiiON, ClientPak, Codebook Correlation Technology, Common Information Model,
Configuration Intelligence, Configuresoft, Connectrix, CopyCross, CopyPoint, Dantz, DatabaseXtender, Data Domain, Direct Matrix
Architecture, DiskXtender, DiskXtender 2000, Document Sciences, Documentum, elnput, E-Lab, EmailXaminer, EmailXtender , EMC2, EMC,
EMC Centera, EMC ControlCenter, EMC LifeLine, EMC OnCourse, EMC Proven, EMC Snap, EMC SourceOne, EMC Storage Administrator,
Enginuity, eRoom, Event Explorer, FarPoint, FirstPass, FLARE, FormWare, Geosynchrony, Global File Virtualization, Graphic Visualization,
Greenplum, HighRoad, HomeBase, InfoMover, Infoscape, Infra, InputAccel, InputAccel Express, Invista, Ionix, ISIS, Max Retriever,
MediaStor, MirrorView, Navisphere, NetWorker, nLayers, OnAlert, OpenScale, PixTools, Powerlink, PowerPath, PowerSnap, QuickScan,
Rainfinity, RepliCare, RepliStor, ResourcePak, Retrospect, RSA, the RSA logo, SafeLine, SAN Advisor, SAN Copy, SAN Manager, Smarts,
SnapImage, SnapSure, SnapView, SRDF, StorageScope, SupportMate, SymmAPI, SymmEnabler, Symmetrix, Symmetrix DMX, Symmetrix
VMAX, TimeFinder, UltraFlex, UltraPoint, UltraScale, Unisphere, VMAX, Vblock, Viewlets, Virtual Matrix, Virtual Matrix Architecture, Virtual
Provisioning, VisualSAN, VisualSRM, Voyence, VPLEX, VSAM-Assist, WebXtender, xPression, xPresso, YottaYotta,

Revision Date: 10/2014

Revision Number: MR-1WN-CLTIAPF

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 1
 This course covers an overview of the EMC Cloud Tiering Appliance, or CTA. We will
discuss CTA benefits, use cases, architecture, and features. This course is intended for
anyone seeking to establish a basic understanding of the Cloud Tiering Appliance.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 2
 This module focuses on the EMC Cloud Tiering Appliance, or CTA as a solution and provides
several use cases for file archival and migration.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 3
 This lesson covers the EMC Cloud Tiering Appliance solution and its benefits.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 4
 Not all data has the same value, this is true in any storage environment. As data ages, it
is normally accessed less frequently and becomes cold. In a span of ten years, cold data
is said to increase significantly and consume server resources.

One of the challenges of a growing file storage environment is that primary NAS, or
Network-attached Storage, servers and file servers reach capacity, which causes
organizations to continually purchase more storage. Much of the information being
created today needs to be retained, even though it quickly becomes cold.

A storage administrator must find some way to ensure that the less-valuable, less
frequently accessed data does not consume high-speed, expensive primary storage
resources. Organizations may experience other problems as well, such as unplanned
server outages due to running out of space, excessive administrative costs, backup
failures, and so on.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 5
 The solution for the dilemma regarding cold data is called Hierarchical Storage
Management, or HSM. HSM is a file mobility concept where a policy-engine scans the
primary data, find files that had not been accessed for some time, and automatically
move them to a lower tier of storage. In place of the original file, the system stores a
small stub file that contains a pointer to the location of the archived file. The user will see
the stub as if it were the actual file, but when trying to access it, the system will tell the
user to wait while it automatically retrieved the file.

HSM allows for the efficient placement of data based on capacity and service-level-
agreement. Intelligently placing data in optimal tiers of performance and price lowers the
average cost of storage. Based on pre-configured policies and rules, the policy-engine
moves data from one storage tier to another. These policies can be based on the size of
the data, the length of time since the last access, by capacity, or by particular file
extension type.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 6
 The Cloud Tiering Appliance provides the policy engine functionality in the HSM process.
By interacting with a NAS share or export, the CTA identifies files that fit predefined
criteria and initiates movement to a lower storage tier. The CTA then places a small stub
file in the place of the original file. To the user, the file appears to be in its original
location.
When used for archiving or tiering, the CTA automates policy-based file tiering and retrieval
across multiple storage tiers. This allows more efficient use of the most expensive, highest-
performing NAS storage. Inactive data can be archived onto secondary storage where file
retention requirements can be enforced.

When used for file migration, the CTA enables relocation of file data, within a NAS server,
or across NAS servers from different vendors.

The CTA is an IP-based solution that supports CIFS and NFS source file systems.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 7
 EMC Cloud Tiering Appliance provides a complete tiering architecture by moving data off
a primary server like the EMC VNX and placing it on the cloud. The VNX system has its
own tiering process where cold data is moved down from SSDs to SAS drives, and then
from SAS to Near-line SAS.

The CTA comes into the picture by selecting files to be archived from the Near-line SAS drives to
a secondary server or storage, such as the public cloud. The VNX system uses CTA credentials to
write these files to secondary storage.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 8
 An intelligent file tiering solution, such as the CTA, provides a number of benefits. First,
moving inactive or infrequently accessed files from a source tier to a target tier of
storage defers capital expenditure, or CapEx, purchases of new primary storage capacity
and lowers overall total cost of ownership. Second, operating expenses, or OpEX, are
reduced when storage administrators no longer have to be consumed with lengthy, error-
prone manual processes or are not continually dealing with outages.

Performance is also improved because dedicated backup windows are shortened,

minimizing disruption to other applications. CTA archiving offer zero impact on the end
user. It is as if their file has never moved.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 9
 This lesson covers the supported servers in CTA archiving and migration, and use cases for
a CTA solution.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 10
 Cloud Tiering Appliance provides flexible storage platform support so you can tier and
archive files to the type of storage that best meets your needs.

Archiving schedules can be created to automate file movement from one system to
another, leaving a small stub on the primary storage. The stub ensures that the file
appears unmoved to the end user or application and can immediately be recalled should
it become active again.

The supported source platforms are: VNX, Celerra, and NetApp. The supported target
platforms are: VNX, VNXe, Isilon, Celerra, Windows, Centera, DataDomain, NetApp,
Atmos and Amazon S3.

CTA SP2 introduced the support to ViPR as Atmos archive target. CTA adds ViPR as the
Atmos server and uses Atmos REST (Representational State Transfer) API to
communicate with ViPR. CTA is unaware that ViPR is the target system.

Also, with the release of SP2, Microsoft Azure is a supported target for VNX, Celerra and
NetApp sources in multi-tier archive operations.

When the target platform is a VNX or Celerra, you can take advantage of the file
deduplication and compression capabilities for further efficiencies.

For more information on the different types of servers and their supported Operation Systems,
please refer to the CTA Interoperability Matrix on support.emc.com.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 11
 Cloud Tiering Appliance is a great way to introduce the advantages of the public cloud in
an efficient and secure manner.

Unlike private cloud, when tiering to the public cloud, bandwidth becomes a primary cost
concern. With CTA, data compression can be enabled, allowing bandwidth optimization
when tiering to cloud storage.

Additionally, CTA provides encryption protection for data “at rest” and reduces the risk of
compromising sensitive data stored in the cloud.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 12
 CTA is a good fit for archiving files which are accessed infrequently from tier1 or tier2
NAS server to a lower, less costly tier of storage such as a Centera. It is a great solution
for reducing space on the source file system while still providing access to the files from
secondary storage. An example would be files that have not been accessed in more than
60 days or files larger than 100 MB.

Another case for CTA is in a big NAS environment where the organization is constantly growing
file systems and backup times keep increasing. When files that have gone cold can be tiered to
secondary storage, this decreases file system size and improves backup performance by backing
up only the stub files, which are significantly smaller than the original files.

Companies that have lower cost servers that are not being fully utilized may also benefit
from a CTA solution. By using these secondary servers as archiving targets, more
resources and space can be freed up on primary high-performance storage. This results
in organizations not needing to purchase new storage and thus achieving best TCO.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 13
 For this use case, a software development company is using both file-level retention
options provided by the VNX in its CTA implementation. FLR-E, or File-level Retention
Enterprise, allows for businesses to carry out good governance practices. FLR-C, or File-
level Retention Compliance, allows for SEC Rule 17a4(f) requirements to be met. In both
FLR-E and FLR-C enabled file systems, files that are in the locked state cannot be
modified or deleted.

On its primary storage, the company has a large requirement for general file systems
that are non-FLR. Some of the different organizations within the company have a
requirement for their own copies of source, object, and executables. They also want to
keep the new compiled versions of code for one year after the project is complete. These
files are FLR-E-enabled, which allows them to implement best practices and prevent file
deletion.

There is also a requirement for certain financial data to be managed and comply with
SEC Rule 17a-4(f). These files are FLR-C-enabled and are maintained on the primary
storage.

Certain files that are required to be maintained in a retention state for a lengthy time
period are archived to a FLR-C-enabled file system on the secondary. These files also
meet the SEC Rule 17a-4(f) requirements. Non-FLR files can also be archive in the same
storage.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 14
 In addition to archiving, or tiering, cold data, the CTA can also be used to complete
stubless migrations. CTA file migrations copy data from one NAS share or export on one
system to another. All files are permanently moved without leaving any stub files
behind. During a migration, all files are available for client access.

CTA supports CIFS, NFS, or multi-protocol CIFS/NFS file systems. The supported source
platforms are: VNX, Celerra, NetApp, Windows. The supported target platforms are: VNX,
VNXe, Celerra, and Isilon. CTA migrates data from a Windows source server only to VNX
or VNXe targets.

For more information on the different types of servers and their supported Operation
Systems, refer to the CTA Interoperability Matrix on support.emc.com

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 15
 Many administrators use CTA to move data from old to new servers with minimum
disruption to the NAS clients. This is a common scenario where the company is moving
to a VNX in order to decommission an old Celerra.

Another file migration use case is to consolidate several servers into one. Organizations
with many different file servers can be costly to manage. By consolidating Windows
servers, or NetApp filers, into a VNX or Isilon system would simplify things and save
money with operation expenditures. A company may also wish to migrate their ever-
growing file data to an Isilon system to meet Big Data requirements.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 16
 This module covered the Cloud Tiering Appliance, which enables NAS data tiering, allowing
administrators to move inactive data off of high-performance storage to less-expensive
archival storage. The CTA also enables relocation of NAS data to new shares or exports,
on the same or different servers, even from different vendors.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 17
 This module focuses on the components that make up the CTA solution and discuss what
happens during an archive and a file recall. We will also cover an overview of file
migration.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 18
 CTA is a hardware and software bundled solution. This appliance consists of a Linux-
based operating system with specialized software. CTA provides archival, migration, and
retrieval functionality in a NAS environment. Up to 500 million files can be archived per
appliance.

The CTA-HA, for high-availability, complements an existing CTA by adding high

availability and load balancing capabilities when recalling archived data. The CTA-HA can
be used for recall only and cannot be used for archiving, or any other CTA function. A
CTA-HA may be paired with more than one CTA. However, if file encryption is enabled, a
single CTA-HA cannot provide redundancy for multiple CTAs.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 19
 The Cloud Tiering Appliance can also be implemented as a VMware virtual appliance
called the CTA/VE, or virtual edition. CTA/VE installs on a VMware ESX or ESXi Server
and provides all the functionality of CTA, including the 500 million files per appliance
limit. CTA/VE is provided in an industry-standard virtual appliance distribution that
consists of an Open Virtualization Format (OVF) and Virtual Machine Disk (VMDK) file.

CTA/VE-HA is a virtual high-availability appliance that can serve as the failover appliance
for either a CTA or CTA/VE. It provides the same functionality as the CTA-HA but it
comes as a virtual appliance like the CTA/VE. By having the CTA/VE-HA deployed with a
physical CTA, an environment does not need a second piece of hardware to provide high
availability.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 20
 Now let’s discuss what happens during an archive…

CTA will archive files based on policies configured by an administrator. Once a file is
found that meets the policy, it is archived to the designated secondary server. From a
client perspective, the archival is completely transparent. A stub file containing the same
name as the archived file will replace the original file on the primary server. Data is
never cached on the CTA when archiving. Data will travel from the primary server
directly down to the secondary server by using the CTA as an authenticated user for
writes.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 21
 Once a file is archived, a clock icon and the offline bit are used in Windows Explorer to
notify the client and the administrator that the file is offline. File size will still remain as
the original file size.

Backups using NDMP or CIFS will perform seamlessly and anti-virus processes do not
need to be changed. Files will not be recalled from secondary storage.

Depending on the archival source, the stub file will be either 8KB for VNX/Celerra or 4KB
in size for NetApp. The stub file size is the minimum size for a file to be archived. If
required, CTA has the capability to archive files that are less than the stub size. This
feature is useful for companies with compliance requirements that need to archive every
file regardless of size.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 22
 There is no difference in the way a client opens an archived file. A client accessing an
archived file will trigger the stub file to retrieve the data. The stub file will contain all the
metadata necessary to retrieve the archived data, like the location of the file on
secondary storage for example.

Depending on the primary and secondary tiers, the primary server will retrieve the file from
secondary by using the stub file as a pointer. The alternative would be for the CTA or CTA-HA
appliance to stream the data back to the primary server.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 23
 When it comes to recalling archived files, there are three methods. The pass-through
method is the default for EMC VNX and Celerra systems. With this method, the archived
file will remain on secondary and data is streamed to the primary server via the CTA.

With a partial recall, only a certain amount of data is retrieved to satisfy the request
made on the primary. The stub file will still remain on the primary. An example of a
partial recall would be when a media application requests a specific byte range to be
returned. NetApp NAS devices do not support partial recalls.

A full recall will take place every time a client issues a write to an archived file. In a full
recall, the archived data is entirely written back to primary server and it remains on
primary until the archive policy runs again. This is the default setting for NetApp
devices. Enough space on the primary needs to be assured for full recalls.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 24
 A policy is a set of rules which defines one or more archival destinations. Policy creation
begins with defining a FME, or a File Matching Expression. A FME consists of a file
attribute, an operator, and a value. The attributes supported by the CTA policy engine
are last_accessed, last_modified, file size and name, and directory name.

A rule consists of a FME, or many FMEs, and whether or not a file which matches the FME should
be archived or deleted. Administrators will define a number of rules and then reorder them to
build an archiving policy. When a policy is applied to a file system, files will be compared to the
rules in order. The order in which the rules are configured will determine which files will be
processed first.

In the example illustrated on this slide, first all files that have not been accessed in 60 days or
more will be archived to a Centera. Then, from the files that are left, any files bigger than 100
MB will be archived to Atmos. Finally, if there are any .txt files left, these will be tiered down to a
Windows 2008 server.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 25
 With CTA 10.0 SP2 the Intelligent File Recall Policy introduced the support to a policy
“recall“ task, which can be added in the GUI or CLI as “run now” or simulation. Or it can
be defined in the policy component with the policy type “recall”. The task uses the same
attributes as an Archive task: time based, capacity based, simulation.

Only one recall task or simulation can run at any given time. The task is limited to 1,000
files, but it is supported on all products.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 26
 The CTA and CTA/VE appliances have two different user interfaces for administrative
tasks and for making configurations. To access both of these interfaces, you will need
the CTA IP address.

On the CTA GUI, there are four tabs at the top of the page: Schedule, Archived Files,
Policies, and Configuration. The first three will be void of any entries until an Archiving
plan is implemented. The Configuration tab allows you to view security, alerts, and
logging settings. This is also where primary and secondary file servers are added.

The CLI offers the same functionality as the GUI. Through the CLI you may configure the
appliance and schedule archiving and migration tasks. A client that supports SSH
(Secure Shell) is a requirement to access the CTA CLI.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 27
 When it comes to migrating files from one server to another, CTA will create several
snapshots on the source server to be used in the migration. This minimizes the
downtime window by improving migration performance due to the fact that actual file
system is not being touched. Full read and write access is permitted while the data is
being migrated. The migration feature leverages the CTA policy engine to provide
selective migration based on file attributes.

After a full copy is performed, another snapshot is taken to compare and determine if
there are any differences in the file system since the last migration. File migration can be
scheduled with a configurable threshold to provide automatic incremental migrations.
The threshold is defined as the number of files migrated in the previous migration run.

In the CTA GUI the File Migration task history will indicate initial full copy and date for
each incremental migration. Up to 40 millions files may be migrated in a single task.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 28
 This module covered an overview of the CTA architecture, including the process of
archiving and recalling a file.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 29
 This module focuses on the CTA and CTA-HA platform model differences, as well as the
CTA/VE and CTA/VE-HA specifications. We will also discuss the different deployment
options supported by the CTA.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 30
 CTA’s most recent platform model is the Generation 8, which is built on the Intel 1U 2-
socket rack-mounted server. This platform uses a Dual Intel Sandy Bridge 2.0 GHz
processor. It contains 16 GB of RAM and four 900 GB SAS drives configured in a RAID 5
with one hot spare.

For network interface ports, the server comes with four gigabit Ethernet ports on the
motherboard. There is also an available IO module providing an additional 2-ports for
10GbE.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 31
 Another platform option for the CTA is the Generation 7 (Gen-7) model. This model is a
Dell R710 2U server with only 4 GB of RAM instead of the Gen-8’s 16 GB.

The Gen-7 comes with four 1 TB SATA drives in a RAID 1 configuration with two hot
spares. There are two gigabit Ethernet ports for network connection. With this model,
only 250 million files can be archived per appliance.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 32
 The oldest CTA hardware model is the Generation 6 (Gen-6). The Gen-6 is built on the
Dell 2950 server. This model contains a Dual Intel 3.0 GHz Xeon processor with 4 GB of
RAM.

There are four 250 GB SATA drives in a RAID 5 configuration with one hot spare. As with
the Gen-7 model, the Gen-6 only has two gigabit Ethernet ports for networking and has a
limitation of 250 million archived files per appliance.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 33
 The CTA-HA comes on the same Gen-6, Gen-7, and Gen-8 hardware platforms as the
CTA. The only differences between CTA and CTA-HA hardware are the single processor,
number of disks per model, and different RAID protection for Gen-8 and Gen-6 models.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 34
 In the event that a Gen-8 CTA or CTA-HA becomes unresponsive, a network console
management page is available to allow users to control the appliance or reboot the
system.

The console can be accessed through a dedicated management port on the back of the
appliance which is labeled MGMT. For security purposes, network console management
should be enabled on a network with access limited to system administrators only.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 35
 The requirements to implement a CTA/VE solution are four virtual CPUs, 16 GB of virtual
RAM, 1 TB of virtual disk space and two Gigabit virtual interfaces must be reserved. For
a CTA/VE-HA, the only differences compared to a CTA/VE is that only 4 GB of virtual RAM
is needed along with 100 GB of virtual disk space. Both CTA/VE and CTA/VE-HA support
ESXi server 4.1 and later, as well as ESX server 4.0 and later.

Disk space for the CTA/VE can be thin provisioned from the backend. Make sure that 1
TB is available in case the CTA/VE will need to archive close to its limit of 500 million
files.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 36
 For many environments, using a single CTA or CTA/VE network interface will satisfy
networking requirements. However, there are cases when more complex topologies are
used.

The CTA supports combining Ethernet interfaces to form a bonded interface. This
topology is used for high availability, to protect the CTA installation from a single point of
failure. You may also use two subnets or more, one for the primary storage tier, and
another for either the secondary tier or for a management interface. One port can be
used for one subnet, and another port for the second subnet. The CTA also supports
VLAN tagging and VLAN bonding, which is a VLAN interface created on top of a bond
interface. Be aware that bonding or VLAN bonding is not supported on the CTA/VE.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 37
 A bond is an aggregate of multiple physical ports into one logical link, increasing
throughput by load-balancing traffic. CTA link aggregation will support between 2 to 4
links per bond.

There are 4 types of configurable bonds. The 802.3ad mode is the default and load
balances by MAC addresses. The CTA will negotiate the trunks with the switch, which
reduces the likelihood of network loops due to mis-configuration. The Balance-RR mode
balances traffic evenly among the supplied links.

The Balance-XOR mode balances the traffic by MAC address like 802.3ad. Traffic for
clients will stick to one interface in the bond. The active-backup bond mode keeps one
interface active and the other as a standby. If the active interface fails, the backup
interfaces is promoted to be the new active.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 38
 This module covered the different CTA and CTA-HA hardware models. We looked at the
requirements to implement a CTA/VE and CTA/VE-HA and also the options in deploying a
Cloud Tiering Appliance in a network environment.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 39
 This module focuses on the features and functions of the Cloud Tiering Appliance. We will
look at Orphan File Management, Stub and File retention, Delayed Stubbing, and NAS
Repository migrations.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 40
 An orphan file is an archived file stored on secondary storage that is no longer referenced
by a stub file on the primary storage for 30 days or more. A client may delete a stub by
accident or on purpose, thus creating an orphan file.

CTA periodically scans all of the archived files to determine if the associated stub file still
exists. An internal database that keeps track of all archived files is used during the scan
process. If the stub file is found, the CTA database is updated with the date the stub file
was detected. This scanning can be run manually at any time or may be scheduled to
run automatically. CTA creates a list of files that were orphaned at the time the last stub
scanning was performed. An administrator can then delete orphaned files if the user
intentionally deleted the stub and reclaim secondary storage capacity. Since the CTA-
HA, and CTA/VE-HA cannot archive files, there is no internal database present.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 41
 This slide shows the orphan file deletion workflow. This process will first detect the
orphan files that are 30 or more days old.

Next, it will check if the source file is still a stub or not. If the file is still a stub then the
process will check if the offline path of the stub and the orphan file in the DB match – if a
match is found then the orphan will be not deleted. If it does not match the database,
the orphan file will be deleted.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 42
 Users have a tendency to accidentally delete a file every now and then, this is also true
with stub files. If it is determined that the stub file was accidentally deleted, it can be
re-created.

Stub file recovery provides the backup and restore functionality of the CTA solution. If
for any reason a stub file on the primary storage is lost, CTA can recreate the stub file for
any file that was previously archived and has not been deleted through orphan
management. If the secondary server contains multiple versions of an archived file, CTA
can be used to recreate a stub file on primary storage for a specific version. This action
can only be performed by the CTA that originally archived the file. Its internal database
will be used in recreating the stub.

Stub retention may be enabled if a retention period is configured. This will prevent users
from deleting the stub file until the retention time has expired. The retention period that
is applied to the stub is the same retention period that is applied to the archived file.
Stub retention on the source may be selected for any archive policy; however, it only
applies to certain source and destination combinations as seen on this slide.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 43
 Data may be archived with a retention period depending on the secondary tier. The
retention period is configured during policy creation. Setting a retention time period
guarantees that a particular file will not be deleted or modified before its retention time
has expired. The retention period can be measured in days, months, weeks, or years
from time of archive.

When the secondary storage is Centera or Atmos, retention is supported natively.

However, retention is not supported on ViPR as Atmos server.

When it comes to the VNX/VNXe/Celerra for an archive destination, retention is

supported by using File Level Retention, and NetApp uses its SnapLock feature. Data
Domain support CTA retention with its Retention Lock software, and Isilon uses its
SmartLock feature.

Stubs and archived files that are no longer under retention or that were defined without
any retention period can be automatically deleted by running a CTA policy.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 44
 Delayed stubbing prevents a stub from being created on the primary server until the
stubbing period has expired. The stubbing period gives the production secondary server
enough time to replicate the file to a DR, or Disaster Recovery, secondary server. At this
point in time, the file will exist in three locations: the primary, the production secondary,
and the DR secondary.

After the stubbing period has expired, the CTA will then replace the file on the primary
file server with its associated stub. This feature provides the production secondary
enough time to replicate the archived file to another server.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 45
 Delayed stubbing is important because it helps to protect against a data unavailability
situation. In some environments, remote replication is often used to copy data to a
remote Disaster Recovery site. Replication between NAS devices can be delayed,
especially in large environments, and in those where sites are separated by great
distances.

In a scenario without Delayed Stubbing a problem can occur if the production secondary
server becomes unavailable prior to completing the replication of the archived data to the
DR secondary server. In this case, the stub file will not have an archived file to reference
if a recall is necessary.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 46
 However, in a scenario using Delayed Stubbing, the CTA will only create a stub for an
archived file after a certain number of days. This way, the production secondary server
has enough time to replicate the archived file to the DR secondary.

If the production secondary goes offline before replicating the data, the original file is still
available on the primary server.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 47
 CTA 10 SP2 offers a feature that recalls duplicate stubs and automatically archive them.
Duplicate stubs refer to two stubs with the same offline path.

The stub scanner detects duplicate stubs, and inserts stub filename into the
`stub_management.duplicate_stub_files’ table. The stub files are fully recalled to the
source and then automatically re-archived to the target. These operations will create new
entries in the duplicateRecall.log.

Also, the process will create a new off-line file on target, and a new entry in the Archived
files DB table. Then it will remove the file from the Duplicate Stub Table.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 48
 A NAS repository migration task moves archived data from a NAS repository to another
destination. A NAS repository are archived files located in a VNX/VNXe/Celerra, Isilon,
Data Domain, Windows, or NetApp.

With the source being a NAS repository, the destination can be another NAS repository, a
Centera, or cloud storage such as Atmos, Amazon S3 or. CTA SP2 added platform
support for Microsoft Azure as an archive target with the Multi-tier archiving policy.

A NAS repository migration cannot relocate data from a Centera, Atmos, or Amazon S3.

The NAS protocol, CIFS or NFS, must match when moving archived data between NAS
file servers. This task will not relocate data that was archived with a different CTA to the
same repository. It moves data that was archived by the CTA running the task. A NAS
repository migration task cannot migrate files that are enforced by retention. Other
active archiving jobs must be stopped and disabled during the migration.

CTA 10.0 SP2 added port 445 to CIFS connections to allow CIFS communication when
NetBIOS on port 139 is disabled.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 49
 The CTA contains reporting capabilities when it comes to file archiving. A report can
display an archive history bar chart of total MB archived per server over a period of
months. File size and file types of archived data can be displayed as pie charts.

The archive summary table contains a summary of values listed by the source.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 50
 This module covered how the CTA is able to recreate stub files and prevent users from
deleting archived files and their stubs. We also looked at the migration of archived files
from one secondary server to another, and archive reports that can be generated by the
CTA.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 51
 This course covered the EMC Cloud Tiering Appliance, its hardware platforms and features.

This concludes the training.

Copyright 2014 EMC Corporation. All rights reserved. Cloud Tiering Appliance Fundamentals 52