Schedule for TDP4VE Hyper-V in clustered environment

[Daemon-FF]

I has a cluster (HVCLUSTER) with three nodes: NODE1, NODE2 and NODE3. I installed TSM TDP4VE for Hyper-V at them all. I 've registred nodes NODE1..3 and HVCLUSTER at TSM server. In file dsm.opt at hosts I've written (for HOST1 in this example):

NODENAME HOST1
ASNODENAME HVCLUSTER

Now, I made the schedule:


tsm: TSM12R2>q sched WIN_VM VM_BACKUP f=d

Policy Domain Name: WIN_VM
Schedule Name: VM_BACKUP
Description:
Action: Backup
Subaction: VM
Options: -vmbackuptype=hypervfull -domain.vmfull=all-vm -mode=ifinc
Objects:
Priority: 5
Start Date/Time: 30-12-2014 17:05:00
Duration: 5 Minute(s)
Schedule Style: Classic
Period: 1 Day(s)
Day of Week: Any
Month:
Day of Month:
Week of Month:
Expiration:
Last Update by (administrator): ADMIN
Last Update Date/Time: 30-12-2014 16:58:40
Managing profile:

That is OK, work fine with non-clustered hosts. But I cannot understand, what name I must associate with this schedule - host name (e.g HOST1, HOST2, HOST3) or cluster name HVCLUSTER?

 

[Daemon-FF]

Anybody can help me?

 

[LexRogoff]

As far as I understand, you should run a schedule for HOST1, HOST2 and HOST3. Make sure you have ASNODENAME HVCLUSTER added in the dsm.opt files on every node to have your backups stored under cluster node name. Don't forget to grant the proxynode authority to host1, host2 and host3 using GRANT PROXYNODE command (GRANT PROXYNODE AGENT=HOST1,HOST2,HOST3 TARGET=HVCLUSTER).

 

[Daemon-FF]

Thank You, LexRogoff.

I think in my case cannot use server-prompted mode with TSM-client. If I have ASNODENAME option in dsm.opt file the following happens:

CAD services started at HOST1 and connected to TSM server (as node HVCLUSTER!). TSM server stores ip-address of node HVCLUSTER (but it's ip-address of node HOST1 in really!). After this, CAD service starts at HOST2 and connect to TSM server (as node HVCLUSTER!) too. TSM server changes in the store ip-address of node HVCLUSTER to ip address of HOST2! When schedule must be run, TSM server connect to client in order to initiate session from client... But with what of client it will make the connect?! It's depend of who had latest connection to TSM-server! Other host (node of cluster) will not have connect from TSM-server...

In my mind with clustered environment TDP4VE for Hyper-V client must works in polling mode!

Other workaround (with server prompted mode) is to use ACTION=COMMAND with OPTION='dsmc backup vm ... -optfile=dsm_clstr.opt...' in schedule. In this case we must write ASNODENAME option in dsm_clstr.opt file, but hav'nt to use ASNODENAME in default dsm.opt file, that is using by CAD service.

 

[LexRogoff]

I don't think so. CAD starts at host1 and connects to TSM server as host1. The same for host2 and host3. No need to create a CAD service for HVCLUSTER.
What happens then?
1. A schedule is initiated for host1
2. Host1 connects to TSM server using ASNODENAME=HVCLUSTER option. It doesn't need to authenticate as HVCLUSTER because it has the PROXYNODE authority granted.
3. Any data backed up from host1 is stored under the HVCLUSTER node
The same for host2 and host3. Result: you have all backups from your Hyper-V cluster kept together. 'PROMPTED' or 'POLLING' schedmode makes no difference here.

 

[Daemon-FF]

When I set option ASNODENAME in dsm.opt file, any schedule will execute as node HVCLUSTER. But if I want to run ordinary action (i.e. backup C, both backups (from HOST1 and from HOST2) will be placed in same filespace. This is wrong.

In addition, when CAD works in prompted mode, TSM server sets up admin session with hosts at time of schedule. Which host can be accessed at address of HVCLUSER?

 

[LexRogoff]

Well, you can avoid adding ASNODENAME to dsm.opt and put it into the options parameter of your client schedule (define schedule .... options='-asnodename=hvcluster').
Consequently, you'll need at least one schedule to backup the local resources from host1 and host2 and another schedule for cluster resources with -asnodename option. Thus, backups will go into their proper filespaces. All schedules should be executed against host1 and host2, not hvcluster. Actually, you shouldn't run any schedules against hvcluster at all.