이 문서는 Linux 패키지를 대상으로 합니다. 번들되지 않은 자체 Redis를 사용하려면 자체 인스턴스를 제공하는 Redis 복제 및 장애 조치를 참고합니다.

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

확장 가능한 환경에서 Redis를 사용하는 것은 장애 조치 절차를 감시하고 자동으로 시작하는 Redis Sentinel 서비스와 함께 기본 x 복제본 토폴로지를 사용하면 가능합니다.

Redis는 Sentinel과 함께 사용할 때 인증이 필요합니다. 자세한 내용은 Redis 보안 설명서를 참고합니다. Redis 서비스를 보호하려면 Redis 비밀번호와 엄격한 방화벽 규칙을 함께 사용하는 것을 권장합니다. 토폴로지와 아키텍처를 완전히 이해하려면 GitLab으로 Redis를 구성하기 전에 Redis Sentinel 설명서를 먼저 읽어보는 것을 권장합니다.

Redis와 Redis Sentinel을 복제 토폴로지로 설정하는 세부 내용에 들어가기 전에, 구성 요소들이 어떻게 연결되는지 더 잘 이해하기 위해 이 문서를 전체적으로 한 번 읽어보는 것을 권장합니다.

물리적인 머신이든, 별도의 물리적 머신에서 실행되는 VM이든 최소 3개의 독립된 머신이 필요합니다. 모든 기본 및 복제본 Redis 인스턴스는 서로 다른 머신에서 실행되어야 합니다. 머신을 이 특정 방식으로 프로비저닝하지 못하면, 공유 환경의 문제가 전체 설정을 중단시킬 수 있습니다.

기본 또는 복제본 Redis 인스턴스와 함께 Sentinel을 실행해도 됩니다. 다만 같은 머신에 Sentinel을 두 개 이상 두면 안 됩니다.

또한 기반 네트워크 토폴로지도 고려해야 합니다. Redis/Sentinel과 GitLab 인스턴스 사이에 이중화된 연결을 확보해야 합니다. 그렇지 않으면 네트워크가 단일 장애 지점이 될 수 있습니다.

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

• 여러 개의 Redis 인스턴스
• 기본 x 복제본 토폴로지로 Redis 실행
• 여러 개의 Sentinel 인스턴스
• 모든 Sentinel 및 Redis 인스턴스에 대한 애플리케이션 지원과 가시성

Redis Sentinel은 HA 환경에서 가장 중요한 작업을 처리하며, 다운타임을 최소화하거나 없애면서 서버를 온라인 상태로 유지하도록 돕습니다. Redis Sentinel은 다음을 수행합니다:

• 기본 및 복제본 인스턴스를 모니터링하여 사용 가능한지 확인합니다
• 기본이 실패하면 복제본을 기본으로 승격시킵니다
• 실패했던 기본이 다시 온라인 상태가 되면 기본을 복제본으로 강등시킵니다(데이터 파티셔닝 방지)
• 애플리케이션이 항상 현재 기본 서버에 연결하도록 조회할 수 있습니다

기본이 응답하지 않으면, 타임아웃을 처리하고 재연결하는 것은 애플리케이션(우리의 경우 GitLab)의 책임입니다(새로운 기본을 찾기 위해 Sentinel에 조회합니다).

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

권장 설정#

최소 설정을 위해서는 3개의 독립된 머신에 Redis와 Sentinel을 모두 포함하여 Linux 패키지를 설치해야 합니다:

• Redis 기본 + Sentinel
• Redis 복제본 + Sentinel
• Redis 복제본 + Sentinel

노드 수가 어디서 왜 나온 것인지 확실하지 않거나 이해되지 않는다면 Redis 설정 개요와 Sentinel 설정 개요를 참고합니다.

더 많은 장애를 견딜 수 있는 권장 설정을 위해서는 5개의 독립된 머신에 Redis와 Sentinel을 모두 포함하여 Linux 패키지를 설치해야 합니다:

