이 설명서는 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 인스턴스는 서로 다른 머신에서 실행되어야 합니다. 이 특정 방식으로 머신을 프로비저닝하지 못하면 공유 환경의 문제가 전체 설정을 중단시킬 수 있습니다.

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

또한 기반 네트워크 토폴로지를 고려하여 Redis/Sentinel과 GitLab 인스턴스 간에 중복 연결이 있는지 확인해야 합니다. 그렇지 않으면 네트워크가 단일 장애 지점이 됩니다.

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

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

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

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

기본이 응답하지 못하면 애플리케이션(우리의 경우 GitLab)이 시간 초과를 처리하고 재연결(새 기본을 위해 Sentinel 쿼리)하는 것이 해당 애플리케이션의 책임입니다.

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

권장 설정#

최소 설정의 경우 Redis 및 Sentinel이 모두 있는 3개의 독립된 머신에 Linux 패키지를 설치해야 합니다:

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

노드 수가 어디서 나오는지 확실하지 않거나 이해가 안 된다면 Redis 설정 개요와 Sentinel 설정 개요를 읽어보세요.

더 많은 오류에 견딜 수 있는 권장 설정의 경우 Redis 및 Sentinel이 모두 있는 5개의 독립된 머신에 Linux 패키지를 설치해야 합니다:

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

Redis 설정 개요#

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

추가 Redis 노드를 두면 더 많은 노드가 다운되는 상황에서도 살아남는 데 도움이 됩니다. 온라인 상태의 노드가 2개만 있을 때는 장애 조치가 시작되지 않습니다.

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

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

장애 조치 상황에서 Sentinel 서버가 어떤 복제본이든 새 기본으로 승격할 수 있으므로, 모든 Redis 노드는 동일한 방식으로 유사한 서버 사양으로 구성되어야 합니다.

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

Sentinel 설정 개요#

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

쿼럼에 도달할 때마다, 알려진 모든 Sentinel 노드의 대다수가 사용 가능하고 연결 가능해야 합니다. 그래야 Sentinel 리더를 선출할 수 있으며, 리더는 다음을 통해 서비스 가용성을 복원하기 위한 모든 결정을 내립니다:

• 새 기본 승격
• 다른 복제본을 재구성하여 새 기본을 가리키게 함
• 다른 모든 Sentinel 피어에 새 기본 발표
• 기존 기본이 다시 온라인 상태가 될 때 재구성하여 복제본으로 강등

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

다른 Redis 서버를 구성한 것과 동일한 머신에 구성할 수 있지만, 전체 노드가 다운되면 Sentinel과 Redis 인스턴스를 모두 잃게 됩니다.

합의 알고리즘이 오류 발생 시 효과적이려면 Sentinel의 수는 항상 홀수여야 합니다.

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

다음은 몇 가지 예입니다:

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

합의가 달성되지 않으면 리더 선출 투표 라운드가 실패할 수 있습니다. 그 경우 sentinel['failover_timeout'](밀리초)에 정의된 시간이 지난 후 새 시도가 이루어집니다.

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

• 주어진 Sentinel이 동일한 기본을 대상으로 이전 장애 조치를 이미 시도한 후 장애 조치를 다시 시작하는 데 필요한 시간은 장애 조치 시간 초과의 두 배입니다.
• Sentinel 현재 구성에 따라 잘못된 기본으로 복제하는 복제본이 올바른 기본으로 강제 복제하는 데 필요한 시간은 정확히 장애 조치 시간 초과입니다(Sentinel이 잘못된 구성을 감지한 순간부터).
• 이미 진행 중이지만 구성 변경을 생성하지 않은 장애 조치를 취소하는 데 필요한 시간(승격된 복제본이 아직 승인하지 않은 REPLICAOF NO ONE).
• 진행 중인 장애 조치가 모든 복제본이 새 기본의 복제본으로 재구성될 때까지 기다리는 최대 시간. 그러나 이 시간이 지난 후에도 Sentinel은 복제본을 재구성하지만 지정된 병렬 동기화 진행으로는 아닙니다.

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

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

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

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

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

   • 현재 설치와 동일한 버전과 유형(Community, Enterprise 에디션)의 올바른 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 에디션)의 올바른 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. 업그레이드 시 재구성이 자동으로 실행되지 않도록 하려면 다음을 실행합니다:

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

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

   gitlab_rails['auto_migrate'] = false
   

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

7. 다른 모든 복제본 노드에 대해 단계를 반복합니다.

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

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

히스토리

• GitLab 16.1에서 Sentinel 비밀번호 인증 지원이 도입되었습니다.

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

Redis 서버가 제대로 작동하고 올바르게 복제되는지 확실하지 않은 경우 복제 트러블슈팅을 읽고 Sentinel 설정을 진행하기 전에 수정하세요.

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

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를 편집하고 내용을 추가합니다(다른 Redis 인스턴스와 동일한 노드에 Sentinel을 설치하는 경우 아래 일부 값이 중복될 수 있습니다):

   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 a 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.s
   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 produced 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 애플리케이션 구성#

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

새 설치나 기존 설치에서 언제든지 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_SERVER_NODES를 수집해야 합니다. 이는 Consul 서버 노드의 IP 주소 또는 DNS 레코드입니다. 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 설정 개요 설명서에서 설명한 동일한 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 노드가 재구성되고 기본이 한 노드에서 다른 노드로 영구적으로(redis.conf 포함) 변경됩니다. 이는 새 장애 조치가 다시 시작될 때까지 계속됩니다.

초기 실행 후, 새로운 Sentinel 노드가 기본을 감시하기 시작하거나 장애 조치가 다른 기본 노드를 승격시킬 때마다 재정의되는 sentinel.conf에서도 동일한 일이 발생합니다.

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 패키지는 다양한 지속성 클래스를 위한 별도의 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 기본 이름입니다. 예를 들어 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에서 찾을 수 있습니다.

시작 동작 제어#

히스토리

• 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 대신 Valkey 사용#

히스토리

• GitLab 18.9에서 베타로 도입되었습니다.
• GitLab 19.0에서 일반 제공됩니다.

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

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

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

# 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. 로드 밸런서 구성