Hi KB, IBM-MAIN is great. There are shops that are all primary disk. Just make sure that you are aware of all of the considerations before going down that route. (The ones that I'm aware of are still HSM users to take advantage of ML1, class transitions, and backup). A few responses to your follow-on questions...
Hi, Thank you for the detailed response Glenn, IBM-MAIN is truly amazing. > Migrate/Archive > The three purposes of HSM migration are to 1) compress the data so that the > footprint is smaller, 2) move it to a lower cost media so that the TCO is > lower and 3) move the data to an offline media that doesn't consume online > UCBs. When considering bringing all of your data back online, you need to > consider the impact of all three. 1) Assuming 3:1 compaction, you'll need 3x > the online storage. With zEDC, that will vary on both what you can get on the > primary storage and the ML2 storage. 3) For larger shops, the number on > online UCBs is a factor. It's not a factor for smaller shops. ----- 1) Compression - wouldn't it be enough to rely on z15 on-chip compression + the compression/dedupe done by the storage array itself? Sure, it may not be 3:1.. but worth evaluating? If the array itself is doing C+D, then "rehydrating" the data isn't a problem I believe? >> Glenn: z15 compression can be utilized for nonVSAM, not VSAM. >> Compression/Dedup are generally provided by offline storage systems or those >> that emulate them (like virtual tape). Dedupe is generally too slow for >> primary storage. I'm not aware of compression capabilities on primary >> storage. If you are currently deduping your backup copies, then they will >> take even more storage when they are moved to primary disk unless you can >> utilize a backup solution that does software based dedup and targets disk. 2) It's not just the storage cost though right.. (cost of a bunch of disk, S&S) vs (cost of tape emulation, physical carts, bandwidth, S&S, HSM's direct & indirect costs) >>Glenn: agreed. TCO has to be considered 3) Ok, the UCB thing can be problematic for big shops, agreed. There's only so much you can do with 3390-54 (are bigger volumes coming anytime soon?). >>Glenn. DFSMS currently supports EAV 1TB volumes. > Another thing to consider with an all disk environment is your 'relief > valve'. It's simple to migrate data to tape as a means of ensuring that you > always have enough space on your primary storage for growth. If you only have > primary storage, what is your exception handling case when you have > unexpected growth and no migration tiers to which to move your inactive data? > How quickly can you bring more primary storage online? Sorry, I know it sounds silly when I keep saying 'assume x/y/z is already catered to', but ... assuming primary storage provisioning is no longer a problem (apart from the UCBs mentioned above). > Another option is DS8000 transparent cloud tiering. This enables you to > migrate inactive data to cloud object storage, with minimal cpu since the > DS8K is doing the data movement. If not a primary means of migrating data, it > is a very good option for a 'relief valve'. Hmm... the two whole approaches (all-primary vs standard procedure) need to costed out and compared to be impartial to either case. > Backup > Regardless of the replication technique that you are using > (synchronous/asynchronous), you need point-in-time copies of your data for > logical corruption protection. If a data set is accidentally or maliciously > deleted, replication quickly deletes it from all copies. Also, if data > becomes logically corrupted, it is instantly corrupted in all copies. So, you > have to have a point-in-time backup technique for all of your data. You need > as many copies as you want recovery points. One copy doesn't give you much > security. Keeping n copies on disk can get pricey and consume alot of > storage. Also, you need to replicate the n PiT copies to all of your sites so > that you can do a logical recovery after a physical fail over. This makes the > cost add up even more quickly. TCT is another good option for this. You can > keep 1 or 2 copies on disk and then have HSM migrate/expire the older backup > copies to cloud object storage which is then available at all of your > recovery sites. If we consider that the storage array has *proper* support for multi-site, snapshots/PiTs, etc. ... again not problematic. Fully understand I may be dreaming about such a primary storage, it's good to know the technical constraints against it. - KB ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
