Translate

субота, 14 грудня 2013 р.

Використання Innobackupex (Xtrabuckup) для бекапу MySQL

Mysqldump буде влаштовувати вас лише до того моменту, доки він зможе знімати дамп на протязі прийнятного часу. База збільшується і це саме час задуматись про альтернативи. І такою альтернативою може бути Xtrabackup.

Xtrabackup - розробка компанії Percona, програма, що дозволяє робити бекап MySQL-серверів і не блокує базу данних на протязі бекапу. Xtrabackup може працювати з InnoDB, XtraDB і MyISAM (проте з певними обмеження на кшталт інкрементальних бакапів) таблицями. Мабуть, головною особливістю Xtrabackup є його висока швидкість роботи, на відміну від Mysqldump-а, що пояснюється тим, що він працює на бінарному рівні (умовно кажучи, копіює бінарні файли /var/lib/mysql, а не генерує запити як mysqldump).

Для початку я б хотів би розповісти логіку роботи програми Xtrabackup (точніше як я її розумію) і почну саме з особливостей роботи InnoDB. Запити, що генерують користувачі, приходять на mysql-server, записуються у лог транзакцій (mysql bin log) а потім виконуються. Результати запитів одразу не пишуться на жорсткий диск і лишаються в кешах.


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

середа, 11 грудня 2013 р.

MySQL/InnoDB one file per table

Після видалення бази данних чи таблиці MySQL розмір файлу ibdata1 не змінюється, що в результаті може призвести до повного заповнення диску. Для вирішення цієї проблеми існує опція innodb_file_per_table, що дозволяє зберігати кожну таблицю в окремому файлі на відміну від стандартної поведінки зберігання таблиць. Як наслідок, при видаленні таблиці, видалиться файл, що відповідає за її вміст та звільниться простір на диску. Опція innodb_file_per_table увімкнена по замовчуванню в Mysql версії 5.6.6 і старше.

Щоб перейти до нового варіанту зберігання таблиць необхідно виконати декілька пунктів. Розглянемо варіант міграції всіх баз на новий метод їхнього зберігання. Перш за все, про всяк випадок, забекапимо всю директорію /var/lib/mysql:

# cd ~
# mkdir backup
# cd backup
# service mysql stop
# cp -ra /var/lib/mysql mysqldata_backup
# service mysql start

Зробимо дамп всіх існуючих баз:

# mysqldump --routines --events --flush-privileges --all-databases > all-db.sql

понеділок, 9 грудня 2013 р.

MySQL/Galera replication with Haproxy balancing

MySQL/Galera - синхронний мульти-майстер кластер для MySQL/InnoDB бази данних, що володіє такими перевагами:
- синхронна реплікація.
- аctive-active мульти-майстер топологія
- читання чи запис на будь-яку ноду кластеру.
- автоматичний контроль членів кластеру: проблемні члени будуть автоматично виключені з діючого кластеру.
- автоматичне (просте) додавання додаткових серверів до кластеру. Зручне масштабування.
- справжня паралельна реплікація, на рівні рядків.

Додам, що звичайна реплікація типу master-master не є синхронною. На активному майстрі всі запити спочатку будуть записані в binlog і лише потім будуть передані на інший пасивний MySQL-майстер (слейв), запити на пасивному сервері можуть виконуватись із значною затримкою. У випадку із Galera запити на кожній ноді виконуються одночасно, або майже одночасно.

MySQL/Galera кластер використовує бібліотеку Galera для реалізації реплікації, що працює через MySQL wsrep API (патчена версія MySQL)



Як я вже згадував Galera допускає запис на будь-яку ноду кластеру, навіть одночасні записи із різних нод в одну таблицю. Все це завдяки алгоритму сертифікації транзакцій:
Логіка алгоритму сертифікації приблизно така: SQL-запити приходить на різні сервери кластеру і якщо вони конфліктують між собою (наприклад, запис в той самий рядок таблиці) відбувається роллбек і послідовне виконання запитів (виправте, якщо я помиляюсь).

вівторок, 12 листопада 2013 р.

Shc: compile bash-script to binary view

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

Ім'я цієї програми Shc і, на щастя, вона відсутня в репозиторіях. Тому зкомпілюємо її :

