Using Celerra FileMover

Transcription

1 P/N Rev A02 March 2007 Contents Introduction Terminology Cautions and warnings FileMover concepts How Celerra FileMover works Migrate operation Write operation Read operation Configuring Celerra FileMover System requirements E-Lab Interoperability Navigator Planning considerations Storage considerations Orphan file management Backup strategies File system usage Network availability Read-only file systems Interactions between Celerra FileMover and your applications File system scanning performance Integration considerations User interface choices Celerra FileMover roadmap Enabling Celerra FileMover Creating a connection Creating a CIFS connection Creating an NFS connection Creating an HTTP connection Configuring API security Configuring access based on IP address Creating a Celerra FileMover user account Configuring digest access authentication Listing HTTP connection information Managing the Celerra FileMover connection Modifying a connection Listing Celerra FileMover connections Listing connection information of 72

2 Deleting a Celerra FileMover connection Celerra FileMover administration Changing a CIFS password Disabling Celerra FileMover logging Increasing log file size Scanning applications Performing an NDMP backup Performing a CIFS network backup Performing an NFS network backup Enabling pop-up notification (CIFS only) Adjusting offline attribute settings Tuning HTTP threads Tuning threads to read data from secondary storage Moving Celerra FileMover stub files Disabling FileMover functionality Example procedure Troubleshooting Celerra FileMover Technical support Telephone Known problems and limitations Limitations Error messages Related information Customer training programs Appendix A: Celerra FileMover log file example Appendix B: Storage space requirement example Index of 72

3 Introduction Celerra FileMover is a Celerra feature that delivers dynamic file mobility the ability to automate the migration of files in a network-attached storage (NAS) environment across a hierarchy of storage platforms. When Celerra FileMover is used with external policy and migration software, it automatically migrates infrequently used files, or files of a particular type, to slower, less-expensive storage devices. Celerra FileMover demonstrates the benefits of Information Lifecycle Management (ILM) by optimizing the placement of files within an existing tiered storage infrastructure. Enabling Celerra FileMover on the Celerra Network Server allows administrators to use storage devices economically to: Reduce storage management costs Extend storage lifetime Reduce the frequency of backups This technical module discusses how to configure Celerra FileMover on the Celerra Network Server, including: Configuring and managing Celerra FileMover connections on the Celerra Network Server Configuring API security This technical module is part of the Celerra Network Server information set and is intended for the system administrators responsible for configuring a Celerra FileMover file system to use with an external policy and migration software. Terminology This section defines terms important to understanding Celerra FileMover. The Celerra Glossary provides a complete list of Celerra terminology. CAVA (Celerra AntiVirus Agent): An application developed by EMC that runs on a Windows 2000 or Windows NT server and communicates with a standard antivirus engine to scan CIFS files stored on a Celerra Network Server. Celerra FileMover: A policy-based system used to determine where files should be physically stored. In most cases, policies are based on file size and/or last access time (LAT) and used to identify data that can be moved to slower, less-expensive storage. Celerra FileMover API: An API that enables integration between the Celerra Network Server and policy and migration software applications to automatically monitor and manage the movement of files between primary and secondary storage. CIFS (Common Internet File System): A file-sharing protocol based on the Microsoft Server Message Block (SMB). It allows users to share file systems over the Internet and intranets. 3 of 72

4 component file system: Refers to the file system(s) mounted on the nested mount root file system and is part of the nested mount file system. connection database: A database of secondary storage connection information that includes the server name, share, and credentials, which are stored on the file and maintained across system reboots. Digest Access Authentication: A means of verifying the client and server possess a shared secret (a password). extended ACL: Extended access control list (ACL). A container used to store extended attributes. In a Celerra FileMover system, extended ACLs are used to back up and restore stub files via a CIFS network backup. FQDN: Fully qualified domain name. The full name of a system, containing the domain name of the organization and its highest subdomain. FSN (Fail Safe Network): A high-availability feature that extends link failover out into the network by providing switch-level redundancy. An FSN appears as a single link with a single MAC address and potentially multiple IP addresses. Multi-Path File System (MPFS): A Celerra Network Server feature that allows heterogeneous clients with MPFS client software to concurrently access, directly over Fibre Channel or iscsi channels, shared data stored on a Symmetrix or CLARiiON array. MPFS adds a lightweight protocol called FMP (File Mapping Protocol) that controls metadata operations. See also FMP. link aggregation: A high-availability feature based on the IEEE 802.3ad Link Aggregation Control Protocol (LACP) standard allowing Ethernet ports with similar characteristics to the same switch to combine into a single virtual device/link with a single MAC address and potentially multiple IP addresses. migration method: An attribute that is set per individual file and is contained in the stub file when a file migrates to secondary storage. The Celerra Network Server uses the migration method to determine the amount of data that is recalled to primary storage to satisfy the client read request. NAS (network-attached storage): A specialized file server that connects to the network. A NAS device, such as a Celerra Network Server, contains a specialized operating system and a file system and processes only I/O requests by supporting popular file sharing protocols such as NFS and CIFS. NDMP: Network Data Management Protocol. A network protocol designed for the backup and retrieval of data. It is an open standard protocol for enterprise-wide backup of heterogeneous network-attached storage. NFS: Network File System. A distributed file system that provides transparent access to remote systems. NFS allows all systems on the network to share a single copy of a directory. Nested mount file system root: File system on which the component file systems are mounted read-only, except for mount points of the component file systems. orphan file: A file that exists on secondary storage but is no longer referenced by a stub file on the Celerra Network Server. An orphan file is kept intact on secondary storage; it can be managed by the system administrator. 4 of 72

5 passthrough: A migration method option that instructs the Celerra Network Server to read the requested data from secondary storage. The data is returned to the client, but is not recalled to primary storage; thus the stub file remains intact. policy and migration software: The policy and software used to migrate data from the Celerra Network Server to secondary storage according to customer-defined policies and schedules. policy engine: An external server on which the policy and migration software runs. primary storage: The Celerra Network Server that provides clients access to normal files as well as migrated files via the stub files that represent them. The Celerra Network Server contains all the stub files. quota: A limit on the amount of allocated disk space as well as the number of files (inodes) that a user or group of users can create in a production file system. Quotas control the amount of disk space and/or the number of files a user or group of users can consume. secondary storage: The storage device that contains file data associated with stub files on the primary storage. This device must be either a CIFS or NFS server. The Celerra Network Server can also be secondary storage. SnapSure: On a Celerra system, a feature providing read-only point-in-time copies, also known as checkpoints, of a file system. SRDF : Symmetrix Remote Data Facility. An EMC technology that allows multiple Symmetrix systems to maintain multiple copies of data in more than one location. The systems can be located within the same facility, in a campus, or hundreds of miles apart using fibre or dedicated high-speed circuits. stub file: A file that replaces the original file on the Celerra Network Server when the file is migrated to secondary storage. The stub file contains all the metadata associated with the migrated file and the information required by the Celerra Network Server to allow it access to the migrated data on secondary storage when required. TimeFinder /FS: A business continuance solution that allows customers to use business continuance volumes (BCVs) to provide a local mirror of Symmetrix devices, while the standard devices are online for regular host operations. trunk: A Celerra Network Server term used as a generic term for a set of physical network devices bundled together for high availability. Both Ethernet channels and link aggregations are trunks. VDM (virtual Data Mover): A Celerra software feature that enables users to administratively separate CIFS servers, replicate CIFS environments, and move CIFS servers from one Data Mover to another. Cautions and warnings This section lists the cautions for using this feature on the Celerra Network Server. If this information is unclear, contact an EMC Customer Support Representative for assistance. When the read policy value is set to the partial option, a partially recalled file remains intact on the Celerra Network Server until the recall operation is completed in response to a NAS client reading the remainder of the file, or the 5 of 72

6 policy and migration software reissues a Celerra FileMover API call to free the data blocks associated with the recalled data. Only policy and migration software and backup applications should be allowed to modify the migrated data on secondary storage. Otherwise, migrated data on secondary storage must not be modified. Any modification of migrated files on secondary storage causes the files to be inaccessible via the stub file on the Celerra Network Server. Celerra FileMover compares the modification time (mtime) kept by the stub file to the mtime on the file on secondary storage to ensure the two remain synchronous. If stub files are restored from a SnapSure checkpoint with an mtime different from the mtime of the secondary storage file, depending on the policy and migration software in use, the data may be unavailable on primary file system. This caution also applies to tape backup, a BCV for either TimeFinder/FS or TimeFinder/FS NearCopy (which uses SRDF/S), or an STD volume for TimeFinder/FS FarCopy (which uses SRDF adaptive copy write pending mode). Contact your software vendor to determine whether your policy and migration software supports multiple file migration. Depending on the policy and migration software in use, if a file is migrated more than once and a backup occurs between migrations, such as SnapSure checkpoint refresh or TimeFinder / FS Snapshot refresh, the file on the secondary storage becomes inaccessible via the stub file in the SnapSure checkpoint, TimeFinder NearCopy and FarCopy. You might experience the same behavior on the secondary file system of Celerra Replicator if a file is migrated more than once and the file systems have not yet synchronized. If your policy and migration software supports multiple file versions, which is the ability to store multiple versions of a single file, it is likely the migrated file content is accessible via the stub file in the backup. Contact your software vendor directly to determine whether your policy and migration software supports multiple file migration. When you are working with the Celerra FileMover log files in the /.etc directory of the file system, be careful not to touch any other files in the same directory. EMC recommends you disable logging on the primary file system before removing any dhsm_log.* files in the /.etc directory of the primary file system. Celerra FileMover can manage a maximum pathname length of 1024 bytes (not characters); however, the actual maximum pathname length depends on the policy and migration software application, file system type and operating system of the policy and migration software or the secondary server, device format connected to secondary server, and so on. The lowest maximum pathname length supported for any of these elements is the actual maximum pathname length in the environment. The primary Celerra Network Server, secondary file server, and the policy and migration software all must use the same locale. "Integration considerations" on page 21 contains more information about international character set support. If you intend to use Celerra FileMover with existing Celerra features such as international character sets, SnapSure, quotas, or the Celerra AntiVirus Agent, review "Integration considerations" on page of 72

7 FileMover concepts This version of Celerra Network Server supports Celerra FileMover. When combined with policy and migration software and a secondary storage infrastructure, this feature enables you to build an Information Lifecycle Management solution for NAS data, putting the right data in the right location at the right time. A combination of policies or rules helps Celerra FileMover determine whether files should be automatically migrated from higher speed, costly primary storage to slower, less-expensive storage devices and back again. Commonly used migration policies are those that migrate older, less frequently used files or files of a particular type, such as.mpg files. Files not symbolic links or directories are targeted for migration. 7 of 72

8 How Celerra FileMover works In the Celerra FileMover environment, the Celerra Network Server is the primary data store while the secondary store might be another Celerra Network Server or a network file server supporting CIFS, NFS, or HTTP. Refer to E-Lab TM Interoperability Navigator for secondary file servers supported using Celerra FileMover. External policy and migration software defines and implements the policies or rules that control whether files are migrated from primary to secondary storage. The Celerra Network Server implements the migration method options that determine whether files should be recalled from secondary storage. The file migration and retrieval process is automatic and completely transparent. When you access a file on the server, your files are immediately accessible and you can process data as though it were stored on primary storage. However, migrated files can take longer to access than files that are not migrated. Migrate operation A file is usually targeted for migration based on its attributes, such as file size, file type, or period of inactivity. As shown in Figure 1 on page 9, the policy and migration software periodically searches the Celerra Network Server for files that match policies preset by customers. When the policy and migration software finds a match, it migrates or reads the file from the Celerra Network Server, and then writes it to the secondary file server using NFS or CIFS. Finally, the policy and migration software issues a command via the Celerra FileMover API to convert the file to a stub file. This action frees the storage associated with the file and completes the migration operation. When a file is migrated, its data is moved to a file on secondary storage, and the original file is replaced with a stub file. The stub file contains all the metadata associated with the original file permissions, timestamps, size, attributes, and alternate datastreams. The stub file also contains additional data associated with the FileMover functionality, including the location of the file content on secondary storage, the identity of the policy and migration software that migrated the file's content, and an information field in which the policy and migration software can store any additional information it deems necessary. A stub file consumes one inode and one 8 KB data block, plus the size of any alternate datastreams associated with the file, in the primary file system on the Celerra Network Server. 8 of 72

9 PS0 PS1 PS2 PS3 PS4 SMB0 SMB1 Celerra 1. Search SB8 SB10 SB12 SB14 SB9 SB11 SB13 SB15 2. Read File Policy and Migration Software SB4 SB2 SB0 SB5 SB3 SB1 SB6 SB7 4. Replace file w/stub File NAS Clients Celerra FileMover API over HTTP 3. Write File Secondary Storage File Server(s) NFS/CIFS Centera ATA Tape/Optical Figure 1 Celerra FileMover migration operation To estimate migration time, you might consider the time it takes for the policy and migration software to search for and migrate data from the Celerra Network Server to secondary storage via the network. The size of the directory tree, network speed, and policy and migration software resources help determine the amount of time it takes for the policy and migration software to search and migrate the data. The time it takes to replace an original file with a stub file after it has migrated the data to secondary storage is a relatively small overhead. "System requirements" on page 16 contains information about network requirements. The search operation scans all directories on the primary file system for files specified by the policy and migration software even if there is no file match for migration. Because searching uses the Data Mover and network resources, it is strongly recommended that you schedule migration and search operations to occur at a time when the Data Mover is less utilized. Note: The policy engine can be a secondary server. Review your policy and migration software documentation for more information about policy and migration software performance. CNS of 72

10 PS0 PS1 PS2 PS3 PS4 SMB0 SMB1 Write operation NAS clients write file data to the Celerra Network Server via NFS, CIFS, or FTP as illustrated in Figure 2. Until the policy and migration software migrates a file, the file physically resides on the Celerra Network Server and write operations proceed normally. When a file migrates from the Celerra Network Server to secondary storage, policy and migration software copies all of the file s data to a file on secondary storage and converts the original file to a stub file. The stub file contains all of the file s metadata, including the file s actual location on secondary storage. Policy and Migration Software Write File SB0 SB1 SB2 SB3 SB4 SB5 SB6 SB7 SB8 SB10 SB12 SB14 SB9 SB11 SB13 SB15 NAS Clients Secondary Storage File Server(s) NFS/CIFS Centera ATA Tape/Optical Figure 2 Celerra FileMover write operation Writing to migrated files When a write operation occurs, the Celerra Network Server uses the information in the stub file to locate the file on secondary storage. It then compares the modification time (mtime) and size it has stored to the current mtime and size of the file on secondary storage. This comparison ensures the stub file and migrated file remain synchronous. When these attributes match, file data is returned to the client to satisfy the read request. If the attributes differ, an error message appears. Celerra Network Server will not return potentially corrupt file data. There are two ways in which client applications can write to migrated files on a file server. The client can either modify a portion of a file or replace the entire file. If the write operation is modifying a portion of a migrated file, the Celerra Network Server recalls the entire file to primary storage; the file replaces the stub file to allow the client to proceed with the write operation. The file remains on the Celerra Network Server until the policy and migration software determines it should be moved back to secondary storage. At that time, the file s full pathname is once again contained in the stub file and its data stored on a secondary file server. 10 of 72

11 Note: If there is not enough space on the file system, or, the user, group, or tree quota limits have been exceeded, file data cannot be recalled and the client write request fails. The original file and the stub file are unchanged. If the write request is an attempt to rewrite an entire file, the client application truncates the file to zero, thus causing the file server to discard the existing content of the file. After a file is truncated, whatever the application writes to the file becomes the file s new content. When the Celerra Network Server detects a truncated file, it marks the file as one that belongs on primary storage; there is no need to recall any data from secondary storage. Note: If there is inadequate space on the file system or quota limits are exceeded during a rewrite request, there will be partially written files on the primary file system. If your policy and migration software supports multiple file migration, which is the ability to store multiple generations of a single file, it is likely file content will remain accessible. Contact your software vendor to determine whether your policy and migration software supports multiple file migration. Read operation Until the policy and migration software migrates a file, the file physically resides on the Celerra Network Server and client read operations proceed normally. When a file migrates to secondary storage, the file contents migrate to a file on secondary storage and the original file is converted to a stub file. The stub file contains all the file s metadata including its actual location on secondary storage, modification time, size, and its migration method, which is set per individual file when the file migrates. When a client attempts to read a migrated file, the Celerra Network Server accesses the information in the stub to locate the file on the secondary storage server as illustrated in Figure 3 on page 12. When the Celerra Network Server reads the contents of a migrated file, it compares the modification time and size it has stored for the file to the current modification time and size of the file on secondary storage. This comparison ensures the stub file and migrated file remain synchronous. The amount of file data recalled during a read operation depends on the migration method specified on the file and the amount of data the application actually reads during access. Depending on the type of client I/O (read or write operation) and the migration method specified in the stub file, connection, or file system level, the Celerra Network Server might replace the stub file on primary storage with the recalled data or leave the file in a migrated state. With the exception of CIFS backup, all NFS and CIFS applications cause file data to be recalled during read operations. Note: Migration method options are sometimes referred to as read policies and read methods. 11 of 72

12 PS0 PS1 PS2 PS3 PS4 SMB0 SMB1 SB14 SB15 Policy and Mirgation Software SB0 SB1 SB2 SB3 SB4 SB5 SB6 SB7 SB8 SB9 SB10 SB11 SB12 SB13 NAS Clients Read File The read operation may, or may not, replace the stub file on the Celerra Network Server. Secondary Storage File Server(s) NFS/CIFS Centera ATA Tape/Optical Figure 3 Celerra FileMover NAS client read of a migrated file Note: A customer-defined migration method specified on an individual file, connection, or primary file system determines whether the file s content is recalled from secondary storage to the Celerra Network Server in response to the client request. The read operation may or may not replace the stub file on the Celerra Network Server. Celerra FileMover is designed so the policy and migration software is not part of the file data recall process. Data migration and/or data recall is automatic and completely transparent to NAS clients and has no effect on the availability or integrity of data. For example, if the migration method is set to full, the Celerra Network Server recalls all the file data to primary storage in response to the read request. However, if the method is set to the default passthrough, the file data is retrieved and returned to the client, but the original file is not recalled to the Celerra Network Server. 12 of 72

13 Reading migrated file data The migration method for read operations is set to passthrough by default. If a migration method is not specified in the file, and the connection or file system overrides are set to none, the passthrough option is used. When a client attempts to read a migrated file, the Celerra Network Server recalls file data based on one of the three migration method options set by the policy and migration software: Passthrough The Celerra Network Server reads the requested data from secondary storage and returns it to the client immediately. None of the file s data is recalled to primary storage; the file remains on secondary storage. The passthrough option (default) ensures that migrated files remain migrated regardless of how often the files are read. This option is also applicable as an override setting on a connection (secondary storage) or primary file system. For example, you might use the passthrough option when you want to prevent an operation, such as a search for specific content in all files, from prompting a massive unintended recall of migrated files to primary storage. Partial The Celerra Network Server recalls only as much of the file s contents in part or whole as it needs to satisfy the client read request.the data is retrieved and returned to the client when the Celerra Network Server receives it from secondary storage. In addition, if a NAS client reads the same data again, the Celerra Network Server retrieves the data from the partially recalled file; the data does not need to be recalled from secondary storage. Use of the partial option is applicable in the same situations where you might use the full option. You might use partial for files that are read frequently and thus should have the performance benefit of being on primary storage. The additional benefit is that client read requests of large files complete more quickly because the Celerra Network Server recalls only the data requested before responding to the client request. Full The Celerra Network Server recalls all the file data to primary storage when the file is first accessed for read, which maximizes performance of subsequent read or write operations. It is important to realize that when the Celerra Network Server recalls large files in order to satisfy a read request, the read operation might take time to complete. This behavior emulates that of traditional hierarchical storage management (HSM) where the entire file must be recalled from secondary to primary storage before client access is possible. Note: In some cases, the primary Data Mover might not need to retrieve data from secondary storage because the data already resides in cache of the primary Data Mover. 13 of 72

14 Migration method selection The migration method associated with each stub file can be overridden at the connection or primary file system level using the -read_policy_override option of the fs_dhsm command. The migration method for a read operation is determined as follows: If the file system is read-only, the passthrough option is used. If the file is currently being backed up by an NDMP or CIFS backup application using options to read migrated data, or is being scanned by CAVA, the passthrough option is used. The file system migration method, when specified, takes precedence over the connection and stub file settings. The connection migration method, when specified, takes precedence over the option set in the stub file. The stub file migration method, when specified, is used; otherwise, the policy defaults to the passthrough option. If attempts to recall data produce an error related to insufficient space or quotas, FileMover attempts to reread the data using the passthrough option. 14 of 72

15 Configuring Celerra FileMover Configuring and managing a Celerra FileMover file system is consists of: "Creating the connection to the secondary store" "Managing the Celerra FileMover file system" "Configuring API security" After a file system and associated Data Mover are enabled and configured for Celerra FileMover on the Celerra Network Server, day-to-day management of Celerra FileMover is performed via the policy and migration software. This technical module does not discuss the installation, configuration, and management of the policy and migration software. Contact your software vendor or refer to your policy and migration software documentation for more information. Creating the connection to the secondary store You enable Celerra FileMover on the file system, and then create a connection to a secondary file server. This connection must be established before any files can be migrated to, or recalled from, secondary storage. The policy and migration software must have read/write access to the secondary file server; the Celerra Network Server requires read access only. Note: NAS clients must not be allowed to modify the migrated data on secondary storage. Any modification of migrated files on secondary storage causes the files to be inaccessible via the stub file on the Celerra Network Server. Managing the Celerra FileMover file system After you enable Celerra FileMover on a file system and establish a connection to the secondary storage device, you can perform several management tasks. Using options in the fs_dhsm command, you can list Celerra FileMover attributes, modify the Celerra FileMover connection, set and/or query file system parameters, and disconnect the connection. Configuring API security The Data Mover must be configured to work with the policy and migration software. The Celerra FileMover API service is started on Data Mover port 5080; it uses the HTTP protocol to allow the policy and migration software to migrate files and query the Celerra Network Server for file attributes. You can configure security options to modify the HTTP server on the Data Mover to restrict access to the Celerra FileMover API service based on the policy and migration software s IP address, or to use digest authentication per request. The process of configuring security options might involve: Using the server_user command to add users to the Data Mover s local passwd file Configuring the Data Mover s HTTP server using the server_http command Note: This HTTP implementation is intended for Celerra FileMover API only; not for use by any other HTTP clients. 15 of 72

16 System requirements This section describes the Celerra Network Server software, hardware, network, and storage configurations required for using Celerra FileMover as described in this technical module. Table 1 Celerra FileMover system requirements Software This technical module describes Celerra Network Server version 5.5. If you are running an earlier version of Celerra Network Server, note the following requirements: At minimum, version or later is required for the Celerra Network Server Version 5.4 release At minimum, version or later is required for the Celerra Network Server version 5.3 release Refer to EMC NAS Interoperability Matrix for policy and migration software supported using Celerra FileMover. Hardware Network Celerra Network Server 510 Data Mover or later NS 500 or later Refer to your policy and migration software documentation for requirements specific to the policy and migration software platform. For maximum performance and security, consider managing the network traffic between the Celerra Network Server, policy and migration software, and secondary storage to travel via private, high-speed (Gigabit Ethernet) network. Refer to "Network availability" on page 20. Refer to your policy and migration software documentation for detailed information about network requirements. Storage Refer to "Storage considerations" on page 17. Refer to EMC NAS Interoperability Matrix for secondary file servers that are supported using Celerra FileMover. E-Lab Interoperability Navigator The E-Lab TM Interoperability Navigator is a searchable, web-based application that provides access to EMC interoperability support matrices. It is available at After logging in to Powerlink, go to Support > Interoperability > E-Lab Interoperability Navigator. 16 of 72