• Redis 기본 + Sentinel
• Redis 복제본 + Sentinel
• Redis 복제본 + Sentinel
• Redis 복제본 + Sentinel
• Redis 복제본 + Sentinel

Redis 설정 개요#

최소 3개의 Redis 서버가 있어야 합니다: 1개의 기본, 2개의 복제본이며, 각각 독립된 머신에 있어야 합니다.

추가 Redis 노드를 둘 수 있으며, 이는 더 많은 노드가 다운되는 상황에서도 버틸 수 있도록 돕습니다. 온라인 상태인 노드가 2개뿐일 때는 장애 조치가 시작되지 않습니다.

예를 들어 Redis 노드가 6개 있다면, 최대 3개까지 동시에 다운되어도 됩니다.

Sentinel 노드에는 다른 요구 사항이 있습니다. Sentinel을 같은 Redis 머신에 호스팅하는 경우, 프로비저닝할 노드 수를 계산할 때 이러한 제약을 고려해야 할 수 있습니다. 자세한 내용은 Sentinel 설정 개요 설명서를 참고합니다.

모든 Redis 노드는 동일한 방식으로 구성하고 서버 사양도 유사하게 맞춰야 합니다. 장애 조치 상황에서는 어떤 복제본이든 Sentinel 서버에 의해 새로운 기본으로 승격될 수 있기 때문입니다.

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

Sentinel 설정 개요#

Sentinel은 다른 Sentinel과 Redis 노드를 모두 감시합니다. Sentinel이 Redis 노드가 응답하지 않는 것을 감지하면, 해당 노드의 상태를 다른 Sentinel들에게 알립니다. 장애 조치를 시작하려면 Sentinel들이 쿼럼 (노드가 다운되었다는 데 동의하는 최소 Sentinel 수)에 도달해야 합니다.

쿼럼이 충족되면, 알려진 모든 Sentinel 노드 중 과반수가 사용 가능하고 접근 가능한 상태여야 합니다. 그래야 서비스 가용성을 복구하기 위한 모든 결정을 내리는 Sentinel 리더를 다음과 같은 방법으로 선출할 수 있습니다:

• 새로운 기본 승격
• 다른 복제본을 재구성하여 새로운 기본을 가리키게 함
• 다른 모든 Sentinel 피어에게 새로운 기본을 알림
• 이전 기본이 다시 온라인 상태가 되면 재구성하여 복제본으로 강등

최소 3개의 Redis Sentinel 서버가 있어야 하며, 각각은(독립적으로 실패할 것으로 예상되는) 독립된 머신에 있어야 하고, 가능하면 서로 다른 지리적 영역에 있어야 합니다.

다른 Redis 서버를 구성한 머신과 동일한 머신에 Sentinel을 구성할 수도 있지만, 노드 전체가 다운되면 Sentinel과 Redis 인스턴스를 모두 잃게 된다는 점을 알아야 합니다.

장애 상황에서 합의 알고리즘이 효과적으로 동작하려면 Sentinel의 수는 항상 홀수인 것이 이상적입니다.

3개 노드 토폴로지에서는 1개의 Sentinel 노드만 다운되어도 감당할 수 있습니다. Sentinel의 과반수가 다운되면 네트워크 파티션 보호 기능이 파괴적인 작업을 막고 장애 조치가 시작되지 않습니다.

다음은 몇 가지 예입니다:

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

리더 선출은 합의에 도달하지 못하면 투표 라운드가 실패할 수도 있습니다. 이 경우 sentinel['failover_timeout']에 정의된 시간(밀리초 단위)이 지난 후 다시 시도합니다.

failover_timeout 변수는 다양한 용도로 사용됩니다. 공식 설명서에 따르면 다음과 같습니다:

