Linux 패키지를 사용한 Redis 복제 및 장애 조치

Tier: 프리미엄, 얼티메이트 Offering: Self-Managed

이 문서는 Linux 패키지용입니다. 자체 묶이지 않은 Redis를 사용하려면 자체 인스턴스 제공 시 Redis 복제 및 장애 조치를 참조하십시오.

Redis 용어에서 primary는 master로 불립니다. 이 문서에서는 master가 필요한 설정을 제외하고, primary를 사용합니다.

확장 가능한 환경에서 Redis를 사용하면 Redis Sentinel 서비스를 사용하여 Primary x Replica 토폴로지로 실패 조치 프로시저를 자동으로 감시합니다.

Sentinel을 사용하려면 Redis에서 인증이 필요합니다. 자세한 내용은 Redis 보안 문서를 참조하십시오. Redis 서비스를 보호하기 위해 Redis 암호와 엄격한 방화벽 규칙의 조합을 권장합니다. Redis를 GitLab과 구성하기 전에 Redis Sentinel 문서를 꼼꼼히 읽어 토폴로지와 아키텍처를 완전히 이해하는 것이 좋습니다.

복제된 토폴로지에 대해 Redis 및 Redis Sentinel을 설정하는 세부 정보에 들어가기 전에 구성 요소가 어떻게 서로 연결되는지 전체 문서를 한 번 읽어보는 것이 좋습니다.

최소 3대의 독립적인 머신이 필요합니다. 물리적인 머신이나 서로 다른 물리적인 머신에서 실행 중인 VM이어야 합니다. 모든 기본 및 복제 Redis 인스턴스가 서로 다른 머신에서 실행되어야 하는 것이 중요합니다. 그 특정 방식으로 기기를 할당하지 못할 경우, 공유 환경 문제로 인해 전체 설정이 중단될 수 있습니다.

기본 또는 복제 Redis 인스턴스와 함께 Sentinel을 실행하는 것은 괜찮습니다. 그러나 동일한 기계에는 하나 이상의 Sentinel이 있으면 안 됩니다.

Redis/Sentinel과 GitLab 인스턴스 사이에 백그라운드 네트워크 토폴로지를 고려해야 합니다. 그렇지 않으면 네트워크가 단일 장애 지점이 될 수 있기 때문입니다.

중복 연결성을 확보하기 위해 Redis/Sentinel과 GitLab 인스턴스 사이에 백그라운드 네트워크 토폴로지를 고려해야 합니다.

확장된 환경에서의 Redis 실행에는 몇 가지 필요합니다: - 여러 개의 Redis 인스턴스 - Primary x Replica 토폴로지에서 Redis 실행 - 여러 개의 Sentinel 인스턴스 - 모든 Sentinel과 Redis 인스턴스에 대한 애플리케이션 지원 및 가시성

Redis Sentinel은 고가용성 환경에서 가장 중요한 작업을 처리하고 서버를 최소한 또는 전혀 다운시키지 않고 온라인 상태를 유지하는 데에 도움을 줄 수 있습니다. Redis Sentinel은 다음을 수행합니다: - Primary 및 Replica 인스턴스의 가용성 모니터링 - Primary이 실패하면 Replica를 Primary로 승격 - 실패한 Primary가 다시 온라인 상태로 전환될 때 Primary를 Replica로 강등 (데이터 파티션 방지) - 애플리케이션이 항상 현재 Primary 서버에 연결하도록 쿼리하는 것

Primary가 응답하지 않을 때, 애플리케이션(GitLab의 경우)은 타임아웃 및 재연결을 처리하는 것이 필요합니다(새 Primary를 위해 Sentinel에 쿼리).

Sentinel을 올바르게 설정하는 방법을 더 잘 이해하려면 먼저 Redis Sentinel 문서를 읽어보세요. 설정을 올바르게 구성하지 않으면 데이터 손실이 발생하거나 전체 클러스터가 중단될 수 있기 때문입니다.

권장 설정

최소한으로 설정하려면 Linux 패키지를 3대의 독립적인 머신에 설치해야 합니다. 각각에는 Redis와 Sentinel이 있어야 합니다: - Redis Primary + Sentinel - Redis Replica + Sentinel - Redis Replica + Sentinel

노드 수의 이유가 무엇이며 왜 그런지 잘 모르거나 이해하지 못하는 경우, Redis 설정 개요 및 Sentinel 설정 개요를 읽어보세요.

더 많은 장애에도 불구하고 버틸 수 있는 추천 설정을 위해, Redis와 Sentinel이 모두 있는 독립적인 5 대의 머신에 Linux 패키지를 설치해야 합니다: - Redis Primary + Sentinel - Redis Replica + Sentinel - Redis Replica + Sentinel - Redis Replica + Sentinel - Redis Replica + Sentinel

Redis 설정 개요

적어도 3대의 Redis 서버가 있어야 하며, 1대의 primary, 2대의 Replicas여야 합니다. 각각은 독립적인 머신에 있어야 하며(위의 설명 참조).

추가적인 Redis 노드를 가질 수 있습니다. 이는 더 많은 노드가 다운되는 상황에 대처하는 데 도움이 됩니다. 온라인 상태인 노드가 2개만 있는 경우 장애 조치가 시작되지 않습니다.

