Once an organisation has been using Enterprise Vault for several years there might come a time through company acquisitions or general growth that the current Enterprise Vault environment needs to be expanded outwards. The Enterprise Vault organisation needs to grow, just like the business organisation. In this article I'll explain a few different ways in which this growth can take place.
Build new - and use
One way to expand is to simply build a whole new Enterprise Vault Server, with a new Vault Store, and new Vault Store Partitions and then simply start creating new archives on it. It will lead to a somewhat uneven balance, at least at the start, and it won't stop the current server still continuing to grow. Existing archives on the original server are still likely to be growing, with new email, and other data arriving daily still, and getting archived per the schedule and policies.
Going for this approach does mean that nothing extra needs to be done, save perhaps for some minor work on the existing server and at the very least careful monitoring of disk space usage if the server continues to consume additional space.
The newly created archives, either for new data, or for new users, will have the full run of the new server, which will start to consume space as time goes on. So gradually over time the current save will in some ways stabilise (some people will leave, and free up space that the existing users will use some of, and new users will be commissioned on the new server)
Wait - and swing upgrade
Sometimes organisations are fortunate enough to be able to plan for growth and relate that to a time when they plan to upgrade too. For example upgrading from EV 9 to EV 10, or in the near future it might be when they upgrade from EV to EV 11. Doing a swing upgrade of effectively replacing the server underneath all the data means that all of the existing archives and users will get the benefit of a new, more modern, faster system. It could also be that the storage gets expanded at the same time, or at the very least maybe new partitions are created either on existing devices or new ones, and these will then be used for the environment to grow into.
With this approach you'll still be left with the one server, probably, but it'll be much newer, therefore faster. The problem that would still need to be addressed is storage, but Vault Storage partitions can effectively be created almost anywhere, they just need some level of management to keep them somewhat under control. The advantage of this approach is that you haven't expanded out the number of servers, so, you're left with only one that needs maintenance, but you also have the downside of having a single point of failure.
Build new - and move
As long as an organisation has kept reasonably up to date in terms of Enterprise Vault version, the IT team might be able to make use of the Move Archive feature to move some existing mailbox archives to a new server. So like the first option a new server is built, and commissioned, with a new vault store, and vault store partitions. Perhaps new archives will be made on the new server going forward, but in addition, with this approach the IT team also use some of the built in features of Enterprise Vault and move some of the mailbox archives to the new hardware.
With this approach you could go from a server which is at say 90% capacity and over a period of a few weekends where you have more 'run of the system' you might move some of that data over to the new machine and new storage, leaving say 50% on the original machine, and 40% on the new machine. Now both machines have the capability to grow - the server spec of the old machine is likely to become a problem in the medium to long term, but that's also replaceable at some point.
Build new - and balance
Another option which builds on the previous idea is to build new hardware and use third party software to help with the balancing of mailbox archives between the different systems. One such possibility is Archive Shuttle from QUADROtech. Its easy to use web based interface presents information relating to archives in an intuitive way. It's quite easy to define batches of users that go through a migration. The migration happens first of all using a synchronisation approach - here data is copied from the source to the target, meaning it remains available to the users throughout the migration. The second stage is the switch, which is usually quick and painless - just a matter of minutes. A last synchronisation takes place and then a number of steps are performed to reunite the user with their target archive, which in our scenario will be on the new machine. There are many possibilities that can be explored with Archive Shuttle, but the previous idea fulfills the immediate need we're describing here - you can in fact use something Archive Shuttle to help with migration to the cloud as well.
Working through a balancing process like this can mean that the introduction of new hardware can be a quick and painless affair, and during the whole process users maintain access to their archived data and that's a big benefit. It is also pretty easy to administer with a low overhead in terms of system requirements and load on the systems which are in place.
Sharing
Some of the ideas presented here are of course dependent on the sharing level within Enterprise Vault. If a new vault store is created, in the same vault store group where sharing is configured across the group, then any movement of email archive data isn't going to have an effect on the actual data stored down on the vault store partitions.
If sharing is configured in this way, and it is a good thing to do, it might be that you would need to create a new vault store group, and a new vault store within that group. You'd have to do that to realise some of the benefits of moving archives 'off' a main server on to a new server, otherwise the new servers archives end up just having references back to the data on the old server.
Summary
Growth is what everyone hopes for their business, but with it comes some costs, and eventually that cost spreads to things like infrastructure upgrades. We've seen here how a perfectly well designed Enterprise Vault environment may require some growth, and some attention over the space of a few years.
How has your Enterprise Vault environment grown? Let me know in the comments below...
