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.

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), що буде мігрувати на робочу ноду у разі падіння попередньої.

Elasticsearch Cluster: Overview And Setup

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

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

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

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

Кластер (Cluster)

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

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

LXC Сontainers. Part II: Network Configuration

У попередній статті я описав, що таке LXC та чому ця технологія може вас зацікавити.

Перед прочитанням тексту нижче, бажано звісно розуміти базові речі про LXC чи просто про контейнеризацію, тому дуже раджу хоча б переглянути статтю, згадану вище.
У цій статті спробуємо розібратись які можливості надає LXC для конфігурації мережевого стеку та і що власне ОС Linux може запропонувати для цього.

Конфігурація з'єднання з мережею описується окремо для кожного контейнера в /var/lib/lxc/<container_name>/config. По замовчуванню, мережевий зв’язок для контейнерів LXC налаштовується за рахунок додаткової приватної мережі 10.0.3.0/24, що NAT-иться на хост машині: всі пакети, що приходять на інтерфейс lxcbr0 (10.0.3.1, gateway) за допомогою маскарадингу динамічно транслюються в публічний айпі і навпаки. Видає IP-адреси dnsmasq, що працює на LXC-хості, а діапазон можливих адрес описаний в /etc/default/lxc-net. На практиці це виглядає так:

# vim /etc/default/lxc-net
...
USE_LXC_BRIDGE="true"

LXC_BRIDGE="lxcbr0"
LXC_ADDR="10.0.3.1"
LXC_NETMASK="255.255.255.0"
LXC_NETWORK="10.0.3.0/24"
LXC_DHCP_RANGE="10.0.3.2,10.0.3.254"
LXC_DHCP_MAX="253"
...

Налаштування Iptables на хості, одразу після установки lxc, мають такий вигляд:

# iptables-save
...
-A POSTROUTING -s 10.0.3.0/24 ! -d 10.0.3.0/24 -j MASQUERADE
...
COMMIT

LXC Сontainers. Part I: Overview

LXC (англ. LinuX Containers) — система віртуалізації на рівні операційної системи для запуску декількох ізольованих примірників ОС Linux на одному комп'ютері. LXC не використовує віртуальні машини, а створює віртуальне оточення (контейнер) з власним простором процесів і мережевим стеком. Тобто у разі контейнеризації хост-ситема не емулює хардову частину (відсутній гіпервізор), а просто обмежує процеси та ресурси гостей внутрішніми підсистемами.

У разі LXC, ці підсистеми - це cgroups (додана у версії 2.6.29), namespaces (для ізоляції процесів, мережевого стека і т.д.); для обмеження доступу задіяні такі можливості ядра, як профілі Apparmor і SELinux, політики Seccomp, Chroots (pivot_root) і capabilities. Усі контейнери LXC використовують один примірник ядра ОС.

Ця система схожа на системи OpenVZ (LXC прийняв багато патчів та ідей з цього проекту) і Linux-VServer для ОС Linux, jail для FreeBSD, Solaris Containers для Solaris. Проте на відміну від OpenVZ, LXC не потребує окремого ядра для своєї роботи: необхідні для роботи LXC підсистеми одразу знаходяться в основній вітці ядра.

До складу інструментарію LXC входить бібліотека liblxc, набір утиліт (lxc-create, lxc-start, lxc-stop, lxc-ls і тому подібне), шаблони для побудови контейнерів і набір біндінгів для різних мов програмування.

Cassandra. Part II: Cluster

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

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

10.131.75.141  cs-1
10.131.75.142  cs-2
10.131.75.143  cs-3
10.131.75.144  cs-4

Із них і буде складатись кільце кластеру (Token Ring). Отже, створимо ці віртуальні машини та додамо цей список адрес до кожної із них в /etc/hosts. У якості ОС я обрав Ubuntu 14.04. Кількість оперативної пам'яті для кожної віртуальної машини рівна 1 ГБ, що звісно достатньо лише для тестових цілей.

Установлюємо Java:

# add-apt-repository ppa:webupd8team/java
# apt-get update
# apt-get install oracle-java8-installer

# apt-get install oracle-java8-set-default

Та останню версію Cassandra з репозиторіїв DataStax:

# echo "deb http://debian.datastax.com/community stable main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
# curl -L http://debian.datastax.com/debian/repo_key | sudo apt-key add -

# apt-get update
# aptitude install cassandra
The following NEW packages will be installed:
  cassandra libopts25{a} ntp{a} python-support{a} 
0 packages upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 24.9 MB of archives. After unpacking 34.0 MB will be used.
Do you want to continue? [Y/n/?]

Java та Cassandra, очевидно, необхідні на всіх нодах кластеру. Після установки перевіримо роботу бази, підключившись до неї через CQLSH:

# cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 2.2.1 | CQL spec 3.3.0 | Native protocol v4]
Use HELP for help.
cqlsh> 

Cassandra. Part I: Overview

Apache Cassandra — розподілена система керування базами даних, що відноситься до класу noSQL-систем і розрахована на створення високомасштабованих і надійних сховищ величезних масивів даних, представлених у вигляді хеша.

Проект стартував у надрах компанії Facebook і в 2009 році був переданий фонду Apache. В основу Cassandra лягли 2 архітектурні ідеї: Amazon Dynamo та Google Big Table, опис яких був опублікований в 2007 та 2006 роках відповідно.

Цю базу данних використовують такі компанії як IBM, Apple, Netflix, Twitter, Yandex, CERN, Reddit, SoundCloud, Rackspace та інші.

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

Що ж таке Cassandra? Cassandra - це гібрид key-value и column-oriented баз даних. Термінологія структури данних дещо інша ніж в реліційній моделі, проте не варто на цьому особливо зациклюватись адже це не так важливо.

Тож в Cassandra є бази (keyspace), в котрих знаходяться сімейства колонок (аналог таблиць у реляційній системі), а в самому сімействі, вже майже як і у звичайній таблиці, колонки і рядки. Майже, тому що для кожного рядка може бути визначений свій набір колонок (розріджені таблиці). Як це виглядає в реальному житті? Ну щось схоже на це:

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