레디스 센티넬

Lediseu Sentinel



프로덕션에 Redis 인스턴스가 하나만 있고 어떤 이유로 인해 어느 시점에서 실패하는 시나리오를 가정합니다. 애플리케이션이 Redis 데이터 저장소에 데이터를 캐시하고 이제 유일한 데이터 소스가 중단되었습니다. 이러한 종류의 시나리오를 제어하는 ​​한 가지 방법은 마스터 노드가 돌아올 때까지 슬레이브가 마스터 노드를 복제할 수 있는 마스터-슬레이브 아키텍처를 유지하는 것입니다. Redis 클러스터는 마스터-복제본 접근 방식을 통해 어느 정도 고가용성을 지원합니다. Redis Sentinel은 Redis 인스턴스의 고가용성을 유지하기 위한 보다 안정적인 방법을 제공하는 또 다른 접근 방식입니다. Redis 마스터 노드의 오류를 모니터링하고 기존 슬레이브 노드를 새로운 마스터로 승격시키는 장애 조치 프로세스를 즉시 트리거합니다.







또한 Redis 센티넬은 클라이언트가 연결하여 최신 마스터 노드 IP 주소를 요청하는 중개자 역할을 합니다. 따라서 연결된 센티넬은 즉시 마스터 노드 주소를 제공합니다.



또한 여러 센티넬이 특정 마스터에 연결할 수 없거나 사용할 수 없다는 데 동의하면 마스터 노드 오류가 확인됩니다. 이로써 장애 감지 단계가 완료되고 장애 조치 프로세스가 즉시 시작됩니다. 따라서 Redis 센티넬은 특정 속성을 가진 분산 시스템으로 볼 수 있습니다.



센티넬의 동의는 다음 섹션에서 논의될 쿼럼 값을 기반으로 합니다.





누구의 가치

쿼럼 값은 마스터 노드가 다운될 때 합의해야 하는 센티넬의 최대 수입니다. 이 값은 마스터 노드의 오류를 식별하는 데만 사용됩니다. 장애 조치 프로세스는 선택된 센티넬을 리더로 진행하기 위해 사용 가능한 여러 센티넬 노드의 권한 부여로 시작됩니다.

레디스 센티넬의 특징

센티넬은 Redis 데이터 저장소에 고가용성 메커니즘을 제공하는 것으로 알려져 있습니다. 그 외에도 몇 가지 다른 기능을 나열할 수 있습니다.



  • Sentinel은 Redis 시스템의 마스터 및 슬레이브 노드 상태를 지속적으로 모니터링합니다.
  • Redis 인스턴스에 오류가 발생하거나 문제가 발생할 때마다 센티넬은 센티넬 API를 사용하여 관리자 또는 연결된 애플리케이션에 알릴 수 있습니다.
  • 장애 조치 단계는 복제본을 새 마스터로 승격하여 센티넬이 지시합니다. 새 마스터를 사용하도록 구성된 나머지 복제본. 마지막으로 해당 클라이언트는 새 마스터 노드 주소에 대한 알림을 받습니다.
  • 또한 Redis 센티넬은 클라이언트가 현재 사용 가능한 마스터 인스턴스의 주소를 요청할 수 있는 연결된 클라이언트에 대한 구성 제공자이며, 갑작스러운 붕괴가 발생하면 센티넬은 즉시 새 마스터 노드 주소를 푸시하도록 커밋됩니다.

다음 섹션에서는 마스터-복제본 인스턴스로 Redis 센티넬을 구성하고 센티넬 API를 사용하여 노드를 모니터링합니다.

센티넬 구성

먼저 포트 7000과 7001에 두 개의 Redis 인스턴스를 생성합니다. 포트 7000은 마스터 노드가 되고 다른 하나는 마스터를 복제합니다. 두 인스턴스 모두 각각 다음 구성 파일을 사용합니다.

마스터 노드 구성

포트 7000
클러스터 사용 아니요
클러스터 구성 파일 node.conf
클러스터 노드 시간 초과 5000
추가 전용

슬레이브 노드 구성

포트 7001
클러스터 사용 아니요
클러스터 구성 파일 node.conf
클러스터 노드 시간 초과 5000
추가 전용

두 인스턴스 모두 각각에 연결된 구성 파일을 제공하여 시작됩니다. 다음 명령을 사용하여 Redis 인스턴스를 별도로 시작할 수 있습니다.

redis-server redis.conf

다음과 같이 포트 7001에서 시작된 Redis 인스턴스에 연결해 보겠습니다.

redis-cli -피 7001

이제 이 인스턴스를 포트 7000에서 실행 중인 마스터의 복제본으로 만들 수 있습니다. REPLICAOF 명령은 다음과 같이 사용할 수 있습니다.

127.0.0.1의 복제본 7000

예상대로 포트 7001에서 실행 중인 인스턴스는 포트 7000에서 실행 중인 마스터의 복제본 노드가 되었습니다.

이제 위의 마스터 인스턴스를 모니터링하기 위해 3개의 Redis 센티넬을 구성할 준비가 되었습니다. 다음과 같이 포트 5000, 5001 및 5002에서 3개의 센티넬 인스턴스를 생성하려면 3개의 구성 파일이 필요합니다.

센티넬.conf 파일은 포트 번호가 변경된다는 점을 제외하고 다음과 같습니다.

포트 5000
센티넬 모니터 마스터노드 127.0.0.1 7000
센티넬 다운 애프터 밀리세컨드 마스터노드 5000
센티넬 장애 조치 시간 초과 마스터노드 60000

이제 세 명의 센티넬을 실행할 시간입니다. redis-sentinel 실행 파일을 경로와 함께 사용할 수 있습니다. 센티넬.conf 센티넬 인스턴스를 생성하기 위한 구성 파일. 그렇지 않으면 경로를 지정하여 redis-server 실행 파일을 계속 호출할 수 있습니다. 센티넬.conf 그리고 깃발 -보초 .

다음 명령을 사용하여 각 센티넬을 시작하겠습니다.

redis-server sentinel.conf --보초

첫 번째 센티넬은 포트 5000에서 시작되었습니다. 마찬가지로 다른 두 인스턴스도 시작할 수 있습니다.

이제 다음 그림과 같이 Redis 센티넬 설정이 실행되고 있습니다.

다음 섹션에서는 Sentinel API에 대해 자세히 알아보고 이를 활용하여 Redis 마스터 노드와 관련된 정보를 검색하는 방법을 살펴보겠습니다.

센티넬 API

Redis는 연결된 마스터 및 복제본을 모니터링하고, 알림을 구독하고, 센티넬 설정을 수정하기 위한 별도의 센티넬 API를 제공합니다. 또한 다음과 같이 여러 용도를 나열합니다.

  • 모니터링되는 Redis 마스터 및 슬레이브 인스턴스의 상태 확인
  • 다른 센티넬에 대한 세부 정보
  • 장애 조치(failover) 발생 시 센티넬로부터 푸시 스타일 알림 수신

SENTINEL 명령을 연결된 하위 명령과 함께 사용하여 Redis 센티넬 및 모니터링되는 노드를 쿼리, 업데이트 또는 설정할 수 있습니다.

마스터 노드 상태 확인

마스터 노드 상태를 수시로 모니터링하거나 확인하는 것은 매우 중요합니다. 다음 센티넬 API 명령을 사용하여 마스터 세부 정보를 검색할 수 있습니다.

센티넬 마스터 < 모니터링된_마스터_이름 >

모니터링된_마스터_이름: 이전 단계에서 생성한 센티넬 구성 파일에 지정된 마스터 노드의 이름입니다.

이 명령을 사용하여 설정에서 마스터 상태를 쿼리해 보겠습니다. 우리의 경우 마스터 노드 이름은 '마스터노드'.

SENTINEL MASTER 마스터노드

여러 정보가 검색되었으며 num-slave, flag 및 num-other-sentinels와 같은 몇 가지 정보가 중요합니다.

그만큼 깃발 속성은 다음으로 설정됩니다. 주인 주인이 건강하다는 뜻입니다. 마스터 노드가 다운될 때마다 s_down 또는 o_down 플래그가 표시됩니다. 속성 num-other-sentinels Redis 센티넬이 이미 마스터 노드에 대해 다른 두 센티넬을 인식했음을 의미하는 2로 설정됩니다. 또한, 숫자 노예 속성은 마스터 노드에 사용 가능한 복제본을 표시합니다. 이 경우 복제본이 하나만 있으므로 1로 설정됩니다.

연결된 복제본에 대한 정보 얻기

다음 SENTINEL 하위 명령을 사용하여 마스터 노드와 연결된 복제본을 확인할 수 있습니다.

센티넬 복제본 < 모니터링된_마스터_이름 >

이 예에서 마스터 이름은 '마스터노드'입니다.

SENTINEL 복제본 마스터노드

예상대로 Sentinel은 포트 7001에서 실행 중인 슬레이브 노드를 감지했습니다.

연결된 센티넬에 대한 정보 얻기

마찬가지로 다음 SENTINEL 하위 명령을 사용하여 현재 마스터 노드와 연결된 다른 센티넬과 관련된 세부 정보를 쿼리할 수 있습니다.

센티넬 센티넬 < master_node_name >

이 경우 'masternode'라는 이름의 마스터 노드와 관련된 정보를 가져옵니다.

SENTINEL 센티넬 마스터노드

마스터 노드 주소 얻기

이전 섹션에서 언급했듯이 Redis sentinel은 연결된 클라이언트를 위한 구성 공급자입니다. 따라서 현재 실행 중인 마스터 노드의 IP 주소와 포트를 요청한 클라이언트에 제공할 수 있습니다. 다음 Sentinel API 하위 명령을 사용하여 언급된 정보를 검색할 수 있습니다.

센티넬 GET-MASTER-ADDR-BY-NAME < master_node_name >

다음과 같이 시나리오에 대해 위의 명령을 실행해 보겠습니다.

센티넬 get-master-addr-by-name 마스터노드

우리는 몇 가지 센티넬 API 명령에 대해서만 논의했습니다. sentinel-failover, sentinel info-cache, sentinel master 등과 같은 몇 가지 다른 하위 명령을 사용할 수 있습니다. 또한 많은 명령을 관리 목적으로 사용할 수도 있습니다. 다음 섹션에서는 Redis 센티넬 장애 조치 프로세스에 중점을 둘 것입니다.

센티넬 장애 조치 프로세스

센티넬이 구성되었으므로 장애 조치 단계를 테스트할 수 있습니다. 마스터 노드에서 실패를 시뮬레이션하는 300초 동안 마스터 노드를 절전 모드로 보내겠습니다.

디버그 300

포트 7000에서 실행 중인 마스터 노드는 지금 연결할 수 없습니다. 따라서 연결된 센티넬은 마스터를 사용할 수 없음을 알게 됩니다. +sdown 이벤트. 그러면 다음과 같이 설정됩니다. +다운 여기서 2개의 센티넬은 쿼럼 값에 따라 마스터 노드가 다운되었음을 확인합니다. 마지막으로 장애 조치 단계가 시작되며 이상적으로는 복제본이 새 마스터로 승격되어야 합니다.

마스터노드의 IP 주소와 포트를 다시 확인해보자.

센티넬 get-master-addr-by-name 마스터노드

예상대로 이전 복제본이 새 마스터로 승격되었으며 이는 센티넬 장애 조치 프로세스가 성공했음을 의미합니다. 이것으로 단일 마스터-복제본 쌍에 대한 세 가지 센티넬 설정의 배포 및 테스트를 마칩니다.

결론

Redis 센티넬은 지정된 Redis 마스터 복제본 인스턴스의 고가용성을 보장하는 가장 안정적인 접근 방식입니다. 센티넬은 사람의 개입 없이 모니터링, 알림 및 자동 장애 조치를 시작할 수 있습니다. 또한 여러 센티넬이 함께 마스터 노드에 연결할 수 없다는 사실과 마스터 인스턴스의 가용성을 확인할 때 합의해야 하는 센티넬의 최대 수로 쿼럼 값이 사용된다는 사실에 동의합니다. Redis sentinel은 마스터 노드 및 관련 복제본의 상태에 대한 정보를 검색하고 관리 작업도 수행할 수 있는 사용하기 쉬운 API를 제공합니다.