EMC DiskXtender for NAS Release 3.0

EMC DiskXtender for NAS Release 3.0 Theory of Operations P/N 300-004-497 REV A02 EMC Corporation Corporate Headquarters: Hopkinton, MA 01748-9103 1-508-435-1000 www.emc.com

Copyright 2006-2007 EMC Corporation. All rights reserved. Published July, 2007 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 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 DiskXtender for NAS Release 3.0 Theory of Operations

Contents Contents... 3 Preface... 11 Chapter 1 Chapter 2 Components of the DX-NAS Solution About the EMC Celerra... 16 About the FileMover Functionality in DART... 17 About the NetApp Filer... 19 About the DX-NAS Policy Engine... 20 Recalling Migrated Files... 20 About Secondary Storage... 22 About NAS server to NAS server Migration... 22 NAS Server to Separate Host Migration... 23 NAS Server Direct to EMC Centera... 24 NAS Server to Other Storage Device Migration... 25 DX-NAS server port usage... 27 Celerra requirements... 28 NetApp filer requirements... 29 EMC Centera Recommendations... 30 Basic DX-NAS Configurations About File Migration... 32 Creating Jobs in the GUI... 32 Running Jobs... 39 Monitoring Jobs... 41 Stopping Jobs... 44 EMC DiskXtender for NAS Release 3.0 Theory of Operations 3

Contents File Recall... 45 Recalling All Files from Celerra... 45 Recalling All Files from NetApp... 48 About Orphan Files... 49 About Source Scans... 51 Orphan File Management... 52 About File Versioning... 54 Storage Reporting... 57 About the Migration Report... 57 About the Orphan File Report... 58 About the Primary Storage Report... 59 About the Secondary Storage Report... 60 About Printing Reports... 61 Error Reporting... 62 About Alerts... 62 Printing Alerts... 63 About Logs... 63 Chapter 3 Chapter 4 Chapter 5 Differences between Celerra and NetApp with DX-NAS Differences between DX-NAS on Microsoft Windows and UNIX Configuration Planning and Performance Tuning DX-NAS Configurations... 74 Two Data Movers on the Same Celerra... 74 One Data Mover on the Same Celerra... 75 Two Celerras... 76 NetApp Filer to Celerra... 77 Celerra or NetApp to DX-NAS Server Local Disk... 78 Celerra or NetApp to Network Disk Destination... 79 Celerra or NetApp to CLARiiON ATA... 79 Celerra or NetApp to FSM-Managed File System... 80 Celerra or NetApp to DiskXtender for Windows Server... 83 Celerra or NetApp Direct to EMC Centera... 84 Primary Storage Considerations... 86 Effects of Source File Size on DX-NAS... 86 Effects of Volatile Source Files on DX-NAS... 86 The Effect of the Full Readback Method... 87 Primary Storage Sizing Formula... 88 4 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Contents DX-NAS Server Local Disk Considerations... 89 Sizing Secondary Storage... 90 Effect of Source File Size on Secondary Storage... 90 Effect of Volatile Source on Secondary Storage... 90 Managing Secondary Storage with Orphan File Scans... 90 Secondary Storage Considerations... 90 Deploying Multiple DX-NAS Servers... 92 Chapter 6 Chapter 7 Chapter 8 Backup and Recovery for DX-NAS Backing Up Full Data... 94 Orphan File Management with Full Data Backups... 95 Forcing a Full Data Backup to Read Stubs in Passthrough Mode... 96 Backing up Stubs... 97 Preparing primary storage for Stub Backups on Celerra... 99 Performing Orphan File Management without Backup Synchronization... 100 Performing Orphan File Management with Backup Synchronization... 100 Backing up Secondary Storage... 102 Restoring Stubs from Backup Media... 103 About Orphan File Previews with Restored Stubs... 103 Determining Offline File Name from the GUI... 104 Determining File Attributes from the CLI... 106 Using Celerra CheckPoints with DX-NAS About Checkpoints... 110 Checkpointing Source Directories... 112 Copying Stubs from Checkpoint Directories... 112 About Checkpoints and Readback Method Override... 112 Using a Checkpoint Directory as a DX-NAS Source... 112 Checkpointing Secondary Storage... 113 Integrating DX-NAS with other Products Using Anti-Virus Software with DX-NAS... 116 Using VisualSRM... 117 Configuring VisualSRM to Work with DX-NAS... 119 Integrating with DiskXtender for Windows... 121 Integrating with DXUL File System Manager... 122 EMC DiskXtender for NAS Release 3.0 Theory of Operations 5

Contents Integrating with DXUL Storage Manager 2.9... 123 Configuring DXUL-SM with DX-NAS... 123 DXUL-SM and Celerra DX-NAS... 125 Using EMC Celerra HighRoad... 127 Chapter 9 Chapter 10 High Availability Solutions for DX-NAS High Availability on the Celerra... 131 Data Mover Failover... 131 Celerra Replication... 132 High Availability on NetApp... 133 High Availability for the DX-NAS server... 134 DX-NAS Server and Microsoft Server Clustering... 136 A DX-NAS Configuration on a Microsoft Cluster... 137 High Availability for Secondary Storage... 139 HA Secondary Storage on the Celerra... 139 HA Secondary Storage on the NetApp... 140 HA Secondary Storage on a Microsoft or Linux Cluster... 140 HA on an EMC Centera Using DX Windows... 141 HA on an EMC Centera Using FSM... 141 Disaster Tolerant Strategies for DX-NAS Disaster Tolerant Strategies... 144 About Synchronous Data Mirroring... 144 About Point-In-Time Data Mirroring... 144 About Asynchronous Data Mirroring... 145 Failing Over a Disaster Tolerant Configuration... 148 Index... 149 6 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Figures 1 EMC Celerra provides file sharing for clients... 16 2 Celerra perspective of file access on local disk arrays... 17 3 Celerra perspective on file access for a migrated or offline file... 18 4 NetApp Filer provides file sharing for clients... 19 5 DX-NAS migrating files from one NAS server to another... 23 6 DX-NAS migrating files to a remote host... 23 7 DX-NAS migrating files directly to an EMC Centera... 24 8 DX-NAS migrating files to other storage devices using FSM... 26 9 Sources and Destinations in the DX-NAS GUI... 33 10 Example of creating a job using the CLI... 35 11 The Policy Wizard combines DX-NAS elements and search behaviors 36 12 Readback methods available for the Celerra... 38 13 Migration Job Preview in the DX-NAS GUI... 40 14 Orphan Job Preview in the DX-NAS GUI... 41 15 Details of a migration job in progress... 42 16 Details of an orphan file job in progress... 43 17 Details of a source scan job in progress... 44 18 Connection string listing from Celerra... 46 19 Examples of how orphan files can be created... 50 20 Example of directory structure on secondary storage... 55 21 Example of tracking multiple versions of files on Celerra... 56 22 Example of a Migration Report... 58 23 An example of an Orphan File Report... 59 24 Alerts Tab in the DX-NAS GUI... 63 25 Two Data Movers on the Same Celerra System Configuration... 74 26 One Data Mover Configuration... 75 27 Celerra to Destination Celerra System Configuration... 76 28 NetApp Filer to Celerra Destination... 77 29 Celerra or NetApp to Local Disk Configuration... 78 30 Celerra or NetApp to Network Disk Configuration... 79 EMC DiskXtender for NAS Release 3.0 Theory of Operations 7

31 Celerra or NetApp to CLARiiON ATA Configuration... 80 32 Celerra or NetApp to FSM File System Configuration... 81 33 Celerra or NetApp to FSM to AVALONidm Configuration... 82 34 Celerra or NetApp to DiskXtender for Windows Configuration... 83 35 DX-NAS migrating files directly to an EMC Centera... 85 36 Example of full data backup of migrated files on Celerra... 95 37 Stub backup with corresponding secondary storage backup... 97 38 Example of stub backup on EMC Legato Networker... 99 39 Example of using the Windows file attributes GUI... 105 40 Example of using the CLI fileattrs command... 107 41 Example of the pfs12 file system with a WorkingData directory... 110 42 Example of the pfs12 file system with checkpoints... 111 43 DX-NAS policy set to find PDF files... 117 44 VisualSRM filter set to find PDF files... 118 45 DXUL-SM 2.9 running on different machine than DX-NAS... 124 46 DXUL-SM 2.9 running on Solaris with DX-NAS... 125 47 DX-NAS Components that need HA configuration... 130 48 A Celerra configured with a standby Data Mover for failover... 132 49 A Celerra configured with data mover failover and replication... 132 50 AutoStart Configuration... 135 51 DX-NAS installed in a two-node cluster configuration... 137 52 DX-NAS using a Celerra to provide HA for secondary storage... 140 53 FSM configured for HA using Autostart... 142 54 Example of Synchronous Mirroring with DX-NAS... 145 55 Example of Asynchronous Mirroring with DX-NAS... 147 8 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Tables Title Page 1 Ports used by DX-NAS...27 2 Support matrix for Data ONTAP...29 3 Example of information file used to track orphan files...53 4 Column definition for the Primary Storage Report...60 5 Column definition for the Primary Storage Report...60 6 Differences between Celerra and NetApp as source hosts...68 7 Differences between DX-NAS on Microsoft Windows and UNIX...69 8 Source File Size Considerations for DX-NAS migration...86 9 Source File System Volatility Considerations for DX-NAS...87 10 DX-NAS Server Disk Space Requirements on Microsoft Windows...89 11 Sizing Secondary Storage...91 12 DX-NAS and cluster specifications...136 EMC DiskXtender for NAS Release 3.0 Theory of Operations 9

10 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Preface As part of an effort to improve and enhance the performance and capabilities of its product lines, EMC periodically releases revisions of its hardware and software. Therefore, some functions described in this document may not be supported by all versions of the software or hardware currently in use. For the most up-to-date information on product features, refer to your product release notes. If a product does not function properly or does not function as described in this document, please contact your EMC representative. Audience This document is part of the EMC DiskXtender for NAS (DX-NAS), Release 3.0, documentation set, and is intended for use by trained DX-NAS system administrators. Readers of this document are expected to be familiar with the following topics: EMC Celerra administration EMC Centera administration Celerra FileMover API (formerly known as DHSM) NetApp Filer administration Solaris, Linux, or Microsoft Windows operating system configuration and management EMC DiskXtender for NAS Release 3.0 Theory of Operations 11

Preface Related documentation Related documents include: DiskXtender for NAS Release 3.0 Multiplatform Version Release Notes DiskXtender for NAS Release 3.0 Microsoft Windows Version Installation and Configuration Guide DiskXtender for NAS Release 3.0 UNIX/Linux Version Installation and Configuration Guide DiskXtender for NAS Release 3.0 Multiplatform Version Administrator s Guide Autostart Module For DiskXtender for NAS Release 3.0 Using Celerra FileMover Technical Module 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. The caution may apply to hardware or software.! IMPORTANT An important notice contains information essential to operation of the software. The important notice applies only to software. 12 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Preface 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, filenames, functions, utilities URLs, pathnames, filenames, directory names, computer names, links, groups, service keys, file systems, notifications Bold: Italic: Courier: Courier bold: Used in running (nonprocedural) text for: Names of commands, daemons, options, programs, processes, services, applications, utilities, kernels, notifications, system call, 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 Used in all text (including procedures) for: Full titles of publications referenced in text Emphasis (for example a new term) Variables Used for: System output, such as an error message or script URLs, complete paths, filenames, prompts, and syntax when shown outside of running text 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 DiskXtender for NAS Release 3.0 Theory of Operations 13

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 Comments and suggestions about our product documentation are always welcome. To provide feedback: 1. Go to: http://powerlink.emc.com 2. Click the Feedback link. 14 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Invisible Body Tag 1 Components of the DX-NAS Solution The DiskXtender File System Manager for NAS (DX-NAS) is an archiving solution that allows you to free storage space on your NAS server while maintaining NAS client access to archived files. The solution consists of integrating the following three components: An EMC Celerra or NetApp Filer The DX-NAS 3.0 policy engine Secondary storage Components of the DX-NAS Solution 15

PS0 PS1 PS2 PS3 PS4 SMB0 SMB1 Components of the DX-NAS Solution About the EMC Celerra The EMC Celerra provides Network Attached Storage (NAS) to UNIX (Solaris or Linux) and Microsoft Windows clients. Windows clients connect to the Celerra using the CIFS protocol, and UNIX clients connect using NFS. From the perspective of these clients, they are simply mapping drives to, or mounting volumes on, a specialized server in the Celerra cabinet called a Data Mover. Windows NAS Client Celerra SB0 SB1 SB2 SB3 SB4 SB5 SB6 SB7 SB8 SB9 SB10 SB11 SB12 SB13 SB14 SB15 UNIX NAS Client Figure 1 EMC Celerra provides file sharing for clients Generally, NAS clients are not concerned with the configuration of the file system on the back-end disk array nor the physical location of their files. However, from the Celerra perspective, the Data Mover manages the client connection and functions as an intermediate layer between the NAS clients and the physical storage (see Figure 2). 16 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Components of the DX-NAS Solution Celerra NAS Client Windows NAS Client UNIX Data Mover G:\file.avi /home/file.mpeg File System Back-End Disk Array Figure 2 Celerra perspective of file access on local disk arrays As with all storage solutions, there are physical limits to the amount of storage that a Celerra can manage. Consequently, functionality was included in the Data Mover operating system (called DART) to allow files to be moved from a NAS file system to another location while preserving NAS client access to those files. The DX-NAS solution exploits this functionality by moving files through the DART FileMover API. (In earlier releases of DART, this functionality was called DHSM.) About the FileMover Functionality in DART When a file is moved to another location using the Celerra File Mover API, the only change in the way the NAS client sees the file is that the file may now have an offline attribute set. However, from the perspective of the Celerra, the file has now been moved to a separate location (most often referred to as secondary storage) leaving only a small stub on the Celerra. This stub is one block (usually 8 KB) in size and contains file attribute information as About the EMC Celerra 17

Components of the DX-NAS Solution well as the location of the data portion of the file. 1 When a NAS client attempts to read a file that is offline, the Data Mover retrieves the file from the secondary location (see Figure 3). Celerra NAS Client Windows NAS Client UNIX Data Mover :\file.avi /home/file.mpeg Secondary Storage on Remote Host Shared File System File System Back-End Disk Array Figure 3 Celerra perspective on file access for a migrated or offline file 1. In some cases if additional alternate data streams are associated with a file, the stub left behind on the Celerra will use one block for each data stream. In these cases the stub could be as large as 64 KB. 18 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Components of the DX-NAS Solution About the NetApp Filer NetApp filers provide Network Attached Storage (NAS) to UNIX and Microsoft Windows clients as well, and DX-NAS can be configured to move files to secondary storage while leaving a stub on the NetApp Filer for NAS clients to access. The stub on the NetApp filer is also 8KB in size; however, DX-NAS will not migrate a file smaller than 8KB off the NetApp filer. All migrations off the NetApp filer use a readback method of Full. Note: NetApp file migration is not available for DX-NAS servers running on Solaris. Windows NAS Client NetApp UNIX NAS Client Figure 4 NetApp Filer provides file sharing for clients About the NetApp Filer 19

