The best choice for storage, memory and processors depends on various factors. Before deciding on hardware find an answer to the following questions:
- How many users will be logged in and using the system at the same time?
- Will users be performing a lot of searches?
- How many files will be stored in Elvis?
- What type of files will be stored: image, video, office documents, text, ...?
- Will there be a lot of (manual) importing?
- Will there be constant feeds of incoming material?
- Will there be high volume bursts of incoming material?
When you have gathered this information, the following sections can provide a guide to decide what kind of hardware is needed for your situation.
The required hardware for storage depends on the size and type on content stored on Elvis. Text and XML files usually take up less space than images, and video often requires quite a bit of space.
Example storage size (one million assets of various types):
|Originals (one million)||1 TB|
|Search Index (on fast storage)||2 to 8 GB|
|Previews & thumbnails (depending on type of assets)||400 to 800 GB|
|Versions (depends on how many versions are configured to be kept)||200 GB to 2 TB|
The index size depends on the type of documents you need to store in Elvis. Text files, office documents and PDFs are fully indexed, so they need more space. For images and video, only metadata is indexed, so they will use less space in the index.
Previews in Elvis are light-weight, but still use disk space. For some file types previews can take up considerable space. For example, for PDF documents, once requested, a preview is stored for each page. Video previews are only made from the first few minutes, but can still take up quite some space.
Elvis stores all its data like originals and previews and search index on a file system. You can put all this data on a local disk. For larger environments it can be useful to split the data into fast storage and large storage.
|Fast storage: search index||Large storage: original & previews|
Using fast storage for the index (Elvis Hot Data) is essential when a lot of searches are performed by users. Typically you would use 10.000 or 15.000-RPM SAS or SCSI disks, or even SSD disks. Since the index is usually only a few gigabytes in size, this disk does not need a lot of storage capacity.
When there are lots of assets in Elvis, the originals, previews and versions can take up a lot of space. These can be stored on big disks or a SAN. If you expect the number of assets to grow, use a volume that is expandable, like a SAN solution which allows extra disks to be added to an existing volume.
Non-supported storage systems
The following storage solutions are not supported for use with Elvis Server:
Note: This list is not complete. When in doubt, contact WoodWing.
- Distributed Files System (DFS)
Memory is used by Elvis to cache the search index, run scheduled modules and web services.
- The search index uses a memory cache for sorting and facet filtering.
- When the index gets larger, memory use will increase.
- Memory use will also increase when multiple fields are used for sorting and filtering.
In general follow these guidelines:
|Assets||1 million||3 million||6+ million|
|Users (searching at the same time)||1-5||6-25||25+|
|Memory||4 GB||8 GB||16-64 GB|
Note: Since Elvis 5.0, 8 GB is the absolute minimum for a node with search data enabled.
Tip: Add a processing server for faster imports and indexing. The main server can send heavy processing jobs like generating preview to the processing engine, allowing the main server to focus on handling searches and indexing.
The number of cores needed depends mostly on the amount of people concurrently using the Elvis server.
|Users (active in the system)||1-5||6-25||25+|
|Internal AIR Client||100 Mbit - 1 Gbit (LAN)|
|Email links (web client)||1 Mbit or higher (WAN)|
|Remote AIR Client||2 Mbit or higher (WAN)|
Note: Remember that potentially large 'original' files need to be sent to the processing engine, and previews will be sent back to the server. A fast ethernet network (Gigabit) between server and processing engine is mandatory.
Tip: If you have very high import volumes, use a separate network port and a separate switch to connect the main server and processing servers. This will prevent network traffic between them from clogging up your normal network.
Server hardware examples
The following hardware configurations have proven reliable in performance. For more detailed diagrams of hardware configurations in some example settings, see Examples.
A Mac mini with a dual-core Intel Core and 8GB of memory is a very good configuration for a small amount of users with a fair amount of assets and a low daily intake of new assets.
It's a simple machine to install with Mac OS X client or Mac OS X server (if you want to run an LDAP service). The hardware can be configured with 1 or 2 (OSX server version only) hard disks, possibly in RAID and/or use an external hard disk for storage.
A Mac Pro (or xServe) with a Quad-Core Intel Xeon processor and 8-16GB of memory is very suitable for a small to average amount of users with a lot of assets with a low daily intake of new assets. The extra number of cores and processors makes this a much more powerful configuration than the Mac mini. Because of the multiple hard disk bays it is also possible to setup hard/soft RAID and also offers the option to use SSD storage for storing the index, for exceptional search performance. Optionally, SAN solutions can dramatically expand the storage capacity if needed.
By adding extra Mac mini’s or Mac Pro’s with Elvis processing server software it is very easy to expand processing power to handle more assets, which allows the main server to handle more users.
A Windows server with Quad-Core Intel Xeon processor (or higher) and 16-32GB of memory is very suitable for a small to average amount of users with a lot of assets with an average daily intake of new assets. Advised are machines with multiple hard disk bays, so it’s possible to set up hard/soft RAID. This also offers the option to use SSD storage for storing the index, for exceptional search performance. Optionally, SAN solutions can dramatically expand the storage capacity if needed.
Note: Elvis versions 5.2 or higher include a processing server that can be run on Windows. When using a lower version of Elvis, the processing server needs to be run on Linux or Mac OS. This can be in the form of a Mac mini or Mac Pro. These processing server(s) require no further configuration or maintenance other than installing the processing server software.
Spread server load
When content is added to the system, the Elvis server performs a lot of processing like generating thumbails, previews, extracting text and metadata. Processing requires lots of IO, CPU and memory. Installing a separate processing server will take this load away from the main server, with considerable performance gains for other tasks like searching and indexing content.
Elvis versions 5.2 or higher include a processing server that can be run on Windows. When using a lower version of Elvis, the processing server needs to be run on Linux or Mac OS.
Connecting the main server to the processing server
We advise to connect the main server and its processing servers to the same physical switch and in the same network subnet. If there are too many network switches or routers in between, the connection might become unstable and performance will degrade due to the large amounts of data sent back and forth.
The Elvis processing server is only available for Mac OS X.
How many processing capacity you need depends mostly on how many files are imported per day and how heavy those files are to process. For example, if you have a number of wire feeds being imported by scheduled folder-import modules, you may need additional processing servers. Video files and high-res material can take longer to process, so if you expect heavy material to be imported on a regular base, use more or heavier processing servers.
Since you can use a cluster of multiple processing servers with Elvis, it makes sense to use at least two or more. Doing so provides not only increased processing power, but also provides automatic redundancy when one of the processing machines fail. Elvis will detect a processing server that is no longer responding and will redirect any processing requests to the remaining machines in the cluster. When all no processing server are down, the main Elvis server switches to it's internal processing engine as last fallback.
The fact that a cluster is auto-redundant also means you do not necessarily need top-of-the-line server hardware. A raid set is not needed for redundancy, it's only use could be to provide improved performance - make sure to configure it as such when the machine has a raid set. The processing server only stores temporary copies of files from the main server, it has no critical data. So when a disk fails, just replace it and re-install the Elvis processing server - which is just a few clicks.
Processing server hardware examples
Typical hardware used for processing servers:
Mac mini cluster
- Slower than a Mac Pro.
You can build a cluster of about 3 Mac mini's for the same price as one Mac Pro. In some cases this can result in higher total throughput. Although each individual file will take longer to process.
When using Mac mini's you will typically use at least two or more of them. You do not necessarily need the 'server' version of the Mac mini. A simple desktop model will do: no raid-set is required and redundancy is already provided because you are using more than one processing server.
The advantage of a server model is that it's CPU is faster and the hard drives are faster (when configured as maximum performance raid set).
Mac Pro (cluster)
- High-performance IO system.
- Much faster than a Mac mini.
- More expensive than a Mac mini.
Very suitable when you have a lot of files being imported in Elvis, and you need the previews available as fast as possible.
Although they require more rack-space than Mac mini's, these machines are very powerful. You will need quite a few Mac mini's to get the same capacity as one or two Mac Pro's.
These are quite suitable for use as a processing server and only take up a 1U of rack space. Unfortunately, Apple declared the Xserve end of life and will no longer produce them after January 2011.
The following examples try to make the hardware recommendations a bit more concrete.
Note: Your situation will probably have its own specific needs. These are ONLY SAMPLES and should not be used literally, you will have to make your own decisions.
We picked 4 different situations to show various choices that can be made. Things can be combined differently depending on a specific situation. Please read the hardware recommendations before looking at these samples so you understand the choices behind these examples.
Each of the samples shows the expected user load, expected number of assets and the expected daily intake.
The diagrams in these samples also show an impression of possible network configurations. To keep the schema clean, some elements like bandwidth, DNS, LDAP / Active Directory and Backup, have not been included. This does not mean they are not important.
If you expect heavier intake of assets, you can always add more processing servers to the Elvis cluster to increase the processing capacity.
Minimalistic setup, running Elvis on a Mac Mini. Only suitable for small environments with light use of Elvis.
A medium size setup with a dedicated main server and two light processing servers.
This setup uses a SAN as 'large storage' so it can scale when more space is needed. It also uses a dedicated switch between the main server and processing servers to prevent flooding the LAN with processing traffic.
This setup places the main server in a DMZ. It also shows a 'passive failover' setup for the mainserver. Note that failovers for the processing servers are automatically handled because there are multiple processing servers.
Also note that both the 'Elvis Hot Data' and 'Elvis Data' are placed on the SAN. Since a big SAN is composed of lots of simultaneously operating disks, it can often out-perform internal disks.