일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- Keepalived
- mmbot
- sentinel
- gitlab
- 고가용성
- AirComic
- 커버구루
- ASP.NET
- 개발
- haproxy
- iPod Touch
- High Availability
- 센티넬
- 닷넷
- XBOX360
- DotNetOpenAuth
- 복제
- NoSQL
- TeamCity
- ipod
- 레디스
- redis
- Cover Guru
- 네아로
- c#
- replication
- DSM6
- Gears of War
- .NET
- 기어스 오브 워
- Today
- Total
Once in a Lifetime
03. Redis - 센티넬(Sentinel) 구성 본문
지난 포스트에서 우리는 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 서버의 구성을 마무리 하도록 하겠습니다.
다음 포스팅에서 계속 됩니다.