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

Tier: 프리미엄, 얼티밋 Offering: Self-managed

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

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

확장 가능한 환경에서 Redis를 사용하면 Redis Sentinel 서비스를 사용하여 Primary x Replica 위상과 failover 절차를 자동으로 실행할 수 있습니다.

Redis는 Sentinel과 함께 사용될 때 인증이 필요합니다. 자세한 정보는 Redis 보안 문서를 참조하십시오. Redis 서비스를 안전하게 보호하기 위해 Redis 암호와 엄격한 방화벽 규칙을 결합하여 사용하는 것을 권장합니다. Redis를 GitLab과 함께 구성하기 전에 Redis Sentinel 문서를 반드시 읽고 전체적으로 이해할 것을 권장합니다.

복제된 위상에 대한 Redis 및 Redis Sentinel 설정의 자세한 내용에 대해 들어가기 전에 모든 구성 요소가 함께 어떻게 연결되어 있는지 전체 문서를 한 번 읽어보는 것이 좋습니다.

적어도 3대의 독립적인 머신이 필요합니다. 물리적인 머신이나 서로 다른 물리적 머신에 있는 VM을 실행해야 합니다. 모든 Primary 및 Replica Redis 인스턴스가 서로 다른 머신에서 실행되어야 합니다. 특정한 방식으로 머신을 구축하지 않으면 공유 환경에서 발생하는 모든 문제가 전체 설정을 멈출 수 있습니다.

Primary 또는 Replica Redis 인스턴스와 함께 Sentinel을 실행하는 것은 괜찮습니다. 그러나 동일한 머신에는 하나의 Sentinel만 있어야 합니다.

Redis 및 Sentinel과 GitLab 인스턴스 사이의 기본 네트워크 위상도 고려해야 합니다. 그렇지 않으면 네트워크가 단일 장애 지점이 될 수 있습니다.

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

여러 개의 Redis 인스턴스
Redis를 Primary x Replica 위상으로 실행
여러 Sentinel 인스턴스
어플리케이션에 모든 Sentinel 및 Redis 인스턴스가 지원되고 보이도록 하기

Redis Sentinel은 HA 환경에서 가장 중요한 작업을 수행할 수 있으며 서버를 최소한 또는 없는 다운타임으로 유지하는 데 도움이 됩니다. Redis Sentinel:

Primary 및 Replica 인스턴스를 모니터하여 사용 가능한지 확인
Primary이 실패하면 Replica를 Primary로 승격
실패한 Primary가 다시 온라인 상태로 변환되면 Primary를 Replica로 내려듭니다(데이터 파티션을 방지하기 위함)
응용 프로그램이 항상 현재 Primary 서버에 연결하도록 Sentinel에 쿼리 가능

