Hi Mike and Marc
Thanks for your responses.
Order of presentation of VMs seems to be dependent on the order that vCenter
provides them to the TSM for VE query. It is certainly not alphabetical or any
other obvious ordering (to me at least) and it can change over time. One
problem VM was starting at the beginning of the schedule and suddenly moved to
late in the order with no changes that we could see.
We are running multiple data movers based on class of VM. There are two
separate vCenters and each of those have prod and non-prod backup streams
organized by VMWare cluster with a datamover for each. Leaving out unnecessary
detail, there is one VBS server for each vCenter/stream and one datamover on
each VBS with its own storage agent. Data transport is SAN. All this is
controlled through a single TSM Server.
VMMAXSESSIONS is set to 10 in prod... we have been experimenting in non-prod
with making this higher, but so far have found that more allowed sessions does
not necessarily mean more active sessions: the most we have had in non-prod was
16 active when VMAXSESSIONS was 20, and then only briefly. More sessions also
seem to push out the elapsed time: 10 to 20 pushed out the end of backup from
8 to 10 hours.
For non-prod we have therefore now settled at 12 sessions and have started to
play with VMLIMITPERDATASTORE and VMLIMITPERHOST which have both been 2 until
now.
Yes we have considered multiple datamovers and schedules. As we control things
by editing dsm.sys that gets messy very quickly. The level of TSM for VE code
we are on means that the automatic exclusion of PRDMs, VMDKs>2TB etc does not
work so we have to exclude these individually.
I am really tempted to, but the effort to script an automatic generation
process for the dsm.sys stanzas is probably not warranted. There are also
issues with having to generate using powershell on Windows and then updating
control files on Linux and security implications in our environment or having
to teach myself python for this one task (and getting python3 installed and the
prereqs for the VMware API etc etc etc).
Looks like I may be stuck until we can at least get a code upgrade. The
Spectre/Meltdown security issue will likely force a VMWare upgrade, at which
point we can move off our current TSM for VE level and some of the pain will go
away, however if anyone has more information on how the TSM for VE VM
selection algorithm works and how it can be influenced, I'd be interested to
hear it.
Cheers
Steve
Steven Harris
TSM Admin/Consultant
Canberra Australia
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Ryder, Michael S
Sent: Saturday, 10 February 2018 3:07 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Influencing order of VM backup.
You can take more control by setting up specific schedules to backup some VMs
first. You might use VM folders to control that as well.
Do you let VMs backup in parallel with "VMMAXParallel" ? It defaults to 1...
You can also have multiple jobs running simultaneously. It's not clear to me,
are you using the "IBM Spectrum Protect for Virtual Environments: Data
Protection for VMware"? If so, in addition you could be running multiple jobs
on multiple datamovers simultaneously.
Enabling #>1 on VMMAXParallel and multiple datamovers helped us to drastically
reduce our backup windows.
Best regards,
Mike
On Fri, Feb 9, 2018 at 6:08 AM, Marc Lanteigne <marclanteigne AT ca.ibm DOT com>
wrote:
> Hi,
>
> You could configure a new DataMover to handle that VM.
>
> In the preview, is the order alphabetical? If so, can you rename the VM?
>
> Marc...
>
> Sent from my iPhone using IBM Verse
>
> On Feb 8, 2018, 11:17:20 PM, steven.harris AT BTFINANCIALGROUP DOT COM wrote:
>
> From: steven.harris AT BTFINANCIALGROUP DOT COM
> To: ADSM-L AT VM.MARIST DOT EDU
> Cc:
> Date: Feb 8, 2018, 11:17:20 PM
> Subject: [ADSM-L] Influencing order of VM backup.
>
>
> Hi All
> Thanks for the input on my recent query about 7 Year VM backups.
> I'll let you know when I decide something.
> Moving on..
> TSM Server 7.1.1.300 AIX, Datamovers and Storage Agents on Redhat,
> writing to Protectier VTL, TSM for VE 7.1.1/2 hybrid.
> We can't use the VMware plugin because of separation of duties
> concerns, so we edit the DOMAIN.VMFULL lines in the dsm.sys stanzas.
> VMs have a range of different sizes that all back up on the same
> schedule and we'd prefer not to split this up. The execution order of
> the VM backups is determined by TSM for VE, somehow, and can be seen when a
> backup vm -preview is run.
> There are some large VMs that take quite a while to back up, but
> unfortunately run late in the execution order, so we overrun our
> backup window.
> Changing the order of the VMs in the DOMAIN.VMFULL statement does
> not influence execution order. Is there any way to make the big ones run
> first?
> Thanks
> Steve
> Steven Harris
> TSM Admin/Consultant
> Canberra Australia
This message and any attachment is confidential and may be privileged or
otherwise protected from disclosure. You should immediately delete the message
if you are not the intended recipient. If you have received this email by
mistake please delete it from your system; you should not copy the message or
disclose its content to anyone.
This electronic communication may contain general financial product advice but
should not be relied upon or construed as a recommendation of any financial
product. The information has been prepared without taking into account your
objectives, financial situation or needs. You should consider the Product
Disclosure Statement relating to the financial product and consult your
financial adviser before making a decision about whether to acquire, hold or
dispose of a financial product.
For further details on the financial product please go to http://www.bt.com.au
Past performance is not a reliable indicator of future performance.
|
