Here is the long version of my question. I hope it's clear.
"Recommendations for Scheduling with TSM for VE" in the TSMVE wiki recommends
"including the ESX server that is processed in the name" of options files, and
by examples, the backup instance names too. We did that, and were quite happy
with the model until we learned that our ESX hosts are sometimes moved between
clusters for load balancing. When that happens, host specific names will create
side-effects. Specifically, the backup instance which processes that host will
no longer be in the same cluster as the host it backs up --which will degrade
its backup performance, and its processing will have to be moved to a backup
instance on the new cluster.
Our testing has shown that a backup instance needs to live in the same VMware
cluster as the ESX host it processes for best performance. We don't let LUNs
mix between clusters, so we can't put all our backup instances on one host and
zone it to see all the LUNs in a datacenter.
We are installing multiple (4) backup instances per virtual machine. Each one
will process one ESX host which is named in the DOMAIN.VMFULL option in its
dsm.opt.
For backup instance names, we could use specific names as recommended, like
TSMVE03-ESX01; or generic names, like TSMVE03-A (where TSMVE03 is the name of
the virtual machine underlying the backup instance, 'A' is anything, and ESX01
is the host processed.)
If we use specific names, it should be easy to see which backup instance was
affected by a host move, since the host is part of its name. But, it will be
complicated to manage after that.The old backup instance will have to be
removed, since it can't be reused, and a new backup instance with a new
specific name installed on the new cluster. Hooray for dsmcutil, but it can be
moody.
If we use generic names, it will be difficult to see which backup instance was
affected by the host move, since generic names are meaningless. But, once it is
found, perpetuating the backup process will be easy to manage. Just stop CAD on
the old backup instance. It can even be reused for another ESX host by
modifying its DOMAIN.VMFULL option. A handy generic backup instance on the new
cluster will be put into use for the moved host.
Each naming scheme has strengths and weaknesses. If a table and column is
available which contains the DOMAIN.VMFULL option we could use a select
statement to find the backup instance affected by a host move. Being able to do
this would allow us to use generic names for backup instances which should make
management of host moves easier than if backup instances had host-specific
names.
I would be glad to hear if I have missed the point somewhere in absorbing the
TSMVE documentation.
With best wishes,
Keith Arbogast
|