Mainframe Storage

 View Only

What's New in IBM Copy Services Manager

By Randy Blea posted Tue December 13, 2022 01:00 AM


In Dec 2022 IBM GA'd a new version of IBM Copy Services Manager 

Copy Services Manager Download

IBM Copy Services Manager is a storage replication product that provides a single place to manage all the replication across your IBM storage environment.  With IBM Copy Services Manager customers can simplify the management of their replication solutions while providing disaster recovery and high availability to their applications. 

As always, we're very excited to provide the following key features being released in this new version.  We develop Copy Services Manager in an agile development cycle and as such have included a number of customer requested features!!!

RFE CSM-I-96– REST API to update Spectrum Virtualize connection credentials

  • With the heightened awareness of security nowadays, customers are updating their credentials more and more frequently.  However, for products like CSM, which needs a connection to all the storage systems being managed, this can be problematic as CSM has to be updated with the correct credentials to ensure there's not disruption to the customer's replication management, recovery capabilities, or Safeguarded Copy backup creations.  
  • Starting with the,  a new REST API is now available to allow customers to programmatically change CSM when a credential change has been made to their Spectrum Virtualize system.  This streamlines the process for customers making it far easier to make the change in their environment and meet their security guidelines. 
  • NOTE: The updateHMC command is already available for updating the credentials of a DS8000 HMC connection.

RFE CSM-I-106 and CSM-I-108– Audit log message for all successful logins and the ability to disable log messages

  • Another security related feature that went into the release was RFE CSM-I-106.  In order to track which users logged into CSM, through any of the CSM interfaces, a new audit log message will appear in the CSM console.  IWNR4005I indicates which user successfully logged in and at what time. 
  • There are cases though where this extra audit logging may result in flooding the console, such as when extensive automation is used via either the CSM CLI or REST interfaces.  For these cases, RFE CSM-I-108 was implemented to allow customers to choose to suppress the message. By adding the following property and setting it to false on Settings -> Server Properties, the IWNR4005I message will no longer appear in the console.

Support for Spectrum Virtualize Volume Group Safeguarded Snapshots

  • In the CSM 6.3.3 release, support was added for the the Spectrum Virtualize Volume Group Snapshot feature.  See the 6.3.3 blog for more details.  Starting with the, with the same Spectrum Virtualize Snapshot session, you can specify to either create a regular Snapshot or a Safeguarded Snapshot.
  • Safeguarded Snapshots use the same base Volume Group Snapshot technology, however they are safeguarded and thus provide extra protection including preventing a malicious user from deleting the Snapshot. 
  • With CSM you can create BOTH regular Snapshots and Safeguarded Snapshots, at the exact same time and even on different schedules.  For example, if you wanted to say take regular Snapshots hourly, but wanted to preserve a Safeguarded snapshot once a day and retain it for 7 days, you simply create two different Scheduled Tasks in CSM.  One that creates the hourly regular backups using the "Create Snapshot" command.  And another that takes daily backups with a 7 day retention using the "Create Safeguarded Snapshot" command. 
  • The CSM GUI/CLI/REST interfaces display which snapshots are Safeguarded and which aren't.  As well as what the retention date is for each snapshot, making management of hundreds of snapshots easier in a large environment.

Infrastructure changes: Move to Java 11 and new SSH handler

  • A couple of major infrastructure changes have been made in the CSM 6.3.5 release. 
  • The CSM server code has moved from Java 8 to Java 11.  There were a couple of reasons for this move.  First, the IBM Java 8 JRE will be going out of support in a few years.  Second, this allows CSM to pickup some of the new Java features as well as stay on top of the latest Java security fixes.
  • The second infrastructure change was a change to how CSM makes SSH calls outside the CSM server.  CSM will use SSH when connecting to a Spectrum Virtualize / FlashSystem storage system.  It will also use SSH when a Scheduled Task is created with an External Command action.  These SSH calls in the past used internal SSH code.  In CSM 6.3.5, Apache Mina will now be embedded in the server to make the SSH call.  This allows CSM to stay on top of the latest security algorithms and fixes while concentrating on customer requests for the CSM product. 
  • NOTE: These changes are only to the internal infrastructure.  Changes should have no noticeable affect on behavior or features in CSM.

Apache MINA - Wikipedia

