Meeting Reminder - NY TSM User Group July 16th
New York Tivoli Storage Manager User Group July 16th, 2009 Agenda: (subject to updates) 10:00 - 11:00 TSM Update/Road Map 11:00 - 12:00 TSM FastBack 12:00 - 1:00 Lunch 1:00 - 2:00 TSM 6.1 Upgrade - News from the front 2:00 - 3:00 TSM 6.1 Reporting 3:00 - 4:00 Group Roundtable Meeting location: IBM Global Services 1630 Long Pond Road Rochester, New York 14626 (585) 723-4000 Directions: http://www.mapquest.com/maps?city=Rochesterstate=NYaddress=1630+Long+P ond+Roadzipcode=+ To register for this event and get details on other Tivoli User Groups, visit the Tivoli User Group site at : https://secure.tivoli-ug.org/check_user?type=meetingmeetid=1095 Sponsor: Jeffrey Connor This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please reply to this message and let the sender know.
NY TSM User Group Meeting Announcement
Hello! The next NY TSM User Group meeting is Thursday July 19th from 10:00-4:30 at National Grid in Syracuse NY. If you are interested in attending, please go to http://www.tivoli-ug.org/ and register as a member of our group and as an attendee for the meeting on 07/19. Or email Jeff Connor at [EMAIL PROTECTED] asap. . Thank you Jeff Connor - NYTUG Group Leader Agenda: Introductions 10:00 - Jeff Connor TSM Update/Directions 10:15 - Hershel Harris (IBM VP Tivoli Storage/Security Product Dev) TSM 5.4 Differences 11:15 - IBM Lunch 12:15 Optimizing Data Backup and Restoration 01:15 - IBM Shell, Perl Scripts to Generate TSM Reports 02:15 - Keith Rodrigues (NYS OFT) Open Forum/Group Roundtable 03:15 - Jeff Connor/Group Set fall meeting date and location 04:15 - Jeff Connor/Group Logistics: Location - National Grid 300 Erie Blvd West (Corner of Erie Blvd and Franklin Street) Syracuse, NY 13202 Meeting room A38/A39 Lost? - Call Jeff Connor, Office (315-428-6096), Cell phone(315-447-8057) Food - Sandwiches, Water/soda(a.k.a. pop), cookies/brownies, and other healthy snacks Parking - Pay parking lot on the corner of Franklin St and Washington St one block from National Grid Please use the main entrance on Erie Blvd. Tell the guard you are meeting with Jeff Connor for the TSM User Group Meeting. Driving Directions from South of Syracuse: 1. Take I-81 North 2. Merge onto I-690 W toward BALDWINSVILLE. 0.40 Miles 3. Take the WEST ST exit- exit number 11. 0.34 Miles 4. Merge onto N WEST ST. 0.23 Miles 5. Turn SLIGHT RIGHT onto ramp. 0.07 Miles 6. Keep RIGHT at the fork in the ramp. 0.04 Miles 7. Turn SLIGHT RIGHT onto NY-5/ERIE BLVD W. 0.10 Miles Driving Directions from North of Syracuse: 1. Take I-81 South 2. Take the CLINTON ST/SALINA ST exit- exit number 19. 0.04 Miles 3. Take the SALINA ST ramp. 0.13 Miles 4. Turn SLIGHT RIGHT onto N SALINA ST. 0.22 Miles 5. Turn RIGHT onto West Genesee St/James St. 0.010 Miles 6. Turn LEFT onto Clinton St. 0.10 Miles 7. Turn RIGHT onto NY-5/ERIE BLVD W. 0.30 Miles Driving Directions from East of Syracuse: 1. Take I-90 West toward BUFFALO 2. Merge onto I-81 S via exit number 36 toward SYRACUSE/BINGHAMTON. 3.50 Miles 3. Take the CLINTON ST/SALINA ST exit- exit number 19. 0.04 Miles 4. Take the SALINA ST ramp. 0.13 Miles 5. Turn SLIGHT RIGHT onto N SALINA ST. 0.22 Miles 6. Turn RIGHT onto West Genesee St/James St. 0.20 Miles 7. Turn LEFT onto Clinton St. 0.10 Miles 8. Turn RIGHT onto NY-5/ERIE BLVD W. 0.30 Miles Driving Directions from West of Syracuse: 1. Take I-90 East/NEW YORK STATE TRWY 2. Merge onto I-690 E via exit number 39 toward SYRACUSE. 8.76 Miles 3. Take the WEST ST exit- exit number 11- toward ONCENTER. 0.27 Miles 4. Merge onto N WEST ST. 0.23 Miles 5. Turn SLIGHT RIGHT onto ramp to Erie Blvd. 0.07 Miles 6. Keep RIGHT at the fork in the ramp. 0.04 Miles 7. Turn SLIGHT RIGHT onto NY-5/ERIE BLVD W. 0.10 Miles This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please reply to this message and let the sender know.
Re: Very slow restores (days), hours to locate files
Robin, I hope the LTO firmware resolves your problem. However, I have seen a similar situation for Windows clients in our shop and it was not a tape drive issue. The situation here was that we had a tape stgpool, 3590Ks /3590E1A drives, collocated by node, that reached its maxscratch value. This led to what some folks call imperfect collocation where even though the stgpool is setup to collocate by node, data for more than one node can end up on the same tape. The problem we had with the node intermix in a collocated by node pool showed itself with a situation that sounds similar to yours. We attempted to run a restore of an 8GB Win2k C: drive about 50% full and saw very long delays where nothing appeared to be happening. A tape change would occur, some data would transfer, and then a VERY long pause before a mount request for the next tape. Query Session while tape was mounted showed what your Q SE showed below, session in Run state, zero seconds wait time, but send and recv byte counts remain unchanged. While not as many but similar to you, our incremental backups of the servers C: drive had files spread around a number of tapes. We never determined the root cause of the think time between tape mount requests. We resolved the issue by moving tapes in our stgpool to a new pool with a high MAXSCR value effectively re-collocating the data. All restores ran very happy after that. Sorry I could not provide a root cause of our situation but that's how we addressed it. Just curious but do the 310 tapes you identified also contain data for other nodes and are you using collocation? Jeff Connor National Grid USA -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Robin Sharpe Sent: Wednesday, July 06, 2005 10:10 AM To: ADSM-L@VM.MARIST.EDU Subject: Very slow restores (days), hours to locate files Hi guys, We're having problems restoring some windows servers (W2K)... The servers in question had some disk problems and are being rebuilt, so the Windows admins are restoring the C: drive. It is an 8GB drive and less than 50% used, so only 4GB to restore. It has taken several days to restore. I know one of our problems is that the data is spread over hundreds of volumes (literally... I counted 310 from a volumeusage query). Another problem is that we have an overflowed library, but we have loaded all of the tapes from the Windows storage pool. What I don't understand is why it takes so long to locate a file once the tape is mounted. We have seen the same tape mounted for hours before any data is transferred. Here is an excerpt from a q se f=d of a restore that is running right now: Sess Number: 1,143 Comm. Method: TCP/IP Sess State: Run Wait Time: 0 S Bytes Sent: 670.9 M Bytes Recvd: 58.2 K Sess Type: Node Platform: WinNT Client Name: WANO01 Media Access Status: Current input volume(s): 200658,(2279 Seconds) User Name: Date/Time First Data Sent: Proxy By Storage Agent: This restore has been running for almost 12 hours now (they have been restarting them periodically). There has been NO DATA transferred from that tape in the 38 minutes it has been mounted... I know this from doing an lsof command and looking at the offset which indicates the number of bytes transferred. I know that when I restore a single file, it can be found within seconds of mounting a tape (these are all LTO-2)... so, why does it take so long in this case? Is TSM actually reading the entire tape? If so, wouldn't I see lots of data being transferred? Or is there some kind of SCSI command that allows the drive to read and compare the data it gets? I thought TSM stored actual locations of the files in the DB, so it could quickly find any file (or aggregate) without reading the whole tape... I've been searching the literature, and I can't find any details on this. The TSM server is on HP-UX 11i, IBM LTO-2 drives, fiber attached, in a STK L700 library. Also, my DB is huge (314GB), and we are currently (for the last year) unable to delete anything, so we have many versions of volatile files. We are planning to split our environment into several TSMs, and in the short term, our windows admins will start doing weekly selective backups of the C: drives to consolidate active versions on few tapes. Thanks for any thoughts on this Robin Sharpe Berlex Labs This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please reply to this message and let the sender know.
Re: Very slow restores (days), hours to locate files
In a sense, due to reaching maxscr, our pool was not collocated as well. Our issue was not the number of mounts but the long inactivity periods as you described. If you do find the cause, please post it on the listserv. Thanks Jeff -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Robin Sharpe Sent: Thursday, July 07, 2005 4:51 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: Very slow restores (days), hours to locate files The pool in question here is not collocated, so I expected to have lots of tape mounts but the long period of inactivity is what puzzles us. I've also seen notes indicating that the No Query Restore may be the cause... I'll suggest to our Windows guys to try a classic restore. -Robin Connor, Jeffrey P. [EMAIL PROTECTED] To: ADSM-L@VM.MARIST.EDU .NGRID.COMcc: Sent by: ADSM:Subject: Dist Stor Manager Re: Very slow restores (days), hours to locate files [EMAIL PROTECTED] EDU 07/07/2005 04:39 PM Please respond to ADSM: Dist Stor Manager Robin, I hope the LTO firmware resolves your problem. However, I have seen a similar situation for Windows clients in our shop and it was not a tape drive issue. The situation here was that we had a tape stgpool, 3590Ks /3590E1A drives, collocated by node, that reached its maxscratch value. This led to what some folks call imperfect collocation where even though the stgpool is setup to collocate by node, data for more than one node can end up on the same tape. The problem we had with the node intermix in a collocated by node pool showed itself with a situation that sounds similar to yours. We attempted to run a restore of an 8GB Win2k C: drive about 50% full and saw very long delays where nothing appeared to be happening. A tape change would occur, some data would transfer, and then a VERY long pause before a mount request for the next tape. Query Session while tape was mounted showed what your Q SE showed below, session in Run state, zero seconds wait time, but send and recv byte counts remain unchanged. While not as many but similar to you, our incremental backups of the servers C: drive had files spread around a number of tapes. We never determined the root cause of the think time between tape mount requests. We resolved the issue by moving tapes in our stgpool to a new pool with a high MAXSCR value effectively re-collocating the data. All restores ran very happy after that. Sorry I could not provide a root cause of our situation but that's how we addressed it. Just curious but do the 310 tapes you identified also contain data for other nodes and are you using collocation? Jeff Connor National Grid USA -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Robin Sharpe Sent: Wednesday, July 06, 2005 10:10 AM To: ADSM-L@VM.MARIST.EDU Subject: Very slow restores (days), hours to locate files Hi guys, We're having problems restoring some windows servers (W2K)... The servers in question had some disk problems and are being rebuilt, so the Windows admins are restoring the C: drive. It is an 8GB drive and less than 50% used, so only 4GB to restore. It has taken several days to restore. I know one of our problems is that the data is spread over hundreds of volumes (literally... I counted 310 from a volumeusage query). Another problem is that we have an overflowed library, but we have loaded all of the tapes from the Windows storage pool. What I don't understand is why it takes so long to locate a file once the tape is mounted. We have seen the same tape mounted for hours before any data is transferred. Here is an excerpt from a q se f=d of a restore that is running right now: Sess Number: 1,143 Comm. Method: TCP/IP Sess State: Run Wait Time: 0 S Bytes Sent: 670.9 M Bytes Recvd: 58.2 K Sess Type: Node Platform: WinNT Client Name: WANO01 Media Access Status: Current input volume(s): 200658,(2279 Seconds) User Name: Date/Time First Data Sent: Proxy By Storage Agent: This restore has been running for almost 12 hours now (they have been restarting them periodically). There has been NO DATA transferred from that tape in the 38 minutes it has been mounted... I know this from doing an lsof command and looking at the offset which indicates the number of bytes transferred. I know that when I restore a single file, it can be found within seconds of mounting a tape (these are all LTO-2)... so, why does it take so long in this case? Is TSM actually reading the entire tape
Re: 3590 FC
Hello Rod, We are using 3590E's with EMC 24M2's(Mcdata Sphereon 4500) which are ISL'd to a 64M director. Basically the configuration you are considering and we haven't had any problems with the 24M2's. Jeff Connor National Grid USA -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of rh Sent: Thursday, January 15, 2004 8:24 PM To: [EMAIL PROTECTED] Subject: 3590 FC Hi ITSM'rs, I apologize if this has been asked before. I'm not a SAN engineer and find it very frustrating when trying to navigate the many support matrix lists offered by all the SAN switch vendors. I currently have 14 3590E's connected to a Connectrix E64M director using Adic Gateway 3000 switches. The Adic switches have been very unreliable and I don't think they are still sold/supported. I'm looking for a replacement for the Adic switches. In particular I'd like to know if anyone is using Mcdata 4500 Sphereon's successfully with Connectrix in this kind of configuration. I'm not certain but I believe the Connectrix E64M is actually a Mcdata switch. If anyone is using any kind of switch successfully in a like configuration I'd like the particulars. Thanks very much, Rod Hroblak ADP __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please reply to this message and let the sender know.
Reminder: NY TSM Users Group Meeting - June 4th
Announcing a NY TSM Users Group Meeting to be held at Niagara Mohawk Power Corp 300 Erie Blvd West Syracuse, NY 13202 Conference Room #A38/A39 on June 4, 2003 1-3pm Agenda to include: Introductions TSM V5.2 Update Open discussion and a chance to meet other TSM users. Please confirm your attendence back to Jeff Connor ([EMAIL PROTECTED], 315-428-6096) at National Grid and cc: Ron Neidig at IBM ([EMAIL PROTECTED], 781-895-1360). This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please contact the National Grid USA Enterprise Support Center on 508-389-3375 or 315-428-6360.