This guide outlines minimum hardware requirements and discusses important topics to consider when planning your community install. Requirements will vary based on utilization and monitoring the performance of your community is always recommended. Every use case is different and the infrastructure should be able to expand as site usage changes.
Page views are defined as any URL request for service via the platform, including content, for example, views to a blog or forum thread; files (for example, files served out of the media gallery), RSS requests, and platform API calls.
[toc]
Architecture Overview
Community is made up of a number of components:
- Website - The website is the component that your users interact with. Asp.Net running on IIS.
- Database - This stores the majority of user-uploaded content (user lists, posts etc.). Uses Microsoft SQL Server.
- Filestorage - This stores user-uploaded files, as well as some system configuration. A local directory or a UNC directory.
- Job Server - The Job Server runs background tasks that aid your community. This includes (but is not limited to): Email Notifications, Daily/Weekly maintenance. A .Net Windows service.
- Search
- Socket Bus - Used to allow communication between web nodes. Mainly used for live notifications, and presence. A .Net Windows service.
Planning
Note: Recommendations are minimums.
(<500K page views per month)
(example architecture)
Server Specs:
- Web: 6GB RAM, 4 CPU Cores
- Utility: 6GB RAM, 4 CPU Cores
- Database: 4GB RAM, 4 CPU Cores
(500K-8M page views per month)
(example architecture)
Server specs:
- Web Servers: 6GB RAM, 4 CPU Cores
- Utility server: 8GB RAM, 4 CPU Cores, SSD for search
- Database: 8-16GB RAM, 4 CPU Cores
(8M-30M page views per month)
(example architecture)
Server specs:
- Web: 4GB RAM, 4 CPU Cores
- Search: 6GB RAM, 4 CPU Cores, SSD
- Utility: 4GB RAM, 4 CPU Cores
- Database: 16-32 GB RAM, 8 CPU Cores
Filestorage
Filestorage contains the user uploaded media, as well as some system settings. It needs to be accessible by the website and the job server. If you have a single website instance, and the job server is on that same server, you can do this very easily via local directory (e.g. d:\Telligent\Filestorage ). If you have multiple servers, however, this gets more complicated.
- DFS Replication: Each server stores its own copy of the filestorage, and synchronize changes between themselves with DFS Replication. This provides a natural high availability solution, but does mean that each server needs enough storage capacity to contain the entire filestorage. DFS Replication works well for small numbers of servers.
- UNC Share: Filestorage is stored on a remote server.
To decide which solution is appropriate for you, we'd recommend asking yourself the following questions
- For a single server installation, use a local directory (e.g.
d:\Telligent\Filestorage). - If you have an existing highly available file server you can use, use that.
- If your SAN supports exposing a UNC share directly, use that.
- If you have 2 servers hosting the website or job server, use DFS Replication.
- If you have 4 or more servers hosting, use a UNC share.
Database Authentication Method
We recommend using Integrated Authentication where ever possible. We only recommend SQL authentication if you're using a hosted SQL option which doesn't support Integrated authentication (e.g. Azure SQL or Amazon RDS)
Service Accounts
Where possible, we recommend using local accounts over domain accounts as they are simpler to manage. You will, however, need to use a domain account if:
- You're hosting filestorage on a UNC Share.
- You're using integrated authentication to connect a SQL Server (and that SQL Server is not on the same machine as the Website or Job Server).
High Availability
The following sections highlight what will happen if a particular component fails so you can decide if you need to make it highly available, as well as how you can provide for High Availability.
Website
If the website component is unavailable, your end users and integrations will be unable to use your community at all.
High availability of the website is achieved by having multiple web servers and using a load balancer to balance traffic across the servers. When one server fails, the load balancer will redirect traffic to the working web servers.
Database
The database is an essential part of Telligent Community - if it is unavailable the website and job server will be non-functional. The community does have a caching layer so may be able to tolerate very brief database outages without much visible impact to end users, but any longer than a few seconds and the website will error for almost every request. The website and job server will recover almost instantly once the database becomes available again.
SQL Server has a variety of high availability options. Refer to Microsoft's documentation for more details. If using SQL Azure or Amazon RDS, refer to the relevant product documentation.
Filestorage
Filestorage is an essential part of Telligent Community - if it is unavailable the website UI will be mostly non-functional. The Job Server, as well as API requests in the website, will mostly continue to function. The community does have a caching layer so may be able to tolerate very brief filestorage outages without much visible impact to end users. Within a couple of minutes, the community UI will error for almost every request. API and jobs lot more tolerant of filestorage outages. Any failed jobs will be re-queued and retried after a delay,
If using DFS Replication for your filestorage, then you already have high availability. If using a UNC Share on a windows server, you'll need to host the share on a File Cluster, and make the share highly available.
Search
If search is unavailable, the community will run with reduced functionality. Any operation involving search will fail. The search feature in the website will obviously not work.
High availability for search is achieved through Solr Cloud. Our indexes do not support sharding, but replicas are supported.
Job Server
If this component fails, the community will run in a reduced functionality mode - background tasks will be queued up, but not processed until the Job Server comes online again. Most of these are background tasks that are not visible to end users, although end users may notice when the Job Server comes back online again as they receive delayed notifications.
The Job Server does not support an active/active high availability. A passive failover is supported if you replicate the Job Server configuration to another server with the service disabled. When a failure happens, failover to the passive node either manually, with Windows Failover Clustering, or with other monitoring solutions.
Socket Bus
If the socket bus fails, The community will continue to run in a reduced functionality mode - specifically real-time features (such as live presence and live notifications will only work) across an individual server.
Socket Bus does not have an active/active redundancy option. Failover to the passive node could be done manually, with Windows Failover Clustering, or with other monitoring solutions. On failover, the webservers will also need to be configured to the new socket bus server. This could either be done manually, or by using a DNS CNAME record and updating that CNAME on failover.
Co-Locating Telligent Community with other applications
You may co-locate Telligent Community on the same hardware as other applications, however, be aware that when doing so, the performance of other applications may affect the performance of Telligent Community (and vice versa) if the shared hardware does not have enough resources to handle all applications
- IIS - Set Memory Limits on app pools (1.5-2 GB recommended for Community). Also, consider using IIS CPU Throttling to ensure that no IIS website takes overall CPU resources