17 Planning considerations This section contains information that is helpful to understand before implementing Celerra FileMover with the Celerra Network Server to meet your storage management needs. EMC strongly recommends that you: Review "Storage considerations" on page 17 Review "Orphan file management" on page 18 Determine "Backup strategies" on page 19 Monitor "File system usage" on page 20 Consider "Network availability" on page 20 Consider "Read-only file systems" on page 20 Review "Interactions between Celerra FileMover and your applications" on page 21 Consider "File system scanning performance" on page 21 Review "Integration considerations" on page 21 Note: Celerra FileMover can be used in multiprotocol environments. This means NFS, CIFS, and HTTP file servers can be used as secondary storage regardless of the protocol clients use to access migrated files. This is because all the metadata associated with a migrated file is contained in a stub file; only the content of the file is migrated to secondary storage. The Managing Celerra for a Multiprotocol Environment technical module contains detailed information about how to configure the Celerra Network Server for use in a multiprotocol environment. Storage considerations When you design an ILM solution based on Celerra FileMover, you need to consider the relative space requirements for primary and secondary storage. Dimensioning primary versus secondary storage Primary storage must be large enough to store all the files you do not plan to migrate to secondary storage, as well as the stub files representing all migrated files. Stub files typically occupy 8 KB of space on primary storage. The secondary storage device must be a CIFS, NFS, or HTTP server. Secondary storage must be large enough to store all the files you intend to migrate. It is also important to consider the amount of file data, as well as the number of objects files, directories, and symbolic links the secondary storage device needs to manage. You can associate up to 1,024 secondary storage locations with a single primary file system; storage space can be spread over a number of devices. Contact your software vendor directly for advice on dimensioning your secondary storage. You might also consider the amount of data that will be written to primary storage before the policy and migration software is able to migrate the data to secondary storage. Be mindful about keeping an amount of space available on primary storage for any new files being created. Space is also needed to recall migrated 17 of 72

18 files if they are written to, or recalled, in response to a client request. "Appendix B: Storage space requirement example" on page 67 provides additional information about space requirements. Note: In the Microsoft Explorer Properties dialog box, the Size on disk property for the stub file displays the logical size of the file or its true size on disk, not the file system block size on the primary file system. This size shown is dependent on the quota policy in force on the Celerra Network Server. "Quotas" on page 22 contains more information about quota policy settings. Note: A multiple hop configuration (multihop) allows you to move data from primary to secondary storage, from secondary to tertiary storage, and back. A FileMover-enabled file system can be secondary storage. In a multihop configuration, secondary storage must be the Celerra Network Server while tertiary storage can be the Celerra Network Server or NFS/CIFS file server. Although FileMover supports a multihop configuration up to two hops, your policy engine vendor might not support this functionality. Contact your policy and migration software vendor for the most up-to-date information about multihop configurations. Migrating small files Each stub file occupies a minimum of 8 KB and a maximum of 64 KB of space on primary storage. If you intend to migrate files to release space on primary storage, it is important to realize there is no advantage to migrating any file less than 8 KB. However, if you need to migrate files for compliance purposes, you might choose to migrate files regardless of their size. Note: It is recommended you do not migrate zero-length or empty files to secondary storage as CIFS and NFS protocols never issue a read request against a zero-byte file. Celerra FileMover recalls a zero-byte file only when the file is written to; it does not recall the file if it is read. Orphan file management When a file is migrated from the Celerra Network Server to secondary storage, the original file physically resides on the secondary file server and a stub file replaces the original file on Celerra Network Server. If the stub file on the Celerra Network Server is deleted, the file data on secondary storage becomes orphaned with respect to the Celerra Network Server. If this happens, the Celerra Network Server does not delete the file content on secondary storage. Note: There might be a copy of that stub file in a SnapSure checkpoint of the primary file system, a TimeFinder/FS or Celerra Replicator copy of the primary file system, or on a backup tape that might need to reference the content on the secondary storage. For this reason, it is important that the secondary store file content remain intact. Celerra FileMover does not automatically delete orphan files on the secondary storage. You determine how long you want to retain access to the content on secondary storage through alternative copies of a deleted stub file. Contact your software vendor or refer to your policy and migration software documentation for information about orphan file management and multiversioning of files on secondary storage. 18 of 72

19 Backup strategies Table 2 lists backup behaviors of FileMover-enabled file systems. Table 2 Backup behaviors "Performing an NDMP backup" Back up the stub files and online file content on primary storage Default Back up the contents of migrated files on secondary storage without recalling the files to primary storage Set the NDMP variable to: EMC_OFFLINE_DATA=y "Performing a CIFS network backup" Set the primary FileMover file system -backup option to offline By default, the -backup option is set to passthrough. "Performing an NFS network backup" N/A Set the FileMover file system -read_policy_override option to passthrough. server_archive Default N/A There are two ways to back up FileMover-enabled file systems: backing up from primary only, or backing up from primary and secondary. Backing up from primary only When backing up from primary only, the online file content on primary storage and the migrated file content on secondary storage the offline files are contained in the backup. For NDMP backups, set the NDMP environment variable in your backup software to back up file contents of migrated files on secondary storage. Migrated file content is backed up without recalling the files to primary storage. "Performing an NDMP backup" on page 49 provides instructions about how to set the NDMP environment variable. For CIFS network backups, the -backup option is set to passthrough by default. Files are backed up to the backup application without being recalled to primary storage. For NFS backups, set the -read_policy_override option to passthrough to back up migrated file contents also called offline files without recalling the files to primary storage. You cannot back up the stub files in the primary file system using NFS backup. "Performing an NFS network backup" on page 50 contains procedural information. If the network between primary and secondary is slow, or the secondary server s response is slow, backup performance may be impacted as the data associated with the file from secondary storage is put into the backup stream. Some applications may experience errors, such as time-out. 19 of 72

20 Backing up from primary and secondary By default, NDMP backs up and restores stub files and files that have not migrated from primary storage also called online files. The contents of migrated files or offline files on secondary storage must be backed up independently. For CIFS network backups, set the -backup option to offline to back up stub files and online files the files that have not migrated from primary storage. The contents of migrated files or offline files on the secondary file server must be backed up independently. "Performing a CIFS network backup" on page 49 contains procedural information. For NFS, it is not possible to back up only the stub files. File system usage Use the server_df command to obtain the actual usage of Celerra FileMover file system. If a file is partially recalled from secondary storage, another inode is allocated for this partial file. This command counts all of the files on the Celerra Network Server, including the partially recalled files and stub files. "Integration considerations" on page 21 contains more information about quotas. Network availability For maximum performance and security, consider managing the network traffic between the Celerra Network Server, policy and migration software, and secondary storage to travel via private, high-speed (Gigabit Ethernet) network. In this case, you can use the standard Celerra network traffic monitoring capabilities to monitor the FileMover traffic levels in the environment. You can use trunking, Fail-Safe Network, and LACP to maintain a high-availability network between the Celerra Network Server and secondary storage. There is no automatic network failover functionality in Celerra FileMover. The Configuring and Managing Celerra Network High Availability technical module provides additional information. Note: When the network between primary and secondary storage is slow or the secondary server s response is slow based on access time to the connected device, some applications might experience errors, such as time-out. Read-only file systems Changes to parameters at the connection and file system level on a read-only Celerra FileMover-enabled file system are not persistent; they are in memory only. Reboots or remounts cause the settings to revert to their former state. 20 of 72

21 Interactions between Celerra FileMover and your applications It is important to understand file system usage as well as the behavior of the applications associated with the Celerra FileMover file system. For example, some applications cause migrated files to be recalled unexpectedly. When you perform a content search, Celerra FileMover reads the content of migrated files from secondary storage in the same manner as all other read request operations. However, in an environment where content searching is performed, it is strongly recommended you set the migration method to passthrough to avoid data from being mistakenly recalled to primary storage. File system scanning performance EMC has enhanced Celerra FileMover to improve file system scanning performance for policy and migration software. The metadata attributes retrieval operation allows a FileMover policy and migration software to scan a file system and locate files matching criteria defined by the policy and migration software. A variety of search criteria can be specified in the scan request, such as timestamp, file size, and file type. When matching files are found, the metadata or file attributes associated with those files are written to an output file located on a Celerra file system. Because the content of output files may be sensitive in nature, EMC strongly recommends creating a file system specifically to hold output files and be accessible only to the policy and migration software that initiated the metadata retrieval request. Under normal circumstances, the policy and migration software deletes output files no longer required. Occasionally, the administrator may have to clean up output files if the policy and migration software fails to do this. Integration considerations This section provides information important to consider to ensure successful integration with Celerra FileMover using the following applications: "Quotas" on page 22 "AntiVirus scanning" on page 23 "SnapSure" on page 23 "Replicator, TimeFinder/FS, TimeFinder NearCopy, and FarCopy" on page 24 "Multi-Path File System (MPFS)" on page 24 "Virtual Data Mover" on page 24 "International character sets" on page 24 "FS linking" on page 25 "Nested mount file system (NMFS)" on page of 72

22 "File-Level Retention (FLR)" on page 25 "CDMS" on page 25 Quotas When you set file system quotas on a Celerra Network Server, those quotas monitor and control the usage of only the primary file systems on that Celerra system. The quotas on the Celerra Network Server do not monitor or control the usage of the secondary storage file systems. Thus, quotas set on the Celerra Network Server do not affect or reflect usage on the secondary storage systems. The Celerra Network Server can track quotas using either of two quota policies. By default, the quota policy is set to blocks. When configured to use the blocks quota policy the Celerra Network Server calculates disk usage by counting the number of file system blocks each file occupies on disk. For example, a 1 KB file counts as 8 KB in the quota because the file consumes one 8 KB block on disk. As the content of files migrates to secondary storage, the Celerra Network Server quota usage decreases because the number of blocks occupied in the primary file system on the Celerra is reduced. Likewise, Celerra quota usage increases as files are recalled from secondary storage and begin to occupy blocks in the primary file system on the Celerra Network Server again. If quota policy is set to filesize, disk usage is calculated in logical file size, which means a 1 KB file counts as 1 KB in the quota. When using the filesize quota policy Celerra quota usage is unaffected by file migration and recall operations because these operations do not impact the logical size of files. In this case, the reported size on disk of each file is approximately the same as the reported logical size of the file. When calculating the storage required in the primary file system on the Celerra Network Server remember that each migrated file consumes one inode, regardless of the quota policy setting. Each migrated file will also consume one 8 KB data block in the primary file system. In addition, the Celerra Network Server will allocate an additional inode in the primary file system both while it converts an unmigrated file in the primary file system into a stub file, and while it recalls the content of a migrated file from secondary storage to the primary file system. These temporary inodes count toward any inode-based quotas in use. It is strongly recommended you avoid letting the system reach hard inode quota limits to avoid disrupting FileMover-related activity. The server_df command always displays the inodes and blocks in use in the primary file system on the Celerra Network Server. The Using Quotas on Celerra technical module provides additional information about setting quotas. Note: If the file system is out of space, is mounted read-only, or a quota limit is encountered, the method specified in the stub file or connection database is overridden and the passthrough read method is used. In this case, any files partially recalled to the primary file system will continue to occupy space in the primary file system until they are cleaned up by the policy and migration software. The presence of such partially recalled files does not affect the users ability to access the data. 22 of 72

23 AntiVirus scanning Using the Celerra AntiVirus Agent (CAVA), the write operation proceeds as usual. Regarding scan-on-read operation, the scan operation does not cause data to be recalled; data is read using the passthrough migration method from the AntiVirus (AV) server. Using CAVA, -fsscan options scan all the files on the file system. By default, stub files are skipped. Using the -fsscan -create offline option, stub files are scanned. The scan operation does not cause data to be recalled; data is read using the passthrough option from the secondary storage. For network drive scan from the AV server without CAVA, the read operation does not fall back to the passthrough method as it does with CAVA. Instead, it follows the read policy setting in the Celerra FileMover configuration. In addition, AV applications may or may not scan stub files depending on whether they recognize the Server Message Block (SMB) offline file attribute set on all migrated files by default. The -offline_attr off option of the fs_dhsm command might change the behavior of the AV server as it disables the offline bit in the SMB protocol file attribute. EMC recommends the use of CAVA for AV scanning of Celerra file systems rather than network drive scanning. Contact your AV software vendor for information about how the AV application handles stub files. Note: For safety when performing a full file system scan using an external AV server, set the -read_policy_override command to the passthrough option while files are being scanned. "Scanning applications" on page 48 contains procedural information. SnapSure You can create a checkpoint of a Celerra FileMover-enabled file system. Because a checkpoint is read-only, any attempt to access a stub file contained within the checkpoint causes the file data to be read from secondary storage using the passthrough option. The file content is not recalled from secondary storage in response to the client request. Celerra FileMover configuration information is stored in a Celerra FileMover file system. Restoring from a checkpoint restores the configuration prior to any subsequent modification occurring after the checkpoint.!!caution If stub files are restored from a SnapSure checkpoint with an mtime different from the mtime of the original file, depending on the policy and migration software in use, the data may be unavailable on the primary file system. This caution also applies to tape backup, a BCV for either TimeFinder/FS or TimeFinder/FS NearCopy (which uses SRDF/S), or an STD volume for TimeFinder/FS FarCopy (which uses SRDF adaptive copy write pending mode). Contact your software vendor to determine whether your policy and migration software supports multiple file migration. 23 of 72

