Mainframe Storage

 View Only
  • 1.  DS8000 migration with DSCLI

    Posted Fri December 09, 2022 09:31 AM
    We have a GM setup between two DS8K and are replacing them with two newer DS8K. 

    Given that we've already GC cascaded the new secondary. Is there any reason not to just shut down the systems, pause the GM with secondary, remove the GM/FC/GC and rebuild the PPRC pairs with NOCP?  Basically start over with the new device?   Probably same for the primary.   

    Is there a procedure documented for migrating primary and secondary to new boxes using DSCLI?  Not an overview but a procedure? The Copy Services manuals stop short of actually saying how to do (most of) the process.  It doesn't describe what one would actually see. 


    ------------------------------
    John Traylor
    ------------------------------


  • 2.  RE: DS8000 migration with DSCLI

    Posted Mon December 12, 2022 09:31 AM
    I don't think that you will find these details necessarily documented anymore, as we strongly encourage management through CSM.  But as you described the situation for replacing the Secondary, yes you can do as you described.  Primary->Secondary(GM)->Secondary'(GC): shutdown all systems using Primary volumes, suspend GM session (with consistency), verify all OOS tracks are transferred to Secondary', remove GC relationship from Secondary to Secondary', remove GC relationship from Primary to Secondary, create GC relationship Primary to Secondary' with NOCOPY, create journal FC relationships on Secondary', start GM process on Primary, IPL.

    Replacing the Primary could be done using a multi-target relationship, with a new second PPRC relationship from Primary volumes to Primary' volumes running in GC mode.  As above, when ready for cutover, shutdown all systems using Primary volumes, suspend GM session (with consistency), remove GC relationships from Primary to Secondary, verify all OOS tracks are transferred from Primary to Primary', remove GC relationships from Primary to Primary', create GC relationship Primary' to Secondary with NOCOPY, define sessions and populate the GM sessions on Primary', start GM process on Primary', IPL.

    ------------------------------
    Craig Gordon
    ------------------------------



  • 3.  RE: DS8000 migration with DSCLI

    Posted Mon December 12, 2022 11:07 AM
    Thanks Craig.  I appreciate the confirmation.  With the changes to the function and licenses, just wanted to confirm it.

    I think CSM would be nice to use.  There are certainly things it can do that dscli cannot.  However, it has too many challenges for me and I'm still old school enough to need to know how it's working and what it's doing.  I would rather see dscli evolved to include object lists and a few other niceties.  It would be nice is CSM were just included in the package rather than being a separate license.  And it would be nice if there was access to a (virtual?) system where guys who only do this every few years can play with it a bit first.  

    Thanks again.  

    Cheers,

    ------------------------------
    John Traylor
    ------------------------------



  • 4.  RE: DS8000 migration with DSCLI

    Posted Mon December 12, 2022 12:02 PM
    CSM comes pre-installed on the DS8000 HMC.  With that comes the ability to create both FC sessions as well as now Migration sessions (GC only sessions).  So, you do not have to get a full CSM license to run FC or GC relationships through CSM.  With that Migration session is a new solution as well for Migrating Secondary boxes which should make the process MUCH easier.  Again, without having to purchase a full CSM license.  See the following blog for more details on that solution.  https://community.ibm.com/community/user/storage/blogs/randy-blea1/2022/03/03/whats-new-in-ibm-copy-services-manager-6320?CommunityKey=c6644533-459d-4dc4-af5e-9c9f04f4f4c7

    ------------------------------
    Randy Blea
    IBM
    (512) 286-5376
    ------------------------------



  • 5.  RE: DS8000 migration with DSCLI

    Posted Fri December 16, 2022 02:45 PM
    Thanks Randy.  It looks quite nice.  Until I can get a system I/we can play with, I'm unlikely to change.  The expectation is folks who don't or rarely see this rather messy tool will be able to follow a script and successfully not blow up a production DR configuration.  Having just watched a (storage?) consultant do that, not once, not twice, but three times, using CSM, I'm less convinced. That for someone not familiar with CSM will not stub a toe.  I could follow what he did and tell him when he broke it.  But it was not obvious until I could play with DSCLI and confirm what he did.

    I'll say again, if I had a virtual environment to go through it with, checking status, seeing failures and messages and such, ya, I think CSM would be quite nice.  There are a lot of benefits to using a tool like this.  I hate writing scripts to manage this stuff.  I partially worked out a parallel GM to try things with but no CSM.

    Unfortunately, our company didn't pay for the CSM license, which would give us ongoing familiarity with the interface.  Even then, I would want the senior admins to be able to verify things with DSCLI commands.  It's the same way we expect our system automation to be run; the senior techs gotta know the real commands happening under the covers.  Trust but verify.

    ------------------------------
    John Traylor
    ------------------------------