예를 들어, 6개의 Redis 노드가 있는 경우, 최대 3개가 동시에 다운될 수 있습니다.

Sentinel 노드에는 다른 요구 사항이 있습니다. Redis 머신에 호스팅하는 경우, 고려해야 할 제한 사항이 있을 수 있으며, 이는 할당해야 하는 노드 수를 계산할 때 고려해야 합니다. 자세한 내용은 Sentinel 설정 개요 문서를 참조하십시오.

모든 Redis 노드는 동일한 방식으로 구성되어 있어야 하며 유사한 서버 사양으로 구성해야 합니다. 장애 조치 상황에서 Sentinels 서버가 새 Primary로 승격시키기 때문에, 복제에는 인증이 필요합니다. 따라서 Redis 노드와 Sentinel을 모두 보호하기 위해 암호를 정의해야 합니다. 모든 인스턴스가 네트워크를 통해 서로 통신할 수 있어야 합니다.

Sentinel 설정 개요

Sentinel은 다른 Sentinel 및 Redis 노드를 모니터링합니다. Sentinel이 Redis 노드의 응답이 없음을 감지하면 해당 노드의 상태를 다른 Sentinel에게 알립니다. 이들은 장애 조치를 시작할 수 있도록 최소한의 Sentinel이 동의하는 쿼럼 (노드 다운에 동의하는 최소한의 Sentinel 수)에 도달해야 합니다.

쿼럼이 충족되면 모든 알려진 Sentinel 노드 중 과반수가 사용 가능하고 접근 가능해야 하므로, 서비스 가용성을 복원하기 위한 모든 결정을 내리는 Sentinel 리더를 선출할 수 있습니다. 선출된 리더는 다음과 같은 작업을 수행합니다:

새로운 주 노드(Primary)로 승격
다른 복제본(Replica)을 다시 구성하여 새로운 주 노드(Primary)를 가리키도록 함
새로운 주 노드(Primary)를 각 다른 Sentinel 동료에게 알림
이전 주 노드(Primary)을 다시 구성하여 온라인 상태일 때 복제본(Replica)로 강등

적어도 3개의 Redis Sentinel 서버가 있어야 하며, 이들은 각각 독립된 기기에 설치되어야 하며(독립적으로 실패할 것으로 예상됨), 이상적으로 지리적으로 다른 지역에 있어야 합니다.

이들을 다른 Redis 서버를 구성한 기기에 같이 구성할 수 있지만, 전체 노드가 다운되는 경우 Sentinel과 Redis 인스턴스가 모두 손실될 수 있음을 이해해야 합니다.

일반적으로 Sentinel 수는 언제나 홀수여야 하며, 장애 발생 시 합의 알고리즘이 효과적일 수 있도록 합니다.

3개 노드의 토폴로지에서는 1개의 Sentinel 노드만 다운될 수 있습니다. 과반수의 Sentinel이 다운되면 네트워크 분할 보호로 인해 파괴적인 작업이 방지되고 장애 조치 를 시작하지 않습니다.

다음은 일부 예시입니다:

5 또는 6개의 Sentinel로, 최대 2개가 다운될 수 있습니다.
7개의 Sentinel로, 최대 3개의 노드가 다운될 수 있습니다.

리더 선출은 때때로 합의가 달성되지 않을 때 투표 라운드를 실패할 수 있습니다(위의 홀수 노드 요구사항 참조). 이 경우에는 sentinel['failover_timeout'] (밀리초 단위)에 정의된 시간이 지난 후에 재시도됩니다.

참고: sentinel['failover_timeout']이 어디에 정의되어 있는지는 나중에 확인할 수 있습니다.

failover_timeout 변수는 많은 다양한 사용 사례가 있습니다. 공식 문서에 따르면 다음과 같습니다:

이전에 특정 Sentinel에 의해 동일한 프라이머리에 대해 이미 시도된 다음 장애 조치를 재시작하는데 필요한 시간은 장애 조치 시간의 두 배입니다.
현재 Sentinel 구성에 따라 잘못된 프라이머리에 복제하는 레플리카가 올바른 프라이머리로 강제 복제되기 위해 필요한 시간은 정확히 장애 조치 시간입니다(특정 Sentinel이 잘못된 구성을 감지한 이후부터 계산됨).
이미 진행 중이지만 설정 변경이 없었던(아직 승격된 복제본으로부터 아직 승인되지 않은 REPLICAOF NO ONE) 장애 조치를 취소하는데 필요한 시간
진행 중인 장애 조치가 모든 레플리카가 새로운 프라이머리의 복제본으로 다시 구성되기 위한 최대 시간. 그러나 이 기간이 지난 후에도 레플리카는 결국 Sentinel에 의해 다시 구성되지만, 명시된 대로 정확한 병렬 동기화 진행은 보장되지 않음.

Redis 구성

이 부분은 새로운 Redis 인스턴스를 설치하고 설정하는 곳입니다.

