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

Tier: Premium, Ultimate Offering: Self-Managed

이 설명서는 Linux 패키지를 위한 것입니다. 자체 묶지 않은 Redis를 사용하려면 자체 인스턴스 제공 복제 및 장애 조치을 참조하세요.

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

확장 가능한 환경에서 Redis를 사용하여 Primary x Replica 위상 및 Redis Sentinel 서비스를 사용하여 자동 장애 조치 절차를 감시하고 자동으로 시작할 수 있습니다.

Redis는 Sentinel을 사용할 때 인증이 필요합니다. 자세한 내용은 Redis Security 문서를 참조하세요. Redis 서비스를 보호하기 위해 Redis 암호 및 엄격한 방화벽 규칙의 조합을 권장합니다. Redis를 GitLab과 구성하기 전에 Redis Sentinel 문서를 자세히 읽어 전체 위상 및 아키텍처를 완전히 이해하는 것이 좋습니다.

복제 위상에 대한 Redis 및 Redis Sentinel 설정의 세부 사항에 들어가기 전에 이 문서를 한 번 통째로 읽어 컴포넌트가 어떻게 연결되는지 더 잘 이해하세요.

최소 3 대의 독립적인 머신이 필요합니다. 물리적 머신이나 별도의 머신에서 실행되는 VM이어야 합니다. 기본적인 Redis 인스턴스와 복제가 다른 머신에서 실행되는 것이 중요합니다. 특정 방식으로 머신을 프로비저닝하지 않으면 공유 환경에 문제가 발생할 수 있습니다.

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

또한 Redis / Sentinel 및 GitLab 인스턴스 간에 백업 연결이 있음을 확인하고 네트워크의 단일 장애 지점이 되지 않도록 해야 합니다.

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

  • 여러 개의 Redis 인스턴스
  • Primary x Replica 위상에서 Redis 실행
  • 여러 개의 Sentinel 인스턴스
  • 모든 Sentinel 및 Redis 인스턴스를 지원하고 볼 수 있는 응용프로그램

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

  • PrimaryReplica 인스턴스를 감시하여 사용 가능한지 확인합니다.
  • Primary이 실패하면 ReplicaPrimary로 승격시킵니다.
  • 실패한 Primary가 온라인 상태로 돌아올 때 PrimaryReplica로 강등합니다 (데이터 파티션 방지)
  • 응용프로그램이 항상 현재 Primary 서버에 연결하도록 Sentinel에 쿼리할 수 있습니다.

Primary가 응답하지 않을 때, 응용프로그램(GitLab 등)은 타임아웃 및 재연결을 처리하기 위한 책임이 있습니다 (Sentinel에 새 Primary을 요청하는 쿼리 포함).

Sentinel을 올바르게 설정하는 방법에 대한 이해를 높이기 위해 Redis Sentinel 문서를 먼저 읽어야 합니다. 올바르게 구성하지 않으면 데이터 손실 또는 전체 클러스터 다운으로 이어질 수 있으므로 이 문서를 읽는 것이 좋습니다.

추천 설정

최소한 3 대의 독립적인 머신에 Linux 패키지를 설치해야 하며, RedisSentinel을 각각 다음과 같이 설치해야 합니다:

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

서버의 양과 그 원천, 그리고 노드의 수가 왜 필요한지 확실하지 않은 경우 Redis 설정 요약Sentinel 설정 요약 을 읽으십시오.

더 많은 장애를 견딜 수 있는 추천 설정을 위해 Linux 패키지를 5 대의 독립적인 머신에 설치해야 합니다. 각 머신에는 다음과 같이 RedisSentinel이 필요합니다:

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

Redis 설정 요약

적어도 3 개의 Redis 서버가 있어야 합니다: 1개의 primary, 2개의 Replicas가 필요하며 각각 독립적인 머신에 있어야 합니다 (위에서 설명한 것 참조).

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

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

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

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

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

Sentinel 설정 요약

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

quorum이 충족되면 모든 알려진 Sentinel 노드의 대다수가 사용 가능하고 연결할 수 있는지 확인해야 합니다. 그러면 leader로 정해지는 Sentinel이 서비스의 가용성을 복구하기 위한 모든 결정을 내립니다. 이 결정에는 다음이 포함됩니다:

  • Primary 승격
  • 다른 Replica 구성 및 새 Primary을 가리키도록 만듭니다.
  • 모든 다른 Sentinel 동료에게 새로운 Primary 알림
  • 이전의 Primary 구성을 재구성하고 온라인으로 돌아올 때 Primary에서 Replica로 강등