Components of the DX-NAS Solution About the DX-NAS Policy Engine The DX-NAS policy engine does not run on the Celerra or on the NetApp Filer. Rather, it runs on a separate host and connects to Celerra or NetApp like any other NAS client. It has four primary functions: Identifying files that need to be migrated Copying the files to the new location Creating a stub on Celerra or NetApp for continued access by NAS Clients Performing maintenance on orphaned files (i.e. stubs that no longer have a corresponding data portion on secondary storage, or files on secondary storage than no longer correspond to a stub) The DX-NAS administrator establishes criteria to identify which files should be archived or migrated to secondary storage. This criteria can be based on things like file size, file creation date, or days that have passed since the file was last accessed. To facilitate the articulation of this criteria, the DX-NAS GUI and CLI offer a preview function that allows administrators to see what files meet the defined criteria before they are actually moved. The DX-NAS policy engine is the component of the solution that copies the files. Consequently, DX-NAS must be able to access or mount locations on Celerra and NetApp as well as on any hosts where the secondary storage will be located. (DX-NAS needs to have full read and write privileges on the drives or mount points being used as secondary storage.) Recalling Migrated Files When NAS clients access migrated files on Celerra or NetApp the data portion of the files is recalled. On the Celerra, the recall is performed by the Celerra data mover. When the file was originally migrated, DX-NAS wrote the location of the data file into the stub, and the data mover uses this information to retrieve the file. Consequently, even if DX-NAS is not present, the data mover on the Celerra can retrieve the data portion of migrated files. The exception is configurations where DX-NAS is migrating files from NetApp or migrating files directly to an EMC Centera. 20 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Components of the DX-NAS Solution In the case of a Celerra recalling files directly from an EMC Centera, the Celerra data mover contacts the DX-NAS server, and the DX-NAS server retrieves the requested data from the EMC Centera and passes it back to the Celerra. (DX-NAS must be present for a Celerra to recall files that have been migrated directly to an EMC Centera.) Similarly, in all NetApp configurations, the DX-NAS server retrieves the data portion of migrated files. (DX-NAS must be present for NetApp to recall any files that have been migrated.) About the DX-NAS Policy Engine 21

Components of the DX-NAS Solution About Secondary Storage In the DX-NAS solution, secondary storage can be any file system on any host that the DX-NAS policy engine can connect to. In Microsoft Windows, DX-NAS needs to be able to access secondary storage using UNC paths. For Solaris and Linux, DX-NAS needs to be able to mount the file system on secondary storage. While there are a number of ways that DX-NAS can be implemented, secondary storage configurations generally fall into the following categories: NAS server file systems File systems on remote hosts EMC Centera Other Storage Devices About NAS server to NAS server Migration In some cases system administrators merely want to move files from expensive storage in a Celerra or NetApp cabinet to less-expensive storage in the same cabinet or on a different Celerra or NetApp Filer (see Figure 5). Expensive storage might be, for example, a file system with a RAID 5 configuration. In such a case, a system administrator might want to archive older files to a file system which is just a bunch of disks (JBOD). Using DX-NAS terminology, then, the RAID 5 file system would be the source, and the JBOD file system would be destination. 22 EMC DiskXtender for NAS Release 3.0 Theory of Operations

PS0 PS1 PS2 PS3 PS4 SM B0SM B1 SB8 SB6 SB4 Components of the DX-NAS Solution DX-NAS Source Data Mover 1 Destination Data Mover 2 SB0 SB1 SB2 SB3 SB4 SB5 SB6 SB7 SB8 SB9 SB2 SB0 PS0 PS1 PS2 PS3 PS4 SMB0 SMB1 SB9 PS0 PS1 PS2 PS3 PS4 SM B0SM B1 SB10 SB12 SB14 SB11 SB13 SB15 SB0 SB1 SB2 SB3 SB4 SB5 SB6 SB7 SB8 SB7 SB9 SB5 SB3 SB1 SB10 SB12 SB14 SB11 SB13 SB15 Figure 5 DX-NAS migrating files from one NAS server to another NAS Server to Separate Host Migration Another common DX-NAS configuration is to migrate files to a file system on a separate host. These destination file systems can be a CIFS (Windows) or an NFS (UNIX) based file system, and the only requirement is that both the DX-NAS policy engine and the Celerra (if part of the configuration) need to be able to access secondary storage using a UNC paths (Windows) or by mounting the file system on the secondary storage as an NFS share (Solaris or Linux). SB14 SB15 DX-NAS Remote Host Data Mover 1 Source SB12 SB10 SB13 SB11 NFS/CIFS Destination Celerra or NetApp Figure 6 DX-NAS migrating files to a remote host About Secondary Storage 23

PS0 PS1 PS2 PS3 PS4 SM B0SM B1 Components of the DX-NAS Solution NAS Server Direct to EMC Centera It is also possible for DX-NAS to migrate data directly to an EMC Centera (see Figure 7). This requires the Celerra to be running Dart 5.5 and the EMC Centera to be running CentraStar version 2.4, 3.0, 3.1, or higher. Any version of NetApp Ontap can migrate to the Centera. In a Celerra configuration, DX-NAS provides a web server interface to the EMC Centera. When the Celerra needs to recall a file that has been migrated to the EMC Centera, it makes an HTTP call to the DX-NAS web server which retrieves the file from the EMC Centera and supplies it to the Celerra. This configuration requires you to identify the EMC Centera secondary storage as type http in the connection string on the Celerra. For example a connection string for direct to EMC Centera migration might look like this: fs_dhsm -connection myfilesystem -create -type http -secondary http://tp2003-99.lab.local/centera -httpport 8080 -cgi y With NetApp, the DX-NAS server tracks all migrated files in its database, and DX-NAS knows if a file needs to be retrieved from the EMC Centera. Note: With EMC Centera, the DX-NAS server is part of the restore path for migrated files. Consequently, if you want to uninstall DX-NAS you will want to migrate all your files back first. For more information on how this is accomplished see Recalling All Files from Celerra on page 45. Data Mover 1 SB10 SB12 SB14 SB11 SB13 SB15 DX-NAS Source SB0 SB2 SB4 SB6 SB8 SB1 SB3 SB5 SB7 SB9 Destination (DX-NAS HTTP Server) Celerra or NetApp EMC Centera Figure 7 DX-NAS migrating files directly to an EMC Centera 24 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Components of the DX-NAS Solution NAS Server to Other Storage Device Migration It is possible to migrate files to devices such as a tape library. However the migration must be done indirectly through an intermediary product like the DiskXtender File System Manager (DX-FSM) or DiskXtender for Microsoft Windows (DX-Windows). With DX-FSM or DX-Windows, a managed file system is created where all the files placed on that file system are moved to an EMC Centera or to a supported storage device. Using DX-FSM or DX-Windows, then, DX-NAS would migrate files to the managed file system, which in turn would migrate them to the storage device. (Figure 8) The restore path would be similar: when an offline file is accessed, Celerra or DX-NAS (in the case of NetApp) would attempt to read the file from the FSM managed file system, and it would have to wait for DX-FSM or DX-Windows to retrieve the file from the About Secondary Storage 25

PS0 PS1 PS2 PS3 PS4 SMB0 SMB1 Components of the DX-NAS Solution storage device before transferring the contents of the file back to the requesting client. Windows 2000/2003 (Destination) SB8 SB10 SB12 SB14 SB9 SB11 SB13 SB15 Secondary storage SB0 SB2 SB4 SB6 SB1 SB3 SB5 SB7 Celerra or NetApp DX-NAS DiskXtender FSM, or DiskXtender for Windows Tertiary storage NAS Device MediaStor EMC Centera Drive, library, and tower devices Figure 8 DX-NAS migrating files to other storage devices using FSM 26 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Components of the DX-NAS Solution DX-NAS server port usage Table 1 on page 27 provides a list of the ports used by the DX-NAS server. Table 1 Ports used by DX-NAS Port number Description 139 NetApp callback (not configurable) Note: If DX-NAS is used to migrate files from a NetApp filer, you cannot run Samba on the same machine where the DX-NAS server is running. 445 CIFS 2049 NFS 1976 DX-NAS database 3682 EMC Centera CLI EMC Centera Viewer EMC Centera communication 8080 DX-NAS web server 11001 DX-NAS server (configurable) If you configured a fire wall on the network where the DX-NAS server and client are located, enable access to ports 1976, 11001, and 8080. DX-NAS server port usage 27

Components of the DX-NAS Solution Celerra requirements The DX-NAS software supports the following versions of data access in real time (DART): 5.6 5.4.18.3 or later 5.5.20.1 or later Note: Versions of DART that are before 5.4.18.3 are not supported. The EMC NAS Support Matrix provides more information on supported software and hardware, Fibre Channel switches, and applications for Celerra network-attached storage products. The EMC NAS Support Matrix can be viewed at http://powerlink.emc.com. 28 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Components of the DX-NAS Solution NetApp filer requirements DX-NAS release 3.0 is the first release to support NetApp filers as primary storage. The following requirements for using NetApp filers apply: DX-NAS server software installed on either Red Hat Linux or Microsoft Windows. Note: You cannot use a NetApp filer as primary storage if you are using DX-NAS server software on Solaris. Data ONTAP version 7.0.x or later installed on the NetApp filer. Table 2 on page 29 provides a support matrix for ONTAP versions that can be used with DX-NAS. Table 2 Support matrix for Data ONTAP ONTAP version File systems DX-NAS server 7.0.x CIFS only Note: ONTAP 7.0.x does not support NFS. Microsoft Windows 7.1.1 CIFS Microsoft Windows NFS Red Hat Linux 7.2.1 and 7.2.2 CIFS Microsoft Windows NFS Red Hat Linux NetApp filer requirements 29

Components of the DX-NAS Solution EMC Centera Recommendations When migrating from primary storage to an EMC Centera, consider the following recommendations: Configure the EMC Centera to use its single instance storage abilities rather than use the DX-NAS check-summing feature. Single instance storage is the ability of the Centera to recognize that the same unchanged file is being migrated more than once and only store one instance of the file. By default, this feature comes turned on regardless of the Centera model (Basic, Governance, or Compliance Use retention classes rather than retention periods. Where possible, use EMC Centera virtual pools. 30 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Invisible Body Tag 2 Basic DX-NAS Configurations The primary objective of DX-NAS is to move files from primary storage to secondary storage. To accomplish this effectively, DX-NAS needs to provide the following basic services: File Migration File Recall File Versioning Orphan File Management Storage Reporting Error Reporting Basic DX-NAS Configurations 31

Basic DX-NAS Configurations About File Migration In DX-NAS, file migration is accomplished by creating and running jobs. Jobs consist of the following elements: A Source the folder or directory on a Celerra or NetApp Filer where the policy engine looks for files that are candidates for migration. On Microsoft Windows a source is specified as a UNC path (for example, \\server2\wip). On Solaris or Linux a source is specified as a a directory or mount point (for example, /Celerra/server2/wip). A Destination the folder or directory where the file will be migrated to. The machine the DX-NAS server is running on needs to be able to access the destination in one of the following ways: As a local directory As a UNC path (for CIFS shares) As a mounted NFS share (for Solaris or Linux) A Policy a description of what files to migrate and how to migrate them. When a policy is created, match criteria is established to identify which files are candidates for migration. This match criteria can be based on a variety of file attributes like file name, file size, last modification time, etc. After jobs have been created, the DX-NAS server can be scheduled to run the jobs at times that will have the least impact on normal NAS client use. Creating Jobs in the GUI The structure of a job is implied in the layout of the DX-NAS GUI. The tabs in the GUI reflect the elements or steps necessary to create a job. 32 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Basic DX-NAS Configurations In Figure 9, the first three tabs on the user interface correspond to the elements of a job identified above and represent the first three steps in creating a job. Figure 9 Sources and Destinations in the DX-NAS GUI The fourth step--the step of actually creating a job on the Jobs tab of the GUI--consists primarily in choosing which policy the job will implement. About File Migration 33

Basic DX-NAS Configurations Jobs can also be created in the DX-NAS command line interface (CLI). Figure 10 shows an example of the commands used to create a job in the CLI. 34 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Basic DX-NAS Configurations DXNAS Ready>host -c server229.lab.local -type celerra -user dhsm_user -pass dhsm_user -i "Celerra host from CLI" Source Host Configurations: ========================== SourceHost :server229.lab.local Description=Celerra host from CLI FileMover Username=dhsm_user NAS Filer Type=EMC Celerra DART Hostname=server229.lab.local Number of sources=0 DXNAS Ready>source -c "Celerra CIFS Source" -h server229.lab.local -p \\server229.lab.local\wayne_test\win -i "Celerra CIFS source from CLI" Adding source : Celerra CIFS Source Source Configurations: ========================== Source :Celerra CIFS Source Description=Celerra CIFS source from CLI Sourcehost=server229.lab.local Source path=\\server229.lab.local\wayne_test\win DXNAS Ready>dest -c "Windows Dest for Celerra" -type fs -h TP2003-127.lab.local -p \\TP2003-127.lab.local\WinStorage -fmp \\TP2003-127.lab.local\WinStorage -i "Windows Storage for Celerra referencing a connection string." Destination Configurations: ========================== Destination :Windows Dest for Celerra Type=Disk Filesystem Offline directory=\\tp2003-127.lab.local\winstorage Description=Windows Storage for Celerra referencing a connection string. Destination path=\\tp2003-127.lab.local\winstorage Host Name=TP2003-127.lab.local DXNAS Ready>policy -c "Migrate all.mpg to File System" -type mig -s "Celerra CIFS Source" -dest Windows Dest for Celerra" -mode filemover -rb passthrough -rule "-name *.mpg" -md5 off -i "Migrate to Local Disk" Policy Configurations: ========================== Policy :Migrate all.mpg to File System Migration Source=Celerra CIFS Source Match Criteria= Use MD5 deduplication=false Policy Type=Migration Policy Readback Method=Passthrough Description=Migrate to Local Disk Destination=Windows Dest for Celerra Source Host=server229.lab.local Source Path=\\server229.lab.local\wayne_test\Win Find Match Criteria=-type f -name *.mpg Celerra Offline Directory=\\TP2003-127.lab.local\WinStorage Destination Path=\\TP2003-127.lab.local\WinStorage DXNAS Ready>job -c "Migrate MPG" -p "Migrate all.mpg to File System" -m 15 -t 0 -i "Job created from CLI" Job Configurations and Running Jobs: ========================== Job :Migrate MPG Migration Source=Celerra CIFS Source Readback Method=Passthrough Destination=Windows Dest for Celerra Time Limit (minutes)=0.0 Find Match Criteria=-type f -name *.mpg Celerra Offline Directory=\\TP2003-127.lab.local\WinStorage Match Criteria= Policy Type=Migration Policy Use MD5 deduplication=false Policy=Migrate all.mpg to File System Description=Job created from CLI Source Host=server229.lab.local Source Path=\\server229.lab.local\wayne_test\Win Number of Threads=15 Destination Path=\\TP2003-127.lab.local\WinStorage Figure 10 Example of creating a job using the CLI About File Migration 35

Basic DX-NAS Configurations About Policies There are three types of DX-NAS policies: Migration Policies--which identify files that should be migrated from primary storage to secondary storage Orphan File Policies--which identify migrated files on secondary storage that no longer have a valid corresponding stub on primary storage Source Scan Policies--which identify stubs on primary storage that no longer have valid corresponding files on secondary storage Each of these policies is created with the Policy Wizard that is launched from the Policies tab. Figure 11 The Policy Wizard combines DX-NAS elements and search behaviors 36 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Basic DX-NAS Configurations About Readback Method Polices currently support three readback methods: Full--(Celerra or NetApp) The file on secondary storage is recalled, and it replaces the stub on the source. On the Celerra, if attempts to recall data produce an error related to insufficient space or quotas, the Celerra will attempt to re-read the data using the passthrough mode. Full is the only readback method supported on NetApp. Note: Except when using a NetApp source, EMC strongly recommends that you do not use the full readback method. However, if you do use the full readback method with Celerra, then also use the checksum feature. Partial--(Celerra only) The Celerra reads the file on secondary storage and restores only the parts of the file that are being accessed by the requesting client. There is no benefit to be gained by using the partial readback method unless the application recalling the file has the ability to read file using byte offsets. Passthrough--(Celerra only) The Celerra reads the file on secondary storage and passes the data to the requesting client without affecting the stub. Note: On Celerra, the read policy override parameter for the FileMover (or DHSM) connection takes precedence over the value set in the policy. About File Migration 37

Basic DX-NAS Configurations Figure 12 illustrates how the readback methods work. Full Readback Method Client Celerra or NetApp Secondary Storage Online Passthrough Readback Method Client Celerra Only Secondary Storage Offline Partial Readback Method Client Celerra Only Secondary Storage Offline Figure 12 Readback methods available for the Celerra 38 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Basic DX-NAS Configurations About Match Criteria The behavior of a job is determined largely by the match criteria that is established in its policy. The match criteria tells the policy engine what files to search for. DX-NAS can search for files in the following ways: By name--search for files of a specific name or extension By size--search for files that are at or above a specified size By user--search for files belonging to a specified user By group--search for files belonging to a specified group By accessed date (atime)--search for files based on when they were last accessed. By change time or create time (ctime)--on NFS file systems you can search for files based on when they have had their attributes changed. On CIFS file systems, you can search for files based on when they were created. By modified date (mtime)--search for files based on when they were modified. By file permissions (perm)--search for file based on their file permissions. Note: Source file scan policies don t allow search criteria. A source scan policy examines every file on the specified source. DX-NAS will begin its search in the directory specified as the source and searches through each of its subdirectories. Every file that matches the search criteria is acted upon according to the requirements of the policy. Running Jobs When jobs are run they migrate files, delete files, or generate reports. Additionally, in the case of migration jobs and orphan files jobs you can run the jobs in preview mode to see a list of files that will be affected by the job. This allows you to fine tune your match criteria. About File Migration 39

Basic DX-NAS Configurations Jobs can be run or previewed from the CLI or the GUI, and jobs can be scheduled to run at specific times or specific intervals. Figure 13 Migration Job Preview in the DX-NAS GUI 40 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Basic DX-NAS Configurations Figure 14 Orphan Job Preview in the DX-NAS GUI Monitoring Jobs If you want to monitor the progress of jobs that are running, you can use the DX-NAS GUI. On the Jobs tab, in the tree display pane, there is a heading named Jobs in progress. All running jobs are listed in under this heading, and by clicking on one of these jobs you can see details about the running jobs. About File Migration 41

Basic DX-NAS Configurations Note: You cannot monitor job status in the DX-NAS CLI Figure 15 Details of a migration job in progress 42 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Basic DX-NAS Configurations Figure 16 Details of an orphan file job in progress About File Migration 43

Basic DX-NAS Configurations Figure 17 Details of a source scan job in progress Stopping Jobs Using the DX-NAS GUI you can stop any job that is running by clicking on the running job and then clicking the Stop button. A confirmation dialog will be displayed, and you can confirm that you want to stop the job. Jobs continue to run as long as the confirmation dialog is displayed. Jobs are not stopped until you click Yes. 44 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Basic DX-NAS Configurations File Recall When a file is migrated, the file is copied to secondary storage, and a stub is created on Celerra or NetApp. At this point the file is considered offline, and as long as the relationship between the stub and the data file is maintained, or remains valid, the file can be accessed normally. (This process is represented in Figure 19 on the Migrate line.) However, if the file is migrated with a readback method of full, then when any NAS client accesses the stub, Celerra or NetApp deletes the stub and recalls the entire file from secondary storage. This file recall is transparent to the NAS client. It may take longer to open the file, but it is seen and accessed from the same location with the same name. The only difference may be that, in Microsoft Windows, the user may see that the file has an offline icon and/or offline attribute. Note: As the information necessary to recall the file is contained in the stub on the Celerra, migrated files can be recalled even if DX-NAS is uninstalled. However, there are two exceptions: 1) If you have used DX-NAS to migrate directly to EMC Centera. If this is the case, you will need to recall all your files from the EMC Centera before uninstalling DX-NAS. 2) If you have migrated from a NetApp source. The DX-NAS server is required to recall files from secondary storage on NetApp. Recalling All Files from Celerra If you want to recall all the files from secondary storage that is, un-migrate all your files from secondary storage you can accomplish this by deleting the secondary storage connection string on the control station of the Celerra. The connection string was created on the control station when you configured the Filemover protocol. This connection string contained the information about where to retrieve data for migrated stubs. For example, connection strings might have looked something like this: fs_dhsm -connection CIFSFilesystem1 -create -type cifs -admin administrator -secondary '\\server227.lab.local\winstor' -local_server server227.lab.local fs_dhsm -connection NFSFilesystem1 -create -type nfsv3 -secondary lava2113:/solstor File Recall 45