GitLab 및 그 모든 구성 요소를 처음부터 설치했다고 가정합니다. 이미 Redis를 설치하고 실행 중이라면 기존 단일 머신 설치에서 전환하는 방법을 읽어보세요.

참고: Redis 노드(주 노드 및 복제본)는 redis['password']로 정의된 동일한 암호가 필요합니다. 언제든지 장애 조치 중에 Sentinel은 노드를 다시 구성하고 해당 노드의 상태를 주 노드 또는 복제본으로 변경할 수 있습니다.

요구 사항

Redis 설정에 대한 요구 사항은 다음과 같습니다:

권장된 설치 섹션에 명시된 것과 같은 최소 필수 인스턴스 수를 제공합니다.
GitLab 애플리케이션이 실행 중인 머신에는 Redis 또는 Redis Sentinel을 설치하는 것을 권장하지 않습니다. 그러나 Redis 및 Sentinel을 동일한 머신에 설치할 수 있습니다.
모든 Redis 노드는 서로 통신하고 Redis(6379) 및 Sentinel(26379) 포트로부터 들어오는 연결을 수락해야 합니다(기본값을 변경하지 않는 한).
GitLab 애플리케이션을 호스팅하는 서버는 Redis 노드에 액세스할 수 있어야 합니다.
외부 네트워크(인터넷)으로부터 노드를 보호하기 위해 방화벽을 사용합니다.

기존 단일 머신 설치에서 전환하기

이미 단일 머신에 GitLab 설치가 실행 중이라면 Redis 인스턴스를 비활성화하기 전에 먼저이 머신부터 복제해야 합니다.

귀하의 단일 머신 설치는 초기 주 노드(Primary)이며, 그 외의 3개는 방금 설정된 복제본(Replica)으로 구성되어야 합니다.

복제가 따라잡기 전에 서비스를 중지하여 새 노드 중 하나로 주 노드(Primary)를 전환해야 합니다.

구성 파일에서 필요한 변경 사항을 적용하고 새 노드를 다시 시작하세요.

단일 설치에서 Redis를 비활성화하려면 /etc/gitlab/gitlab.rb 파일을 편집하세요:

redis['enable'] = false

먼저 복제를하지 않은 경우 데이터(처리되지 않은 백그라운드 작업)를 잃을 수 있습니다.

단계 1. 기본 Redis 인스턴스 구성

주 Redis 서버로 SSH를 실행합니다.
GitLab 다운로드 페이지의 단계 1과 2를 사용하여 원하는 Linux 패키지를 다운로드하고 설치하세요.
- 현재 설치된 버전 및 유형(커뮤니티, 엔터프라이즈 버전)과 동일한 올바른 Linux 패키지를 선택해야 합니다.
- 다운로드 페이지에서 다른 단계를 완료하지 마십시오.

/etc/gitlab/gitlab.rb를 편집하고 다음 내용을 추가합니다.

# 서버 역할을 'redis_master_role'로 지정합니다.
roles ['redis_master_role']

# 다른 기기가 접근할 수 있는 로컬 IP를 가리키는 IP 주소입니다.
# 모든 인터페이스에서 수신 대기하는 '0.0.0.0'으로 바인딩할 수도 있습니다.
# 외부 접근 가능한 IP로 바인딩해야 하는 경우, 무단 액세스를 방지하기 위해
# 추가 방화벽 규칙을 추가해야 합니다.
redis['bind'] = '10.0.0.1'

# Redis가 TCP 요청을 수신할 수 있도록 포트를 정의합니다.
redis['port'] = 6379

# Redis의 암호 인증을 설정합니다 (모든 노드에서 동일한 암호를 사용합니다).
redis['password'] = '여기에_redis_암호_입력'

기본 GitLab 애플리케이션 서버만 마이그레이션을 처리해야 합니다. 업그레이드 시 데이터베이스 마이그레이션이 실행되지 않도록 하려면 /etc/gitlab/gitlab.rb 파일에 다음 구성을 추가하세요.
```
gitlab_rails['auto_migrate'] = false
```
변경 사항이 적용되려면 GitLab을 다시 구성하세요.

참고: roles ['redis_sentinel_role', 'redis_master_role']와 같이 Sentinel 및 Redis와 같은 여러 역할을 지정할 수 있습니다. roles에 대해 자세히 알아보기.

단계 2. 복제본 Redis 인스턴스 구성

복제본 Redis 서버로 SSH를 실행합니다.
GitLab 다운로드 페이지의 단계 1과 2를 사용하여 원하는 Linux 패키지를 다운로드하고 설치하세요.
- 현재 설치된 버전 및 유형(커뮤니티, 엔터프라이즈 버전)과 동일한 올바른 Linux 패키지를 선택해야 합니다.
- 다운로드 페이지에서 다른 단계를 완료하지 마십시오.

/etc/gitlab/gitlab.rb를 편집하고 다음 내용을 추가합니다.

# 서버 역할을 'redis_replica_role'로 지정합니다.
roles ['redis_replica_role']

# 다른 기기가 접근할 수 있는 로컬 IP를 가리키는 IP 주소입니다.
# 모든 인터페이스에서 수신 대기하는 '0.0.0.0'으로 바인딩할 수도 있습니다.
# 외부 접근 가능한 IP로 바인딩해야 하는 경우, 무단 액세스를 방지하기 위해
# 추가 방화벽 규칙을 추가해야 합니다.
redis['bind'] = '10.0.0.2'

