Встановлення Proxmox в Debian на raid 1
На сьогоднішній день існує декілька найбільш популярних гіпервізора для побудови віртуальної інформаційної системи. У даній статті я розгляну установку і настройку безкоштовної системи віртуалізації proxmox 6 на базі ОС Debian 10, встановленої на RAID 1. Як гіпервізора вона використовує опенсорсний KVM і LXC, дозволяючи віртуалізувати найбільш популярні ОС.
Вступ
Деякий час назад я дізнався про систему віртуалізації proxmox на базі KVM. Раніше з цим гіпервізором я був знайомий, але він мені не сподобався через відсутність зручних інструментів управління під windows. Це було давно, років 5 тому. Мені довелося адмініструвати вже налаштований гипервизор і мені це не сподобалося, занадто багато дій доводилося робити в консолі. Не скажу, що мені це прям не подобається, але я не бачу сенсу в консолі робити те, що в інших Гіпервізор мишкою ти робиш в 5 разів швидше в gui. Свого часу намагаюся економити і використовувати раціонально.
Все змінилося, коли я вирішив подивитися на Proxmox . Проста установка і зручна панель управління через браузер залучили відразу. Спробував, потестувати, ніби все непогано працює, управління зручне і зрозуміле. Особливо сподобалися бекапи з коробки. Чи не наважувався використовувати в реальній роботі, тому що не маю досвіду роботи c zfs, а ставити гипервизор на поодинокі диски погана ідея. Раніше я використовував XenServer, встановлений на mdadm raid1, поки він не перестав підтримувати такий режим роботи. Proxmox чомусь не підтримує установку на простий і зрозумілий mdadm, але при цьому є zfs. Цей момент мені щиро не зрозумілий, якщо враховувати, що proxmox працює на базі системи Debian, яка без проблем встановлюється на програмний рейд.
У підсумку я вирішив встановити, налаштувати і протестувати proxmox, встановлений на програмний raid 1 mdadm. Диски відключав, виймав, вставляв назад. Всі прекрасно працює. Відмовостійкість на рівні дисків забезпечена, значить можна використовувати в реальній роботі. Я і використовую останні пару років. Окремо згадаю, що мене відразу привернуло в KVM – можливість прокидати USB. До сих пір Hyper-V і XenServer не вміють це робити. Перший зовсім не вміє, другий ніби як-то прокидає, але без гарантій і не всі пристрої працюють. А в KVM без проблем вийшло прокинути USB в виртуалку і увіткнути туди HASP ключ від 1С. Для малих і середніх офісів це актуальна потреба.
Для того, щоб встановити proxmox на raid 1 підемо обхідним шляхом. Стандартний інсталятор не дає нам необхідної можливості установки на рейд. У нас є 2 варіанти вирішення проблеми:
- Установка спочатку голою системи Debian 10 на raid1, а потім на неї встановлюється proxmox. Кінцевий результат не буде відрізнятися від інсталяції зі стандартного диска.
- Встановити систему proxmox на одиночний диск, а потім перенести її на raid1.
Я пробував обидва способи, перший мені здався більш простим і зрозумілим, тому займемося його реалізацією.
Установка proxmox на mdadm raid 1 в debian 10
Насамперед нам потрібно встановити чисту систему Debian . На даний момент це версія 10 Buster . У мене є окрема стаття по установці Debian . Там докладно описаний процес установки системи на Софтова рейд mdadm. В кінці я на прикладі показав, що робити, коли диск виходить з ладу, як його міняти. Я на практичному прикладі продемонстрував відмовостійкість такого рішення, тому не буду тут докладно на цьому зупинятися.
Завантажуйте дистрибутив останньої версії Debian. Взяти його можна, наприклад, на Yandex.Mirror , конкретно тут . Для установки підійде образ CD-1 або netinst . Починайте стандартну установку і доходите до пункту настройки жорсткого диска. Я буду використовувати консольне відображення, що не графічне. Мені так зручніше. Принципових відмінностей немає, можете робити за аналогією, якщо почали установку в графічному режимі. Коли справа дійде до настройки диска, вибирайте варіант ручної розмітки.
Якщо ви робите установку на чисті диски, то вас повинна зустріти така картина стану дисків:
Якщо є якісь розділи, то видаліть їх все, щоб були чисті диски. Для написання статті я використовую віртуальну тестову середу, диски виділені невеликого обсягу. Для навчальних цілей цього достатньо. Я розіб’ю диски наступним чином:
| / boot | Завантажувальний розділ 500 мб |
| / | Кореневий розділ майбутньої системи, 10 гб виділяю в тесті, в реальній роботі рекомендую зробити 30-50 гб про всяк випадок |
| Вільне місце | Все інше простір диска залишаю нерозмічену. Як його розділити і використовувати буде залежати від ваших потреб. Пізніше покажу як його все задіяти під різні сховища (віртуальних машин, образів або резервних копій) |
Створюємо в інсталятор зазначені розділи на обох дисках. Не буду розписувати по кроках як їх зробити, сподіваюся самі розберетеся, це не складно. Повинна вийти така картина:
Параметри першого розділу на 500 Мб:
Параметри другого розділу на 10 Гб:
Обидва розділу повинні бути Primary .
Тепер створимо 2 окремих raid масиву на 500 мб і 10 гб. Вибираємо розділ Configure Software RAID , далі Create MD device, потім RAID1, 2 диска в масиві, і в завершенні вибираємо 2 наших розділу по 500 мб:
Те ж саме робимо з розділами по 10Гб – об’єднуємо їх в рейд:
Як закінчите, тиснете Finish. У вас повинна вийти така картина:
Тепер потрібно створити файлову систему на рейд масивах. Зробимо на першому розділ / boot ext2, а на другому корінь системи – / і файлову систему ext4. У результаті повинно вийти ось так:
Застосовуємо зміни і продовжуємо стандартну установку. У вас буде попередження про те, що невідомий розділ для swap.
Ігноруйте його, потім підключимо swap окремо у вигляді файлу. В процесі установки вам буде запропоновано вибрати набір пакетів. Не ставте нічого зайвого, тільки ssh сервер і системні утиліти.
В кінці буде запропоновано встановити завантажувач на один з дисків. Можете вибрати будь-який диск, пізніше ми встановимо завантажувач на другий диск і переконаємося, що він буде встановлений на обох дисках. Це потрібно для того, щоб система могла завантажуватися з будь-якого з дисків, в разі виходу одного з ладу.
Після установки рекомендую виконати базову настройку Debian . Це не обов’язково, подивіться на мої рекомендації і робіть те, що вважаєте за потрібне. Якщо гипервизор буде всередині локальної мережі, то фаєрвол можна вимкнути, порт ssh не чіпати, а логін під root дозволити. Оновитися, налаштувати мережу , час і корисні утиліти. Так само на всякий випадок створіть swap розділ хоча б на 2-4 гігабайти.
Тепер встановимо grub на обидва жорстких диска. Підключаємося до сервера по ssh і виконуємо команду:
# Dpkg-reconfigure grub-pc
На всі питання залишаєте дефолтні значення, в кінці вибираєте обидва жорстких диска для установки завантажувача:
Про всяк випадок перевіримо як встала система на жорсткі диски:
# Df -h Filesystem Size Used Avail Use% Mounted on udev 3.9G 0 3.9G 0% / dev tmpfs 798M 17M 782M 3% / run / Dev / md1 9.1G 1020M 7.7G 12% / tmpfs 3.9G 0 3.9G 0% / dev / shm tmpfs 5.0M 0 5.0M 0% / run / lock tmpfs 3.9G 0 3.9G 0% / sys / fs / cgroup / Dev / md0 460M 47M 390M 11% / boot tmpfs 798M 0 798M 0% / run / user / 0
# Cat / proc / mdstat
Personalities: [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md0: active raid1 sdb1 [1] sda1 [0]
486400 blocks super 1.2 [2/2] [UU]
md1: active raid1 sda2 [0] sdb2 [1]
9756672 blocks super 1.2 [2/2] [UU]
Все в порядку, вийшло так, як і задумували. На даному етапі можна повитягали жорсткі диски і перевірити як система працює без одного з них, навчитися замінювати зіпсований диск. Команди рекомендації не буду приводити, щоб не роздувати статтю. Мінлива по роботі з mdadm в інтернеті повно. До того ж, я про це розповідаю в статті про установку debian, посилання на яку вже давав раніше. Рекомендую відразу налаштувати моніторинг mdadm в zabbix .
Переходимо безпосередньо до установки proxmox. Для цього редагуємо файл / etc / hosts і наводимо його строго до наступного вигляду. Якщо щось буде не так, як зазначено у мене, отримаєте помилку установки з дуже великою часткою ймовірності. Я на цьому моменті пристойно застряг, коли розбирався.
# Mcedit / etc / hosts
127.0.0.1 localhost.localdomain localhost 192.168.155.104 proxmox6.local proxmox6 pvelocalhost
| proxmox6 | Ім’я сервера, вказане під час установки |
| local | Домен, вказаний під час установки |
| 192.168.155.104 | IP адреса сервера |
Перевірити вірність налаштувань можна командою:
# Hostname --ip-address 192.168.155.104
У відповідь повинні отримати свій ip адресу.
Додаємо в список репозиторіїв ріпу proxmox і стандартні репозиторії debian. Я буду використовувати дзеркало яндекса, все інше можна закомментировать:
# Mcedit /etc/apt/sources.list
deb http://mirror.yandex.ru/debian/ buster main non-free contrib deb-src http://mirror.yandex.ru/debian/ buster main non-free contrib deb http://download.proxmox.com/debian/pve buster pve-no-subscription
Якщо не підходить репозиторій яндекса (заблокований), можна скористатися будь-яким іншим, наприклад http://mirror.corbina.net/debian/
Додаємо цифровий підпис proxmox сховища:
# Wget http://download.proxmox.com/debian/proxmox-ve-release-6.x.gpg -O /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg
Якщо раніше не оновили систему, то оновіться і про всяк випадок перезавантажте сервер після цього:
# Apt update && apt full-upgrade # reboot
Тепер встановлюємо саму систему віртуалізації proxmox:
# Apt install proxmox-ve postfix open-iscsi
Якщо отримаєте помилку під час установки:
dpkg: error processing package proxmox-ve (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: pve-cluster libpve-access-control librados2-perl pve-firewall pve-ha-manager qemu-server pve-container pve-manager proxmox-ve
Перевіряйте файл hosts. У мене там зайві рядки були, крім тих, що я вказав раніше. Коли виправив, установка пройшла без помилок. Після закінчення установки перезавантажте сервер, щоб загрузилось нове ядро. Якщо все в порядку, то побачите вікно вітання на моніторі сервера:
Відкривайте браузер за вказаною адресою і заходите в web інтерфейс. Нагадую, що web порт proxmox за замовчуванням – 8006 . Не забувайте його вказувати в рядку адреси в браузері. Ви повинні побачити попередження браузера щодо сертифіката. Так і повинно бути, по-замовчуванню використовується самоподпісанний сертифікат.
Базова настройка proxmox
Заходимо через браузер за вказаною адресою. У вікні логіна вводите системний root і пароль від нього. Нас відразу ж зустрічає попередження:
You do not have a valid subscription for this server. Please visit www.proxmox.com to get a list of available options.
У нас немає платної підписки, тому потрібно видалити зі списку репозиторіїв платний. Для цього відкриваємо консоль сервера і закомментіруем репозиторій:
# Mcedit /etc/apt/sources.list.d/pve-enterprise.list
#deb https://enterprise.proxmox.com/debian/pve buster pve-enterprise
Далі бачимо головну сторінку управління гіпервізором proxmox 6.
Налаштування мережі
Зазвичай для віртуальних машин досить 3 режиму роботи мережі:
- Режим Bridge . В цьому режимі віртуальні машини отримують ip адресу з однієї підмережі з гіпервізором і мають в неї прямий доступ.
- Режим NAT . Віртуальні машини отримують ip адреси у своїй віртуальній підмережі, в зовнішню мережу виходять через гипервизор і налаштований на ньому NAT.
- Routed режим , коли шлюзом в інтернет є одна з віртуальних машин.
Я використовую всі три режими роботи мережі, в залежності від ситуації. Покажу це на прикладах.
Як створити bridge в proxmox
Для створення мережевого інтерфейсу типу bridge в proxmox, в web інтерфейсі перейдіть в розділ Network і натисніть Create -> Linux Bridge.
Заповнюєте необхідні поля. Обов’язковими є поле IP address, Gateway, Bridge Ports.
З такими настройками ви зможете в якості локального інтерфейсу залишити тільки vmbr0, а eth0 відключити. Це на ваш розсуд. Якщо залишити обидва інтерфейсу, то ваш proxmox буде доступний за двома різними ip адресами. Якщо отримаєте помилку:
Видаліть налаштування шлюзу на eth0, додайте його на vmbr0.
Відразу звертаю увагу, що після створення бриджу, в системі створюється новий файл з мережевими настройками – /etc/network/interfaces.new . Там відображені зроблені нами зміни. Інформація з нього буде додана в основний файл interfaces після перезавантаження. Перезавантажте сервер і перевірте. Якщо все в порядку, то ви зможете підключатися і по ssh і по web доступу до обох ip адресами – eth0 і vmbr0.
Дуже уважно поставтеся до налаштування мережі в proxmox. Переконайтеся, що у вас є доступ до консолі гипервизора. Мені часто доводиться налаштовувати виділені сервери. Проте, іноді втрачаю доступ до сервера через якийсь помилки або неуважності. Та й у самому proxmox можуть бути проблеми.
У мене були ситуації, коли виконуєш описані вище дії, перезавантажувати сервер – він недоступний. Заходжу локально, відкриваю файл / etc / network / interfaces , і видаляю якусь зайву закоментувавши рядок, через яку не піднімалася мережу. Подробиць вже не пам’ятаю, що саме було не так, але пару раз ловив такі помилки.
Розповім про ще один нюанс. Під час створення бриджу вас обов’язково просять вказати статичні мережеві настройки. А іноді потрібно використовувати dhcp сервер. Через web інтерфейс це зробити не вийде, або я не зрозумів як. Роблю іншим чином. Пишу довільні настройки через gui, а потім виправляю файл / etc / network / interfaces . Ось приклад налаштування мережі, коли bridge отримує мережеві настройки по dhcp.
source /etc/network/interfaces.d/* auto lo iface lo inet loopback allow-hotplug eth0 #iface eth0 inet dhcp auto vmbr0 iface vmbr0 inet dhcp bridge-ports eth0 bridge-stp off bridge-fd 0
Перезавантажувати сервер і переконуюся, що все працює як треба.
При цьому в web інтерфейсі буде ось так.
Налаштування NAT для віртуальних машин
Для того, щоб налаштувати зручний спосіб підключення до мережі віртуальних машин з використанням NAT, коли все виртуалки разом з гіпервізором будуть в єдиній віртуальній мережі бачити один одного, потрібно створити ще один bridge і налаштувати трансляцію адрес за допомогою iptables на самому гіпервізора. Зробимо це.
Заходимо по ssh на гипервизор і додаємо в файл з новими мережевими настройками кілька рядків:
# Mcedit /etc/network/interfaces.new
auto vmbr1 iface vmbr1 inet static address 10.10.10.1 netmask 255.255.255.0 bridge_ports none bridge_stp off bridge_fd 0 post-up echo 1> / proc / sys / net / ipv4 / ip_forward post-up iptables -t nat -A POSTROUTING -s '10 .10.10.0 / 24 '-o vmbr0 -j MASQUERADE post-down iptables -t nat -D POSTROUTING -s '10 .10.10.0 / 24 '-o vmbr0 -j MASQUERADE
Пояснюю, що ми зробили:
- Дозволили форвард пакетів між мережевими інтерфейсами. Без цього гипервизор не зможе працювати в ролі шлюзу.
- Додали правила iptables для настройки NAT.
Зберігаємо файл і перезавантажуємо сервер. В налаштуваннях мережі віртуальних машин вказуєте інтерфейс vmbr1 , а в самій системі виртуалки вручну прописуєте мережеві настройки, де адреса шлюзу дорівнює адресою інтерфейсу vmbr1 – 10.10.10.1, а ip адресу самої машини буде в підмережі 10.10.10.0/24 . Всі віртуальні машини, у яких встановлено бридж vmbr1 будуть бачити один одного.
Якщо вам не хочеться на кожній ВМ вручну прописувати IP, можна налаштувати dhcp сервер або на одній з віртуалок, або на самому гіпервізора. Головне призначити йому потрібний інтерфейс – vmbr1. Налаштування dhcp сервера виходить за рамки цієї статті, не буду на цьому зупинятися. Для загального використання досить того, що я вже вказав.
Routed режим мережі
Останній варіант, який я іноді використовую. В якості шлюзу в інтернет для локальних машин, а якщо необхідно і офісу, виступає віртуальна машина. Цей режим нічим особливо не відрізняється від режиму NAT, крім того, що сам нат на гіпервізора не потрібен, так як натіть трафік буде шлюз на віртуальній машині. Нам потрібні будуть 2 бриджу: один для передачі мережі провайдера в віртуальну машину-шлюз, другий для мережі віртуальних машин. Налаштування може трохи відрізнятися, в залежності від того, що ви хочете отримати. Тут можуть бути 2 варіанти:
- У вас гипервизор з 1 фізичної мережевою картою, в яку застромлять шнурок з інтернетом від провайдера. Вся ваша інфраструктура віртуальна, доступ тільки через інтернет. Наприклад, ви орендуєте виділений сервер десь і використовуєте для різних цілей.
- На вашому фізичному сервері 2 і більше мережевих карт. В першу приходить інтернет від провайдера, друга дивиться в локальну мережу. На гіпервізора віртуальні машини використовуються користувачами з локальної мережі і знаходяться з ними в єдиному адресному просторі.
В обох випадках є ще варіанти настройки в залежності від кількості ip адрес, які вам видає провайдер. Якщо у вас тільки 1 зовнішній IP адреса, ви повинні його прокинути в віртуальний шлюз. Тільки він матиме доступ в інтернет. Для цього ви повинні створити бридж разом з мережевою картою, в яку приходить інтернет, але при цьому сам бридж не повинен мати IP адреси. Ось приклад, як це має виглядати в першому варіанті:
iface eth0 inet manual auto vmbr0 iface vmbr0 inet manual bridge_ports eth0 bridge_stp off bridge_fd 0 auto vmbr1 iface vmbr1 inet static address 10.0.0.1 netmask 255.255.255.0 gateway 10.0.0.2 bridge_ports none bridge_stp off bridge_fd 0
У eth0 входить провід від провайдера. Цей інтерфейс включений в vmbr0 і йому не призначено ip адресу. Другий бридж vmbr1 має віртуальний ip адресу і створений для локальної мережі віртуальних машин. Далі ви створюєте віртуальну машину для шлюзу і додаєте йому обидва бриджу – vmbr0 і vmbr1. На першому налаштовуєте ip відповідно до настройками провайдера, на другому в даному випадку вказуєте статичний ip адресу 10.0.0.2, який буде шлюзом для всіх віртуальних машин і самого гипервизора в тому числі. Це відображено в параметрі gateway у властивостях vmbr1. Потім налаштовуєте віртуальний шлюз і все буде працювати.
Віртуальному шлюзу потрібно не забути поставити автозапуск при старті гипервизора, щоб можна було перезавантажувати гипервизор віддалено і не втрачати доступ. Схема здається трохи заплутаною, треба просто вникнути і розібратися. Насправді це зручно в тому випадку, якщо у вас один єдиний сервер і на ньому треба розгорнути всю інфраструктуру. Шлюз чудово живе на віртуальній машині, легко бекапіть і переноситься. Налаштувати можна будь-який функціонал. Єдиний нюанс – налаштовувати потрібно локально, ретельно перевірити і тільки переконавшись, що все коректно працює і перезавантажується, ставити на постійну роботу.
Таким чином, у вас буде гипервизор, на ньому шлюз у вигляді віртуальної машини. Всі настройки мережі виконуються на шлюзі, гипервизор чіпати взагалі не треба. Якщо у вас кілька гіпервізора в різних місцях, ви їх поєднуєте в єдину мережу за допомогою, наприклад, openvpn , який налаштовується на самих шлюзу. Віртуальні машини окремо налаштовувати не треба. Вони чудово будуть бачити один одного через свої шлюзи на Гіпервізор.
Якщо у вас дві мережеві карти, то все те ж саме. Перший бридж для інтернету від провайдера без ip, другий бридж для віртуальних машин і локальної мережі. Потрібно тільки вказати в ньому bridge_ports eth1, якщо eth1 використовується для фізичного підключення в локальну мережу.
Я часто використовував таку схему підключення, якихось особливих проблем і підводних каменів тут немає. Якщо сервер під гипервизор надійний, то працює таке рішення часто краще, ніж окремий бюджетний роутер. А функціонал в рази більше. Останнім часом намагаюся під шлюз використовувати Mikrotik там, де це можливо і виправдано.
Приклад організації мережі для віртуальних машин
Я зараз покажу на конкретному прикладі як налаштувати мережу в proxmox за останнім описаному способу. Для доступу в інтернет віртуальних машин буде використовуватися шлюз у вигляді окремої віртуальної машини. На гіпервізора нічого робити не потрібно буде, крім створення бриджу.
Отже, ось налаштування мережі на гіпервізора.
eth0 дивиться в інтернет, vmbr0 бридж, до якого включено інтерфейс eth0. На обох інтерфейсах налаштовані зовнішні ip адреси провайдера, але це не обов’язково. Їх може і не бути. Тут просто у сервера 8 зовнішніх ip, вистачає для всіх. vmbr1 повністю віртуальний бридж для організації мережі віртуальних машин.
Далі створюємо віртуальну машину під шлюз. Додаємо їй обидва бриджа
Диска, як бачите, вистачить і 10 гб для шлюзу. Він уже кілька років так працює. Тепер дивимося на настройки мережі у цій віртуалки.
auto ens18 iface ens18 inet static address 5.79.111.222 netmask 255.255.255.224 gateway 5.79.111.1 dns-nameservers 1.1.1.1 8.8.4.4 post-up iptables-restore </etc/iptables.rules auto ens19 iface ens19 inet static address 10.10.11.1 netmask 255.255.255.0
Ens18 відповідає vmbr0, а ens19 – vmbr1. На ens18 налаштований зовнішній ip і шлюз провайдера, який виділив цей ip адресу і видав мережеві настройки. Налаштовуємо на цій віртуальній машині шлюз так, як нам треба – iptables , dns , dhcp і т.д. Далі цей шлюз вказуємо як default gateway для інших віртуальних машин гипервизора.
Ось приклад налаштувань мережі з однієї з віртуальних машин цього гіпервізора.
auto eth0 iface eth0 inet static address 10.10.11.17 netmask 255.255.255.0 gateway 10.10.11.1
В даному випадку eth0 це бридж vmbr1 гіпервізора. Віртуальна машина підключена тільки до віртуальної мережі гіпервізора і має вихід в інтернет через шлюз, налаштований вище. Всі доступи до віртуальної машини, кидок портів і т.д. налаштовується на шлюзі. Якщо таких гіпервізора багато, то вони через vpn на шлюзах об’єднуються.
Такий підхід зручний тим, що не треба взагалі чіпати гіпервізор. Всі настройки мережі (а вони можуть бути складними і їх може бути багато) зберігаються на маленькому шлюзі, який зручно бекапіть і розгортати. У разі необхідності, з бекапів швидко піднімається вся інфраструктура на чистому гіпервізора.
Якщо комусь не зрозуміла описана схема, задавайте питання в коментарях. Я в такому режимі експлуатую Гіпервізор вже давно. Мені це здається зручним. Якщо у вас є пропозиції, як можна організувати мережу віртуальних машин в proxmox більш зручно, діліться міркуваннями.
Сховище для віртуальних машин
Після чистої установки proxmox на debian, автоматично створюється сховище local , яке розташовується на одному розділі з самою операційною системою за адресою / var / lib / vz . Воно вже призначене для зберігання образів дисків, віртуальних машин і контейнерів.
Для зручності краще цей розділ не позичати, залишити необхідний простір для нормальної роботи ОС, а для віртуальних машин створити окреме сховище в незайнятої області жорстких дисків, яку ми залишили під час установки, або на окремому жорсткому диску або рейд масиві. Спочатку розглянемо варіант створення сховища на неразмеченное області диска.
Ми створимо ще один raid 1 mdadm з незайнятого місця на дисках. Для цього нам потрібно буде там створити розділи і об’єднати їх в програмний рейд за допомогою mdadm.
Звертаю відразу увагу, що це тестова середовище, в реальності так диски розбивати не треба. Оптимально зробити raid 1 з двох окремих під систему, зайнявши 30-50 гигов, інше місце на цьому рейді віддати під iso образи і можливо бекапи. Для віртуальних машин підключити окремі диски і зібрати з них рейд. Його рівень буде залежати від кількості дисків. Оптимально 4 штуки для raid 10
Дивимося імена дисків в нашій системі:
# Ls -l / dev | grep sd brw-rw ---- 1 root disk 8, 0 Aug 9 15:26 sda brw-rw ---- 1 root disk 8, 1 Aug 9 15:26 sda1 brw-rw ---- 1 root disk 8, 2 Aug 9 15:26 sda2 brw-rw ---- 1 root disk 8, 16 Aug 9 15:26 sdb brw-rw ---- 1 root disk 8, 17 Aug 9 15:26 sdb1 brw-rw ---- 1 root disk 8, 18 Aug 9 15:26 sdb2
У мене 2 диска sda і sdb . На них вже є по 2 розділу, які ми зробили під час установки системи. Створимо на кожному з них ще по одному розділу з усього залишку вільного місця.
# Cfdisk / dev / sda
Вибираємо вільний простір, створюємо на ньому розділ і вказуємо тип – Linux raid autodetect .
Те ж саме робимо з другим диском. Після цих дій у вас повинні з’явитися нові розділи / dev / sda3 і / dev / sdb3 . Щоб це сталося, потрібно або перезавантажити сервер, або перечитати таблицю розділів командою:
# Partprobe -s
Якщо команда не знайдена, встановіть parted :
# Apt install parted
Перевіримо нові розділи:
# Ls -l / dev | grep sd brw-rw ---- 1 root disk 8, 0 Aug 9 15:40 sda brw-rw ---- 1 root disk 8, 1 Aug 9 15:40 sda1 brw-rw ---- 1 root disk 8, 2 Aug 9 15:40 sda2 brw-rw ---- 1 root disk 8, 3 Aug 9 15:40 sda3 brw-rw ---- 1 root disk 8, 16 Aug 9 15:40 sdb brw-rw ---- 1 root disk 8, 17 Aug 9 15:40 sdb1 brw-rw ---- 1 root disk 8, 18 Aug 9 15:40 sdb2 brw-rw ---- 1 root disk 8, 19 Aug 9 15:40 sdb3
Тепер об’єднаємо щойно створені розділи в raid1:
# Mdadm --create / dev / md2 --level = 1 --raid-disks = 2 / dev / sda3 / dev / sdb3
mdadm: Note: this array has metadata at the start and may not be suitable as a boot device. If you plan to store '/ boot' on this device please ensure that your boot-loader understands md / v1.x metadata, or use --metadata = 0.90 Continue creating array? y mdadm: Defaulting to version 1.2 metadata mdadm: array / dev / md2 started.
Перевіримо інформацію про mdadm:
# Cat / proc / mdstat
Personalities: [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md2: active raid1 sdb3 [1] sda3 [0]
42140672 blocks super 1.2 [2/2] [UU]
[=> ...................] resync = 9.4% (4001792/42140672) finish = 3.0min speed = 210620K / sec
md0: active raid1 sdb1 [1] sda1 [0]
486400 blocks super 1.2 [2/2] [UU]
md1: active raid1 sdb2 [1] sda2 [0]
9756672 blocks super 1.2 [2/2] [UU]
Все в порядку, масив синхронізується. Дочекайтеся закінчення синхронізації і продовжуйте. Хоча це не обов’язково, масив і зараз вже готовий до роботи, він він буде сильно гальмувати під час ребілд. Додамо інформацію про новий масиві в конфігураційний файл /etc/mdadm/mdadm.conf , інакше після перезавантаження маса не буде видно в системі:
# Mdadm --examine --scan | grep 'md / 2' >> /etc/mdadm/mdadm.conf
Конфігураційний файл прийме такий вигляд:
# Cat /etc/mdadm/mdadm.conf
# mdadm.conf # mdadm.conf # #! NB! Run update-initramfs -u after updating this file. #! NB! This will ensure that initramfs has an uptodate copy. # # Please refer to mdadm.conf (5) for information about this file. # # By default (built-in), scan all partitions (/ proc / partitions) and all # Containers for MD superblocks. alternatively, specify devices to scan, using # Wildcards if desired. #DEVICE partitions containers # Automatically tag new arrays as belonging to the local system HOMEHOST # Instruct the monitoring daemon where to send mail alerts MAILADDR root # Definitions of existing MD arrays ARRAY / dev / md / 0 metadata = 1.2 UUID = a214eb8b: c3ff0ab2: 13197140: 25a25924 name = proxmox6: 0 ARRAY / dev / md / 1 metadata = 1.2 UUID = 1d5a52f3: 7caa923c: b8f13836: 8a7bcf54 name = proxmox6: 1 # This configuration was auto-generated on Fri, 09 Aug 2019 13:59:40 +0300 by mkconf ARRAY / dev / md / 2 metadata = 1.2 UUID = 30be9c4e: 6a351eca: 6d66228d: ee695c19 name = proxmox6: 2
Далі у нас 2 шляхи:
- Створити файлову систему на md2, змонтувати розділ в систему і створити storage у вигляді звичайної директорії , такий же, як за замовчуванням.
- Створити тому LVM і на його основі storage.
Традиційно використовують другий спосіб, так як він дозволяє потім використовувати в якості дисків віртуальних машин lvm розділи. З ними зручно працювати, плюс, теоретично, блоковий пристрій типу lvm має працювати трохи швидше. Так що підемо іншим шляхом. Виконаємо ініціалізацію розділу для роботи з LVM:
# Pvcreate / dev / md2 File descriptor 7 (pipe: [31619]) leaked on pvcreate invocation. Parent PID 2856: bash Physical volume "/ dev / md2" successfully created.
Створимо групу томів:
# Vgcreate raid1-md2 / dev / md2 File descriptor 7 (pipe: [31619]) leaked on vgcreate invocation. Parent PID 2856: bash Volume group "raid1-md2" successfully created
Тепер йдемо в web інтерфейс, вибираємо Datacenter, вкладку Storage , тиснемо Add і вибираємо LVM:
Вказуємо параметри щойно створеної групи томів.
| ID | Будь-яка назва нового сторейджа. Я зазвичай називаю так, щоб потім можна було легко порівняти з ім’ям системного розділу. Так зручно. |
| Volume group | Ім’я групи томів LVM, яке ви вказали при створенні командою vgcreate |
Все готово. Новий storage додали. Його можна використовувати для зберігання дисків віртуальних машин.
Додавання і підключення диска
Розглянемо варіант додавання нового диска і використання його в якості сховища віртуальних машин. За великим рахунком, це те ж саме, що ми виконали раніше з новим розділом, тільки тепер все зазначені вище операції потрібно буде виконати над новим диском. Швидко пройдемо по етапах.
Я підключив новий жорсткий диск, перевіримо його ім’я в системі:
# Ls -l / dev | grep sd
brw-rw ---- 1 root disk 8, 0 Aug 9 15:40 sda brw-rw ---- 1 root disk 8, 1 Aug 9 15:40 sda1 brw-rw ---- 1 root disk 8, 2 Aug 9 15:40 sda2 brw-rw ---- 1 root disk 8, 3 Aug 9 15:40 sda3 brw-rw ---- 1 root disk 8, 16 Aug 9 15:40 sdb brw-rw ---- 1 root disk 8, 17 Aug 9 15:40 sdb1 brw-rw ---- 1 root disk 8, 18 Aug 9 15:40 sdb2 brw-rw ---- 1 root disk 8, 19 Aug 9 15:40 sdb3 brw-rw ---- 1 root disk 8, 32 Aug 9 15:40 sdc
Можна не створювати на диску розділ, а відразу його форматувати для роботи в lvm і створити групу томів:
# Pvcreate / dev / sdc # Vgcreate disk-sdc / dev / sdc
Йдемо в веб інтерфейс і створюємо новий storage:
Якщо у вас буде не поодинокий диск, а кілька, то перед цим створіть рейд масив з них і так само поверх накочуйте lvm і додавайте новий storage. На цьому настройку локальних сховищ завершуємо. Всі основні дії ми виконали, можна починати працювати з системою – створювати віртуальні машини.
Сховище по NFS
Наведу простий приклад підключення сховища по NFS. Мені воно в майбутньому знадобиться для організації бекапа віртуальних машин. Про це я розповім пізніше. Зараз тільки додамо нове сховище. Зробити це дуже просто. У мене вже є налаштований сервер NFS. Опис його настройки виходить за рамки матеріалу, тому будемо вважати, що сервер у вас є. Йдемо в розділ Storage і додаємо нове сховище NFS:
Я це сховище буду використовувати тільки для iso образів і backup’ов, тому виставляю відповідні налаштування.
Звертаю увагу, що після вказівки адреси сервера, список доступних каталогів для експорту буде автоматично запитаний з сервера. Так що немає необхідності вказувати шлях вручну, можна вибрати зі списку.
Створення та налагодження віртуальних машин
У налаштуванні віртуальних машин в proxmox немає нічого складного і незвичайного. Я не буду крок за кроком розповідати, як це зробити. Якщо ви дійшли до цього пункту, подолавши всі інші, розібратися не складе труднощів. Звертаю увагу тільки на кілька ключових моментів.
Щоб встановити віртуальну машину, потрібно використовувати iso образ . Його треба якось завантажити на proxmox. Зробити це не складно, потрібно тільки розуміти, що завантажити образ можна тільки на той storage, який підтримує таку можливість. Сторейджі LVM не дозволяють завантажувати образи, для цього потрібно використовувати, наприклад, storage у вигляді локальної директорії. За замовчуванням, один такий є в системі. У нього і завантажимо образ віртуальної машини. Для цього відкриваємо потрібний storage і вибираємо вкладку Content . Тиснемо на Upload і вибираємо потрібний образ.
На етапі завантаження iso образу я іноді стикаюся з проблемою. Образ більше 4Гб не завантажується. Перевіряв кілька разів, в тому числі в різних інсталяціях на різний залізо. Помилка час від часу проявляється. Якщо у вас образи більше, ніж 4 Гб, шукайте альтернативні способи завантаження в сховище, благо це не складає великих труднощів.
Альтернативний спосіб завантаження iso образу в proxmox – використовувати scp або безпосередньо через wget качати образ з інтернету. Покласти його потрібно в директорію / var / lib / vz / template / iso , якщо використовуєте дефолтний storage, доданий за замовчуванням після установки.
Чекаємо закінчення завантаження. Тепер цей образ можна використовувати для установки ОС на віртуальну машину. Створення віртуальної машини виглядає наступним чином. Натискаємо на кнопку Create VM
Заповнюємо всі необхідні поля і стартуємо машину. Деякий час піде на створення машини (від декількох секунд до 1-2 хвилин). У нижній частині екрана ведеться лог подій, там побачите інформацію про закінчення створення:
Вибирайте тільки що створену машину і запускайте її. Для того, щоб потрапити в консоль віртуальної машини, вибери відповідний розділ:
Віртуальна машина повинна бути запущена, щоб побачити консоль. Розповідати про налаштування віртуальних машин особливо нічого. Всі настройки видно у властивостях машини, виставляйте те, що вам необхідно і користуйтеся. Окремо розгляну питання автозапуску.
Автозапуск віртуальної машини
За замовчуванням створені віртуальні машини не запускаються зі стартом гипервизора, це потрібно робити вручну. Але є настройка, яка відповідає за автозавантаження віртуальних машин, а так само за порядок їх завантаження. Ось список параметрів, якими ми можемо управляти:
| Start at boot | Приймає значення Yes або No, відповідно, завантажуємося автоматично чи ні. |
| Start / Shutdown order | Порядок завантаження та вимикання віртуальних машин, приймає цілі цифрові значення (1, 2, і т.д.). |
| Startup delay | Затримка запуску інших ВМ після запуску цієї, приймає значення в секундах. |
| Shutdown timeout | Затримка в виключенні ВМ. Спочатку буде віддана команда на завершення роботи. Якщо ВМ не від’ôднаôтесь роботу коректно, їй буде посланий сигнал на примусове виключення. |
Розглянемо простий приклад. У нас є віртуальна машина, наприклад Windows Server з роллю Active Directory на борту. Всі інші сервери зав’язані на коректну роботу служби каталогів. Нам треба спочатку запустити контролер домену, а потім всі інші сервери за ним. Встановіть параметр Start at boot в положення Yes для всіх віртуальних машин, які хочете запускати автоматично. Вкажіть Start / Shutdown order на контролері домену 1, Startup delay 240, Shutdown timeout 120. З такими настройками при запуску гипервизора першої стартує віртуальна машина з КД, через 240 секунд всі інші відповідно до їх настройками.
Backup віртуальних машин
Підійшли до дуже важливого етапу налаштування proxmox – організація бекапа віртуальних машин. На цей момент потрібно звернути особливу увагу, і все добре перевірити. Налаштовується backup так само просто, як і все інше в proxmox. Йдемо в розділ Backup і створюємо завдання:
Виставляємо необхідні параметри, наприклад такі:
Чекаємо призначеного часу і перевіряємо виконання завдання.
Для того, щоб виконати разовий бекап конкретної віртуальної машини, досить відкрити віртуальну машини, вибрати в ній розділ Backup і натиснути Backup Now :
Далі вказуєте необхідні параметри і чекаєте завершення бекапа. Звертаю увагу, що бекап буде виконуватися при працюючій віртуальній машині. Зупиняти її не потрібно.
ут відразу постає наступне питання – як автоматично видаляти старі бекапи? Однозначно відповісти не вийде, все буде залежати від того, де будуть зберігатися бекапи. Якщо це звичайний linux сервер з доступом до консолі, то можна скористатися програмою find :
# / Usr / bin / find / mnt / backups-vm -type f -mtime +30 -exec rm {} \;
Після виконання цієї команди, всі файли в папці / mnt / backups-vm старше 30 днів будуть видалені. Для автоматизації процесу команду можна помістити в cron . За допомогою zabbix ви можете моніторити актуальність бекапів і стежити за їх розмірами .
Після створення бекапа рекомендую відразу переконатися, що з нього можна відновити віртуальну машину. Для цього відкрийте вікно storage, де у вас зроблена копія і звідти почніть процес відновлення. У такому випадку ви зможете вказати нове ім’я для віртуальної машини. Якщо ви будете намагатися відновити з резервної копії в інтерфейсі віртуальної машини, то буде запропонована тільки заміна існуючої ВМ.
Не забудьте у відновленій копії віртуальної машини, якщо відновіть на тому ж гіпервізора, поміняти mac адресу і мережеві настройки. Якщо не поміняти мак, то будете потім довго ловити і розбиратися з незрозумілими мережевими проблемами.
Висновок
Не сподобалася стаття і хочеш навчити мене адмініструвати? Будь ласка, я люблю вчитися. Коментарі в твоєму розпорядженні. Розкажи, як зробити правильно!
Підіб’ємо підсумок того, що зробили:
- Встановили гіпервізор proxmox на сервер під керуванням Debian на програмний raid1, забезпечивши відмовостійкість системи на рівні дисків.
- Налаштували віртуальну мережу для віртуальних машин.
- Підключили різні storage для виконання завдань розміщення і бекапа віртуальних машин.
- Додали і налаштували віртуальні машини.
- Організували автоматичний бекап всіх ВМ.
Я постарався вибрати найбільш затребувані функції і описати їх, щоб систему можна було використовувати в реальній роботі і не боятися за надійність рішення. Зібрав необхідний мінімум, але статися все одно вийшла дуже велика, об’ємна. Я не став її розділяти на частини, щоб була цілісна картина всього того, що зробили. Тут є ще над чим попрацювати, особливо актуальним є питання бекапа. Без інкрементного бекапа незручно зберігати резервні копії на віддаленому сервері, дуже великий обсяг переданих даних виходить. Мені не відомий спосіб інкрементного бекапа віртуальних машин в proxmox, буду радий, якщо хтось порадить гарне рішення для KVM. Снепшот zfs не береться до уваги.