Best practise regarding number of Index locations?

[Tobbe]

Hi.

If I remember correctly the sizing recommendations has historically been that you should have one index location per 1.000 users with a minimum of 4 locations.

This was later updated to "a minimum of 8 locations". This is now the only recommendation that I can find in any documentation including the performance guide but what I am wondering is if there are any more precise recommendations?
Since 8 is minimum, at what amount of users/data should more locations be used?

[Wayne_Humphrey]

Sorry Tobbe, I dont quite understand what you are asking here.

[Tobbe]

Hi Wayne.

What I'm wondering is when I should create more than 8 Index locations since the only reference that I can find says "a minumum of 8 locations". In a medium to large implementation would I be better of in creating, lets say 50 locations?
What I'm looking for is really some sizing guidelines/best practise.

Thanks for your time,
/Tobbe

[MichelZ · Accepted solution]

Hi Have a look at the "Enterprise Vault Indexing" Whitepaper: http://www.enterprisevaultfaq.com/wiki/EV_Documents_(Index) You can find the following Statement there about Index locations: It is Best Practice that a minimum of 8 index location sub-folders be created and left open under the primary Index Location. [...] This will also make it easier in the future to manage the indexes by moving an entire index location containing a subset of Index Volumes if necessary and will allow for more segmentation of the index back ups. 50% capacity is a rule of thumb for closing index locations and opening new ones. This will allow the closed index locations to grow with less chance of them becoming too full in the immediate future. This of course is dependent on the size of the disk the Index locations are on. Considerations for the growth rate of your indexes will determine the best percentage for your environment. Index locations can always be reopened later to allow more indexes to be created in them if necessary. Index Locations and their underlying volumes / LUNs should be sized to accommodate an efficient and regular back up. Again, this will vary based on the type of backup software used. So, Index locations are used to speed up Backups, to split them up to multiple LUN's/Storage spaces, and to be able to move a whole index location to another LUN/Storage location e.g. if your current storage is too small and has got multiple index locations on it. In a large organisation, it probably doesn't hurt if you create 16 locations. You will be more flexible in the future. Cheers Michel

[Tobbe]

Thanks Michel.

Based on your provided text I guess that the number of sub folders is secondary, rather spreading the Indexes over multiple LUN's is more essential in terms of performance in both backup and user generated workloads. Outgrowing a disk is less of an issue as long as one is able to use SAN disk that can be extended at will.
If I put all 16 Index locations on the same physical drives, have I then accomplished anything better than putting the default 8 locations on the same drives?

Again, thanks for your help.

/Tobbe

[Wayne_Humphrey]

"If I put all 16 Index locations on the same physical drives, have I then accomplished anything better than putting the default 8 locations on the same drives?" This will help you in the future should you wish to split your index servers up.

How large is your envrioment? Do you forsee splitting 1 EV server onto more servers in the future?

[Tobbe]

Hi Wayne.

The question is more a request for more specific recommendations since I'm in contact with environments of different sizes. The text "a minimum of 8 locations" is a bit too vauge to apply equally to environments with a couple of hundred of users and other with 15.000+ users...

Do you have the possibility to explain why 16 locations would be easier to split onto different servers than 8?

Thanks!
/Tobbe

[Wayne_Humphrey]

I would not bother with going to 16 locations if you only have as little as > 50,000 users.

Lest say you have 2 EV Servers:

vltsrv01 - 16 locations
vltsrv02 - 8 location

If you introduce a another server for each server you will split the indexes twice

vltsrv01 - 8 locations
vltsrv02 - 4 location
vltsrv03 - 8 locations
vltsrv02 - 4 location

So you still have 4 locations which is no issues what so ever, but you would only be able to split that server 4 times.

Another way you can utilise this is if you have say 8 index locations on 1 LUN that is 800GB for example. Should your SAN become full and you cannot expand it you could then move the indexes onto separate LUNS e.g. 8 LUNS @ 200GB 8 Locations.

So going for 16 index locations in my opinion under is really over the top :)

I hope this helps, and makes things a little more clear.

[Tobbe]