# Redis가 TCP 요청을 수신할 수 있도록 포트를 정의합니다.
redis['port'] = 6379

# 기본 노드에 설정한 Redis 인증을 위한 동일한 비밀번호입니다.
redis['password'] = '여기에_redis_암호_입력'

# 주 Redis 노드의 IP입니다.
redis['master_ip'] = '10.0.0.1'

# 기본 Redis 서버의 포트입니다. 기본값이 아닌 다른 포트로 변경하려면 주석을 해제합니다.
#redis['master_port'] = 6379

업그레이드 시 자동으로 다시 구성되지 않도록 하려면 다음을 실행하세요.
```
sudo touch /etc/gitlab/skip-auto-reconfigure
```
기본 GitLab 애플리케이션 서버만 마이그레이션을 처리해야 합니다. 업그레이드 시 데이터베이스 마이그레이션이 실행되지 않도록 하려면 /etc/gitlab/gitlab.rb 파일에 다음 구성을 추가하세요.
```
gitlab_rails['auto_migrate'] = false
```
변경 사항이 적용되려면 GitLab을 다시 구성하세요.
다른 복제 노드의 경우 단계를 다시 실행하세요.

참고: roles ['redis_sentinel_role', 'redis_master_role']와 같이 Sentinel 및 Redis와 같은 여러 역할을 지정할 수 있습니다. roles에 대해 자세히 알아보기.

이러한 값들은 Sentinels에 의해 관리되기 때문에 장애 조치 후에도 /etc/gitlab/gitlab.rb에서 다시 변경할 필요가 없습니다. 심지어 gitlab-ctl reconfigure 명령을 실행해도 같은 Sentinels에 의해 구성이 복원됩니다.

단계 3. Redis Sentinel 인스턴스 구성

참고: Sentinel 패스워드 인증 지원은 GitLab 16.1에서 도입되었습니다.

이제 Redis 서버가 모두 설정되었으므로 Sentinel 서버를 구성해 봅시다.

Redis 서버가 올바르게 작동하고 복제되는지 확신이 들지 않는다면 복제 문제 해결를 읽고 계속하기 전에 문제를 해결하세요.

적어도 3개의 Redis Sentinel 서버가 있어야 하며, 각각이 독립적인 머신에 있어야 합니다. 다른 Redis 서버를 구성한 곳과 동일한 머신에 구성할 수 있습니다.

GitLab 엔터프라이즈 에디션을 사용하면 Linux 패키지를 사용하여 여러 대의 머신에 Sentinel 데몬을 설정할 수 있습니다.

Redis Sentinel을 호스팅하는 서버에 SSH로 로그인합니다.
다른 Redis 인스턴스와 같은 노드에 Sentinels이 호스팅되어 있으면 이 단계를 생략할 수 있습니다.
다운로드 및 설치를 통해 Linux 엔터프라이즈 에디션 패키지를 GitLab 다운로드 페이지의 단계 1 및 2를 사용합니다. - GitLab 애플리케이션이 실행 중인 버전과 동일한 Linux 패키지를 선택하는지 확인합니다. - 다운로드 페이지에서 다른 단계를 완료하지 않도록 합니다.

/etc/gitlab/gitlab.rb를 편집하고 다음 내용을 추가합니다 (다른 Redis 인스턴스와 같은 노드에 Sentinels을 설치하는 경우 아래의 일부 값이 중복될 수 있습니다):

roles ['redis_sentinel_role']

# 모든 Sentinel 노드에서 동일해야 합니다.
redis['master_name'] = 'gitlab-redis'

# 기본 노드에 설정한 Redis 인증용 동일한 패스워드입니다.
redis['master_password'] = '여기에_redis_패스워드_입력'

# 기본 Redis 노드의 IP 주소입니다.
redis['master_ip'] = '10.0.0.1'

# 다른 머신이 연결할 수 있도록 Redis가 TCP 요청을 수신할 수 있도록 포트를 정의합니다.
redis['port'] = 6379

# 기본 Redis 서버의 포트입니다. 기본값인 `6379`로 변경하려면 주석을 제거합니다.
#redis['master_port'] = 6379

## Sentinel 구성
sentinel['bind'] = '10.0.0.1'

## Sentinel 패스워드는 선택 사항입니다. 기본적으로 패스워드가 필요하지 않습니다.
# sentinel['password'] = '여기에_sentinel_패스워드_입력'

# Sentinel이 수신 대기하는 포트입니다. 기본값인 `26379`로 변경하려면 주석을 제거합니다.
# sentinel['port'] = 26379

## 페일오버를 시작하는 데 필요한 투표 센티넬의 양을 반영해야 합니다.
## 값은 센티넬의 양보다 커서는 안 됩니다.
##
## 퀄럼은 Sentinel을 두 가지 방식으로 조정할 수 있습니다:
## 1. 만약 퀄럼이 우리가 배포하는 Sentinels의 대부분보다 작은 값으로 설정되면,
##    우리는 사실상 Sentinel을 주 마스터가 더 이상 통신할 수 없을 때 도중에 페일오버를
##    트리거하는 주 실패에 민감한 Sentinel을 만들고 있습니다.
## 2. 퀄럼이 대부분의 Sentinels보다 큰 값으로 설정되면, 우리는
##    Sentinel이 주가 다운되었음에 동의하는 매우 많은 수 (다수보다 큰)의 좋은 연결된 Sentinels가
##    있을 때에만 페일오버할 수 있도록 만들고 있습니다.
sentinel['quorum'] = 2

## x ms 후 응답하지 않는 서버를 다운으로 간주합니다.
# sentinel['down_after_milliseconds'] = 10000

## 밀리초 단위의 페일오버 타임아웃을 지정합니다. 다음과 같이 여러 가지 방법으로 사용됩니다:
##
## - 동일한 주 마스터에 대해 이전 페일오버 이후에 페일오버를 다시 시작하는 데 필요한 시간은
##   페일오버 타임아웃의 두 배 입니다.
##
## - 현재 구성에 따라 잘못된 주에 복제하는 레플리카에 대해 올바른 주로 강제로 복제되어야 하는 레플리카에 대한 시간은
##   바로 페일오버 타임아웃입니다 (Sentinel이 구성 오류 감지 이후부터 카운트).
##
## - 이미 진행 중인 페일오버를 취소하기 위해 필요한 시간이지만 어떤 구성 변경도 생성하지 않은 경우
##   (아직 승격된 레플리카에 의해 아직 확인되지 않은 REPLICAOF NO ONE).
##
## - 진행 중인 페일오버가 모든 레플리카가 새로운 주의 레플리카로 재구성되기를 기다리는 최대 시간입니다.
##   그러나 이 시간 이후에도 Sentinels에 의해 레플리카가 재구성되지만
##   명시된 것과 정확한 병렬 동기화 진행은 아닙니다.
# sentinel['failover_timeout'] = 60000

업그레이드 시 데이터베이스 마이그레이션이 실행되지 않도록 하려면 다음을 실행합니다:
```
sudo touch /etc/gitlab/skip-auto-reconfigure
```
마이그레이션은 기본 GitLab 애플리케이션 서버에서만 처리해야 합니다.
변경 사항이 적용되려면 GitLab을 다시 구성합니다.
다른 Sentinel 노드에 대해 모든 단계를 다시 진행하세요.

단계 4. GitLab 어플리케이션 구성

마지막 단계는 메인 GitLab 어플리케이션 서버에게 Redis Sentinel 서버와 인증 자격 증명을 알리는 것입니다.

새로운 설치 또는 기존 설치에서 언제든지 Sentinel 지원을 활성화하거나 비활성화할 수 있습니다. GitLab 어플리케이션 관점에서는 모든 필요한 것은 Sentinel 노드의 올바른 자격 증명뿐입니다.

모든 Sentinel 노드의 목록이 필요하지는 않지만, 장애 발생 시에는 나열된 노드 중 하나에 접근해야 합니다.

참고: 다음 단계는 이상적으로 Redis나 Sentinel이 없어야 하는 HA(High Availability) 설정에서 GitLab 어플리케이션 서버에서 수행해야 합니다.

GitLab 어플리케이션이 설치된 서버에 SSH로 접속합니다.

/etc/gitlab/gitlab.rb 파일을 편집하고 다음 라인들을 추가/변경합니다:

## 모든 sentinel 노드에서 이 값은 같아야 합니다
redis['master_name'] = 'gitlab-redis'

## 기본 노드의 Redis 인증에 설정한 동일한 비밀번호입니다.
redis['master_password'] = '여기에 레디스 비밀번호를 입력합니다'

## `host`와 `port`를 포함한 Sentinel 목록
gitlab_rails['redis_sentinels'] = [
  {'host' => '10.0.0.1', 'port' => 26379},
  {'host' => '10.0.0.2', 'port' => 26379},
  {'host' => '10.0.0.3', 'port' => 26379}
]
# gitlab_rails['redis_sentinels_password'] = '여기에 센티넬 비밀번호를 입력합니다' # 주석을 해제하고 sentinel['password']와 동일한 값으로 설정합니다

변경 사항이 적용되도록 GitLab을 재구성합니다.

단계 5. 모니터링 활성화

GitLab 12.0에서 도입되었습니다.

모니터링을 활성화하면 모든 Redis 서버에서 활성화해야 합니다.

다음 단계를 위해 CONSUL_SERVER_NODES를 수집해야 합니다. 이는 다음 단계의 Consul 서버 노드의 IP 주소 또는 DNS 레코드로, Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z로 제공됩니다.

/etc/gitlab/gitlab.rb 파일을 생성/편집하고 다음 구성을 추가합니다:

# Prometheus를 위한 서비스 디스커버리 활성화
consul['enable'] = true
consul['monitoring_service_discovery'] =  true

# 플레이스홀더 교체
# Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z
# Consul 서버 노드의 주소로 대체합니다
consul['configuration'] = {
   retry_join: %w(Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z),
}

# 익스포터가 수신 대기하는 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'

