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? 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) 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?). > 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 ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, July 6, 2020 10:54 PM, Glenn Wilcock <wilc...@us.ibm.com> wrote: > A few thoughts: > > 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. > > Some clients have selected to go to an all HSM ML1 environment to still get > the advantage of zEDC compression on inactive data. (You may be utilizing > zEDC for primary storage, but that is only available for nonVSAM data). These > clients utilize the lowest cost disk and utilize the value of zEDC > compression to minimize the footprint. > > 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? > > 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'. > > 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. > > Glenn Wilcock > DFSMS Chief Product Owner > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
