• 권장 설정
  • Redis 설정 개요
  • Sentinel 설정 개요
• Redis 구성
  • 요구 사항
  • 기존 단일 머신 설치에서 전환하기
  • 1단계. 주 Redis 인스턴스 구성
  • 2단계. Replica Redis 인스턴스 구성하기
  • 3단계. Redis Sentinel 인스턴스 구성하기
  • 4단계. GitLab 애플리케이션 구성
  • 5단계. 모니터링 활성화
• 1개의 기본 서버, 2개의 복제본 및 3개의 Sentinel로 구성된 최소 구성 예
  • Redis 주 서버 및 Sentinel 1에 대한 예제 구성
  • Redis 복제본 1 및 Sentinel 2에 대한 예제 구성
  • Redis 복제본 2 및 Sentinel 3에 대한 예제 구성
  • GitLab 애플리케이션에 대한 예제 구성
• 고급 구성
  • 여러 Redis 클러스터 실행
  • 실행 중인 서비스 제어
  • 시작 동작 제어
  • 복제 구성 제어
• 문제 해결
• 추가 자료

Redis 복제 및 장애 조치 설정하기: 리눅스 패키지

이 문서는 리눅스 패키지를 위한 것입니다. 자체 비포장 Redis를 사용하려면 자체 인스턴스를 사용하는 Redis 복제 및 장애 조치를 참조하세요.

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

Redis를 확장 가능한 환경에서 사용하는 것은 Redis Sentinel 서비스를 사용하여 Primary x Replica 토폴로지를 통해 가능하며, 이 서비스는 자동으로 장애 조치 절차를 시작합니다.

Redis는 Sentinel과 함께 사용할 경우 인증이 필요합니다. 추가 정보는 Redis 보안 문서를 참조하세요. Redis 서비스를 보호하기 위해 Redis 비밀번호와 엄격한 방화벽 규칙의 조합을 사용하는 것을 권장합니다.

GitLab과 함께 Redis를 구성하기 전에 Redis Sentinel 문서를 읽어 보시고 토폴로지와 아키텍처를 완전히 이해하시기 바랍니다.

Redis와 Redis Sentinel을 복제된 토폴로지로 설정하는 세부 사항에 들어가기 전에 이 문서를 전체적으로 한 번 읽어보시면 구성 요소가 어떻게 연결되어 있는지 더 잘 이해할 수 있습니다.

최소한 3개의 독립적인 머신이 필요합니다: 물리적 머신이든 다른 물리적 머신에서 실행되는 VM이든 상관없습니다. 모든 primary 및 replica Redis 인스턴스는 서로 다른 머신에서 실행되는 것이 필수적입니다. 특정 방식으로 머신을 프로비전하지 못할 경우 공유 환경의 모든 문제로 인해 전체 설정이 중단될 수 있습니다.

Sentinel을 primary 또는 replica Redis 인스턴스와 함께 실행하는 것은 괜찮습니다. 그러나 동일한 머신에서 하나 이상의 Sentinel이 있으면 안 됩니다.

또한 Redis / Sentinel과 GitLab 인스턴스 간의 이중 연결을 확보하는 등 기본 네트워크 토폴로드도 고려해야 합니다. 그렇지 않으면 네트워크가 단일 실패 지점이 됩니다.

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

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

Redis Sentinel은 HA 환경에서 가장 중요한 작업을 처리할 수 있습니다. 즉, 서버를 최소한의 다운타임으로 온라인 상태로 유지하는 데 도움을 주는 것입니다. Redis Sentinel:

• Primary 및 Replica 인스턴스의 가용성을 모니터링합니다.
• Primary가 실패했을 때 Replica를 Primary로 승격합니다.
• 실패한 Primary가 다시 온라인 상태가 되었을 때 Primary를 Replica로 강등합니다.
• 애플리케이션이 항상 현재 Primary 서버에 연결할 수 있도록 쿼리할 수 있습니다.

Primary가 응답하지 않을 경우, 타임아웃 및 재연결을 처리하는 것은 애플리케이션의 책임입니다(본 경우 GitLab).

Sentinel을 올바르게 설정하는 방법을 더 잘 이해하려면 먼저 Redis Sentinel 문서를 읽어보세요. 잘못 구성할 경우 데이터 손실이 발생하거나 전체 클러스터가 중단될 수 있으므로 장애 조치 노력이 무효화될 수 있습니다.

권장 설정