RFE CSM-I-93– Define users to receive session level email events

  • CSM provides both SNMP and email alerts.  In recent releases, CSM added the ability to define an email address for a user, or use the email address defined on an LDAP user do that users can be selected when defined email alerts instead of having to enter a list of email addresses.  This allows customer to setup alert notification much faster and tie it to the actual users allowed to access the server.
  • RFE CSM-I-93 was open however, because when selecting a user and requesting that they receive a Session State Change type alert, that user would get alerts for ALL sessions as opposed to just the sessions they may have access to or want to monitor.  This is particularly an issue in multi-tenancy environments, where certain users should never receive alerts for sessions managed for other customers. 
  • Starting in CSM 6.3.5, when you select to add a Session State Change type event,  you will now be prompted to choose which sessions that user should receive email alerts for.  Only sessions the user has access to will show in the list.  A subset of those sessions, or all the sessions can then be selected. 
  • This solution provides a CSM admin far greater control of who receives events for which sessions.

RFE CSM-I-98– Internal change to start all MM pairs in GC mode for DS8000, to improve synchronization performance

  • CSM customers can start DS8000 Remote Copy relationships in Metro Mirror mode or Global Copy mode.  When starting pairs in Metro Mirror mode however, if there is a large number of out of sync tracks across a large number of volumes, customers have noticed that synchronization times may slow down as some of the pairs reach a Prepared/Duplex state, as the hardware prioritizes the writes to those volumes in order to keep the source and target in synch without having application impact.  The issue with this is that it causes the pairs that are not yet Prepared/Duplex, to take longer to synchronize than they normally would. 
  • To better handle this, CSM will now internally start all pairs in the role pair, in Global Copy mode first, if the customer issues a start for Metro Mirror.  Internally CSM will then monitor the pairs and once the role pair reaches a state of 99% in sync across all the pairs in the role pair, CSM will then establish the pairs in Metro Mirror mode.  By doing this, it will prevent any pairs from going into Metro Mirror mode too soon allowing the synchronization or resynchonization to complete faster. 
  • Nothing external is necessary for a customer to do and no changes in procedures are necessary.  The above all happens automatically in order to try to optimize the synchronization or resynchronization process.

