TSM architecture
Hi All, My current environment is TSM 5.5.3, 1 library manager, 3 database servers. These are installed on a P550 AIX 5.3 system in separate LPAR's. We have 355 clients, 200 + are active. My current TSM databases are 100GB, 65-82% utilized. We are going to be doing a large business object installation which will add 30-50 new clients including multiple Oracle databases. Our proposal was to add an additional TSM server to handle the new requirements. We have a new architect that is not very familiar with TSM and his proposal is to stack TSM on another server that is running a different application. His argument is that TSM does most of it's work at night and the application (which one is TBD) does most of it's work during the day. From what I know, due to TSM's resource utilization, it should be on it's own hardware. Has anyone tried to do this and what were your results? I would love to get some good arguments to take back that would support our original position to install on separate hardware. Thanks to everyone for your ideas. Debbie Haberstroh TSM Server Administration
Re: TSM architecture
Immediate quick thought is that whilst much of the client backup activity for a TSM Server may well be overnight, most TSM Servers perform their not-insignificant essential housekeeping during the day which, depending upon the load of your TSM Server, may be a considerable drain on the system's I/O resources (disk tape migration, expiration, reclamation etc). /David Mc London, UK -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Haberstroh, Debbie (IT) Sent: 18 September 2009 16:36 To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM architecture Hi All, My current environment is TSM 5.5.3, 1 library manager, 3 database servers. These are installed on a P550 AIX 5.3 system in separate LPAR's. We have 355 clients, 200 + are active. My current TSM databases are 100GB, 65-82% utilized. We are going to be doing a large business object installation which will add 30-50 new clients including multiple Oracle databases. Our proposal was to add an additional TSM server to handle the new requirements. We have a new architect that is not very familiar with TSM and his proposal is to stack TSM on another server that is running a different application. His argument is that TSM does most of it's work at night and the application (which one is TBD) does most of it's work during the day. From what I know, due to TSM's resource utilization, it should be on it's own hardware. Has anyone tried to do this and what were your results? I would love to get some good arguments to take back that would support our original position to install on separate hardware. Thanks to everyone for your ideas. Debbie Haberstroh TSM Server Administration No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.102/2377 - Release Date: 09/18/09 07:49:00
Re: TSM architecture
Our TSM servers are busy around the clock. In fact, 6am-noon is some of the busiest with migrations going on. Haberstroh, Debbie (IT) habe...@voughtai To RCRAFT.COM ADSM-L@VM.MARIST.EDU Sent by: ADSM:cc Dist Stor Manager Subject ads...@vm.marist TSM architecture .EDU 09/18/2009 11:36 AM Please respond to ADSM: Dist Stor Manager ads...@vm.marist .EDU Hi All, My current environment is TSM 5.5.3, 1 library manager, 3 database servers. These are installed on a P550 AIX 5.3 system in separate LPAR's. We have 355 clients, 200 + are active. My current TSM databases are 100GB, 65-82% utilized. We are going to be doing a large business object installation which will add 30-50 new clients including multiple Oracle databases. Our proposal was to add an additional TSM server to handle the new requirements. We have a new architect that is not very familiar with TSM and his proposal is to stack TSM on another server that is running a different application. His argument is that TSM does most of it's work at night and the application (which one is TBD) does most of it's work during the day. From what I know, due to TSM's resource utilization, it should be on it's own hardware. Has anyone tried to do this and what were your results? I would love to get some good arguments to take back that would support our original position to install on separate hardware. Thanks to everyone for your ideas. Debbie Haberstroh TSM Server Administration - 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: TSM architecture
All of this depends on the amount of data involved, not the number of nodes. We have some TSM instances with 50 nodes that finish their backups by 3AM or so. and all the house-keeping finishes by 6AM. Regards, Shawn Shawn Drew Internet rrho...@firstenergycorp.com Sent by: ADSM-L@VM.MARIST.EDU 09/18/2009 11:49 AM Please respond to ADSM-L@VM.MARIST.EDU To ADSM-L cc Subject Re: [ADSM-L] TSM architecture Our TSM servers are busy around the clock. In fact, 6am-noon is some of the busiest with migrations going on. Haberstroh, Debbie (IT) habe...@voughtai To RCRAFT.COM ADSM-L@VM.MARIST.EDU Sent by: ADSM:cc Dist Stor Manager Subject ads...@vm.marist TSM architecture .EDU 09/18/2009 11:36 AM Please respond to ADSM: Dist Stor Manager ads...@vm.marist .EDU Hi All, My current environment is TSM 5.5.3, 1 library manager, 3 database servers. These are installed on a P550 AIX 5.3 system in separate LPAR's. We have 355 clients, 200 + are active. My current TSM databases are 100GB, 65-82% utilized. We are going to be doing a large business object installation which will add 30-50 new clients including multiple Oracle databases. Our proposal was to add an additional TSM server to handle the new requirements. We have a new architect that is not very familiar with TSM and his proposal is to stack TSM on another server that is running a different application. His argument is that TSM does most of it's work at night and the application (which one is TBD) does most of it's work during the day. From what I know, due to TSM's resource utilization, it should be on it's own hardware. Has anyone tried to do this and what were your results? I would love to get some good arguments to take back that would support our original position to install on separate hardware. Thanks to everyone for your ideas. Debbie Haberstroh TSM Server Administration - 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. This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. Please note that certain functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.
Re: TSM architecture
FWIW, When you upgrade to 6.1, your TSM server will be running Websphere (for the ISC) and DB2, plus TSM. I think your current way of stacking via LPARs is a better choice. W On Fri, Sep 18, 2009 at 12:01 PM, Shawn Drew shawn.d...@americas.bnpparibas.com wrote: All of this depends on the amount of data involved, not the number of nodes. We have some TSM instances with 50 nodes that finish their backups by 3AM or so. and all the house-keeping finishes by 6AM. Regards, Shawn Shawn Drew Internet rrho...@firstenergycorp.com Sent by: ADSM-L@VM.MARIST.EDU 09/18/2009 11:49 AM Please respond to ADSM-L@VM.MARIST.EDU To ADSM-L cc Subject Re: [ADSM-L] TSM architecture Our TSM servers are busy around the clock. In fact, 6am-noon is some of the busiest with migrations going on. Haberstroh, Debbie (IT) habe...@voughtai To RCRAFT.COM ADSM-L@VM.MARIST.EDU Sent by: ADSM:cc Dist Stor Manager Subject ads...@vm.marist TSM architecture .EDU 09/18/2009 11:36 AM Please respond to ADSM: Dist Stor Manager ads...@vm.marist .EDU Hi All, My current environment is TSM 5.5.3, 1 library manager, 3 database servers. These are installed on a P550 AIX 5.3 system in separate LPAR's. We have 355 clients, 200 + are active. My current TSM databases are 100GB, 65-82% utilized. We are going to be doing a large business object installation which will add 30-50 new clients including multiple Oracle databases. Our proposal was to add an additional TSM server to handle the new requirements. We have a new architect that is not very familiar with TSM and his proposal is to stack TSM on another server that is running a different application. His argument is that TSM does most of it's work at night and the application (which one is TBD) does most of it's work during the day. From what I know, due to TSM's resource utilization, it should be on it's own hardware. Has anyone tried to do this and what were your results? I would love to get some good arguments to take back that would support our original position to install on separate hardware. Thanks to everyone for your ideas. Debbie Haberstroh TSM Server Administration - 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. This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. Please note that certain functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.
Re: TSM architecture
Also, please consider system maintenance. TSM is usually maintained during the day when backups are not running. Ask you newby architect if you can take this system down during the day for OS maintenance/problems/etc. ROBERT R. PRICE TSM Administrator CSC Phone: 412-342-1947 Fax: 412-342-1755 rpric...@csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. Wanda Prather wprat...@jasi.co M To Sent by: ADSM: ADSM-L@VM.MARIST.EDU Dist Stor cc Manager ads...@vm.marist Subject .EDU Re: TSM architecture 09/18/2009 12:05 PM Please respond to ADSM: Dist Stor Manager ads...@vm.marist .EDU FWIW, When you upgrade to 6.1, your TSM server will be running Websphere (for the ISC) and DB2, plus TSM. I think your current way of stacking via LPARs is a better choice. W On Fri, Sep 18, 2009 at 12:01 PM, Shawn Drew shawn.d...@americas.bnpparibas.com wrote: All of this depends on the amount of data involved, not the number of nodes. We have some TSM instances with 50 nodes that finish their backups by 3AM or so. and all the house-keeping finishes by 6AM. Regards, Shawn Shawn Drew Internet rrho...@firstenergycorp.com Sent by: ADSM-L@VM.MARIST.EDU 09/18/2009 11:49 AM Please respond to ADSM-L@VM.MARIST.EDU To ADSM-L cc Subject Re: [ADSM-L] TSM architecture Our TSM servers are busy around the clock. In fact, 6am-noon is some of the busiest with migrations going on. Haberstroh, Debbie (IT) habe...@voughtai To RCRAFT.COM ADSM-L@VM.MARIST.EDU Sent by: ADSM:cc Dist Stor Manager Subject ads...@vm.marist TSM architecture .EDU 09/18/2009 11:36 AM Please respond to ADSM: Dist Stor Manager ads...@vm.marist .EDU Hi All, My current environment is TSM 5.5.3, 1 library manager, 3 database servers. These are installed on a P550 AIX 5.3 system in separate LPAR's. We have 355 clients, 200 + are active. My current TSM databases are 100GB, 65-82% utilized. We are going to be doing a large business object installation which will add 30-50 new clients including multiple Oracle databases. Our proposal was to add an additional TSM server to handle the new requirements. We have a new architect that is not very familiar with TSM and his proposal is to stack TSM on another server that is running a different application. His argument is that TSM does most of it's work at night and the application (which one is TBD) does most of it's work during the day. From what I know, due to TSM's resource utilization, it should be on it's own hardware. Has anyone tried to do this and what were your results? I would love to get some good arguments to take back that would support our original position to install on separate hardware. Thanks to everyone for your ideas. Debbie Haberstroh TSM Server Administration - 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. This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall
Re: TSM architecture
On 18/09, Haberstroh, Debbie (IT) wrote: Hi All, My current environment is TSM 5.5.3, 1 library manager, 3 database servers. These are installed on a P550 AIX 5.3 system in separate LPAR's. We have 355 clients, 200 + are active. My current TSM databases are 100GB, 65-82% utilized. We are going to be doing a large business object installation which will add 30-50 new clients including multiple Oracle databases. Our proposal was to add an additional TSM server to handle the new requirements. We have a new architect that is not very familiar with TSM and his proposal is to stack TSM on another server that is running a different application. His argument is that TSM does most of it's work at night and the application (which one is TBD) does most of it's work during the day. From what I know, due to TSM's resource utilization, it should be on it's own hardware. Has anyone tried to do this and what were your results? I would love to get some good arguments to take back that would support our original position to install on separate hardware. Thanks to everyone for your ideas. Debbie Haberstroh TSM Server Administration For the love of god, please dont. You are going to kill that other application. TSM opposed to other backup solutions does most of it's work during daytime which will include heavy CPU and I/O usage. Something else to keep in mind is also that separating backup and DR machines from the normal production environment is a good thing since you will have fewer common point of failures for both, ie less chance of losing or having trouble with both at the same time. -km
Re: TSM architecture
We technicians tend to think about this issue in terms of processing capacity. Others in the organization may consider it in different terms, and indeed perhaps should be reviewed on that larger scale. If I were a technology-savvy expert in your Security Department and was made aware of this question of placement, I would immediately think that the corporation's data gravitates toward this central data preservation point, and that the application software or the administrators who log on to that system to manage their application could bend toward the dark side to gain control of one or more tape drives to gain surreptitious access to the data, in a physical manner or - even more conveniently - if there were a TSM client running co- resident with the TSM server, simply recall it. This is a traditionally compelling reason for isolating servers performing distinctly different tasks. One wonders how aware your new architect is of more global considerations. Richard Sims
Re: TSM architecture
Thanks to all, you have given me some good arguments. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu]on Behalf Of Richard Sims Sent: Friday, September 18, 2009 1:43 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM architecture We technicians tend to think about this issue in terms of processing capacity. Others in the organization may consider it in different terms, and indeed perhaps should be reviewed on that larger scale. If I were a technology-savvy expert in your Security Department and was made aware of this question of placement, I would immediately think that the corporation's data gravitates toward this central data preservation point, and that the application software or the administrators who log on to that system to manage their application could bend toward the dark side to gain control of one or more tape drives to gain surreptitious access to the data, in a physical manner or - even more conveniently - if there were a TSM client running co- resident with the TSM server, simply recall it. This is a traditionally compelling reason for isolating servers performing distinctly different tasks. One wonders how aware your new architect is of more global considerations. Richard Sims
