Clustering an EV Server

I was setting up EV 2007 Service Pack 2 on a Windows 2003 2-node cluster for the last couple of days (so I could work on a repro that I have to do).   One interesting thing that I found was that when I was trying to configure the failover node, it wasn’t giving me a list of all the cluster resource group containing my EV resources.

What I mean is that when I run the Enterprise Vault Configuration Wizard I see this :

If I select the middle option to add a new to an existing cluster I see this :

I should also see my other resource group called EVGroup.

I read through the notes on the wizard screen:

Does my group contain all those resources? Yes.

Is it online on the node in the cluster? Yes.

Why then is EVGroup not listed?  A little snippet of information in the Installing and Configuring Guide led me to find out what the problem was :

Configuring a failover node

Perform this procedure on the nodes that are to act as failover nodes.

To configure a failover node

1 On the node’s Windows Start menu, click All Programs > Enterprise Vault > Enterprise Vault Configuration. The first page of the Enterprise Vault Configuration wizard appears.

2 Click Configure the node as a failover node for an existing clustered server, and then click Next.

3 The wizard prompts you for the name of the resource group for which you want to add the node as a failover node. Select any resource group that is configured to fail over to this node. The resource group must be online on one of the nodes that you have configured as an Enterprise Vault primary node, and its  resources must all have the failover node as a possible owner.

Select the name of the resource group, and then click Next.

4 On the next wizard page, enter the password for the Vault Service account, and then click Next.

5 The next wizard page lists the actions the wizard will take if you proceed. To continue click Next, then click and then click OK to confirm the actions taken.

6 The final wizard page displays a list of the actions the wizard has performed,and the results. Click Finish to exit the wizard.

When I double checked the EV resources didn’t have this node listed as a possible owner :

Now one way to fix this up would be to edit each of the resources and add the second node as a possible owner.  Another way is to take the resources offline on the active node, fail the group over to the passive node (Node B in my case), then fail the resources back to the active node  (Node A in my case).  If you then bring the resources back online on NodeA, the configuration wizard can go through on the passive node !

NBU Migrations or not

I just finished helping an engineer get NBU migrations working from Enterprise Vault (EV).  He had set everything up in text book style, but still he was not getting anything migrated.  His event log was saying :

0 Saveset(s) were collected into 0 Collection(s).

0 file(s) were migrated to secondary storage

The run completed in 0 hour(s), 0 minute(s), 0 second(s).

At first I thought that this was because he has only test data.  By default we don’t collect if we don’t find more than 15 files in the “hours” folder for each day.  i.e. we’re going to create a CAB file for the day, but won’t unless we find at least 15 files in that day.

First of all we added this registry key, and restarted the storage service :

MinimumFilesInCollection

Location	HKEY_LOCAL_MACHINE  \SOFTWARE   \KVS    \Enterprise Vault    \Storage
Content	DWORD Maximum value: 25000. Minimum value: 1 Setting a value of 0 forces the default (15) to be used .
Description	When creating collections, MinimumFilesInCollection controls the minimum number of saveset files in a collection. The collection is not created unless there are at least this number of savesets to be added.

Still no joy.

We then dtrace’d storagefilewatch and evstgofflineopns to see if that would tell us what is happening.  The output of that DID show us what is wrong :

EV:M Collector is walking the directory tree for Partition 12039DD547090F34A899831D7AFCC68651q10000dbawl11.nbuev.vxindia.veritas.com
EV:L The Collector for Partition 12039DD547090F34A899831D7AFCC68651q10000dbawl11.nbuev.vxindia.veritas.com is parsing directory E:\Enterprise Vault Stores\vaultstore1 Ptn1\2008
EV:L The Collector for Partition 12039DD547090F34A899831D7AFCC68651q10000dbawl11.nbuev.vxindia.veritas.com is parsing directory E:\Enterprise Vault Stores\vaultstore1 Ptn1\20081
EV:L The Collector for Partition 12039DD547090F34A899831D7AFCC68651q10000dbawl11.nbuev.vxindia.veritas.com is parsing directory E:\Enterprise Vault Stores\vaultstore1 Ptn1\200813
EV:L The Collector for Partition 12039DD547090F34A899831D7AFCC68651q10000dbawl11.nbuev.vxindia.veritas.com is parsing directory E:\Enterprise Vault Stores\vaultstore1 Ptn1\2008139
EV:L The Collector for Partition 12039DD547090F34A899831D7AFCC68651q10000dbawl11.nbuev.vxindia.veritas.com is going to Collect file E:\Enterprise Vault Stores\vaultstore1 Ptn1\2008139\135500000000000~200801030937410000~0.DVS
EV:M The Collector for Partition 12039DD547090F34A899831D7AFCC68651q10000dbawl11.nbuev.vxindia.veritas.com determined the file E:\Enterprise Vault Stores\vaultstore1 Ptn1\2008139\135500000000000~200801030937410000~0.DVS as not safe for Collection
EV:M The Collector for Partition 12039DD547090F34A899831D7AFCC68651q10000dbawl11.nbuev.vxindia.veritas.com did not create a Collection as either the Collection was too small or it did not contain enough files. Collection size = 0 bytes, number of files = 0>

This means that the vault store is set to keep safety copies.  By default we won’t put the DVS files in to a CAB file if they’ve not been made safe, ie backed up.  A quick workaround on this test system was to run :-

attrib -A *.* /s

That was run from a DOS prompt in the folder on disk containing the vault store files.

After that, a collection run happened successfully, and data begun migrating to NBU.