ServerAdmin.ru
31.6K subscribers
839 photos
57 videos
23 files
2.99K links
Авторская информация о системном администрировании.

Информация о рекламе: @srv_admin_reklama_bot
Автор: @zeroxzed

Второй канал: @srv_admin_live
Сайт: serveradmin.ru

Ресурс включён в перечень Роскомнадзора
Download Telegram
Как можно закрыть веб интерфейс Proxmox от посторонних глаз? Если, к примеру, вы арендуете одиночный сервер и он смотрит напрямую в интернет. Как вы понимаете, способов тут может быть очень много. Расскажу про самые простые, быстрые в настройке и эффективные. Они все будут проще, чем настроить VPN и организовать доступ через него.

1️⃣ Самый простой способ - настроить ограничение по IP с помощью настроек pveproxy. Я об этом подробно рассказывал в отдельной заметке. Достаточно создать файл /etc/default/pveproxy примерно такого содержимого:

ALLOW_FROM="192.168.13.0/24,1.1.1.1"
DENY_FROM="all"
POLICY="allow"

И после этого перезапустить службу:

# systemctl restart pveproxy.service

2️⃣ С помощью iptables. Если заранее не настроили iptables, то на работающем сервере лучше не пробовать настраивать, если у вас нет прямого доступа к консоли. Если файрвол вообще не настраивали, то в общем случае понадобятся два правила:

/usr/sbin/iptables -A INPUT -i enp5s0 -s 192.168.13.0/24,1.1.1.1 -p tcp --dport 8006 -j ACCEPT
/usr/sbin/iptables -A INPUT -i enp5s0 -p tcp --dport 8006 -j DROP

Первое разрешает подключения из подсети 192.168.13.0/24 и ip адреса 1.1.1.1. Второе правило запрещает все остальные подключения к веб интерфейсу. Правила эти можно сохранить в файл и подгружать во время загрузки сервера или явно прописать в /etc/network/interfaces примерно так:

auto enp5s0
iface enp5s0 inet static
address 5.6.7.8/24
dns-nameservers 188.93.17.19 188.93.16.19
gateway 5.6.7.1
post-up /usr/sbin/iptables -A INPUT -i enp5s0 -s 192.168.13.0/24,1.1.1.1 -p tcp --dport 8006 -j ACCEPT
post-up /usr/sbin/iptables -A INPUT -i enp5s0 -p tcp --dport 8006 -j DROP

Если уже есть другие правила, то их надо увязывать вместе в зависимости от ситуации. Тут нет универсальной подсказки, как поступить. Если не разбираетесь в iptables, не трогайте его. Используйте другие методы.

Я сам всегда использую iptables. Настраиваю его по умолчанию на всех гипервизорах. Примерный набор правил показывал в заметке.

3️⃣ Вы можете установить Nginx прямо на хост с Proxmox, так как по своей сути это почти обычный Debian. У Nginx есть свои способы ограничения доступа по ip через allow/deny в конфигурации, либо по пользователю/паролю через basic auth. Бонусом сюда же идёт настройка TLS сертификатов от Let's Encrypt и доступ по 443 порту, а не стандартному 8006.

Ставим Nginx:

# apt install nginx

Настраиваем базовый конфиг /etc/nginx/sites-available/default:

server {
listen 80 default_server;
server_name _;
allow 192.168.13.0/24;
allow 1.1.1.1/32;
deny all;
return 301 https://5.6.7.8;
}
server {
listen 443 ssl;
server_name _;
ssl_certificate /etc/pve/local/pve-ssl.pem;
ssl_certificate_key /etc/pve/local/pve-ssl.key;
proxy_redirect off;
allow 192.168.13.0/24;
allow 1.1.1.1/32;
deny all;
location / {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_pass https://localhost:8006;
proxy_buffering off;
client_max_body_size 0;
}
}

Разрешили подключаться только с указанных адресов. Это пример с использованием стандартных сертификатов. Для Let's Encrypt нужна отдельная настройка, которая выходит за рамки этой заметки. Для того, чтобы закрыть доступ паролем, а не списком IP адресов, необходимо настроить auth_basic. Настройка легко гуглится по ключевым словам nginx auth_basic, не буду об этом рассказывать, так как не умещается в заметку. Там всё просто.

Этот же Nginx сервер можно использовать для проксирования запросов внутрь виртуалок. Удобный и универсальный способ, если вы не используете отдельную виртуалку для управления доступом к внутренним ресурсам.

После настройки Nginx, доступ к веб интерфейсу по порту 8006 можно закрыть либо через pveproxy, либо через iptables.

#proxmox
👍106👎3
В продуктах Proxmox не так давно появилась возможность использовать сторонние SMTP сервера для отправки уведомлений. Точнее, стало возможно через веб интерфейс настроить аутентификацию на внешнем сервере. В PVE вроде бы с 8-го релиза появилась эта настройка, в PBS не помню точно.

