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.
© IBM Corporation 2012
Page 3
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:
ACE
File Module
File Module
TSM HSM
Public network
Migration
& Recall
V7000 disk
External TSM Server
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).
© IBM Corporation 2012
Page 4
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
© IBM Corporation 2012
Page 5
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 Automigration 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 (Automigration and schedule policies).
© IBM Corporation 2012
Page 6
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.
HSM Client
Archive Client
Backup Client
Policy Domain
Policy Set (Active)
Mgmt. Class
Archive copy
Group
Archivepool
Backup copy
Group
Backuppool
Space
Mgmt
Migratepool
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
© IBM Corporation 2012
Page 7
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.
© IBM Corporation 2012
Page 8
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 migrationundelete 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].
© IBM Corporation 2012
Page 9
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 10Gbit 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.
© IBM Corporation 2012
Page 10
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
Storage pool name for
migration
Parameter
name
input
Device class name
number of volumes
size of volumes
number of concurrent
sessions
data format
© IBM Corporation 2012
Page 11
Policy domain name
Storage pool name for backup
(optional)
Policy set name
Management class name
System node name 1
System node name 2
Proxy node name
name
name
Device class name
number of volumes
size of volumes
number of concurrent
sessions
data format
name
name
name
password
maxnummp
name
password
maxnummp
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
© IBM Corporation 2012
Page 12
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,systemnodename2
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
TSM server name 1
TSM server IP address
TSM server port (q stat)
TSM server admin port (q opt)
System node name 1
System node 1 password
Input
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.
© IBM Corporation 2012
Page 13
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):
© IBM Corporation 2012
Page 14
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).
© IBM Corporation 2012
Page 15
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
© IBM Corporation 2012
Policy type
(auto-migrate or
scheduled)
Policy text (abstract)
Page 16
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 automigration 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
© IBM Corporation 2012
Page 17
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
© IBM Corporation 2012
N
define(is_empty,(KB_ALLOCATED=0))
Page 18
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:
© IBM Corporation 2012
Page 19
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
© IBM Corporation 2012
Page 20
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 %
© IBM Corporation 2012
Page 21
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 Automigration 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 (nils_haustein@de.ibm.com).
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.
© IBM Corporation 2012
Page 22