설정을 컴파일하려면 sudo gitlab-ctl reconfigure를 실행합니다.

기본, 2 개의 레플리카, 3 개의 Sentinel이 있는 최소 구성 예시

이 예시에서는 모든 서버에 내부 네트워크 인터페이스가 있으며 10.0.0.x 범위의 IP를 가지며 이 IP를 사용하여 서로 연결할 수 있다고 가정합니다.

실제 사용시 외부 기계에서의 무단 접근을 방지하고 외부(인터넷)에서의 트래픽을 차단하기 위해 방화벽 규칙을 설정해야 합니다.

Redis 설정 개요 및 Sentinel 설정 개요에서 논의한 Redis + Sentinel 토폴로지에서 3 노드를 사용합니다.

다음은 각 서버 및 할당된 IP에 대한 목록과 설명입니다:

10.0.0.1: Redis Primary + Sentinel 1
10.0.0.2: Redis 레플리카 1 + Sentinel 2
10.0.0.3: Redis 레플리카 2 + Sentinel 3
10.0.0.4: GitLab 어플리케이션

초기 구성 이후, Sentinel 노드에 의해 장애 조치가 시작되면 Redis 노드가 재구성되고 Primary가 영구적으로 변경되며 (redis.conf에서도 변경됨) 새로운 장애 조치가 다시 시작될 때까지 다른 노드로 변경됩니다.

동일한 일이 sentinel.conf에서도 발생하여 초기 실행 후 새로운 센티넬 노드가 Primary를 감시하거나 장애 조치가 다른 Primary 노드를 프로모션하는 경우 재정의됩니다.

Redis 주 서버 및 Sentinel 1에 대한 구성 예

/etc/gitlab/gitlab.rb에서:

roles ['redis_sentinel_role', 'redis_master_role']
redis['bind'] = '10.0.0.1'
redis['port'] = 6379
redis['password'] = '여기에 레디스 암호 입력'
redis['master_name'] = 'gitlab-redis' # 각 sentinel 노드에서 동일해야 함
redis['master_password'] = '여기에 레디스 암호 입력' # 주 인스턴스의 redis['password']에서 정의한 값과 동일
redis['master_ip'] = '10.0.0.1' # 초기 주 레디스 인스턴스의 IP
#redis['master_port'] = 6379 # 기본값에서 변경하려면 주 레디스 인스턴스의 포트를 주석 처리 해제
sentinel['bind'] = '10.0.0.1'
# sentinel['password'] = '여기에 센티넬 암호 입력' # 각 센티넬 노드에서 동일해야 함, 비밀번호 설정하려면 주석 처리 해제
# sentinel['port'] = 26379 # 기본 포트를 변경하려면 주석 처리 해제
sentinel['quorum'] = 2
# sentinel['down_after_milliseconds'] = 10000
# sentinel['failover_timeout'] = 60000

변경 사항을 적용하려면 GitLab 재구성하세요.

Redis 복제본 1 및 Sentinel 2에 대한 구성 예

/etc/gitlab/gitlab.rb에서:

roles ['redis_sentinel_role', 'redis_replica_role']
redis['bind'] = '10.0.0.2'
redis['port'] = 6379
redis['password'] = '여기에 레디스 암호 입력'
redis['master_password'] = '여기에 레디스 암호 입력'
redis['master_ip'] = '10.0.0.1' # 주 레디스 서버의 IP
#redis['master_port'] = 6379 # 기본값에서 변경하려면 주석 처리 해제
redis['master_name'] = 'gitlab-redis' # 각 센티넬 노드에서 동일해야 함
sentinel['bind'] = '10.0.0.2'
# sentinel['password'] = '여기에 센티넬 암호 입력' # 각 센티넬 노드에서 동일해야 함, 비밀번호 설정하려면 주석 처리 해제
# sentinel['port'] = 26379 # 기본 포트를 변경하려면 주석 처리 해제
sentinel['quorum'] = 2
# sentinel['down_after_milliseconds'] = 10000
# sentinel['failover_timeout'] = 60000

변경 사항을 적용하려면 GitLab 재구성하세요.

Redis 복제본 2 및 Sentinel 3에 대한 구성 예

/etc/gitlab/gitlab.rb에서:

roles ['redis_sentinel_role', 'redis_replica_role']
redis['bind'] = '10.0.0.3'
redis['port'] = 6379
redis['password'] = '여기에 레디스 암호 입력'
redis['master_password'] = '여기에 레디스 암호 입력'
redis['master_ip'] = '10.0.0.1' # 주 레디스 서버의 IP
#redis['master_port'] = 6379 # 기본값에서 변경하려면 주석 처리 해제
redis['master_name'] = 'gitlab-redis' # 각 센티넬 노드에서 동일해야 함
sentinel['bind'] = '10.0.0.3'
# sentinel['password'] = '여기에 센티넬 암호 입력' # 각 센티넬 노드에서 동일해야 함, 비밀번호 설정하려면 주석 처리 해제
# sentinel['port'] = 26379 # 기본 포트를 변경하려면 주석 처리 해제
sentinel['quorum'] = 2
# sentinel['down_after_milliseconds'] = 10000
# sentinel['failover_timeout'] = 60000

