Comments 6
А где собственно сам ранбук для Ansible?
И ещё вопрос. Почему:
где‑то на третьем сервере оно падает, потому что в /var или /boot кончилось место.
если
Старые ядра удаляются через dnf repoquery --installed --installonly с явным исключением загруженного ядра.
Т.е. почему заканчивается место в /boot, если старые ядра удаляются?
Второй вопрос. Зачем расширять место автоматически в /var, если там, как правило, место съедают логи (/var/log) база данных (/var/lib). Может стоит лучше вручную посмотреть, что там за проблема? Если место скушала база, то +10 GB ей не особо помогут. Если место скушали логи, то может быть лучше настроить logrotate или посмотреть, что пишет слишком много логов, возможно, кто-то забыл отключить debug.
Также было бы неплохо использовать мониторинг, типа zabbix, чтобы проблемы с нехваткой места решать заранее, а не когда происходят внезапные работы с сервером.
Про /boot: ядра-то сносятся нормально, дело не в них.
dnf по дефолту держит три ядра (installonly_limit), и лишнее выкидывает только когда ставит новое. А ядро — это не только vmlinuz на 10 метров, к нему ещё initramfs 40–100 (в host-only и жирнее бывает) плюс kdump-образ такого же порядка, если kdump включён. Три ядра с kdump — уже под 700 метров, а /boot по дефолтной разметке 512М–1Г. Впритык изначально.
Плюс пик — ровно в середине транзакции: новое ядро распаковано, dracut initramfs собрал, а старое ещё лежит, оно уедет в конце. То есть в моменте там N+1 ядер, и оно падает именно тогда, а не «потом, когда почистится».
Плюс половина барахла в /boot вообще не принадлежит пакетам, поэтому repoquery его в упор не видит. Дёрни rpm -qf /boot/initramfs-*.img — на что-то скажет not owned by any package. initramfs же генерится скриптлетом уже после установки, в файлах пакета его нет. При штатном сносе ядра он подчищается, а если ядро выпиливали руками, транзакция когда-то отвалилась или машину клонировали — висит сиротой вечно. Плюс initramfs-0-rescue-*, который не удаляется никогда, и после смены machine-id их накапливается по несколько штук по 80 метров. du -sh /boot/* — и обычно сразу видно, что полраздела занято тем, чего в rpmdb нет.
А /var кончается по своей причине, к ядрам вообще отношения не имеет: dnf тянет всю транзакцию в /var/cache/dnf до начала установки, там же rpmdb и history.
Про расширение /var — оно не про логи. Это чтобы обновление не сдохло на середине транзакции с недописанным rpmdb, разгребать такое куда дороже, чем пара лишних гигов на LV. Если место скушала база или забытый debug — да, + память - это только отодвинет, но плейбук её и не должен лечить, его задача довести апдейт до конца и не оставить сервер в разобранном виде.
По zabbix'у согласен на все сто, триггеры нужны, и лучше предиктивные по тренду, а не голый порог.
Но одно другое не заменяет: мониторинг не знает, сколько сожрёт конкретная транзакция, а плейбук не видит тренда между патчингами.
Лично я не понимаю, зачем вообще на ВМках использовать LVM. Диски и ФС можно прозрачно увеличивать, а LVM - лишняя прокладка. Только один раз он действительно понадобился - когда потребовались разделы по 30 Тб.
Если на ВМ один диск и одна ФС на всё — да, LVM там ни к чему. Но так почти никогда: на нормальной разметке томов несколько, и вот тут он и выручает — каждый ресайз быстрее и без плясок с разделами. 30Тб просто нагляднее всего, а по факту он отбивается на любом рядовом расширении.
Что мешает создавать столько дисков, сколько нужно разделов и управлять ими независимо? Насколько быстрее изменять размер одного диска по сравнению с двумя-тремя? Я не могу придумать существенную причину использования лишней и совсем необязательной прокладки.
Можно и дисками, но их число ограничено (15 на контроллер), и каждый — отдельный объект в fstab, бэкапе, inventory ВМ. 12 томов = 12 дисков, которые не перепутать.
По скорости ресайза они равны: там growpart+ресайз, тут pvresize+lvextend. Разница не в этом, а в том, что LVM умеет перекинуть место с тома на том без железа и растянуть том поверх нескольких дисков. На схеме «диск=ФС» место обратно не заберёшь.
Статичная разметка раз в год — можно дисками. А где место между разделами гуляет постоянно (БД, логи) — LVM просто удобнее в эксплуатации.
Ansible против нехватки места: как я научил плейбук самостоятельно расширять диски виртуалок и патчить RedOS