Thanks for taking the time Wayne - I really appreciate it.

Just to clarify that I've understood this correctly - This document at http://www.symantec.com/content/en/us/enterprise/media/stn/pdfs/Articles/enterprise-vault-7-and-ente... outlines how to move the index of individual archives so I guess that means that I can move 50% of the users to a different server, regardless of the number of Index locations on my source and target server? It is only described how to perform this move through the GUI but I guess that it also can be scripted. 

However, your description on how to spread the load is based on moving entire index locations. Is that because it is easier to perform that kind of migration, than one that is user oriented and obviously scripting dependant?

Also, besides the possibility to run out of free space on any Index location, doesn't the size of an individual Index play any part in these calculations? 

Thanks,
/Tobbe

[Wayne_Humphrey]

Tobbe,

You can move an individual index if you want, however that is a tedious task so moving an index location is simple and less chance of messing things up.

Size should not play a big role as Enterprise Vault rolls over your indexes should they get to 1 billion. (AVSSMaxLoc)
 

[TonySterling]

What a nice document! I wanted to clarify that 1 billion for AVSMaxLoc is the new default since that doc was written.  The doc itself say 500 Million.

[Wayne_Humphrey]

HAHA,

Tony, stop blaging it....

Why don't we get that excellent doc updated Tony?  If you need help just holla.

--wayne

[Tobbe]

Thanks guys.

On the subject of Indexes that are rolling over - are there any guidelines here to follow or can the index of an archive, such as the archive of a journaling mailbox, roll over until the end of time as long as I have the disk space and are using AVSmaxloc to keep the individual Indexes to something smaller such as 500 million locations?

By the way, updating the Indexing white paper seems like an excellent idea. It is that kind of documentation that I'm looking for most of the time...

/Tobbe

[TonySterling]

Hey Tobbe,

Your index volumes can roll over for as long as you have space for them.  One thing I have seen some customers do is create a new journal archive by year, some as often as quartely, so that they are able to compartmentalize their information more logically that way.  If that isn't a concern for you then you can just let them roll.  :)

Updating the document is a great idea but since I am not with Symantec any longer it would take a bit of co-ordination on my part and it is entirely possible that the EV business unit would rather do the refresh themselves.  For the most part I think the principles apply to EV 8, so it might be worth them waiting for the next release and do a paper then.

Regards,
Tony

[Michael_Bilsbor]

Hi,

The index settings defaults we have in the product are best practise and so in general if you've created any new indexes with recent ish service packs they you'd be having indexes with an avsmaxloc of 1 billion, schematype of 1 (for journal indexes) etc.  So all should be good and that certainly is reflected in the reduction in support calls we get on indexing.  Don't go setting any registry keys, you don't need to do anything.

The index locations is really about two thiings.  I/O and reconfiguration. I/O in terms of if you have the different index locations on different disks.
For reconfiguration, it's because if you have all the index locations on one disk, then it is quite easy to move that one index location (via a bit of sql).  If you had just one index location for example and wanted to move 1/2 of them then you can do it,but it's not nearly as straightforward.  So having a number of index locations even if they are on one disk allows you to move a subset of them to another location at tlater date if you need to.

Cheers,
Mike

[TonySterling]

Mike has a great point, as he is known to do!  :)

All the most up to date best practice are now by default in the application.

[Tobbe]

Thanks everyone for the attention on this thread. Just to summarize for future reference, and verify that I’ve understood this correctly:

• The recommended number of Index locations is the default of 8. Adding extra locations gives you no benefit unless you face a future where you will separate the Index function from its original server many, many times.
• Having all Index locations on the same physical disks gives you no performance gain, but the very fact that you have multiple locations helps you when you want to spread the workload since the easiest part to move is an Index location.
• For backup and performance reasons it might make sense to locate the different Index locations on separate Volumes/LUN’s/Spindles/whatever-term-you-want-to-use.
• It’s no longer recommended to implement the avsmaxloc key since the new default has been lowered to 1 billion which can be considered a best practice.

/Tobbe

[MichelZ]

Sounds correct, yes!