В разделе меню Notification обоих продуктов появился новый тип уведомлений SMTP, где можно указать привычные параметры внешних почтовых серверов. Тем не менее, если для отправки используется бесплатный почтовый сервис типа Yandex, Mail или Gmail, я предпочитаю настраивать по старинке через локальный Postfix, который так же использует внешний SMTP сервер с аутентификацией.

Причина этого в том, что через Postfix отправляются и другие системные сообщение, плюс есть нормальное логирование, где можно сразу понять, если по какой-то причине письма не будут отправляться. У Postfix очень информативный лог. Его и мониторить удобно, и решать возникающие проблемы.

Настройка Postfix простая. Не помню, устанавливается ли он в свежих версиях PVE и PBS по умолчанию, но если нет, то надо поставить:

# apt install postfix

И затем добавить в конфиг /etc/postfix/main.cf, например, для Яндекса:

relayhost = smtp.yandex.ru:465
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_security_options =
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_CAfile = /etc/ssl/certs/Entrust_Root_Certification_Authority.pem
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_tls_session_cache
smtp_tls_session_cache_timeout = 3600s
smtp_tls_wrappermode = yes
smtp_tls_security_level = encrypt
smtp_generic_maps = hash:/etc/postfix/generic


Если эти же параметры где-то выше уже объявлены, то закомментируйте их там. Создаём файл /etc/postfix/sasl_passwd такого содержания:

smtp.yandex.ru user01@yandex.ru:userpass123

Эти данные нужны для аутентификации. Убедитесь, что у файла права 600, чтобы никто, кроме рута, не смог его прочитать.

Создайте файл /etc/postfix/generic:

root@pve user01@yandex.ru

Здесь мы настраиваем, чтобы все письма от локального пользователя root сервера с именем pve отправлялись с заменой адреса отправителя на user01@yandex.ru. Иначе Яндекс не примет письмо к отправке. У других почтовых сервисов может не быть таких ограничений и этот шаг можно будет пропустить.

Формируем на основе текстовых файлов локальные базы данных, с которыми будет работать postfix, и перезапускаем его:

# postmap /etc/postfix/generic /etc/postfix/sasl_passwd
# systemctl restart postfix

Можно проверять отправку. Проще всего это сделать в веб интерфейсе PVE. Для этого идём в раздел Datacenter ⇨ Notification. Там по умолчанию уже есть способ отправки типа sendmail с указанным Target mail-to-root. Это как раз отправка почты с помощью Postfix на ящик системного пользователя root@pam. Ящик для него можно указать в настройках пользователя: Datacenter ⇨ Permissions ⇨ Users ⇨ root ⇨ E-Mail.

Выбираем способ отправки sendmail и жмём Test. Можно сходить в консоль сервера и проверить лог отправки. Если всё прошло успешно, то в /var/log/mail.log будет примерно следующее:

pve postfix/pickup[941603]: 4C81718E07A1: uid=0 from=<user01@yandex.ru>
pve postfix/cleanup[941760]: 4C81718E07A1: message-id=<20240820202545.4C81718E07A1@pve>
pve postfix/qmgr[941604]: 4C81718E07A1: from=<user01@yandex.ru>, size=894, nrcpt=1 (queue active)
pve postfix/smtp[941762]: 4C81718E07A1: to=<superadmin@yandex.ru>, relay=smtp.yandex.ru[77.88.21.158]:465, delay=0.48, delays=0.03/0.02/0.17/0.26, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued on mail-nwsmtp-smtp-production-main-17.iva.yp-c.yandex.net 1724185545-jPUEPlgXtGk0-KOiggjh6)
pve postfix/qmgr[941604]: 4C81718E07A1: removed


Сервер успешно использовал relay=smtp.yandex.ru и отправил с его помощью письмо superadmin@yandex.ru, получив status=sent. Письмо ушло адресату, отправляющий сервер принял его в обработку.

Подобная настройка будет актуальна для любого сервера с Linux, так что можете сохранить на память готовую инструкцию.

#proxmox
👍132👎2
Я ранее делал пару заметок на тему бесплатных инструментов для организации SSO: Keycloak и Authentik. Первый более навороченный и сложный для больших организаций. Второй попроще и больше подходит для небольших инфраструктур, в том числе личных сервисов. По настройке и возможностям мне Authentik понравился больше. Жду подходящий проект, чтобы его внедрить. Уже давно решил, что где-нибудь его попробую.

Тут как раз на днях посмотрел видео про настройку Basic Auth на базе Authentik. Очень востребованная лично для меня функциональность. Я люблю использовать Basic Auth в Nginx для того, чтобы скрыть от посторонних глаз то, что не должно быть в публичном доступе: различные управляющие веб панели, типа postfixadmin или phpmyadmin, веб доступ к 1С и т.д.

▶️ Authentik и basic http аутентификация

