Overview of V7000 Unified HSM integration

IBM Storwize V7000 Unified

TSM HSM Overview and

Implementation

White Paper

Nils Haustein, Senior Certified IT Specialist, IBM European Storage Competence Center

Andre Gaschler, Certified IT Specialist, IBM European Storage Competence Center

July 2012, Document Version 1.5

Table of Content Introduction ............................................................................................................ 3 Overview of V7000 Unified HSM integration ................................................................. 4

TSM HSM concept.................................................................................................. 5 Migration Rules and Policies .................................................................................... 5 TSM Server........................................................................................................... 7 Reconciliation........................................................................................................ 8 Considerations and Limitations ................................................................................ 8

Implementation guidance .........................................................................................10 Overview.............................................................................................................10 Planning..............................................................................................................10 Configure TSM server............................................................................................11 Configure TSM definition in V7000 Unified ................................................................13

Using the GUI ...................................................................................................14 Using the CLI ....................................................................................................15

Activate HSM in V7000 Unified ...............................................................................16 Create and apply policies .......................................................................................16

Creating an Auto-migration policies ......................................................................17 Creating scheduled policy....................................................................................17 Using policy templates........................................................................................18

Testing and monitoring the HSM policies ..................................................................19 Verifying migrated files from the share mount point................................................20

Configuring Reconciliation schedules .......................................................................20 Appendix ...............................................................................................................21

References ..........................................................................................................21 Example of HSM migration rules and policies ............................................................21

Size based migration..........................................................................................21 Premigration policy ............................................................................................21 Age based migration ..........................................................................................22 Threshold based migration ..................................................................................22

Disclaimer ...........................................................................................................22 Trademarks .........................................................................................................22

Acknowledgements: I would like to thank Andreas Luengen from V7000U / Sonas Development for the great support answering my questions.

© IBM Corporation 2012 Page 2

Introduction IBM Storwize V7000 Unified is a unified storage product providing file storage via Network Attached Storage (NAS) protocols and block storage via block storage protocols such as Fibre Channel and iSCSI. The NAS part of V7000 Unified allows storing files through standardized protocols such as NFS and CIFS. Internally the V7000 Unified file storage can be configured to automatically move a file between different tiers of storage. The integrated Information Lifecycle Management (ILM) function allows moving of files between disk-tiers, which are managed by the V7000 system. Furthermore the Hierarchical Storage Management (HSM) capability allows moving files from the V7000 managed disk storage to an external Tivoli Storage Manager (TSM) server while keeping the access to the file transparent. This paper introduces the integration of Hierarchical Storage Management (HSM) with V7000 Unified and outlines essential concepts such as TSM HSM client, GPFS policies and rules and TSM server configuration (see chapter Overview of V7000 Unified HSM integration). It also describes the relation between the local Active Cloud Engine™ (ACE), migration policies and rules and the interaction with the TSM HSM client. In the second part, this paper gives guidance for the configuration and implementation of the HSM function with V7000 Unified and TSM server (see chapter Implementation guidance). This guidance assumes that the audience has administrative background regarding TSM server and V7000 Unified. In summary, the HSM functionality in V7000 Unified provides cost efficiency, because a file can be stored on the most appropriate storage medium. This especially supports archiving use cases, because it allows moving old files, which are no longer accessed, to a low cost storage medium like tape. The HSM function provides operational efficiency, because it can be automated using the built-in ACE and the inline backup function. Furthermore it can also be used to manage file system utilization and prevent file system overflows.


Overview of V7000 Unified HSM integration The V7000 Unified includes TSM HSM client for migrating files from V7000 Unified managed disk to tape, which is attached to an external TSM server. Figure 1 shows the general architecture of TSM HSM in the V7000 Unified and the external TSM server:

File Module File Module

Migration & Recall

External TSM ServerV7000 disk

Public networkACE

TSM HSM

Figure 1: TSM HSM architecture The local Active Cloud Engine™ (ACE) - which is integral part of the V7000 Unified – in combination with the TSM HSM client and TSM server is used to perform policy-based migration of files from V7000 managed disk to external tape managed by an external TSM server. For example, policies can be based on age or last access time of files, whereby files older than 1 year or files which have not been accessed for the last 30 days can be migrated to an external TSM server with attached tape storage (see section Migration Rules and Policies). The TSM HSM client can use the same TSM server as the TSM backup client [1], which is configured for the file system. Using the same TSM server for file system backup and migration enables the inline backup function: When a file, which has been migrated, is backed up then the file will not be recalled and copied again to the TSM server. Instead the TSM server performs an inline copy of the file from the HSM storage pool to the backup storage pool of the TSM server. This improves operational efficiency and reduces the amount of data being transferred over the network. TSM HSM is enabled on file system basis and operates on the entire file system. Policies and rules can be configured to operate on a file set basis. If multiple file systems are configured for HSM, one or more TSM servers can be used as a migration target, however a single file system can have only one migration destination TSM server. TSM HSM can be configured to run on one or both file modules of the V7000 Unified system. The recommendation is to configure TSM HSM to run on all file modules for all file systems, because the workload (file migration) is distributed among the file modules (~100 files per file module for each chunk). When files are migrated from the disk storage to an external TSM server, these files remain represented in the name space of the file share, facilitating transparent access from a user perspective. If the user accesses a migrated file, the TSM HSM client performs a recall of the file from the TSM server (see section TSM HSM concept).