적어도 3 개의 Redis Sentinel 서버가 있어야 하며 이들은 상호 독립적으로 실패할 수 있는 머신에 있어야 합니다. 이상적으로 지리적으로 다른 영역에 있어야 합니다.

Redis 서버를 구성한 것과 같은 머신에 구성할 수 있지만, 전체 노드가 다운되면 Sentinel과 Redis 인스턴스를 둘 다 잃게 된다는 것을 이해해야 합니다.

센티넬 노드의 개수는 이상적으로 항상 홀수여야 합니다. 그룹의 합의 알고리즘이 실패 상황에서 효과적인데 이를 위해 필요합니다.

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

다음은 예시입니다:

  • 5 또는 6개의 센티넬로는 2개가 다운될 수 있고, 장애 조치가 시작됩니다.
  • 7개의 센티넬로는 3개의 노드가 다운될 수 있습니다.

리더 선출은 때때로 합의가 달성되지 않을 때 투표 과정이 실패할 수 있습니다 (위의 홀수 노드 수 요구사항 참조). 이 경우에는 sentinel['failover_timeout'] (밀리초)에 정의된 시간이 지난 후에 새로운 시도가 이루어집니다.

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

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

  • 이전에 특정 센티넬이 특정 기간에 동일한 primary에 대한 장애 조치를 시작했지만 이 일자는 이미 다시 시도를 했을 때 다음 장애 조치를 다시 시작하는 시간은 장애 조치 시간의 두 배입니다.

  • 현재 설정에 따라 잘못된 Primary와 복제 중인 복제가 올바른 Primary로 복제하도록 강제될 때까지 필요한 시간은 정확히 장애 조치 시간입니다 (센티넬이 구성을 감지한 시점부터 세는 시간).

  • 이미 진행 중인 장애 조치를 취소하는 데 필요한 시간이다. 구성 변경을 만들지 않고 이미 승급된 복제에 의해 아직 인정받지 않은 REPLICAOF NO ONE까지 포함합니다.

  • 진행 중인 장애 조치가 모든 복제가 새 Primary의 복제로 재구성되기까지 기다리는 최대 시간입니다. 그러나 이 시간이 지나고도 Sentinel이 복제를 새로 구성하지만 명시된 것처럼 정확한 병렬 동기화 진행은 되지 않습니다.

Redis 구성

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

GitLab 및 모든 컴포넌트를 처음부터 설치했다고 가정합니다. 이미 Redis를 설치하고 실행한 경우 기존 단일 머신 설치에서 전환하는 방법을 읽으십시오.

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

요구 사항

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

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

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

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

사용 중인 단일 머신 설치는 초기 기본이며, 3개의 다른 기기를 복제본으로 구성해야 합니다.

복제가 따라잡히면 단일 머신 설치의 서비스를 중지하고 새 노드 중 하나를 기본으로 변경해야 합니다.

구성 변경 사항을 적용하고 새 노드를 다시 시작합니다.

단일 설치의 Redis를 비활성화하려면 /etc/gitlab/gitlab.rb를 편집합니다:

redis['enable'] = false

