cancel
Showing results for 
Search instead for 
Did you mean: 

EV 9 sizing guidelines

Hi Guys,

I am presently involved in a design of EV 9.0 for 1100000 users.

Presently they have about 20000 users enabled for archiving.We are buliding a brand new EV 9 system along side Exchange 2010 SP1.

We need to move the archives from the present EV 7, 8 systems to EV 9 and also migrate user PST's..

At present I am calculating the SQL DB size and got some issue.

let me take the ex for one region.

I have 20000 users who will be enabled for archiving with a 5GB of archive quota.

I do not have the count of number of items at present.I am assuming the avg message size is 100KB

Symantec suggests the following:

 

Directory DB  5GB
Vault store DB :  5GB+250 bytes*total number of items
Vault store group FP DB :5 GB
Monitoring DB: 5Gb
Audit DB :5GB

I am calculating for 5GB, if you consider 100KB messages there will be 50000 messages and as per the formula , it is

 

5GB converted to KB No of items of size 100KB each /user Total no of items for all users of 100 KB each
(5*1024*1024) (5242880/100KB) (Total no users*no of items of 100 KB each)
     
5242880 52428.8 1064304640

 

so

 

Vault store DB (5GB)+(250 bytes*total no items) 5GB+(250 bytes*1064304640) 255GB

 

Please let me know if my calculation is correct.I am thinking it is not cos for a 6200 user system with unlimited storage space(6 months older archive 7 yers retention) i see a vault store DB of only 4.5 GB..Pls help me get this right

1 Solution

Accepted Solutions
Accepted Solution!

reply

Hello Maxie,

For a large scale migration, Move Archive is definitely NOT the tool to use.

If possible, go for 3rd party tools (they have (for instance) better errorlogging.

active/active I am not too sure about. You can have only 1 directory database, which needs to be reachable at a decent speed. (as MichelZ stated (latency)).

 

On the EV-client, to be sure check the compatibility guide. Located at http://www.symantec.com/docs/TECH38537
 

In general, the EV-client is compatible 1 up 1 down. In other words, EVclient 8 is compatible with EV7.5 and 9.0. The 9.0 client is compatible with server 9 and 8 only. The 7.5 client is compatible with 8 en 7

If a user is NOT enabled for archiving, it is safe to roll out the client to him. As long as they are not provisioned and enabled, they will not get the ev-functionality in outlook.

If you have a set of users you know will going to be enabled in 9.0 only, roll out the 9.0 client to them.

Users enabled for 8.0, having the 8.0 client you CAN update the client, or wait until 9 is up and running and they are moved to 9.

Users enabled for 7.0, you can roll out the 7.5 client, or upgrade that one to 8.0

I know that some 3rd party tools can move archives 'version independent' (ie from 7 to 9), but some might not.

Depending on the size of your environments, it might be wise to upgrade all 'legacy' environments to V8.0SP5 (just released) For 7.0 this means going to 7.5 (2007) first, then to 8.0. Upgrading is relatively simple, also gives you the possibility to go to a higher SQL level, and makes client roll-out easier.

Really sounds like you need a Symantec 'sparring-partner' ;)

Regards. Gertjan

View solution in original post

13 Replies

Well, first off - the latest

Well, first off - the latest sizing guidelines state 400B per line item in SQL.

So, using that starting point...

5GB (per user) * 20,000 users = 100,000GB * 1048576 (GB to KB) = 104857600000KB /

100 (size of emails) = 1048576000 (# of email) * 400 (bytes per email) = 419430400000B / 1024/1024/1024 = 391GB

 

I have a question though...  are you really designing for 1,100,000 users?

 

Also, I'm not sure why your other environment has such a small SQL VS DB, but there can be many mitigating factors.

 

I would recommend that you consider bringing in an  EV architect consultant to help with the design, especially one with experience in very large environments if you are looking at 11000000 or even 110,000 users.

Archive Quota don't have

Archive Quota don't have anything to do with DB sizing.

The DB's will be sized, depending on the amount of archived mails, not the size but the actual number of mails being archived.

Per unique mail/attachment/etc. 500 bytes will be added to the Fingerprint DB, another 500 bytes in the VS DB. But then you have all the SIS functionality, so if the same mail is archived from another user the DB's won't increase with 1KB because it will be shared with the already archived item. Depending on how sharing is setup etc. of course.

So to really answer your question the number of mails and attachments will be needed and you would need to use some assumptions, e.g. the sharing ratio. Otherwise you'll need a tool that will hash-check the mails and come up with a sharing ratio for that particular environment. You should be able to get it from Symantec or a partner to run against your Exchange servers.

It's called Exchange Mailbox Analyser or the older one called Exchange Storage Reporter. Not sure anymore which one works best :)

Then there is a Excel spreadsheet with the sizing formulas, that will let you size the environment using the output of one of the tools above. Not sure how "freely" available that is, so again check with a partner and/or Symantec.

/Fredrik

As maxwits said above, if you

As maxwits said above, if you are not incredibly familiar with EV designing a system for 1million users or even 100k or 10k users is a pretty big undertaking, and one you should probably involve Professional Services on.

Thanks Guys for the quick

Thanks Guys for the quick advice..much appritiated

The total number of users are 1,10,000 users..sorry about that

@maxwits: thanks for calculating the size..My 20,000 users environamnet looks like this..

SQL will be in Active passive cluster where the sec Datacenter  vault servers have to travel over the WAN for SQL access(is that a catch)

for both SQl and EV the config is 2xQC CPU,16GB RAM..i hope thats fine

I am planning to validate my design with symantec.pls let me know how can go about it?

The WAN travelling could be

The WAN travelling could be an issue. What latency do you have between those DC's?

You may be better off to install a second active SQL Server just for the second EV Servers Vault Stores...


cloudficient - EV Migration, creators of EVComplete.

hm.

How many exchange servers do you have?

Regards. Gertjan

Thanks Guys..I am amazed @

Thanks Guys..I am amazed @ the spped at which ppl answer here..

@gertjan:  3 in each DC (total 6) configured for exchange 2010 DAG.

@MichelZ : yes i also think so..High availbaility and money is the factor though..Can i make 2 SQL servers active at the same and still ofeer HA for SQL..any thoughts?

 

Best regards,

Maxie

Well, what you CAN do is

Well, what you CAN do is install another instance of SQL Server on your cluster, then having one instance active at DC A and the other instance at DC B (talk with your SQL guys about that)

This probably does not have any impact on money (at least license-wise), I think, and both Servers would be HA as they failover to each other.

Cheers


cloudficient - EV Migration, creators of EVComplete.

exchange vs ev

Hello Maxie,

Your welcome. As this is something most of us deal with/have dealt with, we're more than happy to throw in our 2cts. Here are mine smiley

At first.

When you want to use the native move archives from EV8/9, you will have to upgrade the ev7 to ev8 the least. Also note that it (move archive feature) is not very well suited for mass-migration of archives. If you need to move a lot of archives, you might be better off using a 3rd party tool (Archiveshuttle or Transvault), or use the export to PST/import to archive functionality, or export the archives to the original mailboxes, then move the mailboxes to 2010, archive from there.

At 2nd.

If possible, use 1 ev server to target 1 exchange-server. Although DAG's is a good solution, you run the risk of overloading your ev-server. Depending on the specs of the EV-server obviously, but you might run into issues with the archiving window vs backup window. I understand this is a little more costly, but I cannot stress enough that you have to get this setup right the first time! It is not impossible to restructure later, but you will get a better experience if the setup is done properly (taking in account growth for example). If money is an issue, investigate getting your EV-servers virtualized.

At 3rd.

Are you going to use the 2nd dc as DR-site, or are you spreading the dag's over the 2 dc's? If the first (DR), check the EV-documentation on buildingblocks/dr. You can then mirror/logship the databases to the 2nd dc, and have 3 ev-servers there in 'standby'. When there is an issue, you do a dr to the 2nd dc, and of you go. Obviously, you then also need to replicate the data of the vaultservers (indexes + storage). There are several methods. We use (ahum) robocopy to do this. There are other ways obviously.

If you're spreading the load accross the dc's, you might (as MichaelZ states) put a 2nd SQL server in the 2nd DC to host the VaultStore database for that site.

At last

Seeing the stage you're in (initial preparation?), I agree with previous posters that you are best of involving Symantec Professional Services. (or a good partner) to help in defining the proper setup/configuration.

Do keep us posted on how you get on. I for one am curious to see where you go with your design, and how you resolve issues you run into.

Good luck!

Gertjan

Regards. Gertjan

Thanks..@gertjanA: so you

Thanks..

@gertjanA: so you say for large scale migration move archive wont be a good idea,PST import/export would be a better idea? I will also discuss the possibility of 3rd party such as transvault.

and yes, I will keep you guys posted on how things go going forward and share my experiences ,post and wait for advice if I run into troubled waters :)

ours is a active:active with 50% each spread between the two.I also felt SQL access over the WAN could be an issue.I have a meeting setup to discuss this issue

I have a question on EV client.is it OK if i install the EV outlook client add-in ,well in advance on client desktops and keep them ready before they are enabled for archiving on EV 9.0?. for users who are not yet on EV this would be fine ,but what about those user who are already enabled on legacy systems such as 7.0,8.0 etc and already have a previous version of outlook client add-in installed? please let me know..will it break the existing archiving functionality or pose any issue or will it sit quietly till the user is actually enabled on EV 9?

 

Best regards,

Maxie

Accepted Solution!

reply

Hello Maxie,

For a large scale migration, Move Archive is definitely NOT the tool to use.

If possible, go for 3rd party tools (they have (for instance) better errorlogging.

active/active I am not too sure about. You can have only 1 directory database, which needs to be reachable at a decent speed. (as MichelZ stated (latency)).

 

On the EV-client, to be sure check the compatibility guide. Located at http://www.symantec.com/docs/TECH38537
 

In general, the EV-client is compatible 1 up 1 down. In other words, EVclient 8 is compatible with EV7.5 and 9.0. The 9.0 client is compatible with server 9 and 8 only. The 7.5 client is compatible with 8 en 7

If a user is NOT enabled for archiving, it is safe to roll out the client to him. As long as they are not provisioned and enabled, they will not get the ev-functionality in outlook.

If you have a set of users you know will going to be enabled in 9.0 only, roll out the 9.0 client to them.

Users enabled for 8.0, having the 8.0 client you CAN update the client, or wait until 9 is up and running and they are moved to 9.

Users enabled for 7.0, you can roll out the 7.5 client, or upgrade that one to 8.0

I know that some 3rd party tools can move archives 'version independent' (ie from 7 to 9), but some might not.

Depending on the size of your environments, it might be wise to upgrade all 'legacy' environments to V8.0SP5 (just released) For 7.0 this means going to 7.5 (2007) first, then to 8.0. Upgrading is relatively simple, also gives you the possibility to go to a higher SQL level, and makes client roll-out easier.

Really sounds like you need a Symantec 'sparring-partner' ;)

Regards. Gertjan

View solution in original post

Guys..many thanks for the

Guys..many thanks for the help..

 

Best regards,

Maxie

If ok, can you close?

Hi Maxie,

If you are ok with the answers, can you please close this post, mark one as solution?

If possible, it would be nice to see another entry when you have put all this in place.... (yep, hint)

 

Regards

Regards. Gertjan