Автор по шагам показал, как это сделать на примере Traefik и Nginx. Там ничего особо сложного, но из-за скудной документации по этой теме некоторые вещи неочевидны. С инструкцией всё понятно. Посмотрел наглядно, как это выглядит. Мне понравилось. С учётом того, как часто я использую Basic Auth, точно пригодится. Вот ссылка на документацию по теме. Там реально всего пару предложений и пример конфига.

У автора серия из 3-х публикаций про Authentik:
▶️ Настройка authentik по-быстрому
▶️ OIDC авторизация с помощью Authentik на примере Portainer

Этой информации достаточно для базового внедрения основных возможностей. Материал свежий и пока актуальный.

#sso #nginx
2👍74👎3
iptables-proxmox.sh
4.8 KB
Поискал по каналу и не нашёл ни одной заметки, где бы я рассказал и показал на практике, как я настраиваю iptables на гипервизорах Proxmox. Я всегда в обязательном порядке это делаю. Не утверждаю, что так, как настраиваю я, правильно и наиболее подходящий вариант. Просто привык делать именно так, проблем с этим не было, поэтому закрепилось. Воспроизвожу из раза в раз эту настройку.

Порядок настройки следующий:

1️⃣ Сохраняю список правил в файл /etc/iptables.sh. Адаптирую под текущие условия гипервизора: меняю имена сетевых интерфейсов, IP адреса. Делаю его исполняемым. Обычно сразу же проверяю, просто запустив его.

# mcedit /etc/iptables.sh
# chmod +x /etc/iptables.sh
# bash /etc/iptables.sh
# iptables -L -v -n

Настройку делаю на чистом гипервизоре, поэтому даже если ошибусь где-то, то проблемы это не вызовет. Набор правил отлажен, обычно проблем нет, если не ошибся с именами интерфейсов.

2️⃣ Убеждаюсь, что после выполнения скрипта появился файл-экспорт с набором правил /etc/iptables.rules. Добавляю применение правил в файл /etc/network/interfaces:

iface enp5s0 inet manual
post-up iptables-restore < /etc/iptables.rules

Вешаю загрузку правил iptables на поднятие wan интерфейса.

3️⃣ Перезагружаю сервер и убеждаюсь, что всё нормально поднимается, правила применяются, доступ к серверу у меня есть.

4️⃣ Если нужно добавить или изменить какое-то правило, то правлю файл iptables.sh, а когда закончу, запускаю его. Он обновляет набор правил в iptables.rules, так что после перезагрузки хоста изменённые правила сохранятся.

Если у вас хост Proxmox выполняет роль шлюза, то не забудьте проверить, что параметр net.ipv4.ip_forward=1 активен в /etc/sysctl.conf. Без него NAT для виртуалок не заработает. Точнее не сам нат, а передача пакетов между локальным и wan интерфейсом. Если в качестве шлюза для VM выступает отдельная VM, то как минимум из набора правил исчезает NAT и всё, что касается локалки и проброса портов. А на шлюз уезжает этот же шаблон с правилами и там правится по месту.

В наборе правил пример с работающего сервера. На основе него можете сформировать свой набор правил. Я там некоторые правила закомментировал, так как нужны они будут не всем. Оставил их для примера.

Формирую набор правил именно в таком виде, потому что он мне кажется удобным и наглядным. Можно быстро оценить все правила, оставить комментарии, что-то добавить.

#proxmox #iptables
3👍145👎4
В Proxmox 7.3 без особых подробностей завезли обновление со следующим описанием: Framework for remote migration to cluster-external Proxmox VE hosts. По факту добавили экспериментальную возможность по миграции виртуальных машин между гипервизорами (не только кластерами).

Реализована миграция с помощью консольной команды 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

🦖 Selectel — дешёвые и не очень дедики с аукционом!
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍187👎2
▶️ Очередная подборка авторских 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. Я, кстати, об этой уязвимости писал в своё время. На видео примерно то же самое делается, что у меня в заметке.

#видео
2👍60👎8
Когда только начинал работать с виртуализацией на Linux, очень хотелось сесть за сервер и прямо на нём что-то сделать. Но на тот момент ни XenServer, ни VmWare не позволяли это сделать. На экране сервера был небольшой список простых действий типа настроек сети или перезагрузки. И ничего, что относилось бы к управлению виртуальными машинами. После экспериментов с VMware Workstation и Hyper-V было как-то непривычно и неудобно.

Для управления гипервизором нужно было сесть за какое-то рабочее место, поставить соответствующий клиент и через него подключаться для управления. В 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
👍173👎14
Для автоматизации установки и настройки виртуальных машин в 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 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
👍139👎6
Пока была возможность, решил проверить, какой штраф на дисковые операции накладывает виртуализация в Proxmox. В моей работе чаще всего именно дисковая подсистема является узким местом серверов. CPU обычно хватает, память сейчас недорога и легко расширяется. С дисками проблем больше всего.

Взял тестовый сервер 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
2👍126👎4
Завершу тему с тестированием дисков информацией про кэширование в 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
5👍151👎1