Enterprise Vault - Centera temp location

[Itegral]

All,

We have two Centera - replication is uni-directional between the Centera clusters.

The EV will be installed on two node active passive (multi-site) Cluster using Windows Server 2008 R2 enterprise.

The Centera tem location is not on a shared SAN - it is on a SAN volume presented to Node A of the Windows cluster but asynchronous replication will run to the other side.

What if we have a site DR, while Centera and Windows Server 2008 will failover but the temp location wouldnt? Will Centera complain about it. What behaviour will EV have in this case?

[TonySterling]

Well, yes, if the temp locations isn't available the storage service will throw errors and not be able to archive.

This technote has a good example of setting up storage:

Setting up the shared disks and volumes for a Windows Server failover cluster

Article: HOWTO56439

|

Created: 2011-08-01

|

Updated: 2012-03-31

|

Article URL http://www.symantec.com/docs/HOWTO56439

[Itegral]

Thanks Tony.

In case of site DR, will archiving work straight away once the replicated volume (Centera temp location) is presented to the fail-over node?

Currently due to some limitation, client is unable to allocate shared disks and volumes for a Windows Server failover cluster.

[TonySterling]

Honestly, if you can't configure it correctly why proceed?  Wait until you can allocate the disks and then configure the cluster.  Until then you could have EV installed on a warm stand-by and just fail over with USL.

[Itegral]

Update - the two Centera - replication is bi-directional between the Centera clusters

I have managed to add the Centera Temp Volume as part of cluster shared resource. Now with the failover the volume fails over to the failover Node (DR data center).

The storage is not shared, but SAN MirrorView Replication (Synchronous) is being used to replicate the Centera Temp Volume to the DR DC.

1 - What would be the impact if we lose the Centera Temp Volume? bearing in mind that DR location will only have Synchronous repliated data...

2 - Similarly, if we lose MSMQ volume in PRI (synchronous replication to DR) - what would be the impact if DR occurs while archiving task is running and the messages are in queue?

Thanks

[JesusWept3]

if you lose the temp locations you will get errors but you wont have dataloss, you will jus thave items that remain in pending and possibly items in the index that no longer point to a proper saveset,

As for the MSMQ, msmq is really least of your worries, same issues apply, you may end up with stuff stuck in pending, its no longer a huge issue like it used to be where you could have duplicates created

[Itegral]

Obviously the C-clips in the temp location will be lost (VS set to remove safety copies after backup). How EV will deal with this situation and will the items archived again in the next archive run?

With MSMQ - I assume the MSMQ failover wouldnt take the queues with it to the failover node? Does it mean, the items will be picked up on the next archive run?

[Chris_Warren]

When the Storage Service starts, StorageFileWatch will begin performing Housekeeping on the Temp volume.  During this process, it compares the data in the location with the records in SQL (Items in the Saveset table which are referencing the Centera Partition however do not have a CollectionIdentity or Clip).  When it identifies the discrepancy, it will 'deallocate' the reference and clean up.  Then, once the item is stored again, this will get a new Transaction and go on.

As for MSMQ, in a Cluster, the MSMQ storage will be its own resource which will normally failover with everything else to the passive node.  Barring that and if it does not move to the DR, it will start from scratch during the schedule run by placing mailbox work requests in A5.

You may end up seeing a number of errors in the event log regarding NEG ACK requests where EV was expecting items via the database that are no longer available in MSMQ.

Hope this helps.

[JesusWept3 · Accepted solution]

i'm pretty sure the deallocation will not remove sql/indexing records though , because it does the SQL lookup first and then goes through the temp collections area grouping them in to 100 items or whatever it has in 15 seconds and then pushes to a clip.

what can happen is where you have a rolling allocation and deallocation if one of the items is missing.
So if you have item1, item2, item3 and item4 in the database, it puts them in to a collection and then pushes them to the centera.

If an item physically doesn't exist, like item3 for instance, it will then deallocate item1,2,3 and 4 and then try again once all the items have been stored, the collection entry is then given the clipID, otherwise it will allocate, reallocate, allocate again etc.

No new transactionID's will be created, especially since in EV9+ any pending items that have been stored, indexed etc, will keep the same transactionID as not to create duplicates.