InfoGrab Docs

자체 인스턴스를 사용하는 Redis 복제 및 장애 조치

요약

클라우드 공급자에서 GitLab을 호스팅하는 경우, 선택적으로 Redis용 관리형 서비스를 사용할 수 있습니다. 또는 Linux 패키지와 별도로 자체 Redis 인스턴스를 관리하도록 선택할 수도 있습니다. 자체 Redis 인스턴스를 제공하기 위한 요구 사항은 다음과 같습니다:

클라우드 공급자에서 GitLab을 호스팅하는 경우, 선택적으로 Redis용 관리형 서비스를 사용할 수 있습니다. 예를 들어 AWS는 Redis를 실행하는 ElastiCache를 제공합니다.

또는 Linux 패키지와 별도로 자체 Redis 인스턴스를 관리하도록 선택할 수도 있습니다.

요구 사항#

자체 Redis 인스턴스를 제공하기 위한 요구 사항은 다음과 같습니다:

  • 요구 사항 페이지에서 필요한 최소 Redis 버전을 확인합니다.
  • 독립형 Redis 또는 Sentinel을 사용한 Redis 고가용성이 지원됩니다. Redis Cluster는 지원되지 않습니다.
  • AWS ElastiCache와 같은 클라우드 공급자의 관리형 Redis는 정상 작동합니다. 이러한 서비스가 고가용성을 지원하는 경우 Redis Cluster 유형이 아닌지 확인하세요.

Redis 노드의 IP 주소 또는 호스트명, 포트 및 비밀번호(필요한 경우)를 기록해 두세요.

클라우드 공급자의 관리형 서비스로서의 Redis#

  1. 요구 사항에 따라 Redis를 설정합니다.

  2. /etc/gitlab/gitlab.rb 파일에서 외부 Redis 서비스에 대한 적절한 연결 세부 정보로 GitLab 애플리케이션 서버를 구성합니다:

    단일 Redis 인스턴스를 사용하는 경우:

    redis['enable'] = false
    
    gitlab_rails['redis_host'] = '<redis_instance_url>'
    gitlab_rails['redis_port'] = '<redis_instance_port>'
    
    # Required if Redis authentication is configured on the Redis node
    gitlab_rails['redis_password'] = '<redis_password>'
    
    # Set to true if instance is using Redis SSL
    gitlab_rails['redis_ssl'] = true
    

    별도의 Redis 캐시 및 영구 인스턴스를 사용하는 경우:

    redis['enable'] = false
    
    # Default Redis connection
    gitlab_rails['redis_host'] = '<redis_persistent_instance_url>'
    gitlab_rails['redis_port'] = '<redis_persistent_instance_port>'
    gitlab_rails['redis_password'] = '<redis_persistent_password>'
    
    # Set to true if instance is using Redis SSL
    gitlab_rails['redis_ssl'] = true
    
    # Redis Cache connection
    # Replace `redis://` with `rediss://` if using SSL
    gitlab_rails['redis_cache_instance'] = 'redis://:<redis_cache_password>@<redis_cache_instance_url>:<redis_cache_instance_port>'
    
  3. 변경 사항을 적용하려면 재구성합니다:

    sudo gitlab-ctl reconfigure
    

축출 정책 설정#

단일 Redis 인스턴스를 실행하는 경우 축출 정책은 noeviction으로 설정해야 합니다.

별도의 Redis 캐시 및 영구 인스턴스를 실행하는 경우, 캐시는 allkeys-lru를 사용하는 LRU(Least Recently Used) 캐시로 구성하고 영구 인스턴스는 noeviction으로 설정해야 합니다.

이 설정은 클라우드 공급자 또는 서비스에 따라 다르지만 일반적으로 다음 설정과 값이 캐시를 구성합니다:

  • maxmemory-policy = allkeys-lru
  • maxmemory-samples = 5

자체 Redis 서버를 사용한 Redis 복제 및 장애 조치#

