Galera DB를 사용하여 Nextcloud 고가용성 클러스터를 설정하는 방법

Galera를 사용한 Nextcloud 고가용성 배포는 단순히 세 대의 데이터베이스 서버만으로 구성되는 것이 아니라, 통합된 시스템입니다. 이중화된 Nextcloud 애플리케이션 노드, 공유 및 영구적인 파일 데이터 계층, 분산 캐싱 및 파일 잠금, 로드 밸런싱, 모니터링, 그리고 검증된 백업이 필요합니다. Galera는 쿼럼이 유지되는 한 데이터베이스 노드 장애 발생 후에도 데이터베이스 서비스를 계속 사용할 수 있도록 지원하지만, 다른 구성 요소들의 고가용성을 보장하지는 않습니다.

이 가이드는 MariaDB Galera와 리버스 프록시 또는 로드 밸런서를 사용하는 벤더 중립적인 Linux 설계를 기반으로 합니다. 패키지 이름, 서비스 이름, Galera 공급자 경로, 부트스트랩 명령 및 프록시 상태 확인 통합은 배포판 및 MariaDB 릴리스에 따라 다를 수 있습니다. 배포 전에 해당 릴리스의 문서를 참조하여 확인하십시오. Nextcloud의 최신 안정 버전 관리 설명서에서는 PostgreSQL과 MariaDB를 권장 데이터베이스 엔진으로 나열하고 있으며, 지원되는 버전이 다를 수 있다고 경고합니다. 실행하려는 릴리스 의 Nextcloud 시스템 요구 사항을 확인하십시오 . 이 문서는 2026년 10월 6일에 Nextcloud 35 안정 버전 설명서를 기준으로 검토되었습니다.

먼저 적절한 가용성 설계 방식을 선택하세요.

Galera는 MySQL 호환 서버를 위한 동기식 다중 프라이머리 복제 방식입니다. 트랜잭션은 클러스터 전체에서 인증되므로 구성원 간의 일관성을 유지하는 데 도움이 되지만, 조정 오버헤드가 발생하고 충돌하는 트랜잭션은 거부될 수 있습니다. 데이터베이스 노드를 추가한다고 해서 Nextcloud의 처리량이 자동으로 증가하는 것은 아닙니다. Nextcloud 개발자 가이드에서는 클러스터 구성에 성능 저하가 발생하며 데이터베이스와 스토리지는 여전히 중요한 공유 리소스라고 명시하고 있습니다.

새로운 설치의 경우, 운영팀에서 지원할 수 있다면 독립적인 호스트에 분산된 3개의 데이터 노드로 구성된 Galera 클러스터가 일반적인 시작점입니다. Galera 쿼럼은 과반수를 필요로 하므로, 2개의 노드로 구성된 클러스터는 한 멤버에 장애가 발생하더라도 자동으로 안전하게 페일오버될 수 없습니다. 3개의 노드는 하나의 멤버가 사용 불가능하더라도 나머지 두 멤버는 연결된 상태를 유지할 수 있습니다. 가능한 경우 장애 도메인에 걸쳐 노드를 배치하되, 테스트 없이 지연 시간이 긴 링크를 통해 동기 복제를 확장하지 마십시오. 복잡성이 낮은 환경의 경우, 지원되는 단일 데이터베이스와 잘 테스트된 백업 및 복구 계획을 사용하는 것이 좋습니다.

설치하기 전에: "고가용성"이 무엇을 의미하는지 결정하세요.

웹 프로세스, 웹 호스트, 데이터베이스 호스트, 로드 밸런서, 스토리지 엔드포인트, 네트워크 경로 또는 전체 사이트와 같이 예상되는 장애 유형을 명시하십시오. 각 유형에 대한 복구 목표를 설정하십시오. 데이터베이스 노드 3개와 로드 밸런서 1개로 구성된 설계는 완전한 이중화를 보장하지 않습니다. 사용자 파일이 하나의 웹 서버 로컬 디스크에만 존재하는 애플리케이션 클러스터 또한 마찬가지입니다.

모든 애플리케이션 노드에서 일관된 Nextcloud 릴리스, PHP 런타임, 애플리케이션 세트 및 구성을 사용하십시오. MariaDB 및 Galera 버전은 서로 호환되고 선택한 Nextcloud 릴리스에서 지원되는 버전을 선택하십시오. Nextcloud 데이터베이스 요구 사항에는 InnoDB, READ COMMITTED 트랜잭션 격리, 바이너리 로깅 또는 ROW 형식 비활성화가 포함됩니다. 현재 요구 사항을 확인하지 않고 다른 버전의 튜닝 값을 복사하지 마십시오.

