О разметке, о VLM и о тонких дисках далее и пойдет речь.
На одном сервере столкнулся с очень большой и неприятной вещью. Сервер отдельный, на debian 8. При разметке, в которой отдельное большое место выделяется под thin-lvm диск для хранения дисков виртуальных машин, есть одна тонкость, которую я не учитывал ранее.
Пример реальной конфигурации: создан soft raid-10 из 4 дисков по 3 Тб.
Из общих 5,7 Тб выделен отдельный диск в 5,37 типа LVM-Thin для дисков виртуалок. Размещены виртуальные машины, общий выделенный объем дисков которых составил 4,03 ТБ. Машины работали себе и понемногу заполняли диски. Заполнение за полгода составило в среднем на 20-30% в каждой из виртуалок.
В очередной день (естественно понедельник, который совпал еще и с первым днем долгожданного отпуска) наш сервер zabbix начал лихорадочно отправлять через телеграмм уведомления от витруалок. Сначала про отказы отдельных сервисов типа http или ssh, а потом и вовсе про потерю пингов. Полез подключаться через ssh на почтовую виртуалку, тормозит, с первых пары секунд ничего не понятно, тут прилетают еще с десяток сообщений от zabbix о проблемах других виртуалок. Боковым взглядом понимаю, что плохо у всех виртуалок, кроме самого гиперзивора. Залезаю на него и открываю консоль первой же проблемной машины.
И вижу
device-mapper: message ioctl on failed: Operation not supportedПервым, что подумал, рассыпался soft-raid. Но почему не было уведомления на эту тема от самого гипера – раз, почему гиппер работает внешне корректно – два.
Лезу на lvm –a И вижу общие данные по pve\data
Data% — 23,51%
Meta% — 99,95%
Шах и мат.
Проверяю остальные виртуалки – лежат с такими же ошибками записи, сервисы лихорадочно дергаются в конвульсиях. Пользователи – в истерике.
Из всех вменяемых статей в гугле на эту тему – везде пишут одно и тоже средство – расширить место с помощью добавления дополнительного физического жесткого диска.
Учитывая, что попасть в наш местный форд нокс, где находится этот сервер сложновато, теряем кучу времени, отправляем атишника с флешкой на 8Гб. Через 1,5 часа он на месте, вставляет флешку, я добавляю ее в группу lvm, расширяю meta диск еще на 3 Гб командой:
lvresize --poolmetadatasize +3G pve/dataИ получаю в итоге Meta% — 1,58%
Перезапускаю по очереди машины, проверяя их диски и исправляя проблемы руками, т.к. некоторые (например, почтовый сервер) не захотели без проблем и исправлений по sfck запускаться по-человечески. И наконец-то решаю проблему.
Что это было, Карл? — спрашиваю я себя.
Создавая раздел Thin-LVM и добавляя его в proxmox я и не думал, что надо вручную учитывать емкость метаданных, вычислять их на калькуляторе и задавать вручную при создании диска. Почему такие важные, критичные показатели никак не мониторятся к примеру через тот же GUI Proxmox?
Ребята, если не сложно, в комментариях, очень прошу высказаться по этому поводу, что сделано не так, почему очень мало написано про создание Thin и именно про meta данные. И какие есть варианты решения проблемы помимо моего. Далеко не всегда рядом может оказаться авторизованный человек с флешкой, которого пустили в ДЦ, дали доступ в стойку, а я, находясь в отпуске за 1 тыс км, сумел-таки простоем в 2 часа решить проблему.
P.S.: Ну и результат конечно же меня не устраивает. Флешка таки торчит в сервере. Добавлена в группу LVM и может сдохнуть в любой момент (с потерей метаданных в этом случае – а это хуже, чем, когда система их просто не может записать). При возвращении буду думать, как избавиться от флешки другими путями (менять и\или добавить диск в сервер уже нельзя). По этому поводу, товарищи, так же хотел бы услышать объективные комментарии.
Комментарии (33)
a_shats
09.10.2017 18:08Родной аппаратный RAID для этого сервера (SA P411) б/у — 10-12К рублей на развалах (avito, ebay и иже с ними). Это точно стоило последующего геморроя?
lvm, насколько я знаю, прекрасно прожует и подключенные по iscsi диски (сам пробовал только ради экспериментов, не в продакшне под нагрузкой, разумеется).
vasyakrg Автор
09.10.2017 18:20iscsi диски — возможно. попробую на досуге. но в любом случае, не вариант расширять на них раздел с метаданными. разве что емкость (но с ней то проблем не было).
по аппаратному — да, можно купить. но 12-14к — это треть стоимости этого сервера. уже не рентабельно.
past
09.10.2017 22:14+1Если есть возможность подключить внешнее хранилище, определите его как новое и смигрируйте на него диски виртуалки, в онлайне.
vasyakrg Автор
10.10.2017 11:02смигрирую. а как потом быть с самим разделом LVM?
как я это вижу — развалить пустую группу и пересобрать снова.
только при сборке сначала создать раздел с метаданными и руками задать ему размер в 5 гигов например, а потом все оставшееся место 100%FREE?
ну и переехать виртуалками обратно.
past
09.10.2017 22:12Прекрасно на прод кластера у меня 5 лет работало. Один из рекомендованных проксмоксом вариантов. LVM in iSCSI
a_shats
10.10.2017 10:29+1Тут немного другая ситуация — когда блочным устройством по iSCSI предполагается нарастить lvm, уже собранный на локальных дисках. Немного бредовато получается, оттого и опасения — но в рамках сервера без полной замены хардов расти некуда.
Да и харды особо не наменять — сервер весьма не новый, и если с >2TB дисками еще проблема как-то решается, то вот гарантированно совместимые харды (Seagate Constellation ES всех серий, HGST A7K2000 серии и пр. подобные) найти будет уже не просто, а современные очень не всегда в старье заводятся (разумеется, речь даже не о дисках с 4К блоком, а о 512e/512n).
SergeyD
10.10.2017 21:42Может попробовать по этой доке — https://www.systutorials.com/docs/linux/man/7-lvmthin/ — увеличить место под metadata-pool?
Если в volume group место еще есть, конечно.
Конкретные инструкции в разделе "Metadata space exhaustion".vasyakrg Автор
11.10.2017 02:53Места нет. Одной командой в этой статье можно увеличить размер меты. Причем ирония в том, что хватило бы и 500мб
SergeyD
11.10.2017 03:05Тогда разве что забекапить ВМ по одной. Удалить вместе с LV. И разбекапить обратно.
vasyakrg Автор
11.10.2017 04:33все верно. только есть несколько НО.
1) удалить диски виртуалок не получится. потому как, даже процедура удаления требует изменения меты, у которой нет места.
2) забекапить надо куда то. выше ребята в комментах подсказали отличную идею с цеплянием по сети репозитория и переноса дисков туда. идея отличная (в моем случае репы не было и пришлось бы все равно нести в ДЦ USB-диск большой).
gluko
11.10.2017 00:12Нафиг этот LVM нужен, когда Proxmox из коробки умеет отлично работать с ZFS?
SergeyD
11.10.2017 02:09Возможно потому, что ZoL из коробки всё ещё не умеет отлично работать.
gluko
11.10.2017 09:12Zol отлично работает из коробки. Не хватает только поддержки trim для SSD, но это скорее из-за из параноидально безопасного подхода разработчиков к сохранности данных. Многие производители SSD реализуют trim настолько плохо, что были неоднократные случаи потери данных на EXT4 и других фс. Погуглите.
SergeyD
11.10.2017 15:24К сожалению не всё так радужно.
При высокой I/O нагрузке на zfs, даже только на чтение, система начинает залипаться и тупить.
Конкретно Proxmox 5.0 + последний ZoL 0.6.5.11 при работе бекапов.
И это не рабочий сервер под нагрузкой, а тестовый.
Диски правда не SSD.
Если использовать хранилище на LVM / Dir + (ext|x)FS — таких диких лагов не наблюдается.
gluko
11.10.2017 16:09+1Если у вас не контейнеры, а виртуальные машины, то диски хранятся на zfs volume (zvol), а для них Proxmox делает по умолчанию размер блока 8кб. Попробуйте использовать больший размер блока (128кб, как в датасетах). Так же могут наблюдаться проблемы с IO из за swap раздела на zfs volume. Попробуйте отмонтировать swap, если проблемы с IO исчезнут, используйте другую FS для SWAP или настройте оптимальный размер блока.
Вообще имея zfs можно вместо бэкапов делать реплики на уровне файловой системы. Это вообще не нагружает систему, т.к. Zfs не нужно сравнивать файлы и совершать какую либо работу, что бы получить разницу между 2 снимками.gluko
11.10.2017 16:15Так же для swap нужно выставить logbias=throughput, это серьезно уменьшит накладные расходы.
SergeyD
11.10.2017 16:20- используем контейнеры, данные — в датасетах
- recordsize = 32k
- без дедупликации
- включено сжатие lz4
- arc_max_size = 4G
- logbias оставлен на latency, на throughput еще хуже лагает
- swap на отдельном разделе, не на zfs. да и почти не используется.
vasyakrg Автор
11.10.2017 02:54Ну хотя бы потому, что на сервере всего 10мб ОЗУ
gluko
11.10.2017 09:09Память не проблема. ARC кэш можно ограничить или отключить через файл
/etc/modprobe.d/zfs.conf
options zfs zfs_arc_max=8299967296 # (по умолчанию 50% от общего объема памяти)
# arc_sys_free — количество памяти которое нужно оставлять свободным. По умолчанию 1\64 от общего объема :)
options zfs zfs_arc_sys_free=6442450944 # (оставлять 6 гб свободной памяти)gluko
11.10.2017 09:14#To apply this change immediately without a reboot, issue the command:
echo 8299967296 >> /sys/module/zfs/parameters/zfs_arc_max
echo 6442450943 >> /sys/module/zfs/parameters/zfs_arc_sys_free
battlemixerpilot
11.10.2017 04:30По-моему скромному опыту, ZFS не всегда хорошее решение. Имел проблемы с зависаниями виртуалок крутящих MSSQL. В основном это касается слабых дисковых подсистем, там ext4+LVM вполне стабильное и рабочее решение. Плюс ZFS надо памятью кормить
loktionovam
13.10.2017 08:00У меня используется PVE+LXC+LVM thin и есть пара моментов
- Нужно использовать trim
описано в разделе Using fstrim to increase free space in a thin pool LV При этом уменьшается использование не только Data, но Меtadataman lvmthin
- Обязательно использовать мониторинг lvm thin томов, например, через zabbix
battlemixerpilot
13.10.2017 13:54По второму пункту есть иные способы загонять данные в zabbix помимо парсинга вывода
и UserParameter в конфиге zabbix?lvs -a
Я мониторинг lvm пока только так себе вижу
- Нужно использовать trim
a_shats
Ну, в DL120 G6 нельзя просто взять и установить еще один диск к четырем имеющимся LFF.
Хотя внешний-то можно — например, подключить USB HDD/SSD, или хранилище какое по iSCSI или NFS.
Второй момент — я и в первой статье не увидел, в чем была причина и необходимость перехода с ESXi на Proxmox/Debian?
vasyakrg Автор
Верно — мы и добавили флешку на 8 гигов.
Не представляю как диск с метаданными расширить на сетевом хранилище… во-первых, lvm нужны физические диски, а во-вторых, при потере связи метаданные повредили бы и сами диски с виртуалками.
Переход был вызван тем, что Esxi не видит программный raid. А на дебиан был поднят и soft-raid и lvm
Shaz
Зато esxi прекрасно работает и с nfs и с iscsi, что могло решить проблему.
past
Так и проксмокс тоже!