최소한의 설정을 위해, 3개의 독립적인 머신에 리눅스 패키지를 설치해야 합니다. 각각 Redis와 Sentinel이 있어야 합니다:

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

노드 수가 왜 이렇게 되는지 이해하지 못한다면 Redis 설정 개요 및 Sentinel 설정 개요를 읽어 보세요.

더 많은 장애에 저항할 수 있는 권장 설정을 위해서는 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 노드는 동일한 방식으로 구성되어야 하며 유사한 서버 사양을 가져야 합니다. 장애 조치 상황에서는 모든 Replica가 Sentinel 서버에 의해 새로운 Primary로 승격될 수 있습니다.

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

Sentinel 설정 개요

Sentinel은 다른 Sentinel과 Redis 노드를 감시합니다. Sentinel이 Redis 노드가 응답하지 않음을 감지하면, 노드의 상태를 다른 Sentinel에 알립니다. Sentinel은 장애 조치를 시작할 수 있도록 최소한의 Sentinel 수인 _quorum_에 도달해야 합니다.

quorum이 충족되면, 모든 알려진 Sentinel 노드의 majority가 사용 가능하고 도달 가능해야 하며, 이를 통해 결정권이 있는 Sentinel leader를 선출해야 합니다. 그 leader는 서비스 가용성을 복구하기 위해 모든 결정을 내립니다:

• 새로운 Primary 승격
• 다른 Replicas 재구성 및 새로운 Primary를 가리키도록 설정
• 모든 다른 Sentinel 피어에게 새로운 Primary 알리기
• 이전 Primary를 재구성하고 온라인 상태가 되었을 때 Replica로 강등

최소한 3 개의 Redis Sentinel 서버가 필요하며, 이들도 각각 독립된 머신에 배치되어야 합니다 (서로 독립적으로 실패할 것으로 가정됩니다), 이상적으로는 서로 다른 지리적 지역에 위치해야 합니다.

기타 Redis 서버와 같은 머신에서 구성할 수 있지만, 전체 노드가 다운되면 Sentinel과 Redis 인스턴스를 모두 잃게 됩니다.

Sentinel 수는 이상적으로 항상 홀수 개여야 하며, 이는 실패 경우에 합의 알고리즘이 효과적입니다.

3 노드 토폴로지에서는 1 개의 Sentinel 노드만 다운될 수 있습니다.

Sentinel의 majority가 다운되면, 네트워크 파티션 보호가 파괴적인 행동을 방지하며 장애 조치 가 시작되지 않습니다.

다음은 몇 가지 예입니다:

• 5 개 또는 6 개의 Sentinel이 있을 경우, 최대 2 개가 다운되어야 장애 조치가 시작됩니다.
• 7 개의 Sentinel이 있을 경우, 최대 3 개의 노드가 다운될 수 있습니다.

Leader 선출은 때때로 consensus가 이루어지지 않으면 투표 라운드에서 실패할 수 있습니다 (위의 홀수 노드 요구 사항 참조). 그 경우, sentinel['failover_timeout']에 정의된 시간만큼 대기한 후 새로운 시도가 이루어집니다 (밀리초 단위).

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

failover_timeout 변수는 여러 다양한 사용 사례가 있습니다. 공식 문서에 따르면:

• 특정 Sentinel에 의해 이전에 시도된 기본(primary)에 대해 장애 조치를 재시작하는 데 필요한 시간은 장애 조치 타임아웃의 두 배입니다.

• Sentinel 현재 구성에 따라 잘못된 기본(primary)에 복제하는 복제가 올바른 기본의 복제를 강제로 시작하는 데 필요한 시간은 정확히 장애 조치 타임아웃입니다 (Sentinel이 잘못된 구성을 감지한 순간부터 계산).

• 이미 진행 중인 장애 조치를 취소하는 데 필요한 시간은 구성 변경을 초래하지 않은 경우입니다 (REPLICAOF NO ONE이지만 승격된 복제로부터 아직 확인되지 않음).

• 진행 중인 장애 조치가 새 기본의 복제로 모든 복제가 재구성되기를 기다리는 최대 시간입니다. 그러나 이 시간 이후에도 복제본은 여전히 Sentinel에 의해 재구성되지만 지정된 정확한 병렬 동기화 진행으로는 수행되지 않습니다.

Redis 구성

이 섹션에서는 새 Redis 인스턴스를 설치하고 설정합니다.

GitLab 및 모든 구성 요소를 처음부터 설치했다고 가정합니다.

