Redis 센티넬 대 클러스터링


111

redis sentinel이 여러 redis 인스턴스간에 HA (고 가용성)를 구성하는 방법이라는 것을 이해합니다. 보시다시피 주어진 시간에 클라이언트 요청을 적극적으로 처리하는 하나의 redis 인스턴스가 있습니다. 두 개의 추가 서버가 대기 상태에 있습니다 (실패가 발생할 때까지 대기하므로 그중 하나가 다시 작동 할 수 있음).

  • 자원 낭비입니까?
  • 사용 가능한 리소스를 최대한 활용하는 더 좋은 방법이 있습니까?
  • Redis 클러스터링은 Redis 센티넬의 대안입니까?

나는 이미 sentinelclustering에 대한 redis 문서를 찾았습니다 . 경험이있는 누군가가 설명해 주시겠습니까?

Redis sentinel의 마스터 슬레이브 구성-실패 전

마스터가 실패하고 슬레이브가 행동을 시작

최신 정보

확인. 실제 배포 시나리오에서는 redis 전용 서버가 두 개 있습니다. 내 Jboss 서버가 실행중인 다른 서버가 있습니다. Jboss에서 실행되는 응용 프로그램은 redis 마스터 서버 (M)에 연결하도록 구성되어 있습니다.

장애 조치 시나리오

이상적으로는 마스터 캐시 서버가 실패하면 (Redis 프로세스가 다운되거나 시스템이 실패하면) Jboss의 애플리케이션이 Slave 캐시 서버에 연결해야한다고 생각합니다. 이를 위해 redis 서버를 어떻게 구성해야합니까?

+--------+          +--------+
| Master  |---------| Slave  |
|         |         |        |
+--------+          +--------+

Configuration: quorum = 1

답변:


119

먼저 센티넬을 이야기합시다.

Sentinel은 장애 조치를 관리하지만 HA 용 Redis를 구성하지 않습니다. 중요한 구별입니다. 둘째, 게시 한 다이어그램은 실제로 잘못된 설정입니다. 관리중인 Redis 노드와 동일한 노드에서 Sentinel을 실행하고 싶지는 않습니다. 호스트를 잃으면 둘 다 잃게됩니다.

"자원 낭비인가?" 사용 사례에 따라 다릅니다. 해당 설정에는 3 개의 Redis 노드가 필요하지 않으며 2 개만 필요합니다. 3은 중복성을 증가 시키지만 필수는 아닙니다. 추가 중복이 필요한 경우 리소스 낭비가 아닙니다. 중복성이 필요하지 않은 경우 단일 Redis 인스턴스를 실행하고 더 많은 것을 실행하는 것은 "낭비"될 수 있으므로이를 좋음이라고합니다.

두 개의 슬레이브를 실행하는 또 다른 이유는 읽기를 분할하는 것입니다. 다시 말하지만, 필요하다면 낭비가 아닙니다.

"사용 가능한 자원을 최대한 활용하는 더 좋은 방법이 있습니까?" 특정 시나리오와 코드에 너무 많이 의존하기 때문에 대답 할 수 없습니다. 즉, 저장할 데이터의 양이 "작고"명령 속도가 너무 높지 않다면 호스트를 Redis 전용으로 사용할 필요가 없다는 것을 기억하십시오.

이제 "Redis 클러스터링은 Redis 센티넬의 대안입니까?"입니다. 실제로 사용 사례에 따라 다릅니다. Redis Cluster는 HA 솔루션이 아닙니다. 다중 작성자 / ram보다 큰 솔루션입니다. 목표가 HA 인 경우 적합하지 않을 수 있습니다. Redis Cluster에는 특히 다중 키 작업과 관련된 제한 사항이 있으므로 반드시 "클러스터 사용"작업이 간단하지는 않습니다.

Redis를 실행하는 호스트 3 개 (및 센티넬 실행중인 3 개)를 갖는 것이 낭비라고 생각한다면 더 많은 리소스가 필요하므로 클러스터를 훨씬 더 많이 보유하게 될 것입니다.

당신이 묻는 질문은 아마도 너무 광범위하고 의견에 근거하여 쓰여진대로 살아남을 수 없습니다. 해결중인 특정 사례 / 문제가있는 경우이를 업데이트하여 특정 지원 및 정보를 제공 할 수 있습니다.

세부 사항 업데이트 :

귀하의 시나리오에서 적절한 장애 조치 관리를 위해 JBoss 서버에서 실행되는 3 개의 센티널을 사용하겠습니다. 3 개의 JBoss 노드가있는 경우 각각 하나씩 사용하십시오. 별도의 노드에 Redis 포드 (마스터 + 슬레이브)가 있고 sentinel이 장애 조치를 관리하도록합니다.

