Redis 복제 및 Linux 패키지와 장애 조치

Tier: Premium, Ultimate Offering: Self-managed

이 문서는 Linux 패키지용입니다. 자체 제공되는 Redis를 사용하려면 자체 인스턴스를 제공하는 Redis 복제 및 장애 조치를 참조하세요.

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

확장 가능한 환경에서 Redis를 사용하려면 Primary x Replica 토폴로지를 사용하여 Redis Sentinel 서비스를 활용하여 장애 조치 절차를 자동으로 시작할 수 있습니다.

Sentinel을 사용하려면 Redis를 인증해야 합니다. 자세한 내용은 Redis 보안 문서를 참조하세요. Redis 서비스를 보호하기 위해 Redis 암호와 엄격한 방화벽 규칙의 조합 사용을 권장합니다. Redis를 GitLab과 구성하기 전에 Redis Sentinel](https://redis.io/docs/manual/sentinel/) 문서를 반드시 읽어 전체 토폴로지와 구조를 완전히 이해하는 것이 좋습니다.

복제된 토폴로지에 Redis 및 Redis Sentinel을 설정하려면 컴포넌트들이 어떻게 서로 연결되어 있는지 전반적으로 파악하기 위해 전체 문서를 한 번 읽는 것이 좋습니다.

독립적인 머신(물리적이거나 별도의 머신에서 실행되는 가상 머신)이 적어도 3대 필요합니다. 모든 primary 및 복제 Redis 인스턴스가 서로 다른 머신에서 실행되어야 합니다. 특정한 방식으로 머신을 프로비저닝하지 못하면 공유 환경의 문제로 전체 설정이 다운될 수 있습니다.

Primary 또는 복제 Redis 인스턴스와 함께 Sentinel을 실행해도 괜찮습니다. 그러나 동일한 머신에는 둘 이상의 Sentinel이 있어서는 안 됩니다. 또한 Redis / Sentinel 및 GitLab 인스턴스 간에 중복 연결이 있는지 확인하여 네트워크가 단일 장애 지점이 되지 않도록 해야 합니다.

확장 가능한 환경에서 Redis를 실행하려면 몇 가지 사항이 필요합니다:

여러 개의 Redis 인스턴스
Primary x Replica 토폴로지에서 Redis 실행
여러 Sentinel 인스턴스
모든 Sentinel 및 Redis 인스턴스에 대한 애플리케이션 지원 및 가시성

Redis Sentinel은 HA 환경에서 가장 중요한 작업을 처리할 수 있으며 서버를 중단하지 않고 온라인으로 유지하는 데 도움이 됩니다. Redis Sentinel은 다음과 같은 작업을 수행합니다:

Primary 및 Replicas 인스턴스를 모니터링하여 사용 가능한지 확인
Primary가 실패하면 Replica를 Primary로 승격
실패한 Primary이 온라인으로 돌아오면 Replica를 Primary로 승급시킨 후 데이터 파티셔닝을 방지
애플리케이션이 항상 현재 Primary 서버에 연결하도록 Sentinel에 쿼리할 수 있음

Primary가 응답하지 않을 때는 애플리케이션의 책임(우리의 경우 GitLab)으로 타임아웃 및 재연결을 관리하여 새로운 Sentinel을 쿼리합니다.

Sentinel을 올바르게 설정하는 방법을 정확히 이해하려면 장애 조치를 올바르게 구성하지 못하면 데이터 손실이 발생할 수 있거나 전체 클러스터가 다운될 수 있기 때문에 먼저 Redis Sentinel 문서를 읽는 것이 좋습니다.

권장 설정

최소 구성으로, Linux 패키지를 3 대의 독립적인 머신에 설치해야 합니다. 각 머신에는 Redis 및 Sentinel이 모두 있어야 합니다:

Redis Primary + Sentinel
Redis Replica + Sentinel
Redis Replica + Sentinel

양이 어디서 어떻게 나온 건지 확실하지 않거나 왜 필요한지 이해하지 못하는 경우 Redis 설치 개요 및 Sentinel 설치 개요를 읽어보세요.

더 많은 장애를 견딜 수 있는 권장 설정으로, Linux 패키지를 5 대의 독립적인 머신에 설치해야 합니다. 각 머신에는 Redis 및 Sentinel이 모두 있어야 합니다:

Redis Primary + Sentinel
Redis Replica + Sentinel
Redis Replica + Sentinel
Redis Replica + Sentinel
Redis Replica + Sentinel

Redis 설치 개요

적어도 3 개의 Redis 서버가 필요합니다: 1대의 primary, 2대의 복제, 모두 독립적인 머신에 있어야 합니다(위의 설명 참조).

추가적인 Redis 노드가 있는 경우, 더 많은 노드가 다운된 상황을 견딜 수 있습니다. 노드가 2개만 온라인인 경우 장애 조치가 시작되지 않습니다.

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

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

모든 Redis 노드는 동일한 방식으로 구성되어야 하며 유사한 서버 사양으로 설정해야 합니다. 장애 조치 상황에서 Sentinel 서버가 새로운 Primary로 승격시킬 Replica를 선택할 수 있기 때문입니다.

복제에는 인증이 필요하므로 모든 Redis 노드 및 Sentinel을 보호하기 위해 암호를 정의해야 합니다. 모두가 동일한 암호를 공유해야하며 모든 인스턴스가 네트워크상에서 서로 통신할 수 있어야 합니다.

Sentinel 설치 개요

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

쿼럼이 충족되면 모든 알려진 Sentinel 노드의 대다수가 사용 가능하고 접근 가능해야 하므로 서비스의 가용성을 복구하기 위한 모든 결정을 내릴 리더 Sentinel을 선출합니다:

새로운 Primary를 승격
다른 Replicas를 다시 구성하고 새로운 Primary를 가리키도록 함
새로운 Primary을 다른 Sentinel 피어에 알림
이전 Primary를 다시 구성하고 온라인 상태로 복귀시킬 때 Replicas로 강등함

적어도 3개의 Redis Sentinel 서버가 필요하며 각각 독립적인 머신(독립적으로 실패할 것으로 예상되는)에 있어야 합니다. 이상적으로 지리적으로 다른 지역에 위치해야 합니다.

다른 Redis 서버를 구성한 머신에 Sentinel을 구성할 수 있지만, 전체 노드가 다운된다면 Sentinel과 Redis 인스턴스를 모두 잃게 됨을 이해해야 합니다.

보통 실패가 발생한 경우 합의 알고리즘이 효과적일 수 있도록 실제로 항상 홀수의 수로 Sentinel을 구성해야 합니다.

3개 노드 토폴로지에서는 1개의 Sentinel 노드만 다운될 수 있습니다. 대다수의 Sentinel 노드가 다운되면 네트워크 파티션 보호가 파괴적인 작업을 방지하므로 장애 조치가 시작되지 않습니다.

다음은 몇 가지 예입니다:

5개 또는 6개의 Sentinel로 시작하면 2개까지 다운될 수 있습니다.
7개의 Sentinel로 시작하면 3개의 노드까지 다운될 수 있습니다.

리더 선출은 합의가 달성되지 않을 때 투표 과정이 실패할 수 있습니다(위에서 언급한 홀수의 노드 요구조건 참조). 이 경우 sentinel['failover_timeout'](밀리초 단위)에 정의된 시간이 경과한 후에 새로운 시도가 진행됩니다.

sentinel['failover_timeout']이 어디에 정의되어 있는지 나준은 나준 내에서 확인할 수 있습니다.

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

이전에 동일한 primary에 대해 같은 Sentinel이 이미 시도한 장애 조치를 다시 시작하는 데 필요한 시간은 장애 조치 시간의 두 배입니다.
현재 구성에 따라 잘못된 primary로 복제하는 REPLICA의 구성 변경을 강제하여 올바른 primary로 복제되도록 하는 시간은 정확히 장애 조치 시간입니다(특정 Sentinel이 구성 오류를 감지한 시점부터).
이미 진행 중인 장애 조치를 취소하는 데 필요한 시간은 정확히 장애 조치 시간입니다(REPLICAOF NO ONE은 하지만 승급된 REPLICA가 아직 인정되지 않은 경우).
현재 진행 중인 장애 조치가 모든 복제본이 새로운 primary의 복제본으로 다시 구성되기 위해 기다리는 최대 시간. 그러나 이 시간이 경과하면 Sentinels이 이미 모든 복제본을 다시 구성하지만 정확한 병렬 동기화 진행 상황은 지정된 대로 진행되지 않습니다.

Redis 구성

새로운 Redis 인스턴스를 설치하고 설정하는 섹션입니다.

GitLab 및 그 모든 컴포넌트를 처음부터 설치한 것으로 가정합니다. 이미 Redis를 설치하고 실행한 경우 기존 단일 기계 설치에서 전환하는 방법을 읽어보세요.

Redis 노드(기본 및 레플리카 모두)는 redis['password']에 정의된 동일한 암호가 필요합니다. 장애 조치(failover) 중에 언제든지 Sentinels가 노드를 다시 구성하고 상태를 기본에서 레플리카로 또는 그 반대로 변경할 수 있습니다.

요구 사항

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

권장 설정에 명시된대로 최소 필요한 인스턴스 수를 준비합니다.
GitLab 애플리케이션이 실행 중인 기계에 Redis 또는 Redis Sentinel을 설치하는 것은 권장하지 않습니다. 그렇게 하면 HA 구성이 약화됩니다. 그러나 Redis 및 Sentinel을 동일한 기계에 설치하도록 선택할 수 있습니다.
모든 Redis 노드는 서로 통신하고 Redis(6379) 및 Sentinel(26379) 포트를 통해 들어오는 연결을 허용해야 합니다(기본값을 변경하지 않는 한).
GitLab 애플리케이션을 호스팅하는 서버는 Redis 노드에 액세스할 수 있어야 합니다.
외부 네트워크(인터넷)에서 노드에 액세스하지 못하도록 방화벽을 사용하여 보호합니다.

기존 단일 기계 설치에서 전환하는 방법

이미 단일 기계 GitLab 설치가 실행 중인 경우, Redis 인스턴스를 비활성화하기 전에 먼저 이 기계에서 복제해야 합니다.

귀하의 단일 기계 설치가 초기 기본(Primary)이며, 3개의 다른 인스턴스는 레플리카(Replica)로 구성되어야 합니다. 이들은 새로운 노드 중 하나를 기본(Primary)으로 가리키도록 설정해야 합니다.

복제가 따라잡으면, 단일 기계 설치에서 서비스를 중지하고 기본(Primary)을 새 노드 중 하나로 변경해야 합니다.

필요한 변경 사항을 구성 파일에서 편집하고 새 노드를 다시 시작합니다.

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

redis['enable'] = false

복제를 먼저 하지 않으면 데이터(미처리된 백그라운드 작업)를 잃을 수 있습니다.

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

기본(Primary) Redis 서버에 SSH로 로그인합니다.
Linux 패키지 다운로드 및 설치 단계 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']과 같이 여러 역할을 지정할 수 있습니다. 역할에 대해 자세히 알아보세요.

단계 2. 레플리카 Redis 인스턴스 구성

레플리카(Replica) Redis 서버에 SSH로 로그인합니다.
Linux 패키지 다운로드 및 설치 단계 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'
# primary Redis 서버의 포트, 기본값을 변경하려면 주석 처리를 해제합니다. 기본값은 `6379`입니다.
#redis['master_port'] = 6379

업그레이드시 자동으로 다시 구성되는 것을 방지하려면 다음을 실행합니다:
```
sudo touch /etc/gitlab/skip-auto-reconfigure
```
변경 사항이 적용되려면 GitLab 다시 구성을 실행하세요.
모든 다른 레플리카 노드에 대해 단계를 다시 진행하세요.

roles ['redis_sentinel_role', 'redis_master_role']와 같이 여러 역할을 지정할 수 있습니다. 역할에 대해 자세히 알아보세요.

이러한 값들은 Sentinels에 의해 관리되므로 장애 조치 이후에도 /etc/gitlab/gitlab.rb에서 다시 변경할 필요가 없으며 gitlab-ctl reconfigure를 통해 동일한 Sentinels에 의해 구성이 복원됩니다.

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

Sentinel 암호 인증 지원이 GitLab 16.1에서 도입되었습니다.

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

Redis 서버가 올바르게 작동하고 복제되는지 확신하지 못하는 경우, 복제 문제 해결를 읽고 Sentinels 설정을 진행하기 전에 문제를 해결하세요.

적어도 3개의 Redis Sentinel 서버가 있어야하며, 각각 독립된 기계에 있어야 합니다. 다른 Redis 서버를 구성한 기계와 동일한 기계에 구성할 수 있습니다.

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

Redis Sentinel을 호스팅하는 서버에 SSH로 연결합니다.
다른 Redis 인스턴스와 동일한 노드에 Sentinels가 호스팅되는 경우 이 단계를 생략할 수 있습니다.
GitLab 다운로드 페이지의 단계 1과 2를 사용하여 Linux 엔터프라이즈 에디션 패키지를 다운로드하고 설치하세요. - 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이 수행해야 하는 투표를 나타내는 쿼럼입니다.
# ##
# ## 쿼럼은 Sentinel을 두 가지 방법으로 조정하는 데 사용할 수 있습니다.
# ## 1. 만약 우리가 배치하는 Sentinel의 과반수보다 더 작은 값을 쿼럼으로 설정하면,
# ##    우리는 사실상 Sentinel을 주요 장애에 보다 민감하게 만들고, 과반수의 Sentinel이
# ##    주요와 대화할 수 없어지면 즉시 장애 조치를 유발합니다.
# ## 1. 만약 쿼럼이 대다수의 Sentinel보다 큰 값으로 설정되면, Sentinel을 주요 장애가
# ##    발생했을 때 매우 많은 수(과반수 보다 더 큰 수)의 제대로 연결된 Sentinel로만
# ##    장애 조치가 가능하도록 만듭니다.
sentinel['quorum'] = 2
   
## 지정된 밀리초 후 응답하지 않는 서버를 다운으로 간주합니다.
# sentinel['down_after_milliseconds'] = 10000
   
## 밀리초 단위의 장애 조치 타임아웃을 지정합니다. 이 시간은 여러 가지 방법으로 사용됩니다:
##
## - 이전 장애 조치 후 동일한 주요에 대해 시도한 이전 장애 조치를 다시 시작하는 데 걸리는 시간은
##   장애 조치 시간의 두 배입니다.
##
## - 현재의 구성에 따라 잘못된 주요와 복제를 하는 레플리카가 올바른 주요와 동기화하도록
##   강제하는데 필요한 시간은 정확히 장애 조치 시간입니다(일관되지 않은 구성이 감지된 직후부터
##   메트릭).
##
## - 이미 진행 중인 장애 조치를 취소하는 데 필요한 시간(아직 프로모션된 레플리카에 의해
##   인정되지 않은 REPLICAOF NO ONE)은 장애 조치 시간입니다.
##
## - 현재 진행 중인 장애 조치가 모든 레플리카가 새로운 주요의 레플리카로 다시 구성되기를
##   기다리는 최대 시간. 그러나 심지어 이 시간이 지나도 Sentinel에서는 복제가 되지만
##   지정된 정확한 병렬 동기화 진행 상황과 일치하지 않습니다.
# sentinel['failover_timeout'] = 60000

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

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

마지막으로 주요 GitLab 애플리케이션 서버에게 Redis Sentinel 서버 및 인증 자격 증명에 대한 정보를 알려야 합니다.

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

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

다음 단계는 Redis나 Sentinels를 포함하지 않는 것이 이상적인 HA(High Availability) 설정을 위해 GitLab 애플리케이션 서버에서 수행해야 합니다.

GitLab 애플리케이션이 설치된 서버에 SSH로 연결합니다.

/etc/gitlab/gitlab.rb 파일을 편집하고 다음 내용을 추가 또는 변경합니다:

## 모든 Sentinel 노드에서 동일해야 합니다.
redis['master_name'] = 'gitlab-redis'
   
## 주요 노드에 설정한 Redis 인증용 동일한 암호입니다.
redis['master_password'] = '여기에 redis 암호를 입력합니다.'
   
## `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 암호를 입력하고 주석을 해제합니다.' # 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 파일을 생성/편집하고 다음 구성을 추가하세요:

# 프로메테우스를 위한 서비스 디스커버리 활성화
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를 실행하세요.

주요 구성의 예: 주 서버 1대, 복제본 2대 및 Sentinel 3대가 있는 구성

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

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

우리는 Redis 설정 개요와 Sentinel 설정 개요 문서에서 설명한 것과 같이 Redis + Sentinel 토폴로지를 가진 3개의 노드를 사용합니다.

다음은 각 머신과 할당된 IP의 디렉터리과 설명입니다:

10.0.0.1: Redis 주 서버 + 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에서도 일어납니다. 이는 초기 실행 후에 오버라이드되고, 새로운 sentinel 노드가 주 서버(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 노드에서 동일해야 함
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 노드에서 동일해야 함
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'] = 'redis-password-goes-here'
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-goes-here' # 주석 처리하고 sentinel['password'] 값과 동일하게 설정합니다.

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

고급 구성

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

여러 개의 Redis 클러스터 실행

Linux 패키지는 다른 지속성 클래스를 위해 별도의 Redis 및 Sentinel 인스턴스를 실행하는 것을 지원합니다.

클래스	목적
`cache`	캐시된 데이터 저장
`queues`	Sidekiq 백그라운드 작업 저장
`shared_state`	세션 관련 및 기타 지속적 데이터 저장
`actioncable`	ActionCable용 Pub/Sub 큐 백엔드
`trace_chunks`	CI trace chunks 데이터 저장
`rate_limiting`	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-password-goes-here'
# gitlab_rails['redis_queues_sentinels_password'] = 'sentinel-password-goes-here'
# gitlab_rails['redis_shared_state_sentinels_password'] = 'sentinel-password-goes-here'
# gitlab_rails['redis_actioncable_sentinels_password'] = 'sentinel-password-goes-here'
# gitlab_rails['redis_trace_chunks_sentinels_password'] = 'sentinel-password-goes-here'
# gitlab_rails['redis_rate_limiting_sentinels_password'] = 'sentinel-password-goes-here'
# gitlab_rails['redis_sessions_sentinels_password'] = 'sentinel-password-goes-here'
# gitlab_rails['redis_repository_cache_sentinels_password'] = 'sentinel-password-goes-here'

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 역할이 활성화되면, 다음 서비스가
# 활성화/비활성화됩니다. Redis 및 Sentinel 역할이 결합된 경우,
# 두 서비스가 모두 활성화됩니다.

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

# Redis Replica 역할의 경우, 다음 설정도 기본 'true'에서 'false'로 변경하십시오:
redis['master'] = false

관련 속성은 gitlab_rails.rb에서 정의된 내용을 찾을 수 있습니다.

시작 동작 제어하기

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

구성을 변경한 후에 부팅시 또는 다시 시작시 GitLab 번들된 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 문제 해결 가이드를 참조하세요.

더 많은 자료

추가 읽기:

Redis 복제 및 Linux 패키지와 장애 조치

권장 설정

Redis 설치 개요

Sentinel 설치 개요

Redis 구성

요구 사항

기존 단일 기계 설치에서 전환하는 방법

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

단계 2. 레플리카 Redis 인스턴스 구성

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

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

단계 5. 모니터링 활성화

주요 구성의 예: 주 서버 1대, 복제본 2대 및 Sentinel 3대가 있는 구성

Redis 주 서버 및 Sentinel 1의 구성 예

Redis 복제본 1 및 Sentinel 2의 구성 예

Redis 복제본 2 및 Sentinel 3의 구성 예

GitLab 애플리케이션의 구성 예시

고급 구성

여러 개의 Redis 클러스터 실행

실행 중인 서비스 제어하기

시작 동작 제어하기

복제 구성 제어하기

문제 해결

더 많은 자료

도움말

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

도움받기