• 특정 Sentinel이 동일한 기본에 대해 이미 장애 조치를 시도한 후 장애 조치를 다시 시작하는 데 필요한 시간은 장애 조치 시간 초과의 두 배입니다.

• Sentinel의 현재 구성에 따라 잘못된 기본에 복제하고 있는 복제본이 올바른 기본으로 강제로 복제하게 되는 데 걸리는 시간은 정확히 장애 조치 시간 초과입니다(Sentinel이 잘못된 구성을 감지한 시점부터 계산합니다).

• 이미 진행 중이지만 아직 구성 변경을 만들지 않은 장애 조치를 취소하는 데 필요한 시간입니다(승격된 복제본이 REPLICAOF NO ONE을 아직 인식하지 못한 상태).

• 진행 중인 장애 조치가 모든 복제본이 새로운 기본의 복제본으로 재구성되기를 기다리는 최대 시간입니다. 다만 이 시간이 지나도 Sentinel은 어차피 복제본을 재구성하지만, 지정된 것과 정확히 같은 parallel-syncs 진행 방식으로는 이루어지지 않습니다.

Redis 구성#

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

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

요구 사항#

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

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

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

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

2. GitLab 다운로드 페이지에서 1단계와 2단계를 사용하여 원하는 Linux 패키지를 다운로드하고 설치합니다.

   • 현재 설치와 동일한 버전과 유형(Community, Enterprise edition)의 올바른 Linux 패키지를 선택해야 합니다.
   • 다운로드 페이지의 다른 단계는 수행하지 않습니다.

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

   # Specify server role as 'redis_master_role'
   roles ['redis_master_role']
   
   # IP address pointing to a local IP that the other machines can reach to.
   # You can also set bind to '0.0.0.0' which listen in all interfaces.
   # If you really need to bind to an external accessible IP, make
   # sure you add extra firewall rules to prevent unauthorized access.
   redis['bind'] = '10.0.0.1'
   
   # Define a port so Redis can listen for TCP requests which allows other
   # machines to connect to it.
   redis['port'] = 6379
   
   # Set up password authentication for Redis (use the same password in all nodes).
   redis['password'] = 'redis-password-goes-here'
   

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

   gitlab_rails['auto_migrate'] = false
   

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

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

1. 복제본 Redis 서버에 SSH로 접속합니다.

2. GitLab 다운로드 페이지에서 1단계와 2단계를 사용하여 원하는 Linux 패키지를 다운로드하고 설치합니다.

   • 현재 설치와 동일한 버전과 유형(Community, Enterprise edition)의 올바른 Linux 패키지를 선택해야 합니다.
   • 다운로드 페이지의 다른 단계는 수행하지 않습니다.

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

   # Specify server role as 'redis_replica_role'
   roles ['redis_replica_role']
   
   # IP address pointing to a local IP that the other machines can reach to.
   # You can also set bind to '0.0.0.0' which listen in all interfaces.
   # If you really need to bind to an external accessible IP, make
   # sure you add extra firewall rules to prevent unauthorized access.
   redis['bind'] = '10.0.0.2'
   
   # Define a port so Redis can listen for TCP requests which allows other
   # machines to connect to it.
   redis['port'] = 6379
   
   # The same password for Redis authentication you set up for the primary node.
   redis['password'] = 'redis-password-goes-here'
   
   # The IP of the primary Redis node.
   redis['master_ip'] = '10.0.0.1'
   
   # Port of primary Redis server, uncomment to change to non default. Defaults
   # to `6379`.
   #redis['master_port'] = 6379
   

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

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

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

   gitlab_rails['auto_migrate'] = false
   

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

7. 다른 모든 복제본 노드에 대해서도 이 단계를 다시 진행합니다.

장애 조치 후에는 /etc/gitlab/gitlab.rb에서 이 값들을 다시 변경할 필요가 없습니다. 노드는 Sentinel이 관리하며, gitlab-ctl reconfigure를 실행한 후에도 동일한 Sentinel에 의해 구성이 복원되기 때문입니다.

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

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

