Redis 본가 프로젝트로 개발되고있는 Redis 서버의 사활 감시 / 알림 및 자동 페일 오버 기능을 제공하는 관리 서버 (redis-sentinel)입니다. v2.4.16 또는 2.6.0-rc6 이상 버전에서 사용할 수 있습니다. 공식 문서를 참고로하면서 동작 확인을합니다.
- 환경 : CentOS 5.9 (x86_64), Redis 2.6.10
구성
여기에서는 두 호스트에서 Slave를 2 프로세스 Sentinel 3 프로세스 구성 봅니다.
- Master db0 : 6379
- Slave db0 : 6380, db1 : 6379
- Sentinel db0 : 26379, db0 : 23680, db1 : 26379
설정
/etc/redis/sentinel.conf
# port <sentinel-port>
port 26379
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster db0 6379 2
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down – after – milliseconds mymaster 5000
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover – timeout mymaster 900000
# sentinel can-failover <master-name> <yes | no>
sentinel can – failover mymaster yes
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel – syncs mymaster 1
각 설정 항목 표하고 있습니다. Sentinel 의한 클러스터 모니터는 이른바 Quorum 기반 투표의 방식을 취합니다. 여러 Sentinel이 Master를 감시하고 그중 임계 값보다 많은 Sentinel이 Master 다운을 감지하면 장애 조치 프로세스를 시작합니다.
| 설정 항목 | 개요 |
| monitor | Master 호스트와 포트 및 상태가 ** ODOWN (objectively down) **로 전환하기위한 정족수 (quorum) |
| down-after-milliseconds | Master / Slave 다운 감지 후 상태가 ** SDOWN (subjectively down) **로 전환 될 때까지의 시간 (ms) |
| failover-timeout | 장애 처리 시간 (ms) |
| can-failover | 장애 조치가 실행하거나 (yes / no) |
| parallel-syncs | Slave를 Master로 승격시킨 후, 몇 개의 Slave와 동기화하거나 |
Sentinel은 Master와 Slave 모두의 사활 감시를 해줍니다 만, 상태가 ODOWN로 전환하는 것은 Master만이므로주의하십시오. can-failover를 no로하고 시작한 Sentinel 과정은 장애 조치 자체는 실시하지 않고 (다른 Sentinel에 맡길) 자신은 다운 탐지 및 투표 처리 만합니다.
시작
Sentinel 시작 전에 복제가 작동하는지 확인해야합니다.
redis-cli
redis db0 : 6379> info replication
# Replication
role : master
connected_slaves : 1
slave0 : db0, 6380, online
slave1 : db1, 6379, online
계속 3 개의 Sentinel 프로세스를 시작합니다.
redis-sentinel
$ redis – sentinel / etc / redis / sentinel. conf
## 또는 redis-server를 sentinel 모드로 부팅
$ redis – server / etc / redis / sentinel. conf – sentinel
로그에서 각 Slave 및 Sentinel와 연결 한 것을 확인할 수 있습니다.
[19069] 14 May 16 : 30 : 31.909 * + slave slave db1 : 6379 db1 6379 @ mymaster db0 6379
[19069] 14 May 16 : 30 : 31.909 * + slave slave db0 : 6380 db0 6380 @ mymaster db0 6379
[19069] 14 May 16 : 30 : 38.320 * + sentinel sentinel db0 : 26380 db0 26380 @ mymaster db0 6379
[19069] 14 May 16 : 30 : 39.655 * + sentinel sentinel db1 : 26379 db1 26379 @ mymaster db0 6379
또한 Sentinel 시작 후 INFO 명령 Sentinel 관련 정보를 확인할 수 있습니다.
redis-cli
redis db0 : 26379> info sentinel
# Sentinel
sentinel_masters : 1
sentinel_tilt : 0
sentinel_running_scripts : 0
sentinel_scripts_queue_length : 0
master0 : name = mymaster, status = ok, address = db0 : 6379, slaves = 2, sentinels = 3
Sentinel 과정 자체 모니터링은 아래 항목을 보도록하면 좋을까 생각합니다.
장애 조치 동작 확인을 위해 여기에서 Master를 떨어 뜨립니다.
redis-cli
redis db0 : 6379> shutdown
로그에서 장애 조치 진행 상황을 확인할 수 있습니다.
[19069] 14 May 16 : 30 : 51.170 # + sdown master mymaster db0 6379
[19069] 14 May 16 : 30 : 52.386 # + odown master mymaster db0 6379 #quorum 2/2
[19069] 14 May 16 : 30 : 52.386 # + failover-triggered master mymaster db0 6379
[19069] 14 May 16 : 30 : 52.386 # + failover-state-wait-start master mymaster db0 6379 #starting in 13910 milliseconds
[19069] 14 May 16 : 31 : 06.379 # + failover-state-select-slave master mymaster db0 6379
[19069] 14 May 16 : 31 : 06.480 # + selected-slave slave db1 : 6379 db1 6379 @ mymaster db0 6379
[19069] 14 May 16 : 31 : 06.480 * + failover-state-send-slaveof-noone slave db1 : 6379 db1 6379 @ mymaster db0 6379
[19069] 14 May 16 : 31 : 06.583 * + failover-state-wait-promotion slave db1 : 6379 db1 6379 @ mymaster db0 6379
[19069] 14 May 16 : 31 : 06.901 # + promoted-slave slave db1 : 6379 db1 6379 @ mymaster db0 6379
[19069] 14 May 16 : 31 : 06.902 # + failover-state-reconf-slaves master mymaster db0 6379
[19069] 14 May 16 : 31 : 06.991 * + slave-reconf-sent slave db0 : 6380 db0 6380 @ mymaster db0 6379
[19069] 14 May 16 : 31 : 07.294 * + slave-reconf-inprog slave db0 : 6380 db0 6380 @ mymaster db0 6379
[19069] 14 May 16 : 31 : 08.316 * + slave-reconf-done slave db0 : 6380 db0 6380 @ mymaster db0 6379
[19069] 14 May 16 : 31 : 08.417 # + failover-end master mymaster db0 6379
[19069] 14 May 16 : 31 : 08.417 # + switch-master mymaster db0 6379 db1 6379
[19069] 14 May 16 : 31 : 08.548 * + slave slave db0 : 6380 db0 6380 @ mymaster db1 6379
[19069] 14 May 16 : 31 : 09.068 * + sentinel sentinel db0 : 26380 db0 26380 @ mymaster db1 6379
[19069] 14 May 16 : 31 : 12.258 * + sentinel sentinel db1 : 26379 db1 26379 @ mymaster db1 6379
Sentinel이 Master 다운을 감지하면 상태가 SDOWN에 quorum 파라미터에서 지정한 수의 SDOWN이 맞춰지면 다음은 ODOWN로 전환 후 장애 조치 프로세스가 시작됩니다.
마지막으로 새로운 Master와 Slave에서 제대로 실행되는지 확인합니다.
redis-cli
redis db1 : 6379> info replication
# Replication
role : master
connected_slaves : 1
slave0 : db0, 6380, online
이상 Sentinel 페일 오버 기능이 작동 확인까지 시도했습니다.
Sentinel API
Sentinel 몇 가지 API를 제공하고 있기 때문에 쉽게 소개하고 싶습니다.
redis-cli
## SENTINEL masters
# 감시 대상의 Master 정보 확인
redis 127.0 0.1 : 26379> sentinel masters
1) 1) “name”
2) “mymaster”
3) “ip”
4) “127.0.0.1”
5) “port”
6) “6379”
7) “runid”
8) “b3b31e6c6d1fbb0cec5d179fd666ce00ea103746”
9) “flags”
10) “master”
11) “pending-commands”
12) “0”
13) “last-ok-ping-reply”
14) “568”
15) “last-ping-reply”
16) “568”
17) “info-refresh”
18) “9745”
19) “num-slaves”
20) “1”
21) “num-other-sentinels”
22) “1”
23) “quorum”
24) “2”
## SENTINEL slaves <master name>
# Slave 정보 확인
redis 127.0 0.1 : 26379> sentinel slaves mymaster
1) 1) “name”
2) “127.0.0.1:6380”
3) “ip”
4) “127.0.0.1”
5) “port”
6) “6380”
7) “runid”
8) “17c0f7e7e4d2af0f5f6140ea0ceb0d82d0010aed”
9) “flags”
10) “s_down, slave, disconnected”
11) “pending-commands”
12) “0”
13) “last-ok-ping-reply”
14) “709377”
15) “last-ping-reply”
16) “709377”
17) “s-down-time”
18) “704333”
19) “info-refresh”
20) “712808”
21) “master-link-down-time”
22) “0”
23) “master-link-status”
24) “ok”
25) “master-host”
26) “127.0.0.1”
27) “master-port”
28) “6379”
29) “slave-priority”
30) “100”
## SENTINEL is-master-down-by-addr <ip> <port>
# Master의 사활 확인
redis 127.0 0.1 : 26379> sentinel is – master – down – by – addr 127.0 0.1 6379
1) (integer) 0 ## 0 : UP 1 : DOWN
2) “397dec99760d5d30043941fe4c1c35ba99e99ebf”## Sentinel (subjective leader)의 run_id
## SENTINEL get-master-addr-by-name <master name>
# Master의 IP, Port를 확인
redis 127.0 0.1 : 26379> sentinel get – master – addr – by – name mymaster
1) “127.0.0.1”
2) “6379”
## SENTINEL reset
# Sentinel의 현재 상태를 재설정 (장애 조치 중에라도)
redis 127.0 0.1 : 26379> sentinel reset mymaster
(integer) 1
Sentinel 관련 관리 도구를 만들 때이 Sentinel API를 지원하는 클라이언트 라이브러리를 사용하면 쉽게 아닐까 생각합니다.
이하, 장애 복구 프로세스의 거동에 관한 부분을 픽업하여 소개합니다.
승격 Slave의 선택
당연 합니다만 Slave로 성공적으로 실행하는 프로세스가 적용됩니다. 세세한 조건을 생략하고 싹둑 말하면, Master와의 연결이 안정하고 (다운 타임이 적은) Sentinel에서 PING / INFO 명령에 최근 5000ms 이내에 응답하는 Slave가 대상이됩니다 (자세한 내용은 공식 문서와 src / sentinel.c 참조).
대상이되는 Slave가 여러 개있는 경우 slave_priority 값이 작은 Slave를 선택합니다.
redis-cli
redis db0 : 6380> info replication
# Replication
role : slave
master_host : 127.0 0.1
master_port : 6379
master_link_status : up
master_last_io_seconds_ago : 0
master_sync_in_progress : 0
slave_priority : 100 ## <-이 값
slave_read_only : 1
connected_slaves : 0
같은 slave_priority의 Slave가 있으면 run_id 작은 Slave를 선택합니다.
redis-cli
redis db0 : 6380> info
# Server
redis_version : 2.6. 10
redis_git_sha1 : 00000000
redis_git_dirty : 0
redis_mode : standalone
os : Linux 2.6 18 – 194.26 1. el5 x86_64
arch_bits : 64
multiplexing_api : epoll
gcc_version : 4.1. 2
process_id : 17468
run_id : 17 c0f7e7e4d2af0f5f6140ea0ceb0d82d0010aed ## <-이 값
tcp_port : 6380
uptime_in_seconds : 1738
uptime_in_days : 0
lru_clock : 538965
2013/06 현재는 slave_priority을 변경할 API는 공개되지 않은 것이므로 단순히 run_id 젊은 Slave가 선택되게됩니다. Slave 선택 알고리즘은 향후 변경 될 수도있을 것입니다.
Sentinels / Slaves 자동 감지
Sentinel 설정에 Slave의 목록을 갖게 할 필요가없는 것은 Sentinel이 Pub / Sub 의한 정보 공유를하고 있기 때문입니다. 중간에 다른 Sentinel와 Slave를 온라인으로 추가해도 다른 Sentinel 그 정보는 전해집니다.
redis-cli
## Sentinel은 “__sentinel __ : hello”채널을 이용하고있다
redis db0 : 6379> subscribe __sentinel__ : hello
Reading messages … (press Ctrl – C to quit)
1) “subscribe”
2) “__sentinel __ : hello”
3) (integer) 1
1) “message”
2) “__sentinel __ : hello”
3) “127.0.0.1:26380:77887a367e1c76ee9dc15f67a2fb3dc49bb00bf4:1”
1) “message”
2) “__sentinel __ : hello”
3) “127.0.0.1:26379:3a92da7269b69fa1dcce5915068c4af6e8caf161:1”
1) “message”
2) “__sentinel __ : hello”
3) “127.0.0.1:26380:77887a367e1c76ee9dc15f67a2fb3dc49bb00bf4:1”
1) “message”
2) “__sentinel __ : hello”
3) “127.0.0.1:26379:3a92da7269b69fa1dcce5915068c4af6e8caf161:1”
메시지의 내용은 host : port : run_id : can-failover가있어 __ sentinel __ : hello 채널에 5 초마다 publish 모든 Sentinel은이 채널을 subscribe하여 정보 공유하고 있습니다.
