DS8000 Transparent Cloud Tiering

 View Only
  • 1.  Testing communication Between the Hydra and DS8Ks

    Posted Mon February 06, 2023 09:30 AM
    Is there a way to test (beside ping tests) the communication once the IPs have been entered in the Hydra and DS8Ks?

    Nick Pilney

  • 2.  RE: Testing communication Between the Hydra and DS8Ks

    Posted Tue February 07, 2023 08:09 AM
    Not really. Remember that pings to the DS8000 ethernet addresses will not receive responses, firewall blocks all incoming traffic.  But, assuming that the SSR has updated the Hydra with the addresses that are expected to connect (the DS8000 addresses) and your mkcloudserver command completes successfully, this means that the DS8000 has communicated to the Hydra and create a test file there, proving successful comm.


    Craig Gordon

  • 3.  RE: Testing communication Between the Hydra and DS8Ks

    Posted Tue February 07, 2023 03:39 PM
    Agree with what Craig said.  On a second note, I also had discussions with the DS8k to provide a way to do ping/tracroutes for these paths.  There are a few thoughts on several ways to support it that are being tossed around.  I suggest someone opening up an Idea on the IBM site.  Other users/customers can vote on an idea.  Opening an Idea legitimizes the request, especially if it is opened by or on behalf of a customer.  It helps us track who is requesting the item and serves as a record keeping mechanism.  The teams do periodic reviews of the ideas, can ask questions if needed, and will state if they will consider the idea or not.  The website for this is:


    Lourie Goodall

  • 4.  RE: Testing communication Between the Hydra and DS8Ks

    Posted Wed February 08, 2023 05:51 PM

    As craig mentioned, the best way to "test" whether your connection works is to run the mkcloudserver command on the DSCLI once you think you have both DS8k and TS7700 configured.  It will either work or it wont.  If it succeeds, you have good paths between the two boxes.  If it fails, there is some issue...and this is where it becomes difficult to determine as it can be any point in the network where ping/tracerouting will help determine the problem (e.g. packet loss, etc).  

    here is information about mkcloudserver command: mkcloudserver

    Ibm remove preview
    The mkcloudserver command creates a configuration entry for a cloud.
    View this on Ibm >

    If the object store is a TS7700 running FC5283 (Advanced Object Store), you will: 

    • select type "TS7700". 
    • I suggest starting with -nossl (encryption off) to rule out certificate type issues...you can always turn encryption on later
    • -primaryTS7700IPs - you will list TS7700 grid link IP addresses for the first cluster (ds8k supports targeting one or two TS7700 clusters in a grid).  I recommend you start with just targeting one cluster in the grid for a test.  If that succeeds,  you can run rmcloudserver (to remove the cloud server configuration) and then rerun it but this time including the second TS7700 cluster's grid link IP addresses under the -secondaryTS7700IPs.  Running with both -primaryTS7700IPs and -secondaryTS7700IPs will test all paths to both.  
    • Last, you will include the cloud name (this is the DFSMS Cloud Network Connection Construct name that should be set up in the ISMF panel on Z).  

    Please let me know if you are running the older FC5282 DS8000 Object Store feature. Setup-wize it is pretty close to the same but setting up a primary and secondary IP address to the TS7700 handles replication differently and there as some things you should know.  

    If you do experience a problem where mkcloudserver fails it could be a failure anywhere and in any path between the DS8000 and TS7700.  mkcloudserver tests all paths and, if one path is no good it will fail.  The default expectation is that each DS8k CEC TCT port will have 100% connectivity to every TS7700 grid link port.  If the customer data center network is not configured to include 100% pathing both ways between these two systems (it can sometimes be configured this way when only like-subnet IP Address have available paths then we (TS7700) offers VTD_EXEC.369 that will restrict those routing paths that do not lie on the same subnet. You only want to use this EXEC if this is your use-case.  

    Another thing to know is the network configuration does not support Cisco ACI.  ACI must be disabled otherwise it sometimes causes routing failure and will result in packet loss issue and the inability to configure between the boxes.  

    The DFSMS, TS7700 and DS8000 teams created a "cheat sheet" that summarizes some important things to know.  It is just some quick information that may help you but wont contain details like some of the documents and links that can be found in the Library:   https://community.ibm.com/community/user/storage/viewdocument/ibm-z-ds8k-tct-to-ts7700-user-cheat?CommunityKey=389634d3-147e-4db6-99d2-01852bb5a77f  

    Hope this helps

    Lourie Goodall