TSM HSM concept The TSM HSM client installed on the V7000 Unified system is a client to the TSM server (see section TSM Server). It uses a proprietary protocol to perform migration and recall of files to and from the TSM server. Within the V7000 Unified system the TSM HSM client integrates with the Data Management API (DM API) and the GPFS file system, which allows intercepting file access. The TSM HSM client can perform migration or pre-migration. Pre-migration copies the file to the external TSM server and migration moves it. The purpose of pre-migration is to keep a copy on disk allowing faster access while also having a copy in the external TSM server. The disadvantage is that it does not reduce the occupied storage capacity on disk. In order to reduce the occupied storage capacity migration has to be used. When a pre-migrated file is migrated it is not copied again to the TSM server which safes processing and network resources. It just involves removing the content of the file from disk and creating a so called stub-file in the file system allowing transparent access to the file content. If a file is migrated which has not been pre-migrated then the file is copied to the TSM server and subsequently the stub-file is created which removes the file content from the disk. Migration and pre-migration is performed automatically based on scheduled policies (see section Migration Rules and Policies). The migration process may also be invoked if only attributes of a file have changed and not the content of the file. This is because file attributes are stored with the file content. Policies and rules can be used to prevent this. This behavior is similar to the TSM backup implementation with V7000 Unified. After a file has been migrated to the TSM server, the content of the file is not longer stored on disk and a stub-file is used to provide transparent access. When a stub-file is accessed by the user of the file share, the TSM HSM client intercepts the file access and recalls the file from the TSM server. When the file is fully resident on disk, the user access is granted and the user can perform the required operations on the file. Recall and migration of files in a TSM HSM environment does not change the time stamps of the file and preserve the ACL of files. The TSM HSM client honors include and exclude list defined for the backup client in the dsm.sys file. The dsm.sys file however cannot be changed in the V7000 Unified via the CLI, (requires root access). Additional include and exclude list can also be defined within policies (see section Migration Rules and Policies) which might be a much more efficient way to exclude files from migration.

Migration Rules and Policies The Active Cloud Engine™ (ACE) integrated in V7000 Unified utilizes GPFS rules and policies [2]. A policy contains rules, which describe the selection criteria of files and the action to be performed for the selected files. Selection criteria of files are typically based on the file attributes, such as the file and path name, the file size, the file time stamps and ownership of files. Actions can include:

− Initial file placement − File migration − File deletion


HSM rules can only include file migration actions. When a HSM migration policy is activated, the ACE first identifies the files based on the given rules. In the next step it invokes the TSM HSM client, which performs migration or pre-migration of the selected files to the external TSM server including all file attributes. The file attributes are stored within the file. During the migration process the TSM HSM client locks the file in order to prevent updates or changes. The migration process also ensures that the time stamps of the file (especially last access time and modification) are not changed by performing “invisible reads”. There are two kinds of migration policies, which can be used with HSM:

− The Auto-migration policies − Scheduled policies

The Auto-migration policies are activated for the file system and are automatically executed when the file system space utilization crosses a defined threshold. The Auto-migration policies must ensure that files are being migrated in order to free up space in the file system pools. Only one set of policies can be activated in a file system. This set of policies must include all required rules to assure proper auto-migration for the file system pools, including the ILM rules and placement rules. The following example shows a simple Auto-migration policy which is activated when the file system pool “system” is 80 % utilized. This policy is comprised of three rules. The first rule defines the “hsmpool” as HSM managed. The second rule identifies files with the oldest access date first and migrate as many files until the file system is 60 % utilized. The third rule includes a default placement policy whereby all files are placed in the pool “system”. RULE ‘hsmpool' EXTERNAL POOL 'hsm' EXEC ‘HSMEXEC'; RULE 'systemMigration' MIGRATE FROM POOL 'system' THRESHOLD(80,60) WEIGHT(ACCESS_DATE) TO POOL 'hsm'; RULE 'default' SET POOL 'system' Scheduled policies are automatically activated based on scheduled tasks. There can be multiple sets of scheduled policies for one file system running at different times. Scheduled policies can be more sophisticated and (pre-)migrate files based on specific criteria such as file names, file size, file time stamps and other file attributes. The following example shows a scheduled policy, which migrate all files from the “system” pool of the file system, which are older than 60 days, independent of the space utilization of the file system: RULE ‘hsmpool' EXTERNAL POOL 'hsm' EXEC ‘HSMEXEC'; RULE ‘fileMigration' MIGRATE FROM POOL 'system‘ TO POOL ‘hsm’ WHERE (DAYS(CURRENT_TIMESTAMP) – DAYS(ACCESS_TIME) > 60); Scheduled policies accompany the Auto-migration policy and ensure that file system space is freed up on a periodic basis. Scheduled policies in combination with the capacity sizing of the file system pools shall ensure that the Auto-migration policy must never be executed. If a file system is comprised of multiple storage pools then multiple rules might have to be defined to assure that each storage pool is treated by the Auto-migration policies when the space utilization crosses a certain threshold. Not every storage pool might have to be configured for migration via HSM to the external TSM server. Instead files can be migrated from one V7000 disk pool to another using the ILM function and only the last pool within this storage hierarchy is migrated to the external TSM server using the HSM function (Auto-migration and schedule policies).


