On Sat, 31 Mar 2007 21:28:20 -0400, Harold Zbiegien <[EMAIL PROTECTED]> wrote:
>We are planning to implement a 100% virtual tape solution (VSM from STK) >with backend T10000 drives in a STK silo. We will have NO real tape drives >attached to our z/OS 1.7 system. (I wasn't actively involved in the choice, >but now I have to implement and make the solution work). > >I have several concerns and I was hoping some of you could provide some >practical expierience. >1) The tape drives are 500gig capacity, uncompressed and I'm concerned about >putting hundreds of virtual tapes on a single cartridge. I'm thinking of >perhaps making duplex copies of everything. (of course that wasn't >considered in the vendor proposal) Do it. Originally we duplexed 100% just because through different consolidations and lack of the application groups following standards, there was no way to guarantee we would have what we *really* needed in a disaster if we picked and chose what we duplexed. We've had enough media issues in the past 5 years that I know we would have had some major issues had we not duplexed everything. And this was with 9840B when we started - which is much lower capacity. We now use 9840C and duplex to 9940B (which goes off site). >2) We seem to have bought such a very few cartridges. I have to move, I >think, 1 or 2 tapes offsite for DR purposes, keep some backups on site as >the VSM disk buffer is not that large and I have to move some data offsite >for normal archive purposes. I'm trying to figure out how to do a real >analysis to double check the vendor recomendations. I don't understand the part about keeping VSM data off site for normal archive purposes. To me, that is the same as DR. Anyway... I don't have a good answer for this. They have tools for the analysis. Just get what they tell you in writing with guarantees. When we first migrated from VTS to VSM we did run short on virtual tapes because we didn't realize that VTS virtual tapes were twice the capacity (3490E) as VSM and no one warned us. That has since changed in later releases of VTCS. We currently use 800MB VTVs. This didn't cost us anything since we just had to expand the range in our tape management software and in VTCS. >3) I've got all kinds of retention criteria today from several days to >forever and we currently move tapes between 2 off site vaults and back onsite >for varying periods of time. With the new system if I move a virtual tape >off site it is offsite for as long as everything else on the cartridge it >was written to, I can't bring one volume back onsite after a couple of days. >I've got to come up with some type of rotation. I'm almost thinking of >keeping an additional copy onsite of everything that goes offsite. > That would have been impossible for us for the same reasons. There is another option that we use (although it has presented some challenges). You can use ExLM (or home grown rexx reading a report) to pick off site tapes that are fragmented (IOW, some percentage of expired data), mark them "lost", then drain them. This causes recalls from the on site MVCs to write to new off site MVCs. After the new ones get sent off site, you can bring the old ones back. See the VSMVDR software and manuals (although we don't use the software... the concept is the same as what we do). >Disaster Recovery is going to be an issue. Today we use a "floor" system >under VM at the DR site to read 20-30 full volume dumps to disk using DFDSS >to get our base system up then we IPL our system and do the rest of the >recovery functions. Now I'm going to need a similar VSM system with silo on >the DR site's floor system just to do my 20-30 full volume restores. Why does this part change? > But I >can't take my silo software on a tape as I have no tape. I can't take my >VSM manifest on tape as I have no tape on my z/OS system. I guess I'm >going >to have to find some outside service location that I can ftp various things >like this to so that I can retrieve them at DR time. > FTPing a backup of the HSC/VTCS CDS to be used at DR would work. I was considering doing the same thing at one point in order to recover VSM quicker (before tapes were shipped to the DR site). It wasn't because we needed virtual tapes as input quickly, it was because we needed virtual tapes as output quickly (for example, DB2 writes its archive logs to virtual tape). Just as an FYI... we do have a few small monoplex LPARs that run 100% virtual including HSM - which in essence means a recall to do a double recall on ML2. BTW, have you considered using the lower capacity T10000 tapes? At least for the ones that don't go off site? I'm wondering how long it will take for a recall of a VTV from a near full T10000. That was why we kept our primary copies on 9840 media and only duplexed to 9940. We also wanted to keep the number of MVCs sent off site down. Unfortunately, that didn't work out they way we had hoped and is still an issue. The number was reduced by 50% perhaps, but the 9940s hold 5 times the amount as 9840C (10 x 9840B). This is because VTCS doesn't try to stack as much data as it can when selecting output MVCs. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group: G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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