Support for using z/OS HyperSwap to migrate from older DS8000 storage systems to new DS8000 storage systems

  • Performing a hardware refresh in order to pick up new enhancements or to get better performance with the latest technology can be quite stressful.  It can also be quite difficult and may even require customers shut down the applications for a short period to start back up on the new hardware.
  • Starting with CSM 6.3.5.x, we're releasing a new Migration solution for mainframe customers using DS8000 based on z/OS HyperSwap technology.  HyperSwap on z/OS could be used for migrations today, however, there is often fear to do so as customers don't typically want to swap until they are ready to do so and an unplanned HyperSwap trigger might result in a swap before they are ready. 
  • With the new solution, a new type of HyperSwap configuration will be available that can be used only for Migration purposes.  The configuration does NOT respond to HyperSwap triggers (will only swap by command, when you're ready to swap) and provides a few new features to make migration easier. 
  • Important Notes:
    • - This solution is does NOT require a full CSM license and is available as part of the base license for all CSM servers running on a DS8000 HMC. 
    • - This solution will work whether you're managing your existing relationships with CSM, GDPS or DSCLI. 
    • - This solution requires z/OS APAR OA62931 and may require the DS8000 RPQ for hardware reserves IF volumes being migrated are shared across multiple sysplexes.
    • IOS APAR OA62931 is not available at the time of the GA.  A fixpack for 6.3.5.x will be delivered sometime at the beginning of 2023 when that APAR is available which enables this new feature.
  • Automatic session creation for existing relationships

    • When CSM detects that the volumes being swapped are already in another remote copy relationship, regardless of whether CSM is managing those pairs or not, CSM will automatically generate a new CSM Migration session where there sources are the new source volumes on the new storage system and the targets are the old target volumes.
    • CSM will automatically establish the relationship in GC mode from the new source to old targets which takes advantage of the multi-target DS8000 support so that this can be done without requiring a full copy.
    • As soon as the migration is complete, you can them import those GC relationships into a new MM/GM solution to resume replication as it was running before off the old targets.
  • Unfence and Clip

    • After a HyperSwap is issued, even with the new Migration HyperSwap configuration type, the original sources are soft fenced on the DS8000.  By soft fencing the volumes, customers can rest assured that they can't accidentally IPL off of the old volumes. 
    • Once the migration has been confirmed completed though, you'll need to cleanup the old relationship.  With this solution there is a new Unfence and Clip command.  This command will not only remove the soft fence from the hardware, but will clip the volsers as well. 
    • Removing the soft fence allows you to terminate the relationships, while clipping the volsers helps to ensure that the volumes cannot be accidentally used as primaries still.
    • An Undo Clip command is also available in the event that you need to undo the clip after issuing Unfence and Clip.
  • Support for "shared" volumes across sysplexes

    • Some customers may share volumes across multiple sysplexes.  This can complicate a migration because all sysplexes must swap those volumes to the new storage system at the same time.
    • This solution supports shared volumes across sysplexes by taking advantage of the Hardware Reserves support on the DS8000 (available via RPQ).
    • Customers can setup a different Migration session for each sysplex which shares the volumes and enable HyperSwap for Migration on each of those sessions. 
    • When a swap occurs, z/OS IOS will use it's existing Hardware Reserves solution and swap the sessions on the other sysplexes. 
  • Steps for migrating when volumes are NOT shared across sysplexes

    • 1.  Setup a Migration session where the H1 volume is the same as the existing sources, and the H2 volume is what will be the new source volume.

      2.  Issue StartGC H1->H2 on the Migration session

      3.  Update the properties for the Migration session selecting the sysplex/system the volumes are attached to and the checkbox “Manage H1-H2 Migration with HyperSwap

      4.  Confirm that Hyperswap configuration loaded (should indicate HyperSwap = Yes on the CSM GUI.

      5.  Once Progress reaches >99% (recommended), issue the Swap and Sync command.

      6. The Swap and Sync command will tell IOS to drive all pairs to MM and then automatically swap the I/O from the H1 volumes to the H2 volumes once all are Prepared/Duplex. 

      7.  If CSM detected existing relationships, you’ll then find a new CSM Migration session automatically created and running between the new sources and old targets.

  • Steps for migrating when volumes ARE shared across sysplexes

    • 1.  Request RPQ to enable Hardware Reserves support on the DS8000

      2.  Setup a Migration session where the H1 volume is the same as the existing sources, and the H2 volume is what will be the new source volume.

      3.  Repeat step 2 and ensure that there is a Migration session for each H1 that is shared across sysplexes, for each sysplex it’s shared in

      4.  Issue StartGC H1->H2 on all the Migration sessions

      5.  Update the properties for the Migration sessions selecting the sysplex/system the volumes are attached to and the checkbox “Manage H1-H2 Migration with HyperSwap

      6.  Confirm that Hyperswap configuration loaded (should indicate HyperSwap = Yes on the CSM GUI on all sessions

      7.  Once Progress reaches >99% (recommended) on all sessions, issue the Sync command. The Sync command will tell drive all pairs to MM mode. 

      8.  When all sessions reach a Prepared state and you’re ready to migrate, issue the Swap command to all sessions.  NOTE: With Hardware reserves all other sessions may automatically swap when IOS detects a swap has occurred.  If it doesn’t, issue the Swap command.  

      9.  If CSM detected existing relationships, you’ll then find a new CSM Migration session automatically created and running between the new sources and old targets.

  • Cleanup after migration

    • After performing a HyperSwap for Migration, a new command will be available on the Migration session.
    • Unfence and Clip, is an optional command customers can issue which after the swap is confirmed to be successful, removes the soft fence from the original source volumes and then clips the volsers.
    • By clipping the volsers, it helps to ensure that customers don’t IPL off the wrong volumes. By removing the soft fence the customer can now terminate and cleanup the old relationships as well as the Migration session used for the HyperSwap.
    • If CSM had detected, that there were preexisting pairs, customers can import the the copy sets from the new Migration session into a MM, GM or other CSM session so that they can be fully integrated into their remote copy solution.

CSM 6.3.5 What’s New Video

Idea/RFE support for Copy Services Manager

If you wish to open a new IDEA (formally called a Request for Enhancement) on IBM Copy Services Manager, you can now do so through the following link.