OpenVZ Web Panel

Зовсім нещодавно я писав про OpenVZ віртуалізацію. І не те щоб мені було дуже потрібно, проте я випадково наткнувся на досить симпатичну веб-панель для управління контейнерами і вирішив її спробувати. Тож поділюсь рецептом налаштування OpenVZ Web Panel.

OpenVZ Web Panel - досить непоганий варіант управління OpenVZ-контейнерами, адже з ним відпадає потреба кожен раз логінитись по ssh задля створення нового контейнеру чи зміни параметрів існуючого. У OpenVZ Web Panel також є можливість клонувати чи бекапити діючу віртуальну машину в пару кліків, тобто управління сервером стає справді зручним і швидким.

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

# yum install ruby-devel sqlite sqlite-devel ruby-rdoc

# yum install make gcc

# yum install lsb_release

# gem install sqlite3-ruby

Скачуємо і запускаємо скрипт інсталяції:

# wget -O - http://ovz-web-panel.googlecode.com/svn/installer/ai.sh | sh

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

Віртуалізація дуже актуальна тема, адже дозволяє більш раціонально використовувати ресурси серверу. Дещо раніше я писав про віртуалізацію на базі KVM, що власне є технологією повної віртуалізації, на відміну від OpenVZ, про яку і піде далі мова.

OpenVZ — це реалізація технології віртуалізації на рівні операційної системи, яка базується на ядрі Linux. OpenVZ дозволяє на одному фізичному сервері запускати безліч ізольованих копій операційної системи, так званих контейнерів (Virtual Environments, VE).

Оскільки OpenVZ базується на ядрі Linux, в ролі «гостьових» систем можуть виступати тільки дистрибутиви GNU/Linux. Проте віртуалізація на рівні операційної системи у OpenVZ дає також і певні переваги, а саме: зручність у адмініструванні, щільніше розміщення віртуальних контейнерів в хост-системі (що зазвичай позитивно відображено на вартості VPS-хостингу), і дещо кращу продуктивність в порівнянні з технологіями повної віртуалізації.

Звісно, що і недоліків достатньо. Головний із них, що на відміну від KVM, модулі OpenVZ не входять у ванільне ядро, тому для фунціонування останнього необхідне окреме ядро і версія його далеко не остання. На момент публікації цієї статті, остальна стабільна версія - 2.6.32-042stab084.14. Із цього по-суті випливає, що хост-системою на OpenVZ може виступати не кожен дистрибутив, а лише з ядром біля 2.6.32 версії. Тому скажімо OpenVZ-ядро під Ubuntu 12.04 LTS навряд заведеться (що я вже спробував), адже ядро тут версії 3.8.0. Але не все так погано, адже для RedHat 6 (CentOS 6, Scientific Linux 6) та Debian 7 "Wheezy" все просто інсталюється і ці дистрибутиви офіційно підтримуюються Parallels.

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

Про певні інші недоліки та переваги можна прочитати тут.

Теорія без практики – мертва, тож самий час описати установку і налаштування хост-системи для OpenVZ. У якості хост-системи я обрав CentOS 6.5 (необхідно лиш попередньо не забути перевірити наявність правил iptables). Додаємо репозиторії для установки ядра OpenVZ та утиліт для роботи із контейнерами:

# wget -P /etc/yum.repos.d/ http://ftp.openvz.org/openvz.repo
# rpm --import http://ftp.openvz.org/RPM-GPG-Key-OpenVZ

Speedtest from shell console

Існують різні способи для перевірки швидкості інтернет з'єднання і мабуть найбільш популярний - це speedtest.net. Проте для цього необхідний браузер із підтримкою adobe flash і середовище в котрому він власне зможе запускатись. Тому у якості альтернативи раджу спробувати speedtest-cli, консольну програму, що виконує абсолютно ті ж функції.

Установку speedtest-cli можна виконати декількома способами: наприклад через pip чи easy_install. Тому спершу встановимо python-pip:

# apt-get install python-pip

Та після скачаємо і установимо speedtest-cli:

# pip install speedtest-cli

Все готово для нашої початкової цілі, тому запускаємо:

$ speedtest

Retrieving speedtest.net configuration...

Retrieving speedtest.net server list...

Testing from Domashnya Merezha LLC (79.28.193.171)...

Selecting best server based on ping...

Hosted by LLC"Astelit" (Kiev) [2.52 km]: 10.649 ms

Testing download speed........................................

Download: 73.08 Mbit/s

Testing upload speed..................................................

Upload: 90.80 Mbit/s

Monitoring SNMP device with Cacti (setup and configuration)

Cacti - опенсорс моніторингова система, написана як фронтенд до утиліт RRDtool (RRD, Round-robin Database, кільцева база даних). RRDtool включають в себе можливість графічного відображення інформації, що зберігається; це може бути зміна в часі завантаження процесора, завантаження мережевого інтерфейсу і тд. 

Cacti є зручним інструментом для задання параметрів побудови графіків за допомогою RRDtool, а також має багато готових темплейтів для відображення звичних даних на кшталт використання ресурсів системи.

У статті я спробую описати його установку та конфігурацію.

Встановлюється все досить просто:

# apt-get update

# apt-get install snmpd cacti cacti-spine

Демон snmpd необхідно установити на всіх машинах, що будуть моніторитись.

Установщик запропонує обрати вебсервер з котрим буде працювати Cacti (Apache чи Lighttpd) та деякі інші питання, з якими необхідно погодитись. У якості веб-сервера я використав Apache.

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

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

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