# wget http://www.datsi.fi.upm.es/~frosal/sources/shc-3.8.9.tgz
--2013-11-12 01:40:16--  http://www.datsi.fi.upm.es/~frosal/sources/shc-3.8.9.tgz
Resolving www.datsi.fi.upm.es (www.datsi.fi.upm.es)... 138.100.9.22
Connecting to www.datsi.fi.upm.es (www.datsi.fi.upm.es)|138.100.9.22|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 20536 (20K) [application/x-gzip]
Saving to: ‘shc-3.8.9.tgz’

100%[====================================================>] 20 536      --.-K/s   in 0,1s    

2013-11-12 01:40:16 (150 KB/s) - ‘shc-3.8.9.tgz’ saved [20536/20536]

# tar xvfz shc-3.8.9.tgz
shc-3.8.9/CHANGES
shc-3.8.9/Copying
shc-3.8.9/match
shc-3.8.9/pru.sh
shc-3.8.9/shc-3.8.9.c
shc-3.8.9/shc.1
shc-3.8.9/shc.README
shc-3.8.9/shc.html
shc-3.8.9/test.bash
shc-3.8.9/test.csh
shc-3.8.9/test.ksh
shc-3.8.9/makefile

# cd shc-3.8.9


понеділок, 28 жовтня 2013 р.

ZFS filesystem on Linux (configuration and performance)

ZFS (Zettabyte File System) - 128-бітна файлова система, створена в Sun Microsystems в 2004 році. Вона об'єднує концепції файлової системи, менеджера логічних дисків і фізичних носіїв, новаторську структуру даних на дисках, а також просте управління томами зберігання даних. ZFS не без підстав називають найбільш функціональною у світі файловою системою.

Подейкують, що ZFS - це розробка інженерів, котрих перекупив Sun (тепер Oracle) в NetApp, через що це ніби як копія WAFL.
Підтримка файлової системи ZFS у Лінуксі реалізована у якості модуля, адже включити його прямісінько в ядро не дозволяє конфлікт ліцензій GPL v2 та CDDL, під якою і було випущено ZFS.

Часом ZFS докоряють тим, що це не unix-way включати купу можливостей (LVM, Raid та ін) в саму файлову систему, краще щоб кожну роль виконувала окрема програма. Проте з іншої сторони таким чином досягається кращий рівень інтегрованості між собою цих можливостей в одній системі.

Починаючи з травня 2013 (версія 0.6.1) файлову систему вважають готовою для використання в  production ситемах.

Наведу приклад установки і налаштування ZFS-розділу в Ubuntu 12.04.3.  Підтримка ZFS в Debian-подібних системах реалізована через модулі dkms, пакети яких розповсюджуються через ppa-репозиторій. Тож спершу додамо репозиторій і встановимо модулі:

# add-apt-repository ppa:zfs-native/stable
# apt-get update
# apt-get upgrade
# apt-get install ubuntu-zfs

понеділок, 7 жовтня 2013 р.

Установка Redmine (Nginx у якості frontend)

Відносно нещодавно я писав як установити систему управління проектами та відстежування помилок Atlassian Jira. Проте ймовірно вона влаштовує не всіх, адже як кожна річ вона має свої недоліки та і ліцензія на цей програмний продукт коштує зовсім не дешево. Тому як альтернативу я пропоную Redmine, open source рішення на ruby, що є повністю безкоштовним і розповсюджується під ліцензією GPL v2. Варто також зауважити, що Redmine має клієнти під ОС Android та Iphone.

У цій статті піде мова про установку системи управління проектами та відстежування помилок Redmine, що працюватиме під ОС Ubuntu 13.04, у якості веб-серверу будемо використовувати Nginx та Thin (веб-сервер для Ruby).

Почнемо із установки Redmine. Сирці можна скачати багатьма способами: через Git/SVN/Mercurial репозиторій, чи просто як tar.gz чи zip-архів із RubyForge. Подробиці тут http://www.redmine.org/projects/redmine/wiki/Download.

1. Скачаємо Redmine і розпакуємо:

# wget http://rubyforge.org/frs/download.php/77138/redmine-2.3.3.tar.gz
# tar xvfz redmine-2.3.3.tar.gz
# mv redmine-2.3.3 /var/www/

2. У якості бази даних будемо користуватись MySQL. Установлюємо його та переходимо до створення користувача і самої бази:

mysql> CREATE DATABASE redmine CHARACTER SET utf8;
mysql> GRANT ALL PRIVILEGES ON redmine.* TO 'redmine'@'localhost' IDENTIFIED BY 'my_password';