이것은 Linux 패키지에 포함된 것을 사용하지 않고 직접 Redis를 설치한 경우 확장 가능한 Redis 설정을 구성하기 위한 문서입니다. 단, GitLab에 맞게 최적화되고 최신 지원 버전으로 업그레이드를 담당하므로 Linux 패키지 사용을 강력히 권장합니다.

또한 구성 파일 문서에 설명된 고급 Redis 설정에 따라 /home/git/gitlab/config/resque.yml에 대한 모든 참조를 재정의하도록 선택할 수도 있습니다.

Redis HA 구성에 매우 중요한 정보를 제공하는 Linux 패키지 Redis의 복제 및 장애 조치 문서를 아무리 강조해도 부족합니다. 이 가이드를 진행하기 전에 반드시 읽어보세요.

새 Redis 인스턴스를 설정하기 전에 다음 요구 사항이 있습니다:

  • 이 가이드의 모든 Redis 서버는 소켓 대신 TCP 연결을 사용하도록 구성해야 합니다. TCP 연결을 사용하도록 Redis를 구성하려면 Redis 구성 파일에서 bindport를 모두 정의해야 합니다. 모든 인터페이스(0.0.0.0)에 바인딩하거나 원하는 인터페이스의 IP를 지정할 수 있습니다(예: 내부 네트워크에서의 IP).
  • Redis 3.2부터는 외부 연결을 받으려면 비밀번호를 정의해야 합니다(requirepass).
  • Redis를 Sentinel과 함께 사용하는 경우 동일한 인스턴스에서 복제본 비밀번호 정의(masterauth)에도 동일한 비밀번호를 정의해야 합니다.

또한 Linux 패키지를 사용한 Redis 복제 및 장애 조치에 설명된 사전 요구 사항을 읽어보세요.

Step 1. 기본 Redis 인스턴스 구성#

Redis 기본 인스턴스 IP가 10.0.0.1이라고 가정합니다:

  1. Redis를 설치합니다.

  2. /etc/redis/redis.conf를 편집합니다:

    ## Define a `bind` address pointing to a local IP that your other machines
    ## can reach you. If you really need to bind to an external accessible IP, make
    ## sure you add extra firewall rules to prevent unauthorized access:
    bind 10.0.0.1
    
    ## Define a `port` to force redis to listen on TCP so other machines can
    ## connect to it (default port is `6379`).
    port 6379
    
    ## Set up password authentication (use the same password in all nodes).
    ## The password should be defined equal for both `requirepass` and `masterauth`
    ## when setting up Redis to use with Sentinel.
    requirepass redis-password-goes-here
    masterauth redis-password-goes-here
    
  3. Redis 서비스를 재시작하여 변경 사항을 적용합니다.

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

Redis 복제본 인스턴스 IP가 10.0.0.2라고 가정합니다:

  1. Redis를 설치합니다.

  2. /etc/redis/redis.conf를 편집합니다:

    ## Define a `bind` address pointing to a local IP that your other machines
    ## can reach you. If you really need to bind to an external accessible IP, make
    ## sure you add extra firewall rules to prevent unauthorized access:
    bind 10.0.0.2
    
    ## Define a `port` to force redis to listen on TCP so other machines can
    ## connect to it (default port is `6379`).
    port 6379
    
    ## Set up password authentication (use the same password in all nodes).
    ## The password should be defined equal for both `requirepass` and `masterauth`
    ## when setting up Redis to use with Sentinel.
    requirepass redis-password-goes-here
    masterauth redis-password-goes-here
    
    ## Define `replicaof` pointing to the Redis primary instance with IP and port.
    replicaof 10.0.0.1 6379
    
  3. Redis 서비스를 재시작하여 변경 사항을 적용합니다.

  4. 다른 복제본 노드들에 대해 동일한 단계를 반복합니다.

Step 3. Redis Sentinel 인스턴스 구성#

Sentinel은 특수한 유형의 Redis 서버입니다. redis.conf에서 정의할 수 있는 대부분의 기본 구성 옵션을 상속하며, sentinel 접두사로 시작하는 특정 옵션이 있습니다.

