kipz,

Clusters can be confusing and there are different ways to cluster a NetWorker server (NWS), each having caveats.

As you want effectively Physical hosts of the cluster to be active storage nodes within the environment and not active on virtual resource of NetWorker server, and from the error message you see I would say this is down to name resolution issue with the NetWorker server (virtual resource) and Node2. It would appear from your error that it thinks the volume is mounted on NWS but how can this be so if there are no devices created for this?

So it's either mounted still on one of Node1's devices or its mounted on Node2's device and again name resolution is causing confusion.

Check your local hosts files, DNS etc and ensure you flush DNS cache if this is used.

Regards,

Bill Mason

but which server owns those VLT-s? also virtual?

in this environment cluster physical nodes are not used only for metadata. they are used as regular storage nodes for most of the clients. so we need to have drives assigned to physical nodes as well. otherwise only one node could be used as storage node at the time.

kipz

When running backup server in cluster your local drives should be local to server virtual name and not physical name of the box.  My approach to this is usually (and this is what I have):

- assign 2 drives from VTL A to both NODE1 and NODE2

- assign 2 drives from VTL B to both NODE1 and NODE2

This means that I will have 4 drives - no matter on which node backup server is running - and they will be seen as local.  I use these just for metadata backup and this combination protects me from local and remote failures (I also use EDL).  In case you are not able to mask drive paths to be the same on both nodes for same drives, you may wish to have jbconfig script in cluster startup inserted (something I do on HPUX).  One thing to remember is to run jbconfig -s when doing this sort of config.

kipz wrote: but which server owns those VLT-s? also virtual? in this environment cluster physical nodes are not used only for metadata. they are used as regular storage nodes for most of the clients. so we need to have drives assigned to physical nodes as well. otherwise only one node could be used as storage node at the time. kipz

In my case they both do.  Only node though uses it when being active of course.  Your current setup is pretty much what I used before.  In that case I found best approach to be with jbconfig script which would delete all NSR jukebox and NSR devoce resources before running backup application.  Once this is brought up, then jbconfig script would configure it based on data and mapping associated with active and passive nodes.  Robotic would always be controlled by active node.