Нужен ли Redis Cluster Sentinel?

С помощью Gitlab Enterprise Edition вы можете использовать пакет Omnibus для настройки нескольких машин с помощью Deamond Daemon.

Redis Sentinel и Fix-Slave-Config Проблема: Redis Node устанавливается как раб двух мастеров, когда это не должно быть.

Я использовал Redis Sentinel для отказоустойчивости в большом флоте Redis, состоящем из 12 стражных и более 500 осколков, каждый с одним мастером и одним рабом. Тем не менее, я столкнулся с странной проблемой, когда определенные узлы Redis неоднократно выпускают команду +Fix-Slave-Config Sentinels. Это привело к тому, что некоторые рабы переключались между правильным мастером и другим неправильным мастером. Я не заметил эту проблему в меньшем масштабе. Я ищу совета о том, как исправить или отладить эту проблему.

Я наблюдал две конкретные проблемы:

А) Сообщения +fix-lave-config, которые я упоминал ранее.

Б) Страж.Файл CONF показывает, что у определенных рабов есть два мастера, даже если у них должен быть только один.

Первоначально флот имеет определенный подчиненный узел xxx.XXX.XXX.177 с мастером xxx.XXX.XXX.244 (формирование Шарда 188). Однако без каких -либо перебоев в узле мастер этого раба переключается на XXX.XXX.XXX.96 (который является мастером Shard 188), а затем обратно к правильному мастеру, и этот цикл повторяется. Я проверил это, получив доступ к подчиненным и мастер-узлам и используя команду Redis-Cli Info. Все узлы Redis запускаются с правильной конфигурацией, и все узлы Sentinel имеют правильную конфигурацию в своем Sentinel.conf файлы. Когда я запрашиваю каждый стражи, они все имеют один и тот же список мастеров после каждого смены рабов-мастера.

После проверки файлов журналов моих 12 Стражных, я вижу, что каждую минуту есть сообщение с фиксированным складом-конфигурацией. Вот некоторые примеры:

Sentinel #8: 20096: x 22 октября 01:41:49.793 * +Fix-Slave-Config Slave xxx.XXX.XXX.177: 6379 xxx.XXX.XXX.177 6379 @ shard-188 xxx.XXX.XXX.96 6379
Sentinel #1: 9832: x 22 октября 01:42:50.795 * +Fix-Slave-Config Slave xxx.XXX.XXX.177: 6379 xxx.XXX.XXX.177 6379 @ shard-172 xxx.XXX.XXX.244 6379
Sentinel #6: 20528: x 22 октября 01:43:52.458 * +Fix-Slave-Config Slab xxx.XXX.XXX.177: 6379 xxx.XXX.XXX.177 6379 @ shard-188 xxx.XXX.XXX.96 6379
Sentinel #10: 20650: x 22 октября 01:43:52.464 * +Fix-Slave-Config Slab xxx.XXX.XXX.177: 6379 xxx.XXX.XXX.177 6379 @ shard-188 xxx.XXX.XXX.96 6379
Sentinel #2: 20838: x 22 октября 01:44:53.489 * +Fix-Slave-Config Slave xxx.XXX.XXX.177: 6379 xxx.XXX.XXX.177 6379 @ shard-172 xxx.XXX.XXX.244 6379

Когда я запускаю команду Sentinel Masters, я заметил что -то странное. В случае 1, Shard-188 имеет два раба вместо одного. Та же схема наблюдается, когда xxx.XXX.XXX.177 падает под Шард-172 или Шард-182:

Случай 1) Мастер – XXX.XXX.XXX.244 и XXX.XXX.XXX.177 – один из его рабов:

183) 1) «Имя»
2) “Шард-172”
3) “IP”
4) “xxx.XXX.XXX.244 “
5) “порт”
6) “6379”
7) “Runid”
8) “CA02DA1F0002A25A880E6765AED306B1857AE2F7”
9) «Флаги»
10) “Мастер”
11) «Отказ от команд»
12) “0”
13) “Последний пинг-заседай”
14) “0”
15) «Последний-пинг-реппи»
16) “14”
17) “Последний пинг-зарплата”
18) “14”
19) «Даутер-мелисекунд»
20) “30000”
21) “Info-Refresh”
22) “5636”
23) «Расчет роле»
24) “Мастер”
25) «РОЛИЧЕСКОЕ Время»
26) “17154406”
27) “config-epoch”
28) “0”
29) “Число-славы”
30) “1”
31) “NUM-METHER-SENTINELS”
32) “12”
33) «Кворум»
34) “7”
35) «Неудача времени»
36) “60000”
37) “Параллельные синхронизации”
38) “1”
72) 1) «Имя»
2) “Шард-188”
3) “IP”
4) “xxx.XXX.XXX.96 “
5) “порт”
6) “6379”
7) “Runid”
8) “95CD3A457EF71FC91FF1A1C5A6D5D4496B266167”
9) «Флаги»
10) “Мастер”
11) «Отказ от команд»
12) “0”
13) “Последний пинг-заседай”
14) “0”
15) «Последний-пинг-реппи»
16) “927”
17) “Последний пинг-зарплата”
18) “927”
19) «Даутер-мелисекунд»
20) “30000”
21) “Info-Refresh”
22) “5333”
23) «Расчет роле»
24) “Мастер”
25) «РОЛИЧЕСКОЕ Время»
26) “17154312”
27) “config-epoch”
28) “0”
29) “Число-славы”
30) “2”
31) “NUM-METHER-SENTINELS”
32) “12”
33) «Кворум»
34) “7”
35) «Неудача времени»
36) “60000”
37) “Параллельные синхронизации”
38) “1”

Случай 2) Мастер – xxx.XXX.XXX.96 и XXX.XXX.XXX.177 – один из его рабов:

79) 1) «Имя»
2) “Шард-172”
3) “IP”
4) “xxx.XXX.XXX.244 “
5) “порт”
6) “6379”
7) “Runid”
8) “CA02DA1F0002A25A880E6765AED306B1857AE2F7”
9) «Флаги»
10) “Мастер”
11) «Отказ от команд»
12) “0”
13) “Последний пинг-заседай”
14) “0”
15) «Последний-пинг-реппи»
16) “1012”
17) “Последний пинг-зарплата”
18) “1012”
19) «Даутер-мелисекунд»
20) “30000”
21) “Info-Refresh”
22) “1261”
23) «Расчет роле»
24) “Мастер”
25) «РОЛИЧЕСКОЕ Время»
26) “17059720”
27) “config-epoch”
28) “0”
29) “Число-славы”
30) “1”
31) “NUM-METHER-SENTINELS”
32) “12”
33) «Кворум»
34) “7”
35) «Неудача времени»
36) “60000”
37) “Параллельные синхронизации”
38) “1”
273) 1) «Имя»
2) “Шард-188”
3) “IP”
4) “xxx.XXX.XXX.96 “
5) “порт”
6) “6379”
7) “Runid”
8) “95CD3A457EF71FC91FF1A1C5A6D5D4496B266167”
9) «Флаги»
10) “Мастер”
11) «Отказ от команд»
12) “0”
13) “Последний пинг-заседай”
14) “0”
15) «Последний-пинг-реппи»
16) “886”
17) “Последний пинг-зарплата”
18) “886”
19) «Даутер-мелисекунд»
20) “30000”
21) “Info-Refresh”
22) “5333”
23) «Расчет роле»
24) “Мастер”
25) «РОЛИЧЕСКОЕ Время»
26) “17154312”
27) “config-epoch”
28) “0”
29) “Число-славы”
30) “2”
31) “NUM-METHER-SENTINELS”
32) “12”
33) «Кворум»
34) “7”
35) «Неудача времени»
36) “60000”
37) “Параллельные синхронизации”
38) “1”

Это детали моей проблемы с Redis Sentinel и проблемой Fix-Slave-Config. Похоже, что некоторые рабы устанавливаются как рабы двух мастеров, что вызывает неожиданное поведение в моем кластере Redis. Я ищу решение этой проблемы и буду признателен за любыми советами или предложениями.

Нужен ли Redis Cluster Sentinel

С помощью Gitlab Enterprise Edition вы можете использовать пакет Omnibus для настройки нескольких машин с помощью Deamond Daemon.

Redis Sentinel и Fix-Slave-Config Проблема: Redis Node устанавливается как раб двух мастеров, когда это не должно быть.

ВОЗМОЖНО, АДРЕСАНА Экттрон, в то время как.

Я пытаюсь использовать Sentinel для отказоустойчивости в большом флоте Redis (12 Sentinels, 500+ Shard of One Master и по одному рабу каждый) каждый). Я сталкиваюсь с очень странной проблемой, в которой мои стражи неоднократно выпускают команду +Fix-Slave-Config для определенных узлов Redis, и результатом является то, что некоторые рабы переключаются между правильным мастером и другим неправильным мастером. Я не заметил, что это происходит в меньшем масштабе, для того, что оно стоит. Любой совет о том, что исправить или дальнейшее отладку?

Я заметил две конкретные проблемы:

A) +Сообщения Fix-Slave-Config, как указано выше.

Б) Страж.CONF показывает определенных рабов, имеющих два мастера (у них должен быть только один)

Флот в своем стартовом состоянии имеет определенный подчиненный узел xxx.XXX.XXX.177 с мастером xxx.XXX.XXX.244 (вместе они составляют Shard 188 во флоте). Без каких -либо перебоев в узле мастер раба переключается на XXX.XXX.XXX.96 (Мастер для Шарда 188), а затем назад, а затем вперед. Это подтверждается SSHING в рабов и главных узлах и проверяет информацию Redis-CLI. Все узлы Redis начались в правильной конфигурации. Все узлы Sentinel имели правильную конфигурацию в их Sentinel.конфликт. Каждый стражи имеет один и тот же список мастеров, когда я запрошу их после каждого из этих рабов-изменений.

В моих 12 часовых, следующее зарегистрировано. Каждую минуту отправлено сообщение +Fix-Slave-Config:

Sentinel #8: 20096: x 22 октября 01:41:49.793 * +Fix-Slave-Config Slave xxx.XXX.XXX.177: 6379 xxx.XXX.XXX.177 6379 @ shard-188 xxx.XXX.XXX.96 6379
Sentinel #1: 9832: x 22 октября 01:42:50.795 * +Fix-Slave-Config Slave xxx.XXX.XXX.177: 6379 xxx.XXX.XXX.177 6379 @ shard-172 xxx.XXX.XXX.244 6379
Sentinel #6: 20528: x 22 октября 01:43:52.458 * +Fix-Slave-Config Slab xxx.XXX.XXX.177: 6379 xxx.XXX.XXX.177 6379 @ shard-188 xxx.XXX.XXX.96 6379
Sentinel #10: 20650: x 22 октября 01:43:52.464 * +Fix-Slave-Config Slab xxx.XXX.XXX.177: 6379 xxx.XXX.XXX.177 6379 @ shard-188 xxx.XXX.XXX.96 6379
Sentinel #2: 20838: x 22 октября 01:44:53.489 * +Fix-Slave-Config Slave xxx.XXX.XXX.177: 6379 xxx.XXX.XXX.177 6379 @ shard-172 xxx.XXX.XXX.244 6379

Вот результат команды Sentinel Masters. Странно то, что у Shard-188 есть два раба, когда на самом деле он должен иметь только 1. Вывод выглядит так же для когда xxx.XXX.XXX.177 находится под Шардом-172 и Шардом-182.

Случай 1) xxx.XXX.XXX.244 – мастер XXX.XXX.XXX.177

