*"Could you monitor the TSM sessions and ensure that if one is still going
it it put on hold from 7:00 am to 11:00 pm during the work week."*
Yes, the above sentence is what I have been tasked with.
Some back-story
We have some non-local nodes that often backup terabytes of data, thereby
My first thought is to blame it on the network. If you follow that logic then
have the network boys (girls) lower the priority of the backup traffic during
that time. TSM uses well known ports, so it should not be an issue provided
your network links pass through something with this capability
There's a couple things that might help:
1. Assuming you're using server-side schedules (not something like cron
or Task Scheduler jobs on the clients), you can use QUERY EVENT to see
which client schedules are completed, which ones have failed, which ones
are still running, and which ones have y
In the past our networking folks have setup some kind of QOS on the
routers so that TSM traffic did not dominate. From what I remenber it was
a ugly process for them to do.
From: Zoltan Forray
To: ADSM-L@VM.MARIST.EDU
Date: 09/26/2012 10:46 AM
Subject:Stopping backups from
As far as killing those sessions goes, something like this might do the
job. Just put it in a script, cron it for 7am.
dsmadmc -id=id -pa=pa cancel session all
Heheh - talk about a big stick.
If you need it to cancel only certain nodes' sessions, you could try
something like this. Put the node
You would want to grep for Node in the q sess output so that you don't cancel
Admin sessions.
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Alex
Paschal
Sent: Wednesday, September 26, 2012 12:41 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-
All of this discussion is great but the bigger picture/issue is being
missed.
Yes, I would like to automate it but isn't really possible since it is
subjective to which one is eligible to be canceled.
If I (or an operator) figure out which to cancel and then cancel it, backup
session will automat
Can you lock the node before you cancel the sessions, and then unlock it
when the backup window starts in the evening?
-- Skylar Thompson (skyl...@u.washington.edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Med
Then probably a script running that looks for sessions, cancels the
sessions, then loops around a node lock cmd until it works.
if sessions running for node X at wrong time
cancel sessions
loop
lock node
did lock work?
yes - exit
no - repeat loop
From: Zoltan F
Suggest you create a script that first does a disa ses client then does a can
sess all. Then ena ses client some time later.
Regards,
Joerg Pohlmann
- Original Message -
From: "Zoltan Forray"
To: ADSM-L@VM.MARIST.EDU
Sent: Wednesday, September 26, 2012 3:45:18 PM
Subject: Re: [ADSM-L]
Out of curiosity, when you cancel the sessions manually, how do you stop
them from restarting?
On 9/26/2012 11:15 AM, Zoltan Forray wrote:
All of this discussion is great but the bigger picture/issue is being
missed.
Yes, I would like to automate it but isn't really possible since it is
subject
That is my whole point of my question/this discussion. So far the only
thing to do is what I already thought of (1-disable sessions, 2-cancel
session, 3-try to lock the node in-between retries...) but that in itself
is problematic since the node will "keep banging on the door" for a while
trying
To step a little bit outside of the TSM box, have you considered using
iptables (you¹re a Linux shop, right?) with a time rule on the TSM server to
block these troublesome hosts/subnets from connecting to TSM during
undesirable times. You can either be heavy-handed and stop any matching
packet afte
13 matches
Mail list logo