이미 Redis가 설치되어 실행 중인 경우 단일 머신 설치에서 전환하는 방법을 읽으세요.

참고: Redis 노드(주 노드 및 복제 노드 모두)는 redis['password']에 정의된 동일한 비밀번호가 필요합니다. 장애 조치가 진행되는 동안 언제든지 Sentinel이 노드를 재구성하고 상태를 주에서 복제로, 또는 그 반대로 변경할 수 있습니다.

요구 사항

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

1. 권장 설정 섹션에 지정된 최소 요구 인스턴스 수를 프로비저닝합니다.
2. GitLab 애플리케이션이 실행 중인 동일한 머신에 Redis 또는 Redis Sentinel을 설치하는 것은 권장하지 않습니다. 이는 HA 구성을 약화시키기 때문입니다. 그러나 Redis와 Sentinel을 동일한 머신에 설치할 수 있습니다.
3. 모든 Redis 노드는 서로 통신할 수 있어야 하며 기본 Redis(6379) 및 Sentinel(26379) 포트에서 수신 연결을 허용해야 합니다(기본 포트를 변경하지 않는 경우).
4. GitLab 애플리케이션을 호스팅하는 서버는 Redis 노드에 액세스할 수 있어야 합니다.
5. 방화벽을 사용하여 외부 네트워크(인터넷)로부터 노드를 보호하십시오.

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

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

당신의 단일 머신 설치는 초기 주 노드이며, 나머지 3개는 이 머신을 가리키는 복제 노드로 구성되어야 합니다.

복제가 완료되면, 단일 머신 설치에서 서비스를 중지하여 주 노드를 새로운 노드 중 하나로 전환해야 합니다.

구성에서 필요한 변경 사항을 만든 후 새로운 노드를 다시 시작합니다.

단일 설치에서 Redis를 비활성화하려면 /etc/gitlab/gitlab.rb를 편집하십시오:

redis['enable'] = false

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

1단계. 주 Redis 인스턴스 구성

1. 주 Redis 서버에 SSH로 접속합니다.

2. 다운로드 및 설치를 위해 GitLab 다운로드 페이지의 1단계 및 2단계를 사용하여 원하는 Linux 패키지를 다운로드합니다.

   • 현재 설치와 동일한 버전 및 유형(커뮤니티, 엔터프라이즈 에디션)의 올바른 Linux 패키지를 선택했는지 확인하십시오.

   • 다운로드 페이지의 다른 단계를 완료하지 마십시오.

3. /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-password-goes-here'
   

4. 오직 주 GitLab 애플리케이션 서버만 마이그레이션을 처리해야 합니다. 데이터베이스 마이그레이션이 업그레이드 중에 실행되지 않도록 하려면 /etc/gitlab/gitlab.rb 파일에 다음 구성을 추가하십시오:

   gitlab_rails['auto_migrate'] = false
   

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

참고: 여러 역할을 지명할 수 있습니다, 예: roles ['redis_sentinel_role', 'redis_master_role']. Roles에 대해 더 읽어보십시오.

2단계. Replica Redis 인스턴스 구성하기

1. replica Redis 서버에 SSH로 접속합니다.

2. 다운로드 및 설치할 Linux 패키지를 GitLab 다운로드 페이지의 1단계 및 2단계를 사용하여 선택합니다.
   • 현재 설치된 버전과 유형(Community, Enterprise editions)과 동일한 올바른 Linux 패키지를 선택했는지 확인합니다.
   • 다운로드 페이지의 다른 단계는 완료하지 마십시오.

3. /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-password-goes-here'  
   
   # 기본 Redis 노드의 IP입니다.  
   redis['master_ip'] = '10.0.0.1'  
   
   # 기본 Redis 서버의 포트, 기본값을 변경하려면 주석을 제거합니다. 기본값은  
   # `6379`입니다.  
   #redis['master_port'] = 6379  
   

4. 업그레이드 시 자동으로 재구성이 실행되지 않도록 하려면, 다음을 실행합니다:

   sudo touch /etc/gitlab/skip-auto-reconfigure  
   

5. 오직 기본 GitLab 애플리케이션 서버만 마이그레이션을 처리해야 합니다.
   업그레이드 시 데이터베이스 마이그레이션이 실행되지 않도록 하기 위해
   /etc/gitlab/gitlab.rb 파일에 다음 구성을 추가합니다:

   gitlab_rails['auto_migrate'] = false  
   

6. GitLab을 재구성합니다 수정 사항이 적용되도록 합니다.