거기에서 정보 및 연결 관리를 위해 Sentinel을 사용하기 위해 JBoss / Jedis를 연결하는 문제입니다. 빠른 검색을 사용하지 않기 때문에 Jedis가 지원하는 것으로 나타 났으므로 올바르게 구성하면됩니다. 내가 찾은 몇 가지 예 는 Sentinelhttps://github.com/xetorthio/jedis/issues/725 와 함께 Jedis의 예찾고JedisSentinelPool 있으며 풀 사용 경로에 대해 이야기 합니다.

Sentinel이 페일 오버를 실행할 때 클라이언트는 연결이 끊어지고 Jedis는 현재 마스터가 누구인지 센티넬에게 요청하여 재 연결을 처리합니다.


6
@ The-Real-Bill 님, "Sentinel이 장애 조치를 관리하지만 HA 용 Redis를 구성하지 않습니다."에 대해 자세히 설명해 주시겠습니까? 공식 문서 ( redis.io/topics/sentinel )에 "Redis Sentinel은 Redis에 고 가용성을 제공합니다."라고되어 있습니다.
샤오 펭 - ZenUML.com

1
HA Redis에는 여러 부분이 HA가 필요합니다. Sentinel은 장애 조치라는 한 가지만 처리합니다. 복제를 설정하지 않으며 HA 엔드 포인트를 제공하지 않습니다. 서비스 검색을 제공하므로 클라이언트가 마스터에 도달하기 위해 대화 할 위치를 알 수 있습니다. 이것은 HA 용 Redis를 구성하지 않습니다.
The Real Bill

5
여기의 주장은 사실이 아닙니다-redis with sentinel DOES는 기본 노드에서 대기 노드로의 복제를 관리합니다. 장애 조치시 마스터가 변경되고 복제가 새 마스터의 나머지 노드로 이동합니다. 복구 된 노드는 복제 대상인 보조 사이트가됩니다. 누락 된 부분은 CLIENT가 상태 변경에 대한 정보를 받기 위해 센티넬과 대화해야한다는 것입니다. 따라서 Sentinel은 고 가용성 솔루션입니다.
JasonG 16.08.08

6
나는 그것이 복제를 설정하지 않는다고 말했고 이것은 사실입니다. 슬레이브를 설정하여 Redis 복제를 구성합니다. 그런 다음 센티넬은이를 발견하고 장애 조치를 관리합니다. Sentinel은 기존 복제 설정 만 관리하므로 복제를 설정할 수 없습니다. 시도 해봐. 두 개의 독립적 인 Redis 서버를 켜고 직접 슬레이브를 사용하지 않고 하나의 슬레이브를 다른 슬레이브로 만들기 위해 감시를받습니다. 작동하지 않습니다. 새로운 노예를 추가 할 수도 없습니다. 따라서 그렇습니다. 복제를 설정합니다.
실제 빌

35

모든 곳에서 권장 사항은 둘 또는 둘의 배수를 사용하지 않고 홀수의 인스턴스로 시작하는 것입니다. 수정되었지만 다른 점을 수정하겠습니다.

첫째, Sentinel이 HA없이 장애 조치를 제공한다는 것은 거짓입니다. 장애 조치가있는 경우 애플리케이션 상태가 복제된다는 추가 이점이있는 HA가 있습니다. 차이점은 복제없이 시스템에서 HA를 가질 수 있다는 것입니다 (HA이지만 내결함성이 아님).

둘째, 대상 redis 인스턴스와 동일한 머신에서 센티넬을 실행하는 것은 "잘못된 설정"이 아닙니다. 센티넬, redis 인스턴스 또는 전체 머신을 잃어버린 경우 결과는 동일합니다. 이것이 아마도 그러한 구성의 모든 예가 동일한 시스템에서 실행되는 것을 보여주는 이유 일 것입니다.


6
실제로 Sentinel이 "sentinel-on-the-instance"설정에서 선거를 시작하지 못하는 버그가있는 것으로 보이며 여기, ML 및 개별 컨설팅에서 여러 번 보았습니다. Redis 서버에서 센티넬을 이동하면 매번 수정되었습니다. 따라서 그렇게하는 것은 필요한 순간에 실패한다는 점에서 나쁜 설정입니다. 예제는 광범위한 운영 경험을 가진 사람들이 작성하지 않고 더 쉽기 때문에 그렇게 보여줍니다.
The Real Bill

3
이것은 어떤 버그입니까? 버그 보고서가 있습니까? 아직 존재하는지 아십니까?
sivann

응용 기계에 센티넬을 두는 유사한 문제가 있습니까?
OrangeDog

31

이것은 귀하의 질문에 대한 직접적인 대답은 아니지만 저와 같은 Redis 초보자에게 유용한 정보라고 생각하십시오. 또한이 질문은 "Redis cluster vs sentinel"을 검색 할 때 Google의 첫 번째 링크로 나타납니다.

Redis Sentinel은 Redis 고 가용성 솔루션의 이름입니다. Redis 클러스터와는 아무 관련이 없으며 Redis 클러스터가 필요하지 않은 사람들이 사용하도록 설계되었지만 마스터가 필요할 때 자동 장애 조치를 수행하는 방법입니다. 인스턴스가 올바르게 작동하지 않습니다.

으로부터 촬영 레디 스 센티넬 디자인 초안 1.3

Redis를 처음 사용하고 장애 조치 솔루션을 구현하는 것은 분명하지 않습니다. 센티넬클러스터링 에 대한 공식 문서는 서로 비교되지 않으므로 수많은 문서를 읽지 않고 올바른 방법을 선택하기가 어렵습니다.


10

이것은 문서 전반에 걸쳐 머리를 두드리는 후에 나의 이해입니다.

Sentinel은 슬레이브가 복제 된 상태로 유지되고 언제든지 승격 될 준비가 된 일종의 핫 스탠바이 솔루션입니다. 그러나 다중 노드 쓰기는 지원하지 않습니다. 읽기 작업을 위해 슬레이브를 구성 할 수 있습니다. Sentinel이 HA를 제공하지 않는다는 것은 사실이 아니며 일반적인 액티브-패시브 클러스터의 모든 기능을 갖추고 있습니다 (여기서 사용하기에 적합한 용어는 아닙니다).

Redis 클러스터는 샤드 위에서 작동하는 분산 솔루션입니다. 각 데이터 청크는 마스터 및 슬레이브 노드간에 분산됩니다. 최소 복제 계수 2는 마스터와 슬레이브에서 두 개의 활성 샤드를 사용할 수 있도록합니다. Mongo 또는 Elasticsearch의 샤딩을 알고 있다면 쉽게 따라 할 수 있습니다.


6

Redis는 분할 된 클러스터 (많은 마스터 및 해당 마스터의 슬레이브 포함) 또는 단일 인스턴스 모드 (복제본 슬레이브가있는 단일 마스터)에서 작동 할 수 있습니다. 링크는 여기에 말한다 :

단일 Redis 서버가 파티션되지 않은 전체 데이터베이스를 관리하는 단일 인스턴스 모드에서 Redis를 사용하는 경우 Redis Sentinel을 사용하여 가용성을 관리합니다.

또한 다음과 같이 말합니다.

데이터가 여러 기본 인스턴스로 분할되는 Redis 클러스터는 가용성을 자체적으로 관리하고 추가 구성 요소가 필요하지 않습니다.

따라서 언급 된 두 가지 시나리오에서 HA를 보장 할 수 있습니다. 이것이 의심을 없애기를 바랍니다. Redis 클러스터와 센티넬은 서로 대안이 아닙니다. 파티션 된 또는 파티션되지 않은 마스터의 다른 경우에 HA를 보장하기 위해 사용됩니다.


4

Redis Sentinel은 마스터가 다운 된 경우 복제본 승격 장애 조치를 수행합니다. 일반적으로 홀수 개의 센티넬 노드를 원합니다. 하나의 마스터와 하나의 복제본의 경우 결정에 대한 합의가 이루어질 수 있도록 3 개의 센티널을 사용해야합니다. 이상적으로 세 번째 센티넬은 세 번째 서버에 있으므로 결정이 왜곡되지 않습니다 (실패에 따라 다름). Sentinel은 노드의 마스터 / 복제본 구성 설정을 변경하여 승격 및 동기화가 올바른 순서로 발생하고 이제 이전 데이터가 포함 된 이전 실패한 마스터를 가져 와서 데이터를 덮어 쓰지 않도록합니다.

장애 조치를 수행하도록 센티널 노드를 설정했으면 올바른 인스턴스를 가리키고 있는지 확인해야합니다. 이에 대한 HAProxy 구성 의 예를 참조하십시오 . HAProxy는 상태 확인을 수행하고 오류가 발생하면 새 마스터를 가리 킵니다.

클러스터링을 사용하면 수평으로 확장 할 수 있고 높은로드를 처리 할 수 ​​있습니다. 미리 설정하고 구성하는 데 약간의 작업이 필요합니다.

Active-replica 옵션이있는 센티넬 노드의 필요성을 제거한 Redis,“KeyDB”의 오픈 소스 포크가 있습니다. 이를 통해 복제본 노드는 읽기 및 쓰기를 허용 할 수 있습니다. 장애 조치가 발생하면 HAProxy는 실패한 노드의 읽기 / 쓰기를 중지하고 이미 동기화 된 나머지 활성 노드 만 사용합니다. 타임 스탬프를 사용하면 실패한 노드가 자동으로 다시 가입하고 온라인 상태가 될 때 데이터 손실없이 다시 동기화 할 수 있습니다. 설정은 간단하며 트래픽이 많은 경우 읽기를 복제본 노드로 지정하고 읽기 / 쓰기를 마스터로 지정하기 위해 특별한 사전 설정이 필요하지 않습니다. 여기에서 활성 복제의 예를 참조하십시오 . KeyDB는 또한 일부 응용 프로그램의 경우 클러스터링의 대안이 될 수 있지만 실제로 요구 사항에 따라 달라지는 다중 스레드입니다.

설정의 예도 있습니다 수동으로 클러스터링 과 함께 만들 클러스터를 도구 . Redis를 사용하는 경우 동일한 단계입니다 (명령에서 'keydb'를 'redis'로 대체).


1

위 답변에 대한 추가 정보

Redis 클러스터

  • Redis 클러스터의 주요 목적 중 하나는 샤딩을 통해 데이터로드를 동일 / 균등하게 분산하는 것입니다.

  • Redis Cluster는 일관된 해싱을 사용하지 않지만 모든 키가 개념적으로 해시 슬롯이라고하는 것의 일부인 다른 형태의 샤딩을 사용합니다.

  • Redis 클러스터에는 16384 개의 해시 슬롯이 있습니다. Redis 클러스터의 모든 노드는 해시 슬롯의 하위 집합을 담당하므로 예를 들어 3 개의 노드가있는 클러스터가있을 수 있습니다.

    노드 A에는 0에서 5500까지의 해시 슬롯이 포함되고 노드 B에는 5501에서 11000까지의 해시 슬롯이 포함되며 노드 C에는 11001에서 16383까지의 해시 슬롯이 포함됩니다.

이를 통해 클러스터에서 노드를 쉽게 추가하고 제거 할 수 있습니다. 예를 들어 새 노드 D를 추가하려면 노드 A, B, C에서 D로 일부 해시 슬롯을 이동해야합니다.

  • Redis 클러스터는 마스터-슬레이브 구조를 지원하므로 클러스터를 생성 할 때 마스터 A, B, C와 함께 슬레이브 A1, B1, C2를 생성 할 수 있으므로 마스터 B가 다운되면 슬레이브 B1이 마스터로 승격됩니다.

Redis Cluster를 사용할 때 추가 장애 조치 처리가 필요하지 않으며 클러스터 노드에서 Sentinel 인스턴스를 가리 키지 않아야합니다.

그래서 실제적으로 Redis Cluster로 무엇을 얻을 수 있습니까?

1. 데이터 세트를 여러 노드로 자동 분할하는 기능.

2. 노드의 하위 집합에 오류가 발생하거나 나머지 클러스터와 통신 할 수없는 경우 작업을 계속할 수있는 기능.

레디 스 센티넬

  • Redis는 마스터 노드에서 데이터를 복제하는 여러 슬레이브를 지원합니다.
  • 이것은 마스터 노드의 데이터에 대한 백업을 제공합니다.
  • Redis Sentinel은 마스터 및 슬레이브를 관리하도록 설계된 시스템입니다. 별도의 프로그램으로 실행됩니다. 이상적인 시스템에 필요한 최소 센티넬 수는 3 개입니다. 그들은 서로 통신하고 마스터가 살아 있는지 확인합니다. 살아 있지 않으면 슬레이브 중 하나를 마스터로 승격하므로 나중에 데드 노드가 회전 할 때 새 마스터의 노예 역할
  • 쿼럼은 구성 가능합니다. 기본적으로 마스터가 다운되었을 때 동의해야하는 파수꾼의 수입니다. N / 2 +1 은 동의해야합니다. N은 포드의 노드 수입니다 (이 설정을 포드라고하며 클러스터가 아님).

그래서 실제적으로 Redis Sentinel을 통해 무엇을 얻을 수 있습니까?

마스터가 항상 사용 가능한지 확인합니다 (마스터가 다운되면 슬레이브가 마스터로 승격됩니다).

참조 :

https://fnordig.de/2015/06/01/redis-sentinel-and-redis-cluster/

https://redis.io/topics/cluster-tutorial

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.