четвер, 3 жовтня 2013 р.

Список контроля доступу Linux (ACL, setfacl)

Класичні права в операційній системі Linux/Unix не такі гнучкі як хотілось би: у випадку коли права на файл/директорію хочеться розподілити якомога точно між багатьма групами користувачів  - вони безсилі. Для реалізації таких складних прав було розроблено ACL (Access Control List - список контроля доступу). Вперше можливіть вести списи ACL було додано в ядрі 2.4.21.

Щоб скористатись розширеними правилами необхідно, щоб файлова система була змонтована із опцією acl. Для цього необхідно або прописати опцію в fstab і перемонтувати розділ:

# vim /etc/fstab
...
# /media/free was on /dev/sda5 during installation
UUID=b0218d9d-3d5b-4598-a8ac-5bf90a0d2090 /media/free     ext4    defaults,acl        0       2
...

Перемонтувати розділ можна таким чином (або просто перевантажити після додавання опцій в fstab):

# sudo mount -o remount /home

У випадку, якщо пакет acl відсутній - варто його встановити:

# apt-get install acl

Але, ймовірно, що він вже проінстальований у вашому дистрибутиві. Перевірити чи файлова система правильно змонтувалась можна так:

# mount | grep sda5
/dev/sda5 on /media/free type ext4 (rw,acl)

Перейдемо ближче до суті. Розглянемо роботу ACL із практичної сторони. Для цього створимо директорію lol і тестового користувача test:

понеділок, 2 вересня 2013 р.

Compile into deb-package

Не всі розробники пропонують бінарні пакети своїх програм і як результат їх необхідно зібрати. Наприклад, я полюбляю користуватись переглядачем фотографій Viewnior та простим регулятором гучності Volumeicon, але вони не розповсюджуються як deb-пакети. Звісно можна виконати установку make install скриптом, але така установка не завжди бажана, адже можуть з'явитись проблеми під час видалення програми і т.п.

Для початку розберемось як перекомпілювати deb-пакет, що наявний в репозиторію Debian/Ubuntu.

Перевіряємо доступність source-репозиторіїв. Якщо вони відсутні - необхідно їх дозволити:

$ grep deb-src /etc/apt/sources.list
deb-src http://us.archive.ubuntu.com/ubuntu/ raring main restricted
deb-src http://us.archive.ubuntu.com/ubuntu/ raring-updates main restricted
deb-src http://us.archive.ubuntu.com/ubuntu/ raring universe
deb-src http://us.archive.ubuntu.com/ubuntu/ raring-updates universe
deb-src http://us.archive.ubuntu.com/ubuntu/ raring multiverse
deb-src http://us.archive.ubuntu.com/ubuntu/ raring-updates multiverse
deb-src http://us.archive.ubuntu.com/ubuntu/ raring-backports main restricted universe multiverse
deb-src http://us.archive.ubuntu.com/ubuntu/ raring-security main restricted
deb-src http://us.archive.ubuntu.com/ubuntu/ raring-security universe
deb-src http://us.archive.ubuntu.com/ubuntu/ raring-security multiverse
deb-src http://archive.canonical.com/ubuntu raring partner
deb-src http://extras.ubuntu.com/ubuntu raring main

четвер, 15 серпня 2013 р.

Dialog: ncurses-інтерфейс до shell-скрипта

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

Звісно програму необхідно спочатку встановити:

# aptitude install dialog

Продемонструю його роботу з найпростішим case-скриптом.

#!/bin/bash

dialog --title 'Перезапуск мережі' \
       --yesno "Ви насправді бажаєте перезавантажити сервіс мережі на комп'ютері?" 10 40

case "$?" in
'0')
sudo service networking restart > /dev/null &2>1
echo 'Restarting...'
;;
'1')
exit 0
;;
-1|255)
echo "Сталась помилка, або ви натиснули ESC"
esac

Ключем "-yesno" вказуємо програмі dialog створити вікно з вибором "Так" чи "Ні", "--title" - встановлює назву вікна. Відповідь, що була обрана буде ідентифікуватись зі змінної $? (код завершення останньої команди). Тобто dialog буде повертати "0", якщо було обрано "Yes" та "1" - якщо "No". "10 40" - це позиція вікна, можна указати дефолтні - "0 0".
Також dialog повертає код "-1" у випадку, коли сталась помилка та "255", якщо було натиснено клавішу ESC.



субота, 3 серпня 2013 р.

Debug with Strace

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

Strace - трасувальник системних викликів і сигналів, інакше кажучи деббагер, котрий здатний виводити результати в системний термінал. Працює в ОС Linux та деяких Unix-системах. Робота програми можлива завдяки системному виклику ptrace ("process trace") в ядрі ОС.

Для початку його необхідно його установити:

# apt-get install strace

Розпочнемо з найбільш простого прикладу: перевіримо, які системні виклики з'являються при запуску команди ls

$ strace ls
 execve("/bin/ls", ["ls"], [/* 49 vars */]) = 0
brk(0)                                  = 0x6ef000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa60c3a3000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=147033, ...}) = 0
mmap(NULL, 147033, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fa60c37f000
close(3)                                = 0
....
write(1, "8154c50c.jpg\t\t   Desktop\t\t\t  fil"..., 618154c50c.jpg  Desktop  films out.log  walls
) = 61
close(1)                                = 0
munmap(0x7fa60c3a2000, 4096)            = 0
close(2)                                = 0
exit_group(0)                           = ?

неділя, 28 липня 2013 р.

Network File System (NFS)

Network File System (NFS) — протокол мережевого доступу до файлових систем, що був розроблений компанією Sun Microsystems у 1984 році. Заснований на протоколі виклику віддалених процедур (ONC RPC, Open Network Computing Remote Procedure Call). Дозволяє підключати (монтувати) віддалені файлові системи через мережу.
    NFS надає клієнтам прозорий доступ до файлів і файлової системи сервера. На відміну від FTP, протокол NFS здійснює доступ тільки до тих частин файлу, до яких звернувся процес, і основна перевага його в тому, що він робить цей доступ прозорим. Це означає, що будь-який сервіс/програма клієнта, що може працювати з локальним файлом, із таким же успіхом зможе працювати і файлом, що доступний через NFS, без будь-яких модифікацій самої програми.
NFS-клієнти одержують доступ до файлів на NFS-сервері шляхом відправлення RPC-запитів на сервер.(c) Wikipedia

Процес монтування каталогу віддаленого NFS-серверу можна розбити на такі кроки:

1. На сервері та клієнті на 111 порту udp та tcp запускається RPC-сервер (представлений як rpcbind). Він завантажується разом із запуском NFS-демону.
2. Запускаються служби rpc.statd, rpc.idmapd, rpc.statd і тд., що реєструються на довільних мережевих портах.
3. Команда mount на клієнті створює запит (із вказанням ip/доменнейму, каталогу) на монтування каталогу до ядра ОС. На що ядро формує і відсилає запит на віддалений RPC-сервер, на сервер, де власне локально зберігається необхідний каталог.
4. Ядро NFS-серверу через rpcbind перевіряє наявність процеса rpc.mountd і повертає номер порту, на якому він працює (знову, використовуючи RPC-протокол), ядру клієнта, що надав запит на монтування.
5. Отримавши номер порту, mount відправляє RPC-запит на отриманий порт серверу. Надалі сервер перевіряє дозволи і надає відповідні права на запитану директорію.
6. Демон монтування rpc.mountd на NFS-сервері повертає опис запитаної директорії і на основі цих данних проходить монтування директорії. Надалі в дереві директорій вона буде представлена як звичайна директорія.

Доступ до файлу в директорії, що примонтована як NFS, відбувається через модуль ядра nfsd/nfs, котрий вже потім надсилає запит на віддалений RPC-сервер (зазвичай на порт 2049, що відповідає за роботу з NFS). Тобто для клієнтських програм, що запитують файл на віддаленому розділі не важливо, що це не локальний файл, адже всі додаткові операції виконує ядро ОС та модуль ядра nfsd/nfs.

Щоб дізнатись на яких портах працюють RPC-програми, можна виконати таку команду:

# rpcinfo -p
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  54107  status
    100024    1   tcp  56055  status
    100003    2   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    2   tcp   2049
    100003    2   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    2   udp   2049
    100021    1   udp  39802  nlockmgr
    100021    4   udp  39802  nlockmgr
    100021    1   tcp  32786  nlockmgr
    100021    4   tcp  32786  nlockmgr
    100005    1   udp  49768  mountd
    100005    2   udp  43705  mountd
    100005    2   tcp  54465  mountd
    100005    3   tcp  35113  mountd

неділя, 16 червня 2013 р.

RAID: теорія та практика

Жорсткий диск завжди вважався "вузьким" місцем системи в плані надійності і, зазвичай, швидкості. Саме тому людство придумало таку технологію як RAID, що здатна в певній мірі підвищити ці показники, проте звісно не без втрат. Про це і піде далі мова.
   RAID (англ. redundant array of independent/inexpensive disks) - надлишковий масив дисків, що покликаний підвищити надійність та/або швидкість роботи постійної пам'яті. В залежності від рівня, RAID буває:

1) RAID 0 - масив, як мінімум із 2-х дисків, дані на яких розподіляються частинами (блоками) і записується відповідно на кожен диск. Тобто кожен блок знаходиться лише на одному диску. Таким чином цей масив значно підвищує швидкість запису/читання проте аж ніяк не підвищує надійність.