7. 다른 모든 replica 노드에 대해 다시 단계를 수행합니다.

노트:
여러 역할을 지정할 수 있습니다: roles ['redis_sentinel_role', 'redis_master_role'].
역할에 대해 더 알아보세요.

이 값들은 페일오버 후 /etc/gitlab/gitlab.rb에서 다시 변경할 필요가 없으며,
노드는 Sentinels에 의해 관리되므로, 심지어 gitlab-ctl reconfigure 후에도
동일한 Sentinels에 의해 구성 내용이 복원됩니다.

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

노트:
Sentinel 비밀번호 인증 지원은 GitLab 16.1에서 도입되었습니다.

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

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

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

GitLab Enterprise Edition을 사용하면, Sentinel 데몬을 사용하여 여러 머신을
설정할 수 있습니다.

1. Redis Sentinel를 호스팅하는 서버에 SSH로 접속합니다.

2. 다른 Redis 인스턴스와 동일한 노드에 Sentinel이 호스팅되는 경우 이 단계를 생략할 수 있습니다.

   다운로드 및 설치할 Linux Enterprise Edition 패키지를
   GitLab 다운로드 페이지의 1단계 및 2단계를 사용하여 선택합니다.
   - GitLab 애플리케이션이 실행 중인 버전과 동일한 올바른 Linux 패키지를 선택했는지 확인합니다.
   - 다운로드 페이지의 다른 단계는 완료하지 마십시오.

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

   roles ['redis_sentinel_role']
   
   # 모든 센티넬 노드에서 같아야 합니다.  
   redis['master_name'] = 'gitlab-redis'
   
   # 기본 노드를 위해 설정한 Redis 인증에 대한 동일한 비밀번호입니다.  
   redis['master_password'] = 'redis-password-goes-here'  
   
   # 기본 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-password-goes here'  
   
   # Sentinel이 수신하는 포트, 기본값을 변경하려면 주석을 제거합니다. 기본값은  
   # `26379`입니다.  
   # sentinel['port'] = 26379  
   
   ## 쿼럼은 페일오버를 시작하는 데 필요한 투표 센티넬의 수를 반영해야 합니다.  
   ## 값은 센티넬 수보다 클 수 없습니다.  
   ##  
   ## 쿼럼은 Sentinel을 조정하는 두 가지 방법으로 사용할 수 있습니다:  
   ## 1. 쿼럼이 배포한 센티넬의 다수보다 작은 값으로 설정되면,  
   ##    기본 실패에 더욱 민감하게 작동하게 되어, 기본에 대한  
   ##    연결이 끊어지면 신속하게 페일오프를 유발합니다.  
   ## 1. 쿼럼이 센티넬의 다수보다 큰 값으로 설정되면,  
   ##    기본이 다운되었음을 승인하는 연결된 센티넬 수가 매우  
   ##    많을 때에만 페일오프를 수행할 수 있습니다.  
   sentinel['quorum'] = 2  
   
   ## 응답하지 않는 서버는 x 밀리초 후 다운으로 간주합니다.  
   # sentinel['down_after_milliseconds'] = 10000  
   
   ## 페일오버 타임아웃을 밀리초로 지정합니다. 여러 방법으로 사용됩니다:  
   ##  
   ## - 주어진 Sentinel에 의해 이전 페일오버가 이미  
   ##   시도된 경우에는 이미 페일오버 타임아웃의 2배의  
   ##   시간이 필요합니다.  
   ##  
   ## - 현재 Sentinel 구성에 따라 잘못된 기본에 복제하고 있는  
   ##   복제본이 올바른 기본으로 복제되도록 강제하는 데 필요한 시간은  
   ##   정확히 페일오버 타임아웃입니다 (Sentinel이 잘못된 구성을  
   ##   감지한 순간부터 계산).  
   ##  
   ## - 이미 진행 중인 페일오버를 취소해야 하고,  
   ##   구성 변경이 일어나지 않은 경우 (REPLICAOF NO ONE이지만  
   ##   승격된 복제본에 의해 아직 인정받지 않음).  
   ##  
   ## - 진행 중인 페일오버가 새 기본의 복제본으로  
   ##   모든 복제가 재구성되기를 기다리는 최대 시간입니다.  
   ##   그러나 이 시간이 지난 후에도 replicas는  
   ##   여전히 Sentinels에 의해 재구성되지만,  
   ##   지정된 병렬 동기화 진행과는 정확하지 않을 수 있습니다.  
   # sentinel['failover_timeout'] = 60000  
   