Primary의 응답이 없을 때 응용 프로그램(GitLab의 경우)은 타임아웃 및 다시 연결을 처리해야 합니다(새 Primary에 대해 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개의 Replica가 각각 독립적인 머신에 있어야 합니다(위에서 설명한 대로).

추가적인 Redis 노드를 사용하면 다운되는 노드가 더 많은 상황을 견딜 수 있습니다. 온라인인 노드가 2개만 있는 경우에는 failover가 시작되지 않습니다.

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

Sentinel 노드에는 다른 요구 사항이 있습니다. 만약 Redis 머신에 호스트하는 경우 노드를 구성할 때 해당 제약 사항을 고려해야 합니다. 더 많은 정보는 Sentinel 설치 개요 문서를 참조하십시오.

모든 Redis 노드는 동일한 방식으로 구성되어 있어야 하며 유사한 서버 사양으로 설정되어야 합니다. failover 상황에서 임의의 Replica가 Sentinel 서버에 의해 새로운 Primary로 승격될 수 있습니다.

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

Sentinel 설치 개요

Sentinel은 다른 Sentinel 및 Redis 노드를 모니터링합니다. Sentinel이 Redis 노드가 응답하지 않는 것을 감지하면 해당 노드 상태를 다른 Sentinel에 알립니다. Sentinel은 quorum(노드다운인을 동의하는 최소한의 Sentinel 수)에 도달해야 하고

majority 모든 알려진 Sentinel 노드의 majority가 가능하고 연결 가능해야 합니다. 그래야 leader 센티넬이 새 Primary를 승격하여 서비스를 복구하도록 결정할 수 있습니다.

새 Primary를 승격
다른 Replica를 다시 구성하고 새 Primary를 가리키도록 함
새 Primary를 모든 다른 Sentinel 피어에 알림
온라인으로 돌아온 이전 Primary를 구성 및 Replica로 변경

적어도 3개의 Redis Sentinel 서버가 있어야 하며 독립적인 머신에 있어야 합니다(독립적으로 실패할 것으로 예상).

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

또한 sentinels의 수는 이상수가 될 수 있도록 항상 홀수여야 합니다.

3개 노드의 위상에서 각각 1개의 Sentinel 노드의 중단을 감당할 수 있습니다. majority Sentinels가 다운되면 네트워크 분리 보호로 인해 파괴적인 작업을 방지하며 failover가 시작되지 않습니다.

다음은 몇 가지 예시입니다:

5 또는 6 개의 Sentinel에서 2개까지 다운될 수 있음
7 개의 Sentinel에서 3개까지 다운될 수 있음

Leader 선거가 때로는 투표 라운드에서 실패할 수 있으며 이 경우 합의가 이루어지지 않았을 때 설정된 sentinel['failover_timeout']에서 시간이 지난 후에 새 시도가 이루어집니다.

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

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

이미 같은 Primary에 대한 이전 failover 후에 또 다른 failover를 다시 시작하기 위해서 필요한 시간은 failover 시간의 2배입니다.
현재 구성에 따라 잘못된 Primary에 복제 중인 REPLICAOF NO ONE을 승강복제하도록 하기까지의 시간은 정확히 failover timeout입니다(센티넬이 구성 오류를 감지한 순간부터 계산)
이미 진행 중인 failover를 취소하는 데 필요한 시간(아직 승격된 REPLICAOF NO ONE이 새로운 구성으로 인정되지 않은 상황)
모든 레플리카가 새 Primary의 레플리카로 다시 구성되는 최대 시간. 그러나 이 시간이 지난 후도 센티넬은 레플리카를 다시 구성하지만 정확한 parallel-syncs 진행은 지정된 것과 다를 수 있다.

Redis 구성

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

GitLab 및 모든 구성 요소를 처음부터 설치했다고 가정합니다. 이미 Redis가 설치되어 실행 중인 경우 기존 단일 머신 설치에서 전환하는 방법을 읽으십시오.

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

요구 사항

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

권장 설정 섹션에 명시된 대로 최소 필요한 인스턴스 수를 준비합니다.
GitLab 애플리케이션이 실행 중인 동일한 머신에 Redis 또는 Redis Sentinel을 설치하는 것을 권장하지 않습니다. 그러면 HA 구성이 약화됩니다. 그러나 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 인스턴스 구성

주(Primary) Redis 서버에 SSH로 연결합니다.
리눅스 단계 1 및 단계 2에서 GitLab 다운로드 페이지의 Linux 패키지를 선택하고 설치합니다.
- 현재 설치된 버전 및 유형(Community, Enterprise Editions)과 동일한 올바른 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 재구성을 수행하십시오.

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

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

복제본(replica) Redis 서버에 SSH로 연결합니다.
리눅스 단계 1 및 단계 2에서 GitLab 다운로드 페이지의 Linux 패키지를 선택하고 설치합니다.
- 현재 설치된 버전 및 유형(Community, Enterprise Editions)과 동일한 올바른 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 서버의 포트입니다. 기본값에서 변경하려면 주석 처리을 해제하세요. 기본값은 `6379`입니다.
#redis['master_port'] = 6379

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

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

이러한 값은 Sentinels에 의해 관리되기 때문에(안정 떨어지기) 장애 조치 후에도 /etc/gitlab/gitlab.rb에서 다시 변경할 필요가 없습니다. 같은 Sentinels에 의해 변경된 구성으로 gitlab-ctl reconfigure 를 실행하면 되기 때문입니다.

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

참고: Sentinel 암호 인증 지원은 GitLab 16.1에서 소개되었습니다.

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

Redis 서버가 제대로 작동하고 복제되는지 확실하지 않다면 복제 문제 해결를 읽고 Sentinels 설정을 진행하기 전에 문제를 해결하십시오.

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

GitLab Enterprise Edition을 사용하면 Linux 패키지를 사용하여 Sentinel 데몬이 구성된 여러 기계를 설정할 수 있습니다.

Redis Sentinel을 호스팅하는 서버에 SSH로 접속합니다.
다른 Redis 인스턴스가 있는 노드와 동일한 노드에 Sentinels이 호스팅되어 있는 경우 이 단계를 생략할 수 있습니다.
Linux Enterprise Edition 패키지를 다운로드하고 설치합니다. 단계 1 및 2에서 GitLab 다운로드 페이지의 지침을 따릅니다. - 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 수를 반영하여야 합니다.
## 값은 반드시 Sentinel 수보다 크지 않아야 합니다.
##
## 과반수는 Sentinel을 두 가지 방식으로 조정할 수 있습니다:
## 1. 설정한 과반수가 배치한 Sentinel보다 낮은 경우, 사실상 우리가 배치한 Sentinel의 과반수 이하로 주요 장애에 대응하여,
##    다수의 Sentinel이 주요 노드와 대화할 수 없어도 즉시 장애 조치를 유발합니다.
## 1. 설정한 과반수가 배치한 Sentinel의 과반수보다 큰 경우, Sentinel은 주요 장애에 대해 매우 많은 (대다수 이상) 잘 연결된
##    Sentinel에 의해 동의를 얻었을 때에만 장애 조치가 수행됩니다.
sentinel['quorum'] = 2

## x 밀리초 후에 응답하지 않는 서버를 고려합니다.
# sentinel['down_after_milliseconds'] = 10000

## 밀리초 단위의 장애 조치 시간을 지정합니다. 다음과 같이 여러 가지 방법으로 사용됩니다:
##
## - 이전 장애 조치에 대한 장애 조치 후 재시작에 필요한 시간은 2배의 장애 조치 시간입니다.
##
## - 잘못된 주요 노드로 복제되는 복제본이 Sentinel의 현재 구성에 따라 올바른 주요 노드와 복제하도록 강제하는 데 필요한 시간은
##   정확히 장애 조치 시간입니다 (Sentinel이 구성 오류를 감지한 시점부터 계산).
##
## - 이미 진행 중인 장애 조치를 취소하는 데 필요한 시간입니다.
##
## - 모든 복제본이 새로운 주요 노드의 복제본으로 재구성될 때까지 장애 조치 중인 최대 시간입니다. 그러나 실제로는 이 시간 이후에도
##   복제본은 어차피 Sentinels에 의해 재구성되지만 정확한 parallel-syncs 진행은 지정된 것과 다를 수 있습니다.
# 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 설치에 대한 GitLab 애플리케이션 서버에서 수행해야 합니다.

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

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

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

## 기본 노드에 설정한 Redis 인증 암호와 동일해야 함.
redis['master_password'] = '여기에_redis_암호_입력'

## `호스트` 및 `포트`를 사용하여 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. 모니터링 활성화

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

다음 단계를 위해, CONSUL_SERVER_NODES를 수집해야 합니다. 이는 Consul 서버 노드의 IP 주소 또는 DNS 레코드로, Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z와 같이 표시됩니다. replication_and_failover.md#consul-information을 확인하세요.

/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을 실행하세요.

1 primary, 2 레플리카 및 3 Sentinel의 최소 구성 예시

이 예시에서는 모든 서버가 10.0.0.x 범위의 내부 네트워크 인터페이스를 갖고 있으며 이 IP로 서로 통신할 수 있다고 가정합니다.
실제 환경에서는 다른 기계로부터의 비인가된 액세스를 방지하고 외부(인터넷)의 트래픽을 차단하기 위해 방화벽 규칙을 설정해야 할 것입니다.

Redis 설정 개요와 Sentinel 설정 개요 문서에서 논의된 Redis + Sentinel topology와 동일한 3 노드를 사용합니다.

다음은 각 머신 및 할당된 IP의 목록과 설명입니다:

10.0.0.1: Redis Primary + Sentinel 1
10.0.0.2: Redis Replica 1 + Sentinel 2
10.0.0.3: Redis Replica 2 + Sentinel 3
10.0.0.4: GitLab application

초기 구성 이후, Sentinel 노드에 의해 장애 조치가 시작되면 Redis 노드가 다시 구성되고 Primary가 영구적으로 변경되며(redis.conf에도 포함) 다른 노드로 이동합니다. 새로운 장애 조치가 다시 시작될 때까지 이러한 과정이 반복됩니다.

동일한 일이 sentinel.conf에서도 발생하며, 처음 실행 후에, 새로운 sentinel 노드가 Primary를 감시하기 시작하거나 장애 조치가 다른 Primary 노드로 홍보되면 재정의됩니다.

Redis Primary 및 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-password-goes-here'
redis['master_name'] = 'gitlab-redis' # 모든 sentinel 노드에서 동일해야 함
redis['master_password'] = 'redis-password-goes-here' # 주요 인스턴스의 redis['password']에서 정의된 값과 동일
redis['master_ip'] = '10.0.0.1' # 초기 주요 redis 인스턴스의 IP
#redis['master_port'] = 6379 # 기본값 변경하려면 주석 해제
sentinel['bind'] = '10.0.0.1'
# sentinel['password'] = 'sentinel-password-goes-here' # 모든 sentinel 노드에서 동일해야 함, 비밀번호 설정하려면 주석 해제
# 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-password-goes-here'
redis['master_password'] = 'redis-password-goes-here'
redis['master_ip'] = '10.0.0.1' # 주요 Redis 서버의 IP
#redis['master_port'] = 6379 # 기본값 변경하려면 주석 해제
redis['master_name'] = 'gitlab-redis' # 모든 sentinel 노드에서 동일해야 함
sentinel['bind'] = '10.0.0.2'
# sentinel['password'] = 'sentinel-password-goes-here' # 모든 sentinel 노드에서 동일해야 함, 비밀번호 설정하려면 주석 해제
# 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-password-goes-here'
redis['master_password'] = 'redis-password-goes-here'
redis['master_ip'] = '10.0.0.1' # 주요 Redis 서버의 IP
#redis['master_port'] = 6379 # 기본값 변경하려면 주석 해제
redis['master_name'] = 'gitlab-redis' # 모든 sentinel 노드에서 동일해야 함
sentinel['bind'] = '10.0.0.3'
# sentinel['password'] = 'sentinel-password-goes-here' # 모든 sentinel 노드에서 동일해야 함, 비밀번호 설정하려면 주석 해제
# 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 암호 입력'
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 재구성을 수행하세요.

고급 구성

이 섹션에서는 추천 및 최소 구성을 넘어선 구성 옵션을 다룹니다.

여러 개의 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 }
]
# 나머지 클래스의 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 역할
redis_sentinel_role['enable'] = true

# Sentinel 역할을 활성화하면 다음 서비스도 활성화됩니다
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 역할
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에서 도입되었습니다.

구성을 변경한 후에 부팅 시 또는 다시 시작하지 않도록 번들된 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 primary, 2 레플리카 및 3 Sentinel의 최소 구성 예시

Redis Primary 및 Sentinel 1의 구성 예시

Redis 레플리카 1과 Sentinel 2의 구성 예시

Redis 레플리카 2와 Sentinel 3의 구성 예시

GitLab 애플리케이션을 위한 구성 예시

고급 구성

여러 개의 Redis 클러스터 실행

실행 중인 서비스 제어

시작 동작 제어

복제본 구성 제어

문제 해결

추가 읽기

도움말

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

도움받기