Redis Sentinel

Sentinel

redis cluster를 사용하지 않는 경우에서 HA를 제공

기본적으로 다음과 같은 기능을 제공

• monitoring : redis master/replica가 잘 동작하고 있는지 모니터링
• notification : redis instance에 이상이 있는 경우 system administrator에게 알림
• automatic failover : redis master가 제대로 동작하지 않는 경우에 sentinal이 failover process를 진행
  • replica instance 중 한 개를 master로 승격
• configuration provider : client에게 redis master에 대한 정보를 제공

sentinel 역시 distributed system으로 동작한다.

• failover system 자체가 단일 장애 지점이 되는 것은 바람직하지 않음

 

fundamental things to know about Sentinel before deploying

• robust deployment를 위해서는 적어도 3개 이상의 sentinel instance가 필요
• 각 sentinel instance는 각 instance 장애에 독립적인 환경이어야 함
• senties + redis가 장애 시에 master에 write된 데이터가 replica에 있음을 보장하지는 않는다.
  • redis는 기본적으로 master/replica 간에 비동기적으로 데이터를 주고 받기 때문

 

configure sentinel

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

sentinel monitor resque 192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000
sentinel failover-timeout resque 180000
sentinel parallel-syncs resque 5

sentinel monitor mymaster 127.0.0.1 6379 2

• sentinel monitor <master-name> <ip> <port> <quorum>
• sentinel이 monitoring할 master node에 대한 정보 지정
  • replica는 monitoring하지 않아도 자동으로 모니터링
• quorum : sentinel instances가 quorum 개수 이상 master node와 연결이 안 되면 장애 발생으로 판단
  • 위와 같이 특정 sentinel instance에서 장애 발생 판단 후, 해당 sentinel instance가 다른 sentinel instance와의 과반 이상이 통신이 되고 있는 상태라면 failover process 진행
    • minority partition에서는 failover를 진행하지 않는다는 의미

sentinel down-after-milliseconds mymaster 60000

• 해당 master에 60000ms 동안 응답이 없는 경우 장애로 판단

sentinel failover-timeout mymaster 180000

• failover process 중 특정 단계에서 18000ms 이상이 걸리는 경우 failover process를 중단

failover_state_change_time을 세팅하는 단계
1단계: 객관적 다운(odown)
2단계: 센티널 리더 선출(elected-leader)
3단계: 슬레이브 선정(selected-slave)
4단계: 선정된 슬레이브 마스터로 승격(promoted-slave)
5단계: 슬레이브들이 새 마스터에서 데이터를 받도록 SLAVEOF 명령 수행(slave-reconf-done)
6단계: 센티널 내 정보 갱신(failover-end, switch-master, update_config)
시간초과(timeout)가 발생해서 취소(abort)되면 각 단계마다 다음과 같은 메시지가 센티널 로그에 남는다.

2단계: 센티널 리더 선출 -> "-failover-abort-not-elected"
3단계: 슬레이브 선정 -> "-failover-abort-no-good-slave"
4단계: 선정된 슬레이브 마스터로 승격 -> "-failover-abort-slave-timeout"
5단계: 슬레이브들이 새 마스터에서 데이터를 받도록 명령 수행 -> "+failover-end-for-timeout"

sentinel parallel-syncs mymaster 1

• failover process에 의해 새로운 master가 승격되었을 때 동시에 나머지 replica와 동기화하는 수
  • 해당 값이 높을수록 동기화 작업이 빨리 끝나지만, 새로운 master로부터 bulk data를 받는 과정에서 block이 되는 순간이 있을 수 있어 성능 상 이슈가 발생할 수 있다.
  • 해당 값이 낮을수록 동기화 작업이 늦게 끝나지만, block이 되는 instance의 수가 적어 성능 상 이슈 발생이 적어진다.

 

Adding or removing sentinel

새로운 sentinel instance를 추가하는 것은 다음과 같다.

• monitoring 하고자하는 redis master를 기준으로 sentinel instance를 띄우면 기존 sentinel과 자동으로 연동된다.
• 여러개를 추가하고자 할 때에는 한 개씩 추가하는 것을 권장

기존 sentinel instance을 삭제하는 것은 꽤 복잡

• 기본적으로 sentinel은 한번 본 다른 sentinel instance를 잊기 않기 때문
• 다음과 같은 과정을 따라야 한다.
  1. 지우고자 하는 sentinel instance의 process를 종료
  2. 나머지 모든 sentinel instance에 SENTINEL RESET * 명령어를 입력
     1. 또는 SENTINEL RESET <master-name> 을 사용해도 된다.