183) 1) «Имя»
2) “Шард-172”
3) “IP”
4) “xxx.XXX.XXX.244 ”
5) “порт”
6) “6379”
7) “Runid”
8) “CA02DA1F0002A25A880E6765AED306B1857AE2F7”
9) «Флаги»
10) “Мастер”
11) «Отказ от команд»
12) “0”
13) “Последний пинг-заседай”
14) “0”
15) «Последний-пинг-реппи»
16) “14”
17) “Последний пинг-зарплата”
18) “14”
19) «Даутер-мелисекунд»
20) “30000”
21) “Info-Refresh”
22) “5636”
23) «Расчет роле»
24) “Мастер”
25) «РОЛИЧЕСКОЕ Время»
26) “17154406”
27) “config-epoch”
28) “0”
29) “Число-славы”
30) “1”
31) “NUM-METHER-SENTINELS”
32) “12”
33) «Кворум»
34) “7”
35) «Неудача времени»
36) “60000”
37) “Параллельные синхронизации”
38) “1”
72) 1) «Имя»
2) “Шард-188”
3) “IP”
4) “xxx.XXX.XXX.96 ”
5) “порт”
6) “6379”
7) “Runid”
8) “95CD3A457EF71FC91FF1A1C5A6D5D4496B266167”
9) «Флаги»
10) “Мастер”
11) «Отказ от команд»
12) “0”
13) “Последний пинг-заседай”
14) “0”
15) «Последний-пинг-реппи»
16) “927”
17) “Последний пинг-зарплата”
18) “927”
19) «Даутер-мелисекунд»
20) “30000”
21) “Info-Refresh”
22) “5333”
23) «Расчет роле»
24) “Мастер”
25) «РОЛИЧЕСКОЕ Время»
26) “17154312”
27) “config-epoch”
28) “0”
29) “Число-славы”
30) “2”
31) “NUM-METHER-SENTINELS”
32) “12”
33) «Кворум»
34) “7”
35) «Неудача времени»
36) “60000”
37) “Параллельные синхронизации”
38) “1”

Случай 2) xxx.XXX.XXX.96 – мастер XXX.XXX.XXX.177

79) 1) «Имя»
2) “Шард-172”
3) “IP”
4) “xxx.XXX.XXX.244 ”
5) “порт”
6) “6379”
7) “Runid”
8) “CA02DA1F0002A25A880E6765AED306B1857AE2F7”
9) «Флаги»
10) “Мастер”
11) «Отказ от команд»
12) “0”
13) “Последний пинг-заседай”
14) “0”
15) «Последний-пинг-реппи»
16) “1012”
17) “Последний пинг-зарплата”
18) “1012”
19) «Даутер-мелисекунд»
20) “30000”
21) “Info-Refresh”
22) “1261”
23) «Расчет роле»
24) “Мастер”
25) «РОЛИЧЕСКОЕ Время»
26) “17059720”
27) “config-epoch”
28) “0”
29) “Число-славы”
30) “1”
31) “NUM-METHER-SENTINELS”
32) “12”
33) «Кворум»
34) “7”
35) «Неудача времени»
36) “60000”
37) “Параллельные синхронизации”
38) “1”
273) 1) «Имя»
2) “Шард-188”
3) “IP”
4) “xxx.XXX.XXX.96 ”
5) “порт”
6) “6379”
7) “Runid”
8) “95CD3A457EF71FC91FF1A1C5A6D5D4496B266167”
9) «Флаги»
10) “Мастер”
11) «Отказ от команд»
12) “0”
13) “Последний пинг-заседай”
14) “0”
15) «Последний-пинг-реппи»
16) “886”
17) “Последний пинг-зарплата”
18) “886”
19) «Даутер-мелисекунд»
20) “30000”
21) “Info-Refresh”
22) “5762”
23) «Расчет роле»
24) “Мастер”
25) «РОЛИЧЕСКОЕ Время»
26) “17059758”
27) “config-epoch”
28) “0”
29) “Число-славы”
30) “2”
31) “NUM-METHER-SENTINELS”
32) “12”
33) «Кворум»
34) “7”
35) «Неудача времени»
36) “60000”
37) “Параллельные синхронизации”
38) “1”

Мой стартовый стражи.CONF для каждого Стража

MaxClients 20000
уведомление о логлевеле
logfile “/home/redis/logs/sentinel.бревно”
Sentinel Monitor Shard-172 Redis-B-172 7
Sentinel Down-After-Milliseconds Shard-172 30000
Sentinel Shopk-Timeout Shard-172 60000
Sentinel Parallel-Syncs Shard-172 1
.
Sentinel Monitor Shard-188 Redis-B-188 7
Sentinel Down-After-Milliseconds Shard-188 30000
Sentinel Shopk-Timeout Shard-188 60000
Sentinel Parallel-Syncs Shard-188 1

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

Sentinel Monitor Shard-172 XXX.XXX.XXX.244 6379 7
Sentinel Shopk-Timeout Shard-172 60000
Sentinel config-epoch shard-172 0
Sentinel Leader-Epoch Shard-172 0
Sentinel известный сол-шар Шард-172 XXX.XXX.XXX.177 6379 Sentinel известный Sentinel Shard-172 .
.
Sentinel Monitor Shard-188 XXX.XXX.XXX.96 6379 7
Sentinel Shopk-Timeout Shard-188 60000
Sentinel config-epoch shard-188 0
Sentinel Leader-Epoch Shard-188 0
Sentinel известный сол-шард-188 xxx.XXX.XXX.194 6379 Sentinel Известный солевой Shard-188 XXX.XXX.XXX.177 6379
Sentinel известный Sentinel Shard-188 .

Репликация и переработка Redis с Omnibus gitlab (Самооценка премиум -класса)

Примечание: это документация для пакетов Omnibus gitlab. Для использования собственного безвязшего Redis, следуйте соответствующей документации.

Примечание: в Redis Lingo, Primary называется Master. В этом документе используется первичный вместо мастера, за исключением настроек, где требуется мастер.

Использование Redis в масштабируемой среде возможно с помощью Начальный Икс Реплика Топология с сервисом Redis Sentinel для просмотра и автоматического запуска процедуры отказоустойчивости.

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

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

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

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

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

Запуск redis в масштабированной среде требует нескольких вещей:

  • Несколько экземпляров Redis
  • Запустить Redis в Начальный Икс Реплика топология
  • Несколько экземпляров Страж
  • Поддержка заявки и видимость всех экземпляров Sentinel и Redis

Redis Sentinel может справиться с наиболее важными задачами в среде HA, и это поможет сохранить серверы в Интернете с минимальными или без простоя. Redis sentinel:

  • Мониторы Начальный и Реплики случаи, чтобы увидеть, доступны ли они
  • Продвигает а Реплика к Начальный когда Начальный терпит неудачу
  • Демоты а Начальный к Реплика когда провалился Начальный возвращается в Интернете (чтобы предотвратить передачу данных)
  • Может быть запрошено приложением, чтобы всегда подключаться к текущему Начальный сервер

Когда Начальный не отвечает, это ответственность приложения (в нашем случае Gitlab) обрабатывать тайм -аут и воссоединение (запрос Страж для нового Начальный).

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

Рекомендуемая настройка

Для минимальной настройки необходимо установить пакет Omnibus gitlab в 3 независимый машины, оба с Редис и Страж:

  • Redis Primary + Sentinel
  • Redis Replica + Sentinel
  • Redis Replica + Sentinel

Если вы не уверены или не понимаете, почему и откуда взялось количество узлов, прочтите обзор настройки Redis и обзор настроек Sentinel.

Для рекомендованной настройки, которая может противостоять большему количеству сбоев, вам необходимо установить пакет Omnibus gitlab в 5 независимый машины, оба с Редис и Страж:

  • Redis Primary + Sentinel
  • Redis Replica + Sentinel
  • Redis Replica + Sentinel
  • Redis Replica + Sentinel
  • Redis Replica + Sentinel

Обзор настройки Redis

У вас должно быть не менее 3 серверов Redis: 1 первичные, 2 реплики, и они должны быть на независимых машинах (см. Пояснение выше).

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

Например, если у вас есть 6 узлов Redis, максимум 3 может быть одновременно вниз.

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

Все узлы Redis должны быть настроены одинаково и с аналогичными характеристиками сервера, как в условиях отказа Реплика может быть повышен как новый Начальный Серверами Стражи.

Репликация требует аутентификации, поэтому вам необходимо определить пароль для защиты всех узлов Redis и Sentinels. Все они имеют один и тот же пароль, и все экземпляры должны иметь возможность общаться друг с другом по сети.

Обзор настроек Sentinel

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

Всякий раз, когда кворум встречается, большинство Из всех известных узлов Sentinel должны быть доступны и доступны, чтобы они могли выбрать Sentinel лидер Кто принимает все решения, чтобы восстановить доступность услуги с помощью:

  • Продвижение нового Начальный
  • Преобразование другого Реплики и заставить их указывать на новый Начальный
  • Объявить о новом Начальный на все остальные режимы Sentinel
  • Пересмотреть старое Начальный и понизить до Реплика Когда он вернется в Интернете

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

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

Количество стражей в идеале всегда должно быть странный число, чтобы алгоритм консенсуса был эффективным в случае неудачи.

В топологии 3 узлов вы можете позволить. Всякий раз, когда большинство Сентинелей уходит, защита сетевых разделов предотвращает разрушительные действия и отказоустойчивость не запускается.

Вот некоторые примеры:

  • С 5 или 6 часовыми, максимум 2 могут спуститься на начало отказа.
  • С 7 часовыми, максимум 3 узлов могут выйти вниз.

А Лидер Выборы могут иногда провалить раунд голосования, когда Консенсус не достигается (см. Нечетное количество требований к узлам выше). В этом случае предпринимается новая попытка после количества времени, определенного в Sentinel [‘saikover_timeout’] (в миллисекундах).

Примечание: мы можем увидеть, где Sentinel [‘failover_timeout’] определяется позже.

Переменная на saffover_timeout имеет много разных вариантов использования. Согласно официальной документации:

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

Настройка Redis

Это раздел, в котором мы устанавливаем и устанавливаем новые экземпляры Redis.

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

Примечание: узлы Redis (как первичная, так и реплика) нуждаются в одном и том же пароле, определенном в Redis [‘пароль’] . В любое время во время переключения переключения, Стражи могут перенастроить узел и изменить его статус с первичной на реплику и наоборот.

Требования

Требования для установки Redis являются следующими:

  1. Предоставьте минимальное количество необходимого количества экземпляров, указанных в рекомендуемой разделе «Настройка».
  2. Мы Не Рекомендую установить Redis или Redis sentinel на тех же машинах, на которых работает приложение Gitlab, так как это ослабляет конфигурацию HA. Однако вы можете выбрать установку Redis и Sentinel в той же машине.
  3. Все узлы Redis должны иметь возможность общаться друг с другом и принимать входящие соединения по портам Redis (6379) и Sentinel (26379) (если вы не измените по умолчанию).
  4. Сервер, который размещает приложение Gitlab, должен иметь возможность получить доступ к узлам Redis.
  5. Защитите узлы от доступа от внешних сетей (Интернет), используя брандмауэр.

Переключение от существующей установки с одной машиной

Если у вас уже есть установка с одной машиной Gitlab, вам нужно сначала повторить с этой машины, прежде чем деактивировать экземпляр Redis внутри него.

Ваша установка для одной машины является начальной Начальный, и 3 других должны быть настроены как Реплика указывая на эту машину.

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

Внесите необходимые изменения в конфигурации и снова перезапустите новые узлы.

Отключить Redis в одной установке, редактирование/и т. Д./Gitlab/gitlab.RB:

Редис['давать возможность'] "=" ЛОЖЬ

Если вам не удастся повторить сначала, вы можете потерять данные (необработанные фоновые задания).

Шаг 1. Настройка первичного экземпляра Redis

  1. SSH в Начальный Redis Server.
  2. Загрузите/установите пакет Omnibus gitlab, который вы хотите использовать Шаги 1 и 2 со страницы загрузки Gitlab.
    • Убедитесь, что вы выбрали правильный пакет Omnibus, с той же версией и типом (сообщество, Enterprise Editions) вашей текущей установки.
    • Не выполняйте другие шаги на странице загрузки.
  3. Редактировать/и т. Д./Гитлаб/Гитлаб.RB и добавьте содержимое:

# Укажите роль сервера как 'redis_master_role' роли ['redis_master_role'] # IP -адрес, указывающий на локальный IP, который могут достичь других машин. # Вы также можете установить привязку на 0.0.0.0 ', которые слушают во всех интерфейсах. # Если вам действительно нужно привязать к внешнему доступному IP, сделайте # Конечно, вы добавляете дополнительные правила брандмауэра, чтобы предотвратить несанкционированный доступ. Редис['связывать'] "=" 10.0.0.1 ' # Определить порт, чтобы Redis мог прослушать запросы TCP, которые позволяют другие # Машины для подключения к нему. Редис['порт'] "=" 6379 # Установите аутентификацию пароля для Redis (используйте один и тот же пароль во всех узлах). Редис['пароль'] "=" 'Redis-Password-Goes-Here'

gitlab_rails['Auto_migrate'] "=" ЛОЖЬ

ПРИМЕЧАНИЕ. Вы можете указать несколько ролей, таких как Sentinel и Redis As: Roles [‘redis_sentinel_role’, ‘redis_master_role’] . Узнайте больше о ролях.

Шаг 2. Настройка экземпляров реплики Redis

  1. SSH в реплика Redis Server.
  2. Загрузите/установите пакет Omnibus gitlab, который вы хотите использовать Шаги 1 и 2 со страницы загрузки Gitlab.
    • Убедитесь, что вы выбрали правильный пакет Omnibus, с той же версией и типом (сообщество, Enterprise Editions) вашей текущей установки.
    • Не выполняйте другие шаги на странице загрузки.
  3. Редактировать/и т. Д./Гитлаб/Гитлаб.RB и добавьте содержимое:

# Укажите роль сервера как 'Redis_Replica_Role' роли ['Redis_Replica_Role'] # IP -адрес, указывающий на локальный IP, который могут достичь других машин. # Вы также можете установить привязку на 0.0.0.0 ', которые слушают во всех интерфейсах. # Если вам действительно нужно привязать к внешнему доступному IP, сделайте # Конечно, вы добавляете дополнительные правила брандмауэра, чтобы предотвратить несанкционированный доступ. Редис['связывать'] "=" 10.0.0.2 ' # Определить порт, чтобы Redis мог прослушать запросы TCP, которые позволяют другие # Машины для подключения к нему. Редис['порт'] "=" 6379 # Тот же пароль для аутентификации Redis, который вы настроили для первичного узла. Редис['пароль'] "=" 'Redis-Password-Goes-Here' # IP первичного узла Redis. Редис['master_ip'] "=" 10.0.0.1 ' # Порт первичного сервера Redis, некоммерческая переход на не дефолт. По умолчанию # до `6379. #Redis ['Master_port'] = 6379

Sudo Touch /etc/gitlab/skip-auto-reconfigure

ПРИМЕЧАНИЕ. Вы можете указать несколько ролей, таких как Sentinel и Redis As: Roles [‘redis_sentinel_role’, ‘redis_master_role’] . Узнайте больше о ролях.

Эти значения не должны быть снова изменены в/etc/gitlab/gitlab.RB после аварийного переключения, так как узлы управляются стражи, и даже после реконфигурации Gitlab-CTL они восстанавливают свою конфигурацию.

Шаг 3. Настройка экземпляров Redis Sentinel

ПРИМЕЧАНИЕ. Если вы используете экземпляр Redis Sentinel, обязательно исключите параметр reteplyepass из конфигурации Sentinel. Этот параметр заставляет клиентов сообщать о необходимой аутентификации NOAUTH. . Redis Sentinel 3.2.X не поддерживает аутентификацию пароля.

Теперь, когда настраиваются все серверы Redis, давайте настроим серверы Sentinel.

Если вы не уверены, что ваши серверы Redis работают и реплицируются правильно, прочитайте репликацию по устранению неполадок и исправьте ее, прежде чем продолжить настройку Sentinel.

У вас должно быть как минимум 3 сервера Redis Sentinel, и они должны быть каждым в независимой машине. Вы можете настроить их на тех же машинах, где вы настроили другие серверы Redis.

С помощью Gitlab Enterprise Edition вы можете использовать пакет Omnibus для настройки нескольких машин с помощью Deamond Daemon.

  1. SSH на сервер, который размещает Redis sentinel.
  2. Вы можете опустить этот шаг, если стражи размещены в том же узле, что и другие экземпляры Redis.Загрузите/установите пакет Omnibus gitlab Enterprise Edition, используя Шаги 1 и 2 со страницы загрузки Gitlab.
    • Убедитесь, что вы выбрали правильный пакет Omnibus, с той же версией, что и приложение Gitlab, работает.
    • Не выполняйте другие шаги на странице загрузки.
  3. Редактировать/и т. Д./Гитлаб/Гитлаб.RB и добавьте содержимое (если вы устанавливаете Стражи в том же узле, что и другие экземпляры Redis, некоторые значения могут быть дублированы ниже):

роли ['redis_sentinel_role'] # Должен быть одинаковым в каждом узле Стража Редис['master_name'] "=" 'gitlab-redis' # Тот же пароль для аутентификации Redis, который вы настроили для первичного узла. Редис['основной пароль'] "=" 'Redis-Password-Goes-Here' # IP первичного узла Redis. Редис['master_ip'] "=" 10.0.0.1 ' # Определить порт, чтобы Redis мог прослушать запросы TCP, которые позволяют другие # Машины для подключения к нему. Редис['порт'] "=" 6379 # Порт первичного сервера Redis, некоммерческая переход на не дефолт. По умолчанию # до `6379. #Redis ['Master_port'] = 6379 ## Настроить Sentinel Страж['связывать'] "=" 10.0.0.1 ' # Порт, который Стражи прослушивает, неудобно переключиться на не дефолт. По умолчанию # до `26379`. # sentinel ['port'] = 26379 ## Quorum должен отражать сумму голосования, которые требуются, чтобы начать отказоустойчивость. Значение ## не должно быть больше, чем сумма стражей. ## ## Кворум можно использовать для настройки Sentinel двумя способами: ## 1. Если кворум установлен на значение меньше, чем большинство стражей ## мы развертываем, мы в основном делаем Sentinel более разумным для первичных сбоев, ## запускает отказоустойчивость, как только даже меньшинство стражей больше не станет ## способен поговорить с основным. ## 1. Если кворум устанавливается на значение, превышающее большинство стражей, мы ## Сделать Sentinel, способный к переключению, только когда есть очень большое количество (больше ##, чем большинство) хорошо связанных стражных, которые согласны с тем, что первичное существовало.с Страж['Quorum'] "=" 2 ## рассмотрите неречение сервера вниз после x суммы MS. # sentinel ['down_after_milliseconds'] = 10000 ## указывает тайм -аут в миллисекундах. Он используется во многих отношениях: ## ## - Время, необходимое для повторного запуска после переключения после предыдущего аварийного переключения ## уже пытался против того же первичного срока ## времена тайм -аут для переключения. ## ## - Время, необходимое для копирования реплики, на неправильную первичку в соответствии с ## к конфигурации тока Стража, которая должна быть вынуждена воспроизвести ## с правильной первичной ## В тот момент, когда Страж обнаружил неправильную конфигурацию). ## ## - время, необходимое для отмены переключения, которое уже находится ## не произвела никаких изменений конфигурации (никому никому нет реплики ## подтверждено повышенной копией). ## ## - максимальное время, когда пробегает, ожидает, пока все реплики будут ## перенастроен как реплики нового первичного. Однако даже после этого времени ## все в любом случае реконфигурированы Стражи, но не с помощью ## точная прогрессия параллельных синхронизий, как указано. # sentinel ['failover_timeout'] = 60000

Sudo Touch /etc/gitlab/skip-auto-reconfigure

Шаг 4. Настройка приложения Gitlab

Последняя часть – информировать основной сервер приложений Gitlab на серверах Redis Sentinels и учетных данных аутентификации.

Вы можете включить или отключить поддержку Sentinel в любое время в новых или существующих установках. С точки зрения приложения Gitlab, все, что им требуется, это правильные учетные данные для узлов Sentinel.

Несмотря на то, что он не требует списка всех узлов Sentinel, в случае сбоя, ему необходимо получить хотя бы один из перечисленных.

ПРИМЕЧАНИЕ. Следующие шаги должны быть выполнены на сервере приложений Gitlab, у которых в идеале не должно быть Redis или Sentinels для настройки HA.

  1. SSH на сервер, где установлено приложение Gitlab.
  2. Редактировать/и т. Д./Гитлаб/Гитлаб.RB и добавить/изменить следующие строки:

## должен быть одинаковым в каждом узле Стража Редис['master_name'] "=" 'gitlab-redis' ## тот же пароль для аутентификации Redis, который вы настроили для первичного узла. Редис['основной пароль'] "=" 'Redis-Password-Goes-Here' ## Список часовых с `host` и` port` gitlab_rails['redis_sentinels'] "=" [ 'хозяин' => 10.0.0.1 ', 'порт' => 26379>, 'хозяин' => 10.0.0.2 ', 'порт' => 26379>, 'хозяин' => 10.0.0.3 ', 'порт' => 26379> ]

Шаг 5. Включить мониторинг

Если вы включите мониторинг, он должен быть включен на все Redis Servers.

  1. Обязательно собирайте Consul_Server_Nodes, которые являются IP -адресами или записями DNS узлов сервера консул, для следующего шага. Обратите внимание, что они представлены как y.У.У.Y Консуль1.Гитлаб.пример.комму.Z.Z.Z
  2. Создать/редактировать/и т.д./gitlab/gitlab.RB и добавьте следующую конфигурацию:

# Включить обнаружение услуг для Прометея консул['давать возможность'] "=" истинный консул['monitoring_service_discovery'] "=" истинный # Заменить заполнители # Y.У.У.Y Консуль1.Гитлаб.пример.комму.Z.Z.Z # с адресами узлов консул -сервера консул['Конфигурация'] "="  retry_join: %w (y.У.У.Y Консуль1.Гитлаб.пример.комму.Z.Z.Z), > # Установите сетевые адреса, которые выслушают экспортеры node_exporter['Lister_Address'] "=" 0.0.0.0: 9100 ' redis_exporter['Lister_Address'] "=" 0.0.0.0: 9121 '

Пример минимальной конфигурации с 1 первичной, 2 реплики и 3 стражника

В этом примере мы считаем, что все серверы имеют внутренний сетевой интерфейс с IPS в 10.0.0.x диапазон, и что они могут подключаться друг к другу, используя эти IPS.

В реальном мире вы также установите правила брандмауэра, чтобы предотвратить несанкционированный доступ от других машин и блокировать трафик снаружи (Интернет).

Мы используем те же 3 узла с Редис + Страж Топология, обсуждаемая в обзоре настройки Redis и Обзор настройки Sentinel.

Вот список и описание каждого машина и назначен IP:

  • 10.0.0.1: Redis Primary + Sentinel 1
  • 10.0.0.2: Redis Replica 1 + Sentinel 2
  • 10.0.0.3: Redis Replica 2 + Sentinel 3
  • 10.0.0.4: Приложение Gitlab

После первоначальной конфигурации, если аварийное переключение инициируется узлами Sentinel, узлы REDIS реконфигурируются и Начальный изменяется навсегда (в том числе в Redis.conf) от одного узла к другому, пока не будет инициировано новое аварийное переключение.

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

Пример конфигурации для Redis Primary и Sentinel 1

роли ['redis_sentinel_role', 'redis_master_role'] Редис['связывать'] "=" 10.0.0.1 ' Редис['порт'] "=" 6379 Редис['пароль'] "=" 'Redis-Password-Goes-Here' Редис['master_name'] "=" 'gitlab-redis' # должен быть одинаковым в каждом узле Стража Редис['основной пароль'] "=" 'Redis-Password-Goes-Here' # то же значение, определенное в Redis ['пароль'] в первичном экземпляре Редис['master_ip'] "=" 10.0.0.1 ' # IP начального первичного экземпляра Redis #redis ['Master_port'] = 6379 # порт начального экземпляра первичного Redis, некоммерть к не дефолте Страж['связывать'] "=" 10.0.0.1 ' # sentinel ['port'] = 26379 # Неукомплектование к изменению порта по умолчанию Страж['Quorum'] "=" 2 # sentinel ['down_after_milliseconds'] = 10000 # sentinel ['failover_timeout'] = 60000

Пересмотреть Omnibus gitlab для изменений, которые вступят в силу.

Пример конфигурации для Redis Replica 1 и Sentinel 2

роли ['redis_sentinel_role', 'Redis_Replica_Role'] Редис['связывать'] "=" 10.0.0.2 ' Редис['порт'] "=" 6379 Редис['пароль'] "=" 'Redis-Password-Goes-Here' Редис['основной пароль'] "=" 'Redis-Password-Goes-Here' Редис['master_ip'] "=" 10.0.0.1 ' # IP первичного сервера Redis #Redis ['master_port'] = 6379 # порт первичного сервера Redis, некомментирование, чтобы измениться на не дефолт Редис['master_name'] "=" 'gitlab-redis' # должен быть одинаковым в каждом узле Стража Страж['связывать'] "=" 10.0.0.2 ' # sentinel ['port'] = 26379 # Неукомплектование к изменению порта по умолчанию Страж['Quorum'] "=" 2 # sentinel ['down_after_milliseconds'] = 10000 # sentinel ['failover_timeout'] = 60000

Пересмотреть Omnibus gitlab для изменений, которые вступят в силу.

Пример конфигурации для Redis Replica 2 и Sentinel 3

роли ['redis_sentinel_role', 'Redis_Replica_Role'] Редис['связывать'] "=" 10.0.0.3 ' Редис['порт'] "=" 6379 Редис['пароль'] "=" 'Redis-Password-Goes-Here' Редис['основной пароль'] "=" 'Redis-Password-Goes-Here' Редис['master_ip'] "=" 10.0.0.1 ' # IP первичного сервера Redis #Redis ['master_port'] = 6379 # порт первичного сервера Redis, некомментирование, чтобы измениться на не дефолт Редис['master_name'] "=" 'gitlab-redis' # должен быть одинаковым в каждом узле Стража Страж['связывать'] "=" 10.0.0.3 ' # sentinel ['port'] = 26379 # Неукомплектование к изменению порта по умолчанию Страж['Quorum'] "=" 2 # sentinel ['down_after_milliseconds'] = 10000 # sentinel ['failover_timeout'] = 60000

Пересмотреть Omnibus gitlab для изменений, которые вступят в силу.

Пример конфигурации для приложения Gitlab

Редис['master_name'] "=" 'gitlab-redis' Редис['основной пароль'] "=" 'Redis-Password-Goes-Here' gitlab_rails['redis_sentinels'] "=" [ 'хозяин' => 10.0.0.1 ', 'порт' => 26379>, 'хозяин' => 10.0.0.2 ', 'порт' => 26379>, 'хозяин' => 10.0.0.3 ', 'порт' => 26379> ]

Пересмотреть Omnibus gitlab для изменений, которые вступят в силу.

Расширенная конфигурация

Omnibus gitlab настраивает некоторые вещи за шторами, чтобы упростить жизнь Sysadmins. Если вы хотите знать, что происходит внизу, продолжайте читать.

Запуск нескольких кластеров Redis

Omnibus gitlab поддерживает запуск отдельных экземпляров Redis и Sentinel для разных классов постоянства.

Сорт Цель
кеш Хранить кэшированные данные.
очереди Магазин Sidekiq фоновые работы.
shared_state Магазин, связанные с сеансом и другие постоянные данные.
ActionCable Backend Pub/Sub -queuebure для ActionCable.
trace_chunks Хранить данные CI Trace Thunks.

Чтобы сделать эту работу с Sentinel:

  1. Настройте различные экземпляры Redis/Sentinels на основе ваших потребностей.
  2. Для каждого экземпляра приложения Rails отредактируйте ITS/etc/gitlab/gitlab.Файл RB:

gitlab_rails['redis_cache_instance'] "=" Redis_cache_url gitlab_rails['redis_queues_instance'] "=" Redis_queues_url gitlab_rails['redis_shared_state_instance'] "=" Redis_shared_state_url gitlab_rails['Redis_ActionCable_Instance'] "=" Redis_actioncable_url gitlab_rails['redis_trace_chunks_instance'] "=" Redis_trace_chunks_url # Настроить Стражи gitlab_rails['redis_cache_sentinels'] "=" [  хозяин: Redis_cache_sentinel_host, Порт: 26379 >,  хозяин: Redis_cache_sentinel_host2, Порт: 26379 > ] gitlab_rails['redis_queues_sentinels'] "=" [  хозяин: Redis_queues_sentinel_host, Порт: 26379 >,  хозяин: Redis_queues_sentinel_host2, Порт: 26379 > ] gitlab_rails['redis_shared_state_sentinels'] "=" [  хозяин: Shared_state_sentinel_host, Порт: 26379 >,  хозяин: Shared_state_sentinel_host2, Порт: 26379 > ] gitlab_rails['Redis_ActionCable_sentinels'] "=" [  хозяин: ActionCable_sentinel_host, Порт: 26379 >,  хозяин: ActionCable_sentinel_host2, Порт: 26379 > ] gitlab_rails['redis_trace_chunks_sentinels'] "=" [  хозяин: Trace_chunks_sentinel_host, Порт: 26379 >,  хозяин: Trace_chunks_sentinel_host2, Порт: 26379 > ]

  • URL -адреса Redis должны быть в формате: Redis: //: password@sentinel_primary_name, где:
    • Пароль – это пароль с открытым текстом для экземпляра REDIS.
    • Sentinel_primary_name-это первичное имя Sentinel с Redis [‘Master_Name’], например, Gitlab-Redis-Cache .

    судо gitlab-ctl Reonfigure

    Примечание. Для каждого класса Persistence Gitlab по умолчанию использует конфигурацию, указанную в Gitlab_Rails [‘redis_sentinels’], если только не переопределяется ранее описанными настройками.

    Контроль за рабочими услугами

    В предыдущем примере мы использовали redis_sentinel_role и redis_master_role, которые упрощают объем изменений конфигурации.

    Если вы хотите больше управления, вот что каждый устанавливает для вас автоматически при включении:

    ## Redis Sentinel Роль redis_sentinel_role['давать возможность'] "=" истинный # Когда роль Sentinel включена, также включены следующие службы Страж['давать возможность'] "=" истинный # Следующие службы отключены Редис['давать возможность'] "=" ЛОЖЬ начальная загрузка['давать возможность'] "=" ЛОЖЬ nginx['давать возможность'] "=" ЛОЖЬ Postgresql['давать возможность'] "=" ЛОЖЬ gitlab_rails['давать возможность'] "=" ЛОЖЬ почтовый зал['давать возможность'] "=" ЛОЖЬ ------- ## Redis Primary/Relica Роль redis_master_role['давать возможность'] "=" истинный # Включить только один из них redis_replica_role['давать возможность'] "=" истинный # Включить только один из них # Когда Redis Primary или Relica будет включена, следующие сервисы # включено выключено. Если роли Redis и Sentinel объединены, оба # Службы включены. # Следующие службы отключены Страж['давать возможность'] "=" ЛОЖЬ начальная загрузка['давать возможность'] "=" ЛОЖЬ nginx['давать возможность'] "=" ЛОЖЬ Postgresql['давать возможность'] "=" ЛОЖЬ gitlab_rails['давать возможность'] "=" ЛОЖЬ почтовый зал['давать возможность'] "=" ЛОЖЬ # Для роли Redis Replica, также измените эту настройку с по умолчанию «true» на «false»: Редис['владелец'] "=" ЛОЖЬ

    Вы можете найти соответствующие атрибуты, определенные в gitlab_rails.РБ .

    Поиск неисправностей

    дальнейшее чтение

    1. Справочные архитектуры
    2. Настройте базу данных
    3. Настройка NFS
    4. Настройка балансировщиков нагрузки

    Redis Sentinel

    Внимание. Умеренный механизм Redis Sentinel будет уйти в отставку в версии Creatio 7.18.3. Мы рекомендуем переключиться на Redis Cluster после обновления Creatio до версии 7.18.0.

    Механизм Redis Sentinel используется для обеспечения устойчивости к неисправности для репозитории Redis, используемых Creatio. Он предоставляет следующие функции:

    • Мониторинг. Sentinel гарантирует, что экземпляры мастера/раба работают правильно в Redis.
    • Уведомления. Sentinel предупреждает системные администраторы, если в Redis возникают какие -либо ошибки, связанные с экземпляром.
    • Автоматическое отказоустойчивость. Если экземпляр Redis Master работает не правильно, Sentinel продвигает один из рабов для мастера и перенастроет остальные для работы с новым мастер -экземпляром. Creatio также уведомляется о новом адресе подключения Redis.

    Внимание. Creatio не поддерживает кластеры Redis в версии 7.17.4 и раньше.

    Redis Sentinel – это распределенная система, которая предназначена для запуска нескольких экземпляров, которые сотрудничают вместе. Этот подход имеет следующие преимущества:

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

    Примечательные специфики стражи

    • Для надежного развертывания требуется не менее трех экземпляров Sentinel. Эти случаи должны быть помещены в компьютеры или виртуальные машины, которые, как полагают, терпят неудачу независимо, я. эн., Разломы, зарегистрированные этими экземплярами Стража, должны быть вызваны различными источниками. Например, компьютеры расположены в разных сетевых зонах.
    • Из -за асинхронной репликации распределенная система (Sentinel + Redis) не гарантирует, что все данные будут сохранены, если произойдет сбой.
    • Устойчивость к разлому конфигурации должна регулярно контролироваться и дополнительно подтверждать с помощью тестов, которые имитируют сбои.
    • Remapping порта Docker создает определенные проблемы с процессами Sentinel (см. Sentinel, Docker, NAT и возможные проблемы блока документации Sentinel).

    Требования к минимальной устойчивости к неисправности для Redis sentinel

    • M1, M2 – экземпляры Redis Master.
    • R1, R2, R3 – рабыня Redis.
    • S1, S2, S3 – экземпляры Sentinel.
    • C1 – это приложение Creatio.
    • [M2] является повышенным экземпляром (E. г., от раба до Мастера).

    Мы рекомендуем использовать конфигурацию как минимум с тремя экземплярами Redis и Sentinel (см. Пример 2: Базовая настройка с тремя блоками коробки ссора) документации). Эта конфигурация основана на трех узлах (компьютеры или виртуальные машины), каждая из которых содержит рабочие экземпляры как Redis, так и Sentinel (рис. 1). Два экземпляра Sentinel (S2 и S3) образуют кворум (количество экземпляров, необходимых для обеспечения устойчивости к разлому текущего главного экземпляра).

    инжир. 1 Конфигурация трех узлов: Quorum = 2

    scr_chapter_setup_redis_sentinel_3_pitts_configuration.png

    Во время регулярной работы клиентское приложение Creatio записывает свои данные в основной экземпляр (M1). Затем эти данные асинхронно реплицируются в рабские экземпляры (R2 и R3).

    Если экземпляр Master Redis (M1) становится недоступным, экземпляры Sentinel (S1 и S2) считают это сбоем и запустите процесс отказа. Один из экземпляров Redis Slave (R2 или R3) продвигается в мастер, что позволяет приложению использовать его вместо предыдущего мастер -экземпляра.

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

    Примечание. Другие возможные конфигурации, терпимые из неисправности, описаны в документации Sentinel .

    Проблемы сетевого разделения

    Если сетевое соединение потеряно, существует риск, что Creatio будет продолжать работать со старым экземпляром Master Redis (M1), в то время как недавно пропагандированный мастер -экземпляр ([M2]) уже был назначен (рис. 2).

    инжир. 2 сетевое разделение

    scr_chapter_setup_redis_sentinel_nerwork_spliting.png

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

    Мин-славы к записи 1 мин. Слава-макс-лаг 10

    В результате, если экземпляр Master Redis (M1) не сможет передавать данные, по крайней мере, одному экземпляру рабов, он прекратит получение данных через 10 секунд после первой попытки. Как только система восстановлена ​​с помощью экземпляров Sentinel, которые образуют кворум (S2 и S3), приложение Creatio (C1) будет перенастроено для работы с новым мастером (M2).

    Внимание. Если сеть восстановлена, мастер -экземпляр не сможет автоматически продолжить свою работу после остановки. Если оставшийся экземпляр Redis Slave (R3) также становится недоступным, система полностью перестанет работать.

    Системные Требования

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

    Рекомендуется развернуть Redis и Sentinel на Linux OS.

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

    Нужен ли Redis Cluster Sentinel?

    Охто

    Мы аррегировали подоаджолгн. SpoMOщHщ эtOй straoniцы mы smosememememopredetath, чto -aprosы otpra. То, что нужно?

    Эta -steraniцa otobrana -overshy -aTeх -stuчah -obra -aTeх -stu -y -y -ogdaTomAtiчeskymi -stri -stri -rah -strhe -strhe -strhe -stri -stri -stri -stri -stri -stri -rah -rah -stristriouri Котора. Straoniцa -oprepaneTeTeTeTeTOTOTOTO -opobrasthep -apoSle -o, kak -эat. ДО СОМОМОНТА.

    Иошнико -а -а -а -в -впологовый схлк -а -апросов. Esli-yspolheoute obhщiй dostup-vanterneTTHETHETHETHETHET,. Охраторс. Подеб.

    Проверка, в котором я, eSli -voAchephephephephe -yvodyte -sloжne -apro Эмами, Или,.