Redis Sentinel은 Redis를 위한 간단한 자동 고가용성(HA) 솔루션을 제공합니다. MongoDB 선거가 어떻게 작동하는지 잘 알고 있다면 이것은 그리 멀지 않은 일입니다. 시작하려면 N개의 슬레이브에 복제하는 마스터가 있습니다. 여기에서 애플리케이션 서버에서든 Redis가 실행 중인 서버에서든 Sentinel 데몬이 실행됩니다. 이것은 주인의 건강을 추적합니다.
Sentinel은 마스터가 응답하지 않는 것을 감지하면 SDOWN(주관적으로 다운됨) 메시지를 다른 센티넬에 브로드캐스트합니다. 그런 다음 마스터가 다운되었다는 쿼럼에 도달하면 ODOWN(객관적으로 다운)을 브로드캐스트하고 새 마스터가 선택됩니다. ODOWN 상태에 도달하는 데 동의하려면 센티넬의 과반수 또는 쿼럼이 필요하므로 동률을 피하기 위해 항상 홀수의 센티넬을 실행하는 것이 가장 좋습니다.
참고:Sentinel에서 최상의 성능을 얻으려면 2.8 브랜치 이상의 Redis 버전을 사용하는 것이 좋습니다.
작동 방식
Sentinel은 실행 중인 Redis 인스턴스의 구성 파일을 다시 작성하여 장애 조치를 처리합니다. 시나리오를 살펴보겠습니다.
슬레이브 "B"와 "C"에 복제하는 마스터 "A"가 있다고 가정합니다. Redis에 쓰는 애플리케이션 서버에서 3개의 Sentinel(s1, s2, s3)이 실행되고 있습니다. 이 시점에서 현재 마스터인 "A"가 오프라인 상태가 됩니다. 우리의 센티넬은 모두 "A"를 오프라인으로 보고 서로 SDOWN 메시지를 보냅니다. 그런 다음 모두 "A"가 다운되어 "A"가 ODOWN 상태로 설정된다는 데 동의합니다. 여기에서 누가 가장 앞서 있는지를 보기 위한 선택이 발생하며 이 경우 "B"가 새 마스터로 선택됩니다.
"B"에 대한 구성 파일은 더 이상 누구의 슬레이브도 되지 않도록 설정됩니다. 한편, "C"에 대한 config 파일은 더 이상 "A"의 슬레이브가 아닌 "B"가 되도록 다시 작성됩니다. 여기에서 모든 것이 정상적으로 계속됩니다. "A"가 다시 온라인 상태가 되면 Sentinels는 이를 인식하고 "B"가 현재 마스터이기 때문에 "A"에 대한 구성 파일을 "B"의 슬레이브로 다시 작성합니다.
구성
Sentinels를 구성하는 것은 생각보다 어렵지 않습니다. 사실 가장 어려운 일 중 하나는 Sentinel 프로세스를 배치할 위치를 선택하는 것입니다. 개인적으로 가능하면 앱 서버에서 실행하는 것이 좋습니다. 아마도 이것을 설정하는 경우 마스터에 대한 쓰기 가용성에 대해 걱정하고 있을 것입니다. 따라서 Sentinels는 애플리케이션 서버가 마스터와 통신할 수 있는지 여부에 대한 통찰력을 제공합니다. 물론 Redis 인스턴스 서버에서도 Sentinels를 실행할 수 있습니다.
구성 단계를 시작하려면 여기에 있는 예제 파일을 참조하십시오. 이것은 Ubuntu 14.04의 Redis 2.8.4에서 발견된 sentinel.conf의 예이지만 모든 2.8.x 버전의 Redis에서 작동해야 합니다. 실제로 사용하고 싶은 두 줄을 맨 위에 자유롭게 추가했습니다.
daemonize yes
logfile /var/log/redis/redis-sentinel.log이것은 센티넬 프로세스를 데몬화 모드로 전환하고 모든 메시지를 stdout 대신 로그 파일에 기록합니다.
여기에는 구성 가능한 옵션이 많이 있으며 대부분 주석이 잘 되어 있습니다. 그러나 이 게시물에서는 두 가지에만 중점을 둘 것입니다.
가장 중요한 부분은 센티넬에게 현재 마스터가 어디에 있는지 알려주는 것입니다. 이것은 다음 줄에서 참조됩니다.
sentinel monitor mymaster 127.0.0.1 6379 2이렇게 하면 Sentinel이 "mymaster"(임의의 이름이므로 원하는 대로 이름을 지정할 수 있음)와 지정된 포트의 지정된 IP, 장애 조치를 위한 쿼럼(쿼럼)을 충족하는 데 필요한 Sentinel 수를 모니터링하도록 지시합니다. 최소 2). 여기서 변경하고 싶은 부분은 마스터의 IP 주소이며 표준 포트 6379에서 실행되지 않는 경우 해당 포트입니다.
다음으로 다음 줄을 변경할 수 있습니다.
sentinel down-after-milliseconds mymaster 30000이것은 센티넬이 SDOWN에서 마스터를 선언하기 전에 기다리기를 원하는 시간입니다. 기본값은 30초이며 일반적으로 이 값을 10초로 약간 낮추고 싶습니다. 이 값을 너무 낮추고 싶지는 않습니다. 그렇지 않으면 장애 조치가 너무 자주 발생하는 문제가 발생할 수 있습니다.
다른 옵션을 자유롭게 살펴보십시오. 많은 사용자가 관심을 가질 만한 것 중 하나는 장애 조치가 발생할 때 이를 추적하려는 경우 알림 스크립트입니다.
Sentinel.conf를 적절하게 구성했으면 다음 명령으로 데몬을 시작하십시오.
redis-server /path/to/sentinel.conf --sentinel장애 조치 테스트
모든 센티넬이 온라인 상태가 되면 장애 조치를 위한 테스트 실행을 수행하여 모두 올바르게 구성되었는지 확인할 수 있습니다.
먼저 첫 번째 것들. redis-cli를 통해 Sentinel에 연결:
redis-cli -p 26379센티넬에 대한 정보를 수신하려면 다음 명령을 실행하기만 하면 됩니다.
127.0.0.1:26379> INFO이것은 현재 마스터가 누구인지, 슬레이브가 몇 명인지, 감시하고 있는 센티넬 수와 같은 정보를 제공합니다.
장애 조치를 테스트하려면 다음을 실행하기만 하면 됩니다.
127.0.0.1:26379> SENTINEL failover mymaster이렇게 하면 현재 마스터에서 강제로 ODOWN이 발생하고 장애 조치가 발생합니다. 잠시 후 "INFO" 명령을 다시 실행하면 이제 새 마스터가 나열되는 것을 볼 수 있습니다.
결론
이것이 Redis와 Sentinel을 이해하는 데 도움이 되었기를 바랍니다. 질문이 있으시면 언제든지 아래에 게시해 주세요!