Sizing and Scalability Considerations
When planning for sizing and scalability, use these recommendations for installations (database and server), deployment, trusted agent, and scaling variables.
Installation Considerations
CSM uses Microsoft SQL Server as a back-end database (see the System Requirements for supported versions). SQL Server can often be installed on the same server as CSM. However, organizations with a centralized database server should host CSM on that server instead. This setup is more efficient because it simplifies management and ensures that CSM data participates in an existing backup/recovery plan.
When moving the CSM database to a separate server, consider the following:
- Network activity exists between the CSM server and database server (typically via TCP/IP). There is typically a fast connection between the two machines, though firewalls might require configuration to allow this communication.
- CSM servers must have appropriate security access to the database. This is accomplished by either providing SQL credentials for the database to the CSM server or ensuring that the account used by the CSM servers has appropriate rights on the database server (and also has appropriate local rights on the CSM server machine).
By default, servers and server components are installed on a single server. However, the components can be separated onto additional servers if necessary.
Consider the following reasons for separating components:
- Support of existing infrastructure: Customers commonly have separate servers set up for specific functionality. Typically, this includes either the database or the web server.
- Scalability: When the number of concurrent Users increases substantially, separating secondary services might improve efficiency. Typically, this includes secondary services expected to use a significant amount of data.
- Server Farms: The Cherwell Server and CSM Web Applications also support enabling of server farms starting with CSM 6.0. This utilizes a Redis cache to handle state management between multiple servers when used with a hardware load balancer.
Deployment Considerations
- Network performance.
- Database performance.
- Complexity of the SQL database network configuration.
- Use of CSM on a shared or dedicated server.
- Use of CSM in a high availability environment.
Trusted Agent Considerations
Prior to deployment, consider the impact of Trusted Agents on scalability and system performance. In most cases, the use of Trusted Agents adds only a marginal amount of overhead, but in the case of the Trusted Agents for email, the impact can be as much as a 40% reduction in the throughput of emails.
Scaling Variables
See System Requirements for minimum requirements, then scale CSM based on the specific projections of the organization. For more information on scaling in a single-server configuration, see Consolidated Layout. The table below lists variables that will affect your system's scalability:
| Variable | Notes |
|---|---|
| Total number of Users | |
| Concurrent licenses used | Consider factoring 600 MB of database storage per license per year. |
| Connection pools |
To improve performance, set the maximum pool size to three times the number of concurrent CSM licenses that are used in your organization. You may need to adjust this value, depending on usage of your system. |
| Number of records created (example: Incident or Change) | If the record count is especially high, consider increasing the memory and processors on both servers. |
| Number and complexity of system relationships | |
| Number and type of CSM reports run | If running multiple reports frequently, or reporting historical/trend data for extended periods of time, consider increasing the memory and processors on both servers. |
| Number and type of CSM attachments used | If using many large attachments, consider doubling the amount of storage. |
| Using a server farm |
|