Once in a Lifetime

03. Redis - 센티넬(Sentinel) 구성 본문

Develope Diary

03. Redis - 센티넬(Sentinel) 구성

riceworld 2016. 2. 13. 09:43

지난 포스트에서 우리는 Master 1대와 이를 미러링하고 복제하는 Slave 2대를 구성하였습니다.


그런데, 만약 Master 가 예기치 않게 종료되거나, 서버가 다운되었을 경우 Slave 가 Failover 하여 마스터를 대체하는 구성하기 위하여 Redis 에서 제공하는 Sentinel 을 설정해 보도록 하겠습니다.


앞선 포스트에서 구성도를 참조하여 우리는 3대의 Sentinel 을 설치하여 Redis 서버를 감시하는 구성으로 합니다. 

Sentinel 은 별도의 물리적인 서버에 설치하여 감시토록 해도 되지만, Redis 가 설치된 3대의 서버에 Sentinel 을 설치해서 비용을 절감해 봅니다.


Sentinel 은 Master 서버의 장애판단을 위해서 리더를 두고 투표하여 다수결의 원칙에 따라 장애판단을 하기 때문에 가급적 홀수대로 구성하는 것이 좋습니다. Sentinel 이 Master 서버를 감시중에 연결 상태가 끊어짐을 확인했을 경우 각각의 Sentinel 은 SDown (Subjective Down - 주관적 다운) 으로 판단하고 다른 Sentinel 서버의 투표 결과 (Quorum) 에 따라 ODown (Objective Down - 객관적 다운) 처리 후 Failover 를 하게 됩니다. ODown 으로 판명되면 Sentinel 은 Slave 중 한대를 Master 로 승격처리 하며, Failover 를 완료하게 됩니다.


Sentinel 은 Redis 서버 설치시에 이미 함께 설치되었으므로 별도의 설치과정은 필요치 않습니다.


Sentinel 구성을 위한 설정파일을 편집합니다.

nano /etc/redis-sentinel.conf



- 센티넬 포트 설정 (본 포스트에서는 8000, 8001, 8002 로 구성합니다.)

port 8000


- 감시할 Redis Master 서버

- [mymaster-별칭] [xxx.xxx.xx.xxx-마스터 서버 IP] [6379-포트] [2-ODown 판단을 위한 투표수(Sentinel 수 - 1)]

sentinel monitor mymaster xxx.xxx.xx.xxx 6379 2


- SDown 판단 기준 (밀리초)

sentinel down-after-milliseconds mymaster 5000


- FailOver시 병렬 싱크 수 (Slave 몇대가 동시에 Sync 할 것인지...일반적으로 1대씩)

sentinel parallel-syncs mymaster 1


- FailOver 타임아웃 (밀리초)

sentinel failover-timeout mymaster 180000


- Master 패스워드 설정 (본 포스트에서 Failover 를 위해 Master/Slave 모두 동일한 패스워드)

sentinel auth-pass mymaster mypassword


Sentinel 서비스 실행 및 등록

systemctl start redis-sentinel.service

systemctl enable redis-sentinel.service


3대의 Sentinel 서버 모두 설정파일 구성을 완료하고 Sentinel 서비스가 기동중이라면, 이제 Sentinel 이 제대로 동작하는지 검증해 보도록 하겠습니다. 먼저 Sentinel 이 제대로 동작중인지 log 파일을 확인해 봅니다.