먼저 복제하지 않으면 데이터(처리되지 않은 백그라운드 작업)가 손실될 수 있습니다.

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

  1. 기본 Redis 서버에 SSH로 로그인합니다.
  2. Linux 패키지를 다운로드하고 설치합니다. GitLab 다운로드 페이지의 단계 1과 2를 사용합니다.
    • 현재 설치된 버전 및 유형(Community, Enterprise Edition)과 동일한 올바른 Linux 패키지를 선택했는지 확인합니다.
    • 다운로드 페이지의 다른 단계를 완료하지 않습니다.
  3. /etc/gitlab/gitlab.rb를 편집하고 내용을 추가합니다:

    # 서버 역할을 'redis_master_role'로 지정
    roles ['redis_master_role']
       
    # 다른 머신이 연결할 수 있는 로컬 IP를 가리키는 IP 주소
    # 모든 인터페이스에서 수신 대기하기 위해 bind를 '0.0.0.0'으로 설정할 수도 있습니다.
    # 외부 액세스 가능한 IP에 바인딩하는 경우 무단 액세스를 방지하도록 추가 방화벽 규칙을 추가해야 합니다.
    redis['bind'] = '10.0.0.1'
       
    # Redis가 TCP 요청을 수신하도록하는 포트를 정의하여 다른 머신이 연결할 수 있도록합니다.
    redis['port'] = 6379
       
    # Redis의 암호 인증 설정(모든 노드에서 동일한 암호 사용)
    redis['password'] = '여기에-redis-암호-입력'
    
  4. 기본 GitLab 애플리케이션 서버만 마이그레이션을 처리해야 합니다. 업그레이드 시 데이터베이스 마이그레이션을 방지하려면 /etc/gitlab/gitlab.rb 파일에 다음 구성을 추가하세요:

    gitlab_rails['auto_migrate'] = false
    
  5. 변경 사항이 적용되려면 GitLab을 다시 구성합니다.
note
roles ['redis_sentinel_role', 'redis_master_role']와 같이 여러 역할을 지정할 수 있습니다. 역할에 대해 더 알아보기.

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

  1. 복제본 Redis 서버에 SSH로 로그인합니다.
  2. Linux 패키지를 다운로드하고 설치합니다. GitLab 다운로드 페이지의 단계 1과 2를 사용합니다.
    • 현재 설치된 버전 및 유형(Community, Enterprise Edition)과 동일한 올바른 Linux 패키지를 선택했는지 확인합니다.
    • 다운로드 페이지의 다른 단계를 완료하지 않습니다.
  3. /etc/gitlab/gitlab.rb를 편집하고 내용을 추가합니다:

    # 서버 역할을 'redis_replica_role'로 지정
    roles ['redis_replica_role']
       
    # 다른 머신이 연결할 수 있는 로컬 IP를 가리키는 IP 주소
    # 모든 인터페이스에서 수신 대기하기 위해 bind를 '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
    
  4. 업그레이드 시 자동으로 reconfigure가 실행되는 것을 방지하려면 다음을 실행합니다:

    sudo touch /etc/gitlab/skip-auto-reconfigure
    
  5. 변경 사항이 적용되려면 GitLab을 다시 구성합니다.
  6. 모든 다른 복제본 노드에 대해 다시 한 번 단계를 수행하세요.
note
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 서버가 올바르게 작동하고 복제되고 있는지 확실하지 않다면 복제 문제 해결을 읽고 진행하기 전에 문제를 해결하세요.

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

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

  1. Redis Sentinel을 호스트하는 서버에 SSH로 로그인합니다.
  2. 다른 Redis 인스턴스가 호스트하는 노드와 Sentinels를 호스트하는 노드가 동일한 경우 이 단계를 생략할 수 있습니다.

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

  3. /etc/gitlab/gitlab.rb를 편집하고 다음 내용을 추가합니다(만약 Sentinels을 다른 Redis 인스턴스를 호스트하는 동일한 노드에 설치하는 경우 일부 값은 중복될 수 있습니다):

    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
       
    ## 1. 투표 센티넬 수를 반영해야 합니다. 
    ## 값은 반드시 센티넬 수보다 클 수 없습니다.
    ## 
    ## 센티넬은 두 가지 방법으로 조정할 수 있습니다.
    ## 1. 다수의 센티넬에 비해 투표수가 작게 설정된 경우, 기본적으로 센티넬을 주요 실패에 민감하게 만들어 절반의 센티넬에서 더 이상 주요가 아닌 경우가
    ##    발생하면 장애 조치를 트리거합니다.
    ## 1. 다수의 센티넬에 비해 투표수가 크게 설정된 경우, 센티넬이 매우 많고 상당한 수(ALM)의 잘 연결된 센티넬의 가장자리 다운에 동의하는 경우에만 
    ##    동의하기 때문에 센티넬은 매우 많고 잘 연결된 센티넬의 대부분이 기본 서버가 중단된 것을 인시할 때에만 장애 조치할 수 있습니다.
    sentinel['quorum'] = 2
       
    ## x밀리초 후 무응답 서버를 다운으로 간주
    # sentinel['down_after_milliseconds'] = 10000
       
    ## 밀리초 단위의 장애 조치 제한 시간을 지정합니다. 여러 가지 방법으로 사용됩니다.
    ## - 이전 장애 작업을 이미 시도한 센티넬이 동일한 기본에 대해 장애 조치를 다시 시작하는 데 필요한 시간은 failover 제한시간의 두 배입니다.
    ## - 잘못된 기본에 대한 레플리카 복제시도에는 sentinel이 현재 구성에 따라 잘못된 기본과 복제되기까지 정확히 failover_timeout할 때까지 거릅니다.
    ## - 현재 진행 중인 장애 조치를 취소하는 데 필요한 시간(아직 승격된 복제본이 아닌 REPLICAOF NO ONE을 아직 인정받지 않았지만 이미 시도된 경우).
    ## - 현재 진행 중인 장애 조치가 새로운 기본의 모든 복제본이 새로운 기본의 복제본으로 다시 구성되기를 기다리는 최대 시간. 그러나 이 시간이 지나도
    ##   Sentinels에 의해 복제가 수행되지만 parallel-syncs 진행은 정확하지만 지정된 것과는 약간 다릅니다.
    # sentinel['failover_timeout'] = 60000
    
  4. 업그레이드 시 데이터베이스 마이그레이션을 방지하려면 다음을 실행합니다:

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

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

  5. 변경 사항이 적용되려면 GitLab을 다시 구성합니다.
  6. 모든 다른 Sentinel 노드에 대해 다시 한 번 단계를 수행하세요.

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

