There are many different ways to load balance Enterprise Vault as the usage of it grows, and the amount of data it starts to accumulate also grows. In this article I will present to you several different ways that this can be achieved. Remember that every environment is different; the information below are some areas that can be considered but will need to be tweaked to be applicable to your particular deloyment
Move SQL Databases
One of the common things to do when deploying Enterprise Vault is to 'just add' the Enterprise Vault Directory Database, the first fingerprint database, and Vault Store database all to an existing SQL Server. That SQL Server might already have 10, 20, or more databases on it. At the beginning this might be okay, performance-wise, and scale-wise, but over time as the Enterprise Vault data grows it might start to become a problem on both of those fronts. So one possible action that can be taken is to move those databases to other SQL Servers. They don't have to be moved to their own dedicated super-high-spec'ed machine. Of course that will definitely be best, but in the real world it might just be that there is a lesser-loaded shared SQL server that can be used.
There are plenty of technotes in the Symantec knowledge base that talk about how to move the Enterprise Vault databases, so I won't cover that here. What I'm trying to convey is that Enterprise Vault places quite a reliance on SQL, and having the databases on shared resource will need careful planning, and monitoring. Sooner or later it might well become necessary to move one or more of the databases either to dedicated resources, or a lesser loaded system.
Create some new Vault Stores
Another way that the load can be spread in an Enterprise Vault deployment is to create a new Vault Store. This can be on the same or different SQL server to the existing ones. Be mindful though of the previous point in this article about sharing the load with other databases/applications. Also remember that what goes on in this Vault Store and it's interaction with other Vault Stores in the environment will largely depend on the sharing settings in the Vault Store:
If sharing is enabled within the Vault Store, then the freshly created Vault Store will had totally independent load, but if sharing is configured at the Vault Store group level, there will still be load placed on the existing fingerprint database for the activities performed on the new Vault Store.
Create some new partitions
The actual data files on disk in an Enterprise Vault deployment are another area that will need to be monitored and thought given of how to cope with the expanding environment. There are many ways that the partition space can be grown:
- Additional partitions on local disk, SAN disk, network attached storage
- Data can be collected
- Data can be migrated off to tertiary storage
Probably the most common thing to do is to close off partitions (regularly, say monthly, or quarterly, or when they reach a particular size), and to rollover to a new partition. We all know that disk storage devices are getting bigger and bigger, but in the IT-world we still have to consider how this data is going to be quickly backed up and restored in the event of a disaster, so partition sizes for Enterprise Vault are usually tempered with that fact and won't necessarily be multi-terabyte.
Archiving some company leavers
There are frequent discussions on the Symantec Connect forums about how best to handle company leavers. QUADROtech has it's Archive Leavers tool which can be used to help automate some of the processes involved here, but the main thing is to think about how to handle the user archive of a user that leaves the organization. The company probably already has a way of handling their Active Directory account and mailbox, so sometimes the handling of the archive is added on to that same process. Some companies move the archive to a different almost 'non-production' Enterprise Vault server, which of course will free up some resources on the main systems.
How you do it is down to the individual company requirements, the main thing is to consider the options and then implement the process.
Deleting some old archives
We all like to keep everything forever! But really in an Enterprise Vault deployment consideration should be given to how long data really does need to be kept for. Consider employees that left the organization a year ago, three years, 10 years ago.. does their data need to be kept? If it doesn't then take the time to delete some of those old archives. It is a bit cumbersome in the Vault Administration Console because you can't multi-select and delete. Also worth remembering is that deleting the archive will take some time, add some load to the system (as Enterprise Vault effectively has to 'unarchive' the item in many ways) and won't necessarily free up that much space. The reason for the last point is Enterprise Vault's single instancing might mean that the item is still needed by another archive in the system. That being said deleting old archive is likely to give you 'some' space back, just not the total amount given by the size of the archives that are being deleted.
Move some user archives
Another way that the load can be spread out in an Enterprise Vault deployment is to move some user archives around. This might involve moving them to new Enterprise Vault servers, or it could just mean moving their archives to freshly created Vault Stores. The Enterprise Vault Move Archive tool, or 3rd party tools like Archive Shuttle, can help with automating this move and if planned correctly should give minimal impact to end users and help effectively balance the environment better.
Conclusion
There are many different ways that load can be balanced in an Enterprise Vault deployment. The big question is... how do you plan to do it in your deployment?
