В Proxmox 7.3 без особых подробностей завезли обновление со следующим описанием: Framework for remote migration to cluster-external Proxmox VE hosts. По факту добавили экспериментальную возможность по миграции виртуальных машин между гипервизорами (не только кластерами).
Реализована миграция с помощью консольной команды
Я разобрался, как это работает. У меня получилось выполнить миграцию между разными гипервизорами. Показываю, как это работает. Итоговая работающая команда выглядит следующим образом:
▪️120 120 - ID виртуалки на исходном гипервизоре и желаемое ID на том, куда переносим. Я оставил одинаковые.
▪️10.20.1.65 - IP адрес принимающего гипервизора
▪️root@pam!token1 - имя токена token1 для пользователя root@pam
▪️0ace469b-9c8d-4f05-ba84-d720414129ee - секрет указанного выше токена
▪️vmbr0 - сетевой бридж на принимающем гипервизоре
▪️local-lvm - хранилище дисков на принимающем гипервизоре
▪️16:21:AB:AE:A3:06:92:BB:E9:F8:25:C2:A1:53:26:7F:67:29:1B:A9:A9:1C:D1:3B:A7:47:BD:23:9F:E8:7C:6B - fingerprint сертификата pve-ssl.pem принимающего гипервизора
Для того, чтобы миграция прошла успешно, нужно на принимающем сервере создать токен. Делается это в разделе Datacenter ⇨ Permissions ⇨ API Tokens. После создания вы получите имя в виде root@pam!token1, где root@pam - пользователь, а token1 - указанное имя токена. И само значение секрета этого токена. Далее в разделе Datacenter ⇨ Permissions нужно добавить API Token Permissions. Я выбрал существующий токен и дал ему полные права. Не разбирался, какие нужны для миграции. Думаю, нужны права на создание виртуалок и дисков в хранилище.
Отпечаток сертификата можно посмотреть в разделе Node ⇨ System ⇨ Certificates. Надо выбрать стандартный pve-ssl.pem, два раза кликнуть по нему мышкой и скопировать Fingerprint.
После этого можно идти в консоль и запускать команду миграции. Её процесс можно наблюдать как в консоли, так и через веб интерфейс в списке задач. Через веб интерфейс даже прогресс копирования дисков виден, в отличие от консоли. Там этой информации нет.
Работает всё довольно удобно. Поддерживается миграция из разных типов хранилищ. Я для теста с обычного LVM переехал в LVM-Thin на другой гипервизор. По факту сначала происходит копирование диска, а потом перенос его в нужное хранилище на принимающей стороне через
Если у вас много виртуалок, которые надо перекинуть на другой гипервизор, то можно пользоваться. Один раз настроил и перенёс все виртуалки со всеми настройками и дисками.
После миграции исходная VM будет заблокирована. Если захотите её запустить на старом гипервизоре, то разблокируйте:
#proxmox
🦖 Selectel — дешёвые и не очень дедики с аукционом!
Реализована миграция с помощью консольной команды
qm remote-migrate. Подробности реализации можно посмотреть в соответствующем коммите в репозитории. Описание команды в документации скудное. Не особо понятен итоговый формат работающей команды.qm remote-migrate <vmid> [<target-vmid>] <target-endpoint> --target-bridge <string> --target-storage <string> [OPTIONS]Я разобрался, как это работает. У меня получилось выполнить миграцию между разными гипервизорами. Показываю, как это работает. Итоговая работающая команда выглядит следующим образом:
# qm remote-migrate 120 120 'host=10.20.1.65,apitoken=PVEAPIToken=root@pam!token1=0ace469b-9c8d-4f05-ba84-d720414129ee,fingerprint=16:21:AB:AE:A3:06:92:BB:E9:F8:25:C2:A1:53:26:7F:67:29:1B:A9:A9:1C:D1:3B:A7:47:BD:23:9F:E8:7C:6B' --target-bridge vmbr0 --target-storage local-lvm▪️120 120 - ID виртуалки на исходном гипервизоре и желаемое ID на том, куда переносим. Я оставил одинаковые.
▪️10.20.1.65 - IP адрес принимающего гипервизора
▪️root@pam!token1 - имя токена token1 для пользователя root@pam
▪️0ace469b-9c8d-4f05-ba84-d720414129ee - секрет указанного выше токена
▪️vmbr0 - сетевой бридж на принимающем гипервизоре
▪️local-lvm - хранилище дисков на принимающем гипервизоре
▪️16:21:AB:AE:A3:06:92:BB:E9:F8:25:C2:A1:53:26:7F:67:29:1B:A9:A9:1C:D1:3B:A7:47:BD:23:9F:E8:7C:6B - fingerprint сертификата pve-ssl.pem принимающего гипервизора
Для того, чтобы миграция прошла успешно, нужно на принимающем сервере создать токен. Делается это в разделе Datacenter ⇨ Permissions ⇨ API Tokens. После создания вы получите имя в виде root@pam!token1, где root@pam - пользователь, а token1 - указанное имя токена. И само значение секрета этого токена. Далее в разделе Datacenter ⇨ Permissions нужно добавить API Token Permissions. Я выбрал существующий токен и дал ему полные права. Не разбирался, какие нужны для миграции. Думаю, нужны права на создание виртуалок и дисков в хранилище.
Отпечаток сертификата можно посмотреть в разделе Node ⇨ System ⇨ Certificates. Надо выбрать стандартный pve-ssl.pem, два раза кликнуть по нему мышкой и скопировать Fingerprint.
После этого можно идти в консоль и запускать команду миграции. Её процесс можно наблюдать как в консоли, так и через веб интерфейс в списке задач. Через веб интерфейс даже прогресс копирования дисков виден, в отличие от консоли. Там этой информации нет.
Работает всё довольно удобно. Поддерживается миграция из разных типов хранилищ. Я для теста с обычного LVM переехал в LVM-Thin на другой гипервизор. По факту сначала происходит копирование диска, а потом перенос его в нужное хранилище на принимающей стороне через
query-disk-import. Отсюда можно сделать вывод, что должен быть запас по доступному месту на принимающем гипервизоре в двойном размере от объёма диска. Это нужно учитывать при переносе.Если у вас много виртуалок, которые надо перекинуть на другой гипервизор, то можно пользоваться. Один раз настроил и перенёс все виртуалки со всеми настройками и дисками.
После миграции исходная VM будет заблокирована. Если захотите её запустить на старом гипервизоре, то разблокируйте:
# qm unlock 120 #proxmox
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
▶️ Очередная подборка авторских IT роликов, которые я лично посмотрел и посчитал интересными/полезными. Как обычно, ниже те видео из моих подписок за последнее время (обычно беру период в 2 недели), что мне показались интересными и полезными.
В этот раз как-то мало интересного было. Много роликов отсеял, так как не посчитал их полезными. Да и в целом контента меньше стало, особенно русскоязычного.
⇨ Настройка DNS over HTTPS в OPNsense
Небольшой ролик про DNS over HTTPS для тех, кто не знает, что это такое и как работает. Тут автор кратко рассказал о технологии и на практике показал, как это работает и как настраивается на своём софтовом шлюзе OPNsense.
⇨ Netbird Update - How to add the new "Relays" feature to your netbird install.
Рассказ про бесплатную, open source платформу для построения VPN сетей - netbird.io. Вышло крупное обновление продукта. Автор рассказал, как его установить и что в нём нового. Вообще, это интересный продукт. Я видел его обзор у разных блогеров, писал заметку про него. Один из лучших open source проектов из этой области.
⇨ Vinchin - Backup система для ВСЕГО!
Обзор системы для бэкапа Vinchin. Автор прошёлся по основным возможностям. Я в своё время примерно то же самое оформил в отдельную статью на сайте. Система, в принципе, неплохая. Мне понравилась.
⇨ Building a Low-Power, Fully Loaded Plex Server
Подробное описание сборки сервера под популярный медиасервер Plex для дома. Автор поставил задачу собрать тихий и маломощный в плане потребления электричества сервер на базе Mini ITX. Интересно посмотреть, что у него в итоге получилось.
⇨ Администрирование Линукс. Стабильность и безопасность системы
Короткое видео с наглядным примером эксплуатации уязвимости ярда Linux CVE-2024-1086. Я, кстати, об этой уязвимости писал в своё время. На видео примерно то же самое делается, что у меня в заметке.
#видео
В этот раз как-то мало интересного было. Много роликов отсеял, так как не посчитал их полезными. Да и в целом контента меньше стало, особенно русскоязычного.
⇨ Настройка DNS over HTTPS в OPNsense
Небольшой ролик про DNS over HTTPS для тех, кто не знает, что это такое и как работает. Тут автор кратко рассказал о технологии и на практике показал, как это работает и как настраивается на своём софтовом шлюзе OPNsense.
⇨ Netbird Update - How to add the new "Relays" feature to your netbird install.
Рассказ про бесплатную, open source платформу для построения VPN сетей - netbird.io. Вышло крупное обновление продукта. Автор рассказал, как его установить и что в нём нового. Вообще, это интересный продукт. Я видел его обзор у разных блогеров, писал заметку про него. Один из лучших open source проектов из этой области.
⇨ Vinchin - Backup система для ВСЕГО!
Обзор системы для бэкапа Vinchin. Автор прошёлся по основным возможностям. Я в своё время примерно то же самое оформил в отдельную статью на сайте. Система, в принципе, неплохая. Мне понравилась.
⇨ Building a Low-Power, Fully Loaded Plex Server
Подробное описание сборки сервера под популярный медиасервер Plex для дома. Автор поставил задачу собрать тихий и маломощный в плане потребления электричества сервер на базе Mini ITX. Интересно посмотреть, что у него в итоге получилось.
⇨ Администрирование Линукс. Стабильность и безопасность системы
Короткое видео с наглядным примером эксплуатации уязвимости ярда Linux CVE-2024-1086. Я, кстати, об этой уязвимости писал в своё время. На видео примерно то же самое делается, что у меня в заметке.
#видео
YouTube
Настройка DNS over HTTPS в OPNsense
#nas, #opnsense, #truenas, #proxmox
В этом ролике поговорим о том, как пустить наши днс запросы с помощью сервиса https. Ссылки на ресурсы будет внизу описания
Реферальная ссылка на хостера smartape чьими услугами я пользуюсь http://www.smartape.ru/?partner=139490…
В этом ролике поговорим о том, как пустить наши днс запросы с помощью сервиса https. Ссылки на ресурсы будет внизу описания
Реферальная ссылка на хостера smartape чьими услугами я пользуюсь http://www.smartape.ru/?partner=139490…
Когда только начинал работать с виртуализацией на Linux, очень хотелось сесть за сервер и прямо на нём что-то сделать. Но на тот момент ни XenServer, ни VmWare не позволяли это сделать. На экране сервера был небольшой список простых действий типа настроек сети или перезагрузки. И ничего, что относилось бы к управлению виртуальными машинами. После экспериментов с VMware Workstation и Hyper-V было как-то непривычно и неудобно.
Для управления гипервизором нужно было сесть за какое-то рабочее место, поставить соответствующий клиент и через него подключаться для управления. В Proxmox с этим сейчас попроще, так как управление через браузер. Но тем не менее, он тоже не позволяет локально что-то с ним сделать. В связи этим не возникает проблем в обычной эксплуатации. А вот если вы используете Proxmox в каких-то необычных задачах, то может возникнуть желание подключить к нему монитор и выполнять настройки прямо тут же.
В Proxmox решить эту задачу очень просто. Под капотом там обычная система Debian, на которую можно установить графическую оболочку. Более того, как это сделать, рассказано в официальной Wiki проекта. Там это названо так:
⇨ Developer Workstations with Proxmox VE and X11
Всё, что вам надо сделать, так это установить туда xfce, браузер и менеджер управления графическими оболочками в системе. Предупреждаю, что делать это на продуктовых серверах - плохая практика.
Выполняем непосредственно гипервизоре:
Добавляем пользователя, от имени которого мы будем заходить и подключаться к веб интерфейсу:
Запускаем графическую оболочку:
Можно подключать монитор к серверу, заходить в систему и подключаться к локальному веб интерфейсу по адресу https://localhost:8006.
Вроде мелочь, а на самом деле удобная возможность. Я одно время хотел дома организовать рабочую станцию, чтобы семейные могли работать локально, а я иногда запускать тестовые виртуальные машины в случае необходимости. Решил в итоге задачу через RDP подключение к системе, даже когда на ней кто-то локально работает. Обычная винда позволяет превратить себя в мини-терминальник. Но это отдельная история.
Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#proxmox
Для управления гипервизором нужно было сесть за какое-то рабочее место, поставить соответствующий клиент и через него подключаться для управления. В Proxmox с этим сейчас попроще, так как управление через браузер. Но тем не менее, он тоже не позволяет локально что-то с ним сделать. В связи этим не возникает проблем в обычной эксплуатации. А вот если вы используете Proxmox в каких-то необычных задачах, то может возникнуть желание подключить к нему монитор и выполнять настройки прямо тут же.
В Proxmox решить эту задачу очень просто. Под капотом там обычная система Debian, на которую можно установить графическую оболочку. Более того, как это сделать, рассказано в официальной Wiki проекта. Там это названо так:
⇨ Developer Workstations with Proxmox VE and X11
Всё, что вам надо сделать, так это установить туда xfce, браузер и менеджер управления графическими оболочками в системе. Предупреждаю, что делать это на продуктовых серверах - плохая практика.
Выполняем непосредственно гипервизоре:
# apt install xfce4 chromium lightdmДобавляем пользователя, от имени которого мы будем заходить и подключаться к веб интерфейсу:
# adduser webuserЗапускаем графическую оболочку:
# systemctl start lightdmМожно подключать монитор к серверу, заходить в систему и подключаться к локальному веб интерфейсу по адресу https://localhost:8006.
Вроде мелочь, а на самом деле удобная возможность. Я одно время хотел дома организовать рабочую станцию, чтобы семейные могли работать локально, а я иногда запускать тестовые виртуальные машины в случае необходимости. Решил в итоге задачу через RDP подключение к системе, даже когда на ней кто-то локально работает. Обычная винда позволяет превратить себя в мини-терминальник. Но это отдельная история.
Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#proxmox
Для автоматизации установки и настройки виртуальных машин в Proxmox я рассказывал про Cloud-Init. С помощью этой технологии можно создать преднастроенный образ, который включает в себя базовые настройки системы, такие как сеть, пользователи, установка пакетов и некоторые другие.
Если хочется пойти дальше в автоматизации и развернуть сразу набор виртуальных машин определённой конфигурации, то для этого можно воспользоваться Terraform. Для Proxmox есть провайдер (terraform registry доступ через vpn, github). Это самый популярный. Есть ещё один, который очень активно развивается и допиливается - terraform registry и github.
Кратко поясню, для тех, кто не знает, что такое Terraform и для чего он может быть полезен в связке с Proxmox. Terraform был разработан как решение по управлению в стиле IaC (Infrastructure as Code, IaC) - инфраструктура как код. В первую очередь это касается управления ресурсами облачных провайдеров. Вы описываете в Terraform, что хотите получить на выходе, запускаете шаблон и получаете набор виртуальных машин, сетей и прочих облачных ресурсов. Причём вы можете оперативно как развернуть инфраструктуру, так и потушить. Это актуально для динамических сред с плавающей нагрузкой. Часто Terraform работает в связке с Ansible. Первый разворачивает инфраструктуру, второй её настраивает.
Proxmox не является инструментом для построения динамичных облачных инфраструктур. Его область применения - одиночные гипервизоры или небольшие кластеры на несколько серверов. По моим представлениям в проде на базе Proxmox нет большой нужды использовать Terraform. Он может быть актуален для каких-то тестовых задач как по изучению самого Terraform, так и для разворачивания тестового окружения в Proxmox. Можно разом развернуть какую-то лабораторию и потом так же в одно действие от неё избавиться.
Использование Terraform с Proxmox выглядит примерно следующим образом. Это не будет готовой инструкцией, так как в формат заметки не уместить. Все подробности без проблем гуглятся, так как тема живая. В целом, Terraform относительно простой инструмент. Чтобы начать им пользоваться достаточно небольшой инструкции или видео. Можно брать готовые шаблоны из статей или документации и править под себя.
1️⃣ Готовится образ с использованием Cloud-Init, на базе которого будет разворачиваться инфраструктура.
2️⃣ Создаётся отдельный пользователь и токен для него, который будет использовать Terraform.
3️⃣ Устанавливается Terraform или Opentofu (форк).
4️⃣ Создаётся конфигурация с провайдером и планон разворачивания инфраструктуры. Будут 2 файла: provider.tf и vm-debian12.tf. Содержимое прикреплю следующим сообщением. По желанию можно все переменные вынести в отдельный файл.
Пример конфигурации можно посмотреть в репозитории. После подготовки конфигурации, её можно проверить:
Посмотреть, что будет создано:
Если всё ОК, то создаём описанное:
Когда всё это будет не нужно, удаляем:
В моём примере была одна виртуальная машина. По аналогии, вы можете описать любое необходимое количество. Поместить их в одну или разные сети, посадить в разные хранилища и т.д.
Как я уже говорил, инструмент относительно простой. Я быстро во всём разобрался и протестировал. Единственный неприятный нюанс - репозитории terraform и opentofu заблокированы для РФ. Пришлось трафик через VPN пускать. У меня всё автоматизировано для этого. Отправил домены registry.terraform.io, apt.releases.hashicorp.com и registry.opentofu.org через VPN на шлюзе.
Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#proxmox #iac #terraform
Если хочется пойти дальше в автоматизации и развернуть сразу набор виртуальных машин определённой конфигурации, то для этого можно воспользоваться Terraform. Для Proxmox есть провайдер (terraform registry доступ через vpn, github). Это самый популярный. Есть ещё один, который очень активно развивается и допиливается - terraform registry и github.
Кратко поясню, для тех, кто не знает, что такое Terraform и для чего он может быть полезен в связке с Proxmox. Terraform был разработан как решение по управлению в стиле IaC (Infrastructure as Code, IaC) - инфраструктура как код. В первую очередь это касается управления ресурсами облачных провайдеров. Вы описываете в Terraform, что хотите получить на выходе, запускаете шаблон и получаете набор виртуальных машин, сетей и прочих облачных ресурсов. Причём вы можете оперативно как развернуть инфраструктуру, так и потушить. Это актуально для динамических сред с плавающей нагрузкой. Часто Terraform работает в связке с Ansible. Первый разворачивает инфраструктуру, второй её настраивает.
Proxmox не является инструментом для построения динамичных облачных инфраструктур. Его область применения - одиночные гипервизоры или небольшие кластеры на несколько серверов. По моим представлениям в проде на базе Proxmox нет большой нужды использовать Terraform. Он может быть актуален для каких-то тестовых задач как по изучению самого Terraform, так и для разворачивания тестового окружения в Proxmox. Можно разом развернуть какую-то лабораторию и потом так же в одно действие от неё избавиться.
Использование Terraform с Proxmox выглядит примерно следующим образом. Это не будет готовой инструкцией, так как в формат заметки не уместить. Все подробности без проблем гуглятся, так как тема живая. В целом, Terraform относительно простой инструмент. Чтобы начать им пользоваться достаточно небольшой инструкции или видео. Можно брать готовые шаблоны из статей или документации и править под себя.
Пример конфигурации можно посмотреть в репозитории. После подготовки конфигурации, её можно проверить:
# terraform init# terraform validateПосмотреть, что будет создано:
# terraform planЕсли всё ОК, то создаём описанное:
# terraform applyКогда всё это будет не нужно, удаляем:
# terraform destroyВ моём примере была одна виртуальная машина. По аналогии, вы можете описать любое необходимое количество. Поместить их в одну или разные сети, посадить в разные хранилища и т.д.
Как я уже говорил, инструмент относительно простой. Я быстро во всём разобрался и протестировал. Единственный неприятный нюанс - репозитории terraform и opentofu заблокированы для РФ. Пришлось трафик через VPN пускать. У меня всё автоматизировано для этого. Отправил домены registry.terraform.io, apt.releases.hashicorp.com и registry.opentofu.org через VPN на шлюзе.
Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#proxmox #iac #terraform
Please open Telegram to view this post
VIEW IN TELEGRAM
Пока была возможность, решил проверить, какой штраф на дисковые операции накладывает виртуализация в Proxmox. В моей работе чаще всего именно дисковая подсистема является узким местом серверов. CPU обычно хватает, память сейчас недорога и легко расширяется. С дисками проблем больше всего.
Взял тестовый сервер Proxmox, в котором есть железный RAID контроллер без кэша и собранный RAID10 из 4-х HDD. Воткнул туда дополнительно обычный SSD AMD Radeon R5 R5SL480G 480ГБ. RAID10 подключил как обычный LVM storage, а SSD как LVM-Thin.
Нарезал там LV для хоста:
Сделал фс ext4 и смонтировал:
Прогнал серию из 10-ти тестов для каждого хранилища с помощью dd:
Далее взял fio и прогнал тесты с его помощью:
Линейное чтение:
Линейная запись:
Пиковые IOPS случайной записи:
Так для обоих дисков. С dd сделал по 10 тестов, с fio по 5. Потом создал VM на Debian 12, создал для неё такие же диски, выбрав параметры:
▪️Device: SCSI
▪️Cache: Default (No cache)
▪️IO thread: yes
▪️Async IO: Default (io_uring)
Настройки все по умолчанию. И там выполнил точно такие же тесты. Свёл всё в одну таблицу. Я тут приводить точные цифры тестов не буду, так как они не имеют принципиального значения. Цифры можете сами посмотреть. Перейду сразу к выводам.
Разброс в производительности не более 9%. А если точно, то разница между хостом и VM только в одном тесте на запись была 9%, в остальных случаях 2-6%. Немного удивило то, что в паре тестов в VM результаты были выше на 2%, чем на хосте. Я несколько раз перепроверял, но ситуация воспроизводилась снова. Не знаю, с чем это может быть связано.
Честно говоря думал, что по диску просадка будет больше в виртуальных машинах. А на практике она очень незначительная. Часто выбирают контейнеры, чтобы минимизировать разницу в производительности дисков, так как там хранилище прямо с хоста подключается. Для себя большого смысла не увидел в этом, если это единственный довод в пользу контейнера. Предпочту развернуть нагрузку в VM, как более универсальное решение, если не стоит задача максимальной плотности размещения для утилизации процессора и памяти.
#proxmox #disk #perfomance
Взял тестовый сервер Proxmox, в котором есть железный RAID контроллер без кэша и собранный RAID10 из 4-х HDD. Воткнул туда дополнительно обычный SSD AMD Radeon R5 R5SL480G 480ГБ. RAID10 подключил как обычный LVM storage, а SSD как LVM-Thin.
Нарезал там LV для хоста:
# lvcreate -V 10G -n test_ssd --thinpool SSD-RADEON/SSD-RADEON# lvcreate -L 10G -n test_raid10 raid10Сделал фс ext4 и смонтировал:
# mkfs.ext4 /dev/SSD-RADEON/test_ssd# mkfs.ext4 /dev/raid10/test_raid10# mount /dev/SSD-RADEON/test_ssd /mnt/SSD-RADEON# mount /dev/raid10/test_raid10 /mnt/raid10Прогнал серию из 10-ти тестов для каждого хранилища с помощью dd:
# dd if=/dev/zero of=/mnt/raid10/tempfile bs=1M count=2000 oflag=direct# dd if=/dev/zero of=/mnt/SSD-RADEON/tempfile bs=1M count=2000 oflag=directДалее взял fio и прогнал тесты с его помощью:
Линейное чтение:
# fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=1M -iodepth=32 -rw=read -runtime=30 -filename=/dev/raid10/test_raid10Линейная запись:
# fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=1M -iodepth=32 -rw=write -runtime=30 -filename=/dev/raid10/test_raid10Пиковые IOPS случайной записи:
# fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 -rw=randwrite -runtime=30 -filename=/dev/raid10/test_raid10Так для обоих дисков. С dd сделал по 10 тестов, с fio по 5. Потом создал VM на Debian 12, создал для неё такие же диски, выбрав параметры:
▪️Device: SCSI
▪️Cache: Default (No cache)
▪️IO thread: yes
▪️Async IO: Default (io_uring)
Настройки все по умолчанию. И там выполнил точно такие же тесты. Свёл всё в одну таблицу. Я тут приводить точные цифры тестов не буду, так как они не имеют принципиального значения. Цифры можете сами посмотреть. Перейду сразу к выводам.
Разброс в производительности не более 9%. А если точно, то разница между хостом и VM только в одном тесте на запись была 9%, в остальных случаях 2-6%. Немного удивило то, что в паре тестов в VM результаты были выше на 2%, чем на хосте. Я несколько раз перепроверял, но ситуация воспроизводилась снова. Не знаю, с чем это может быть связано.
Честно говоря думал, что по диску просадка будет больше в виртуальных машинах. А на практике она очень незначительная. Часто выбирают контейнеры, чтобы минимизировать разницу в производительности дисков, так как там хранилище прямо с хоста подключается. Для себя большого смысла не увидел в этом, если это единственный довод в пользу контейнера. Предпочту развернуть нагрузку в VM, как более универсальное решение, если не стоит задача максимальной плотности размещения для утилизации процессора и памяти.
#proxmox #disk #perfomance
Google Docs
Тесты дисков
Завершу тему с тестированием дисков информацией про кэширование в Proxmox VE. У него стандартный набор режимов, которые будут плюс-минус такие же и у рейд контроллеров. Сделаю в формате небольшой шпаргалки, а подробности с картинками есть в документации.
▪️None - режим по умолчанию. Если не хочется разбираться в этой теме, то можете оставлять этот режим и не заморачиваться. Он универсален для сервера общего назначения. Гипервизор никак не вмешивается в операции ввода-вывода. VM работает как-будто напрямую с хранилищем. Может отправлять данные в очередь хранилища на запись, либо дожидаться реальной записи.
▪️Writethrough - операции записи VM идут напрямую в хранилище, как и в режиме none. В этом режиме добавляется кэш гипервизора, который используется только для чтения. То есть мы получаем такую же надёжность записи, как и в none, но добавляется кэш на операции чтения. Если у вас сервер отдаёт много статики, то можете включить этот режим.
Железный рейд контроллер без батарейки обычно работает в таком же режиме.
▪️Directsync - кэширование гипервизора не используется вообще, как в none. Отличие этого режима в том, что мы заставляем VM работать с хранилищем только в режиме реальной записи с подтверждением. То есть виртуалка не использует очередь хранилища. Затрудняюсь придумать пример, где это реально надо. Никогда не использовал этот режим.
▪️Writeback - операции записи и чтения кэшируются гипервизором. VM будет получать подтверждения о записи, когда данные попадут в кэш гипервизора, а не хранилища. Это существенно увеличивает быстродействие дисков VM. Особенно если у гипервизора много свободной оперативной памяти для кэша. Если будет сбой сервера и данные из кэша хоста не успеют записаться, то мы получим потерю информации с разными последствиями для системы. Она скорее всего выживет, но если там работала СУБД, то база может оказаться битой.
Если у вас настроен UPS, сервер корректно завершает работу в случае пропадания питания, и в целом стабильно работает, без проблем и аварийных завершений, то можно использовать этот режим для всех виртуальных машин. Железный рейд контроллер с батарейкой обычно работает в этом же режиме.
▪️Writeback (unsafe) - то же самое, что Writeback, но с одним отличием. В режиме Writeback гостевая VM может отправить команду на запись данных в реальное хранилище, а не кэш гипервизора. У неё есть возможность принудительно поддерживать консистентность данных. В режиме unsafe команда на запись в хранилище всё равно перехватывается кэшем хоста. Это обеспечивает максимальное быстродействие VM и максимальную ненадёжность сохранности данных. Я этот режим использую на тестовых гипервизорах.
❗️Все эти режимы имеют смысл при использовании типа диска RAW. Например, при использовании LVM Storage или обычных raw файлов с хранением в директории хоста. Во всех остальных случаях (qcow2, zfs) кэширование лучше не трогать и оставлять его в режиме none. Также следует аккуратно менять режимы при использовании raid контроллера с батарейкой, встроенной памятью и включенным кэшированием. Будет неочевидно, какой режим выбрать - тот или иной кэш гипервизора или самого контроллера, либо их обоих. Надо тестировать на своей нагрузке. Я в таких случаях оставляю кэш контроллера и не использую кэш гипервизора. Просто интуитивно так делаю. Как лучше, я не знаю.
🔹Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#proxmox #disk
▪️None - режим по умолчанию. Если не хочется разбираться в этой теме, то можете оставлять этот режим и не заморачиваться. Он универсален для сервера общего назначения. Гипервизор никак не вмешивается в операции ввода-вывода. VM работает как-будто напрямую с хранилищем. Может отправлять данные в очередь хранилища на запись, либо дожидаться реальной записи.
▪️Writethrough - операции записи VM идут напрямую в хранилище, как и в режиме none. В этом режиме добавляется кэш гипервизора, который используется только для чтения. То есть мы получаем такую же надёжность записи, как и в none, но добавляется кэш на операции чтения. Если у вас сервер отдаёт много статики, то можете включить этот режим.
Железный рейд контроллер без батарейки обычно работает в таком же режиме.
▪️Directsync - кэширование гипервизора не используется вообще, как в none. Отличие этого режима в том, что мы заставляем VM работать с хранилищем только в режиме реальной записи с подтверждением. То есть виртуалка не использует очередь хранилища. Затрудняюсь придумать пример, где это реально надо. Никогда не использовал этот режим.
▪️Writeback - операции записи и чтения кэшируются гипервизором. VM будет получать подтверждения о записи, когда данные попадут в кэш гипервизора, а не хранилища. Это существенно увеличивает быстродействие дисков VM. Особенно если у гипервизора много свободной оперативной памяти для кэша. Если будет сбой сервера и данные из кэша хоста не успеют записаться, то мы получим потерю информации с разными последствиями для системы. Она скорее всего выживет, но если там работала СУБД, то база может оказаться битой.
Если у вас настроен UPS, сервер корректно завершает работу в случае пропадания питания, и в целом стабильно работает, без проблем и аварийных завершений, то можно использовать этот режим для всех виртуальных машин. Железный рейд контроллер с батарейкой обычно работает в этом же режиме.
▪️Writeback (unsafe) - то же самое, что Writeback, но с одним отличием. В режиме Writeback гостевая VM может отправить команду на запись данных в реальное хранилище, а не кэш гипервизора. У неё есть возможность принудительно поддерживать консистентность данных. В режиме unsafe команда на запись в хранилище всё равно перехватывается кэшем хоста. Это обеспечивает максимальное быстродействие VM и максимальную ненадёжность сохранности данных. Я этот режим использую на тестовых гипервизорах.
❗️Все эти режимы имеют смысл при использовании типа диска RAW. Например, при использовании LVM Storage или обычных raw файлов с хранением в директории хоста. Во всех остальных случаях (qcow2, zfs) кэширование лучше не трогать и оставлять его в режиме none. Также следует аккуратно менять режимы при использовании raid контроллера с батарейкой, встроенной памятью и включенным кэшированием. Будет неочевидно, какой режим выбрать - тот или иной кэш гипервизора или самого контроллера, либо их обоих. Надо тестировать на своей нагрузке. Я в таких случаях оставляю кэш контроллера и не использую кэш гипервизора. Просто интуитивно так делаю. Как лучше, я не знаю.
🔹Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#proxmox #disk
⇨ Truenas Scale Electric Eel. Как же долго я тебя ждала
Вышло крупное обновление Trunas Scale - одно из лучших open source решений для NAS. Оказывается, в нём под капотом был Kebernetes 😱 В обновлении его заменили на Docker Compose. Содержательное видео по этому продукту.
⇨ OpenProject - Система для организации проектов. Обзор функций. Установка пакетов и docker
Обзор OpenProject - системы управления проектами с открытым исходным кодом. Популярная и функциональная система. Раньше про неё не слышал. Думаю, разверну и сделаю отдельную заметку.
⇨ Установка Speedtest Tracker на Synology
Обзор Speedtest Tracker для регулярной проверки и хранения результатов замеров скорости интернета. Не раз получал просьбы посоветовать что-то для регулярных замеров, чтобы был график и можно было отслеживать свой канал. Вот вариант решения задачи.
⇨ xPipe is a fantastic, amazing remote connection manager!
Обзор xPipe - менеджера для удалённых подключений. Я писал про него. Пользовался им некоторое время, но в итоге бросил. Докучали некоторые баги и его тормознутость. По виду и возможностям всё нравится, но на практике не зашло. Попробуйте, может вам понравится. Из особенностей - для подключений по SSH использует Windows Terminal. Лично мне это особенно нравилось.
⇨ What’s the better Git? // GitLab vs Gitea
Краткое сравнение GitLab и Gitea. Так то они сильно различаются. Не знаю, что сподвигло автора сравнить их в лоб. Наверное, тема популярная.
⇨ Self-host your own Git platform! // Gitea Tutorial
Вдогонку от этого же автора ролик про саму Gitea.
⇨ GitLab - Установка приватного GitLab Сервера с Ручной и Авто настройкой SSL + PASSWORD
Подробный урок по установке Gitlab. Рассмотрены и системные требования, и разные редакции и т.д. База для тех, кто не особо знаком с продуктом.
⇨ GitLab CI/CD - Полный DevOps Pipeline с НУЛЯ, Создание Docker Image и деплой в AWS ECS Fargate
Практический урок по созданию пайплайна в Gitlab. Он привязан к сервисам AWS. Пол урока создание там сущностей и раздача прав. Тем не менее показано всё наглядно для общего понимания, как это в принципе работает: разные ветки в git, ветвление деплоя в зависимости от ветки, переменные и т.д.
⇨ 7 Правил безопасности сервера
Автор рассмотрел некоторый набор правил для повышения безопасности сервера. Информация для новичков, набор тривиальный: не ходим под root, не используем пароль, прячем SSH порт и т.д.
⇨ PostgreSQL Clustering the Hard Way...
Тяжёлое для восприятия техническое видео на час по построению кластера на базе PostgreSQL. Смотреть имеет смысл, если вам актуальна эта тема. Кластер на базе Patroni.
⇨ Установка ONLYOFFICE в докер и связываем его с Nextcloud
Небольшая инструкция по настройке этой связки. Меня не раз спрашивали, как это настроить. Последний раз буквально неделю назад кто-то то ли в личку, то ли куда-то в комментарии писал.
⇨ SafeLine: A Feature-Rich WAF with a Catch (or Two)
Обзор open source self-hosted WAF. Не слышал про него ранее. Думаю, что попробую и напишу отдельную заметку.
⇨ Reubah: Optimize Your Images & Files Without Compromising Your Privacy
Функциональный open source продукт Rebuah для одиночной или пакетной обработки изображений. В целом ничего особенно, но выглядит аккуратно и удобно. Можно сразу перемотать на демонстрацию. Мне понравилось. В список программ для собственного применения записал.
⇨ The Perfect Home Server 2024 – 56TB, ECC, IPMI, Quiet & (kind of) Compact
Интересное описание сборки домашнего сервера с минимальным шумом с IPMI и ECC. Понравилась материнка из видео - gigabyte mc12-le0. К сожалению, не нашёл, где её у нас купить можно. На aliexpress тоже нету. У автора ролики очень хорошего качества. Огромное количество просмотров для такой узкой темы это подтверждают.
#видео
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Truenas Scale Electric Eel. Как же долго я тебя ждала
#nas, #opnsense, #truenas, #proxmox, #ubuntu
В этом ролике поговорим о ключевых изменениях в новой версии Truenas Scale 24.10. Посмотрим на новый dashboard, как расширить пулы, а самое главное пощупаем docker, который появился вместо kubernetes.
Можно…
В этом ролике поговорим о ключевых изменениях в новой версии Truenas Scale 24.10. Посмотрим на новый dashboard, как расширить пулы, а самое главное пощупаем docker, который появился вместо kubernetes.
Можно…
Новость разлетелась, что Proxmox выкатил совершенно новый продукт - Proxmox Datacenter Manager. Это веб панель, которая объединяет в едином интерфейсе все разрозненные хосты или кластеры. Информация пока только на форуме, так как это alpha версия:
⇨ Proxmox Datacenter Manager - First Alpha Release
Продукт однозначно востребован. Я уже писал когда-то, что сам для управления различными серверами с Proxmox держу отдельный браузер, куда добавляю все CA, сохраняю пароли и делаю директории со ссылками в быстром доступе, чтобы оперативно переключаться между серверами, открывая веб интерфейсы.
Существует похожий продукт от энтузиаста - Cluster Manager. Я писал о нём, пользовался. До сих пор стоит на ноуте и работает. Но проект не получил развитие. Новых версий со времени написания моей заметки так и не появилось. А теперь уже и не появится, так как вышла аналогичная панель от разработчиков.
Я пока не придумал, где лучше разместить Datacenter Manager, так как он по сути не привязан ни к какому проекту, а служит для моего личного удобства. Поставил на чистую виртуалку с Debian 12, которая работает на моём рабочем ноуте. В моём случае это единственное удобное размещение, так как к серверам обычно ограничен доступ. Попасть на них можно либо по белым спискам IP, либо по VPN, которые настроены на моём рабочем ноуте.
Идём по https://IP-server:8443, используем аутентификацию через системную учётку root сервера, на котором установлена панель.
Для подключения PVE к панели нужно, как обычно, указать Fingerprint сертификата сервера. Те, кто используют бесплатные от LE с коротким сроком жизни, будут страдать, так как при обновлении сертификата отпечаток меняется. Я обычно оставляю самоподписанные, которые создаются при установке сервера. Потом указывается учётка от сервера. PDM автоматом подключится к PVE, создаст там для себя токен пользователю root, которым будет пользоваться во время своей работы.
Возможностей пока не особо много. Можно быстро посмотреть информацию о сервере, его ресурсах, виртуалках. Остановить, запустить их. Там же в списке серверов есть ссылки, чтобы подключиться к веб интерфейсу конкретного сервера. Всё это пока тормозит и подглючивает. Графики у меня не рисовались, а отображение использования CPU и RAM сильно отставало от реальных значений. Панелька падала пару раз с ошибками. Если вам не сильно надо, то не торопитесь устанавливать.
Составлен Roadmap с обещанием следующих возможностей:
▪️Расширенное управление хостами: обновления, бэкапы, репозитории и т.д.
▪️Интеграция со службой SDN на хостах.
▪️Миграция виртуалок между хостами. Сейчас работает только, если они на ZFS.
▪️Поддержка остальных продуктов: Proxmox Backup Server и Proxmox Mail Gateway.
Список большой, я перечислил только наиболее интересное на мой взгляд. Подробный обзор панели можно посмотреть в свежем видео со странным названием:
▶️ Proxmox Datacenter Manager - кластер теперь не нужен ?
#proxmox
⇨ Proxmox Datacenter Manager - First Alpha Release
Продукт однозначно востребован. Я уже писал когда-то, что сам для управления различными серверами с Proxmox держу отдельный браузер, куда добавляю все CA, сохраняю пароли и делаю директории со ссылками в быстром доступе, чтобы оперативно переключаться между серверами, открывая веб интерфейсы.
Существует похожий продукт от энтузиаста - Cluster Manager. Я писал о нём, пользовался. До сих пор стоит на ноуте и работает. Но проект не получил развитие. Новых версий со времени написания моей заметки так и не появилось. А теперь уже и не появится, так как вышла аналогичная панель от разработчиков.
Я пока не придумал, где лучше разместить Datacenter Manager, так как он по сути не привязан ни к какому проекту, а служит для моего личного удобства. Поставил на чистую виртуалку с Debian 12, которая работает на моём рабочем ноуте. В моём случае это единственное удобное размещение, так как к серверам обычно ограничен доступ. Попасть на них можно либо по белым спискам IP, либо по VPN, которые настроены на моём рабочем ноуте.
# echo 'deb http://download.proxmox.com/debian/pdm bookworm pdm-test' >/etc/apt/sources.list.d/pdm-test.list# wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg# apt update# apt install proxmox-datacenter-manager proxmox-datacenter-manager-uiИдём по https://IP-server:8443, используем аутентификацию через системную учётку root сервера, на котором установлена панель.
Для подключения PVE к панели нужно, как обычно, указать Fingerprint сертификата сервера. Те, кто используют бесплатные от LE с коротким сроком жизни, будут страдать, так как при обновлении сертификата отпечаток меняется. Я обычно оставляю самоподписанные, которые создаются при установке сервера. Потом указывается учётка от сервера. PDM автоматом подключится к PVE, создаст там для себя токен пользователю root, которым будет пользоваться во время своей работы.
Возможностей пока не особо много. Можно быстро посмотреть информацию о сервере, его ресурсах, виртуалках. Остановить, запустить их. Там же в списке серверов есть ссылки, чтобы подключиться к веб интерфейсу конкретного сервера. Всё это пока тормозит и подглючивает. Графики у меня не рисовались, а отображение использования CPU и RAM сильно отставало от реальных значений. Панелька падала пару раз с ошибками. Если вам не сильно надо, то не торопитесь устанавливать.
Составлен Roadmap с обещанием следующих возможностей:
▪️Расширенное управление хостами: обновления, бэкапы, репозитории и т.д.
▪️Интеграция со службой SDN на хостах.
▪️Миграция виртуалок между хостами. Сейчас работает только, если они на ZFS.
▪️Поддержка остальных продуктов: Proxmox Backup Server и Proxmox Mail Gateway.
Список большой, я перечислил только наиболее интересное на мой взгляд. Подробный обзор панели можно посмотреть в свежем видео со странным названием:
#proxmox
Please open Telegram to view this post
VIEW IN TELEGRAM
Вчера была новость о релизе Proxmox VE 8.4. Из нововведений там ничего особенного не увидел, кроме одного момента. Анонсировали Virtiofs – функциональность для совместного доступа к файлам и директориям хоста из виртуальных машин. Это реально полезная штука, так как нередко возникает такая потребность. Обычно приходится поднимать NFS или SMB для этого. Решил сразу посмотреть, как это работает.
Обновил тестовый гипервизор. В списке оборудования VM появилось новое устройство - Virtiofs. А в Datacenter появился новый подраздел Directory Mappings. В этом разделе вам нужно создать общую директорию на хосте, а потом в виртуальную машину добавить через новое устройство.
Итак, чтобы использовать Virtiofs для гостевых виртуальных систем надо:
1️⃣ Добавить общую директорию хоста через Datacenter ⇨ Directory Mappings.
2️⃣ Добавить устройство Virtiofs в виртуальную машину и указать ранее созданную общую директорию.
3️⃣ Современные ядра Linux версии >=5.4 имеют встроенную поддержку virtiofs, ничего специально для её работы делать не надо. Сразу монтируем внутри системы:
Я смонтировал общую директорию
Если у вас виртуальная машина Windows, то нужно установить специальный драйвер, который обеспечит поддержку virtiofs. Он входит в состав актуального диска VirtIO-Win package (virtio-win.iso). Дополнительно понадобится программа WinFsp. Это аналог линуксового FUSE.
Для Linux всё выглядит просто и удобно. Для Windows добавляются костыли в виде установки драйвера virtiofs и аналога линуксового FUSE, чтобы смонтировать пользователю общий диск. Не знаю, насколько это будет быстро и стабильно.
⇨ Документация по Virtiofs
⇨ Virtiofs в Windows
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#proxmox
Обновил тестовый гипервизор. В списке оборудования VM появилось новое устройство - Virtiofs. А в Datacenter появился новый подраздел Directory Mappings. В этом разделе вам нужно создать общую директорию на хосте, а потом в виртуальную машину добавить через новое устройство.
Итак, чтобы использовать Virtiofs для гостевых виртуальных систем надо:
# mount -t virtiofs VM_Shares /mnt/VM_SharesЯ смонтировал общую директорию
VM_Shares, добавленную в Directory Mappings с указанными именем в директорию /mnt/VM_Shares виртуальной машины с Linux.Если у вас виртуальная машина Windows, то нужно установить специальный драйвер, который обеспечит поддержку virtiofs. Он входит в состав актуального диска VirtIO-Win package (virtio-win.iso). Дополнительно понадобится программа WinFsp. Это аналог линуксового FUSE.
Для Linux всё выглядит просто и удобно. Для Windows добавляются костыли в виде установки драйвера virtiofs и аналога линуксового FUSE, чтобы смонтировать пользователю общий диск. Не знаю, насколько это будет быстро и стабильно.
⇨ Документация по Virtiofs
⇨ Virtiofs в Windows
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#proxmox
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Я написал большую и насколько смог подробную статью по настройке кластера на базе Proxmox VE. По современным требованиям законодательства я вынужден промаркировать её как реклама, так как сервера для её написания мне предоставил хостер Selectel, а я оставил на него ссылки. Никаких требований непосредственно по рекламе предъявлено не было, кроме одного – в статье должно быть показано, как я заказываю услуги через панель управления. По содержанию и тексту не было ни единой правки. Всё продумал, настроил и написал лично я от и до.
Статья получилась универсальной без привязки к конкретным услугам, так как я использую обычные арендные сервера с установленной бесплатной версией Proxmox VE, а в качестве общих хранилищ для кластера – сетевые диски, подключаемые через iSCSI интерфейс. Настройка подобных дисков плюс-минус везде одинаковая. Разница если и будет, то в типе аутентификации или её отсутствии.
В статье отражены следующие моменты:
▪️Настройка Proxmox VE на серверах с двумя NVMe M.2 дисками, объединёнными в программный RAID1 на базе mdadm для отказоустойчивости на уровне дисков.
▪️Объединение трёх идентичных серверов в обычный кластер с локальными дисками и ручной миграцией виртуальных машин без их остановки.
▪️Настройка сети виртуальных машин с VLAN с помощью встроенной Proxmox SDN.
▪️Подключение к серверам сетевых дисков по iSCSI, добавление их в Proxmox и создание на их базе общих хранилищ для дисков виртуальных машин в формате LVM.
▪️Настройка HA (High Availability) на примере виртуальной машины и LXC контейнера. Я настраиваю HA, аварийно выключаю одну из нод кластера и показываю, как с неё автоматически переезжают ресурсы на работающие ноды.
На выходе мы получаем универсальное и относительно бюджетное (в сравнении с другими кластерами) решение для размещения виртуальных машин и LXC контейнеров. Оно закрывает задачи размещения нагрузки на локальных дисках для максимальной производительности и отказоустойчивой нагрузки высокой доступности на базе сетевых дисков с общим доступом.
Остались нерассмотренными пара других полезных конфигураций:
◽️Репликация виртуальных машин в кластере на базе файловых хранилищ в формате zfs.
◽️Использование кластера Ceph для виртуальных машин, построенного на базе этих же трёх нод кластера.
Изначально хотел всё это рассмотреть, но по факту материал получился и так очень большой, потратил на него много времени и банально не осилил. Возможно получится это сделать в будущих статьях.
⇨ Установка и настройка кластера Proxmox VE
Настройка кластера высокой доступности на базе Proxmox VE представляет из себя относительно простую, рядовую задачу. При этом выполнить её можно на любом железе, от самого бюджетного десктопного оборудования до серверных платформ. Сочетание софтовых решений по отказоустойчивости дисков на базе mdadm или zfs вкупе с функциональностью HA кластера Proxmox позволяют реализовать относительно (!) высокую доступность на любом поддерживаемом этой системой оборудовании. А так как сама система на базе ОС Debian и ядра Linux, поддерживает она практически любое более-менее современное железо.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#proxmox #статья
Статья получилась универсальной без привязки к конкретным услугам, так как я использую обычные арендные сервера с установленной бесплатной версией Proxmox VE, а в качестве общих хранилищ для кластера – сетевые диски, подключаемые через iSCSI интерфейс. Настройка подобных дисков плюс-минус везде одинаковая. Разница если и будет, то в типе аутентификации или её отсутствии.
В статье отражены следующие моменты:
▪️Настройка Proxmox VE на серверах с двумя NVMe M.2 дисками, объединёнными в программный RAID1 на базе mdadm для отказоустойчивости на уровне дисков.
▪️Объединение трёх идентичных серверов в обычный кластер с локальными дисками и ручной миграцией виртуальных машин без их остановки.
▪️Настройка сети виртуальных машин с VLAN с помощью встроенной Proxmox SDN.
▪️Подключение к серверам сетевых дисков по iSCSI, добавление их в Proxmox и создание на их базе общих хранилищ для дисков виртуальных машин в формате LVM.
▪️Настройка HA (High Availability) на примере виртуальной машины и LXC контейнера. Я настраиваю HA, аварийно выключаю одну из нод кластера и показываю, как с неё автоматически переезжают ресурсы на работающие ноды.
На выходе мы получаем универсальное и относительно бюджетное (в сравнении с другими кластерами) решение для размещения виртуальных машин и LXC контейнеров. Оно закрывает задачи размещения нагрузки на локальных дисках для максимальной производительности и отказоустойчивой нагрузки высокой доступности на базе сетевых дисков с общим доступом.
Остались нерассмотренными пара других полезных конфигураций:
◽️Репликация виртуальных машин в кластере на базе файловых хранилищ в формате zfs.
◽️Использование кластера Ceph для виртуальных машин, построенного на базе этих же трёх нод кластера.
Изначально хотел всё это рассмотреть, но по факту материал получился и так очень большой, потратил на него много времени и банально не осилил. Возможно получится это сделать в будущих статьях.
⇨ Установка и настройка кластера Proxmox VE
Настройка кластера высокой доступности на базе Proxmox VE представляет из себя относительно простую, рядовую задачу. При этом выполнить её можно на любом железе, от самого бюджетного десктопного оборудования до серверных платформ. Сочетание софтовых решений по отказоустойчивости дисков на базе mdadm или zfs вкупе с функциональностью HA кластера Proxmox позволяют реализовать относительно (!) высокую доступность на любом поддерживаемом этой системой оборудовании. А так как сама система на базе ОС Debian и ядра Linux, поддерживает она практически любое более-менее современное железо.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#proxmox #статья
Server Admin
Proxmox — настройка HA кластера (High Availability)
Подробное пошаговое руководство по настройке Proxmox VE на нескольких серверах и объединение их в HA кластер высокой доступности.
Вчера в публикации про сетевые проблемы в комментариях подписчик упомянул проблемы с сетевой картой Realtek. Я сталкивался с ними несколько раз и прилично натерпелся, так что мне есть что сказать. Возможно кому-то это сэкономит время, если столкнётся с похожими проблемами.
Проблема эта всплывает, когда ставишь Proxmox на десктопное железо. Я нередко его использовал для различных вспомогательных задач – тестирование бэкапов, временный запасной гипервизор и т.д. В прод ставить не рекомендую, хоть и будет работать, и может показаться это выгодным. Я всегда настаивал на покупке хоть какого, старого, бушного, но сервера на полноценной серверной платформе с IPMI.
Итак, проблемы могут возникнуть, когда у вас будет примерно такая сетевая карта:
По умолчанию у вас будет установлен драйвер r8169. Проверить так:
С ним сетевая карта может быть как вообще недоступна, так и на вид полностью рабочей, но с вероятностью непрогнозируемого зависания. Причём зависать она может очень редко, например, раз в месяц в момент сильной сетевой загрузки. Выглядит это так, что сеть как-будто вообще не работает. Причём проявляться это может как на гипервизоре, так и в каких-то отдельных виртуальных машинах. Они перестают быть доступны по сети.
Проблема может через 10 минут пройти сама, а может и нет, и поможет только перезагрузка. В логах могут быть какие-то упоминания проблем с сетевой картой, типа таких:
А может и вообще ничего не быть. Известное мне решение только одно – использовать драйвер r8168. Это решение широко освещено на официальном форуме Proxmox. Там можно найти множество веток с обсуждением подобной проблемы.
Драйвер можно скачать самому и собрать его. Взять можно, например, тут. Там есть инструкция по сборке, она несложная. Можно взять готовый пакет для Debian из non-free репозитория: r8168-dkms. Установить его можно так. Добавляем себе в систему репозитории non-free и non-free-firmware. То есть в файле
Ставим необходимые пакеты:
Во время установки r8168-dkms должен собраться и установиться драйвер r8168, а предыдущий r8169 отключиться и добавиться к заблокированным во время загрузки.
Есть ещё один пакет с этим драйвером, собранный специально под PVE. Я не знаю, чем он отличается от обычного дебиановского. Брать тут. Его достаточно просто скачать и установить:
Описанные выше действия могут как помочь, так и нет. Например, на одном сервере я вообще не видел сетевой карты. После установки драйвера r8168, она определялась в системе и начинала нормально работать. А иногда ничего не менялось и сеть как отваливалась периодически, так и продолжала отваливаться. Тогда приходилось делать что-то типа такого:
Ставил подобный bash скрипт в cron на исполнение каждую минуту. В моменты редких зависаний он перезапускал сеть и всё продолжало нормально работать.
☝️ А резюме всего этого такое. Если у вас сетевая карта Realtek, то либо замените её, либо не ставьте туда Proxmox. Есть высокая вероятность, что нормально он всё равно работать не будет, а вы только время потеряете на отладку и решение проблем.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#proxmox #ошибка
Проблема эта всплывает, когда ставишь Proxmox на десктопное железо. Я нередко его использовал для различных вспомогательных задач – тестирование бэкапов, временный запасной гипервизор и т.д. В прод ставить не рекомендую, хоть и будет работать, и может показаться это выгодным. Я всегда настаивал на покупке хоть какого, старого, бушного, но сервера на полноценной серверной платформе с IPMI.
Итак, проблемы могут возникнуть, когда у вас будет примерно такая сетевая карта:
# lspci | grep Ethernet04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet ControllerПо умолчанию у вас будет установлен драйвер r8169. Проверить так:
# lsmod | grep r81r8169С ним сетевая карта может быть как вообще недоступна, так и на вид полностью рабочей, но с вероятностью непрогнозируемого зависания. Причём зависать она может очень редко, например, раз в месяц в момент сильной сетевой загрузки. Выглядит это так, что сеть как-будто вообще не работает. Причём проявляться это может как на гипервизоре, так и в каких-то отдельных виртуальных машинах. Они перестают быть доступны по сети.
Проблема может через 10 минут пройти сама, а может и нет, и поможет только перезагрузка. В логах могут быть какие-то упоминания проблем с сетевой картой, типа таких:
[01448.532276] r8169 0000:09:00.0 enp3s0: rtl_rxtx_empty_cond == 0 (loop: 42, delay: 100).А может и вообще ничего не быть. Известное мне решение только одно – использовать драйвер r8168. Это решение широко освещено на официальном форуме Proxmox. Там можно найти множество веток с обсуждением подобной проблемы.
Драйвер можно скачать самому и собрать его. Взять можно, например, тут. Там есть инструкция по сборке, она несложная. Можно взять готовый пакет для Debian из non-free репозитория: r8168-dkms. Установить его можно так. Добавляем себе в систему репозитории non-free и non-free-firmware. То есть в файле
/etc/apt/sources.list должна быть строка:deb http://ftp.ru.debian.org/debian bookworm main contrib non-free non-free-firmwareСтавим необходимые пакеты:
# apt install pve-headers r8168-dkmsВо время установки r8168-dkms должен собраться и установиться драйвер r8168, а предыдущий r8169 отключиться и добавиться к заблокированным во время загрузки.
Есть ещё один пакет с этим драйвером, собранный специально под PVE. Я не знаю, чем он отличается от обычного дебиановского. Брать тут. Его достаточно просто скачать и установить:
# wget https://github.com/nathanhi/r8168/releases/download/pve8%2F8.054.00-1-bpo12/r8168-dkms_8.054.00-1-bpo12_all.deb# dpkg -i r8168-dkms_8.054.00-1-bpo12_all.debОписанные выше действия могут как помочь, так и нет. Например, на одном сервере я вообще не видел сетевой карты. После установки драйвера r8168, она определялась в системе и начинала нормально работать. А иногда ничего не менялось и сеть как отваливалась периодически, так и продолжала отваливаться. Тогда приходилось делать что-то типа такого:
#!/bin/bashIP="10.20.1.2"if ! ping -c 1 -W 5 "$IP" > /dev/null 2>&1; then echo "$(date): $IP недоступен. Перезапуск сетевой службы..." systemctl restart networkingelse echo "$(date): $IP доступен."fiСтавил подобный bash скрипт в cron на исполнение каждую минуту. В моменты редких зависаний он перезапускал сеть и всё продолжало нормально работать.
☝️ А резюме всего этого такое. Если у вас сетевая карта Realtek, то либо замените её, либо не ставьте туда Proxmox. Есть высокая вероятность, что нормально он всё равно работать не будет, а вы только время потеряете на отладку и решение проблем.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#proxmox #ошибка
GitHub
GitHub - mtorromeo/r8168: Linux device driver for Realtek Ethernet controllers (unofficial mirror)
Linux device driver for Realtek Ethernet controllers (unofficial mirror) - mtorromeo/r8168