Translate

Показ дописів із міткою centos. Показати всі дописи
Показ дописів із міткою centos. Показати всі дописи

неділя, 9 лютого 2014 р.

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

неділя, 2 лютого 2014 р.

Віртуалізація з 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

пʼятниця, 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
----------------------------------------------------

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

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

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

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

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


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

пʼятниця, 21 грудня 2012 р.

Syslog-ng для централізованого збирання логів


Рано чи пізно постає питання про збирання логів всієї купи серверів, що у вас, у одному місці. І причин, щоб саме так зробити, є декілька: по-перше, так зручно, по-друге, - так безпечніше, адже логи будуть зберігатись в декількох місцях (як мінімум в двох). Коротше кажучи, якщо ви вже читаєте цю статтю - то ви маєте знати навіщо це вам.

Перейдемо до суті. Налаштування проводилось на двох тестових віртуальних машинах:

centos1 - 192.168.1.23
centos2 
- 192.168.1.24

Тому на кожну із них встановлюємо syslog-ng. В CentOS це робиться наступним чином:

# yum install syslog-ng

Нехай centos1 буде головним syslog-ng сервером, що буде слухати 514-й порт, приймати всі логи і розкладати куди-треба. Centos2 буде відправником логів на перший сервер.

Конфігураційний файл syslog-ng на centos2, тобто відправника логів:

# Опис джерела всього потоку логів, що власне нас цікавить.
source s_all {
  internal();
  unix-stream("/dev/log");
  file("/proc/kmsg" program_override("kernel: "));
  file("/var/log/dmesg");
};

# Описуємо які саме файли потрібно буде відсилати. Перед відсиланням до 
# кожної рядка логу буде додано назву демона, який його відіслав 
# (за допомогою опції 'program_override').
source mysqld_log { file("/var/log/mysqld.log" program_override("mysqld")); };
source httpd_log { file("/var/log/httpd/error_log" program_override("httpd")); };

# Описуємо місце/сервер куди будуть відправлятись файли
destination remote { udp("192.168.1.23" port(514)); };

#Найголовніша частина: куди саме і які будуть відсилатись логи.
log { source(s_all); destination(remote); };
log { source(mysqld_log); destination(remote);};
log { source(httpd_log); destination(remote);};

Конфігураційний файл syslog-ng на centos1, тобто сервера, що ці логи прийматиме:

# Описуємо джерело логів - сервер мережі.Тобто логи, котрі прийшли на порт syslog-ng.
source s_udp { udp(ip(0.0.0.0)); };

# Описуємо фільтри. Параметр match означає, що обирати з усього потоку повідомлень 
# лише рядки з указаним значенням
filter mysqld { match("mysqld" value("MESSAGE")); };
filter httpd { match("httpd" value("PROGRAM")); };

# Місце куди будуть зберігатись логи.
destination df_remote { file("/var/log/remote/$HOST.other.log"); };
destination mysqld_log { file("/var/log/remote/$YEAR.$MONTH.$DAY/mysqld.log" owner("root") group("root") perm(0640) dir_perm(0750) dir_group("root"));};
destination httpd_log { file("/var/log/remote/$HOST.apache.log"); };

# Власне сам процес логування - це комбінація всіх вищезазначених параметрів.
log { source(s_udp); destination(df_remote); };
log { source(s_udp); filter(mysqld); destination(mysqld_log); };
log { source(s_udp); filter(httpd); destination(httpd_log); };

Тобто, все відбувається наступним чином:

1) Хост centos2 відправляє логи (всі системні логи+mysqld логи+apache логи) на centos1. Перед відправкою логи httpd помічаються значенням, що стоїть у параметрі program_override. Тобто кожен запис логу mysqld.log помітиться словом mysqld, відповідно httpd.log - словом httpd.

2) Логи, відіслані сервером centos2 приходять на centos1 і починають сортуватись. Всі логи загальні підуть в /var/log/remote/$HOST.other.log,а логи httpd та mysqld за допомогою директиви match будуть сортуватись в окремі папки.

Ну власне все, всі питання або зауваження пишіть в коментарі.

Посилання:
https://wiki.archlinux.org/index.php/Syslog-ng