Redis Sentinel이 IP 10.0.0.1인 Redis 기본 인스턴스와 동일한 인스턴스에 설치되어 있다고 가정합니다(일부 설정이 기본 인스턴스와 겹칠 수 있음):

  1. Redis Sentinel을 설치합니다.

  2. /etc/redis/sentinel.conf를 편집합니다:

    ## Define a `bind` address pointing to a local IP that your other machines
    ## can reach you. If you really need to bind to an external accessible IP, make
    ## sure you add extra firewall rules to prevent unauthorized access:
    bind 10.0.0.1
    
    ## Define a `port` to force Sentinel to listen on TCP so other machines can
    ## connect to it (default port is `6379`).
    port 26379
    
    ## Set up password authentication (use the same password in all nodes).
    ## The password should be defined equal for both `requirepass` and `masterauth`
    ## when setting up Redis to use with Sentinel.
    requirepass redis-password-goes-here
    masterauth redis-password-goes-here
    
    ## Define with `sentinel auth-pass` the same shared password you have
    ## defined for both Redis primary and replicas instances.
    sentinel auth-pass gitlab-redis redis-password-goes-here
    
    ## Define with `sentinel monitor` the IP and port of the Redis
    ## primary node, and the quorum required to start a failover.
    sentinel monitor gitlab-redis 10.0.0.1 6379 2
    
    ## Define with `sentinel down-after-milliseconds` the time in `ms`
    ## that an unresponsive server is considered down.
    sentinel down-after-milliseconds gitlab-redis 10000
    
    ## Define a value for `sentinel failover_timeout` in `ms`. This has multiple
    ## meanings:
    ##
    ## * 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 replicas 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 30000
    
  3. Redis 서비스를 재시작하여 변경 사항을 적용합니다.

  4. 다른 Sentinel 노드들에 대해 동일한 단계를 반복합니다.

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

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

모든 Sentinel 노드의 목록이 필요하지는 않지만, 장애 발생 시 나열된 노드 중 하나 이상에 액세스할 수 있어야 합니다.

다음 단계는 GitLab 애플리케이션 서버에서 수행해야 하며, 이상적으로는 Redis나 Sentinel이 동일한 머신에 없어야 합니다:

  1. resque.yml.example의 예를 따라 /home/git/gitlab/config/resque.yml을 편집하고, Sentinel 줄의 주석을 해제하여 올바른 서버 자격 증명을 지정합니다:

    # resque.yaml
    production:
      url: redis://:redis-password-goes-here@gitlab-redis/
      sentinels:
        -
          host: 10.0.0.1
          port: 26379  # point to sentinel, not to redis port
        -
          host: 10.0.0.2
          port: 26379  # point to sentinel, not to redis port
        -
          host: 10.0.0.3
          port: 26379  # point to sentinel, not to redis port
    
  2. 변경 사항을 적용하려면 GitLab을 재시작합니다.

기본 1개, 복제본 2개, Sentinel 3개로 구성된 최소 구성 예시#

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

실제 환경에서는 다른 머신의 무단 액세스를 방지하고 외부(인터넷)의 트래픽을 차단하는 방화벽 규칙도 설정해야 합니다.

이 예시에서 Sentinel 1Redis 기본 머신과 같은 머신에 구성되고, Sentinel 2복제본 1과 같은 머신에, Sentinel 3복제본 2와 같은 머신에 구성됩니다.

머신과 할당된 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 구성 예시#

  1. /etc/redis/redis.conf에서:

    bind 10.0.0.1
    port 6379
    requirepass redis-password-goes-here
    masterauth redis-password-goes-here
    
  2. /etc/redis/sentinel.conf에서:

    bind 10.0.0.1
    port 26379
    sentinel auth-pass gitlab-redis redis-password-goes-here
    sentinel monitor gitlab-redis 10.0.0.1 6379 2
    sentinel down-after-milliseconds gitlab-redis 10000
    sentinel failover_timeout 30000
    
  3. Redis 서비스를 재시작하여 변경 사항을 적용합니다.