24 Replicator, TimeFinder/FS, TimeFinder NearCopy, and FarCopy You can create replicated copies of a Celerra FileMover-enabled file system. Because the secondary file system of Replicator is read-only, any attempt to access a stub file on the secondary file system causes the file to be read in the passthrough method. The file content can be read, but is not recalled from secondary storage in response to the client request. If you are using CIFS connections on the primary storage, the CIFS server on the secondary side of Replicator must be in the same domain as the CIFS server on the primary Data Mover. Otherwise, the CIFS connections on the replicated file system do not work, and attempts to access stub files on the replicated file system result in I/O errors. When you access files on the primary file system of Replicator, the behavior is the same as in a typical Celerra FileMover-enabled file system. If NFS is used to make a connection to the secondary storage, Celerra FileMover uses any available network interface to make the connection because the network interface is different on the secondary side of Replicator. This behavior applies to a BCV for either TimeFinder/FS or TimeFinder/FS NearCopy (which uses SRDF/S), or an STD volume for TimeFinder FarCopy (which uses SRDF adaptive copy write pending mode). Note: In each of the previously mentioned cases, the Data Mover that mounts the copy of the primary file system must have network connectivity to the secondary storage. Otherwise, it cannot retrieve migrated content from secondary storage when clients access stub files in the copy of the primary file system. Multi-Path File System (MPFS) If a migrated file on a Celerra FileMover system is accessed by a MPFS client, the MPFS client is notified and all subsequent I/O requests will use the client s native protocol NFS or CIFS. Note: An application on the MPFS client is not affected, except that it will likely experience some performance degradation if it accesses a migrated file. Virtual Data Mover Virtual Data Mover (VDM) file systems can be used as primary and secondary data stores. Note however that the Celerra FileMover API security, managed via the server_http command, is implemented at the physical Data Mover level. This means that when using the server_http command to configure Celerra FileMover API security you must specify the physical Data Mover hosting the VDM as the target of the command, not the VDM itself. It also means if the VDM is moved to another Data Mover, in the same or a different Celerra, you must ensure that you have configured the API security on the new Data Mover appropriately. You can also alter the API security on the Data Mover that the VDM has moved from. International character sets Unicode must be enabled on the Data Mover that mounts a Celerra FileMoverenabled file system. 24 of 72

25 Even if Unicode is enabled, any non-ascii filename not converted to UTF-8 cannot be migrated using the policy and migration software. You must convert the non- ASCII filenames before using Celerra FileMover. This applies to non-ascii filenames created from an NFS client with a locale that does not match the Celerra encoding information from the client. The primary Celerra Network Server, secondary file server, and policy and migration software all must use the same locale. Note: Contact your software vendor directly or refer to your policy and migration software documentation for information about international character sets. FS linking Celerra FileMover must be enabled at each file system level. Each file system must have a connection to secondary storage. Nested mount file system (NMFS) Celerra FileMover cannot be enabled on the nested mount root file system. If you are using nested mount file systems (NMFS) to access stub files, you must enable Celerra FileMover and create connections on all the individual component file systems containing stub files. File-Level Retention (FLR) You cannot use an FLR file system as primary storage in a FileMover environment. However, it is possible to create a new FLR file system as secondary storage. Contact your software vendor to determine whether your policy and migration software supports this configuration. Note that a file in the FLR state on secondary storage cannot be altered or deleted by NAS clients or users. An FLR file can be deleted only after its retention period expires. The Using File-Level Retention on Celerra technical module provides additional information about file-level retention storage technology and FLR file system behavior. CDMS FileMover cannot be used with CDMS. You cannot enable the FileMover functionality on an MGFS file system. FileMover cannot be used to migrate data out of file system while you are using CDMS to migrate data into it. You can enable FileMover on a file system only after you have finished using CDMS and converted the file system to UxFS. 25 of 72

26 User interface choices This technical module describes how to set and manage the Celerra Network Server side of Celerra FileMover using the command line interface (CLI). You cannot use other Celerra management applications to configure Celerra FileMover. 26 of 72

27 Celerra FileMover roadmap This section lists the tasks for configuring and managing Celerra FileMover connections. FileMover configuration tasks: 1. "Enabling Celerra FileMover" on page "Creating a connection" on page "Configuring API security" on page 34 FileMover administrative tasks: "Managing the Celerra FileMover connection" on page 37 "Celerra FileMover administration" on page of 72

28 Enabling Celerra FileMover Enabling Celerra FileMover Creating a connection Configuring API security Managing the Celerra FileMover connection Celerra FileMover administration You can enable Celerra FileMover functionality on a mounted file system via the Control Station CLI. These settings remain persistent across remounts unless the file system is mounted read-only. When you enable Celerra FileMover, it must be enabled on a uxfs file system that is mounted read/write. Action To enable Celerra FileMover functionality on a Data Mover, use this command syntax: $ fs_dhsm -modify <fs_name> -state {enabled disabled} Where: <fs_name> = name of the file system on which you want to enable Celerra FileMover Example: To enable Celerra FileMover on a file system pri_ufs1, type: $ fs_dhsm modify pri_ufs1 state enabled Output pri_ufs1: state = enabled offline attr = on popup timeout = 0 backup = passthrough read policy override = none log file = on max log size = 10MB Done 28 of 72

29 Creating a connection Enabling Celerra FileMover Creating a connection Configuring API security Managing the Celerra FileMover connection Celerra FileMover administration The following section provides instructions for setting up CIFS, NFS, and HTTP connections to the secondary store. A connection ID or <cid> is automatically created when a connection is established. Use the fs_dhsm -list option to display connection information. Creating a CIFS connection You can create a connection using the CIFS protocol between the specified file system and a secondary file system. To create a CIFS connection, you must specify the username and password that matches the username and password stored on the domain controller or in Active Directory in the CIFS environment. The username and password is reused each time that CIFS connection is established. Note: When creating a CIFS connection, do not use a share that references a Distributed File System (DFS) link. If the fully-qualified domain name of the CIFS file server acting as primary storage for the connection is not explicitly set, the Control Station appends the domain name. You cannot use an IP address to specify the secondary server in a CIFS connection. EMC strongly recommends you use fully-qualified domain names where domain names are required. 29 of 72

30 Action To create a CIFS connection on the file system, use this command syntax: $ fs_dhsm -connection <fs_name> -create -type cifs -admin <fqdn>\<admin_name> -secondary <\\<fqdn>\<share>\<path>> -local_server <cifs_server> Where: <fs_name> = name of the Celerra FileMover-enabled file system from which files are migrated to secondary storage accessible via this connection <fqdn> = fully qualified domain name of secondary CIFS server <admin_name> = username used to make the CIFS connection <share> = fully qualified domain name of the secondary server and its sharename <path> = (optional) base path within the share on the secondary server under which all migrated files reside <cifs_server> = computer name or NetBIOS name of the local CIFS file server acting as primary storage on the Data Mover Note: The user does not have to be a domain administrator but must have administrator privileges to access the migrated files on secondary storage. Example: To create a CIFS connection from ufs1 to wichita.nasdocs.emc.com\dhsm2, type: $ fs_dhsm -connection ufs1 -create -type cifs -admin 'nasdocs.emc.com\administrator' -secondary '\\wichita.nasdocs.emc.com\dhsm2' -local_server dm112-cge0 Note: You must use single quotes when you include backslashes in the command line. Output Enter Password:******* ufs1: state = enabled offline attr = on popup timeout = 0 backup = passthrough read policy override = none log file = on max log size = 10MB cid = 1 type = CIFS source = \\wichita.nasdocs.emc.com\dhsm2\ state = enabled read policy override = none write policy = full local_server = DM112-CGE0.NASDOCS.EMC.COM Done Note: To establish a Celerra FileMover connection between Windows domains, specify the domain\name using -admin. For example, if the Celerra Network Server belongs to abc.com and the secondary file server belongs to xyz.com, type: -admin 'xyz.com\administrator'. 30 of 72

31 Note: You can associate up to 1,024 secondary storage connections with a single primary file system; storage space can be spread over a number of devices. Enabling Celerra FileMover Creating a connection Configuring API security Creating an NFS connection You can create a connection using the NFS protocol between the specified file system and a secondary file system. The secondary file system stores the migrated files. EMC recommends that you use the -userootcred option to specify the user credentials the Data Mover uses when requesting data from the secondary Celerra Network Server. When set to true, the Data Mover requests data as the root user (UID 0); the secondary storage NFS server must grant the Data Mover root privilege for NFS traffic. When set to false (default), the Data Mover requests data as the owner of the file as specified in the stub file. Contact your policy and migration software vendor for the most up-to-date information about NFS connections to a secondary server. Action Managing the Celerra FileMover connection Celerra FileMover administration To create an NFS connection on the file system, use this command syntax: $ fs_dhsm -connection <fs_name> -create -type {nfsv3 nfsv2} -secondary <nfs_server>:/<src_path> -userootcred {true false} Where: <fs_name> = name of the file system on which you want to enable Celerra FileMover <nfs_server> = name or IP address of the NFS server <src_path> = location of the remote file system Note: Although you can specify an IP address for <host>, EMC suggests that you use the hostname of the server. Example: To create an NFSv3 connection for ufs1 to nasdocs.emc.com:/dest with -userootcred set to true, type: $ fs_dhsm connection ufs1 create -type nfsv3 -secondary nasdocs.emc.com:/dest -userootcred true Output source: state = enabled offline attr = on popup timeout = 0 backup = passthrough read policy override = none log file = on max log size = 10MB cid = 0 type = NFSV3 source = nasdocs.emc.com:/dest state = enabled read policy override = none write policy = full options = userootcred=true Done 31 of 72

32 Creating an HTTP connection Enabling Celerra FileMover Creating a connection Configuring API security Managing the Celerra FileMover connection Celerra FileMover administration A FileMover HTTP connection is a virtual circuit between two endpoints: a Celerra file system and a portion of the namespace published by a web server. You can create an HTTP connection between a primary and secondary file system to access migrated files on secondary storage. An HTTP connection allows you to integrate Celerra Network Server with a web server. There are two types of HTTP connections: CGI and non-cgi. Use the -cgi option to specify the type of HTTP connection you want to create. By default, Celerra FileMover assumes a web server hosted on the secondary storage is using CGI connections to access migrated file data via a CGI application. When -cgi option is set to yes, you must configure the application to send an HTTP response by the application and/or web server describing the status of the health of the secondary storage. CGI connections require the -secondary option be used to identify the CGI application that will provide access to a backend storage system. If basic or digest authentication is required by the secondary storage HTTP server, use the -user and -password options to create the HTTP connection. When an HTTP server stops responding, the next IP address mapping to the server s hostname is used to satisfy the user s read request without interruption. By default, the Celerra HTTP client waits 30 seconds for a reply from the HTTP server and then retries the operation. Use the -timeout option to increase the time the Celerra waits for a response from the web server after it sends a request. The Data Mover selects a local port that issues HTTP requests to the web server running on secondary storage, and issues HTTP requests to port 80 on the secondary storage HTTP server. Use -localport or -httpport option to modify the local and remote ports, respectively. Use this procedure to create a non-cgi HTTP connection. Action To create a non-cgi HTTP connection: $ fs_dhsm -connection <fs_name> -create -type http -secondary -cgi <y n> -timeout <seconds> Where: <fs_name> = name of the file system on which you want to enable Celerra FileMover <host> = hostname of the server running the secondary storage HTTP server <url_path> = location of the application used to access secondary storage <seconds> = time-out value for reply from the HTTP server, in seconds Note: Although you can specify an IP address for <host>, EMC strongly suggests that you use the hostname of the server, which allows you to take advantage of DNS failover capability. Note: For non-cgi connections, FileMover assumes that the web server has direct access to secondary storage content. In this case, providing a URL path in the -secondary option is optional. Example: To create an HTTP connection from pri_ufs1 to type: $ fs_dhsm connection pri_ufs1 create -type http -secondary -cgi n -timeout of 72

