Hi,
In version TSM Server 6.3 there was improvements in relation to Virtual
Libraries, I am not sure if this solves the problem. Anyway if you open a RFE I
will add my vote and I hope new releases TSM Server will have the possibility
to choose the pool to restore the data. I have seen this behavior when we use
VTL and Physical Tape Libraries, the restores has been done from PTL instead of
VTL due to the number of the tape volumes.
Regards,
________________________________
De: "Hart, Charles A" <charles_hart AT UHC DOT COM>
Para: ADSM-L AT VM.MARIST DOT EDU
Enviado: Martes 8 de enero de 2013 21:01
Asunto: Re: Battles with TSM for VE
Interesting ... we have experienced a very similar issue where our DB
(Oracle etc) restores were coming off the Copy pool. We opened a PMR
and found out this was due to the way TSM was designed to take the least
path of resistance for restores meaning if there are less copy pools
volumes required for a restore than primary volumes TSM will choose the
pool with less volumes. This is s a real pain with Virtual tape as we
make those smaller by design unlike physical tapes at 1+TB. IBM did do
a "fix" with a option to put in the server option file but it didn't
work for us. So if we have a critical restore and we see this happen
we'll mark the offsite tapes as unavailable.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Neil Schofield
Sent: Tuesday, January 08, 2013 1:24 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Battles with TSM for VE
We've been using TSM for VE in production for about 6 months now and
although it generally works well, there have been a number of minor
issues which remain unresolved. However one problem stands out above the
others and despite extensive discussions with IBM support, we've been
unable to achieve a resolution. I just wanted to run it past the ADSM-L
community to gain their perspective.
There are about 500 VMs (predominantly Windows Server) on ESX 4.1 that
we back up on a nightly basis, with each VM getting one full backup a
week and incrementals (using change block tracking) on the other
nights.
Consider the following scenario:
- A backup proxy server accessing the ESX disk LUNs over a SAN running
TSM for VE and with LAN-free (Storage Agent) access to tape library A
- A dedicated primary disk storage pool (VMCTLDISK) on the TSM server
for storing the CTL data
- A dedicated primary tape storage pool (VMDATATAPE) using a device
class in library A for the VM backup data
- A dedicated copy tape storage pool (VMCTLTAPE) using a device class in
library A to provide a backup for the CTL data on disk
- VMDATATAPE is collocated by filespace so each VM's backup data is on
the smallest number of tapes
- VMCTLTAPE contains only one or two tape volumes to hold the copy of
all the CTL data for all VMs (no collocation)
- A daily admin schedule backs up CTL data in the primary storage pool
to the copy storage pool after the backup window for the TSM for VE
clients
Now a full backup of a VM works fine. The backup proxy server sends CTL
data over the LAN to disk on the TSM server and VM backup data over the
SAN to library A.
Incremental VM backups work less well. Under the covers, incremental
backups involve a significant amount of restore processing by the client
as it restores previously backed up CTL data. In the scenario above, we
naively expected the process for restoring the CTL data to be the
reverse of the backup process - ie the CTL data would be accessed over
the LAN from the primary disk storage pool on the TSM servers.
However it quickly became evident that the TSM for VE client was
favouring the far slower tape volume in the copy storage pool when it
came to restoring CTL data for every incremental backup (presumably on
the basis that the tape volume could be mounted LAN-free while the disk
volume couldn't). For the relatively small amount of data involved when
restoring the CTL files (compared to the size of the backup data), the
overhead of mounting the tape was significant. Even worse though, those
one or two copy storage pool volumes became a massive source of
contention when running multiple concurrent incremental VM backups.
I can't find an easy way of inhibiting LAN-free access to the copy
storage pool volumes by the backup proxy server without affecting it's
ability to store (and restore) the VM backup data using LAN-free.
When we discovered this behaviour the only relief I could find was to
put in place a spectacularly ugly work-around which involved running for
99% of the day with the volumes in the copy storage pool holding the CTL
data updated to have an access mode of unavailable. This forces the TSM
for VE client to restore the CTL files from the primary disk storage
pool during incremental VM backups. The script which performs the
storage pool backup first updates the copy storage pool volumes to
read/write and then changes them back to unavailable upon completion.
This doesn't sit well with me because volumes which aren't read/write
typically indicate trouble and it means mods to our monitoring to ignore
these volumes.
At the same time as we introduced this, we logged a PMR with IBM. This
has now been relegated to the status of a documentation APAR to describe
the behaviour, so it looks like the kludge we implemented could become
permanent.
Am I being unreasonable in thinking the way IBM have implemented this is
flawed?
For info, TSM for VE is v6.2 and TSM Server is v5.5.6
Regards
Neil Schofield
Technical Leader
Yorkshire Water
----------------------------------------
Spotted a leak?
If you spot a leak please report it immediately. Call us on 0800 57 3553
or go to http://www.yorkshirewater.com/leaks
Get a free water saving pack
Don't forget to request your free water and energy saving pack, it could
save you money on your utility bills and help you conserve water.
http://www.yorkshirewater.com/savewater
The information in this e-mail is confidential and may also be legally
privileged. The contents are intended for recipient only and are subject
to the legal notice available at http://www.keldagroup.com/email.htm
Yorkshire Water Services Limited
Registered Office Western House, Halifax Road, Bradford, BD6 2SZ
Registered in England and Wales No 2366682
This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
|