The V7000 Unified ILM function is also implemented by policies and rules, similar to the HSM function. The difference is that the term HSM is used when data is migrated to an external TSM server, while the term ILM is used when data is migrated from one disk tier to another managed by the same V7000 system. Rules and policies can be configured to process only a partition (file set) of the file system. Likewise include and exclude lists can be defined within rules and policies. For more information about rules and policies refer to [2].

TSM Server The TSM HSM client is a client node to the TSM server. Figure 2 shows an overview of the TSM server configuration concept.

Archivepool

Policy Set (Active)

Mgmt. Class

Archive copyGroup

Backup copyGroup

Backuppool

Policy Domain

SpaceMgmt

Migratepool

Archive Client Backup ClientHSM Client

Space management parameters:SPACEMGTECHNIQUE: Specifies whether a file is eligible for migration.AUTOMIGONUSE: Number of days a file was last accessed before it is eligible for automatic migration.MIGREQUIRESBKUP: Specifies whether a backup version of a file must exist before migrated.MIGDESTINATION: Destination storage pool

Figure 2: TSM server configuration concept Within the TSM server a client node is bound to a domain including management classes and copy groups. In each management class there are several parameters for space management (HSM) and two kind of copy groups, which can be selectively configured based upon the type of data the client node send to the TSM server:

Archive copy group is used for archive clients performing data archiving and defines the retention policies and destination storage pool. Backup copy group is used for backup clients performing data backup and defines the versioning and retention policies and destination storage pool. Space management (as part of the Management Class) is used for HSM clients performing data migration and defines whether a migrated file requires a backup and the destination storage pool. Note, there is no copy group for space management, the space management parameter set is part of the management class.

For the TSM HSM client implementation, the space management parameter set of the management class must be configured. One TSM client node (one V7000 Unified file module) can perform backup and HSM operations, which allows the implementation of the inline backup functions. With the inline backup function, migrated files, which must be backed up


are not recalled, instead they are copied directly in the TSM server from the destination storage pool of the space management copy group to the destination storage pool of the backup copy group. Because two V7000 Unified file modules can be configured to perform HSM migration for one or more file systems, a proxy node configuration has to be defined in the TSM server for the two nodes, representing the two file modules.

Reconciliation If migrated files are deleted or renamed in the file system of the V7000 Unified system, these changes are not instantly promoted to the migrated file content stored in the TSM server. In order to synchronize the inventory of the file system with the TSM server the reconciliation process has to be performed. Deleted files are removed from the inventory of the TSM server and for renamed files, only the metadata is updated in the TSM server without changing the file content. The reconciliation process also finds orphaned files whereby stubs are available in the V7000 Unified file system but no migrated files are available in the TSM server. The reconciliation process synchronizing the inventory of the file system with the TSM server shall be run periodically (e.g. once a week) based on schedules. Because the reconciliation process add workload to the file modules of the V7000 Unified system, it is recommended to run this process in time frames with no or low production workload (e.g. on weekends). When running the reconciliation process it must be assured that the file system is in a good state.

Considerations and Limitations Do not configure HSM policies using the V7000 Unified GUI because this will apply the same rules for Auto-migration and scheduled policies. The CLI offers much more flexibility configuring different policies and rules for Auto-migration and schedules. A maximum of one scheduled HSM policy can be run at a time. Scheduled HSM policies can impact V7000 Unified system performance. The first phase of a HSM policy run operates mainly on file system metadata and identifies files for migration. The second phase operates on the file system data itself by reading the files from the V7000 managed disk system and transferring them over the public network. Thus HSM policies shall be scheduled wisely to not interfere with other operations. TSM HSM cannot be configured for file systems including file sets. The underlying reason for this is that a file set can be unlinked which causes the associated subdirectory to disappear from the file system. A subsequent HSM reconciliation process (see section Reconciliation) will delete all files stored in that unlinked file set from the TSM server causing data to become lost. In order to prevent this it is not supported to activate TSM HSM for a file system including file sets. Migration and recalls transfer full (entire) and uncompressed files over the public network. The minimum supported TSM server version is 5.5. The recommended TSM server version is 6.x. Keep in mind that the HSM clients running on both V7000 Unified file modules must be licensed with the TSM server as space management clients.


V7000 Unified TSM HSM cannot be used for disaster recovery in case files have been lost in the file system, because the file attributes (e.g. ACL) are stored with the file. The migration-undelete tool will not recover the ACL of files. The recovery of the ACL requires to read each file from the external TSM server which could take several days. For disaster recovery the V7000 Unified asynchronous replication function and the TSM backup function have to be used. Asynchronous replication will cause recalls of already migrated files if the files have not been replicated already. Therefore the migration policies must be configured to assuring that replication happens prior to migration. If only the attributes of a migrated file have changed then the file might not be recalled, instead only the attributes are replicated. The V7000 Unified antivirus function skips migrated files upon bulk scans and does not cause a recall of migrated files. With the scan-on-read option it can be assured that migrated files are also checked for virus. TSM HSM does not work in conjunction with NDMP, both functions are mutually exclusive. For a complete list of limitations refer to the V7000 Unified Info Center [3].


Implementation guidance This chapter gives an overview of the planning and implementation of the TSM HSM function within a V7000 Unified system. It is assumed that the reader has basic administrative knowledge of the TSM server [4] and the V7000 Unified system [3].

Overview The implementation of the TSM HSM function in V7000 Unified presented here comprises the following steps:

1. Plan the TSM server configuration and HSM policies (see section Planning) 2. Configure TSM server for HSM (see section Configure TSM server) 3. Configure TSM definition server in V7000 Unified (see section Configure TSM

definition in V7000 Unified) 4. Activate HSM for file systems in V7000 Unified (see section Enable HSM in V7000

Unified) 5. Configure and test HSM policies (see section Create and apply policies) 6. Configure reconciliation schedules (see section Configuring Reconciliation schedules)

These steps are explained below including an extra section about Test the configuration and Monitoring HSM operations.

Planning A mapping of file systems configured in V7000 Unified to destination TSM servers must be accomplished. The file systems used for HSM migration can be selected based on requirements and the stored data in the file systems. Once a file system is selected for HSM migration, the destination TSM server must be determined. Multiple file systems can have the same TSM server as migration destination or each file system can have a distinct TSM server. The network location of the TSM server used as migration destination determines at which speed the file transfer between the V7000 Unified system and the TSM server can be performed. It is recommended to place the TSM server and the V7000 Unified within the 10-Gbit network. The naming of the TSM constructs should reflect the origin of the data. The TSM construct to be named are:

− policy domain name − policy set name − management class name − space management destination pool name − name and password of the system nodes (one system for each file module) − name and password of the proxy node (two system nodes are consolidated under

one proxy node) If multiple file systems use the same TSM server as migration destination it is recommended to plan one set of nodes (two system nodes and one proxy node) for each file system. This improves resiliency because if one set of nodes runs out of storage or loses the password the other sets of nodes are still operational. In addition TSM server reporting can be much easier be implemented on a node basis.


The type of storage pool used in the TSM server as space management destination has to be planned. It is recommended to use a disk-based storage pool (DISK or FILE device class) as a staging area to prevent dependencies on tape mounts during the migration. Afterwards the TSM server is migrating the data from the disk staging area to the tape storage pool.. When implementing migration from a TSM server disk storage pool to a tape storage pool, storage pools based on a FILE device class might be appropriate because the migration process is faster from a FILE devices class. To leverage the inline-backup function, the TSM server used for HSM migration has to be the same as the one used for TSM client backup of a given file system. The node names used for migration and backup are identical. Note: Technically the same storage pool hierarchy can be used for backup data and space management (HSM) data. Nevertheless, the recommendation is to separate the storage pool hierarchies for both types of data. The HSM migration policies must be planned. As outlined in section Migration Rules and Policies there are two types of policies: Auto-migration policies, which are activated for the file system and schedule policies, which are executed based on schedules. Both types of policies must be planned whereby the Auto-migration policies shall be simple and based on thresholds, whereas schedule policies can be based on file attributes. The schedule for schedule policies must be planned accordingly. Because the HSM migration policies are based on file system pools the architecture of the V7000 Unified storage pools belonging to a file system must be considered. For file system comprising multiple V7000 Unified storage pools which are configured for ILM it might be appropriate to configure HSM migration only for the last pool in the ILM hierarchy. Find below a summary-checklist for planning the implementation of TSM HSM with V7000 Unified:

__ Mapping of file systems (pool) to TSM server __ TSM server construct names __ TSM server storage pool names and hierarchy __ TCPIP address and port (data and admin) of the TSM server __ Inline backup function __ Auto-migration policy rules __ Schedule policy rules __ Time table for scheduled policies

Configure TSM server Before configuring the TSM server, the names of the constructs and the parameters must have been defined. The following checklist can be used to document the names and parameters: Construct name Parameter input Storage pool name for migration

name

Device class name number of volumes size of volumes number of concurrent

sessions

data format


Policy domain name name Storage pool name for backup (optional)

name

Device class name number of volumes size of volumes number of concurrent

sessions