33 Output pri_ufs1: state = enabled offline attr = on popup timeout = 0 backup = passthrough read policy override = none log file = on max log size = 10MB cid = 0 type = HTTP secondary = state = enabled read policy override = none write policy = full user = options = timeout=30 cgi=n Done Note: If you attempt to create multiple connections using identical endpoints with different attributes such as: -cgi, -user, -password, -localport, -httpport, the connection will fail. Use this procedure to create a CGI HTTP connection. Enabling Celerra FileMover Creating a connection Configuring API security Action To create a CGI HTTP connection: $ fs_dhsm -connection <fs_name> -create -type http -secondary -cgi <y n> -timeout <sec> Example: To create an HTTP connection from pri_ufs1 to type: $ fs_dhsm connection pri_ufs1 -create -type http -secondary -cgi y -timeout 30 Output Managing the Celerra FileMover connection Celerra FileMover administration pri_ufs1: state = enabled offline attr = on popup timeout = 0 backup = passthrough read policy override = none log file = on max log size = 10MB cid = 0 type = HTTP secondary = state = enabled read policy override = none write policy = full user = options = timeout=30 cgi=y Done 33 of 72

34 Configuring API security Enabling Celerra FileMover Creating a connection Configuring API security FileMover API security administration is done on the Control Station. You can use server_http command to modify the HTTP server on the Data Mover to restrict access to the Celerra FileMover API service based on the IP address of the policy and migration software server. Optionally, the HTTP protocol can use digest authentication to permit only specified users access to the Celerra FileMover API. Note: Policy and migration software must be run on a separate external server, not the Celerra Network Server. Configuring access based on IP address Use this procedure to permit access to the Celerra FileMover API service based on the IP address of the policy and migration software server. Action Managing the Celerra FileMover connection Celerra FileMover administration To configure access based on the IP address of the policy and migration software server, use this command syntax: $ server_http <movername> -append dhsm -hosts <ipaddress> Where: <movername> = name of the specified Data Mover <hosts> = IP address of the policy and migration software host Example: To allow the policy and migration software running on a host with IP address to access the Celerra FileMover API on server_2, type: $ server_http server_2 -append dhsm -hosts Output server_2: done 34 of 72

35 Creating a Celerra FileMover user account Enabling Celerra FileMover Creating a connection Configuring API security If digest access authentication is required, the policy and migration software must use a username and password to issue Celerra FileMover API requests to the Data Mover HTTP server. Use the server_user command as root on the Celerra Control Station to create a user account on the Data Mover that hosts the Celerra FileMover-enabled file system. You can create as many user accounts as you need. Celerra FileMover user accounts require MD5 password encryption; use the -md5 option. Action To create a Celerra FileMover user account to support Celerra FileMover access, use this command syntax: # /nas/sbin/server_user <movername> -add -md5 -passwd <name> Where: <movername> = name of the specified Data Mover (or IP address) <name> = name of Celerra FileMover user account Note: -md5 must be used in order to support Celerra FileMover. Managing the Celerra FileMover connection Celerra FileMover administration Note: The username and password are important for the policy and migration software. EMC recommends you avoid using a user or group identifier (UID or GID) that might be in use. The Configuring Celerra User Mapping technical module contains additional information about user and group identifiers. Example: To create a new user for md5 on server_3, type: # /nas/sbin/server_user server_3 -add -md5 -passwd user1 Output Creating new user user1 User ID: 1000 Group ID: 1000 Home Directory: Changing password for user user1 New password: Retype new passwd: 35 of 72

36 Enabling Celerra FileMover Creating a connection Configuring API security Configuring digest access authentication The HTTP server can also be configured to permit only specified users to access the Celerra FileMover API. Upon completion, every attempt to access the FileMover API is challenged and requires digest authentication to proceed. If the valid user is set, all users in the Data Mover's local passwd file can authenticate for access to the Celerra FileMover API. Use a comma-separated list to specify multiple users. If users are not set, digest authentication is not required and all users have access. Use this procedure to configure digest authentication. Action Managing the Celerra FileMover connection Celerra FileMover administration To specify users allowed to digest authenticate to the HTTP server, use this command syntax: $ server_http <movername> -append dhsm -users {valid <user>[,<user>,<user>...]} -hosts <ipaddress> Where: <movername> = name of the specified Data Mover <user> = user permitted to administer Celerra FileMover commands <ipaddress> = IP address of the secondary storage host Example: To configure server_2 to allow all users to digest authenticate from , type: $ server_http server_2 -append dhsm -users valid -hosts Output server_2: done Listing HTTP connection information Action To display HTTP connection information, use this command syntax: $ server_http <movername> -info dhsm Where: <movername> = name of the specified Data Mover Example: To display connection information for server_2, type: $ server_http server_2 -info dhsm Output server_2: DHSM: users: <all valid users> allowed IPs: threads: 20 Note The default output is <no user authentication>. 36 of 72

37 Managing the Celerra FileMover connection Enabling Celerra FileMover The following sections provide instructions for managing CIFS and NFS connections to secondary storage. Table 3 Celerra FileMover management tasks Creating a connection Configuring API security Management Task Modify connection attributes on the file system. List one or more Celerra FileMover-enabled connections on the file system. Procedure "Modifying a connection" "Listing Celerra FileMover connections" on page 39 List detailed information about a particular connection on the file system. "Listing connection information" on page 39 Delete a Celerra FileMover connection on the file system. "Deleting a Celerra FileMover connection" on page 41 Managing the Celerra FileMover connection Celerra Using DHSM FileMover API administration Commands Modifying a connection When you modify a CIFS, NFS, or HTTP connection, the change is effective immediately. Although you may experience a slight delay, there is no impact on the client. Use this procedure to modify a Celerra FileMover connection. Action To modify the connection attributes on the file system, use this command syntax: $ fs_dhsm -connection <fs_name> -modify {-all <cid>[,<cid>...]} Where: <fs_name> = name of the file system <cid> = connection ID Example: To modify read policy override setting for connection 0 for the file system ufs1, type: $ fs_dhsm -connection ufs1 -modify 0 -read_policy_override partial 37 of 72

38 Output ufs1: state = enabled offline attr = on popup timeout = 0 backup = passthrough read policy override = none log file = on max log size = 10MB cid = 0 type = CIFS secondary = \\wichita.nasdocs.emc.com\dhsm1\ state = enabled read policy override = partial write policy = full local_server = DM112-CGE0.NASDOCS.EMC.COM cid = 1 type = CIFS secondary = \\wichita.nasdocs.emc.com\dhsm2\ state = enabled read policy override = full write policy = full local_server = DM112-CGE0.NASDOCS.EMC.COM Done 38 of 72

39 Listing Celerra FileMover connections Action To list one or all of the Celerra FileMover-enabled connections on the file system, use this command syntax: $ fs_dhsm -connection <fs_name> -list Where: <fs_name> = name of the FileMover-enabled file system Example: To list Celerra FileMover connections for ufs1, type: $ fs_dhsm -connection ufs1 -list Output id name cid 22 ufs ufs1 1 Note Column definitions: id file system ID name name of the file system cid connection ID Listing connection information Action To list all the information about a given connection, use this command syntax: $ fs_dhsm -connection <fs_name> -info Where: <fs_name> = name of the FileMover-enabled file system Example: To list ufs1 connection information, type: $ fs_dhsm -connection ufs1 -info 39 of 72

40 Output ufs1: state = enabled offline attr = on popup timeout = 0 backup = passthrough read policy override = none log file = on max log size = 1MB cid = 0 type = CIFS source = \\wichita.nasdocs.emc.com\dhsm1\ state = enabled read policy override = none write policy = full local_server = DM112-CGE0.NASDOCS.EMC.COM cid = 1 type = NFSV3 source = nasdocs.emc.com:/home/dhsm2 state = enabled read policy override = none write policy = full options = 40 of 72

41 Enabling Celerra FileMover Creating a connection Configuring API security Deleting a Celerra FileMover connection When you delete an NFS, CIFS, or HTTP connection, use the -recall_policy option to specify whether the Celerra Network Server should recall all migrated files relying on the connection to primary storage before deleting the connection. The -recall_policy option default is check. The file system checks for stub files and causes the delete operation to fail at the first stub file found. Set the -recall_policy option to no only when you are certain the stub files are no longer needed to recall file data. When the FileMover connection no longer exists, a read request to the stub file causes an I/O error to appear. To regain access to migrated file data, reestablish the FileMover connection using exactly the same secondary path initially specified. Action Managing the Celerra FileMover connection Celerra Using DHSM FileMover API administration Commands To delete a Celerra FileMover connection from the file system, use this command syntax: $ fs_dhsm -connection <fs_name> -delete <cid> -recall_policy {check no yes} Where: <fs_name> = name of the FileMover-enabled file system <cid> = connection ID Example: To delete the Celerra FileMover connection from ufs1 and recall the files back to the Celerra Network Server, type: $ fs_dhsm connection usf1 delete 1 recall_policy yes If the -recall_policy option is set to yes: Migrated files are recalled to the Celerra Network Server before the connection is removed. The delete operation can take some time to complete depending on the size of the file system. During this time, you can continue to access all the files regardless of whether the file is migrated. 41 of 72

42 Output ufs1: state = enabled offline attr = on popup timeout = 10 backup = offline read policy override = full log file = on max log size = 10MB cid = 0 type = CIFS source = \\wichita.nasdocs.emc.com\dhsm1\ state = recallonly read policy override = none write policy = full local_server = DM112-CGE0.NASDOCS.EMC.COM cid = 1 type = NFSV3 source = emcdocs.emc.com:/home/dhsm2 state = enabled read policy override = none write policy = full options = Done You can use a UNIX client to locate stub files mentioned in the server_log output. The stub file inode is identified as node <inode number> is offline,abort. To locate stub files in the server_log file, use find /<directory> -inum <inode number> or ls -lria. Events can be issued when the delete operation is complete. Use facility number 75 and event ID 0. The Configuring Celerra Events and Notifications technical module contains more information about events. 42 of 72

43 Celerra FileMover administration Enabling Celerra FileMover The following sections provide instructions for performing a variety of tasks on Celerra FileMover-enabled CIFS and NFS file systems. Table 4 Celerra FileMover administration tasks Creating a connection Configuring API security Task Change a CIFS administrator username or password. Disable Celerra FileMover logging on the file system. Procedure "Changing a CIFS password" on page 44 "Disabling Celerra FileMover logging" on page 46 Increase log file size. "Increasing log file size" on page 47 Scan applications. "Scanning applications" on page 48 Back up Celerra FileMover-enabled file systems via NDMP. "Performing an NDMP backup" on page 49 Managing the Celerra FileMover connection Celerra FileMover administration Back up Celerra FileMover-enabled file systems via CIFS. Back up Celerra FileMover-enabled file systems via NFS. "Performing a CIFS network backup" on page 49 "Performing an NFS network backup" on page 50 Enable pop-up notification for CIFS clients. "Enabling pop-up notification (CIFS only)" on page 52 Adjust offline file attributes. "Adjusting offline attribute settings" on page 53 Increase the number of HTTP threads on the Data Mover. Increase the number of threads to read data from secondary storage. Copy or move FileMover stub files. "Tuning HTTP threads" on page 53 "Tuning threads to read data from secondary storage" on page 54 "Moving Celerra FileMover stub files" on page 55 Disable Celerra FileMover. "Disabling FileMover functionality" on page of 72

44 Enabling Celerra FileMover Creating a connection Configuring API security Changing a CIFS password To ensure security, your organization may require you to change user passwords on a regular basis. The administrator password on the Celerra FileMover connection must match the administrator password in the CIFS environment. Note: The username and password for a CIFS connection is different than the username and password used to manage Celerra FileMover API security. Use this procedure to change a CIFS password. Step Action 1. List all Celerra FileMover-enabled file systems, using this command syntax: $ fs_dhsm -connection <fs_name> -list Managing the Celerra FileMover connection Celerra FileMover administration 2. List connection information for each Celerra FileMover-enabled file system to confirm the sessions for Celerra FileMover, using this command syntax: $ fs_dhsm -connection <fs_name> -info This action queries whether a session exists. If one does not, a session is established. CIFS sessions are triggered under the following conditions: Stub files have been accessed. A new connection was created. The fs_dhsm command was used to list connection information. However, if a session does exist, the actions listed do not trigger a connection. The Data Mover always keeps the session until the connection is disconnected, CIFS stops, or umount of the file system. 3. Disable the Celerra FileMover connection, using this command syntax: $ fs_dhsm -connection <fs_name> -modify {-all <cid>[,<cid>...]} -state {enabled disabled} Where: <fs_name> = name of the file system <cid> = connection ID Example: To disable all Celerra FileMover connections on ufs1, type: $ fs_dhsm -connection ufs1 -modify -all -state disabled To disable Celerra FileMover connections 1 and 3 on ufs1, type: $ fs_dhsm -connection ufs1 -modify 1,3 -state disabled 4. Change the user password on the Windows server or domain controller. 44 of 72

