'2015/04'에 해당되는 글 1건

  1. 2015.04.03 sentinel 설정

sentinel 설정

Redis 2015. 4. 3. 10:14

sentinel은 master-slave로 구성된 서버에 master노드가 죽었을때 자동으로 살아있는 slave를 master로 승격시키고 계속적으로 서비스를 가능하게 해주는 기능이다.


failover를 가능하게 하도록 자기만의 로직을 사용하는것도 좋지만, sentinel일는 편리한 기능이 있으므로 사용해보도록 하자. 참고로, redis가 몇백대로 구성된 대규모 서버에서는 sentinel보다는 그네들만의 방법을 사용한다고 한다. 하지만, 중소규모 서버구성이라면 충분히 활용이 가능해보인다.


sentinel 기동

sentinel이라고 해서 특별한것이 없고 redis를 기동하는데 sentinel모드로 기동한다는 개념이다.

# redis-server /path/to/sentinel.conf --sentinel

기동시 필요한 옵션으로 sentinel의 conf파일을 지정, 그리고 sentinel이라고 명시한다.

한가지 방법이 더 있는데 redis-sentinel이라는 실행파일로 실행하는것이다.

# redis-sentinel /path/to/sentinel.conf

방법만 다를뿐이지 결과적으로 sentinel을 기동시킨다는것에는 틀린점이 없다.


sentinel.conf 설정

port 26379

포트를 지정


sentinel monitor mymaster 127.0.0.1 6379 2

sentinel monitor <master-name> <ip> <redis-port> <quorum> : master노드의 정보를 지정. master-name은 alias한master노드의 이름을 지정. ip와 redis-port는 master노드의 ip와 port를 지정. quorum은 failover를 진행하기 위해 필요한 SDown수를 의미한다. 만약에 slave노드의 정보를 입력해도, INFO명령어를 사용하여 자동으로 master를 감시하게 된다.


여기서 sdown이 무엇이냐? sentinel은 master노드의 이상을 위해 SDown(Subjectively down), ODown(Objectively down)의 두가지의 상태를 가지는데 각각 주관적다운, 객관적다운 이라는 말이다.

master노드가 이상이 생겻다는것은 여러가지 원인이 있을수있는데 그중에 sentinel과 master노드간 네트워크에 문제가 생겻을때도 이상이 생겻다고 판단을 할수있다. 하지만 서버자체는 이상이 없다. 이런경우 sentinel가 하나만 있다면 완전외부에서 master노드를 사용함에 있어 문제가 없는데도 master노드가 문제가 생겻다고 판단해서 필요없는 failover를 진행해버릴수도 있다. 그래서 복수의 sentinel로 master노드를 감시를 하며, 각각의 sentinel가 master노드를 감시하며 이상이 발생했다면 SDown상태로 인식하게 된다. 그리고 이상을 감지한 sentinel의 수가 quorum의 이상이 되었다면 비로서 ODown상태로서 인식하게 되고 failover를 진행시키게 된다. 즉, sentinel가 오판을 할수도 있으므로 복수의 sentinel로 감시를 하게 하고 투표제로 일정수가 넘었는지를 체크하는 방식이다. 만약 quorum에 설정한 수가 감시하고있는 sentinel수보다 많다면 failover는 절대 일어나지 않을것이다.


sentinel down-after-milliseconds mymaster 5000

sentinel down-after-milliseconds <master-name> <milliseconds> : SDown상태로 인식하기까지의 시간. master-name은 master노드의 alias. millseconds는 시간이다. sentinel이 master노드가 살았는지 죽었는지를 판단하기 위해서 주기적으로 PING과 INFO명령어를 사용하는데 이 명령어를 master노드에 던저서 지정한시간안에 응답이 없거나 잘못된 응답이 돌아올경우 Sdown상태로 인식하게 된다. 레디스는 싱글스레드이므로 당연히 sentinel으로 온 명령어도 순차적으로 처리를 하게 되고 서버가 아주 바쁜상태라면 응답이 늦어지는 경우도 발생할수 있으므로 1초나 2초같이 너무 짧은 설정은 피하는것이 좋다. 추천은 3초~5초.


sentinel parallel-syncs mymaster 1

sentinel parallel-syncs <master-name> <numslaves> : failover가 진행하였을때 slave가 새로운 master로 부터 새롭게 동기를 하게 되는데 몇개의 slave가 병렬적으로 동기를 하느냐 설정을 한다. 만약 numslaves를 1로 설정한다면 salve들이 순차적으로 새로운 master와 동기를 하게된다. 숫자를 크게 설정하면 그만큼 병렬적으로 slave의 동기작업이 발생하므로 master에게는 좋지않다. 경우에 따라서 failover를 했는데, 동기하는데 너무 많은 리소스를 사용하여 새로운 master가 또다시 죽었다고 판단되버릴수도 있다.


sentinel failover-timeout mymaster 180000

sentinel failover-timeout <master-name> <milliseconds> : failover작업의 timeover시간을 지정한다. 너무 짧게 설정&salve가 많은 상태라면 slave와 동기작업도중 timeout을 넘어버려 어중간하게 failover를 마치게 될수도있다.


sentinel can-failover 라는 설정도 있었는데 현재 최신버전에는 이 설정이 사라졌다.


■sentinel간의 통신과 slave의 감시

sentinel.conf에는 slave에 대한 설정이나 다른 sentinel에 대한 정보를 일체 하지 않았다. 하지만 sentinel은 다른 sentinel과 통신을 하고 slave에 대한 감시(failover시 어떤 slave를 master로 설정할지 알아내기위해)도 하고 있다. 어떻게 다른 서버의 정보를 알수있는 것인가?

다른 sentinel과의 통신 : Pub/Sub기능을 사용한다. __sentinel__:hello라는 채널을 만들어 sentinel끼리 통신을 하게 된다.

slave의 정보를 알아내기 : INFO명령어를 사용하여 slave의 정보를 알아낸다.

Posted by 명혀니
,