Translate

субота, 26 листопада 2016 р.

RabbitMQ Cluster. AMQP protocol

RabbitMQ - сервер черг, написаний на мові Erlang, що реалізує платформу обміну повідомленнями між компонентами програмної системи.

RabbitMQ побудований на фреймоворку Open Telecom Platform та реалізує стандарт обміну повідомленнями AMQP версії 0-9-1 (через плагіни також AMQP версії 1)

Для роботи з RabbitMQ існує багато готових бібліотек для основних мов програмування, що дозволяють без особливих надзусиль почати використовувати сервер у власній інфраструктурі.

Наразі розробкою RabbitMQ займається компанія Pivotal, що в свою чергу є підрозділом Dell. Код сервера відкритий і розповсюджується по ліцензії Mozilla Public License.

Перш за все розглянемо основні логічні одиниці, з яких складається процес роботи брокера повідомлень RabbitMQ (протоколу AMQP):
Отже, програма-генератор повідомлень (Producer) створює повідомлення і у разі, якщо в користувача, від якого вона працює, є права на їх запис у конкретний Virtual Host, повідомлення потрапляє до точки обміну (Exchange). У залежності від її типу та правил, за якою вона працює (Bindings), повідомлення записуються в черги (Queues). Далі вони відправляються до програм-споживачів (Consumers), що підписані на зміни до черг (push API), або ж останні самостійно їх забирають (pull API). У випадку push API споживачі повідомлень підписуються на зміни і, як результат, надсилають запити на реєстрацію (підписку) до черги. Кожен споживач має унікальний ідентифікатор, що зветься consumer tag. Він може використовуватись брокером для відписки останніх від черги.

середа, 2 листопада 2016 р.

Apache Kafka: Setup And Configuration

Apache Kafka - популярний сервер черг, що був створений для ефективної обробки великих обсягів даних в реальному часі. Кластер Kafka не лише гарно масштабується, але і має значно кращу продуктивність, в порівнянні з такими брокерами повідомлень, як ActiveMQ та RabbitMQ. Це зовсім не значить, що в останніх немає переваг.

Apache Kafka - це розробка компанії Linkedin, код якої було відкрито в 2011 році і пізніше переданий в інкубатор Apache. Сервер написаний на мові Scala, тож потребує Java-машину для роботи.

Що ж таке брокер повідомлень? Брокер повідомлень (сервер черг, система повідомлень) - це сервер, що відповідає за передачу даних від однієї програми (producer) до іншої (consumer). Брокер повідомлень допомагає абстрагуватись від того, як буде відбуватись обмін повідомленнями між програмами та зосередитись на написанні логіки програм, що працюють по обидва боки. Більш того, сервери черг дозволяють винести певну логіку на окремі сервери задля того, щоб основні потужності працювали швидко і без перебоїв, особливо якщо ця окрема логіка не термінова по часу виконання - щось на кшталт обробки фотографій для корисувачів і т.п. З іншого боку з брокерами повідомлень досить легко масштабувати споживачів (в т.ч. тимчасово), у разі якщо навантаження зросло чи ускладнилась логіка.
Також сервер черг корисно мати у разі, якщо програма-генератор повідомлень часом створює їх більше ніж програма-споживач може обробити, та деякі затримки у обробці цих повідомлень не є критичними. Наприклад, Rsyslog може слати логи напряму в Logstash, але якщо Rsyslog на деякий час почне генерувати їх більше, ніж останній може обробити, то Logstash може впасти, як зазвичай і відбувається. Коли ж в цю схему додати брокер Kafka між Rsyslog та Logstash, то перший буде все одразу віддавати в чергу, а останній по змозі все буде забирати з неї і обробляти. Більше того, часом Kafka-у використовують як основний лог-сервер, адже вона зберігає свої дані на диск.

четвер, 25 серпня 2016 р.

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
...

пʼятниця, 19 серпня 2016 р.

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.

неділя, 14 серпня 2016 р.

Redis Replication: Master-Slave

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

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

неділя, 24 липня 2016 р.

Redis Basics

Redis (REmote DIctionary Server) - високопродуктивна нереляційна база даних типу ключ-значення, розробку якої наразі фінансує Redis Labs, а раніше - Pivotal Software та VMware. Це програмне забезпечення з відкритим сирцевим кодом написане на мові C. Redis досить зрілий проект і має набір готових біндингів до різноманітних мов програмування.

Redis дуже часто розглядають як заміну Memcached, адже доступ до значень також відбувається по ключу. Проте він, на відміну від останнього, володіє купою переваг, серед яких:
  • Можливість з певною частотою зберігати дані з оперативної в постійну пам'ять. Тож у разі падіння демона дані будуть наявні після рестарту. У останніх версіях Redis є можливість вести лог операцій запису. Щось на зразок бінлогу в MySQL.
  • Більше можливих типів даних, котрі можуть зберігатись. Redis, окрім рядків (strings), підтримує збереження масивів (lists), хеш-таблиць (hash tables), множин (sets), сортованих множин (sorted sets), масиви біт (bitmaps) та HyperLogLog. Останні по-суті базуються на рядках (strings), які мають свою власну семантику. Детальніше про них далі.
  • Реплікація (built-in), кластеризація (Redis Sentinel, Redis Cluster), шардинг (Redis Cluster), висока доступність (Redis Sentinel, Redis Cluster). Цього всього немає в ванільному Memcached, але воно так необхідне при створенні інфраструктур високої доступності.
  • Підтримка транзакцій. Команди можуть бути виконані групою, і у разі невиконання однієї із них - відбудеться повернення на попередній стан. Також команди можна виконувати пакетами (виконуємо пачку команд, потім отримуємо пачку результатів).
  • Підтримка механізму publish/subscribe. Програми, що використовують Redis, можуть створювати іменовані канали і додавати в них повідомлення, а інші програми, відповідно, можуть забирати дані з таких каналів. У моєму розумінні, це щось схоже на черги в RabbitMQ.

субота, 9 липня 2016 р.

Marvel. Monitoring Plugin for Elasticsearch

Півроку тому я писав статтю про Elasticsearch, його кластеризацію, основи роботи. Сьогодні ж поговоримо про способи його моніторингу, а саме установку Marvel. Одразу скажу, що він коштує достатньо космічних сум (проте безкоштовний для використання в DEV-середовищах) і не кожен бізнес може його дозволити собі.

Враховуючи ці ціни, можливо, краще спробувати відкриті альтернативи на кшталт Kopf чи Elasticsearch-head, про котрі я також згадував у власній статті. Проте, ймовірно, вони менш функціональні і призначені скоріше для моніторингу кластерних ресурсів: шардів, реплік, стану кластеру.

Опишу трохи майбутню тестову архітектуру. Розробники з Elastic рекомендують для Prod-середовищ виділяти окремий сервер для Marvel, адже останній логує свої сервісні дані та проводить певні розрахунки, котрі можуть впливати на завантаження самого Elasticsearch. Тому наша інсталяція складатиметься з вузлу Elasticsearch + Marvel-agent, котрий надсилатиме необхідні сервісні дані до іншого вузлу Elasticsearch, котрий буде зберігати їх локально, а Kibana та Marvel plugin, що будуть встановлені тут же, відображатимуть це все.


Установимо oracle-java8-jdk на обидва вузла кластера:

# add-apt-repository ppa:webupd8team/java
# aptitude update
# aptitude install oracle-java8-installer
# update-java-alternatives -s java-8-oracle

# java -version
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)

середа, 29 червня 2016 р.

Mesos. Cluster Management

Apache Mesos - це централізована відмовостійка система управління кластером. Вона розроблена для розподілених комп’ютерних середовищ задля забезпечення ізоляції ресурсів та зручного управління кластерами підлеглих вузлів (mesos slaves). Це новий ефективніший спосіб управління серверною інфраструктурою.

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

Mesos розподіляє ресурси CPU та пам’яті в кластері для задач в схожій манері як ядро Linux виділяє ресурси заліза між локальними процесами. По-суті, у випадку Mesos, це і є мікросервісами.

Уявімо собі, що є необхідність виконати різні типи задач. Для цього можна виділити окремі віртуальні машини (окремий кластер) для кожного типу. Ці віртуальні машини ймовірно не будуть повністю завантаженими і певний час будуть простоювати, тобто не працюватимуть з максимальною ефективністю. Якщо ж всі віртуальні машини для всіх задач об’єднати в єдиний кластер, ми можемо підвищити ефективність використання ресурсів і паралельно з тим підвищити швидкість їх виконання (у разі якщо задачі короткострокові чи віртуальні машини не завантажені повністю увесь час). Наступний малюнок, надіюсь, прояснить сказане:

Але це далеко не все. Кластер Mesos (із фреймворком до нього) здатен перестворювати окремі ресурси, у разі їх падіння, масштабувати ресурси вручну чи автоматично за певних умов і т.п.

субота, 11 червня 2016 р.

Sensu. Modern Monitoring

Моніторинг - це важлива складова будь-якої серверної архітектури. Найбільш популярні варіанти його організації - це Nagios та Zabbix. Проте вони мають багато недоліків. Основні з них - це необхідність описувати кожен сервер, що потребує спостереження, окремо на сервері моніторингу; необхідність розміщення клієнта та сервера в прямій доступності та брак гнучкості. Процес автоматичного додавання хостів в моніторинги, на зразок Nagios, не дуже легко автоматизується, адже про це в 1999 році, підозрюю, особливо не думали. І це вже не кажучи про проблеми маштабування, убогість програмних інтерфейсів і т.п.

Поставивши собі за мету вирішення згаданих вище проблем, з'явився проект Sensu. Він має дві версії: Sensu Core (free, opensource) та Sensu Enterprise. Архітектура роботи Sensu досить цікава і змушує повірити в світле майбутнє. Основні особливості:
  • Написаний на Ruby. Схоже люди поділяються на тих, хто любить Ruby, за його гнучкість синтаксису і ненавидить Python за його більшу строгість, і навпаки. Я відношусь до другого табору. :) Тому в кожного емоції щодо цього різні.
  • Конфігураційні файли - JSON. Шкода, що не YAML.
  • Може працювати з перевірками від Nagios. Що чудово - не треба все знову переписувати.
  • Перевірка описується лише одноразово на сервері і підключається до аналогічної групи серверів. Кожен новий хост додається в моніторинг значно простіше і з мінімумом ручної роботи.
  • Чудова архітектура, яка добре масштабується.
Зупинюсь детальніше на схемі роботи Sensu.


Sensu-server процес у якості сервера черг використовує RabbitMQ, а у якості місця збереження результатів відпрацювань чеків - Redis. Процес sensu-server має бути відповідно сконфігурований на їх використання. Одразу після старту процесу sensu-client на вузлі, що буде моніторитись, опитує sensu-server на предмет призначених для нього перевірок і надалі відсилає результати перевірок напряму в сервер черг RabbitMQ. Sensu-server підключається до останнього, робить обробку черги і записує дані в Redis. За певних обставин sensu-server може викликати відповідний handler. Handler - це деяка логіка сповіщення у разі певних проблем чи пересилки даних на окремі бекенди у разі їх появи і т.п. Sensu-api - процес, котрий надає інтерфейс взаємодії з іншими сторонніми скриптами чи сервісами. Якраз Uchiwa (frontend на схемі) і користується API задля відображення всього, що відбувається з моніторингом.

середа, 4 травня 2016 р.

Grafana. Frontend to Graphite

Місяць тому я писав про налаштування та конфігурацію Graphite та пообіцяв незабаром розповісти про Grafana. І ось лише сьогодні я виконую свою обіцянку.

Справа в тому, що Graphite має не надто зручну панель відображення графіків. Звісно вона володіє необхідним мінімумом, але не більше (наприклад, не можна швидко збільшити регіон графіку). Можливо це і було поштовхом для появи Grafana.

Grafana - це фронтенд для відображення графіків, що має швидкий та зручний інтерфейс. З Graphite він працює через API, проте також, у якості джерела даних може використовувати InfluxDB, KairosDB, Elasticsearch, AWS Cloudwatch і т.п.

Установка графічної панелі Grafana не викликає труднощів, а для налаштування Graphite, як бази метрик, можна скористатись моєю попередньою статею, про яку згадано на початку.

Якщо ви лише тестуєте продукт для інтеграції з власною інфраструктурою - варто одразу спробувати останню бету, що ймовірно стане стейбл на момент вашої фінальної установки. Наступний мажорний реліз Grafana, з версією 3, матиме багато змін, серед яких платформа плагінів Grafana.net, які розширять можливості фронтенду додатковими джерелами данних, панелями відображення та додатками (вміщають в собі пакети джерел данних та панелей). Зовнішній вигляд також зазнав деяких змін та вдосконалень, проведено багато оптимізацій.

Ми будемо розглядати установку останньої стабільного релізу, що на момент написання статті має версію 2.6. Grafana поки що відутня у основних репозиторіях Ubuntu - тому додамо сторонній репозиторій:

# echo 'deb https://packagecloud.io/grafana/stable/debian/ wheezy main' |  sudo tee -a /etc/apt/sources.list

понеділок, 11 квітня 2016 р.

Graphite Configuration. Sending Metrics Using CollectD, StatsD

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

Раніше я писав про побудову графіків за допомогою Cacti, графічного бекенду до Nagios Nagiosgraph, в основі побудови графіків яких лежить RRDtool. Дуже можливо, що це саме те, що вам необхідно. Проте цього разу мова піде про Graphite, що має подібну до RRDtool логіку збереження даних для зображень графіків.

Graphite складається з таких компонентів:

  • Carbon - storage-бекенд, написаний на Twisted Framework. Приймає дані, по-замовчуванню на 2003 порту, та в певні проміжки часу записує їх на диск, використовуючи Whisper. Задля масштабування стандартний процес carbon-cache.py, котрого більш ніж досить у звичайних конфігураціях, може бути доповнений додатковими процесами carbon-relay.py та carbon-aggregator.py. Перший може виступати як балансувальника між декількома carbon-cache.py процесами, а другий - у якості проміжного буферу.
  • Whisper - storage-engine, бібліотека бази Graphite, використовується для збереження даних. Відповідає за реорганізацію даних, що отримав Carbon: переважно перетворює більш точні серії даних в менш точні та довгострокові задля більшої ефективності використання дискового простору. У залежності від наявних серій, може показувати більш точні дані на коротких діапазонах часу, або менш точні на більш довгих. Політика точності, тип агрегації та тривалості збереження серій даних звісно може налаштовуватись. В перспективі Whisper планується замінити на Ceres. Суть в тому, що Whisper на початку створює файли серій метрик фіксованого розміру і, в разі їх великої кількості, це може займати значний розмір дискового простору без корисних даних. Ceres не володіє таким недоліком: він записує файл даних лише по надходженню самих метрик. Також Ceres краще працює з розподіленими сховищами і, як наслідок, один файл метрик може лежати на декількох серверах. Але, на противагу, він менш стабільний. Є звісно і інші альтернативи для storage-engine.
  • Веб-панель Graphite/API-сервер - панель/API для перегляду графіків, отриманих із серій даних Whisper. Також має можливість побудови панелей для швидкого перегляду груп графіків. Написана на Django з використанням бібліотеки Cairo.

Підсумуємо. Carbon отримує дані, та записує метрики кожний сталий проміжок часу, Whisper агрегує їх залежно від політики збереження, а веб-панель Graphite надає можливість їх переглядати.

понеділок, 14 березня 2016 р.

Foreman. Setup and Configuration

Foreman - це інструмент управління повним життєвим циклом серверів. Проект розпочав 6 років тому Ohad Levy, співробітник RedHat в Ізраїлі. Проект розвивається дуже активно та має обширне співтовариство. По замовчуванню працює з Puppet, з певними зауваженнями також може інтегруватись з Chef, Salt, а через систему плагінів і з Ansible.

Під управлінням повним життєвим циклом вузла розуміються такі етапи:

  • Установка - початкова установка операційної системи.
  • Конфігурація - установка та налаштування усього необхідного програмного забезпечення та налаштування самої операційної системи (додавання користувачів, налаштування мережевих інтерфейсів і т.п.)
  • Оновлення, Управління та Аудит - установка виправлень помилок софту, додавання змін до конфігурацій діючих програм, моніторинг вузлів на протязі усього життєвого циклу.

Щоб зрозуміти як Foreman забезпечує виконання цих етапів спочатку розглянемо його складові:


  • Веб-панель Foreman - панель для зручного адміністрування Puppet-модулями, групами та ін.
  • API - програмний інтерфейс Foreman.
  • DB - база даних Foreman. У якості бази може виступати як PosgreSQl, так і MySQL.
  • LDAP/AD - користувачі можуть авторизуватись через віддалені бази LDAP чи Active Directory, що дуже зручно навіть для відносно великих компаній.
  • Smart Proxy (DHCP, DNS, TFTP, CA) - група сервісів Foreman, що можуть перебувати як на одному вузлі, так і на різних. Відповідають за різні дії: provisioning нових серверів, збереження та підписання сертифікатів та ін. Таких проксі може бути декілька, наприклад для зв'язку із різними підмережами.
  • Puppet Master - майстер, що надає конфігурації за іменем хосту Puppet-агента. Foreman-інсталятор налаштовує майстер на роботу через Apache та Passenger.
  • Puppet Agents - агенти, що мають бути установлені на серверах, що адмініструються за допомогою Foreman.

понеділок, 7 березня 2016 р.

Puppet Masterless Setup. Heartbeat Configuration


Puppet - це одна із найбільш популярних систем управління конфігурацією. Декілька років тому я вже описував її основні ідеї, а цього разу розповім про masterless-конфігурацію та, як приклад її роботи, продемонструю налаштування та роботу кластеру Heartbeat.

Якщо ви лише плануєте використовувати подібні системи - то раджу звернути увагу на Ansible. Він більш дружній до початківців, має менше недоліків та і може виконувати ту ж роботу з аналогічним успіхом.

Класична система роботи Puppet - клієнт-серверна (standalone). Певні проміжки часу (по замовчуванню кожні 30 хвилин) Puppet-клієнт запитує дані щодо власної конфігурації в Puppet-сервера, сервер компілює їх в проміжний результат та віддає клієнту. Вузьке місце такої системи - це сам Puppet-сервер: у разі виходу його із ладу, одразу всі клієнти не зможуть отримати зміни конфігурації. Також з часом ймовірно необхідно буде масштабувати сервер, адже потужностей сервера може бути недостатньо.

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

Перейдемо до суті. Як я вже говорив розбиратись із masterless конфігурацією ми будемо на прикладі автоматичної конфігурації Heartbeat. Це можливо не найтривіальніший приклад, проте досить цікавий. Суть роботи Heartbeat полягає в міграції (переміщенні) IP адреси з непрацюючого серверу кластера на працюючий і, таким чином, підвищувати рівень доступності. З деталями використання Heartbeat можна ознайомитись на офіційній сторінці проекту:

http://www.linux-ha.org/doc/users-guide/users-guide.html

Про щось подібне я також вже писав раніше. Для конфігурації Heartbeat кластеру необхідно як мінімум дві ноди та 3 вільні IP-адреси однієї мережі. У якості ОС я обрав Ubuntu 14.04, а серверам призначив такі адреси та хостнейми:

192.168.1.21 - hb1.me
192.168.1.22 - hb2.me

192.168.1.20 - віртуальний IP (VIP), що буде мігрувати на робочу ноду у разі падіння попередньої.

вівторок, 19 січня 2016 р.

Elasticsearch Cluster: Overview And Setup

Elasticsearch - це пошукова платформа майже реального часу (near real time, NRT). На практиці це означає, що існує лише мінімальна затримка (зазвичай біля секунди) між часом додавання документу до індексу і часом, коли він стає доступним для пошуку.

Elasticsearch, як і його основний конкурент Solr, базується на бібліотеці Lucene. Сам по собі Apache Lucene не являється повноцінним сервісом: це просто бібліотека для побудови пошукових систем, вона займається лише індексом та пошуком. А, власне, за введення даних, налаштування сервісу, кластеризацію, маршрутизацію пошукових запитів та ін. відповідає Elasticsearch чи інша "обгортка".

Використання та налаштування (переважно) здійснюється за допомогою RESTful API запитів. У випадку з unix-подібною OC з цим може допомогти curl. Але про це дещо далі.

Спочатку почнемо з базової термінології Elasticsearch.

Кластер (Cluster)

Сервери, що обслуговують один набір даних та забезпечують індексацію та їх пошук по всіх серверах. Кластер також може складатись лише з єдиного сервера, проте в цьому випадку не може йти мова про високу доступність.

Про те як створити кластер я напишу нижче.