Во-первых, Sentinel не является балансировщиком нагрузки или прокси для Redis.
Во-вторых, не все неудачи — это смерть хоста. Иногда сервер ненадолго зависает, иногда отключается сетевой кабель и т. д. В связи с этим не рекомендуется запускать Sentinel на тех же хостах, что и ваш экземпляр Redis. Если вы используете Sentinel для управления аварийным переключением, все, что меньше трех Sentinel, работающих на узлах, отличных от вашего главного и подчиненных устройств Redis, вызывает проблемы.
Sentinel использует механизм кворума для голосования по отказоустойчивости и ведомому серверу. Имея менее двух часовых, вы рискуете разделить мозг, когда два или более серверов Redis считают себя главными.
Представьте себе сценарий, в котором вы запускаете два сервера и запускаете дозорный на каждом. Если вы потеряете один из них, вы потеряете надежную возможность аварийного переключения.
Клиенты подключаются к Sentinel только для получения информации о текущем основном соединении. Каждый раз, когда клиент теряет соединение, он повторяет этот процесс. Sentinel не является прокси для Redis — команды для Redis идут непосредственно в Redis.
Единственная надежная причина для запуска Sentinel с менее чем тремя сигнальными устройствами — это обнаружение служб, что означает отказ от использования его для управления аварийным переключением.
Рассмотрим сценарий с двумя хостами:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis slave + sentinel 2 (Quorum 1)
Если узел B временно потеряет сетевое подключение к узлу A в этом сценарии, узел B продвинет себя до главного. Теперь у вас есть:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis master + sentinel 2 (Quorum 1)
Любым клиентам, которые подключаются к Sentinel 2, будет указано, что хост B является ведущим, тогда как клиентам, которые подключаются к Sentinel 1, будет указано, что хост A является ведущим (что, если ваши Sentinels находятся за балансировщиком нагрузки, означает половину ваших клиентов).
Таким образом, для получения минимально приемлемого надежного управления аварийным переключением вам необходимо выполнить следующее:
Host A: Redis master
Host B: Redis Slave
Host C: Sentinel 1
Host D: Sentinel 2
Host E: Sentinel 2
Ваши клиенты подключаются к часовым и получают текущий мастер для экземпляра Redis (по имени), а затем подключаются к нему. Если мастер умирает, клиент должен разорвать соединение, после чего клиент снова подключится к Sentinel и получит новую информацию.
Насколько хорошо каждая клиентская библиотека справляется с этим, зависит от библиотеки.
В идеале хосты C, D и E находятся на тех же хостах, откуда вы подключаетесь к Redis (т. е. на клиентском хосте). или представляют собой хорошую выборку, которую они получили. Основная цель здесь — убедиться, что вы проверяете, откуда вам нужно подключиться к Redis. В противном случае поместите их в тот же DC/Rack/Region, что и клиенты.
Если вы хотите, чтобы ваши клиенты общались с балансировщиком нагрузки, постарайтесь, чтобы ваши Sentinels были на этих узлах LB, если это возможно, добавляя дополнительные хосты, не относящиеся к LB, по мере необходимости, чтобы получить нечетное количество Sentinels> 2. Исключением является, если ваш клиентские хосты являются динамическими в том смысле, что их количество непостоянно (например, они увеличиваются для трафика, уменьшаются в периоды замедления). В этом сценарии вы в значительной степени должны запускать свои Sentinels на хостах, отличных от клиента и сервера redis.
Обратите внимание, что если вы сделаете это, вам нужно будет написать демон, который отслеживает канал Sentinel PUBSUB для события главного переключателя, чтобы обновить LB, который вы должны настроить так, чтобы он общался только с текущим мастером (никогда не пытайтесь общаться с обоими). Это требует больше работы, но позволяет использовать Sentinel прозрачно для клиента, который знает только, что нужно общаться с IP/портом LB.
person
The Real Bill
schedule
04.02.2015