클러스터를 12단계로 설정하세요

1. 호스트 이름, 주소 및 서비스 엔드포인트를 예약합니다.

각 데이터베이스 멤버, 웹 노드, 캐시 서비스, 공유 스토리지 및 공용 웹 엔드포인트에 대해 개인 DNS 이름 또는 안정적인 주소를 생성하십시오. Nextcloud PHP 노드용으로 별도의 안정적인 데이터베이스 엔드포인트를 예약하십시오. 인프라가 허용하는 경우 애플리케이션, 복제 및 공용 트래픽을 적절하게 분리된 네트워크 경로에서 유지하십시오. 노드 이름은 고유해야 하며 모든 클러스터 멤버는 Galera 피어를 일관되게 확인해야 합니다.

2. 호환되는 데이터베이스와 Galera 릴리스를 설치합니다.

운영 체제에 권장되는 벤더 저장소를 사용하여 MariaDB 서버와 Galera 공급자를 설치하십시오. 모든 멤버에 동일한 주요 서버 및 공급자 제품군을 유지하십시오. 임의로 커뮤니티 패키지를 별도로 다운로드한 공급자 라이브러리와 함께 사용하지 마십시오. 진행하기 전에 해당 패키지 세트에 대해 지원되는 업그레이드 경로, SST 방법, 서비스 단위 및 구성 포함 디렉터리를 확인하십시오.

3. Nextcloud의 데이터베이스 요구 사항을 적용합니다.

서버를 InnoDB 데이터베이스와 READ COMMITTED 트랜잭션 격리 수준으로 설정하십시오. 바이너리 로깅이 활성화된 경우 ROW 바이너리 로깅을 사용하십시오. 구성 파일이 포함되었다고 가정하지 말고 재시작 후 유효 값을 확인하십시오. Nextcloud는 데이터베이스 구성 가이드 및 시스템 요구 사항 에 이러한 요구 사항을 명시하고 있습니다 .

4. 세 멤버 모두에서 Galera를 일관되게 구성하십시오.

벤더의 구성 참조를 사용하여 클러스터 이름, 피어 주소 목록, 각 노드의 고유 이름 및 주소, 공급자 라이브러리, 상태 스냅샷 전송(SST) 방법을 설정하십시오. SST는 참여하는 노드에 데이터베이스 상태를 프로비저닝하는 프로세스입니다. 일반적인 MariaDB 클러스터 구성에는 다음과 같은 옵션이 포함됩니다.

[mariadb]
wsrep_on=ON
wsrep_cluster_name=nextcloud-cluster
wsrep_cluster_address=gcomm://db1.example.net,db2.example.net,db3.example.net
wsrep_node_name=db1
wsrep_node_address=db1.example.net
wsrep_sst_method=mariabackup
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
transaction_isolation=READ-COMMITTED

각 서버에서 노드별 값을 변경하십시오. 공급자 경로 및 지원되는 SST 메서드는 설치된 패키지에 따라 다르므로, 사용 중인 릴리스에 맞는 문서화된 메서드와 자격 증명을 사용하십시오. SST 자격 증명, 인증서 및 데이터베이스 암호는 비밀 정보로 보호하십시오. 클러스터 주소를 비워둔 상태로 영구 설정하지 마십시오. MariaDB 문서에 따르면 클러스터 주소를 비워두면 서버가 기존 클러스터에 다시 참여하는 대신 새 클러스터를 시작할 수 있습니다.

5. 필요한 피어에게만 네트워크 접근을 허용합니다.

웹 계층은 데이터베이스 서비스 엔드포인트에만 접근할 수 있도록 허용하고, 데이터베이스 구성원들은 선택한 공급자와 SST(상태 스냅샷 전송) 방식에 필요한 Galera 복제 및 상태 전송 포트를 통해 서로 통신할 수 있도록 허용하십시오. 일반적인 Galera 배포 환경에서는 그룹 통신에 TCP를 사용하고, 공급자 설정에 따라 UDP를 사용하기도 합니다. 관련 기본값에는 복제용 4567, 증분 상태 전송용 4568, 상태 스냅샷 전송용 4444가 포함되는 경우가 많습니다. 이러한 포트들은 사용 중인 버전 및 구성과 일치하는지 확인하는 체크리스트로만 활용하고, 모든 포트를 무작정 개방해서는 안 됩니다. SQL 포트는 비공개로 유지하고 공용 접근을 차단하십시오.