45 Step Action 5. Change the CIFS administrator password on a Celerra FileMover connection, using this command syntax: $ fs_dhsm -connection <fs_name> -modify {-all <cid>[,<cid>...]} password <password> Where: <fs_name> = name of the file system <cid> = connection ID <password> = the specified administrator password Note: If the -password option is given but a password is not specified, the user is prompted interactively. Example: To change the administrator password on all Celerra FileMover connections on ufs1, type: $ fs_dhsm connection ufs1 modify -all password Enter Password: ****** To disable Celerra FileMover connections 1 and 3 on ufs1, type: $ fs_dhsm -connection ufs1 -modify 1,3 -password Enter Password: ****** 6. Enable the disabled FileMover connection, using this command syntax: $ fs_dhsm -connection <fs_name> -modify {-all <cid>[,<cid>...]} -state {enabled disabled} Where: <fs_name> = name of the file system <cid> = connection ID Example: To enable all Celerra FileMover connections on ufs1, type: $ fs_dhsm -connection ufs1 -modify -all -state enabled To enable Celerra FileMover connections 1 and 3 on ufs1, type: $ fs_dhsm -connection ufs1 -modify 1,3 -state enabled 45 of 72

46 Enabling Celerra FileMover Creating a connection Configuring API security Managing the Celerra FileMover connection Celerra FileMover administration Disabling Celerra FileMover logging By default, the Celerra Network Server logs all stub file activity, which includes all events associated with creating, modifying, and deleting stub files. The default log filename is dhsm.log; it resides in the /.etc directory on the Celerra FileMoverenabled file system and is accessible by the policy and migration software. "Appendix A: Celerra FileMover log file example" on page 66 contains additional information about Celerra FileMover log files. Stub file event activity is written to read/write file systems only; there is no logging of stub file events on read-only file systems. You cannot modify logging parameters on a read-only file system. When logging events exceed the size of the log file, a new log file is created. A maximum of five log files are kept at any given time; the oldest log file is replaced in sequential order. If the primary file system is running low on space, you can delete the old dhsm.log files in the /.etc directory to free the space they occupy. EMC recommends you disable logging on the primary file system before removing any dhsm_log.* files.!!caution When you are working with Celerra FileMover log files in the /.etc directory of the primary file system, be careful not to touch any other files in the same directory. Action To disable Celerra FileMover logging, use this command syntax: $ fs_dhsm -modify <fs_name> -log off Where: <fs_name> = name of the FileMover-enabled file system Example: To disable Celerra FileMover logging, type: $ fs_dhsm -modify ufs1 -log off Output ufs1: state = enabled offline attr = on popup timeout = 0 backup = passthrough read policy override = none log file = off max log size = 10MB cid = 0 type = CIFS source = \\wichita.nasdocs.emc.com\dhsm1\ state = enabled read policy override = none write policy = full local_server = DM112_CGE0.NASDOCS.EMC.COM Done 46 of 72

47 Enabling Celerra FileMover Creating a connection Configuring API security Increasing log file size The default Celerra FileMover log file size is 10 MB; this is also the minimum log size. Although you cannot decrease the size below the minimum, you can increase the log file size. Action To increase the log file size, use this command syntax: $ fs_dhsm -modify <fs_name> -max_log_size <mb> Where: <fs_name> = name of the FileMover-enabled file system <mb> = log file size in megabytes Example: To increase the log file size to 20 MB on ufs1, type: $ fs_dhsm -modify ufs1 -max_log_size 20 Output Managing the Celerra FileMover connection Celerra FileMover administration ufs1: state = enabled offline attr = on popup timeout = 0 backup = passthrough read policy override = none log file = on max log size = 20MB cid = 0 type = CIFS source = \\wichita.nasdocs.emc.com\dhsm1\ state = enabled read policy override = none write policy = full local_server = DM112_CGE0.NASDOCS.EMC.COM 47 of 72

48 Enabling Celerra FileMover Creating a connection Configuring API security Scanning applications If you employed an application that uses CIFS or NFS to scan a Celerra FileMoverenabled file system, consider setting the -read_policy_override option to passthrough for the duration of the file system scan to avoid recalling files from secondary to primary storage. Examples of such applications are: NFS backups, antivirus software, and Microsoft Explorer file content searches. Use this procedure to scan applications without causing data to be recalled from secondary storage. Action To enable passthrough reads while scanning applications, use this command syntax: $ fs_dhsm -modify <fs_name> -read_policy_override passthrough Where: <fs_name> = name of the FileMover-enabled file system Example: To enable a passthrough read while scanning file system ufs1, type: $ fs_dhsm -modify ufs1 -read_policy_override passthrough Managing the Celerra FileMover connection Celerra FileMover administration Output ufs1: state = enabled offline attr = on popup timeout = 0 backup = passthrough read policy override = passthrough log file = on max log size = 10MB cid = 0 type = CIFS source = \\wichita.nasdocs.emc.com\dhsm1\ state = enabled read policy override = none write policy = full local_server = DM112_CGE0.NASDOCS.EMC.COM Done Note: To use the Windows offline folder synchronization feature on a Celerra FileMoverenabled file system, the -read_policy_override option must be set to passthrough for any files synchronized with users machines. If passthrough is not specified, the migrated files are recalled to the Celerra Network Server every time a user synchronizes their local machine with the shared files because the operation prompts a read of the migrated files. Note: Zip files might be recalled when Microsoft Explorer reads them during a file/folder name search. 48 of 72

49 Performing an NDMP backup Enabling Celerra FileMover Creating a connection Configuring API security By default, when NDMP backup runs, it backs up the stub files. The backup option of the fs_dhsm command has no impact on an NDMP backup. When an NDMP backup is performed with the environment variable EMC_OFFLINE_DATA=n, which is the default configuration, only the primary storage content is backed up. When you restore such a file system, the stub files are restored and continue to serve as pointers to access the file content on secondary storage. The file content remains on secondary storage as long as its associated policy dictates. In this case, the contents of all migrated files on the secondary file server must be backed up independently. You can also choose to set the NDMP environment variable to read the contents of each migrated file from secondary storage without recalling the files to primary storage and back up the file contents to a tape drive if this is the action you want. Action Managing the Celerra FileMover connection To set the NDMP environment variable on the backup application server, include the following text in the backup job definition: EMC_OFFLINE_DATA=y Celerra FileMover administration Performing a CIFS network backup By default, a backup using CIFS causes the file content on secondary storage to be read using passthrough. The files are backed up to the backup application and not recalled to primary storage. The data is read from secondary storage to the backup stream via local area network. Set the -backup option to offline to back up stub files and files that have not migrated from primary storage. Note: This command applies only to CIFS network backup. It does not apply to NDMP, NFS, or server_archive backups. Action To back up only the stub files to the CIFS backup application, use the command syntax: $ fs_dhsm -modify <fs_name> -backup {offline passthrough} Where: <fs_name> = name of the FileMover-enabled file system Example: To back up stub files on ufs1 using the offline method, type: $ fs_dhsm -modify ufs1 -backup offline 49 of 72

50 Output ufs1: state = enabled offline attr = on popup timeout = 0 backup = offline read policy override = none log file = on max log size = 10MB cid = 0 type = CIFS source = \\wichita.nasdocs.emc.com\dhsm1\ state = enabled read policy override = none write policy = full local_server = DM112_CGE0.NASDOCS.EMC.COM Done Enabling Celerra FileMover Creating a connection Configuring API security Performing an NFS network backup Set the -read_policy_override option to passthrough to perform an NFS backup operation that does not recall migrated file content to primary storage. There is no option to back up only the stub files when you back up via NFS network. Use this procedure to back up via NFS network. Action To perform an NFS backup, use the command syntax: $ fs_dhsm -modify <fs_name> -read_policy_override {full partial passthrough none} Where: <fs_name> = name of the FileMover-enabled file system Example: To back up all the file data on ufs1 using passthrough, type: $ fs_dhsm -modify ufs1 -read_policy_override passthrough Managing the Celerra FileMover connection Celerra FileMover administration 50 of 72

51 Output ufs1: state = enabled offline attr = on popup timeout = 0 backup = passthrough read policy override = passthrough log file = on max log size = 10MB cid = 0 type = CIFS source = \\wichita.nasdocs.emc.com\dhsm1\ state = enabled read policy override = none write policy = full local_server = DM112_CGE0.NASDOCS.EMC.COM Done 51 of 72

52 Enabling Celerra FileMover Creating a connection Configuring API security Enabling pop-up notification (CIFS only) Use the -popup_timeout option to specify a pop-up time-out value, which permits the Celerra Network Server to send pop-up notifications to CIFS clients. When a CIFS I/O request cannot be processed within the time specified, a notification of the delay appears to the CIFS client in a Windows pop-up message. The default value for -popup_timeout <sec> is zero, which disables pop-up notification. Action To enable pop-up notification, use this command syntax: $ fs_dhsm -modify <fs_name> -popup_timeout <sec> Where: <fs_name> = name of the FileMover-enabled file system <sec> = the pop-up time-out value, in seconds Example: To enable pop-up notification on ufs1, type: $ fs_dhsm -modify ufs1 -popup_timeout 10 Managing the Celerra FileMover connection Celerra FileMover administration Output ufs1: state = enabled offline attr = on popup timeout = 10 backup = passthrough read policy override = passthrough log file = on max log size = 10MB cid = 0 type = CIFS source = \\wichita.nasdocs.emc.com\dhsm1\ state = enabled read policy override = none write policy = full local_server = DM112_CGE0.NASDOCS.EMC.COM Done Note The default Windows pop-up notification message is: Accessing offline data, please wait while retrieving data. To customize this message, change the parameter line in the cifsmsg.txt file to $warning.remote=<the customized message>. The Using Quotas on Celerra technical module contains more information about customizing Windows pop-up warning and error messages. Note: The Windows Messenger service must be running on the CIFS client for it to be able to display Windows pop-up messages. This service does not run by default in Windows 2003 or XP. 52 of 72

53 Enabling Celerra FileMover Creating a connection Configuring API security Adjusting offline attribute settings EMC strongly recommends you accept the default for the offline_attr option. The default enables the Celerra Network Server to notify CIFS clients that a file is migrated. A small marker appears at the bottom-left corner of the file icon when the file appears in Windows Explorer. If the option is disabled, migrated files can be recalled to primary storage unnecessarily as applications, like Windows Explorer, read parts of files even when just viewing the enclosing directory. Note: CIFS Notify Change is not supported using the Celerra FileMover. To obtain up-todate stub file status information, refresh Windows Explorer as needed. Action Managing the Celerra FileMover connection Celerra FileMover administration To adjust offline attribute settings, use this command syntax: $ fs_dhsm -modify <fs_name> -offline_attr {on off} Where: <fs_name> = name of the FileMover-enabled file system Example: To disable offline attributes on ufs1, type: $ fs_dhsm -modify ufs1 -offline_attr off Output ufs1: state = enabled offline attr = off popup timeout = 0 backup = offline override = full log = on max log size = 20MB cid = 2 type = NFSV3 source = emcdocs.emc.com:/dhsm1 state = enabled read policy override = none write policy = full options = Done Tuning HTTP threads By default, 20 threads are available on the Data Mover to service all HTTP requests; of that number, 15 threads 75 percent of the thread pool are available for Celerra FileMover. This means the Data Mover, unless otherwise configured, can process at most 15 simultaneous Celerra FileMover API requests from the policy and migration software. In most environments, the default number of threads should be sufficient. If, however, the policy and migration software you are using can simultaneously issue more API requests than there are HTTP threads, or you have multiple policy and migration software applications that might simultaneously issue Celerra FileMover API requests to the Data Mover, consider increasing this thread count. 53 of 72

54 Note: The recommended maximum number of threads is 30. If more Celerra FileMover API requests are sent to the Data Mover than there are HTTP threads to process them, the extra requests are rejected. Enabling Celerra FileMover Creating a connection Configuring API security You can use the -threads option to specify the number of threads to make available for an external policy and migration software (server) that requires more than the default. If you change this value, you must reboot the Data Mover before the new value can take effect. Action To specify the number of threads available on a Data Mover, use this command syntax: $ server_http <movername> -modify dhsm -threads <threads> Where: <movername> = name of the specified Data Mover <threads> = number of threads for incoming service requests Example: To increase the number of threads to 30 on server_2, type: $ server_http server_2 -modify dhsm -threads 30 Output Note Managing the Celerra FileMover connection Celerra FileMover administration server_2: Warning 4126: server_2 : You must reboot server_2 for thread change to take effect. 25 percent of the thread pool is reserved for non-celerra FileMover operations, which means a value of 40 provides 30 threads on the Data Mover to service the Celerra FileMover API. Tuning threads to read data from secondary storage The Data Mover usually reads data from secondary storage in response to a client reading or writing to stub files, but also recalls data when a Celerra FileMover connection is deleted using the -recall_policy yes flag. By default, for NFS and CIFS 256 threads run on the 510 or later Data Mover. The number of simultaneous reads allowed to the stub files is half of the lesser of the number of CIFS threads and NFS threads. This means there can be at most 128 simultaneous reads to the stub files. Note: The default number of threads depends on the memory size of the Data Mover. If the memory size is less than 1 GB, the default is 32 threads. Several applications can read from stub files: CIFS and NFS clients, NDMP backup, CIFS/NFS network backup, recall operations with Celerra FileMover connection deletion, AV servers, FTP clients, and so on. If the limit on simultaneous reads is reached, NFS and CIFS clients might experience slow response time and CIFS clients may see an error. CIFS clients may need to attempt the operation again. To increase the number of CIFS threads, refer to the Configuring CIFS on Celerra technical module. Contact the EMC Customer Support Center to increase the number of NFS threads. 54 of 72

55 Enabling Celerra FileMover Creating a connection Configuring API security Moving Celerra FileMover stub files You can copy or move the stub files between Celerra file systems. There are two ways to copy or move Celerra FileMover stub files from one file system to another without recalling file data from secondary storage. The simplest way to copy or move FileMover stub files between Celerra file systems is to use a policy engine that supports the copying or moving of stub files. Contact your software vendor to determine whether your policy and migration software supports this functionality. You can also use EMCopy to copy Celerra FileMover stub files between Celerra file systems. In this case, you need to set the CIFS backup option to offline on the source file system; it is unnecessary to set this option on the destination file system. Note: EMC strongly suggests the Data Movers hosting the source and destination file systems be running Celerra Network Server version or later. The destination file system must exist and be enabled with FileMover functionality. In addition, the connections to secondary storage must match the connections defined on the source file system. Managing the Celerra FileMover connection Celerra FileMover administration Disabling FileMover functionality If you disable FileMover functionality on a Celerra file system, any files migrated to secondary storage are inaccessible. Subsequent attempts to read or write to a migrated file cause an I/O error to occur. Note: Disabling FileMover functionality on a Celerra file system does not delete Celerra FileMover connections, including the options set on the file system.you can also choose to disable or enable a single FileMover connection. Action To disable FileMover functionality on a Celerra file system, use this command syntax: $ fs_dhsm -modify <fs_name> -state disabled Where: <fs_name> = name of the FileMover-enabled file system Example: To disable ufs1, type: $ fs_dhsm -modify ufs1 -state disabled Output ufs1: state = disabled offline attr = on popup timeout = 10 backup = offline read policy override = full log file = off max log size = 20MB Done 55 of 72

56 When specifying the -modify option on a disabled file system, the state is automatically changed to enabled. In this instance, to maintain the disabled state specify -state disabled. 56 of 72

57 Example procedure This example procedure shows you how to enable Celerra FileMover on the file system, and then create a connection to a secondary file server. Step Action 1. Create a file system on the Celerra Network Server. 2. Enable the file system for Celerra FileMover using this command syntax: $ fs_dhsm -modify <fs_name> -state enabled Note: This command has to be done only once. It remains persistent across Data Mover boots and must be explicitly disabled. 3. To create an NFS connection, type: $ fs_dhsm -connection dm7fs1 -create -type nfsv3 -secondary nasdocs.emc.com:/nfsv3_fs This command creates a Celerra FileMover connection on the file system dm7fs1. This command remains persistent across Data Mover boots. nasdocs.emc.com is the hostname of the secondary NFS file server with an export path of /nfsv3_fs. Be certain the NFS file server allows root access from this Data Mover. Use /usr/sbin/showmount -e nasdocs.emc.com to verify the export path. To create a CIFS connection, type: $ fs_dhsm -connection dm7fs1 -create -type cifs -admin nasdocs.emc.com\administrator -secondary \\wichita.nasdocs.emc.com\test_share -local_server DMNJ-2-7 This command creates a second Celerra FileMover connection on the file system dm7fs1. This uses a secondary CIFS file server, wichita, which exports the share test_share. You are prompted for a password for the administrator account. This command remains persistent across Data Mover boots. 4. Configure the HTTP server on the Data Mover to accept Celerra FileMover API connections from the user / host using this command syntax: $ server_http <server_x> -append dhsm -users <user_name> -hosts <ip_address_policy_engine> 5. Use your policy and migration software to migrate files from the Celerra Network Server to secondary storage. 6. Access the file. 57 of 72

58 Troubleshooting Celerra FileMover As part of an effort to continuously improve and enhance the performance and capabilities of its product lines, EMC periodically releases new versions of its hardware and software. Therefore, some functions described in this document may not be supported by all revisions 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. 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. Telephone U.S.: (SVC.4EMC) Canada: (543.4SVC) Worldwide: Note: Please do not request a specific Support Representative unless one has already been assigned to your particular system problem. The Problem Resolution Roadmap for Celerra contains additional information about using Powerlink and resolving problems. Known problems and limitations Table 5 identifies known problems, limitations, and other types of issues that might arise when using Celerra FileMover. File attributes are set using the policy and migration software. Table 5 Celerra FileMover known problems and workarounds Known Problem Symptom Workaround If the pop-up time-out value is less than 10 seconds, pop-up notifications on CIFS clients do not appear until at least 10 seconds have passed. Pop-up notifications appear after 10 seconds have passed. 58 of 72

59 Table 5 Celerra FileMover known problems and workarounds (continued) Known Problem Symptom Workaround Viewing the stub file properties using some Windows Server 2003 or XP clients might cause a read operation to occur. The Summary tab may not appear for stub file properties on some Windows 2000 and 2003 clients. Files may be recalled to primary storage when some Windows clients check the property of the stub files. Use the policy and migration software to remigrate the recalled files and set the read recall policy to passthrough, if needed. EMC is investigating the behavior between FileMover and Windows Explorer. EMC is investigating the behavior between FileMover and Windows Explorer. Viewing the stub file properties of executable and Zip files using Windows 2000 might recall all data from secondary storage. EMC is investigating the behavior between FileMover and Windows Explorer. Filenames not in UTF-8 format that are created from wrong locale NFS/CIFS clients cannot migrate using FileMover. Conversion to UTF-8 must be done before the file is migrated. fs_dhsm -connection -create -type cifs: failed to complete command Microsoft Windows Explorer search functionality cannot locate migrated files or folders on Windows Server 2003 or Windows XP. Warning: RecvStream failed Protocol not available on server lnsga176 with client 170dm2test Search results do not return files matching the search criteria. Try to create the CIFS connection again. 1. Click Start and point to Search. 2. In the All or part of the file name field, type the file name you want to find. 3. Click Search tape backup. 4. Click Search. Note: When the Search tape backup option is enabled, do not search for a migrated file using a specific word or phrase. Doing so recalls all the files to primary storage as they are searched. 59 of 72

60 Limitations FileMover cannot be enabled on a read-only file system not previously enabled for FileMover functionality. A File-Level Retention (FLR) capable file system cannot be used as primary storage in a FileMover environment. However, it is possible to use an FLR file system as secondary storage. Contact your software vendor to determine whether your policy and migration software supports this configuration. Note that a file in the FLR state on secondary storage cannot be altered or deleted by NAS clients or users. A file in the FLR state can be deleted only after its retention period expires. The Using File-Level Retention on Celerra technical module contains information about FLR storage technology and file system behavior. Celerra FileMover cannot be enabled on an MGFS file system. Celerra FileMover can manage a maximum path length of 1024 bytes; however, the maximum pathname length depends on the policy and migration software. Celerra FileMover does not support migration of alternate datastreams. Celerra FileMover does not support NFSv4 protocol. Celerra FileMover does not support using a DFS-based UNC paths to connect to CIFS-based secondary storage. The Celerra must connect to the real server and share name when using CIFS connections to secondary storage. To avoid issues when accessing files migrated from primary storage multiple times, be sure your chosen policy and migration software supports maintaining multiple versions of files on secondary storage. A multihop configuration allows you to move data from primary to secondary storage, from secondary to tertiary storage, and back. A FileMover-enabled file system can be secondary storage. In a multihop configuration, secondary storage must be the Celerra Network Server while tertiary storage can be the Celerra Network Server NFS/CIFS file server. Although FileMover supports a multihop configuration up to two hops, your policy engine vendor might not yet support this functionality. Contact your policy engine software vendor directly for the most up-to-date information about multihop configurations. If you want to use a Windows Microsoft Cluster Service (MSWC) based file server as secondary storage in the FileMover environment, you need Celerra Network Server version , , 5.5, or later. NDMP Volume Backup (VBB) does not support the NDMP environment variable EMC_OFFLINE_DATA. In this case, the contents of migrated files the offline files on secondary storage must be backed up independently. 60 of 72

61 Error messages Certain error messages may appear indicating an error in your command execution. Table 6 lists server log error messages, their definition, and corrective action. Table 7 lists command line error messages, their definition, and corrective action. The Celerra Network Server Error Messages Guide contains additional information about error messages. Table 6 Celerra FileMover error messages Server Log Error Definition Corrective Action SMB: 3: SmbSessionSetupXMsg:: buildwithkerberos: KC_ComputeBlob is unable to build blob (CIFS error: KRB5KRB_AP_ERR_SKEW) Kerberos error clock skew. Resynchronize the time between the Data Mover and the Windows 2000 domain controller. MGFS: 3: cannot establish connection between dnsalias.nasdocs.emc. com and celerra4. nasdocs.emc.com with share secondaryshare with user nasdocs.emc. com\administrator status=c SMB: 4: netbios session request failed return type 131 server dnsalias with client Celerra1 DNS alias error. When creating FileMover connections, you must use the actual computer name of the Microsoft Windows file server. A DNS alias does not work. Search the Microsoft Support website Knowledge Base for article ID and apply the registry change as noted. Be sure you are running Celerra Network Server version , , 5.5 or later. MGFS: 3: modify option for connection 2 failed, status 8 - DuplicateEntry CIFS connection error. Disable the CIFS connection between the primary and secondary storage prior to modifying the -admin account, then reestablish the connection. Unknown offline attr=%s,an >getname Policy / Migration Software tried to set an unknown or unsupported parameter in the DHSM API. Contact EMC Customer Service and provide the Policy /Migration software vendor name, the version number of Celerra, and the actual error string. 61 of 72

62 Table 6 Celerra FileMover error messages (continued) Server Log Error Definition Corrective Action MGFS: 3: cannot establish connection between trenton.njqa.us.dg.com and DMNJ-2-7.njqa.us.dg.com with test share with user njqa/administrator status=c000006d CIFS connection error. Specify a fully qualified domain account or use the default domain. SMB: 3: Cannot find remote server MGFS: 3: cannot establish connection between and DMNJ-27.NJQA.US.DG.COM with share dm3fs1 with user Administrator status=c00000be IP address error. CIFS servers require computer name or NetBIOS name. Refer to "Creating a CIFS connection" on page 29. DHSM: 3: offline inode 15 validation failed, remotemtime= , offlinemtime= ; remotesz= bytes, offlinesz= bytes A Windows message box appears: Cannot open the <Z:\1abc.txt> file. Make sure a disk is in the drive you specified. For NFS, an input/output error appears. Delete the stub file. Then use the policy and migration software to copy the file from secondary to primary storage and set file attributes to replace the file with a new stub file. DHSM: 3: operation failed because file system is read only File system is inaccessible. Enable Celerra FileMover on a file system mounted as read/write. DHSM: 3: HTTP verifyserverhealthinte rnal(): Unexpected HTTP status 302 : 302 Found Missing cgi option for non-cgi connections. Set the -cgi option to n and try the create the HTTP connection. DHSM: 3: If a non-cgi connection is desired "-cgi n" should be used during connection creation Missing cgi option for non-cgi connections. Set the -cgi option to n and try to create the HTTP connection again. DHSM: 3: HTTP createdarthttpconnecti ons(): could not connect/talk to server apache.njqa.us.dg.com Web server is down. Bring the web server up. 62 of 72

