1. Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING) Click the link to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This message will disappear after you have made at least 12 posts. Thank you for your cooperation.

Windows Clustering setup without failover?

Discussion in 'TSM Client' started by dannyblair, Feb 9, 2010.

  1. dannyblair

    dannyblair New Member

    Joined:
    Aug 13, 2009
    Messages:
    58
    Likes Received:
    0
    I am setting up TSM on a Windows cluster that has a fair amount of differnent resources and not easily failed over for several different reasons.

    I have the local (physical nodes) setup and each one with the resources it currently owns setup with the scheduler, but my question is this:

    Is it at all possible to setup the scheduler on the cluster nodes that are not currently owning the shared resource?

    Sorry if this sounds confusing, but if there is a way to do this it would help me GREATLY.
    Thank in advance for any advice.
     
  2.  
  3. GregE

    GregE Senior Member

    Joined:
    May 12, 2006
    Messages:
    2,100
    Likes Received:
    31
    If I remember right from my last attempt where I was not on the server that owns the resources, it would fail because it couldn't locate the dsm.opt file.

    Quick offhand thought you could pursue, I suppose you could try it by putting the dsm.opt file somewhere accessible, running the dsmcutil command pointing to it with /optfile, then go into the registry and change the path to what you need it to actually be for production use. I'm not sure if this is all you would need to do, but its just a quick thought.

    You're not going to know if this works until you failover to this box though, but maybe this can be a starting point to think of other possibilities.
     
  4. dannyblair

    dannyblair New Member

    Joined:
    Aug 13, 2009
    Messages:
    58
    Likes Received:
    0
    Thats actually a good idea. I wonder if I could export the reg key off one of the owning nodes and import onto the non-owning ones.
    Like you said though, no way of knowing if it will work untill it actually fails over.
     
  5. Eldoraan

    Eldoraan Senior Member

    Joined:
    Feb 19, 2003
    Messages:
    288
    Likes Received:
    10
    Occupation:
    Data Protection
    Location:
    Charlotte, NC
    It won't work, if you have clusternode=yes in dsm.opt then it will expect the drives in that config file to be online. If the host doesn't own the resources, then the backup will fail. If you change to clusternode=no it will not process any drives that are part of a cluster at all. Doesn't matter where the dsm.opt file is, if the drive is not accessible, it's not going to backup.
     
  6. yager

    yager New Member

    Joined:
    Oct 7, 2002
    Messages:
    8
    Likes Received:
    0
    Location:
    Raleigh, NC
    I have a few cluster nodes that don't fail much and I've set them up as 'stand alone' that way. OR I set the clients up ahead of time then have the other admins do the resource config at a later time.

    Here is what I do:
    Second/Offline Node work around (note: in this example R:\TSM for tsm config/logs etc..
    ----------------------------------------------------------
    [Options 1]
    net use r: \\<current-owner-physical-name>\r$
    Run ALL steps for normal config/service install etc.
    - Expected R:\TSM folder exists as far as local TSM install is concerned. Keeping both installs the same.
    net use r: /d

    [Options 2]
    mkdir c:\temp\tsm
    subst R: c:\temp

    copy dsm.opt/config files into c:\temp\tsm
    - Run ALL steps for normal config/service install etc. again R:\TSM exists for the install.
    subst R: /d


    This is only part of the setup needed for a fail over but it helps me to get some of it done during my update/change window to the point I can at least run a manual. Many times systems 'slip' into production before everything is done.

    Good luck...
     

Share This Page