TSM for VE I/O performance
Hi, In this newly-setup TSM for VE 6.3 environment all building blocks (vCenter, data mover, ESX hosts, VM guests and TSM server) have Gigabit Ethernet explicitly set to 1000 full duplex. But VM full backup or restore operations from vCenter plug-in send data up to 100Mbs. LANfree has not been configured on the data mover node, so TCP/IP performance is important in this phase. - TSM server is v6.2 on AIX 6.1 - All other operating systems are Windows 2008 R2 Any comment will be appreciated. Regards, Mehdi
Firewall problem
Hi Everyone, We have six TSM v5.5.5 instances (on AIX) named TSM1 to TSM6. All six instances handle backups for nodes that are behind firewalls, although only five work. The six instances are on separate servers, so each has it's own IP address and firewall rules. The firewall rules are all identical so we can put any node on any TSM server. We cannot get firewall backups to work to our TSM5 instance. Since it was brought up a couple years ago we have fought to get firewall backups to work but have failed. Nodes out behind a firewall are able to contact the TSM server, a sessions is established, then it is immediately disconnected. This repeats over and over as the node retries. You can sometimes see 50 or more sessions - all hung - for a firewalled node. We've done everything we can think of: check/double/triple checked FW rules, talked with IBM support, run traces for them, check AIX setup, checked TSM5 setup, compared anything related to TSM5 to the other working instances. If we move the node to one of our other TSM instances it worked just fine!! In all, we firgured this HAD to be a firewall setup problem of some kind. This past weekend we move TSM5 (and TSM6 also) to new servers/lpars. The new servers had to have new IP addresses and run a newer AIX v6. We've done this upgrade for the other TSM servers already. With new IP addresses we had to create new FW rules. We figured that with a whole new setup FW backups would have to work - we're kicking it real hard NOPE - it didn't help! The only thing that didn't change in this server swing was the actual TSM instance. It seems our FW backup problem on this one instance HAS to be in TSM itself. Question: Is there any setting in TSM that could explain failing backups for firewalled servers? 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.
Re: Firewall problem
Richard, Just a shot in the dark; but do by chance employ any type of intrusion prevention? By design it will allow the connection thru the firewall to the target IP, then assesses the traffic for suspicious behavior. Here I had the exact situation, and seeing as the clients would connect to the TSM Server I quickly dismissed the firewall. The clients would start a session and within seconds disconnect. Finally, at my wits end I contacted our network team, a rule was added to the intrusion prevention system the issue was resolved. ~Rick -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Richard Rhodes Sent: Monday, February 06, 2012 6:47 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Firewall problem Hi Everyone, We have six TSM v5.5.5 instances (on AIX) named TSM1 to TSM6. All six instances handle backups for nodes that are behind firewalls, although only five work. The six instances are on separate servers, so each has it's own IP address and firewall rules. The firewall rules are all identical so we can put any node on any TSM server. We cannot get firewall backups to work to our TSM5 instance. Since it was brought up a couple years ago we have fought to get firewall backups to work but have failed. Nodes out behind a firewall are able to contact the TSM server, a sessions is established, then it is immediately disconnected. This repeats over and over as the node retries. You can sometimes see 50 or more sessions - all hung - for a firewalled node. We've done everything we can think of: check/double/triple checked FW rules, talked with IBM support, run traces for them, check AIX setup, checked TSM5 setup, compared anything related to TSM5 to the other working instances. If we move the node to one of our other TSM instances it worked just fine!! In all, we firgured this HAD to be a firewall setup problem of some kind. This past weekend we move TSM5 (and TSM6 also) to new servers/lpars. The new servers had to have new IP addresses and run a newer AIX v6. We've done this upgrade for the other TSM servers already. With new IP addresses we had to create new FW rules. We figured that with a whole new setup FW backups would have to work - we're kicking it real hard NOPE - it didn't help! The only thing that didn't change in this server swing was the actual TSM instance. It seems our FW backup problem on this one instance HAS to be in TSM itself. Question: Is there any setting in TSM that could explain failing backups for firewalled servers? 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.
Re: Firewall problem
-Richard Rhodes wrote: - Question: Is there any setting in TSM that could explain failing backups for firewalled servers? The 'register node' and 'update node' commands have a 'sessioninitiation' parameter. The default value, 'clientorserver', would be needed for the backup arrangement you describe for clients outside the firewall. The other possible value, 'serveronly', would cause these backups to fail, possibly with the symptoms you describe. Thomas Denier
Re: Firewall problem
Maybe this will help. We have a firewall rule that allows all of the DMZ servers to contact the TSM servers and the TSM servers are allowed in on specific ports. In the opt files we have these lines: httpport webports All of our servers run the CAD. Andy Huebner -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Richard Rhodes Sent: Monday, February 06, 2012 5:47 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Firewall problem Hi Everyone, We have six TSM v5.5.5 instances (on AIX) named TSM1 to TSM6. All six instances handle backups for nodes that are behind firewalls, although only five work. The six instances are on separate servers, so each has it's own IP address and firewall rules. The firewall rules are all identical so we can put any node on any TSM server. We cannot get firewall backups to work to our TSM5 instance. Since it was brought up a couple years ago we have fought to get firewall backups to work but have failed. Nodes out behind a firewall are able to contact the TSM server, a sessions is established, then it is immediately disconnected. This repeats over and over as the node retries. You can sometimes see 50 or more sessions - all hung - for a firewalled node. We've done everything we can think of: check/double/triple checked FW rules, talked with IBM support, run traces for them, check AIX setup, checked TSM5 setup, compared anything related to TSM5 to the other working instances. If we move the node to one of our other TSM instances it worked just fine!! In all, we firgured this HAD to be a firewall setup problem of some kind. This past weekend we move TSM5 (and TSM6 also) to new servers/lpars. The new servers had to have new IP addresses and run a newer AIX v6. We've done this upgrade for the other TSM servers already. With new IP addresses we had to create new FW rules. We figured that with a whole new setup FW backups would have to work - we're kicking it real hard NOPE - it didn't help! The only thing that didn't change in this server swing was the actual TSM instance. It seems our FW backup problem on this one instance HAS to be in TSM itself. Question: Is there any setting in TSM that could explain failing backups for firewalled servers? 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. This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.
Re: Firewall problem
compare the q opt output from an instance that works with the instance that doesn't. There might be a conservative timeout setting. Other long-shot things to compare are q node (NODENAME) f=d for the specific nodes that are having trouble and q stat Regards, Shawn Shawn Drew Internet rrho...@firstenergycorp.com Sent by: ADSM-L@VM.MARIST.EDU 02/06/2012 06:46 AM Please respond to ADSM-L@VM.MARIST.EDU To ADSM-L cc Subject [ADSM-L] Firewall problem Hi Everyone, We have six TSM v5.5.5 instances (on AIX) named TSM1 to TSM6. All six instances handle backups for nodes that are behind firewalls, although only five work. The six instances are on separate servers, so each has it's own IP address and firewall rules. The firewall rules are all identical so we can put any node on any TSM server. We cannot get firewall backups to work to our TSM5 instance. Since it was brought up a couple years ago we have fought to get firewall backups to work but have failed. Nodes out behind a firewall are able to contact the TSM server, a sessions is established, then it is immediately disconnected. This repeats over and over as the node retries. You can sometimes see 50 or more sessions - all hung - for a firewalled node. We've done everything we can think of: check/double/triple checked FW rules, talked with IBM support, run traces for them, check AIX setup, checked TSM5 setup, compared anything related to TSM5 to the other working instances. If we move the node to one of our other TSM instances it worked just fine!! In all, we firgured this HAD to be a firewall setup problem of some kind. This past weekend we move TSM5 (and TSM6 also) to new servers/lpars. The new servers had to have new IP addresses and run a newer AIX v6. We've done this upgrade for the other TSM servers already. With new IP addresses we had to create new FW rules. We figured that with a whole new setup FW backups would have to work - we're kicking it real hard NOPE - it didn't help! The only thing that didn't change in this server swing was the actual TSM instance. It seems our FW backup problem on this one instance HAS to be in TSM itself. Question: Is there any setting in TSM that could explain failing backups for firewalled servers? 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. 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: Firewall problem
I've had to use schedmode polling to get some firewall backups to run. Jim Schneider -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@vm.marist.edu] On Behalf Of Shawn Drew Sent: Monday, February 06, 2012 11:35 AM To: ADSM-L@vm.marist.edu Subject: Re: [ADSM-L] Firewall problem compare the q opt output from an instance that works with the instance that doesn't. There might be a conservative timeout setting. Other long-shot things to compare are q node (NODENAME) f=d for the specific nodes that are having trouble and q stat Regards, Shawn Shawn Drew Internet rrho...@firstenergycorp.com Sent by: ADSM-L@VM.MARIST.EDU 02/06/2012 06:46 AM Please respond to ADSM-L@VM.MARIST.EDU To ADSM-L cc Subject [ADSM-L] Firewall problem Hi Everyone, We have six TSM v5.5.5 instances (on AIX) named TSM1 to TSM6. All six instances handle backups for nodes that are behind firewalls, although only five work. The six instances are on separate servers, so each has it's own IP address and firewall rules. The firewall rules are all identical so we can put any node on any TSM server. We cannot get firewall backups to work to our TSM5 instance. Since it was brought up a couple years ago we have fought to get firewall backups to work but have failed. Nodes out behind a firewall are able to contact the TSM server, a sessions is established, then it is immediately disconnected. This repeats over and over as the node retries. You can sometimes see 50 or more sessions - all hung - for a firewalled node. We've done everything we can think of: check/double/triple checked FW rules, talked with IBM support, run traces for them, check AIX setup, checked TSM5 setup, compared anything related to TSM5 to the other working instances. If we move the node to one of our other TSM instances it worked just fine!! In all, we firgured this HAD to be a firewall setup problem of some kind. This past weekend we move TSM5 (and TSM6 also) to new servers/lpars. The new servers had to have new IP addresses and run a newer AIX v6. We've done this upgrade for the other TSM servers already. With new IP addresses we had to create new FW rules. We figured that with a whole new setup FW backups would have to work - we're kicking it real hard NOPE - it didn't help! The only thing that didn't change in this server swing was the actual TSM instance. It seems our FW backup problem on this one instance HAS to be in TSM itself. Question: Is there any setting in TSM that could explain failing backups for firewalled servers? 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. 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: Isilon backup
On 02/02/2012 04:12 PM, Huebner,Andy,FORT WORTH,IT wrote: Anyone backup an Isilon array? Using 3592 tape drives? The sales guys say it is just NDMP. I am looking for just basic information (good, bad, Oh Smurf!). One may be in our future. We're contemplating such a device, too. In our plans so far, we're thinking 'replicate and snap' for DR purposes. Longer term archives aren't currently under consideration, but pleasantly they don't have the same frequency issues. If it takes me a week to do an incr once a year, I'm less concerned. - Allen S. Rout
Re: Firewall problem
You doubtless checked the DNSLOOKUP option, and set it the same way on all your servers. Is it possible that the DNS for the problem client is also the only DNS that is also behind the firewall? - Margaret -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Richard Rhodes Sent: Monday, February 06, 2012 3:47 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Firewall problem Hi Everyone, We have six TSM v5.5.5 instances (on AIX) named TSM1 to TSM6. All six instances handle backups for nodes that are behind firewalls, although only five work. The six instances are on separate servers, so each has it's own IP address and firewall rules. The firewall rules are all identical so we can put any node on any TSM server. We cannot get firewall backups to work to our TSM5 instance. Since it was brought up a couple years ago we have fought to get firewall backups to work but have failed. Nodes out behind a firewall are able to contact the TSM server, a sessions is established, then it is immediately disconnected. This repeats over and over as the node retries. You can sometimes see 50 or more sessions - all hung - for a firewalled node. We've done everything we can think of: check/double/triple checked FW rules, talked with IBM support, run traces for them, check AIX setup, checked TSM5 setup, compared anything related to TSM5 to the other working instances. If we move the node to one of our other TSM instances it worked just fine!! In all, we firgured this HAD to be a firewall setup problem of some kind. This past weekend we move TSM5 (and TSM6 also) to new servers/lpars. The new servers had to have new IP addresses and run a newer AIX v6. We've done this upgrade for the other TSM servers already. With new IP addresses we had to create new FW rules. We figured that with a whole new setup FW backups would have to work - we're kicking it real hard NOPE - it didn't help! The only thing that didn't change in this server swing was the actual TSM instance. It seems our FW backup problem on this one instance HAS to be in TSM itself. Question: Is there any setting in TSM that could explain failing backups for firewalled servers? 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.
Excessive number of filling tapes...
So, I've got an offsite machine which exists to accept remote virtual volumes. For years, now, the filling volumes have behaved in a way I thought I understood. The tapes are collocated by node. There are about 20 server nodes which write to it. My number of filling volumes has rattled around 50-60 for years; I interpret this as basic node collocation, plus occasional additional tapes allocated when more streams than tapes are writing at a time. So some of the servers have just one filling tape, some have two, and the busiest of them might have as many as 6 (my drive count). Add a little error for occasionally reclaiming a still-filling volume, and that gives me a very clear sense of what's going on, and I can just monitor scratch count. Right now, I have 190 filling volumes. None of them has data from more than one client. I have some volumes RO and filling, and am looking into that, but it's 20 of them, not enough to account for this backlog. Those are also the only vols in error state. I've been rooting through my actlogs looking for warnings or errors, but I've never had occasion to introspect about how TSM picks which tape to call for, when it's going to write. It's always Just Worked. Does this ring any bells for anyone?Any dumb questions I've forgotten to ask? I don't hold much hope for getting a good experience out of IBM support on this. - Allen S.Rout
Re: Excessive number of filling tapes...
Check out the Filling item: http://people.bu.edu/rbs/ADSM.QuickFacts Regards, Shawn Shawn Drew Internet a...@ufl.edu Sent by: ADSM-L@VM.MARIST.EDU 02/06/2012 04:17 PM Please respond to ADSM-L@VM.MARIST.EDU To ADSM-L cc Subject [ADSM-L] Excessive number of filling tapes... So, I've got an offsite machine which exists to accept remote virtual volumes. For years, now, the filling volumes have behaved in a way I thought I understood. The tapes are collocated by node. There are about 20 server nodes which write to it. My number of filling volumes has rattled around 50-60 for years; I interpret this as basic node collocation, plus occasional additional tapes allocated when more streams than tapes are writing at a time. So some of the servers have just one filling tape, some have two, and the busiest of them might have as many as 6 (my drive count). Add a little error for occasionally reclaiming a still-filling volume, and that gives me a very clear sense of what's going on, and I can just monitor scratch count. Right now, I have 190 filling volumes. None of them has data from more than one client. I have some volumes RO and filling, and am looking into that, but it's 20 of them, not enough to account for this backlog. Those are also the only vols in error state. I've been rooting through my actlogs looking for warnings or errors, but I've never had occasion to introspect about how TSM picks which tape to call for, when it's going to write. It's always Just Worked. Does this ring any bells for anyone?Any dumb questions I've forgotten to ask? I don't hold much hope for getting a good experience out of IBM support on this. - Allen S.Rout 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: Excessive number of filling tapes...
Re your line None of them has data from more than one client Has collocation been turned on by accident? Thanks Regards Paul So, I've got an offsite machine which exists to accept remote virtual volumes. For years, now, the filling volumes have behaved in a way I thought I understood. The tapes are collocated by node. There are about 20 server nodes which write to it. My number of filling volumes has rattled around 50-60 for years; I interpret this as basic node collocation, plus occasional additional tapes allocated when more streams than tapes are writing at a time. So some of the servers have just one filling tape, some have two, and the busiest of them might have as many as 6 (my drive count). Add a little error for occasionally reclaiming a still-filling volume, and that gives me a very clear sense of what's going on, and I can just monitor scratch count. Right now, I have 190 filling volumes. None of them has data from more than one client. I have some volumes RO and filling, and am looking into that, but it's 20 of them, not enough to account for this backlog. Those are also the only vols in error state. I've been rooting through my actlogs looking for warnings or errors, but I've never had occasion to introspect about how TSM picks which tape to call for, when it's going to write. It's always Just Worked. Does this ring any bells for anyone?Any dumb questions I've forgotten to ask? I don't hold much hope for getting a good experience out of IBM support on this. - Allen S.Rout ANL - Regional Carrier of the Year 2011 - Containerisation International ANL DISCLAIMER This e-mail and any file attached is confidential, and intended solely to the named add ressees. Any unauthorised dissemination or use is strictly prohibited. If you received this e-mail in error, please immediately notify the sender by return e-mail from your s ystem. Please do not copy, use or make reference to it for any purpose, or disclose its contents to any person.
Re: Excessive number of filling tapes...
Allen, We opened a PMR that sounds like it might match your observations. We have way too many volumes in what I call barely filling status, with no explanation of how they got that way. APAR IC76192 was opened for this: http://www-01.ibm.com/support/docview.wss?uid=swg1IC76192 ..Paul At 04:17 PM 2/6/2012, Allen S. Rout wrote: So, I've got an offsite machine which exists to accept remote virtual volumes. For years, now, the filling volumes have behaved in a way I thought I understood. The tapes are collocated by node. There are about 20 server nodes which write to it. My number of filling volumes has rattled around 50-60 for years; I interpret this as basic node collocation, plus occasional additional tapes allocated when more streams than tapes are writing at a time. So some of the servers have just one filling tape, some have two, and the busiest of them might have as many as 6 (my drive count). Add a little error for occasionally reclaiming a still-filling volume, and that gives me a very clear sense of what's going on, and I can just monitor scratch count. Right now, I have 190 filling volumes. None of them has data from more than one client. I have some volumes RO and filling, and am looking into that, but it's 20 of them, not enough to account for this backlog. Those are also the only vols in error state. I've been rooting through my actlogs looking for warnings or errors, but I've never had occasion to introspect about how TSM picks which tape to call for, when it's going to write. It's always Just Worked. Does this ring any bells for anyone?Any dumb questions I've forgotten to ask? I don't hold much hope for getting a good experience out of IBM support on this. - Allen S.Rout -- Paul ZarnowskiPh: 607-255-4757 Manager, Storage Services Fx: 607-255-8521 719 Rhodes Hall, Ithaca, NY 14853-3801Em: p...@cornell.edu
