고가용성 클러스터

Enterprise 플랜에서 사용 가능

이 기능은 레거시 Mattermost Enterprise Edition E20에서도 사용할 수 있습니다.

고가용성 클러스터는 중복되는 인프라를 사용하여 시스템이 서비스를 유지하고 하드웨어 장애와 정전 중에도 작동할 수 있도록 하는 것입니다.

Mattermost의 고가용성은 중복 Mattermost 애플리케이션 서버, 중복 데이터베이스 서버 및 중복 로드 밸런서를 실행하는 것으로 구성됩니다. 이러한 구성 요소 중 하나의 장애가 시스템 작동을 중단시키지 않습니다.

Note

이 문서는 Mattermost Server v4.0 이상에 적용됩니다.

지속적인 작동을 위한 요구 사항

서버 업데이트 및 업그레이드 중에도 항상 지속적인 작동을 보장하려면 중복된 구성 요소의 적절한 크기 조정 및 각 시스템 구성 요소를 올바른 순서로 업데이트해야합니다.

예상 규모에서의 중복성: 하나의 구성 요소가 실패할 경우 나머지 애플리케이션 서버, 데이터베이스 서버 및 로드 밸런서는 시스템의 전체 부하를 처리할 수 있도록 크기 및 구성되어야 합니다. 이 요구 사항을 충족하지 않으면 하나의 구성 요소 장애로 나머지 구성 요소에 과부하가 걸려 시스템 전체가 중단될 수 있습니다.
지속적인 작동을 위한 업데이트 순서: 대부분의 구성 변경 및 dot 릴리스 보안 업데이트를 적용할 때 시스템 구성 요소를 올바른 순서로 업데이트한다면 서비스를 중단시키지 않고 적용할 수 있습니다. 이에 대한 자세한 내용은 업그레이드 가이드 _를 참조하여 수행할 수 있습니다.

예외: 서버 재시작을 필요로 하는 구성 설정 변경 및 데이터베이스 스키마 변경이 포함된 서버 버전 업그레이드는 짧은 다운타임이 필요합니다. 서버 재시작의 다운타임은 약 5초입니다. 데이터베이스 스키마 업데이트의 경우 다운타임이 최대 30초까지 발생할 수 있습니다.

배포 가이드

고가용성을 설정하고 유지하는데 필요한 Mattermost 서버의 배포 가이드. 이 문서는 재해 복구 관점에서 데이터베이스 구성을 다루지 않지만, 궁금한 점이 있으면 자주 묻는 질문 (FAQ) _ 섹션을 참조할 수 있습니다.

고가용성을 위한 초기 설정 가이드

고가용성과 호환되는 인스턴스 및 구성을 보장하기 위해, 구성 및 호환성 _ 섹션을 검토하십시오.

Note

고가용성을 구성하기 전에 Mattermost 데이터베이스와 파일 저장 위치를 백업하세요. 백업에 대한 자세한 내용은 백업과 재해 복구 을(를) 참조하십시오.

동일한 구성 파일인 config.json 의 복사본을 사용하는 새로운 Mattermost 서버를 설정합니다. 각 독립적인 서버에 개별적인 사설 IP 주소를 통해 접속하여 서버가 제대로 작동하는지 확인합니다.
두 서버의 config.json 파일을 수정하여 ClusterSettings 를 추가합니다. 자세한 내용은 `고가용성 구성 설정</configure/environment-configuration-settings.html#high-availability>`__ 문서를 참조하십시오.
두 서버의 구성 파일이 동일한지 확인한 다음 클러스터의 각 기계를 다시 시작합니다.
NGINX 설정을 수정하여 두 서버로 프록시하도록 합니다. 자세한 내용은 프록시 서버 구성 설정 문서를 참조하십시오.
시스템 콘솔 > 환경 > 고가용성 을 열어 클러스터의 각 기계가 예상대로 통신하는지 확인합니다. 그렇지 않은 경우 로그 파일을 확인하여 추가 정보를 조사합니다.

클러스터에 서버 추가

Mattermost 데이터베이스 및 파일 저장 위치를 백업하세요. 백업에 대한 자세한 내용은 백업과 재해 복구 을(를) 참조하십시오.
새 Mattermost 서버를 설정하세요. 이 서버는 구성 파일 “config.json”의 동일한 사본을 사용해야 합니다. 개별 서버에 접근하여 서버가 작동하는지 확인하세요.
NGINX 설정을 수정하여 새 서버를 추가하세요.
시스템 콘솔 > 환경 > 고가용성 을 열어 모든 클러스터 기계가 예상대로 통신하고 있는지를 확인하세요. 그렇지 않으면 추가 정보를 얻기 위해 로그 파일을 조사하세요.

클러스터에서 서버 제거

Mattermost 데이터베이스 및 파일 저장 위치를 백업하세요. 백업에 대한 자세한 내용은 백업과 재해 복구 을(를) 참조하십시오.
NGINX 설정을 수정하여 서버를 제거하세요. 이에 대한 자세한 내용은 프록시 서버 구성 _을(를) 참조하십시오.
시스템 콘솔 > 환경 > 고가용성 을 열어 클러스터에 남아있는 모든 기계가 예상대로 통신하고 있는지를 확인하세요. 그렇지 않으면 추가 정보를 얻기 위해 로그 파일을 조사하세요.

구성 및 호환성

고가용성을 위한 시스템 설정에 대한 자세한 내용.

Mattermost Server 구성

구성 설정

고가용성은 “config.json”의 “ClusterSettings” 섹션에서 구성되며 해당 설정은 시스템 콘솔에서 볼 수 있습니다. 고가용성이 활성화되면 시스템 콘솔은 읽기 전용 모드로 설정되어 모든 Mattermost 서버의 “config.json” 파일이 항상 동일하게 유지됩니다. 그러나 고가용성 설정을 테스트하고 유효성을 검사할 때는 “ReadOnlyConfig”를 “false”로 설정하여 시스템 콘솔에서 수행한 변경 사항을 구성 파일에 다시 저장할 수 있습니다.

"ClusterSettings": {
        "Enable": false,
        "ClusterName": "production",
        "OverrideHostname": "",
        "UseIpAddress": true,
        "UseGossip": true,
        "ReadOnlyConfig": true,
        "GossipPort": 8074,
        "StreamingPort": 8075
}

이러한 설정에 대한 자세한 내용은 고가용성 구성 설정 문서를 참조하세요.

프로세스 제한을 8192로 변경하고 최대 파일 개수를 65536으로 변경합니다.

각 Mattermost 서버를 호스팅하는 각 기계의 “/etc/security/limits.conf”에 다음과 같은 줄을 추가하여 수정하세요.
* soft nofile 65536
* hard nofile 65536
* soft nproc 8192
* hard nproc 8192

WebSocket 연결 수를 증가합니다:

각 Mattermost 서버를 호스팅하는 각 기계의 “/etc/sysctl.conf”에 다음과 같은 줄을 추가하여 수정하세요.
net.ipv4.ip_local_port_range = 1025 65000
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_tw_reuse = 1
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 8192

프록시 서버에 대해서도 동일하게 적용할 수 있습니다.

클러스터 탐지

비표준(복잡한) 네트워크 구성이 있는 경우 클러스터 노드가 서로를 발견하는 데 도움이 되도록 호스트 이름 무시 설정을 사용해야 할 수 있습니다. 고가용성 모드에서 config 파일 해시에서 구성 설정이 제거되므로 고가용성 모드에서 약간 다른 “config.json” 파일을 가질 수 있습니다. Override Hostname은 각 클러스터 노드의 “config.json”에서 다른 값을 가져야 하는 경우를 위해 의도되었습니다.

만약 “UseIpAddress”가 “true”로 설정되어 있다면, IP 주소를 얻기 위해 첫 번째로 로컬이 아닌 IP 주소(루프백, 로컬 유니캐스트, 로컬 멀티캐스트 네트워크 인터페이스가 아님)를 찾으려 합니다. 내장된 go 함수 net.InterfaceAddrs() 를 사용하여 네트워크 인터페이스를 열거합니다. 그렇지 않다면 내장된 go 함수 os.Hostname() 을 사용하여 호스트 이름을 가져오려 합니다.

또한 데이터베이스에 대해 SELECT * FROM ClusterDiscovery 를 실행하여 Hostname 필드가 어떻게 채워졌는지 확인할 수 있습니다. 이 필드는 클러스터 내 다른 노드와의 연락을 시도할 호스트명 또는 IP 주소가 될 것입니다. “url Hostname:Port” 및 “Hostname:PortGossipPort”에 연결을 시도합니다. 클러스터가 올바르게 게시하기 위해 올바른 포트가 열려 있는지도 확인해야 합니다. 이러한 포트는 구성에서 “ClusterSettings” 아래에 있습니다.

요약하면 다음을 사용해야 합니다:

다른 머신에서 첫 번째 비로컬 주소가 볼 수 있다면 IP 주소 검색을 사용합니다.
클러스터 내 다른 노드에서 올바르게 찾을 수 있는 이름이 되도록 운영 체제에서 Hostname을 재정의합니다.
위 단계가 작동하지 않으면 “config.json”에서 Hostname을 재정의합니다. 필요한 경우 IP 주소를 이 필드에 넣을 수 있습니다. “config.json”은 각 클러스터 노드마다 다릅니다.

시간 동기화

클러스터의 각 서버는 메시지가 올바른 순서로 게시되도록 네트워크 시간 프로토콜 데몬인 ntpd 가 실행되어야 합니다.

상태

Mattermost 서버는 수평 확장을 허용하기 위해 매우 적은 상태를 가지도록 설계되었습니다. Mattermost 확장을 위해 고려되는 상태 항목은 아래와 같습니다:

빠른 유효성 검사 및 채널 액세스를 위한 메모리 내 세션 캐시
빠른 응답을 위한 메모리 내 온라인/오프라인 캐시
메모리에 로드되고 저장되는 시스템 구성 파일
메시지를 보내기 위해 클라이언트로부터 사용되는 WebSocket 연결

Mattermost 서버가 고가용성으로 구성되어 있을 때, 서버는 상태를 동기화하기 위해 다른 수신 주소에서 상태를 유지합니다. 상태 변경이 발생하면 데이터베이스에 기록되고 다른 서버에 상태 변경을 통지하는 데 사용되는 노드 간 메시지가 전송됩니다. 항상 데이터베이스에서 항목의 실제 상태를 읽을 수 있습니다. Mattermost는 또한 실시간 메시지를 위해 물론 WebSocket 메시지를 클러스터 내 다른 서버로 전달하기 위해 노드 간 통신을 사용합니다. “[사용자 X]가 입력 중입니다.”와 같은 실시간 메시지를 위해.

프록시 서버 구성

프록시 서버는 Mattermost 서버 클러스터를 외부 환경에 노출시킵니다. Mattermost 서버는 NGINX와 같은 프록시 서버, 하드웨어 로드 밸런서 또는 Amazon Elastic Load Balancer와 같은 클라우드 서비스와 함께 사용하기 위해 설계되었습니다.

서버를 상태 확인하려면 http://10.10.10.2/api/v4/system/ping 을 사용하고 Status 200 을 응답으로 받으면 in-service 또는 *out-of-service*로 표시하는 것이 좋습니다.

NGINX에 대한 샘플 구성은 아래에서 제공됩니다. 두 개의 Mattermost 서버가 각각 “10.10.10.2” 및 “10.10.10.4”의 사설 IP 주소에서 실행되고 있다고 가정합니다.

upstream backend {
        server 10.10.10.2:8065;
        server 10.10.10.4:8065;
  }

  server {
      server_name mattermost.example.com;

      location ~ /api/v[0-9]+/(users/)?websocket$ {
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            client_max_body_size 50M;
            proxy_set_header Host $http_host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Frame-Options SAMEORIGIN;
            proxy_buffers 256 16k;
            proxy_buffer_size 16k;
            proxy_read_timeout 600s;
            proxy_http_version 1.1;
            proxy_pass http://backend;
      }

      location / {
            client_max_body_size 50M;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Host $http_host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Frame-Options SAMEORIGIN;
            proxy_pass http://backend;
      }
}

단일 장애 지점을 제한하려면 여러 프록시 서버를 사용할 수 있지만, 이는 이 설명서의 범위를 벗어납니다.

파일 저장소 구성

Note

파일 저장소는 NAS 또는 Amazon S3와 같은 서비스를 사용하는 모든 기계간에 공유되었다고 가정합니다.
“DriverName”: “local”이 사용되는 경우, "FileSettings" 의 디렉터리인 "./data/" 에 매핑된 NAS 위치를 지역 디렉터리로 예상합니다. 그렇지 않으면 고가용성이 올바르게 작동하지 않을 수 있고 파일 저장소가 손상될 수 있습니다.
Amazon S3 또는 MinIO를 파일 저장소로 사용하는 경우 다른 구성이 필요하지 않습니다.

Mattermost Enterprise에서 규정 준수 보고서 기능을 사용하는 경우 "ComplianceSettings" 의 "Directory": "./data/", 를 모든 기계간에 공유해야 합니다. 그렇지 않으면 보고서는 지역 Mattermost 서버의 시스템 콘솔에서만 사용할 수 있습니다.

NAS 또는 S3로의 마이그레이션은 본 문서의 범위를 벗어납니다.

데이터베이스 구성

Tip

Mattermost 환경 변수를 사용하여 구성 설정 값을 지정하면 항상 다른 구성 설정보다 우선시됩니다.

AWS 고가용성 RDS 클러스터 배포의 경우, AWS 장애 조치 처리를 활용하기 위해 datasource 구성 설정을 클러스터 수준의 쓰기/읽기 엔드포인트로 지정하십시오. AWS는 다양한 데이터베이스 노드를 작성자 노드로 승격시키는 작업을 관리합니다. Mattermost가 이를 관리할 필요가 없습니다.

데이터베이스 확장을 위해 read replica 기능을 사용하십시오. Mattermost 서버를 구성하여 하나의 마스터 데이터베이스와 하나 이상의 읽기 복제본 데이터베이스를 사용할 수 있습니다.

Note

AWS 고가용성 RDS 클러스터 배포의 경우 IP 주소를 하드코딩하지 마십시오. 이 구성 설정을 클러스터 수준의 쓰기/읽기 엔드포인트로 지정하십시오. 이렇게 하면 AWS가 다양한 데이터베이스 노드를 작성자 노드로 승격시키는 장애 조치 처리를 활용할 수 있습니다. Mattermost가 이를 관리할 필요가 없습니다.

대규모 배포의 경우 search replica 기능을 사용하여 하나 이상의 검색 복제본에 검색 쿼리를 격리하는 것도 고려하십시오. 검색 복제본은 읽기 복제본과 유사하지만 검색 쿼리 처리에만 사용됩니다.

Note

AWS 고가용성 RDS 클러스터 배포의 경우 IP 주소를 하드코딩하지 마십시오. 이 구성 설정을 RDS 클러스터 내의 읽기 전용 노드 엔드포인트로 직접 지정하십시오. AWS/RDS가 처리하는 장애 조치/로드 밸런싱을 우회하는 것이 좋습니다 (쓰기 트래픽은 제외). Mattermost에는 읽기 전용 연결을 균형잡는 고유한 방법이 있으며, 이러한 쿼리를 DataSource/쓰기+읽기 연결로 분산시킬 수도 있습니다.

Mattermost는 쿼리를 다음과 같이 분산합니다:

모든 쓰기 요청과 일부 특정 읽기 요청은 마스터로 전송됩니다.
다른 모든 읽기 요청(마스터로 전송되는 특정 쿼리를 제외하고)은 사용 가능한 읽기 복제본 사이에 분산됩니다. 읽기 복제본을 사용할 수 없는 경우 이러한 요청은 대신 마스터로 전송됩니다.
검색 요청은 사용 가능한 검색 복제본 사이에 분산됩니다. 검색 복제본을 사용할 수 없는 경우 이러한 요청은 대신 읽기 복제본으로 전송됩니다(또는 읽기 복제본을 사용할 수 없는 경우 마스터로 전송됩니다).

데이터베이스 크기 조정

데이터베이스 서버 크기 조정에 대한 정보는 엔터프라이즈용 하드웨어 크기 조정 을 참조하십시오.

마스터/슬레이브 환경에서는 마스터 머신이 다운되었을 때 100%의 부하를 처리할 수 있도록 슬레이브 머신의 크기를 조정해야 합니다.

다중 데이터베이스 구성 배치

다중 데이터베이스 Mattermost 서버를 구성하려면:

config.json 의 DataSource 설정을 마스터 데이터베이스 서버에 대한 연결 문자열로 업데이트합니다.
config.json 의 DataSourceReplicas 설정을 데이터베이스 읽기 복제본 서버에 대한 일련의 연결 문자열로 업데이트합니다. 각 연결은 또한 DriverName 설정과 호환되어야 합니다.

다음은 하나의 마스터 및 두 개의 읽기 복제본에 대한 예제 SqlSettings 블록입니다:

"SqlSettings": {
      "DriverName": "mysql",
      "DataSource": "master_user:master_password@tcp(master.server)/mattermost?charset=utf8mb4,utf8\u0026readTimeout=30s\u0026writeTimeout=30s",
      "DataSourceReplicas": ["slave_user:slave_password@tcp(replica1.server)/mattermost?charset=utf8mb4,utf8\u0026readTimeout=30s\u0026writeTimeout=30s","slave_user:slave_password@tcp(replica2.server)/mattermost?charset=utf8mb4,utf8\u0026readTimeout=30s\u0026writeTimeout=30s"],
      "DataSourceSearchReplicas": [],
      "MaxIdleConns": 20,
      "MaxOpenConns": 300,
      "Trace": false,
      "AtRestEncryptKey": "",
      "QueryTimeout": 30
  }

새로운 설정은 서버를 중지하고 다시 시작하거나, 다음 섹션에 설명된대로 구성 설정을 로드하여 적용할 수 있습니다.

로드된 후, 데이터베이스 쓰기 요청은 마스터 데이터베이스로 보내지고, 읽기 요청은 목록의 다른 데이터베이스 사이에서 분산됩니다.

활성 서버에 다중 데이터베이스 구성 로드

다중 데이터베이스 구성이 config.json 에 정의된 후, Mattermost 서버를 중지시키지 않고 다음 설정을 적용하는 데 사용할 수 있는 절차는 다음과 같습니다.

시스템 콘솔 > 환경 > 웹 서버 로 이동한 후, 디스크에서 구성 재로드 를 선택하여 config.json 에서 Mattermost 서버를 위한 구성 설정을 다시 로드합니다.
시스템 콘솔 > 환경 > 데이터베이스 로 이동한 후, 데이터베이스 연결 재생성 을 선택하여 기존의 데이터베이스 연결을 끊고 다중 데이터베이스 구성에 새로운 연결을 설정합니다.

연결 설정이 변경되는 동안, 마스터 데이터베이스로의 쓰기가 성공하지 못할 수 있는 짧은 순간이 발생할 수 있습니다. 프로세스는 모든 기존 연결이 완료될 때까지 기다리고 새로운 연결로 새로운 요청을 제공하기 시작합니다. 스위치가 진행되는 동안 메시지를 보내려는 최종 사용자들은 Mattermost 서버와의 연결이 끊겨 있는 것과 유사한 경험을 할 수 있습니다.

마스터 데이터베이스를 수동으로 장애 조치: 예를 들어 현재의 마스터 데이터베이스를 사용할 수 없게 되는 경우 - 예를 들어, 디스크 공간이 부족한 경우, 또는 유지 관리 업데이트가 필요한 경우, 또는 다른 이유로 인한 경우 - config.json 의 DataSource `` 를 업데이트하여 Mattermost 서버가 읽기 레플리카 중 하나를 마스터 데이터베이스로 사용하도록 전환할 수 있습니다.

Mattermost 서버를 중지시키지 않고 설정을 적용하려면:

시스템 콘솔 > 환경 > 웹 서버 로 이동한 후, 디스크에서 구성 재로드 를 선택하여 config.json 에서 Mattermost 서버를 위한 구성 설정을 다시 로드합니다.
시스템 콘솔 > 환경 > 데이터베이스 로 이동한 후, 데이터베이스 연결 재생성 을 선택하여 기존의 데이터베이스 연결을 끊고 다중 데이터베이스 구성에 새로운 연결을 설정합니다.

연결 설정이 변경되는 동안, 마스터 데이터베이스로의 쓰기가 성공하지 못할 수 있는 짧은 순간이 발생할 수 있습니다. 프로세스는 모든 기존 연결이 완료될 때까지 기다리고 새로운 연결로 새로운 요청을 제공하기 시작합니다. 스위치가 진행되는 동안 스위치가 진행되는 동안 메시지를 보내려는 최종 사용자들은 Mattermost 서버와의 연결이 끊겨 있는 것과 유사한 경험을 할 수 있습니다.

투명한 장애 조치: ``

기존의 데이터베이스 기술을 사용하여 데이터베이스를 고가용성 및 투명한 장애 조치를 위한 구성할 수 있습니다. 데이터베이스 투명한 장애 조치는 PostgreSQL 클러스터링이나 Amazon Aurora를 권장합니다. 데이터베이스 투명한 장애 조치는 이 문서의 범위를 벗어납니다.

PostgreSQL의 권장 구성 설정: ``

데이터베이스로 PostgreSQL을 사용하는 경우, Mattermost 서버에서 다음과 같은 구성 최적화를 권장합니다. 이러한 구성은 PostgreSQL 11.7의 AWS Aurora r5.xlarge 인스턴스에서 테스트되었습니다. 또한 서버 사양이 더 높은 일반적인 최적화도 언급되어 있습니다.

Postgres 기본 노드 설정

 # 인스턴스가 r5.xlarge보다 용량이 낮으면 해당 수를 낮춥니다.
 # 또한 Mattermost 앱의 "SqlSettings" 하위의 "MaxOpenConns" 설정도 해당에 따라 조정해야 합니다.
 # Mattermost의 "MaxOpenConns"는 데이터 소스 이름 당입니다.
 max_connections = 1024

 # 디스크가 회전하는 디스크를 사용하지 않는 한, 1.1로 설정합니다.
 random_page_cost = 1.1

 # 읽기 레플리카를 사용하는 경우 32MB, 단일 PostgreSQL 인스턴스를 사용하는 경우 16MB여야 합니다.
 # 인스턴스가 r5.xlarge보다 용량이 낮으면 해당 수를 낮춥니다.
 work_mem = 32MB

 # 아래 설정 둘 다 총 메모리의 65%로 설정합니다. 32GB 인스턴스의 경우 21GB이어야 합니다.
 # 더 작은 서버의 경우 전체 RAM의 20% 또는 그 이하로 설정합니다.
 # 예: 512MB의 경우 4GB RAM 서버에는 작동합니다.
 effective_cache_size = 21GB
 shared_buffers = 21GB

 # DB 앞단에 pgbouncer 또는 유사한 연결 풀링 프록시를 사용하는 경우,
 # 해당 프록시에 keepalive 설정을 적용하고 DB의 keepalive 설정을 기본값으로 되돌리십시오.
 tcp_keepalives_idle = 5
 tcp_keepalives_interval = 1
 tcp_keepalives_count = 5

 # 1GB (32GB RAM 미만인 경우 이 값을 512MB로 줄입니다)
 maintenance_work_mem = 512MB

 autovacuum_max_workers = 4
 autovacuum_vacuum_cost_limit = 500


 # 데이터베이스 서버에서 32개 이상의 CPU를 사용하는 경우, 다음 옵션을 설정하여 서버에서 더 많은 CPU를 활용하도록 합니다.
 max_worker_processes = 12
 max_parallel_workers_per_gather = 4
 max_parallel_workers = 12
 max_parallel_maintenance_workers = 4

**Postgres 레플리카 노드 설정**

모든 위의 설정을 읽기 레플리카에 복사하고, 다음을 수정하거나 추가하십시오.

# 인스턴스가 r5.xlarge보다 용량이 낮으면 해당 수를 낮춥니다.
# 또한 Mattermost 앱의 "SqlSettings" 하위의 "MaxOpenConns" 설정도 해당에 따라 조정해야 합니다.
max_connections = 1024

# 이 설정은 읽기 노드에서는 16MB이고, 라이터 노드에서는 32MB입니다.
work_mem = 16MB

# 아래 설정은 프라이머리에 쓰기 프로세스가 실행 중일 때라도 리더가 쿼리 결과를 반환할 수 있게 합니다.
# 쿼리 충돌이 발생할 때라도 리더가 쿼리 결과를 반환할 수 있게 합니다.
# 이는 리더가 타임아웃 내에 쿼리 결과를 반환하지 못할 수 있는 높은 쓰기 트래픽 때문에 설정된 것입니다.
# https://www.postgresql.org/docs/current/hot-standby.html#HOT-STANDBY-CONFLICT

``hot_standby``   를   ``on``   으로 설정합니다.
``hot_standby_feedback``   를   ``on``   으로 설정합니다.

Leader election

클러스터 리더 선출 프로세스는 다중 노드 클러스터 환경에서 LDAP 동기화와 같은 예약된 작업을 단일 노드에 할당합니다.

이 프로세스는 널리 사용되는 bully leader election algorithm 를 기반으로 합니다. 여기서는 실패하지 않은 프로세스 중에서 노드 ID 번호가 가장 낮은 프로세스가 리더로 선출됩니다.

작업 서버

Mattermost 는 작업 서버 를 통해 주기적인 작업을 수행합니다.

이러한 작업에는 다음이 포함됩니다:

LDAP 동기화
데이터 보존
컴플라이언스 내보내기
Elasticsearch 색인

클러스터의 모든 앱과 작업 서버의 config.json 에서 JobSettings.RunScheduler 를 true 로 설정했는지 확인하세요. 그러면 클러스터 리더가 주기적인 작업을 예약하게 됩니다.

Note

true 로 설정된 기본 설정을 변경하지 않는 것이 강력히 권장됩니다. 이로 인해 ClusterLeader 가 스케줄러를 실행할 수 없게 되는 문제가 발생할 수 있습니다. 따라서 LDAP 동기화, 컴플라이언스 내보내기 및 데이터 보존과 같은 주기적인 작업이 더 이상 예약되지 않을 수 있습니다.

이전 Mattermost Server 버전 및 이 설명서에서는 Job Server 를 RunScheduler: false 로 실행할 것을 명시했습니다. 그러나 클러스터 디자인이 발전하면서 이러한 경우가 더는 해당되지 않습니다.

플러그인 및 고가용성

플러그인을 설치하거나 업그레이드하면 클러스터의 모든 서버에 자동으로 전파됩니다. 파일 저장소는 NAS 또는 Amazon S3와 같은 서비스를 사용하여 모든 서버간에 공유되는 것으로 가정합니다.

만약 "DriverName": "local" 라면, "FileSettings": "Directory": "./data/" 에서 NAS 위치로 매핑된 로컬 디렉터리가 예상됩니다. 그렇지 않은 경우 고가용성이 올바르게 작동하지 않을 수 있으며 파일 저장소가 손상될 수 있습니다.

v5.14에서 플러그인을 다시 설치할 경우 이전 활성화 또는 비활성화 상태가 유지됩니다. v5.15부터는 다시 설치된 플러그인의 초기 상태가 비활성화 로 설정됩니다.

CLI와 고가용성

CLI는 고가용성 환경 에 사용되는 메커니즘을 우회하여 단일 노드에서 실행됩니다. 따라서 고가용성 환경에서 CLI 명령 을 실행할 때 사용자 업데이트 및 삭제 또는 구성 설정 변경과 같은 작업에 서버 재시작이 필요합니다.

서버 재시작이 필요하지 않은 mmctl 을 고가용성 환경에서 사용하는 것을 권장합니다. 이 변경 사항은 API 레이어를 통해 이루어지며, 변경 요청을 받은 노드가 클러스터 내의 모든 다른 노드에 통지합니다.

업그레이드 가이드

업데이트는 Mattermost 서버에 버그나 성능 문제를 해결하는 점진적인 변경입니다. 업그레이드는 서버에 새로운 기능을 추가하거나 기능을 향상시키는 것입니다.

운영중에 설정 변경 사항 업데이트

대부분의 설정 업데이트에는 서비스 중단이 필요하지 않습니다. 서비스 중단이 필요한 업그레이드에 대한 자세한 내용은 아래 섹션을 참조하세요. 작업량이 적은 시간에 업데이트할 수 있지만, 고가용성 클러스터는 올바르게 구성되어 있기 때문에 언제든지 수행할 수 있습니다. 시스템 다운타임은 짧으며, Mattermost 서버의 수에 따라 다릅니다. 머신을 재시작하는 것이 아니라 Mattermost 서버 애플리케이션만 다시 시작하는 것입니다. Mattermost 서버 재시작은 일반적으로 약 다섯 초 정도 소요됩니다.

Note

시스템 콘솔을 통해 구성 설정을 수정하지 마십시오. 그렇게 하면 고가용성 클러스터의 서버마다 다른 config.json 파일을 가지고 있게 되어 사용자가 다른 앱 서버에 연결할 때마다 새로고침이 발생합니다.

기존의 config.json 파일을 백업하세요.
Mattermost 서버 중 하나에 대해 config.json 을 수정하고 파일을 저장하세요. 파일을 아직 다시 로드하지 마세요.
config.json 파일을 다른 서버에 복사하세요.
하나의 서버를 제외한 모든 서버에서 Mattermost를 중지하세요.
여전히 실행 중인 서버에서 구성 파일을 다시 로드하세요. 시스템 콘솔 > 환경 > 웹 서버 로 이동한 다음 디스크로부터 구성 다시 로드 를 선택하세요.
다른 서버를 시작하세요.

서버 버전 업데이트 중에 운영 계속

Mattermost 서버의 보안 패치 dot 릴리스에는 서비스 중단이 필요하지 않습니다. 예상된 작업량이 적은 시간에 업데이트를 적용할 수 있습니다.새 요청을 모두 단일 서버로 이동하도록 프록시를 설정하세요. 예를 들어 NGINX를 사용하고 있다면, /etc/nginx/sites-available/mattermost 에서 upstream backend 섹션으로 구성되어 있으며 여기에서 첫 번째 서버만 주석 처리하고 NGINX를 다시 로드하세요. 5. 각 중지된 Mattermost 인스턴스를 업데이트하세요. 6. 각 서버에서 새로운 config.json 파일을 백업된 복사본으로 대체하세요. 7. Mattermost 서버를 시작합니다. 8. 남아있는 서버에 대해 업데이트 프로시저를 반복하세요.

서버 업그레이드가 서비스 중단이 필요한 경우

데이터베이스 스키마 변경이 포함되거나 config.json 변경으로 서버 재시작이 필요한 경우에는 서비스 중단이 필요합니다.

데이터베이스 스키마 변경이 포함된 업그레이드인 경우, 시작하는 서버에서 데이터베이스가 업그레이드됩니다.

작업량이 적은 시간에 업데이트를 적용하세요. 시스템 다운타임은 짧으며, Mattermost 서버의 수에 따라 다릅니다. 머신을 재시작하는 것이 아니라 Mattermost 서버 애플리케이션만 다시 시작하는 것입니다.

업그레이드 Mattermost 서버 의 Upgrade Enterprise Edition 섹션에서 업그레이드 절차를 검토합니다.
기존의 config.json 파일을 백업하세요.
NGINX를 중지하세요.
각 Mattermost 인스턴스를 업데이트하세요.
각 서버에서 새로운 config.json 파일을 백업된 복사본으로 대체하세요.
Mattermost 서버 중 하나를 시작하세요.
서버가 실행되면 다른 서버를 시작하세요.
NGINX를 다시 시작하세요.

4.0 이상 버전으로 업그레이드

서버가 시작되면 동일한 클러스터 내의 다른 서버를 자동으로 탐색할 수 있습니다. 구성 파일인 config.json``을 수정할 필요없이 서버를 추가하거나 제거할 수 있습니다. 이 기능을 지원하기 위해 ``config.json 의 ClusterSettings 섹션에 새로운 항목이 추가되었습니다.

업그레이드 Mattermost 서버 에서 업그레이드 절차를 검토합니다.
기존의 config.json 파일을 백업합니다.
기존의 config.json 을 수정하여 ClusterSettings 섹션을 업데이트합니다. 대부분의 경우 다음 설정이 작동해야 합니다:
```
"ClusterSettings": {
    "Enable": true,
    "ClusterName": "production",
    "OverrideHostname": "",
    "UseIpAddress": true,
    "UseGossip": true,
    "ReadOnlyConfig": true,
    "GossipPort": 8074,
    "StreamingPort": 8075
},
```
이러한 설정에 대한 자세한 내용은 고가용성 구성 설정 문서를 참조하세요.
NGINX를 중지합니다.
각 Mattermost 인스턴스를 업그레이드합니다.
각 서버에서 새 config.json 파일을 수정된 버전으로 교체합니다.
Mattermost 서버 중 하나를 시작합니다.
서버가 실행되면 다른 서버를 시작합니다.
NGINX를 다시 시작합니다.

모든 클러스터 노드는 단일 프로토콜을 사용해야 합니다

모든 클러스터 트래픽은 gossip 프로토콜을 사용합니다. 더 이상 gossip 클러스터링을 비활성화할 수 없습니다 .

고가용성 클러스터를 업그레이드할 때, 한 노드가 gossip 프로토콜을 사용하지 않을 때 클러스터의 다른 노드를 업그레이드할 수 없습니다. 고가용성 업그레이드를 완료하려면 gossip를 사용해야 합니다. 또는 모든 노드를 종료하고 업그레이드 후 개별적으로 모두 시작할 수 있습니다.

자주 묻는 질문 (FAQ)

Mattermost는 멀티 리전 고가용성 배포를 지원합니까?

예. 공식적으로 테스트되지는 않았지만 AWS 리전을 가로질러 클러스터를 설정하면 잘 작동할 것으로 예상됩니다.

데이터베이스의 재해 복구를 위해 Mattermost가 권장하는 방법은 무엇입니까?

고가용성 구성으로 Mattermost를 배포할 때, Mattermost와 데이터베이스 사이에 데이터베이스 로드 밸런서를 사용하는 것을 권장합니다. 배포에 따라 더 많거나 적은 고려 사항이 필요합니다.

예를 들어, Amazon Aurora에서 Mattermost를 배포하는 경우, 여러 가용 영역을 활용하는 것을 권장합니다. 고객 자체 클러스터에 Mattermost를 배포하는 경우, 현재 아키텍처에 가장 적합한 솔루션을 IT 팀과 상의하십시오.

문제 해결

고가용성 문제 해결 데이터 캡처

Mattermost를 고가용성 구성으로 배포할 때, 엄청나게 긴 Prometheus와 Grafana 메트릭과 클러스터 서버 로그를 가능한 한 오랫동안 보관하는 것을 권장합니다. 적어도 두 주 동안은 보관하시기 바랍니다.

Mattermost 분석 및 문제 해결 목적으로 이러한 데이터를 Mattermost에 제공해야 할 수도 있습니다.

Note

서버 로그 파일이 생성되도록 해야 합니다. Mattermost 로그 사용에 대한 자세한 정보는 여기에서 확인하세요 .
문제를 조사하고 복제하는 경우, 시스템 콘솔 > 환경 > 로깅 을 열고 파일 로그 수준 을 DEBUG 로 설정하여 더 완전한 로그를 얻도록 권장합니다. 문제 해결 후 디스크 공간을 절약하기 위해 INFO 로 되돌려 놓으시기 바랍니다.
각 서버는 자체 서버 로그 파일을 가지고 있으므로 고가용성 클러스터의 모든 서버에 대한 서버 로그를 제공해야 합니다.

빨간색 서버 상태

고가용성이 활성화되면 시스템 콘솔에서 서버 상태가 빨간색 또는 녹색으로 표시됩니다. 이는 서버가 클러스터와 올바르게 통신하는지 여부를 나타냅니다. 서버는 상호 노드 통신을 사용하여 클러스터 내 다른 기기들에 핑을 보내며, 핑이 수립되면 서버 버전 및 구성 파일과 같은 정보를 교환합니다.

빨간색 서버 상태는 다음과 같은 이유로 발생할 수 있습니다:

구성 파일 불일치: Mattermost는 여전히 상호 노드 통신을 시도하지만, 고가용성 기능은 올바르게 기능하려면 동일한 구성 파일을 가정하기 때문에 시스템 콘솔에서 해당 서버에 대한 빨간색 상태가 표시됩니다.
서버 버전 불일치: Mattermost는 여전히 상호 노드 통신을 시도하지만, 고가용성 기능은 클러스터 내 각 서버에 동일한 Mattermost 버전이 설치되어 있음을 가정하기 때문에 시스템 콘솔에서 해당 서버에 대한 빨간색 상태가 표시됩니다. 클러스터 내 각 서버에서는 Mattermost의 최신 버전을 사용하는 것이 권장됩니다 . 필요한 경우 업그레이드 Mattermost 서버 의 업그레이드 절차를 따르십시오.
서버 다운: 서로 노드 통신이 메시지를 보내지 못하면 15초 후에 다시 시도합니다. 두 번째 시도가 실패하면 서버가 다운되었다고 간주됩니다. 오류 메시지가 로그에 기록되고 시스템 콘솔에서 해당 서버에 대한 빨간색 상태가 표시됩니다. 서로 노드 통신은 다운된 서버에 15초 간격으로 계속 ping을 보냅니다. 서버가 다시 올라오면 새로운 메시지가 해당 서버로 보내집니다.

WebSocket 연결 끊김

클라이언트 WebSocket이 연결 끊김을 받으면 백오프로 3초마다 자동으로 다시 연결을 시도합니다. 연결이 수립되면 클라이언트는 연결이 끊겨 있을 때 전송된 메시지를 받도록 시도합니다.

앱이 계속 새로 고침됨

고가용성 클러스터의 경우, 시스템 콘솔을 통해 구성 설정이 수정되면 사용자가 다른 앱 서버에 연결될 때마다 클라이언트가 계속해서 새로 고침됩니다. 이는 고가용성 클러스터의 서버가 서로 다른 config.json 파일을 가지고 있는데 그로 인해 발생합니다.

계속해서 운영 중에 구성 설정을 config.json 을 통해 직접 수정하려면 다음 단계를 따르십시오 .

메시지가 새로 고침 후에만 게시

고가용성 모드로 실행할 때, 모든 Mattermost 애플리케이션 서버가 동일한 Mattermost 버전을 실행하고 있는지 확인하십시오. 서로 다른 버전을 실행하면 하위 버전의 앱 서버가 요청을 처리하지 못하고 요청이 새로 고침되고 유효한 Mattermost 버전을 사용하는 서버로 보내질 때까지 대기될 수 있습니다. 무작위로 실패하는 요청이나 특정한 응용 프로그램 서버에서 고루틴 및 API 오류가 급증하는 경우에 대비할 증상이 있습니다.

Mattermost 원문 보기