Setting up System Storage Archive Manager with Snaplock storage pools
Nils Haustein 060000NX38 Visits (6432)
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: http
When SSAM writes an object to a new Snaplock volume the following steps are done:
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:
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
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:
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)
Find more information about Snaplock with SSAM in the TSM Info Cent