6. 첫 번째 노드를 부트스트랩한 다음 나머지 노드들을 결합합니다.

배포판의 MariaDB 패키지에 설명된 부트스트랩 절차를 사용하여 클러스터를 정확히 한 번 초기화하십시오. 첫 번째 멤버가 기본 구성 요소를 형성하는지 확인한 후 나머지 멤버를 정상적으로 시작하여 기본 구성 요소에 참여하고 IST 또는 SST를 통해 상태를 수신하도록 하십시오. IST는 사용 가능한 경우 누락된 쓰기 세트를 전송하고, SST는 전체 상태 전송을 수행합니다. 각 호스트를 개별적으로 부트스트랩하지 마십시오. 또한 재시작을 부트스트랩 작업으로 간주하지 마십시오.

데이터베이스 멤버가 조인된 후, 각 멤버에 대해 다음 쿼리를 실행하십시오.

SHOW GLOBAL STATUS WHERE Variable_name IN
('wsrep_cluster_status','wsrep_cluster_size','wsrep_ready',
 'wsrep_connected','wsrep_local_state_comment');

각 노드가 연결되어 준비되었는지, 기본 구성 요소에 속하는지, 예상 클러스터 크기를 보고하는지, 동기화 상태에 도달했는지 확인하십시오. MariaDB는 Galera 모니터링 가이드 에서 이러한 지표에 대해 설명합니다 .

7. Nextcloud 전용 데이터베이스와 최소 권한 계정을 생성합니다.

현재 Nextcloud 설치 가이드에서 요구하는 문자 집합 및 정렬 방식을 사용하여 데이터베이스를 생성하십시오. 애플리케이션 네트워크에만 접근 가능한 전용 데이터베이스 사용자를 생성하고, Nextcloud 설정 및 정상 작동에 필요한 권한만 부여하십시오. 호스트 또는 신뢰할 수 없는 네트워크 세그먼트를 통과하는 연결에는 TLS를 사용하고, 배포 환경에서 지원하는 경우 인증서를 검증하십시오. 루트 자격 증명을 .에 저장하지 마십시오 config.php.

8. 동일한 Nextcloud 애플리케이션 노드를 배포합니다.

각 웹 노드에 동일한 Nextcloud 코드 릴리스, PHP 확장 프로그램, 활성화된 앱 및 서버 구성을 설치하십시오. 노드별 파일에 서로 다른 데이터베이스 호스트를 설정하는 대신, 하나의 공유 데이터베이스 엔드포인트를 구성하십시오. 모든 노드는 동일한 인스턴스 ID, 비밀 키, 솔트, 신뢰 도메인 정책 및 기타 인스턴스 전체 설정을 사용해야 합니다. 구성은 관리되는 공유 배포 프로세스에 저장하거나 안전하게 배포하여 업데이트 시 구성이 동일하게 유지되도록 하십시오.

사용자 파일 데이터 계층은 애플리케이션 노드 간에 공통으로 사용되어야 합니다. Nextcloud 버전 및 운영 요구 사항에 맞는 지원되는 공유 파일 시스템 또는 지원되는 기본 객체 스토리지 설계를 사용하십시오. 한 웹 호스트에 로컬 사용자 데이터만 저장하면 장애 조치가 불가능해집니다. 다른 호스트로 라우팅된 요청은 동일한 파일을 볼 수 없기 때문입니다. 애플리케이션 코드와 쓰기 가능한 데이터 경로를 분리하고, 프로덕션 환경 구축 전에 파일 잠금 및 스토리지 의미 체계를 검증하십시오.

Nextcloud는 일반적으로 설치 중에 데이터베이스 설정을 생성합니다. 데이터베이스 엔드포인트와 공유 스토리지가 준비되면 각 노드에서 동일한 값이 확인되는지 확인하십시오. 대표적인 구성 예시는 다음과 같습니다. 실제 자격 증명은 안전한 비밀 관리 워크플로에 보관하고, 이 예시를 기존 운영 환경 구성에 덮어쓰지 마십시오.

