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 7.5
Getting Started Guide
P/N 300-005-093
REV A14
EMC Corporation
Corporate Headquarters:
Hopkinton, MA 01748-9103
1-508-435-1000
www.EMC.com
Copyright © 2007 - 2011 EMC Corporation. All rights reserved.
Published August, 2011
EMC believes the information in this publication is accurate as of its publication date. The information is subject to change
without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO
REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION,
AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.
For the most up-to-date regulatory document for your product line, go to the Technical Documentation and Advisories section
on EMC Powerlink.
For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.
All other trademarks used herein are the property of their respective owners.
2
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Contents
Preface
Chapter 1
Introduction
Overview of the EMC Cloud Tiering Appliance................................................
Cloud Tiering Appliance/VE (CTA/VE) .....................................................
High Availability for CTA and CTA/VE......................................................
CTA implementation with Celerra or VNX primary storage...........................
CTA implementation with NetApp primary storage ........................................
CTA and CTA/VE tasks.........................................................................................
Using CTA and CTA/VE .......................................................................................
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
16
16
17
18
20
21
23
26
26
26
27
29
31
34
Deploying the Cloud Tiering Appliance
Deployment process ...............................................................................................
Supported platforms ..............................................................................................
Appliance setup ......................................................................................................
Installing the virtual edition..................................................................................
CTA and CTA/VE for high availability...............................................................
Celerra or VNX primary storage ....................................................................
NetApp primary storage .................................................................................
Configuring CTA ....................................................................................................
Configuring the CTA network .......................................................................
Configuring the hostname, domain, and DNS server.................................
Graphical user interface...................................................................................
Command line interface ..................................................................................
Deploying CTA with Celerra or VNX..................................................................
Prerequisites for using Celerra or VNX as a file migration source or
destination ........................................................................................................
Prerequisites for Celerra or VNX as an archive source...............................
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
36
37
38
39
43
43
43
44
45
45
46
46
47
47
47
3
Adding a Celerra or VNX to the CTA configuration................................... 48
Configuring Celerra or VNX to EMC Centera or Atmos archiving
on the CTA ......................................................................................................... 50
Configure name resolution for archiving ...................................................... 51
Prerequisite tasks on the Celerra or VNX Control Station
for file migration or archiving......................................................................... 52
Deploying CTA with NetApp ............................................................................... 58
Prerequisites for using NetApp as a file migration source......................... 58
Prerequisites for using NetApp as an archiving source ............................. 58
vFiler configuration ......................................................................................... 60
Configuring NetApp archiving on the CTA ................................................ 60
Adding a NetApp filer to the CTA configuration........................................ 61
Deploying the CTA with a VNXe ......................................................................... 63
Prerequisites for using VNXe as a file migration destination ................... 63
Adding a VNXe to the CTA configuration.................................................... 63
Deploying CTA with a Windows server .............................................................. 65
Deploying CTA with Isilon.................................................................................... 66
Prerequisite tasks when using Isilon as a CIFS share destination ............. 66
Prerequisite tasks when using Isilon as an NFS export destination.......... 69
Adding an Isilon to the CTA configuration .................................................. 70
Deploying the CTA with a Data Domain............................................................. 71
Configuring a NAS-based repository .................................................................. 72
Deploying CTA with EMC Centera...................................................................... 73
Deploying CTA with Atmos .................................................................................. 75
Adding Atmos to the CTA configuration...................................................... 75
Installing the SSL certificate on the CTA ....................................................... 76
Chapter 4
Maintaining the Cloud Tiering Appliance
Importing a file list archive.................................................................................... 78
Adding the primary servers ............................................................................ 78
Configuring the import provider ................................................................... 79
Configuring the import task............................................................................ 79
Importing the file list ........................................................................................ 80
Validating the import file................................................................................. 81
Backing up the configuration ................................................................................ 82
Creating a backup dump ................................................................................. 83
Restoring a backup dump................................................................................ 84
Maintaining the database....................................................................................... 88
Checking database size and disk capacity .................................................... 88
Performing database maintenance ................................................................. 88
Performing a CD clean install................................................................................ 89
Software upgrades .................................................................................................. 90
Before upgrading from FMA versions earlier than 7.3................................ 90
CD full upgrade................................................................................................. 91
UPG upgrade ..................................................................................................... 92
Migrating from CTA to CTA/VE .......................................................................... 93
Shutting down and restarting the appliance....................................................... 94
Chapter 5
Cloud Tiering Appliance System Settings
Security hardening .................................................................................................. 96
Single security database ................................................................................... 96
Disable root logins ............................................................................................ 97
Strengthen passwords ...................................................................................... 98
4
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Age passwords.................................................................................................. 98
Configuring the GUI access method.................................................................... 99
STIG hardening ....................................................................................................... 99
Enabling STIG hardening ................................................................................ 99
Disabling STIG hardening............................................................................. 100
LDAP client configuration .................................................................................. 101
Global LDAP settings..................................................................................... 101
LDAP authentication ..................................................................................... 101
Configuring basic LDAP settings................................................................. 102
Configuring advanced LDAP settings ........................................................ 103
RADIUS and TACACS+ ...................................................................................... 104
Certificate management ...................................................................................... 104
Appliance mail delivery settings........................................................................ 105
Log settings............................................................................................................ 106
Configuring log rotation................................................................................ 106
Configuring SCP of rotated log files............................................................ 106
Alerts ................................................................................................................ 108
Configuring email alerts................................................................................ 112
Configuring SNMP alerts .............................................................................. 113
Enabling SNMP polling ................................................................................. 113
System command accounting ............................................................................. 114
Tracking user command history .................................................................. 115
Tracking user login history ........................................................................... 115
Tracking daemon command history............................................................ 115
Windows domain user ......................................................................................... 116
Creating a Windows domain user ............................................................... 116
Adding an admin user to the local administrator group.......................... 116
Configuring Windows 2008 for NTLM ....................................................... 117
SID translator......................................................................................................... 118
Installing the SID translator .......................................................................... 118
Creating the SID translation file ................................................................... 119
Uploading the SID translation file ............................................................... 121
Deleting a SID translation file....................................................................... 121
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 .................................................................
124
124
125
125
127
127
128
Glossary
Index
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
5
6
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Figures
Title
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Page
Celerra or VNX implementation .........................................................................................
NetApp implementation ......................................................................................................
Archived report example .....................................................................................................
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 5 or Gen 6 appliance ..............................................................................
Front view of Gen 5 or Gen 6 appliance with bezel removed ........................................
Front view of the Gen 5 or Gen 6 appliance with bezel ..................................................
Front view of Dell R710 for High Availability with bezel removed ..............................
Front view of Dell 2950 for High Availability with bezel removed ..............................
CTA-APL, CTA-APL-HA, FMA7-APL and FMA7-HA-APL port details ....................
FMA6-APL, FMA6-HA-APL, and FMA5-HA-APL port details ....................................
Cloud Tiering Appliance deployment process .................................................................
Example of Celerra property settings in FMA version 7.2 ..............................................
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
18
20
22
31
31
31
32
32
32
33
33
34
34
36
90
7
Figures
8
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Tables
Title
1
2
3
4
5
6
7
8
9
Page
CTA that is based on Dell R710 ........................................................................................... 27
CTA that is based on Dell 2950 ........................................................................................... 27
CTA-HA that is based on Dell R710 ................................................................................... 29
CTA-HA that is based on Dell 2950 .................................................................................... 29
Supported platform matrix for multi-tier archiving ........................................................ 37
Supported platform matrix for file migration ................................................................... 37
VMware ESX Server interoperability ................................................................................. 39
Supported SNMP traps ...................................................................................................... 108
CTA alerts ............................................................................................................................. 108
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
9
Tables
10
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 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
Related
documentation
This document is part of the EMC Cloud Tiering Appliance and Cloud Tiering
Appliance/VE documentation set. The documentation is intended for use by:
◆
Storage management administrators who are new to the EMC Cloud Tiering
Appliance and Cloud Tiering Appliance/VE.
◆
Existing customers who are new to version 7.5.
Related documents include:
◆
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE online help —
Provides detailed reference information on specific product features and
functions.
◆
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Release Notes —
Provides an overview of new features and lists any limitations.
◆
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
Preface
11
Preface
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
A caution contains information essential to avoid data loss or damage to the system
or equipment.
!
IMPORTANT
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 7.5 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 for
information about EMC products, licensing, and service, go to the EMC Powerlink
website (registration required) at:
http://Powerlink.EMC.com
Technical support — For technical support, go to EMC Customer Service on
Powerlink. To open a service request through Powerlink, you must have a valid
support agreement. Please contact your EMC sales representative for details about
obtaining a valid support agreement or to answer any 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
14
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
1
Introduction
This chapter includes the following sections:
◆
◆
◆
◆
◆
Overview of the EMC Cloud Tiering Appliance ....................................................... 16
CTA implementation with Celerra or VNX primary storage .................................. 18
CTA implementation with NetApp primary storage ............................................... 20
CTA and CTA/VE tasks ................................................................................................ 21
Using CTA and CTA/VE .............................................................................................. 23
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 multi-tier archiving” on page 37
◆
“Supported platform matrix for file migration” on page 37
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 7.5 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.
Depending on the environment, VMware HA features require:
◆
Virtual Center 2.5 for ESX 3.5
◆
vCenter Server 4.0 for ESX 4.0
Information on configuring the VMware HA is provided in the VMware
documentation.
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 18 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
CTA implementation with Celerra or VNX primary storage
Figure 1 on page 18 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 EMC Centera)
(TCP 9000 for Atmos)
/etc/hosts
2
3
DNS
EMC CTA
PowerEdge
2950
NFS
CIFS
EMC CTA-HA
PowerEdge
2950
Platform API
NFS
Repository
CIFS
Repository
EMC Centera or Atmos
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:
1. Clients send read/write operations for files that have been archived. These
operations are intercepted by the DHSM layer on the Celerra or VNX prior to
being serviced from the filesystem.
2. If the file has been archived to EMC Centera® or EMC Atmos™ storage, the
Celerra or VNX blade resolves the fully qualified domain name (FQDN) to the IP
address of the CTA or CTA-HA.
The blade then uses HTTP to read the archived data from the appliance, which in
turn reads it from EMC Centera or Atmos 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
18
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Introduction
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.
3. 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.
4. 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 Celerra or VNX primary storage
19
Introduction
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)
Primary
FPolicy
2
Secondary
WAFL
FPolicy API
FPolicy API
EMC CTA
EMC CTA-HA
PowerEdge
PowerEdge
2950
3
NFS
CIFS/SMB
over NetBIOS
NFS
Repository
CIFS
Repository
2950
Platform
API
EMC Centera or Atmos
CNS-001619
Figure 2
NetApp implementation
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.
20
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Introduction
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, EMC Centera, or Atmos 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 tiering, 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
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.
CTA and CTA/VE tasks
21
Introduction
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 all regular (non-stub) files. Files are selected for
archiving based on the archive policy.
◆
Multi-tier (with policy) — For this archiving task, all 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
repository 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 repository and the stub is updated to point to the new
location. Otherwise, the archived data remains in the current repository.
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 7.5 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 scans for stubs in the CTA
database that are no longer present on the source. When a stub has not been
detected for 30 or more days, the archived file is designated as an orphan.
◆
Backup — The backup task performs periodic backups of the CTA configuration
and database. Schedule backup tasks as part of a regular maintenance program.
◆
Repository Migration — Repository migration moves all archived data from one
repository to another storage tier. Migration can be to a NAS repository, to an
EMC Centera, or to an Atmos on-premise or service provider cloud. 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 between two
primary file servers 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.
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 46 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, ”Deploying the Cloud Tiering Appliance”
◆
Chapter 4, ”Maintaining the Cloud Tiering Appliance”
◆
Chapter 5, ”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.
Using CTA and CTA/VE
23
Introduction
24
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 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....................................................................................................................... 34
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:
◆
A 2U 19-inch rackmountable Cloud Tiering Appliance.
◆
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.
◆
One serial cable.
Note: The following are items are not included: VGA monitor, keyboard, and mouse for a
system console.
Cloud Tiering Appliance types
◆
Dell R710 — Models CTA-APL and FMA7-APL ship with two enabled on-board
gigabit Ethernet copper 10/100/1000TX ports. Figure 12 on page 34 shows the
port details.
◆
Dell 2950 — Models FMA6-APL and FMA5-APL ship with two on-board gigabit
Ethernet copper 10/100/1000TX ports. Figure 13 on page 34 shows the port
details.
Cloud Tiering Appliance High Availability types
26
◆
Dell R710 — Models CTA-APL-HA and FMA7-HA-APL ship with two enabled
on-board gigabit Ethernet copper 10/100/1000TX ports. Figure 12 on page 34
shows the port details.
◆
Dell 2950 — Models FMA6-HA-APL and FMA5-HA-APL ship with two on-board
gigabit Ethernet copper 10/100/1000TX ports. Figure 13 on page 34 shows the
port details.
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Cloud Tiering Appliance Hardware and Port Configurations
Cloud Tiering Appliance details
Table 1 on page 27 lists the Gen 7 hardware configurations for the CTA that are based
on the Dell R710 hardware.
Table 1
CTA that is based on Dell R710
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 80W 4MB 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 5 on page 31.
RAID controller
PERC6/I
CD-ROM
Read-only DVD that can read CD or DVD material for system upgrades. Item (a) in
Figure 5 on page 31.
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 4 on page 31.
VGA
Standard VGA video connector for a system console. Item (a) in Figure 4 on
page 31.
Keyboard connector
Standard USB keyboard connector for a system console. Item (d) in Figure 4 on
page 31.
Mouse connector
Standard USB mouse connector for a system console. Item (c) in Figure 4 on
page 31.
Serial port
Standard DB9 serial port for a serial-terminal system. Item (b) in Figure 4 on
page 31.
Table 2 on page 27 lists the Gen 5 and Gen 6 hardware configurations for the CTA that
are based on the Dell 2950 hardware.
Table 2
CTA that is based on Dell 2950 (page 1 of 2)
Component
FMA6-APL
FMA5-APL
Chassis
The appliance is based on Dell 2950
hardware.
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.
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: 5A
at 120 V or 2.5 A at 240 V.
Dual redundant 750 watt hot-plug,
power supplies. Total consumption: 5A
at 120 V or 2.5 A at 240 V.
CPUs
Dual Intel Xeon 3.00 GHz Quad Core
processors with 1333 MHz front-side
bus.
Dual Intel Xeon 3.00 GHz Dual Core
processors with 1333 MHz front-side
bus.
Cloud Tiering Appliance details
27
Cloud Tiering Appliance Hardware and Port Configurations
Table 2
28
CTA that is based on Dell 2950 (page 2 of 2)
Component
FMA6-APL
FMA5-APL
Disks
Four 250 GB, SATA, 3.5-inch, 7.2K RPM
hard drives in a RAID-5 configuration.
Items (b) through (e) in Figure 8 on
page 32.
Six 160 GB, SATA, 3.5-inch, 7.2K RPM
hard drives in a RAID-1 configuration.
Items (b) through (g) in Figure 8 on
page 32.
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.
PERC 5/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.
Dell DRAC Card.
CD-ROM
24x IDE CD-ROM/DVD-ROM drive for
system upgrades. Item (a) in Figure 8
on page 32.
24x IDE CD-ROM drive for system
upgrades. Item (a) in Figure 8 on
page 32.
Memory
667 MHz, (4 x 1 GB), single-ranked
DIMMs
667 MHz, (8 x 512 MB), single-ranked
DIMMs
Network interfaces
Two on-board gigabit 10/100/1000TX
Ethernet copper ports with RJ45
connectors. Item (e) in Figure 7 on
page 32.
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.
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.
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.
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.
Standard DB9 serial port for a
serial-terminal system. Item (b) in
Figure 7 on page 32.
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Cloud Tiering Appliance Hardware and Port Configurations
Cloud Tiering Appliance for High Availability details
Table 3 on page 29 lists the Gen 7 hardware configurations for the CTA-HA that are
based on the Dell R710 hardware.
Table 3
CTA-HA that is based on Dell R710
Component
CTA-APL-HA, FMA7-HA-APL
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 W 4 MB Cache Nehalem-EP
Disks
Two 1 TB, SATA, 3.5-inch, 7.2K RPM hard drives in a RAID-1 (SW) configuration.
Items (b) and (c) in Figure 10 on page 33.
RAID controller
SAS6/IR
CD-ROM
Read-only DVD that can read CD or DVD material for system upgrades. Item (a) in
Figure 10 on page 33.
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 4 on page 31.
VGA
Standard VGA video connector for a system console. Item (a) in Figure 4 on
page 31.
Keyboard connector
Standard USB keyboard connector for a system console. Item (d) in Figure 4 on
page 31.
Mouse connector
Standard USB mouse connector for a system console. Item (c) in Figure 4 on
page 31.
Serial port
Standard DB9 serial port for a serial-terminal system. Item (b) in Figure 4 on
page 31.
Table 4 on page 29 lists the Gen 5 and Gen 6 hardware configurations for the CTA-HA
that are based on the Dell 2950 hardware.
Table 4
CTA-HA that is based on Dell 2950 (page 1 of 2)
Component
FMA6-HA-APL
FMA5-HA-APL
Chassis
The appliance is based on Dell 2950
hardware. It is a 2U rackmount form
factor with universal rails.
The appliance is based on Dell 2950
hardware. It is a 2U rackmount form
factor with universal rails.
Size
2U rackmount form factor with universal
rails. Dimensions: 8.6 cm (h), 44.5 cm
(w), 66.1 cm (d). Weight: 34 kg.
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.
Dual redundant 750 watt hot-plug,
power supplies.
CPU
Single Intel Xeon 2.33 GHz Quad Core
processor with 1333 MHz front-side
bus.
Single Intel Xeon 1.86 GHz Dual Core
processor with 1066 MHz front-side
bus.
Cloud Tiering Appliance for High Availability details
29
Cloud Tiering Appliance Hardware and Port Configurations
Table 4
30
CTA-HA that is based on Dell 2950 (page 2 of 2)
Component
FMA6-HA-APL
FMA5-HA-APL
Disks
Two 250 GB, SATA, 3.5-inch, 7.2K RPM
hard drives in a RAID 1 configuration.
Items (b) and (c) in Figure 11 on
page 33.
Two 160 GB, SATA, 3.5-inch, 7.2K RPM
hard drives in a RAID 1 configuration.
Items (b) and (c) 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.
PERC 5/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.
CD-ROM
24x IDE CD-ROM/DVD-ROM drive for
system upgrades. Item (a) in Figure 11
on page 33.
24x IDE CD-ROM drive for system
upgrades. Item (a) in Figure 11 on
page 33.
Memory
4 GB, 533 MHz (4x1 GB), dual-ranked
DIMMs.
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 7 on
page 32.
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.
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.
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.
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.
Standard DB9 serial port for a
serial-terminal system. Item (b) in
Figure 7 on page 32.
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Cloud Tiering Appliance Hardware and Port Configurations
Appliance diagrams
These photographs illustrate configurations of the CTA and CTA-HA.
Figure 4
Rear view of Gen 7 appliance
Figure 5
Front view of Gen 7 appliance with bezel removed
Figure 6
Front view of the Gen 7 appliance with bezel
Appliance diagrams
31
Cloud Tiering Appliance Hardware and Port Configurations
32
Figure 7
Rear view of Gen 5 or Gen 6 appliance
Figure 8
Front view of Gen 5 or Gen 6 appliance with bezel removed
Figure 9
Front view of the Gen 5 or Gen 6 appliance with bezel
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Cloud Tiering Appliance Hardware and Port Configurations
Figure 10
Front view of Dell R710 for High Availability with bezel removed
Figure 11
Front view of Dell 2950 for High Availability with bezel removed
Appliance diagrams
33
Cloud Tiering Appliance Hardware and Port Configurations
Port details
Models CTA-APL, CTA-APL-HA, FMA7-APL and FMA7-HA-APL ship with two
on-board ports enabled. Figure 12 on page 34 is a rear view of the appliance with the
ports labeled.
eth0
eth1
Disabled Disabled
CNS-001354
Figure 12
CTA-APL, CTA-APL-HA, FMA7-APL and FMA7-HA-APL port details
Models FMA6-APL, FMA6-HA-APL, and FMA5-HA-APL ship with two on-board
ports. Figure 13 on page 34 is a rear view of the appliance with the ports labeled.
eth1
eth0
CNS-001259
Figure 13
34
FMA6-APL, FMA6-HA-APL, and FMA5-HA-APL port details
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
3
Deploying the Cloud
Tiering Appliance
This chapter contains the following sections:
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
Deployment process ...................................................................................................... 36
Supported platforms...................................................................................................... 37
Appliance setup.............................................................................................................. 38
Installing the virtual edition ......................................................................................... 39
CTA and CTA/VE for high availability ...................................................................... 43
Configuring CTA............................................................................................................ 44
Deploying CTA with Celerra or VNX ......................................................................... 47
Deploying CTA with NetApp ...................................................................................... 58
Deploying the CTA with a VNXe ................................................................................ 63
Deploying CTA with a Windows server..................................................................... 65
Deploying CTA with Isilon........................................................................................... 66
Deploying the CTA with a Data Domain.................................................................... 71
Configuring a NAS-based repository.......................................................................... 72
Deploying CTA with EMC Centera............................................................................. 73
Deploying CTA with Atmos ......................................................................................... 75
Deploying the Cloud Tiering Appliance
35
Deploying the Cloud Tiering Appliance
Deployment process
Figure 14 on page 36 illustrates how the EMC Cloud Tiering Appliance (CTA) or
Cloud Tiering Appliance/VE is deployed for archiving.
.
CTA Setup
1. Install the CTA/VE, if applicable.
2. Configure CTA networking.
Celerra or VNX to EMC Centera
or Atmos Configuration
1. Configure Celerra or VNX properties.
2. Initialize recall services.
3. Configure name resolution for recall.
4. Configure FileMover API.
5. Configure DHSM.
Celerra or VNX to NAS Configuration
NetApp Configuration
1. Configure Celerra or VNX properties.
2. Configure FileMover API.
3. Configure DHSM.
1. Configure ONTAPI.
2. Configure vFilers, if applicable.
3. Initialize recall services.
4. 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 14
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.
◆
“Supported platforms” on page 37 lists the platforms supported for archiving and
migration tasks.
◆
“Appliance setup” on page 38 outlines the procedure to deploy a CTA 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.
36
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Deploying the Cloud Tiering Appliance
Supported platforms
Platform support varies depending on the task performed.
Table 5 on page 37 shows platform support for multi-tier archiving.
Table 5
Supported platform matrix for multi-tier archiving
Primary tier
Secondary tier
Tertiary tier
Celerra
VNX
Celerra
VNX
VNXe
Windows
Isilon
NetApp
Data Domain
Celerra
VNX
VNXe
Windows
Isilon
NetApp
Data Domain
EMC Centera
Atmos
Celerra
VNX
Atmos
none
Celerra
VNX
EMC Centera
none
NetApp
Celerra
VNX
VNXe
Windows
Isilon
NetApp
Data Domain
Celerra
VNX
VNXe
Windows
Isilon
NetApp
Data Domain
EMC Centera
Atmos
NetApp
Atmos
none
NetApp
EMC Centera
none
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 72. Data Domain is only supported natively as an NFS NAS repository.
Table 6 on page 37 shows platform support for file migration.
Table 6
Supported platform matrix for file migration
Source
Destination
Celerra
VNX
Celerra
VNX
VNXe
NetApp
Celerra
VNX
VNXe
Supported platforms
37
Deploying the Cloud Tiering Appliance
Appliance setup
The appliance arrives with the software installed. Before it may be used to perform
tasks, the appliance and the software must be properly configured:
◆
If a 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.”
The CTA software is preinstalled on every new appliance. If the software must be
reinstalled without preserving any previous information or data, follow the
instructions provided in “Performing a CD clean install” on page 89.
“Software upgrades” on page 90 provides instructions to perform a CD full
upgrade or UPG upgrade.
◆
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 43 describes configuration considerations.
◆
To install the appliance on the network, follow instructions provided in
“Configuring CTA” on page 44.
◆
If the system requires security hardening or any other special configuration,
Chapter 5, ”Cloud Tiering Appliance System Settings,”provides information for
all system settings.
Then proceed to configure the appliance for your environment as described in:
38
◆
“Deploying CTA with Celerra or VNX” on page 47
◆
“Deploying CTA with NetApp” on page 58
◆
“Deploying the CTA with a VNXe” on page 63
◆
“Deploying CTA with Isilon” on page 66
◆
“Deploying CTA with a Windows server” on page 65
◆
“Deploying the CTA with a Data Domain” on page 71
◆
“Configuring a NAS-based repository” on page 72
◆
“Deploying CTA with EMC Centera” on page 73
◆
“Deploying CTA with Atmos” on page 75
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Deploying 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
ESX 3.5 Update 3
ESXi 3.5 Update 3
ESX 4.0
ESXi 4.0
ESX 4.1
ESXi 4.1
Four virtual CPUs, 4 GB of RAM, 512 GB of disk space, 2 gigabit
virtual interfaces are reserved.
CTA/VE HA
ESX 3.5 Update 3
ESXi 3.5 Update 3
ESX 4.0
ESXi 4.0
ESX 4.1
Four virtual CPUs, 4 GB of RAM, 100 GB of disk space, 2 gigabit
virtual interfaces are reserved.
Hardware and firmware requirements for 64-bit guest operating systems are listed at
the VMware web site.
The following example shows the steps to install the CTA/VE or CTA/VE HA virtual
appliance on an ESX 3.5 Server host:
1. Unzip the 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
2. Open the Virtual Infrastructure (VI) Client.
a. To find the appliance with the most free space, consider %CPU and %Memory.
Installing the virtual edition
39
Deploying 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.
3. Import the OVF file. Instructions differ depending upon VMware version.
• For ESXi 3.5 Server, from the VI Client, select File > Virtual Appliance >
Import.
40
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Deploying the Cloud Tiering Appliance
• For ESX 4.0 Server, from the VI Client, select File > Deploy OVF Template.
4. Using the Import from file selection, type the path to the OVF file or click Browse
to locate the file.
Installing the virtual edition
41
Deploying the Cloud Tiering Appliance
5. After answering a few basic questions, the summary screen appears. Validate the
information and click Finish.
6. The import may take 3–30 minutes depending on the network connection
between the VI Client and the VMware ESX Server. Approximately 600 MB will
initially be transferred across the network.
If the CTA/VE will be configured for archiving in either of the following
deployments:
◆
from Celerra or VNX to EMC Centera
◆
from Celerra or VNX to Atmos
Configure the single set of credentials for recall with the FileMover Settings as
described in step 3 of “Adding a Celerra or VNX to the CTA configuration” on
page 48. Then run ccdsetup or acdsetup as described in “Configuring Celerra or VNX
to EMC Centera or Atmos archiving on the CTA” on page 50.
42
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Deploying the Cloud Tiering Appliance
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 EMC Centera to Celerra and VNX
◆
ACD is used to recall files from Atmos 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.
Celerra or VNX primary storage
For Celerra or VNX primary storage archived to an EMC Centera or Atmos, 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.
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 47 provides details on configuring Celerra or
VNX Data Movers.
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 EMC Centera or Atmos archiving on the
CTA” on page 50 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.
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.
CTA and CTA/VE for high availability
43
Deploying the Cloud Tiering Appliance
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 60
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, EMC Centera, or NetApp storage.
Note: 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.
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 (optional)
1. Set up the appliance:
• For a CTA or CTA-HA, connect the keyboard, monitor, and mouse to the
appliance. The serial cable provided with the CTA and a HyperTerminal on a
PC or laptop may be used. Connect the power cord and power on the
appliance.
• 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 Rainfinity setup tool appears. This tool performs basic setup tasks that are
not available through the CTA GUI.
3. Select Change File Management Appliance Password, and change the password.
4. Select Configure Date and Time to set the time zone and date for the appliance.
5. Select Configure File Management Networking. The network configuration
menu appears.
Use the menu to change interface settings or set global settings such as hostname,
domain, and DNS servers.
44
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Deploying the Cloud Tiering Appliance
Configuring the CTA network
To configure the CTA network:
1. Select option 1 from the Network Configuration menu. The File Management
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 File Management
Network Setup menu is exited.
5. Press the left arrow key to exit from the File Management Network Setup, Main
Menu. When prompted, select Yes to save your changes.
Configuring 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 Rainfinity Setup Tool (Configure Hostname, Domain and DNS
Server(s))
Hostname
= rs
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
45
Deploying the Cloud Tiering Appliance
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 appliance.
2. Type the username and password for the default account which are:
• Username: admin
• Password: rain
Tabs appear as follows:
◆
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:
• 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 users, passwords, logging, primary
servers, and secondary destination servers.
Command line interface
As an alternative to the GUI, you can use a command line interface to send
commands to the CTA 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.
◆
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 82.
◆
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.
46
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 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.
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.
◆
If migrating files from a source that is shared and exported, CTA has root access
with read/write permission to both shares and exports.
◆
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 54 describes how to set up the user.
◆
For every server, properties are configured on the CTA for:
• Control Station IP address
• NDMP username and password
“Adding a Celerra or VNX to the CTA configuration” on page 48 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.
Deploying CTA with Celerra or VNX
47
Deploying the Cloud Tiering Appliance
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.
◆
(For CIFS archiving only) The NetBIOS name of the filer.
◆
(For CIFS archiving only) Credentials for local administrator access through CIFS.
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. Click the File Servers link on the Configuration tab. The File Server List appears.
Click New.
2. On the File Server Properties page that appears, select Celerra from the Type list
box.
3. Click FileMover Settings.
The FileMover Settings page appears.
48
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Deploying the Cloud Tiering Appliance
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 52.
4. Specify the following for the Celerra Data Mover:
• Basic File Server Information — Type the Celerra name. If the Data Mover will
be involved in CIFS archiving, the NetBIOS name of the CIFS server must be
used. Do not use the fully qualified domain name (FQDN) or IP address.
Note: To identify the Celerra as a Virtual Data Mover, select the checkbox. Virtual Data
Movers support only the CIFS protocol.
• 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.
• Control Station — Type the IP address of the Celerra Control Station. This is
required for all source Celerra servers. It is not required for destination Celerra
servers. In file migration transactions, it is used to create a snapshot of the
source. It also allows the CTA to automatically perform some prerequisite
tasks for archiving as described in “Configuring automatically created DHSM
connections for file migration or archiving” on page 54. If this field is empty,
the CTA takes 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’s
group on the Celerra. “Windows domain user” on page 116 provides more
information.
Note: The CIFS credential is not required if the Celerra 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.
• Celerra 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.
Deploying CTA with Celerra or VNX
49
Deploying the Cloud Tiering Appliance
!
CAUTION
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
from a single filesystem.
• Celerra Callback Agent Settings
This option is required if archiving to an EMC Centera. For the CCD DNS
name, type the FQDN of the Celerra Callback DNS entry. Note that the FQDN
is case-sensitive.
• Atmos Callback Agent Settings
This option is required if archiving to an Atmos server. For the ACD DNS
name, type the FQDN of the Atmos Callback DNS entry. Note that the FQDN
is case-sensitive.
Note: The DNS names for the Celerra Callback agent and Atmos Callback agent must
be distinct. They cannot be the same.
• Directory Exclusion List — 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 system directories such as, etc,
lost+found, and ckpt by default.
!
CAUTION
Verify that stub files are not in the excluded directories. CTA will not access
the excluded directories and the stub files will become orphans.
5. Click Commit to define the Celerra file server.
Configuring Celerra or VNX to EMC Centera or Atmos archiving on the CTA
To archive from a Celerra or VNX to an EMC Centera or Atmos, configure the
callback service so that the CTA is in the recall path.
Configure the callback service to recall from EMC Centera
To configure recall from the EMC 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 File
Management service on the local machine.
Do you wish to configure another File Management Machine? (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.
50
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Deploying the Cloud Tiering Appliance
Configure the callback service to recall from the Atmos
To configure recall from the Atmos:
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:
By default the Atmos Callback Daemon will connect to the File
Management service on the local machine.
Do you wish to configure another File Management Machine? (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.
Configure name resolution for archiving
When the Celerra or VNX Data Mover needs to establish a connection to the
appliance to recall data from an EMC Centera or Atmos, 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. Do
not manually edit the hosts file on the CTA as this can later result in data access problems.
◆
To 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
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“Celerra Callback Agent Settings” on page 50.
– rainacd.domain is the FQDN that will be used to create the HTTP DHSM
connection described in “Atmos Callback Agent Settings” on page 50.
Deploying CTA with Celerra or VNX
51
Deploying the Cloud Tiering Appliance
c. Save the file and confirm that the Celerra or VNX Control Station is not
mounted to the Data Mover:
cd ~
umount /mnt/source
◆
To use DNS:
a. Create a DNS entry for the callback daemon that points 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.
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
52
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Deploying the Cloud Tiering Appliance
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.
For example, if the IP address is 10.10.18.1, add:
::10.10.18.1::: CTA requires no translation (UTF-8)
To specify a subnet, add:
::10.10.18.0,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 : FMA_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 3 on page 48.
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’
Deploying CTA with Celerra or VNX
53
Deploying the Cloud Tiering Appliance
• 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
Note: Once the offline attribute is set to on, it must remain on or CTA archiving will not
work.
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 an EMC Centera or an Atmos cluster, a
DHSM connection that uses the HTTP protocol needs to be configured for the
filesystem.
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 on the Celerra or VNX and the
appliance:
1. Check to see if the XML API server is running. As root user 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.
54
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Deploying the Cloud Tiering Appliance
The New User screen appears.
b. 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 52. 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 3 of
“Adding a Celerra or VNX to the CTA configuration” on page 48.
– FileMover API password as in step 2 of “Prerequisite tasks on the Celerra or
VNX Control Station for file migration or archiving” on page 52.
– DHSM connection password with the command:
fs_dhsm -connection <primary_fs> -modify <cid> -password
<new_password>
Note: This command applies when updating passwords for EMC Centera and Atmos
DHSM connections only. This does not apply for NAS repository connections.
Deploying CTA with Celerra or VNX
55
Deploying the Cloud Tiering Appliance
• For a new user on a VNX running DART 7.0:
Log in as root and select: Security > Administrators > Users > New. The New
User screen appears.
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 52.
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 3 of “Adding a Celerra or VNX to the CTA configuration” on page 48 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 48 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>
56
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Deploying the Cloud Tiering Appliance
For example: fs_dhsm -connection fileSystem1 -create -type cifs -admin
'mydomain.prv\administrator' -secondary '\\oldServer.mydomain.prv\CTA\'
-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:
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:/CTA’ -proto TCP –useRootCred True
◆
When archiving any type of data to an EMC Centera CAS or Atmos server, recall
requests will flow from the Data Mover to CTA, CTA-HA, or CTA/VE.
• To create the connection for an EMC 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>
For example: fs_dhsm -connection fileSystem1 -create -type http –secondary
'http://CCD01.mydomain.prv/fmroot' -httpPort 8000 -cgi n -user rffm
When prompted, type a password for the ‘rffm’ user.
• To create the connection for an Atmos 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>
For example: fs_dhsm -connection fileSystem1 -create -type http –secondary
'http://ACD01.mydomain.prv/fmroot' -httpPort 9000 -cgi n -user rffm
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 48.
• The FQDN for the callback daemon is used for “Celerra Callback Agent
Settings” on page 50 or “Atmos Callback Agent Settings” on page 50. The
FQDN must be distinct even if the Celerra or VNX and Atmos callback
daemons are running on the same appliance.
• The same user and password credentials are used for FileMover Settings in step 3.
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.
Deploying CTA with Celerra or VNX
57
Deploying the Cloud Tiering Appliance
◆
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 NetApp
To use the CTA with a NetApp filer, first configure the filer, and then configure the
appliance.
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 every NetApp filer, properties are configured on the CTA for the NDMP
username and password
“Adding a NetApp filer to the CTA configuration” on page 61 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:
◆
Portmap v2 RPC service (TCP port 111)
◆
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:
◆
58
All IP addresses that are used by the filer
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Deploying the Cloud Tiering Appliance
◆
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.
Direct command line access through Telnet or SSH is not used by the appliance.
However, ONTAPI access is used to send a variety of API calls and hence the
requirement for a local administrator’s credentials. If a user other than root is
specified, then 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:
◆
For NetApp filers that run Data ONTAP 7.2 or later, disable duplicate session
detection by setting:
options cifs.client.dup-detection off
Note: CTA prefers to have this option set to off. However, in cases where the network
environment requires duplicate session detection, the option can be set to name.
◆
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.
◆
To archive NFS files with Unicode names, configure the NetApp source for UTF-8
language encoding with the command:
Deploying CTA with NetApp
59
Deploying the Cloud Tiering Appliance
vol lang <vol> <language_encoding>
where language_encoding ends with .UTF-8, for example en_US.UTF-8.
vFiler configuration
To use NetApp vFilers with the CTA, ensure that:
◆
The CTA can access to 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 61.
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.
60
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Deploying the Cloud Tiering Appliance
Adding a NetApp filer to the CTA configuration
1. Click the File Server link on the Configuration tab. The File Server Properties
dialog box appears. Select NetApp from the Type list box.
2. Specify the following for the NetApp file server:
• Name — Type the NetApp filer NetBIOS name.
• IP Addresses — Type the NetApp filer 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. The IP address is added to
the list.
– To delete an existing IP address, select an IP and click Delete.
• Vfiler Host IP — If using a vFiler, 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 as a member of the domain administrator group with backup
operator privileges. If this user cannot be added to the domain administrator
group, add it to the file server's local Administrators group with backup
privileges. “Windows domain user” on page 116 provides more information
on administering domain users.
Note: For NetBIOS Domain, use the NetBIOS domain name and not the FQDN. For
example, use emc and not emc.com.
• 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.
Deploying CTA with NetApp
61
Deploying the Cloud Tiering Appliance
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.
!
CAUTION
The command will prompt for a password, but this is not the NDMP
password and is not used for the NDMP specific settings.
The NDMP password 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 NDMP password is
different from the root password. “vFiler configuration” on page 60 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.
!
CAUTION
Multiple appliances may be configured to archive data from a single
NetApp filer, but only one CTA or CTA/VE should be used to archive data
from a single filesystem.
• NetApp Local Admin — 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.
!
CAUTION
Verify that stub files are not in the excluded directories. CTA will not access
the excluded directories and the stub files will become orphans.
• NetApp FPolicy callback agents
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.
62
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Deploying the Cloud Tiering Appliance
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. Secondary agents may include
CTA-HAs.
3. Click Commit to define the NetApp filer.
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 63 provides details on
configuring a Celerra or VNX server
Adding a VNXe to the CTA configuration
To configure CTA with a VNXe server:
1. Click the File Servers link on the Configuration tab. The File Server List appears.
2. Click New. The File Server Properties page appears.
Deploying the CTA with a VNXe
63
Deploying the Cloud Tiering Appliance
3. Select VNXe from the Type list box. The VNXe Properties page appears.
4. Specify the following for the VNXe server:
• Basic File Server Information — Type the VNXe name. If the server will be
involved in CIFS archiving and migration, the NetBIOS name of the CIFS
server must be used. Do not use the fully qualified domain name (FQDN) or
IP address.
Note: File server as a VDM is not an option. A VNXe cannot be used as a VDM.
• IP Addresses — Type the VNXe 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.
• Control Station — This field is inactive because the Control Station does not
apply to VNXe.
• 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’s
group on the VNXe. “Windows domain user” on page 116 provides more
information.
• 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.
• Celerra as Source — This field is inactive because VNXe is not supported as an
archive source.
64
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Deploying the Cloud Tiering Appliance
• Celerra Callback Agent Settings — This field is inactive because VNXe is not
supported as an archive source.
• Atmos Callback Agent Settings — This field is inactive because VNXe is not
supported as an archive source.
• Directory Exclusion List — This field is inactive because VNXe is not
supported as an archive source.
5. Click Commit to define the VNXe server
Deploying CTA with a Windows server
CTA supports the Windows 2003 and 2008 servers as CIFS NAS destinations.
Configure Windows server properties on the CTA.
1. Click the File Servers link on the Configuration tab. The File Server List appears.
2. Click New. The File Server Properties page appears.
3. Select Windows from the Type list box. The Windows Properties page appears:
4. Specify the following for the Windows server:
• Name — Type a name to identify the Windows server.
• IP Addresses — Specify the IP address of 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. The IP address is added to
the list.
– To delete an existing IP address, choose an address and click Delete.
Deploying CTA with a Windows server
65
Deploying the Cloud Tiering Appliance
• 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’s
group on the Celerra or VNX. “Windows domain user” on page 116 provides
more information.
5. Click Commit to define the Windows server.
Deploying CTA with Isilon
CTA supports Isilon version 6.5.1.8 and later as a NAS destination. 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. 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.
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 116. 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. Log in to the Isilon as root. The Isilon Administration GUI appears.
66
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 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 SMB service is running.
• If the SMB service is running, the Isilon is listening on port 139. To check if the
Isilon is listening on port 139, type:
netstat -an | grep LISTEN | grep 139
• If nothing is returned, start the SMB service with the command:
isi services -a nbns enable
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 66, for example, /ifs/data/CTADir. Click OK.
– For Directory ACLs, select Do not change existing permissions.
Deploying CTA with Isilon
67
Deploying the Cloud Tiering Appliance
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 66.
– 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.
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.
68
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
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.
1. Log in to the Isilon as root. The Isilon Administration GUI appears.
2. 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.
3. 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:
Deploying CTA with Isilon
69
Deploying the Cloud Tiering Appliance
– For User name, type root.
– For Group names, type everyone.
e. Click Submit. The NFS Summary appears with the export added.
Adding an Isilon to the CTA configuration
Configure Isilon properties on the CTA.
1. Click the File Servers link on the Configuration tab. The File Server List appears.
2. Click New. The File Server Properties page appears.
3. Select Isilon from the Type list box. The Isilon Properties page appears:
4. Specify the following for the Isilon:
• Name — Type a name to identify the Isilon.
• IP Addresses — Specify the IP address of the Isilon.
– When editing an existing server, click Update to retrieve the IP address
from the DNS that is based on the server name.
70
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Deploying the Cloud Tiering Appliance
– To specify an additional IP address, click Add. The IP address is added to
the list.
– To delete an existing IP address, choose an address 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’s
group. “Windows domain user” on page 116 provides more information.
Note: If the Isilon is an NFS export destination only, this setting is not used.
5. Click Commit to define the Isilon.
Deploying the CTA with a Data Domain
CTA supports the EMC Data Domain storage product:
◆
As an NFS destination for archiving and repository migration.
◆
As a CIFS destination when a multi-protocol export is used to export the source
filesystem over NFS.
◆
For recall upon CIFS or NFS client access.
Configure Data Domain server properties on the CTA.
1. Click the File Servers link on the Configuration tab. The File Server List appears.
2. Click New. The File Server Properties page appears.
3. Select Data Domain from the Type list box. The Data Domain Properties page
appears.
Deploying the CTA with a Data Domain
71
Deploying the Cloud Tiering Appliance
4. Specify the following for Data Domain:
• Name — Type a name to identify the Data Domain server.
• IP Addresses — Type the IP address of 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. The IP address will be
added to the list.
– To delete an existing IP address, select an IP and click Delete.
5. Click Commit to define the Data Domain server.
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. Click NAS Repository and NAS group on the Configuration tab. The NAS
Repository List and NAS Group List page appears.
2. For Create NAS Repository, click New. The Create New NAS Repository dialog
box appears.
3. Specify the following for the NAS repository:
• File Server — Select a file server 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.
72
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Deploying the Cloud Tiering Appliance
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:
– “Adding a Celerra or VNX to the CTA configuration” on page 48 provides
details on configuring this setting for Celerra or VNX NAS.
– “Adding a NetApp filer to the CTA configuration” on page 61 provides
details on configuring this setting for NetApp.
– “Deploying the CTA with a VNXe” on page 63 provides details on
configuring this setting for VNXe.
– “Deploying CTA with a Windows server” on page 65 provides details on
configuring this setting for Windows.
– “Deploying CTA with Isilon” on page 66 provides details on configuring
this setting for Isilon.
• 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%.
4. Click Save Repository. The NAS Repository List reappears with the new NAS
repository listed.
Deploying CTA with EMC Centera
CTA supports the EMC Centera as an archiving destination, and as a source or
destination for repository migration. Configure the CTA for an EMC Centera.
1. Click the File Servers link on the Configuration tab. The File Server List appears.
2. Click New. The File Server Properties page appears.
Deploying CTA with EMC Centera
73
Deploying the Cloud Tiering Appliance
3. Select Centera from the Type list box. The Centera Properties page appears:
4. Specify the following for EMC Centera:
• Name — Type a name to identify the EMC Centera.
• Access Node IP — Specify the IP address of the EMC Centera access node:
– To specify an additional access node IP, click Add. The IP address is added
both to the list and as an entry in the Access Node String field. A hostname
can be used in place of an IP address to support failover if EMC Centera
replication is being used.
Note: CTA uses DNS to resolve hostnames. The /etc/hosts file should never be
manually edited.
– To delete an existing node, select a node IP and click Delete.
• Access Node String — This is automatically generated when the Access Node
IP address is added or deleted. You cannot type data directly into the field.
• Authentication
Select from one of the three choices:
– Anonymous — If selected, no security is used to authenticate with EMC
Centera.
– User profile — If selected, type the username and password of the EMC
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 EMC 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 EMC 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.
5. Click Commit to define EMC Centera.
74
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
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. Click the File Servers link on the Configuration tab. The File Server List appears.
2. Click New. The File Server Properties page appears.
3. Select Atmos from the Type list box. The Atmos Properties page appears.
4. Specify the following for the Atmos:
• Name — Type a name to identify the Atmos.
• 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 of a 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.
Deploying CTA with Atmos
75
Deploying the Cloud Tiering Appliance
• Password — Type the Shared Secret associated with the UID on the Subtenant
Information page of the Atmos.
5. Click Commit to define the Atmos.
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
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 75 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
76
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
4
Maintaining the
Cloud Tiering
Appliance
This chapter contains the following sections:
◆
◆
◆
◆
◆
◆
◆
Importing a file list archive........................................................................................... 78
Backing up the configuration ....................................................................................... 82
Maintaining the database.............................................................................................. 88
Performing a CD clean install....................................................................................... 89
Software upgrades ......................................................................................................... 90
Migrating from CTA to CTA/VE................................................................................. 93
Shutting down and restarting the appliance.............................................................. 94
Maintaining the Cloud Tiering Appliance
77
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. For the complete list of third-party software that supports this
feature go to the EMC Powerlink website:
http://Powerlink.EMC.com
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 78.
• Configures an import provider with username and password as described in
“Configuring the import provider” on page 79.
• Configures an import file task as described in “Configuring the import task”
on page 79.
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 80. 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 48
◆
“Adding a NetApp filer to the CTA configuration” on page 61
The CTA administrator gives the server names to the third-party software
administrator.
78
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Maintaining the Cloud Tiering Appliance
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.
1. Click Import Provider on the Configuration tab. The Import Provider List
appears.
2. Click New. The Provider Properties page appears.
3. Specify the following:
• Name — 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. Click Create new policy on the Policies tab. The Create Policy page appears.
2. Type a policy name for the archive policy, and click Add Rule. The Add File
Matching Criteria to Rule page appears.
Importing a file list archive
79
Maintaining the Cloud Tiering Appliance
a. To archive all files in the imported list, build an expression with a size >= 1
byte:
b. Select an archive destination. Click Save Rule. The Create Policy page
appears.
3. Click Save Policy and Schedule. The Create New Task page appears with the
name of the newly created policy listed.
4. Check Import. The page reappears:
5. Specify the following:
• Select Task Type — Click an archive task and select a policy for the task.
• Import File List
– Task Name — Type a task name.
– Providers — Select a provider defined in “Configuring the import
provider” on page 79.
• Select Archive Condition — Accept the default. The run will not occur until
the XML file list is imported and validated.
6. Click Save Task.
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. On the Schedule tab, show schedules of type Import Files.
80
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Maintaining the Cloud Tiering Appliance
2. For the import task defined in “Configuring the import task” on page 79, select
Import Files from the Status column. The Import File List page appears.
3. Browse for the XML file, or type the path.
4. To import the file, click Import.
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 79 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.
Importing a file list archive
81
Maintaining the Cloud Tiering Appliance
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. On the Schedule tab, show schedules of the type Import Files.
2. For any import file archive task defined, select Import Logs from the Status
column. The Import Logs page appears.
3. Each row corresponds to an XML file list import. On any row where the status
shows a validation error, click View 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
page 89.
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:
◆
Critical CTA system configuration data is backed up to a gzipped tar file (.tgz).
◆
The tar file is written to a destination on an EMC 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.
82
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Maintaining the Cloud Tiering Appliance
Creating a backup dump
Regular backups may be scheduled to run automatically.
1. On the Configuration tab, select Backup and Recovery Settings.
Under File Management Backup Destination, specify:
• The number of backups — The default value is 5.
• Select Destination — The EMC 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.
Backing up the configuration
83
Maintaining the Cloud Tiering Appliance
2. On the Schedule tab, select Schedule a new task.
• Under Select Task Type, select Auxiliary and Backup.
• Under Select Start Time, schedule the recurring time for backups to run.
To perform a nonrecurring backup, or to perform a backup immediately, run the
script:
/opt/rainfinity/filemanagement/bin/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. “Configuring the CTA network” on page 45 provides
details.
2. Configure the hostname, domain, and DNS servers. “Configuring the hostname,
domain, and DNS server” on page 45 provides details.
3. Configure the destination for the restored backup files (.tgz).
• If the backup files were written to an EMC Centera, configure an EMC Centera
as the destination for the restored files. “Deploying CTA with EMC Centera”
on page 73 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 72 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 83.
5. Copy DBBackup.out to /opt/rainfinity/filemanagement/conf.
84
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Maintaining the Cloud Tiering Appliance
6. On the Configuration tab in the GUI, select 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
/opt/rainfinity/filemanagement/bin/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 Atmos.
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 any
Stopping
Stopping
Stopping
Stopping
bin]# fmrestore /var/fmbackup_7.3_fm2.Sun_27-09-09_08_13.tgz
/var/fmbackup_7.3_fm2.Sun_27-09-09_08_13.tgz in /var...
overwrite your configuration and database. Are you sure?
key to continue or abort now...
FileManagement GUI...
Tomcat server
FileManagement...
File Management watchdog
[
OK
]
[
OK
]
Backing up the configuration
85
Maintaining the Cloud Tiering Appliance
Stopping File Management
[
OK
]
[
OK
]
[
[
[
[
OK
OK
OK
OK
]
]
]
]
Empty the current database...
Restore configuration and database...
Starting ntpd:
Starting FileManagement GUI...
Starting Tomcat server
Starting FileManagemnt...
Starting rslogd (already running):
Starting rslogd Monitor (already running):
Starting File Management
Starting File Management watchdog
rssystatd is running
Do you want to setup FPolicy Callback Service, y/n?
y
Warning: configuration file,
/opt/rainfinity/filemanagement/conf/fcd.xml, already exists. If you
select to remove it, all the previous configurations will be missing.
Do you wish to remove and recreate it? (y/n)y
Stopping FPolicy Server watchdog
[ OK ]
Stopping FPolicy Server
[ OK ]
Configuration file removed.
By default the FPolicy Callback Daemon will connect to the File
Management service on the local machine.
Do you wish to configure another File Management machine? (y/n)n
Configuring FPolicy callback for File Management machine(s):
127.0.0.1
Since there is only one interface, (10.10.9.56/255.255.255.192), it
will be
used to receive FPolicy callbacks from NetApp.
FPolicy Callback Daemon successfully set up.
System service, fpolicycallback, enabled.
Starting rslogd (already running):
[ OK ]
Starting rslogd Monitor (already running):
[ OK ]
Starting FPolicy Server
[ OK ]
Starting FPolicy Server watchdog
[ OK ]
NOTE: Use the rsconfig command to add newly configured File
Management IP addresses as passthrough clients on all Rainfinity GFV
nodes. Online help for the Stub Awareness Configuration provides
information on how to use the rsconfig command.
Do you want to setup Celerra Callback Service, y/n?
y
Warning: configuration file,
/opt/rainfinity/filemanagement/conf/ccd.xml, already exists. If you
select to remove it, the previous configurations will be missing.
Do you wish to remove and recreate it? (y/n)y
Stopping celerracallback Server watchdog
[ OK ]
Stopping celerracallback Server
[ OK ]
Configuration file removed.
By default the Celerra Callback Daemon will connect to the File
Management service on the local machine.
Do you wish to configure another File Management machine? (y/n)n
Configuring Celerra callback for File Management machine(s):
86
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Maintaining the Cloud Tiering Appliance
127.0.0.1
quiet is set to 0
Since there is only one interface, (10.10.9.56/255.255.255.192), it
will be
used to receive CelerraDaemon callbacks from Celerra.
Initialized encryption key from file
Celerra Callback Daemon successfully set up.
System service, celerracallback, enabled.
Starting rslogd (already running):
[ OK ]
Starting rslogd Monitor (already running):
[ OK ]
Starting celerracallback Server
[ OK ]
Starting celerracallback Server watchdog
[ OK ]
NOTE: Use the rsconfig command to add newly configured File
Management IP addresses as passthrough clients on all Rainfinity GFV
nodes. Online help for the Stub Awareness Configuration provides
information on how to use the rsconfig command.
Do you want to setup Atmos Callback Service, y/n?
y
Warning: configuration file,
/opt/rainfinity/filemanagement/conf/acd.xml, already exists. If you
select to remove it, all the previous configurations will be missing.
Do you wish to remove and recreate it? (y/n)y
Stopping atmoscallback Server watchdog
[ OK ]
Stopping atmoscallback Server
[ OK ]
Configuration file removed.
By default the Atmos Callback Daemon will connect to the File
Management service on the local machine.
Do you wish to configure another File Management machine? (y/n)n
Configuring Atmos callback for File Management machine(s):
127.0.0.1
quiet is set to 0
Since there is only one interface, (10.10.9.56/255.255.255.192), it
will be used to receive AtmosCallbackDaemon callbacks from Celerra.
Initialized encryption key from file
Atmos Callback Daemon successfully set up.
System service, atmoscallback, enabled.
Starting rslogd (already running):
[ OK ]
Starting rslogd Monitor (already running):
[ OK ]
Starting atmoscallback Server
[ OK ]
Starting atmoscallback Server watchdog
[ OK ]
NOTE: Use the rsconfig command to add newly configured File
Management IP addresses as passthrough clients on all Rainfinity GFV
nodes. Online help for the Stub Awareness Configuration provides
information on how to use the rsconfig command.
Restore Done.
Backing up the configuration
87
Maintaining the Cloud Tiering Appliance
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 CTA 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
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 CTA daemon and GUI.
2. Runs the database vacuum process.
3. Restarts the daemon and the GUI.
Database maintenance is run as a CTA task immediately or scheduled to run at a later
time.
◆
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:
88
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Maintaining the Cloud Tiering Appliance
• 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
Performing a CD clean install
The CD clean install installs all necessary packages and binary files on the hardware
for CTA or CTA-HA. To perform a clean install of CTA/VE 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 Powerlink, with all the downloads. “Where to get help” on page 13
provides information on how to access Powerlink.
The ISO file is named:
fm-7.5-##-i686.iso
where ## indicates the particular build number.
b. Burn a CD from the ISO image.
2. Insert the software recovery CD in the drive.
3. With console access to the appliance, restart the CTA.
Performing a CD clean install
89
Maintaining the Cloud Tiering Appliance
4. When prompted for installation options:
• For a CTA installation, type fm_clean.
• For a CTA-HA installation, type fmha_clean.
The appropriate packages are installed.
A restart occurs after installation completes and the login prompt appears.
5. Log in with username root and password rain.
6. Use the Rainfinity setup tool menu that appears to configure the time and
network settings.
If the CTA will be configured for Celerra or VNX to EMC Centera or Atmos
archiving, use FileMover Settings as described in step 3 of “Adding a Celerra or VNX
to the CTA configuration” on page 48. Configure the single set of credentials for recall
before running ccdsetup.sh or acdsetup.sh as described in “Configuring Celerra or
VNX to EMC Centera or Atmos archiving on the CTA” on page 50.
Software upgrades
The CTA software may be upgraded with a CD full upgrade or a UPG upgrade.
Before upgrading, review the CTA Upgrade Checklist that is available from the EMC
Powerlink website at:
http://Powerlink.EMC.com
Before upgrading from FMA versions earlier than 7.3
If a deployment includes more than one Celerra or VDM, and different FileMover
API credentials are being used for each Celerra or VDM, additional steps are required
before upgrading from FMA versions earlier than 7.3.
For version 7.2, the username and password settings for the FileMover API used in
archiving, and the Celerra Callback Agent used for recall, were separate settings on
the Celerra Properties page and could be different as shown in Figure 15 on page 90.
Figure 15
Example of Celerra property settings in FMA version 7.2
For version 7.3 or later, a simpler method of authentication verification has been
implemented. The username and password settings for the FileMover API and the
Celerra Callback Agent are the same.
90
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Maintaining the Cloud Tiering Appliance
When upgrading, the Celerra Callback Agent settings used for FMA version 7.2 are
automatically applied to FMA version 7.3 or later. If multiple usernames and
passwords were configured, only the first set will be preserved. This username and
password will be the single set of credentials for recall as described in step 3 of
“Adding a Celerra or VNX to the CTA configuration” on page 48.
To reduce any potential complication from the consolidation of these settings, before
upgrading to FMA version 7.3 or later, use FMA version 7.2 to reconfigure the
FileMover API settings and Celerra Callback Agent settings to a single set of
credentials and apply the same settings to all Celerra file servers. When choosing the
set to use, it is best to copy the Celerra Callback Agent settings to the FileMover
settings. For example, the username for FileMover Settings in Figure 15 on page 90
would be changed from dhsm_user to rffm, and the password would be changed
respectively. This same single set would be used for the FileMover and Callback
Agent settings on all Celerra file servers.
If the FileMover settings are changed, it will not be possible to archive until the
FileMover API is reconfigured with the new username and password. To re-create the
user, perform step 2 of “Prerequisite tasks on the Celerra or VNX Control Station for
file migration or archiving” on page 52.
If the Celerra Callback Agent settings are changed, it will not be possible to recall
until the DHSM connections are re-created with the new username and password.
1. Delete the DHSM connections with the option recall_policy set to no.
2. Follow the steps in “Configuring manually created DHSM connections for file
migration or archiving” on page 56. Use the single set of credentials to re-create
the connections manually.
CD full upgrade
The CD full upgrade refreshes all system software packages. If upgrading both a CTA
and a CTA-HA, upgrade the CTA first. Following an upgrade, the CTA and CTA-HA
must be running the same version of software.
1. Back up the CTA configuration with the command:
fmbackup
The process writes a backup file to
/var/fmbackup.<machine_name>.<timestamp>.tgz.
2. Copy the fmbackup file to another system.
3. To reduce the upgrade time, run the CTA vacuum process with the command:
rffm doDBMaintenance
4. Insert the software recovery CD in the drive.
5. Type reboot. The machine will restart.
Note: To abort the upgrade, power down the node, remove the CD, and reboot.
6. When the boot prompt appears:
• For CTA, type fm_upgrade.
• For CTA-HA, type fmha_upgrade.
The CD installation is fully automatic. No user interaction is required.
7. Installation is complete after about 10 minutes. Eject the CD and restart the
appliance.
Software upgrades
91
Maintaining the Cloud Tiering Appliance
The fm_upgrade process continues with a database pretest script that checks to see if
the CTA databases are consistent between the old and new releases. If the pretest
finds inconsistencies, the upgrade will exit with a "Failed to upgrade database" error
message. Contact an EMC Customer Support Representative to correct the problem
before restarting the upgrade.
UPG upgrade
This upgrade changes the core packages. The UPG upgrade is much faster than a full
CD upgrade. If upgrading both a CTA and a CTA-HA, upgrade the CTA first.
Following an upgrade, the CTA and CTA-HA must be running the same version of
software.
Note: Before upgrading, read the Upgrade Checklist document available with the Cloud
Tiering Appliance Software Downloads on Powerlink.
1. If the CTA GUI is running, log out.
2. Stop the CTA daemon with the command:
filemanagement stop
3. Download the upgrade file from Powerlink and place it in the root directory on
the appliance:
• For CTA, the file is rf_7.5-##.i686.upg.
• For CTA/VE, the file is: rfve_7.5-##.i686.upg.
where ## indicates the build number.
4. Download the RPM upgrade script, rfupgrade, from Powerlink. The same
rfupgrade script is used for CTA and CTA/VE. Place rfupgrade in the directory:
/opt/rainfinity/filemanagement/bin
5. Back up the CTA configuration with the command:
fmbackup
The process writes a backup file to
/var/fmbackup.<machine_name>.<timestamp>.tgz.
Copy the fmbackup file to another system. If needed for disaster recovery, restore
the backup with the command:
fmrestore /var/fmbackup.<machine_name>.<timestamp>.tgz
“Restoring a backup dump” on page 84 provides more details on the fmrestore
command.
6. Start the upgrade.
For CTA, type the command:
/opt/rainfinity/filemanagement/bin/rfupgrade rf_7.5-##.i686.upg
For CTA/VE, type the command:
/opt/rainfinity/filemanagement/bin/rfupgrade rfve_7.5-##.i686.upg
The upgrade process begins with a database pretest script that checks to see if the
CTA databases are consistent between the old and new releases. If the pretest
finds inconsistencies, the upgrade will exit with a "Failed to upgrade database"
error message. Contact an EMC Customer Support representative to correct the
problem before restarting the upgrade.
If no problems are encountered, the process upgrades the rpm files.
92
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Maintaining the Cloud Tiering Appliance
Note: For large databases, the upgrade will require a significant amount of time. To avoid
any disruption during the upgrade process, run the rfupgrade command in a screen
session on a server that will not be rebooted or shutdown.
If alerts were enabled before the upgrade and the rfupgrade session window is
closed during the upgrade process, the CTA alert daemon must be restarted after
the upgrade concludes. “Configuring email alerts” on page 112 provides details
on running rfhsetup to enable alerts. Following the prompts and accepting the
defaults will restart the CTA daemon.
7. Start the callbacks with the following commands:
celerracallback start
atmoscallback start
fpolicycallback start
• If using a Celerra or VNX, “Configuring Celerra or VNX to EMC Centera or
Atmos archiving on the CTA” on page 50 provides instructions on how to
configure the Celerra or VNX Callback Service for EMC Centera or Atmos.
• If using a NetApp, “Configuring NetApp archiving on the CTA” on page 60
provides instructions on how to configure the FPolicy Callback Service.
8. Wait at least 30 seconds for the FCD and CCD to register with the daemon.
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:
1. Upgrade the FMA to CTA version 7.5 or later.
2. Back up the current FMA configuration to an EMC 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
Migrating from CTA to CTA/VE
93
Maintaining the Cloud Tiering Appliance
• install a CTA/VE-HA to provide recall for the CTA/VE
Shutting down and restarting the appliance
To shut down and restart a working CTA or CTA/VE:
1. Stop all services with the commands:
filemanagement stop
celerracallback stop
atmoscallback stop
fpolicycallback stop
2. Either shut down or reboot the appliance.
• To shut down the appliance, type the command:
shutdown 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.
94
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
5
Cloud Tiering
Appliance System
Settings
This chapter contains the following sections:
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
Security hardening ......................................................................................................... 96
Configuring the GUI access method ........................................................................... 99
STIG hardening............................................................................................................... 99
LDAP client configuration .......................................................................................... 101
RADIUS and TACACS+.............................................................................................. 104
Certificate management .............................................................................................. 104
Appliance mail delivery settings ............................................................................... 105
Log settings ................................................................................................................... 106
System command accounting......................................................................................114
Windows domain user..................................................................................................116
SID translator .................................................................................................................118
Cloud Tiering Appliance System Settings
95
Cloud Tiering Appliance System Settings
Security hardening
By default, security hardening is not enabled:
To configure security hardening:
1. Start the Rainfinity 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.
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:
a. Log in to the CTA as root.
b. Type the following commands:
adduser –G rainfinity,wheel <username>
passwd <username>
96
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Cloud Tiering Appliance System Settings
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:
adduser –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 File Management Users.
3. Select Add a New User. In the File Management 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 File Management Users, a warning appears.
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.
Security hardening
97
Cloud Tiering Appliance System Settings
◆
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. The same holds true for RADIUS users.
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:
◆
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.
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.
98
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Cloud Tiering Appliance System Settings
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 Rainfinity 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).
◆
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.
Configuring the GUI access method
99
Cloud Tiering Appliance System Settings
To enable STIG hardening on the CTA and CTA-HA:
1. Start the Rainfinity 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 Rainfinity 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.
STIG hardening is disabled when the appliance hardening level is reset to the default
level as follows:
1. Start the Rainfinity setup tool, type rfhsetup.
2. Select Configure System Security.
3. Select Remove Appliance Hardening Settings.
100
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Cloud Tiering Appliance System 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.
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.
LDAP client configuration
101
Cloud Tiering Appliance System Settings
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 Rainfinity 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
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.
102
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Cloud Tiering Appliance System Settings
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 96 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 rssetup, 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, RADIUS, TACACS+) before enabling the
single security database.
2. Invoke the GUI.
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
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.
LDAP client configuration
103
Cloud Tiering Appliance System Settings
◆
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.
RADIUS and TACACS+
To configure RADIUS or TACACS+:
1. Start the Rainfinity setup tool, type rfhsetup.
2. Select Display advanced menu options.
3. Select Configure System Security.
A set of security settings options appears:
a. Configure RADIUS:
– Type the RADIUS server address
– Type 1812 as the default RADIUS port number
b. Configure TACACS+:
– Type the server address
– Type the server secret
Note: After the appliance checks with the RADIUS and TACACS+ servers for authentication, it
will, by default, check the local /etc/passwd file for authorization information.
If the user does not exist in the local file, add the user with the commands:
useradd –G rainfinity,wheel <adminusername>
useradd –G rainfinity <opsusername>
Using multiple authentication methods
If TACACS+ or LDAP, and RADIUS are configured, the CTA will attempt to
authenticate users in the following order:
◆
Credentials are checked against either the TACACS+ or the LDAP database.
◆
If TACACS+ or LDAP authentication fails, credentials are checked against the
RADIUS database.
◆
If RADIUS authentication fails, credentials are checked against the local
authentication database including the /etc/shadow, /etc/group, and
/etc/passwd information stored on the CTA.
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:
104
◆
Periodically refreshed
◆
Correctly located on the appliance
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Cloud Tiering Appliance System Settings
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 Rainfinity 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.
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 Rainfinity setup tool, type rfhsetup.
2. Select Configure Appliance Mail Configuration. 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.
Appliance mail delivery settings
105
Cloud Tiering Appliance System Settings
◆
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 Rainfinity 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 Rainfinity setup tool, type rfhsetup.
2. Select Display advanced menu options.
3. Select Configure Logging Options.
4. Select Configure Log Rotation.
5. 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, or /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.
106
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Cloud Tiering Appliance System Settings
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.
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 Rainfinity setup tool, type rfhsetup.
2. Select Display advanced menu options.
3. Select Configure Logging Options.
4. Select Configure SCP of Rotated Log Files.
5. 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 106.
• 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 106.
• 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 Rainfinity setup tool.
Log settings
107
Cloud Tiering Appliance System Settings
Alerts
A CTA can be configured to monitor various system log files and send email to alert
whenever an event occurs.
Table 8 on page 108 lists the SNMP traps for which the CTA will send a notification.
Table 8
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
The CTA alerts are classified by type:
◆
Rainfinity alerts
◆
Generic alerts
◆
Security alerts
◆
Hardware alerts
Table 9 on page 108 lists all the CTA alerts.
Table 9
CTA alerts (1 of 5)
Index
Pattern name
Description
Type
SNMP OID
001-0001 CLI login
CLI session opened
securityAlert
1.3.6.1.4.1.1139.9.3.2.0.3
001-0002 CLI logout
CLI session closed
securityAlert
1.3.6.1.4.1.1139.9.3.2.0.3
securityAlert
1.3.6.1.4.1.1139.9.3.2.0.3
securityAlert
1.3.6.1.4.1.1139.9.3.2.0.3
001-0003 Authentication failure
001-0004 Telnet alert
108
Access through Telnet has
been attempted (and the
Telnet server is running).
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Cloud Tiering Appliance System Settings
Table 9
CTA alerts (2 of 5)
Index
Pattern name
Description
Type
SNMP OID
Attempt to bind to the LDAP
server failed. This could be
due to a misconfigured
LDAP server address, or
due to a network
connectivity issue. The user
could see delays in logging
in or executing commands if
the LDAP server is
unavailable.
securityAlert
1.3.6.1.4.1.1139.9.3.2.0.3
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
genericAlert
1.3.6.1.4.1.1139.9.3.2.0.5
001-0008 SCP of Rainfinity log files Secure copy of Rainfinity log
files.
genericAlert
1.3.6.1.4.1.1139.9.3.2.0.5
001-0010 Accepted password
A user’s password has been
accepted.
securityAlert
1.3.6.1.4.1.1139.9.3.2.0.3
001-0011 Security level change
System security level has
been modified.
securityAlert
1.3.6.1.4.1.1139.9.3.2.0.3
001-0013 Certificate expiration
warning
One certificate will expire
securityAlert
soon or has already expired.
1.3.6.1.4.1.1139.9.3.2.0.3
001-0014 Failed password
A user’s password has
failed.
securityAlert
1.3.6.1.4.1.1139.9.3.2.0.3
001-0015 Password expiry change
Appliance password expiry
settings have been
changed.
genericAlert
1.3.6.1.4.1.1139.9.3.2.0.5
001-0016 Password changed
A user’s password has been
changed.
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 alert
rfhsetup script has been
launched.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
002-1001 Temperature alert
A temperature sensor
reading exceeds or drops
below a safe threshold.
hardwareAlert 1.3.6.1.4.1.1139.9.3.1.0.1
002-1002 Fan alert
A fan status has changed, or
a fan failure occurs.
hardwareAlert 1.3.6.1.4.1.1139.9.3.1.0.2
002-1003 Power supply alert
A power supply status has
changed, or a power supply
failure occurs.
hardwareAlert 1.3.6.1.4.1.1139.9.3.1.0.3
001-0005 Failed to bind to LDAP
server
001-0006 Log rotation
001-0007 SCP of system log files
Secure copy of system log
files.
Log settings
109
Cloud Tiering Appliance System Settings
Table 9
CTA alerts (3 of 5)
Index
110
Pattern name
Description
Type
SNMP OID
002-1004 Memory alert
A memory hardware status
has changed, or a memory
hardware failure occurs.
Note that if a memory
hardware failure occurs, the
system may shut down prior
to generating the alert.
hardwareAlert 1.3.6.1.4.1.1139.9.3.1.0.4
002-1005 Disk alert
A disk status has changed,
or when a disk failure
occurs. This alert is related
to the mechanical operation
of the hard disk, and does
not provide any indication of
the disk capacity utilization.
Alerts 002-1007 and
003-0001 are generated for
capacity utilization.
hardwareAlert 1.3.6.1.4.1.1139.9.3.1.0.5
002-1006 NIC alert
A network card status has
changed, or when a network
card failure (or port failure
within that network card)
occurs.
hardwareAlert 1.3.6.1.4.1.1139.9.3.1.0.6
002-1007 Capacity utilization alert
Disk capacity utilization
exceeds the preconfigured
threshold of 85%.
genericAlert
1.3.6.1.4.1.1139.9.3.2.0.5
002-1008 Timezone alert
Time zone has been
changed.
genericAlert
1.3.6.1.4.1.1139.9.3.2.0.5
002-3001 Problem starting File
Management
CTA daemon is not present.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.3
002-3002 File Management
stopped
CTA daemon has been
stopped.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
002-3003 File Management started CTA daemon has been
started.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
002-3004 Number of CCD
connections in
CLOSE_WAIT
When a Celerra or VNX
recalls files stored on an
EMC Centera, the request
passes through the CCD on
the CTA which creates a
TCP connection in
CLOSE_WAIT for a few
milliseconds. Multiple
connections in the
CLOSE_WAIT state
consume resources on the
CTA.
If this number continually
grows or does not decrease
when there is no recall
activity, reboot the CTA.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
003-0001 Partition full
Disk partition is full. This
alert is triggered when any
partition on the system
exceeds 99% utilization.
genericAlert
1.3.6.1.4.1.1139.9.3.2.0.5
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Cloud Tiering Appliance System Settings
Table 9
CTA alerts (4 of 5)
Index
Pattern name
Description
Type
SNMP OID
301-0001 File Management
enabled
CTA daemon has been
enabled.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
301-0002 File Management
disabled
CTA daemon has been
disabled.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
301-0003 FMHA appliance unable
to contact File
Management Appliance
CTA has not responded to
the 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
Archiving task has failed
because no DHSM
connection is configured on
the Celerra or VNX for the
specified secondary server.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
301-0005 Automatic creation of
DHSM connection failed
rfwalker cannot
automatically create a
DHSM connection. The
connection might need to be
manually created with the
command fs_dhsm.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
301-0006 ARCHIVE FILES
COUNT LIMIT
EXCEEDED
The maximum archive file
limit is exceeded. Once this
limit is reached, jobs to
archive additional files will
not be allowed. Existing
jobs will be allowed to
complete.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
301-0007 Could not update
capacity values
CTA is unable to obtain disk
capacity values for primary
servers. Restart the CTA
daemon. If the alert
persists, contact EMC
technical support.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
302-0001 FMHA alert (CCD)
CTA-HA is unable to contact
CTA with Celerra or VNX as
primary storage.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
302-0002 Centera had this problem
during connect
EMC Centera is not
responding to a connection
request.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
303-0001 GUI user logged in
successfully
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
303-0002 GUI login attempt failed
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
303-0003 GUI user logged out
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
304-0001 Exceeds threshold
NAS Repository exceeds
the configured threshold.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
305-0003 DX Conversion progress
Display number of DX NAS
stub files converted
periodically. Only displayed
while DX conversion is
running.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
Log settings
111
Cloud Tiering Appliance System Settings
Table 9
CTA alerts (5 of 5)
Index
Pattern name
Description
Type
SNMP OID
305-0004 DX Conversion Complete Display final number of DX
NAS stub files converted.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
701-0001 Centera alert
Unable to open connection
to EMC Centera.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
801-0001 Recall failure alert
A recall attempt from
archived storage has failed.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
901-0001 Found a duplicate Atmos
name and so this
configuration will not be
pulled down.
Duplicate Atmos name
rejected by ACD.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
901-0002 The recall username and
password does not seem
to be in sync across
FMAs and may cause
recall problems.
Password is not in sync
across multiple CTAs
configured for this ACD.
rainfinityAlert
1.3.6.1.4.1.1139.9.3.2.0.4
All alerts are listed in the Log Pattern Index of the GUI.
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.
Note: In order to generate alert email messages from the device, sendmail must be configured.
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 Rainfinity setup tool, type rfhsetup.
2. Select Configure Logging Options.
3. Select Configure Log Alerts.
4. Follow the prompts to configure:
• Typey, when asked to enable alerts.
• Specify one or more email addresses separated by a space or comma, to
receive the alerts.
112
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Cloud Tiering Appliance System Settings
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
• 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 Rainfinity 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 Rainfinity setup tool, type rfhsetup.
b. Select Configure Logging Options.
c. Select Configure Log Alerts.
d. Follow the prompts to configure:
– Select Yes, when asked to enable alerts.
– 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.
Log settings
113
Cloud Tiering Appliance System Settings
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 Rainfinity 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 Rainfinity setup tool, type rfhsetup.
2. Select Configure Logging Options
3. Select Configure System Command Accounting
4. Type y to enable system command accounting.
114
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
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
System command accounting
115
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 116
◆
“Adding an admin user to the local administrator group” on page 116
In addition, when using a CTA in a Windows 2008 domain, the domain controller
Group Policy Object (GPO) must be configured to support NT LAN Manager
(NTLM) versions 1 and 2 for CIFS authentication. “Configuring Windows 2008 for
NTLM” on page 117 provides information on how to modify the domain controller
configuration.
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 FMA 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.
2. From the Start menu, select Start > Programs > Administrative Tools >
Computer Management. The MMC application appears.
116
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Cloud Tiering Appliance System Settings
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.
Configuring Windows 2008 for NTLM
By default, the Windows 2008 domain controller supports Kerberos authentication
only and disables NTLM authentication. The CTA supports only NTLM versions 1
and 2 authentication for CIFS. Kerberos is not supported. To use a CTA in a Windows
2008 domain, confirm that the domain controller is configured for NTLM
authentication:
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.
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.
Windows domain user
117
Cloud Tiering Appliance System Settings
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. Insert the CTA Software Recovery CD in a Windows system. To start the
installation script, run the following file on the CD:
SIDUtilities<BuildNumber>.msi
where <BuildNumber> is a number similar to 8_0b15.
118
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 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
119
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.
120
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 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. Click the File Migration Settings link on the Configuration tab. The File
Migration Settings page appears.
2. To add a SID translation file:
a. Click Browse.
b. Navigate to find the XML file and choose that file.
c. Click Add to list. The new file appears on the list of Available SID Translation
Files.
Deleting a SID translation file
To delete a SID translation file:
1. Click the File Migration Settings link on the Configuration tab. The File
Migration Settings page appears with a list of previously uploaded SID
translation files.
2. Select the file to delete and click Remove from list.
SID translator
121
Cloud Tiering Appliance System Settings
122
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
A
Network Topology
Scenarios
The appendix includes the following sections:
◆
◆
Advanced network topologies ................................................................................... 124
VLAN tagging modes for the CTA/VE .................................................................... 127
Network Topology Scenarios
123
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 124 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 125 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 125 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 File Management 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.
124
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 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 File Management 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
125
Network Topology Scenarios
b. Select Configure File Management 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 File
Management 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.
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.
126
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 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 127
◆
“ESX Server virtual guest tagging” on page 128
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
127
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. Use the rfhsetup networking menu to invoke 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 as follows:
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
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.
128
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Network Topology Scenarios
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
129
Network Topology Scenarios
130
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Glossary
This glossary contains terms related to file management. Many of these terms are
used in this manual.
A
API
archiving
Atmos Callback
Service
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.
CTA callback service to support FileMover recall from Atmos.
C
Celerra Callback
Service
CTA callback service to support FileMover recall from EMC Centera.
Celerra FileMover
HSM implementation used to support offline files on the Celerra.
D
DHSM
Distributed Hierarchical Storage Management is the former name for Celerra
FileMover.
E
EMC Centera API
EMC Centera content
address
API used to write and read files from EMC Centera.
Unique key to the saved file on EMC Centera.
F
File version
FileMover API
FPolicy Callback
Daemon (FCD)
FPolicy server
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.
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
131
Glossary
FQDN
Fully qualified domain name. Used with the Celerra Callback DNS entry.
H
HSM
Hardware security module.
L
LDAP
Lightweight Directory Access Protocol
N
NAS
Network attached storage.
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
RADIUS
retention period
Remote Authentication Dial In User Service
Number of days from time of archiving that a file can not be deleted.
S
secondary storage
SNMP
STIG
stub file/offline files
Data storage that is a backup to primary storage.
Simple Network Management Protocol
Security Technical Implementation Guide
Files that appear as normal files on the primary storage but point to data content
stored on the secondary storage.
T
TACACS+
Terminal Access Controller Access-Control System Plus
V
VMotion
132
VMware VMotion technology is virtual machine mobility unique to VMware.
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Index
A
access control list 118
access node IP 74
access node string 74
acdsetup.sh 51
ACL. See access control list
admin user 96
age passwords 98
alert settings
email 112
SNMP 113
alerts 108
anonymous 74
anonymous bind 103
appliance
diagrams 31
rails 26
archive file list 78
Atmos
archiving from Celerra or VNX 50
configure in CTA GUI 75
creating connection from Celerra or VNX 57
DNS name 75
recall from 51
shared secret 76
SSL certificate 76
Atmos callback
FQDN 50
Atmos callback agent 50
VNXe 65
atmos_trusted_CAs.pem 76
atmoscallback
CTA upgrade 93
stop 89
atmoscert.pl 76
authentication 74
B
backup 84
backup dump
create 83
CTA 82
restore 84
bind policy 101
bind type 101
C
callback agent
VNXe 65
callback daemon
clean install 89
DNS entry 52
callback service 50
ccdsetup.sh 50
CD clean install 89
CD full upgrade 91
Celerra
Atmos callback agent settings 50
callback agent settings 50
CIFS specific settings 49
configure in CTA GUI 48
Control Station 49
CTA configuration 47
DART 6.0 XML API user 54
directory exclusion 50
FileMover API user 53
FileMover settings 48
FQDN 43
NDMP 49
prerequisite configuration tasks 52
prerequisites for archiving tasks 47
prerequisites for file migration tasks 47
source 49
VDM 49
Celerra callback agent
before upgrade 91
celerracallback
CTA upgrade 93
stop 89
Centera
access node IP 74
access node string 74
archiving from Celerra or VNX 50
authentication 74
configure in CTA GUI 73
creating connection from Celerra or VNX 57
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
133
Index
Certificate Authority 101
certificate authority 105
certificate management 104
chassis
CTA 27
CTA-HA 29
CIFS specific settings
Celerra or VNX 49
Isilon 71
NetApp 61
VNXe 64
Windows 66
cifs.client.dup-detection 59
clean install 89
cleartext 103
CLI login 46
client certificate 105
client configuration 101
command history 114
command line interface 46
community string 114
control station
Celerra or VNX 49
VNXe 64
convert unicode 58
create unicode 58
CTA
adding Celerra 48
adding NetApp 61
adding VNX 48
adding VNXe 63
backup 82
configure Atmos server 75
configure Centera 73
configure Data Domain server 71
configure Isilon 70
configure VNXe 63
configure Windows server 65
disable duplicate session 59
NetApp archiving 60
overview 16
restore 82
CTA daemon 92
CTA setup 45
CTA-HA
appliance details 29
CD full upgrade 91
configuring on Celerra or VNX 43
configuring on NetApp 43
UPG upgrade 92
D
DART 6.0
XML API system user 54
DART 7.0
XML API system user 56
Data Domain 71
database maintenance 88
DBMaintenance.log 88
Deploy OVF Template 41
134
DHSM
automatically create connections 54
connection password for DART 6.0 55
connection password for DART 7.0 56
enable for Data Mover 53
manually create connections 56
directory exclusion 62
Celerra or VNX 50
VNXe 65
disaster recovery 82
disks
CTA 28
CTA-HA 30
DNS entry 52, 72
DNS server 45
domain 45
DUMPFILE 84
duplicate session disable 59
E
EMC Centera
recall from 50
enable SNMP alerts 113
ESX 39
F
file list import 78
filemanagement command 92
FileMover API 53
setting before upgrading 91
setting in CTA 49
fm_clean 90
fm_upgrade 91
fmadmin 116
fmbackup 46
before upgrade 91, 92
creating backup 84
fmha_clean 90
fmha_upgrade 91
fmrestore 46, 84, 85
fmsupportdump 46
fpolicy callback agent 62
FPolicy Callback Service 60
fpolicy.enable 59
fpolicycallback
CTA upgrade 93
stop 89
fpsetup.sh 60
FQDN 43, 50
fs_dhsm 56
Fully Qualified Domain Name. See FQDN
G
global LDAP 101
graphical user interface 46
GUI 46
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
Index
H
harden appliance 96, 99, 104
high availability appliance details 29
host IP 61
hostname 45
hostname resolution 51
I
import file list 81
import file list archive 78
import file task 79
import list provider 79
import logs 82
installation 89
Isilon 70
ISO image 89
K
Kerberos 103
local admin 62
NDMP 61
prerequisites as archiving source 58
prerequisites for file migration tasks 58
source 62
unicode options 58
vFiler 60
vFiler host IP 61
network interfaces
CTA 28
CTA-HA 30
networking 45
notification host 113
O
online help 23
Open LDAP 101
ops user 97
OVF file 39
P
L
last 115
LDAP 104
advanced settings 103
authentication 101
basic settings 102
bind policy 102
global settings 101
server type 101, 102
time limits 101
Linux PAM users 97
local admin 62
local authentication database 104
log alert pattern 112
logs
alerts 108
rotating 106
M
md5sum 89
memory
CTA 28
CTA-HA 30
MSI file
SID translator utility 118
N
NAS repository 72
NAS repository list 73
nasadmin 52
NDMP 61
Celerra or VNX 49
VNXe 64
NetApp
CTA configuration 58
directory exclusion 62
FPolicy callback agent 62
PAM. See pluggable authentication module
passwords 98
PEA file 74
PEM file 76
pluggable authentication module 96
Pool Entry Authentication file 74
port detail
CTA-APL, CTA-APL-HA, FMA7-APL,
FMA7-HA-APL 34
FMA6-APL, FMA6-HA-APL, FMA5-HA-APL 34
pretest script 92
Process Acounting package 114
provider properties 79
psacct 114
R
RADIUS 104
RAID controller
CTA 28
CTA-HA 30
rails 26
rainacd.domain 51
rainccd.domain 51
Rainfinity setup tool 44
recall_policy 91
repository 72
restore
CTA 84
dumpfile 84
reverse lookup zones 52
rfalertd 114
rffm 46, 88, 91
rfhsetup 96, 99, 102, 104, 105, 106, 107, 112, 114
rflastcomm 115
rfpolicy 59
rfsnmp 114
rfupgrade 92
root logins 97
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 Getting Started Guide
135
Index
rotating logs 106
rpm files 92
rssystat 46
V
TACACS+ 104
tgz file 84
third-party software provider 78
time limits 101
TLS 103
track command history 115
track user login history 115
vacuum process 88
vFiler 60
VGT 128
VI Client 42
virtual data mover 49
VLAN tagging mode
virtual guest tagging 128
virtual switch tagging 127
VMDK file 39
VMotion 128
VMware
ESX 4.0 server 39
ESXi 3.5 server 39
VNX
Atmos callback agent settings 50
callback agent settings 50
CIFS specific settings 49
configure in CTA GUI 48
Control Station 49
CTA configuration 47
DART 7.0 XML API user 56
directory exclusion 50
FileMover API user 53
FileMover settings 48
FQDN 43
NDMP 49
prerequisite configuration tasks 52
prerequisites for archiving tasks 47
prerequisites for file migration tasks 47
source 49
VDM 49
VNXe
Atmos callback agent settings 65
callback agent settings 65
configure in CTA GUI 63
Control Station 64
directory exclusion 65
NDMP 64
prerequisites for file migration tasks 63
source 64
VST 127
U
W
uc_config 53
unicode
Celerra or VNX 52
NetApp 58
upgrade
CD full 91
FileMover API considerations 91
pretest script 92
rpm files 92
UPG 92
user profile 74
UTF-8 52
web service specific settings 75
wheel group 96
Windows 65
Windows domain user 116
S
SASL 103
scp 106
security hardening
features 96
logs 106
security ID. See SID translator
sendmail 112
serial port
CTA 28
CTA-HA 30
server type 101
shared secret 76
SID translator 118
upload tables for migration 121
simple bind 103
single security database 96
Snapsure 47
SNMP
community string 114
notification host 113
SNMP alerts 113
SNMP polling 113
SSL certificate 76
SSL X.509 certificate 76
STIG hardening 99
strengthen passwords 98
system command accounting 114
T
136
X
xlt.cfg 52
XML API
system user for DART 6.0 54
system user for DART 7.0 56
XML file for import 78
EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Version 7.5 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