Redis 복제본 1 및 Sentinel 2 구성 예시#

  1. /etc/redis/redis.conf에서:

    bind 10.0.0.2
    port 6379
    requirepass redis-password-goes-here
    masterauth redis-password-goes-here
    replicaof 10.0.0.1 6379
    
  2. /etc/redis/sentinel.conf에서:

    bind 10.0.0.2
    port 26379
    sentinel auth-pass gitlab-redis redis-password-goes-here
    sentinel monitor gitlab-redis 10.0.0.1 6379 2
    sentinel down-after-milliseconds gitlab-redis 10000
    sentinel failover_timeout 30000
    
  3. Redis 서비스를 재시작하여 변경 사항을 적용합니다.

Redis 복제본 2 및 Sentinel 3 구성 예시#

  1. /etc/redis/redis.conf에서:

    bind 10.0.0.3
    port 6379
    requirepass redis-password-goes-here
    masterauth redis-password-goes-here
    replicaof 10.0.0.1 6379
    
  2. /etc/redis/sentinel.conf에서:

    bind 10.0.0.3
    port 26379
    sentinel auth-pass gitlab-redis redis-password-goes-here
    sentinel monitor gitlab-redis 10.0.0.1 6379 2
    sentinel down-after-milliseconds gitlab-redis 10000
    sentinel failover_timeout 30000
    
  3. Redis 서비스를 재시작하여 변경 사항을 적용합니다.

GitLab 애플리케이션 구성 예시#

  1. /home/git/gitlab/config/resque.yml을 편집합니다:

    production:
      url: redis://:redis-password-goes-here@gitlab-redis/
      sentinels:
        -
          host: 10.0.0.1
          port: 26379  # point to sentinel, not to redis port
        -
          host: 10.0.0.2
          port: 26379  # point to sentinel, not to redis port
        -
          host: 10.0.0.3
          port: 26379  # point to sentinel, not to redis port
    
  2. 변경 사항을 적용하려면 GitLab을 재시작합니다.

문제 해결#

Redis 문제 해결 가이드를 참조하세요.

자체 인스턴스를 사용하는 Redis 복제 및 장애 조치

Tier: Free, Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기
요약

클라우드 공급자에서 GitLab을 호스팅하는 경우, 선택적으로 Redis용 관리형 서비스를 사용할 수 있습니다. 또는 Linux 패키지와 별도로 자체 Redis 인스턴스를 관리하도록 선택할 수도 있습니다. 자체 Redis 인스턴스를 제공하기 위한 요구 사항은 다음과 같습니다:

클라우드 공급자에서 GitLab을 호스팅하는 경우, 선택적으로 Redis용 관리형 서비스를 사용할 수 있습니다. 예를 들어 AWS는 Redis를 실행하는 ElastiCache를 제공합니다.

또는 Linux 패키지와 별도로 자체 Redis 인스턴스를 관리하도록 선택할 수도 있습니다.

요구 사항#

자체 Redis 인스턴스를 제공하기 위한 요구 사항은 다음과 같습니다:

  • 요구 사항 페이지에서 필요한 최소 Redis 버전을 확인합니다.
  • 독립형 Redis 또는 Sentinel을 사용한 Redis 고가용성이 지원됩니다. Redis Cluster는 지원되지 않습니다.
  • AWS ElastiCache와 같은 클라우드 공급자의 관리형 Redis는 정상 작동합니다. 이러한 서비스가 고가용성을 지원하는 경우 Redis Cluster 유형이 아닌지 확인하세요.

Redis 노드의 IP 주소 또는 호스트명, 포트 및 비밀번호(필요한 경우)를 기록해 두세요.

클라우드 공급자의 관리형 서비스로서의 Redis#

  1. 요구 사항에 따라 Redis를 설정합니다.

  2. /etc/gitlab/gitlab.rb 파일에서 외부 Redis 서비스에 대한 적절한 연결 세부 정보로 GitLab 애플리케이션 서버를 구성합니다:

    단일 Redis 인스턴스를 사용하는 경우:

    redis['enable'] = false
    
    gitlab_rails['redis_host'] = '<redis_instance_url>'
    gitlab_rails['redis_port'] = '<redis_instance_port>'
    
    # Required if Redis authentication is configured on the Redis node
    gitlab_rails['redis_password'] = '<redis_password>'
    
    # Set to true if instance is using Redis SSL
    gitlab_rails['redis_ssl'] = true
    

    별도의 Redis 캐시 및 영구 인스턴스를 사용하는 경우:

    redis['enable'] = false
    
    # Default Redis connection
    gitlab_rails['redis_host'] = '<redis_persistent_instance_url>'
    gitlab_rails['redis_port'] = '<redis_persistent_instance_port>'
    gitlab_rails['redis_password'] = '<redis_persistent_password>'
    
    # Set to true if instance is using Redis SSL
    gitlab_rails['redis_ssl'] = true
    
    # Redis Cache connection
    # Replace `redis://` with `rediss://` if using SSL
    gitlab_rails['redis_cache_instance'] = 'redis://:<redis_cache_password>@<redis_cache_instance_url>:<redis_cache_instance_port>'
    
  3. 변경 사항을 적용하려면 재구성합니다:

    sudo gitlab-ctl reconfigure
    

축출 정책 설정#

단일 Redis 인스턴스를 실행하는 경우 축출 정책은 noeviction으로 설정해야 합니다.

별도의 Redis 캐시 및 영구 인스턴스를 실행하는 경우, 캐시는 allkeys-lru를 사용하는 LRU(Least Recently Used) 캐시로 구성하고 영구 인스턴스는 noeviction으로 설정해야 합니다.

이 설정은 클라우드 공급자 또는 서비스에 따라 다르지만 일반적으로 다음 설정과 값이 캐시를 구성합니다:

  • maxmemory-policy = allkeys-lru
  • maxmemory-samples = 5

자체 Redis 서버를 사용한 Redis 복제 및 장애 조치#

이것은 Linux 패키지에 포함된 것을 사용하지 않고 직접 Redis를 설치한 경우 확장 가능한 Redis 설정을 구성하기 위한 문서입니다. 단, GitLab에 맞게 최적화되고 최신 지원 버전으로 업그레이드를 담당하므로 Linux 패키지 사용을 강력히 권장합니다.

또한 구성 파일 문서에 설명된 고급 Redis 설정에 따라 /home/git/gitlab/config/resque.yml에 대한 모든 참조를 재정의하도록 선택할 수도 있습니다.

Redis HA 구성에 매우 중요한 정보를 제공하는 Linux 패키지 Redis의 복제 및 장애 조치 문서를 아무리 강조해도 부족합니다. 이 가이드를 진행하기 전에 반드시 읽어보세요.

새 Redis 인스턴스를 설정하기 전에 다음 요구 사항이 있습니다:

  • 이 가이드의 모든 Redis 서버는 소켓 대신 TCP 연결을 사용하도록 구성해야 합니다. TCP 연결을 사용하도록 Redis를 구성하려면 Redis 구성 파일에서 bindport를 모두 정의해야 합니다. 모든 인터페이스(0.0.0.0)에 바인딩하거나 원하는 인터페이스의 IP를 지정할 수 있습니다(예: 내부 네트워크에서의 IP).
  • Redis 3.2부터는 외부 연결을 받으려면 비밀번호를 정의해야 합니다(requirepass).
  • Redis를 Sentinel과 함께 사용하는 경우 동일한 인스턴스에서 복제본 비밀번호 정의(masterauth)에도 동일한 비밀번호를 정의해야 합니다.

또한 Linux 패키지를 사용한 Redis 복제 및 장애 조치에 설명된 사전 요구 사항을 읽어보세요.

Step 1. 기본 Redis 인스턴스 구성#

Redis 기본 인스턴스 IP가 10.0.0.1이라고 가정합니다:

  1. Redis를 설치합니다.

  2. /etc/redis/redis.conf를 편집합니다:

    ## Define a `bind` address pointing to a local IP that your other machines
    ## can reach you. If you really need to bind to an external accessible IP, make
    ## sure you add extra firewall rules to prevent unauthorized access:
    bind 10.0.0.1
    
    ## Define a `port` to force redis to listen on TCP so other machines can
    ## connect to it (default port is `6379`).
    port 6379
    
    ## Set up password authentication (use the same password in all nodes).
    ## The password should be defined equal for both `requirepass` and `masterauth`
    ## when setting up Redis to use with Sentinel.
    requirepass redis-password-goes-here
    masterauth redis-password-goes-here
    
  3. Redis 서비스를 재시작하여 변경 사항을 적용합니다.

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

Redis 복제본 인스턴스 IP가 10.0.0.2라고 가정합니다:

  1. Redis를 설치합니다.

  2. /etc/redis/redis.conf를 편집합니다:

    ## Define a `bind` address pointing to a local IP that your other machines
    ## can reach you. If you really need to bind to an external accessible IP, make
    ## sure you add extra firewall rules to prevent unauthorized access:
    bind 10.0.0.2
    
    ## Define a `port` to force redis to listen on TCP so other machines can
    ## connect to it (default port is `6379`).
    port 6379
    
    ## Set up password authentication (use the same password in all nodes).
    ## The password should be defined equal for both `requirepass` and `masterauth`
    ## when setting up Redis to use with Sentinel.
    requirepass redis-password-goes-here
    masterauth redis-password-goes-here
    
    ## Define `replicaof` pointing to the Redis primary instance with IP and port.
    replicaof 10.0.0.1 6379
    
  3. Redis 서비스를 재시작하여 변경 사항을 적용합니다.

  4. 다른 복제본 노드들에 대해 동일한 단계를 반복합니다.

Step 3. Redis Sentinel 인스턴스 구성#

Sentinel은 특수한 유형의 Redis 서버입니다. redis.conf에서 정의할 수 있는 대부분의 기본 구성 옵션을 상속하며, sentinel 접두사로 시작하는 특정 옵션이 있습니다.

Redis Sentinel이 IP 10.0.0.1인 Redis 기본 인스턴스와 동일한 인스턴스에 설치되어 있다고 가정합니다(일부 설정이 기본 인스턴스와 겹칠 수 있음):

  1. Redis Sentinel을 설치합니다.

  2. /etc/redis/sentinel.conf를 편집합니다:

    ## Define a `bind` address pointing to a local IP that your other machines
    ## can reach you. If you really need to bind to an external accessible IP, make
    ## sure you add extra firewall rules to prevent unauthorized access:
    bind 10.0.0.1
    
    ## Define a `port` to force Sentinel to listen on TCP so other machines can
    ## connect to it (default port is `6379`).
    port 26379
    
    ## Set up password authentication (use the same password in all nodes).
    ## The password should be defined equal for both `requirepass` and `masterauth`
    ## when setting up Redis to use with Sentinel.
    requirepass redis-password-goes-here
    masterauth redis-password-goes-here
    
    ## Define with `sentinel auth-pass` the same shared password you have
    ## defined for both Redis primary and replicas instances.
    sentinel auth-pass gitlab-redis redis-password-goes-here
    
    ## Define with `sentinel monitor` the IP and port of the Redis
    ## primary node, and the quorum required to start a failover.
    sentinel monitor gitlab-redis 10.0.0.1 6379 2
    
    ## Define with `sentinel down-after-milliseconds` the time in `ms`
    ## that an unresponsive server is considered down.
    sentinel down-after-milliseconds gitlab-redis 10000
    
    ## Define a value for `sentinel failover_timeout` in `ms`. This has multiple
    ## meanings:
    ##
    ## * 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 replicas 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 30000
    
  3. Redis 서비스를 재시작하여 변경 사항을 적용합니다.

  4. 다른 Sentinel 노드들에 대해 동일한 단계를 반복합니다.

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

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

모든 Sentinel 노드의 목록이 필요하지는 않지만, 장애 발생 시 나열된 노드 중 하나 이상에 액세스할 수 있어야 합니다.

다음 단계는 GitLab 애플리케이션 서버에서 수행해야 하며, 이상적으로는 Redis나 Sentinel이 동일한 머신에 없어야 합니다:

  1. resque.yml.example의 예를 따라 /home/git/gitlab/config/resque.yml을 편집하고, Sentinel 줄의 주석을 해제하여 올바른 서버 자격 증명을 지정합니다:

    # resque.yaml
    production:
      url: redis://:redis-password-goes-here@gitlab-redis/
      sentinels:
        -
          host: 10.0.0.1
          port: 26379  # point to sentinel, not to redis port
        -
          host: 10.0.0.2
          port: 26379  # point to sentinel, not to redis port
        -
          host: 10.0.0.3
          port: 26379  # point to sentinel, not to redis port
    
  2. 변경 사항을 적용하려면 GitLab을 재시작합니다.

기본 1개, 복제본 2개, Sentinel 3개로 구성된 최소 구성 예시#

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

실제 환경에서는 다른 머신의 무단 액세스를 방지하고 외부(인터넷)의 트래픽을 차단하는 방화벽 규칙도 설정해야 합니다.

이 예시에서 Sentinel 1Redis 기본 머신과 같은 머신에 구성되고, Sentinel 2복제본 1과 같은 머신에, Sentinel 3복제본 2와 같은 머신에 구성됩니다.

머신과 할당된 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 구성 예시#

  1. /etc/redis/redis.conf에서:

    bind 10.0.0.1
    port 6379
    requirepass redis-password-goes-here
    masterauth redis-password-goes-here
    
  2. /etc/redis/sentinel.conf에서:

    bind 10.0.0.1
    port 26379
    sentinel auth-pass gitlab-redis redis-password-goes-here
    sentinel monitor gitlab-redis 10.0.0.1 6379 2
    sentinel down-after-milliseconds gitlab-redis 10000
    sentinel failover_timeout 30000
    
  3. Redis 서비스를 재시작하여 변경 사항을 적용합니다.

Redis 복제본 1 및 Sentinel 2 구성 예시#

  1. /etc/redis/redis.conf에서:

    bind 10.0.0.2
    port 6379
    requirepass redis-password-goes-here
    masterauth redis-password-goes-here
    replicaof 10.0.0.1 6379
    
  2. /etc/redis/sentinel.conf에서:

    bind 10.0.0.2
    port 26379
    sentinel auth-pass gitlab-redis redis-password-goes-here
    sentinel monitor gitlab-redis 10.0.0.1 6379 2
    sentinel down-after-milliseconds gitlab-redis 10000
    sentinel failover_timeout 30000
    
  3. Redis 서비스를 재시작하여 변경 사항을 적용합니다.

Redis 복제본 2 및 Sentinel 3 구성 예시#

  1. /etc/redis/redis.conf에서:

    bind 10.0.0.3
    port 6379
    requirepass redis-password-goes-here
    masterauth redis-password-goes-here
    replicaof 10.0.0.1 6379
    
  2. /etc/redis/sentinel.conf에서:

    bind 10.0.0.3
    port 26379
    sentinel auth-pass gitlab-redis redis-password-goes-here
    sentinel monitor gitlab-redis 10.0.0.1 6379 2
    sentinel down-after-milliseconds gitlab-redis 10000
    sentinel failover_timeout 30000
    
  3. Redis 서비스를 재시작하여 변경 사항을 적용합니다.

GitLab 애플리케이션 구성 예시#

  1. /home/git/gitlab/config/resque.yml을 편집합니다:

    production:
      url: redis://:redis-password-goes-here@gitlab-redis/
      sentinels:
        -
          host: 10.0.0.1
          port: 26379  # point to sentinel, not to redis port
        -
          host: 10.0.0.2
          port: 26379  # point to sentinel, not to redis port
        -
          host: 10.0.0.3
          port: 26379  # point to sentinel, not to redis port
    
  2. 변경 사항을 적용하려면 GitLab을 재시작합니다.

문제 해결#

Redis 문제 해결 가이드를 참조하세요.