DFSMSdss just got a powerful upgrade! With the latest enhancements, we are harnessing z/OS Cloud Data Access (CDA) to take our transparent cloud tiering (TCT) backup solution to the next level. But that’s not all—we have also introduced a game-changing, storage vendor-agnostic direct-to-cloud solution. Now, clients without IBM disk storage can seamlessly back up their data straight to the cloud. The enhancements provide more flexibility, more choices, and more ways to simplify your storage strategy.
CDA is the latest and greatest z/OS DFSMSdfp access method, built to revolutionize how you connect with cloud object storage from IBM Z. Designed for seamless integration, CDA provides a unified environment with a common set of APIs to effortlessly communicate with top cloud providers—including S3-compatible IBM Cloud Object Storage, Amazon S3, Azure Blob Storage, and Google Cloud Storage. With CDA, DFSMSdss clients gain the power to target any cloud object storage with ease, unlocking new levels of flexibility and efficiency in data management. In addition, combining the features of CDA with TCT has allowed us to enhance the existing solution for all TCT supported cloud storage types.
So, what is the new DFSMSdss enhancement?
First, with our DFSMSdss S3 Support for TCT (OA63892), we have leveraged CDA provider files to allow each end-user the ability to tailor their cloud network connection enabling more control over their backups. Unlike the traditional SMS network connection which enforced a unique cloud name across the entire environment, this enhancement now allows two users to define the same cloud endpoint in their own way. But wait! There’s more —CDA provider files enable multiple endpoint configurations, eliminating the single point of failure that SMS network connections traditionally faced with their single-endpoint limitation – a necessary enhancement for those using TS7700 as an object storage cloud! This ability was introduced for z/OS V2.5 and above.
Additionally, a new direct-to-cloud option is now available with APAR OA66450 for those on z/OS 3.1. Our clients have expressed a need for a disk storage vendor-agnostic solution for cloud object storage; With direct-to-cloud, we provide a software-only solution where we can target any cloud storage provider supported by CDA. Since everything hinges on the provider file, end-users have greater flexibility in managing their cloud storage backups!
Why you should care:
You still need to be convinced?? We know our clients want to leverage cloud object storage and we are providing our customers with multiple hybrid cloud solutions.
The existing TCT solution enables direct data movement from IBM DS8000 to cloud object storage, without the need for data to go through the host, which potentially provides significant savings in mainframe CPU utilization on large data migrations. Recent enhancements that allow multiple endpoint configurations make this solution more resilient.
Additionally, we now have a software-only, storage vendor-agnostic direct-to-cloud solution where we can target any cloud storage provider supported by CDA! Our users can seamlessly back up their data straight to the cloud with more flexibility, more choices, and more ways to simplify their storage strategy!
How to take advantage of the new enhancements:
We’ve introduced a new keyword, CDAPROVIDERFILE, which tells DSS to first check for the presence of a CDA provider file before defaulting to an SMS network connection. When specified, the CLOUD(provider_name) value is used to locate the file either in the user’s home directory at ‘~/gdk/providers/provider_name.json’ or in the CDA default location ‘/usr/lpp/dfsms/gdk/providers/provider_name.json.’ If the file is found, CDA will parse it for correctness. If the file does not exist, the file is empty or is not marked as enabled for the use of DFSMSdss (more on this later), we revert to using an SMS network connection matching the provider_name as usual.
Enabling the provider file for DFSMSdss:
The provider file is a UNIX file that is in JavaScript Object Notation (JSON). Since CDA provider files pre-date our support of CDA, there may be existing files in such an environment that coincidentally match the specified provider file but were not intended for use for your backups. To remedy this issue, we require that you update any desired provider file to have the following key-value pair if you want DSS to use it.
We have shipped sample provider files as examples on how to do so in ‘/usr/lpp/dfsms/dss/samples/’
Selecting a desired cloud solution:
Specifying the CDAPROVIDERFILE keyword and finding the desired provider file in your environment is a great step in the right direction to taking advantage of these recent enhancements. Prior to getting that far in processing, you should decide which solution you desire so that it can be communicated to DSS.
Transparent Cloud Tiering:
TCT supports either a subset of cloud storage providers or a TS7700 as an object storage cloud. If you desire to use TCT, it starts by specifying the following key-value pair:
For TS7700 as an object storage cloud:
Otherwise:
Direct-to-cloud:
Any provider file that does not have the ‘tctType’ key-value pair is assumed to be a direct-to-cloud solution connection.
What about CDA environment setup:
Prior to getting started with these enhancements, there is some CDA dependent setup you will be required to perform, which will include:
- A required OMVS segment for the invoking user
- A ‘gdk/’ directory in the user’s home directory
- Configuration and provider files within
- User access for CDA required services.
Luckily, you can find a quick start guide in their documentation to help you navigate those waters: https://www.ibm.com/docs/en/zos/3.1.0?topic=services-cloud-data-access-configuration
Stay Tuned:
DFSMSdss will be releasing more blog entries on our cloud support to help you decipher our two distinct cloud solutions and highlight their functionality in more detail.
We would love to hear your thoughts on these enhancements, leave a comment on this blog post, start a discussion on the DFSMS Community Page, or join the Mainframe Data Management LinkedIn group to discuss in the comments there!
Author:
Ernesto E. Figueroa
Editors:
Alexis Kapica
Barbara McDonald