data format Policy set name name Management class name name System node name 1 name password maxnummp System node name 2 name password maxnummp Proxy node name name password maxnummp Once the naming and parameters are determined the TSM server constructs can be defined as outline below. Define the storage pool. When using a FILE device class define this device class first and than the storage pool:

define devc devclass-name devt=File maxcap=size-of-volumes mountlimit=number-concurrent-sessions directory=path define stg stgpool-name devclass-name maxscr=number-of-volumes

The DISK device class is predefined in the TSM server, define the storage pool and volumes:

define stg stgpool-name DISK

define vol stgpool-name volume-name formatsize=size-of-volumes numberofvol=number-of-volumes

Define domain, policy set and management class

define domain domain-name define pol domain-name policyset-name define mgmt domain-name policyset-name mgmt-name spacemgtech=auto migrequiresbkup=no migdestination=HSMstoragepool-name assign defmgmt domain-name policyset-name mgmt-name

Optional: Define a backup copygroup for backup data define copygroup domain-name policyset-name mgmt-name type=backup destination=BACKUPstoragepool-name

Activate the policy set

Activate pol domain-name policyset-name


Note, you may get warnings that no backup copy group and archive copy group has been defined. These warnings can be ignored.

Define the system nodes and proxy node

Register node systemnode-name1 password dom=domain-name passexp=0 maxnummp=max-num-mountpoints Register node systemnode-name2 password dom=domain-name passexp=0 maxnummp=max-num-mountpoints Register node proxynode-name password dom=domain-name passexp=0 maxnummp=max-num-mountpoints Grant proxy target= proxynode-name agent= systemnode-name1,systemnode-name2

Check your configuration using the following command: Display the configured nodes (system and proxy node)

query node Display the backup copy group in the domain and within the active policy set:

query co domain-name active * format=detailed

Display the storage pool: query stg stgpool-name f=d

Obtain the following parameters from the TSM server (using the query stat command):

− server name − host name or TCPIP address − port number

Once the TSM server has been configured the TSM server definition can be configured in V7000 Unified (see section Configure TSM definition in V7000 Unified).

Configure TSM definition in V7000 Unified Prior to the configuration of the TSM server definitions in the V7000 Unified write down the TSM server properties. Fill in such table for each TSM server: TSM server property Input TSM server name1 TSM server IP address TSM server port (q stat) TSM server admin port (q opt) System node name 1 System node 1 password

1 The TSM server name is an alias name used in the V7000 Unified. This can be any name and it should be meaningful. Recommend is the name gathered from the query status output.


System node name 2 System node 2 password Proxy node name Proxy node password

Using the GUI Note, if the TSM server admin port is not the default port number (1500) then the TSM configuration in V7000 Unified must be done via the CLI!! Now configure the TSM server definition in the V7000 Unified using the GUI. Logon the V7000 Unified GUI and perform the following steps:

− select Files – Services – Backup Selection − select the TSM backup method (see figure 3)

Figure 3: Backup Selection menu

Note, if NDMP backup is configured it is not possible to configure HSM, because NDMP backup and HSM are mutually exclusive.

Select the Backup tab, press the Configure button (or Action – Configure TSM server) and enter the required fields:

− In the General tab enter the TSM server properties (alias name, IP address and port) and proxy node name (see figure 4):


Figure 4: TSM server definition - General Tab

− In the Node Pairing tab enter the system node parameters such as name and password (see figure 5):

Figure 5: TSM server definition – Node pairing Tab

− In the Script tab check the names of the nodes to be equal to the nodes and passwords configured in TSM

− Press OK which completes the TSM definition Note, if a failure occurs when creating the TSM server definition review the output of the message.

Ensure that the date and time of file modules (command lstime) and the TSM server are identical. Ensure that the TCPIP connectivity between the file modules and the TSM server works (use the root logon to verify this using the ping command). Ensure that the admin port of the TSM server is the default port number (1500). If this is not the case you have to use the CLI in order to specify a different admin port number.

Using the CLI The TSM server definition can also be configured using the CLI and the command cfgtsmnode. This command has to be issued twice, once for each file module. Find below an example:

cfgtsmnode tsm-servername TSM-server-IP TSM-server-port mgmt001st001 Proxy-nodename System-nodename1 password --adminport Admin-Port cfgtsmnode tsm-servername TSM-server-IP TSM-server-port mgmt002st001 Proxy-nodename System-nodename2 password --adminport Admin-Port

The TSM server definition can be viewed using the command: lstsmnode Once the TSM server definition has been completed HSM can be activated (see section Activate HSM in V7000 Unified).


Activate HSM in V7000 Unified Once the TSM server definition has been configured in V7000 Unified, HSM can now be enabled per file system. Thereby each file system subject for HSM migration is mapped to a TSM server definition. The TSM server definition is denoted by the TSM server name. The HSM activation can be performed via the V7000 Unified CLI, using the following command:

cfghsmnodes tsmservername mgmt001st001,mgmt002st001 cfghsmfs filesystemname tsmservername

Note, the tsmservername is the alias name of the TSM server, which you configured above. The filesystemname is the file system you previously created. It is recommended to activate HSM for one file system first and check that everything works as expected. To list the HSM configuration perform the following CLI commands:

lshsm lshsmlog lshsmstatus

Once the HSM has been activated for the file system in V7000 Unified, policies can be created (see section Create and apply policies).

Create and apply policies As described in section Migration Rules and Policies there are two kinds of HSM migration policies which can be configured:

The Auto-migration policies are activated for the file system and are automatically activated when the file system space utilization crosses a defined threshold within the policy. The Auto-migration must ensure that files are being migrated in order to free up space in the file system pools. The auto-migration policies must also include placement rules and ILM policies when required. Scheduled policies are automatically activated based on scheduled tasks. There can be multiple scheduled policies for one file system. Scheduled policies can be more sophisticated and pre-migrated or migrated files based on specific criteria such as file names, file size, file time stamps and other file attributes.

Even though policies are configured and activated for file systems they typically operate on a file system pool level. Thus the GPFS storage pool design must be available and understood in order to configure policies appropriately. Fill in the following table to document policies for the file systems: File system name Policy type

(auto-migrate or scheduled)

Policy text (abstract)


HSM rules and policies are configured and activated from the V7000 Unified CLI. The following sections outline the configuration and activation of auto-migration and scheduled policies.

Creating an Auto-migration policies An Auto-migration policies shall be threshold based and it must be effective. The auto-migration policy must also include a file placement rule. The following example configures and activates a typical Auto-migration policy with the name hsmsyspol for a file system with one pool (system). The policy will be triggered if the file system is filled 80 % or higher and oldest files are migrated first until it reaches 60 %. Create policy for threshold based migration including a default placement policy. The name of this policy is hsmsyspool which can be chosen differently:

mkpolicy hsmsyspol –R „RULE ‘hsmpool' EXTERNAL POOL 'hsm' EXEC ‘HSMEXEC'; RULE 'systemMigration' MIGRATE FROM POOL 'system' THRESHOLD(80,60) WEIGHT(ACCESS_TIME) TO POOL 'hsm‘; RULE 'default' set pool 'system'”

Check the policy:

chkpolicy filesystemName –P hsmsyspol If the policy has been successfully checked activate the policies for the file system

setpolicy filesystemName -P hsmsyspol Note, multiple auto-migration policies can be set for one file system using the command setpolicy. It is thereby important also to consider the ILM policies and include them with the setpolicy command. Verify the policy to be active

lspolicy –D filesystenName lspolicy –P hsmsyspool

Creating scheduled policy A scheduled HSM policy shall ensure that files matching certain criteria are migrated to the external TSM server on a periodic basis. The following example configures a policy named hsmdaily, which runs daily at 8 PM and migrate all files older than 60 days: Create policy, which migrate files not accessed for more than 60 days:

mkpolicy hsmdaily –R “RULE ‘hsmpool' EXTERNAL POOL 'hsm' EXEC ‘HSMEXEC';RULE ‘fileMigration' MIGRATE FROM POOL 'system‘ TO POOL ‘hsm’ WHERE (DAYS(CURRENT_TIMESTAMP) – DAYS(ACCESS_TIME) > 60)”

Create a placement policy, which is required for the chkpolicy command:

mkpolicy default –R “RULE 'default' set pool 'system‘” Check the policy

chkpolicy filesystemName –P default,hsmdaily


Note, the policy named default is a default placement policy and is required for this command. This policy can be deleted afterwards:

rmpolicy default The following command can be used to test-run the policy for a selected file system:

runpolicy filesystemName –P hsmdaily The policy run can be monitored with the following commands:

lsjobstatus --all showerrors [job-ID] showlog [job-ID]

Finally, schedule the to run daily at 8 PM

mkpolicytask filesystemName –P hsmdaily –hour 20 The previous command will create a cron task (named StartRunPolicy), which can be checked using the following command:

lstask –t cron -v More information and examples of HSM policies can be found in section Example of HSM migration rules and policies)

Using policy templates The V7000 Unified system includes a pre-defined policy template for HSM with the name TEMPLATE-HSM. In this template certain rule declarations and macros are predefined as shown below: Policy Name Declaration Name Default Declarations TEMPLATE-HSM is_empty N define(is_empty,(KB_ALLOCATED=0)) TEMPLATE-HSM stub_size N define(stub_size,0) TEMPLATE-HSM is_premigrated N define(is_premigrated,(MISC_ATTRIBUTES LIKE '%M%' AND KB_ALLOCATED > stub_size)) TEMPLATE-HSM is_migrated N define(is_migrated,(MISC_ATTRIBUTES LIKE '%M%' AND KB_ALLOCATED == stub_size)) TEMPLATE-HSM access_age N define(access_age,(DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME))) TEMPLATE-HSM mb_allocated N define(mb_allocated,(INTEGER(KB_ALLOCATED / 1024))) TEMPLATE-HSM weight_expression N define(weight_expression,(CASE WHEN access_age < 1 THEN 0 WHEN mb_allocated < 1 THEN access_age WHEN is_premigrated THEN mb_allocated * access_age * 10 ELSE mb_allocated * access_age END)) TEMPLATE-HSM hsmexternalpool N RULE 'hsmexternalpool' EXTERNAL POOL 'hsm' EXEC 'HSMEXEC' OPTS '-l LOGID' TEMPLATE-HSM systemtotape N RULE 'systemtotape' MIGRATE FROM POOL 'silver' THRESHOLD(80,70) WEIGHT(weight_expression) TO POOL 'hsm' WHERE NOT (is_migrated) AND NOT (is_empty) The above policy template defines (left to right) the policy name (TEMPLATE-HSM), the declaration name, the indication if this declaration is default and the declaration definition. For example the first entry in the template:

TEMPLATE-HSM is_empty N define(is_empty,(KB_ALLOCATED=0))


defines the declaration name is_empty, which is true if 0 KB are allocated. This declaration can be used for example to exclude files, which are empty. The HSM policy template can be used to create HSM policies as explained below. First copy the predefined template to a new policy named HSM-ACTIVE

mkpolicy HSM-ACTIVE -CP TEMPLATE-HSM When listing the new policy HSM-ACTIVE, it will show the same content as the policy template TEMPLATE-HSM:

lspolicy –P HSM-ACTIVE In the next step, the declaration systemtotape might have to be changed to use the system pool as the source pool for HSM migration instead of the silver pool.

chpolicy HSM-ACTIVE --remove systemtotape chpolicy HSM-ACTIVE --add "RULE 'systemtotape' MIGRATE FROM POOL 'system' THRESHOLD(80,70) WEIGHT(weight_expression) TO POOL 'hsm' WHERE NOT (exclude_list) AND NOT (is_migrated)"

In order to check this policy a default placement policy has to be added which places all file on the system pool:

chpolicy HSM-ACTIVE --add "RULE 'default' set pool 'system'" Now the policy can be checked:

chkpolicy filesystemName –P HSM-ACTIVE And now the policy can be set for the file system as Auto-migration policy.

setpolicy filesystemName -P default, HSM-ACTIVE Likewise the HSM policy template TEMPLATE-HSM can be used to create scheduled HSM policies.

Testing and monitoring the HSM policies HSM policies can be tested in two ways, either in a test-run mode where files subject for migration are identified and not migrated, or in a real-run mode where files subject for migration are identified and migrated. To start a test-run of the policy enter the command:

chkpolicy filesystemName –P default,hsmdaily -T This command will start a job and its job-ID and status can be listed with the command:

lsjobstatus --all The log of this job can be inspected with the command:

showerrors [job-ID] The error log of this job can be inspected with the command:

showlog [job-ID] To start a real-run of the policy enter the command:

runpolicy filesystemName –P hsmdaily This command will start a job and its job-ID and status can be listed with the command:

lsjobstatus --all The log of this job can be inspected with the command:


showerrors [job-ID] The error log of this job can be inspected with the command:

showlog [job-ID] In the TSM server, HSM client session can be listed using the TSM server command:

query session

Verifying migrated files from the share mount point If the file share has been exported to a Windows client using the CIFS protocol, migrated files will be represented by the offline-icon as shown in figure 6 (example for Windows XP) below:

Figure 6: shows the offline icon for the first file in the list, while the other file is resident. If the file share has been exported to a Unix client using the NFS protocol, migrated files can be recognized using the stat command. The actual size of the file will be shown but the blocks are set to 0 or another low number as shown below: #stat HSM_LFTS_spec_dominic.rtf File: ` HSM_LFTS_spec_dominic.rtf ' Size: 14753792 Blocks: 0

Configuring Reconciliation schedules As outlined in section Reconciliation, the reconciliation process is an essential part of the HSM implementation because it assures that the inventory of the V7000 Unified file system is synchronized with the external TSM server. Therefore reconciliation tasks can be scheduled for each file system, which is configured for HSM. The reconciliation task does not have to run every day, it is sufficient to run this task once a week or once a month. It is important to schedule this task during time frames with low file system workload, because this task will cause intensive metadata operations in the file system. To configure reconciliation to run every Sunday at 4 AM perform the following command:

mkreconciletask filesystemName -minute 0 -hour 4 -dayOfWeek 0 Alternatively a scheduled cron task can be configured using the following command:

mktask StartReconcileCron -p filesystemName -minute 0 -hour 4 To verify reconciliation tasks and schedules perform the following command:

lsreconciletask lstask –t cron


Appendix

References [1] V7000 Unified backup whitepaper http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102046 [2] GPFS admin guide and policies: http://publib.boulder.ibm.com/infocenter/clresctr/vxrx/index.jsp?topic=%2Fcom.ibm.cluster.gpfs.v3r4.gpfs200.doc%2Fbl1adv_storage_mgt.html [3] V7000 Unified Info center: http://publib.boulder.ibm.com/infocenter/storwize/unified_ic/index.jsp [4] TSM 6.3 Info center http://publib.boulder.ibm.com/infocenter/tsminfo/v6r3/index.jsp

