Video Screencast Help

EV 10.0.3 FSA sizing

Created: 12 Mar 2013 • Updated: 05 May 2013 | 5 comments
This issue has been solved. See solution.

Could someone point me to a sizing guide for Enterprise Vault for File Server Archiving please. I've checked the "Setting Up File Server Archiving", "Installing and Configuring" and "Introduction and Planning" documentation but can't see a sizing guide other than for database sizes

Currently we have a single EV server archiving 18 file server targets. As far as I can see the archiving and indexing jobs don't have lots of queues so I think this is OK. A support rep (Rohan) said the following, which we're trying to verify

"The other thing is that one EV server is targeting 8-9 file servers which will slow down the performance and IIS won't be able to handle so many requests. I would recommend you to split the load across two EV server for better performance. You can monitor the file server and then let me know if there are any issues."

We're not sure how to check whether the amount of requests for files being opened from Vault is high, don't see many IIS errors though. Is there a report that shows how many files get opened per day?

Operating Systems:

Comments 5 CommentsJump to latest comment

JesusWept3's picture

well honestly IIS won't be the bottle neck, IIS is designed to cater for large web applications, so you can safely have 20,000 connections all at once, the real bottle neck would be with Enterprise Vault and the amount of Storage processes it would create (or in this case, could not create)

So i guess the question is, why was the case opened? was it opened around performance or something else?

That being said, its never a bad idea to have multiple EV servers to spread the load, but at this point with how your vault stores are set up, it wouldn't make much of a difference

So lets say you set up the following


EVServer1 has a vault store called "FileStore"
All the FSA archives are owned in the FileStore vault store.
And you have all your FSA Tasks on EVServer1

So you build EVServer2 and want to move tasks to EVServer2
Well the thing is, you can't
The task *has* to stay where the vault store lives.

It doesn't apply to Exchange Mailbox Archiving, Journaling and Public Folder Archiving because it uses MSMQ to communicate between different EV Servers

But with FSA, Sharepoint etc, they use checkpoints and the task has to pass the items to the local storage service, and the local storage service will look after the vault store it belongs to.

IF you have all 18 file servers going to one vault store, all 18 tasks sitting on one EV Server, then i think from a database perspective too you may wish to branch out

Otherwise the saveset tables etc will grow insanely large, not that SQL Server can't handle it, but when it comes to backups, maintanance (like sql index rebuilds) it will take longer and longer and longer

Arjun Shelke's picture

"Is there a report that shows how many files get opened per day?"

answered by Archived Items access trends report. Auditing should be Enabled.


AMPearce's picture

The original case was opened because of some "the item is no longer in the vault" errors which are related to some orphaned placeholders we've found. Considering our retention policy is retain forever and we don't delete items from Vault when placeholders are deleted, we're not sure how these placeholders have become orphaned. Rohan is basicall suggesting that performance of the EV server is a contributing factor, so we're trying to find out whether it is sized correctly.

JesusWept3's picture

you can probably still delete through search.asp and  archive explorer etc
but honestly, sizing of the EV server would have little or nothing to do with  how your server is sized

AMPearce's picture

We don't give end users access to those, so the likelihood of them being deleted that way is minimal. We have seen some deadlocked transactions on the SQL server, I'm hoping that we've not ended up with files/savesets existing in the store but failing to be written into the database properly.