4. 업그레이드 시 데이터베이스 마이그레이션이 실행되지 않도록 하려면 다음을 실행합니다:

   sudo touch /etc/gitlab/skip-auto-reconfigure  
   

   오직 기본 GitLab 애플리케이션 서버만 마이그레이션을 처리해야 합니다.

5. GitLab을 재구성합니다 수정 사항이 적용되도록 합니다.

6. 다른 모든 Sentinel 노드에 대해 다시 단계를 수행합니다.

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

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

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

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

참고: 다음 단계는 이상적으로 Redis 또는 Sentinel이 없어야 하는 GitLab 애플리케이션 서버에서 수행되어야 합니다.

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

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

   ## 모든 Sentinel 노드에서 동일해야 합니다.
   redis['master_name'] = 'gitlab-redis'
   
   ## 기본 노드에 대해 설정한 Redis 인증을 위한 동일한 비밀번호입니다.
   redis['master_password'] = 'redis-password-goes-here'
   
   ## `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-goes-here' # 주석을 제거하고 sentinel['password']와 동일한 값으로 설정합니다.
   

3. 변경 사항을 적용하려면 GitLab 재구성을 수행합니다.

5단계. 모니터링 활성화

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

1. 다음 단계를 위해 IP 주소 또는 DNS 레코드인 CONSUL_SERVER_NODES를 수집해야 합니다. Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z와 같이 표시됩니다.

2. /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'
   

3. 구성을 컴파일하려면 sudo gitlab-ctl reconfigure를 실행합니다.

1개의 기본 서버, 2개의 복제본 및 3개의 Sentinel로 구성된 최소 구성 예

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

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

우리는 Redis 설정 개요와 Sentinel 설정 개요 문서에서 논의한 동일한 3 노드를 사용한 Redis + Sentinel 토폴로지를 사용합니다.

각 머신과 할당된 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 노드가 재구성되고 기본 서버는 영구적으로(및 redis.conf 포함) 한 노드에서 다른 노드로 변경되며, 새로운 장애 조치가 다시 시작될 때까지 유지됩니다.

동일한 일이 sentinel.conf에서도 발생하며, 초기 실행 후 새로운 sentinel 노드가 기본 서버를 감시하기 시작하거나 장애 조치가 다른 기본 노드를 승격할 때 덮어쓰기가 이루어집니다.

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-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 # 초기 주 redis 인스턴스의 포트, 기본값 변경하려면 주석 해제
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 서버의 포트, 기본값 변경하려면 주석 해제
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 서버의 포트, 기본값 변경하려면 주석 해제
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-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 인스턴스를 실행하는 것을 지원합니다.

이 작업을 Sentinel과 함께 작동하게 하려면:

1. 필요에 따라 다양한 Redis/Sentinels 인스턴스를 구성하세요.

2. 각 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입니다.

3. 파일을 저장하고 변경 사항이 적용되도록 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 기본/복제 역할
redis_master_role['enable'] = true # 둘 중 하나만 활성화
redis_replica_role['enable'] = true # 둘 중 하나만 활성화

# Redis 기본 또는 복제 역할이 활성화되면, 다음 서비스가
# 활성화/비활성화됩니다. Redis와 Sentinel 역할이 결합되는 경우,
# 두 서비스가 모두 활성화됩니다.

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

# Redis 복제 역할의 경우, 이 설정을 기본값 'true'에서 'false'로 변경하십시오:
redis['master'] = false

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

시작 동작 제어

• GitLab 15.10에 도입됨.

번들된 Redis 서비스가 부팅 시 시작되거나 구성 변경 후 재시작되지 않도록 하려면:

1. /etc/gitlab/gitlab.rb를 편집합니다:

   redis['start_down'] = true
   

2. GitLab을 재구성합니다:

   sudo gitlab-ctl reconfigure
   

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

복제 구성 제어

• GitLab 15.10에 도입됨.

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

1. /etc/gitlab/gitlab.rb를 편집합니다:

   redis['set_replicaof'] = false
   

2. GitLab을 재구성합니다:

   sudo gitlab-ctl reconfigure
   

이 설정은 다른 Redis 설정과 독립적으로 Redis 노드의 복제를 방지하는 데 사용될 수 있습니다.

문제 해결

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

추가 자료

자세히 읽어보세요:

1. 참조 아키텍처
2. 데이터베이스 구성
3. NFS 구성
4. 로드 밸런서 구성