Example of HSM migration rules and policies Find some example rules and policies for HSM migration in this section.

Size based migration The following policy migrate all files from system pool to HSM which are larger than 2 MB. This is a typical schedule policy and shall not be used as Auto-migration policy: mkpolicy hsm_size –R "RULE 'hsmpool' EXTERNAL POOL 'hsm' EXEC 'HSMEXEC' OPTS '-l LOGID';RULE 'sizeMigration' MIGRATE FROM POOL 'system' TO POOL 'hsm' WHERE (INTEGER(KB_ALLOCATED) / 1024) > 2)" Note, the integer conversion (INTEGER(KB_ALLOCATED / 1024) > 2) cuts off the digits after the comma. The next rule is more precise mkpolicy hsm_size –R "RULE 'hsmpool' EXTERNAL POOL 'hsm' EXEC 'HSMEXEC' OPTS '-l LOGID';RULE 'sizeMigration' MIGRATE FROM POOL 'system' TO POOL 'hsm' WHERE (INTEGER(KB_ALLOCATED) > 2048)"

Premigration policy The following policy performs premigration based on size. Thereby premigration is performed if the system pool is utilized less than 50 %, otherwise migration is performed until 50 % are reached. Only files are migrated which are larger than 2 MB. This is a typical schedule policy: mkpolicy hsm_size_premig -R "RULE 'hsmpool' EXTERNAL POOL 'hsm' EXEC 'HSMEXEC' OPTS '-l LOGID';RULE 'sizeMigration' MIGRATE FROM POOL 'system' THRESHOLD(0,50,0) TO POOL 'hsm' WHERE (KB_ALLOCATED > 2048)" The statement THRESHOLD(0,50,0) means, that the rule starts when 0 % of the file system are occupied, if less than 50 % of the file system are full, then everything which is identified by the rule is pre-migrated. Otherwise, if the file system is more than 50 % full, files are migrated until the threshold drops below 50 %


http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102046

http://publib.boulder.ibm.com/infocenter/clresctr/vxrx/index.jsp?topic=%2Fcom.ibm.cluster.gpfs.v3r4.gpfs200.doc%2Fbl1adv_storage_mgt.html

http://publib.boulder.ibm.com/infocenter/clresctr/vxrx/index.jsp?topic=%2Fcom.ibm.cluster.gpfs.v3r4.gpfs200.doc%2Fbl1adv_storage_mgt.html

http://publib.boulder.ibm.com/infocenter/storwize/unified_ic/index.jsp

http://publib.boulder.ibm.com/infocenter/tsminfo/v6r3/index.jsp

Age based migration This policy performs migration of all files which have not been accessed for more than 30 days from the system pool. This is a typical schedule policy and shall not be used as Auto-migration policy: mkpolicy hsm_age –R "RULE 'hsmpool' EXTERNAL POOL 'hsm' EXEC 'HSMEXEC' OPTS '-l LOGID';RULE 'ageMigration' MIGRATE FROM POOL 'system' TO POOL 'hsm' WHERE (DAYS(CURRENT_TIMESTAMP) – DAYS(ACCESS_TIME) > 30)"

Threshold based migration This policy performs migration of all files if the system pool is filled more than 80 % until 60 % are reached. Thereby files with the oldest access date are selected first. This is a typical Auto-migration policy: mkpolicy hsm_threshold –R "RULE 'hsmpool' EXTERNAL POOL 'hsm' EXEC 'HSMEXEC'; RULE 'systemMigration' MIGRATE FROM POOL 'system' THRESHOLD(70,60) WEIGHT(ACCESS_TIME) TO POOL 'hsm‘“ The statement WEIGHT(ACCESS_DATE) selects files based on last access date (oldest first).

Disclaimer This document reflects the understanding of author on many of the questions asked about archiving solutions with IBM hardware and software. This document is presented “As-Is” and IBM does not assume responsibility for the statements expressed herein. It reflects the opinions of the author. These opinions are based on several years of joint work with the IBM Systems group. If you have questions about the contents of this document, please direct them to the Author ([email protected]). The Techdocs information, tools and documentation ("Materials") are being provided to IBM Business Partners to assist them with customer installations. Such Materials are provided by IBM on an "as-is" basis. IBM makes no representations or warranties regarding these Materials and does not provide any guarantee or assurance that the use of such Materials will result in a successful customer installation. These Materials may only be used by authorized IBM Business Partners for installation of IBM products and otherwise in compliance with the IBM Business Partner Agreement.”

Trademarks The following terms are trademarks or registered trademarks of the IBM Corporation in the United States or other countries or both: the e-business logo, IBM, system x, system p, System Storage. Microsoft and Microsoft Windows are registered trademark of Microsoft Inc. in the United States. Other company, product, and service names may be trademarks or service marks of others.


mailto:[email protected]

Documents

Overview of V7000 Unified HSM integration