cat /var/log/redis/sentinel.log


                 _._

           _.-``__ ''-._

      _.-``    `.  `_.  ''-._           Redis 2.8.19 (00000000/0) 64 bit

  .-`` .-```.  ```\/    _.,_ ''-._

 (    '      ,       .-`  | `,    )     Running in sentinel mode

 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 8001

 |    `-._   `._    /     _.-'    |     PID: 56755

  `-._    `-._  `-./  _.-'    _.-'

 |`-._`-._    `-.__.-'    _.-'_.-'|

 |    `-._`-._        _.-'_.-'    |           http://redis.io

  `-._    `-._`-.__.-'_.-'    _.-'

 |`-._`-._    `-.__.-'    _.-'_.-'|

 |    `-._`-._        _.-'_.-'    |

  `-._    `-._`-.__.-'_.-'    _.-'

      `-._    `-.__.-'    _.-'

          `-._        _.-'

              `-.__.-'


[56755] 25 Jan 08:34:36.881 # Sentinel runid is 9099fe62e1aecb70d48ebf2c7181a7fb17b2c621

[56755] 25 Jan 08:34:36.881 # +monitor master mymaster xxx.xxx.xx.xxx 6379 quorum 2


제대로 동작하고 있는것 같습니다.


이제 Sentinel 이 제대로 Failover 하는지 확인하기 위해서 Master 서버를 중지해 보겠습니다.

systemctl stop redis.service


다시 한번 로그를 확인해 볼까요?


[56802] 25 Jan 08:50:40.200 # Sentinel runid is 37165ee2e8084572acc8e5f061867ae98954aaeb

[56802] 25 Jan 08:50:40.200 # +monitor master mymaster xxx.xxx.xx.xxx 6379 quorum 2

[56802] 25 Jan 08:50:40.202 * +slave slave yyy.yyy.yy.yyy:6379 yyy.yyy.yy.yyy 6379 @ mymaster xxx.xxx.xx.xxx 6379

[56802] 25 Jan 08:50:40.202 * +slave slave zzz.zzz.zz.zzz:6379 zzz.zzz.zz.zzz 6379 @ mymaster xxx.xxx.xx.xxx 6379

[56802] 25 Jan 08:50:41.014 * +sentinel sentinel xxx.xxx.xx.xxx:8002 xxx.xxx.xx.xxx 8002 @ mymaster xxx.xxx.xx.xxx 6379

[56802] 25 Jan 08:51:19.581 * +sentinel sentinel zzz.zzz.zz.zzz:8000 zzz.zzz.zz.zzz 8000 @ mymaster xxx.xxx.xx.xxx 6379

[56802] 25 Jan 08:54:04.470 # +sdown master mymaster xxx.xxx.xx.xxx 6379

[56802] 25 Jan 08:54:04.588 # +new-epoch 1

[56802] 25 Jan 08:54:04.671 # +vote-for-leader 1cde8517263c3626ffe745d6046e4dbffaa1599a 1

[56802] 25 Jan 08:54:04.671 # +odown master mymaster xxx.xxx.xx.xxx 6379 #quorum 3/2

[56802] 25 Jan 08:54:04.671 # Next failover delay: I will not start a failover before Mon Jan 25 09:00:05 2016

[56802] 25 Jan 08:54:05.730 # +config-update-from sentinel zzz.zzz.zz.zzz:8000 zzz.zzz.zz.zzz 8000 @ mymaster xxx.xxx.xx.xxx 6379

[56802] 25 Jan 08:54:05.730 # +switch-master mymaster xxx.xxx.xx.xxx 6379 yyy.yyy.yy.yyy 6379

[56802] 25 Jan 08:54:05.730 * +slave slave zzz.zzz.zz.zzz:6379 zzz.zzz.zz.zzz 6379 @ mymaster yyy.yyy.yy.yyy 6379

[56802] 25 Jan 08:54:05.798 * +slave slave xxx.xxx.xx.xxx:6379 xxx.xxx.xx.xxx 6379 @ mymaster yyy.yyy.yy.yyy 6379


xxx.xxx.xx.xxx 라는 아이피의 Master 를 감시중에 SDown 상태 -> ODown 상태로 변경되고 Failover 를 하여, yyy.yyy.yy.yyy 라는 아이피의 Slave 서버가 마스터로 승격(Switch)되었음을 알 수 있습니다. 이 상태에서 원래 마스터였던 xxx.xxx.xx.xxx 를 다시 재기동하면 이 서버는 Slave 로서 동작하게 됩니다. 이는 Sentinel 이 Redis 의 설정파일을 Rewrite 하기 때문인데요. Master 가 Slave 로 Slave 가 Master 로 승격되는 일련의 과정들이 모두 Sentinel 이 설정파일을 Rewrite 하므로써 가능한 것입니다.


이로써 우리는 Redis 서버를 설치하고, 복제설정, Sentinel 을 이용한 고가용성 구성까지 완료하였습니다.

하지만, 실제 어플리케이션 개발단에서 위와 같은 Failover 시 Master/Slave 를 판단하기 위한 별도의 코드들을 넣어처리하는 짓은 하고 싶지 않습니다. 이를 위해 HaProxy 를 이용한 스위치 구성과 HaProxy 의 HA를 구성하여 최종적으로 Redis 서버의 구성을 마무리 하도록 하겠습니다.


다음 포스팅에서 계속 됩니다.




Comments