В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

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

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

KVM (PVE/oVirt etc)

739 membersпожаловаться на группу
2020 July 22

NS

Nik Sh in KVM (PVE/oVirt etc)
Aleksandr
Nik Sh ну жизнь часто многообразнее. У вас есть например сценарий, что делать если процесс ресайза не завершился успешно а отвалился на середине?
да, откатываемся на только что сделаннй бэкап блочный перед ресайзом. Ресайз опасно, да, но иногда необходимо.
источник
18:00пожаловаться#1

A

Aleksandr in KVM (PVE/oVirt etc)
Nik Sh
да, откатываемся на только что сделаннй бэкап блочный перед ресайзом. Ресайз опасно, да, но иногда необходимо.
это не путь настоящего джедая
источник
18:01пожаловаться#2

A

Aleksandr in KVM (PVE/oVirt etc)
сила должна подсказать тебе какой байтик вправить на место, не перекачивая 100500тб из бекапа
источник
18:01пожаловаться#3

NP

Nick Potemkin in KVM (PVE/oVirt etc)
а если он не вправится?
источник
18:02пожаловаться#4

NS

Nik Sh in KVM (PVE/oVirt etc)
Aleksandr
это не путь настоящего джедая
странная логика. блин, у меня например иногда комп рабочий не с первого раза включается и что? не включать его вообще?
источник
18:02пожаловаться#5

A

Aleksandr in KVM (PVE/oVirt etc)
Nik Sh
да, откатываемся на только что сделаннй бэкап блочный перед ресайзом. Ресайз опасно, да, но иногда необходимо.
чаще всего это "необходимо" можно сделать описанным мной способом - копия на новое место, и wipe старого
источник
18:02пожаловаться#6

A

Aleksandr in KVM (PVE/oVirt etc)
стоит избегать маневров , при неудачном заверешении которых не предусмотрено отката
источник
18:02пожаловаться#7

NS

Nik Sh in KVM (PVE/oVirt etc)
Aleksandr
чаще всего это "необходимо" можно сделать описанным мной способом - копия на новое место, и wipe старого
дольше, куча дисковых операций. ресайз виртуалки занимает около минуты. еще минута на выключение и старт.
источник
18:03пожаловаться#8

NP

Nick Potemkin in KVM (PVE/oVirt etc)
а выключать зачем? )
источник
18:03пожаловаться#9

NS

Nik Sh in KVM (PVE/oVirt etc)
Nick Potemkin
а выключать зачем? )
хммм, действительно...
источник
18:04пожаловаться#10

A

Aleksandr in KVM (PVE/oVirt etc)
Nik Sh
дольше, куча дисковых операций. ресайз виртуалки занимает около минуты. еще минута на выключение и старт.
операции это плата за безопасность. а заодно и лишняя проверка что оно живо.  прерывать работу для этого в большинстве кейсов не нужно, просто сменить точку монтирования по окончанию - это доли секунды
источник
18:04пожаловаться#11

NS

Nik Sh in KVM (PVE/oVirt etc)
Nik Sh
дольше, куча дисковых операций. ресайз виртуалки занимает около минуты. еще минута на выключение и старт.
еще один раз был кейс, разрабы обновляли таблицу и кончилось место, совсем. БД встала в лок, убить БД - гарантированно получить фарш из innodb. Подцепили диск наживую, добавили его в  VG, расширили LV, расширили раздел. Все ожило. Потом через ночные работы уже расширили основной диск и удалили лишний pv из vg.
источник
18:07пожаловаться#12

i

ivdok in KVM (PVE/oVirt etc)
Nik Sh
еще один раз был кейс, разрабы обновляли таблицу и кончилось место, совсем. БД встала в лок, убить БД - гарантированно получить фарш из innodb. Подцепили диск наживую, добавили его в  VG, расширили LV, расширили раздел. Все ожило. Потом через ночные работы уже расширили основной диск и удалили лишний pv из vg.
По времени долго релоцировало экстенты?
источник
18:08пожаловаться#13

A

Aleksandr in KVM (PVE/oVirt etc)
Nik Sh
еще один раз был кейс, разрабы обновляли таблицу и кончилось место, совсем. БД встала в лок, убить БД - гарантированно получить фарш из innodb. Подцепили диск наживую, добавили его в  VG, расширили LV, расширили раздел. Все ожило. Потом через ночные работы уже расширили основной диск и удалили лишний pv из vg.
я про эту  историю на хабре читал.   там был тонкий лвм и вставленный диск типа 2гб флешка
источник
18:09пожаловаться#14

NS

Nik Sh in KVM (PVE/oVirt etc)
ivdok
По времени долго релоцировало экстенты?
неа, там 20 гб всего добавили, на ссд быстро отработало.
источник
18:09пожаловаться#15

NP

Nick Potemkin in KVM (PVE/oVirt etc)
точка монтирования - это данные, которые там лежат и с которыми работает какой-то сервис
в вашем случае - это куча телодвижений, которые без остановки сервиса не получится сделать...
а если это сервис 24х7 и на нем БД? у нас два варианта - либо расширить диск на котором оно лежит и live resize fs, либо докинуть большой диск, сделать pvmove и все-равно потом делать live resize...
источник
18:09пожаловаться#16

i

ivdok in KVM (PVE/oVirt etc)
Nik Sh
неа, там 20 гб всего добавили, на ссд быстро отработало.
Для теста делал два диска по тб, затем расширил основной до двух и релоцировал. Заняло где-то час, несмотря на то, что данных почти не было.
источник
18:10пожаловаться#17

A

Aleksandr in KVM (PVE/oVirt etc)
Nick Potemkin
точка монтирования - это данные, которые там лежат и с которыми работает какой-то сервис
в вашем случае - это куча телодвижений, которые без остановки сервиса не получится сделать...
а если это сервис 24х7 и на нем БД? у нас два варианта - либо расширить диск на котором оно лежит и live resize fs, либо докинуть большой диск, сделать pvmove и все-равно потом делать live resize...
ну если это прям такой большой сервис который затруднительно остановить на несколько секунд, то он наверное и весь из себя кластерный и можно один из узлов кластера вывести на обслуживание
источник
18:10пожаловаться#18

NS

Nik Sh in KVM (PVE/oVirt etc)
Aleksandr
я про эту  историю на хабре читал.   там был тонкий лвм и вставленный диск типа 2гб флешка
не, это не про нас, мы не пишем туда, в нашем случае это обычный гипервизор KVM, там всегда есть резерв места для бэкапа снапшотами, тонкий LVM не используем, ибо в нашем случае от него одни минусы.
источник
18:11пожаловаться#19

A

Aleksandr in KVM (PVE/oVirt etc)
Nik Sh
не, это не про нас, мы не пишем туда, в нашем случае это обычный гипервизор KVM, там всегда есть резерв места для бэкапа снапшотами, тонкий LVM не используем, ибо в нашем случае от него одни минусы.
у тебя ребят из статьи раком встал именно тонкий lvm , овесейлинг случился.  и весь куст раскорячило
источник
18:12пожаловаться#20