Server Deployment Scenarios¶
Production and Test environments¶
While it is not mandatory to have a separate test environment, there are definite advantages to having a separate server environment for testing.
The test environment does not need to support a large number of users; therefore the hardware requirements for the test environment can be somewhat relaxed. The configuration of the test environment is outside the scope of this guide and should be discussed with the CALUMO implementation team.
Single Server or Multi Server Environment¶
CALUMO can be installed and configured to run on a single server or the server components can be installed on two or more servers.
Our experience is that a single server configuration can easily support 100 simultaneous users, as long as the server has enough memory. It is fairly easy to move from a single server configuration to a multi-server configuration, so unless there are well over 100 users from the outset, it is recommended that you start with a single server configuration.
The table below outlines the recommended minimum requirements for either a single server or multi-server environment. The multi-server environment assumes that the web components are installed on one server and the database components (including Analysis Services) are installed on another server or multiple other servers.
|Component||Single Server (Web & Database)||Multi Server (Web)||Multi Server (Database)|
|Processor||8 CPUs||4 CPUs||4 CPUs|
|Memory 1||16 GB||4 GB||8 GB|
|Disk Space 2||200 GB||100 GB||100 GB|
1 These are the minimum memory requirements. In most situations, the database server also acts as an analysis server and an ETL server. Where this is the case, the amount of RAM required will be higher to accommodate the additional services and usage.
2 The disk space requirements quoted here are general minimum guidelines. The requirements are for available disk space, not physical disk size and RAID requirements should be taken into account when purchasing disks. Actual disk space requirements should be confirmed with the implementation team after taking into account data conversion requirements and monthly volumes.
SQL Server Database Requirements¶
The following databases will need to be hosted by SQL Server: | Database | Purpose | |—|—| |CALUMO|This database is used by the CALUMO application and will be created automatically by the CALUMO installation.| |Datamart|This database will store the dimension data and the fact data that will be exposed in Analysis Services. When Analysis Services cubes are processed the data is read from this database into Analysis Services cube structures.| |DatamartStaging|This database will store data as part of the ETL (Extract/Transform/Load) processes|
SQL Server Disk Requirements¶
By default the SQL Server data files are all installed and created on the same drive. CALUMO advised against this for performance reasons.
Each SQL Server database will have two types of files:
- Data file
- Log file
The way that SQL Server reads and writes to these files is totally different and to avoid disk head thrashing, it is highly recommended that the data files are located on a separate physical disk to the log files. Ideally, the operating system files should be on a separate physical disk and tempdb (a system database) should be isolated on its own separate disk.
Often disks are prepared in arrays to provide protection in the event of disk failure. The following table summaries the different types of RAID:
|RAID Type||How it works||Evaluation|
|None||Plain disk||Provides no protection. Should be used only if absolutely necessary.|
|0||Disk striping. Two disks with data distributed across them. The disks act as one larger disk.||High performance but no protection of data. Not suitable for SQL Server|
|1||Disk Mirrors. Data copied on both disks||A little faster for reads and a little slower for writes. Provides good protection of data at the expense of double the disks.|
|5||Parity checks performed across three or more disks. Data is stripped across them.||Provides good protection at the cost of performance, particularly for writes.|
|1+0 Or 10||Mirroring a striped set||Combines performance and protection but expensive.|
RAID 5 is the most commonly adopted configuration for network drives, but is not really suitable for SQL Server.
CALUMO recommends that SQL Server be configured with 5 sets of RAID 1 pairs as follows:
- For the operating system, SQL Server software, paging file, master, msdb, and transaction log backup files. This disk pair should have two partitions. The first is for the OS and software and it should be 8-12 GB. The second partition should use the remaining space and hold the SQL system databases and transaction log backup files.
- tempdb and a file group with low activity indexes.
- Database Log files (the LDF files).
- A small PRIMARY file group and a file group with all user table data.
- A file group with the high activity indexes.
After CALUMO has been installed and the user databases have been created, it is important that the options for the databases are set correctly to provide the best performance and reliability.
CALUMO recommends the following options be set:
|Database Option||CALUMO DB||Datamart DB||Datamart Staging DB||Tempdb|
|Auto Create Statistics||True||True||True||True|
|Auto Update Statistics||True||True||True||True|
|Data File Auto Growth||50 Mb unrestricted||250 Mb unrestricted||100Mb unrestricted||250 Mb unrestricted|
|Log File Auto Growth||20 Mb restricted to 2 Gb||50 Mb restricted to 2 Gb||50 Mb restricted to 2 Gb||50 Mb unrestricted|
It is important that all databases (including the system databases) are backed up on a regular basis. We recommend that a full database backup is performed at the end of each day to disk and then to tape, and that offsite backups are maintained.
In addition to the full database backups, we recommend that logs are backed up (for the databases with a “Full” recovery model) on an hourly basis during work hours so that log files do not grow to their limit.
More information can be found at:
It is recommended that a weekly maintenance plan be created to check the integrity of each database, rebuild indexes and update statistics. The “Shrink Database” task should be avoided as this will fragment indexes.
More information can be found at: