Translate

пʼятниця, 3 лютого 2017 р.

OpenVPN Part II: Connect Two Local Networks

Декілька тижнів тому я опублікував першу статтю про програму OpenVPN, де описав декілька способів її практичного використання. Цього разу я розповім про те, як об’єднати дві різні локальні мережі, в результаті чого кожен із вузлів буде мати доступ до всіх інших вузлів обох підмереж. Звісно дуже раджу спочатку ознайомитись із першою статтею, яка надасть необхідний теоретичний мінімум.

Для експериментів будемо використовувати наступні вузли:

 Short name  Public IP  Private IP  Network  Role
 ams1 37.139.10.10 10.129.18.182  10.129.0.0/16 SERVER
 ams2  - 10.129.20.80 10.129.0.0/16   -
 local1  - 192.168.1.10 192.168.1.0/24 CLIENT
 local2 -  192.168.1.20 192.168.1.0/24  -

Отже ми маємо два хости у підмережі 10.129.0.0/16 та два в іншій підмережі 192.168.1.0/24. ams1 (10.129.18.182) буде працювати у ролі сервера і для зовнішніх з’єднань володітиме публічною адресою 37.139.10.10 (це обов’язкова умова, якщо не враховувати можливість перебросу порта на OpenVPN-сервер). А local1 (192.168.1.10) буде підключатись до сервера у якості клієнта OpenVPN.

Установимо OpenVPN на ams1 та local1 вузлах:

# apt install openvpn

неділя, 22 січня 2017 р.

OpenVPN Part I: Setup and Configuration

OpenVPN - вільна реалізація технології Віртуальної Приватної Мережі (VPN) для створення зашифрованих каналів типу точка-точка або сервер-клієнти між комп’ютерами і може працювати як у звичайному routing, так і у bridge-режимі. Програма дозволяє створювати з’єднання навіть між вузлами, що знаходяться за NAT та мережевими екранами (фаєрволами), без необхідності їх переналаштування. OpenVPN була написана Джеймсом Йонаном (James Yonan) на мові програмування C і поширюється по ліцензії GNU GPL. Її перший реліз побачив світ в далекому 2001 році, і, на момент написання статті, актуальною є версія 2.4.

Для організації з’єднань OpenVPN використовує свій оригінальний протокол над TCP/UDP, що в свою чергу застосовує SSL/TLS для обміну ключами. Програма використовує бібліотеку OpenSSL для шифрування як корисних даних, так і сервісних, що необхідні для створення підключень і підтримки з’єднань. Остання, в свою чергу, дозволяє задіяти увесь набір алгоритмів шифрування, що доступні в бібліотеці.

Клієнти для OpenVPN існують для великої кількості операційних систем і платформ, в т.ч. мобільних та ОС для роутерів. У цьому сенсі це майже універсальне рішення.

Автентифікувати підключення OpenVPN-сервер може наступними способами:

  • За допомогою логіна та пароля із клієнтськими сертифікатами/без сертифікатів. Це забезпечується сторонніми модулями від третіх сторін.
  • За допомогою попередньо згенерованого єдиного ключа для сервера та клієнта (PSK, тобто з’єднання встановлюється симетричним алгоритмом шифруванням).
  • Аутентифікація за допомогою сертифікатів (TLS client/server mode). Найбільш надійний варіант, адже в клієнта та сервера є свій унікальний набір ключів/серифікатів, що підписані одним центром сертифікації.

У останньому варіанті аутентифікації, сервер та клієнт мають свій ключ, випущений сертифікат та кореневий (СА) сертифікат. Для підняття рівня безпеки, клієнт також може мати додатковий пароль.

субота, 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 використаємо такі адреси:

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-процесу необхідно заборонити, адже інакше відсутні дані майстра (дивно звучить), після його можливого падіння, скопіюються і на слейви, що призведе до повного видалення баз. Але навіть так це достатньо ризиковано.