Redis sentinel против кластеризации

Я понимаю, что redis sentinel - это способ настройки HA (высокой доступности) для нескольких экземпляров Redis. Как я вижу, есть один экземпляр Redis, который в любой момент активно обслуживает клиентские запросы. Два дополнительных сервера находятся в режиме ожидания (ждут, пока произойдет сбой, поэтому один из них может снова работать).

• Это пустая трата ресурсов?
• Есть ли лучший способ использовать все доступные ресурсы?
• Кластеризация Redis - это альтернатива Redis sentinel?

Я уже просмотрел документацию по Redis для дозорного и кластеризации , может кто-нибудь, имеющий опыт, объяснить, пожалуйста.

ОБНОВИТЬ

ХОРОШО. В моем реальном сценарии развертывания у меня есть два сервера, выделенных для Redis. У меня есть другой сервер, на котором работает мой сервер Jboss. Приложение, работающее в Jboss, настроено для подключения к главному серверу Redis (M).

Сценарий аварийного переключения

В идеале, я думаю, что при выходе из строя главного кеш-сервера (либо процесс Redis, либо сбой машины) приложение в Jboss должно подключиться к подчиненному кеш-серверу. Как мне настроить серверы Redis для этого?

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

Configuration: quorum = 1

Во-первых, давайте поговорим о часовом.

Sentinel управляет отработкой отказа, он не настраивает Redis для HA. Это важное различие. Во-вторых, опубликованная вами диаграмма на самом деле плохая настройка - вы не хотите запускать Sentinel на том же узле, что и узлы Redis, которыми он управляет. Когда вы теряете этого хозяина, вы теряете и то, и другое.

На вопрос «Это трата ресурсов?» это зависит от вашего варианта использования. В этой настройке вам не нужны три узла Redis, вам нужно только два. Три увеличивает вашу избыточность, но это не обязательно. Если вам нужна дополнительная избыточность, это не пустая трата ресурсов. Если вам не нужна избыточность, вы просто запускаете один экземпляр Redis и называете его хорошим - так как запуск большего количества будет «потрачен впустую».

Еще одна причина для запуска двух ведомых устройств - это разделенное чтение. Опять же, если вам это нужно, это не будет пустой тратой.

Что касается «Есть ли лучший способ использовать все доступные ресурсы?» мы не можем ответить на этот вопрос, поскольку он слишком зависит от вашего конкретного сценария и кода. Тем не менее, если объем данных для хранения «мал», а скорость выполнения команд не слишком высока, помните, что вам не нужно выделять хост для Redis.

Теперь вопрос «Является ли кластеризация Redis альтернативой Redis sentinel?». Это действительно полностью зависит от вашего варианта использования. Redis Cluster - это не решение высокой доступности - это решение с несколькими модулями записи и размером больше оперативной памяти. Если ваша цель - просто HA, то она, скорее всего, вам не подойдет. Redis Cluster имеет ограничения, особенно в отношении операций с несколькими ключами, поэтому это не обязательно простая операция «просто использовать кластер».

Если вы считаете, что наличие трех хостов, на которых запущен Redis (и трех запущенных дозорных), расточительно, вы, вероятно, будете считать кластер еще более трудным, поскольку он требует больше ресурсов.

Вопросы, которые вы задали, вероятно, слишком широки и основаны на мнении, чтобы выжить в том виде, в котором они написаны. Если у вас есть конкретный случай / проблема, над которой вы работаете, сообщите об этом, чтобы мы могли предоставить конкретную помощь и информацию.

Обновление для уточнения:

Для правильного управления аварийным переключением в вашем сценарии я бы выбрал 3 дозорных, один из которых работает на вашем сервере JBoss. Если у вас 3 узла JBoss, используйте по одному на каждом. У меня был бы модуль Redis (главный + подчиненный) на отдельных узлах, и я позволил бы дозорному управлять аварийным переключением.

Оттуда нужно подключить JBoss / Jedis для использования Sentinel для управления информацией и подключениями. Поскольку я не использую их, быстрый поиск показывает, что у Jedis есть поддержка для этого, вам просто нужно правильно его настроить. Некоторые примеры, которые я нашел, - это поиск примеров джедаев с Sentinel и https://github.com/xetorthio/jedis/issues/725, в которых говорится оJedisSentinelPool маршруте использования пула.

Когда Sentinel выполняет аварийное переключение, клиенты будут отключены, и Jedis (должны?) Обработать повторное подключение, спросив Sentinels, кто является текущим мастером.

Везде рекомендуется начинать с нечетного числа экземпляров, а не использовать два или кратное двум. Это было исправлено, но давайте исправим некоторые другие моменты.

Во-первых, неверно сказать, что Sentinel обеспечивает аварийное переключение без высокой доступности. Когда у вас есть аварийное переключение, у вас есть высокая доступность с дополнительным преимуществом репликации состояния приложения. Различие в том, что в системе может быть HA без репликации (это HA, но не отказоустойчивый).

Во-вторых, запуск дозорного на том же компьютере, что и его целевой экземпляр Redis, не является «плохой настройкой»: если вы потеряете своего дозорного, или свой экземпляр Redis, или всю машину, результаты будут такими же. Вероятно, поэтому каждый пример таких конфигураций показывает, что оба они работают на одном компьютере.

Это не прямой ответ на ваш вопрос, но думаю, это полезная информация для новичков Redis, таких как я. Также этот вопрос появляется в качестве первой ссылки в Google при поиске «Redis cluster vs sentinel».

Redis Sentinel - это название решения высокой доступности Redis ... Оно не имеет ничего общего с Redis Cluster и предназначено для использования людьми, которым не нужен Redis Cluster, а просто способ выполнить автоматическое переключение при сбое, когда мастер экземпляр работает некорректно.

Взято из проекта проекта Redis Sentinel 1.3.

Это не очевидно, когда вы новичок в Redis и внедряете отказоустойчивое решение. Официальные документы о дозорных и кластеризованных не сравнивают друг с другом, поэтому трудно выбрать правильный путь, не прочитав тонны документации.

Это мое понимание после того, как я ударил головой по документации.

Sentinel - это своего рода решение горячего резервирования, при котором ведомые устройства сохраняются и готовы к продвижению в любое время. Однако он не будет поддерживать многоузловую запись. Подчиненные устройства могут быть настроены для операций чтения. Это НЕ правда, что Sentinel не будет обеспечивать высокую доступность, он обладает всеми функциями типичного активно-пассивного кластера (хотя это не тот термин, который здесь использовать).

Кластер Redis - это более или менее распределенное решение, работающее поверх шардов. Каждый блок данных распределяется между ведущими и ведомыми узлами. Минимальный коэффициент репликации 2 гарантирует, что у вас будет два активных шарда, доступных для главного и подчиненных устройств. Если вы знакомы с шардингом в Mongo или Elasticsearch, наверстать упущенное будет несложно.

Redis может работать в многораздельном кластере (со многими мастерами и подчиненными устройствами этих мастеров) или в режиме одного экземпляра (один мастер с подчиненными репликами). Ссылка здесь говорит:

При использовании Redis в режиме одного экземпляра, в котором один сервер Redis управляет всей неразмеченной базой данных, Redis Sentinel используется для управления ее доступностью.

В нем также говорится:

Кластер Redis, в котором данные разделены между несколькими первичными экземплярами, управляет доступностью самостоятельно и не требует дополнительных компонентов.

Таким образом, HA может быть обеспечена в двух упомянутых сценариях. Надеюсь, это развеет сомнения. Кластер Redis и дозорные не являются альтернативой друг другу. Они просто используются для обеспечения высокой доступности в различных случаях разделенного или несекционированного мастера.

Redis Sentinel выполняет аварийное переключение реплик, когда они видят, что главный сервер не работает. Обычно вам нужно нечетное количество контрольных узлов. В примере с одним мастером и одной репликой следует использовать 3 дозорных, чтобы можно было прийти к консенсусу по поводу решения. В идеале третий дозорный находится на третьем сервере, поэтому решение не искажается (в зависимости от сбоя). Sentinel позаботится об изменении настроек конфигурации главного / реплики на ваших узлах, чтобы продвижение и синхронизация происходили в правильном порядке, и вы не перезаписывали данные, вызывая старый отказавший мастер, который теперь содержит более старые данные.

После того, как вы настроили контрольные узлы для выполнения отработки отказа, вам необходимо убедиться, что вы указываете на правильный экземпляр. См. Для этого пример конфигурации HAProxy . HAProxy выполняет проверки работоспособности и в случае сбоя указывает на нового мастера.

Кластеризация позволит вам масштабироваться по горизонтали и может помочь справиться с высокими нагрузками. Для предварительной настройки и настройки требуется немного времени.

Существует форк Redis с открытым исходным кодом, «KeyDB», который устранил необходимость в контрольных узлах с опцией активной реплики. Это позволяет узлу реплики принимать операции чтения и записи. Когда происходит аварийное переключение, HAProxy прекращает чтение / запись с отказавшим узлом и просто использует оставшийся активный узел, который уже синхронизирован. Отметка времени позволяет отказавшим узлам автоматически подключаться и повторно синхронизироваться без потери данных, когда они возвращаются в оперативный режим. Настройка проста, и для более высокого трафика вам не потребуется специальная предварительная настройка для прямого чтения на узел реплики и чтения / записи на главный. См. Пример активной репликации здесь . KeyDB также является многопоточным, что для некоторых приложений может быть альтернативой кластеризации, но действительно зависит от ваших потребностей.

Также есть пример настройки кластеризации вручную и с помощью инструмента create-cluster . Это те же шаги, если вы используете Redis (замените keydb на redis в инструкции)

Дополнительная информация к приведенным выше ответам

Кластер Redis

• Одна из основных целей кластера Redis - равномерно / равномерно распределять нагрузку на данные за счет сегментирования.

• Redis Cluster не использует согласованное хеширование, а использует другую форму сегментирования, в которой каждый ключ концептуально является частью того, что называется хеш-слотом.

• В кластере Redis есть 16384 хэш-слота. Каждый узел в кластере Redis отвечает за подмножество хэш-слотов, поэтому, например, у вас может быть кластер с 3 узлами, где:

  Узел A содержит хэш-слоты от 0 до 5500, узел B содержит хэш-слоты от 5501 до 11000, узел C содержит хэш-слоты от 11001 до 16383

Это позволяет нам легко добавлять и удалять узлы в кластере. Например, если мы хотим добавить новый узел D, нам нужно переместить некоторый хэш-слот из узлов A, B, C в D.

• Кластер Redis поддерживает структуру master-slave, вы можете создавать подчиненные A1, B1, C2 вместе с мастерами A, B, C при создании кластера, поэтому, когда мастер B выходит из строя, подчиненный B1 продвигается как мастер

Вам не нужна дополнительная обработка отказа при использовании Redis Cluster, и вам определенно не следует указывать экземпляры Sentinel на каком-либо из узлов кластера.

Итак, с практической точки зрения, что вы получаете с Redis Cluster?

1. Возможность автоматического разделения набора данных между несколькими узлами.

2. Возможность продолжить операции, когда подмножество узлов испытывает сбой или не может связаться с остальной частью кластера.

Redis Sentinel

• 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