'dbtype' => 'mysql',
'dbname' => 'nextcloud',
'dbhost' => 'db-vip.internal:3306',
'dbuser' => 'nextcloud',
'dbpassword' => 'REPLACE_WITH_SECRET',
'datadirectory' => '/srv/nextcloud-data',
'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
  'host' => 'redis.internal',
  'port' => 6379,
  'password' => 'REPLACE_WITH_SECRET',
],

Nextcloud 릴리스에서 지원하는 옵션에 맞게 캐시 백엔드 및 데이터 디렉터리를 선택하십시오. 필요한 PHP 확장 프로그램을 설치하고 구성하십시오.

9. 분산 캐시 및 파일 잠금 서비스를 추가합니다.

적절한 경우 호스트별 로컬 캐싱에는 APCu를 사용하고, 분산 캐싱 및 트랜잭션 파일 잠금에는 Redis 또는 Valkey와 같은 Redis 호환 공유 서비스를 사용하십시오. 모든 웹 노드는 localhost가 아닌 동일한 캐시 서비스 또는 지원되는 캐시 클러스터를 참조해야 합니다. Nextcloud는 클러스터링 설정을 위한 Redis 클러스터 구성 문서를 제공하며, 트랜잭션 파일 잠금은 기본적으로 데이터베이스를 사용한다고 명시하고 있습니다. 네트워크 제한, 인증 및 TLS를 사용하여 캐시를 보호하십시오. 캐시 가용성 및 장애 조치 동작은 별도로 설계해야 합니다.

10. Galera 앞에 데이터베이스를 인식하는 엔드포인트를 배치합니다.

Nextcloud가 데이터베이스 프록시 또는 지원되는 다른 라우팅 계층에서 제공하는 안정적인 엔드포인트 하나를 가리키도록 설정하십시오. 프록시는 기본 구성 요소에 속하지 않거나, 동기화되지 않았거나, 준비되지 않은 노드로 새 연결을 전송하지 않도록 해야 합니다. 기본적인 TCP 포트 검사는 소켓이 연결을 수락하는지 여부만 확인할 뿐, Galera가 애플리케이션을 안전하게 제공할 수 있는지 여부는 보장하지 않습니다. 선택한 프록시의 상태 검사 동작 및 오류 모드를 검토하십시오. 간단한 TCP 로드 밸런서를 사용하는 경우, 신뢰할 수 있는 Galera 준비 상태 검사 및 보수적인 라우팅 규칙과 함께 사용하십시오.

읽기/쓰기 분할이나 라운드 로빈 라우팅을 함부로 추가하지 마십시오. Nextcloud 개발자 설명서에서는 기본/복제본 연결 지원에 대해 설명하면서, 데이터가 전파되지 않았거나 프록시가 트랜잭션 읽기를 올바른 노드에 유지할 수 없는 경우 클러스터 전체에 걸쳐 읽기를 라우팅하면 일관성 문제가 발생할 수 있다고 경고합니다. 안정적인 쓰기 가능 엔드포인트로 시작하여 성능을 측정하고, 일관성 및 지원에 미치는 영향을 충분히 이해한 후에만 특수 라우팅을 도입하십시오.

11. 웹 로드 밸런싱 및 신뢰할 수 있는 프록시 설정에 중복 기능을 추가합니다.

로드 밸런서 뒤에 최소 두 개의 웹 노드를 배치하고, 관리형 서비스, 이중화된 노드 쌍 또는 검증된 가상 IP 설계와 같은 로드 밸런서 자체에 대한 별도의 가용성 메커니즘을 사용하십시오. 배포 환경에 따라 TLS 종료, 요청 크기 및 시간 초과 동작, 스티키 세션 요구 사항을 구성하십시오. Nextcloud 역방향 프록시 문서를 참조하여 trusted_proxies실제 프록시 주소로 설정하십시오. 임의의 클라이언트 IP 범위에 대한 신뢰는 클라이언트 IP 처리 보안을 약화시킵니다.

12. 신중하게 배포한 후, 장애 발생 시 복구 과정을 테스트하십시오.

업그레이드 전에 동일한 토폴로지를 가진 스테이징 환경에서 먼저 테스트하십시오. 업그레이드 절차에 따라 Nextcloud를 유지 관리 모드로 전환하고, 모든 노드에 동일한 애플리케이션 릴리스를 적용한 후, 상태 점검이 통과된 후에만 노드를 다시 서비스 상태로 전환하십시오. 정기적인 호스트 유지 관리를 위해 웹 노드를 하나씩 드레인하고 남은 용량이 충분한지 확인하십시오. 데이터베이스 업그레이드는 해당 버전에 맞는 MariaDB/Galera 롤링 업그레이드 프로세스를 사용하여 적용하십시오. 일반적인 튜토리얼을 참고하여 순서를 임의로 정하지 마십시오.

