Чи слід використовувати розділи LVM у зображеннях віртуальної машини?

Чи слід використовувати LVM для розділів під час створення зображень VM (наприклад, зображень KVM)? Схоже, це додає складності, якщо ви хочете, скажімо, змонтувати зображення qcow2 в хості, якщо зображення має розділи LVM.

З іншого боку, схоже, що переваги LVM-розділів настільки важливі для зображення VM, оскільки набагато простіше зняти VM в автономному режимі та змінити розміри розділів, ніж це стосується фізичної системи.

"Це залежить."

Якщо ви перебуваєте в середовищі, яким ви керуєте (vmware або kvm чи будь-яке інше), і ви можете приймати власні рішення щодо продуктивності QoS на диску, тоді я рекомендую не використовувати LVM у своїх віртуальних машинах. Це не дає вам великої гнучкості, якої ви не змогли б отримати на рівні гіпервізора.

Пам’ятайте, гіпервізор вже ефективно виконує ці завдання. Якщо ви хочете мати можливість довільно змінити розмір файлових систем (чудова ідея), просто створіть окремий віртуальний диск для кожної файлової системи.

Одне, про що можна подумати, коли йдеш цією дорогою. Вам навіть не обов’язково таким чином ставити розділи на свої віртуальні диски. Наприклад, ви можете створити віртуальний диск для /home; це /dev/vdcвсередині вашого vm. Створюючи файлову систему, просто зробіть щось на зразок mke2fs -j /dev/vdcзамість вказування розділу.

Це гарна ідея, але ... більшість інструментів (та інших адміністраторів, які йдуть за вами) очікують побачити розділи на кожному диску. Я рекомендую просто поставити один диск на диск і зробити це з ним. Однак це означає ще один крок при зміні розміру файлової системи. І не забудьте правильно вирівняти свої розділи - запуск першого розділу в 1 Мб є хорошим правилом.

Все, що було сказано - Виконання цього на рівні гіпервізора означає, що вам, ймовірно, доведеться перезавантажити VM, щоб змінити розмір розділів. Використання LVM дозволить вам додати віртуальний диск (припускаючи, що комбінація гіпервізора / ОС дозволяє це) та розширити файлову систему без перезавантаження. Це, безумовно, плюс.

Тим часом, якщо ви використовуєте хмарного провайдера, це більш тонко.

Я мало знаю про Azure, GCP або будь-який з менших плеєрів, тому не можу там допомогти.

З AWS ви можете слідувати моїм порадам вище, і ви часто будете просто добре. Ви можете (зараз) збільшувати розмір томів EBS (віртуальних дисків) на ходу та змінювати розміри розділів тощо.

Однак у загальному випадку може бути доцільним розмістити все на одному великому обсязі EBS та використовувати LVM (або, я думаю, звичайні розділи). Amazon дає обмеження IOPS на кожен том. За замовчуванням ця межа масштабується з розміром гучності. наприклад, за gp2обсяги ви отримуєте 3 IOPS на ГіБ (мінімум 100 IOPS). Дивіться https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html

Для більшості навантажень ви хочете, щоб усі ваші наявні IOPS були доступні для будь-якої файлової системи, залежно від потреби на даний момент. Тому є сенс зробити один великий об'єм EBS, зібрати всі свої IOPS в одне відро і розділити / LVM.

Приклад:

3 диски з незалежними файловими системами / областями для обміну, розміром 100 Гб. Кожен отримує 300 IOPS. Продуктивність обмежена 300 IOPS на кожному диску.

1 диск, розміром 300 Гб. Розділи LVM на диску 100 Гб кожен. Диск отримує 900 IOPS. Будь-який з розділів може використовувати всі 900 IOPS.

Логічні томи легше створювати під час руху, змінювати розмір, видаляти.
На запитання "до LVM чи ні" завжди є однакова відповідь, це залежить :)
Це має сенс, якщо вам потрібна гнучкість на рівні диска (ив), розділів (и).
Це не має особливого сенсу, якщо вам не потрібна гнучкість, надана LVM, або ви не хочете скористатися іншими можливостями LVM

