Re: Bandwidth
Thomas, To get some immediate consider using the randomize setting on the TSM server combined with an extended backup window and limiting the number of machines that can backup concurrently with the maxschedsessions setting. This will allow you to have some control over how many clients backup at one time. For example; if you set your backup window for say 4 hours then tweak the randomize setting which will stagger your start times of the client backups by a set percentage. This keeps all of them from initiating their backups at once. Additionally, maxschedsessions will allow you to limit how many actual clients can connect at one time. Obviously each environment is different and actual settings depend on variables such as total number of clients, amount of data, speed of network, etc, etc. I suggest starting off conservatively, monitor the actlog for issues, and tweak as needed. I have used this approach many times for customers while campaigning for increased bandwidth resources. Rick Adamson -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Tom Taylor Sent: Wednesday, May 14, 2014 10:56 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Bandwidth Good morning, I run TSM 6.3.4 How do I throttle bandwidth so that the clients don't choke the network during backups. I have already set a large window for the clients to use, and I am reading about client side de-duplication, and adaptive file backup. Are these the only two avenues to reduce the bandwidth used by TSM? Thomas Taylor System Administrator Jos. A. Bank Clothiers Cell (443)-974-5768
Re: Bandwidth
Hi Thomas, Just to be sure, are you talking about LAN or WAN backup traffic? Is your bottleneck in the TSM-client-to-switch connection or the switch-to-tsm-server connection? If TSM is saturating your WAN lines, looking into dedup and compression is the best you can do. If your problem is within a LAN you might have to reconsider your backbone and network design, if that is not an option spreading the client start times might do the trick. But there is no such thing in TSM as bandwidth throttling like in i.e. Symantec Netbackup. - Bent -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Tom Taylor Sent: Wednesday, May 14, 2014 5:56 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Bandwidth Good morning, I run TSM 6.3.4 How do I throttle bandwidth so that the clients don't choke the network during backups. I have already set a large window for the clients to use, and I am reading about client side de-duplication, and adaptive file backup. Are these the only two avenues to reduce the bandwidth used by TSM? Thomas Taylor System Administrator Jos. A. Bank Clothiers Cell (443)-974-5768
Re: Upgrading a Linux client
For Linux clients, I've always had to remove (rpm -e) and install (rpm ivh or rpm -Uvh) the client rpms. If upgrade now works without a remove first, I'd love to know at what client level that started. David -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Remco Post Sent: Thursday, May 15, 2014 1:54 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Upgrading a Linux client what he said, or rpm -Uhv will maybe do (-U for upgrade, -i for install), h for nice hash marks as a progress bar and v for not Very quiet ;-) Op 14 mei 2014, om 16:19 heeft Erwann Simon erwann.si...@free.fr het volgende geschreven: Eric, You need to uninstall (rpm -e) and then reinstall (rpm -i). On 14 mai 2014 16:17:02 CEST, Loon, EJ van (SPLXM) - KLM eric-van.l...@klm.com wrote: Hi guys! I'm not really an Linux expert, but I'm trying to upgrade a 6.2 client to 7.1 on a Linux nodes. When I follow the commands from the manual to install the API client (rpm -i TIVsm-API64.x86_64.rpm) it fails with several of the following messages: file /opt/tivoli/tsm/client/api/bin64/sample/dapiutil.c from install of TIVsm-API64-7.1.0-0.x86_64 conflicts with file from package TIVsm-API64-6.2.4-0.i586 file /opt/tivoli/tsm/client/api/bin64/sample/dpsthread.h from install of TIVsm-API64-7.1.0-0.x86_64 conflicts with file from package TIVsm-API64-6.2.4-0.i586 file /opt/tivoli/tsm/client/api/bin64/sample/dsmapips.h from install of TIVsm-API64-7.1.0-0.x86_64 conflicts with file from package TIVsm-API64-6.2.4-0.i586 I tried the -U switch, but that doesn't help either. What am I doing wrong here? Isn't it possible to upgrade the client and should I uninstall 6.2.4 first? Thanks again for your help! Kind regards, Eric van Loon AF/KLM Storage Engineering For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- Erwann SIMON Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté. -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl +31 6 248 21 622
Re: Upgrading a Linux client
Hi David, Upgrade (rpm -U) is working begining with client 6.3. I guess it has been changed to enable/facilitate autodeployment. -- Best regards / Cordialement / مع تحياتي Erwann SIMON - Mail original - De: David E. Ehresman deehr...@louisville.edu À: ADSM-L@VM.MARIST.EDU Envoyé: Jeudi 15 Mai 2014 15:04:31 Objet: Re: [ADSM-L] Upgrading a Linux client For Linux clients, I've always had to remove (rpm -e) and install (rpm ivh or rpm -Uvh) the client rpms. If upgrade now works without a remove first, I'd love to know at what client level that started. David -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Remco Post Sent: Thursday, May 15, 2014 1:54 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Upgrading a Linux client what he said, or rpm -Uhv will maybe do (-U for upgrade, -i for install), h for nice hash marks as a progress bar and v for not Very quiet ;-) Op 14 mei 2014, om 16:19 heeft Erwann Simon erwann.si...@free.fr het volgende geschreven: Eric, You need to uninstall (rpm -e) and then reinstall (rpm -i). On 14 mai 2014 16:17:02 CEST, Loon, EJ van (SPLXM) - KLM eric-van.l...@klm.com wrote: Hi guys! I'm not really an Linux expert, but I'm trying to upgrade a 6.2 client to 7.1 on a Linux nodes. When I follow the commands from the manual to install the API client (rpm -i TIVsm-API64.x86_64.rpm) it fails with several of the following messages: file /opt/tivoli/tsm/client/api/bin64/sample/dapiutil.c from install of TIVsm-API64-7.1.0-0.x86_64 conflicts with file from package TIVsm-API64-6.2.4-0.i586 file /opt/tivoli/tsm/client/api/bin64/sample/dpsthread.h from install of TIVsm-API64-7.1.0-0.x86_64 conflicts with file from package TIVsm-API64-6.2.4-0.i586 file /opt/tivoli/tsm/client/api/bin64/sample/dsmapips.h from install of TIVsm-API64-7.1.0-0.x86_64 conflicts with file from package TIVsm-API64-6.2.4-0.i586 I tried the -U switch, but that doesn't help either. What am I doing wrong here? Isn't it possible to upgrade the client and should I uninstall 6.2.4 first? Thanks again for your help! Kind regards, Eric van Loon AF/KLM Storage Engineering For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- Erwann SIMON Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté. -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl +31 6 248 21 622
Slow mount of FILE storage pools volumes
Hi all, I've recently done some upgrades to a customer's TSM server and I'm now experiencing some strange behabiour with long delay for mount of FILE storage pools volumes. Delay is 1 minute or more, and it seems it does not depend on usage (mount for client sessions or server processes). Does someone had some similar issue ? Thanks. Here's a view of the current platform : - RHEL 6.4 - TSM 6.3.4.300 - 2 CPU 8C - 256GB - 15k disks for DB (internal) - 10k disks for FILE storage pools (IBM DS3524) - FILE volumes are pre-allocated and 100GB each (I know, it's a bit large) - TSM deduplication is used Changes made : - Server HW has been renewed from an 4 years old server - Older server was running RHEL 5.8 and TSM 6.3.4.200 - No other significative change. -- Best regards / Cordialement / مع تحياتي Erwann SIMON
Re: Bandwidth
Thanks for all the advice, I am talking about WAN traffic. Thomas Taylor System Administrator Jos. A. Bank Clothiers Cell (443)-974-5768 From: Bent Christensen b...@cowi.dk To: ADSM-L@VM.MARIST.EDU, Date: 05/15/2014 08:54 AM Subject: Re: [ADSM-L] Bandwidth Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU Hi Thomas, Just to be sure, are you talking about LAN or WAN backup traffic? Is your bottleneck in the TSM-client-to-switch connection or the switch-to-tsm-server connection? If TSM is saturating your WAN lines, looking into dedup and compression is the best you can do. If your problem is within a LAN you might have to reconsider your backbone and network design, if that is not an option spreading the client start times might do the trick. But there is no such thing in TSM as bandwidth throttling like in i.e. Symantec Netbackup. - Bent -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Tom Taylor Sent: Wednesday, May 14, 2014 5:56 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Bandwidth Good morning, I run TSM 6.3.4 How do I throttle bandwidth so that the clients don't choke the network during backups. I have already set a large window for the clients to use, and I am reading about client side de-duplication, and adaptive file backup. Are these the only two avenues to reduce the bandwidth used by TSM? Thomas Taylor System Administrator Jos. A. Bank Clothiers Cell (443)-974-5768
Re: Slow mount of FILE storage pools volumes
A couple things I can think of: * Do you have any stale NFS mounts on your TSM server? Even if the FILE volumes are not on NFS, I've seen slow access on any file if there's a hung mount. * Do you use a central directory server (NIS, LDAP, etc.) for this system? If directory lookups are slow, that could slow down file access as well. On Thu, May 15, 2014 at 03:44:32PM +0200, Erwann Simon wrote: Hi all, I've recently done some upgrades to a customer's TSM server and I'm now experiencing some strange behabiour with long delay for mount of FILE storage pools volumes. Delay is 1 minute or more, and it seems it does not depend on usage (mount for client sessions or server processes). Does someone had some similar issue ? Thanks. Here's a view of the current platform : - RHEL 6.4 - TSM 6.3.4.300 - 2 CPU 8C - 256GB - 15k disks for DB (internal) - 10k disks for FILE storage pools (IBM DS3524) - FILE volumes are pre-allocated and 100GB each (I know, it's a bit large) - TSM deduplication is used Changes made : - Server HW has been renewed from an 4 years old server - Older server was running RHEL 5.8 and TSM 6.3.4.200 - No other significative change. -- Best regards / Cordialement / Erwann SIMON -- -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine
Re: Slow mount of FILE storage pools volumes
Thanks Skylar, The is no NFS mount on this server and is does not use and external directory for identification authentification either. -- Best regards / Cordialement / مع تحياتي Erwann SIMON - Mail original - De: Skylar Thompson skyl...@u.washington.edu À: ADSM-L@VM.MARIST.EDU Envoyé: Jeudi 15 Mai 2014 16:25:45 Objet: Re: [ADSM-L] Slow mount of FILE storage pools volumes A couple things I can think of: * Do you have any stale NFS mounts on your TSM server? Even if the FILE volumes are not on NFS, I've seen slow access on any file if there's a hung mount. * Do you use a central directory server (NIS, LDAP, etc.) for this system? If directory lookups are slow, that could slow down file access as well. On Thu, May 15, 2014 at 03:44:32PM +0200, Erwann Simon wrote: Hi all, I've recently done some upgrades to a customer's TSM server and I'm now experiencing some strange behabiour with long delay for mount of FILE storage pools volumes. Delay is 1 minute or more, and it seems it does not depend on usage (mount for client sessions or server processes). Does someone had some similar issue ? Thanks. Here's a view of the current platform : - RHEL 6.4 - TSM 6.3.4.300 - 2 CPU 8C - 256GB - 15k disks for DB (internal) - 10k disks for FILE storage pools (IBM DS3524) - FILE volumes are pre-allocated and 100GB each (I know, it's a bit large) - TSM deduplication is used Changes made : - Server HW has been renewed from an 4 years old server - Older server was running RHEL 5.8 and TSM 6.3.4.200 - No other significative change. -- Best regards / Cordialement / Erwann SIMON -- -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine
3584 L23 IP interface
Am I correct that the IP connection in the L23 frame is used purely for the Tape Library Specialist web interface, not like the 3494 where its IP connection was also used for management interface with the TSM servers? My network folks want to change/move the address. -- *Zoltan Forray* TSM Software Hardware Administrator BigBro / Hobbit / Xymon Administrator Virginia Commonwealth University UCC/Office of Technology Services zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html
Re: 3584 L23 IP interface
Yes and No It is used to access the Specialist web interface. The IP info is set from the front console. We don't do this, but I believe you also use the ethernet interface to have the 3584 access a Master Console for dial home. See the topic Remote Support through a Master Console in the 3584 Introduction and Planning Guide. I think it says you need 2 ethernet interfaces to do this. Curiously, there are ethernet connections in each frame with drives. It's on a small box above the top most drive. Via the console you can set IP info on each frames ethernet port. You can then access the specialist from multiple IP addresses. We had a issue where the specialist became unresponsive. IBM said the library would need power cycled to free it up - which we couldn't do right then. They then suggested just moving the IP address to one of the other ethernet ports and move the lan cable to that port. This worked until we got a power cycle on the lib. I found this interesting - a hung specialist in the first frame and working specialist when accessed via other frames. You are correct that the ethernet connection is NOT used for library communications from the TSM server. That is handled via control paths defined on some number of drives. These show up as a separate device at the server. On AIX they show up as smcX devices. So library communications occurs across the fibrechannel san. rick -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Zoltan Forray Sent: Thursday, May 15, 2014 1:07 PM To: ADSM-L@VM.MARIST.EDU Subject: 3584 L23 IP interface Am I correct that the IP connection in the L23 frame is used purely for the Tape Library Specialist web interface, not like the 3494 where its IP connection was also used for management interface with the TSM servers? My network folks want to change/move the address. -- *Zoltan Forray* TSM Software Hardware Administrator BigBro / Hobbit / Xymon Administrator Virginia Commonwealth University UCC/Office of Technology Services zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html - 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.
Re: 3584 L23 IP interface
Thanks for the confirmation. In our other frame with drives, there is an Ethernet cable going to a switch besides the TS3000 console. It has a 172 address (we don't use it), so it must be the call home/maintenance connection. FWIW, on Linux systems, the drives used for the control paths appear via IBMchangern, where the number on entries depends on how many fibre paths and drives assigned as control paths. On Thu, May 15, 2014 at 1:50 PM, Rhodes, Richard L. rrho...@firstenergycorp.com wrote: Yes and No It is used to access the Specialist web interface. The IP info is set from the front console. We don't do this, but I believe you also use the ethernet interface to have the 3584 access a Master Console for dial home. See the topic Remote Support through a Master Console in the 3584 Introduction and Planning Guide. I think it says you need 2 ethernet interfaces to do this. Curiously, there are ethernet connections in each frame with drives. It's on a small box above the top most drive. Via the console you can set IP info on each frames ethernet port. You can then access the specialist from multiple IP addresses. We had a issue where the specialist became unresponsive. IBM said the library would need power cycled to free it up - which we couldn't do right then. They then suggested just moving the IP address to one of the other ethernet ports and move the lan cable to that port. This worked until we got a power cycle on the lib. I found this interesting - a hung specialist in the first frame and working specialist when accessed via other frames. You are correct that the ethernet connection is NOT used for library communications from the TSM server. That is handled via control paths defined on some number of drives. These show up as a separate device at the server. On AIX they show up as smcX devices. So library communications occurs across the fibrechannel san. rick -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Zoltan Forray Sent: Thursday, May 15, 2014 1:07 PM To: ADSM-L@VM.MARIST.EDU Subject: 3584 L23 IP interface Am I correct that the IP connection in the L23 frame is used purely for the Tape Library Specialist web interface, not like the 3494 where its IP connection was also used for management interface with the TSM servers? My network folks want to change/move the address. -- *Zoltan Forray* TSM Software Hardware Administrator BigBro / Hobbit / Xymon Administrator Virginia Commonwealth University UCC/Office of Technology Services zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html - 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. -- *Zoltan Forray* TSM Software Hardware Administrator BigBro / Hobbit / Xymon Administrator Virginia Commonwealth University UCC/Office of Technology Services zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html
