When iManage released the IDOL indexer into the legal community, they were being very cautious about ensuring proper performance on this platform. They require that you fill out an RFI document with information about your environment and submit it to them for examination. They will then give you sizing recommendations to outline hardware specifications for proper performance of IDOL in your environment. While this information is very useful, I’ve watched many of my clients mistakenly use that document, with no additional review, as the template for building out their servers.
At this point, you are probably asking “Why would I need to modify sizing recommendations from the vendor?” The answer is that the recommendations that are provided from iManage are based solely upon running IDOL. They do not take into consideration any of the overhead of the OS nor the ability to backup the IDOL collections.
RAM and the OS
The RAM requirements set forth in the sizing recommendations are for running IDOL only. If they specify 28 GB of RAM, that is what is needed to manage the overhead of IDOL. But what about the OS? It still needs a good memory footprint to run as well. As a general rule, I add between 2 and 4 GB of RAM on top of any sizing recommendation to allow for this variance. This assumes that you are using Windows Server 2008 R2 and the official memory guidelines for this platform can be found here. If it is a smaller site (1 Million documents or less) you can add 2 GB of RAM, but push for 4 GB if it is larger.
Backups
The sizing recommendations lay out your disk arrangement for the deployment of IDOL. However, they do not specify any amount of space needed for backups. Furthermore, backups must be stored on a disk local to the Indexer (presented from SAN or Direct Attached Storage) as you cannot backup the collections to a location on the network. For this reason, you must add additional disk space to your indexer to house backups.
I usually allow 1/3 of the collection size for backups assuming compression is on. I also use the maximum size of the content engine drive in my calculations as well (Active Content is not backed up). If we look at this mathematically it would be ((X * Y) * 0.33) Where X = The size of a single content engine and Y = The number of content engines. If a sizing recommendation specifies 4 content engines, each 100 GB, then we would need 132 GB of space for backups ((100 * 4) * 0.33)
So where do we put these backups? You have several options. If you are SAN attached, the first thought is to present another drive(s) to the machine to host the backups. However, this is an expensive option for something that is just housing backups. Another option would be to put in a Direct Attached Storage (DAS) disk. Since this is just a temporary location for these backups (and you’re likely copying them off to some other location, right?) you do not need to worry about RAID and other considerations for this disk. I’m sure there are other options out there, but these seem to be the most common. Just remember that you want to maintain a high I/O rate on the disk or else the backups will take longer.
Hopefully this gives you a little guidance on what to look for and how to balance out your sizing recommendation document to properly deploy IDOL.
When facing a single tree, if you look at a single one of its red leaves, you will not see all the others. When the eye is not set on one leaf, and you face the tree with nothing at all in mind, any number of leaves are visible to the eye without limit. But if a single leaf holds the eye, it will be as if the remaining leaves were not there. – Takuan Soto