Lizette, With Tiered Storage on internal disk available on all three vendors, and on midrange storage with HDS, perhaps it is time to re-examine the need for ML1 with the big 3, and ML2 with HDS.
The objective of ML1 is to compress recently inactive data sets and use less GB on media that is the same $/GB as Primary storage. The objective of ML2 is to move long term dormant data sets to a cheaper media. Both processes require data movement and transformation to archive and recall the data sets which introduces overhead and recall latency. Don't shoot me for using the HDS example - it's who I work for and what I know best. A three tier strategy using HDD or SSD for Tier 1, Nearline SAS for ML2, and virtualized Brand-X midrange storage for Tier 3 presents a new paradigm for archiving inactive and dormant data sets, including back-ups, that I believe over time can displace DFSMShsm altogether. It is the cost per GB of the media that provides the savings, divorced from double handling and transformation of the data. Data sets are written to the first tier of a tiered storage pool much in the same way as they are written to Primary storage with DFSMShsm - there are no real changes here. What does change is that from this point on the storage is managing pages, not data sets, and as pages go inactive they will move to cheaper NL-SAS installed in the same controller, and finally onto virtualized Brand-X midrange storage - perhaps a repurposed IBM-XIV from and Open application that the bean counters want kept for a another year, or something you got cheap with a bunch of squatty boxes from Oracle. What I find important is there is no data transformation or recall latency: it is all transparent to the application. You have to read 12 months of General Ledger files or SMF data sets? The application simply reads them directly from whatever tier disk the pages happen to be on. You're not waiting 24 hours for data sets scattered all over myriad ML2 tapes to be recalled, you don't have to find redundant Primary space to store the recalled data sets, and there won't be any TMM thrash when they are migrated again by the next space management cycle. That process is transparent to z/OS in the way we thought the STK Iceberg would go. Of course all this dormant data remains replicated with TC and/or HUR while it is being shuffled around the backstore tiers in both sites - you're not moving any DFSMShsm traffic across the replication links. The big saving that I see here is vitalizing the cheapest, acceptable midrange disk for Tier 3. It looks and smells like a 3390 to System z, but it is just commodity midrange disk that you buy at the local midrange disk vendor store. You're no longer locked into the big 3, but you can still use it with TrueCopy, HUR, Shadowimage, FlashCopy, etc through the Enterprise Controller where the backstore is a HP 3PAR storage system. Whatever gives you the best bang for your buck. This probably sounds like a bit of a hard sell, but I drank the cool-aid back in 1994 with Iceberg and I think DFSMShsm is looking rather old and heavy compared to Storage tiering from IBM, EMC and HDS. Ron -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Lizette Koehler Sent: Saturday, August 23, 2014 12:19 PM To: [email protected] Subject: [Bulk] Re: [IBM-MAIN] General question on moving DFHSM work from mix TAPE/DASD to More DASD The driving force is the Mgt team is familiar with NetBackup and Other Open system software that does backup. They do not understand mainframe. I have been unsuccessful in explaining it is MORE THAN BACKUP on the mainframe. And we cannot lose HSM Data unlike NetBackup. So that is the process driving the discussion. I am concerned I cannot anticipate how much spinning disk they would need on the storage array to replace a tape appliance for tape datasets. And HSM is our biggest consumer. Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of TonyIcloud-OPERA > Sent: Saturday, August 23, 2014 9:04 AM > To: [email protected] > Subject: Re: General question on moving DFHSM work from mix TAPE/DASD > to More DASD > > Yes, 1988. We had abundant spinning DASD since that's the only kind > that existed. > It was a small MVS shop that IBM provided ($$) generously. > > Usual questions: > 1. Do you have enough disk? No guessing allowed. > 2. Is the tape mount scenario driving this plan? > 2. Will it complicate your DR? > 3. Will it complicate your routine non-DR backups? > > I know you asked that below but every shop has its own methods of > backup for DR > and non DR. Without intimate knowledge of your current backup > methods.......speculation. > > All in all I think it's an excellent idea, subject to niggling details > of course. > > > > On Fri, 22 Aug 2014 22:42:38 -0500, Lizette Koehler <[email protected]> > wrote: > > > We are z/OS V1.12 > > > > We are considering changing from a mix of Tape and Disk for HSM > > functions. > > > > So ML2 would go away or be very reduced > > ML1 would be expanded > > BACKUP and ABARS would be directed to DASD. > > > > Has anyone done this? > > > > If so, what were some of the experiences? Did you find the increase > > in dasd requirements were exponential? Or were they an easy slope > > (that is not any quick growth) Did you find any issues with > > constantly adding dasd? Or could you stabilize the HSM needs. > > Did it provide better support for Business Recovery or Disaster Recovery? > > Any performance issues? > > > > Thanks for any input > > > > Lizette > > > > -------------------------------------------------------------------- > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO > > IBM-MAIN > > > -- > Using Opera's mail client: http://www.opera.com/mail/ > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to > [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
