Antwort: Re: Antwort: Re: Antwort: Re: Windows HSM experiences?
If you'll accept the modification ... no candidate for [ current TSM Windows ] HSM, then I think we're in complete agreement. yes i agree with you; there are disadvantages or missing implementations of hsm for windows compared with hsm for unix. with best regards stefan savoric
Antwort: Re: Antwort: Re: Windows HSM experiences?
hello, another thing to mention: HSM is a product to move inactive data from the disks, so when there are a lot of changes or retrieves of such former hsm migrated files, then this filespace is surely no candidate for HSM. with best regards stefan savoric
Re: Antwort: Re: Antwort: Re: Windows HSM experiences?
Just a note: I don't want to appear to be just dissing the Win HSM product; but I -do- want to make sure that nobody confuses it with the other products TSM has deployed under that name. It's _different_. On Fri, 20 Jan 2006 09:26:43 +0100, TSM [EMAIL PROTECTED] said: another thing to mention: HSM is a product to move inactive data from the disks, so when there are a lot of changes or retrieves of such former hsm migrated files, then this filespace is surely no candidate for HSM. If you'll accept the modification ... no candidate for [ current TSM Windows ] HSM, then I think we're in complete agreement. Our largest use of HSM has been for logfiles: Huge directories of every (say) SMTP or HTTP log from our cluster, dating back years. Access to the old files is uncommon, but regular, and not time sensitive. Once every (say) quarter, we might re-run a Last 12 months analysis, or some such. Once a year we might re run a Last four years analaysis or such. Worked well for years. This kind of use pattern is what I think of when I think HSM. You'd be nuts to try to do this under the windows HSM product. The largest speculative use we've entertained is related to large datafiles associated with e.g. physics experiments, with similar usage patterns: ~10TB of space with relatively rapid access needed, and hundreds of TB of other data available more slowly from tape, with access patterns, again, uncommon but regular. I think these access patterns are right down the middle of mainstream HSM utilization. - Allen S. Rout
Re: Windows HSM experiences?
I haven't used it myself, but it works the same way as OTG DiskExtender did. It was mentioned during discussion at our local TSM user group; at least 2 sites were using DiskExtender and LIKED the way it handled stub files. Yes, your backup has only the stub. But the file itself, is still in the HSM storage pool (and you should have a copy pool version also, etc.) The people who liked this arrangement pointed out that if they had to do a mass restore of a hard drive, it doesn't take very long, because they only restore the STUBS, not all the MB of all the data. Then when someone wants the file, and they touch it, TSM HSM kicks in to restrieve it as usual. Just another point of view. Wanda Prather I/O, I/O, It's all about I/O -(me) -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Allen S. Rout Sent: Wednesday, January 18, 2006 9:17 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: Windows HSM experiences? On Tue, 17 Jan 2006 13:28:36 -0500, Richard Rhodes [EMAIL PROTECTED] said: We are a Novell shop that has made a decision to migrate to Windows for file and print serving. There is talk about implementing the HSM client for Windows to help solve disk space problems. Is anyone using Windows HSM client and what are your experiences with it - good and bad. I had a bad experience with it; it was the presentation about it in Oxford. The Windows HSM implementation is very very different from the unix one. One example: If you have a HSM filesystem, and you put a file down: Day 1: You run an incr, and back up the file. Day 1.1: HSM decides to migrate your file. A stub is left. Day 2: You run an incr, and back up the stub. (!) Yes, your actual backup is now inactive. I asked about this three times. HSM might not migrate the file immediately, of course. But whenever it does, you'll cut a new copy of the (from your perspective 'unchanged') file, and make the complete version inactive. If you later retrieve the (in your opinion unchanged) file, the next incr will make another new version, and for a while your active version will be the full file. The long and short of it was that the presenter felt the Windows HSM client was appropriate for very, very static filespaces; perhaps PDF output repositories or report holding bins? But it seemed clear to me that it was not suitable for the kinds of tasks I've been accustomed to deploying on UNIX HSM. - Allen S. Rout - Apologies for the double 'very very'.
Re: Antwort: Re: Windows HSM experiences?
On Wed, 18 Jan 2006 16:55:25 +0100, TSM [EMAIL PROTECTED] said: let us view tsm: you will only have two sorts of files on the filesystem: the original file or (after hsm migration) the stub (or not, it depends on the hsm configuration) so tsm will have the stub and the original file in its storage, how many of them depends on the copygroup parameters. often the active version will be the stub file hsm: hsm migrates the file and the file is in the tsm storage, stub file is left. so you have to mention both hsm and tsm parameters very carefuly, that no data is lost. We agree. Contrast this with the UNIX HSM implementation, in a similar scenario to that which I discussed. Here's the windows HSM scenario: ]] Day 1: You run an incr, and back up the file. ]] Day 1.1: HSM decides to migrate your file. A stub is left. ]] Day 2: You run an incr, and back up the stub. (!) On AIX, it would go: Day 1: you run an incr, back up the file. Day 1.1: HSM decides to migrate your file, a stub is left. Day 2: You run an incr, and to a filesystem client the file is completely unchanged. No new copy needed, no new copy sent. The active version is the correct version, and there's never a stub backed up. I think that the AIX behavior is much more clear, much more TSM-ish. One response to this would be using your HSM workflow to serve the needs usually addressed by backups. But the windows-HSM storage is managed on the TSM server as archives, not as space-managed storage. This means that (unless you want your HSM filesystem to just lose files after N days) you have to set retention to NOLIMIT. This, in turn, means that you want to be -extremely- careful about how dynamic the space is, because you'll be keeping every version of every file, forever. Like I said in my initial reply: very very static spaces. - Allen S. Rout
Re: Windows HSM experiences?
On Tue, 17 Jan 2006 13:28:36 -0500, Richard Rhodes [EMAIL PROTECTED] said: We are a Novell shop that has made a decision to migrate to Windows for file and print serving. There is talk about implementing the HSM client for Windows to help solve disk space problems. Is anyone using Windows HSM client and what are your experiences with it - good and bad. I had a bad experience with it; it was the presentation about it in Oxford. The Windows HSM implementation is very very different from the unix one. One example: If you have a HSM filesystem, and you put a file down: Day 1: You run an incr, and back up the file. Day 1.1: HSM decides to migrate your file. A stub is left. Day 2: You run an incr, and back up the stub. (!) Yes, your actual backup is now inactive. I asked about this three times. HSM might not migrate the file immediately, of course. But whenever it does, you'll cut a new copy of the (from your perspective 'unchanged') file, and make the complete version inactive. If you later retrieve the (in your opinion unchanged) file, the next incr will make another new version, and for a while your active version will be the full file. The long and short of it was that the presenter felt the Windows HSM client was appropriate for very, very static filespaces; perhaps PDF output repositories or report holding bins? But it seemed clear to me that it was not suitable for the kinds of tasks I've been accustomed to deploying on UNIX HSM. - Allen S. Rout - Apologies for the double 'very very'.
Antwort: Re: Windows HSM experiences?
hello allen, you describe mixed solution with tsm and hsm, let us view tsm: you will only have two sorts of files on the filesystem: the original file or (after hsm migration) the stub (or not, it depends on the hsm configuration) so tsm will have the stub and the original file in its storage, how many of them depends on the copygroup parameters. often the active version will be the stub file hsm: hsm migrates the file and the file is in the tsm storage, stub file is left. so you have to mention both hsm and tsm parameters very carefuly, that no data is lost. when you restore the filesystem, you can decide to do it with tsm, then a mix of stub files and original files is restored (this is exact the filesystem as it was at last tsm backup), or you can restore with hsm, then all original files are restored. with best regards stefan savoric
Windows HSM experiences?
We are a Novell shop that has made a decision to migrate to Windows for file and print serving. There is talk about implementing the HSM client for Windows to help solve disk space problems. Is anyone using Windows HSM client and what are your experiences with it - good and bad. Thanks Rick - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