마지막으로, 주요 GitLab 애플리케이션 서버에 Redis Sentinel 서버 및 인증 자격 증명을 알리는 것입니다.

설치 바랍니다. redis[‘master_name’] = ‘gitlab-redis’

Example of a minimal configuration with 1 primary, 2 replicas and 3 Sentinels

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

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['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 재구성하여 변경 사항이 적용되도록 합니다.

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

/etc/gitlab/gitlab.rb에서:

redis['master_name'] = 'gitlab-redis'
redis['master_password'] = '여기에 레디스 비밀번호 입력'
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 속도 제한 상태 저장
sessions 세션 저장
repository_cache 리포지터리에 특화된 캐시 데이터 저장

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
       
    # Sentinel 구성
    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-비밀번호-입력-여기'
    # gitlab_rails['redis_queues_sentinels_password'] = 'sentinel-비밀번호-입력-여기'
    # gitlab_rails['redis_shared_state_sentinels_password'] = 'sentinel-비밀번호-입력-여기'
    # gitlab_rails['redis_actioncable_sentinels_password'] = 'sentinel-비밀번호-입력-여기'
    # gitlab_rails['redis_trace_chunks_sentinels_password'] = 'sentinel-비밀번호-입력-여기'
    # gitlab_rails['redis_rate_limiting_sentinels_password'] = 'sentinel-비밀번호-입력-여기'
    # gitlab_rails['redis_sessions_sentinels_password'] = 'sentinel-비밀번호-입력-여기'
    # gitlab_rails['redis_repository_cache_sentinels_password'] = 'sentinel-비밀번호-입력-여기'
    
    • Redis URL은 redis://:PASSWORD@SENTINEL_PRIMARY_NAME 형식이어야 하며:
      • PASSWORD는 Redis 인스턴스의 평문 암호입니다.
      • SENTINEL_PRIMARY_NAMEredis['master_name']으로 설정한 Sentinel 주 이름입니다. 예: gitlab-redis-cache.
  3. 파일을 저장하고 변경 사항이 적용되도록 GitLab을 재구성하세요:

    sudo gitlab-ctl reconfigure
    
note
각 지속 클래스에 대해 GitLab은 변경된 설정에 대한 기본 구성을 사용하며, 이전에 설명한 설정에 의해 재정의되지 않는 한 기본적으로 gitlab_rails['redis_sentinels']을 사용합니다.

실행 중인 서비스 제어

이전 예에서는 redis_sentinel_roleredis_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에서 찾을 수 있습니다.

시작 시 동작 제어하기

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

  1. /etc/gitlab/gitlab.rb 파일을 편집합니다:

    redis['start_down'] = true
    
  2. GitLab을 다시 구성합니다:

    sudo gitlab-ctl reconfigure
    

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

복제 구성 제어하기

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