GlusterFS: setup and configuration

GlusterFS — розподілена файлова система, що дозволяє організувати роботу розподіленого на кілька вузлів сховища, розгорнутого поверх штатних файлових систем POSIX, таких як Ext4, XFS і Btrfs, з використанням механізму FUSE (файлова система у просторі користувача). GlusterFS надає засоби автоматичного відновлення після збоїв і забезпечує практично необмежену масштабованість, завдяки відсутності прив'язки до централізованого серверу мета-даних (використовуються розподілені хеш-таблиці).

Цю файлову систему застосовують у хмарних обчисленнях, службах потокового медіа та у мережах постачання даних. (c) Wikipedia

Ключові особливості GlusterFS:

* Еластичність - томи зберігання даних абстраговані від заліза, на якому фізично знаходяться і можуть бути як-завгодно збільшені/зменшені/переміщені в межах фізичних систем.
* Відсутність окремого сервера метаданих - на відміну від інших розподілених файлових систем (наприклад, Lustre), GlusterFS не використовує окремого сервера для метаданих. Таким чином у неї відсутня єдина точка відмови.
* Масштабованість - досить просто збільшити або зменшити розмір файлової системи, без даунтайму. Може маштабуватись як у продуктивності так і обсягу даних.
* Висока доступність - у випадку правильного проектування тому, випадання окремого серверу не призведе до простою системи. Звісно, рівень доступності залежить від кількості реплікацій.
* Гнучкість - GlusterFS працює в просторі користувача (FUSE), тому не потрібно патчити ядро, додавати до нього модулі і т.д. Проте з іншої сторони, файлові системи в ядрі працюють швидше.
* Гео-реплікація - GlusterFS дозволяє синхронізувати всю систему збереження даних між різними датацентрами чи географічними місцями.

Налаштування GlusterFS достатньо просте. Конфігурацію будемо проводити на 3 віртуальних машинах: 2 сервера та 1 клієнт. До клієнта буде примонтований розділ GlusterFS, котрий буде попередньо створений на серверах.

Provisioning with Ansible

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

Щоб уникнути подібних страждань людство і придумало системи управління конфігураціями. До найбільш популярних таких систем можна віднести Puppet, Salt, Chef, CFEngine. Хронологія їх появи така:

* CFEngine. Перший реліз - 1993, написаний на С.
* Puppet - 2005, написаний на Ruby. DSL
* Chef - 2009, написаний також на Ruby, DSL
* Juju - 2010, Python.
* Salt - 2011, Python.
* Ansible. Перший реліз - 2012, Python.

Ansible один із наймолодших із існуючих популярних систем конфігурації. Проект стартував лише в 2012 році, проте вже має багато прихильників. Засновник проекту - Майкл Де Хаанн, попередньо працював над Puppet і Cobbler/Func. Назва продукту взято з науково-фантастичної літератури: в романах американської письменниці Урсули Ле Гуїн ансіблом називається пристрій для оперативного космічного зв'язку. Про Ansible далі і піде мова.

Ansible - програма з відкритим вихідним кодом для налаштування і управління серверами. Для деплоя конфігурації на новий сервер необхідно лише SSH-з’єднання та Python-інтерпритатор, який зазвичай йде по-замовчуванню в основних дистрибутивах. Сценарій конфігурації (в Ansible він називається Playbook) описується за допомогою мови розмітки YAML.

Docker. Setup and configuration

Останнім часом дуже часто пишуть про Docker та його можливості, дехто навіть приписує йому мало не магічні вміння. Тож у цій статті спробуємо розібратись, що таке Docker і чи потрібно все кидати та мігрувати на нього.

Docker - це один із різновидів контейнерної віртуалізації. Контейнерна віртуалізація не використовує віртуальні машини, як у випадку з повною віртуалізацією, а створює віртуальне середовище з власним простором процесів та мережевим стеком. Всі контейнери хосту використовують один екземпляр ядра хостової системи.

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

Centralize Loggining with Kibana/Logstash/Elasticsearch

Я раніше писав про установку та налаштування серверу централізованого збору логів в основі якого лежав Rsyslog з бекендом LogAnalyzer, та сервер із Syslog-ng. Основним недоліком LogAnalyzer є відсталість його інтерфейсу. Тому якщо цей недолік для вас є основним - раджу спробувати Kibana/Logstash зі зберіганням данних в Elasticsearch.

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

Спочатку розберемось щодо складових частин серверу збору логів та їхнього призначення.

Logstash читає логи або отримує їх від клієнтів за допомогою Logstash-forwarder, розбирає їх по полям відповідними драйверами та записує їх до Elasticsearch, потім, за допомогою Kibana, можна переглядати логи і будувати різноманітні діаграми чи графіки.

Дистрибутив, що я буду використовувати - Ubuntu 14.04. Навіть для тестів краще брати машину як мінімум із 2 ГБ RAM та 2 CPU.

Почнемо з установки серверної частини. Logstash та Elasticsearch потребують Java 7 для роботи, для чого підійде як Oracle Java 7, так і OpenJDK.

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

Для production середовища, можливо, краще скористатись джавою що надає Oracle на власному сайті та зібрати власний пакет:

# apt-get install java-package

# wget http://download.oracle.com/otn-pub/java/jdk/7u75-b13/server-jre-7u75-linux-x64.tar.gz?AuthParam=1423217016_530b51c9d6c77e8237c6a2f2288d7657 -O jre-7u75-linux-x64.tar.gz

# make-jpkg jre-7u75-linux-x64.tar.gz

# dpkg -i oracle-j2re1.7_1.7.0+update75_amd64.deb

# update-alternatives --auto java

Deploy with Webistrano (Capistrano)

Webistrano - це фронтенд написаний на ROR до ruby-програми Capistrano. Це зручна адмін-панель до управління процесом виливки коду: за допомогою Webistrano можна зручно управляти етапами деплою проектів, надавати певні права користувачам, повертатись на попередні релізи у разі появи проблем та ін.

На жаль, проект більше 5 років не підтримується розробником - тому чим далі, тим буде складніше його установити, адже ніхто не тестує його роботу з останніми бібліотеками Ruby. Наразі краще пошукати альтернативи Webistrano або ж просто користуватись лише консольним інтерфейсом Capistrano, що звісно не додає зручності.

Для Ubuntu 14.04 LTS установка і налаштування проходить наступним чином. Перш за все встановимо необхідні пакети зі стандартних репозиторіїв:

# apt-get install ruby ruby-dev gem rubygems-integration libmysqlclient-dev ruby1.9.1-dev make git mysql-server

Призначення кожного пакету, я думаю, зрозуміле. Наступний крок - установка Rails:

# gem install rdoc mysql2
# gem install rails --no-ri --no-rdoc

Встановлюємо Capistrano, бекенд до Web:

# gem install capistrano

How to sync Google Apps account with own LDAP installation

У цій статті я розкажу про установку та налаштування Google Apps Directory Sync. За допомогою GADS можна автоматично синхронізувати акаунти користувачів, груп, на стороні аккаунту Google, з сервером LDAP (наприклад, з Microsoft Active Directory або Lotus Domino, openLDAP та ін). Додаток підключається до каталогу Google Apps і додає або видаляє акаунти користувачів згідно з описаною політикою.

Для роботи GADS звісно необхідно працюючий LDAP-сервер, a про його установку я писав ось тут.

Установка може проходити на будь-якому сервері та операційній системі (окрім OS X), для ОС Linux програмі необхідний Xserver (точніше X11), адже програма не має повнофункціонального CLI-інтерфейсу. Надалі синхонізацію можна виконувати автоматично, наприклад, через cron, за допомогою sync-cmd.

Ілюстрація роботи GADS. Особливо то і нічого додати.

Configure Linux сlients to authenticate through OpenLDAP

Раніше я писав про установку та налаштування OpenLDAP серверу. Тож наразі прийшов час налаштування клієнтів для аутентифіікації через центральний сервер. Це так би мовити продовження попередньої статті, яку бажано прочитати спочатку.

Логінимось на клієнт та встановлюємо додаткові пакети:

# apt-get install libnss-ldap libpam-ldap nscd

Дебіан підтримує конфігурацію сервісів під час установки (шах і мат, RPM-щики), тому одразу відповідаємо на питання налаштування.

Вводимо адресу LDAP-сервера у вигляді ldap://1.2.3.4: