Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
If you are doing Point in Time backups for your DR and you want to get the backups of those copies quickly done, then the V2X2 is your baby. SnapShot is more friendly in this area than Flashcopy. SnapShot saves pointers to the current data whereas FlashCopy copies it from one location to another under the covers. You have to wait for each block to be dumped to get to the Flashed location before it can be dumped. Your last statement is not true. When dumping from the Flashed copy, when the dump accesses a track which has not been copied, the IBM CU accesses the track from the source disk. No special penalty to be paid. But it is true that Snapshot is fast. Because of the log structured organization of the STK disks, Snapshot is just a matter of copying pointers. No data movement at all. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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
Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
If you are doing Point in Time backups for your DR and you want to get the backups of those copies quickly done, then the V2X2 is your baby. SnapShot is more friendly in this area than Flashcopy. SnapShot saves pointers to the current data whereas FlashCopy copies it from one location to another under the covers. You have to wait for each block to be dumped to get to the Flashed location before it can be dumped. At a previous shop where I worked, we had all Storage Technology DASD and loved it. We also did point in Snaps and then backed them up for our DR. One area to consider is if you have to go back on your schedule and run the Snap (Flash jobs again). With SNAP there is not problem. With Flash you have to stop the current Flash connections and then Flash again. ___ Jim Petersen MVS - Lead Systems Engineer Home Depot Technology Center 1300 Park Center Drive, Austin, TX 78753 www.homedepot.com email: [EMAIL PROTECTED] 512-977-2615 direct 512-977-2930 fax 210-859-9887 cell This message may contain confidential information. The information contained in this message and any attachments are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any disclosure, copying, distribution or other use of the contents of this message is strictly prohibited. If you have received this email in error, please notify the sender immediately by email and delete all copies of this message -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Pinnacle Sent: Thursday, January 04, 2007 5:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: V2X2 vs. Shark (SnapShot v. FlashCopy) My current client has a V2X2 and is thinking about replacing it with a Shark. SnapShot is used to snap 600 volumes in about 5-10 minutes. The physical tape backups are done from the snaps and take about 8 hours. This DR process is fully tested and works great. My main concern if we replace the V2X2 with the Shark is the DR process. Has FlashCopy improved to the point that you can make a point in time backup and physically move it to tape later? And can you FlashCopy the entire box in a few minutes? If not, the DR process for this client is going to get much more complicated. PPRC or XRC are not options due to cost. Let me know your thoughts. Regards, Tom Conley -- 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
Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
Again, just to correct: BCV is not TF/MIRROR, however it's related. I'm not sure what you mean, Radoslaw. From the EMC page on the Timefinder Family *TimeFinder/Mirror *Highly available, ultra-performance mirror BCV option for the most demanding environments. Sounds clear to me -- Bruce Black Senior Software Developer Innovation Data Processing -- 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
Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
Bruce Black wrote: Again, just to correct: BCV is not TF/MIRROR, however it's related. I'm not sure what you mean, Radoslaw. From the EMC page on the Timefinder Family *TimeFinder/Mirror *Highly available, ultra-performance mirror BCV option for the most demanding environments. Sounds clear to me It's a matter of names, irrelevant detail in fact. BCV stands for Business Continuance Volume - special kind of volume available to host. TF/Mirror is copy technique. This technique exploits the BCV volumes. It's (more or less) like PPRC and Secondary volume. The names are related, but they're not synonyms. Regards -- Radoslaw Skorupka Lodz, Poland -- 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
Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
Bruce Black wrote: My current client has a V2X2 and is thinking about replacing it with a Shark. SnapShot is used to snap 600 volumes in about 5-10 minutes. The physical tape backups are done from the snaps and take about 8 hours. This DR process is fully tested and works great. My main concern if we replace the V2X2 with the Shark is the DR process. Has FlashCopy improved to the point that you can make a point in time backup and physically move it to tape later? And can you FlashCopy the entire box in a few minutes? If not, the DR process for this client is going to get much more complicated. PPRC or XRC are not options due to cost. Let me know your thoughts. Tom, we have a lot of experience with all the various vendor's instant replication functions, since we support them all in our FDR INSTANT backup product. In our experience, the elapsed time to do the SNAPSHOTs and the time to establish the FLASHCOPYs is similar. In both cases it takes only a few seconds per volume (your milage may vary gr). The big difference is the architecture: The STK disks use a virtual architecture, so that the SNAPSHOT is just a matter of copying pointers in a table. The snapped copy takes up no more space on the back-end disks, except for tracks that are updated. The virtual disk data is compressed, so it takes up less back-end room than the actual data would require. The IBM and HDS disks copy the data in the background when a FLASHCOPY is done. The ESTABLISH may be quick but the background copy may take a while, especially if you FLASH many volumes. The FLASHCOPY architecture makes the flashed copy look like the original disk immediately so you don't need to wait for the copy to complete, however, your performance may suffer if you try to do the DUMP before the background copy is complete. EMC SNAP actually supports both options. TIMEFINDER/CLONE does SNAP to real volumes, similar to the IBM/HDS Flashcopy. TIMEFINDER/SNAP does SNAP to virtual volumes. These are not really like the STK virtual volumes, but they do only copy tracks which are updated on the original disks. In our experience, TIMEFINDER/SNAP can be slow, but TIMEFINDER/CLONE is better. Just to complement: there's also TIMEFINDER/MIRROR. It is the best from performance point of view. It works like internal PPRC, so the pair have to be established in advance, and when synchronized can be splitted. It takes approx. 0 seconds to get copy of your volumes. Your can then reuse the pairs, the next synchronization process will take significantly less time since bitmap of changed tracks is maintained on both ends. Last but not least: consistency group are available for split. AFAIK consistency groups for FlashCopy are constrained to single (and whole) LSS. -- Radoslaw Skorupka Lodz, Poland -- 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
Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
Bruce, that would be true but Sam used the FCNOCOPY option. Using this option in DSS, only the T0 (time 0) tracks that were updated on the source volume are copied to the target. This assumes FLASHCOPY V2 is used. Once the target volume is dumped and the FC withdraw is done, the data on the target is basically 'junk'. True, althought I believe the NOCOPY was available in FC V1 as well. FDRINSTANT uses NOCOPY for backups by default. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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
Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
Just to complement: there's also TIMEFINDER/MIRROR. True, also known as BCVs (Business Continuance Volumes). This was EMC's original point-in-time backup function. EMC does market it as the :high-performance option. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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
Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
Bruce Black wrote: Just to complement: there's also TIMEFINDER/MIRROR. True, also known as BCVs (Business Continuance Volumes). This was EMC's original point-in-time backup function. EMC does market it as the :high-performance option. Again, just to correct: BCV is not TF/MIRROR, however it's related. The MIRROR is done from STD (standard) device to BCV device. Type of devices is defined by EMC and is recorded in BIN file. There are also other types of devices, it. SAVE device (for SNAPshots). Regards -- Radoslaw Skorupka Lodz, Poland -- 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
Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
Timefinder/Mirror is the software that is required to control the Business Continuance Volumes that are defined in the BIN file of the Symmetrix. This has been discussed at a high level in previous posts, however, it is probably worth stating here that all RAID configuration specifications for the pair of volumes (Standard and BCV) is controlled within the Symmetrix device itself. However, a change to the condition of the pair (i.e. mirror Established or mirror Split using EMC terminology) is controlled by TF/Mirror from the host through commands to the Symmetrix. Inside the Symmetrix, there is a requirement for enough storage to be allocated to support a complete copy of both volumes. Both volumes must be defined as the same size. From my point of view, the most valuable feature of this arrangement is the ability within the Symmetrix to perform what EMC calls a Consistent split of the mirror across any number of volumes. The Split of the mirror between all volumes is I/O consistent at a single instant in time. This is especially good for database subsystems that have related data across a large number of volumes. The user can break off a copy of a subsystem assuming that all related datasets are contained upon a select set of identifiable volumes that exist in this mirrored relationship -- Standard to BCV. The resulting volumes that contain the subsystem appear as though the subsystem was simply brought down by something as simple as a power failure and the subsystem is perfectly capable of dealing with restart after a power failure. Tom Moulder -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Saturday, January 06, 2007 8:46 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: V2X2 vs. Shark (SnapShot v. FlashCopy) Bruce Black wrote: Just to complement: there's also TIMEFINDER/MIRROR. True, also known as BCVs (Business Continuance Volumes). This was EMC's original point-in-time backup function. EMC does market it as the :high-performance option. Again, just to correct: BCV is not TF/MIRROR, however it's related. The MIRROR is done from STD (standard) device to BCV device. Type of devices is defined by EMC and is recorded in BIN file. There are also other types of devices, it. SAVE device (for SNAPshots). Regards -- Radoslaw Skorupka Lodz, Poland -- 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 -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.410 / Virus Database: 268.16.6/617 - Release Date: 1/5/2007 -- 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
Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
Pinnacle wrote: My current client has a V2X2 and is thinking about replacing it with a Shark. SnapShot is used to snap 600 volumes in about 5-10 minutes. The physical tape backups are done from the snaps and take about 8 hours. This DR process is fully tested and works great. My main concern if we replace the V2X2 with the Shark is the DR process. Has FlashCopy improved to the point that you can make a point in time backup and physically move it to tape later? And can you FlashCopy the entire box in a few minutes? If not, the DR process for this client is going to get much more complicated. It is feasible, however FlashCopy is worse than Snapshot. It takes more real disk space, it is slows down the dasd box. PPRC or XRC are not options due to cost. Let me know your thoughts. PPRC need not to be expensive. Obviously it requires two dasd boxes and link, but gives you much better RTO and RPO. -- Radoslaw Skorupka Lodz, Poland -- 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
Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
Hi Tom, Yes it is possible to use Flashcopy to establish Flashcopy pairs for a large number of volumes at approximately the same time. We do this in conjunction with a daily syncpoint where activity is suspended in DB2 to support DRP. PAGE 0001 5695-DF175 DFSMSDSS V1R07.0 DATA SET SERVICES 2006.359 00:30 ADR004I (SCH)-PRIME(01), USER ABEND 0001 WILL BE ISSUED ON OCCURRENCE 0001 OF MESSAGE ADR306 PARALLEL ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'PARALLEL' COPY FULL INDDNAME(SOURCE1) OUTDDNAME(TARGET1) DUMPCONDITIONING - PURGE FCNOCOPY ADMINISTRATOR ALLDATA(*) ALLEXCP ADR101I (R/I)-RI01 (01), TASKID 002 HAS BEEN ASSIGNED TO COMMAND 'COPY ' COPY FULL INDDNAME(SOURCE2) OUTDDNAME(TARGET2) DUMPCONDITIONING - PURGE FCNOCOPY ADMINISTRATOR ALLDATA(*) ALLEXCP ADR101I (R/I)-RI01 (01), TASKID 003 HAS BEEN ASSIGNED TO COMMAND 'COPY ' COPY FULL INDDNAME(SOURCE3) OUTDDNAME(TARGET3) DUMPCONDITIONING - PURGE FCNOCOPY ADMINISTRATOR ALLDATA(*) ALLEXCP ADR101I (R/I)-RI01 (01), TASKID 004 HAS BEEN ASSIGNED TO COMMAND 'COPY ' COPY FULL INDDNAME(SOURCE4) OUTDDNAME(TARGET4) DUMPCONDITIONING - PURGE FCNOCOPY ADMINISTRATOR ALLDATA(*) ALLEXCP ADR101I (R/I)-RI01 (01), TASKID 005 HAS BEEN ASSIGNED TO COMMAND 'COPY ' COPY FULL INDDNAME(SOURCE5) OUTDDNAME(TARGET5) DUMPCONDITIONING - PURGE FCNOCOPY ADMINISTRATOR ALLDATA(*) ALLEXCP To minimize the time you can use multiple jobs, multiple steps in each job (we do 20 volumes in each step), and use the PARALLEL option in DFDSS. You can Flashcopy hundreds or thousands of volumes quickly. A typical Flashcopy job here does 100 volumes in 5 steps in 30 to 50 seconds total. Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Do not seek to follow in the footsteps of the men of old; Seek what they sought. Basho -Original Message- What you describe is exactly what I did for a client in Columbus OH. They had a Shark for their mainframe. We flashed as soon as the batch cycle ended and then did the full volume copies to tape (2 copies) (one for on site and one for offsite). As I recall, Backups of the flash copies started between 5a-6a and finished by 9AM. 3390-3s and 3490 with oreos. I've forgotten how many 3490 units and how many DASD units. Oh yeah, and D/R tests worked the first time, every time. Steve, Over what period of time were the volumes FlashCopy'd? My understanding is that DFDSS front-ends the FlashCopy function, so you only get the FlashCopy just before DFDSS can do the physical backup to tape. Can you batch all the FlashCopy's, then copy them to tape later? It's very important to keep the time window when the volumes are actually copied as small as possible. Regards, Tom Conley This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- 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
Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Pinnacle Sent: Thursday, January 04, 2007 10:56 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: V2X2 vs. Shark (SnapShot v. FlashCopy) SNIP Steve, Over what period of time were the volumes FlashCopy'd? My understanding is that DFDSS front-ends the FlashCopy function, so you only get the FlashCopy just before DFDSS can do the physical backup to tape. Can you batch all the FlashCopy's, then copy them to tape later? It's very important to keep the time window when the volumes are actually copied as small as possible. SNIP It has been about 4 years since I was involved with that process. As I recall, from the time the flashcopy jobs started to the time they were all completed was about 10 minutes (we did not flash all the volumes at once, automation submitted the flash jobs so many seconds/minutes apart). Batch jobs were complete at that point (except for incremental backups). As soon as the flashcopy jobs completed, on-lines (CICS) could become active (the files were closed/disabled in CICS terms) and TSO max users was changed from 0. The jobs were then started to backup the flashed volumes. Later, Steve Thompson -- 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
Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
What is a V2X2? V2X2 is StorageTek (now Sun-Storagetek) disk array. General reference name is SVA (Shared Virtual Array) and the various models over the years have been: IceBerg 9393 9500 V960 V2X V2X2 V2X4 (and V2X4f for FICON attached) We've gone through every model except the V960 at some point over the last seven years. I think STK calls it: Log Structured Array. To me, its description sounded like 'virtual DASD'. I believe they (the WinTel world folks) call it thin provisioning these days. Works great. I have only 2.8TB of physical raw disk in my V2X4f, yet I present 23.1 TB of usable space. Split three ways, I've got 7.7 TB presented to my production LPAR, another 7.7 TB for BCP snapshot copies, and another 7.7TB that is snapshot copied daily and used as a sandbox LPAR. If I was to go and buy disk from some other vendors and duplicate the functionality I have today, I would have to be asking for that 23.1 TB of actual physical disk. It's very important to keep the time window when the volumes are actually copied as small as possible. I snap 926 volumes (almost all 3390-9) in about 1.4 minutes. We dynamically create the snap JCL each morning right before our syncpoint with a rexx routine wrapped around a dcollect report. This way name and allocation changes are automatically picked up (one less possible human error potential). With the automated IMS/DB2/TSO/etc down and up processes, the whole syncpoint runs about 2.5 minutes. PPRC or XRC are not options due to cost PPRC need not to be expensive. Obviously it requires two dasd boxes and link, but gives you much better RTO and RPO. We just replaced our tape based backups (which were taking about 3.5-4.5 hours with 9840's, HSDM, and ExHPDM) with a PPRC solution. HUGE reduction in RTO as the 1-2 days it was going to take to ship the tapes to the hot site was simply eliminated. The 4-5 hour restore from tape time was also eliminated as the data is sitting on another V2X4f at the hotsite ready to go. Last DR test we were IPL'ed in under an hour after arriving at the local recovery center. The RPO only lost a few hours (the difference between the time it took to create the tapes verses push the data across the PPRC link) and is still about 24 hours since we only take one syncpoint a day (after batch), but we are looking at adding another in the pre-batch lull time. We'll probably take a hard look (I'm hoping) at a GDPS solution as well since it would be the next logical step.. but I fear the costs may simply be too high for management to bear - even with the promise of zero down time. Most expensive ongoing cost of the PPRC solution was the link cost. But we manage to do it with a tiny DS3 by snapping the BCP sets throughout the day and sending changes across the link. That way, when it comes to syncpoint time, the amount of change data is very small and the DR set at the remote site is set and stable and ready for recovery just 10-15 minutes after the snaps (keeping the RPO close to that 24 hours) Jeffrey Deaver, Engineer Systems Engineering [EMAIL PROTECTED] 651-665-4231(v) 651-610-7670(p) -- 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
Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
On Fri, 5 Jan 2007 09:15:31 -0500, Knutson, Sam [EMAIL PROTECTED] wrote: Hi Tom, Yes it is possible to use Flashcopy to establish Flashcopy pairs for a large number of volumes at approximately the same time. We do this in conjunction with a daily syncpoint where activity is suspended in DB2 to support DRP. PAGE 0001 5695-DF175 DFSMSDSS V1R07.0 DATA SET SERVICES 2006.359 00:30 ADR004I (SCH)-PRIME(01), USER ABEND 0001 WILL BE ISSUED ON OCCURRENCE 0001 OF MESSAGE ADR306 PARALLEL ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'PARALLEL' COPY FULL INDDNAME(SOURCE1) OUTDDNAME(TARGET1) DUMPCONDITIONING - PURGE FCNOCOPY ADMINISTRATOR ALLDATA(*) ALLEXCP ADR101I (R/I)-RI01 (01), TASKID 002 HAS BEEN ASSIGNED TO COMMAND 'COPY ' COPY FULL INDDNAME(SOURCE2) OUTDDNAME(TARGET2) DUMPCONDITIONING - PURGE FCNOCOPY ADMINISTRATOR ALLDATA(*) ALLEXCP ADR101I (R/I)-RI01 (01), TASKID 003 HAS BEEN ASSIGNED TO COMMAND 'COPY ' COPY FULL INDDNAME(SOURCE3) OUTDDNAME(TARGET3) DUMPCONDITIONING - PURGE FCNOCOPY ADMINISTRATOR ALLDATA(*) ALLEXCP snip To minimize the time you can use multiple jobs, multiple steps in each job (we do 20 volumes in each step), and use the PARALLEL option in DFDSS. You can Flashcopy hundreds or thousands of volumes quickly. A typical Flashcopy job here does 100 volumes in 5 steps in 30 to 50 seconds total. Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Do not seek to follow in the footsteps of the men of old; Seek what they sought. Basho Sam, Thanks for this. I did a little RTFM and based on what you have above, I need to then run a DFDSS DUMP with FCWITDRAW on the target, correct? If so, then the process is very close to the SnapShot process my client is using. Tom -- 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
Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
My current client has a V2X2 and is thinking about replacing it with a Shark. SnapShot is used to snap 600 volumes in about 5-10 minutes. The physical tape backups are done from the snaps and take about 8 hours. This DR process is fully tested and works great. My main concern if we replace the V2X2 with the Shark is the DR process. Has FlashCopy improved to the point that you can make a point in time backup and physically move it to tape later? And can you FlashCopy the entire box in a few minutes? If not, the DR process for this client is going to get much more complicated. PPRC or XRC are not options due to cost. Let me know your thoughts. Tom, we have a lot of experience with all the various vendor's instant replication functions, since we support them all in our FDR INSTANT backup product. In our experience, the elapsed time to do the SNAPSHOTs and the time to establish the FLASHCOPYs is similar. In both cases it takes only a few seconds per volume (your milage may vary gr). The big difference is the architecture: The STK disks use a virtual architecture, so that the SNAPSHOT is just a matter of copying pointers in a table. The snapped copy takes up no more space on the back-end disks, except for tracks that are updated. The virtual disk data is compressed, so it takes up less back-end room than the actual data would require. The IBM and HDS disks copy the data in the background when a FLASHCOPY is done. The ESTABLISH may be quick but the background copy may take a while, especially if you FLASH many volumes. The FLASHCOPY architecture makes the flashed copy look like the original disk immediately so you don't need to wait for the copy to complete, however, your performance may suffer if you try to do the DUMP before the background copy is complete. EMC SNAP actually supports both options. TIMEFINDER/CLONE does SNAP to real volumes, similar to the IBM/HDS Flashcopy. TIMEFINDER/SNAP does SNAP to virtual volumes. These are not really like the STK virtual volumes, but they do only copy tracks which are updated on the original disks. In our experience, TIMEFINDER/SNAP can be slow, but TIMEFINDER/CLONE is better. | Has FlashCopy improved to the point that you can make a point in time backup and physically move it to tape later? FLASHCOPY has always supported this. FDR INSTANT has done this since IBM Flashcopy first came out. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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
Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
The IBM and HDS disks copy the data in the background when a FLASHCOPY is done. The ESTABLISH may be quick but the background copy may take a while, especially if you FLASH many volumes. The FLASHCOPY architecture makes the flashed copy look like the original disk immediately so you don't need to wait for the copy to complete, however, your performance may suffer if you try to do the DUMP before the background copy is complete. Bruce, that would be true but Sam used the FCNOCOPY option. Using this option in DSS, only the T0 (time 0) tracks that were updated on the source volume are copied to the target. This assumes FLASHCOPY V2 is used. Once the target volume is dumped and the FC withdraw is done, the data on the target is basically 'junk'. The default (no FCNOCOPY keyword specified) will perform the background copy and the data can be used as is; i.e. dumped to tape, used in a testing environment, updated, deleted, etc. Bruce Estey -- 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
V2X2 vs. Shark (SnapShot v. FlashCopy)
My current client has a V2X2 and is thinking about replacing it with a Shark. SnapShot is used to snap 600 volumes in about 5-10 minutes. The physical tape backups are done from the snaps and take about 8 hours. This DR process is fully tested and works great. My main concern if we replace the V2X2 with the Shark is the DR process. Has FlashCopy improved to the point that you can make a point in time backup and physically move it to tape later? And can you FlashCopy the entire box in a few minutes? If not, the DR process for this client is going to get much more complicated. PPRC or XRC are not options due to cost. Let me know your thoughts. Regards, Tom Conley -- 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
Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Pinnacle Sent: Thursday, January 04, 2007 5:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: V2X2 vs. Shark (SnapShot v. FlashCopy) My current client has a V2X2 and is thinking about replacing it with a Shark. SnapShot is used to snap 600 volumes in about 5-10 minutes. The physical tape backups are done from the snaps and take about 8 hours. This DR process is fully tested and works great. My main concern if we replace the V2X2 with the Shark is the DR process. Has FlashCopy improved to the point that you can make a point in time backup and physically move it to tape later? And can you FlashCopy the entire box in a few minutes? If not, the DR process for this client is going to get much more complicated. PPRC or XRC are not options due to cost. Let me know your thoughts. snip What you describe is exactly what I did for a client in Columbus OH. They had a Shark for their mainframe. We flashed as soon as the batch cycle ended and then did the full volume copies to tape (2 copies) (one for on site and one for offsite). As I recall, Backups of the flash copies started between 5a-6a and finished by 9AM. 3390-3s and 3490 with oreos. I've forgotten how many 3490 units and how many DASD units. Oh yeah, and D/R tests worked the first time, every time. Later, Steve Thompson -- 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
Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
V2X2 I've been involved in storage management since 1981 (way pre-SMS). What is a V2X2? When in doubt. PANIC!! -- 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
Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
According to simple google search on v2x2 disk it is a StorageTek (ie Sun) Disk Array. Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Thursday, January 04, 2007 6:02 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: V2X2 vs. Shark (SnapShot v. FlashCopy) V2X2 I've been involved in storage management since 1981 (way pre-SMS). What is a V2X2? When in doubt. PANIC!! -- 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
Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
Hi Tom, We have used the SnapShot process on a STK V2X ( eariler model ) and we have used FlashCopy on a HDS9980V. We have not experienced any subsystem performance issues with either subsystem. The issue we did encounter was trying to explain to management why we needed 'more DASD' on the HDS9980V vs. the STK V2X. As you may know, the answer is the way the STK V2X 'stores' data, especially as a result of the SnapShot process versus the way IBM, EMC HDS 'stores' data. I think STK calls it: Log Structured Array. To me, its description sounded like 'virtual DASD'. Maybe 'virtual' anything wasn't cool 10 years ago when STK designed the Iceberg box. Glenn Miller --- This message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorised use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. ABN AMRO Bank N.V, which has its seat at Amsterdam, the Netherlands, and is registered in the Commercial Register under number 33002587, including its group companies, shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. ABN AMRO Bank N.V. (or its group companies) does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. --- -- 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
Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
Okay, my curiosity is peeked. We have DMX box (EMC) so for our process for production packs/DR packs we need a total of 3 volumes. So I have my prod pack, my Replicate pack and a SNAP (Using FDR Instance). How does IBM or HDS differ from that. Which uses less dasd and how is that done? I have just been assigned storage management duties and would like to understand different storage configurations and how each compares to the other. Thanks Lizette --- Snip We have used the SnapShot process on a STK V2X ( eariler model ) and we have used FlashCopy on a HDS9980V. We have not experienced any subsystem performance issues with either subsystem. The issue we did encounter was trying to explain to management why we needed 'more DASD' on the HDS9980V vs. the STK V2X. As you may know, the answer is the way the STK V2X 'stores' data, especially as a result of the SnapShot process versus the way IBM, EMC HDS 'stores' data. I think STK calls it: Log Structured Array. To me, its description sounded like 'virtual DASD'. Maybe 'virtual' anything wasn't cool 10 years ago when STK designed the Iceberg box. --- UnSnip -- 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
Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
Hi Lizette, My comment about the STK Log Structured Array ( LSA ) mechanism was a comparison to all the other mainframe DASD vendors ( IBM, HDS EMC ). The STK LSA is a method of storing the data internally within the DASD subsystem. As far as I know, no other mainframe DASD vendor used ( the IBM RVA doesn't count, it was a 'newer' STK ICEBERG with an IBM label on the cover of the machine ) the LSA concept to internally store the data. Glenn Miller --- This message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorised use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. ABN AMRO Bank N.V, which has its seat at Amsterdam, the Netherlands, and is registered in the Commercial Register under number 33002587, including its group companies, shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. ABN AMRO Bank N.V. (or its group companies) does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. --- -- 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
Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
- Original Message - From: Anne Lynn Wheeler [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main,alt.folklore.comuters Sent: Thursday, January 04, 2007 9:56 PM Subject: Re: V2X2 vs. Shark (SnapShot v. FlashCopy) [EMAIL PROTECTED] writes: My comment about the STK Log Structured Array ( LSA ) mechanism was a comparison to all the other mainframe DASD vendors ( IBM, HDS EMC ). The STK LSA is a method of storing the data internally within the DASD subsystem. As far as I know, no other mainframe DASD vendor used ( the IBM RVA doesn't count, it was a 'newer' STK ICEBERG with an IBM label on the cover of the machine ) the LSA concept to internally store the data. DFSMShsm Fast Replication Technical Guide http://www.redbooks.ibm.com/redbooks/pdfs/sg247069.pdf from above: The source volumes within a storage group can span logical subsystems, physical subsystems, or both. With ESS FlashCopy Version 2, the source volumes can be in different Logical Subsystems within the same Storage Subsystem. Because the ESS is not a Log Structured Array (LSA) device, but rather uses Home Area method, the use of multiple backup versions means that physical space will be consumed by this approach. On the RVA, in contrast, its LSA technology means that the backup versions only take a small fraction of extra physical space. Anne Lynn, Thank you for the above link. As I suspected, my client gots to git lots more DASD to support FlashCopy. Regards, Tom Conley -- 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
Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
- Original Message - From: Thompson, Steve , SCI TW [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Thursday, January 04, 2007 6:39 PM Subject: RE: V2X2 vs. Shark (SnapShot v. FlashCopy) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Pinnacle Sent: Thursday, January 04, 2007 5:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: V2X2 vs. Shark (SnapShot v. FlashCopy) My current client has a V2X2 and is thinking about replacing it with a Shark. SnapShot is used to snap 600 volumes in about 5-10 minutes. The physical tape backups are done from the snaps and take about 8 hours. This DR process is fully tested and works great. My main concern if we replace the V2X2 with the Shark is the DR process. Has FlashCopy improved to the point that you can make a point in time backup and physically move it to tape later? And can you FlashCopy the entire box in a few minutes? If not, the DR process for this client is going to get much more complicated. PPRC or XRC are not options due to cost. Let me know your thoughts. snip What you describe is exactly what I did for a client in Columbus OH. They had a Shark for their mainframe. We flashed as soon as the batch cycle ended and then did the full volume copies to tape (2 copies) (one for on site and one for offsite). As I recall, Backups of the flash copies started between 5a-6a and finished by 9AM. 3390-3s and 3490 with oreos. I've forgotten how many 3490 units and how many DASD units. Oh yeah, and D/R tests worked the first time, every time. Steve, Over what period of time were the volumes FlashCopy'd? My understanding is that DFDSS front-ends the FlashCopy function, so you only get the FlashCopy just before DFDSS can do the physical backup to tape. Can you batch all the FlashCopy's, then copy them to tape later? It's very important to keep the time window when the volumes are actually copied as small as possible. Regards, Tom Conley -- 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