Мені дуже подобається використовувати LV, тому що вони не легко доступні через virt-сервер. Таким чином, ці файли не можуть бути легко знищені / переміщені випадково.

Інші важливі особливості ЛШ:

• Можна робити знімки
• Ви можете аналізувати IO диска на основі LV ( iostat)
• Легко змінити розмір
• За допомогою знімків ви можете зробити послідовний клон працюючих систем

Для зменшення складності я використовую LV як диск (а не як розділ). Недолік полягає в тому, що я можу легко змінити розмір останнього розділу "диска", але мій стандартний VM-диск-макет враховує це (тому останній розділ містить важливі дані програми).

Крім гнучкості, VM-зображення на основі LVM мають потенційно менші накладні витрати, оскільки до них не можна отримати доступ через файлову систему. З іншого боку, це забирає засоби для легкого переміщення зображень, як це робиться з файлом. Не неможливо, але трохи складніше

Мій власний досвід….

Я хотів використати логічний том (lv) з lvm2 для файлової системи ext4; не як диск, а точніше, просто як нерозподілений сирий диск для fs.

Я виявив, що запуск ВМ буде зупинений на початковому етапі; якби я прокоментував /etc/fstabзапис, машина завантажиться. Залишити коментар до /etc/fstabвступу не було рішенням, з яким я радий жити. Отже, я створив звичайний образ диска (все ще логічний том), розділив його одним розділом, використовуючи fdiskта створивши на цьому файлову систему. Більше жодних питань.

Відповідні кріплення в моєму /etc/fstabвикористовували UUID.

Я думав про використання файлу чи файлової системи, але вирішив проти цього.

У моєму випадку я використовую систему Devuan на базі Debian Jessie

Я фактично використовую LVM лише для зберігання резервних копій на рівні гіпервізора, файли зображень - для птахів. Я також рекомендую використовувати їх також на рівні гостей. Це правда, що ви не отримаєте користі від об'єднання різних джерел пам’яті або легше збільшити загальний доступний дисковий простір (оскільки ви можете отримати це так само просто, змінивши розмір того, що представляє гіпервізор), але колись ви виділяєте занадто багато для однієї файлової системи . Можливо, вам сподобається простий спосіб взяти 1 концерт з / opt і подати на / var (наприклад). Якщо ви робите регулярні розділи всередині самого віртуального комп'ютера, тоді це змінює розмір просто набагато складніше.

На додаток до інших хороших відповідей тут, єдиний справді хороший привід використовувати LVM всередині VM - це те, що ви хочете, щоб тестове середовище експериментувало і отримувало практичний практичний досвід роботи з LVM.

Ви можете пройти різні HOWTO та підручники, практикувати загальні (і не дуже поширені) функції адміністрування LVM, налаштувати різні сценарії відмов та навчитися боротися з ними.

тобто як допомога самонавчання.

Редагувати: Нижче це більше не відповідає дійсності. Значення використання тонкого забезпечення, передбаченого LVM, для зображень диска VM, ймовірно, ситуаційне;

Ви використовуєте програмне забезпечення VM на ноутбуці? то вам, мабуть, краще з QCow2.

Керуючи фермою віртуальних машин, яка, можливо, може використовувати величезну кількість пам’яті на декількох дисках? LVM, ймовірно, хороший спосіб керувати цим сховищем.

Однією з причин не використовувати lvm є те, що ви не можете перезапустити сховище за допомогою lvm. Якщо ви створюєте 10 ВМ зі 100 ГБ пам’яті, вам потрібно 1000 ГБ фактичного диска, навіть якщо 9 з десяти ВМ використовуватимуть лише 20 ГБ їх файлових систем. Рідкі зображення диска або зображення формату qcow2 можуть означати, що їм потрібно виділити лише сховище, яке фактично використовується гостями.

Чи справді це вам корисно, залежить від того, що вам потрібно для зберігання.