snapshot of https://github.com/mattermost/mattermost.git (master, 2026-09-16; blobs > 131072B omitted)
Some checks failed
Server CI / Postgres (shard 0) (push) Has been skipped
Server CI / Postgres (shard 3) (push) Has been skipped
BuildEnv Docker Image / build-image (push) Failing after 4s
BuildEnv Docker Image / build-image-fips (push) Failing after 4s
Migration Review & Release Notes / Generate migration review & release notes (push) Failing after 3s
Server CI / Build Environment (push) Failing after 3s
Server CI / Postgres (shard 1) (push) Has been skipped
Tools CI / check-style (mattermost-govet) (push) Failing after 4s
Server CI / Postgres (shard 2) (push) Has been skipped
Tools CI / check-style (mmgotool) (push) Failing after 3s
Server CI / Elasticsearch v8 Compatibility (push) Has been skipped
Server CI / OpenSearch v2 Compatibility (push) Has been skipped
Server CI / Postgres FIPS (shard 0) (push) Has been skipped
Tools CI / Test (mattermost-govet) (push) Failing after 3s
Server CI / Postgres FIPS (shard 1) (push) Has been skipped
Server CI / Postgres FIPS (shard 2) (push) Has been skipped
Tools CI / Test (mmgotool) (push) Failing after 3s
Server CI / Postgres FIPS (shard 3) (push) Has been skipped
Server CI / Run mmctl tests (push) Has been skipped
Server CI / Run mmctl tests (FIPS) (push) Has been skipped
Server CI / Merge Postgres Test Results (push) Has been skipped
Server CI / Merge Postgres FIPS Test Results (push) Has been skipped
Server CI / Check backport migrations (push) Has been skipped
Server CI / Check generated files (push) Has been skipped
Server CI / check-style (push) Has been skipped
Server CI / Vet API (push) Has been skipped
Server CI / Build mattermost server app (push) Has been skipped
Server CI / Server CI Complete (push) Failing after 2s
Server CI / Server CI Artifacts (push) Has been skipped
Server CI / Sentry Upload (push) Has been skipped
Server CI / Server CI Report (push) Failing after 5m1s
Server CI Nightly Race / Race Detector (push) Has been skipped
CodeQL / Analyze (go) (push) Has been cancelled
CodeQL / Analyze (javascript) (push) Has been cancelled
Webapp CI Cache Warm / Warm Webapp node_modules Cache (push) Has been cancelled
E2E CI Cache Warm / Warm E2E npm Registry Cache (push) Has been cancelled
API / build (push) Has been cancelled
Web App CI / check-types (push) Has been cancelled
Web App CI / check-lint (push) Has been cancelled
Web App CI / check-i18n (push) Has been cancelled
Web App CI / check-external-links (push) Has been cancelled
Web App CI / test (platform) (push) Has been cancelled
Web App CI / test (mattermost-redux) (push) Has been cancelled
Web App CI / test (channels shard 1/4) (push) Has been cancelled
Web App CI / test (channels shard 2/4) (push) Has been cancelled
Web App CI / test (channels shard 3/4) (push) Has been cancelled
Web App CI / test (channels shard 4/4) (push) Has been cancelled
Web App CI / upload-coverage (push) Has been cancelled
Web App CI / build (push) Has been cancelled
YAML Lint / yamllint (push) Has been cancelled
Push mirrored docker images / cd/Push mirrored docker images (push) Has been cancelled
docs-cd / Build and deploy docs (push) Has been cancelled
Docs CI / build (push) Has been cancelled
E2E Cache Warm: Cypress deps / Warm Cypress deps cache (push) Has been cancelled
Scorecards supply-chain security / Scorecard analysis (push) Has been cancelled
Server CI Weekly / Postgres FIPS (push) Has been skipped
Server CI Weekly / Run mmctl tests (FIPS) (push) Has been skipped
Server CI Weekly / Postgres with binary parameters (push) Has been skipped
Server CI Weekly / Build Environment (push) Failing after 1s
Server CI Cache Warm / Warm Go Module and Build Cache (push) Failing after 2s
Server CI Nightly Race / Build Environment (push) Failing after 1s
Some checks failed
Server CI / Postgres (shard 0) (push) Has been skipped
Server CI / Postgres (shard 3) (push) Has been skipped
BuildEnv Docker Image / build-image (push) Failing after 4s
BuildEnv Docker Image / build-image-fips (push) Failing after 4s
Migration Review & Release Notes / Generate migration review & release notes (push) Failing after 3s
Server CI / Build Environment (push) Failing after 3s
Server CI / Postgres (shard 1) (push) Has been skipped
Tools CI / check-style (mattermost-govet) (push) Failing after 4s
Server CI / Postgres (shard 2) (push) Has been skipped
Tools CI / check-style (mmgotool) (push) Failing after 3s
Server CI / Elasticsearch v8 Compatibility (push) Has been skipped
Server CI / OpenSearch v2 Compatibility (push) Has been skipped
Server CI / Postgres FIPS (shard 0) (push) Has been skipped
Tools CI / Test (mattermost-govet) (push) Failing after 3s
Server CI / Postgres FIPS (shard 1) (push) Has been skipped
Server CI / Postgres FIPS (shard 2) (push) Has been skipped
Tools CI / Test (mmgotool) (push) Failing after 3s
Server CI / Postgres FIPS (shard 3) (push) Has been skipped
Server CI / Run mmctl tests (push) Has been skipped
Server CI / Run mmctl tests (FIPS) (push) Has been skipped
Server CI / Merge Postgres Test Results (push) Has been skipped
Server CI / Merge Postgres FIPS Test Results (push) Has been skipped
Server CI / Check backport migrations (push) Has been skipped
Server CI / Check generated files (push) Has been skipped
Server CI / check-style (push) Has been skipped
Server CI / Vet API (push) Has been skipped
Server CI / Build mattermost server app (push) Has been skipped
Server CI / Server CI Complete (push) Failing after 2s
Server CI / Server CI Artifacts (push) Has been skipped
Server CI / Sentry Upload (push) Has been skipped
Server CI / Server CI Report (push) Failing after 5m1s
Server CI Nightly Race / Race Detector (push) Has been skipped
CodeQL / Analyze (go) (push) Has been cancelled
CodeQL / Analyze (javascript) (push) Has been cancelled
Webapp CI Cache Warm / Warm Webapp node_modules Cache (push) Has been cancelled
E2E CI Cache Warm / Warm E2E npm Registry Cache (push) Has been cancelled
API / build (push) Has been cancelled
Web App CI / check-types (push) Has been cancelled
Web App CI / check-lint (push) Has been cancelled
Web App CI / check-i18n (push) Has been cancelled
Web App CI / check-external-links (push) Has been cancelled
Web App CI / test (platform) (push) Has been cancelled
Web App CI / test (mattermost-redux) (push) Has been cancelled
Web App CI / test (channels shard 1/4) (push) Has been cancelled
Web App CI / test (channels shard 2/4) (push) Has been cancelled
Web App CI / test (channels shard 3/4) (push) Has been cancelled
Web App CI / test (channels shard 4/4) (push) Has been cancelled
Web App CI / upload-coverage (push) Has been cancelled
Web App CI / build (push) Has been cancelled
YAML Lint / yamllint (push) Has been cancelled
Push mirrored docker images / cd/Push mirrored docker images (push) Has been cancelled
docs-cd / Build and deploy docs (push) Has been cancelled
Docs CI / build (push) Has been cancelled
E2E Cache Warm: Cypress deps / Warm Cypress deps cache (push) Has been cancelled
Scorecards supply-chain security / Scorecard analysis (push) Has been cancelled
Server CI Weekly / Postgres FIPS (push) Has been skipped
Server CI Weekly / Run mmctl tests (FIPS) (push) Has been skipped
Server CI Weekly / Postgres with binary parameters (push) Has been skipped
Server CI Weekly / Build Environment (push) Failing after 1s
Server CI Cache Warm / Warm Go Module and Build Cache (push) Failing after 2s
Server CI Nightly Race / Build Environment (push) Failing after 1s
This commit is contained in:
upstream-mirror
@@ -0,0 +1,7 @@
|
||||
---
|
||||
title: Additional HA considerations
|
||||
unlisted: true
|
||||
---
|
||||
[Elasticsearch](https://www.elastic.co) provides enterprise-scale deployments with optimized search performance and prevents performance degradation and timeouts. Elasticsearch allows you to search large volumes of data quickly, in near real-time, by creating and managing an index of post data. Mattermost’s implementation uses [Elasticsearch](https://www.elastic.co) as a distributed, RESTful search engine supporting highly efficient database searches in a [cluster environment](/deployment-guide/server/high-availability-cluster-based-deployment). Visit the [Mattermost Elasticsearch product documentation](/deployment-guide/scale/elasticsearch-setup) for deployment and configuration details.
|
||||
|
||||
Performance monitoring support enables a Mattermost server to track system health for large Enterprise deployments through integrations with [Prometheus](https://prometheus.io/) and [Grafana](https://grafana.com/). These integrations support data collection from several Mattermost servers, which is particularly useful if you’re running Mattermost [in high availability mode](/deployment-guide/server/high-availability-cluster-based-deployment). Once you’re tracking system health, you can [set up performance alerts](/administration-guide/scale/performance-alerting) on your Grafana dashboard. Visit the [Mattermost Performance Monitoring product documentation](/administration-guide/scale/deploy-prometheus-grafana-for-performance-monitoring) for installation details.
|
||||
156
docs/main/deployment-guide/scale/backing-storage-benchmarks.mdx
Normal file
156
docs/main/deployment-guide/scale/backing-storage-benchmarks.mdx
Normal file
@@ -0,0 +1,156 @@
|
||||
---
|
||||
title: "Backing storage benchmarks"
|
||||
---
|
||||
Understanding the performance characteristics of your backing storage is critical for optimizing your Mattermost deployment. These benchmarks offer insights into the relative performance of each storage option, helping you make informed decisions based on your use case and infrastructure needs.
|
||||
|
||||
This page provides detailed write and read benchmark results for supported storage options including [local file system (EBS, gp3)](#local), [network file system (EFS)](#efs), and [object storage (S3)](#s3).
|
||||
|
||||
## Write operations
|
||||
|
||||
<table style={{width: '73%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '10%'}} />
|
||||
<col style={{width: '20%'}} />
|
||||
<col style={{width: '20%'}} />
|
||||
<col style={{width: '22%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>File Size</th>
|
||||
<th>Local (EBS)</th>
|
||||
<th>EFS</th>
|
||||
<th>S3</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>100KB</td>
|
||||
<td>0.57 ms (±0.26 ms, p50: 0.63 ms)</td>
|
||||
<td>34.47 ms (±6.33 ms, p50: 32.57 ms)</td>
|
||||
<td>181.59 ms (±39.05 ms, p50: 174.83 ms)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1MB</td>
|
||||
<td>2.08 ms (±0.92 ms, p50: 2.28 ms)</td>
|
||||
<td>57.43 ms (±7.32 ms, p50: 58.16 ms)</td>
|
||||
<td>277.13 ms (±49.95 ms, p50: 279.36 ms)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>10MB</td>
|
||||
<td>18.15 ms (±5.31 ms, p50: 18.23 ms)</td>
|
||||
<td>180.58 ms (±97.95 ms, p50: 150.35 ms)</td>
|
||||
<td>469.29 ms (±166.32 ms, p50: 462.12 ms)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>100MB</td>
|
||||
<td>585.14 ms (±274.38 ms, p50: 795.78 ms)</td>
|
||||
<td>390.87 ms (±166.32 ms, p50: 339.20 ms)</td>
|
||||
<td>1.09 s (±0.04 s, p50: 1.09 s)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1GB</td>
|
||||
<td>7.42 s (±2.13 s, p50: 7.99 s)</td>
|
||||
<td>3.05 s (±1.09 s, p50: 2.93 s)</td>
|
||||
<td>10.65 s (±0.82 s, p50: 10.44 s)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>10GB</td>
|
||||
<td>70.66 s (±7.05 s, p50: 80.50 s)</td>
|
||||
<td>26.54 s (±2.47 s, p50: 26.86 s)</td>
|
||||
<td>109.05 s (±12.47 s, p50: 105.13 s)</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<Note>
|
||||
|
||||
**Write Performance**: Local EBS storage is fastest for small files (100KB - 10MB), while EFS performs better for larger files (100MB - 10GB). S3 is consistently the slowest for writes across all file sizes.
|
||||
|
||||
</Note>
|
||||
|
||||
## Read operations
|
||||
|
||||
<table style={{width: '74%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '10%'}} />
|
||||
<col style={{width: '20%'}} />
|
||||
<col style={{width: '20%'}} />
|
||||
<col style={{width: '22%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>File Size</th>
|
||||
<th>Local (EBS)</th>
|
||||
<th>EFS</th>
|
||||
<th>S3</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>100KB</td>
|
||||
<td>0.05 ms (±0.02 ms, p50: 0.04 ms)</td>
|
||||
<td>0.66 ms (±0.17 ms, p50: 0.60 ms)</td>
|
||||
<td>28.55 ms (±4.12 ms, p50: 27.63 ms)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1MB</td>
|
||||
<td>0.18 ms (±0.06 ms, p50: 0.18 ms)</td>
|
||||
<td>0.82 ms (±0.19 ms, p50: 0.72 ms)</td>
|
||||
<td>27.03 ms (±4.28 ms, p50: 27.54 ms)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>10MB</td>
|
||||
<td>1.27 ms (±0.27 ms, p50: 1.16 ms)</td>
|
||||
<td>7.83 ms (±18.12 ms, p50: 1.68 ms)</td>
|
||||
<td>108.24 ms (±0.56 ms, p50: 108.18 ms)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>100MB</td>
|
||||
<td>16.50 ms (±0.95 ms, p50: 16.16 ms)</td>
|
||||
<td>73.53 ms (±182.32 ms, p50: 16.91 ms)</td>
|
||||
<td>1.05 s (±0.00 s, p50: 1.05 s)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1GB</td>
|
||||
<td>167.89 ms (±2.19 ms, p50: 167.72 ms)</td>
|
||||
<td>773.41 ms (±1768.89 ms p50: 168.17 ms)</td>
|
||||
<td>10.49 s (±0.02 s, p50: 10.49 s)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>10GB</td>
|
||||
<td>1.57 s (±0.03 s, p50: 1.56 s)</td>
|
||||
<td>1.56 s (±0.02 s, p50: 1.55 s)</td>
|
||||
<td>150.66 s (±33.47 s, p50: 146.51 s)</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<Note>
|
||||
|
||||
- **Read Performance**: Local and EFS have comparable read performance for very large files (10GB), but local storage outperforms for smaller files. S3 read performance is significantly slower, especially for large files (150.66s versus ~1.56s for 10GB files).
|
||||
- **Consistency**: Local storage shows the most consistent performance (lower standard deviations) for small files, while EFS shows more consistent performance for large files. S3 generally has higher variability across all metrics.
|
||||
- **Median vs Average**: The median (p50) values generally align with the averages, but in some cases (particularly EFS read operations), the median reveals that outliers significantly affect the average. For example, EFS read performance for 100MB and 1GB files shows much better median values than averages.
|
||||
|
||||
</Note>
|
||||
|
||||
|
||||
|
||||
## Testing notes
|
||||
|
||||
- For S3 tests, [Amazon S3 exported upload part size](/administration-guide/configure/environment-configuration-settings#amazon-s3-upload-part-size) was set to the default value (100MB).
|
||||
- Local EBS storage is the stock gp3 (3000 IOPS) provided by EC2 instances.
|
||||
- Both EBS and EFS solutions tested are considered `local` storage options from the application's perspective, where the [file storage system](/administration-guide/configure/environment-configuration-settings#file-storage-system) is set to `local` in both cases. EFS is essentially AWS's managed NFS, which enables it to serve as a potential alternative to S3 by allowing multiple Mattermost nodes in a high-availability (HA) deployment to share a common file system. In such HA scenarios, the standard local file storage (e.g., an EBS volume attached to a single instance) [is not suitable, as it can't be shared across multiple nodes](/deployment-guide/server/high-availability-cluster-based-deployment#file-storage). EFS is a good alternative in this case, but EFS is not a block storage solution like EBS.
|
||||
|
||||
## Supported storage options
|
||||
|
||||
### Local
|
||||
|
||||
The local file system of the Mattermost server. If running in a cloud environment like AWS, this often utilizes Elastic Block Storage (EBS), which provides block-level storage attached directly to the instances. This setup typically offers high performance with low latency since the storage is local to the server. This option is often the fastest for small files due to low latency.
|
||||
|
||||
### EFS
|
||||
|
||||
Amazon Elastic File System, a managed file storage solution that supports shared access across multiple instances. EFS supports shared access across multiple instances but adds network overhead, which can impact performance compared to local storage options. EFS is generally slower than local storage but can be beneficial for certain use cases requiring shared access.
|
||||
|
||||
### S3
|
||||
|
||||
Amazon Simple Storage Service, an object storage solution that provides high durability and scalability. While S3 is great for storing large amounts of data reliably, it introduces higher latency and slower performance due to network-based access and its nature as object storage rather than block or file storage.
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
title: "Set server connection details"
|
||||
unlisted: true
|
||||
---
|
||||
{/* Snippet include: imported by elasticsearch-setup and opensearch-setup. Kept as
|
||||
its own page because admin-onboarding-tasks deep-links to its "enterprise
|
||||
search limitations" anchor. */}
|
||||
1. (Optional) Enter **Server Username** used to access the enterprise search server.
|
||||
2. (Optional) Enter **Server Password** associated with the username.
|
||||
3. Set **Enable Cluster Sniffing** (Optional). Sniffing finds and connects to all data nodes in your cluster automatically.
|
||||
|
||||
<Warning>
|
||||
|
||||
Do not enable cluster sniffing when using cloud-hosted search providers such as Elastic Cloud or Amazon OpenSearch Service. Cloud providers typically hide search cluster nodes behind a proxy, so sniffed node addresses may be unreachable from your network. The provider handles connection pooling for you, making sniffing unnecessary and potentially disruptive.
|
||||
|
||||
</Warning>
|
||||
|
||||
4. Optional CA and client certificate configuration settings are available for use with basic authentication credentials or to replace them. See the [Enterprise search configuration settings](/administration-guide/configure/environment-configuration-settings#enterprise-search) documentation for details.
|
||||
5. Select **Test Connection** and then select **Save**. If the server connection is unsuccessful you won't be able to save the configuration or enable searching with Elasticsearch or AWS OpenSearch.
|
||||
|
||||
<Note>
|
||||
|
||||
From Mattermost v11, enterprise search server connections are tested during [Support Packet generation](/administration-guide/manage/admin/generating-support-packet). Any connection errors encountered during Support Packet generation are automatically included in the packet to help diagnose configuration issues.
|
||||
|
||||
</Note>
|
||||
|
||||
# Build the post index of existing messages
|
||||
|
||||
Select **Index Now**. This process can take up to a few hours depending on the size of the post database and number of messages. The progress percentage can be seen as the index is created. To avoid downtime, set **Enable Elasticsearch for search queries** to `false` so that database search is available during the indexing process.
|
||||
|
||||
# Enable enterprise search
|
||||
|
||||
Ensure bulk indexing is complete before enabling enterprise search, otherwise search results will be incomplete.
|
||||
|
||||
Set **Enable Elasticsearch for search queries** to `true`, and setting **Enable Elasticsearch for autocomplete** to `true`. Save your configuration updates and restart the Mattermost server.
|
||||
|
||||
<Note>
|
||||
|
||||
For high post volume deployments, we strongly encourage you to read and properly configure the Mattermost [LiveIndexingBatchSize](/administration-guide/configure/environment-configuration-settings#live-indexing-batch-size) configuration setting.
|
||||
|
||||
</Note>
|
||||
|
||||
<Warning>
|
||||
|
||||
For high post volume deployments, we also strongly recommend *disabling* Database Search once Elasticsearch or AWS OpenSearch is fully configured and running. The Mattermost Server will fall back on Database search if Elasticsearch or OpenSearch are unavailable, which can lead to performance degradation on high post volume deployments. From Mattermost v11.7, the server proactively detects outages through periodic health checks and falls back to database search on the first health check failure, rather than waiting for requests to time out. See the [outage handling FAQ](/deployment-guide/scale/enterprise-search#how-does-mattermost-handle-elasticsearch-or-opensearch-outages) for details.
|
||||
|
||||
</Warning>
|
||||
|
||||
Once the configuration is saved, new posts made to the database are automatically indexed on the Elasticsearch or AWS OpenSearch server.
|
||||
|
||||
## Enterprise search limitations
|
||||
|
||||
1. Elasticsearch and AWS OpenSearch use a standard selection of "stop words" to keep search results relevant. Results for the following words will not be returned: "a", "an", "and", "are", "as", "at", "be", "but", "by", "for", "if", "in", "into", "is", "it", "no", "not", "of", "on", "or", "such", "that", "the", "their", "then", "there", "these", "they", "this", "to", "was", "will", and "with".
|
||||
2. Searching stop words in quotes returns more results than just the searched terms ([ticket](https://mattermost.atlassian.net/browse/MM-7216)).
|
||||
3. By default, search results are limited to a user's team and channel membership. This is enforced by the Mattermost server. The entities are indexed in Elasticsearch or AWS OpenSearch in a way that allows Mattermost to filter them when querying, so the Mattermost server narrows down the results on every Elasticsearch or AWS OpenSearch request applying those filters. From Mattermost v11.6, admins can [allow searching public channels without membership](/administration-guide/configure/environment-configuration-settings#allow-searching-public-channels-without-membership) so that users can find messages in public channels they haven't joined, scoped to teams they belong to.
|
||||
4. User search and autocomplete served by Elasticsearch or AWS OpenSearch match on username, nickname, and first and last name only. Email addresses aren't indexed, so no user can be found by email address, including system admins. User searches served from the database continue to match on email address. For channel and team member searches, system admins always match on email address, and all other users also require [Show email address](/administration-guide/configure/site-configuration-settings#show-email-address) to be enabled. The **System Console > User Management > Users** list always matches on email address, independently of that setting.
|
||||
123
docs/main/deployment-guide/scale/elasticsearch-setup.mdx
Normal file
123
docs/main/deployment-guide/scale/elasticsearch-setup.mdx
Normal file
@@ -0,0 +1,123 @@
|
||||
---
|
||||
title: "Elasticsearch server setup"
|
||||
---
|
||||
import Inc0_common_configure_mattermost_for_enterprise_search from './common-configure-mattermost-for-enterprise-search.mdx';
|
||||
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
Elasticsearch allows you to search large volumes of data quickly, in near real-time, by creating and managing an index of post data. The indexing process can be managed from the System Console after setting up and connecting an Elasticsearch server. The post index is stored on the Elasticsearch server and updated constantly after new posts are made. In order to index existing posts, a bulk index of the entire post database must be generated.
|
||||
|
||||
Deploying Elasticsearch includes the following two steps: [setting up Elasticsearch](#set-up-elasticsearch), and [configuring Mattermost](#configure-mattermost).
|
||||
|
||||
## Set up Elasticsearch
|
||||
|
||||
We highly recommend that you set up Elasticsearch server on a dedicated machine separate from the Mattermost Server.
|
||||
|
||||
1. Download and install the latest release of [Elasticsearch v9](https://www.elastic.co/guide/en/elasticsearch/reference/current/install-elasticsearch.html) or [Elasticsearch v8](https://www.elastic.co/guide/en/elasticsearch/reference/8.19/install-elasticsearch.html). See the Elasticsearch documentation for installation details.
|
||||
2. Set up Elasticsearch with `systemd` by running the following commands:
|
||||
|
||||
> ``` sh
|
||||
> sudo /bin/systemctl daemon-reload
|
||||
> sudo /bin/systemctl enable elasticsearch.service
|
||||
> sudo systemctl start elasticsearch.service
|
||||
> ```
|
||||
|
||||
3. Confirm Elasticsearch is working on the server by running the following command:
|
||||
|
||||
> ``` sh
|
||||
> curl localhost:9200
|
||||
> ```
|
||||
|
||||
4. Get your network interface name by running the following command:
|
||||
|
||||
> ``` sh
|
||||
> ip addr
|
||||
> ```
|
||||
|
||||
5. Edit the Elasticsearch configuration file in `vi` by running the following command:
|
||||
|
||||
> ``` sh
|
||||
> vi /etc/elasticsearch/elasticsearch.yml
|
||||
> ```
|
||||
|
||||
6. In this file, replace the `network.host` value of `_eth0_` with your network interface name, and save your changes.
|
||||
7. Ensure you set `action.destructive_requires_name` to `false` in `elasticsearch.yml` to allow for wildcard operations to work.
|
||||
8. Restart Elasticsearch by running the following commands:
|
||||
|
||||
> ``` sh
|
||||
> sudo systemctl stop elasticsearch
|
||||
> sudo systemctl start elasticsearch
|
||||
> ```
|
||||
|
||||
9. Confirm the ports are listenings by running the following command:
|
||||
|
||||
> ``` sh
|
||||
> netstat -plnt
|
||||
> ```
|
||||
>
|
||||
> You should see the following ports, including the ones listening on ports 9200 and 9300. Confirm these are listening on your server's IP address.
|
||||
|
||||
10. Create an Elasticsearch directory and give it the proper permissions.
|
||||
11. Install the [icu-analyzer plugin](https://www.elastic.co/guide/en/elasticsearch/plugins/current/analysis-icu.html) to the `/usr/share/elasticsearch/plugins` directory by running the following command:
|
||||
|
||||
> <Important>
|
||||
>
|
||||
> The `analysis-icu` plugin is **required on every node in the cluster**, not optional. Mattermost's post and file index templates depend on it. Without the plugin, Mattermost cannot create these templates.
|
||||
>
|
||||
> </Important>
|
||||
>
|
||||
> ``` sh
|
||||
> sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-icu
|
||||
> ```
|
||||
>
|
||||
> Restart Elasticsearch on each node to load the newly installed plugin before verifying it; `_cat/plugins` only reports active plugins, so a restart is required first. For production clusters, restart nodes one at a time (rolling restart) rather than all at once. Confirm the plugin is installed and active on every node before continuing. Replace `<your-elasticsearch-host>` and `<password>`, and update the CA path if needed:
|
||||
>
|
||||
> ``` sh
|
||||
> curl --silent --show-error --fail-with-body --cacert /etc/elasticsearch/certs/http_ca.crt --user 'elastic:<password>' 'https://<your-elasticsearch-host>:9200/_cat/plugins?v&h=name,component,version&s=name,component'
|
||||
> ```
|
||||
>
|
||||
> Running this command should show `analysis-icu` once per node in the cluster. If the `analysis-icu` line is missing for any node, the plugin is not installed there. Use plain HTTP without credentials only for a cluster where Elasticsearch security has been explicitly disabled.
|
||||
>
|
||||
> **(Optional) CJK language analyzer plugins**: To improve search for Korean, Japanese, or Chinese content, install one or more of the following language-specific analyzer plugins: `analysis-nori` (Korean), `analysis-kuromoji` (Japanese), and `analysis-smartcn` (Chinese).
|
||||
>
|
||||
> ``` sh
|
||||
> sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-nori
|
||||
> sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-kuromoji
|
||||
> sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-smartcn
|
||||
> ```
|
||||
>
|
||||
> After installing the CJK plugins, restart Elasticsearch to load them:
|
||||
>
|
||||
> ``` sh
|
||||
> sudo systemctl restart elasticsearch
|
||||
> ```
|
||||
>
|
||||
> Then enable the [EnableCJKAnalyzers](/administration-guide/configure/environment-configuration-settings#enable-cjk-analyzers) configuration setting. See [Enabling Chinese, Japanese, and Korean Search](/administration-guide/configure/enabling-chinese-japanese-korean-search) for additional CJK search configuration options.
|
||||
>
|
||||
> <div class="important">
|
||||
>
|
||||
> <div class="title">
|
||||
>
|
||||
> Important
|
||||
>
|
||||
> </div>
|
||||
>
|
||||
> If you enable CJK analyzers on a server with existing indexed content, you must purge and rebuild the search index in **System Console \> Environment \> Elasticsearch** for the CJK analyzers to take effect on existing posts.
|
||||
>
|
||||
> </div>
|
||||
|
||||
12. Test the connection from Mattermost to Elasticsearch by running the following command:
|
||||
|
||||
> ``` sh
|
||||
> curl 172.31.80.220:9200
|
||||
> ```
|
||||
|
||||
## Configure Mattermost
|
||||
|
||||
Follow these steps to configure Mattermost to use your Elasticsearch server and to generate the post index:
|
||||
|
||||
1. Go to **System Console \> Environment \> Elasticsearch**.
|
||||
2. Set **Enable Elasticsearch Indexing** to `true` to enable the other the settings on the page. Once the configuration is saved, new posts made to the database are automatically indexed on the Elasticsearch server.
|
||||
3. Ensure **Backend type** is set to `elasticsearch`.
|
||||
|
||||
<Inc0_common_configure_mattermost_for_enterprise_search />
|
||||
211
docs/main/deployment-guide/scale/enterprise-search.mdx
Normal file
211
docs/main/deployment-guide/scale/enterprise-search.mdx
Normal file
@@ -0,0 +1,211 @@
|
||||
---
|
||||
title: "Enterprise search"
|
||||
---
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
Mattermost database search starts to show performance degradation at around 2 million posts, on a server with 32 GB RAM and 4 CPUs. If you anticipate your Mattermost server reaching more than 2.5 million posts, we recommend enabling [Elasticsearch](#elasticsearch) or [AWS OpenSearch Service](#aws-opensearch-service) for optimum search performance **before** reaching 3 million posts. Both tools are highly capable and can handle enterprise-scale workloads. The choice between them depends on the following factors:
|
||||
|
||||
- **Licensing and cost**: AWS OpenSearch may be preferable for organizations avoiding proprietary licensing or opting for cost-effective solutions.
|
||||
- **Feature requirements**: Elasticsearch's proprietary features (e.g., advanced analytics, security suites) may be preferred by organizations needing powerful out-of-the-box functionality.
|
||||
- **Infrastructure alignment**: AWS OpenSearch aligns well with AWS-centric environments, while Elasticsearch offers broader integrations.
|
||||
|
||||
## Elasticsearch
|
||||
|
||||
Elasticsearch is a well-established and widely used search engine with a large ecosystem and community support that provides enterprise-scale deployments with optimized search performance, dedicated indexing, and usage resourcing via cluster support for fast, predicable search results.
|
||||
|
||||
Mattermost's implementation uses [Elasticsearch](https://www.elastic.co) as a distributed, RESTful search engine supporting highly efficient database searches in a [cluster environment](/deployment-guide/server/high-availability-cluster-based-deployment). Learn more about [setting up and configuring Mattermost for an Elasticsearch server](/deployment-guide/scale/elasticsearch-setup).
|
||||
|
||||
## AWS OpenSearch Service
|
||||
|
||||
AWS OpenSearch Service is the official path forward from Elasticsearch v7.10.x for AWS customers. It's a fully managed service that makes it easy to deploy, operate, and scale OpenSearch clusters in the AWS Cloud to provide a simple and cost-effective way to search, analyze, and visualize data in real time.
|
||||
|
||||
The AWS OpenSearch Service is built on the open-source OpenSearch project, which is a community-driven fork of Elasticsearch. Learn more about [setting up and configuring Mattermost for an OpenSearch server](/deployment-guide/scale/opensearch-setup).
|
||||
|
||||
## Supported paths
|
||||
|
||||
Review the following support paths for enterprise search based on the version you're using:
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="elasticsearch-v9" label="Elasticsearch v9">
|
||||
|
||||
[Elasticsearch v9](https://www.elastic.co/guide/en/elasticsearch/reference/current/elasticsearch-intro.html) is supported from Mattermost v11.7. We recommend upgrading to Elasticsearch v9 for the latest features and security updates. See the [Elasticsearch upgrade](https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-upgrade.html) documentation for upgrade details, and see the [Elasticsearch setup](/deployment-guide/scale/elasticsearch-setup) documentation for details on configuring your Mattermost deployment to use Elasticsearch.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="elasticsearch-v8" label="Elasticsearch v8">
|
||||
|
||||
[Elasticsearch v8](https://www.elastic.co/guide/en/elasticsearch/reference/8.19/elasticsearch-intro.html) is supported from Mattermost v9.11. We recommend upgrading to Elasticsearch v9 for the latest features and security updates. See the [Elasticsearch upgrade](https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-upgrade.html) documentation for upgrade details, and see the [Elasticsearch setup](/deployment-guide/scale/elasticsearch-setup) documentation for details on configuring your Mattermost deployment to use Elasticsearch.
|
||||
|
||||
<Note>
|
||||
|
||||
Elasticsearch v7.17 is no longer supported as of Mattermost v11.7. If you're still using Elasticsearch v7, you must upgrade to Elasticsearch v8 or v9.
|
||||
|
||||
</Note>
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="aws-opensearch-service" label="AWS OpenSearch Service">
|
||||
|
||||
AWS OpenSearch Service is the official path forward from Elasticsearch v7.10.x for AWS customers to provide a simple and cost-effective way to search, analyze, and visual data in real time. It's essentially a continuation of Elasticsearch v7.10.x but maintained as open source by AWS. It provides long-term support, active development, and compatibility with AWS clients, libraries, and managed services.
|
||||
|
||||
See the **AWS Elasticsearch v7.10.x** tab on this page for details on upgrading to AWS OpenSearch, and see the [AWS OpenSearch setup](/deployment-guide/scale/opensearch-setup) documentation for details on configuring your Mattermost deployment to use AWS OpenSearch.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="aws-elasticsearch-v7-10-x" label="AWS Elasticsearch v7.10.x">
|
||||
|
||||
If you're using Elasticsearch v7.10.x under AWS’s managed services, you can't use newer Elasticsearch clients like the v8 or v9 client without changing backend infrastructure. If you're using AWS Elasticsearch v7.10.x, you must [upgrade to AWS OpenSearch](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/version-migration.html) for future compatibility.
|
||||
|
||||
The migration path from Elasticsearch v7.10.x to OpenSearch has been designed to be straightforward, minimizing effort:
|
||||
|
||||
1. Disable "compatibility mode" in OpenSearch.
|
||||
2. Upgrade Mattermost server.
|
||||
3. Update the Mattermost `ElasticsearchSettings.Backend` configuration setting value from `elasticsearch` to `opensearch` manually or using [mmctl](/administration-guide/manage/mmctl-command-line-tool#mmctl-config-set). This value cannot be changed using the System Console. See the Mattermost search [backend type](/administration-guide/configure/environment-configuration-settings#backend-type) configuration setting documentation for additional details.
|
||||
4. Restart the Mattermost server.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
## Frequently asked questions (FAQ)
|
||||
|
||||
### Do I need to use Elasticsearch or AWS OpenSearch?
|
||||
|
||||
No. Enterprise search engines are designed for large Enterprise deployments to run highly efficient database searches in a cluster environment. The default Mattermost database search starts to show performance degradation at around 2.5 million posts, depending on the specifications for the database server. If you expect your Mattermost server to have more than 2.5 million posts, we recommend using Elasticsearch or AWS OpenSearch for optimum search performance.
|
||||
|
||||
### Should I install Elasticsearch or OpenSearch on the same machine as Mattermost Server?
|
||||
|
||||
No. We strongly recommend that you install Elasticsearch or AWS OpenSearch on a dedicated machine that's separate from the Mattermost server.
|
||||
|
||||
### What types of indexes are created?
|
||||
|
||||
Mattermost creates three types of indexes: users, channels, and posts. Users and channels have one index each. Posts are aggregated by date, into multiple indexes.
|
||||
|
||||
### Can I pause an search indexing job?
|
||||
|
||||
Yes. From Mattermost v6.7, the search indexing job is resumable. Stopping a server while the search indexing job is running puts the job in pending status. The job resumes when the server restarts. System admins can cancel an indexing job through the System Console.
|
||||
|
||||
### Can an index rollover policy be defined?
|
||||
|
||||
The [AggregatePostsAfterDays](/administration-guide/configure/environment-configuration-settings#aggregate-search-indexes) configuration setting defines a cutoff value. All posts preceding this value are reindexed and aggregated into new and bigger indexes. The default setting is 365 days.
|
||||
|
||||
### Are there any new search features offered with Elasticsearch?
|
||||
|
||||
The current implementation of Elasticsearch matches the search features currently available with database search. The Mattermost team is working on extending the Elasticsearch feature set with file name and content search, date filters, and operators and modifiers.
|
||||
|
||||
### Are my files stored in Elasticsearch or OpenSearch?
|
||||
|
||||
No, files and attachments are not stored.
|
||||
|
||||
### How do I monitor system health of an Elasticsearch server?
|
||||
|
||||
You can use this Prometheus exporter to monitor [various metrics](https://github.com/justwatchcom/elasticsearch_exporter#metrics) about Elasticsearch: [justwatchcom/elasticsearch_exporter](https://github.com/justwatchcom/elasticsearch_exporter).
|
||||
|
||||
You can also refer to this [article about Elasticsearch performance monitoring](https://www.datadoghq.com/blog/monitor-elasticsearch-performance-metrics/#key-elasticsearch-performance-metrics-to-monitor). It's not written specifically for Prometheus, which [Mattermost's performance monitoring](/administration-guide/scale/deploy-prometheus-grafana-for-performance-monitoring) system uses, but has several tips and best practices.
|
||||
|
||||
### What form of data is sent to Elasticsearch or OpenSearch?
|
||||
|
||||
Mattermost communicates with Elasticsearch or OpenSearch through its REST API using JSON messages for indexing and querying entities.
|
||||
|
||||
### How much data is sent to Elasticsearch or OpenSearch and when?
|
||||
|
||||
Every time a message is published, a channel is created, or a user changes, (either because their properties change e.g.: change of the first name or because they join/leave a channel), the data associated with that event is sent to Elasticsearch or OpenSearch.
|
||||
|
||||
If search via Elasticsearch or OpenSearch is enabled, every search will generate a query. If autocompletion is enabled, every user or channel autocompletion associated with writing a message or user search will generate a query.
|
||||
|
||||
### How do I know if a search job fails?
|
||||
|
||||
Mattermost provides the status of each Elasticsearch or OpenSearch indexing job in **System Console \> Environment \> Elasticsearch**. Here you can see if the job succeeded or failed, including the details of the error.
|
||||
|
||||
Failures are returned in the server logs. The error log begins with the string `Failed job` and includes a job_id key/value pair. Search job failures are identified with worker name `EnterpriseElasticsearchAggregator` and `EnterpriseElasticsearchIndexer`. You can optionally create a script that programmatically queries for such failures and notifies the appropriate system.
|
||||
|
||||
### How do I diagnose enterprise search connection issues?
|
||||
|
||||
From Mattermost v11, [Support Packet generation](/administration-guide/manage/admin/generating-support-packet) automatically tests the connection to your configured Elasticsearch or AWS OpenSearch server and includes any connection errors in the Support Packet. This provides valuable diagnostic information including server version, installed plugins, and specific error details if the connection fails.
|
||||
|
||||
The enterprise search connection test results appear in the Support Packet and can help identify configuration issues such as network connectivity problems, authentication failures, or server availability issues. If connection errors are present, they will be clearly documented with specific error messages to aid in troubleshooting.
|
||||
|
||||
### How does Mattermost handle Elasticsearch or OpenSearch outages?
|
||||
|
||||
From Mattermost v11.7, the server includes an automatic health monitor for Elasticsearch and OpenSearch connections. The health monitor runs periodic health checks and automatically manages the connection lifecycle:
|
||||
|
||||
- **Health checks**: The server checks the health of the search engine cluster every 60 seconds. After 3 consecutive health check failures, the engine is stopped and search falls back to the database.
|
||||
- **Fast-fail on first failure**: On the very first health check failure, the engine is immediately marked as unhealthy and search requests are routed to the database. This happens before the consecutive failure threshold is reached, so users experience minimal disruption.
|
||||
- **Automatic retry**: When the search engine is unavailable, the server retries connecting with exponential backoff, starting at 15 seconds and doubling up to a maximum of 5 minutes between attempts.
|
||||
- **Automatic recovery**: When the search engine becomes available again, the server automatically reconnects and resumes using it for search queries. No manual intervention or server restart is required.
|
||||
- **Configuration changes**: Changes to Elasticsearch or OpenSearch configuration settings, or license changes, immediately trigger the health monitor to re-evaluate the connection state.
|
||||
- **Monitoring**: A `mattermost_search_engine_status` Prometheus metric reports the health of the search engine (`1` = healthy or not configured, `0` = configured but unavailable). Use this metric to [set up alerts](/administration-guide/scale/performance-alerting) for search engine outages. See [performance monitoring metrics](/administration-guide/scale/performance-monitoring-metrics) for details.
|
||||
|
||||
During an outage, you may see the following log messages:
|
||||
|
||||
| Level | Log message | Meaning |
|
||||
|---|---|---|
|
||||
| Error | `Search engine health check failed repeatedly; stopping engine` | The failure threshold was reached and the engine has been stopped. Search falls back to the database. |
|
||||
| Warn | `Search engine health check failed` | An individual health check failed. Includes a `consecutive_failures` count. |
|
||||
| Warn | `Search engine health check failed: it is now marked as unhealthy` | A previously healthy engine failed a health check and has been marked unhealthy. Search requests will fall back to the database immediately. |
|
||||
| Error | `Search engine watcher: Start() failed, will retry` | A reconnection attempt failed. Includes a `next_backoff` field indicating the time until the next retry. |
|
||||
| Info | `Search engine health check succeeded: it is now marked as healthy` | The engine passed a health check after being unhealthy and is now handling search requests again. |
|
||||
| Info | `Search engine watcher: engine started successfully` | The engine has recovered and is active again. |
|
||||
| Info | `Search engine watcher: engine disabled, parking` | The health monitor is idle because the search engine is disabled in configuration. |
|
||||
|
||||
### My search indexes won't complete, what should I do?
|
||||
|
||||
If you have an search indexing job that's paused, it's likely your Elasticsearch or OpenSearch server has restarted. If you restart that server, you must also restart Mattermost to ensure jobs are completed. If restarting the Mattermost server does not resolve the issue, [customers with a Mattermost subscription can contact Mattermost Support](https://mattermost.com/support/) for assistance.
|
||||
|
||||
### Do I need to purge first then bulk index each time?
|
||||
|
||||
Yes. Every time you choose to remove old data (purge), you must follow it up with a bulk index operation to repopulate them with new data. When you purge (delete) indices, you are removing the existing data from Elasticsearch. After purging, if you want to repopulate the indices with fresh data, you perform a bulk index operation to rebuild the indices efficiently. The bulk API allows for indexing, deleting, or updating multiple documents in a single request, which is faster and more efficient than processing documents one by one.
|
||||
|
||||
## Required Permissions For Mattermost Service Account
|
||||
|
||||
In "least privilege" environments you may need to further constrain the service account permissions to limit the access your Elasticsearch or AWS OpenSearch service account has.
|
||||
|
||||
The following JSON provides an example of a "least privilege" permission set that allows Mattermost to operate correctly with Elasticsearch or AWS OpenSearch:
|
||||
|
||||
> ``` json
|
||||
> {
|
||||
> "cluster_permissions": [
|
||||
> "cluster:monitor/*",
|
||||
> "indices:admin/template/put",
|
||||
> "indices:data/write/bulk"
|
||||
> ],
|
||||
> "index_permissions": [
|
||||
> {
|
||||
> "index_patterns": [
|
||||
> "\<IndexPrefix\>*"
|
||||
> ],
|
||||
> "allowed_actions": [
|
||||
> "indices:admin/get",
|
||||
> "indices:admin/create",
|
||||
> "indices:admin/delete",
|
||||
> "indices:admin/mapping/put",
|
||||
> "indices:admin/mappings/fields/get*",
|
||||
> "indices:data/read*",
|
||||
> "indices:data/write*"
|
||||
> ]
|
||||
> }
|
||||
> ]
|
||||
> }
|
||||
> ```
|
||||
|
||||
A simpler, more flexible, and resilient variant of the above would be:
|
||||
|
||||
``` json
|
||||
{
|
||||
"cluster_permissions": [
|
||||
"cluster:monitor/*",
|
||||
"indices:admin/template/put",
|
||||
"indices:data/write/bulk"
|
||||
],
|
||||
"index_permissions": [
|
||||
{
|
||||
"index_patterns": [
|
||||
"\<IndexPrefix\>*"
|
||||
],
|
||||
"allowed_actions": [
|
||||
"indices:*"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: Estimated storage per user, per month
|
||||
unlisted: true
|
||||
---
|
||||
File usage per user varies significantly across industries. The below benchmarks are recommended:
|
||||
|
||||
- **Low usage teams** (1-5 MB/user/month)
|
||||
|
||||
> - Primarily using text messages and links to communicate. Examples would include software development teams that heavily use web-based document creation and management tools, and therefore rarely upload files to the server.
|
||||
|
||||
- **Medium usage teams** (5-25 MB/user/month)
|
||||
|
||||
> - Using a mix of text messages as well as shared documents and images to communicate. Examples might include business teams that may commonly drag and drop screenshots, PDFs and Microsoft Office documents into Mattermost for sharing and review.
|
||||
|
||||
- **High usage teams** (25-100 MB/user/month)
|
||||
|
||||
> - Heaviest utilization comes from teams uploading a high number of large files into Mattermost on a regular basis. Examples include creative teams who share and store artwork and media with tags and commentary in a pipeline production process.
|
||||
9
docs/main/deployment-guide/scale/lifetime-storage.mdx
Normal file
9
docs/main/deployment-guide/scale/lifetime-storage.mdx
Normal file
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: Lifetime storage
|
||||
unlisted: true
|
||||
---
|
||||
To forecast your own storage usage, begin with a Mattermost server approximately 600 MB to 800 MB in size including operating system and database, then add the multiplied product of:
|
||||
|
||||
- Estimated storage per user per month (see below), multiplied by 12 months in a year
|
||||
- Estimated mean average number of users in a year
|
||||
- A 1-2x safety factor
|
||||
341
docs/main/deployment-guide/scale/opensearch-setup.mdx
Normal file
341
docs/main/deployment-guide/scale/opensearch-setup.mdx
Normal file
@@ -0,0 +1,341 @@
|
||||
---
|
||||
title: "AWS OpenSearch server setup"
|
||||
---
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
import Inc0_common_configure_mattermost_for_enterprise_search from './common-configure-mattermost-for-enterprise-search.mdx';
|
||||
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
AWS OpenSearch Service allows you to search large volumes of data quickly, in near real-time, by creating and managing an index of post data. The indexing process can be managed from the System Console after setting up and connecting an OpenSearch server. The post index is stored on the OpenSearch server and updated constantly after new posts are made. In order to index existing posts, a bulk index of the entire post database must be generated.
|
||||
|
||||
Deploying AWS OpenSearch includes the following two steps: [setting up AWS OpenSearch](#set-up-aws-opensearch), and [configuring Mattermost](#configure-mattermost).
|
||||
|
||||
## Set up AWS OpenSearch
|
||||
|
||||
From Mattermost v9.11, beta support is available for [AWS OpenSearch v1.x and v2.x](https://opensearch.org/). This document covers both on‑premises and AWS OpenSearch setup, including manual steps and Terraform examples.
|
||||
|
||||
We highly recommend that you set up an AWS OpenSearch server on a separate machine from the Mattermost server.
|
||||
|
||||
<Important>
|
||||
|
||||
Starting in Mattermost v12.0 (October 2026), OpenSearch v1.x is no longer supported. Upgrading to OpenSearch v2.x or later is required.
|
||||
|
||||
</Important>
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="on-premises-opensearch" label="On-Premises OpenSearch">
|
||||
|
||||
1. To install on-premise OpenSearch, provision a dedicated server (e.g. Ubuntu 22.04 LTS).
|
||||
2. Install Java (OpenSearch requires Java 11+):
|
||||
|
||||
``` sh
|
||||
sudo apt update
|
||||
sudo apt install -y openjdk-11-jdk
|
||||
java -version
|
||||
```
|
||||
|
||||
3. Download & extract OpenSearch 2.x:
|
||||
|
||||
``` sh
|
||||
wget https://artifacts.opensearch.org/releases/bundle/opensearch/2.9.0/opensearch-2.9.0-linux-x64.tar.gz
|
||||
tar -xzf opensearch-2.9.0-linux-x64.tar.gz
|
||||
sudo mv opensearch-2.9.0 /usr/share/opensearch
|
||||
```
|
||||
|
||||
4. Create a dedicated user & set permissions:
|
||||
|
||||
``` sh
|
||||
sudo useradd --no-create-home --shell /bin/false opensearch
|
||||
sudo chown -R opensearch:opensearch /usr/share/opensearch
|
||||
```
|
||||
|
||||
5. Configure systemd:
|
||||
|
||||
``` sh
|
||||
[Unit]
|
||||
Description=OpenSearch
|
||||
Wants=network-online.target
|
||||
After=network-online.target
|
||||
|
||||
[Service]
|
||||
Type=notify
|
||||
User=opensearch
|
||||
Group=opensearch
|
||||
ExecStart=/usr/share/opensearch/bin/opensearch
|
||||
Restart=on-failure
|
||||
LimitNOFILE=65536
|
||||
LimitNPROC=4096
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
6. Edit `opensearch.yml` to include the following:
|
||||
|
||||
``` yaml
|
||||
cluster.name: mattermost-cluster
|
||||
node.name: node-1
|
||||
path.data: /var/lib/opensearch
|
||||
path.logs: /var/log/opensearch
|
||||
network.host: 0.0.0.0
|
||||
discovery.seed_hosts: ["<other-node-ip>"]
|
||||
cluster.initial_master_nodes: ["node-1", "node-2"]
|
||||
```
|
||||
|
||||
<Note>
|
||||
|
||||
Ensure `path.data` and `path.logs` directories exist and are owned by the `opensearch` user before starting the service:
|
||||
|
||||
``` sh
|
||||
sudo mkdir -p /var/lib/opensearch /var/log/opensearch
|
||||
sudo chown -R opensearch:opensearch /var/lib/opensearch /var/log/opensearch
|
||||
```
|
||||
|
||||
</Note>
|
||||
|
||||
7. Enable & start OpenSearch:
|
||||
|
||||
``` sh
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl enable opensearch
|
||||
sudo systemctl start opensearch
|
||||
sudo systemctl status opensearch
|
||||
```
|
||||
|
||||
8. Install the [icu-analyzer plugin](https://docs.opensearch.org/latest/install-and-configure/additional-plugins/index/) to the `/usr/share/opensearch/plugins` directory by running the following command:
|
||||
|
||||
<Important>
|
||||
|
||||
The `analysis-icu` plugin is **required on every node in the cluster**, not optional. Mattermost's post and file index templates depend on it. Without the plugin, Mattermost cannot create these templates.
|
||||
|
||||
</Important>
|
||||
|
||||
``` sh
|
||||
sudo /usr/share/opensearch/bin/opensearch-plugin install analysis-icu
|
||||
```
|
||||
|
||||
Restart OpenSearch on each node to load the newly installed plugin before verifying it; `_cat/plugins` only reports active plugins, so a restart is required first. For production clusters, restart nodes one at a time (rolling restart) rather than all at once. Confirm the plugin is installed and active on every node before continuing. Replace the host, admin password, and path to your cluster's CA certificate:
|
||||
|
||||
``` sh
|
||||
curl --silent --show-error --fail-with-body --cacert <path-to-root-ca.pem> --user 'admin:<password>' 'https://<your-opensearch-host>:9200/_cat/plugins?v&h=name,component,version&s=name,component'
|
||||
```
|
||||
|
||||
Running this command should show `analysis-icu` once per node in the cluster. If the `analysis-icu` line is missing for any node, the plugin is not installed there.
|
||||
|
||||
**(Optional) CJK language analyzer plugins**: To improve search for Korean, Japanese, or Chinese content, install one or more of the following language-specific analyzer plugins: `analysis-nori` (Korean), `analysis-kuromoji` (Japanese), and `analysis-smartcn` (Chinese).
|
||||
|
||||
``` sh
|
||||
sudo /usr/share/opensearch/bin/opensearch-plugin install analysis-nori
|
||||
sudo /usr/share/opensearch/bin/opensearch-plugin install analysis-kuromoji
|
||||
sudo /usr/share/opensearch/bin/opensearch-plugin install analysis-smartcn
|
||||
```
|
||||
|
||||
After installing the CJK plugins, restart OpenSearch to load them:
|
||||
|
||||
``` sh
|
||||
sudo systemctl restart opensearch
|
||||
```
|
||||
|
||||
Then enable the [EnableCJKAnalyzers](/administration-guide/configure/environment-configuration-settings#enable-cjk-analyzers) configuration setting. See [Enabling Chinese, Japanese, and Korean Search](/administration-guide/configure/enabling-chinese-japanese-korean-search) for additional CJK search configuration options.
|
||||
|
||||
<Important>
|
||||
|
||||
If you enable CJK analyzers on a server with existing indexed content, you must purge and rebuild the search index in **System Console \> Environment \> Elasticsearch** for the CJK analyzers to take effect on existing posts.
|
||||
|
||||
</Important>
|
||||
|
||||
## Terraform (Docker) Example
|
||||
|
||||
``` sh
|
||||
provider "docker" {
|
||||
host = "unix:///var/run/docker.sock"
|
||||
}
|
||||
|
||||
resource "docker_image" "opensearch" {
|
||||
name = "opensearchproject/opensearch:2.9.0"
|
||||
}
|
||||
|
||||
resource "docker_container" "opensearch" {
|
||||
name = "opensearch"
|
||||
image = docker_image.opensearch.latest
|
||||
|
||||
ports {
|
||||
internal = 9200
|
||||
external = 9200
|
||||
}
|
||||
ports {
|
||||
internal = 9600
|
||||
external = 9600
|
||||
}
|
||||
|
||||
env = [
|
||||
"cluster.name=mattermost-cluster",
|
||||
"network.host=0.0.0.0",
|
||||
"discovery.type=single-node", # remove for multi-node
|
||||
]
|
||||
|
||||
restart = "unless-stopped"
|
||||
}
|
||||
|
||||
resource "null_resource" "install_icu_plugin" {
|
||||
depends_on = [docker_container.opensearch]
|
||||
|
||||
provisioner "local-exec" {
|
||||
command = "docker exec opensearch /usr/share/opensearch/bin/opensearch-plugin install analysis-icu && docker restart opensearch"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="aws-opensearch-console-setup" label="AWS OpenSearch Console Setup">
|
||||
|
||||
1. To install AWS OpenSearch, open the **AWS Console \> OpenSearch Service**.
|
||||
2. Create a domain, where:
|
||||
|
||||
- Domain name: `mattermost-os`
|
||||
- Engine version: `OpenSearch 2.x`.
|
||||
|
||||
3. Configure the cluster, where:
|
||||
|
||||
- instance type: `r6g.xlarge.search`
|
||||
- data nodes: 2
|
||||
- master nodes: 2
|
||||
- storage: EBS gp3 (1536 GiB, 4608 IOPS, 250 MiB/s)
|
||||
|
||||
4. Specify the network for: VPC with 2 subnets, and a security group allowing Mattermost IPs on port `443`.
|
||||
|
||||
<Note>
|
||||
|
||||
Port 9200 is commonly used for local or on-premise OpenSearch. The AWS OpenSearch domain only supports HTTPS over port 443.
|
||||
|
||||
</Note>
|
||||
|
||||
5. Configure the access policy (JSON). Mattermost doesn't sign OpenSearch requests with AWS SigV4, so restrict access at the network layer with the VPC and security group from step 4, and use an open principal in the domain access policy:
|
||||
|
||||
``` sh
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [{
|
||||
"Effect": "Allow",
|
||||
"Principal": { "AWS": "*" },
|
||||
"Action": "es:ESHttp*",
|
||||
"Resource": "arn:aws:es:us-east-1:123456789012:domain/mattermost-os/*" }]
|
||||
}
|
||||
```
|
||||
|
||||
<Warning>
|
||||
|
||||
IAM principal-based access policies (for example, `"Principal": { "AWS": "arn:aws:iam::<account-id>:role/<role-name>" }`) are not supported. Mattermost's OpenSearch client doesn't sign requests with AWS SigV4, so AWS treats the requests as anonymous and an IAM-restricted policy will reject them with `User: anonymous is not authorized to perform: es:ESHttpGet`. If you need authentication enforced at the OpenSearch layer rather than the network layer, enable [fine-grained access control](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/fgac.html) on the domain with an internal master user, and enter those credentials as the **Server Username** and **Server Password** in the Mattermost Elasticsearch configuration.
|
||||
|
||||
</Warning>
|
||||
|
||||
6. Configure the following advanced settings (JSON):
|
||||
|
||||
``` sh
|
||||
{
|
||||
"action.destructive_requires_name": "false",
|
||||
"rest.action.multi.allow_explicit_index": "true",
|
||||
"indices.query.bool.max_clause_count": "1024",
|
||||
"indices.fielddata.cache.size": "20"
|
||||
}
|
||||
```
|
||||
|
||||
7. Configure the automated snapshot start hour as 23 (UTC), enforce HTTPS, then review & create.
|
||||
8. To test, run the following command:
|
||||
|
||||
``` sh
|
||||
curl https://mattermost-os-xxxxxxxxxxx.us-east-1.es.amazonaws.com
|
||||
```
|
||||
|
||||
## AWS Terraform Example
|
||||
|
||||
``` sh
|
||||
provider "aws" {
|
||||
region = "us-east-1"
|
||||
}
|
||||
|
||||
resource "aws_iam_role" "os_service_role" {
|
||||
name = "OSServiceRole"
|
||||
assume_role_policy = <<EOF
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [{
|
||||
"Action": "sts:AssumeRole",
|
||||
"Effect": "Allow",
|
||||
"Principal": { "Service": "es.amazonaws.com" }
|
||||
}]
|
||||
}
|
||||
EOF
|
||||
}
|
||||
|
||||
resource "aws_opensearch_domain" "mattermost" {
|
||||
domain_name = "mattermost-os"
|
||||
engine_version = "OpenSearch_2.9"
|
||||
cluster_config {
|
||||
instance_type = "r6g.xlarge.search"
|
||||
instance_count = 2
|
||||
dedicated_master_enabled = true
|
||||
dedicated_master_type = "r6g.xlarge.search"
|
||||
dedicated_master_count = 2
|
||||
zone_awareness_enabled = true
|
||||
}
|
||||
|
||||
ebs_options {
|
||||
ebs_enabled = true
|
||||
volume_type = "gp3"
|
||||
volume_size = 1536
|
||||
iops = 4608
|
||||
}
|
||||
|
||||
vpc_options {
|
||||
subnet_ids = ["subnet-blah1", "subnet-blah2"]
|
||||
security_group_ids = ["sg-1234567890"]
|
||||
}
|
||||
|
||||
advanced_options = {
|
||||
"rest.action.multi.allow_explicit_index" = "true"
|
||||
"indices.query.bool.max_clause_count" = "1024"
|
||||
"indices.fielddata.cache.size" = "20"
|
||||
"action.destructive_requires_name" = "false"
|
||||
}
|
||||
|
||||
access_policies = <<POLICY
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [{
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "*"
|
||||
},
|
||||
"Action": "es:ESHttp*",
|
||||
"Resource": "arn:aws:es:us-east-1:123456789012:domain/mattermost-os/*"
|
||||
}]
|
||||
}
|
||||
POLICY
|
||||
service_software_options {
|
||||
automated_snapshot_start_hour = 23
|
||||
}
|
||||
|
||||
domain_endpoint_options {
|
||||
enforce_https = true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
## Configure Mattermost
|
||||
|
||||
Follow these steps to configure Mattermost to use your AWS OpenSearch server and to generate the post index:
|
||||
|
||||
1. Go to **System Console \> Environment \> Elasticsearch**.
|
||||
2. Set **Enable Elasticsearch Indexing** to `true` to enable the other the settings on the page.
|
||||
3. Ensure **Backend type** is set to `opensearch`.
|
||||
4. Set the **Server Connection Address** to your Elasticsearch or OpenSearch cluster endpoint.
|
||||
5. Monitor cluster health: `curl https://mattermost-os-xxxxx.us-east-1.es.amazonaws.com/_cluster/health`
|
||||
|
||||
<Inc0_common_configure_mattermost_for_enterprise_search />
|
||||
99
docs/main/deployment-guide/scale/redis.mdx
Normal file
99
docs/main/deployment-guide/scale/redis.mdx
Normal file
@@ -0,0 +1,99 @@
|
||||
---
|
||||
title: "Redis"
|
||||
---
|
||||
<PlanAvailability slug="ent-adv" />
|
||||
|
||||
Redis is an open-source, in-memory data structure store used as a database, cache, message broker, and streaming engine. Mattermost uses Redis as an external cache to improve performance at scale. When properly configured, Redis can help support Mattermost installations with more than 100,000 users by providing improved performance through efficient caching.
|
||||
|
||||
## Deployment guide
|
||||
|
||||
Deploying Redis with Mattermost includes the following 2 steps: [setting up the Redis server](#set-up-a-redis-server), and [configuring Redis in Mattermost](#configure-redis-in-mattermost).
|
||||
|
||||
### Set up a Redis server
|
||||
|
||||
1. Download and install the latest release of [Redis 7.x](https://redis.io/download/). See the Redis documentation for installation details specific to your operating system.
|
||||
2. Configure Redis appropriately for your environment. Ensure that Redis is secured and accessible only by trusted systems.
|
||||
3. For high availability deployments, consider setting up Redis in a cluster configuration for improved reliability and performance.
|
||||
|
||||
### Configure Redis in Mattermost
|
||||
|
||||
Follow these steps to configure Mattermost to use your Redis server:
|
||||
|
||||
1. Go to **System Console \> Environment \> Cache**.
|
||||
2. Set **Cache Type** to `redis` to enable the Redis-specific settings.
|
||||
3. Set the Redis server connection details:
|
||||
|
||||
> 1. Enter **Redis Address** for the Redis server you set up earlier (e.g., `redis.example.com:6379`).
|
||||
> 2. (Optional) Enter **Redis Password** if your Redis server requires authentication.
|
||||
> 3. (Optional) Enter **Redis Database** to specify which Redis database to use (-1 by default, which uses Redis's default database).
|
||||
|
||||
4. Save your configuration and restart the Mattermost server.
|
||||
|
||||
Alternatively, you can configure Redis in the `config.json` file:
|
||||
|
||||
``` json
|
||||
"CacheSettings": {
|
||||
"CacheType": "redis",
|
||||
"RedisAddress": "redis.example.com:6379",
|
||||
"RedisPassword": "",
|
||||
"RedisCachePrefix": "",
|
||||
"RedisDB": -1,
|
||||
"DisableClientCache": false
|
||||
}
|
||||
```
|
||||
|
||||
## Deploy with AWS ElastiCache
|
||||
|
||||
For enterprise-scale deployments, AWS ElastiCache for Redis provides a fully managed Redis service that simplifies deployment, operation, and scaling.
|
||||
|
||||
When deploying Mattermost with AWS ElastiCache:
|
||||
|
||||
1. Create an ElastiCache for Redis instance, choosing Redis OSS version 7.1 or later.
|
||||
2. Based on load testing results, we recommend starting with a `cache.m7g.2xlarge` instance for deployments supporting over 100,000 users.
|
||||
3. Configure your Mattermost server to connect to the ElastiCache endpoint.
|
||||
4. Monitor CPU utilization closely, as Redis is single-threaded and performance bottlenecks are typically CPU-bound rather than memory-bound.
|
||||
|
||||
### Performance considerations
|
||||
|
||||
When using Redis with Mattermost, consider the following performance insights:
|
||||
|
||||
- Current load tests indicate that memory usage of Redis is relatively low, with CPU being the primary bottleneck because Redis is single-threaded.
|
||||
- When planning your Redis deployment, use CPU utilization as the primary metric for scaling decisions.
|
||||
|
||||
## Implementation details
|
||||
|
||||
Mattermost uses the [rueidis](https://github.com/redis/rueidis) library instead of the more popular [go-redis](https://github.com/redis/go-redis), primarily because rueidis offers more performance optimizations out of the box, including:
|
||||
|
||||
- Automatic pipelining of concurrent queries
|
||||
- Client-side caching
|
||||
- Additional performance tuning options like MaxFlushDelay
|
||||
|
||||
The primary implementation files include:
|
||||
|
||||
- `platform/services/cache/provider.go` - Contains the library initialization code
|
||||
- `platform/services/cache/redis.go` - Contains the cache interface implementation
|
||||
|
||||
## Frequently asked questions (FAQ)
|
||||
|
||||
### Do I need to use Redis?
|
||||
|
||||
While Redis is not required for smaller Mattermost deployments, it is highly recommended for large-scale installations. - If your installation has more than 100K users, Redis is highly recommended. Redis significantly improves performance by reducing database load and optimizing common operations. - If your installation has less than 100K users, Redis is not recommended.
|
||||
|
||||
It is suggested to keep an eye on the `sum(rate(mattermost_cache_mem_invalidation_total[5m]))` metric which indicates the rate of cache invalidations happening. A single cache invalidation will send a message across your HA cluster to all nodes, leading to database calls from all of them. So the metric, combined with the number of nodes in your cluster should be used to determine when is the right time to use Redis.
|
||||
|
||||
For example, if you have more than 10 nodes in your cluster, and the rate of invalidations goes beyond 10, then you should definitely start considering adding Redis.
|
||||
|
||||
### Should I install Redis on the same machine as Mattermost Server?
|
||||
|
||||
For production deployments, we recommend running Redis on a separate machine from the Mattermost server. This separation allows for better resource allocation and improved system reliability.
|
||||
|
||||
### What Redis metrics should I monitor?
|
||||
|
||||
When running Redis with Mattermost, monitor the following metrics:
|
||||
|
||||
- CPU utilization (primary bottleneck)
|
||||
- Memory usage
|
||||
- Connected clients
|
||||
- Cache hit ratio
|
||||
- Operation latency
|
||||
- Mattermost's `mattermost_db_cache_time` Grafana metric with labels of `cache_name` and `operation`, which can be used to further monitor the performance of Redis
|
||||
127
docs/main/deployment-guide/scale/scale-to-100000-users.mdx
Normal file
127
docs/main/deployment-guide/scale/scale-to-100000-users.mdx
Normal file
@@ -0,0 +1,127 @@
|
||||
---
|
||||
title: "Scale Mattermost up to 100,000 users"
|
||||
---
|
||||
import Inc0_lifetime_storage from './lifetime-storage.mdx';
|
||||
import Inc1_estimated_storage_per_user_per_month from './estimated-storage-per-user-per-month.mdx';
|
||||
import Inc2_additional_ha_considerations from './additional-ha-considerations.mdx';
|
||||
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
This page describes the Mattermost reference architecture designed for the load of up to 100,000 concurrent users. Unsure which reference architecture to use? See the [scaling for enterprise](/deployment-guide/scale/scaling-for-enterprise) documentation for details.
|
||||
|
||||
- **High Availability**: Required
|
||||
- **Database Configuration**: writer, multiple readers
|
||||
|
||||
<Note>
|
||||
|
||||
\- Usage of CPU, RAM, and storage space can vary significantly based on user behavior. These hardware recommendations are based on traditional deployments and may grow or shrink depending on how active your users are. - From Mattermost v10.4, Mattermost Enterprise customers can configure [Redis](https://redis.io/) (Remote Dictionary Server) as an alternative cache backend. Using Redis can help ensure that Mattermost remains performant and efficient, even under heavy usage. See the [Redis cache backend](/administration-guide/configure/environment-configuration-settings#redis-cache-backend) configuration settings documentation for details. - While the following Elasticsearch specifications may be more than sufficient for some use cases, we have not extensively tested configurations with lower resource allocations for this user scale. If cost optimization is a priority, admins may choose to experiment with smaller configurations, but we recommend starting with the tested specifications to ensure system stability and performance. Keep in mind that under-provisioning can lead to degraded user experience and additional troubleshooting effort.
|
||||
|
||||
</Note>
|
||||
|
||||
## Requirements
|
||||
|
||||
<style>
|
||||
.scale-requirements-table {
|
||||
width: 100% !important;
|
||||
table-layout: fixed !important;
|
||||
border-collapse: collapse;
|
||||
font-size: 0.9em;
|
||||
overflow-wrap: break-word !important;
|
||||
word-wrap: break-word !important;
|
||||
}
|
||||
.scale-requirements-table th, .scale-requirements-table td {
|
||||
border: 1px solid #ddd;
|
||||
padding: 8px;
|
||||
text-align: left;
|
||||
vertical-align: top;
|
||||
word-wrap: break-word;
|
||||
overflow-wrap: break-word;
|
||||
}
|
||||
.scale-requirements-table th {
|
||||
background-color: #f8f9fa;
|
||||
font-weight: bold;
|
||||
}
|
||||
.scale-requirements-table col:nth-child(1) { width: 25%; }
|
||||
.scale-requirements-table col:nth-child(2) { width: 10%; }
|
||||
.scale-requirements-table col:nth-child(3) { width: 18%; }
|
||||
.scale-requirements-table col:nth-child(4) { width: 23%; }
|
||||
.scale-requirements-table col:nth-child(5) { width: 24%; }
|
||||
</style>
|
||||
|
||||
<table class="scale-requirements-table">
|
||||
<colgroup>
|
||||
<col style={{width: '25%'}} />
|
||||
<col style={{width: '10%'}} />
|
||||
<col style={{width: '18%'}} />
|
||||
<col style={{width: '23%'}} />
|
||||
<col style={{width: '24%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Resource Type</th>
|
||||
<th>Nodes</th>
|
||||
<th>vCPU/Memory (GiB)</th>
|
||||
<th>AWS Instance</th>
|
||||
<th>Azure Instance</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Mattermost Application</td>
|
||||
<td>6</td>
|
||||
<td>16/32</td>
|
||||
<td>c7i.4xlarge</td>
|
||||
<td>F16s v2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>RDS Writer</td>
|
||||
<td>1</td>
|
||||
<td>16/128</td>
|
||||
<td>db.r7g.4xlarge</td>
|
||||
<td>E16ds v5</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>RDS Reader</td>
|
||||
<td>5</td>
|
||||
<td>16/128</td>
|
||||
<td>db.r7g.4xlarge</td>
|
||||
<td>E16ds v5</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Elasticsearch cluster</td>
|
||||
<td>4</td>
|
||||
<td>8/64</td>
|
||||
<td>r6g.2xlarge.search</td>
|
||||
<td>E8ads v6</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Proxy</td>
|
||||
<td>1</td>
|
||||
<td>16/64</td>
|
||||
<td>m7i.4xlarge</td>
|
||||
<td>D16s v6</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## Lifetime storage
|
||||
|
||||
<Inc0_lifetime_storage />
|
||||
|
||||
### Estimated storage per user, per month
|
||||
|
||||
<Inc1_estimated_storage_per_user_per_month />
|
||||
|
||||
### Example
|
||||
|
||||
A 100000-person team with medium usage (with a safety factor of 2x) would require between 10.56TB <sup>1</sup> and 52.8TB <sup>2</sup> of free space per annum.
|
||||
|
||||
<sup>1</sup> 100000 users \* 5 MB \* 12 months \* 2x safety factor
|
||||
|
||||
<sup>2</sup> 100000 users \* 25 MB \* 12 months \* 2x safety factor
|
||||
|
||||
We strongly recommend that you review storage utilization at least quarterly to ensure adequate free space is available.
|
||||
|
||||
## Additional considerations
|
||||
|
||||
<Inc2_additional_ha_considerations />
|
||||
146
docs/main/deployment-guide/scale/scale-to-15000-users.mdx
Normal file
146
docs/main/deployment-guide/scale/scale-to-15000-users.mdx
Normal file
@@ -0,0 +1,146 @@
|
||||
---
|
||||
title: "Scale Mattermost up to 15,000 users"
|
||||
---
|
||||
import Inc0_lifetime_storage from './lifetime-storage.mdx';
|
||||
import Inc1_estimated_storage_per_user_per_month from './estimated-storage-per-user-per-month.mdx';
|
||||
import Inc2_additional_ha_considerations from './additional-ha-considerations.mdx';
|
||||
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
This page describes the Mattermost reference architecture designed for the load of up to 15,000 concurrent users. Unsure which reference architecture to use? See the [scaling for enterprise](/deployment-guide/scale/scaling-for-enterprise) documentation for details.
|
||||
|
||||
- **High Availability**: Required
|
||||
- **Database Configuration**: writer, reader
|
||||
|
||||
<Note>
|
||||
|
||||
Usage of CPU, RAM, and storage space can vary significantly based on user behavior. These hardware recommendations are based on traditional deployments and may grow or shrink depending on how active your users are.
|
||||
|
||||
</Note>
|
||||
|
||||
## Requirements
|
||||
|
||||
<style>
|
||||
.scale-requirements-table {
|
||||
width: 100% !important;
|
||||
table-layout: fixed !important;
|
||||
border-collapse: collapse;
|
||||
font-size: 0.9em;
|
||||
overflow-wrap: break-word !important;
|
||||
word-wrap: break-word !important;
|
||||
}
|
||||
.scale-requirements-table th,
|
||||
.scale-requirements-table td {
|
||||
border: 1px solid #ddd;
|
||||
padding: 8px;
|
||||
vertical-align: top;
|
||||
word-wrap: break-word !important;
|
||||
overflow-wrap: break-word !important;
|
||||
}
|
||||
.scale-requirements-table th {
|
||||
background-color: #f8f9fa;
|
||||
font-weight: bold;
|
||||
text-align: left;
|
||||
}
|
||||
.scale-requirements-table th:nth-child(1) { width: 25%; }
|
||||
.scale-requirements-table th:nth-child(2) { width: 10%; }
|
||||
.scale-requirements-table th:nth-child(3) { width: 18%; }
|
||||
.scale-requirements-table th:nth-child(4) { width: 23%; }
|
||||
.scale-requirements-table th:nth-child(5) { width: 24%; }
|
||||
|
||||
/* Dark mode support */
|
||||
body:not([data-custom-theme="light"]) .scale-requirements-table {
|
||||
background-color: #2d3748;
|
||||
}
|
||||
body:not([data-custom-theme="light"]) .scale-requirements-table th {
|
||||
background-color: #4a5568 !important;
|
||||
color: #fff;
|
||||
border-color: #718096 !important;
|
||||
}
|
||||
body:not([data-custom-theme="light"]) .scale-requirements-table td {
|
||||
color: #e2e8f0;
|
||||
border-color: #718096 !important;
|
||||
}
|
||||
|
||||
/* Mobile responsiveness */
|
||||
@media (max-width: 768px) {
|
||||
.scale-requirements-table {
|
||||
font-size: 0.8em;
|
||||
}
|
||||
.scale-requirements-table th,
|
||||
.scale-requirements-table td {
|
||||
padding: 6px 4px;
|
||||
}
|
||||
}
|
||||
</style>
|
||||
|
||||
<table class="scale-requirements-table">
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Resource Type</th>
|
||||
<th>Nodes</th>
|
||||
<th>vCPU/ Memory (GiB)</th>
|
||||
<th>AWS Instance</th>
|
||||
<th>Azure Instance</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Mattermost Application</td>
|
||||
<td>2</td>
|
||||
<td>4/8</td>
|
||||
<td>c7i.xlarge</td>
|
||||
<td>F4s v2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>RDS Writer</td>
|
||||
<td>1</td>
|
||||
<td>4/32</td>
|
||||
<td>db.r7g.xlarge</td>
|
||||
<td>E4ds v5</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>RDS Reader</td>
|
||||
<td>1</td>
|
||||
<td>4/32</td>
|
||||
<td>db.r7g.xlarge</td>
|
||||
<td>E4ds v5</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Elasticsearch Node</td>
|
||||
<td>2</td>
|
||||
<td>4/32</td>
|
||||
<td>r6g.xlarge.search</td>
|
||||
<td>E4ads v6</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Proxy</td>
|
||||
<td>1</td>
|
||||
<td>16/64</td>
|
||||
<td>m7i.4xlarge</td>
|
||||
<td>D16s v6</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## Lifetime storage
|
||||
|
||||
<Inc0_lifetime_storage />
|
||||
|
||||
### Estimated storage per user, per month
|
||||
|
||||
<Inc1_estimated_storage_per_user_per_month />
|
||||
|
||||
### Example
|
||||
|
||||
A 15000-person team with medium usage (with a safety factor of 2x) would require between 1.8TB <sup>1</sup> and 9TB <sup>2</sup> of free space per annum.
|
||||
|
||||
<sup>1</sup> 15000 users \* 5 MB \* 12 months \* 2x safety factor
|
||||
|
||||
<sup>2</sup> 15000 users \* 25 MB \* 12 months \* 2x safety factor
|
||||
|
||||
We strongly recommend that you review storage utilization at least quarterly to ensure adequate free space is available.
|
||||
|
||||
## Additional considerations
|
||||
|
||||
<Inc2_additional_ha_considerations />
|
||||
143
docs/main/deployment-guide/scale/scale-to-200-users.mdx
Normal file
143
docs/main/deployment-guide/scale/scale-to-200-users.mdx
Normal file
@@ -0,0 +1,143 @@
|
||||
---
|
||||
title: "Scale Mattermost up to 200 users"
|
||||
---
|
||||
import Inc0_lifetime_storage from './lifetime-storage.mdx';
|
||||
import Inc1_estimated_storage_per_user_per_month from './estimated-storage-per-user-per-month.mdx';
|
||||
|
||||
This page describes the Mattermost reference architecture designed for the load of up to 200 concurrent users. Unsure which reference architecture to use? See the [scaling for enterprise](/deployment-guide/scale/scaling-for-enterprise) documentation for details.
|
||||
|
||||
- **High Availability**: Not required
|
||||
- **Database Configuration**: Single
|
||||
|
||||
<Note>
|
||||
|
||||
Usage of CPU, RAM, and storage space can vary significantly based on user behavior. These hardware recommendations are based on traditional deployments and may grow or shrink depending on how active your users are.
|
||||
|
||||
</Note>
|
||||
|
||||
## Requirements
|
||||
|
||||
<style>
|
||||
.scale-requirements-table {
|
||||
width: 100% !important;
|
||||
table-layout: fixed !important;
|
||||
border-collapse: collapse;
|
||||
font-size: 0.9em;
|
||||
overflow-wrap: break-word !important;
|
||||
word-wrap: break-word !important;
|
||||
}
|
||||
.scale-requirements-table th,
|
||||
.scale-requirements-table td {
|
||||
border: 1px solid #ddd;
|
||||
padding: 8px;
|
||||
vertical-align: top;
|
||||
word-wrap: break-word !important;
|
||||
overflow-wrap: break-word !important;
|
||||
}
|
||||
.scale-requirements-table th {
|
||||
background-color: #f8f9fa;
|
||||
font-weight: bold;
|
||||
text-align: left;
|
||||
}
|
||||
.scale-requirements-table th:nth-child(1) { width: 25%; }
|
||||
.scale-requirements-table th:nth-child(2) { width: 10%; }
|
||||
.scale-requirements-table th:nth-child(3) { width: 18%; }
|
||||
.scale-requirements-table th:nth-child(4) { width: 23%; }
|
||||
.scale-requirements-table th:nth-child(5) { width: 24%; }
|
||||
|
||||
/* Dark mode support */
|
||||
body:not([data-custom-theme="light"]) .scale-requirements-table {
|
||||
background-color: #2d3748;
|
||||
}
|
||||
body:not([data-custom-theme="light"]) .scale-requirements-table th {
|
||||
background-color: #4a5568 !important;
|
||||
color: #fff;
|
||||
border-color: #718096 !important;
|
||||
}
|
||||
body:not([data-custom-theme="light"]) .scale-requirements-table td {
|
||||
color: #e2e8f0;
|
||||
border-color: #718096 !important;
|
||||
}
|
||||
|
||||
/* Mobile responsiveness */
|
||||
@media (max-width: 768px) {
|
||||
.scale-requirements-table {
|
||||
font-size: 0.8em;
|
||||
}
|
||||
.scale-requirements-table th,
|
||||
.scale-requirements-table td {
|
||||
padding: 6px 4px;
|
||||
}
|
||||
}
|
||||
</style>
|
||||
|
||||
<table class="scale-requirements-table">
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Resource Type</th>
|
||||
<th>Nodes</th>
|
||||
<th>vCPU/ Memory (GiB)</th>
|
||||
<th>AWS Instance</th>
|
||||
<th>Azure Instance</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Mattermost Application</td>
|
||||
<td>1</td>
|
||||
<td>2/4</td>
|
||||
<td>c7i.large</td>
|
||||
<td>F2s v2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>RDS Writer</td>
|
||||
<td>1</td>
|
||||
<td>2/16</td>
|
||||
<td>db.r7g.large</td>
|
||||
<td>E2ds v5</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>RDS Reader</td>
|
||||
<td>0</td>
|
||||
<td>2/16</td>
|
||||
<td>db.r7g.large</td>
|
||||
<td>E2ds v5</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Elasticsearch Node</td>
|
||||
<td>0</td>
|
||||
<td>4/32</td>
|
||||
<td>r6g.xlarge.search</td>
|
||||
<td>E4ads v6</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Proxy</td>
|
||||
<td>1</td>
|
||||
<td>16/64</td>
|
||||
<td>m7i.4xlarge</td>
|
||||
<td>D16s v6</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## Lifetime storage
|
||||
|
||||
<Inc0_lifetime_storage />
|
||||
|
||||
### Estimated storage per user, per month
|
||||
|
||||
<Inc1_estimated_storage_per_user_per_month />
|
||||
|
||||
### Example
|
||||
|
||||
A 200-person team with medium usage (with a safety factor of 2x) would require between 12GB <sup>1</sup> and 60GB <sup>2</sup> of free space per annum.
|
||||
|
||||
<sup>1</sup> 200 users \* 5 MB \* 12 months \* 2x safety factor
|
||||
|
||||
<sup>2</sup> 200 users \* 25 MB \* 12 months \* 2x safety factor
|
||||
|
||||
We strongly recommend that you review storage utilization at least quarterly to ensure adequate free space is available.
|
||||
|
||||
## Additional considerations
|
||||
|
||||
Smaller deployments will need an increase in resources due to the fact the database is hosted on the same server as the Mattermost application.
|
||||
146
docs/main/deployment-guide/scale/scale-to-2000-users.mdx
Normal file
146
docs/main/deployment-guide/scale/scale-to-2000-users.mdx
Normal file
@@ -0,0 +1,146 @@
|
||||
---
|
||||
title: "Scale Mattermost up to 2,000 users"
|
||||
---
|
||||
import Inc0_lifetime_storage from './lifetime-storage.mdx';
|
||||
import Inc1_estimated_storage_per_user_per_month from './estimated-storage-per-user-per-month.mdx';
|
||||
import Inc2_additional_ha_considerations from './additional-ha-considerations.mdx';
|
||||
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
This page describes the Mattermost reference architecture designed for a minimum load of 100 concurrent users and up to 2,000 concurrent users. Unsure which reference architecture to use? See the [scaling for enterprise](/deployment-guide/scale/scaling-for-enterprise) documentation for details.
|
||||
|
||||
- **High Availability**: Required
|
||||
- **Database Configuration**: writer, reader
|
||||
|
||||
<Note>
|
||||
|
||||
Usage of CPU, RAM, and storage space can vary significantly based on user behavior. These hardware recommendations are based on traditional deployments and may grow or shrink depending on how active your users are.
|
||||
|
||||
</Note>
|
||||
|
||||
## Requirements
|
||||
|
||||
<style>
|
||||
.scale-requirements-table {
|
||||
width: 100% !important;
|
||||
table-layout: fixed !important;
|
||||
border-collapse: collapse;
|
||||
font-size: 0.9em;
|
||||
overflow-wrap: break-word !important;
|
||||
word-wrap: break-word !important;
|
||||
}
|
||||
.scale-requirements-table th,
|
||||
.scale-requirements-table td {
|
||||
border: 1px solid #ddd;
|
||||
padding: 8px;
|
||||
vertical-align: top;
|
||||
word-wrap: break-word !important;
|
||||
overflow-wrap: break-word !important;
|
||||
}
|
||||
.scale-requirements-table th {
|
||||
background-color: #f8f9fa;
|
||||
font-weight: bold;
|
||||
text-align: left;
|
||||
}
|
||||
.scale-requirements-table th:nth-child(1) { width: 25%; }
|
||||
.scale-requirements-table th:nth-child(2) { width: 10%; }
|
||||
.scale-requirements-table th:nth-child(3) { width: 18%; }
|
||||
.scale-requirements-table th:nth-child(4) { width: 23%; }
|
||||
.scale-requirements-table th:nth-child(5) { width: 24%; }
|
||||
|
||||
/* Dark mode support */
|
||||
body:not([data-custom-theme="light"]) .scale-requirements-table {
|
||||
background-color: #2d3748;
|
||||
}
|
||||
body:not([data-custom-theme="light"]) .scale-requirements-table th {
|
||||
background-color: #4a5568 !important;
|
||||
color: #fff;
|
||||
border-color: #718096 !important;
|
||||
}
|
||||
body:not([data-custom-theme="light"]) .scale-requirements-table td {
|
||||
color: #e2e8f0;
|
||||
border-color: #718096 !important;
|
||||
}
|
||||
|
||||
/* Mobile responsiveness */
|
||||
@media (max-width: 768px) {
|
||||
.scale-requirements-table {
|
||||
font-size: 0.8em;
|
||||
}
|
||||
.scale-requirements-table th,
|
||||
.scale-requirements-table td {
|
||||
padding: 6px 4px;
|
||||
}
|
||||
}
|
||||
</style>
|
||||
|
||||
<table class="scale-requirements-table">
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Resource Type</th>
|
||||
<th>Nodes</th>
|
||||
<th>vCPU/ Memory (GiB)</th>
|
||||
<th>AWS Instance</th>
|
||||
<th>Azure Instance</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Mattermost Application</td>
|
||||
<td>2</td>
|
||||
<td>2/4</td>
|
||||
<td>c7i.large</td>
|
||||
<td>F2s v2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>RDS Writer</td>
|
||||
<td>1</td>
|
||||
<td>2/16</td>
|
||||
<td>db.r7g.large</td>
|
||||
<td>E2ds v5</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>RDS Reader</td>
|
||||
<td>1</td>
|
||||
<td>2/16</td>
|
||||
<td>db.r7g.large</td>
|
||||
<td>E2ds v5</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Elasticsearch Node</td>
|
||||
<td>2</td>
|
||||
<td>4/32</td>
|
||||
<td>r6g.xlarge.search</td>
|
||||
<td>E4ads v6</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Proxy</td>
|
||||
<td>1</td>
|
||||
<td>16/64</td>
|
||||
<td>m7i.4xlarge</td>
|
||||
<td>D16s v6</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## Lifetime storage
|
||||
|
||||
<Inc0_lifetime_storage />
|
||||
|
||||
### Estimated storage per user, per month
|
||||
|
||||
<Inc1_estimated_storage_per_user_per_month />
|
||||
|
||||
### Example
|
||||
|
||||
A 2000-person team with medium usage (with a safety factor of 2x) would require between 120GB <sup>1</sup> and 600GB <sup>2</sup> of free space per annum.
|
||||
|
||||
<sup>1</sup> 2000 users \* 5 MB \* 12 months \* 2x safety factor
|
||||
|
||||
<sup>2</sup> 2000 users \* 25 MB \* 12 months \* 2x safety factor
|
||||
|
||||
We strongly recommend that you review storage utilization at least quarterly to ensure adequate free space is available.
|
||||
|
||||
## Additional considerations
|
||||
|
||||
<Inc2_additional_ha_considerations />
|
||||
142
docs/main/deployment-guide/scale/scale-to-200000-users.mdx
Normal file
142
docs/main/deployment-guide/scale/scale-to-200000-users.mdx
Normal file
@@ -0,0 +1,142 @@
|
||||
---
|
||||
title: "Scale Mattermost up to 200,000 users"
|
||||
---
|
||||
import Inc0_lifetime_storage from './lifetime-storage.mdx';
|
||||
import Inc1_estimated_storage_per_user_per_month from './estimated-storage-per-user-per-month.mdx';
|
||||
import Inc2_additional_ha_considerations from './additional-ha-considerations.mdx';
|
||||
|
||||
<PlanAvailability slug="ent-adv" />
|
||||
|
||||
This page describes the Mattermost reference architecture designed for the load of up to 200,000 concurrent users. Unsure which reference architecture to use? See the [scaling for enterprise](/deployment-guide/scale/scaling-for-enterprise) documentation for details.
|
||||
|
||||
- **High Availability**: Required
|
||||
- **Database Configuration**: writer, multiple readers
|
||||
|
||||
<Note>
|
||||
|
||||
\- Usage of CPU, RAM, and storage space can vary significantly based on user behavior. These hardware recommendations are based on traditional deployments and may grow or shrink depending on how active your users are. - From Mattermost v10.4, Mattermost Enterprise customers can configure [Redis](https://redis.io/) (Remote Dictionary Server) as an alternative cache backend. Using Redis can help ensure that Mattermost remains performant and efficient, even under heavy usage. See the [Redis cache backend](/administration-guide/configure/environment-configuration-settings#redis-cache-backend) configuration settings documentation for details. - While the following Elasticsearch specifications may be more than sufficient for some use cases, we have not extensively tested configurations with lower resource allocations for this user scale. If cost optimization is a priority, admins may choose to experiment with smaller configurations, but we recommend starting with the tested specifications to ensure system stability and performance. Keep in mind that under-provisioning can lead to degraded user experience and additional troubleshooting effort.
|
||||
|
||||
</Note>
|
||||
|
||||
## User login scalability
|
||||
|
||||
Tests across all architectures were conducted at a rate of 4 user logins per second (14,400 users per hour). For this architecture, we performed additional testing at higher rates, reaching up to 30 user logins per second.
|
||||
|
||||
Results show that this architecture supports logging in up to 150,000 users within 1.5 hours at the higher rate. Beyond this 150,000-user mark, the only available data is at the base rate of 4 logins per second, and no conclusive performance data exists at larger rates.
|
||||
|
||||
## Requirements
|
||||
|
||||
<style>
|
||||
.scale-requirements-table {
|
||||
width: 100% !important;
|
||||
table-layout: fixed !important;
|
||||
border-collapse: collapse;
|
||||
font-size: 0.9em;
|
||||
overflow-wrap: break-word !important;
|
||||
word-wrap: break-word !important;
|
||||
}
|
||||
.scale-requirements-table th, .scale-requirements-table td {
|
||||
border: 1px solid #ddd;
|
||||
padding: 8px;
|
||||
text-align: left;
|
||||
vertical-align: top;
|
||||
word-wrap: break-word;
|
||||
overflow-wrap: break-word;
|
||||
}
|
||||
.scale-requirements-table th {
|
||||
background-color: #f8f9fa;
|
||||
font-weight: bold;
|
||||
}
|
||||
.scale-requirements-table col:nth-child(1) { width: 25%; }
|
||||
.scale-requirements-table col:nth-child(2) { width: 10%; }
|
||||
.scale-requirements-table col:nth-child(3) { width: 18%; }
|
||||
.scale-requirements-table col:nth-child(4) { width: 23%; }
|
||||
.scale-requirements-table col:nth-child(5) { width: 24%; }
|
||||
</style>
|
||||
|
||||
<table class="scale-requirements-table">
|
||||
<colgroup>
|
||||
<col style={{width: '25%'}} />
|
||||
<col style={{width: '10%'}} />
|
||||
<col style={{width: '18%'}} />
|
||||
<col style={{width: '23%'}} />
|
||||
<col style={{width: '24%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Resource Type</th>
|
||||
<th>Nodes</th>
|
||||
<th>vCPU/Memory (GiB)</th>
|
||||
<th>AWS Instance</th>
|
||||
<th>Azure Instance</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Mattermost Application</td>
|
||||
<td>14</td>
|
||||
<td>16/32</td>
|
||||
<td>c7i.4xlarge</td>
|
||||
<td>F16s v2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>RDS Writer</td>
|
||||
<td>1</td>
|
||||
<td>16/128</td>
|
||||
<td>db.r7g.4xlarge</td>
|
||||
<td>E16ds v5</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>RDS Reader</td>
|
||||
<td>6</td>
|
||||
<td>16/128</td>
|
||||
<td>db.r7g.4xlarge</td>
|
||||
<td>E16ds v5</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Elasticsearch cluster</td>
|
||||
<td>4</td>
|
||||
<td>8/64</td>
|
||||
<td>r6g.2xlarge.search</td>
|
||||
<td>E8ads v6</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Proxy</td>
|
||||
<td>4</td>
|
||||
<td>32/128</td>
|
||||
<td>m6in.8xlarge</td>
|
||||
<td>D32s v6</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Redis</td>
|
||||
<td>1</td>
|
||||
<td>8/32</td>
|
||||
<td>cache.m7g.2xlarge</td>
|
||||
<td>Azure Cache Redis P3</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## Lifetime storage
|
||||
|
||||
<Inc0_lifetime_storage />
|
||||
|
||||
### Estimated storage per user, per month
|
||||
|
||||
<Inc1_estimated_storage_per_user_per_month />
|
||||
|
||||
### Example
|
||||
|
||||
A 200000-person team with medium usage (with a safety factor of 2x) would require between 21.12TB <sup>1</sup> and 105.6TB <sup>2</sup> of free space per annum.
|
||||
|
||||
<sup>1</sup> 200000 users \* 5 MB \* 12 months \* 2x safety factor
|
||||
|
||||
<sup>2</sup> 200000 users \* 25 MB \* 12 months \* 2x safety factor
|
||||
|
||||
We strongly recommend that you review storage utilization at least quarterly to ensure adequate free space is available.
|
||||
|
||||
## Additional considerations
|
||||
|
||||
<Inc2_additional_ha_considerations />
|
||||
|
||||
[Book a live demo](https://mattermost.com/request-demo/) or [talk to a Mattermost expert](https://mattermost.com/contact-sales/) to explore tailored solutions for your organization's secure collaboration needs. Or try Mattermost yourself with a [1-hour preview](https://mattermost.com/sign-up/) for instant access to a live sandbox environment.
|
||||
128
docs/main/deployment-guide/scale/scale-to-30000-users.mdx
Normal file
128
docs/main/deployment-guide/scale/scale-to-30000-users.mdx
Normal file
@@ -0,0 +1,128 @@
|
||||
---
|
||||
title: "Scale Mattermost up to 30,000 users"
|
||||
---
|
||||
import Inc0_lifetime_storage from './lifetime-storage.mdx';
|
||||
import Inc1_estimated_storage_per_user_per_month from './estimated-storage-per-user-per-month.mdx';
|
||||
import Inc2_additional_ha_considerations from './additional-ha-considerations.mdx';
|
||||
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
This page describes the Mattermost reference architecture designed for the load of up to 30,000 concurrent users. Unsure which reference architecture to use? See the [scaling for enterprise](/deployment-guide/scale/scaling-for-enterprise) documentation for details.
|
||||
|
||||
- **High Availability**: Required
|
||||
- **Database Configuration**: writer, multiple readers
|
||||
|
||||
<Note>
|
||||
|
||||
- Usage of CPU, RAM, and storage space can vary significantly based on user behavior. These hardware recommendations are based on traditional deployments and may grow or shrink depending on how active your users are.
|
||||
- While the following Elasticsearch specifications may be more than sufficient for some use cases, we have not extensively tested configurations with lower resource allocations for this user scale. If cost optimization is a priority, admins may choose to experiment with smaller configurations, but we recommend starting with the tested specifications to ensure system stability and performance. Keep in mind that under-provisioning can lead to degraded user experience and additional troubleshooting effort.
|
||||
|
||||
</Note>
|
||||
|
||||
## Requirements
|
||||
|
||||
<style>
|
||||
.scale-requirements-table {
|
||||
width: 100% !important;
|
||||
table-layout: fixed !important;
|
||||
border-collapse: collapse;
|
||||
font-size: 0.9em;
|
||||
overflow-wrap: break-word !important;
|
||||
word-wrap: break-word !important;
|
||||
}
|
||||
.scale-requirements-table th, .scale-requirements-table td {
|
||||
border: 1px solid #ddd;
|
||||
padding: 8px;
|
||||
text-align: left;
|
||||
vertical-align: top;
|
||||
word-wrap: break-word;
|
||||
overflow-wrap: break-word;
|
||||
}
|
||||
.scale-requirements-table th {
|
||||
background-color: #f8f9fa;
|
||||
font-weight: bold;
|
||||
}
|
||||
.scale-requirements-table col:nth-child(1) { width: 25%; }
|
||||
.scale-requirements-table col:nth-child(2) { width: 10%; }
|
||||
.scale-requirements-table col:nth-child(3) { width: 18%; }
|
||||
.scale-requirements-table col:nth-child(4) { width: 23%; }
|
||||
.scale-requirements-table col:nth-child(5) { width: 24%; }
|
||||
</style>
|
||||
|
||||
<table class="scale-requirements-table">
|
||||
<colgroup>
|
||||
<col style={{width: '25%'}} />
|
||||
<col style={{width: '10%'}} />
|
||||
<col style={{width: '18%'}} />
|
||||
<col style={{width: '23%'}} />
|
||||
<col style={{width: '24%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Resource Type</th>
|
||||
<th>Nodes</th>
|
||||
<th>vCPU/Memory (GiB)</th>
|
||||
<th>AWS Instance</th>
|
||||
<th>Azure Instance</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Mattermost Application</td>
|
||||
<td>2</td>
|
||||
<td>8/16</td>
|
||||
<td>c7i.2xlarge</td>
|
||||
<td>F8s v2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>RDS Writer</td>
|
||||
<td>1</td>
|
||||
<td>8/64</td>
|
||||
<td>db.r7g.2xlarge</td>
|
||||
<td>E8ds v5</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>RDS Reader</td>
|
||||
<td>1</td>
|
||||
<td>8/64</td>
|
||||
<td>db.r7g.2xlarge</td>
|
||||
<td>E8ds v5</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Elasticsearch cluster</td>
|
||||
<td>4</td>
|
||||
<td>8/64</td>
|
||||
<td>r6g.2xlarge.search</td>
|
||||
<td>E8ads v6</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Proxy</td>
|
||||
<td>1</td>
|
||||
<td>16/64</td>
|
||||
<td>m7i.4xlarge</td>
|
||||
<td>D16s v6</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## Lifetime storage
|
||||
|
||||
<Inc0_lifetime_storage />
|
||||
|
||||
### Estimated storage per user, per month
|
||||
|
||||
<Inc1_estimated_storage_per_user_per_month />
|
||||
|
||||
### Example
|
||||
|
||||
A 30000-person team with medium usage (with a safety factor of 2x) would require between 3TB <sup>1</sup> and 15TB <sup>2</sup> of free space per annum.
|
||||
|
||||
<sup>1</sup> 30000 users \* 5 MB \* 12 months \* 2x safety factor
|
||||
|
||||
<sup>2</sup> 30000 users \* 25 MB \* 12 months \* 2x safety factor
|
||||
|
||||
We strongly recommend that you review storage utilization at least quarterly to ensure adequate free space is available.
|
||||
|
||||
## Additional considerations
|
||||
|
||||
<Inc2_additional_ha_considerations />
|
||||
128
docs/main/deployment-guide/scale/scale-to-50000-users.mdx
Normal file
128
docs/main/deployment-guide/scale/scale-to-50000-users.mdx
Normal file
@@ -0,0 +1,128 @@
|
||||
---
|
||||
title: "Scale Mattermost up to 50,000 users"
|
||||
---
|
||||
import Inc0_lifetime_storage from './lifetime-storage.mdx';
|
||||
import Inc1_estimated_storage_per_user_per_month from './estimated-storage-per-user-per-month.mdx';
|
||||
import Inc2_additional_ha_considerations from './additional-ha-considerations.mdx';
|
||||
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
This page describes the Mattermost reference architecture designed for the load of up to 50,000 concurrent users. Unsure which reference architecture to use? See the [scaling for enterprise](/deployment-guide/scale/scaling-for-enterprise) documentation for details.
|
||||
|
||||
- **High Availability**: Required
|
||||
- **Database Configuration**: writer, multiple readers
|
||||
|
||||
<Note>
|
||||
|
||||
- Usage of CPU, RAM, and storage space can vary significantly based on user behavior. These hardware recommendations are based on traditional deployments and may grow or shrink depending on how active your users are.
|
||||
- While the following Elasticsearch specifications may be more than sufficient for some use cases, we have not extensively tested configurations with lower resource allocations for this user scale. If cost optimization is a priority, admins may choose to experiment with smaller configurations, but we recommend starting with the tested specifications to ensure system stability and performance. Keep in mind that under-provisioning can lead to degraded user experience and additional troubleshooting effort.
|
||||
|
||||
</Note>
|
||||
|
||||
## Requirements
|
||||
|
||||
<style>
|
||||
.scale-requirements-table {
|
||||
width: 100% !important;
|
||||
table-layout: fixed !important;
|
||||
border-collapse: collapse;
|
||||
font-size: 0.9em;
|
||||
overflow-wrap: break-word !important;
|
||||
word-wrap: break-word !important;
|
||||
}
|
||||
.scale-requirements-table th, .scale-requirements-table td {
|
||||
border: 1px solid #ddd;
|
||||
padding: 8px;
|
||||
text-align: left;
|
||||
vertical-align: top;
|
||||
word-wrap: break-word;
|
||||
overflow-wrap: break-word;
|
||||
}
|
||||
.scale-requirements-table th {
|
||||
background-color: #f8f9fa;
|
||||
font-weight: bold;
|
||||
}
|
||||
.scale-requirements-table col:nth-child(1) { width: 25%; }
|
||||
.scale-requirements-table col:nth-child(2) { width: 10%; }
|
||||
.scale-requirements-table col:nth-child(3) { width: 18%; }
|
||||
.scale-requirements-table col:nth-child(4) { width: 23%; }
|
||||
.scale-requirements-table col:nth-child(5) { width: 24%; }
|
||||
</style>
|
||||
|
||||
<table class="scale-requirements-table">
|
||||
<colgroup>
|
||||
<col style={{width: '25%'}} />
|
||||
<col style={{width: '10%'}} />
|
||||
<col style={{width: '18%'}} />
|
||||
<col style={{width: '23%'}} />
|
||||
<col style={{width: '24%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Resource Type</th>
|
||||
<th>Nodes</th>
|
||||
<th>vCPU/Memory (GiB)</th>
|
||||
<th>AWS Instance</th>
|
||||
<th>Azure Instance</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Mattermost Application</td>
|
||||
<td>5</td>
|
||||
<td>8/16</td>
|
||||
<td>c7i.2xlarge</td>
|
||||
<td>F8s v2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>RDS Writer</td>
|
||||
<td>1</td>
|
||||
<td>8/64</td>
|
||||
<td>db.r7g.2xlarge</td>
|
||||
<td>E8ds v5</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>RDS Reader</td>
|
||||
<td>4</td>
|
||||
<td>8/64</td>
|
||||
<td>db.r7g.2xlarge</td>
|
||||
<td>E8ds v5</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Elasticsearch cluster</td>
|
||||
<td>4</td>
|
||||
<td>8/64</td>
|
||||
<td>r6g.2xlarge.search</td>
|
||||
<td>E8ads v6</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Proxy</td>
|
||||
<td>1</td>
|
||||
<td>16/64</td>
|
||||
<td>m7i.4xlarge</td>
|
||||
<td>D16s v6</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## Lifetime storage
|
||||
|
||||
<Inc0_lifetime_storage />
|
||||
|
||||
### Estimated storage per user, per month
|
||||
|
||||
<Inc1_estimated_storage_per_user_per_month />
|
||||
|
||||
### Example
|
||||
|
||||
A 50000-person team with medium usage (with a safety factor of 2x) would require between 6TB <sup>1</sup> and 30TB <sup>2</sup> of free space per annum.
|
||||
|
||||
<sup>1</sup> 50000 users \* 5 MB \* 12 months \* 2x safety factor
|
||||
|
||||
<sup>2</sup> 50000 users \* 25 MB \* 12 months \* 2x safety factor
|
||||
|
||||
We strongly recommend that you review storage utilization at least quarterly to ensure adequate free space is available.
|
||||
|
||||
## Additional considerations
|
||||
|
||||
<Inc2_additional_ha_considerations />
|
||||
128
docs/main/deployment-guide/scale/scale-to-80000-users.mdx
Normal file
128
docs/main/deployment-guide/scale/scale-to-80000-users.mdx
Normal file
@@ -0,0 +1,128 @@
|
||||
---
|
||||
title: "Scale Mattermost up to 80,000 users"
|
||||
---
|
||||
import Inc0_lifetime_storage from './lifetime-storage.mdx';
|
||||
import Inc1_estimated_storage_per_user_per_month from './estimated-storage-per-user-per-month.mdx';
|
||||
import Inc2_additional_ha_considerations from './additional-ha-considerations.mdx';
|
||||
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
This page describes the Mattermost reference architecture designed for the load of up to 80,000 concurrent users. Unsure which reference architecture to use? See the [scaling for enterprise](/deployment-guide/scale/scaling-for-enterprise) documentation for details.
|
||||
|
||||
- **High Availability**: Required
|
||||
- **Database Configuration**: writer, multiple readers
|
||||
|
||||
<Note>
|
||||
|
||||
- Usage of CPU, RAM, and storage space can vary significantly based on user behavior. These hardware recommendations are based on traditional deployments and may grow or shrink depending on how active your users are.
|
||||
- While the following Elasticsearch specifications may be more than sufficient for some use cases, we have not extensively tested configurations with lower resource allocations for this user scale. If cost optimization is a priority, admins may choose to experiment with smaller configurations, but we recommend starting with the tested specifications to ensure system stability and performance. Keep in mind that under-provisioning can lead to degraded user experience and additional troubleshooting effort.
|
||||
|
||||
</Note>
|
||||
|
||||
## Requirements
|
||||
|
||||
<style>
|
||||
.scale-requirements-table {
|
||||
width: 100% !important;
|
||||
table-layout: fixed !important;
|
||||
border-collapse: collapse;
|
||||
font-size: 0.9em;
|
||||
overflow-wrap: break-word !important;
|
||||
word-wrap: break-word !important;
|
||||
}
|
||||
.scale-requirements-table th, .scale-requirements-table td {
|
||||
border: 1px solid #ddd;
|
||||
padding: 8px;
|
||||
text-align: left;
|
||||
vertical-align: top;
|
||||
word-wrap: break-word;
|
||||
overflow-wrap: break-word;
|
||||
}
|
||||
.scale-requirements-table th {
|
||||
background-color: #f8f9fa;
|
||||
font-weight: bold;
|
||||
}
|
||||
.scale-requirements-table col:nth-child(1) { width: 25%; }
|
||||
.scale-requirements-table col:nth-child(2) { width: 10%; }
|
||||
.scale-requirements-table col:nth-child(3) { width: 18%; }
|
||||
.scale-requirements-table col:nth-child(4) { width: 23%; }
|
||||
.scale-requirements-table col:nth-child(5) { width: 24%; }
|
||||
</style>
|
||||
|
||||
<table class="scale-requirements-table">
|
||||
<colgroup>
|
||||
<col style={{width: '25%'}} />
|
||||
<col style={{width: '10%'}} />
|
||||
<col style={{width: '18%'}} />
|
||||
<col style={{width: '23%'}} />
|
||||
<col style={{width: '24%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Resource Type</th>
|
||||
<th>Nodes</th>
|
||||
<th>vCPU/Memory (GiB)</th>
|
||||
<th>AWS Instance</th>
|
||||
<th>Azure Instance</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Mattermost Application</td>
|
||||
<td>4</td>
|
||||
<td>16/32</td>
|
||||
<td>c7i.4xlarge</td>
|
||||
<td>F16s v2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>RDS Writer</td>
|
||||
<td>1</td>
|
||||
<td>16/128</td>
|
||||
<td>db.r7g.4xlarge</td>
|
||||
<td>E16ds v5</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>RDS Reader</td>
|
||||
<td>3</td>
|
||||
<td>16/128</td>
|
||||
<td>db.r7g.4xlarge</td>
|
||||
<td>E16ds v5</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Elasticsearch cluster</td>
|
||||
<td>4</td>
|
||||
<td>8/64</td>
|
||||
<td>r6g.2xlarge.search</td>
|
||||
<td>E8ads v6</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Proxy</td>
|
||||
<td>1</td>
|
||||
<td>16/64</td>
|
||||
<td>m7i.4xlarge</td>
|
||||
<td>D16s v6</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## Lifetime storage
|
||||
|
||||
<Inc0_lifetime_storage />
|
||||
|
||||
### Estimated storage per user, per month
|
||||
|
||||
<Inc1_estimated_storage_per_user_per_month />
|
||||
|
||||
### Example
|
||||
|
||||
A 80000-person team with medium usage (with a safety factor of 2x) would require between 10.56TB <sup>1</sup> and 52.8TB <sup>2</sup> of free space per annum.
|
||||
|
||||
<sup>1</sup> 80000 users \* 5 MB \* 12 months \* 2x safety factor
|
||||
|
||||
<sup>2</sup> 80000 users \* 25 MB \* 12 months \* 2x safety factor
|
||||
|
||||
We strongly recommend that you review storage utilization at least quarterly to ensure adequate free space is available.
|
||||
|
||||
## Additional considerations
|
||||
|
||||
<Inc2_additional_ha_considerations />
|
||||
128
docs/main/deployment-guide/scale/scale-to-90000-users.mdx
Normal file
128
docs/main/deployment-guide/scale/scale-to-90000-users.mdx
Normal file
@@ -0,0 +1,128 @@
|
||||
---
|
||||
title: "Scale Mattermost up to 90,000 users"
|
||||
---
|
||||
import Inc0_lifetime_storage from './lifetime-storage.mdx';
|
||||
import Inc1_estimated_storage_per_user_per_month from './estimated-storage-per-user-per-month.mdx';
|
||||
import Inc2_additional_ha_considerations from './additional-ha-considerations.mdx';
|
||||
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
This page describes the Mattermost reference architecture designed for the load of up to 90,000 concurrent users. Unsure which reference architecture to use? See the [scaling for enterprise](/deployment-guide/scale/scaling-for-enterprise) documentation for details.
|
||||
|
||||
- **High Availability**: Required
|
||||
- **Database Configuration**: writer, multiple readers
|
||||
|
||||
<Note>
|
||||
|
||||
- Usage of CPU, RAM, and storage space can vary significantly based on user behavior. These hardware recommendations are based on traditional deployments and may grow or shrink depending on how active your users are.
|
||||
- While the following Elasticsearch specifications may be more than sufficient for some use cases, we have not extensively tested configurations with lower resource allocations for this user scale. If cost optimization is a priority, admins may choose to experiment with smaller configurations, but we recommend starting with the tested specifications to ensure system stability and performance. Keep in mind that under-provisioning can lead to degraded user experience and additional troubleshooting effort.
|
||||
|
||||
</Note>
|
||||
|
||||
## Requirements
|
||||
|
||||
<style>
|
||||
.scale-requirements-table {
|
||||
width: 100% !important;
|
||||
table-layout: fixed !important;
|
||||
border-collapse: collapse;
|
||||
font-size: 0.9em;
|
||||
overflow-wrap: break-word !important;
|
||||
word-wrap: break-word !important;
|
||||
}
|
||||
.scale-requirements-table th, .scale-requirements-table td {
|
||||
border: 1px solid #ddd;
|
||||
padding: 8px;
|
||||
text-align: left;
|
||||
vertical-align: top;
|
||||
word-wrap: break-word;
|
||||
overflow-wrap: break-word;
|
||||
}
|
||||
.scale-requirements-table th {
|
||||
background-color: #f8f9fa;
|
||||
font-weight: bold;
|
||||
}
|
||||
.scale-requirements-table col:nth-child(1) { width: 25%; }
|
||||
.scale-requirements-table col:nth-child(2) { width: 10%; }
|
||||
.scale-requirements-table col:nth-child(3) { width: 18%; }
|
||||
.scale-requirements-table col:nth-child(4) { width: 23%; }
|
||||
.scale-requirements-table col:nth-child(5) { width: 24%; }
|
||||
</style>
|
||||
|
||||
<table class="scale-requirements-table">
|
||||
<colgroup>
|
||||
<col style={{width: '25%'}} />
|
||||
<col style={{width: '10%'}} />
|
||||
<col style={{width: '18%'}} />
|
||||
<col style={{width: '23%'}} />
|
||||
<col style={{width: '24%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Resource Type</th>
|
||||
<th>Nodes</th>
|
||||
<th>vCPU/Memory (GiB)</th>
|
||||
<th>AWS Instance</th>
|
||||
<th>Azure Instance</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Mattermost Application</td>
|
||||
<td>5</td>
|
||||
<td>16/32</td>
|
||||
<td>c7i.4xlarge</td>
|
||||
<td>F16s v2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>RDS Writer</td>
|
||||
<td>1</td>
|
||||
<td>16/128</td>
|
||||
<td>db.r7g.4xlarge</td>
|
||||
<td>E16ds v5</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>RDS Reader</td>
|
||||
<td>4</td>
|
||||
<td>16/128</td>
|
||||
<td>db.r7g.4xlarge</td>
|
||||
<td>E16ds v5</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Elasticsearch cluster</td>
|
||||
<td>4</td>
|
||||
<td>8/64</td>
|
||||
<td>r6g.2xlarge.search</td>
|
||||
<td>E8ads v6</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Proxy</td>
|
||||
<td>1</td>
|
||||
<td>16/64</td>
|
||||
<td>m7i.4xlarge</td>
|
||||
<td>D16s v6</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## Lifetime storage
|
||||
|
||||
<Inc0_lifetime_storage />
|
||||
|
||||
### Estimated storage per user, per month
|
||||
|
||||
<Inc1_estimated_storage_per_user_per_month />
|
||||
|
||||
### Example
|
||||
|
||||
A 90000-person team with medium usage (with a safety factor of 2x) would require between 10.56TB <sup>1</sup> and 52.8TB <sup>2</sup> of free space per annum.
|
||||
|
||||
<sup>1</sup> 90000 users \* 5 MB \* 12 months \* 2x safety factor
|
||||
|
||||
<sup>2</sup> 90000 users \* 25 MB \* 12 months \* 2x safety factor
|
||||
|
||||
We strongly recommend that you review storage utilization at least quarterly to ensure adequate free space is available.
|
||||
|
||||
## Additional considerations
|
||||
|
||||
<Inc2_additional_ha_considerations />
|
||||
82
docs/main/deployment-guide/scale/scaling-for-enterprise.mdx
Normal file
82
docs/main/deployment-guide/scale/scaling-for-enterprise.mdx
Normal file
@@ -0,0 +1,82 @@
|
||||
---
|
||||
title: "Scaling for Enterprise"
|
||||
---
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
Mattermost is designed to scale from small teams hosted on a single server to large enterprises running in cluster-based, highly available deployment configurations.
|
||||
|
||||
- Mattermost supports any 64-bit x86 processor architecture
|
||||
- **Databases supported**: PostgreSQL, Amazon RDS for PostgreSQL
|
||||
- **Storage supported**: Amazon S3 or a local filestore
|
||||
|
||||
Server requirements vary based on usage and we highly recommend that you run a pilot before an enterprise-wide deployment in order to estimate full scale usage based on your specific organizational needs.
|
||||
|
||||
## Backing storage
|
||||
|
||||
Review detailed [write and read storage benchmark results](/deployment-guide/scale/backing-storage-benchmarks) for supported storage options including local file system (EBS, gp3), network file system (EFS), and object storage (S3) to make informed decisions based on your use case and infrastructure needs.
|
||||
|
||||
## Enterprise search
|
||||
|
||||
We highly recommend a dedicated server for large enterprise deployments to run highly efficient database searches in a cluster environment.
|
||||
|
||||
For deployments with over 5 million posts, [Enterprise search](/deployment-guide/scale/enterprise-search) using [Elasticsearch](/deployment-guide/scale/enterprise-search#elasticsearch) or [AWS OpenSearch Service](/deployment-guide/scale/enterprise-search#aws-opensearch-service) is required for optimized search performance, dedicated indexing and usage resourcing via cluster support without performance degradation and timeouts, resulting in faster, more predicable search results.
|
||||
|
||||
## High availability
|
||||
|
||||
A [high availability cluster-based deployment](/deployment-guide/server/high-availability-cluster-based-deployment) enables a Mattermost system to maintain service during outages and hardware failures through the use of redundant infrastructure.
|
||||
|
||||
## Redis
|
||||
|
||||
[Redis](/deployment-guide/scale/redis) is an in-memory data structure store that can be used as a database, cache, and message broker. Mattermost uses Redis as an external cache to improve performance at scale. When properly configured, Redis can help support Mattermost installations with more than 100,000 users by providing improved performance through efficient caching.
|
||||
|
||||
## Available reference architectures
|
||||
|
||||
The following reference architectures are available as recommended starting points for your self-hosted Mattermost deployment, where user counts refer to the number of concurrent users for a given deployment. The number of concurrent numbers is commonly lower than the total number of user accounts.
|
||||
|
||||
- [Scale up to 200 users](/deployment-guide/scale/scale-to-200-users) - Learn how to scale Mattermost to up to 200 users.
|
||||
- [Scale up to 2,000 users](/deployment-guide/scale/scale-to-2000-users) - Learn how to scale Mattermost to up to 2,000 users.
|
||||
- [Scale up to 15,000 users](/deployment-guide/scale/scale-to-15000-users) - Learn how to scale Mattermost to up to 15,000 users.
|
||||
- [Scale up to 30,000 users](/deployment-guide/scale/scale-to-30000-users) - Learn how to scale Mattermost to up to 30,000 users.
|
||||
- [Scale up to 50,000 users](/deployment-guide/scale/scale-to-50000-users) - Learn how to scale Mattermost to up to 50,000 users.
|
||||
- [Scale up to 80,000 users](/deployment-guide/scale/scale-to-80000-users) - Learn how to scale Mattermost to up to 80,000 users.
|
||||
- [Scale up to 90,000 users](/deployment-guide/scale/scale-to-90000-users) - Learn how to scale Mattermost to up to 90,000 users.
|
||||
- [Scale up to 100,000 users](/deployment-guide/scale/scale-to-100000-users) - Learn how to scale Mattermost to up to 100,000 users.
|
||||
- [Scale up to 200,000 users](/deployment-guide/scale/scale-to-200000-users) - Learn how to scale Mattermost to up to 200,000 users.
|
||||
|
||||
<Important>
|
||||
|
||||
Due to constraints in testing, the proxy instance specifications were fixed for all the scaling tests from which we derived these reference architectures. This was done to avoid a combinatorial explosion of variables in tests, but it resulted in minor gaps in our understandings of certain aspects of the reference architectures. In particular, the proxy instance is overspecified for the smaller user counts.
|
||||
|
||||
</Important>
|
||||
|
||||
## Testing methodology and updates
|
||||
|
||||
All tests were executed with the custom load test tool built by the Mattermost development teams to determine supported users for each deployment size. Over time, this guide will be updated with new deployment sizes, deployment architectures, and newer versions of the Mattermost Server will be tested using an ESR.
|
||||
|
||||
At a high level, each deployment size was fixed (Mattermost server node count/sizing, database reader/writer count/sizing), and unbounded tests were used to report the maximum numbers of concurrent users the deployment can support. Each test included populated PostgreSQL v14 databases and a post table history of 100 million posts, ~200000 users, 20 teams, and ~720000 channels to provide a test simulation of a production Mattermost deployment.
|
||||
|
||||
Tests were defined by configuration of the actions executed by each simulated user (and the frequency of these actions) where the coordinator metrics define a health system under load. Tests were performed using the Mattermost v9.5 Extended Support Release (ESR). Job servers weren't used. All tests with more than a single app node had an NGINX proxy running in front of them.
|
||||
|
||||
For the last test of 200K users, further infrastructure changes were made. Elasticsearch nodes were added. A Redis instance was added, and multiple NGINX proxies were used to distribute traffic evenly across all nodes in the cluster. More details can be found on the [scale to 200000 users](/deployment-guide/scale/scale-to-200000-users) documentation page.
|
||||
|
||||
Full testing methodology, configuration, and setup is available, incluidng a [fixed database dump with 100 million posts](https://us-east-1.console.aws.amazon.com/backup/home?region=us-east-1#/resources/arn%3Aaws%3Ards%3Aus-east-1%3A729462591288%3Acluster%3Adb-pg-100m-posts-v9-5-5). Visit the [Mattermost Community](https://community.mattermost.com/) and join the [Developers: Performance channel](https://community.mattermost.com/core/channels/developers-performance) for details.
|
||||
|
||||
The performance specifications and user capacities provided in these reference architectures are based on extensive testing conducted in AWS environments.
|
||||
|
||||
For Azure deployments, the instance specifications have been extrapolated using equivalent configurations, drawing upon AWS performance data and industry expertise. While these configurations are designed to meet the stated requirements, we have not yet conducted formal testing in Azure environments to validate performance under load. Azure Blob Storage support is in active development, and not yet natively supported by Mattermost.
|
||||
|
||||
## Mattermost load testing tools
|
||||
|
||||
Mattermost provides a set of tools written in Go to help profiling Mattermost under heavy load, simulating real-world usage of a server installation at scale. The [Mattermost Load Test Tool](https://github.com/mattermost/mattermost-load-test-ng) estimates the maximum number of concurrently active users the target system supports, and enables you to control the load to generate.
|
||||
|
||||
Visit the [Mattermost Load Test Tool](https://github.com/mattermost/mattermost-load-test-ng/tree/master/docs) documentation on GitHub for details on getting started with the tools, and visit [the Go documentation](https://pkg.go.dev/github.com/mattermost/mattermost-load-test-ng) for code-specific documentation details.
|
||||
|
||||
<Important>
|
||||
|
||||
- The Mattermost Load Test Tool was designed by and is used by our performance engineers to compare and benchmark the performance of the service from month to month to prepare for new releases. It's also used extensively in developing our recommended hardware sizing.
|
||||
- We recommend deploying [Prometheus and Grafana](/administration-guide/scale/deploy-prometheus-grafana-for-performance-monitoring) with our [dashboards](/administration-guide/scale/deploy-prometheus-grafana-for-performance-monitoring#getting-started) for ongoing monitoring and scale guidance.
|
||||
- If you encounter performance concerns, we recommend [collecting performance metrics](/administration-guide/scale/collect-performance-metrics) and sharing them with us as a first troubleshooting step.
|
||||
|
||||
</Important>
|
||||
|
||||
[Book a live demo](https://mattermost.com/request-demo/) or [talk to a Mattermost expert](https://mattermost.com/contact-sales/) to explore tailored solutions for your organization's secure collaboration needs. Or try Mattermost yourself with a [1-hour preview](https://mattermost.com/sign-up/) for instant access to a live sandbox environment.
|
||||
95
docs/main/deployment-guide/scale/server-architecture.mdx
Normal file
95
docs/main/deployment-guide/scale/server-architecture.mdx
Normal file
@@ -0,0 +1,95 @@
|
||||
---
|
||||
title: "Deployment Architecture at Scale"
|
||||
---
|
||||
import useBaseUrl from '@docusaurus/useBaseUrl';
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
The following diagrams detail suggested architecture configurations of [high availability Mattermost deployments](/deployment-guide/server/high-availability-cluster-based-deployment#deployment-guide) at different scales. Hardware and infrastructure requirements will vary significantly based on usage and policies. See the [scaling for enterprise](/deployment-guide/scale/scaling-for-enterprise) documentation for reference architecture guidance at scale, including hardware and infrastructure requirements.
|
||||
|
||||
High availability in Mattermost consists of running redundant Mattermost application servers, redundant database servers, and redundant load balancers so that failure of any one of these components does not interrupt operation of the system. Upon failure of one component, the remaining application servers, database servers, and load balancers must be sized and configured to carry the full load of the system. If this requirement is not met, an outage of one component can result in an overload of the remaining components, causing a complete system outage.
|
||||
|
||||
<Important>
|
||||
|
||||
Mattermost does not support high availability deployments spanning multiple datacenters. All nodes in a high availability cluster must reside within the same datacenter to ensure proper functionality and performance.
|
||||
|
||||
</Important>
|
||||
|
||||
You can apply most configuration changes and dot release security updates without interrupting service, provided that you update the system components in the correct sequence. Changes to configuration settings that require a server restart, and server version upgrades that involve a change to the database schema, require a short period of downtime. Downtime for a server restart is around 5 seconds. For a database schema update, downtime can be up to 30 seconds.
|
||||
|
||||
## Designed for scale
|
||||
|
||||
Mattermost is designed to be able to handle a large number of concurrent users, and the architecture can be scaled up or down as needed. The architecture is also designed to be flexible, allowing for the addition of new components or services as needed. The following diagrams show the recommended architecture for Mattermost deployments at 5,000, 10,000, 25,000, and 50,000 users. The diagrams are organized by user count and include a general diagram, AWS and Azure versions of each diagram, and an Oracle diagram for 5,000 users. See the [scaling for enterprise](/deployment-guide/scale/scaling-for-enterprise) documentation for more information on scaling Mattermost deployments.
|
||||
|
||||
- Each generalized diagram represents a full High Availability deployment across all critical components. The proxy, database, file storage, and Elasticsearch layers can be replaced by cloud services.
|
||||
- Each AWS diagram represents a full High Availability deployment on Amazon Web Services making full use of the available services.
|
||||
- Each Azure diagram represents a full High Availability deployment on Microsoft Azure making full use of the available services.
|
||||
- Each Oracle diagram represents a full High Availability deployment on Oracle Cloud Infrastructure making full use of the available services. Currently, only the 5,000-user diagram is available for Oracle.
|
||||
- Push proxy can be replaced by the Mattermost [hosted push notification service](/administration-guide/configure/push-notification-server-configuration-settings#hosted-push-notifications-service-hpns).
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="aws" label="AWS">
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="5-000-users" label="5,000 users">
|
||||
|
||||
<img src={useBaseUrl('/images/MattermostDeployment5kaws.png')} class="bg-white" alt="Mattermost high availability deployment architecture on AWS for 5,000 users" />
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="10-000-users" label="10,000 users">
|
||||
|
||||
<img src={useBaseUrl('/images/MattermostDeployment10kaws.png')} class="bg-white" alt="Mattermost high availability deployment architecture on AWS for 10,000 users" />
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="25-000-users" label="25,000 users">
|
||||
|
||||
<img src={useBaseUrl('/images/MattermostDeployment25kaws.png')} class="bg-white" alt="Mattermost high availability deployment architecture on AWS for 25,000 users" />
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="50-000-users" label="50,000 users">
|
||||
|
||||
<img src={useBaseUrl('/images/MattermostDeployment50kaws.png')} class="bg-white" alt="Mattermost high availability deployment architecture on AWS for 50,000 users" />
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="azure" label="Azure">
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="5-000-users" label="5,000 users">
|
||||
|
||||
<img src={useBaseUrl('/images/MattermostDeployment5kAzure.png')} class="bg-white" alt="Mattermost high availability deployment architecture on Azure for 5,000 users" />
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="10-000-users" label="10,000 users">
|
||||
|
||||
<img src={useBaseUrl('/images/MattermostDeployment10kAzure.png')} class="bg-white" alt="Mattermost high availability deployment architecture on Azure for 10,000 users" />
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="25-000-users" label="25,000 users">
|
||||
|
||||
<img src={useBaseUrl('/images/MattermostDeployment25kAzure.png')} class="bg-white" alt="Mattermost high availability deployment architecture on Azure for 25,000 users" />
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="50-000-users" label="50,000 users">
|
||||
|
||||
<img src={useBaseUrl('/images/MattermostDeployment50kAzure.png')} class="bg-white" alt="Mattermost high availability deployment architecture on Azure for 50,000 users" />
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="oracle" label="Oracle">
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="5-000-users" label="5,000 users">
|
||||
|
||||
<img src={useBaseUrl('/images/MattermostDeployment5kOracle.png')} class="bg-white" alt="Mattermost high availability deployment architecture on Oracle Cloud Infrastructure for 5,000 users" />
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
Reference in New Issue
Block a user