Redis Sentinel

У цій статті піде мова про Sentinel - один із способів забезпечення високої доступності Redis. Забігаючи наперед, скажу, що Redis Sentinel не надає можливостей шардингу (sharding), тобто для збільшення простору збереження даних необхідно збільшувати кількість оперативної пам’яті сервера.

Дуже раджу попередньо ознайомитись з простою реплікацією Redis, про яку я писав дещо раніше. У двох словах, Redis Sentinel - це звичайна реплікація Redis, але з можливістю автоматичного міграції майстра на інший працюючий вузол, що був у реплікації. Після такої міграції майстра, попередній майстер, завдяки додатковому демону Sentinel, автоматично переконфігуровується в слейв, який може використовуватись лише для читання.

Для налаштування Redis Sentinel використаємо такі адреси:

192.168.1.39
192.168.1.42
192.168.1.43

Установимо пакети redis-server та redis-sentinel на кожен із серверів. У якості дистрибутиву я обрав останню LTS Ubuntu - 16.04. Зі стандартного репозиторію встановимо Redis та Sentinel:

# apt install redis-server
# apt install redis-sentinel

Зрештою, сервер Redis займе звичний порт 6379, а sentinel - 26379. Ясна річ, що ці порти мають бути відкритими в фаєрволі, якщо такий є.

Перезавантажимо Redis та перевіримо його роботу:

# redis-cli ping
PONG

Конфігурація кластера Sentinel не має викликати особливих труднощів. Перше, що необхідно перевірити - це те чи відкритий порт Redis для віддаленої роботи:

# vim /etc/redis/redis.conf
...
bind 0.0.0.0
...

Порт 6379 має працювати на нелокальному інтерфейсі для взаємодії Redis-процесу з іншими вузлами. Ця опція має приймати аналогічне значення і для Sentinel сервісу в /etc/redis/sentinel.conf.

Налаштовуємо Sentinel-процес:

# vim /etc/redis/sentinel.conf
...
sentinel monitor mymaster 192.168.1.39 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
...

Puppet. Arrays of values from Hiera

Це вже буде п'ята стаття про Puppet, котру я розміщую у своєму блозі. Раніше я писав про masterless конфігурацію, клієнт-сервер і навіть про установку та конфігурацію Foreman, що по замовчуванню також працює з Puppet. Наразі піде мова про інструмент організації ієрархії Hiera.

Якщо говорити коротко і не вдаваючись в подробиці, Hiera - це спосіб опису змінних що стосуються окремого хосту чи групи хостів. Тобто змінні, що оголошені для групи віртуальних машин, можуть перезаписуватись іншими значеннями, що описані для конкретної машини, рівнем вище. На практиці це виглядає так:

# cat hiera.yaml

:backends:
  - yaml
:yaml:
  :datadir: /etc/puppet/hieradata
:merge_behavior: deeper
:hierarchy:
  - "nodes/%{::environment}/%{::hostname}"
  - "%{::environment}"
  - "versions"

Тобто yaml-файли, що знаходяться вище в переліку hierarchy мають вищий пріоритет оголошення змінних. Наприклад, якщо змінна variable буде описана в nodes/dev.my.com/host.yaml та nodes/dev.my.com.yaml то пріоритетнішим буде вважатись значення, що описане в nodes/dev.my.com/host.yaml ("nodes/%{::environment}/%{::hostname}").

Звісно, що на вхід ці дані приймає Puppet і, в залежності від значень змінних, виконує відповідні інструкції. Надалі в цій статті піде мова про те, як оголосити асоціативний масив (в термінології Python - це словник) в Hiera і яку користь з цього можна отримати.

Як приклад демонстрації цього оберемо задачу по налаштуванню програми Сurator, за допомогою якої ми будемо проводити очистку старих індексів Elasticsearch.

Redis Replication: Master-Slave

Декілька тижнів тому, я писав базові можливості Redis та як з ним працювати. Також я обіцяв продовжити цикл статей про Редіс і розповісти про високу доступність, кластеризацію та реплікацію цього сервісу. Отже цього разу мова піде про вбудовану в Redis асинхронну реплікацію Master-Slave.

Redis має вбудовану Master-Slave реплікацію і особливості її наступні:

• Асинхронність, що на практиці означає, що дані лише з часом потрапляють на слейв. З версії 2.8 слейв періодично надсилає майстру підтвердження щодо того, скільки даних було cкопійовано.
• Майстер може мати декілька слейвів одночасно
• Слейви можуть бути підключені каскадно один до одного. Тобто для кожного наступного слейву, попередній слейв виступатиме джерелом даних для реплікації.
• Процес реплікації є неблокуючим для майстра. Це значить, що майстер продовжує відповідати на всі запити, навіть якщо слейв запитав початкову синхронізацію
• Процес реплікації також не є блокуючим і для слейвів, у разі, якщо в конфігураційних файлах дозволено використання старого набору даних для відповіді на запити. Інакше, є можливість заборонити такі дії і слати помилки клієнтам, якщо процес реплікації зупинений. 
• Реплікація може використовуватись для масштабування операцій читання: чим більше слейвів - тим швидше відбуваються операції читання, і тим більшу кількість запитів мають можливість обробити сервера. У разі падіння діючого майстра - слейв можна зробити новим майстром. Тобто слейви можуть використовуватись лише для читання, зі зрозумілих причин операції запису на них заблоковані.

Більш того, опціонально можна вимкнути механізм(и) збереження даних на диск на майстрі, задля підвищення швидкості його роботи. Так як слейви все реплікують - вони і будуть джерелом наповнення даних у разі падіння останнього. Але є одне але: у такому разі автозапуск Redis-процесу необхідно заборонити, адже інакше відсутні дані майстра (дивно звучить), після його можливого падіння, скопіюються і на слейви, що призведе до повного видалення баз. Але навіть так це достатньо ризиковано.