Video Screencast Help

Decoupling enterprise vault components

Created: 24 Oct 2012 • Updated: 15 Nov 2012 | 5 comments
This issue has been solved. See solution.

Hello Everyone,

I'm trying to design a scalable Enterprise vault deployment and wondering to what degree decoupling various EV components contribute to scalability. For e.g., based on the performance guide, a given server can archive 60K messages per hour; if Indexing is offloaded to a different server reducing the load on the archival server, how many more additional messages can the server archive?.

Thanks,

Comments 5 CommentsJump to latest comment

JesusWept3's picture

If you have a decent server with good disks, fast CPU and plenty of memory etc, I doubt you will see a bigger throughput jut by removing the indexing processes. If you offload indexing to a new server you will probably see the same "strain" because indexing will be requesting those newly archived items from storage to go ahead and index.

Plus sometimes the 60,000 messages can more a limitation of mapi and exchange.

That being said, there is something to be said for seperating the index server because if you have say an index server for every two or three EV Servers, when you are doing heavy EV searches and things like that, the index query strains will be on that one index server, as opposed to having to hit each of the three EV servers individually to query there indexes.

Plus it simplifies the backup somewhat

SOLUTION
Jeff Shotton's picture

Hi,

Have you read the following indexing best practice?: http://www.symantec.com/docs/DOC4250

The suggestion is maybe 30% additional throughput, but it will depend on a few factors, such as the network bandwidth between the boxes. If you have slow networks, just dont bother.

I think maybe a more scalable strategy would be to focus on the archiving task placement and the vault store distribution (and the association between the two). Also, VMWare is great for scaling - stick in more lower power servers with a single task each and simply ramp up each instance as needed.

Ultimately it is FAR easier to consolidate servers in EV than it is to fan out afterwards.

Regards,

Jeff

Jeff Shotton

Principal Consultant

Adept-tec Ltd

Website: here

ecrgvp's picture

Thanks for your inputs..From my understanding, the limitation is how we scale Exchange servers. If an archival server need to archive from a given physical mailbox server (say 15-20K mailbox per server), then the limitation would be a single achive server trying to catchup with items from that target. In such cases, I was wondering how de-coupling the EV components might help..

JesusWept3's picture

It says 30% but i'd genuinely surprised if it was that high

Jeff Shotton's picture

Your limitation there will be the time taken to pass through all the mailboxes in an archiving run. 15-20k mailboxes per exchange server is a lot unless you are considering keeping mailboxes really really small.

Remember whitespace in the mailboxes will account for time during the archiving run as well.

What you also may have noticed from the performance guide is that there is a reducing rate of return by throwing more processor at the EV server - you would theoretically get 60k/hr from an 8 core box but only 90k from a 16 core box. Also, the number of concurrent MAPI threads is limited by

1) The number of connections you can actually make to exchange as EV limits to 25 per server

2) The number of connections allowed by the version of MAPI you are using  (100 in a patched copy of outlook 2007)

3) The available capacity of the Exchange server

What you dont really want are archiving windows that cannot accommodate full passes of the server, as this will result in buildup on the A5 message queue which you will periodically have to purge. To that end, you might be doing very long archiving runs and you will need a backup strategy to cope with less downtime - such as taking snaps for indexes, replicating vault store partition data real time etc etc

 

Im fairly sure if you throw in a suitably powerful server you will find that the indexing component will scale better than the archiving component. i.e you will be able to index data fast enough without issue on a single box.

However, if your users are heavy searchers there may be a benefit in splitting out the workload, and this is where you may see the biggest performance benefit from index server groups. 

Have you seen the technote on how to choose to use index server groups?

http://www.symantec.com/docs/HOWTO57701 

Regards,

Jeff

Jeff Shotton

Principal Consultant

Adept-tec Ltd

Website: here