변경 사항을 적용하려면 GitLab 재구성하세요.

GitLab 애플리케이션의 구성 예

/etc/gitlab/gitlab.rb에서:

redis['master_name'] = 'gitlab-redis'
redis['master_password'] = '여기에 레디스 암호 입력'
gitlab_rails['redis_sentinels'] = [
  {'host' => '10.0.0.1', 'port' => 26379},
  {'host' => '10.0.0.2', 'port' => 26379},
  {'host' => '10.0.0.3', 'port' => 26379}
]
# gitlab_rails['redis_sentinels_password'] = '여기에 센티넬 암호 입력' # 주석 처리 해제하고 sentinel['password']와 동일한 값으로 설정

변경 사항을 적용하려면 GitLab 재구성하세요.

고급 구성

이 섹션에서는 권장되는 최소 구성을 넘어선 구성 옵션을 다룹니다.

여러 개의 Redis 클러스터 실행

Linux 패키지는 서로 다른 지속성 클래스에 대한 별도의 Redis 및 Sentinel 인스턴스 실행을 지원합니다.

Class	Purpose
`cache`	캐시된 데이터 저장
`queues`	Sidekiq 백그라운드 작업 저장
`shared_state`	세션 관련 및 기타 지속성 데이터 저장
`actioncable`	ActionCable용 Pub/Sub 큐 백엔드
`trace_chunks`	CI 트레이스 청크 데이터 저장
`rate_limiting`	요율 제한 상태 저장
`sessions`	세션 저장
`repository_cache`	저장소에 특화된 캐시 데이터 저장

Sentinel과 함께 사용하려면:

필요에 따라 서로 다른 Redis/Sentinels를 구성합니다.

각 Rails 애플리케이션 인스턴스에 대해 /etc/gitlab/gitlab.rb 파일을 편집합니다:

gitlab_rails['redis_cache_instance'] = REDIS_CACHE_URL
gitlab_rails['redis_queues_instance'] = REDIS_QUEUES_URL
gitlab_rails['redis_shared_state_instance'] = REDIS_SHARED_STATE_URL
gitlab_rails['redis_actioncable_instance'] = REDIS_ACTIONCABLE_URL
gitlab_rails['redis_trace_chunks_instance'] = REDIS_TRACE_CHUNKS_URL
gitlab_rails['redis_rate_limiting_instance'] = REDIS_RATE_LIMITING_URL
gitlab_rails['redis_sessions_instance'] = REDIS_SESSIONS_URL
gitlab_rails['redis_repository_cache_instance'] = REDIS_REPOSITORY_CACHE_URL

# Sentinels 구성
gitlab_rails['redis_cache_sentinels'] = [
  { host: REDIS_CACHE_SENTINEL_HOST, port: 26379 },
  { host: REDIS_CACHE_SENTINEL_HOST2, port: 26379 }
]
gitlab_rails['redis_queues_sentinels'] = [
  { host: REDIS_QUEUES_SENTINEL_HOST, port: 26379 },
  { host: REDIS_QUEUES_SENTINEL_HOST2, port: 26379 }
]
gitlab_rails['redis_shared_state_sentinels'] = [
  { host: SHARED_STATE_SENTINEL_HOST, port: 26379 },
  { host: SHARED_STATE_SENTINEL_HOST2, port: 26379 }
]
gitlab_rails['redis_actioncable_sentinels'] = [
  { host: ACTIONCABLE_SENTINEL_HOST, port: 26379 },
  { host: ACTIONCABLE_SENTINEL_HOST2, port: 26379 }
]
gitlab_rails['redis_trace_chunks_sentinels'] = [
  { host: TRACE_CHUNKS_SENTINEL_HOST, port: 26379 },
  { host: TRACE_CHUNKS_SENTINEL_HOST2, port: 26379 }
]
gitlab_rails['redis_rate_limiting_sentinels'] = [
  { host: RATE_LIMITING_SENTINEL_HOST, port: 26379 },
  { host: RATE_LIMITING_SENTINEL_HOST2, port: 26379 }
]
gitlab_rails['redis_sessions_sentinels'] = [
  { host: SESSIONS_SENTINEL_HOST, port: 26379 },
  { host: SESSIONS_SENTINEL_HOST2, port: 26379 }
]
gitlab_rails['redis_repository_cache_sentinels'] = [
  { host: REPOSITORY_CACHE_SENTINEL_HOST, port: 26379 },
  { host: REPOSITORY_CACHE_SENTINEL_HOST2, port: 26379 }
]

# gitlab_rails['redis_cache_sentinels_password'] = '여기에 Sentinel 비밀번호 입력'
# gitlab_rails['redis_queues_sentinels_password'] = '여기에 Sentinel 비밀번호 입력'
# gitlab_rails['redis_shared_state_sentinels_password'] = '여기에 Sentinel 비밀번호 입력'
# gitlab_rails['redis_actioncable_sentinels_password'] = '여기에 Sentinel 비밀번호 입력'
# gitlab_rails['redis_trace_chunks_sentinels_password'] = '여기에 Sentinel 비밀번호 입력'
# gitlab_rails['redis_rate_limiting_sentinels_password'] = '여기에 Sentinel 비밀번호 입력'
# gitlab_rails['redis_sessions_sentinels_password'] = '여기에 Sentinel 비밀번호 입력'
# gitlab_rails['redis_repository_cache_sentinels_password'] = '여기에 Sentinel 비밀번호 입력'

