Thanks, Ron. I spent a couple minutes on the HDS web site and somehow missed the fact that the NSC55 supports ESCON. Also, my tongue was firmly in cheek when I suggested the idea of plugging a FICON device into an ESCON cable. :-)
I didn't realize that once the initial copy was done, that subsequent copies would only recopy the changed tracks (even tho it makes perfect sense). My thought behind asking the wall clock involved was just curiosity and wondering what the actual impact was to the box to be doing the data movement in the background. I understand the idea that the copy is immediately available before the physical tracks are copied and was just wondering what kind of impact the background copy would have on the foreground tasks running against the same physical disks. Thanks for the info. Rex Rex, With the NSC55 I would suggest ordering ESCON channels to solve your plug problem - you can have up to 16 ESCON channels :) Shadowimage doesn't up and start copying 200 volumes in one hit. There is a maximum number of Logical Devices (volumes) that are being copied at any one time, and this can change with model and microcode. The copies always queue behind host requests to the disks (cache misses), and any potential impact can be further reduced by reducing the number of tracks used in each copy IO. The impact is really quite low, and after the first copy you will be refreshing the volumes, not copying. This means changed data only. The wall clock time depends on how much other activity is taking place, but as we discussed in another thread you don't have to wait for Shadowimage, Flashcopy or Timefinder to move the data - the copies can be used immediately. I don't have times for the NSC55, but I've had an inactive 9960 complete full copies at 6GB/minute - I expect the NSC55 is faster. Depending on your needs you can also use the Flashcopy Compatible add-on to Shadowimage and use FCNOCOPY with DFDSS which causes the copy to operate as a Copy-On-Write, where only changed data is written to the target. BTW something you may like with latest generation software is you can get an IO Consistent Point-in-Time across the snapped volumes without stopping your applications on the Primary LPAR. I don't think the Snapshot you are running supported this. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Pommier, Rex R. > Sent: Tuesday, 7 March 2006 11:38 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: IXFP No Longer Supported > > Ron and Timothy, > > First of all a caveat - I would love to look at either/both the NSC55 > and the DS6800 but unfortunately I don't know how to plug the FICON > into my existing ESCON cables (7060 with only ESCON and -horrors- > parallel channels). (Will be trying to talk mgmt into a new box in > the next week or so) > > That being said, if I were to use shadowimage or IBM's flavor of > "instant" replication where the actual copy of the volumes occurs in > the background, what kind of performance impact does the actual copy > have on the array if for example 200 3390-3 volumes are "snapped"? In > addition to that, what is the typical wall clock time for copying a > full 3390-3 volume in the background? I am sure both software > products use some kind of I/O queuing algorithm to do the copies at a > lower priority than "real" I/Os but they have to have some kind of > impact, don't they? > > Rex > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
