EMC Cloud Tiering Appliance and EMC Cloud Tiering Appliance/VE

EMC Cloud Tiering Appliance and EMC Cloud Tiering Appliance/VE
EMC® Cloud Tiering Appliance and
Cloud Tiering Appliance/VE
Version 10
Getting Started Guide
P/N 300-005-094
REV 21
EMC Corporation
Corporate Headquarters:
Hopkinton, MA 01748-9103
1-508-435-1000
www.EMC.com
Copyright © 2007 - 2015 EMC Corporation. All rights reserved.
Published April, 2015
EMC believes the information in this publication is accurate 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.
EMC2, EMC, and the EMC logo are registered trademarks or trademarks of EMC Corporation in the United States and other
countries. All other trademarks used herein are the property of their respective owners.
For the most up-to-date regulatory document for your product line, go to the technical documentation and advisories section
on EMC Online Support .
2
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Contents
Preface
Chapter 1
Introduction
Overview of the EMC Cloud Tiering Appliance ............................................... 16
Cloud Tiering Appliance/VE (CTA/VE) ..................................................... 16
High Availability for CTA and CTA/VE...................................................... 17
Updating the EMC Business Services Portal with customer site information 18
CTA implementation with Celerra or VNX primary storage........................... 19
CTA implementation with NetApp primary storage........................................ 20
CTA and CTA/VE tasks ........................................................................................ 21
Using CTA and CTA/VE ...................................................................................... 24
Chapter 2
Cloud Tiering Appliance Hardware and Port Configurations
Contents of the appliance ......................................................................................
Cloud Tiering Appliance types ......................................................................
Cloud Tiering Appliance High Availability types ......................................
Cloud Tiering Appliance details ..........................................................................
Cloud Tiering Appliance for High Availability details ....................................
Appliance diagrams ..............................................................................................
Port details ...............................................................................................................
Chapter 3
26
26
26
27
29
31
35
Installing the Cloud Tiering Appliance
Appliance setup ...................................................................................................... 38
Installing the virtual edition.................................................................................. 39
Deploying CTA/VE as a thin virtual machine with vSphere Client 4.0 or 4.1
43
CTA and CTA/VE for high availability .............................................................. 44
High availability with Celerra or VNX primary storage ............................ 44
High availability with NetApp primary storage ......................................... 45
Network console management for Gen 8 models .............................................. 46
Using CTA CLI commands ............................................................................. 48
Rebooting the system ....................................................................................... 49
Performing a CD clean install on the appliance ................................................. 51
Adding the CTA serial number ............................................................................ 52
Configuring CTA .................................................................................................... 52
Configure the CTA network ........................................................................... 53
Configure the hostname, domain, and DNS server .................................... 53
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
3
Update hosts file...............................................................................................
File Encryption........................................................................................................
Enabling keystore replication.........................................................................
Configuring and using file encryption .........................................................
Graphical user interface ........................................................................................
Command line interface ........................................................................................
Chapter 4
54
54
54
55
55
56
Deploying the Cloud Tiering Appliance
Deployment process for archiving....................................................................... 58
Supported platforms .............................................................................................. 60
Deploying CTA with Celerra or VNX ................................................................. 61
Prerequisites for using Celerra or VNX as a file migration source or
destination ........................................................................................................ 61
Prerequisites for Celerra or VNX as an archive source .............................. 62
Adding a Celerra or VNX to the CTA configuration .................................. 62
Configure name resolution for archiving ..................................................... 65
Configuring Celerra or VNX to Centera or cloud archiving on the CTA 66
Prerequisite tasks on the Celerra or VNX Control Station for file migration or
archiving............................................................................................................ 67
Deploying CTA with NetApp .............................................................................. 74
Prerequisites for using NetApp as a file migration source ........................ 74
Prerequisites for using NetApp as an archiving source ............................ 74
Microsoft Office files and NetApp recall ...................................................... 76
vFiler configuration ........................................................................................ 77
Configuring NetApp archiving on the CTA ............................................... 77
Adding a NetApp filer to the CTA configuration ....................................... 77
Verify the FPolicy configuration for CTA .................................................... 79
Deploying the CTA with a VNXe ........................................................................ 80
Prerequisites for using VNXe as a file migration destination .................. 80
Adding a VNXe to the CTA configuration................................................... 80
Deploying CTA with a Windows server ............................................................ 81
Prerequisites for using Windows as a file migration source ..................... 81
Adding a Windows server to the CTA configuration ............................... 82
Installing the EMWS copy agent for CTA .................................................... 82
Installing and running LGDUP...................................................................... 83
Deploying CTA with Isilon................................................................................... 84
Prerequisite tasks when using Isilon as a CIFS share destination ........... 84
Prerequisite tasks when using Isilon as an NFS export destination ........ 88
Prerequisite task when using Isilon as a file migration destination ........ 89
Adding an Isilon to the CTA configuration ................................................. 90
CTA and Isilon SmartConnect ....................................................................... 91
Deploying the CTA with a Data Domain ........................................................... 93
Configuring a NAS-based repository ................................................................. 94
Deploying CTA with Amazon S3 ........................................................................ 95
Adding Amazon S3 to the CTA configuration ............................................ 95
Deploying CTA with Atmos................................................................................. 96
Adding Atmos to the CTA configuration..................................................... 96
Installing the SSL certificate on the CTA ...................................................... 96
Deploying CTA with Azure.................................................................................. 97
Adding Azure to the CTA configuration ..................................................... 97
Deploying CTA with Centera............................................................................... 98
4
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Chapter 5
Maintaining the Cloud Tiering Appliance
Importing a file list archive .................................................................................
Adding the primary servers..........................................................................
Configuring the import provider .................................................................
Configuring the import task .........................................................................
Importing the file list......................................................................................
Validating the import file ..............................................................................
Backing up the configuration ..............................................................................
Creating a backup dump ...............................................................................
Restoring a backup dump .............................................................................
Maintaining the database ....................................................................................
Checking database size and disk capacity ..................................................
Performing database maintenance...............................................................
Migrating from CTA to CTA/VE .......................................................................
Shutting down and restarting the appliance ....................................................
Chapter 6
100
100
100
101
102
103
103
104
104
106
106
107
108
109
Cloud Tiering Appliance System Settings
Security hardening................................................................................................
Single security database.................................................................................
Disable root logins ..........................................................................................
Strengthen passwords....................................................................................
Age passwords ................................................................................................
Configuring the GUI access method ..................................................................
STIG hardening .....................................................................................................
Enabling STIG hardening ..............................................................................
Disabling STIG hardening .............................................................................
LDAP client configuration ..................................................................................
Global LDAP settings.....................................................................................
LDAP authentication......................................................................................
Configuring basic LDAP settings .................................................................
Configuring advanced LDAP settings ........................................................
Certificate management ......................................................................................
Appliance mail delivery settings ........................................................................
Log settings ............................................................................................................
Configuring log rotation................................................................................
Configuring SCP of rotated log files ............................................................
Configuring alerts .................................................................................................
Configuring email alerts ................................................................................
Configuring SNMP alerts ..............................................................................
Enabling SNMP polling .................................................................................
System command accounting .............................................................................
Tracking user command history ..................................................................
Tracking user login history ...........................................................................
Tracking daemon command history............................................................
Windows domain user .........................................................................................
Creating a Windows domain user ...............................................................
Adding an admin user to the local administrator group..........................
Configuring Windows for Kerberos ............................................................
Configuring Windows 2008 for NTLM .......................................................
SID translator.........................................................................................................
Installing the SID translator ..........................................................................
Creating the SID translation file ...................................................................
Uploading the SID translation file ...............................................................
Deleting a SID translation file .......................................................................
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
112
112
114
114
114
115
115
115
116
117
117
117
118
119
120
121
121
121
122
123
123
124
125
125
126
126
126
127
127
127
129
129
130
130
131
133
133
5
Appendix A
Network Topology Scenarios
Advanced network topologies ...........................................................................
Configuring the CTA with bonding ............................................................
Configuring the CTA with two subnets .....................................................
Configuring the CTA with more than two subnets ..................................
VLAN tagging modes for the CTA/VE ............................................................
ESX Server virtual switch tagging ..............................................................
ESX Server virtual guest tagging ................................................................
Appendix B
136
136
137
137
139
139
140
Alerts
Supported SNMP traps ....................................................................................... 144
CTA alerts.............................................................................................................. 145
Glossary
Index
6
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Figures
Title
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Page
Celerra or VNX implementation .........................................................................................
NetApp implementation ......................................................................................................
Archived report example .....................................................................................................
Rear view of Gen 8 appliance ..............................................................................................
Front view of Gen 8 appliance with bezel removed ........................................................
Front view of the Gen 8 appliance with bezel ...................................................................
Rear view of Gen 7 appliance ..............................................................................................
Front view of Gen 7 appliance with bezel removed ........................................................
Front view of the Gen 7 appliance with bezel ...................................................................
Rear view of Gen 6 appliance ..............................................................................................
Front view of Gen 6 appliance with bezel removed ........................................................
Front view of the Gen 6 appliance with bezel ...................................................................
Front view of Gen 8 for High Availability with bezel removed ....................................
Front view of Gen 7 for High Availability with bezel removed ....................................
Front view of Gen 6 for High Availability with bezel removed ....................................
CTA8-APL and CTA8-HA-APL port details .....................................................................
CTA-APL, CTA-APL-HA, FMA7-APL, FMA7-APL-HA port details ...........................
FMA6-APL and FMA6-HA-APL port details ...................................................................
Cloud Tiering Appliance deployment process .................................................................
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
19
20
22
31
31
31
32
32
32
33
33
33
33
34
34
35
35
36
58
7
Figures
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version lOD Getting Started Guide
Tables
Title
1
2
3
4
5
6
7
8
9
10
11
12
13
Page
CTA that is based on Intel C1U ........................................................................................... 27
CTA that is based on Dell R710 ........................................................................................... 27
CTA that is based on Dell 2950 ........................................................................................... 28
CTA-HA that is based on Intel C1U ................................................................................... 29
CTA-HA that is based on Dell R710 ................................................................................... 29
CTA-HA that is based on Dell 2950 .................................................................................... 30
VMware ESX Server interoperability ................................................................................. 39
Supported platform matrix for archiving .......................................................................... 60
Supported platform matrix for file migration ................................................................... 60
Celerra or VNX deployment checklist ............................................................................... 61
NetApp deployment checklist ............................................................................................ 74
Supported SNMP traps ...................................................................................................... 144
CTA alerts ............................................................................................................................. 145
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
9
Tables
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version lOD Getting Started Guide
Preface
As part of an effort to improve and enhance the performance and capabilities of its product
lines, EMC periodically releases revisions of its hardware and software. Therefore, some
functions described in this document may not be supported by all versions of the software or
hardware currently in use. For the most up-to-date information on product features, refer to
your product release notes.
If a product does not function properly or does not function as described in this document,
please contact your EMC representative.
Audience
This document is part of the EMC Cloud Tiering Appliance and Cloud Tiering
Appliance/VE documentation set. The documentation is intended for use by:
◆
◆
Related
documentation
Storage management administrators who are new to the EMC Cloud Tiering
Appliance and Cloud Tiering Appliance/VE.
Existing customers who are new to version 10.0.
Related documents include:
◆
◆
◆
◆
EMC Cloud Tiering Appliance White Papers — Provide best practices for
configuring specific file servers and for conducting specific tasks.
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE online help —
Provides detailed reference information on the graphical user interface.
EMC Cloud Tiering Appliance Upgrade Guide — Provides instructions on upgrading
to the current CTA version.
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Release Notes —
Provides an overview of new features and lists any limitations.
Preface
11
Preface
◆
EMC CTA man pages — Provide detailed command-line help, as well as
overview information. A good starting point is: man rffm. PDFs of all man pages
are available from:
/opt/rainfinity/filemanagement/doc
Conventions used in
this document
EMC uses the following conventions for special notices.
Note: A note presents information that is important, but not hazard-related.
!
CAUTION
!
IMPORTANT
A caution contains information essential to avoid data loss or damage to the system
or equipment.
An important notice contains information essential to operation of the software.
Typographical conventions
EMC uses the following type style conventions in this document:
Normal
Used in running (nonprocedural) text for:
• Names of interface elements (such as names of windows, dialog boxes, buttons,
fields, and menus)
• Names of resources, attributes, pools, Boolean expressions, buttons, DQL
statements, keywords, clauses, environment variables, functions, utilities
• URLs, pathnames, filenames, directory names, computer names, filenames, links,
groups, service keys, file systems, notifications
Bold
Used in running (nonprocedural) text for:
• Names of commands, daemons, options, programs, processes, services,
applications, utilities, kernels, notifications, system calls, man pages
Used in procedures for:
• Names of interface elements (such as names of windows, dialog boxes, buttons,
fields, and menus)
• What user specifically selects, clicks, presses, or types
12
Italic
Used in all text (including procedures) for:
• Full titles of publications referenced in text
• Emphasis (for example a new term)
• Variables
Courier
Used for:
• System output, such as an error message or script
• URLs, complete paths, filenames, prompts, and syntax when shown outside of
running text
Courier bold
Used for:
• Specific user input (such as commands)
Courier italic
Used in procedures for:
• Variables on command line
• User input variables
<>
Angle brackets enclose parameter or variable values supplied by the user
[]
Square brackets enclose optional values
|
Vertical bar indicates alternate selections - the bar means “or”
{}
Braces indicate content that you must specify (that is, x or y or z)
...
Ellipses indicate nonessential information omitted from the example
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Preface
Where to get help
EMC support, product, and licensing information can be obtained as follows.
Product information — For documentation, release notes, software updates, or
information about EMC products, go to the EMC Online Support at:
http://Support.EMC.com
Technical support — Go to EMC Online Support and click Service Center. You will
see several options for contacting EMC Technical Support. Note that to open a service
request, you must have a valid support agreement. Contact your EMC sales
representative for details about obtaining a valid support agreement or with
questions about your account.
Your comments
Your suggestions will help us continue to improve the accuracy, organization, and
overall quality of the user publications. Please send your opinion of this document to:
techpubcomments@EMC.com
13
Preface
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
1
Introduction
This chapter includes the following sections:
◆
◆
◆
◆
◆
◆
Overview of the EMC Cloud Tiering Appliance ....................................................... 16
Updating the EMC Business Services Portal with customer site information ...... 18
CTA implementation with Celerra or VNX primary storage .................................. 19
CTA implementation with NetApp primary storage ............................................... 20
CTA and CTA/VE tasks................................................................................................ 21
Using CTA and CTA/VE .............................................................................................. 24
Introduction
15
Introduction
Overview of the EMC Cloud Tiering Appliance
The EMC® Cloud Tiering Appliance is technology that optimizes primary NAS
storage by automatically moving inactive files based on policies to less expensive
secondary storage. Secondary storage could be lower cost disk, such as NL-SAS or
SATA drives, or to other platforms including public and private clouds. Files that are
moved appear as if they are on primary storage. File tiering dramatically improves
storage efficiency, and backup and restore time. File archiving onto storage with
WORM functionality can support additional business requirements such as
compliance and retention.
As an example, a Cloud Tiering Appliance may be configured to locate all NAS data
that has not been accessed in one year, and move that data to secondary storage. For
each file it moves, the appliance will leave behind a small space-saving stub file that
points to the real data on the secondary storage device. When a user tries to access the
data in its original location on the primary NAS, the user will be transparently
provided with the actual data that the stub points to, from secondary storage.
If a multi-tier policy is used, the appliance may be configured to move files from a
secondary storage device tier to a tertiary storage device tier. This can be particularly
useful in cases where the secondary storage device represents a tier that is smaller,
faster, and more expensive to maintain than a larger, slower, and cheaper storage
used in the tertiary tier. Once the files are moved, the space-saving stub file on the
primary NAS tier would be updated to point to the data’s new location on the tertiary
storage tier.
In addition to tiering data from primary to secondary storage and leaving a stub
behind on the primary server for recall later, the Cloud Tiering Appliance can also
permanently migrate files from a source to a destination without leaving a stub.
The Cloud Tiering Appliance provides a full range of features including the ability to:
◆
tier or archive and recall data
◆
migrate files
◆
simulate the potential effect of policies before taking action
◆
perform orphan file management
◆
perform stub file recovery
The Cloud Tiering Appliance software also includes a robust reporting interface that
provides valuable insight into the efficacy of archiving policies.
Depending on the type of task, CTA supports a variety of platforms:
◆
“Supported platform matrix for archiving” on page 60
◆
“Supported platform matrix for file migration” on page 60
The Cloud Tiering Appliance (CTA) refers to both the physical and virtual appliance,
unless stated otherwise. The physical appliance is delivered preloaded with software.
The virtual appliance is installed on a VMware server. One or more of each type may
be deployed within a customer environment to create a complete solution.
Cloud Tiering Appliance/VE (CTA/VE)
The Cloud Tiering Appliance/VE (CTA/VE) is a VMware virtual appliance installed
on a VMware ESX/ESXi Server. 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.
16
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Introduction
Virtual appliances are prebuilt software solutions, comprised of one or more virtual
machines that are packaged, updated, maintained, and managed as a unit. Unlike a
traditional hardware appliance, these software appliances allow customers to
acquire, deploy, and manage preintegrated solution stacks more quickly and easily.
High Availability for CTA and CTA/VE
The Cloud Tiering Appliance for High Availability (CTA-HA) and the Cloud Tiering
Appliance/VE for High Availability (CTA/VE-HA) complement the existing CTA or
CTA/VE by ensuring that tiered files can always be recalled, even in the event that
the primary appliance goes down. This ensures complete transparency and
nondisruptive service for clients. The high availability appliance is not used for any
purpose other than recall. For example, it does not perform archiving or orphan file
management, nor does it have a graphical user interface.
The CTA-HA is a dedicated machine that runs the EMC Celerra®, EMC VNX®, or
NetApp callback agents and is delivered preloaded with software. Installation
instructions for the CTA-HA differ slightly from the CTA. The CTA/VE-HA provides
the same functionality as the CTA-HA but is installed on a virtual appliance like the
CTA/VE. A virtual HA can be deployed with a physical CTA and vice versa. In this
way, a network with a physical CTA does not need a second piece of hardware to
provide HA, it can use a CTA/VE-HA.
When a high-availability appliance is deployed alongside a CTA or CTA/VE, the
underlying APIs of Celerra, VNX, and NetApp file servers are leveraged to create a
highly available environment for data recall. The Celerra, VNX, and NetApp
implementations differ as shown in Figure 1 on page 19 and Figure 2 on page 20.
High-availability appliances are not needed in all tiered source and destination
combinations. The CTA and CTA/VE Interoperability Matrix provides more details.
Overview of the EMC Cloud Tiering Appliance
17
Introduction
Updating the EMC Business Services Portal with customer site information
To verify that all the customer site information is correct, please register your
customer installation information directly in the EMC Business Services Portal.
1. Open a Web browser to the following URL:
http://emc.force.com/BusinessServices
2. Click the Install Base Group link after scrolling down to the Post Sales heading.
The Install Base Group case creation page opens.
3. Choose a Case Sub Type from the dropdown menu and click Select to populate
the form with the fields for your service request.
Note: For new installations, typically you choose IB Status Change as the case sub type,
and set the Desired Status (under Case Details) to Install.
Other Sub-Type options include:
• PDR Update - Add or change Preferred Dispatch Resource on a TLA
• Move or Party Change - Move or change what customer a TLA is located
• Upgrade/Conversion - Updating a product to the latest version based on a Sales Order
Shipment
• Debrief - Part Usage on the different task types in Oracle
• Model Quantity Update - Changing the quantity on a Model in the Install Base
• ecure Credentials - SP Upgrades and enabling the field to obtain secure credentials
• Model Separation - Splitting multiple models into single instances
• Microcode Update - Updating the microcode to the desired version
• Other - All other requests that don't fit into categories
4. Enter your contact name, e-mail address, phone and geographic theatre.
Fields marked in red are required for submission. You can also include other
notification e-mail addresses in the Additional Notification Email fields.
5. Click Select (next to the Case Sub Type pane). In the Case Details section, provide
information in the Subject and Description fields to provide detail about the type
of support needed, and fill out any additional fields that are relevant to your
specific Case sub-type. If this is a Federal request, make sure to check the Federal
Case check box.
6. Select the Product Families that apply to your request (Family is defined as the
TLA/Model product family for your request). If you have multiple product
families in your request and one of them is listed here, choose that family.
7. Enter the Serial #, Desired Status, and Microcode (Software Level) for your
install base as required.
• Serial #: Located on a pull-out card on the front of the physical appliance or on the SW
kit label sticker
• Desired Status: UsuallyInstall, if you choseIB Status Change as the case sub type
• Microcode: Click the question mark at the top right of the CTA dashoard to show the
current software varriant (for example, Version 10 0SP2 b217)
8. To include additional documents with your request, navigate to the Upload
Attachments section and click Choose file. Use the Description field to provide
details about the purpose of the attached file.
9. After you provide all required information, click Submit.
EMC sends automated e-mail notifications to provide information about the
progress of your request.
18
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Introduction
CTA implementation with Celerra or VNX primary storage
Figure 1 on page 19 shows the recall architecture of CTA implementation with a
Celerra or VNX.
4
CIFS R/W
SMB over
NetBIOS
(TCP 139)
CIFS R/W
SMB over
TCP
(TCP 445)
NFS R/W
NFS
(RPC)
HTTP R/W
HTTP
(TCP 80)
FTP R/W
1
FTP
(TCP 21)
DHSM
Celerra or VNX
File System
HTTP
(TCP 8000 for Centera)
(TCP 9000 for Atmos or Amazon)
/etc/hosts
2
3
DNS
EMC CTA
Power Ed g e
2950
NFS
CIFS
EMC CTA-HA
Power Ed g e
2950
Platform API
NFS
Repository
CIFS
Repository
Centera or Cloud Storage
CNS-001622
Figure 1
Celerra or VNX implementation
Circled numbers correspond to the following steps that illustrate the recall process in
the Celerra or VNX implementation:
10. Clients send read/write operations for files that have been archived. These stub
files contain information about where the file has been archived to. These
operations are intercepted by the DHSM layer on the Celerra or VNX prior to
being serviced from the filesystem.
11. If the file has been archived to EMC Centera® or cloud storage (such as EMC
Atmos™, Amazon S3, or Microsoft Azure), the Celerra or VNX blade resolves the
fully qualified domain name (FQDN) stored in the stub file to the IP address of
the CTA or CTA-HA.
CTA implementation with Celerra or VNX primary storage
19
Introduction
The blade then uses HTTP to read the archived data from the appliance, which in
turn reads it from Centera or cloud storage by using the platform API. If an
appliance does not respond to the HTTP read requests, the Celerra or VNX blade
uses an alternate IP address of another appliance configured in DNS. Every
callback server (CTA, CTA-HA, CTA/VE, or CTA/VE-HA) has its IP address
associated with a single hostname in DNS. The FQDN uses that hostname, which
may have multiple IP addresses associated with it.
12. If the file has been archived to an NFS or CIFS repository, the blade opens a
connection to the repository and reads back the data.
13. The blade responds to the client operation as usual if the recall was successful, or
the client receives a message that the file cannot be opened if the recall fails.
Note: When Celerra or VNX data has been archived to a Celerra, VNX, VNXe, NetApp, Data
Domain, Isilon, or Microsoft Windows repository, the CTA or CTA/VE is not involved in the
recall process and a high availability appliance is not used.
CTA implementation with NetApp primary storage
Figure 2 on page 20 shows the recall architecture of CTA implementation with a
NetApp.
4
1
CIFS Recall (Writes)
SMB over NetBIOS
CIFS R/W
CIFS R/W
NFS R/W
HTTP R/W
FTP R/W
NFS Recall (Writes)
SMB over
NetBIOS
(TCP 139)
SMB over
TCP
(TCP 445)
NFS
(RPC)
HTTP
(TCP 80)
FTP
(TCP 21)
FPolicy
Secondary
Primary
2
WAFL
FPolicy API
EMC CTA
FPolicy API
EMC CTA-HA
Pow er E dg e
Pow
er
295 0
3
NFS
NFS
Repository
CIFS/SMB
over NetBIOS
CIFS
Repository
E dg
e
295 0
Platform
API
Centera or cloud storage
CNS-001619
Figure 2
20
NetApp implementation
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Introduction
Circled numbers correspond to the following steps that illustrate the archive and
recall process in the NetApp implementation:
1. Clients send read/write operations for files that have been archived. These
operations are intercepted by the FPolicy layer on the NetApp prior to being
serviced from the Write Anywhere File Layout (WAFL) filesystem.
2. The NetApp is configured with the following groups:
• A primary group of callback servers, such as a CTA and possibly one or more
CTA-HAs.
• A secondary group, such as one or more physical or virtual HAs.
The NetApp will send FPolicy callbacks to servers registered in the primary
group in round-robin fashion. If a server does not reply to the callback, it is
removed from its group. If there are no servers in the primary group, the
callbacks are distributed in a round-robin fashion among the servers in the
secondary group.
For CTA/VE, the primary group of callback servers consists of virtual machines
such as a CTA/VE and possibly one or more CTA/VE-HAs. The secondary group
consists of one or more CTA/VE-HAs.
3. The appliance connects to the filer by using CIFS to read the contents of the stub
file. The stub file points to where the file data is stored. The appliance then
connects to the NFS repository, CIFS repository, Centera, or cloud storage where
the data was archived. It then reads the data by using the native protocol and the
file data is written back to the NetApp.
4. The filer responds to the client operation as usual if the recall was successful, or
with an "access denied" message if the recall failed.
Note: It is a requirement that the software versions of all the appliances match. For example, do
not deploy a configuration with a CTA that is running version 7.5 and a CTA-HA that is
running version 7.4. While the software does not perform any explicit checks to ensure the
versions are compatible, the running of different software versions has not been tested and
may result in unexpected behavior.
CTA and CTA/VE tasks
The CTA or CTA/VE may be used to run several different tasks:
◆
Tiering or archiving
◆
Deleting orphaned data
◆
Auxiliary tasks, such as stub scanning and backup
◆
Migration tasks such as repository migration and file migration
For archiving, deleting and migrating files, the software leverages a policy engine to
select the files. Users can combine and evaluate multiple rules together in a single
policy. Several rule types are available.
Before running the archive, delete, or migration task, the running of a simulation
allows administrators to review real-time results without executing the task. The
results will return:
◆
Aggregated summary of total files matched
◆
Total bytes potentially archived
CTA and CTA/VE tasks
21
Introduction
Also, if an optional detailed simulation is run, a list of files that match the policy is
saved on the disk for review.
Run a simulation to gain insight into the efficiency of a task before running the task.
This practice is notably important for the delete tasks, since these tasks remove data.
A report displays results of the task. Figure 3 on page 22 is an example of an archived
report.
Figure 3
Archived report example
Archive tasks may be one of three types:
◆
◆
Archive (with policy) — Archives regular (non-stub) files. Files are selected for
archiving based on the archive policy.
Multi-tier (with policy) — For this archiving task, regular and stub files are
evaluated with the multi-tier policy.
• If a regular file matches the policy, it is archived.
• If a stub file matches the policy, archived data is moved to a different storage
tier and the stub is updated to point to the new location.
◆
Multi-tier stub (with policy) — For this archiving task, only stub files are
evaluated with the multi-tier stub policy. If a stub file matches the policy, archived
data is moved to a different storage tier and the stub is updated to point to the
new location. Otherwise, the archived data remains in the current storage tier.
In addition, CTA can perform an archive task on an imported list of files.
Delete tasks may be one of two types:
◆
◆
22
Delete orphan with policy — Deletes orphans on secondary storage that match
the delete orphans policy.
Delete stub with policy — The delete stub task deletes stubs that match the delete
stubs policy. Stubs on primary storage and files on the second tier that are no
longer under retention or that were defined without any retention period are
automatically deleted.
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Introduction
Auxiliary tasks are:
◆
◆
Scan stubs — When a file is archived, a stub file remains on the source and an
entry is added to the CTA database, and maps the name and location of the
archived file to its stub. The stub scanning task tracks the stub file information.
When a stub has not been detected on a CIFS share or NFS export for 30 or more
days, the corresponding archived file is designated as an orphan. If stub files are
moved from the original archive location to another location, manually run a stub
scanner task on the new location so that the CTA does not consider these files
orphans.
Backup — The backup task performs periodic backups of the CTA configuration
and database. Schedule backup tasks as part of a regular maintenance program.
Only one backup task may be scheduled.
Migration tasks are:
◆
◆
Repository Migration — Repository migration moves archived files from one
storage tier to another storage tier. Migration can be to a NAS repository, to a
Centera, or to an on-premise or service provider cloud such as Atmos or Amazon
S3. All stub files that point to this data will be updated to point to the new
location.
File Migration (with policy) — The file migration task moves files from a primary
to a secondary server that are defined as the source and destination in the task
definition. The task evaluates both normal and stub files based on the migrate file
policy with a resulting action of either migrate or don’t migrate.
The CTA software also has the capability to recover stub files accidentally deleted by
client systems. It can even recover prior versions of files archived to any secondary
storage destination.
Note: Do not duplicate stubs, because CTA does not support them. Repository migration and
Orphan deletion tasks will randomly detect and manage the first occurence of a stub, and will
ignore the duplicates. This can lead to data unavailability and data loss.
CTA and CTA/VE tasks
23
Introduction
Using CTA and CTA/VE
Once the appliance has been deployed on the network, the administrator can manage
data through the CTA or CTA/VE graphical user interface (GUI) or command line
interface (CLI). “Graphical user interface” on page 55 explains how to invoke the
GUI. Online help documents all GUI pages.
Technical system details that are not related to the GUI, but are required to configure
the CTA or CTA/VE, are provided in the following chapters and appendixes:
◆
Chapter 3, ”Installing the Cloud Tiering Appliance”
◆
Chapter 4, ”Deploying the Cloud Tiering Appliance”
◆
Chapter 5, ”Maintaining the Cloud Tiering Appliance”
◆
Chapter 6, ”Cloud Tiering Appliance System Settings”
◆
Appendix A, “Network Topology Scenarios”
Except where expressly stated otherwise, all sections of this guide apply to both the
CTA and CTA/VE.
24
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
2
Cloud Tiering
Appliance Hardware
and Port Configurations
This chapter contains the following sections:
◆
◆
◆
◆
◆
Contents of the appliance.............................................................................................. 26
Cloud Tiering Appliance details .................................................................................. 27
Cloud Tiering Appliance for High Availability details ............................................ 29
Appliance diagrams ....................................................................................................... 31
Port details....................................................................................................................... 35
Cloud Tiering Appliance Hardware and Port Configurations
25
Cloud Tiering Appliance Hardware and Port Configurations
Contents of the appliance
The CTA or CTA-HA ships with robust, fault-tolerant hardware consistent with the
mission-critical application for which it is used.
The following items are included in the appliance package:
◆
Cloud Tiering Appliance:
• A 2U 19-inch rackmountable Gen 6 or Gen 7 model.
• A 1U 19-inch rackmountable Gen 8 model.
◆
Two universal rails for mounting the appliance on a 19-inch rack.
◆
Two sets of power cords.
◆
Copper patch cables for the number of ports on your appliance.
◆
Media kit with the software recovery CD.
◆
Cables:
• One serial cable for Gen 6 and Gen 7 models.
• One crossover cable for Gen 8 models.
Note: The following are items are not included: VGA monitor, keyboard, and mouse for a
system console.
Cloud Tiering Appliance types
◆
◆
◆
Intel C1U — Model CTA8-APL ships with four enabled on-board gigabit Ethernet
copper 10/100/1000TX ports, two enabled 10 gigabit Ethernet SR (short range)
optical ports provided with the mezzanine module, and one dedicated
management port. Figure 17 on page 35 shows the port details.
Dell R710 — Models CTA-APL and FMA7-APL ship with two enabled on-board
gigabit Ethernet copper 10/100/1000TX ports. Figure 17 on page 35 shows the
port details.
Dell 2950 — Model FMA6-APL ships with two on-board gigabit Ethernet copper
10/100/1000TX ports. Figure 18 on page 36 shows the port details.
Cloud Tiering Appliance High Availability types
◆
◆
◆
26
Intel C1U — Model CTA8-HA-APL ships with four enabled on-board gigabit
Ethernet copper 10/100/1000TX ports, two enabled 10 gigabit Ethernet SR (short
range) optical ports provided with the mezzanine module, and one dedicated
management port. Figure 17 on page 35 shows the port details.
Dell R710 — Model CTA-APL-HA and FMA7-APL-HA ships with two enabled
on-board gigabit Ethernet copper 10/100/1000TX ports. Figure 17 on page 35
shows the port details.
Dell 2950 — Model FMA6-HA-APL ships with two on-board gigabit Ethernet
copper 10/100/1000TX ports. Figure 18 on page 36 shows the port details.
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Cloud Tiering Appliance Hardware and Port Configurations
Cloud Tiering Appliance details
Table 1 on page 27 lists the Gen 8 hardware configuration for the CTA that is based on
the Intel C1U hardware.
Table 1
CTA that is based on Intel C1U
Component
CTA8-APL
Chassis
The appliance is based on Intel C1U Kylin node hardware.
Size
1U form factor
Power
Dual 750 watt. Item(b) in Figure 4 on page 31. Power button and identification light
is item (f) in Figure 5 on page 31.
CPUs
Dual Intel Sandy Bridge Six Core AES 256 HWencryption.
Disks
Four 900 GB 2.5-inch, 10K RPM hard drives in a RAID-5 configuration. Items (b)
through (e) in Figure 5 on page 31.
RAID controller
Intel RMS25CB080 (Condado Beach)
CD-ROM
Read-only DVD that can read CD or DVD material for system upgrades. Item (a) in
Figure 5 on page 31.
Memory
16 GB
Network interfaces
• Four on-board gigabit 10/100/1000 TX Ethernet copper ports with RJ45
connectors. Item (e).
• Two 10GbE optical ports provided with the Intel mezzanine module. Item (g).
• One dedicated management port. Item (f).
All items in Figure 4 on page 31.
VGA
Standard VGA video connector for a system console. Item (a) in Figure 5 on
page 31.
Keyboard connector
Standard USB keyboard connector for a system console. Item (d) in Figure 5 on
page 31.
Mouse connector
Standard USB mouse connector for a system console. Item (c) in Figure 5 on
page 31.
Table 2 on page 27 lists the Gen 7 hardware configuration for the CTA that is based on
the Dell R710 hardware.
Table 2
CTA that is based on Dell R710 (page 1 of 2)
Component
CTA-APL, FMA7-APL
Chassis
The appliance is based on Dell R710 11G hardware.
Size
2U form factor
Power
Dual 570 watts
CPUs
Dual, 2.0 GHz, E5504 4C/4T 80W4MB Cache Nehalem-EP
Disks
Four 1 TB, SATA, 3.5-inch, 7.2 K RPM hard drives in a RAID-1 configuration with
two hot spares. Items (b) through (e) in Figure 8 on page 32.
RAID controller
PERC6/I
CD-ROM
Read-only DVD that can read CD or DVD material for system upgrades. Item (a) in
Figure 8 on page 32.
Cloud Tiering Appliance details
27
Cloud Tiering Appliance Hardware and Port Configurations
Table 2
CTA that is based on Dell R710 (page 2 of 2)
Component
CTA-APL, FMA7-APL
Memory
1066-MHz, 4 GB total (1 x 2 GB DIMM per proc/dual proc configuration)
Network interfaces
Two on-board gigabit 10/100/1000TX Ethernet copper ports with RJ45 connectors.
Item (e) in Figure 7 on page 32.
VGA
Standard VGA video connector for a system console. Item (a) in Figure 7 on
page 32.
Keyboard connector
Standard USB keyboard connector for a system console. Item (d) in Figure 7 on
page 32.
Mouse connector
Standard USB mouse connector for a system console. Item (c) in Figure 7 on
page 32.
Serial port
Standard DB9 serial port for a serial-terminal system. Item (b) in Figure 7 on
page 32.
Table 3 on page 28 lists the Gen 6 hardware configuration for the CTA that is based on
the Dell 2950 hardware.
Table 3
28
CTA that is based on Dell 2950
Component
FMA6-APL
Chassis
The appliance is based on Dell 2950 hardware.
Size
2U rackmount form factor with universal rails. Dimensions: 8.6 cm (h), 44.5 cm (w),
66.1 cm (d). Weight: 34 kg.
Power
Dual redundant 750 watt hot-plug, power supplies. Total consumption: 5Aat 120 Vor
2.5 A at 240 V.
CPUs
Dual Intel Xeon 3.00 GHz Quad Core processors with 1333 MHz front-side bus.
Disks
Four 250 GB, SATA, 3.5-inch, 7.2KRPMhard drives in a RAID-5 configuration. Items
(b) through (e) in Figure 11 on page 33.
RAID controller
PERC 6/I integrated controller card with 256 MB of battery-backed write cache.
The storage controller buffers all writes to disk so that in the event of a critical
full-system failure. Important state information is saved even during abrupt disk or
power failure.
Remote management
Dell DRAC Card.
CD-ROM
24x IDE CD-ROM/DVD-ROM drive for system upgrades. Item (a) in Figure 11 on
page 33.
Memory
667 MHz, (4 x 1 GB), single-ranked DIMMs
Network interfaces
Two on-board gigabit 10/100/1000TX Ethernet copper ports with RJ45 connectors.
Item (e) in Figure 10 on page 33.
VGA
Standard VGA video connector for a system console. Item (a) in Figure 10 on
page 33.
Keyboard connector
Standard USB keyboard connector for a system console. Item (d) in Figure 10 on
page 33.
Mouse connector
Standard USB mouse connector for a system console. Item (c) in Figure 10 on
page 33.
Serial port
Standard DB9 serial port for a serial-terminal system. Item (b) in Figure 10 on
page 33.
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Cloud Tiering Appliance Hardware and Port Configurations
Cloud Tiering Appliance for High Availability details
Table 4 on page 29 lists the Gen 8 hardware configuration for the CTA-HA that is
based on the Intel C1U hardware.
Table 4
CTA-HA that is based on Intel C1U
Component
CTA8-HA-APL
Chassis
The appliance is based on Intel C1U Kylin node hardware.
Size
1U form factor
Power
Dual 750 watt
CPU
Single Intel Sandy Bridge Six Core AES 256 HWencryption
Disks
Two 900 GB 2.5-inch, 10K RPM hard drives in a RAID-1 configuration. Items (b)
and (c) in Figure 13 on page 33.
RAID controller
Intel RMS25CB080 (Condado Beach)
CD-ROM
Read-only DVD that can read CD or DVD material for system upgrades. Item (a) in
Figure 13 on page 33.
Memory
16 GB
Network interfaces
• Four on-board gigabit 10/100/1000 TX Ethernet copper ports with RJ45
connectors. Item (e).
• Two 10GbE optical ports provided with the Intel mezzanine module. Item (g).
• One dedicated management port. Item (f).
All items in Figure 5 on page 31.
VGA
Standard VGA video connector for a system console. Item (a) in Figure 5 on
page 31.
Keyboard connector
Standard USB keyboard connector for a system console. Item (d) in Figure 5 on
page 31.
Mouse connector
Standard USB mouse connector for a system console. Item (c) in Figure 5 on
page 31.
Table 5 on page 29 lists the Gen 7 hardware configuration for the CTA-HA that is
based on the Dell R710 hardware.
Table 5
CTA-HA that is based on Dell R710 (page 1 of 2) (page 1 of 2)
Component
CTA-APL-HA, FMA7-APL-HA
Chassis
The appliance is based on Dell R710 11G hardware.
Size
2U form factor
Power
Dual 570 watts
CPUs
Single, 2.0 GHz, E5504 4C/4T 80 W4 MB Cache Nehalem-EP
Disks
Two 1 TB, SATA, 3.5-inch, 7.2K RPM hard drives in a RAID-1 configuration. Items
(b) and (c) in Figure 14 on page 34.
RAID controller
SAS6/IR
CD-ROM
Read-only DVD that can read CD or DVD material for system upgrades. Item (a) in
Figure 14 on page 34.
Cloud Tiering Appliance for High Availability details
29
Cloud Tiering Appliance Hardware and Port Configurations
Table 5
CTA-HA that is based on Dell R710 (page 2 of 2) (page 2 of 2)
Component
CTA-APL-HA, FMA7-APL-HA
Memory
1066 MHz, 4 GB total (2 x 2 GB DIMM/single proc configuration)
Network interfaces
Two on-board gigabit 10/100/1000TX Ethernet copper ports with RJ45 connectors.
Item (e) in Figure 7 on page 32.
VGA
Standard VGA video connector for a system console. Item (a) in Figure 7 on
page 32.
Keyboard connector
Standard USB keyboard connector for a system console. Item (d) in Figure 7 on
page 32.
Mouse connector
Standard USB mouse connector for a system console. Item (c) in Figure 7 on
page 32.
Serial port
Standard DB9 serial port for a serial-terminal system. Item (b) in Figure 7 on
page 32.
Table 6 on page 30 lists the Gen 6 hardware configuration for the CTA-HA that is
based on the Dell 2950 hardware.
Table 6
30
CTA-HA that is based on Dell 2950
Component
FMA6-HA-APL
Chassis
The appliance is based on Dell 2950 hardware. It is a 2Urackmount formfactor
with universal rails.
Size
2U rackmount formfactor with universal rails. Dimensions: 8.6 cm(h), 44.5 cm
(w), 66.1 cm (d). Weight: 34 kg.
Power
Dual redundant 750 watt hot-plug, power supplies.
CPU
Single Intel Xeon 2.33 GHz Quad Core processor with 1333 MHz front-side
bus.
Disks
Two 250 GB, SATA, 3.5-inch, 7.2K RPMhard drives in a RAID 1 configuration.
Items (b) and (c) in Figure 15 on page 34.
RAID Controller
PERC6/I integrated controller card with 256 MB of battery-backed write cache.
The storage controller buffers all writes to disk so that in the event of a critical
full-systemfailure. Important state information is saved even during abrupt disk
or power failure.
CD-ROM
24x IDE CD-ROM/DVD-ROM drive for system upgrades. Item (a) in Figure 15
on page 34.
Memory
4 GB, 533 MHz (4x1 GB), dual-ranked DIMMs.
Network Interfaces
Two on-board gigabit 10/100/1000TX Ethernet copper ports with RJ45
connectors. Item (e) in Figure 10 on page 33.
VGA
Standard VGA video connector for a system console. Item (a) in Figure 10 on
page 33.
Keyboard Connector
Standard USB keyboard connector for a system console. Item (d) in Figure 10
on page 33.
Mouse Connector
Standard USB mouse connector for a systemconsole. Item(c) in Figure 10 on
page 33.
Serial port
Standard DB9 serial port for a serial-terminal system. Item (b) in Figure 10 on
page 33.
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Cloud Tiering Appliance Hardware and Port Configurations
Appliance diagrams
These diagrams illustrate configurations of the CTA and CTA-HA.
Figure 4
Rear view of Gen 8 appliance
Figure 5
Front view of Gen 8 appliance with bezel removed
Figure 6
Front view of the Gen 8 appliance with bezel
Appliance diagrams
31
Cloud Tiering Appliance Hardware and Port Configurations
32
Figure 7
Rear view of Gen 7 appliance
Figure 8
Front view of Gen 7 appliance with bezel removed
Figure 9
Front view of the Gen 7 appliance with bezel
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Cloud Tiering Appliance Hardware and Port Configurations
Figure 10
Rear view of Gen 6 appliance
Figure 11
Front view of Gen 6 appliance with bezel removed
Figure 12
Front view of the Gen 6 appliance with bezel
Figure 13
Front view of Gen 8 for High Availability with bezel removed
Appliance diagrams
33
Cloud Tiering Appliance Hardware and Port Configurations
34
Figure 14
Front view of Gen 7 for High Availability with bezel removed
Figure 15
Front view of Gen 6 for High Availability with bezel removed
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Cloud Tiering Appliance Hardware and Port Configurations
Port details
Models CTA8-APL and CTA8-HA-APL support four on-board gigabit Ethernet
copper 10/100/1000TX ports, two 10 gigabit Ethernet SR (short range) optical ports,
and one dedicated management port (MGMT). “Network console management for
Gen 8 models” on page 46 describes how to use the management port.
Figure 16 on page 35 is a rear view of the appliance with the ports labeled.
eth0
eth1
eth2
eth3
MGMT
eth5
eth4
CTA-000105
Figure 16
CTA8-APL and CTA8-HA-APL port details
Models CTA-APL, CTA-APL-HA, FMA7-APL, and FMA7-APL-HA ship with two
on-board ports enabled. Figure 17 on page 35 is a rear view of the appliance with the
ports labeled.
eth0
eth1
Disabled Disabled
CNS-001354
Figure 17
CTA-APL, CTA-APL-HA, FMA7-APL, FMA7-APL-HA port details
Port details
35
Cloud Tiering Appliance Hardware and Port Configurations
Models FMA6-APL and FMA6-HA-APL, ship with two on-board ports. Figure 18 on
page 36 is a rear view of the appliance with the ports labeled.
eth1
eth0
CNS-001259
Figure 18
36
FMA6-APL and FMA6-HA-APL port details
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
3
Installing the Cloud
Tiering Appliance
This chapter contains the following sections:
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
Appliance setup.............................................................................................................. 38
Installing the virtual edition ......................................................................................... 39
CTA and CTA/VE for high availability ..................................................................... 44
Network console management for Gen 8 models ..................................................... 46
Performing a CD clean install on the appliance ........................................................ 51
Adding the CTA serial number.................................................................................... 52
Configuring CTA............................................................................................................ 52
File Encryption................................................................................................................ 54
Graphical user interface ................................................................................................ 55
Command line interface ................................................................................................ 56
Installing the Cloud Tiering Appliance
37
Installing the Cloud Tiering Appliance
Appliance setup
Before an appliance may be used to perform tasks, the appliance and the software
must be properly configured:
◆
◆
◆
◆
◆
◆
◆
◆
◆
If a Cloud Tiering Appliance (CTA) is being deployed, port details that are used to
connect the appliance to the network are provided in Chapter 2, ”Cloud Tiering
Appliance Hardware and Port Configurations.”
If a Cloud Tiering Appliance/VE (CTA/VE) is being deployed, follow the
instructions in “Installing the virtual edition” on page 39.
If a Cloud Tiering Appliance for High Availability (CTA-HA) or Cloud Tiering
Appliance/VE for High Availability (CTA/VE-HA) is being deployed, “CTA and
CTA/VE for high availability” on page 44 describes configuration considerations.
If a CTA Gen 8 model is being deployed, follow the instructions in “Network
console management for Gen 8 models” on page 46.
The CTA software is preinstalled on every new appliance. If the software must be
reinstalled and no previous CTA information or data needs to be retained, follow
the instructions provided in “Performing a CD clean install on the appliance” on
page 51.
If CTA 10.0 is being deployed, add the CTA serial number as described in
“Adding the CTA serial number” on page 52.
To install the appliance on the network, follow instructions provided in
“Configuring CTA” on page 52.
If a CTA-HA or CTA/VE-HA is deployed and encryption is to be used, following
instructions provided in “File Encryption” on page 54.
If the system requires security hardening or any other special configuration,
Chapter 6, ”Cloud Tiering Appliance System Settings,”provides information for
all system settings.
Then proceed to configure the appliance for your environment as described in
Chapter 4, ”Deploying the Cloud Tiering Appliance.”
38
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Installing the Cloud Tiering Appliance
Installing the virtual edition
The CTA-VE and CTA-VE HA are installed on the VMware server. Table 7 on page 39
shows the interoperability.
Table 7
VMware ESX Server interoperability
Virtual Appliance
VMware ESX Server Comments
CTA-VE
ESXi 5.0
ESXi 5.1
Four virtual CPUs, 16 GB of RAM, 1 TB of disk space, 2 gigabit
virtual interfaces are reserved.
CTA-VE HA
ESXi 5.0
ESXi 5.1
Four virtual CPUs, 4 GB of RAM, 100 GB of disk space, 2 gigabit
virtual interfaces are reserved.
Note: If VMware snapshots will be used, reserve extra disk space when creating the VMware
datastore during installation. To estimate the total amount of disk space to reserve for the
datastore, add thirty percent of the size of the CTA-VE VMDK file for each snapshot.
The following example shows the steps to install the CTA-VE or CTA-VE HA virtual
appliance using vSphere Client 5.0:
1. Download the CTA .OVA file.
• For a CTA-VE, the file is: ctave-<version>.ova
• For a CTA-VE HA, the file is: ctaveha-<version>.ova
2. Open the vSphere Client.
a. Click the Hosts tab. To find the appliance with the most free space, consider
%CPU and %Memory.
Installing the virtual edition
39
Installing the Cloud Tiering Appliance
b. Select the line with the ESX server for the installation. A summary of the CPU,
memory, and data store capacities appears.
Per the requirements of Table 7 on page 39, this ESX Server has enough CPU and
memory available to install the CTA/VE.
40
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Installing the Cloud Tiering Appliance
3. Import the OVA file. Instructions differ depending upon VMware version. Select
File > Deploy OVF Template.
4. On the Deploy OVF Template screen, click Browse to locate the OVA file.
Installing the virtual edition
41
Installing the Cloud Tiering Appliance
5. Click Next through several screens until the Storage screen appears. Select the
destination storage on the appliance.
Note: If disk space is insufficient, a message appears under Compatibility. vSphere Client
5.0 will install with thin provisioning. If using vSphere Client 4.0 or 4.1, use the ovftool to
install with thin provisioning as described in “Deploying CTA/VE as a thin virtual
machine with vSphere Client 4.0 or 4.1” on page 43.
42
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Installing the Cloud Tiering Appliance
6. Click Next through several screens until the Ready to Complete screen appears.
Validate the information and click Finish.
7. The import may take 3–30 minutes depending on the network connection
between the VI Client and the VMware ESX Server. Approximately 1 GB will
initially be transferred across the network.
Deploying CTA/VE as a thin virtual machine with vSphere Client 4.0 or 4.1
vSphere Client 4.0 or 4.1 does not support thin provisioning from the GUI. To specify
thin provisioning, use ovftool from the command line.
1. ovftool is available from the VMware web site.
http://www.vmware.com/technical-resources/virtualization-topics/vi
rtual-appliances/ovf
2. To download and install the appropriate version:
a. Click OVF Tool.
b. Click Download.
c. Provide your VMware credentials.
3. Unzip the CTA file to create the directory for your virtual appliance. The Zip file
contains the .OVF file and .VMDK file.
• For a CTA/VE, the zip file is: fmve-<version>.zip
• For a CTA/VE HA, the zip file is: fmve-<version>_ha.zip
Installing the virtual edition
43
Installing the Cloud Tiering Appliance
4. Open a command window, and cd to c:\Program Files\VMware\VMware OVF
Tool. To see the ovftool syntax, type:
ovftool.exe -h
For example, to create a CTA, thin-provisioned, on an ESX host 10.10.38.66 that is
named cta185:
C:\Program Files\VMware\VMware OVF Tool>ovftool.exe --diskMode=thin
--datastore="vmware1 (1)" --name=cta185 --net:"VM Network"=ESX_65
c:\fmve-7.5-204/fmve-7.5-204.ovf vi://localhost?ip=10.10.38.66
where:
◆
◆
◆
◆
vCenter server is on the same Windows host where ovftool is installed, such as
localhost.
ESX host with IP 10.10.38.66 belongs to the vCenter server.
ESX_65 is the name of the VM network instead of the CTA default name, VM
Network.
vmware1 (1) is the name of the datastore as seen by the ESX host.
Note: Use double-quotes when the names contain spaces, and the fact that some slashes are
forward, and some are backward)
CTA and CTA/VE for high availability
High availability is a feature on both CTA and CTA/VE. Both the CTA-HA and the
CTA/VE-HA deliver solutions for a redundancy, which ensure that clients do not
experience data unavailability due to failure of the primary appliance.
When using CTA-HA or CTA/VE-HA for recall, callback services are configured on
the appliance or the virtual appliance.
◆
CCD is used to recall files from Centera to Celerra and VNX
◆
ACD is used to recall files from the cloud to Celerra and VNX
◆
FPolicy callback is used to recall from all secondary devices to NetApp
No callback is used for any of the NAS repository types, such as Celerra, VNX, VNXe,
Windows, Isilon, NetApp, or Data Domain when the source is Celerra or VNX.
This configuration eliminates a single point of failure for the primary callback service
and ensures transparent client access to archived data.
To fulfill requirements for high availability, recall operations can be handled by a
group of appliances such as CTAs, CTA-HAs, CTA/VEs, or CTA/VE-HAs.
High availability with Celerra or VNX primary storage
For Celerra or VNX primary storage archived to a Centera or cloud storage such as
Atmos or Amazon S3 servers, Data Movers resolve an HTTP fully qualified domain
name (FQDN) to the IP addresses of the appliances. If a Data Mover identifies
multiple IP addresses mapped to the same FQDN, it will select the first address it
finds and attempt to send the recall request. If the IP address is not responsive, the
Data Mover will select subsequent addresses for the FQDN and attempt to send the
recall requests to those addresses.
44
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Installing the Cloud Tiering Appliance
All recall requests generated by a Data Mover when resolving the FQDN are sent to a
single appliance even if multiple IP addresses are found. Each Data Mover can be
configured to send recall requests to a preferred appliance which provides
coarse-grained load balancing of recall requests at the Data Mover level. “Deploying
CTA with Celerra or VNX” on page 61 provides details on configuring Celerra or
VNX Data Movers.
To ensure that the Data Mover will contact CTAs and CTA-HAs for recall, first create
a DNS record for the CTA, then add the IP addresses of all CTA-HAs to that record.
The same name points to the IP addresses of the CTA and all HA recall devices.
“Configure name resolution for archiving” on page 65 provides details on how to use
local hostname resolution or DNS to add the HA appliances.
Run ccdsetup or acdsetup on all CTA-HAs or CTA/VE-HAs that will process recall
requests from the Celerra or VNX Data Movers. These scripts link multiple
appliances to process recall requests from a common set of Celerra or VNX Data
Movers. “Configuring Celerra or VNX to Centera or cloud archiving on the CTA” on
page 66 provides details on ccdsetup and acdsetup.
No additional appliances are involved in recall when the CTA or CTA/VE archives
data from Celerra or VNX primary storage to NAS repositories serving as secondary
storage. The Data Movers use the CIFS and NFS protocols to recall data directly from
secondary storage.
High availability with NetApp primary storage
NetApp filers allow FPolicy clients (such as CTA, CTA-HA, CTA/VE, or
CTA/VE-HA) to register for callbacks in response to user access to files with specific
attributes. When using the appliances, a callback will be generated when a
read/write operation occurs to a file with the CIFS offline bit set.
For NetApp primary storage, multiple appliances can register in the primary or
secondary FPolicy groups of the filer. In the event that a registered server becomes
unresponsive, it is removed from its group. Recall requests will be sent by the filer in
a round-robin fashion to the IP addresses registered in the primary group. If there are
no responsive IP addresses in the primary group, then the requests are load-balanced
across the servers in the secondary group.
Run fpsetup on the CTA-HAs or CTA/VE-HAs that will process recall requests. Use
this script to link together multiple appliances that will process recall requests that
are sent from a common set of NetApp Filers. Later, when configuring NetApp filers,
you will have the option to select specific appliances that will register in the primary
and secondary groups. “Configuring NetApp archiving on the CTA” on page 77
provides details on fpsetup.
Appliances are always involved in recall when the CTA or CTA/VE archives data
from NetApp primary storage to any secondary storage location. NetApp filers do
not recall data directly from Celerra or VNX, Centera, or NetApp storage.
Note: If file encryption is not in use, a single CTA-HA or CTA/VE-HA can provide redundancy
for multiple CTAs or CTA/VEs. A single CTA or CTA/VE can have multiple CTA-HAs or
CTA/VE-HAs registered to provide redundancy. Do not use a CTA to provide redundancy for
another CTA or a CTA/VE to provide redundancy for another CTA/VE.
CTA and CTA/VE for high availability
45
Installing the Cloud Tiering Appliance
Network console management for Gen 8 models
In the event that CTA or CTA-HA becomes unresponsive, network console
management allows users to control the appliance or reboot the system. For Gen 8
models based on Intel C1U hardware, communication is established through the
dedicated management port on the back of the appliance which is labeled MGMT in
Figure 16 on page 35.
Note: For security purposes, network console management should be enabled on a network
with access limited to system administrators only.
Use the local console to configure the CTA for network console management and to
change the BMC Web Console Management User password.
1. Connect the power cord and power on the appliance.
2. Using a crossover cable, connect one end to your laptop Ethernet port and the
other end to the management port on the back of the appliance. The laptop must
be running Java Run Time Environment (JRE) version 6.0 update 10 or later.
3. Configure the laptop with static IP 192.168.1.2 and netmask 255.255.255.0.
4. In a web browser with the popup blocker disabled, type the IP address:
192.168.1.1. The CTA BMC Web Console appears.
5. To login to the console, type the username and password:
• Username: root
• Password: rain
The integrated BMC Web Console appears:
To configure remote console management:
1. Select the Configuration tab.
46
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Installing the Cloud Tiering Appliance
2. Select IPv4 Network.
– For LAN Channel, select Intel(R) RMM.
– Change the IP address to a valid network IP address.
– Click Save.
Note: Once remote console management is configured for the network IP address, local console
management is no longer available.
To change the BMC Web Console Management User password:
1. Select the Configuration tab.
Network console management for Gen 8 models
47
Installing the Cloud Tiering Appliance
2. Select Users.
– Under User Name, select root.
– Click Modify User. The Modify User page appears.
3. Type and confirm a password for the root user.
Using CTA CLI commands
To control the appliance from the console:
1. Type the network IP address of the BMC Web Console.
2. Login with the root user and password.
3. Select the Remote Control tab.
4. Select Console Redirection and click Launch Console.
5. A window appears with a message asking to open jviewer.jnlp. Click OK. A Java
applet window appears.
48
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Installing the Cloud Tiering Appliance
6. Type the CTA username and password to login.
“Command line interface” on page 56 provides information on the CTA CLI.
Rebooting the system
To reboot the appliance from the console:
1. Type the network IP address of the BMC Web Console.
2. Login with the root user and password.
3. Select the Remote Control tab.
4. Select Server Power Control.
Network console management for Gen 8 models
49
Installing the Cloud Tiering Appliance
5.
Select Power Cycle Server and click Perform Action.
Remote Control
lbos seCMn )'OU lorernolelymot <.,.. afldClOfllfollle MM!r
Power Control and Status
h.Pettoun Acliorl
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Installing the Cloud Tiering Appliance
Performing a CD clean install on the appliance
CTA and CTA-HA are shipped with the software installed on the appliance. If
needed, a CD clean install installs all necessary packages and binary files. To perform
a clean install of CTA/VE or CTA/VE-HA see “Installing the virtual edition” on
page 39.
Before starting the installation, check to see if the CTA is connected to another
appliance for HA, another CTA, or a stand-alone appliance with a callback daemon
running. If so, stop all callback daemons with the following commands:
fpolicycallback stop
atmoscallback stop
celerracallback stop
To perform a CD clean install on a CTA or CTA-HA:
1. If using a downloaded ISO image:
a. Run md5sum to verify the image integrity.
EMC posts the output of the md5sum commands in the README file that is
posted to EMC Online Support, with all the downloads. “Where to get help”
on page 13 provides information on how to access EMC Online Support.
The ISO files are named:
cta.x86_64-10.0.XXX.iso
ctaha.x86_64-10.0.XXX.iso
b. Burn a CD from the ISO image.
2. Insert disc for CTA or CTA/HA depending on the CTA appliance type.
3. Boot CTA Appliance from the inserted disc.
4. When the appliance boots, choose Install/Restore_cta.
5. Choose Yes. when the Destroying ALL data on /dev/sda, continue prompt
appears.
The appropriate packages are installed.
A restart occurs after installation completes and the login prompt appears.
6. Log in with username root and password rain.
7. Use the Cloud Tiering Appliance setup tool menu that appears to configure the
time and network settings.
If the CTA will be configured for Celerra or VNX to Centera or cloud archiving,
use FileMover Settings as described in step 7 of “Adding a Celerra or VNX to the
CTA configuration” on page 62. Configure the single set of credentials for recall
before running ccdsetup.sh or acdsetup.sh as described in “Configuring Celerra
or VNX to Centera or cloud archiving on the CTA” on page 66.
8. For CTA 10.0, load the CTA serial number on the appliance by choosing Product
Registration from the CTA GUI dashboard. This starts the CTA Registration
Wizard.
9. In the second screen of the CTA Registration Wizard, enter the CTA product Serial
number and click OK.
The EMCSERIALNUMBER appears on a a pull out card on the front of the
appliance or printed on the media kit label for CTA/VE versions of the product.
Performing a CD clean install on the appliance
51
Installing the Cloud Tiering Appliance
Adding the CTA serial number
For CTA 9.0 or later, load the CTA serial number on the appliance with the CLI
command:
rffm setEmcSerialNumber <EMCSERIALNUMBER>
where EMCSERIALNUMBER is located on a pull out card on the front of the
appliance or printed on the media kit label for CTA/VE versions of the product.
Configuring CTA
Before proceeding with the setup, ensure that you have the following information for
each appliance:
◆
IP address
◆
Subnet mask
◆
Hostname
◆
Default gateway IP
◆
◆
DNS server IP — If specifying multiple IP addresses, use spaces to separate IP
addresses.
CTA serial number from CTA packaging
1. Set up the appliance:
• For a CTA or CTA-HA, connect the keyboard and monitor to the appliance.
Connect the power cord and power on the appliance. If a keyboard and
monitor are not available, connect a PC or laptop using:
– the serial cable connected to the serial port for Gen 6 and Gen 7 models.
– a crossover cable connected to the MGMT port for Gen 8 models.
• For a CTA/VE, power on the appliance.
2. Log in to the appliance by using the local keyboard and monitor. Type root as the
login name. Type rain as the password.
The Cloud Tiering Appliance setup tool appears. This tool performs basic setup
tasks that are not available through the CTA GUI.
3. Select Change Cloud Tiering Appliance Password, and change the password.
4. Select Configure Cloud Tiering Appliance Networking. The network
configuration menu appears.
Use the menu to:
• “Configure the CTA network” on page 53
• “Configure the hostname, domain, and DNS server” on page 53
5. Select Configure date and time (including timezone). The current date/time and
a list of current NTP servers are displayed.
Use the menu to set the time zone and date for the appliance and configure an
NTP server.
Note: When archiving to the cloud (for example, Atmos, Amazon S3 , or Azure), the CTA
clock must be accurate and in sync with the cloud service. Therefore it is required to have
an NTP server configured when archiving to these destinations.
52
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Installing the Cloud Tiering Appliance
Configure the CTA network
Configure the CTA network:
1. Select option 1 from the Network Configuration menu. The Cloud Tiering
Appliance Network Setup, Main Menu appears.
On the list of available physical interfaces on the appliance, eth0 appears
highlighted. To highlight a different interface, use the up arrow and down arrow
keys.
2. With eth0 highlighted, press Enter. The configuration menu for the eth0 interface
appears:
• Use the up arrow and down arrow keys to highlight the IP address field. Press
Enter and type a new IP address value into the New Value column. Press
Enter.
• Repeat the process to provide the subnet mask, gateway, and MTU settings.
3. When the configuration for this interface is complete, press the left arrow key to
exit the eth0 interface configuration.
4. To save the interface configuration, select Yes and press Enter. Note that the
changes are saved, but will not be implemented until the Cloud Tiering
Appliance Network Setup menu is exited.
5. Press the left arrow key to exit from the Cloud Tiering Appliance Network
Setup, Main Menu. When prompted, select Yes to save your changes.
Configure the hostname, domain, and DNS server
Configure the hostname, domain, and DNS servers:
1. Select option 2 from the Network Configuration Menu. The following menu
appears:
EMC Cloud Tiering Appliance Setup Tool (Configure Hostname, Domain
and DNS Server(s))
Hostname
= fm
Domain
=
DNS Server
=
Do you want to change the configuration [Y/N]?
2. Type Y. Use the menu to configure the hostname, domain, and DNS servers.
The new hostname, domain, and DNS server information is summarized after all
the changes are entered, and you are given the ability to accept or make further
changes to these settings. To keep the new settings and return to the network
configuration menu, press Enter.
3. Verify that the network configuration has been saved and network connectivity
can be established properly.
Configuring CTA
53
Installing the Cloud Tiering Appliance
Update hosts file
If /etc/hosts on the CTA requires customization, do not manually edit the file
directly.
To customize the /etc/hosts file:
1. Edit the /etc/hosts.local file.
2. Select option 4 from the Network Configuration Menu to import changes from
/etc/hosts.local into /etc/hosts.
Note: If /etc/hosts is customized, maintain /etc/hosts.local to preserve those customizations
and restore /etc/hosts if needed.
File Encryption
Archiving to cloud services such as Atmos or Amazon S3 is a means of archiving at
rest data. However, there is a risk of compromising sensitive data stored in the cloud
unless file encryption is used.
To archive to the cloud with file encryption, a primary CTA or CTA/VE must be
deployed with a CTA-HA or CTA/VE-HA. The HA appliance is configured with a
keystore that replicates the keystore on the primary appliance. As long as a key is
active and the keystores on the HA and primary appliances are in sync, policy-based
file level encryption is enabled.
Note: If file encryption is active, a single CTA-HA or CTA/VE-HA cannot provide redundancy
for multiple CTAs or CTA/VEs.
Enabling keystore replication
The CTA supports encryption of data that is archived to a cloud platform, such as
Atmos or Amazon S3. To enable encryption on the CTA, you must enable replication
of the encryption keystore on the CTA-HA or CTA/VE-HA. The primary keystore is
located on the CTA, and the replica is created on the HA. Before enabling encryption,
ensure that NTP is configured on the CTA or CTA/VE and on the HA appliance.
To enable keystore replication on the CTA-HA or CTA/VE-HA, type:
krdsetup init_rffm
This stores the IP address of the main CTA or CTA/VE and the timestamp of the most
recently replicated keystore in the configuration file:
/opt/rainfinity/filemanagement/conf/krd.xml
Then it starts the keystore replication daemon that automatically keeps the keystore
on the high availability appliance in sync with the primary appliance.
54
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Installing the Cloud Tiering Appliance
Configuring and using file encryption
Once keystore replication has been enabled, the file encryption key can be generated
using the GUI on the primary appliance by selecting Configuration > File
Encryption Key:
To archive to a cloud service with file encryption on, click Encrypted when adding a
rule to an archive policy. If no key is active, Encryption is grayed out.
To migrate secondary storage tier data to a cloud service with file encryption on, click
Encryption when selecting the destination for the repository migration task.
If an active key has not been replicated to the CTA-HA or CTA/VE-HA, an error
appears indicating that file encryption is not enabled.
Note: If a system administrator changes the CTA hostname or configures a network interface,
attempts to generate an encryption key on the CTA or synchronize a keystore on the CTA-HA
might fail. To work around this problem, reboot the CTA.
Graphical user interface
To access the graphical user interface from a web browser:
1. In the navigation field of the web browser, type the IP address of the CTA. The
CTA GUI appears.
2. Type the username and password for the default account which are:
• Username: admin
• Password: rain
Selections appear as follows:
◆
◆
◆
◆
Dashboard — Top leve view displays summaries of Common Tasks, Alerts, and
Reports.
Schedule — Displays a list of scheduled tasks that are currently being processed
and the status of each task.
Archived Files — Displays an archived file report. Also provides a search option
to find archived files, recover stub files, and delete orphan files.
Policies — Provides options that apply to creating and managing policies,
including:
Graphical user interface
55
Installing the Cloud Tiering Appliance
• A list of policies, file matching expressions, and NAS destinations.
• Create new policy.
• Create new file matching expression.
• Create new NAS destination.
◆
◆
Configuration — Provides configuration of servers, repositories, and settings for
servers.
System — Provides system configuration of users, passwords, logs, alerts, and
security.
Command line interface
As an alternative to the GUI, you can use a command line interface to send
commands to the filemanagement daemon.
To log in to the CLI by using SSH, the default username and password are:
◆
Username: root
◆
Password: rain
The most commonly used commands are:
◆
◆
◆
◆
fmsupportdump — Creates a dump of the appliance's current state for technical
support. Run this command from /var.
rffm — Configures the appliance and issues all commands that the GUI interface
supports. To see a list of all commands available, type rffm --help or to view the
man page for more detailed help, type man rffm.
fmbackup/fmrestore — Backs up and restores the configuration as described in
“Backing up the configuration” on page 103.
rssystat — Displays statistics about the CTA.
Man pages for the command line tools are stored in the software installation
directory. To access the man pages, type man command_name as in, man rssystat.
56
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
4
Deploying the Cloud
Tiering Appl ance
This chapter contains the following sections:
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
Deployment process for archiving............................................................................... 58
Supported platforms ...................................................................................................... 60
Deploying CTA with Celerra or VNX ......................................................................... 61
Deploying CTA with NetApp ...................................................................................... 74
Deploying the CTA with a VNXe ................................................................................ 80
Deploying CTA with a Windows server .................................................................... 81
Deploying CTA with Isilon........................................................................................... 84
Deploying the CTA with a Data Domain ................................................................... 93
Configuring a NAS-based repository.......................................................................... 94
Deploying CTA with Amazon S3 ................................................................................ 95
Deploying CTA with Atmos......................................................................................... 96
Deploying CTA with Azure ......................................................................................... 97
Deploying CTA with Centera....................................................................................... 98
Deploying the Cloud Tiering Appliance
57
Deploying the Cloud Tiering Appliance
Deployment process for archiving
Figure 19 on page 58 illustrates how the EMC Cloud Tiering Appliance (CTA) or
Cloud Tiering Appliance/VE is deployed for archiving.
Note: The first time you install and configure the CTA system, click the Add Task Wizard in the
CTA dashboard to guide you through the steps of configuring your system, archivng or
migration task
.
CTA Setup
1. Install the CTA/VE, if applicable.
2. Add the CTA serial number.
3. Configure CTA networking.
4. Enable the keystore on the HA for
file encryption to the cloud, if applicable.
1.
2.
3.
4.
5.
Celerra or VNX to EMC Centera
or Atmos Configuration
Configure Celerra or VNX properties.
Initialize recall services.
Configure name resolution for recall.
Configure FileMover API.
Configure DHSM.
Celerra or VNX to NAS Configuration
1. Configure Celerra or VNX properties.
2. Configure FileMover API.
3. Configure DHSM.
NetApp Configuration
1.
2.
3.
4.
Configure ONTAPI.
Configure vFilers, if applicable.
Initialize recall services.
Configure NetApp properties.
Destination Configuration
1. Configure NAS repositories.
2. Configure non-NAS repositories.
Define Policies
1. Create file matching expressions
and archive destinations
2. Specify policy type, retention, delayed
stubbing, stub retention (as applicable)
Create Task
1. Create an archive, delete, or
auxiliary task
2. Select source (as applicable)
Run Simulation Task (Optional)
1. Select Run Simulation Now
2. Collect real-time results in CTA
3. Review policy efficacy against
real-time results
Run Policy Task
1. Determine optimal task scheduling
2. Select archive conditions or start
times (as applicable)
3. Monitor archiving activity for errors
CNS-001255
Figure 19
Cloud Tiering Appliance deployment process
The top of the flowchart describes deploying the CTA or CTA/VE in various
environments. For Celerra or VNX to NAS configuration, NAS repositories may be
Celerra, VNX, VNXe, Windows, Isilon, NetApp, or Data Domain.
◆
58
“Supported platforms” on page 60 lists the platforms supported for archiving and
migration tasks.
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Deploying the Cloud Tiering Appliance
+
"Appliance setup" on page 38 outlines the procedure to deploy aCTA or
CTA/VE.
Steps in the five boxes at the bottom of the flowchart are performed by using the CTA
GUI. Online help describes these steps in detail.
Deployment process for archiving
Deploying the Cloud Tiering Appliance
Supported platforms
Platform support varies depending on the task performed.
Table 8 on page 60 shows platform support for archiving. Support for stub retention
is listed in the table footnotes.
Table 8
Supported platform matrix for archiving
Primary tier
Secondary tier
Celerraa
VNX
NetApp
Celerra
VNX
VNXe
Windows
Isilon
NetApp
Data Domain
Centera
Atmos
Amazon S3
Microsoft Azure
a. Stub retention is not supported for Windows or Amazon S3.
Note: Celerra, VNX, VNXe, Windows, Isilon, NetApp, and Data Domain are collectively
referred to as NAS repositories as described in “Configuring a NAS-based repository” on
page 94.
Table 9 on page 60 shows platform support for file migration.
Table 9
Supported platform matrix for file migration
Source
Destinationa
Celerra
VNX
Celerra
VNX
VNXe
Isilon
NetApp
Celerra
VNX
VNXe
Isilon
Windowsb
VNX
VNXe
a. Destination must be offline until migration is complete, otherwise there is a risk of
data loss or damage.
b. Windows migration is not policy-based.
Note: While other file servers may be selected as CIFS targets, only
the source and destination combinations listed have been qualified
and are supported.
60
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Deploying the Cloud Tiering Appliance
Deploying CTA with Celerra or VNX
To use CTA with a Celerra or VNX Data Mover, first perform configuration steps on
the CTA, and then on the Celerra or VNX Control Station.
Note: Celerra supports DART versions 6.0 or earlier. VNX supports DART version 7.0 or later.
With Celerra or VNX as a source, the deployment requirements vary with task type.
Table 10
Celerra or VNX deployment checklist
Configure:
File Migratiion
Archiving
System prerequisites
✓
✓
Celerra/VNX properties
including NDMP
NDMP not required
Callback daemon: CCD, ACD
N/A
✓
Name resolution
N/A
✓
Celerra/VNX Control Station
✓
✓
DHSM
✓
✓
Prerequisites for using Celerra or VNX as a file migration source or destination
To migrate files to or from a Celerra or VNX Data Mover, ensure that the following
conditions are satisfied:
◆
◆
◆
◆
For NFS, CTA has root access with read/write permission on source and
destination exports.
CIFS user has local administrator access on all source and destination shares and
is part of the Backup Operators group.
If migrating files from a source that is shared and exported, CTA has root access
with read/write permission to both shares and exports.
If migrating dedupe files from VNX to Isilon, set the backup data threshold for
VNX File Deduplication and Compression on a Data Mover to 0 before migration:
$fs_dedupe -default -set <movername> -backup_data_threshold 0
Where movername is the name of the Data Mover.
After migration, set fs_dedupe back to its original value.
Note: Do not run any other backup applications on the Data Mover while migration is
running because this is a global parameter that will cause all other backup applications to
inflate dedup files.
◆
◆
Snapsure snapshots are enabled on the source.
There is a system user for the XML API setup on the Celerra or VNX Control
Station. Step 2 on page 69 describes how to set up the user.
Note: The system user for the XML API is not needed for Celerra or VNX as a destination.
Deploying CTA with Celerra or VNX
61
Deploying the Cloud Tiering Appliance
◆
For every server, properties are configured on the CTA for:
• Control Station IP address for Celerra or VNX as source
• NDMP username and password
“Adding a Celerra or VNX to the CTA configuration” on page 62 provides details
on configuring a Celerra or VNX server.
Prerequisites for Celerra or VNX as an archive source
To archive data from a Celerra or VNX Data Mover, the CTA requires access to the
FileMover API (TCP port 5080).
To archive NFS data, the CTA needs the following:
◆
Mount v3 RPC service
◆
NFS v3 RPC service
◆
NLM v4 RPC service
◆
Root access with read/write export permissions for all NFS data that will be
archived.
To archive CIFS data, the CTA needs SMB over NetBIOS (TCP port 139).
Direct command line access to the Celerra or VNX Control Station is not used by the
CTA.
When configuring Celerra or VNX Data Mover properties on the CTA, plan to
provide:
◆
Credentials for a FileMover API user. This single set of credentials is used for
both archive and recall.
◆
Control Station IP address.
◆
(For CIFS archiving only) The NetBIOS name of the file server or Kerberos FQDN.
◆
(For CIFS archiving only) Credentials for “Windows domain user” on page 127.
When archiving to a NAS repository, virus scanning on the destination will
negatively impact CTA performance and should be disabled. Virus scanning on the
destination could also delete files, leaving stub files on primary storage that cannot be
opened. Virus scanning can be enabled on the source when needed, however
scanning on read should not be enabled because it can cause a timeout and no reply
errors on the source during archiving. To disable virus scanning on the Celerra or
VNX, mount the file system with the noscan option.
Adding a Celerra or VNX to the CTA configuration
Note: The VNX Properties page is not displayed. The configuration process is the same as for
the Celerra. To add a VNX, follow the instructions for Celerra, substituting VNX for Celerra
throughout.
1. In the navigation field of the web browser, type the IP address of the CTA. The
CTA GUI appears.
2. Type the username and password for the default account which are:
• Username: admin
• Password: rain
62
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Deploying the Cloud Tiering Appliance
3. Select Configuration and File Server. The File Server List appears. Click Add.
4. On the Create File Server page that appears, select Celerra. Click OK.
5. For each step in the File Server wizard, provide the required information
indicated with a red asterisk and click Next.
Step
Description
Basic File Server
Information
Type the NetBIOS server name.
Note: To identify the Celerra as a Virtual Data Mover, select the checkbox.
IP Addresses
Type the Celerra Data Mover IP address:
• When editing an existing server, click Update to retrieve the IP address from the DNS
that is based on the server name.
• To specify an additional IP address, click Add.
• To delete an existing IP address, select an IP and click Delete.
The Control Station IP is required for file migration transactions and is used to create a
snapshot of the source. For archiving, this allows CTA to automatically perform some
prerequisite tasks for archiving as described in “Configuring automatically created DHSM
connections for file migration or archiving” on page 68. If this field is empty, the CTAtakes no
action and the prerequisite tasks must be performed manually.
CIFS Specific
Settings
This is the Windows domain user to be used by the appliance. The domain user must be a
member of the local Administrator group and part of the Backup Operators group on the
Celerra or VNX system. “Windows domain user” on page 127 provides more information.
Specify either a NetBIOSdomain or a Kerberos FQDN. The Kerberos FQDNis a CTAserver
configuration setting, and if selected, the same FQDN applies to all servers. Before
selecting the Kerberos FQDN option, follow steps in “Configuring Windows for Kerberos” on
page 129 to configure your Fully Qualified Domain on the CTA.
Note: The CIFS credential is not required if the Celerra or VNX system performs only NFS
archiving.
NDMP Specific
Settings
For file migration, type the username and password for an NDMP user on the source and
destination servers. By default, the port for NDMP traffic is 10000.
To create an NDMP user on a Celerra Data Mover, log in to the Celerra Control Station as
root, and type:
/nas/sbin/server_user <data_mover> -add -md5 -passwd
<user>
where data_mover is the name of the source or destination server, and user is the
username for login. The command will prompt for a password.
Note: NDMP specific settings do not apply for Windows to VNX migration.
Deploying CTA with Celerra or VNX
63
Deploying the Cloud Tiering Appliance
Step
Description
Celerra or VNX
system as Source
This option configures the CTA to archive data from the Celerra Data Mover. If multiple
appliances are connected to the same Celerra Data Mover, only one appliance should be
configured with the Celerra as Source. This option is required only if the Celerra is serving
as a source for archiving.
Note: Multiple appliances may be configured to archive data from a single Celerra Data
Mover, but only one CTA or CTA/VE should be used to archive data froma single filesystem.
CCD DNS Name
ACD DNS Name
This step appears
if Celerra as
Source or VNX as
source is yes.
Directory
Exclusion List
This step appears
if Celerra as
Source or VNX as
source is yes.
The CCD DNS Name is required if archiving to a Centera. For the CCD DNS name, type the
FQDN of the Celerra Callback DNS entry. Note that the FQDN is case-sensitive.
The ACD DNS Name is required if archiving to a cloud storage server. For the ACD DNS
name, type the FQDN of the Cloud Callback DNS entry. Note that the FQDN is
case-sensitive.
Note: The DNS names for the Celerra Callback agent and Cloud Callback agent must be
distinct. They cannot be the same. If a callback name is not specified, archive tasks to the
destination will not start.
These are the directories to exclude for all tasks that use scanning. Migration tasks do not
scan, so this setting does not apply to file migration. The CTA ignores all systemdirectories
such as, etc, lost+found, and ckpt by default.
Note: Verify that stub files are not in the excluded directories. CTA will not access the
excluded directories and the stub files will become orphans.
6. Review the Summary and click Finish to define the Celerra file server.
7. Select Configuration and FileMover Settings. The FileMover Settings page
appears.
Type the username and password for FileMover API authentication and callback
HTTP authentication. The system uses this username and password to create an
HTTP connection by using XML API. This same username and password are
used when creating the FileMover API user in step 2 of “Prerequisite tasks on the
Celerra or VNX Control Station for file migration or archiving” on page 67.
The FileMover setting applies to all Celerra or VNX file servers configured on the
CTA. If all Celerra or VNX file servers are archive targets only, the FileMover setting is not
required
Note: Because CTA migrates data using NDMP, it can migrate both NFS and CIFS metadata in
a single protocol migration, provided that the NDMP format does not require conversion. For
example when both the source and destination are Celerra/VNX systems , no conversion is
necessary. However to migrate NFS and CIFS metadata between ystems that require NDMP
format conversion, you must both export and share the file system. For example, CTA cannot
migrate CIFS data in an NFS migration involving systems other than Celerra/VNX. This is
because after CTA converts the NDMP data stream, it can only migrate CIFS metadata using
CIFS protocol.
64
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Deploying the Cloud Tiering Appliance
Configure name resolution for archiving
When the Celerra or VNX Data Mover needs to establish a connection to the
appliance to recall data from a Centera or a cloud service, it tries to resolve the FQDN
from the HTTP DHSM connection in its local hosts file. If it cannot be resolved locally,
the Data Mover will use DNS.
Note: These instructions pertain only to configuring the hosts file on the Celerra or VNX.
“Configuring CTA” on page 52 provides information on how to configure the CTA hosts file.
◆
To use DNS:
a. Create a DNS entry for the callback daemon that points to the appliance.
As a best practice, the CTA hostname and CCD hostname should be different.
Using the same hostname for both can raise issues when trying to login to the
appliance.
b. Create multiple entries by the same name for each callback appliance.
c. For each entry that is created, select the checkbox for Create associated
pointer (PTR) record to ensure that it will be included in the Reverse Lookup
Zones list.
Note: The Celerra or VNX FileMover supports DNS HA failover. If the DNS server resolves the
callback daemon hostname to multiple IP addresses, the Celerra or VNX FileMover
transparently switches to the server at the next available IP address.
◆
DNS is the preferred method for name resolution. If using DNS is not feasible, use
local hostname resolution:
a. Log in to the Celerra or VNX Control Station as root and mount the Data
Mover to edit the local hosts file with vi:
mount server_2:/ /mnt/source
cd /mnt/source/.etc
Deploying CTA with Celerra or VNX
65
Deploying the Cloud Tiering Appliance
vi hosts
where server_2 is the name of your Celerra or VNX Data Mover.
b. Edit the hosts file to add one line for each appliance, similar to the following
example:
10.0.0.1
10.0.0.2
10.0.0.3
10.0.0.1
10.0.0.2
10.0.0.3
<rainccd.domain>
<rainccd.domain>
<rainccd.domain>
<rainacd.domain>
<rainacd.domain>
<rainacd.domain>
#
#
#
#
#
#
CCD
CCD
CCD
ACD
ACD
ACD
on
on
on
on
on
on
CTA-HA
CTA
CTA/VE
CTA-HA
CTA
CTA/VE
where:
– rainccd.domain is the FQDN that will be used to create the HTTP DHSM
connection described in“CCD DNS Name” on page 64.
– rainacd.domain is the FQDN that will be used to create the HTTP DHSM
connection described in “ACD DNS Name” on page 64.
c. Save the file and confirm that the Celerra or VNX Control Station is not
mounted to the Data Mover:
cd ~
umount /mnt/source
Configuring Celerra or VNX to Centera or cloud archiving on the CTA
To archive from a Celerra or VNX to a Centera or cloud storage, configure the
callback service so that the CTA is in the recall path.
Configure the callback service to recall from Centera
To configure recall from the Centera:
1. From the console on the CTA, log in as root.
2. Type ! to escape to the command line and type:
ccdsetup init_rffm
3. Type n when the following message appears:
By default the Celerra Callback Daemon will connect to the CTA
service on the local machine.
Do you wish to configure another CTA? (y/n)
4. If there is a secondary callback agent such as a CTA-HA, log in on that agent as
root, and repeat step 2 and step 3. In step 3, type y to provide the IP address and
the root password of the CTA.
If an invalid IP address is provided, the CCD.log file located in
/var/log/rainfinity/filemanagement/recall will fill with errors to indicate that
there was no response from the primary agent. To correct the problem, repeat
step 2 through step 4 of this procedure.
Configure the callback service to recall from the cloud
To configure recall from the cloud service such as Atmos or Amazon S3:
1. From the console on the CTA, log in as root.
2. Type ! to escape to the command line and type:
acdsetup init_rffm
3. Type n when the following message appears:
66
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Deploying the Cloud Tiering Appliance
By default the Cloud Callback Daemon will connect to the CTA service
on the local machine.
Do you wish to configure another CTA? (y/n)
4. If there is a secondary callback agent such as a CTA-HA, log in on that agent as
root, and repeat step 2 and step 3. In step 3, type y to provide the IP address and
root password of the primary callback agent.
If an invalid IP address is provided, the ACD.log file located in
/var/log/rainfinity/filemanagement/recall will fill with errors to indicate that
there was no response from the primary agent. To correct the problem, repeat
step 2 through step 4 of this procedure.
Prerequisite tasks on the Celerra or VNX Control Station for file migration or archiving
If a Celerra or VNX has not been configured as a source for file migration or
archiving, perform the following steps:
1. Enable filename translation on the Celerra or VNX Control Station.
The CTA, CTA-HA, or CTA/VE expects that all filenames are derived from the
Celerra or VNX Network Server in UTF-8 format. To preserve filenames correctly:
a. Log in to the Celerra or VNX Control Station as nasadmin.
b. Use a text editor to open the file: /nas/site/locale/xlt.cfg.
c. Locate the last line of the file. Typically the last line appears as:
::::8859-1.txt: Any thing that didn’t match above will be assumed
to be latin-1
Add the following line immediately above the last line:
::CTA_IP_ADDR::: CTA requires no translation (UTF-8)
where CTA_IP_ADDR is the IP address of your appliance. Add an entry for
each CTA. HA appliances are not added.
For example, if the IP address is 10.10.18.1, type:
::10.10.18.1::: CTA requires no translation (UTF-8)
To specify a subnet, type:
::10.10.18.0,255.255.255.0::: CTA requires no translation (UTF-8)
d. To update the configuration, type:
/nas/sbin/uc_config -update xlt.cfg
e. To verify the new configuration, type:
/nas/sbin/uc_config -verify CTA_IP_ADDR -mover ALL
where CTA_IP_ADDR is the IP address of your appliance. Output will appear
in the format:
server_name : CTA_IP_ADDR is UTF-8
2. Create the FileMover API user. Log in to the Celerra or VNX Control Station CLI
as root and type the command:
/nas/sbin/server_user <data_mover> -add -md5 -passwd <user>
For example: /nas/sbin/server_user server_2 -add -md5 -passwd rffm
The username and password must match the FileMover settings configured on
the CTA in Step 7 on page 64.
Deploying CTA with Celerra or VNX
67
Deploying the Cloud Tiering Appliance
3. Allow the IP addresses of the CTA or CTA/VE to open connections to the
FileMover interface. While logged in to the Celerra or VNX Control Station as an
administrator (such as “nasadmin”), run the following command for all IP
addresses of all appliances that will perform archiving or service recall requests
for the Data Mover:
server_http <data_mover> -append dhsm -users <user> -hosts
<ip_address>
For example: server_http server_2 -append dhsm -users rffm -hosts
192.168.0.100,192.168.0.101, <CTA_IP_address>
Note: A single Celerra or VNX Data Mover can be configured as an archiving source with
multiple appliances, but more than one CTA or CTA/VE should never be used to archive
data from a single filesystem.
4. Enable DHSM (FileMover) for the Data Mover. To enable DHSM and keep it
enabled if the Data Mover reboots, run the following command once:
server_http <data_mover> –service dhsm –start
5. Enable DHSM for specific filesystems that will be used as archiving sources. To
enable DHSM and keep it enabled if the Data Mover reboots, run the following
command once per filesystem.
fs_dhsm -modify <primary_fs> -state enabled
For example: fs_dhsm -modify fileSystem1 -state enabled
6. Ensure that the DHSM offline attribute is enabled for filesystems that will be used
for archiving. To verify that the offline attribute is on, run the command:
fs_dhsm -i <fs_name> | grep ’offline attr’
• If the offline attribute is on, the following line will appear:
offline attr = on
• If the offline attribute is off, turn it on with the command:
fs_dhsm -m <fs_name> -offline_attr on
!
CAUTION
Once the offline attribute is set to on, it must remain on. Disabling the offline
attributes after executing archive tasks can lead to data loss.
Create one or more connections from the Data Mover to the secondary storage
locations for each filesystem that will be archived. Each CIFS or NFS repository used
to store archived data needs to be configured as a DHSM connection for the Celerra
or VNX filesystem. If data will be archived to a Centera or cloud storage service, a
DHSM connection that uses the HTTP protocol must be configured for that filesystem
to the CTA or callback FQDN.
Configuring automatically created DHSM connections for file migration or archiving
The CTA or CTA/VE can automatically create DHSM connections for Celerra
systems running DART 5.6 through DART 6.0, or VNX systems running DART 7.0.
To configure this feature, perform the following steps as root user on the Celerra or
VNX and the appliance:
Note: Run the commands on the Celerra or VNX as root user, and not as nasadmin.
68
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Deploying the Cloud Tiering Appliance
1. Check to see if the XML API server is running on the Celerra or VNX, type:
ps -ef | grep start_xml_api_server | grep -v grep
The following example shows a server that is already running:
[root@celerra01 sbin]# ps -ef | grep start_xml_api_server | grep -v
grep
root
14821 3226 0 15:41 ?
00:00:00 /bin/sh
/nas/sbin/start_xml_api_server
• If it is running, restart the server by typing:
/nas/sbin/hup_api
• If it is not running, start the server by typing:
/nas/sbin/start_xml_api_server
If the server fails to start or restart:
a. Delete the file /nas/api/exit_now.
b. Delete the file /nas/api/api_retry.
c. Repeat the process to check if the server is running and to start it.
If the XML API server still fails to start, contact Celerra or VNX support.
2. Create a new system user for the XML API. Use the API GUI on the Celerra or
VNX Control Station.
• For a new user on a Celerra running DART 6.0:
a. Log in as root and select: Security > Administrators > Users > New.
b. The New User screen appears.Define a new system user:
– In the root group.
– With client access option API access allowed.
Use the same username and password that was defined for the FileMover API
user in step 2 of “Prerequisite tasks on the Celerra or VNX Control Station for
file migration or archiving” on page 67. If the user cannot be added to the root
group, use the filemover group instead.
Password Expiration appears blank, but the Celerra may fix a number of days.
If the password expires, the CTA will be unable to:
– connect to the Data Mover to automatically create DHSM connections.
– migrate from the server.
When a user password is updated or changed on the Celerra Control Station,
update:
– FileMover settings for the Celerra Properties on the appliance as in step 7 of
“Adding a Celerra or VNX to the CTA configuration” on page 62.
– FileMover API password as in step 2 of “Prerequisite tasks on the Celerra or
VNX Control Station for file migration or archiving” on page 67.
– DHSM connection password with the command:
fs_dhsm -connection <primary_fs> -modify <cid> -password
<new_password>
Note: This command applies when updating passwords for Centera and cloud DHSM
connections only. This does not apply for NAS repository connections.
Deploying CTA with Celerra or VNX
69
Deploying the Cloud Tiering Appliance
• For a new user on a VNX running DART 7.x:
Log into Unisphere as root. For Scope, select Global.
Select: Settings > Security > Local Users > Create. The New User screen
appears.
70
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Deploying the Cloud Tiering Appliance
• For a new user on a VNX running DART 7.1.x:
Log into Unisphere as sysadmin. For scope, select Global..
Select: Settings > Security > User Management > Local Users for File > Create. The New
User screen appears.
Deploying CTA with Celerra or VNX
71
Deploying the Cloud Tiering Appliance
Use the same username and password that was defined for the FileMover API
user in step 2 of “Prerequisite tasks on the Celerra or VNX Control Station for
file migration or archiving” on page 67.
When a user password is updated or changed on the VNX Control Station,
update the FileMover settings for the VNX Properties on the appliance as in
step 7 of “Adding a Celerra or VNX to the CTA configuration” on page 62 and update
the DHSM connection password with the command:
fs_dhsm -connection <primary_fs> -modify <cid> -password
<new_password>
3. Define Celerra or VNX Data Mover properties on the CTA or CTA/VE. “Adding a
Celerra or VNX to the CTA configuration” on page 62 describes the following
properties in greater detail:
• For Control Station, provide the Control Station IPs.
• For FileMover Settings, type the username and password that were created for
the new system user.
If DHSM connections do not exist, the CTA automatically creates the connections
before running each archiving task.
Configuring manually created DHSM connections for file migration or archiving
DHSM connections must be created manually if any of the following conditions
apply:
◆
DART 6.0 is being used with an NFS-exported filesystem on a VDM.
◆
The CTA is not being used to automatically create DHSM connections.
Commands to create the connection for different archiving scenarios are provided as
follows:
◆
When archiving CIFS data to NAS, you archive to a CIFS repository configured
on the appliance.
Create a connection to each CIFS repository that will hold archived data. This
setting applies to any repository that is part of a multi-tier destination. Log in to
the CLI of the Celerra or VNX Control Station and type the command:
fs_dhsm -connection <primary_fs> -create -type cifs –admin
‘<fqdn>\<domain_administrator>’ –secondary
‘\\<fqdn_of_secondary_server>\<repository_path>’ -local_server
<local_cifs_server>
For example: fs_dhsm -connection fileSystem1 -create -type cifs -admin
'mydomain.prv\administrator' -secondary
'\\oldServer.mydomain.prv\dir1\dir2' -local_server ns80dm1
Note: Use the apostrophe instead of quotation marks to encapsulate the CIFS
administrative username and UNC path of the secondary storage location.
◆
When archiving NFS data to NAS, you archive to an NFS repository configured
on the appliance.
Create a connection to each NFS repository that will hold archived data. Log in to
the CLI of the Celerra or VNX Control Station, and type the command:
72
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Deploying the Cloud Tiering Appliance
fs_dhsm -connection <primary_fs> -create -type nfsv3 –secondary
‘<fqdn_of_secondary_server>:/<repository_path>’ -proto TCP
–useRootCred True
For example: fs_dhsm -connection fileSystem1 -create -type nfsv3 –secondary
‘oldServer.mydomain.prv:/dir1/dir2’ -proto TCP –useRootCred True
◆
When archiving any type of data to an Centera CAS or cloud storage server, recall
requests will flow from the Data Mover to CTA, CTA-HA, or CTA/VE.
• To create the connection for an Centera, log in to the CLI of the Celerra or VNX
Control Station, and type the command:
fs_dhsm -connection <primary_fs> -create -type http –secondary
'http://<fqdn for CCD>/fmroot' -httpPort 8000 -cgi n -user <user>
-timeout 60
For example: fs_dhsm -connection fileSystem1 -create -type http –secondary
'http://CCD01.mydomain.prv/fmroot' -httpPort 8000 -cgi n -user rffm
-timeout 60
When prompted, type a password for the file mover settings username .
• To create the connection for a cloud storage server, log in to the CLI of the
Celerra or VNX Control Station and type the command:
fs_dhsm -connection <primary_fs> -create -type http –secondary
'http://<fqdn for ACD>/fmroot' -httpPort 9000 -cgi n -user <user>
-timeout 60
For example: fs_dhsm -connection fileSystem1 -create -type http –secondary
'http://ACD01.mydomain.prv/fmroot' -httpPort 9000 -cgi n -user rffm
-timeout 60
When prompted, type a password for the ‘rffm’ user.
These same settings are used in “Adding a Celerra or VNX to the CTA
configuration” on page 62.
• The FQDN for the callback daemon is used for “CCD DNS Name” on page 64
or “ACD DNS Name” on page 64. The FQDN must be distinct even if the
Celerra or VNX and cloud callback daemons are running on the same
appliance.
• The same user and password credentials are used for FileMover Settings in step 7.
Regardless of the type of connection (CIFS, NFS, or HTTP), the target of a connection
should be specified as a hostname or FQDN in the command:
fs_dhsm -connection <primary_fs> -create
◆
◆
When a Celerra or VNX Data Mover needs to establish a connection to secondary
storage, it first attempts to resolve the hostname in the local hosts file. If the name
cannot be resolved locally, the Data Mover then issues a DNS query.
When archiving to NAS from Celerra or VNX, a DNS record is required to resolve
the FQDN of the secondary storage server to IP addresses if the local hostname
resolution of the Celerra or VNX is not going to be used. A PTR record (reverse
DNS) is also required to map the IP addresses of the secondary storage server to
the FQDN.
Note: The Celerra or VNX File Level Retention (FLR) enabled filesystems cannot be used as an
archiving source.
Deploying CTA with Celerra or VNX
73
Deploying the Cloud Tiering Appliance
Deploying CTA with NetApp
To use the CTA with a NetApp filer, first configure the filer, and then configure the
appliance.
With NetApp as a source, the deployment requirements vary with task type.
Table 11
NetApp deployment checklist
Configure:
File Migratiion
Archiving
System prerequisites
✓
✓
NetApp properties
including NDMP
NDMP not required
NetApp vFiler prerequisites
if applicable + ndmpd
if applicable
Callback daemon: FCD
N/A
✓
Prerequisites for using NetApp as a file migration source
To migrate files from a NetApp, ensure that the following conditions are satisfied:
◆
For NFS, CTA has root access with read/write permission on source exports.
◆
CIFS user has local administrator access on all source shares and exports.
◆
◆
◆
If migrating files from a source that is shared and exported, CTA has root access
with read/write permission to both shares and exports.
Create unicode and convert unicode options on the volume are enabled from the
NetApp console with the vol options command.
NDMP is enabled from the NetApp console by typing:
ndmpd on
options ndmpd.authtype plaintext
◆
For NetApp filers running Data ONTAP 7.2 or later, disable duplicate session
detection by typing:
options cifs.client.dup-detection off
Note: CTA works best with duplicate session detection disabled. However, if the network
environment requires duplicate session detection, the option can be set to name.
◆
NDMP specific settings are specified for every NetApp filer configured on the
CTA.
“Adding a NetApp filer to the CTA configuration” on page 77 provides details on
configuring a NetApp server.
Prerequisites for using NetApp as an archiving source
To archive any data from a NetApp filer, the CTA or CTA/VE requires access to:
◆
SMB over NetBIOS (TCP port 139)
◆
ONTAPI (TCP port 80)
In addition, to archive NFS data, the CTA or CTA/VE will require the following:
◆
74
Portmap v2 RPC service (TCP port 111)
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Deploying the Cloud Tiering Appliance
◆
Mount v3 RPC service
◆
NFS v3 RPC service
◆
NLM v4 RPC service
◆
Root and read/write export permissions for all NFS data that will be archived
◆
inode to pathname mapping is enabled for NFS clients that will access stub files
When configuring a NetApp filer on the CTA or CTA/VE, plan to provide:
◆
All IP addresses that are used by the filer
◆
Credentials for local administrator access through both CIFS and ONTAPI
◆
The NetBIOS name of the filer
Note: If a NetApp filer leverages its vScan interface for virus scanning, the IP addresses of the
vScan servers must be configured on the appliance as excluded clients on the NetApp FPolicy
Special Clients configuration page in the GUI. This allows the virus scanner to scan the stub file
upon a recall event. Failure to configure excluded clients properly will lead to recall failures
when vScan is used in conjunction with FPolicy.
Local administrator’s credentials are required because ONTAPI access is used to send
API calls. If a user other than root is specified, the following option must be set:
options httpd.admin.hostsequiv.enable on
Ensure that the appliance hostname:
◆
◆
Can be resolved to its IP addresses in the local /etc/hosts file of the NetApp filer.
Maps to a user with privileges to access the ONTAPI interface in the
/etc/hosts.equiv file on the filer.
Additional configuration prerequisites vary, depending upon the existing network
environment.
Note: If using a vFiler, precede all options commands with vfiler run <vfiler_name>.
◆
Set the following NetApp options by tping:
options
options
options
options
options
options
options
◆
fpolicy.enable on
cifs.nfs_root_ignore_acl on
httpd.admin.hostsequiv.enable on
httpd.admin.enable on
nfs.tcp.enable on
nfs.udp.enable on
cifs.netbios_over_tcp.enable on
If using NFS to archive CIFS shares, type:
options wafl.nt_admin_priv_map_to_root on
And add the following line in the /etc/usermap.cfg file:
<domain_name>\<cifs_user> == root
For example: domainABC\userABC == root
◆
For NetApp filers running Data ONTAP 7.2 or later, disable duplicate session
detection by tping:
options cifs.client.dup-detection off
Note: CTA works best with duplicate session detection disabled. However, if the network
environment requires duplicate session detection, the option can be set to name.
Deploying CTA with NetApp
75
Deploying the Cloud Tiering Appliance
◆
To properly support stub files, NetApp FPolicy requires a particular CIFS offline
bit attribute on the stub files:
• The CIFS protocol must be enabled on the NetApp filer to archive either CIFS
or NFS datasets. An active CIFS license must be installed on all file servers that
are archive sources.
• NFS-only exports must be shared as well.
◆
◆
To properly recall stub files, FPolicy must be enabled (options fpolicy.enable on)
and rfpolicy must be the only screen policy registered for reads and writes. If a
policy that monitors stub files on the NetApp filer was previously installed,
manually delete it.
To configure NFS archiving, perform the following steps on the NFS-only source
directories:
1. Create a share at the qtree or volume level for qtree sources.
2. Create a share at the volume level for non-qtree sources, that is, those not part
of any qtree.
3. Add access to only the CTA user.
Note: The CTA does not support name clashes on qtrees. For example, QTREE1 against
qtree1.
◆
Configure the NetApp source for UTF-8 language encoding with the command:
vol lang <vol> <language_encoding>
where language_encoding ends with .UTF-8, for example en_US.UTF-8.
◆
◆
If a virus scanning or backup program runs on your NetApp filer, type the IP
address of the machines that host these applications as Excluded Clients on the
NetApp FPolicy Special Clients configuration GUI page.
When archiving to a NAS repository, virus scanning on the destination will
negatively impact CTA performance and should be disabled. Virus scanning on
the destination could also delete files, leaving stub files on primary storage that
cannot be opened. Virus scanning can be enabled on the source when needed,
however scanning on read should not be enabled because it can cause a timeout
and no reply errors on the source during archiving.
Microsoft Office files and NetApp recall
Due to the way NetApp implements passthrough recall combined with the way
Microsoft saves data in temporary files, Microsoft Office files could be corrupted if
modified during recall to a NetApp. To ensure data integrity, CTA excludes Microsoft
Office files from passthrough recall by default.
Microsoft Office files with atypical file extensions can also be corrupted during recall,
but CTA does not exclude these files from passthrough recall by default. Use the CTA
CLI command to manually add an atypical file extension to the list of files that are
excluded from passthrough recall:
rffm addNetAppPassthroughExcludedExtension <file_extension>
When adding a file extension from the list of files excluded from recall, contact EMC
Customer Support to report the atypical file extension.
To restore a Microsoft Office file with an atypical extension that was opened using
passthrough recall so that it became corrupted:
76
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Deploying the Cloud Tiering Appliance
1. Delete the corrupted file.
2. Use Recover Stub on the CTA to recover the stub to the source.
3. Manually edit the stub file to have a correct extension such as .doc, .docx, .docm,
.dotx, .dotm, .ppt, .pptx, and so forth.
4. Recall the file with the correctly named stub.
vFiler configuration
To use NetApp vFilers with the CTA, ensure that:
◆
The CTA can access both the vFiler and the hosting NetApp filer.
◆
vFilers and main filers are in IP spaces that can reach each other.
If NetApp vFilers are being used for file migration, the root password is not the same
as the NDMP password. Before configuring NDMP for the vFiler on the CTA, use the
NetApp CLI to retrieve the NDMP password by typing:
ndmpd password root
Either use this password, or create a new NDMP username and password when
configuring NDMP in “Adding a NetApp filer to the CTA configuration” on page 77.
Configuring NetApp archiving on the CTA
To archive from the NetApp filer, configure the FPolicy callback service on the CTA,
CTA-HA, or CTA/VE.
1. Type the following:
fpsetup init_rffm
2. At the prompt that appears, select the interface on which the FPolicy callback
daemon should listen for callbacks from NetApp filers. If there is only one
interface, it will be selected automatically:
• If this is the primary callback agent in the environment, type n.
• If this machine is being configured as the secondary callback agent, type y.
When prompted, type the IP address and the root password of the primary
agent.
Adding a NetApp filer to the CTA configuration
1. In the navigation field of the web browser, type the IP address of the CTA. The
CTA GUI appears.
2. Type the username and password for the default account which are:
• Username: admin
• Password: rain
3. Select Configuration and File Server. The File Server List appears. Click Add.
4. On the Create File Server page that appears, select NetApp. Click OK.
Deploying CTA with NetApp
77
Deploying the Cloud Tiering Appliance
5. For each step in the File Server wizard, provide the required information
indicated with a red asterisk and click Next.
Step
Description
Basic File Server
Information
Type the NetBIOS server name.
IP Addresses
Type the IP address for NetApp filer:
• When editing an existing server, click Update to retrieve the IP address from the DNS
that is based on the server name.
• To specify an additional IP address, click Add.
• To delete an existing IP address, select an IP and click Delete.If using a vFiler with
vFiler Host IP
Address
OnTAP versions earlier than 7.3, type the IP address of the hosting NetApp filer.
CIFS Specific
Settings
This is the Windows domain user to be used by the appliance. To avoid permission issues
during archiving, recall, and migration, add this user who is a domain user to the backup
operator group. Log in as root on the NetApp and type:
useradmin domainuser add <user> -g "Backup Operators"
where user is the Windows domain username for login.
If this user is not in the domain administrator group, add it to the file server's local
administrators group. Log in as root on the NetApp and type:
useradmin domainuser add <user> -g administrators
where user is the Windows domain username for login.
“Windows domain user” on page 127 provides more information on administering domain
users.
Specify either a NetBIOSdomain or a Kerberos FQDN. The Kerberos FQDNis a CTAserver
configuration setting, and if selected, the same FQDN applies to all servers. Before
selecting the Kerberos FQDN option, follow steps in “Configuring Windows for Kerberos” on
page 129 to configure your Fully Qualified Domain on the CTA.
NDMP Specific
Settings
For file migration, type the username and password for an NDMP user on the NetApp
source. By default, the port for NDMP traffic is 10000.
The NDMP user must belong to the backup operators group. To create a user in the backup
operators group, log in as root on the NetApp, and type:
useradmin user add <user> -g "Backup Operators"
where user is the username for login.
Note: The command will prompt for a password, but this is not the NDMP password and is
not used for the NDMP specific settings.
The NDMPpassword is automatically created when the user is created. Use the NetApp CLI
to retrieve the NDMP password by typing:
ndmpd password <user>
where user is a user in the backup operators group. Use this password for the NDMP
specific settings.
Note: For a NetApp filer, the root username and password can also be used as the NDMP
username and password. However for a vFiler, the NDMPpassword is different fromthe root
password. “vFiler configuration” on page 77 provides instructions on how to find the NDMP
password for the root user on a vFiler.
NetApp as Source This option configures the CTA to archive data from the NetApp filer. If multiple appliances
are connected to the same NetApp filer, only one appliance should be configured with the
NetApp as Source. These options are not required if this NetApp is used as a destination.
78
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Deploying the Cloud Tiering Appliance
Step
Description
NetApp Local
Admin
This step appears
if NetApp as
Source is yes.
Type the username and password of a user on the NetApp filer. The user must be a member
of the NetApp local administrator’s group.
Directory
Exclusion List
These are the directories to exclude for all tasks that use scanning. The CTA ignores all
system directories such as, etc, lost+found, and ckpt by default.
This step appears
if NetApp as
Source is yes.
NetApp FPolicy
callback agents
This step appears
if NetApp as
Source is yes.
Note: Verify that stub files are not in the excluded directories. CTA will not access the
excluded directories and the stub files will become orphans.
The primary agent recalls all files when it is registered with the NetApp. A secondary agent
recalls files when the primary is unavailable.
• If the FPolicy callback agent is not explicitly configured as a secondary agent, then it is a
primary agent and the NetApp file server will load balance between the registered
primary agents.
• If no primary agents respond, then the NetApp filer will contact any of the registered
secondary agents. When one of the primary agents is responsive again, the NetApp filer
will automatically fail back to the primary agent.
For the primary agent, select the agent that is on the same subnet as the NetApp machine.
For the secondary agent, select another agent on the same subnet. If no such agent exists,
select an agent on the next physically closest subnet. Up to two secondaries are supported.
Primary or secondary agents may include CTA-HAs. If the CTA-HA is a primary, the recall is
load balanced between the CTA-HA and other primary agents. If the CTA-HA is selected as
a secondary, it is only used for recall if the CTA goes down.
6. Review the Summary and click Finish to define the NetApp filer.
Verify the FPolicy configuration for CTA
After configuring the NetApp, FPolicy is normally configured automatically.
1. To confirm the FPolicy settings, type:
fpolicy
To verify that:
• FPolicy is enabled — Screen shows "CIFS file policy is enabled".
• rfpolicy is enabled — Screen shows "File policy rfpolicy (file screening) is
enabled".
• If an HA has been configured, the IP address is listed.
2. If the settings are not correct, manually configure the fpolicy settings with the
commands:
fpolicy create rfpolicy screen
fpolicy enable rfpolicy
fpolicy options rfpolicy required on
3. If there is a CTA-HA, manually configure it as a secondary FPolicy server with the
command:
fpolicy options rfpolicy secondary_servers <ip>
where ip is the IP address of the CTA-HA. If there are multiple CTA-HAs,
separate the IP addresses with commas.
Deploying CTA with NetApp
79
Deploying the Cloud Tiering Appliance
Deploying the CTA with a VNXe
CTA supports the VNXe server as an archive destination. For file migration, CTA
supports the VNXe server as a destination when the source does not contain any stub
files.
Prerequisites for using VNXe as a file migration destination
To migrate files to a VNXe, ensure that the following conditions are satisfied:
◆
For NFS, CTA has root access with read/write permission on destination exports.
◆
CIFS user has local administrator access on all destination shares.
◆
◆
VNXe does not support stubs so CTA stub aware migration to a VNXe is not
supported. To use a VNXe as a destination, recall all stubs to the source before
starting a migration.
For every server, properties are configured on the CTA for the NDMP username
and password
“Adding a VNXe to the CTA configuration” on page 80 provides details on
configuring a Celerra or VNX server
Adding a VNXe to the CTA configuration
To configure CTA with a VNXe server:
1. In the navigation field of the web browser, type the IP address of the CTA. The
CTA GUI appears.
2. Type the username and password for the default account which are:
• Username: admin
• Password: rain
3. Select Configuration and File Server. The File Server List appears. Click Add.
4. On the Create File Server page that appears, select VNXe. Click OK.
80
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Deploying the Cloud Tiering Appliance
5. For each step in the File Server wizard, provide the required information
indicated with a red asterisk and click Next.
Step
Description
Basic File Server
Information
Type the NetBIOS server name.
IP Addresses
Type the IP address for the VNXe:
• When editing an existing server, click Update to retrieve the IP address from the DNS
that is based on the server name.
• To specify an additional IP address, click Add.
• To delete an existing IP address, select an IP and click Delete.
CIFS Specific
Settings
This is the Windows domain user to be used by the appliance. The domain user must be a
member of the local Administrator group and part of the Backup Operators group on the
VNXe. “Windows domain user” on page 127 provides more information on administering
domain users.
Specify either a NetBIOSdomain or a Kerberos FQDN. The Kerberos FQDNis a CTAserver
configuration setting, and if selected, the same FQDN applies to all servers. Before
selecting the Kerberos FQDN option, follow steps in “Configuring Windows for Kerberos” on
page 129 to configure your Fully Qualified Domain on the CTA.
NDMP Specific
Settings
For file migration, type the username and password for an NDMP user on the destination
servers. By default, the port for NDMP traffic is 10000.
If no NDMP user exists on the VNXe, use the VNXe GUI to create a new user with
username and password.
6. Review the Summary and click Finish to define the VNXe.
Deploying CTA with a Windows server
CTA supports the Windows 2003 and 2008 servers as a CIFS archiving destination or
as a file migration source. If migrating files from a Windows server, the EMCOPY and
LGDUP utilities must be installed on the Windows server before running the file
migration task.
Prerequisites for using Windows as a file migration source
To migrate files from Windows as a source, ensure that the following conditions are
satisfied:
◆
◆
◆
The amount of free disk space on the Windows source is enough to hold a
snapshot of the volume during migration. To estimate the amount of space
required, estimate the amount of change to the data since the previous snapshot.
For example if 25% of the data has changed, ensure that 25% of the disk space is
free.
The amount of free disk space on the destination is enough to hold the source
data. If there is not enough disk space, the migration task will complete without
error, but some data will not be migrated.
CTA supports Windows cluster servers as a file migration source. However,
because the Microsoft Volume Snapshot Service (VSS) is not cluster aware, if a
failover occurs, the migration will fail.
Deploying CTA with a Windows server
81
Deploying the Cloud Tiering Appliance
Adding a Windows server to the CTA configuration
1. In the navigation field of the web browser, type the IP address of the CTA. The
CTA GUI appears.
2. Type the username and password for the default account which are:
• Username: admin
• Password: rain
3. Select Configuration and File Server. The File Server List appears. Click Add.
4. On the Create File Server page that appears, select Windows. Click OK.
5. For each step in the File Server wizard, provide the required information
indicated with a red asterisk and click Next.
Step
Description
Basic File Server
Information
Type the NetBIOS server name.
IP Addresses
Type the IP address for the Windows server.
• When editing an existing server, click Update to retrieve the IP address from the DNS
that is based on the server name.
• To specify an additional IP address, click Add.
• To delete an existing IP address, select an IP and click Delete.
CIFS Specific
Settings
This is the Windows domain user to be used by the appliance. The domain user must be a
member of the local Administrator group and part of the Backup Operators group on the
Windows server. “Windows domain user” on page 127 provides more information on
administering domain users.
Specify either a NetBIOSdomain or a Kerberos FQDN. The Kerberos FQDNis a CTAserver
configuration setting, and if selected, the same FQDN applies to all servers. Before
selecting the Kerberos FQDN option, follow steps in “Configuring Windows for Kerberos” on
page 129 to configure your Fully Qualified Domain on the CTA.
6. Review the Summary and click Finish to define the Windows server.
Note: NDMP is not used for file migration from a Windows server as a source and NDMP
specific settings are not included as Windows properties.
Installing the EMWS copy agent for CTA
To perform CIFS file migration from a Windows source to a VNX or VNXe
destination, install the EMWS copy agent on the Windows server.
1. Log in to the Windows server as administrator with full backup, restore, and
security permissions.
2. Go to the EMC Online Support web site:
http://Support.EMC.com
3. To download the EMWS copy agent:
• For CTA, select Downloads. Search for Cloud Tiering Appliance. Download
EMC CTA Migration Windows Service (EMWS).
• For CTA/VE, select Downloads. Search for Cloud Tiering Appliance/VE.
Download EMC CTA Migration Windows Service (EMWS).
82
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Deploying the Cloud Tiering Appliance
4. To install EMWS type:
emws_V1_install /user <domain>\<user> /passwd <password>
where domain is the local machine name and user is an administrator. Both are
required.
• To update an installation, type: emws_V1_install
• To uninstall, type: emws_V1_install/uninstall
Installing and running LGDUP
When running a Windows file migration task, CTA compares the local users and local
groups on the source with those on the destination. If any users or groups are missing
on the destination, the run will fail with a message written to the CTA file migration
log.
The LGDUP utility merges the users and groups from the source with the users and
groups on the destination. Install the LGDUP utility on the Windows machine and
run it to configure the users and groups on the source and destination before running
a file migration task.
Note: For VNXe, creation of local users on is not supported. So CTA only migrates local groups
not local users to VNXe and SID translation of local users to VNXe is not supported.
1. Log in to the Windows machine as administrator with full backup, restore, and
security permissions.
2. Go to the EMC Online Support web site:
http://Support.EMC.com
3. To download the LGDUP utility, select Downloads. Search for VNX. Download
CIFSTools.zip.
4. Unzip the file. In the resulting directory, click down to locate the lgdup.exe file.
Note: The LGDUP utility is a 32-bit command line application. If the Windows
server is running a 64-bit operating system, run LGDUP in 32-bit compatibility
mode.
5. To merge the local users and local groups database from the Windows source
with the destination and replicate privileges to the target:
• For migration to VNX, type:
lgdup.exe –v –u -l lgdup_log.txt \\<src_server_name>
\\<dst_server_name>
• For migration to VNXe, type:
lgdup.exe –v -l lgdup_log.txt \\<src_server_name>
\\<dst_server_name>
where src_server_name is the name of the Windows NetBIOS name and
dst_server_name is the name of the VNX or VNXe NetBIOS name.
Deploying CTA with a Windows server
83
Deploying the Cloud Tiering Appliance
Deploying CTA with Isilon
CTA supports Isilon as a NAS destination for migration or archiving. To use CTA
with an Isilon, first configure the Isilon, and then configure the appliance.
Prerequisite tasks when using Isilon as a CIFS share destination
1. The Isilon must be part of a Windows domain or Active Directory. Verify that:
• Isilon and the CTA CIFS user are in the same domain, such as rain.prv.
• You are not in WorkGroup mode.
2. On a Windows machine that is part of the Isilon domain, create the destination
directory that CTA will use as a share. Security on the directory must allow full
control to the group Domain Admins and user Administrator. Administrator is
the same Windows domain user that will be used by CTA to archive to the Isilon.
a. Log in to the Windows machine as administrator.
b. Using Windows Explorer, create a directory in ifs/data. For example, create
CTADir.
c. For folder CTADir, right-click Properties. The properties screen for that
directory appears.
d. On the Security tab, click Add. For Windows 7 or 8, click Edit > Add. The
Select Users, Computers, or Groups screen appears.
a. For Enter the object names to select, type the group Domain Admins.
Click Check Names. If the group name is found, it is underlined.
b. Click OK. The properties screen reappears.
e. For Allow, select Full Control. Click Apply.
f. On the Security tab, click Add. The Select Users, Computers, or Groups
screen appears.
a. For Enter the object names to select, type the username for the Windows
domain user to be used by the appliance as described in “Windows domain
user” on page 127. Click Check Names. If the user name is found, it will be
underlined.
b. Click OK. The properties screen reappears.
g. For Allow, select Full Control.
h. Click OK.
3. For CTA to communicate with the Isilon using CIFS protocol, SMB service on the
Isilon must be enabled. Check the SMB service settings on the Isilon.
a. In the navigation field of the web browser, type the IP address of the Isilon.
The Isilon Administration GUI appears.
a. Log in to the Isilon with administrator privileges.
84
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Deploying the Cloud Tiering Appliance
b. Select File Sharing > SMB > Settings.
– For Service status, verify that Enable is selected. If not, select it.
– For Security mode, verify that User is selected. If not, select it.
If any changes are made, click Submit.
4. From the Isilon console, verify that the NetBIOS Name Service (NBNS) is
running.
• Check that the NBNS is enabled with the command:
isi services | grep nbns
• If the NBNS is not enabled, type:
isi services -a nbns enable
• Even if the NBNS is enabled, it may not be running. To verify that the NBNS is
running, check whether the Isilon is listening on port 139 with the command:
netstat -an | grep LISTEN | grep 139
• If the Isilon is not listening on port 139, disable and re-enable the NBNS with
the commands:
isi services -a nbns disable
isi services -a nbns enable
• Recheck whether the Isilon is listening on port 139:
netstat -an | grep LISTEN | grep 139
Deploying CTA with Isilon
85
Deploying the Cloud Tiering Appliance
5. From the Isilon Administration GUI, create a CIFS share for the CTA destination
directory.
a. Select File Sharing > SMB > Add Share.
– For Share name, type the name of the share or export created, for example,
CTADir.
– For Directory to share, click Browse. Select the path to the directory
created in Step 2 on page 84, for example, /ifs/data/CTADir. Click OK.
– For Directory ACLs, select Do not change existing permissions.
b. Under Users and Groups, select Add. The Choose Users and Groups screen
appears.
– For From the location, select the domain, such as rain.prv that was
referenced in Step 1 on page 84.
– For Name, type Administrator. This is the same Windows domain user
that CTA will use.
– Click Search. Search results list the Administrator user of the domain.
– Select the Administrator user and click Choose. Under Users and Groups,
the Administrator is listed with the checkbox selected.
86
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Deploying the Cloud Tiering Appliance
c. Click Edit permissions. The permissions screen appears.
– Select Run as root. All permissions are set to Allow.
– Click OK.
d. Click Submit. The SMB Summary appears with the share added.
Deploying CTA with Isilon
87
Deploying the Cloud Tiering Appliance
Prerequisite tasks when using Isilon as an NFS export destination
For CTA to communicate with the Isilon using NFS protocol, NFS service on the
Isilon must be enabled. First check the NFS service settings on the Isilon and then
create the NFS export for the CTA destination directory.
Note: Before creating the NFS export for the CTA destination directory, you must
configure the Isilon server so that it provides CTA with root CIFS access permissions. You can
do this running specific Isilon-specific CLI commands that add "run-as-root" permissions for
the CTA domain user on every Isilon CIFS share used by CTA system. The following example
shows Isilon CLI commands used to do this for a single CIFS share:
Isilon v6.5:
> isi smb permission create --sharename='myShareName'
--account-name='myDomain'\\'myUserName' --account-type=user
--permission-type=allow --permission=run-as-root
Isilon v7.0:
> isi smb share permission create 'myShareName'
'myDomain'\\'myUserName' --run-as-root
1. In the navigation field of the web browser, type the IP address of the Isilon. The
Isilon Administration GUI appears.
2. Log in to the Isilon with administrator privileges.
3. Select File Sharing > NFS > Settings.
• For Service status, verify that Enable is selected. If not, select it.
• For NFSv4 Support, verify that Disable is selected. If not, select it.
If any changes are made, click Submit.
88
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Deploying the Cloud Tiering Appliance
4. Select File Sharing > NFS > Add Export.
• Under Settings:
– For Directories, click Browse. Select the path to the directory. Click OK.
– For Permissions, select Enable write access and select Enable mount
access to subdirectories.
• Under Access Control:
– For User name, type root.
– For Group names, type everyone.
e. Click Submit. The NFS Summary appears with the export added.
Prerequisite task when using Isilon as a file migration destination
To configure CTA with Isilon as destination for file migration, an NDMP
administrator user on the Isilon is required.
1. In the navigation field of the web browser, type the IP address of the Isilon. The
Isilon Administration GUI appears.
2. Log in to the Isilon with administrator privileges.
Deploying CTA with Isilon
89
Deploying the Cloud Tiering Appliance
3. Select File System > Backup > NDMP Settings.
• Under Service, if the NDMP service is disabled, click Enable.
• Under Settings, port number 10000 is the default. This is the same port
number for the NDMP Specific Settings configured when “Adding an Isilon to
the CTA configuration” on page 90.
• In the NDMP Administrators section, click Add administrator.
– For username, type ndmp_user. This is the same username that CTA will
use.
– For password, type a password. This is the same password that CTA will
use.
– Retype the password.
Adding an Isilon to the CTA configuration
Configure Isilon properties on the CTA.
1. In the navigation field of the web browser, type the IP address of the CTA. The
CTA GUI appears.
2. Type the username and password for the default account which are:
• Username: admin
• Password: rain
3. Select Configuration and File Server. The File Server List appears. Click Add.
4. On the Create File Server page that appears, select Isilon. Click OK.
90
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Deploying the Cloud Tiering Appliance
5. For each step in the File Server wizard, provide the required information
indicated with a red asterisk and click Next.
Step
Description
Basic File Server
Information
Type the NetBIOS server name.
IP Addresses
Type the IP address for the Isilon:
• When editing an existing server, click Update to retrieve the IP address from the DNS
that is based on the server name.
• To specify an additional IP address, click Add.
• To delete an existing IP address, select an IP and click Delete.
Note: If the Isilon cluster is configured using SmartConnect, add all IP addresses configured
for the cluster. “CTA and Isilon SmartConnect” on page 91 provides additional information
about Isilon properties.
CIFS Specific
Settings
This is the Windows domain user to be used by the appliance. The domain user must be a
member of the local Administrator group and part of the Backup Operators group on the
VNXe. “Windows domain user” on page 127 provides more information on administering
domain users.
Specify either a NetBIOSdomain or a Kerberos FQDN. The Kerberos FQDNis a CTAserver
configuration setting, and if selected, the same FQDN applies to all servers. Before
selecting the Kerberos FQDN option, follow steps in “Configuring Windows for Kerberos” on
page 129 to configure your Fully Qualified Domain on the CTA.
Note: If the Isilon is an NFS export destination only, this setting is not used.
NDMP Specific
Settings
For file migration, type the username and password for an NDMP user defined on the Isilon
in “Prerequisite task when using Isilon as a file migration destination” on page 89. By
default, the port for NDMP traffic is 10000.
6. Review the Summary and click Finish to define the Isilon.
CTA and Isilon SmartConnect
When an Isilon cluster is configured to use EMC Isilon SmartConnect, Isilon load
balances SMB and NFS client access among a number of nodes in the cluster.
SmartConnect uses DNS delegation, allowing the DNS server to delegate authority
for the DNS name to a collection of IP addresses.
Isilon properties in CTA
Configuring Isilon properties on the CTA normally requires the NetBIOS name or
Kerberos FQDN and a single IP address that resolves to that name in DNS. However
if the Isilon server is configured to use SmartConnect, the CTA requires all the IP
addresses configured for the Isilon cluster. These include any address that can be
returned by a delegated DNS name to IP lookup serviced by the Isilon SmartConnect
Service IP for the cluster.
For example, if a three node Isilon cluster is configured to use SmartConnect with:
Isilon Cluster Name:
isilon1.mydomain.prv
Isilon SmartConnect Service IP:
10.4.0.89
Isilon SmartConnect Pool IPs:
10.4.0.80, 10.4.0.81, 10.4.0.82
Deploying CTA with Isilon
91
Deploying the Cloud Tiering Appliance
When configuring this Isilon cluster as in “Adding an Isilon to the CTA
configuration” on page 90, the settings are:
NetBIOS server name:
isilon1
IP Addresses:
10.4.0.80, 10.4.0.81, 10.4.0.82
CIFS NetBIOS Domain or CIFS Kerberos FQDN:
mydomain.prv
Configure CTA with all the SmartConnect Pool IPs, but not the SmartConnect Service
IP (such as 10.4.0.89). The SmartConnect Service IP address is only used for DNS
delegation.
CTA will not be able to correctly load balance its access to the Isilon cluster if the
cluster’s IP Pool does not match the configuration in CTA. If Isilon nodes or
SmartConnect Pool IP addresses are added to or removed from an Isilon cluster, edit
the corresponding CTA configuration to add or remove the IPs.
DNS forward and reverse lookup
CTA requires forward DNS (name to IP) and reverse DNS (IP to name) lookups to be
configured correctly in your DNS server. Once the Isilon cluster, the CTA, and the
DNS server are configured for SmartConnect and DNS delegation, use the CTA CLI
to verify the configuration.
To verify that forward DNS lookup resolves the Isilon cluster name to one of the IPs
configured in the SmartConnect IP Pool, at the CTA CLI prompt, type:
nslookup <name>
If the Isilon cluster is configured using the SmartConnect round-robin option,
repeated nslookup name to IP requests should cycle through all the addresses
configured in the SmartConnect IP Pool.
For example, if a three node Isilon cluster is configured to use SmartConnect with:
Isilon Cluster Name:
isilon1.mydomain.prv
Isilon SmartConnect Service IP:
10.4.0.89
Isilon SmartConnect Pool IPs:
10.4.0.80, 10.4.0.81, 10.4.0.82
nslookup isilon1.mydomain.prv must resolve to one of the IPs: 10.4.0.80, 10.4.0.81, or
10.4.0.82.
If nslookup fails or returns an IP that is not in the SmartConnect IP Pool, the DNS
server is not correctly configured to delegate to the Isilon SmartConnect Server IP. See
the Isilon documentation to configure forward DNS lookup and use nslookup to test
the configuration again.
To verify that reverse DNS lookup resolves all of the IPs configured in the
SmartConnect IP Pool to the DNS name of the Isilon cluster, at the CTA CLI prompt,
type:
nslookup <IP>
For example:
◆
nslookup 10.4.0.80 must resolve to isilon1.mydomain.prv
◆
nslookup 10.4.0.81 must resolve to isilon1.mydomain.prv
◆
nslookup 10.4.0.82 must resolve to isilon1.mydomain.prv
If any of these lookups fails to resolve correctly the DNS server’s reverse lookup zone
is not correctly configured. See the Isilon documentation to configure reverse DNS
lookup and use nslookup to test the configuration again.
92
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Deploying the Cloud Tiering Appliance
Note: If either the forward DNS or reverse DNS lookup tests fail, do not use an Isilon server
configured with SmartConnect in CTA for archiving, repository migration, or file migration.
Deploying the CTA with a Data Domain
CTA supports the EMC Data Domain storage product as an NFS destination for
archiving and repository migration. CIFS source data can be exported and archived to
Data Domain through NFS while clients access the archived files through CIFS. The
stub file retains the CIFS attributes such as security settings and ADS.
Note: CTA supports Data Domain CIFS protocol starting from Data Domain 5.3. However,
CTA requires admin privileges to access CIFS shares and successfully create all files on Data
Domain.
Configure Data Domain server properties on the CTA.
1. In the navigation field of the web browser, type the IP address of the CTA. The
CTA GUI appears.
2. Type the username and password for the default account which are:
• Username: admin
• Password: rain
3. Select Configuration and File Server. The File Server List appears. Click Add.
4. On the Create File Server page that appears, select Data Domain. Click OK.
5. For each step in the File Server wizard, provide the required information
indicated with a red asterisk and click Next.
Step
Description
Basic File Server
Information
Type the NetBIOS server name.
IP Addresses
Type the IP address for the Data Domain server:
• When editing an existing server, click Update to retrieve the IP address from the DNS
that is based on the server name.
• To specify an additional IP address, click Add.
• To delete an existing IP address, select an IP and click Delete.
CIFS Specific
Settings
This is the Windows domain user to be used by the appliance. The domain user must be a
member of the local Administrator group and part of the Backup Operators group on the
VNXe. “Windows domain user” on page 127 provides more information on administering
domain users.
Specify either a NetBIOSdomain or a Kerberos FQDN. The Kerberos FQDNis a CTAserver
configuration setting, and if selected, the same FQDN applies to all servers. Before
selecting the Kerberos FQDN option, follow steps in “Configuring Windows for Kerberos” on
page 129 to configure your Fully Qualified Domain on the CTA.
Note: If the Data Domain is an NFS export destination only, this setting is not used.
6. Review the Summary and click Finish to define the Data Domain.
Deploying the CTA with a Data Domain
93
Deploying the Cloud Tiering Appliance
Configuring a NAS-based repository
Any Celerra, VNX, VNXe, Windows, Isilon, NetApp, or Data Domain can be
configured as a NAS-based repository.
Note: The appliance must have read/write access to any share or export that may be used as an
archive source or destination. In addition, the appliance must have read/write permission for
any file that it may archive.
1. In the navigation field of the web browser, type the IP address of the CTA. The
CTA GUI appears.
2. Type the username and password for the default account which are:
• Username: admin
• Password: rain
3. Select Configuration and NAS Repository. The NAS Repository List appears.
Click Add. The NAS Repository Properties dialog box appears.
You can either:
• Add an existing server and repository.
• Add a new server and repository.
4. To add an existing server and repository, specify the following:
• Type — Select a type of NAS server from the list.
• Name — Select a file server of that type from the list.
Note: The file server must have a proper DNS entry defined that links the file server
name with the IP address.
• Protocol — Select NFS or CIFS. The source and repository protocol types must
match.
– If the source protocol is CIFS, the NAS repository protocol must be CIFS.
– If the source protocol is NFS, the NAS repository protocol must be NFS.
If the CIFS protocol is selected, use the CIFS user in the filesystem CIFS DHSM
connection string for CIFS specific settings when configuring the primary
storage on the appliance:
•
• Path — Click Browse to select an existing path.
Once the path is specified, a name in the form of Repository at <path>
appears in the Name field.
• Maximum limit of disk usage — Type a percentage value for disk usage.
Default value is 90%.
5. To add a new server, select the Type and click Add Server. Follow instructions to
add the server as outlined in:
– “Adding a Celerra or VNX to the CTA configuration” on page 62.
– “Adding a NetApp filer to the CTA configuration” on page 77.
– “Deploying the CTA with a VNXe” on page 80.
– “Deploying CTA with a Windows server” on page 81.
– “Deploying CTA with Isilon” on page 84.
94
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Deploying the Cloud Tiering Appliance
– “Deploying the CTA with a Data Domain” on page 93.
6. Click OK to finish defining the NAS repository.
Deploying CTA with Amazon S3
Amazon Simple Storage Service (S3) is cloud storage. CTA supports Amazon S3 as an
archiving destination.
Note: The Amazon S3 account manager uses the Amazon Web Services (AWS) Management
Console to generate the Web Service Specific Settings which are Access Key ID, Secret Access
Key, and Bucket Name.
Adding Amazon S3 to the CTA configuration
Configure the CTA for an Amazon S3.
1. In the navigation field of the web browser, type the IP address of the CTA. The
CTA GUI appears.
2. Type the username and password for the default account which are:
• Username: admin
• Password: rain
3. Select Configuration and File Server. The File Server List appears. Click Add.
4. On the Create File Server page that appears, select Amazon S3. Click OK.
5. For each step in the File Server wizard, provide the required information
indicated with a red asterisk and click Next.
Step
Description
Basic File Server
Information
Type the logical server name. Each file server is configured separately with a unique name
and is associated with a single Amazon S3 bucket.
Web Service
Specific Settings
URL —URL corresponding to the Amazon S3 bucket as displayed in the AWSManagement
Console.
Access Key ID —Type the key that CTA uses to gain REST access to the Amazon S3
bucket. The Amazon S3 account manager generates the key.
Secret Access Key —Type the secret credential used with the Access Key ID. The Secret
Access Key is generated with the Access Key ID.
Bucket Name —Type the Amazon S3 bucket destination where CTA adds, deletes, or edits
objects. The Amazon S3 account manager configures the Amazon S3 bucket.
6. Review the Summary and click Finish to define the Amazon S3.
Note: When archiving to the cloud (for example, Atmos, Amazon S3, or Azure), the CTA clock
must be accurate and in sync with the cloud service. Therefore it is required to have an NTP
server configured when archiving to these destinations.
Deploying CTA with Amazon S3
95
Deploying the Cloud Tiering Appliance
Deploying CTA with Atmos
The Atmos cloud storage platform is an on-premise or service provider cloud. CTA
supports Atmos as an archiving destination, and as a source or destination for
repository migration.
Adding Atmos to the CTA configuration
Configure the CTA for an Atmos.
1. In the navigation field of the web browser, type the IP address of the CTA. The
CTA GUI appears.
2. Type the username and password for the default account which are:
• Username: admin
• Password: rain
3. Select Configuration and File Server. The File Server List appears. Click Add.
4. On the Create File Server page that appears, select Atmos. Click OK.
5. For each step in the File Server wizard, provide the required information
indicated with a red asterisk and click Next.
Step
Description
Basic File Server
Information
Type the name to identify the Atmos.
Web Service
Specific Settings
DNS Name —Specify the name used to resolve the IP addresses in the Atmos cluster.
Port —The GUI access method. HTTPS is the default and is typically used when the Atmos
is deployed remotely. Select HTTPS or HTTP to specify the communication protocol. The
default port number for HTTPS (10080) or HTTP (80) automatically appears. If your Atmos
connects to HTTPS or HTTP through a different port, type the number.
Username —Type the UID within a given Subtenant on the Atmos. CTA uses this UID to
access storage on the cluster. If there is a subtenant, specify the username as:
<Subtenant_ID>/<UID>, where Subtenant _ID is an alphanumeric string generated by the
Atmos.
Note: The UID is not the Tenant Name, the Subtenant Name, or the Subtenant ID.
Password —Type the Shared Secret associated with the UID on the Subtenant Information
page of the Atmos.
6. Review the Summary and click Finish to define the Atmos.
Note: When archiving to the cloud (for example, Atmos, Amazon S3, or Azure), the CTA clock
must be accurate and in sync with the cloud service. Therefore it is required to have an NTP
server configured when archiving to these destinations.
Installing the SSL certificate on the CTA
By default, the Atmos is configured without server-side authentication. However, the
Atmos administrator can install an SSL X.509 certificate on the Atmos to provide
more security to Atmos clients. If the certificate that is installed on the remote Atmos
is available to the CTA, the CTA can use the certificate to authenticate the Atmos
96
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Deploying the Cloud Tiering Appliance
before archiving data to it. The CTA checks the DNS name in the certificate with the
DNS name of the Atmos configured on the CTA. If the DNS names match,
authentication succeeds.
To use the SSL X.509 certificate with the CTA:
◆
The certificate must be in PEM file format. The Atmos administrator can provide
the file.
◆
On the CTA, the name of the certificate must be atmos_trusted_CAs.pem
◆
Install the certificate under:
/opt/rainfinity/filemanagement/conf/ATMOS_certs/<atmos_DNS>
where atmos_DNS is the DNS name of the Atmos configured on the CTA. The
names are case-sensitive and must match exactly. “Adding Atmos to the CTA
configuration” on page 96 provides details on configuring the DNS name on the
CTA.
To run a CTA script that installs the PEM certificate file in the correct directory, type:
/opt/rainfinity/filemanagement/bin/atmoscert.pl
Deploying CTA with Azure
Microsoft Azure is cloud storage. CTA supports Azure as an archiving destination.
Adding Azure to the CTA configuration
Configure the CTA for an Azure.
1. In the navigation field of the web browser, type the IP address of the CTA. The
CTA GUI appears.
2. Type the username and password for the default account which are:
• Username: admin
• Password: rain
3. Select Configuration and File Server. The File Server List appears. Click Add.
4. On the Create File Server page that appears, select Azure. Click OK.
5. For each step in the File Server wizard, provide the required information
indicated with a red asterisk and click Next.
Step
Description
Basic File Server
Information
Type the name to identify the Azure.
Web Service
Specific Settings
Container Name —Type the destination where CTA adds, deletes, or edits objects. The
Windows Azure Management Portal administrator configures the containers associated with
the storage account.
Account Name—Type the name of the Azure storage account that CTA uses to gain REST
access to the Azure container. The Windows Azure Management Portal administrator
creates this account.
Access Key —Type the key that CTA uses to gain REST access to the Azure container.
When a storage account is created, Windows Azure generates primary and secondary
access keys for that account. Either key is valid.
6. Review the Summary and click Finish to define the Azure.
Deploying CTA with Azure
97
Deploying the Cloud Tiering Appliance
Note: When archiving to the cloud (for example, Atmos, Amazon S3, or Azure), the CTA clock
must be accurate and in sync with the cloud service. Therefore it is required to have an NTP
server configured when archiving to these destinations.
Deploying CTA with Centera
CTA supports the Centera as an archiving destination, and as a source or destination
for repository migration. Configure the CTA for an Centera.
1. In the navigation field of the web browser, type the IP address of the CTA. The
CTA GUI appears.
2. Type the username and password for the default account which are:
• Username: admin
• Password: rain
3. Select Configuration and File Server. The File Server List appears. Click Add.
4. On the Create File Server page that appears, select Centera. Click OK.
5. For each step in the File Server wizard, provide the required information
indicated with a red asterisk and click Next.
Step
Description
Basic File Server
Information
Type the name to identify the Centera.
Access Node
Type the Centera access node name or IP address:
• To specify an additional Access Node, click Add.
• To delete an existing Access Node, select a node and click Delete.
The Access Node String is automatically generated when the Access Node is added or
deleted. You cannot type data directly into the field.
Centera
Authentication
Type
Select from one of the three choices:
• User profile —If selected, type the username and password of the Centera profile that is
to be used for archiving.
• PEA file —This option requires that a profile and pool entry authorization (PEA) file was
created to access Centera, and that a copy of the PEA file resides on the CTA. If
selected, the PEA file is used to authenticate the CTA connection with Centera. Type the
path to the file on the local machine or browse for the file. A copy of the file will be stored
with the CTA configuration.
• Anonymous —If selected, no security is used to authenticate with Centera.
6. Review the Summary and click Finish to define the Centera.
98
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
5
Maintaining the
Cloud Tiering
Appliance
This chapter contains the following sections:
◆
◆
◆
◆
◆
Importing a file list archive......................................................................................... 100
Backing up the configuration ..................................................................................... 103
Maintaining the database ............................................................................................ 106
Migrating from CTA to CTA/VE .............................................................................. 108
Shutting down and restarting the appliance............................................................ 109
Maintaining the Cloud Tiering Appliance
99
Maintaining the Cloud Tiering Appliance
Importing a file list archive
The CTA can perform archival tasks on lists of files imported from a third-party
software provider. To generate and import the file lists properly, the CTA
administrator and the third-party software administrator must exchange information
as follows:
1. The third-party software administrator gives the CTA administrator the names of
the primary servers.
2. The CTA administrator:
• Adds the primary servers as source servers on the CTA as described in
“Adding the primary servers” on page 100.
• Configures an import provider with username and password as described in
“Configuring the import provider” on page 100.
• Configures an import file task as described in “Configuring the import task”
on page 101.
The CTA administrator provides the server, provider, and task information to the
third-party software administrator.
3. With settings defined on the CTA, the third-party software generates an XML file
containing lists of files on a primary server that are to be archived.
Note: For optimum performance during file import, limit the XML file list to 1 million
entries.
4. The XML file is transferred to the CTA as described in “Importing the file list” on
page 102. Once CTA validates the imported file, the import files archive task is
queued to run.
Import files archive tasks are run in the same way as other archive tasks. The archive
destination is defined with the CTA policy. The source is defined in the imported
XML file list. Online help describes how to schedule and review results of an archive
task.
Adding the primary servers
To archive files from the primary servers of the third-party software, configure the file
servers as a source on the CTA. A Celerra Data Mover, VNX Data Mover, or NetApp
filer can be a source. Details on how to add the file servers to the CTA configuration
are provided in:
◆
“Adding a Celerra or VNX to the CTA configuration” on page 62
◆
“Adding a NetApp filer to the CTA configuration” on page 77
The CTA administrator gives the server names to the third-party software
administrator.
Configuring the import provider
To copy an archive file list to the CTA, the third-party software provider must have
permission to write to the CTA. The import provider is a unique Linux user on the
CTA that has limited security access to a staging directory. When the provider is
configured, CTA creates the staging directory for the imported XML file.
100
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Maintaining the Cloud Tiering Appliance
1. Select Configuration and Import Provider. The Import Provider List appears.
2. Click Add. The Import Provider Properties page appears.
3. Specify the following:
• Username — Type a name for the user that is allowed to log into the CTA from
the provider. This must be a valid Linux user name. The third-party software
uses the name for the provider in the XML file that it creates.
• Password — Type a password used to log into the CTA from the provider.
4. Click Commit to define the Provider.
The CTA administrator gives the name and the password to the third-party software
administrator.
Configuring the import task
For the CTA to operate on the imported file list, the header of the XML file must
contain a task name configured on the CTA. The CTA matches the name in the header
of the XML file to an import files archive task.
Configure an import files archive task based on an archive policy. Files are archived to
the destination defined in the policy.
1. Select Schedule and click Add.
2. For each step in the Schedule wizard, provide the required information indicated
with a red asterisk and click Next.
Step
Description
Task Type
On the Archive tab, select one of the archive task types.
At the bottomof the screen, check the box to Import file list provided by an external provider.
Import File Task
Type a task name. Select the import provider defined in “Configuring the import provider” on
page 100.
Policy
Click Add Policy.
Define Policy
Parameters
Select an archive policy type: archive, multi_tier, or multi_tier_stub.
Type a policy name.
Define Policy
Rules
Click Add Rule.
Importing a file list archive
101
Maintaining the Cloud Tiering Appliance
Step
Description
Define a Policy
Rule
To archive all files in the imported list, build an expression with:
• File Attribute: Size
• Operator: >=
• Value: 1
• Unit: Bytes
Click Add.
Leave the default action of Archive.
Select the Archive
Destination
Select a destination. Click Save Rule.
Define Policy Rule The Define Policy Rules page reappears with the new rule added.
Verify Policy Rule
After verifying the policy definition, click Save Policy.
Policy
The Policy page reappears with the new policy added.
S chedule
Select the time-based Schedule Type for the import task: Import, Daily, Weekly, Monthly or
Future. The task will not run until the XML file list is imported and validated.
3. After verifying the task definition, click Finish.
The CTA administrator gives the task name to the third-party software administrator.
Importing the file list
To transfer the file list to the CTA, the CTA imports the XML file or the import
provider copies the XML file to the CTA.
CTA imports the file
If the XML file list is in a location that is accessible by the CTA, you can use the CTA
GUI to import the file:
1. Select Schedule, and show schedules of type Import Files.
2. Highlight the import task defined in “Configuring the import task” on page 101,
click Import and select the Import File option.
102
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Maintaining the Cloud Tiering Appliance
3. In the Explorer window that appears, select the XML file and click Open.
Import provider
copies the file
If the import provider is copying the XML file to the CTA, it uses the name and
password assigned by the CTA administrator in “Configuring the import provider”
on page 100 to log in to the CTA. The XML file list is deposited into a staging
directory as:
/opt/rainfinity/filemanagement/import/providers/<PROVIDER>/import_fil
es_<ID>.xml
where PROVIDER is the logical name of the provider defined in CTA and ID is the
unique ID in the XML file.
Validating the import file
Every 30 seconds, the CTA scans for imported file lists. Before launching import file
archive task, the CTA checks the imported XML file to confirm that it has matching
values for:
◆
provider name
◆
task name
◆
file server names
The CTA also verifies that it can access all shares and exports listed in the XML file.
If any validation checks fail, an error is reported in the import log. To review import
logs before running the import file archive task:
1. Select Schedule, and show schedules of type Import Files.
2. For any import file archive task defined, click Import and select the Import Logs
option.
3. Each row corresponds to an XML file list import. On any row where the status
shows a validation error, click View Log to display the log. The text file that
appears will list problems with the XML file.
The logs for the XML file list import are also accessible outside of the GUI:
/opt/rainfinity/filemanagement/import/providers/<PROVIDER>/log
where PROVIDER is the logical name of the provider defined in CTA.
Backing up the configuration
The CTA and CTA/VE contain configuration information and critical database tables.
The CTA-HA contains no persistent data. If data on a CTA-HA is lost, the CTA-HA
software must be reinstalled as described in “Performing a CD clean install on the
appliance” on page 51.
If data on a CTA or a CTA/VE is lost, the software must be reinstalled and the last
backup copy of the configuration and database tables must be restored. For this
reason, backup the CTA or CTA/VE configuration and the critical database tables
nightly.
Note: Task and simulation log files are not included in a backup. To preserve these files, copy
the /opt/rainfinity/filemanagement/log/fws directory to secure storage either periodically or
before performing a CD clean install.
The backup feature uses the following process:
Backing up the configuration
103
Maintaining the Cloud Tiering Appliance
◆
Critical CTA system configuration data is backed up to a gzipped tar file (.tgz).
◆
The tar file is written to a destination on an Centera or NAS repository.
To perform disaster recovery, the CTA uses a catalog file (DBBackup.out) to locate tar
files on the destination and to reconstruct the CTA system configuration after a
disaster. The catalog file is stored on both the CTA and in a secondary disaster
recovery location.
Creating a backup dump
Regular backups may be scheduled to run automatically.
1. Select Configuration and Backup and Recovery Settings.
Under File Management Backup Destination, specify:
• The number of backups — The default value is 5.
• Select Destination — The Centera or NAS repository where the backup files
will be stored. The backup files are gzipped tar files (.tgz) that contain CTA
system configuration data.
Note: Only NFS NAS repositories are listed as backup destinations. CIFS NAS
repositories are not supported as backup destinations and are not listed.
• Select Disaster Recovery Location — The NFS export where the backup
catalog file (DBBackup.out) will be stored. The DBBackup.out file is also
stored on the CTA. The file stored on the NFS export is only used if the file
stored on the CTA is lost or damaged.
Note: Ensure that the selected location is only assigned to one CTA. Multiple CTAs
must not use the same disaster recovery location.
2. Select Schedule and click Add. The Schedule Wizard appears.
3. On the Auxiliary tab, select Backup. Click Next.
4. For backup tasks, time-based is the only schedule selection. Select the daily,
weekly, or monthly recurring time for backups to run.
To perform a nonrecurring backup, or to perform a backup immediately, run the
script:
fmbackup
When the backup is complete, the system returns the message:
Done.
The backup has been output into /tmp/DUMPFILE.
where DUMPFILE is a unique filename generated by the backup script.
Restoring a backup dump
Backups are typically restored after a system failure. To restore a backup, start with a
freshly installed appliance. Steps are performed from both the GUI and the command
line.
1. Configure networking. “Configure the CTA network” on page 53 provides
details.
104
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Maintaining the Cloud Tiering Appliance
2. Configure the hostname, domain, and DNS servers. “Configure the hostname,
domain, and DNS server” on page 53 provides details.
3. Configure the destination for the restored backup files (.tgz).
• If the backup files were written to an Centera, configure an Centera as the
destination for the restored files. “Deploying CTA with Amazon S3” on
page 95 provides details.
• If the backup files were written to a NAS repository, configure a NAS
repository as the destination for the restored files. “Configuring a NAS-based
repository” on page 94 provides details.
4. Mount the NFS export where the backup catalog file (DBBackup.out) is stored.
This is the disaster recovery location described in step 1 of “Creating a backup
dump” on page 104.
5. Copy DBBackup.out to /opt/rainfinity/filemanagement/conf.
6. Select Configuration and Backup and Recovery Settings.
Under Recover File Management, select the .tgz file to restore and click Restore.
The backup file will be restored to /var/fmrestore.
7.
Using database information from DBBackup.out, a restoration script reconstructs
the CTA system configuration from the .tgz file selected in step 6. To run the script
in a screen session that will not be interrupted, type:
screen
fmrestore <backup_file.tgz>
As the restoration occurs, the system will prompt for input to:
• Confirm restoration.
• Start the FPolicy callback service for a NetApp.
• Start the callback daemons for Celerra or VNX and for the cloud service.
At each prompt, type y. When asked if you want to add another server, type n.
Note: The database tables are restored at a rate of approximately 10 million entries per hour.
If restoring data to the same machine, the CTA automatically restarts at the
conclusion of the restoration process. If restoring data to a different machine, the CTA
must be manually restarted. Also, original network configuration files, such as
/etc/hosts, may need to be manually edited to reflect the new IP and hostname of the
new machine.
Typical output of the fmrestore script is as follows:
[root@fm2
Expanding
This will
Press 'y'
bin]# fmrestore /var/fmbackup_9.0_cta.Thu_26-01-12_16_41.tgz
/var/fmbackup_9.0_cta.Thu_26-01-12_16_41.tgz in /var...
overwrite your configuration and database. Are you sure?
to continue or 'n' to abort now
Backing up the configuration
105
Maintaining the Cloud Tiering Appliance
y
Stopping CTA GUI ...
Stopping Tomcat server
Tomcat server stopped
Stopping filemanagement daemon ...
Stopping filemanagement daemon watchdog
Stopping filemanagement daemon
done
done
Empty the current database...
Removing Unique key constraints ...
Restore configuration and database...
Starting network time protocol daemon (NTPD)
done
Warning: backup is missing file: /etc/sysconfig/network
Adding Unique key constraints ...
Updating Database index statistics...
Starting CTA GUI ...
Starting Tomcat server
Tomcat server started
Starting filemanagement daemon ...
Starting rslogd (already running):
done
Starting rslogd Monitor (already running):
Starting rslogd cpu check (already running):
done
done
Starting filemanagement daemon
done
Starting filemanagement daemon watchdog
done
done
Restore Done..
Maintaining the database
After archiving millions of files, archiving tasks may become slow as the number of
entries in the archival database grows larger. To improve performance, use a CTA
vacuum process to clear the database of unused entries and reindex the entries that
remain.
The database maintenance process can take several hours. While the process is
running, the filemanagement daemon must be halted and the GUI may not be used.
System administrators should plan to run database maintenance when the appliance
is not needed.
Note: Recalls are not interrupted by database maintenance.
Checking database size and disk capacity
Before performing database maintenance, verify that the maintenance is warranted.
1. Check the current database size. Click the Archived Files tab:
2. Check how much disk space the database is using by typing:
du -sh /var/lib/pgsql/data/base
106
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Maintaining the Cloud Tiering Appliance
The database should use about 1 million archived files per gigabyte. If the database is
using more than twice the expected disk space, for example, if 1 million archived files
are occupying more than 2 gigabytes, perform database maintenance.
Performing database maintenance
The command line script that starts database maintenance performs the following
steps:
1. Stops the filemanagement daemon and GUI.
2. Runs the database vacuum process.
3. Restarts the daemon and the GUI.
Database maintenance can be run immediately as a CTA task or scheduled to run at a
specific time.
Note: Before running the CTA vacuum process, it is recommended that you backup the CTA
system and copy the backup file to an off-host location.
◆
To start the CTA vacuum process immediately, type:
rffm doDBMaintenance
◆
To schedule the CTA vacuum process to start at a later time and to run repeatedly,
type:
rffm scheduleVacuumTask VacuumStartTime=<StartTime>
VacuumWeekRepetition=<Number_of_weeks>
where:
• StartTime is the date and time when the first vacuum task will run. The format
is yyyy-mm-dd hh:mm:ss. After each run, the value is reset to the date and
time of the repeat run.
• Number_of_weeks is the number of weeks between runs. It is specified as an
integer and the value should be between 4 and 24. The default is 8.
Every 30 minutes, CTA checks to see if there are any vacuum tasks scheduled.
One hour before the vacuum task is scheduled to start, CTA sends the alert “A
VACUUM TASK WILL START WITHIN THE NEXT 1 HOUR”.
For example, to start the CTA vacuum process at 2 a.m. on May 1, 2011 and
run the task every four weeks, type:
rffm scheduleVacuumTask VacuumStartTime="2011-05-01 02:00:00"
VacuumWeekRepetition=4
– At or around 1 a.m. on May 1, 2011, CTA sends the alert that the vacuum
process will start within the hour.
– Following the run, the StartTime is reset to at 2 a.m. on May 29, 2011.
◆
To delete the CTA vacuum process, type:
rffm deleteVacuumSchedule
The log of the process is: /var/lib/pgsql/vacuum.log
The output of the process is:
/opt/rainfinity/filemanagement/conf/DBMaintenance.log
Maintaining the database
107
Maintaining the Cloud Tiering Appliance
Migrating from CTA to CTA/VE
The procedure to migrate from CTA to CTA/VE involves backing up the CTA
database and restoring it to a CTA/VE. The migration path consists of the following
steps:
Note: Migration can only occur between systems running the same CTA versions (for example,
between two systems running CTA 10.0 to 10.0). If two systems are running different CTA
variants, one or both should first be upgraded so that they are running the same variant before
migration occurs.
1. Upgrade the FMA to CTA version 7.5 or later.
2. Back up the current FMA configuration to an Centera or NAS repository. If
preserving additional custom configuration or task simulation and support logs,
back up the files separately.
3. Install CTA/VE version 7.5 or later on the ESX Server and configure networking.
4. Copy the backup file to the CTA/VE.
5. Shutdown the FMA. Remove it from the network.
6. Manually reconfigure the IP address of the CTA/VE to replace the CTA on the
network.
7. Restore the backup file on the CTA/VE.
8. Reboot the CTA/VE.
Note: The network bonding feature, which is available on the CTA, is not available on the
CTA/VE.
If a CTA is being upgraded to CTA/VE, and the Celerra, VNX, or NetApp
implementation includes a CTA-HA for recall:
1. Use the CTA-HA to provide recall functionality while upgrading the CTA to
CTA/VE.
2. Once recall has been tested and verified for the CTA/VE following the upgrade:
• use the CTA-HA to provide recall for the CTA/VE, or
• install a CTA/VE-HA to provide recall for the CTA/VE
108
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Maintaining the Cloud Tiering Appliance
Shutting down and restarting the appliance
To shut down and restart a working CTA or CTA/VE:
1. Stop any running tasks.
2. Stop all services with the commands:
filemanagement stop
celerracallback stop
atmoscallback stop
fpolicycallback stop
3. If an HA appliance is deployed, verify that the HA appliance has taken over file
recalls by attempting to open an archived file.
4. Either shut down or reboot the appliance.
• To shut down the appliance, type the command:
shutdown -h now
• To reboot the appliance, type the command:
reboot
For the CTA-HA, only the callback services are stopped. The filemanagement stop
command is not used.
Shutting down and restarting the appliance
109
Maintaining the Cloud Tiering Appliance
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
6
Cloud Tiering
Appliance System
Settings
This chapter contains the following sections:
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
Security hardening ....................................................................................................... 112
Configuring the GUI access method ......................................................................... 115
STIG hardening ............................................................................................................ 115
LDAP client configuration .......................................................................................... 117
Certificate management .............................................................................................. 120
Appliance mail delivery settings ............................................................................... 121
Log settings ................................................................................................................... 121
Configuring alerts ........................................................................................................ 123
System command accounting..................................................................................... 125
Windows domain user ................................................................................................ 127
SID translator ................................................................................................................ 130
Cloud Tiering Appliance System Settings
111
Cloud Tiering Appliance System Settings
Security hardening
By default, security hardening is not enabled.
To configure security hardening:
1. Start the Cloud Tiering Appliance setup tool, type rfhsetup.
2. Select Configure System Security. A set of security settings options appears.
3. Select Harden Appliance.
The default settings for the items that affect the appliance security level are:
• Use single security database =no
• Disable root logins =no
• Strengthen passwords =no
• Age passwords =no
• Harden to STIG requirements =disabled
When all four settings are “no,” security hardening is disabled and this disabled
security level is referred to as the default level.
If any of the settings is set to a non-default value, security hardening is enabled.
Note: In addition to the security settings, the GUI access method may also be configured
from the Harden Appliance menu. By default, the GUI is accessible over both http and
https. Enabling https only or redirecting http to https does not change the appliance
setting to hardened.
Single security database
If the single security database setting is enabled, all authentication on the device will
go through standard Linux Pluggable Authentication Modules (PAMs). This applies
to both GUI and CLI access.
Both the GUI and the CLI provide two types of users:
◆
Admin users belonging to the wheel group and Rainfinity groups
◆
Ops users belonging to the Rainfinity group
CLI users are configured independently from the GUI users.
If rfhsetup is used to enable the security database setting option, existing GUI users
will not be able to log in. Use rfhsetup to disable root logins, then create the new user.
To disable root logins:
1. Start the Cloud Tiering Appliance setup tool, type rfhsetup.
2. Select Configure System Security. A set of security settings options appears.
3. Select Harden Appliance.
4. Select Configure root login settings.
5. For Allow login as root?, select N.
Note: Once root login is disabled, you must log into the CTA with the new username and
password to use the CLI.
112
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Cloud Tiering Appliance System Settings
Admin users
An admin user who is a member of the wheel group and logged in through SSH can
become a superuser to:
• Create/delete other users
• Run rfhsetup
To add an admin user for access from the CLI:
1. Log in to the CTA as root.
2. Type the following commands:
useradd –G rainfinity,wheel <username>
passwd <username>
Ops users
An ops user belongs to the Rainfinity group.
To add an ops user for access from the CLI:
1. Log in to the CTA as root
2. Type the following commands:
useradd –G rainfinity <username>
passwd <username>
Linux PAM users
A Linux PAM user is created through the CLI. When a Linux PAM user is logged in to
the GUI with the single security database setting enabled, the user’s role (admin or
ops) is cached for the duration of the session.
If the administrator changes the user’s setting while the user is logged in, the user’s
role will not be refreshed until one of the three following conditions occurs:
◆
User logs out.
◆
GUI is restarted.
◆
Cached user information in the Tomcat server expires due to inactivity.
Adding users with the GUI
To add a new admin or ops user with the GUI:
1. Log in as admin.
2. From the Configuration tab, select Cloud Tiering Appliance Users.
3. Select Add a New User. In the Cloud Tiering User Properties dialog box that
appears:
a. Type the name.
b. Type a new password.
c. Specify the type of user:
– Super User — The admin user.
– Regular User — The ops user.
Note: When the single security database setting is disabled, users created through the GUI are
allowed to log in through the GUI but not the CLI. In addition, if the single security database
setting is enabled, user accounts cannot be created through the GUI. If the user attempts to
invoke the configuration page for Cloud Tiering Appliance Users, a warning appears.
Security hardening
113
Cloud Tiering Appliance System Settings
Disable root logins
If root logins are disabled, the only way to add new users or to run rfhsetup is for an
admin user (such as a user who belongs to the wheel group) to log in to the device,
and then become a root user.
When the setting to disable root logins is being changed to yes, the CTA checks to
ensure that:
◆
◆
There is at least one admin user other than root who belongs to the wheel group.
This user must have a configured password.
The wheel users are in the local /etc/group file. The CTA ignores LDAP users
while performing this check because LDAP servers occasionally become
unreachable.
Note: Configure a small set of admin users locally for each CTA. Most admin and ops users are
configured on an LDAP server. In this way, the management of these users scales to large
networks.
Strengthen passwords
If the passwd command is run with password strengthening enabled, your new
password must be at least eight characters long and satisfy the following
requirements:
◆
At least three characters are different from the previous password.
◆
At least one character is an uppercase letter.
◆
At least one character is a number.
◆
At least one character is a special character.
In a clustered environment, run the passwd command on both the primary and
backup nodes.
Note: The root user can change any password including its own to any value, regardless of the
password strengthening setting to strengthen it.
Age passwords
If password aging is enabled, every user (except root) who can log in with a shell
account will have an aging password. The root user configures:
◆
◆
◆
◆
114
When to print a user warning that a password is about to expire.
The maximum number of days a password can remain valid before it must be
changed.
How often a password may be changed.
The number of days following password expiration after which the account will
be locked. Once an account is locked, only the root user can unlock the account by
using the change command to change the age of the password.
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Cloud Tiering Appliance System Settings
Note: If a large number of devices are deployed, a central authentication service (such as
LDAP) should be used. Password administration through the central site greatly facilitates user
scalability, as one user is not required to log in to every deployed CTA to update an aging
password.
Configuring the GUI access method
By default, the GUI can be accessed by both HTTP and HTTPS. To change this for the
CTA:
1. Start the Cloud Tiering Appliance setup tool, type rfhsetup.
2. Select Configure System Security. A set of security settings options appears.
3. Select Harden Appliance.
4. Select Configure GUI access method:
• To disable access over HTTP, select Only enable GUI access over https.
• To redirect http traffic to HTTPS instead of disabling HTTP, select Redirect
GUI access over http to https.
STIG hardening
Security Technical Implementation Guide (STIG) is a set of security guidelines issued by
the US Department of Defense. These STIG UNIX guidelines define how
UNIX/Linux appliances should behave from a security standpoint.
Enabling STIG hardening
The CTA provides an option for hardening the appliance to meet the UNIX STIG
Guide (Version 5, Release 1). When STIG hardening is enabled, the security settings
change as follows:
◆
◆
The user must type the root password to gain access to the CTA in single user
mode.
After three consecutive login attempts, the account is disabled. Only the root user
can reenable a disabled account.
◆
The login delay between login prompts increases from 2 to 4 seconds.
◆
New passwords are required to be a minimum of nine characters in length.
◆
When changing passwords, the past five passwords cannot be reused as the new
password value.
◆
The root account’s home directory will be set to a permission value of 700.
◆
Man page file permissions will be set to 644.
◆
◆
◆
◆
User-directories must not contain undocumented startup files with permissions
greater than 750 (that is, they must allow write access only for that user).
The system and default user umask must be set to 077.
Access to the cron utility will be restricted using the cron.allow and cron.deny
files.
Crontab file permissions above 700 will not be permitted (in the /etc/cron.daily,
/etc/cron.hourly, /etc/cron.weekly directories).
Configuring the GUI access method
115
Cloud Tiering Appliance System Settings
◆
The inetd.conf file permissions will be set to 440.
◆
Unnecessary accounts, for example, games and news will be deleted.
◆
sysctl.conf file will be set to 600 permission.
To enable STIG hardening on the CTA and CTA-HA:
1. Start the Cloud Tiering Appliance setup tool, type rfhsetup.
2. Select Configure System Security.
3. Select Harden Appliance.
4. Select Harden to STIG requirements.
5. When prompted with Enable changes to conform to STIG Hardening
requirements?, type y.
Disabling STIG hardening
When STIG hardening is disabled, the security settings change as follows:
◆
No password prompt is made prior to connecting in single-user mode.
◆
User accounts are unlocked, even after three or more failed login attempts.
◆
◆
The login delay is set to the current default setting, which is less than four
seconds at this time.
When changing passwords, the minimum length must be:
• If password hardening is enabled: eight characters, with at least one
lowercase, one uppercase, one digit, and one special character.
• If password hardening and STIG hardening are disabled: the minimum
requirements for the new password is that it should be six characters long.
◆
When STIG hardening is disabled, the user can reuse previously set passwords.
◆
The /root directory permissions is reset to 750.
◆
Man page file permissions remain at 644. That is, this STIG hardening change is
retained.
◆
User-directory permissions remain at the value prior to STIG hardening.
◆
The system and default user umask must be set to 022.
◆
◆
Unnecessary groups/accounts that are deleted during STIG hardening remain
deleted even after STIG hardening is disabled.
Access to the cron utility is unrestricted using the cron.allow and cron.deny files.
To disable STIG hardening on the CTA:
1. Start the Cloud Tiering Appliance setup tool, type rfhsetup.
2. Select Configure System Security.
3. Select Harden Appliance.
4. Select Harden to STIG requirements.
5. When prompted with Enable changes to conform to STIG Hardening
requirements?, type n.
116
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Cloud Tiering Appliance System Settings
STIG hardening is disabled when the appliance hardening level is reset to the default
level as follows:
1. Start the Cloud Tiering Appliance setup tool, type rfhsetup.
2. Select Configure System Security.
3. Select Remove Appliance Hardening Settings.
LDAP client configuration
LDAP directory trees are used to represent hierarchical directory information, such as
people and phone numbers that belong to an organization. The CTA supports
Lightweight Directory Access Protocol (LDAP) for user authentication and
authorization.
Global LDAP settings
Global LDAP settings affect all LDAP operations. The following settings impact how
the LDAP client on the CTA will behave when the LDAP server does not respond.
Bind type — There are two types of binds:
◆
◆
Hard — The CTA will continue to retry the bind attempt until a maximum
timeout is reached.
Soft — The CTA will attempt to bind once and abort if the server does not
respond.
Time limits — There are two types of time limits.
◆
◆
Search time limit — The amount of time that the LDAP client will wait for an
initial response from the server.
Bind time limit — The amount of time that the LDAP client will attempt to bind.
By default, these time limits are set to 10 seconds to allow the appliance to remain
responsive when the LDAP server is down, and to fail over to an alternate
authentication mechanism, if another mechanism is configured.
Server type — The CTA LDAP client works with three types of LDAP servers:
LDAP authentication
◆
OpenLDAP
◆
Active directory with SFU 3.5 support
◆
Active directory with RFC 2307 support
When LDAP is configured, LDAP authentication is established through a sequence of
events.
◆
◆
A user connects to the CTA. The user is challenged for user authentication.
The CTA LDAP client contacts the LDAP server to validate the user’s credentials.
To validate that the client is trusted, the server attempts:
• To accept anonymous bind attempts, such as accepting all connections without
a password.
• To accept a plain-text password sent over an unencrypted communication
channel.
• To establish a secure communication channel with the client, and then
authenticate by using a plain-text password or SASL.
LDAP client configuration
117
Cloud Tiering Appliance System Settings
The client establishes the secure communication channel as follows:
– The client requests the server’s public key.
– The client validates that the server’s public certificate is signed by a known
Certificate Authority (CA).
– The client then encrypts its data using the server’s public certificate. Only
the private key stored on the server can decrypt this data.
Initial data from the client contains negotiation information that the server and
client will both use to establish a secure communication channel.
Just as the client uses the server’s public key to encrypt its first message, the
server ensures that the client is authentic by requesting the client’s public
certificate, and validating that it is signed by a known Certificate Authority.
After the secure channel is established, the password is exchanged. If SASL is
configured, it may be used instead of a password.
◆
The server and client may negotiate an encryption scheme to secure all traffic
between them.
Once authentication is established and an encryption scheme is optionally selected,
the LDAP client will request user authentication.
Configuring basic LDAP settings
To start LDAP configuration:
1. Start the Cloud Tiering Appliance setup tool, type rfhsetup.
2. Select Configure System Security.
3. Select Configure LDAP.
4. Select Enable LDAP.
Configure the basic LDAP settings:
• Maximum time the LDAP client will wait for an initial response from the
server
Type a period of time. The client will retry after waiting for 2 seconds, and
thereafter continue retrying after doubling the wait time from the previous
retry attempt. The client will continue retries until either the server responds
or the configured LDAP search time limit is exceeded. The default time limit
is 10 seconds.
• LDAP bind policy
Select soft or hard. The default setting is hard, and indicates that the client will
retry bind connections to the LDAP server.
• Maximum time the LDAP client will wait for a bind response from the server
Type a period of time. If the bind policy is set to soft, this setting has no effect.
If the bind policy is set to hard, this policy will cause a bind retry mechanism
to occur.
• LDAP server type
Select from the supported server types:
– OpenLDAP — Applies to LDAP servers distributed by OpenLDAP.
– Active Directory deployed with Services For Unix (SFU) 3.5
– Active Directory with RFC2307 support
118
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Cloud Tiering Appliance System Settings
Note: Other LDAP servers have not been validated for CTA version 7.2 or later.
• IP address or hostname for the LDAP server
When using SSL and TLS, type the hostname that matches the hostname used
in the certificate generation. If an IP address was used in the certificate
generation instead of the hostname, type the IP address.
Note: Failure to type the proper information will create problems during the LDAP
setup. This is one of the most common configuration errors during LDAP setup.
• LDAP basedn
Type the suffix for your domain name.
• Advanced LDAP settings
Type y, to configure a bind password, or enable SASL (Kerberos), SSL, or TLS.
If advanced LDAP settings are left unconfigured, anonymous bind without a
bind password is used by default.
With LDAP enabled, CTA users can log in to the CLI. To log in to the GUI:
◆
◆
The single security database (SSD) setting must be enabled on the CTA. “Security
hardening” on page 112 provides information on enabling the SSD.
Users allowed to login to the CTA must be added to the rainfinity and wheel
groups in the LDAP server database.
If the GUI is running and LDAP is enabled through rfhsetup, the GUI will not
recognize LDAP authentication attempts until it is restarted by typing the command:
/opt/rainfinity/filemanagement/bin/fmgui restart
To avoid this problem:
1. Enable external authentication (LDAP) before enabling the single security
database.
2. Invoke the GUI.
Note: If changing the CTA IP address or moving the CTA to a new location, disable remote
login and reenable root login before changing or moving the CTA. After changing or moving
the CTA, reenable LDAP with the IP address or hostname of a LDAP server that is reachable in
the new configuration.
Configuring advanced LDAP settings
Once basic configuration is complete, the user may continue to configure advanced
LDAP settings:
◆
Anonymous or simple bind
If simple is selected:
• Type the binddn user+domain name that will be used to connect to the LDAP
server.
• Type the password that will be used to authenticate with the LDAP server.
◆
SASL
LDAP client configuration
119
Cloud Tiering Appliance System Settings
To configure SASL, provide:
• SASL KDC address
• Domain name
• Kerberos principal details
Note: When configuring SASL, enter the absolute path for the scp path. ~ is not supported
as root home.
◆
Encryption type
Select cleartext, SSL, or TLS.
◆
Option for the LDAP client to validate the server’s certificate
Type Y if using SSL or TLS. The CTA will prompt you to scp the CA certificate.
◆
Option for the LDAP server to validate the client’s certificate
Before enabling this option, ensure that the client’s key and certificate were
generated and placed on the CTA client.
Certificate management
When configuring LDAP, TLS, and SSL for authentication, key and certificate files are
required. In order for authentication encryption to work correctly, these keys and
certificates must be:
◆
Periodically refreshed
◆
Correctly located on the appliance
Each certificate has an expiration date. Every week, the CTA checks the validity of
each certificate. Certificate warning information is logged into the /var/log/secure
file, and if the alert is enabled, email is sent when the certificate is due to expire. Once
a certificate expiration warning is received, SSL/TLS certificates must be updated.
To update and manage the keys and certificates:
1. Start the Cloud Tiering Appliance setup tool, type rfhsetup.
2. Select Configure System Security.
3. Select Certificate Management.
4. To update either:
• Certificate Authority (CA) public certificate
• Client key and certificate for use with SSL/TLS
a. Select Update Certificate.
b. Type Y.
c. Type the scp path from which the selected certificate or key file will be copied
to the CTA.
120
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Cloud Tiering Appliance System Settings
Appliance mail delivery settings
The CTA supports delivery of alerts through email. To send these alerts, sendmail
must be properly configured. A menu is provided within the rfhsetup tool. To use
this menu:
1. Start the Cloud Tiering Appliance setup tool, type rfhsetup.
2. Select Configure CTA Mail Delivery Settings. The Appliance Mail
Configuration menu appears.
Follow the prompts to configure:
a. Change Configuration — When prompted, type y.
b. Sender’s email address — Type the address that will appear in the From field
of the alert emails sent by the CTA. For example, johndoe@acme.com.
c. SMTP server — Type the server to which mail should be sent. For example,
mailhub.eng.acme.com.
d. email verification — Type a recipient email address to which test emails may
be sent. For example, adminjoe@acme.org. The rfhsetup script will attempt to
verify the mail configuration by sending two emails.
Wait a few minutes. Check the email account to see if these emails were
successfully received.
3. Mail Test 1 — To confirm the receipt of an email with the subject Mail Test 1, type
y. Otherwise, type n.
4. Mail Test 2 — To confirm the receipt of an email with the subject Mail Test 2, type
y. Otherwise, type n.
If either of the test emails was received, mail delivery is working and mail setup is
done.
If neither test email was received, verify:
◆
The name of the SMTP server. Check with your system administrator.
◆
The email address provided for the test email.
◆
The SMTP server is reachable. Try to ping it.
Log settings
When the security level is set to harden, any event that might affect the security of the
system is written to the CTA log files. Use the Cloud Tiering Appliance setup tool to
administer and preserve log files.
Configuring log rotation
With log rotation, the user controls the periodic rotation of files.
To configure log rotation:
1. Start the Cloud Tiering Appliance setup tool, type rfhsetup.
2. Select Configure Logging Options.
3. Select Configure Log Rotation.
Appliance mail delivery settings
121
Cloud Tiering Appliance System Settings
4. Follow the prompts to configure:
• Log rotation frequency — Daily, weekly, or monthly
• Rotation mode — Size or time
• Max log size (for non-debug files)
• Max debug log size
• Number of copies to keep for each log file
Configuring SCP of rotated log files
Log rotation is the first step in archiving the CTA system logs. These log files are
eventually deleted as a part of the normal rotation process. However, in many
customer environments, it may be necessary to preserve these files by copying them
to a remote server. Use the CTA to create a tar file of these rotated system and the
CTA logs, then secure copy them to a remote server.
Configuring the public-private key exchange — Prior to configuring secure copy
(SCP) of rotated log files, a public-private key exchange must take place.
To configure the public-private key exchange:
1. Log in to the CTA or CTA-HA as root.
2. Generate the public key by typing ssh-keygen -t rsa.
• When prompted, press Enter to accept default answers for:
– File in which to save the key, for example, type: /root/.ssh/id_rsa
– No passphrase
– Confirm no passphrase
• At the end of the configuration, a message appears acknowledging:
– Your identification is saved in /root/.ssh/id_rsa.
– Your public key is saved in /root/.ssh/id_rsa.pub.
3. For the external server where the log files will be placed, create a user with write
access to the copy directory. Do not use the root user.
Note: In the following steps, server is the IP address or hostname of the external server, and
user is the name of the user on the external server which will copy the files.
4. Log in to the CTA or CTA-HA and use SSH to:
a. Create the directory ~/.ssh by typing the command:
ssh <user>@<server> mkdir -p .ssh
b. Type the user password.
c. Append the public key on the CTA or CTA-HA by typing the command:
cat /root/.ssh/id_rsa.pub | ssh <user>@<server> 'cat >>
.ssh/authorized_keys'
d. Type the user password.
e. Set correct permissions by typing the command:
ssh <user>@<server> chmod -R 700 .ssh
f. Type the user password.
122
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Cloud Tiering Appliance System Settings
5. To verify successful completion, attempt to log in to the external server as user
from the root account on the CTA by typing:
ssh <user>@<server>
You should not be prompted for a password.
You can now successfully use SCP without a password to send the rotated log files to
your external server.
Configuring SCP of rotated log files by using rfhsetup — Once the public-private
key exchange is completed, configure scp of rotated log files:
1. Start the Cloud Tiering Appliance setup tool, type rfhsetup.
2. Select Configure Logging Options.
3. Select Configure SCP of Rotated Log Files.
4. Follow the prompts to configure:
• The SCP Remote Address — The IP address or hostname of the external
server. This is the external server referenced in “Configuring the
public-private key exchange” on page 122.
• The username to whose account the log files will be copied — The name of the
user on the external server who will copy the files. Same as the user provided
in “Configuring the public-private key exchange” on page 122.
• The full path to the directory at the remote site where the log files should be
placed. The user must have write access to this directory.
Following the configuration, the CTA will test SCP by attempting to copy a test file. If
this test fails, the SCP settings will be accepted, but SCP is probably not configured
properly. Correct the error that is blocking SCP and rerun the Cloud Tiering
Appliance setup tool.
Configuring alerts
A CTA can be configured to monitor various system log files and send email to alert
whenever an event occurs. CTA sends notifications for SNMP traps and alerts listed
in Appendix B, “Alerts.”
Configuring email alerts
Use the GUI to review and configure the list of email alerts:
1. Click the Alert Settings link on the Configuration tab.
2. Click the Edit log alert Pattern link.
A list of alerts with the various alert settings appears:
• Alerts may be individually enabled.
• If alerts occur more than once within a specified time period, edit the throttle
time to suppress the repeated alerts. A different throttle time may be applied
to each alert.
Note: Only admin users can view this configuration page.
To configure email alerts from the command line:
1. Start the Cloud Tiering Appliance setup tool, type rfhsetup.
Configuring alerts
123
Cloud Tiering Appliance System Settings
2. Select Configure Logging Options.
3. Select Configure Log Alerts.
4. Follow the prompts to configure:
• When asked to enable alerts, type y.
• Specify one or more email addresses separated by a space or comma, to
receive the alerts.
Configuring SNMP alerts
Use the GUI to configure SNMP alerts:
1. Click the SNMP Configuration link on the Configuration tab.
2. On the SNMP Settings page that appears, add a notification host. This is the host
to which alerts will be sent:
• IP address
• UDP port (typically SNMP uses UDP port 161 for general SNMP messages
and UDP port 162 for SNMP trap messages)
• Community string
• Security type
3. Click Commit.
4. Click the Alert Settings link on the Configuration tab.
5. Under Alerts, click Enable SNMP alerts.
Note: Only admin users can view this configuration page.
To configure SNMP alerts from the command line:
1. Configure the SNMP Notification Host:
a. Start the Cloud Tiering Appliance setup tool, type rfhsetup.
b. Select Configure Logging Options.
c. Select Configure SNMP.
d. Select Configuration SNMP Notification Hosts.
e. Add the SNMP Notification Hosts:
– The number of hosts that may be added is unlimited.
– For each host, specify: IPv4 address, UDP port number, SNMP community
string, and SNMP version.
– The community string must be alphanumeric, and may include dashes and
underscores.
2. Enable SNMP alert generation:
a. Start the Cloud Tiering Appliance setup tool, type rfhsetup.
b. Select Configure Logging Options.
c. Select Configure Log Alerts.
d. Follow the prompts to configure:
– When asked to enable alerts, select Yes.
124
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Cloud Tiering Appliance System Settings
– Specify the type of alert delivery. Select either email only, SNMP only, or
email and SNMP.
Enabling SNMP polling
Use the GUI to enable SNMP polling:
1. Click the SNMP Configuration link on the Configuration tab.
2. On the SNMP Settings page that appears:
a. Type a community string.
b. Select a security type.
c. Click Add. The community string is added to the Current Community String
list.
3. Click Commit.
To enable SNMP polling from the command line, configure the SNMP Community
String to be used for polling:
1. Start the Cloud Tiering Appliance setup tool, type rfhsetup.
2. Select Configure Logging Options.
3. Select Configure SNMP.
4. Select Configuration SNMP Community Strings.
5. Add the SNMP Community Strings.
• The number of strings that may be added is unlimited.
• For each string, specify the SNMP community string and SNMP version.
• The community string must be alphanumeric, and may include dashes and
underscores.
Note: To poll for SNMP objects without enabling rfalertd, execute the command: service
rfsnmp start from the root account. This restarts SNMP and no alert history is viewable until
the alert daemon is restarted.
System command accounting
The CTA provides the ability to track any command that is successfully executed and
launches a new process.
To track command history, the CTA uses the psacct Process Accounting package. This
package tracks commands that are entered. In addition to commands, the CTA
extends this package to track command arguments.
To enable System Command Accounting on the CTA:
1. Start the Cloud Tiering Appliance setup tool, type rfhsetup.
2. Select Configure Logging Options
3. Select Configure System Command Accounting
4. Type y to enable system command accounting.
System command accounting
125
Cloud Tiering Appliance System Settings
Tracking user command history
After enabling System Command Accounting, admin users can track the list of
commands entered on the system with the tool: /opt/rainfinity/bin/rflastcomm.
To use this tool, admin users must be a superuser. Examples of its use are as follows:
◆
To list the commands entered by all users, use the tool without any options, or:
/opt/rainfinity/bin/rflastcomm
◆
To list the commands entered by a specific user, type:
/opt/rainfinity/bin/rflastcomm –u <username>
◆
To list commands entered by a user since a start date on 5 p.m. on June 6, 2007,
use the tool with the following arguments:
/opt/rainfinity/bin/rflastcomm –u <username> –s ‘2007-06-06
17:00:00’
◆
To track system/daemon/session history, type:
/opt/rainfinity/bin/rfquerycshis.sh
◆
For a help menu and additional options, type:
/opt/rainfinity/bin/rflastcomm --help
Tracking user login history
After enabling System Command Accounting, admin users can track the login
history with the tool:/usr/bin/last.
To run this tool, admin users must su as root first.
This tool is part of the standard psacct Process Accounting package. For detailed info
on using this tool, type: man last.
Tracking daemon command history
To query daemon command history, such as xmlrpc commands issued to the daemon
from the GUI or through various CTA CLI commands, use the tool:
/opt/rainfinity/bin/rfquerycshis.sh.
◆
To obtain the daemon command history, type:
/opt/rainfinity/bin/rfquerycshis.sh -t dc
◆
To query the system command history, type:
/opt/rainfinity/bin/rfquerycshis.sh -t sc
◆
To query the user login history, type:
/opt/rainfinity/bin/rfquerycshis.sh -t ls
◆
To list hardware related messages from the system log files, type:
/opt/rainfinity/bin/rfquerycshis.sh -t hw
126
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Cloud Tiering Appliance System Settings
Windows domain user
When a new file server is added to the CTA configuration, CIFS specific settings
include the username and password for the Windows domain user to be used by the
CTA. Before adding a new CIFS file server, use the instructions in the following
sections to set up the Windows domain user:
◆
“Creating a Windows domain user” on page 127
◆
“Adding an admin user to the local administrator group” on page 127
In addition, for CIFS authentication configure either:
◆
◆
Fully Qualified Domain settings — For Kerberos support as described in
“Configuring Windows for Kerberos” on page 129
Domain controller Group Policy Object (GPO) — For NT LAN Manager (NTLM)
support as described in “Configuring Windows 2008 for NTLM” on page 129.
Note: CIFS specific settings are applicable for all servers except Centera, Atmos, and
Amazon S3.
Creating a Windows domain user
To create an administrator in the Windows 2000, 2003, or 2008 domain:
1. Log in to the primary domain controller as the Domain Administrator.
2. From the Start menu, select Start > Programs > Administrative Tools > Active
Directory Users and Computers.
3. Right-click Users.
4. Select New > User. The New Object — User dialog box appears:
a. In the Full name box, type CTA Administrator.
b. In the Login name box, type fmadmin.
The fmadmin login is the CTA Administrator Windows Domain user.
c. Type a password.
This password is the fmadmin Windows password.
d. (Optional) Select Password Never Expires.
5. Click Finish.
Note: If you have NetApp filers but no Windows 2000, 2003, or 2008 servers in your domain,
then you must include fmadmin in the domain administrator group. Otherwise you will not be
able to include the fmadmin user in the NetApp filers’ administrators group.
Adding an admin user to the local administrator group
The fmadmin account must be added to the administrators group on the CIFS file
servers that will be involved in CTA archiving. To add a CTA Windows domain user
on a NetApp filer or an EMC Celerra or VNX Data Mover:
1. Log in to the primary domain controller as the Domain Administrator.
Windows domain user
127
Cloud Tiering Appliance System Settings
2. From the Start menu, select Start > Programs > Administrative Tools >
Computer Management. The MMC application appears.
3. To start a Computer Management session with the file server:
a. From the Action menu, select Connect to another computer. The Select
Computer dialog box appears.
b. Click Browse or type the file server name to select the NetApp, Celerra, or
VNX to connect to.
c. Click OK.
4. To include the fmadmin user in the administrator group for the CIFS file server:
a. Under System Tools, in the folder Local Users and Groups, select Groups.
b. Select Administrators. The Administrators Properties dialog box appears.
c. Click Add. The Select Users or Groups dialog box appears.
– Click Locations. From the Locations menu, select the domain instead of the
local computer.
– Under Enter the object names to select, type fmadmin to add the domain
user.
d. Click OK. The Administrator’s Properties dialog box reappears with the
newly added fmadmin user.
e. Click OK.
Repeat this process for any other file servers that will be involved in CTA archiving.
128
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Cloud Tiering Appliance System Settings
Configuring Windows for Kerberos
By default, the Windows domain controller supports Kerberos authentication. Before
configuring a file server for CIFS authentication with Kerberos, configure the Fully
Qualified Domain Settings on the CTA:
1. Log in to the CTA GUI.
2. Select Configuration and Fully Qualified Domain.
CTA displays the Fully Qualified Domain List.
3. Click Add to add a new Fully Qualified Domain.
CTA displays a Fully Qualified Domain Properties dialog box.
4. Enter the Domain Name and IP Address of the Domain Controller.
5. Click Commit.
Configuring Windows 2008 for NTLM
If using NTLM for CIFS authentication instead of Kerberos, confirm that the domain
controller is configured for NTLM:
1. Log in to the Windows 2008 domain controller as the Domain Administrator.
2. From the Start menu, select Run. In the Run dialogue box that appears, type
gpmc.msc and click OK. The Group Policy Management dialog box appears.
3. Expand the domain. Under Group Policy Objects, right-click Default Domain
Policy and select Edit. The Group Policy Management Editor appears.
4. Under Computer Configuration, select Policies > Window Settings > Security
Settings > Local Policies > Security Options.
Windows domain user
129
Cloud Tiering Appliance System Settings
In the list of policies, scroll down to Network security: LAN Manager
Authentication. Confirm that the policy setting shows that NTLM is configured
for authentication.
5. Close the Group Policy Management Editor.
SID translator
The CTA is able to translate Security IDs (SID) in the security properties of the files
and directories involved in a CIFS file migration task. The capability may be used to
assist projects in which the data’s group or user association changes from the source
to the destination. For example, when the Access Control List (ACL) is defined in
terms of local groups on the source file server.
When the data is migrated to the destination server, the ACL should be defined in
terms of corresponding local groups. The rules governing this translation are defined
in the SID translation files.
Installing the SID translator
The SID translator is packaged as a Microsoft Installer package, known as an MSI file.
The SID translator supports systems running Windows XP Professional (SP1 or later)
and Windows 2003 Server Standard and Enterprise editions.
.NET Framework 4 must be installed on the Windows server before installing the SID
translator utilities. The latest .NET Framework may be downloaded from Microsoft
at:
http://msdn.microsoft.com/en-us/netframework/default.aspx
To install the SID translator:
1. Verify that your client has the .NET Framework 4 installed.
2. Go to the EMC Online Support web site:
http://Support.EMC.com
3. To download the SID translator utilities, select Downloads. Search for Cloud
Tiering Appliance. Download SIDUtilities<BuildNumber>.msi, where
<BuildNumber> is a number similar to 8_0b15.
4. To start the installation script, run the following file:
SIDUtilities<BuildNumber>.msi
130
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Cloud Tiering Appliance System Settings
Creating the SID translation file
Use the SID translator to create a SID translation file.
1. Once the utility is installed, the SID translator screen appears:
2. Click Select for The groups and users to migrate under Source. The Select
Groups to Migrate dialog box appears:
a. In the Source name box, type the name and click Query. The list of local
groups on that source appears.
b. Select the local groups to migrate. Select only the local groups that are unique
to your source. For example, you would not select the Administrators group
that also likely exists on other file servers.
SID translator
131
Cloud Tiering Appliance System Settings
c. Click Select.
The SID Translator dialog box reappears with The Groups to Migrate listed.
3. Click Select for The container to hold all of the migrated groups under
Destination. The Select Container for Migrated Groups dialog box appears:
a. In the Destination name box, type a name and click Query. The list of local
groups on that destination appears.
b. Select the destination for the source and click Select.
The SID Translator dialog box reappears with the names for the Source and the
Destination listed.
4. Click Configure for Map File Output under Options. The Map File Output
dialog box appears:
a. Type the filename or click Browse to select an existing XML file.
b. Click OK.
The SID Translator dialog box reappears with the name of the Map File Output
listed.
132
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Cloud Tiering Appliance System Settings
5. Click Test Run to test the validity of the setup by creating and removing groups
on the destination.
6. Click Migrate to create the SID translation file.
Uploading the SID translation file
To upload the SID translation file:
1. Select Configuration and File Migration Settings. The File Migration Settings
page appears.
2. To add a SID translation file:
a. Click Add.
b. Navigate to find the XML file and choose that file. When the file is selected, it
is added to the list.
Deleting a SID translation file
To delete a SID translation file:
1. Select Configuration and File Migration Settings. The File Migration Settings
page appears with a list of previously uploaded SID translation files.
2. Select the file to delete and click Delete.
SID translator
133
Cloud Tiering Appliance System Setlings
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
A
Network Topology
Scenarios
The appendix includes the following sections:
◆
◆
Advanced network topologies ................................................................................... 136
VLAN tagging modes for the CTA/VE .................................................................... 139
Network Topology Scenarios
135
Network Topology Scenarios
Advanced network topologies
For many environments, using a single networking interface will satisfy networking
requirements. However, there are cases when more complex topologies are needed.
◆
◆
◆
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.
“Configuring the CTA with bonding” on page 136 provides details on how to set
up this network topology.
Using two subnets, one for the NAS primary storage tier, and another for either
the NAS/CAS secondary tier or for a management interface. “Configuring the
CTA with two subnets” on page 137 provides details on how to set up this
network topology.
Using more than two subnets, for example, when there are three teams using a
CTA distributed across three different subnets. “Configuring the CTA with more
than two subnets” on page 137 provides details on how to set up this network
topology.
Configuring the CTA with bonding
This configuration applies to the CTA installation and is commonly used when fault
tolerance must be built into the networking layer. In this example, eth0+eth1 are
combined into a bonded interface that is configured with the balance-rr bonding
mode:
1. Start the network configuration menu:
a. Type rfhsetup from the CTA command prompt to invoke the system setup
menu.
b. Select Configure Cloud Tiering Appliance Networking. The network
configuration menu appears.
c. Select Configure Networking.
2. Add new bond interface:
a. Type A to add an interface. Use the right arrow key to highlight Bond, and
press Enter.
b. When prompted for a name of the new bond, use the up arrow key to
autogenerate a name. The name generated is bond1. Press Enter to complete.
3. Edit new bond setting:
a. Use the up and down arrow keys to select the bond1 interface. Press Enter to
edit the configuration.
b. Specify a value for each item:
– For Slave, type eth0 eth1.
– For Trunking Mode, select balance-rr.
Complete other values as needed.
c. Once the interface configuration is defined, press the left arrow key to exit the
current menu. When prompted, select Yes to keep the new setting.
Note: If a bond interface is active, do not edit the IP addresses of the any Slaves. Remove
the bond before editing Slave configurations.
136
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Network Topology Scenarios
4. Save new settings, exit, and restart network services:
a. Press the left arrow key to exit the main menu. When prompted, select Yes to
save the configuration.
b. The setup utility will restart the CTA network services for the new
configuration and return to the network configuration menu.
Note: This configuration does not apply to CTA/VE.
Configuring the CTA with two subnets
In this example, the CTA is configured for two subnets with two physical ports (eth0,
eth1):
1. Start the network configuration menu:
a. Type rfhsetup from the CTA command prompt to invoke the system setup
menu.
b. Select Configure Cloud Tiering Appliance Networking. The network
configuration menu appears.
c. Select Configure Networking.
2. Edit settings for the physical ports eth0 and eth1:
a. Use the up and down arrow keys to select eth0 and press Enter. The
configuration menu for the eth0 interface appears.
b. Provide information for each item to properly configure the interface.
– Press Enter to edit an item, the press Enter again to complete.
– Press the left arrow key to exit the menu.
– Select Yes to keep new settings.
c. Repeat these steps for the eth1 interface.
3. Save new settings, exit, and restart network services:
a. Press the left arrow key to exit the main menu. When prompted, select Yes to
save the configuration.
b. The setup utility will restart the CTA network services according to the new
configuration and return to the network configuration setup menu.
Configuring the CTA with more than two subnets
In this example, the CTA is configured for more than two subnets with two physical
interfaces. This configuration utilizes VLAN tagging and the switch connected to the
CTA ethernet ports must be properly configured for tagging. In Cisco terminology,
the switchport mode is set to trunk, and the required VLANs are allowed on the
ports:
1. Start the network configuration menu:
a. Type rfhsetup from the CTA command prompt to invoke the system setup
menu.
Advanced network topologies
137
Network Topology Scenarios
b. Select Configure Cloud Tiering Appliance Networking. The network
configuration menu appears.
c. Select Configure Networking.
2. Add new bond interface:
a. Type A to add an interface. Use the right arrow key to select Bond, and press
Enter.
b. When prompted for the name of the new interface, press the up arrow key to
generate a name. The name generated is bond1. Press Enter to complete.
3. Edit the bond configuration:
a. Use the up and down arrow keys to select the new bond interface. Press Enter.
The configuration menu for the interface appears.
b. For Slave, type eth0 eth1. Complete other values as needed.
c. Once the interface configuration is defined, press the left arrow key to exit the
current menu. When prompted, select Yes to keep the new setting.
Note: Configuration settings are saved, but are not implemented until the Cloud
Tiering Appliance Network Setup menu is exited.
4. Add new VLAN interfaces:
a. Type A to add an interface. Use the right arrow key to select VLAN, and press
Enter.
b. Type a name for the VLAN bond interface. The naming convention is
<interface>.<vlan-ID>. For example, eth0.5 is a VLAN interface on eth0 with a
VLAN ID of 5
c. Repeat these steps to create two more VLAN bond interfaces.
5. Edit the VLAN configuration:
a. Use the up and down arrow keys to select the new VLAN interface. Press
Enter. The configuration menu for the interface appears.
b. Provide information for each item to properly configure the interface:
– Press Enter to edit an item, and then press Enter again to complete.
– Press the left arrow key to exit the menu.
– Select Yes to keep the new settings.
c. Repeat these steps for each new VLAN interface.
Note: To delete a bond that is part of a VLAN bond interface, delete the VLAN bond
interface before deleting the bond.
6. Save the new settings, exit, and restart network services:
a. Press the left arrow key to exit the main menu. When prompted, select Yes to
save the configuration.
b. The setup utility will restart the CTA network services for the new
configuration and return to the network configuration menu.
138
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Network Topology Scenarios
VLAN tagging modes for the CTA/VE
The CTA/VE supports two VLAN tagging modes:
◆
“ESX Server virtual switch tagging” on page 139
◆
“ESX Server virtual guest tagging” on page 140
ESX Server virtual switch tagging
In the Virtual Switch Tagging (VST) mode, a VLAN ID is assigned to an ESX Server
switch port. Untagged layer 2 traffic is sent by using the link between the switch port
and the CTA/VE interface. When the switch receives this traffic, it directs it to the
configured VLAN.
On the CTA/VE, configure each physical eth1, eth2, eth3 or eth4 port with an IP
address, Net Mask, and Default Gateway.
Note: When using the VST mode, do not create a VLAN interface.
Configuring the VLAN number on the ESX switchport in VST mode
Virtual switch tagging is enabled when the port group’s VLAN ID is set to any
number between 1 and 4094, inclusive.
To use VST, create appropriate port groups. Give each port group a label and a VLAN
ID. Port group values must be unique on a virtual switch. Once the port group is
created, you can use the port group label in the virtual machine configuration.
To configure port group properties:
1. Log in to the VMware VI Client and select the server from the inventory panel.
The hardware configuration page for this server appears.
2. On the Configuration tab, click Networking.
3. Click Properties for a network. The vSwitch Properties dialog box appears.
4. On the Ports tab, select the port group and click Edit.
5. In the Properties dialog box for the port group, click the General tab to edit:
• Network Label — This is the name of the port group that you are creating.
• VLAN ID — This identifies the VLAN that the port group’s network traffic
will use.
6. Click OK to exit the vSwitch Properties dialog box.
VLAN tagging modes for the CTA/VE
139
Network Topology Scenarios
ESX Server virtual guest tagging
In the virtual guest tagging (VGT) mode, the link between the ESX Server switch port
and the CTA/VE ethernet port is permitted to carry traffic for multiple VLANs. This
is achieved by adding a VLAN ID or tag to each layer 2 frame transmitted between
the switch port and the CTA/VE ethernet port.
In Cisco parlance, this link is a trunk link.
The advantage of this link is that during VMware VMotion, the remote ESX Server
re-creates the trunk port, and the administrator does not need to preconfigure the
VLANs on the destination ESX Server/Switch combination. The use of VGT prevents
errors during VMotion.
Configuring VGT on the ESX Server
To configure VGT:
1. Log in to the VMware VI Client, and select the server from the inventory panel.
The hardware configuration page for this server appears.
2. On the Configuration tab, click Networking.
3. Click Properties for a network. The vSwitch Properties dialog box appears.
4. On the Ports tab, select the port group and click Edit.
5. In the Properties dialog box for the port group, click the General tab to edit:
• Network Label — This is the name of the port group that you are creating.
• VLAN ID — This identifies the VLAN that the port group’s network traffic
will use. To use VGT, type 4095.
6. Click OK to exit the vSwitch Properties dialog box.
Configuring VLAN interfaces on the CTA/VE
On the CTA/VE side, the VGT mode requires the creation of VLAN interfaces on top
of the CTA/VE ethernet interface. IP addresses are assigned only to the VLAN
interfaces. The VLAN bond interface is unconfigured and does not have an IP
address. Use the rfhsetup networking menu to configure the ethernet interface.
To add a VLAN interface on the CTA/VE:
1. Log in to the CTA/VE. The rfhsetup configuration menu appears.
2. Select Configure FileManagement networking. The Network configuration
menu appears.
3. Select Configure Networking. A list of interfaces appears:
FileManagement Network Setup,
Name
eth0
eth1
eth2
eth3
IP Address
Main Menu
Network Mask
Up/Down
DOWN
DOWN
DOWN
DOWN
Comment
Unconfigured
Unconfigured
Unconfigured
Unconfigured
1 of 4 entries displayed
Command: [Q]uit [A]dd [R]emove [S]ave [U]p [D]own re[F]resh [H]elp
Status: OK
140
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Network Topology Scenarios
rfhsetup <- Network configuration -> Interface eth0's
configuration
4. Type A to add a new interface. Use the left and right arrow keys to select a VLAN
interface and press Enter.
5. Type a name for the VLAN interface. The naming convention is
<bond>.<vlan-ID>. For example, to add VLAN ID 20 on eth0, the name will be
eth0.20. After typing the name, press Enter.
The new VLAN bond interface (for example, eth0.20) will be added to the
interface list.
6. Use the up and down arrow keys to select the newly created VLAN interface.
Press the right arrow key. The eth0.20 VLAN configuration screen appears. Add
the IP address, netmask, and gateway.
7. Use the left arrow key to exit the eth0.20 configuration menu and save the
configuration.
8. Use the left arrow key to exit the Configure Networking menu and apply the
saved configuration.
VLAN tagging modes for the CTA/VE
141
Network Topology Scenarios
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
B
Alerts
The appendix includes the following sections:
◆
◆
Supported SNMP traps ............................................................................................... 144
CTA alerts...................................................................................................................... 145
Alerts
143
Alerts
Supported SNMP traps
Table 12 on page 144 lists the SNMP traps for which the CTA will send a notification.
Table 12
144
Supported SNMP traps
Notification name
MIB where it is defined
SNMP OID
eRAAlertDaemonRestarted
EMC-RAINFINITY-ALERTS-MIB
1.3.6.1.4.1.1139.9.3.2.0.1
eRAAlertsHistoryReset
EMC-RAINFINITY-ALERTS-MIB
1.3.6.1.4.1.1139.9.3.2.0.2
eRARainfinityAlert
EMC-RAINFINITY-ALERTS-MIB
1.3.6.1.4.1.1139.9.3.2.0.4
eRAGenericAlert
EMC-RAINFINITY-ALERTS-MIB
1.3.6.1.4.1.1139.9.3.2.0.5
eRASecurityAlert
EMC-RAINFINITY-ALERTS-MIB
1.3.6.1.4.1.1139.9.3.2.0.3
eRHSTemperatureAlert
EMC-RAINFINITY-HARDWARE-STATUS-MIB
1.3.6.1.4.1.1139.9.3.1.0.1
eRHSFanAlert
EMC-RAINFINITY-HARDWARE-STATUS-MIB
1.3.6.1.4.1.1139.9.3.1.0.2
eRHSPowerSupplyAlert
EMC-RAINFINITY-HARDWARE-STATUS-MIB
1.3.6.1.4.1.1139.9.3.1.0.3
eRHSMemoryAlert
EMC-RAINFINITY-HARDWARE-STATUS-MIB
1.3.6.1.4.1.1139.9.3.1.0.4
eRHSDiskAlert
EMC-RAINFINITY-HARDWARE-STATUS-MIB
1.3.6.1.4.1.1139.9.3.1.0.5
eRHSNICAlert
EMC-RAINFINITY-HARDWARE-STATUS-MIB
1.3.6.1.4.1.1139.9.3.1.0.6
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Alerts
CTA alerts
The CTA alerts are classified by type:
◆
Rainfinity alerts
◆
Generic alerts
◆
Security alerts
◆
Hardware alerts
Table 13 on page 145 lists all the CTA alerts.
Table 13
CTA alerts (1 of 6)
Index
Pattern name
Description
Type
SNMP OID
001-0001 (sshd|telnetd).*session
opened
User logged into this
system via ssh or telnet.
securityAlert
1.3.6.1.4.1.1139.9.3.2.0.3
001-0002 (sshd|telnetd).*session
closed
An ssh or telnet user
logged out.
securityAlert
1.3.6.1.4.1.1139.9.3.2.0.3
001-0003 Permission denied for
illegal user
User is not authenticated
and was denied access to
the system.
securityAlert
1.3.6.1.4.1.1139.9.3.2.0.3
001-0005 failed to bind to LDAP
server
Attempt to bind to the
securityAlert
LDAP server failed.
Possible causes include a
misconfiguredLDAPserver
address or a network
connectivity issue. Delays
in logging in or executing
commands may result if the
LDAPserver is unavailable.
1.3.6.1.4.1.1139.9.3.2.0.3
001-0006 Log rotation
Log rotation settings have rainfinityAlert
been modified via rfhsetup.
1.3.6.1.4.1.1139.9.3.2.0.4
001-0007 scp of system log files
Attempt to securely copy
the system log files has
been made. The alert
indicates whether the
attempt succeeded or
failed.
genericAlert
1.3.6.1.4.1.1139.9.3.2.0.5
001-0008 scp of CTA log files
Attempt to securely copy
CTA log files has been
made. The alert indicates
whether the attempt
succeeded or failed.
genericAlert
1.3.6.1.4.1.1139.9.3.2.0.5
001-0009 Invalid user
User is not known and was
denied access to the
system.
securityAlert
1.3.6.1.4.1.1139.9.3.2.0.3
001-0010 Accepted
keyboard-interactive
User is not known and was
denied access to the
system.
securityAlert
1.3.6.1.4.1.1139.9.3.2.0.3
001-0011 Security level
System's security level has
been modified.
securityAlert
1.3.6.1.4.1.1139.9.3.2.0.3
CTA alerts
145
Alerts
Table 13
CTA alerts (2 of 6)
Index
146
Pattern name
Description
Type
SNMP OID
001-0013 Certificate Expire
Warning
One certificate will expire
soon or has already
expired.
securityAlert
1.3.6.1.4.1.1139.9.3.2.0.3
001-0014 authentication failure
User's loginattempt viassh securityAlert
has failed due to an invalid
password.
1.3.6.1.4.1.1139.9.3.2.0.3
001-0015 changed password
expiry
User's password expiry
information is changed.
This typically happens if
passwordagingis enabled,
modified or disabled.
securityAlert
1.3.6.1.4.1.1139.9.3.2.0.3
001-0016 password changed
User’s password has been
changed in the local user
database.
securityAlert
1.3.6.1.4.1.1139.9.3.2.0.3
001-0017 Log Alerts system
enabled
rfalertd has been started.
securityAlert
1.3.6.1.4.1.1139.9.3.2.0.3
001-0018 Log Alerts system
disabled
rfalertd has been
terminated.
securityAlert
1.3.6.1.4.1.1139.9.3.2.0.3
001-3001 rfhsetup
User has launched the
rfhsetup tool.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
002-1001 Temperature Alert
Temperature status has
changed or a temperature
failure has occurred.
hardwareAlert
1.3.6.1.4.1.1139.9.3.1.0.1
002-1002 Fan Alert
Fan status has changed or
a fan failure has occurred.
hardwareAlert
1.3.6.1.4.1.1139.9.3.1.0.2
002-1003 Power Supply Alert
hardwareAlert
Power supply status has
changed or a power supply
failure has occurred.
1.3.6.1.4.1.1139.9.3.1.0.3
002-1004 Memory Hardware Alert
Memory hardware status
has changed or a memory
hardware failure has
occurred.
hardwareAlert
1.3.6.1.4.1.1139.9.3.1.0.4
002-1005 Disk Alert
Disk hardware status has
changed or a disk failure
has occurred.
hardwareAlert
1.3.6.1.4.1.1139.9.3.1.0.5
002-1006 NIC Alert
Network card status has
changed or a network card
failure has occurred.
hardwareAlert
1.3.6.1.4.1.1139.9.3.1.0.6
002-1007 capacity utilization
Partitioncapacity utilization genericAlert
exceeds a pre-configured
threshold.
1.3.6.1.4.1.1139.9.3.2.0.5
002-3001 Problem starting
Problem starting
filemanagement daemon filemanagement daemon
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
002-3002 filemanagement daemon filemanagement daemon
stopped
has been stopped
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
002-3003 filemanagement daemon filemanagement daemon
started
has been started
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Alerts
Table 13
CTA alerts (3 of 6)
Index
Pattern name
Description
Type
SNMP OID
002-3004 The number of CCD
connection in
CLOSE_WAIT
The number of CCD
connection in
CLOSE_WAIT exceeds
threshold
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
003-0001 Partition is full
A partition is full.
genericAlert
1.3.6.1.4.1.1139.9.3.2.0.5
301-0001 filemanagement daemon filemanagement daemon
enabled
has been enabled.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
301-0002 filemanagement daemon filemanagement daemon
disabled
has been disabled.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
301-0003 CTA-HA unable to
contact Cloud Tiering
Appliance
CTA has not been
responsive for CTA-HA (as
FCD) after a sufficiently
long period.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
301-0004 No matching DHSM
connection
Celerra archiving task has rainfinityAlert
failed because there is no
DHSM connection
configured on the Celerra
for the specified secondary
server. To create a DHSM
connection to the
secondary on the Celerra,
use the fs_dhsm
command.
1.3.6.1.4.1.1139.9.3.2.0.4
301-0005 Automatic creation of a
DHSM connection
rfwalker could not
automatically create a
DHSM connection.
Manually create it with
command fs_dhsm. See
the task summaries for
more details.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
301-0006 Archived files count limit
exceeded.
Archived files limit has
been exceeded.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
301-0007 Could not update
capacity values
CTA was unable to update
Capacity values for the
specified filesystem. This
will affect Capacity based
archiving on this
filesystem.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
301-0008 Database vacuumis due DB Data folder size
to be performed.
exceeds 2 times the
number of archived files.
Perform a database
vacuum.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
302-0001 CTA-HA unable to
contact Cloud Tiering
Appliance
CTA has not been
responsive for CTA-HA (as
CCD) after a sufficiently
long period.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
302-0002 (Centera) had this
problem during connect
Centerahas not responded rainfinityAlert
to a connection request.
1.3.6.1.4.1.1139.9.3.2.0.4
CTA alerts
147
Alerts
Table 13
CTA alerts (4 of 6)
Index
148
Pattern name
Description
Type
SNMP OID
302-0003 The recall
username/password
does not seem to be in
sync across CTAs and
may cause recall
problems
CCD has been monitoring rainfinityAlert
multiple CTAs and the
recall passwords on all the
CTAs are not the same.
1.3.6.1.4.1.1139.9.3.2.0.4
302-0004 has been rejected
because a Centera with
same name exists for a
different CTA IP
Centera with same name
has been added on
multiple CTAs.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
302-0005 The digest password or
digest username is
empty
Recall credentials are
empty. If using CCD with
mutiple CTAs, ensure all
the CTAs have credentials
configured
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
302-0006 has been rejected
because a celerra with
same name exists for a
different CTA IP
Celerra with same name
has been added on
multiple CTAs.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
303-0001 GUI user logged in
successfully
GUI user has logged in
successfully.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
303-0002 GUI login attempt failed
GUI login attempt has
failed.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
303-0003 GUI user logged out
GUI user has logged out.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
304-0001 exceeds threshold
NAS Repository usage has rainfinityAlert
exceeded the configured
threshold.
1.3.6.1.4.1.1139.9.3.2.0.4
304-0002 Task failed too many
operations and
terminated early
Task has failed too many
operations and has been
terminated early.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
304-0003 Failure setting retention
for the Atmos object
Failure to set retention for
the Atmos object. Verify
that the Atmos policy
specifies retention.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
305-0001 StubScanner progress
Display number of CFA
files converted by the
StubScanner periodically.
Only displayed after CFA
Stubs are found.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
305-0002 StubScanner Complete
Display final number of
CFA files converted by the
StubScanner.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
305-0003 DXConversion progress
Display number of DXNAS rainfinityAlert
stub files converted
periodically. Onlydisplayed
while DXConversion is
running.
1.3.6.1.4.1.1139.9.3.2.0.4
305-0004 DXConversion Complete Display final number of DX rainfinityAlert
NAS stub files converted.
1.3.6.1.4.1.1139.9.3.2.0.4
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Alerts
Table 13
CTA alerts (5 of 6)
Index
Description
Type
SNMP OID
306-0001 Task completed
Task has completed.
Additional details provide
task information and
statistics.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
701-0001 Unable to open
connection to Centera
Either ainvalidPEAfilehas rainfinityAlert
been specified or
connectivity to Centera is
down.
1.3.6.1.4.1.1139.9.3.2.0.4
701-0002 Archive Warning
threshold reached
Warning when Capacity
Archive has reached the
threshold.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
701-0003 Archive by Capacity
started
Notice when Capacity
Archive has started.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
701-0004 Tasks remaining in the
pending queue will be
ignored
Alert when pending queue
is not empty when FMD
has been shutdown.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
701-0005 Failed to archive backup
file
Alert when copying of
backup file to backup
destination has failed.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
701-0006 Failed to restore backup
file
Alert when restoring of
backup file from backup
destination has failed.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
701-0007 No successful database
backups done for the
past
Alert when no backup task rainfinityAlert
has run successfully for the
past X number of days.
1.3.6.1.4.1.1139.9.3.2.0.4
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
701-0008
Pattern name
Policy execution caused Alert when the execution of
a repository to exceed its a policy has caused a
capacity limit
repository to exceed its
capacity limit.
701-0009 File archiving has
reached over 80%
Alert when archived files
count has reached 80%of
500 million max file limit.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
701-0010 A fatal error has caused
a CTA process to
terminate
A fatal error has caused a rainfinityAlert
CTA process to terminate.
The log lists specific error
messages.
1.3.6.1.4.1.1139.9.3.2.0.4
701-0011 Unable to get CCD DNS The policy's destination is
Name or was not
Centera but CCD DNS
specified for
Name was not specified.
Update the source celerra
server with CCD DNS
Name and try again
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
701-0012 Unable to get ACD DNS
Name or was not
specified for
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
The policy's destination is
Atmos or Amazon S3 but
ACD DNS Name was not
specified. Update the
source Celerra server with
ACD DNS Name and try
again.
CTA alerts
149
Alerts
Table 13
CTA alerts (6 of 6)
Index
Pattern name
Description
Type
SNMP OID
701-0013 A vacuum task will start
within the next 1 hour.
Alert when a vacuum task
will start in the next 1 hour
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
701-0014 File Migration task
reached its file threshold
limit
Recursive File Migration
task has reached its file
threshold limit and will not
auto run again. Correct the
situation and try again.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
801-0001 Failed to recall file from
NetApp
A recall from NetApp failed rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
901-0001 Found a duplicate Atmos Duplicate Atmos name
name and so this
rejected by ACD.
configuration will not be
pulled down
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
901-0002 The recall
username/password
does not seem to be in
sync across CTAs and
may cause recall
problems
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
Password is not in sync
across multiple CTAs
configured for this ACD
All alerts are listed in the Log Pattern Index of the GUI.
Use the CLI or the Alert Settings page in the CTA GUI to edit log alert patterns.
Configuration options include:
◆
◆
◆
Status — Alerts can be individually enabled.
Throttle time — A different throttle time may be applied to each alert pattern. If
alerts occur more than once within a specified throttle time, the repeated alerts are
suppressed.
Included in summary — Included alerts appear in the alert summary.
Note: To enable e-mail alert messages from the device, alert settings must be configured.
150
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Glo sary
This glossary contains terms related to the Cloud Tiering Appliance. Many of these
terms are used in this manual.
A
API
Archiving
Application programming interface. A source code interface provided by the
computer application to support requests for services.
Process that walks the share/export and performs policy-based file archiving.
B
Backup
Task to back up the CTA and CTA/VE configuration and database.
C
Celerra Callback
Service
Celerra FileMover
Centera API
Centera content
address
Cloud Callback
Service
Callback service to support FileMover recall from Centera. CCD is the callback service
used to recall files from Centera.
HSM implementation used to support offline files on the Celerra.
API used to write and read files from Centera.
Unique key to the saved file on Centera.
CTA callback service to support FileMover recall from cloud storage such as Atmos or
Amazon S3. ACD is the callback service used to recall files from the cloud.
D
Delete orphan
Delete stub
DHSM
DNS
Task to delete orphan files on secondary storage that match the delete_orphans policy.
Task to delete stub files on primary storage that match the delete_stubs policy.
Distributed Hierarchical Storage Management is the former name for Celerra
FileMover.
Domain naming system. Used on the internet to map the names of host computers to
their respective IP addresses.
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
151
Glossary
F
File encryption
File migration
File version
FileMover API
FPolicy Callback
Daemon (FCD)
FPolicy server
FQDN
An option to provide additional protection for data stored in the cloud such as Atmos
or Amazon S3.
Task to move files that match the migrate_file policy between two primary file
servers. Stubs on the new primary file server will point to the archived files on the
original target.
Multiple copies on secondary storage of the same file or path.
API over HTTP exposed by Celerra Data Mover to create stub files.
CTA callback daemon used to support NetApp Fpolicy recall from all secondary
storage.
NetApp Fpolicy server. Provides notification when client accesses stub files.
Fully qualified domain name. Used with the Celerra Callback DNS entry.
H
HSM
Hardware security module.
I
Import file
Files imported from a third-party software provider that CTA archives.
K
Keystores
Keystore replication
Krdsetup
The locations on the HA appliance and the primary appliance where the file
encryption key is stored. To use file encryption, the keystores must be in sync.
Process that copies the file encryption key from the primary appliance to the HA
appliance.
CTA CLI command that enables keystore replication on the HA appliance. KRD is the
keystore replication daemon.
L
LDAP
Lightweight Directory Access Protocol
M
Multi-tier
Multi-tier stub
Archive policy that scans stubs and normal files for for archiving to one tier, and then
later relocates the files to another tier.
Archive policy that scans stubs for archiving to one tier, and then later relocates the
stub files to another tier.
N
NAS
152
Network attached storage.
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Glossary
O
Orphan file
Files on the secondary storage with no reference to the primary storage.
P
Primary storage
NAS device that exports CIFS or NFS volumes.
R
Repository migration
Task to migrate all archived files that have corresponding stubs from one repository
to another storage tier. Repository migration does not move orphan files.
Retention period
Period of time measured in days, months, weeks, or years from time of archiving that
a file can not be deleted.
S
Secondary storage
SNMP
STIG
Stub scanner
Stub file/Offline files
Data storage that is a backup to primary storage.
Simple Network Management Protocol
Security Technical Implementation Guide
Scans stubs and updates the stub file information in the CTA database.
Files that appear as normal files on the primary storage but point to data content
stored on the secondary storage.
V
VMotion
VMware VMotion technology is virtual machine mobility unique to VMware.
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
153
Glossary
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Index
A
access control list 130
access node 98
access node string 98
acdsetup.sh 66
ACL. See access control list
admin user 113
age passwords 114
alert settings
email 123
SNMP 124
alerts 123
Amazon
configure in CTA GUI 95, 97
web service specific settings 95
anonymous 98
anonymous bind 119
appliance
diagrams 31
rails 26
archive file list 100
Atmos
archiving from Celerra or VNX 66
configure in CTA GUI 96
creating connection from Celerra or VNX 73
DNS name 96
recall from 66
shared secret 96
SSL certificate 96
Atmos callback
FQDN 64
Atmos callback agent 64
atmos_trusted_CAs.pem 97
atmoscallback
stop 51
atmoscert.pl 97
authentication 98
Azure
Container Name 97
B
backup 104
backup dump
create 104
CTA 103
restore 104
bind policy 117
bind type 117
C
callback daemon
clean install 51
DNS entry 65
callback service 66
ccdsetup.sh 66
CD clean install 51
Celerra
Atmos callback agent settings 64
CIFS specific settings 63
configure in CTA GUI 62
CTA configuration 61
DART 6.0 XML API user 69
directory exclusion 64
FileMover API user 67
FileMover settings 64
FQDN 44
NDMP 63
prerequisite configuration tasks 67
prerequisites for archiving tasks 62
prerequisites for file migration tasks 61
source 64
VDM 63
celerracallback
stop 51
Centera
access node 98
access node string 98
archiving from Celerra or VNX 66
authentication 98
configure in CTA GUI 98
creating connection from Celerra or VNX 73
Centera recall 66
Certificate Authority 118
certificate management 120
chassis
CTA 28
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
155
Index
CTA-HA 30
CIFS specific settings
Celerra or VNX 63
Data Domain 93
Isilon 91
NetApp 78
VNXe 81
Windows 82
cifs.client.dup-detection 75
clean install 51
cleartext 120
CLI login 56
client certificate 120
client configuration 117
Cloud Tiering Appliance setup tool 52
command history 125
command line interface 56
community string 125
Container Name 97
convert unicode 74
create unicode 74
CTA
adding Celerra 62
adding NetApp 77
adding VNX 62
adding VNXe 80
backup 103
configure Amazon S3 95, 97
configure Atmos server 96
configure Centera 98
configure Data Domain server 93
configure Isilon 90
configure VNXe 80
configure Windows server 82
disable duplicate session 75
NetApp archiving 77
overview 16
restore 103
CTA setup 53
CTA-HA
appliance details 29
configuring on Celerra or VNX 44
configuring on NetApp 45
D
DART 6.0
XML API system user 69
DART 7.0
XML API system user 70
Data Domain 93
database maintenance 106
DBMaintenance.log 106
Deploy OVF Template 41
DHSM
automatically create connections 68
connection password for DART 6.0 69
connection password for DART 7.0 72
enable for Data Mover 68
manually create connections 72
directory exclusion 79
156
Celerra or VNX 64
disaster recovery 104
disks
CTA 28
CTA-HA 30
DNS entry 65, 94
DNS server 53
domain 53
DUMPFILE 104
duplicate session disable 75
E
enable SNMP alerts 124
ESX 39
F
file encryption 54
file list import 100
FileMover API 67
setting in CTA 64
fmadmin 127
fmbackup 56
creating backup 104
fmrestore 56, 104, 105
fmsupportdump 56
fpolicy callback agent 79
FPolicy Callback Service 77
fpolicy.enable 76
fpolicycallback
stop 51
fpsetup.sh 77
FQDN 44, 64
fs_dhsm 72
Fully Qualified Domain Name. See FQDN
G
global LDAP 117
graphical user interface 55
GUI 55
H
harden appliance 112, 115
high availability appliance details 29
host IP 78
hostname 53
hostname resolution 65
hosts 54
I
import file list archive 100
import file task 101
import list provider 100
import logs 103
installation 51
Isilon
configuration 90
NDMP 91
prerequisites as CIFS destination 84
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Index
prerequisites as NFS destination 88
prerequisites for migration 89
ISO image 51
networking 53
notification host 124
O
K
Kerberos 120
keystore 54
keystore replication daemon 54
krdsetup 54
L
online help 24
Open LDAP 117
ops user 113
OVA file 39
OVF file 43
ovftool 43
last 126
LDAP
advanced settings 119
authentication 117
basic settings 118
bind policy 118
global settings 117
server type 117, 118
time limits 117
Linux PAM users 113
local admin 79
log alert pattern 123
logs
alerts 123
rotating 121
P
M
R
md5sum 51
memory
CTA 28
CTA-HA 30
MSI file
SID translator utility 130
RAID controller
CTA 28
CTA-HA 30
rails 26
rainacd.domain 66
rainccd.domain 66
repository 94
restore
CTA 104
dumpfile 104
reverse lookup zones 65
rfalertd 125
rffm 56, 107
rfhsetup 112, 115, 118, 121, 123, 125
rflastcomm 126
rfpolicy 76
rfsnmp 125
root logins 114
rotating logs 121
rssystat 56
N
NAS repository 94
nasadmin 67
NDMP
Celerra or VNX 63
Isilon 89, 91
NetApp 78
VNXe 81
NetApp
CTA configuration 74
directory exclusion 79
FPolicy callback agent 79
local admin 79
NDMP 78
prerequisites as archiving source 74
prerequisites for file migration tasks 74
source 78
unicode options 74
vFiler 77
vFiler host IP 78
network interfaces
CTA 28
CTA-HA 30
PAM. See pluggable authentication module
passwords 114
PEA file 98
PEM file 97
pluggable authentication module 112
Pool Entry Authentication file 98
port detail
CTA8-APL, CTA8-HA-APL 35
CTA-APL, CTA-APL-HA, FMA7-APL,
FMA7-APL-HA 35
FMA6-APL, FMA6-HA-APL 36
Process Acounting package 125
provider properties 100
psacct 125
S
SASL 119
scp 122
security hardening
features 112
logs 121
security ID. See SID translator
sendmail 150
serial port
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
157
Index
CTA 28
CTA-HA 30
server type 117
shared secret 96
SID translator 130
upload tables for migration 133
simple bind 119
single security database 112
Snapsure 61
SNMP
community string 125
notification host 124
SNMP alerts 124
SNMP polling 125
SSL certificate 96
SSL X.509 certificate 96
STIG hardening 115
strengthen passwords 114
system command accounting 125
T
tgz file 104
third-party software provider 100
time limits 117
TLS 120
track command history 126
track user login history 126
FQDN 44
NDMP 63
prerequisite configuration tasks 67
prerequisites for archiving tasks 62
prerequisites for file migration tasks 61
source 64
VDM 63
VNXe
configure in CTA GUI 80
NDMP 81
prerequisites for file migration tasks 80
VST 139
W
web service specific settings 96
wheel group 113
Windows
configuration 82
Windows domain user 127
X
xlt.cfg 67
XML API
system user for DART 6.0 69
system user for DART 7.0 70
XML file for import 100
U
uc_config 67
unicode
Celerra or VNX 67
NetApp 74
user profile 98
UTF-8 67
V
vacuum process 106
vFiler 77
VGT 140
VI Client 43
virtual data mover 63
VLAN tagging mode
virtual guest tagging 140
virtual switch tagging 139
VMDK file 43
VMotion 140
VMware
ESX 4.0 server 39
ESXi 3.5 server 39
VNX
Atmos callback agent settings 64
CIFS specific settings 63
configure in CTA GUI 62
CTA configuration 61
DART 7.0 XML API user 70
directory exclusion 64
FileMover API user 67
FileMover settings 64
158
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 10.0 Getting Started Guide
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising