mirror of
https://github.com/hanzoai/team.git
synced 2026-09-30 01:57:35 +00:00
b5f007d35e
* docs: resolve cross-file anchor mismatches from RST-to-MDX migration
The Sphinx-to-Docusaurus migration converted `:ref:`/`{ref}` links using
naive text-slugification, so anchors that pointed to headings in a
different file (e.g. release-summary tables linking into their
respective changelog pages) were emitted as same-page fragments and
silently resolved to nothing.
Built a label registry from the original Sphinx `.. _label:` / `(label)=`
targets to recover the true source file for each cross-reference, then
rewrote the affected links to point at the correct file + heading
anchor. Fixes 282 broken cross-file anchors, primarily in the mobile/
desktop/server release-summary pages, plus assorted same-page anchor
mismatches caught by re-auditing after the prior admonition/anchor fix.
* docs: manually resolve remaining anchor mismatches after cross-file audit
Hand-verified fixes for anchors that fuzzy-matching alone couldn't
safely resolve (confirmed against actual heading text/context, and in a
few cases against the original RST source, before applying):
- Typos and dropped words carried over from the original Sphinx docs
(e.g. "bot-acocunts", "auto-follow-all-new-channel-threads" ->
"follow-all-new-channel-threads").
- Sphinx auto-generated duplicate-heading IDs (#id1/#id3/#id4) resolved
to their real target headings.
- Numbered-step TOC links in enterprise-roll-out-checklist.mdx that
dropped the leading "N. " used in the actual heading slugs.
- Push-notification docs pointing at the wrong file entirely
(environment-configuration-settings instead of
push-notification-server-configuration-settings).
- SAML "saml-enterprise" label resolved to its true cross-file target
(authentication-configuration-settings#saml-2-0), recovered from the
original RST label definition that the automated registry missed
because it sat after an RST transition marker.
- sso-saml-technical references converted from broken same-page/
malformed-path anchors to correct page links.
* docs: fix SAML 2.0 anchor slug (saml-2-0 -> saml-20)
github-slugger strips periods rather than hyphenating them, so "SAML
2.0" slugifies to saml-20, not saml-2-0 as previously fixed.
* docs: fix broken path links found during docs/main migration cleanup
* docs: convert div.tab blocks to Docusaurus Tabs/TabItem components
* docs: restore missing Kubernetes deployment architecture diagrams
The RST-to-MDX migration never copied over the AWS/Azure/Oracle
architecture diagrams referenced by the deployment-architecture-at-scale
page, leaving broken images in each Tabs/TabItem.
* docs: fix 7 anchor mismatches from the fragment/heading audit
Covers three root causes from the anchor mismatch breakdown:
- Fragment repeated the target page's own title instead of a real
heading, so the link is simplified to point at the bare page.
- Heading exists verbatim but lives on a sibling settings page
(experimental-configuration-settings, push-notification-server-
configuration-settings) rather than environment-configuration-settings.
- A page path was mistakenly pasted into a same-page #fragment instead
of being used as a real cross-page link.
* docs: fix 8 anchor slugs that were close but didn't match the real heading
Repoints links whose fragment was a plausible guess (typo, reworded
heading, or wrong section) at the actual auto-generated slug of the
target heading, confirmed by inspecting each target page directly.
* docs: merge split Tabs blocks so tabs render horizontally
The div.tab conversion script split some sibling tab groups into
separate single-item Tabs blocks whenever a stray blockquote marker
sat between them, causing them to render stacked instead of as one
horizontal tab bar. Merges the MySQL/PostgreSQL and Team/Enterprise
Edition tab groups back into single Tabs blocks.
* docs: remove Azure tab and restore Kubernetes deploy content
The Mattermost Operator, Azure, and Oracle platform tabs on the
Kubernetes deployment guide were split across two separate Tabs
blocks (rendering stacked instead of as one tab bar) and all three
tab bodies were empty because the migration never flattened the
original RST include directives. Removes the unsupported Azure tab
and restores the Mattermost Operator and Oracle content from the
pre-migration RST sources as a single merged Tabs block.
* addresscoderabbitreview
* docs: unify Linux/Kubernetes/Containers deploy pages and fix FIPS/STIG placement
Kubernetes and Containers duplicated full install content across a top-level
page (Tabs) and orphaned sidebar subpages that nothing linked to. Reworked
both to follow the Linux page's pattern: shared content on the landing page,
platform-specific instructions live once in their own subpage.
Also removed configure-fips-at-install-time.mdx, which claimed FIPS is
available for native Linux installs — FIPS/STIG in Mattermost is a container
image property (Chainguard-based build), not available outside Docker/
Kubernetes. Consolidated all FIPS/STIG references onto
containers/fips-stig.mdx and pointed the Mattermost Operator subpage (not
Oracle OKE, which doesn't expose image selection) at it.
* docs: fix review findings — image alt text, Important callout markup, typo
- Replace generic alt="image" on scaling diagrams with descriptive text
identifying cloud provider and user scale.
- Convert raw div.important markup in deploy-containers.mdx to the
repo's <Important> component, matching usage elsewhere in the file.
- Fix "Matermost" typo in manage-your-display-options.mdx.
---------
Co-authored-by: Hanzo Dev <[email protected]>
95 lines
5.6 KiB
Plaintext
95 lines
5.6 KiB
Plaintext
---
|
|
title: "Deployment Architecture at Scale"
|
|
---
|
|
import Tabs from '@theme/Tabs';
|
|
import TabItem from '@theme/TabItem';
|
|
|
|
The following diagrams detail suggested architecture configurations of [high availability Mattermost deployments](/administration-guide/scale/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](/administration-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](/administration-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="/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="/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="/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="/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="/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="/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="/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="/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="/images/MattermostDeployment5kOracle.png" class="bg-white" alt="Mattermost high availability deployment architecture on Oracle Cloud Infrastructure for 5,000 users" />
|
|
|
|
</TabItem>
|
|
</Tabs>
|
|
|
|
</TabItem>
|
|
</Tabs>
|
|
|