Redis 서버가 올바르게 동작하고 복제되고 있는지 확실하지 않다면, 복제 문제 해결을 읽고 Sentinel 설정을 진행하기 전에 문제를 해결합니다.

최소 3개의 Redis Sentinel 서버가 있어야 하며, 각각은 독립된 머신에 있어야 합니다. 다른 Redis 서버를 구성한 것과 동일한 머신에 Sentinel을 구성할 수도 있습니다.

GitLab Enterprise Edition에서는 Linux 패키지를 사용하여 여러 머신에 Sentinel 데몬을 설정할 수 있습니다.

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

2. Sentinel이 다른 Redis 인스턴스와 같은 노드에 호스팅되어 있다면 이 단계를 생략할 수 있습니다.

   GitLab 다운로드 페이지에서 1단계와 2단계를 사용하여 Linux Enterprise Edition 패키지를 다운로드하고 설치합니다.

   • GitLab 애플리케이션이 실행 중인 것과 동일한 버전의 올바른 Linux 패키지를 선택해야 합니다.
   • 다운로드 페이지의 다른 단계는 수행하지 않습니다.

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

   roles ['redis_sentinel_role']
   
   # Must be the same in every sentinel node
   redis['master_name'] = 'gitlab-redis'
   
   # The same password for Redis authentication you set up for the primary node.
   redis['master_password'] = 'redis-password-goes-here'
   
   # The IP of the primary Redis node.
   redis['master_ip'] = '10.0.0.1'
   
   # Define a port so Redis can listen for TCP requests which allows other
   # machines to connect to it.
   redis['port'] = 6379
   
   # Port of primary Redis server, uncomment to change to non default. Defaults
   # to `6379`.
   #redis['master_port'] = 6379
   
   ## Configure Sentinel
   sentinel['bind'] = '10.0.0.1'
   
   ## Optional password for Sentinel authentication. Defaults to no password required.
   # sentinel['password'] = 'sentinel-password-goes here'
   
   # Port that Sentinel listens on, uncomment to change to non default. Defaults
   # to `26379`.
   # sentinel['port'] = 26379
   
   ## Quorum must reflect the amount of voting sentinels it take to start a failover.
   ## Value must NOT be greater than the amount of sentinels.
   ##
   ## The quorum can be used to tune Sentinel in two ways:
   ## 1. If the quorum is set to a value smaller than the majority of Sentinels
   ##    we deploy, we are basically making Sentinel more sensible to primary failures,
   ##    triggering a failover as soon as even just a minority of Sentinels is no longer
   ##    able to talk with the primary.
   ## 1. If a quorum is set to a value greater than the majority of Sentinels, we are
   ##    making Sentinel able to failover only when there are a very large number (larger
   ##    than majority) of well connected Sentinels which agree about the primary being down.
   sentinel['quorum'] = 2
   
   ## Consider unresponsive server down after x amount of ms.
   # sentinel['down_after_milliseconds'] = 10000
   
   ## Specifies the failover timeout in milliseconds. It is used in many ways:
   ##
   ## - The time needed to re-start a failover after a previous failover was
   ##   already tried against the same primary by a given Sentinel, is two
   ##   times the failover timeout.
   ##
   ## - The time needed for a replica replicating to a wrong primary according
   ##   to a Sentinel current configuration, to be forced to replicate
   ##   with the right primary, is exactly the failover timeout (counting since
   ##   the moment a Sentinel detected the misconfiguration).
   ##
   ## - The time needed to cancel a failover that is already in progress but
   ##   did not produce any configuration change (REPLICAOF NO ONE yet not
   ##   acknowledged by the promoted replica).
   ##
   ## - The maximum time a failover in progress waits for all the replica to be
   ##   reconfigured as replicas of the new primary. However even after this time
   ##   the replicas are reconfigured by the Sentinels anyway, but not with
   ##   the exact parallel-syncs progression as specified.
   # sentinel['failover_timeout'] = 60000
   

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

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

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

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