문서화되고 애플리케이션 일관성을 유지하는 절차를 사용하여 데이터베이스와 사용자 파일 데이터 계층을 백업하십시오. 구성, 암호화 자료 및 비밀 정보는 권한이 있는 복구 담당자만 접근할 수 있도록 보관하십시오. Galera 복제본은 백업이 아닙니다. 실수로 삭제하거나 논리적 손상이 발생하면 모든 멤버에 복제될 수 있습니다. 백업은 클러스터의 장애 도메인 외부에 저장하고 정기적으로 복원 연습을 수행하십시오. Galera는 클러스터 백업 지침 에서 상태 전송 및 백업 고려 사항을 설명하고 있으므로 , 사용하는 MariaDB 릴리스를 지원하는 절차를 채택하십시오.

업무량과 팀 역량에 맞춰 설계를 선택하세요.

Galera는 데이터베이스 노드 이중화가 필요하고, 여러 장애 도메인을 운영하며, 쿼럼을 모니터링하고 제어된 복구를 수행할 수 있는 경우에 적합한 선택입니다. 하지만 운영의 ​​단순성이 주요 목표이거나, 데이터베이스 워크로드가 충돌하는 쓰기 작업에 의해 좌우되거나, 쿼럼 손실에 안전하게 대응할 수 없는 경우에는 적합하지 않을 수 있습니다. 이러한 경우에는 강력한 백업 기능을 갖춘 보다 단순한 지원 데이터베이스 배포 방식이나 관리형 데이터베이스 서비스가 운영 안정성 측면에서 더 나은 결과를 제공할 수 있습니다.

소규모 자체 호스팅 서비스의 경우, 먼저 애플리케이션 노드를 상호 교환 가능하게 만들고, 사용자 파일을 내구성이 뛰어난 공유 스토리지로 이동하고, 공유 Redis 잠금을 구성하고, 백업을 테스트하십시오. Galera는 데이터베이스의 단일 노드 장애 또는 유지 관리 시간 동안의 위험이 허용할 수 없을 정도로 심각하고 조직에서 추가 계층을 유지 관리할 수 있다는 것이 측정 결과로 확인된 후에만 추가하십시오. 의미 있는 성공 테스트는 "세 개의 데이터베이스 서버가 모두 실행 중"인 것이 아니라, 계획된 노드 장애 발생 시 Nextcloud URL을 계속 사용할 수 있고, 웹 노드 간 업로드 및 다운로드가 원활하게 작동하며, 데이터베이스의 쿼럼이 유지되고, 팀에서 백업을 통해 데이터베이스 및 파일 데이터를 모두 복원할 수 있는지 여부입니다.

빠른 검증 체크리스트

• Nextcloud, MariaDB, PHP 및 Galera 버전은 호환되며 지원됩니다.
• 모든 데이터베이스 노드는 기본 멤버십, 예상 클러스터 크기, 준비 상태 및 동기화된 로컬 상태를 보고합니다.
• 애플리케이션 서버는 동일한 데이터베이스 엔드포인트, 구성, 캐시 및 파일 데이터 시스템을 사용합니다.
• 데이터베이스, 복제, 캐시 및 스토리지 포트는 비공개이며 필요한 피어로 제한됩니다.
• 웹 및 데이터베이스 프록시는 실제로 비정상적인 백엔드를 서비스에서 제거합니다.
• 계획된 웹 노드 및 데이터베이스 노드 장애 상황을 통제된 환경에서 테스트했습니다.
• 예행연습에서 데이터베이스 및 파일 데이터 백업이 모두 성공적으로 복원되었습니다.

공식 참고 자료

• Nextcloud: 데이터베이스 구성
• Nextcloud: 메모리 캐싱
• Nextcloud: 트랜잭션 파일 잠금
• Nextcloud: 리버스 프록시 구성
• 넥스트클라우드: 성능 및 데이터베이스 클러스터 고려 사항
• MariaDB: 쿼럼, 모니터링 및 복구
• MariaDB: Galera 클러스터 모니터링