63 Table 6 Celerra FileMover error messages (continued) Server Log Error Definition Corrective Action DHSM: 3: HTTP: Couldn't get http response User and password required Missing credentials. Set the username and password options and try to create the HTTP connection again. DHSM: 3: HTTP createdarthttpconnecti ons(): could not connect/talk to server dhsm-w2k Missing credentials. Set the username and password options and try to create the HTTP connection again. DHSM: 3: HTTP: Expecting a content type of "application/octetstream" Nonconformant CGI application. The CGI application has to be modified to conform with the requirements. DHSM: 3: response had "text/html; charset=iso " content type Nonconformant CGI application. The CGI application has to be modified to conform with the requirements. MGFS: 3: error direct read block 0 of entry 55107, status 17 - NoPermission This error may occur if ownership and permissions of the stub file change. Modify the NFS connection using the -userootcred option set to true. MGFS: 3: add connection failed, status 8 DuplicateEntry This error occurs when the connection has already been created. No further action is required. This behavior is true of all of the supported protocols; NFS v2/3, HTTP, and HTTPS. RPC: 3: NFSPROC3_READ failed, status=5 MGFS: 3: NFS V3: Error: read failed at rpc layer, rpc status 5 - RPC: Timed out This error may occur when there is a maximum transmission unit (MTU) size mismatch between primary and secondary file system. Verify that the MTU value is correct and that the MTU value set on the primary file system matches the MTU set on the secondary file system. 63 of 72

64 Table 7 Command line interface error messages Command Line Error Definition Corrective Action CIFS: Error: retrieving underlying fs attrs failed, ntstatus: c Cannot fsstat remote server, status 28 - InternalError. NFS V3: Error: getfsstat failed, nfs status 70 Cannot fsstat remote server, status 9 - StaleHandle. The secondary storage file system is inaccessible. Verify access to the secondary store file system. There could be a permission problem, the remote file system server may be down, or the remote file system may be unmounted. Error 4019: Failed to complete command The file system is read-only. Verify the file system type is uxfs and is mounted as read/write. fs_dhsm -connection -create -type cifs: failed to complete command Warning: RecvStream failed Protocol not available on server lnsga176 with client 170dm2test Try to create the CIFS connection again. 64 of 72

65 Related information For specific information related to the features and functionality described in this technical module, refer to: Celerra Network Server Command Reference Manual Online Celerra man pages Celerra Network Server Parameters Guide Celerra FileMover information that is related, but is beyond the scope of this technical module, is included in: Celerra FileMover API Integration Guide The Celerra Network Server Documentation CD, supplied with your Celerra Network Server and also available on Powerlink, provides general information on other EMC Celerra publications. Customer training programs EMC customer training programs are designed to help you learn how EMC storage products work together and integrate within your environment to maximize your entire infrastructure investment. EMC customer training programs feature online and hands-on training in state-of-the-art labs conveniently located throughout the world. EMC customer training programs are developed and delivered by EMC experts. For program information and registration, refer to Powerlink, our customer and partner website. 65 of 72

66 Appendix A: Celerra FileMover log file example By default, the Celerra Network Server logs all activity associated with creating, modifying, and deleting stub files in a Celerra FileMover-enabled file system. These events are logged to a file named dhsm.log in the /.etc directory of the file system. The following are example entries from a dhsm.log file. Table 8 describes the entries. 1*: debug dhsmlog: initialize dhsm log... Wed May 12 10:14: *: SET_OFFLINE: 1.12.b52.40a2408c, pe_id: Enigma Celerra Host id:795c65be983eee bc3fd025e6d1, offline_path: \\cfs6dm2a.w2003.celerra.co.uk\fs4\smdest\_sha RE_cfs2dm2a\source1\PROJECT\test.txt... Wed May 12 17:13: *: REMOVE: 1.12.b52.40a2408c, pe_id: Enigma Celerra Host id:795c65be983eee bc3fd025e6d1, offline_path: \\cfs6dm2a.w2003.celerra.co.uk\fs4\smdest\_share _cfs2dm2a\source1\project\test.txt... Wed May 12 18:25: *: GET_ONLINE: 1.12.edf.40a27a69, pe_id: Enigma Celerra Host id:795c65be983e ee130171bc3fd025e6d1, offline_path: \\cfs6dm2a.w2003.celerra.co.uk\fs4\smdest\_s HARE_cfs2dm2a\source1\BVT-P10x100\P1\file-1.txt... Wed May 12 19:50: Table 8 Celerra FileMover log file example entry Example log entry SET_OFFLINE 1.12.b52.40a2408c pe_id host id offline_path Wed May 12 17:13: Brief description The event type that occurred: SET_OFFLINE indicates a migrated file was replaced by a stub, REMOVE indicates a stub file was deleted, GET_ONLINE indicates the file represented by the stub file on primary storage was recalled from secondary to primary storage. Log event number. Policy and migration software that migrated the file. Number identifier for the policy and migration software. Location the file was migrated to on secondary storage. The date/time stamp when this event occurred. 66 of 72

67 Appendix B: Storage space requirement example For the purpose of example, assume you have a requirement to store 1 TB of data, of which 80 percent of the files are considered stale. The stale files are eligible for migration to secondary storage in a Celerra FileMover-enabled environment. Also assume the average file size is 110 KB and you want to maintain the utilization of primary and secondary storage at approximately 80 percent. To keep things simple, all the migrated files will reside in a single secondary storage location. To determine how big the primary and secondary file systems should be, consider the following example: With an average file size of 110 KB per file,1 TB of data represents approximately 9,761,289 files. 7,809,031 files (80 percent) are eligible for migration to secondary storage, which leaves the same number of stub files plus 1,952,258 unmigrated files the remaining 20 percent of the 1 TB total on primary storage. Each stub file usually occupies 8 KB of space in the primary file system. In addition, consider the space needed to keep recalled files on primary storage. The read recall method can have significant impact. Assume 1 percent of the stale data (78,090 files x 110 KB) is recalled with read access. Write operations must also be considered. A write operation causes full recall of the data. When a file is fully recalled via a write or read operation the file stays active until it is once again migrated by the policy and migration software. Assume 1 percent stale data (78,090 files x 110 KB) is recalled with write access. Subsequently, the total space used in the primary file system will be ((20 percent *1 TB) + (7,809,031-78,090-78,090) * 8 KB + (78,090 x 110 KB) + (78,090 x 110 KB)) = 301 GB (rounded to the nearest GB). With a targeted file system utilization of 80 percent, the primary file system needs to be 376 GB in size. The amount of data stored in the secondary file system is approximately 800 GB, which is 80 percent of the 1 TB that is stale. With the targeted file system utilization of 80 percent, the secondary file system needs to be 1 TB. For more information on sizing a Celerra FileMover file system, refer to the E-Lab Interoperability Navigator, which is available on Powerlink. 67 of 72

68 68 of 72

69 Index A Adjusting offline attributes 53 AntiVirus server planning considerations 23 scanning applications 48 API. See Celerra FileMover API 34 B Backing up CIFS 49 NDMP 49 NFS 50 Backup strategies 19 C CDMS Integration considerations 25 Celerra AntiVirus Agent (CAVA) definition 3 Integration considerations 23 Celerra FileMover concepts 7 creating CIFS connection 29 HTTP connection 32 NFS connection 31 definition 3 deleting a connection 41 disabling a connection 55 enabling 28 how it works 8 9 listing connection information 39 listing connections 39 modifying a connection 37 tuning HTTP threads 53 Celerra FileMover API CIFS Notify Change 53 configuring access based on IP address 34 API security 34 definition 3 migrate operation 8 Celerra FileMover log files disabling 46 increasing size 47 CIFS adjusting offline attributes 53 backup strategies 19, 20 client backups 19 creating a Celerra FileMover connection 29 definition 3 enabling pop-up notification 52 performing a backup 49 component file system definition 4 Configuring access based on IP address 34 digest access authentication 36 security options 15, 34 Connection 39 CIFS 29 deleting 41 disabling 55 HTTP 32 listing information 36, 39 modifying 37 NFS 31 connection database definition 4 Customizing Windows pop-up messages 52 D Data Mover configuring access based on IP address 34 security options 34 configuring security options 15 enabling Celerra FileMover 28 tuning HTTP threads to read data from secondary storage 54 Deleting a Celerra FileMover connection 41 DFS root 60 Digest access authentication configuring 36 definition 4 Disabling Celerra FileMover 55 Celerra FileMover log files 46 E Enabling Celerra FileMover 28 offline attributes 53 pop-up notification 52 Error messages 61 extended ACL, definition 4 F File system creating CIFS connection 29 HTTP connection 32 NFS connection 31 deleting a Celerra FileMover connection 41 disabling a Celerra FileMover connection 55 enabling pop-up notification 52 listing Celerra FileMover connections 39 listing connection information 39 modifying a connection 37 monitoring usage 20 scanning applications 48 File-Level Retention (FLR) Integration considerations of 72

70 FQDN creating a CIFS connection 29 definition 4 FS linking Integration considerations 25 FSN definition 4 H HighRoad 24 HTTP authentication 34 creating a connection 32 listing connection information 36 tuning HTTP threads 53 I Increasing log file size 47 Information Lifecycle Management 7 Integration considerations CDMS 25 Celerra AntiVirus Agent (CAVA) 23 File-Level Retention (FLR) 25 FS linking 25 International character sets 24 MPFS 24 Quotas 22 Replicator 24 SnapSure 23 TimeFinder/FS 24 Virtual Data Mover (VDM) 24 International character sets Integration considerations 24 L LACP See link aggregation 4 Limitations 60 link aggregation definition 4 Listing FileMover connection information 39 FileMover connections 39 HTTP connection information 36 Log files Celerra FileMover log file example 66 disabling 46 increasing size 47 M metadata retrieving from Celerra file system 21 Microsoft Explorer scanning applications 48 size on disk 18 zip files 48 Migrate operation 9 migration method definition 4 full 13 partial 13 passthrough 13 read operation 14 Migration policy FileMover concepts 7 Modifying a Celerra FileMover connection 37 MPFS definition 4 Integration considerations 24 Multihop configuration 18 N NAS definition 4 NDMP backing up 49 backup strategies 19, 20 definition 4 NFS backup strategies 19, 20 creating a Celerra FileMover connection 31 definition 4 performing an NFS backup 50 NMFS definition 4 Integration Considerations 25, 28 O Offline attributes 53 Orphan file definition 4 handling limitations 18 P passthrough backup strategies 19 definition 5 migration method 13 scanning applications 48 Policy and migration software, definition 5 Policy engine, definition 5 Primary storage, definition 5 Q Quotas definition 5 file system usage 20 limitations 11 planning considerations 22 R Read operation 11 migration method 14 Replicator integration considerations of 72

71 S Scanning applications 48 Celerra AntiVirus Agent (CAVA) 23 secondary storage backing up 20 creating a connection 15 definition 5 migrating small files 18 multi-hop configuration 18 multiprotocol environments 17 orphan file handling limitations 18 storage considerations 17 server_df command 20 server_http command 36 SnapSure Integration considerations 23 SnapSure, definition 5 SRDF definition 5 Storage considerations migrating small files 17 Stub file 7 definition 5 deleting 18 migrate operation 8 performing an NDMP backup 49 storage considerations 17 write operation 10 T telephone using to contact EMC Customer Service 58 Threads tuning HTTP threads to read data from secondary storage 54 TimeFinder NearCopy/FarCopy 24 TimeFinder/FS definition 5 integration considerations 24 trunk definition 5 Tuning HTTP threads 53 U Unicode 6 integration considerations 24 UTF-8 6, 24 V Virtual Data Mover (VDM) definition 5 Integration considerations 24 W Write operation 8 10 Write recall policy of 72

72 About this technical module As part of its effort to continuously improve and enhance the performance and capabilities of the Celerra Network Server product line, EMC from time to time releases new revisions of Celerra hardware and software. Therefore, some functions described in this document may not be supported by all revisions of Celerra software or hardware presently in use. For the most up-to-date information on product features, see your product release notes. If your Celerra system does not offer a function described in this document, contact your EMC Customer Support Representative for a hardware upgrade or software update. Comments and suggestions about documentation Your suggestions will help us improve the accuracy, organization, and overall quality of the user documentation. Send a message to celerradoc_comments@emc.com with your opinions of this document. Copyright EMC Corporation. All rights reserved. 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. 72 of 72