Basic DX-NAS Configurations fs_dhsm -connection myfilesystem -create -type http -secondary http://tp2003-99.lab.local/centera -httpport 8080 -cgi y Connections created with the commands above would have been assigned connection IDs that might have looked like those listed in Figure 18. cid = 2 type = HTTP secondary = http://tp2003-99.lab.local/centera state = enabled read policy override = none write policy = full user = options = httpport=8080 cgi=y cid = 3 type = CIFS secondary = \\server227.lab.local\winstor state = enabled read policy override = none write policy = full local_server = server229.lab.local admin = lab.local\wtaylor wins = cid = 4 type = NFSV3 secondary = lava2113:/solstor state = enabled read policy override = none write policy = full options = userootcred=true proto=udp Figure 18 Connection string listing from Celerra You can force a recall of all migrated files from secondary storage by deleting the connection string using the connection ID (CID) and the -recall_policy option. 46 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Basic DX-NAS Configurations For example, to force a recall of all files from the CIFS connection shown in the example above, you could enter fs_dhsm -connection CIFSFilesystem1 -delete 8 -recall_policy yes When yes is specified with the -recall_policy option, the Celerra attempts to recall all the files on secondary storage. Depending on how many files have been migrated, this can take some time. While recalling the files the state of the connection will be Migration: ON_GOING. For example, during the time the files are being recalled, if you were to query the connection strings for the file system CIFSFilesystem1 by entering the following command fs_dhsm -connection CIFSFilesystem1 -info you might see something like this: cid = 8 type = CIFS secondary = \\server227.lab.local\winstor\ state = recallonly[ Migration: ON_GOING ] read policy override = none write policy = full local_server = server227.lab.local admin = administrator wins = When the files have all been recalled, the connection is deleted or the state of the connection changes to recallonly. cid = 8 type = CIFS secondary = \\server227.lab.local\winstor\ state = recallonly read policy override = none write policy = full local_server = server227.lab.local admin = administrator wins = You can delete recallonly policies by deleting the connection ID again while by specifying no with the -recall_policy option. For example, you could enter fs_dhsm -connection CIFSFilesystem1 -delete 8 -recall_policy no File Recall 47

Basic DX-NAS Configurations With this command, the secondary storage connection ID is permanently deleted. Note: When deleting a Centera connection string, the Celerra wants to have a user associated with the CID before it will delete the connection string using -recall_policy yes. For example, in Figure 18 above, you would need to change CID 2 to user administrator by using a command similar to this: fs_dhsm -connection myfilesystem -modify 2 -user administrator Supply the administrator password usually the password you used to log in to the control station with and the Celerra will update the connection string. Then you can delete the connection string using -recall_policy yes as described above. Recalling All Files from NetApp Unlike Celerra, NetApp does not have a built-in mechanism for recalling all migrated files. In order to recall all files you would need to write a script that opens and reads at least one byte from each file in the directory and sub-directories where you have migrated files. As all NetApp migrations are done with a recall method of full, this will have the effect of recalling all migrated files. 48 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Basic DX-NAS Configurations About Orphan Files When DX-NAS migrates a file from primary storage to secondary storage, it essentially breaks the file into two parts: 1. a stub on primary storage 2. the data portion of the file on secondary storage And whenever the relationship between the stub on primary storage and the data file on secondary storage is broken, this constitutes an orphan file. The most common way orphan files are created is when a NAS client deletes or overwrites a stub on primary storage. However, if DX-NAS has migrated the files using the full readback method, then simply reading a file will result in an orphan file being created as well. (See the Migrate and Recall lines in Figure 19.) 1 If for some reason the data file on secondary storage is deleted, then the stub file itself on primary storage is the orphan. (See the Data File Delete line in Figure 19.) 1. Even though NetApp recalls files with full readback, it technically doesn t create an orphan file because all the information needed to recall the data portion of the stub is contained in the DX-NAS database. On NetApp, then, if a migrated file is recalled and then migrated again, DX-NAS will first check to see if the stub information matches what is on secondary storage, and if it does, it simply stubs the file without migrating the data second time. About Orphan Files 49

Basic DX-NAS Configurations Primary Storage Secondary Storage Migrate Stub (Offline) Data FIle Recall X Stub (Online) Now-orphaned Data File Data File Delete Now-orphaned Stub X Data File Figure 19 Examples of how orphan files can be created In order, then, to effectively manage orphan files, three mechanisms were introduced into DX-NAS 2.0: source scans orphan file management file versioning 50 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Basic DX-NAS Configurations About Source Scans A source scan will inspect every stub or offline file on a defined source and check to see if the information regarding the data portion of the file on secondary storage is still valid. If the data does not exist on secondary storage, the source scan generates an error. If the data exists, but it doesn t have the location information, the source scan will correct the problem. Consequently, running a source scan before an orphan file scan will reduce the number of orphans found. Source Scan on Celerra with File System Backend For Celerras migrating to file system backends, a source scan performs the following steps: 1. It looks at every file on the specified source directory 2. If a file is not a stub, it skips the file. 3. If a file is a stub, the source scan checks to see if the data belonging to the stub is on secondary storage. 4. If the data is not on secondary storage, the source scan generates an alert to notify the user of the error. DX-NAS does not delete stubs or offline files from primary storage; the user needs to make the determination on whether or not to delete these files. 5. If the data is on secondary storage, the source scan looks at the info file. If the info file is wrong that is, it is not pointing to the stub on primary storage correctly the source scan corrects the information in the info file. Source Scan on NetApp with File System Backend For NetApp filers migrating to file system backends, a source scan performs the following steps: 1. It looks at every file on the specified source directory 2. If a file is online, it skips the file. 3. If a file is offline, the source scan looks in the DX-NAS database to see where the data should be on secondary storage. 4. If the data is not on secondary storage, the source scan generates an alert to notify the user of the error. DX-NAS does not delete stubs or offline files from primary storage; the user needs to make the determination on whether or not to delete these files. About Orphan Files 51

Basic DX-NAS Configurations 5. If the data is on secondary storage, the source scan looks up the information on the offline file in the DX-NAS database. If the information in the database is wrong that is, it is not pointing to the stub on primary storage correctly the source scan corrects the information in the DX-NAS database. Source Scan on Celerra or NetApp with EMC Centera Backend For Celerras or NetApp filers migrating to an EMC Centera, a source scan performs the following steps: 1. It looks at every file on the specified source directory 2. If a file is not a stub or is online, it skips the file. 3. If a file is a stub or is offline, the source scan looks in the DX-NAS database to see if the clip is in the EMC Centera. 4. If the clip is not in the EMC Centera, the source scan generates an alert to notify the user of the error. DX-NAS does not delete stubs or offline files from primary storage; the user needs to make the determination on whether or not to delete these files. 5. If the clip is in the EMC Centera, the source scan looks at the metadata stored with the clip and then checks for any updates to that metadata in the DX-NAS database. If any of the metadata is incorrect, the source scan corrects it. Orphan File Management During an orphan file preview or orphan file job, DX-NAS looks at the information file associated with each file that has been migrated. If the stub identified in the information file is missing, then orphan tags are inserted into the file. If on a subsequent orphan file scan the stub is located (because a stub was restored or because network access to a a source is re-established) then the orphan tags are removed from the corresponding information file. 52 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Basic DX-NAS Configurations Table 3 shows an example of how an information file looks. The orphan tags have been bolded. <entry> <path>\\server227.lab.local\wayne1\win\backup\depth\one\twopillars.tif</path> <filehandle>4294967328-27092-1139594692</filehandle> <datafile>40c743bfcb740</datafile> </entry> <entry> <path>\\server227.lab.local\wayne1\win\backup\twopillars.tif</path> <filehandle>4294967328-27090-1139593996</filehandle> <datafile>40c743bfcb740</datafile> <orphan>43ecd610:5</orphan> </entry> Table 3 Example of information file used to track orphan files Orphan File Job on Celerra with File System Backend For Celerras migrating to file system backends, an orphan file job performs the following steps: 1. It looks at every file on the specified destination directory 2. When it finds a migrated data file, it looks for the info file. 3. If the info file does not exist, it creates one and flags the migrated data file as an orphan. 4. If the info file exists, it goes to the source to see if the information in the info file matches the information in the stub. 5. If the information matches, it clears any orphan flags that might have been in the info file. (Effectively, at this point, the migrated data file is no longer an orphan.) 6. If the information is not valid, an orphan flag is placed in the migrated data file s info file, and the migrated data file is now an orphan. 7. If a migrated data file is an orphan and has been previously flagged for later deletion, the delete later criteria is evaluated and acted upon accordingly. Orphan File Job on NetApp with File System Backend For NetApp filers migrating to file system backends, an orphan file job performs the following steps: 1. It looks at every file on the specified destination directory 2. When it finds a migrated data file, it looks it looks in the DX-NAS database for information regarding the corresponding offline file. About Orphan Files 53

Basic DX-NAS Configurations 3. If there is no database entry for the migrated data file, it creates one and flags the migrated data file as an orphan. 4. If the database entry exists, it goes to the source to see if the information in the database matches the information in the offline file. 5. If the information matches, it clears any orphan flags that might have been set. (Effectively, at this point, the migrated data file is no longer an orphan.) 6. If the information is not valid, an orphan flag is placed in the migrated data file s database entry, and the migrated data file is now an orphan. 7. If a migrated data file is an orphan and has been previously flagged for later deletion, the delete later criteria is evaluated and acted upon accordingly. Orphan File Job on Celerra or NetApp with EMC Centera Backend For Celerras or NetApp filers migrating to an EMC Centera, an orphan file job performs the following steps: 1. It looks at every clip in the storage pool where DX-NAS has migrated data. 2. It gets stub or offline file location information for the clip from the DX-NAS database. 3. If the stub or offline file location information is valid, it clears any orphan flags that might have been in the info file. (Effectively, at this point, the migrated data file is no longer an orphan.) 4. If the stub or offline file information is not valid, an orphan flag is placed in the clip s database entry, and the clip is now an orphan. 5. If a clip is an orphan and has been previously flagged for later deletion, the delete later criteria is evaluated and acted upon accordingly. Note: The deletion of clips on the Centera will take place according to whatever retention settings are in effect. About File Versioning DX-NAS manages the data files on secondary storage in a directory structure that is derived from the inode of the source file. The data file 54 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Basic DX-NAS Configurations itself is contained in a leaf node which has the same name as the file handle on the Celerra. As an example, Figure 20 illustrates that DX-NAS has been configured to migrate files to a destination directory named MoreStor. When migrating the first file DX-NAS begins by creating a directory that reflects the source host name, in this case server227. On each subsequent file migration from that source host, DX-NAS will create a series of three directories that are based on the inode of the source file. Then it creates a directory that has the same name as the Celerra file handle and puts the data file in this directory. Figure 20 Example of directory structure on secondary storage When two files with the same inode are migrated, there will be two or more data files in a leaf directory. This situation can happen when a program on the NAS client updates the file without changing an inode. If this case, after the update, when the file is re-migrated to secondary storage, the data file is place in the same directory as the previous data file. A multiple data file situation could also occur in a situation where the source file is deleted, and then the Celerra re-uses the inode. In this case two files will exist in the leaf directory, but they may not be related in any way. About Orphan Files 55