Redis URL은 다음 형식이어야 합니다: redis://:PASSWORD@SENTINEL_PRIMARY_NAME, 여기서:
- PASSWORD는 Redis 인스턴스의 일반 텍스트 암호입니다.
- SENTINEL_PRIMARY_NAME은 redis['master_name']으로 설정된 Sentinel 기본 이름입니다. 예: gitlab-redis-cache.

파일을 저장하고 변경 사항이 적용되도록 GitLab을 다시 구성합니다:
```
sudo gitlab-ctl reconfigure
```

참고: 각 지속성 클래스에 대해 GitLab은 이전 설명된 설정에 의해 재정의되지 않는 한, gitlab_rails['redis_sentinels']에 지정된 구성을 기본값으로 사용합니다.

실행 중인 서비스 제어

이전 예에서는 redis_sentinel_role 및 redis_master_role을 사용하여 구성 변경량을 간소화했습니다.

더 많은 제어가 필요하면, 각각이 활성화될 때 자동으로 설정되는 항목입니다.

## Redis Sentinel Role
redis_sentinel_role['enable'] = true

# Sentinel Role이 활성화되면 다음 서비스도 활성화됩니다
sentinel['enable'] = true

# 다음 서비스는 비활성화됩니다
redis['enable'] = false
bootstrap['enable'] = false
nginx['enable'] = false
postgresql['enable'] = false
gitlab_rails['enable'] = false
mailroom['enable'] = false

-------

## Redis Primary/Replica Role
redis_master_role['enable'] = true # 둘 중 하나만 활성화
redis_replica_role['enable'] = true # 둘 중 하나만 활성화

# Redis Primary 또는 Replica Role이 활성화되면 다음 서비스가
# 활성화/비활성화됩니다. Redis 및 Sentinel Role이 결합된 경우,
# 두 서비스가 모두 활성화됩니다.

# 다음 서비스는 비활성화됩니다
sentinel['enable'] = false
bootstrap['enable'] = false
nginx['enable'] = false
postgresql['enable'] = false
gitlab_rails['enable'] = false
mailroom['enable'] = false

# Redis Replica Role의 경우, 이 설정도 기본값 'true'에서 'false'로 변경하세요:
redis['master'] = false

관련 속성은 gitlab_rails.rb에서 정의할 수 있습니다.

시작 동작 제어

소개 - GitLab 15.10에서 도입됨.

부팅 시 번들된 Redis 서비스의 시작을 방지하거나 구성을 변경한 후 다시 시작하는 것을 방지하려면:

/etc/gitlab/gitlab.rb 파일을 편집하세요:
```
redis['start_down'] = true
```
GitLab을 다시 구성하세요:
```
sudo gitlab-ctl reconfigure
```

새 복제 노드를 테스트해야 하는 경우, start_down을 true로 설정하고 노드를 수동으로 시작할 수 있습니다. 새 복제 노드가 Redis 클러스터에서 작동하는 것을 확인한 후, start_down을 false로 설정하고 GitLab을 다시 구성하여 노드가 작동 및 운영 중에 예상대로 시작 및 재시작되도록 합니다.

복제 구성 제어

소개 - GitLab 15.10에서 도입됨.

Redis 구성 파일에서 replicaof 라인을 렌더링하는 것을 방지하려면:

/etc/gitlab/gitlab.rb 파일을 편집하세요:
```
redis['set_replicaof'] = false
```
GitLab을 다시 구성하세요:
```
sudo gitlab-ctl reconfigure
```

이 설정은 Redis 설정과 관계없이 Redis 노드의 복제를 방지하는 데 사용할 수 있습니다.

문제 해결

Redis 문제 해결 가이드를 참조하십시오.

추가 읽어보기

더 많은 정보를 보려면:

Linux 패키지를 사용한 Redis 복제 및 장애 조치

권장 설정

Redis 설정 개요

Sentinel 설정 개요

Redis 구성

요구 사항

기존 단일 머신 설치에서 전환하기

단계 1. 기본 Redis 인스턴스 구성

단계 2. 복제본 Redis 인스턴스 구성

단계 3. Redis Sentinel 인스턴스 구성

단계 4. GitLab 어플리케이션 구성

단계 5. 모니터링 활성화

기본, 2 개의 레플리카, 3 개의 Sentinel이 있는 최소 구성 예시

Redis 주 서버 및 Sentinel 1에 대한 구성 예

Redis 복제본 1 및 Sentinel 2에 대한 구성 예

Redis 복제본 2 및 Sentinel 3에 대한 구성 예

GitLab 애플리케이션의 구성 예

고급 구성

여러 개의 Redis 클러스터 실행

실행 중인 서비스 제어

시작 동작 제어

복제 구성 제어

문제 해결

추가 읽어보기

도움말

기능 사용 가능성과 제품 평가판

도움받기