При этом решение не одностороннее. LVM тем и хорош, что если /srv однажды начнёт нести реальные данные сервиса и его действительно понадобится вынести — это делается pvmove на живой системе, без простоя и без переливки.
Мне не нужно было пристегивать новый диск. А добавить сайза в системный. Это просто мой кейс. Да и я просто его описал. Имеет место быть и такая вариация.
Можно и дисками, но их число ограничено (15 на контроллер), и каждый — отдельный объект в fstab, бэкапе, inventory ВМ. 12 томов = 12 дисков, которые не перепутать.
По скорости ресайза они равны: там growpart+ресайз, тут pvresize+lvextend. Разница не в этом, а в том, что LVM умеет перекинуть место с тома на том без железа и растянуть том поверх нескольких дисков. На схеме «диск=ФС» место обратно не заберёшь.
Статичная разметка раз в год — можно дисками. А где место между разделами гуляет постоянно (БД, логи) — LVM просто удобнее в эксплуатации.
Если на ВМ один диск и одна ФС на всё — да, LVM там ни к чему. Но так почти никогда: на нормальной разметке томов несколько, и вот тут он и выручает — каждый ресайз быстрее и без плясок с разделами. 30Тб просто нагляднее всего, а по факту он отбивается на любом рядовом расширении.
Про /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 тем и хорош, что если /srv однажды начнёт нести реальные данные сервиса и его действительно понадобится вынести — это делается pvmove на живой системе, без простоя и без переливки.
Но твой подход абсолютно правильный
Мне не нужно было пристегивать новый диск.
А добавить сайза в системный.
Это просто мой кейс.
Да и я просто его описал.
Имеет место быть и такая вариация.
Можно и дисками, но их число ограничено (15 на контроллер), и каждый — отдельный объект в fstab, бэкапе, inventory ВМ. 12 томов = 12 дисков, которые не перепутать.
По скорости ресайза они равны: там
growpart+ресайз, тутpvresize+lvextend. Разница не в этом, а в том, что LVM умеет перекинуть место с тома на том без железа и растянуть том поверх нескольких дисков. На схеме «диск=ФС» место обратно не заберёшь.Статичная разметка раз в год — можно дисками. А где место между разделами гуляет постоянно (БД, логи) — LVM просто удобнее в эксплуатации.
Если на ВМ один диск и одна ФС на всё — да, LVM там ни к чему. Но так почти никогда: на нормальной разметке томов несколько, и вот тут он и выручает — каждый ресайз быстрее и без плясок с разделами. 30Тб просто нагляднее всего, а по факту он отбивается на любом рядовом расширении.
Про /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'у согласен на все сто, триггеры нужны, и лучше предиктивные по тренду, а не голый порог.
Но одно другое не заменяет: мониторинг не знает, сколько сожрёт конкретная транзакция, а плейбук не видит тренда между патчингами.