6. 다른 모든 Sentinel 노드에 대해서도 이 단계를 다시 진행합니다.

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

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

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

모든 Sentinel 노드의 목록이 필요하지는 않지만, 장애가 발생했을 때는 목록에 있는 노드 중 최소 하나에 접근할 수 있어야 합니다.

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

2. /etc/gitlab/gitlab.rb를 편집하여 다음 줄을 추가하거나 변경합니다:

   ## Must be the same in every sentinel node
   redis['master_name'] = 'gitlab-redis'
   
   ## The same password for Redis authentication you set up for the primary node.
   redis['master_password'] = 'redis-password-goes-here'
   
   ## A list of sentinels with `host` and `port`
   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' # uncomment and set it to the same value as in sentinel['password']
   

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

5단계. 모니터링 활성화#

모니터링을 활성화하는 경우, 모든 Redis 서버에서 활성화해야 합니다.

1. 다음 단계에 필요한 Consul 서버 노드의 IP 주소 또는 DNS 레코드인 CONSUL_SERVER_NODES를 반드시 수집합니다. 이는 Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z와 같은 형태로 표시됩니다.

2. /etc/gitlab/gitlab.rb를 생성하거나 편집하여 다음 구성을 추가합니다:

   # Enable service discovery for Prometheus
   consul['enable'] = true
   consul['monitoring_service_discovery'] =  true
   
   # Replace placeholders
   # Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z
   # with the addresses of the Consul server nodes
   consul['configuration'] = {
      retry_join: %w(Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z),
   }
   
   # Set the network addresses that the exporters listen on
   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개, Sentinel 3개로 구성하는 최소 구성 예시#

이 예시에서는 모든 서버가 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 노드가 기본을 감시하기 시작하거나 장애 조치로 다른 기본 노드가 승격되면 재정의됩니다.

/opt/gitlab/embedded/bin/redis-cli -p 26379 SENTINEL failover gitlab-redis

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' # must be the same in every sentinel node
redis['master_password'] = 'redis-password-goes-here' # the same value defined in redis['password'] in the primary instance
redis['master_ip'] = '10.0.0.1' # ip of the initial primary redis instance
#redis['master_port'] = 6379 # port of the initial primary redis instance, uncomment to change to non default
sentinel['bind'] = '10.0.0.1'
# sentinel['password'] = 'sentinel-password-goes-here' # must be the same in every sentinel node, uncomment to set a password
# sentinel['port'] = 26379 # uncomment to change default port
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' # IP of primary Redis server
#redis['master_port'] = 6379 # Port of primary Redis server, uncomment to change to non default
redis['master_name'] = 'gitlab-redis' # must be the same in every sentinel node
sentinel['bind'] = '10.0.0.2'
# sentinel['password'] = 'sentinel-password-goes-here' # must be the same in every sentinel node, uncomment to set a password
# sentinel['port'] = 26379 # uncomment to change default port
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' # IP of primary Redis server
#redis['master_port'] = 6379 # Port of primary Redis server, uncomment to change to non default
redis['master_name'] = 'gitlab-redis' # must be the same in every sentinel node
sentinel['bind'] = '10.0.0.3'
# sentinel['password'] = 'sentinel-password-goes-here' # must be the same in every sentinel node, uncomment to set a password
# sentinel['port'] = 26379 # uncomment to change default port
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' # uncomment and set it to the same value as in sentinel['password']

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

고급 구성#

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

여러 Redis 클러스터 실행#

Linux 패키지는 서로 다른 persistence class를 위해 별도의 Redis 및 Sentinel 인스턴스를 실행하는 것을 지원합니다.

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

1. 필요에 따라 서로 다른 Redis/Sentinel 인스턴스를 구성합니다.

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
   
   # Configure the 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 primary 이름입니다(예: gitlab-redis-cache).

