Translate

неділя, 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