Basic DX-NAS Configurations To help sort out which files are which on secondary storage, DX-NAS 2.0 implemented file versioning. Basically this consists of maintaining and information file (named infofile) about each file in the secondary source directory. This info file contains information such as what the name of the file was on the Celerra. Figure 21 illustrates how an info file works. Primary Storage Secondary Storage Migrate Recall Infofile Online Now orphaned Data File Re-Migrate Offline Data File Still orphaned Data File Infofile Figure 21 Example of tracking multiple versions of files on Celerra 56 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Basic DX-NAS Configurations Storage Reporting The DX-NAS GUI provides reports on the migration activity of the system. There are four types of reports: Migration Report which displays the amount of storage that has been migrated Orphan File Report which displays the orphan files that have been deleted Primary Storage Report which displays the storage capacity of primary storage Secondary Storage Report which displays the storage capacity of secondary storage About the Migration Report The migration report provides data about the number of files and the amount of storage that has been migrated. By default the report displays as a bar chart and shows migration activity for the past seven days. Storage Reporting 57

Basic DX-NAS Configurations Figure 22 Example of a Migration Report About the Orphan File Report Whenever an orphan file job deletes files, the data is collected for an orphan file report. This report will tell you how many orphan files have been deleted from secondary storage and how much space these files took up. 58 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Basic DX-NAS Configurations By default the report displays as a bar chart and shows delete activity for the past seven days. Figure 23 An example of an Orphan File Report About the Primary Storage Report The primary storage report displays information on the amount of storage used and the amount of storage available on each DX-NAS source. Storage Reporting 59

Basic DX-NAS Configurations The primary storage report is displayed as a table with the following columns: Table 4 Column definition for the Primary Storage Report Column Source Source Path Total Bytes Bytes free Percent (%) used Description The DX-NAS source. This is the name the DX-NAS source object was given when it was created. For Microsoft Windows, a UNC path displaying the hostname and file system where the source files are located. For Solaris and Linux, the path (on the machine where the DX-NAS server is running) where the source is mounted. The total number of bytes available on the source file system. The number bytes the Celerra is reporting as being free on the file system. The percentage of total available bytes that are in use on the source file system. About the Secondary Storage Report Table 5 The secondary storage report displays information on the amount of storage used and the amount of storage available on each DX-NAS destination. The secondary storage report is displayed as a table with the following columns: Column definition for the Primary Storage Report Column Destination Destination Path Total Bytes Bytes free Percent (%) used Description The DX-NAS destination. This is the name the DX-NAS destination object was given when it was created. For Microsoft Windows, a UNC path displaying the hostname and file system where the destination files are located. For Solaris and Linux, the path (on the machine where the DX-NAS server is running) where the destination is mounted. The total number of bytes available on the secondary storage host. The number bytes the secondary storage host is reporting as being free on the volume where the secondary storage directory resides. The percentage of total available bytes that are in use on the volume where the secondary storage directory resides. 60 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Basic DX-NAS Configurations About Printing Reports The print function in the DX-NAS GUI only prints what is visible on the screen. Even if there are scroll bars on the screen indicating that there is additional information not shown, only the visible portion is printed. If the migration report is large (that is, the software has been running for many days), it can be more efficient to export the report as a CSV file and then use a spreadsheet or a word processing program to print the file. About Printing Reports 61

Basic DX-NAS Configurations Error Reporting DX-NAS provides information to users two ways: Alerts Logs About Alerts All alerts are related to job activity. If you have no jobs or schedules configured, you will never have any alerts. Messages about the status of jobs are displayed on the Alerts tab of the DX-NAS GUI (see Figure 24). There are three types of alerts: Information these alerts are displayed when jobs are start, complete, or stop. Warning these alerts are displayed when minor problems occur. For example, a source scan job will report orphan stubs (that have the data file missing on secondary storage) as warnings. Critical these alerts are displayed when migration fails or when scheduled jobs can not be run. Alerts are only reported in the DX-NAS GUI. 62 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Basic DX-NAS Configurations Figure 24 Alerts Tab in the DX-NAS GUI Printing Alerts The print function only prints what is visible on the screen. Consequently, if you have a large number of alerts to print, it can be more efficient to export the alerts as a CSV file and then use a spreadsheet or a word processing program to print the file. About Logs DX-NAS uses the following log files: Microsoft Windows DXNASLog.log any messages or errors that are written to the default output stream are captured in this log. In troubleshooting situations, examine this log first. Error Reporting 63

Basic DX-NAS Configurations DXNASServerLog_x.log any messages or errors generated by the DX-NAS server process are written to this log. The value x is a number that is incremented. Note: On Microsoft Windows, if you installed using the defaults, the server logs can be found at C:\Program Files\EMC\DXNAS\Server\logs. Solaris and Linux DXNASLog.log any messages or errors that are written to the default output stream are captured in this log. In troubleshooting situations, examine this log first. DXNASServerLog_x.log any messages or errors generated by the DX-NAS server process are written to this log. The value x is a number that is incremented. Note: On Solaris and Linux, if you installed using the defaults, the server logs can be found at /opt/emc/dxnas/server/logs Setting the Server Log Level Using the DX-NAS GUI you can set how much information gets written to the log files. The following logging levels can be set, and generally, these levels are listed in order from least information to most information: Emergency--report information only when a process becomes unusable. This is the least verbose logging. Alert--report information when action is required and where lack of action could result in the process becoming unusable Critical--report conditions that prevent the proper operation of a process Error--report conditions which cause an operation to fail Warning--report conditions that warn of impending operation failures Notice--report normal, but significant, conditions Informational--report informational messages only Debug--reports most server activity. This is the most verbose logging. 64 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Basic DX-NAS Configurations Note: Selecting one of the more verbose logging levels can cause your log files to grow in size very quickly, and large log files can adversely affect system performance. It is strongly suggested that you run in Debug, Informational, and Notice modes only long enough to complete troubleshooting or testing. Afterwards, copy the log files to a different location, and reset the logs by starting and stopping the DX-NAS console server. Resetting DX-NAS Logs on Microsoft Windows To reset DX-NAS logs on Microsoft Windows: 1. Log in to the host where you installed the DX-NAS server as the same user that installed DX-NAS. 2. Choose Start > All Programs > Administrative Tools > Services 3. In the Services panel, right-click EMC DX NAS Database and click Stop. The Stop Other Services dialog appears informing you that this will stop the DX-NAS server as well. Note: If you prefer to use the Windows command line, you can enter net stop EMC DX NAS Database 4. Click Yes. The services stop. 5. If you want to make copies of the log files, change to the folder C:\Program Files\EMC\DXNAS\Server\logs, and copy DXNASLog.log and DXNASServerLog_x.log to a different location. 6. In the services panel, right-click EMC DX NAS Server and click Start. Note: If you prefer to use the windows command line, you can enter net start EMC DX NAS Server The logs are now reset. Error Reporting 65

Basic DX-NAS Configurations Resetting DX-NAS Logs on Solaris and Linux To reset DX-NAS logs on Solaris and Linux: 1. Log in to the host where you installed the DX-NAS server as root. 2. Enter cd /opt/emc/dxnas/server/database If you installed the DX-NAS server in a location other than the default location, use that location. 3. Enter./DxnasServer stop 4. Enter./DxnasDb stop 5. If you want to make copies of the log files, change to the subdirectory /opt/emc/dxnas/server/logs, and copy DXNASLog.logand ConsoleServerLog to a different location. 6. Enter /opt/emc/dxnas/server/bin/dxnasdb start 7. Enter /opt/emc/dxnas/server/bin/dxnasserver start The logs are now reset. 66 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Invisible Body Tag 3 Differences between Celerra and NetApp with DX-NAS There are some differences in the way the DX-NAS works with a source host that is an EMC Celerra and a source host that is a NetApp filer. Table 6 identifies the areas where the UNIX/Linux and Microsoft Windows versions of DX-NAS differ. Differences between Celerra and NetApp with DX-NAS 67

Differences between Celerra and NetApp with DX-NAS Table 6 Differences between Celerra and NetApp as source hosts Difference EMC Celerra Source Host NetApp Filer Source Host DX-NAS Server Platforms Supported Microsoft Windows Linux Solaris Microsoft Windows Linux Migration Mechanisms Filemover API Must be configured on the control station of Celerra Recall Mechanism Celerra recalls files from secondary storage. DX-NAS is not in recall path unless migrating direct to Centera. NetApp APIs Configured automatically by DX-NAS DX-NAS moves file back from secondary storage. DX-NAS is always in the data path. Number of DX-NAS Servers Supported Multiple DX-NAS servers can connect to one Celerra. Multiple Celerras can be serviced by one DX-NAS server. Only one DX-NAS server can connect to a NetApp filer Multiple NetApp filers can be serviced by one DX-NAS server Readback Methods Full Partial Passthrough Orphan Creation Delete source stub Access a file that was migrated with Full readback method Modify a migrated file Full Delete source stub 68 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Invisible Body Tag 4 Differences between DX-NAS on Microsoft Windows and UNIX The UNIX/Linux and Microsoft Windows versions for DX-NAS are created from the same source code, and the differences between the two products exist either because of operating system differences or file system differences. Table 7 identifies the areas where the UNIX/Linux and Microsoft Windows versions of DX-NAS differ. Table 7 Differences between DX-NAS on Microsoft Windows and UNIX Difference Microsoft Windows UNIX/Linux NetApp Filer Support Configure NetApp filers as source hosts Configure NetApp filers as source hosts on Linux NetApp filers not supported as source hosts on Solaris Default Installation Location Default Location of Uninstall Program C:\Program Files\EMC\ DXNAS C:\Program Files\EMC\DXNAS\ _uninst\uninstallwin32.exe or, you can uninstall by choosing DXNAS from the Add or Remove Programs dialog /opt/emc/dxnas/ /opt/emc/dxnas/_uninstall/ uninstaller.bin Differences between DX-NAS on Microsoft Windows and UNIX 69

Differences between DX-NAS on Microsoft Windows and UNIX Table 7 Differences between DX-NAS on Microsoft Windows and UNIX Difference Microsoft Windows UNIX/Linux Default Location of GUI and CLI Starting and Stopping DX-NAS Server and Database Start > All Programs > EMC DX NAS > DX NAS Client GUI or C:\Program Files\EMC\DXNAS\ Client\runClientGUI.exe Start > All Programs > EMC DX NAS > DX NAS Client CLI or C:\Program Files\EMC\DXNAS\ Client\runClientCLI.exe Starting In the Services dialog, right-click EMC DX NAS Server and click Start. or, on the command line enter net start EMC DXNAS Server Note: Starting the server also starts the database. /opt/emc/dxnas/client/bin/ runclientgui.bin /opt/emc/dxnas/client/bin/ runclientcli.bin Starting 1. /opt/emc/dxnas/server/ bin/dxnasdb start 2. /opt/emc/dxnas/server/ bin/dxnasserver start Stopping In the Services dialog, right-click EMC DX NAS Database and click Stop. or, on the command line, enter net stop EMC DXNAS Database Note: Stopping the database also stops the server. Stopping 1. /opt/emc/dxnas/server/ bin/dxnasserver stop 2. /opt/emc/dxnas/server/ bin/dxnasdb stop Source and Destination Paths UNC Paths Mount Points 70 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Differences between DX-NAS on Microsoft Windows and UNIX Table 7 Differences between DX-NAS on Microsoft Windows and UNIX Difference Microsoft Windows UNIX/Linux Logs C:\Program Files\EMC\DXNAS\ Server\logs\DXNASServerLog_x.log C:\Program Files\EMC\DXNAS\ Server\logs\DXNASLog.log /opt/emc/dxnas/server/logs/ DXNASServerLog_x.log /opt/emc/dxnas/server/logs /DXNASlog.log File and Path Length Limitations The Celerra implementation of CIFS limits path and filename length to approximately 256 characters The path and filename length limit on Linux/Unix is 2000 characters. Note: However, if you are using NetApp, the path limit is 495 characters. Offline File Indicators Microsoft Windows Explorer displays an offline icon and an offline attribute on files that have been migrated. Fileattributes dialog in GUI or command in CLI None Fileattributes dialog in GUI or command in CLI 71

Differences between DX-NAS on Microsoft Windows and UNIX 72 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Invisible Body Tag 5 Configuration Planning and Performance Tuning This section discusses DX-NAS configuration planning and performance optimizations. The topics covered are: DX-NAS Configurations on page 74 Primary Storage Considerations on page 86 Deploying Multiple DX-NAS Servers on page 92 Sizing Secondary Storage on page 90 Configuration Planning and Performance Tuning 73

RPS INPUT RPS INPUT Status Select Function E P O N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Status Select Level To UPS B B A To UPS A Configuration Planning and Performance Tuning DX-NAS Configurations DX-NAS can be configured in a number of ways. However, the following configurations are the most common: Two Data Movers on the Same Celerra on page 74 One Data Mover on the Same Celerra on page 75 Two Celerras on page 76 Celerra or NetApp to DX-NAS Server Local Disk on page 78 Celerra or NetApp to Network Disk Destination on page 79 Celerra or NetApp to CLARiiON ATA on page 79 Celerra or NetApp to FSM-Managed File System on page 80 Celerra or NetApp to DiskXtender for Windows Server on page 83 Two Data Movers on the Same Celerra Figure 25 illustrates a configuration in which two Data Movers are used for primary storage and secondary storage, respectively. Source Data Mover 1 DX-NAS Destination Data Mover 2 Celerra Figure 25 Two Data Movers on the Same Celerra System Configuration 74 EMC DiskXtender for NAS Release 3.0 Theory of Operations

RPS INPUT RPS INPUT Status Select Function E P O N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Status Select Level To UPS B B A To UPS A Configuration Planning and Performance Tuning One Data Mover on the Same Celerra Figure 26 illustrates a configuration in which one Data Mover provides both primary and secondary storage. DX-NAS Source Data Mover 1 Destination Celerra Figure 26 One Data Mover Configuration DX-NAS Configurations 75

PS0 PS1 PS2 PS3 PS4 SM B0SM B1 PS0 PS1 PS2 PS3 PS4 SM B0SM B1 Configuration Planning and Performance Tuning Two Celerras Figure 27 illustrates a configuration in which two Celerra systems are used: one for primary storage and the other for secondary storage. DX-NAS Source Data Mover 1 SB10 SB12 SB14 SB11 SB13 SB15 Destination Data Mover 2 SB0 SB1 SB0 SB1 SB2 SB3 SB2 SB3 SB4 SB5 SB4 SB6 SB7 SB8 SB9 SB10 SB12 SB14 SB11 SB13 SB15 SB5 SB6 SB7 SB8 SB9 Celerra 1 Celerra 2 Figure 27 Celerra to Destination Celerra System Configuration 76 EMC DiskXtender for NAS Release 3.0 Theory of Operations

PS0 PS1 PS2 PS3 PS4 SM B0SM B1 PS0 PS1 PS2 PS3 PS4 SM B0SM B1 Configuration Planning and Performance Tuning NetApp Filer to Celerra Figure 28 illustrates a configuration in which a NetAp[p filer is used for primary storage and a Celerra is used for secondary storage. DX-NAS Source SB14 SB12 Destination SB0 SB15 SB1 SB0 SB2 SB3 SB4 SB5 SB6 SB7 SB8 SB9 SB10 SB11 SB13 SB14 SB12 SB15 SB13 SB1 SB2 SB3 SB4 SB5 SB6 SB7 SB8 SB9 SB10 SB11 NetApp Celerra Figure 28 NetApp Filer to Celerra Destination DX-NAS Configurations 77

PS0 PS1 PS2 PS3 PS4 SM B0SM B1 PS0 PS1 PS2 PS3 PS4 SM B0SM B1 Configuration Planning and Performance Tuning Celerra or NetApp to DX-NAS Server Local Disk Figure 29 illustrates a configuration in which a local disk on the machine that runs the DX-NAS server is designated as secondary storage. NetApp DX-NAS Source SB14 Destination SB0 SB1 SB2 SB0 SB1 SB2 SB3 SB4 SB5 SB6 SB7 SB8 SB9 SB12 SB15 SB13 SB14 SB10 SB15 SB11 SB3 SB4 SB5 SB6 SB7 SB8 SB9 SB10 SB11 SB12 SB13 Celerra Figure 29 Celerra or NetApp to Local Disk Configuration 78 EMC DiskXtender for NAS Release 3.0 Theory of Operations

PS0 PS1 PS2 PS3 PS4 SM B0SM B1 PS0 PS1 PS2 PS3 PS4 SM B0SM B1 Configuration Planning and Performance Tuning Celerra or NetApp to Network Disk Destination Figure 30 illustrates a configuration in which secondary storage is a CIFS or NFS share that has been set up on a remote host. NetApp DX-NAS Source SB14 SB12 Destination NFS/CIFS SB0 SB1 SB2 SB3 SB4 SB5 SB0 SB15 SB1 SB6 SB6 SB7 SB8 SB9 SB13 SB14 SB10 SB15 SB11 SB8 SB4 SB2 SB9 SB5 SB3 SB7 SB10 SB11 SB12 SB13 Celerra Remote Host Figure 30 Celerra or NetApp to Network Disk Configuration Celerra or NetApp to CLARiiON ATA Figure 31 illustrates a configuration in which a CLARiiON ATA provides secondary storage by way of the DX-NAS server. Because a CLARiiON disk is presented to the operating system as if it were a local disk, this configuration is similar to the Celerra or NetApp to DX-NAS Server Local Disk configuration. In fact, this is how the configuration appears to the Celerra. The CLARiiON configuration, however, has the advantage of storing the migrated files in a physical location that is separate from the machine where the DX-NAS server is running. In this way it is similar to the Celerra or NetApp to Network Disk Destination configuration, except that the connection to the CLARiiON is fibre channel and not CIFS or NFS across a network. DX-NAS Configurations 79

PS0 PS1 PS2 PS3 PS4 SM B0SM B1 PS0 PS1 PS2 PS3 PS4 SM B0SM B1 Configuration Planning and Performance Tuning. NetApp DX-NAS Source SB14 SB14 SB12 SB10 SB15 SB15 Destination SB2 SB0 SB1 SB2 SB3 SB4 SB5 SB6 SB7 SB8 SB9 SB13 SB11 SB3 SB4 SB5 SB6 SB7 SB8 SB9 SB10 SB11 SB12 SB13 SB0 SB1 Clariion ATA Celerra Figure 31 Celerra or NetApp to CLARiiON ATA Configuration Celerra or NetApp to FSM-Managed File System Figure 32 illustrates a Solaris or Linux configuration in which secondary storage is an FSM-managed file system. After DX-NAS has migrated the files to the managed file system, the files are further migrated (by FSM) to tertiary storage. This storage can be traditional network accessible storage (NFS, FTP), an EMC Centera, or tape and optical devices supported by EMC AVALONidm 3.2. Figure 33 illustrates how AVALONidm works with FSM. 80 EMC DiskXtender for NAS Release 3.0 Theory of Operations

PS0 PS1 PS2 PS3 PS4 SM B0SM B1 PS0 PS1 PS2 PS3 PS4 SM B0SM B1 Configuration Planning and Performance Tuning NetApp DX-NAS Source SB14 SB15 Secondary storage SB14 SB12 Destination (FSM-managed destination fs) SB2 SB3 SB4 SB5 SB6 SB8 SB10 SB12 SB15 SB13 SB7 SB9 SB11 SB13 SB4 SB0 SB5 SB1 NFS FTP SB0 SB1 SB2 SB3 SB6 SB7 SB8 SB9 SB10 SB11 Centera DXSM Celerra Tertiary storage Figure 32 Celerra or NetApp to FSM File System Configuration DX-NAS Configurations 81

PS0 PS1 PS2 PS3 PS4 SM B0SM B1 PS0 PS1 PS2 PS3 PS4 SM B0SM B1 Configuration Planning and Performance Tuning NetApp DX-NAS Secondary storage Source Destination (FSM-managed destination fs) SB0 SB1 SB2 SB3 SB4 SB5 SB0 SB1 SB6 SB7 SB2 SB14 SB3 SB8 SB9 SB4 SB5 SB10 SB6 SB7 SB8 SB9 SB14 SB12 SB10 SB15 SB15 SB13 SB11 SB11 SB12 SB13 Celerra Tertiary storage AVALONidm Disk Tape DVD Centera Figure 33 Celerra or NetApp to FSM to AVALONidm Configuration Note: AVALONidm 3.2 is a Solaris and Linux only configuration 82 EMC DiskXtender for NAS Release 3.0 Theory of Operations

PS0 PS1 PS2 PS3 PS4 SM B0SM B1 PS0 PS1 PS2 PS3 PS4 SM B0SM B1 Configuration Planning and Performance Tuning Celerra or NetApp to DiskXtender for Windows Server Figure 34 illustrates a Microsoft Windows configuration in which secondary storage is a DiskXtender for Windows managed file system. This provides comparable functionality to FSM-managed secondary storage in the Microsoft Windows environment. NetApp Windows 2000/2003 (Destination) Source DX-Windows SB14 SB12 SB15 SB0 SB1 SB2 SB3 SB13 SB4 SB5 SB4 SB5 SB6 SB6 SB2 SB8 SB9 SB10 SB11 SB7 SB12 SB13 SB8 SB9 SB0 SB14 SB15 SB10 SB11 SB7 SB3 SB1 Celerra NAS Device Tertiary storage MediaStor Centera Drive, library, and tower devices Figure 34 Celerra or NetApp to DiskXtender for Windows Configuration DX-NAS Configurations 83

Configuration Planning and Performance Tuning File Retention Limitations When using DiskXtender 2000 or DiskXtender FSM with DX-NAS, you must not set retention on the files that are to be migrated from DX-NAS secondary storage to tertiary storage. Doing so may result in one or more of the following problems with DX-NAS: Migration fails. Orphan file management may not function properly. File version may not function properly. Celerra or NetApp Direct to EMC Centera It is also possible for DX-NAS to migrate data directly to an EMC Centera (see Figure 35). In this configuration, DX-NAS provides a web server interface to the EMC Centera. When the Celerra needs to recall a file that has been migrated to the EMC Centera, it makes an HTTP call to the DX-NAS web server which retrieves the file from the EMC Centera and supplies it to the Celerra. Note: In this configuration, the DX-NAS server is part of the restore path for migrated files. Consequently, if you want to uninstall DX-NAS you will want to migrate all your files back first. For more information on how this is accomplished Recalling All Files from Celerra on page 45. 84 EMC DiskXtender for NAS Release 3.0 Theory of Operations

PS0 PS1 PS2 PS3 PS4 SM B0SM B1 PS0 PS1 PS2 PS3 PS4 SM B0SM B1 Configuration Planning and Performance Tuning NetApp DX-NAS Source SB14 SB8 SB10 SB12 SB14 Destination (DX-NAS HTTP Server) SB0 SB1 SB2 SB3 SB4 SB5 SB0 SB1 SB6 SB2 SB3 SB4 SB5 SB6 SB7 SB15 SB7 SB9 SB11 SB13 SB15 SB8 SB9 SB10 SB11 SB12 SB13 Celerra EMC Centera Figure 35 DX-NAS migrating files directly to an EMC Centera DX-NAS Configurations 85

Configuration Planning and Performance Tuning Primary Storage Considerations There are a number of ways to organize source files on primary storage, and the layout of the source directories will vary from customer to customer. However, when planning DX-NAS migrations the two main issue to consider are How large are your source files? How often do you your source files change? Effects of Source File Size on DX-NAS Table 8 If the files on your primary storage are predominantly small (e.g. less than 1 MB in size) you will find that migration speeds (as measured in Bytes/Second) will be significantly slower and that the management overhead on secondary storage (as measure in bytes used) will be significantly higher. Conversely, with large source files, your migration throughput will be higher and the secondary storage overhead will be a smaller percentage of the space used. Source File Size Considerations for DX-NAS migration Predominant Size of Files Effect on DX-NAS Small Lower MB/Sec migration throughput Higher percentage of space used for secondary storage management overhead Possible inode shortage on secondary storage when using NFS. Large Higher MB/Sec migration throughput Negligible percentage of space used for secondary storage management overhead Effects of Volatile Source Files on DX-NAS When planning your DX-NAS migrations, you should also take into account how often the files you will be migrating change. If the files are relatively static, then the files will usually only need to be migrated once 1 and will take up a fairly predictable amount of secondary storage. If the files you are migrating are dynamic and changing frequently, the new files will need to be continually migrated, and you will 86 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Configuration Planning and Performance Tuning consume more secondary storage because DX-NAS keeps versions of previously migrated files. Consequently, with dynamic source file systems, you will want to perform orphan file scans of secondary storage on a regular basis. Table 9 Source File System Volatility Considerations for DX-NAS Volatility Effect on DX-NAS Files change frequently More files will be migrating because each changed file will need to be remigrated More space will be consumed on secondary storage because by default each version of the file is saved Regular orphan file scans of secondary storage will be required Files change infrequently Files migrate only once Secondary storage usage more predictable The Effect of the Full Readback Method You need to be careful if you are migrating files using the Full readback method. With this readback method, anytime the file is accessed the entire file is retrieved from secondary storage. On the Celerra this action creates an orphaned file on secondary storage, results in an increased amount of storage being used on the Celerra, and may require the recalled file to be re-migrated (if your policy did not use the checksum for uniqueness option). By itself the full readback method is not a problem, but it can lead to a problematic situation. For example, assume that you migrate a large number of files to secondary storage using the full readback method. Then, with the space that has become available, you add more source files. Then you migrate these files off to secondary storage, and add more source files. This creates a situation where you have more storage on secondary storage than you have room for on primary storage. Consequently, if an application or user, accesses a large number of migrated files you could exhaust primary storage space. Note: If attempts to recall data produce an error related to insufficient space or quotas, the Celerra will attempt to re-read the data using the passthrough mode. 1. On Celerra this is accomplished by setting up policies using the Passthrough readback method or by using checksum for uniqueness. Primary Storage Considerations 87

Configuration Planning and Performance Tuning Primary Storage Sizing Formula When determining the size of primary storage in gigabytes (GB), use the following general formula: ( A 8192) + ( B ( C + 10) ) --------------------------------------------------------------------- 1024 where A is the total number of files to be created or stored on primary storage B the average amount of new data in bytes that will likely be created on primary storage on a daily basis C the last access age in days at which point DX-NAS will migrate files to secondary storage. 88 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Configuration Planning and Performance Tuning DX-NAS Server Local Disk Considerations The disk space requirements for DX-NAS vary depending on the components installed and on the number of files you plan on migrating. Table 10 provides the available space required on the disk where the DX-NAS server is installed. Table 10 DX-NAS Server Disk Space Requirements on Microsoft Windows Hardware Available Disk Space Required Disk space 5 GB for the DX-NAS installation 1.5 additional gigabytes for every one million files to be migrated from a NetApp filer or migrated directly to EMC Centera DX-NAS Server Local Disk Considerations 89

Configuration Planning and Performance Tuning Sizing Secondary Storage When determining the size of secondary storage there are three main considerations: Size of source files Volatility of source files Orphan file management Effect of Source File Size on Secondary Storage When DX-NAS migrates files to secondary storage, in addition to the space used by the migrated file, there is additional space and inodes (if you re using NFS) that are consumed as file management overhead. If you have large files (greater than 10 MB) this overhead is negligible. However, with small files this overhead can become a significant percentage of the storage that is used. Effect of Volatile Source on Secondary Storage If a file that has been migrated off primary storage is updated or changed by a NAS client, the file stub that was created when the file was migrated is deleted and a complete file is written in its place. This creates an orphan file on secondary storage, and, if the new file is re-migrated, the orphan file is preserved. Consequently, if the files on primary storage are being changed or updated frequently, it can result in multiple versions of migrated files being stored on secondary storage. Managing Secondary Storage with Orphan File Scans To alleviate this problem you can run orphan file scan jobs on secondary storage which can be configured to delete earlier versions of a migrated file. Secondary Storage Considerations When determining the size of secondary storage, you need to consider the type of secondary storage you will be using. Table 11 shows how much space to provide on secondary storage. 90 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Configuration Planning and Performance Tuning Table 11 Sizing Secondary Storage Type of Secondary Storage Celerra to secondary storage on a file system NetApp to secondary storage on a file system Celerra or NetApp to secondary storage on an EMC Centera Primary to Secondary Storage Ration 1:1.5 For every megabyte of storage you want to migrate from the Celerra provide 1.5 times that amount of space on secondary storage. (This allows for infofiles and other DX-NAS overhead.) 1:1 1:1 Sizing Secondary Storage 91

Configuration Planning and Performance Tuning Deploying Multiple DX-NAS Servers If you are planning to have DX-NAS migrate a large number of files or a large amount of data, you may want to consider using two or more DX-NAS servers to migrate files. Each DX-NAS server would run on its own machine and would need to be configured to migrate non-overlapping sets of files. When determining the effectiveness of deploying additional DX-NAS servers, the primary consideration is network bandwidth. If, for example, running migration jobs on a single DX-NAS server saturates your network, you will not gain any performance adding another DX-NAS server. However, if one DX-NAS server does not saturate the network then you can improve total migration performance by adding additional servers. The amount of network traffic generated by the DX-NAS server, as well as the effect of this traffic on the network, will vary from site to site. However, estimates of DX-NAS load indicate that two DX-NAS servers can saturate a typical Gigabit Ethernet network. If you are using DX-NAS with NetApp, be aware that only one DX-NAS server should register with the NetApp filer. A single DX-NAS server can register with more than one NetApp filer, but only on DX-NAS server should running against any NetApp filer at any given time. 92 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Invisible Body Tag 6 Backup and Recovery for DX-NAS When files are migrated off primary storage they are essentially split into two parts: the stubs, which remain on primary storage, and the data files, which are copied to secondary storage. Consequently, backup and recovery strategies need to address how both of these parts are backed up. With primary storage, then, there are two principle approaches to back up: Full data backup Stub backup Backup and Recovery for DX-NAS 93

Backup and Recovery for DX-NAS Backing Up Full Data When you perform a full data backup, your backup software can treat stubs as if they were the normal files, and, depending on the readback method that was set when the files were migrated, primary storage does one of two things: Pulls the files back from secondary storage Passes the files data through the stub, leaving the stub intact on primary storage. On Netapp, or on Celerra if files are migrated with the Full readback method, a backup of primary storage will effectively unmigrate them, leaving you with complete files on primary storage and orphan files on secondary storage. In most cases, this defeats the purpose of using DX-NAS. Consequently, it is strongly suggested that on Celerra you do not migrate files using the Full readback method. On Celerra, if files are migrated with the Passthrough option, the backup software reads the files data as it is passed through the stub. This pass through backup is illustrated in Figure 36. Also on Celerra, during a restore, the Celerra overwrites the stub on primary storage with the full data file, creating an orphan file on secondary storage. Backing up the full data of stubs that have been migrated with the Passthrough option has the following advantages: Entire data file resides on the backup media Migrated file remains off line on primary storage and does not need to be migrated again. However, full data backups have the following disadvantages: Longer back up times as the data for the stub file needs to be retrieved from secondary storage Increased network traffic as the data for the stub files are retrieved form secondary storage. Orphan files are created on secondary storage during restore. 94 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Backup and Recovery for DX-NAS Backup Media Celerra Secondary Storage Backup Data FIle Stub (offline with passthrough readback method) Data FIle Restore Data FIle replaces stub Now-orphaned Data File GEN-000083 Figure 36 Example of full data backup of migrated files on Celerra Orphan File Management with Full Data Backups When a full data file is restored from the backup media to primary storage, it overwrites the stub on primary storage. This now allows NAS clients to access the restored file, but it creates an orphan file on secondary storage (see Figure 36). However, because the full data file is now on primary storage, and because the full data file still resides on the backup media, orphan files can be deleted immediately from secondary storage. With full data backups there is no need to keep orphan files. Backing Up Full Data 95

Backup and Recovery for DX-NAS Forcing a Full Data Backup to Read Stubs in Passthrough Mode On Celerra, even if you have migrated files off primary storage using the Full readback method, it is still possible to back up the stubs in pass-through mode, thus obviating the need to remigrate the files. To do this enter the following command on your Celerra s control station: fs_dhsm -modify <filesystem> -backup passthrough where filesystem is the name of primary storage file system that you want to back up as passthrough This command will override the readback mode that was specified when the file was migrated. 96 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Backup and Recovery for DX-NAS Backing up Stubs When you back up the stubs of migrated files, the backup application needs to be able to detect that the stubs represent offline files. If the backup application determines that a file is offline (i.e. it is a stub) it can then backup just the 8 KB stub without recalling the file from secondary storage. However, as shown in Figure 37, in most cases you will want to make sure that the data portions of the stubs on secondary storage are also backed up. Backup Media Celerra Secondary Storage Backup Media Backup Stub Stub Data FIle Data FIle Restore Stub Data FIle Figure 37 Stub backup with corresponding secondary storage backup GEN 000084 Backing up Stubs 97

Backup and Recovery for DX-NAS However, with NetApp you also need to back up the DX-NAS database. Fig illustrates this relationship. DX-NAS DB Backup Media NetApp Secondary Storage Backup Media Backup Stu Ile Restore Stub Data FIle DX-NAS DB Also, if you are migrating from either NetApp or Celerra to an EMC Centera, you will also need to backup the DX-NAS database at the same time you back up y our secondary storage. Note: While backing up the DX-NAS database and secondary storage, you should not run any migration jobs. Backing up stubs from primary storage that has DX-NAS migrated files has the following advantages: Shorter backup times as only the 8 KB stubs need to be backed up (instead of the entire file) Reduced network traffic However, stub backups have the following disadvantages: Only the stub resides on the backup media. The data portion of the stub that resides on secondary storage needs to be backed up separately. 98 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Backup and Recovery for DX-NAS If orphan file management policies are in use, the stub backup and the secondary storage backup need to be kept synchronized Stub only backups are only available using the CIFS protocol. You can not perform a stub only backup on primary storage file systems that are only exported as NFS. Preparing primary storage for Stub Backups on Celerra In order to back up just the stubs on a Celerra you need to enable offline back up on the file system you are backing up. To do this enter the following command on your Celerra s control station: fs_dhsm -modify <filesystem> -backup offline where filesystem is the name of primary storage file system that you want to back up as passthrough With offline back up enabled, backup applications like EMC Legato NetWorker will only back up the stub without recalling data from secondary storage. Figure 38 shows an example of how the stub file takes up very little space on the backup media. Figure 38 Example of stub backup on EMC Legato Networker Backing up Stubs 99

Backup and Recovery for DX-NAS Performing Orphan File Management without Backup Synchronization As long as you are not deleting files on secondary storage, you do not need to keep the stub back up and the secondary storage backup synchronized. And, if the stubs on primary storage are relatively static--that is, they are not modified or deleted very often this may be a viable approach to keeping the stubs and data files synchronized. However, if the stubs are relatively dynamic that is, they are changed or deleted often then the sheer number of orphan files being created will require you to do some sort of orphan file management, which in turn will require you to keep the stub back up and data file back up synchronized. One possible way to avoid the need for synchronization in this scenario is to create orphan file policies that delete files only after the source file backup has expired. For example, consider a company that backs up their primary storage stubs on a weekly basis and keeps those backups for 18 months before re-using the backup media. This company could create orphan file policies that flag orphan files to be deleted18 months after they are migrated. In this way, not only can any restored stub find its data portion, but also no orphan files are retained beyond the point where a backed up stub might need it. Performing Orphan File Management with Backup Synchronization When a stub is deleted off primary storage, an orphan file is created on secondary storage. If the stub file is never going to be restored, then the orphan file on secondary storage is most likely wasting space. However, if the stub is restored from backup at some point in the future, then the file will no longer be an orphan and the stub will ned to be able to retrieve its data. Consequently, in an environment where you may be creating and deleting lots of orphan files, you will need a backup process that ensures that for any backed up stub that is restored there will either be a corresponding data portion to the stub or you can restore the correct corresponding data portion from the secondary storage backup. 100 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Backup and Recovery for DX-NAS The rules to follow, then, in planning your back up process are: 1. Always backup secondary storage before running orphan file jobs 2. Set your orphan file policies to Delete later. Either set the orphan policy to delay deleting until sometime after the Orphan date, or set the policy to delay for a period of time after the Migrate date that is longer than the total time it takes to fully back up secondary storage and complete the orphan file scan. Orphan file jobs that use Delete later policies only delete files the next time the orphan file job runs. Consequently, if you always back up secondary storage before running orphan file jobs, all orphan files will be preserved on backup media before they are deleted. Backing up Stubs 101

Backup and Recovery for DX-NAS Backing up Secondary Storage There are no stubs or special files on DX-NAS secondary storage. Secondary storage is just files on a file system, and you back it up as you would any other file system. 102 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Backup and Recovery for DX-NAS Restoring Stubs from Backup Media A typical file stub restore procedure might look like this: 1. Restore the stub from backup media, noting the date the file was backed up 2. Using DX-NAS, run a source scan on the directories where you restored stubs. 3. If the newly restored stub can t access its correct data portion on secondary storage, query the stub using the GUI File Attributes dialog or the fileattrs command (see Determining Offline File Name from the GUI on page 104 or Determining File Attributes from the CLI on page 106) 4. Restore the file identified in the offline path using the back up of secondary storage that immediately follows the date when the stub was backed up. Note: Secondary storage files need to be restored to their previous location which is identified by the offline path. Restoring files to different locations will result in the stubs being unable to access their data. About Orphan File Previews with Restored Stubs Orphan file jobs and orphan file previews do two things: Insert orphan tags into the information files of files that are found to be orphans Remove orphan tags from the information files of files that are no longer orphans When an orphan file preview evaluates a file it first looks to see if there are orphan tags in the file s information file. If there are, it reports the file as an orphan. Then the orphan file preview goes and looks for the source file identified in the file s information file. If source file, or stub, exists then the orphan tags are removed. If the file does not exist, then the orphan tags are insert or left as they are. Consequently, after restoring file stubs, you will need to run an orphan file preview twice before it displays the correct number of orphan files.determining What Files to Restore from Backup Media When files are deleted or lost on primary storage, users or administrators will generally identify the files that need to be restored by their original file name. Restoring Stubs from Backup Media 103

Backup and Recovery for DX-NAS However, files migrated by DX-NAS are stored on secondary storage with different names. Consequently, if a stub file stops working (that is, primary storage can no longer retrieve the data portion of the file from secondary storage), it may not be readily apparent which file on secondary needs to be restored. You can determine which file needs to be restored to secondary storage by using the File Attributes dialog in the DX-NAS GUI or the fileattrs command in the DX-NAS CLI. Determining Offline File Name from the GUI To determine the name of the file that contains the data portion of a stub file, using the File Attributes command dialog: 1. Start the DX-NAS GUI. 1. Using the menu bar choose Tools > File Attributes. 2. Using the list box in the Source Host field, choose primary storage that contains the stub whose data portion you want to locate on secondary storage. 3. Click Filename. 4. In the Filename field, enter the name of the file (including full path) that you want to get the attributes for. Note: With Solaris and Linux, the path is entered relative to the host where the DX-NAS server is running. For Microsoft Windows, it must be a full UNC path. 5. Click GO. The GUI queries primary storage and returns the information. The location of the data portion of the stub file is listed in the Offline Path field. In many cases the offline path will not completely display in the field. If this is the case, you move the cursor over the field and the mouse over help will display the full off line path. 104 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Backup and Recovery for DX-NAS Figure 39 Example of using the Windows file attributes GUI Restoring Stubs from Backup Media 105

Backup and Recovery for DX-NAS Determining File Attributes from the CLI To determine the name of the file that contains the data portion of a stub file, using the fileattrs command: 1. Start the DX-NAS CLI. 2. Enter the following command: fileattrs -l -h <hostname> -fn <pathname> where hostname is the name of primary storage where the file you want to query resides. On Windows this should be specified with a fully qualified domain name. pathname is the full path and filename of the file you want to query. For Windows this is a UNC path with a fully qualified domain name for the server. The location of the data portion of the stub file is listed in the Offline Path field. As the offline path may be longer than the CLI display width, the offline path can be found in the line immediately below the Offline path= label and may wrap to additional lines as necessary. 106 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Backup and Recovery for DX-NAS DXNAS Ready>fileattrs -l -h server229.lab.local -fn "\\server229.lab.local\wayne_test\win\moby Dick 1 a.rtf" ========================== File attributes for: \\server229.lab.local\wayne_test\win\mobydick.rtf File Status = OFFLINE Offline Path = cifs://tp2003-127.lab.local/winstorage/server229.lab.local/0/0/0/1 4/4294967336-340-1169668404-427cde1357ac7 Readback Method = Passthrough ATIME = 1170343345 MTIME = 1169662632 CTIME = 1169676179 File Size = 1337965 File Handle = 4294967336-340-1169668404 ========================== DXNAS Ready>fileattrs -l -h server229.lab.local -fh 4294967336-335-1169668399 ========================== File attributes for: 4294967336-335-1169668399 File Status = OFFLINE Offline Path = cifs://tp2003-127.lab.local/winstorage/server229.lab.local/0/0/0/f /4294967336-335-1169668399-427cde06f1d8d Readback Method = Passthrough ATIME = 1170343338 MTIME = 1169662561 CTIME = 1169676868 File Size = 4919020 File Handle = 4294967336-335-1169668399 ========================== DXNAS Ready>fileattrs -l -h server229 -fn /Celerra229/Unix/level2/galaxy.jpg ========================== File attributes for: /Celerra229/Unix/level2/galaxy.jpg File Status = OFFLINE Offline Path = nfs://lava2114/work/sparcstor/server229/0/0/0/24/4294967336-36-116 9668101-427cd9e181540 Readback Method = Full ATIME = 1169663980 MTIME = 1169662561 CTIME = 1171318264 File Size = 4919020 File Handle = 4294967336-36-1169668101 ========================== Figure 40 Example of using the CLI fileattrs command Restoring Stubs from Backup Media 107

Backup and Recovery for DX-NAS 108 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Invisible Body Tag 7 Using Celerra CheckPoints with DX-NAS Using the SnapSure technology of the Celerra you can create point-in-time snapshots, or checkpoints, of a file system. This allows you to have data from earlier time periods including any migrated file stubs readily accessible from the Celerra. DX-NAS is fully compatible with checkpoints; however, there are few few considerations to be aware of. Using Celerra CheckPoints with DX-NAS 109

Using Celerra CheckPoints with DX-NAS About Checkpoints As an overview of how checkpoints work on the Celerra, consider the following example. Imagine that on the Celerra you create a file system named pfs12, and you export it as CIFS and NFS. Then you create a directory called WorkingData and copy a set of files to it. Using Microsoft Windows Explorer, then, you would see a directory structure similar to that shown in Figure 41. Figure 41 Example of the pfs12 file system with a WorkingData directory Because pfs12 was exported as NFS, the Celerra created a.etc and a lost+found directory on the file system. Then the WorkingData directory and some text files were added to the file system. Now imagine that you create a checkpoint of the file system by issuing the fs_ckpt command on the control station of the Celerra. This command will create a hidden directory called.ckpt and it will create a directory that is named using the date and time the checkpoint was created. Below this data and time directory, the 110 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Using Celerra CheckPoints with DX-NAS Celerra presents a read-only copy of the pfs12 file system as of the date the snap shot was created (see Figure 42). Figure 42 Example of the pfs12 file system with checkpoints Any stubs of migrated files that were present on the pfs12 file system will be available in the checkpoint, and they will still be able to recall their data from secondary storage if the data portion is still available on secondary storage. 1 The key point to remember about checkpoints is that all the files under the.ckpt directory are read-only which can affect the behavior of DX-NAS. 1. After the checkpoint has been created, a file stub can be deleted from the file system causing an orphan file to be created which could be deleted by an orphan file job. If an orphan job delete the data portion of the file, the check point version of the stub will no longer be able to access it. About Checkpoints 111

Using Celerra CheckPoints with DX-NAS Checkpointing Source Directories Checkpointing a file system that contains DX-NAS source directories has no effect on the performance of DX-NAS. However, if you access files from the checkpoint directories, there are few things to keep in mind. Copying Stubs from Checkpoint Directories You can copy any stub from a checkpoint directory back to the your file system, but be aware that the complete file will be copied. If you want to copy just the stub back to the file system you need a special tool like EMCopy. About Checkpoints and Readback Method Override If files stubs were migrated with the Full readback method, then the Celerra will encounter an error when it tries to restore the file to the read-only checkpoint directory. If this occurs, then the Celerra overrides the readback method and retrieves the information using Pass through mode. Using a Checkpoint Directory as a DX-NAS Source Because checkpoints are a frozen copy of how the file system looked in the past, it is possible that some of your file stubs may get deleted in the present. If this happens, an orphan file job running on secondary storage might flag the data portion of these stub s as orphans. However, if the orphan file job does not immediately deleted the orphans, you can fix the orphan files by running a source file scan on your checkpoint directories. If a source scan runs through the checkpoint directories it will look at each stub and see where the data portion is located. It will then go find the information file that corresponds to that data file and write in the checkpointed stub as a parent of the data file and then removes the orphan tags. By running a source scan on checkpointed directories you can ensure that data files referenced by stubs have their orphan tags removed and are not inadvertently deleted by orphan file jobs. 112 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Using Celerra CheckPoints with DX-NAS Checkpointing Secondary Storage It is possible to migrate files from source directories on the Celerra to secondary storage that is also on the Celerra. This storage could be on another Celerra, another Data Mover, another file system managed by the same Data Mover, or a different directory on the same file system. Because, in this scenario, the secondary storage exists on the Celerra it is possible to checkpoint the secondary storage. This would allow you to copy any data files from a (read-only) checkpoint directory back to the principal (read-write) file system. Note: As the.ckpt subdirectory and all its children are read-only, you can not choose one of these directories as a destination. Consequently, you can not run an orphan file job on a checkpointed directory. Checkpointing Secondary Storage 113

Using Celerra CheckPoints with DX-NAS 114 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Invisible Body Tag 8 Integrating DX-NAS with other Products Currently DX-NAS can be integrated with other products. This chapter contains the following information: Using Anti-Virus Software with DX-NAS on page 116 Using VisualSRM on page 117 Integrating with DiskXtender for Windows on page 121 Integrating with DXUL File System Manager on page 122 Integrating with DXUL Storage Manager 2.9 on page 123 Using EMC Celerra HighRoad on page 127 Integrating DX-NAS with other Products 115

Integrating DX-NAS with other Products Using Anti-Virus Software with DX-NAS DX-NAS does not distinguish between applications that open files. Consequently, DX-NAS treats anti-virus open requests the same as any other file open request. On Celerra, it is strongly recommended that you use the Celerra AntiVirus Agent (CAVA), which understands file stubs and which allows anti-virus file access to be pass through. If you do not use CAVA on Celerra, your anti-virus software may or may not recognize stubbed files, and it will open them using the readback method specified when DX-NAS migrated them. On NetApp, all files scanned by anti-virus software will be recalled in full. However, if the files are unchanged, then on subsequent migration jobs the files will simply be turned offline, and the data will not be migrated again. 116 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Integrating DX-NAS with other Products Using VisualSRM The DX-NAS GUI interface allows you to create rules for identifying files that should be moved to secondary storage. These rules are articulated in the Policy Wizard of the DX-NAS GUI. For example, Figure 43 shows a policy being created that will find all PDF files on the source file system. Note that the search criteria is articulated using syntax similar to that of the UNIX find command. Figure 43 DX-NAS policy set to find PDF files Using VisualSRM 117

Integrating DX-NAS with other Products However, while DX-NAS is focused on creating and running jobs that migrate data off primary storage, VisualSRM is designed to provide a wider range of information about storage volumes. Not only can it create reports on storage usage including trends in historical data usage but it can also take intelligent action to help maintain storage volumes. For example, VisualSRM can monitor disk usage, and, at a pre-defined threshold, start compressing files that haven t been accessed for three months. Another intelligent action that VisualSRM can take is to run a script that calls DX-NAS and migrates any files on the Celerra file system that match its filtering criteria. For example, Figure 44 shows a VisualSRM filter that has been set to find any PDF files on a Celerra volume named lava2176. Any files that meet this criteria will be sent to DX-NAS to be migrated to secondary storage. Figure 44 VisualSRM filter set to find PDF files 118 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Integrating DX-NAS with other Products Configuring VisualSRM to Work with DX-NAS The first phase of configuring VisualSRM to work with DX-NAS is to install each product separately, and specific installation instructions are contained in the following documents: EMC DiskXtender for NAS, Release 3.0, Microsoft Windows Installation Guide (P/N E2-2485-01) EMC DiskXtender for NAS, Release 3.0, UNIX/Linux Installation Guide (P/N e2-2486-01) EMC VisualSRM 1.7.0 Installation Guide (P/N 300-001-136) After both products are configured the following high-level steps need to be taken: 1. In the DX-NAS GUI configure a source that identifies the Celerra file system you want to migrate files from. This source directory needs to be the same directory that VisualSRM will scan. 2. Configure a destination where you want to migrate the files. 3. Configure a policy that uses the source and destination you created and identifies your migration mode and readback method. Be sure, however, to leave the Match Criteria field blank in the GUI. The Match Criteria will default to -type f, but this simply tells DX-NAS to use the files sent to it by VisualSRM. 4. Create a job to migrate the files. This job will use the policy you created in step 3. VisualSRM will run a batch file that will run this job. 5. In the VisualSRM interface, create a resource. This resource can be thought of as a container for disk drives or file systems. 6. In the newly created resource add the Celerra file system you identified in step 1. 7. Create a scan policy for the resource. 8. Create an intelligent action that will run the following script: C:\Program Files\EMC\DXNAS\Server\bin\runVSRMJob.bat Using VisualSRM 119

Integrating DX-NAS with other Products This script is distributed with DX-NAS 2.0 and calls the DX-NAS job you created in step 4. Set the filtering criteria filename, file size, last access time, etc. on this intelligent action. After you have completed these steps you can run the intelligent action from the VisualSRM interface. Note: You may want to preview the results of the VisualSRM scan policy before running the intelligent action as migrating more than 4,000 files at a time can negatively affect the performance of VisualSRM. 120 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Integrating DX-NAS with other Products Integrating with DiskXtender for Windows EMC DiskXtender File System Manager for Windows (DX-Windows) v6.1 provides the ability to migrate files from Windows NTFS file systems to multiple targets including EMC Centera, disk, tape, and optical storage systems. Both DX-NAS and DX-Windows are required in a CIFS environment in which a customer wishes to migrate files from a source file system to multiple storage targets or tape or optical storage mediums. Migrating files from a source file system to multiple storage targets is a two-step, double-hop process. DX-NAS migrates files from the source to a DX-Windows managed NTFS destination file system. DX-Windows then migrates files from the managed NTFS file system to the specified storage targets. For this reason, it is strongly recommended that you install DX-NAS and DX-Windows on the same host. For more information about DX-Windows, please review the appropriate documentation available at http://powerlink.emc.com/ Note: File systems managed by DX-Windows with more than 20 million files can lead to decreased migration and backup/recovery performance. DX-Windows can manage more than one file system on the same server. Note: DX-Windows supports file system retention. However, when implementing DX-Windows with DX-NAS it is strongly suggested that you do not use of this feature. Note: DX-NAS will create info files on the managed file system. For performance reasons, you will want to configure DX-Windows to not purge or migrate these files. Integrating with DiskXtender for Windows 121

Integrating DX-NAS with other Products Integrating with DXUL File System Manager EMC DiskXtender UNIX/Linux File System Manager (FSM) v3.2 provides the ability to migrate files to multiple storage targets including EMC Centera, disk, tape, and optical storage mediums. Both DX-NAS and FSM are required in an NFS environment in which a customer wishes to migrate files from primary storage to multiple storage targets or to tape or optical storage mediums. Migrating files from primary storage with FSM is a two-step, double-hop process. DX-NAS migrates files from the source to an FSM managed NFS destination file system. FSM then migrates files from the managed system to the specified backend storage targets. For this reason it is strongly suggested that you installed DX-NAS and FSM on the same host. For more information about FSM on the Solaris or Linux platform, please review the appropriate documentation available at http://powerlink.emc.com/ Note: File systems managed by FSM with more than 20 million files can lead to decreased migration and backup/recovery performance. FSM on the Solaris or Linux platform can manage more than one file system on the same server. Note: FSM on the Solaris or Linux platform supports file system retention. However, when implementing FSM with DX-NAS it is strongly suggested that you do not use of this feature. Note: DX-NAS will create info files on the managed file system. For performance reasons, you will want to configure FSM to not purge or migrate these files. 122 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Integrating DX-NAS with other Products Integrating with DXUL Storage Manager 2.9 EMC DiskXtender UNIX/Linux Storage Manager v2.9 (DXUL-SM) provides the ability to migrate files to multiple storage targets including EMC Centera, disk, tape, and optical storage mediums. Both DX-NAS and DXUL-SM are required in an NFS environment in which a customer wishes to migrate files from primary storage to multiple storage targets or to tape or optical storage mediums. Migrating files from primary storage with DXUL-SM is a two-step, double-hop process. DX-NAS migrates files from the source to an DXUL-SM managed destination file system. DXUL-SM then migrates files from the managed system to the specified backend storage targets. For more information about DXUL-SM on the Solaris or Linux platform, please review the appropriate documentation available at http://powerlink.emc.com/ Configuring DXUL-SM with DX-NAS The recommended configuration is to run DX-NAS and DXUL-SM on separate machines (Figure 45 on page 124). Integrating with DXUL Storage Manager 2.9 123

PS0 PS1 PS2 PS3 PS4 SM B0SM B1 PS0 PS1 PS2 PS3 PS4 SM B0SM B1 Integrating DX-NAS with other Products NetApp DX-NAS on Solaris or Linux Source SB0 SB1 SB2 SB3 SB4 SB0 SB5 SB1 SB6 SB2 SB7 SB3 SB4 SB5 SB6 SB7 SB8 SB9 SB10 SB11 SB14 SB12 SB15 SB13 SB8 SB9 SB10 SB11 SB12 SB13 SB14 SB15 Celerra DXUL-SM ver 2.9 Disk Tape DVD Centera Figure 45 DXUL-SM 2.9 running on different machine than DX-NAS However, for Solaris only, it is also possible to run DX-NAS and DXUL-SM on the same machine (see Figure 46 on page 125). 124 EMC DiskXtender for NAS Release 3.0 Theory of Operations

PS0 PS1 PS2 PS3 PS4 SM B0SM B1 PS0 PS1 PS2 PS3 PS4 SM B0SM B1 Integrating DX-NAS with other Products NetApp Source SB14 SB12 SB15 SB13 SB14 SB12 SB10 SB8 SB15 SB13 SB11 SB9 DX-NAS on Solaris SB0 SB1 SB4 SB5 SB6 SB6 SB4 SB2 SB2 SB0 SB7 SB5 SB8 SB9 SB10 SB7 SB3 SB3 SB1 SB11 DXUL-SM ver 2.9 Celerra Disk Tape DVD Centera Figure 46 DXUL-SM 2.9 running on Solaris with DX-NAS Note: In both these configurations be sure the DX-NAS machine uses hard mounts when mounting primary and secondary storage. That is, in the /etc/vfstab file of the DX-NAS machine, use the keyword hard in the mount options column when mounting source and destination directories. DXUL-SM and Celerra DX-NAS Even though Celerra Dart 5.x and DXUL-SM both support NFS version 3, the Celerra does not understand the NFS_EJUKEBOX error. Integrating with DXUL Storage Manager 2.9 125

Integrating DX-NAS with other Products Consequently, rather than send the NFS_EJUKEBOX error to the Celerra, DXUL-SM will instead report this error: NFS error: NFS server <IP Address> not responding still trying In this situation the error is benign and simple means that the purged data on DXUL-SM has not yet been fully recalled. If this error persists beyond the time required for DXUL-SM to recall the data, you can check to see if data is moving between the Celerra and DXUL-SM by running the iostat command on the Solaris machine. 126 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Integrating DX-NAS with other Products Using EMC Celerra HighRoad HighRoad is a performance enhancing product for the Celerra that allows data traffic to and from the Celerra to be directed over the SAN as opposed to the network. HighRoad has no negative impact on DX-NAS and can be used in DX-NAS environments. Using EMC Celerra HighRoad 127

Integrating DX-NAS with other Products 128 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Invisible Body Tag 9 High Availability Solutions for DX-NAS In order to create a high availability (HA) solution for DX-NAS, you need set up HA on each of the components that comprise the DX-NAS solution. In many cases the components that need to be configure for HA are: Primary Storage An EMC Celerra or a NetApp Filer The DX-NAS server Secondary Storage A file system or EMC Centera Figure 47 illustrates some of these configurations. High Availability Solutions for DX-NAS 129

High Availability Solutions for DX-NAS Data Mover Failover, Celerra Replication, SnapMirror Autostart Microsoft Cluster, Autostart, or other replication technology EMC Centera Replication Celerra DX-NAS Secondary Storage Celerra DX-NAS DX Windows or FSM EMC Centera Celerra DX-NAS EMC Centera NetApp DX-NAS EMC Centera NetApp DX-NAS Secondary Storage Figure 47 DX-NAS Components that need HA configuration 130 EMC DiskXtender for NAS Release 3.0 Theory of Operations

PS0 PS1 PS2 PS3 PS4 SMB0 SMB1 High Availability Solutions for DX-NAS High Availability on the Celerra The most straightforward way to achieve high availability on the Celerra is to implement Data Mover failover and Celerra Replication. Data Mover Failover On the Celerra, it is the data mover that makes file systems available to NAS clients on the network. If you configure a back up, or standby, data mover, then, if for some reason your primary data mover fails, the Celerra will immediately, and automatically, failover to the standby data mover. Windows NAS Client Note: The Primary Data Mover and the Standby Data Mover will need to have the same hardware components. Data mover failover preserves continuous access to the data on your Celerra file systems. Celerra SB14 SB12 Primary Data Mover SB15 SB13 SB0 SB1 SB6 SB7 SB10 SB8 SB11 SB9 File System UNIX NAS Client SB4 SB2 Standby Data Mover SB5 SB3 High Availability on the Celerra 131

PS0 PS1 PS2 PS3 PS4 SMB0 SMB1 High Availability Solutions for DX-NAS Figure 48 A Celerra configured with a standby Data Mover for failover Celerra Replication While Data Mover failover preserves network access to the exported Celerra file systems, it does not provide any protection for the data on the disks. This level of protection can be added to the Celerra by implementing Celerra replication. Celerra replication consists of creating a checkpoint (or snapshot) of your file system and then having the Celerra track changes that occur to the file system afterwards. In this way, if, for some reason the file system becomes inaccessible, the Celerra can recreate the file system by taking the checkpoint you made and applying the changes. Note: Failover to the replicated file systems does not occur automatically; it requires building the replicated file system on the control station of the Celerra. Windows NAS Client Celerra Primary Data Mover SB12 SB10 SB13 SB11 SB8 SB6 SB9 SB14 SB15 UNIX NAS Client Primary File System Replicated File System SB7 SB4 SavVol SB5 SB2 SB0 Standby Data Mover SB3 SB1 Figure 49 A Celerra configured with data mover failover and replication 132 EMC DiskXtender for NAS Release 3.0 Theory of Operations

High Availability Solutions for DX-NAS High Availability on NetApp For more information on HA products for NetApp like SnapMirror, contact NetApp. High Availability on NetApp 133

High Availability Solutions for DX-NAS High Availability for the DX-NAS server The EMC AutoStart Module for DX-NAS (Mod-DX-NAS) is an optional module that you can install with AutoStart release 5.1 and DX-NAS release 2.x to create a highly available environment for DX-NAS. When the DX-NAS server software or environment fails, the Mod-DX-NAS relocates the affected resources and restarts the DX-NAS software on another computer. This process, commonly referred to as a failover, runs transparently. Anyone who is using the DX-NAS software at the time a failover occurs is unaware of the failure. A typical HA environment in which DX-NAS and Mod-DX-NAS are installed is comprised of the following components: Active AutoStart node with the following software installed and running: AutoStart agent DX-NAS server process Mod-DX-NAS Passive AutoStart node with the following software installed and running: AutoStart agent DX-NAS server process Mod-DX-NAS Shared disk that contains the DX-NAS server data. DX-NAS destination directory that is accessible by both nodes. DX-NAS client software installed on either a Solaris, Linux, or Microsoft Windows computer. Figure 50 shows a sample configuration in which Mod-DX-NAS and DX-NAS are installed and running. 134 EMC DiskXtender for NAS Release 3.0 Theory of Operations

SB14 SB12 SB10 SB8 SB6 SB4 SB2 SB0 PS0 PS1 PS2 PS3 PS4 SMB0 SMB1 SB15 SB13 SB11 SB9 SB7 SB5 SB3 SB1 High Availability Solutions for DX-NAS Celerra (source) file_system Active Node Solaris 9 1. DX-NAS server process 2. AutoStart Module for DX-NAS 3. AutoStart Agent Failover DX-NAS Client AutoStart Console Solaris or Windows Passive Node Solaris 9 1. DX-NAS server process 2. AutoStart Module for DX-NAS 3. AutoStart Agent UNIX (destination) /common DX-NAS server Shared disk /shareddisk/dxnas GEN-000088 Figure 50 AutoStart Configuration High Availability for the DX-NAS server 135

High Availability Solutions for DX-NAS DX-NAS Server and Microsoft Server Clustering DX-NAS, release 3.0, enables you to use DX-NAS with a Microsoft Cluster. DX-NAS supports a two-node cluster with one active node and one passive node. Because DX-NAS is a cluster-unaware application, you must configure the cluster to enable failover and failback for DX-NAS. 1 Table 12 on page 136 lists hardware and software specifications that were used to test DX-NAS release 3.0 with a two-node (active/passive) Microsoft cluster. Table 12 DX-NAS and cluster specifications Component Hardware specifications Software specifications Active and passive nodes Dell PowerEdge 850 with Dual GiGE NICs QLogic QLA 2200 HBA Microsoft Windows 2003 Enterprise Edition with Service Pack 1 Cluster software Navisphere Host Agent CLI 6.19.1.3.0 Source host Celerra NS500 Celerra 5.5 Fibre Channel switch EMC DS-16b fabric channel switch Fabric operating system version 2.6.0f Shared disk CLARiiON AX100SC FLARE operation system, version 02.19.100.5.007 DX-NAS server software, release 3.0 Destination device EMC Centera CenteraStar version 3.0.0-542-557-8615 1. A cluster-aware application supports the Microsoft Cluster API. Cluster-aware applications register with the cluster service. They also receive status and notification information from the cluster service. 136 EMC DiskXtender for NAS Release 3.0 Theory of Operations

High Availability Solutions for DX-NAS A DX-NAS Configuration on a Microsoft Cluster Figure 51 on page 137 illustrates a configuration in which DX-NAS is installed in a two-node cluster. Client DX NAS client 3.0 Source Celerra NS500 DART 5.5 NAS version 5.5.19-2 CIFS shares NIC1 public NIC1 public Active Node NIC1 private Passive Node Dell PowerEdge 850s with dual GiGE NICs Windows 2003 Enterprise Edition SP1 Cluster software QLogic QLA 2200 HBA Navisphere Host Agent CLI6.19.1.3.0 EMC DS-16b fabric channel switch Fabric operating system version 2.6.0f Shared disk CLARiiON AX100SC FLARE 02.19.100.5.007 DX NAS server 3.0 GEN-000111 Destination device CenteraStar version 3.0.0-542-557-8615 Figure 51 DX-NAS installed in a two-node cluster configuration DX-NAS Server and Microsoft Server Clustering 137

High Availability Solutions for DX-NAS The Guide to Creating and Configuring a Server Cluster under Windows Server 2003 White Paper provides specific information for setting up a cluster. This white paper is available from the Microsoft TechNet website. 138 EMC DiskXtender for NAS Release 3.0 Theory of Operations

High Availability Solutions for DX-NAS High Availability for Secondary Storage Because DX-NAS uses secondary storage as simply a shared disk, any secondary storage setup that provides redundancy for the network connection and the file system will suffice for HA coverage. However, the two most common methods for providing HA on secondary storage are: Putting secondary storage on a Celerra or NetApp that is configured for high availability Putting secondary storage on a file system shared out by a Microsoft cluster The HA configuration is a bit more complicated for DX-NAS when it is migrating files indirectly to an EMC Centera using either of these two products: EMC DiskXtender (DX Windows) EMC DiskXtender File System Manager (FSM) Whichever product you use will need to be configured for HA. HA Secondary Storage on the Celerra A simple example of this kind of redundancy is where you use different Celerra, or a different data mover on the same Celerra, as secondary storage. In this way, you can use Data Mover failover and High Availability for Secondary Storage 139

High Availability Solutions for DX-NAS Celerra replication to ensure that the secondary storage file systems are highly available. Windows NAS Client UNIX NAS Client Source Celerra Primary Data Mover Standby Data Mover Destination Celerra Primary Data Mover Replicated File System Primary File System SavVol DX-NAS Server Standby Data Mover Replicated File System Secondary File System SavVol Figure 52 DX-NAS using a Celerra to provide HA for secondary storage HA Secondary Storage on the NetApp For more information on how to set up a NetApp Filer contact NetApp. HA Secondary Storage on a Microsoft or Linux Cluster It is also possible to have the secondary storage for DX-NAS reside on a file system that is shared out by a Microsoft or Linux cluster as well. Configuring DX-NAS to use secondary storage on a Microsoft or 140 EMC DiskXtender for NAS Release 3.0 Theory of Operations

PS0 PS1 PS2 PS3 PS4 SMB0 SMB1 High Availability Solutions for DX-NAS Linux cluster is identical to configuring it for any other file system share. Windows NAS Client DX-NAS Server Microsoft or Linux Cluster SB14 Data Mover SB15 DX Windows SB0 SB10 SB1 SB8 SB11 SB9 SB6 SB7 SB12 SB13 Primary Storage EMC Centera UNIX NAS Client SB4 SB2 SB5 SB3 Celerra or NetApp Note: Any Microsoft clustering solution will not work with the Solaris or Linux version of DX-NAS. HA on an EMC Centera Using DX Windows DX Windows is currently supported on 2-Node Active/Active and Active/Passive Microsoft Clusters. HA protection can be added to the EMC Centera using the EMC Replication Manager. HA on an EMC Centera Using FSM FSM can be configured for high availability using the Autostart product. High Availability for Secondary Storage 141

High Availability Solutions for DX-NAS HA protection can be added to the EMC Centera using the EMC Replication Manager. Public Network Optional Heartbeat Network Primary AutoStart Node (Active) Running Processes uvdmigd (fs1 parent) uvdmigd (fs1 child) uvdmigd (fs2 parent) uvdmigd (fs2 child) migpurged (fs1 parent) migpurged (fs1 child) migpurged (fs2 parent) migpurged (fs2 child) Shared Managed IP Address Secondary AutoStart Node (Passive) Stopped Processes uvdmigd (fs1 parent) uvdmigd (fs1 child) uvdmigd (fs2 parent) uvdmigd (fs2 child) migpurged (fs1 parent) migpurged (fs1 child) migpurged (fs2 parent) migpurged (fs2 child) Shared Disk FSM Installation Directory Two Managed File Systems (fs1 & fs2) Primary Host License File Secondary Host License File Active License File (DXULDM.license) Figure 53 FSM configured for HA using Autostart 142 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Invisible Body Tag 10 Disaster Tolerant Strategies for DX-NAS Disaster tolerant strategies are similar to the high availability strategies discussed in the previous chapters. However, the focus of disaster tolerance is protecting against multiple points of failure or against events that might cripple an entire site. Disaster Tolerant Strategies for DX-NAS 143

Disaster Tolerant Strategies for DX-NAS Disaster Tolerant Strategies Conceptually, there are three approaches to disaster tolerant implementations: Synchronous all data is mirrored synchronously from one site to a different site. Point-in-time the data is check pointed, and then the check point is mirrored from one site to a different site. Asynchronous some data is mirrored asynchronously from one site to a different site About Synchronous Data Mirroring Both your primary and secondary storage will need to support synchronous mirroring. For Celerra, this means that the back end will need to be Symmetrix DMX based. For NetApp this means that you will need to use a product like SnapMirror in synchronous mode. Additionally, the machine where the DX-NAS servers is running will need to support synchronous mirroring as well. Synchronous mirroring has the advantage of ensuring no data will be lost, and, generally, it provides for simple and quick recovery. However, due to latency in the transmission of data, the distance between the source and the mirror is limited. Note: Celerra does not support MirrorView Note: EMC Centera does not support synchronous replication natively. About Point-In-Time Data Mirroring This configuration assumes that you are migrating from a Celerra to a Celerra, or a NetApp Filer to a NetApp Filer, and that your secondary storage supports point in time snapshots. In this way you can checkpoint both the source and the secondary storage and mirror them. As DX-NAS configurations tend to be relatively static once they are set up, you can set up a cold standby DX-NAS server at the mirror site and manually copy the DX-NAS configuration database to that server for use in the event you need to fail over the cold standby to active. 144 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Disaster Tolerant Strategies for DX-NAS Point in time mirroring has the advantage of being able to recreate a consistent point in time for all components, and it allows the mirroring to take place across large distances. However, with this strategy you could potentially lose any data that has been created or updated since the last point in time checkpoint. Figure 54 Example of Synchronous Mirroring with DX-NAS About Asynchronous Data Mirroring In this configuration, some data is mirrored asynchronously. It assumes that secondary storage and DX-NAS are installed on systems that support mirroring of data between the sites. However, it makes no assumption about the co-ordination of updates between components. The advantages of this configuration are it does not require additional storage or special networks and, because it is Disaster Tolerant Strategies 145

Disaster Tolerant Strategies for DX-NAS asynchronous, the mirroring can take place across unlimited distances. Unfortunately, because the component mirroring is not synchronized there will be some data loss on a failover, and the failover process itself can be complex and somewhat lengthy. 146 EMC DiskXtender for NAS Release 3.0 Theory of Operations

PS0 PS1 PS2 PS3 PS4 SM B0SM B1 PS0 PS1 PS2 PS3 PS4 SM B0SM B1 PS0 PS1 PS2 PS3 PS4 SM B0SM B1 PS0 PS1 PS2 PS3 PS4 SM B0SM B1 Disaster Tolerant Strategies for DX-NAS NetApp NetApp SB0 SB6 SB8 SB10 SB12 SB0 SB2 SB4 SB6 SB8 SB1 SB0 SB1 SB7 SB9 SB11 SB13 SB2 SB1 SB3 SB5 SB7 SB9 SB3 SB2 SB3 SB4 SB5 SB4 SB5 SB14 SB15 SB14 SB15 SB10 SB11 SB10 SB6 SB8 SB10 SB12 SB11 SB0 SB2 SB4 SB6 SB8 SB12 SB7 SB9 SB11 SB13 SB13 SB12 SB1 SB3 SB5 SB7 SB9 SB13 SB14 SB15 SB14 SB15 Asynchronous mirroring e.g. Celerra Replication, OnCourse, NetApp SnapMirror Celerra Celerra DX-NAS Server and Local Storage Asynchronous mirroring e.g. EMC RepliStor, Rsync, OnCourse, etc. DX-NAS Server and Local Storage EMC Centera File Server Gateway EMC Centera File Server Gateway Asynchronous mirroring e.g. EMC RepliStor, Rsync, OnCourse, etc. Figure 55 Example of Asynchronous Mirroring with DX-NAS Disaster Tolerant Strategies 147

Disaster Tolerant Strategies for DX-NAS Failing Over a Disaster Tolerant Configuration When you fail over data tolerant configurations you need to take the following steps: Initiate failover procedures for each component and restart services with all standby components assuming the names of production systems On the Celerra, a FileMover environment consistency check may be required to recover some or all of the unreplicated stub files. If your configuration uses an EMC Centera, the EMC Centera file system and/or software database may need to be rebuilt and check for consistency. 148 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Index A alerts 62 critical 62 informational 62 printing 63 warning 62 AutoStart active node 134 agent 134 passive node 134 C CAVA 116 Celerra AntiVirus Agent, see CAVA 116 Celerra replication 132 checkpoints secondary storage 113 source directories 112 CLARiiON ATA 74, 79 cluster-unaware application 136 comments 14 ConsoleServerLog 64, 71 D data mirroring asynchronous 145 point-in-time 144 synchronous 144 data mover failover 131 destination 32 DiskXtender File System Manager for Windows, see DX-Windows 121 DiskXtender UNIX/Linux File System Manager, see DX-UL FSM 122 DiskXtender UNIX/Linux Storage Manager, see DXUL-SM 123 documentation, related 12 DX Windows 139 DX-NAS support for two-node cluster 136 DX-NAS server disk space requirements 89 process 134 DX-NAS server process 134 DX-NAS Windows and DX-NAS UNIX, differences 68, 69 DXNASLog 71 DXNASLog.log 63, 64 DXNASServerLog_x.log 64 DXUL-FSM 122 DXUL-SM 123 DX-Windows 121 E error reporting 62 F failover 148 file attributes from CLI 106 from GUI 104 file migration 32 file recall 45 EMC DiskXtender for NAS Release 3.0 Theory of Operations 149

Index file retention 84 firewall ports 27 FSM 74, 80, 139 H high availability 134, 139 Celerra 131, 139 EMC Centera 141 Microsoft Windows Cluster 140 NetApp 133, 140 I information file 53 J jobs creating 32 monitoring progress 41 stopping 44 L log level 64 alert 64 critical 64 debug 64 emergency 64 error 64 informational 64 notice 64 warning 64 logs 62, 63 resetting 65, 66 M match criteria 39 atime 39 ctime 39 group 39 mtime 39 name 39 perm 39 size 39 user 39 Microsoft Cluster requirements for DX-NAS 136 Microsoft Server clustering 136 mirroring Point-in-time 144 synchronous 144 mod-dx-nas 134 N NetApp filer requirements 29 Network Appliance (NetApp) Data OnTap software 29 NTServiceStdOut.log 71 O orphan file 50, 84, 90, 100 tags 103 with full data backups 95 orphan files 94, 103 P policies 32, 36 source scan 36 policy 32 policy match criteria 39 ports used by DX-NAS 27 primary storage using a Data Mover on Celerra 74 primary storage report 57 column definition 60 printing alerts 63 reports 61 R readback method 37 full 37, 87 override 112 partial 37 passthrough 37, 94 150 EMC DiskXtender for NAS Release 3.0 Theory of Operations

Index reports data migration reports 57 migration 57 orphan file 57, 58 primary storage 57, 59 printing 61 secondary storage 57, 60 requirements for Celerra systems 28 for DX-NAS and Microsoft Cluster 136 for NetApp filer 29 runclientcli.bin 70 runclientgui.bin 70 S search criteria atime 39 ctime 39 group 39 mtime 39 name 39 perm 39 size 39 user 39 secondary storage 22 sizing 90 using a Data Mover on Celerra 74 using a local disk on the FSM-NAS server 78 using a network drive on a remote host 79 using Celerra 76 using CLARiiON ATA 79 source 32 space available primary storage 59 secondary storage 60 storage report 57 primary 59 secondary 60 stub files 20 restoring from backup media 103 V VisualSRM 117, 119 EMC DiskXtender for NAS Release 3.0 Theory of Operations 151

Index 152 EMC DiskXtender for NAS Release 3.0 Theory of Operations