2) RAID 1 - дзеркальний масив. Дані на кожному із дисків ідентичні. Організація масиву в RAID 1 підвищує швидкість  читання та рівень надійності дискової системи (при пошкодженні одного із дисків, система буде працювати з іншим робочим), але все це за рахунок втрати корисної ємності одного із дисків. Тобто використовуючи два диски місця буде доступно вдвічі менше, адже вони оперують тими ж самими даними.


неділя, 9 червня 2013 р.

Використання Logical Volume Manager (LVM)

Вирішив написати пару слів про LVM, адже використання цієї технології при налаштуванні серверів досить актуальне та і щоб просто не забути.
LVM (Logical Volume Manager) - менеджер логічних томів, додатковий рівень абстракції між фізичними (/dev/sda1, /dev/sda2 і  т.д.) та логічними томами ( /home, /root, /boot і т.д.), що значно підвищує гнучкість файлової системи.Використовуючи менеджер логічних томів, можна відносно легко змінювати розмір вже існуючих логічних томів (додавши новий HDD, можна просто пододавати місця на уже створені розділи, таким чином вирішивши проблему браку місця) чи робити бекапи без перевантаження/вимкнення/зупинки сервісів. Створення розділів з LVM не обмежене розміром фізичного диска, тобто один розділ може займати розмір декількох вінчестерів чи розділ може знаходитись частково на декількох HDD.
Отже схематично рівні знаходяться так:


PV- Physical volume, фізичний том. Це власне диск чи просто розділ на диску.
VG - Volume group, группа томів. Найвищий рівень абстрактної моделі LVS. До групи томів входять фізичні томи.
LV - Logical volume, логічний том. Власне це еквівалент звичайного розділу в не-LVM системі. В данному випадку Volume group поділяється на окремі розділи на зразок /dev/mapper/diskone, /dev/mapper/disktwo. Наділі кожний логічний том монтується в відповідну директорію /, /usr, /home і т.д.
Переходимо до практики. Перш за все встановимо пакет для підтримки LVM:

# apt-get install lvm2

Необхідно створити чи використати існуючі неформатовані розділи. За допомогою fdisk я створив два тестових розділи /dev/sda7 та /dev/sda8 і ініціалізував їх для використання як розділів для LVM:

# pvcreate /dev/sda7
# pvcreate /dev/sda8


пʼятниця, 10 травня 2013 р.

Віртуалізація з KVM

KVM (або Kernel-based Virtual Machine) - це програмне рішення, що забезпечує віртуалізацію в середовищі Linux на платформі x86 (а з версією ядра 3.9 для ARMv7 також), яка підтримує апаратну віртуалізацію на базі Intel VT або AMD SVM.
Програмне забезпечення KVM складається з завантаження модуля ядра (що зветься kvm.ko), що надає базовий сервіс віртуалізації, специфічного для процесора модуля kvm-amd.ko або kvm-intel.ko, і компонентів для користувача режиму (модифікованого QEMU). Всі компоненти KVM є програмним забезреченням із відкритим вихідним кодом. Компонент ядра, необхідний для роботи KVM, включений в основну гілку Linux починаючи з версії 2.6.20 (лютий 2007). Тож для роботи з даним типом віртуалізації варто мати лише ядро більш-менш сучасної версії.
Самостійно KVM не виконує емуляції. Замість цього програма (QEMU), що працює в просторі користувача, використовує інтерфейс /dev/kvm для налаштування адресного простору гостя віртуальної машини, через нього ж і емулює пристрої введення-виведення і відеоадаптер. (c) Wikipedia

Тож приступаємо! Установка КVM віртулізації буде проведено для Ubuntu 12.10. Спершу перевіримо чи підтримує процесор хост-системи апаратну віртуалізацію:

# egrep '(vmx|svm)' --color=always /proc/cpuinfo

Має видати щось на зразок цього:

flags:  fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt lahf_lm arat dtherm tpr_shadow vnmi flexpriority ept vpid

Якщо вивід відсутній - то можна завершувати спроби встановлення KVM, адже даний тип віртуалізації не працює на процесорах без підтримки SVM чи Intel VT. Як варіант можна використати XEN PV (паравіртуалізацію), що власне є також дуже хорошим варіантом. Але загалом у всіх відносно сучасних процесорах не має бути таких проблем.
Тепер встановимо супутнє програмне забезпечення:

# sudo -i
# apt-get install ubuntu-virt-server python-vm-builder kvm-ipxe

vm-builder - це python-скрипт для зручного створення віртуальних машин Ubuntu.
Додамо користувача root в групи libvirtd та kvm:

# adduser `id -un` libvirtd
# adduser `id -un` kvm

Перелогінюємось і перевіряємо чи коректно було встановлено KVM:

# virsh -c qemu:///system list
  Id    Name                           State
----------------------------------------------------

четвер, 25 квітня 2013 р.

MySQL Sandbox (декілька MySQL-демонів різних версій на одному хості)



Продовжуємо розгляд установки декількох mysql-демонів на одному хості. Цього разу мова піде про Mysql Sandbox.

Mysql Sandbox - це набір скриптів на Perl для автоматизації та швидкого розвертання інстансів MySQL: за допомогою нього можна лиш однією командою підняти одночасно декілька mysql-демонів різних версій,  налаштувати реплікацію різних типів тощо. Причому установка додаткових інстансів не зачіпає директорій оригінального mysql, якщо він присутній на сервері. Насправді дуже корисно мати такий інструмент для тестування нових фіч чи для перевірки поведінки реплікації при певних діях.

Для початку завантажимо tar-архів mysql необхідної версії:


# wget -O mysql-5.6.11-linux-glibc2.5-x86_64.tar.gz http://www.mysql.com/get/Downloads/MySQL-5.6/mysql-5.6.11-linux-glibc2.5-x86_64.tar.gz/from/http://cdn.mysql.com/

Тепер переходимо до самого завантаження Mysql Sandbox:

# wget https://launchpad.net/mysql-sandbox/mysql-sandbox-3/mysql-sandbox-3/+download/MySQL-Sandbox-3.0.33.tar.gz

Розпаковуємо і переходимо в директорію:

# tar xvfz MySQL-Sandbox-3.0.33.tar.gz
# cd MySQL-Sandbox-3.0.33

І тепер власне потрібно визначитись з користувачем від якого будуть працювати mysql-інстанси. Це може бути рут чи звичайний користувач (на ваш вибір). Для рута виконуємо наступне:

# export SANDBOX_AS_ROOT=1

четвер, 18 квітня 2013 р.

Mysqld_multi: декілька демонів mysql на одному хості

Іноді постає необхідність встановити ще одну базу даних на тому ж хості, але просто на іншому порту. І як показала практика, краще за все це робити за допомогою функціоналу mysqld_multi, котрим володіють останні версії mysql.

1) Ясна справа у вас має бути встановлений mysql-server та mysql-client.

2) Зупиняємо наявний демон, якщо його запущено, бекапимо конфіг /etc/mysql/my.cnf (чи просто /etc/my.cnf).

3) Створюємо новий:

cat /etc/my.cnf

[mysqld_multi]
mysqld = /usr/bin/mysqld_safe
mysqladmin = /usr/bin/mysqladmin

[mysqld1]
datadir = /var/lib/mysql1
socket = /var/lib/mysql1/mysql.sock
pid-file = /var/run/mysqld/mysqld1.pid
user = mysql
port = 3306
log-error=/var/log/mysqld1.log

[mysqld2]
datadir=/var/lib/mysql2
socket=/var/lib/mysql2/mysql.sock
pid-file = /var/run/mysqld/mysqld2.pid
user=mysql
port = 3307
log-error=/var/log/mysqld2.log

[mysqld3]
datadir=/var/lib/mysql3
socket=/var/lib/mysql3/mysql.sock
pid-file = /var/run/mysqld/mysqld3.pid
user=mysql
port = 3308
log-error=/var/log/mysqld3.log

неділя, 3 лютого 2013 р.

Налаштування Puppet

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

Puppet - кроссплатформове клієнт-серверне програмне забезпечення, котре дозволяє централізовано керувати конфігурацією операційних систем та програм, встановлених на групі серверів. Puppet написаний на мові програмування Ruby.

Puppet має клієнт-серверну архітектуру: puppet master (сервер) та puppet agent (клієнт):


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

четвер, 17 січня 2013 р.

Linux HA: Pacemaker / Corosync

При проектуванні високонавантажених систем високої доступності важливо задуматись про надлишковість ресурсів, тобто при падінні якогось важливого серверу (сервісу) було б добре, коли його "підстрахує" інший сервер, налаштований аналогічно. Саме задля цього компанії Red Hat та Novell розробили дуже класну штуку Pacemaker+Corosync.

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


На малюнку зображено архітектуру Pacemaker і ось, якщо говорити коротко, що до неї входить:

1. Не кластерні компоненти (зображені зеленим кольором) - це ресурси та скрипти, що відповідають за їхній старт, зупинку чи моніторинг.

2. Менеджер ресурсів Pacemaker  (зображений синім кольором) - "мозок" кластера, проводить обробку подій та процесів (даних, що представили нижчі рівні) та приймає рішення щодо включення/виключення нод із кластеру. Власне Pacemaker розраховує ідеальний стан кластеру шляхом слідування правилам.

3. Інфраструктура низького рівня (зображено червоним), до якої входить Corosync. Corosync забезпечує обмін повідомленнями з Pacemaker щодо стану серверів в кластері (який із серверів працює чи ні і т.д. )

Для початку опишемо конфігурацію, котру маємо:

Node-1:
Hostname: pcmk-1
IP: 192.168.1.23

Node-2:
Hostname: pcmk-2
IP: 192.168.1.24

На обох серверах встановлено CentOS 6.3 зі стандартним ядром 2.6.32. Нехай на кожному сервері працює Apache і необхідно, щоб у разі падіння одного з серверів відбувався failover, тобто перемикання на працюючий сервер. Як наслідок такий варіант забезпечить максимальну доступність, лише піде деякий час на перемикання нод. 


Переходимо до конфігурації. Редагуємо /etc/hosts (чи свій власний dns, якщо такий є) задля перетворення доменних імен в IP:

# grep pcmk /etc/hosts
192.168.1.23 pcmk-1
192.168.1.24 pcmk-2

пʼятниця, 4 січня 2013 р.

Реплікація MongoDB: ReplicaSet

Зовсім нещодавно, я писав про реплікацію MySQL, тож хотілося б продовжити традицію. Цього разу мова піде про реплікацію MongoDB.

MongoDB підтримує два типи реплікацій Master-Slave (на кшталт такої в MySQL) та ReplicaSet. Остання - це прогресивніший варант, так як по-суті одразу забезпечує failover: обирання майстра, у разі відмови попереднього проходить "голосуванням" наявних інстансів (копій).  Це вже не кажучи про те, що ReplicaSet забезпечує читання зі слейвів (або як кажуть secondary-серверів), тим самим підвищуючи швидкість читання. Запити на запис відбуваються лише на головному (primary) сервері. Коротше кажучи, все вищесказане гарно ілюструє цей малюнок:


Приступимо до конфігурації. 3 інстанси демона MongoDB будуть запущені на локалхості, проте на різних портах.
Перед налаштуванням не забуваємо встановити базу данних.
Щоб не захламлювати систему створимо папку mongodb, а вже в ній папки 1, 2, 3 для кожної копії:

mkdir mongodb
cd mongodb
mkdir 1 2 3 

Запускаємо 3 копії демону mongod на портах 2700(1|2|3):

$ mongod --replSet test --dbpath 1 --port 27001 --smallfiles --oplogSize 50 --logpath 1.log --fork
forked process: 18922
all output going to: /media/other/mongodb/replication/1.log
child process started successfully, parent exiting

$ mongod --replSet test --dbpath 2 --port 27002 --smallfiles --oplogSize 50 --logpath 2.log --fork
forked process: 18983
all output going to: /media/other/mongodb/replication/2.log
child process started successfully, parent exiting

$ mongod --replSet test --dbpath 3 --port 27003 --smallfiles --oplogSize 50 --logpath 3.log --fork
forked process: 19029
all output going to: /media/other/mongodb/replication/3.log
child process started successfully, parent exiting