Ian Wright
Client Technical Sales Engineer
In my last blog, I addressed Transparent Cloud Tiering (TCT) for the DS8000 and Mainframe environments. In this one, we’ll focus on Open System versions that are available on Spectrum Scale and Spectrum Virtualize.
With Spectrum Scale, there is a strong history of tiering. Going back to the days when it was called GPFS, it has long had the ability to set up Information Lifecycle Management (ILM) policies. So, when a file was first created, maybe it would be on SSDs or Flash. If a customer knew that files tended to be touched less frequently after 30 days, then maybe it would move down to a 10k RPM disk. After 60 to 90 days maybe it would end up on tape.
With Spectrum Scale TCT, the cloud is an option as well, and managed by the same ILM process. You may have multiple tiers of disk locally, but for long-term retention (or to reduce your local footprint, if you know that data is not being accessed), cloud adds to the value of Spectrum Scale. As with any other tier, the data is accessible and files that have moved to the cloud are visible as a stub. It just requires planning to make sure that the data that is tiered out to cloud (as with any other tier) is truly unlikely to be accessed, as there will be some lag during the data transfer.
When combined with IBM Cloud Object Storage (ICOS), there’s also a benefit for compliance archiving. Businesses that are required to keep certain documents for a specified period of time can create Locked Vaults in ICOS. This means that when the Spectrum Scale cluster writes to the cloud tier with its private key, that data cannot be deleted until the expiration period has passed. This may allow better costs and flexibility than with traditional storage.
As with the DS8880 example in my previous blog, this really opens the possibility, on a financial level, of just using Flash for anything that would normally have been disk based. For anything that has aged out of use, customers can decide if tape or cloud works best for them, as they are not supported together on the same file system currently. Then, they can really look at the economics of both, but leave the production activity to Flash rather than spinning disk, if the data is likely to be accessed.
The final version of TCT is for Spectrum Virtualize, which runs at the heart of the SAN Volume Controller, Storwize systems, and the FlashSystem V9000. This version takes advantage of the FlashCopy technology that has been part of the SVC code from the beginning.
Normally, FlashCopy is used to create SnapShots, Clones, and Backups within an SVC Cluster or a Storwize or V9000 system. In the case of Transparent Cloud Tiering, it is used to snap a copy of a volume to an Object Store. This could be any OpenStack Swift or S3 container.
Taking the SnapShot can be used for backup and restore purposes, to make sure that a backup of certain volumes exists, but isn’t taking up local space. This needs to be weighed against the costs and time of bandwidth, however, and may not make sense for all customers. One of the more likely uses of it will be for archival purposes.
When a volume has aged past a certain point and is no longer needed, the TCT function could be used to snap a copy of it to the Object Store and then delete the local copy. It can still be restored to the SVC cluster or disk system at any time. Moreover, it could also be migrated to another system or cluster, if needed.
Of course, these are high-level descriptions of the TCT options for Spectrum Scale and Spectrum Virtualize. There are many details to consider, including types and vendors of the object store; whether the “cloud” would actually be local or a CSP; and deciding how and when to use it. We would be happy to discuss these things with you.
Please contact your Mainline Account Executive directly, or click here to contact us with any questions.