Originally posted by: Nils Haustein
I have recently supported an implementation of System Storage Archive Manager (SSAM) with storage pools on N series Snaplock volumes. I would like to share some experiences especially when event based retention is used with SSAM.
The drawing below shows the system architecture. The SSAM software runs on AIX in this example. The AIX server is connected via 10 GBit Ethernet to the N series which is configured to provide NFS shares based on snaplock volumes. The SSAM DB is stored on internal mirrored disk of the AIX server. The storage pools are stored o the NFS shares provided by N series.
Using Snaplock storage pools with SSAM provides an additional layer of WORM protection because with Snaplock (Compliance Edition) it is not possible to delete SSAM storage pool volumes stored in Snaplock pools. However, there are some aspects to consider.
How SSAM works with Snaplock volumes
SSAM sets the Snaplock retention based on the RETMIN and RETVER value configured in the archive copy group which has the Snaplock pool as destination. SSAM uses the append capabilities of Snaplock, which allows to append data to a Snaplock volume. This is done be resetting the read-only mode, appending data to the Snaplock file and setting the file read-only again.
More information about Snaplock append, see here: https://library.netapp.com/ecm/ecm_download_file/ECMP1196889
When SSAM writes an object to a new Snaplock volume the following steps are done:
-
create an empty file
-
make the file read-only
-
make the file read-write --> this enables the append mode
-
append the data --> only append is allowed, no overwrite possible
-
determine the expiration date based on the RETMIN and RETVER values of the objects in the volume
-
set Snaplock retention for the storage pool volume by setting the last access time to the expiration date
-
when the volume is full then set the file read-only
Event based copy groups and reclamation
A special challenge arises when the archive copy group referencing the Snaplock pool as destination is event based (retinit=event). Because when SSAM sets the retention on the Snaplock volume it cannot respect the event-based aspect because this means indefinite retention as long as no event has been sent. It may take years before an event is sent. Instead SSAM sets the Snaplock retention to the maximum of RETMIN and RETVER relative to the archive date. If RETMIN and RETVER are 0 then the Snaplock retention set by SSAM is 0 days from now and this is set by SSAM. In this case the Snaplock minimum retention kicks in which is recommended to be 30 days. So the Snaplock volume is only protected for 30 days which by the way is the reclamation period in SSAM.
And here comes the reclamation issue: SSAM determines reclamation candidates based on the Snaplock volume retention and NOT based on the actual object retention. In the scenario where RETMIN and RETVER are 0, the Snaplock volume (once full) is candidate for immediate reclamation. The reclamation takes place within reclamation period of 30 days. When reclamation start the server determines the reclaimable space based on the actual object retention (the object retention may still be indefinite) and compares this to the reclamation threshold. If the reclaimable space is not greater than the threshold, the server resets the retention date of the volume by the amount specified in the RETENTIONEXTENSION option. The new retention period is calculated by adding the number of days specified to the current date.
If the reclaimable space is greater than the threshold the server sets the retention date of the target volume to the greater of these values:
-
The remaining retention time based on RETMIN and RETVER of the data (this might still be zero), plus 30 days for the reclamation period.
-
The RETENTIONEXTENSION value plus 30 days for the reclamation period.
So if the RETENTIONEXTENSION is default 365 the Snaplock volume retention is extended every year for another year, assuming that no data has expired. If some data expires (event has been sent) and the reclaimable space is greater than the reclamation threshold, the volume is reclaimed and the target volume gets a retention of 365 days, and so on.
General configuration recommendations
NOMIGRECL should be disabled (not set)
Make sure reclamation is configured (reasonably) for the Snaplock pools
RETENTIONEXTENSION should be set to the default (365 days)
RETMIN and RETVER should reflect the objects actual retention period
-
the Snaplock retention is set to max(RETMIN,RETVER) relative to the archivedate
-
if RETMIN=RETVER=0 than the Snaplock volumes have no retention and are forced to RETENTIONEXTENSION during reclamation
Direct group copy groups with the same retention to the same Snaplock pools, so the volume retention matches the copy group
On the Snaplock volume (within the N series) set the following values:
-
minimum retention: 30 days (enforced by Snaplock if last access date < 30 days from now)
-
default retention: 30 days (enforced by Snaplock if no last access date is set)
-
maximim retention: 30 years (enforced by Snaplock if last access date > 30 years from now)
When migrating data from DR550 to SSAM with Snaplock pools then the Snaplock pools should be nextpools to disk pools because the import does not set the Snaplock retention accordingly (only RETENTIONEXTENSION)
-
the disk pools MUST have volumes
-
disk pools must have the same name as on the source
-
Snaplock pools as nextpool of the disk pool must have different names
-
at the end of the migration the disk pools can be migrated completely, deleted and the Snaplock pools can be renamed
Find more information about Snaplock with SSAM in the TSM Info Center:http://pic.dhe.ibm.com/infocenter/tsminfo/v6r3/index.jsp?topic=%2Fcom.ibm.itsm.srv.doc%2Fc_mplmntpol_snaplock.html