Re: Good or bad idea?...offsite disk.
I have a TSM server version 5.3.3.1 running on AIX. Database is 70GB, I recently moved the db and log vols off of 500GB SATA drives to internal drives on the AIX box. I have the dbvols spread across 8 disks and mirrored within TSM on 8 separate internal disks. Everything is much faster now with the exception of "expire inventory", it runs for several hours now as opposed to just a couple hours before. Right now, my expire inventory has been running for an hour and has been stuck where it is in the example below. I don't see anything in the activity logs. Any idears? tsm: TSMCORP3>q pr Process Process Description Status Number - 2,301 Expiration Examined 304 objects, deleting 272 backup objects, 0 archive objects, 0 DB backup volumes, 0 recovery plan files; 0 errors encountered. This email and any files transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended addressee, then you have received this email in error and any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Please notify us immediately of your unintended receipt by reply and then delete this email and your reply. Tyson Foods, Inc. and its subsidiaries and affiliates will not be held liable to any person resulting from the unintended or unauthorized use of any information contained in this email or as a result of any additions or deletions of information originally contained in this email.
Re: Good or bad idea?...offsite disk.
>> On Mon, 02 Apr 2007 15:50:21 -0400, "Allen S. Rout" <[EMAIL PROTECTED]> said: > In imitation of that, I'm considering a library of LIBT FILE, with > predefined FILE volumes on paths accessible to all of the client > instances. Then the library manager hands out individual volumes, > which are (promptly, I hope) backed up, migrated off to tape, and > then returned to the lib mgr. For those who were wondering what I was smoking, the answer is "I have no idea, but It's worn off now". I don't know how I arrived at the (clear and strong) impression that I could share FILE devices in the way I described. But, attempting to test it I found I was unambiguously mistaken. :) I guess that's an anticannibalism measure protecting the SANERGY product. (like you'd want to do that over NFS. Hah) Oh well. - Allen S. Rout
Re: Good or bad idea?...offsite disk.
>> On Mon, 2 Apr 2007 12:34:55 -0600, Kelly Lipp <[EMAIL PROTECTED]> said: > OK, I did volunteer. I'll take a crack at these issues... heh. > 1) reusedelay. In circumstances where I'm thinking of these FILE vols >as replacing DISK vols, I don't want to have to hold on to that >space for a few days before it becomes available again. Just >reusedelay=0, and view the data as ephemeral? > Make sure that if you do restore a database that you audit fix=yes > all of the volumes. With my current DISK pools, if they die, then it's "Too bad, so sad". So I'd probably plan that the FILE devclasses be similar. So I'd mark them all destroyed, attempt to restore what I could from copies. Cool, good advice. > 2) Performance management. [...] > Clearly this is of great concern. [ .. lucid analysis ] OK, I like: and the disk-to-FILE is a really good idea. > Back to my earlier point: I don't like scratch volumes. But one > could try it. However, why have more than one pool anyway? But if > you do, the scratch and trigger mechanisms available for file device > class might work well, but I have not experimented with it much. > When I did play with it, I struggled with understanding the > principles involved and opted to pre-define. I'm failing to communicate; I wasn't suggesting scratch FILE volumes. Let me try again. I've got a library server, with defined tape volumes. These are served to library clients, of which I've got 10 and counting running on the same hardware. In imitation of that, I'm considering a library of LIBT FILE, with predefined FILE volumes on paths accessible to all of the client instances. Then the library manager hands out individual volumes, which are (promptly, I hope) backed up, migrated off to tape, and then returned to the lib mgr. Right now, I've got a big DISK pool which is pegged once a week and empty most of the rest: It's inconvenient for me to redistribute that space: if I could let the library manager do so in (say) 5G aliquots, that would be superfine. :) - Allen S. Rout
Re: Good or bad idea?...offsite disk.
OK, I did volunteer. I'll take a crack at these issues... 1) reusedelay. In circumstances where I'm thinking of these FILE vols as replacing DISK vols, I don't want to have to hold on to that space for a few days before it becomes available again. Just reusedelay=0, and view the data as ephemeral? As is the case with the other sequential device classes one must be concerned about when a volume is reclaimed and then reused in conjunction with a database backup. I believe that making sure that all of your daily processing completes, especially the backup stgpool operations and db backup is the key to success. When we have had problems using large pools of files it has been when we've needed to restore the database and audit those volumes. Consideration and process is the key. Make sure that if you do restore a database that you audit fix=yes all of the volumes. This can be time consuming... 2) Performance management. Currently I'm on Big ol' raids of 36G SSA, which can accept 30MB/s per raid. I allocate a stripe across all my RAIDs to each DISK stgpool, which means I've got e.g. 9 or 11 different performance contention domains. This works really well: if all my servers are booming, I still have really nicely spread IO. If I go against FILE devclasses, especially pre-allocated, it seems like I lose that, and I could easily have all my servers trying to write to the same one or two LUNs. How would you handle that? Just throw it all at the disk devices' cache and hope it's enough? Clearly this is of great concern. However, I believe that over time this problem remedies itself. Since sequential access volumes can be reclaimed, one will find that when some process or client needs a volume it will get one more or less randomly throughout all the storage thus spreading the load. You are correct, though, in that at first, TSM will allocate volumes in numerical order and will thus keep the first disk hot and then the second and so on until the volumes start to be reclaimed. Then the load will normalize across the drives. In the long run I don't think this is an issue. Volumes will be available across all drives and will be somewhat randomly used by TSM. I think the key is to use pre-defined volumes rather than scratch volumes. This keeps each of these volumes contiguous on the disk and increases overall performance. Is there an optimal configuration for your storage for this use? I'm sure. Is it the one you have now? Maybe not, but it is probably worth a try. You can more or less easily switch it around later if you are not convinced. Typically RAID5 is death to smoochy in TSM. But with high end controllers with lots of write cache this is mitigated. One could front the file device class pool with a disk device class pool. We've done that in some cases. Then limit the number of write streams using migration. This takes the problem of many writers (like 100 simultaneous client backups) down to a couple. Your SATA drives will love you! 3) Free space consolidation. The biggest reason I want to use FILEs is that I'd like to be able to deploy my 3TB of landing pad in such a way that any server, any FILE stpool, can temporarily overflow without any OS-level reallocation nonsense; just changing maxscratch or some such. I thought I might be able to do this with a library handing out the FILE vols; am I insane? Back to my earlier point: I don't like scratch volumes. But one could try it. However, why have more than one pool anyway? But if you do, the scratch and trigger mechanisms available for file device class might work well, but I have not experimented with it much. When I did play with it, I struggled with understanding the principles involved and opted to pre-define. A couple of other pointes about the file device class: caching isn't supported, it is sequential so TSM does not need to allocate space as it does in a disk device class pool so is faster, it is strategic to TSM futures. That means new stuff will be put there first and disk might be dead somewhere along the line. Best feature: these volumes can be reclaimed where disk device class cannot. The beauty of the software we are using is that we can change this stuff around fairly easily to see what we get. If we don't like it, we can change it back. I'll be very curious to hear how your experimentation goes. We've had good luck with very large file device pools and have built a number of disk only STORServers (DR is done to tape, but all of the onlinepools are disk). Do let me know! Thanks, Kelly J. Lipp VP Manufacturing & CTO STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 719-266-8777 [EMAIL PROTECTED]
Re: Good or bad idea?...offsite disk.
>> On Mon, 2 Apr 2007 10:40:30 -0600, Kelly Lipp <[EMAIL PROTECTED]> said: > 2. Aggressively reclaim the storage pool. Perhaps set reclaim to 30 > rather than the standard 60. This will have lots of data movement, but > will tend to keep as much space as possible available in the pool. I've been considering using FILE devclasses in place of DISK for some time, but I've got some questions and some design ideas I wanted to run by someone, and > Additional questions: fire away. I've done a good bit of work on > this... YOU just volunteered! Woot. 1) reusedelay. In circumstances where I'm thinking of these FILE vols as replacing DISK vols, I don't want to have to hold on to that space for a few days before it becomes available again. Just reusedelay=0, and view the data as ephemeral? 2) Performance management. Currently I'm on Big ol' raids of 36G SSA, which can accept 30MB/s per raid. I allocate a stripe across all my RAIDs to each DISK stgpool, which means I've got e.g. 9 or 11 different performance contention domains. This works really well: if all my servers are booming, I still have really nicely spread IO. If I go against FILE devclasses, especially pre-allocated, it seems like I lose that, and I could easily have all my servers trying to write to the same one or two LUNs. How would you handle that? Just throw it all at the disk devices' cache and hope it's enough? 3) Free space consolidation. The biggest reason I want to use FILEs is that I'd like to be able to deploy my 3TB of landing pad in such a way that any server, any FILE stpool, can temporarily overflow without any OS-level reallocation nonsense; just changing maxscratch or some such. I thought I might be able to do this with a library handing out the FILE vols; am I insane? - Allen S. Rout
Re: Good or bad idea?...offsite disk.
Yes, we've backed up the db to a devclass=file for many years. >>> [EMAIL PROTECTED] 04/02/07 1:03 PM >>> You wouldnt be able to set up a copypool for the offsite copy it would have to be another onsite pool. You could always try using the devcl type of file and going that route. I would also look at doing the dbbackups as devcl=file. That is what we are looking at doing to reduce the waste of gigs of tape for a rather small db. On Mon, 2007-04-02 at 11:55 -0400, Lawrence Clark wrote: > We have two sites. The 2nd site has primary storage, the primary > copypools. Both are currently in tape libaries. > > We do plan to move the primary storage pools to SATA drives on a > DS4800. > > We did try migrateing the copypools to SATA drives but I found the > setup very awkward. Primary pools can be random storage, copypools can > only be disk based if they simulate drives. > > What I found was when it reached the end of the disk 'volume' it > generated a write error on the 'volume' and then allocated another > volume and continued. However, this meant reseting the volumes that > reached the maximum volume size each morning. > > The problem with mirroring primary storage pool is a delete on one is > an immediate delete on the mirror. > > >>> [EMAIL PROTECTED] 04/02/07 12:31 PM >>> > One of my TSM servers is using disk only for onsite pools and tape for > offsite. I am considering putting a SAN offsite to mirror my onsite > diskpools thereby doing away with tape all together. This server has > about 12TB of storage. I have a dedicated fiber link to my offsite > location. > Is this a good or bad idea? I understand that DRM won't be in effect > any longer. Client restores would be more readily available if needed > but what about the database? Any considerations or recommendations > there or elsewhere? > > Thanks, > Johnny > > > The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain information that is confidential, privileged, and/or otherwise exempt from disclosure under applicable law. If this electronic message is from an attorney or someone in the Legal Department, it may also contain confidential attorney-client communications which may be privileged and protected from disclosure. If you are not the intended recipient, be advised that you have received this message in error and that any use, dissemination, forwarding, printing, or copying is strictly prohibited. Please notify the New York State Thruway Authority immediately by either responding to this e-mail or calling (518) 436-2700, and destroy all copies of this message and any attachments. This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately. Thank you. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain information that is confidential, privileged, and/or otherwise exempt from disclosure under applicable law. If this electronic message is from an attorney or someone in the Legal Department, it may also contain confidential attorney-client communications which may be privileged and protected from disclosure. If you are not the intended recipient, be advised that you have received this message in error and that any use, dissemination, forwarding, printing, or copying is strictly prohibited. Please notify the New York State Thruway Authority immediately by either responding to this e-mail or calling (518) 436-2700, and destroy all copies of this message and any attachments.
Re: Good or bad idea?...offsite disk.
Lots of thoughts here and in no particular order. 1. Define the volumes rather than using scratch volumes for your file device class pools. No point allowing the system to do this: Define volume stgpool e:\of formatsize=5000 numberofvols=256 This command will format and define 256 volumes of size 5GB to your storage pool. Repeat until your drive is filled up. This will eliminate all the errors you are seeing and eliminate fragmentation on the disk. You might want to make the volumes larger (remember the size is also a function of maxcap on the devclass parameter). 2. Aggressively reclaim the storage pool. Perhaps set reclaim to 30 rather than the standard 60. This will have lots of data movement, but will tend to keep as much space as possible available in the pool. 3. As for mirroring primary pool volumes. Hmmm. Why not? You will still want to have a dr copy in case something happens to the primary volumes. This could be tape or it could be disk. I've attached two Oxford 2005 presentations that discuss this in more detail. First is Dave Cannon's feature overview and then my practical implementation of these features. I believe both are still relevant. Additional questions: fire away. I've done a good bit of work on this... Kelly J. Lipp VP Manufacturing & CTO STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 719-266-8777 [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Meadows Sent: Monday, April 02, 2007 10:04 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Good or bad idea?...offsite disk. You wouldnt be able to set up a copypool for the offsite copy it would have to be another onsite pool. You could always try using the devcl type of file and going that route. I would also look at doing the dbbackups as devcl=file. That is what we are looking at doing to reduce the waste of gigs of tape for a rather small db. On Mon, 2007-04-02 at 11:55 -0400, Lawrence Clark wrote: > We have two sites. The 2nd site has primary storage, the primary > copypools. Both are currently in tape libaries. > > We do plan to move the primary storage pools to SATA drives on a > DS4800. > > We did try migrateing the copypools to SATA drives but I found the > setup very awkward. Primary pools can be random storage, copypools can > only be disk based if they simulate drives. > > What I found was when it reached the end of the disk 'volume' it > generated a write error on the 'volume' and then allocated another > volume and continued. However, this meant reseting the volumes that > reached the maximum volume size each morning. > > The problem with mirroring primary storage pool is a delete on one is > an immediate delete on the mirror. > > >>> [EMAIL PROTECTED] 04/02/07 12:31 PM >>> > One of my TSM servers is using disk only for onsite pools and tape for > offsite. I am considering putting a SAN offsite to mirror my onsite > diskpools thereby doing away with tape all together. This server has > about 12TB of storage. I have a dedicated fiber link to my offsite > location. > Is this a good or bad idea? I understand that DRM won't be in effect > any longer. Client restores would be more readily available if needed > but what about the database? Any considerations or recommendations > there or elsewhere? > > Thanks, > Johnny > > > The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain information that is confidential, privileged, and/or otherwise exempt from disclosure under applicable law. If this electronic message is from an attorney or someone in the Legal Department, it may also contain confidential attorney-client communications which may be privileged and protected from disclosure. If you are not the intended recipient, be advised that you have received this message in error and that any use, dissemination, forwarding, printing, or copying is strictly prohibited. Please notify the New York State Thruway Authority immediately by either responding to this e-mail or calling (518) 436-2700, and destroy all copies of this message and any attachments. This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately. Thank you.
Re: Good or bad idea?...offsite disk.
You wouldnt be able to set up a copypool for the offsite copy it would have to be another onsite pool. You could always try using the devcl type of file and going that route. I would also look at doing the dbbackups as devcl=file. That is what we are looking at doing to reduce the waste of gigs of tape for a rather small db. On Mon, 2007-04-02 at 11:55 -0400, Lawrence Clark wrote: > We have two sites. The 2nd site has primary storage, the primary > copypools. Both are currently in tape libaries. > > We do plan to move the primary storage pools to SATA drives on a > DS4800. > > We did try migrateing the copypools to SATA drives but I found the > setup very awkward. Primary pools can be random storage, copypools can > only be disk based if they simulate drives. > > What I found was when it reached the end of the disk 'volume' it > generated a write error on the 'volume' and then allocated another > volume and continued. However, this meant reseting the volumes that > reached the maximum volume size each morning. > > The problem with mirroring primary storage pool is a delete on one is > an immediate delete on the mirror. > > >>> [EMAIL PROTECTED] 04/02/07 12:31 PM >>> > One of my TSM servers is using disk only for onsite pools and tape for > offsite. I am considering putting a SAN offsite to mirror my onsite > diskpools thereby doing away with tape all together. This server has > about 12TB of storage. I have a dedicated fiber link to my offsite > location. > Is this a good or bad idea? I understand that DRM won't be in effect > any longer. Client restores would be more readily available if needed > but what about the database? Any considerations or recommendations > there or elsewhere? > > Thanks, > Johnny > > > The information contained in this electronic message and any attachments to > this message are intended for the exclusive use of the addressee(s) and may > contain information that is confidential, privileged, and/or otherwise exempt > from disclosure under applicable law. If this electronic message is from an > attorney or someone in the Legal Department, it may also contain confidential > attorney-client communications which may be privileged and protected from > disclosure. If you are not the intended recipient, be advised that you have > received this message in error and that any use, dissemination, forwarding, > printing, or copying is strictly prohibited. Please notify the New York > State Thruway Authority immediately by either responding to this e-mail or > calling (518) 436-2700, and destroy all copies of this message and any > attachments. This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately. Thank you.
Re: Good or bad idea?...offsite disk.
We have two sites. The 2nd site has primary storage, the primary copypools. Both are currently in tape libaries. We do plan to move the primary storage pools to SATA drives on a DS4800. We did try migrateing the copypools to SATA drives but I found the setup very awkward. Primary pools can be random storage, copypools can only be disk based if they simulate drives. What I found was when it reached the end of the disk 'volume' it generated a write error on the 'volume' and then allocated another volume and continued. However, this meant reseting the volumes that reached the maximum volume size each morning. The problem with mirroring primary storage pool is a delete on one is an immediate delete on the mirror. >>> [EMAIL PROTECTED] 04/02/07 12:31 PM >>> One of my TSM servers is using disk only for onsite pools and tape for offsite. I am considering putting a SAN offsite to mirror my onsite diskpools thereby doing away with tape all together. This server has about 12TB of storage. I have a dedicated fiber link to my offsite location. Is this a good or bad idea? I understand that DRM won't be in effect any longer. Client restores would be more readily available if needed but what about the database? Any considerations or recommendations there or elsewhere? Thanks, Johnny The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain information that is confidential, privileged, and/or otherwise exempt from disclosure under applicable law. If this electronic message is from an attorney or someone in the Legal Department, it may also contain confidential attorney-client communications which may be privileged and protected from disclosure. If you are not the intended recipient, be advised that you have received this message in error and that any use, dissemination, forwarding, printing, or copying is strictly prohibited. Please notify the New York State Thruway Authority immediately by either responding to this e-mail or calling (518) 436-2700, and destroy all copies of this message and any attachments.
Good or bad idea?...offsite disk.
One of my TSM servers is using disk only for onsite pools and tape for offsite. I am considering putting a SAN offsite to mirror my onsite diskpools thereby doing away with tape all together. This server has about 12TB of storage. I have a dedicated fiber link to my offsite location. Is this a good or bad idea? I understand that DRM won't be in effect any longer. Client restores would be more readily available if needed but what about the database? Any considerations or recommendations there or elsewhere? Thanks, Johnny