3. 파일을 저장하고 변경 사항을 적용하기 위해 GitLab을 재구성합니다:

   sudo gitlab-ctl reconfigure
   

실행 중인 서비스 제어#

이전 예시에서는 구성 변경량을 줄여주는 redis_sentinel_role과 redis_master_role을 사용했습니다.

더 세밀한 제어를 원한다면, 각 역할을 활성화했을 때 자동으로 설정되는 내용은 다음과 같습니다:

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

# When Sentinel Role is enabled, the following services are also enabled
sentinel['enable'] = true

# The following services are disabled
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 # enable only one of them
redis_replica_role['enable'] = true # enable only one of them

# When Redis primary or Replica role are enabled, the following services are
# enabled/disabled. If Redis and Sentinel roles are combined, both
# services are enabled.

# The following services are disabled
sentinel['enable'] = false
bootstrap['enable'] = false
nginx['enable'] = false
postgresql['enable'] = false
gitlab_rails['enable'] = false
mailroom['enable'] = false

# For Redis Replica role, also change this setting from default 'true' to 'false':
redis['master'] = false

관련 속성은 gitlab_rails.rb에 정의되어 있습니다.

시작 동작 제어#

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

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

   redis['start_down'] = true
   

2. GitLab을 재구성합니다:

   sudo gitlab-ctl reconfigure
   

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

복제본 구성 제어#

Redis 구성 파일에 replicaof 줄이 생성되지 않도록 하려면:

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

   redis['set_replicaof'] = false
   

2. GitLab을 재구성합니다:

   sudo gitlab-ctl reconfigure
   

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

Redis 대신 Valkey 사용#

복제 및 장애 조치 설정에서 Redis의 대체품으로 Valkey를 사용할 수 있습니다. Valkey는 Redis와 동일한 역할 및 구성 옵션을 사용합니다.

Valkey 기본 및 복제본 노드 구성#

각 노드(기본 및 복제본)에서 Redis를 Valkey로 전환하려면 /etc/gitlab/gitlab.rb에 다음을 추가합니다:

# Use the same Redis roles
roles ['redis_master_role']  # or 'redis_replica_role' for replicas

# Switch to Valkey
redis['backend'] = 'valkey'

# Use the same configuration options as for Redis
redis['bind'] = '10.0.0.1'
redis['port'] = 6379
redis['password'] = 'redis-password-goes-here'

gitlab_rails['auto_migrate'] = false

Valkey용 Sentinel 구성#

각 Sentinel 노드에서 /etc/gitlab/gitlab.rb에 다음을 추가합니다:

roles ['redis_sentinel_role']

# Switch redis backend to Valkey
# Then Sentinel will use the same backend
redis['backend'] = 'valkey'

# Sentinel configuration (same as for Redis)
redis['master_name'] = 'gitlab-redis'
redis['master_password'] = 'redis-password-goes-here'
redis['master_ip'] = '10.0.0.1'
redis['port'] = 6379

sentinel['bind'] = '10.0.0.1'
sentinel['quorum'] = 2

다른 모든 Sentinel 구성 옵션은 Redis Sentinel 인스턴스 구성에 문서화된 것과 동일하게 유지됩니다.

알려진 문제#

• 알려진 이슈 589642로 인해 관리자 영역에 Valkey 버전이 잘못 표시됩니다. 이 이슈는 설치된 Valkey 버전이나 동작 방식에는 영향을 주지 않습니다.

TLS로 Redis 및 Sentinel 보안#

TLS를 사용하여 Redis 및 Sentinel 통신을 보안하는 방법에 대한 포괄적인 정보는 TLS로 Redis 및 Sentinel 보안을 참고합니다.

문제 해결#

Redis 문제 해결 가이드를 참고합니다.

추가 자료#

다음 자료를 참고합니다:

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