Linux на VMware - навіщо використовувати розділення?

Встановлюючи Linux VM у віртуалізованому середовищі (в моєму випадку ESXi), чи існують якісь вагомі причини для розділення дисків (при використанні ext4), а не просто додавання окремих дисків для кожної точки монтування?

Єдине, що я бачу, це те, що це дещо простіше зрозуміти, чи є на диску дані, наприклад, fdisk.

З іншого боку, я можу побачити деякі вагомі причини не використовувати розділи (очевидно для інших, ніж / boot).

• Набагато простіше розширити диски. Це просто збільшити розмір диска для VM (як правило, в VCenter), потім перевстановити пристрій у VM та змінити розмір файлової системи в Інтернеті.
• Більше не виникає проблем з вирівнюванням розділів з базовими LUN.

Я не знайшов багато з цієї теми навколо. Я пропустив щось важливе?

Це цікаве питання ...

Я не думаю, що є однозначної відповіді, але я можу дати певний історичний контекст про те, як найкращі практики щодо цієї теми могли змінитися з часом.

Мені довелося підтримувати тисячі віртуальних машин Linux, розгорнутих у різних формах у середовищах VMware з 2007 року. Мій підхід до розгортання розвинувся, і я мав унікальний ( іноді невдалий ) досвід успадкування та рефакторингу, побудований іншими інженерами.

Старі часи ...

Ще в той день (2007) мої ранні системи VMware були розділені так само, як і мої системи з голого металу. Що стосується VMware, я використовував розділені файли товщиною 2 Гб, щоб містити дані VM, і навіть не думав про поняття декількох VMDK, тому що я був щасливий, що віртуалізація може навіть працювати!

Віртуальна інфраструктура ...

За версією ESX 3.5 та ранніми випусками ESX / ESXi 4.x (2009-2011 рр.) Я використовував Linux, розміщений як звичайний монолітний товстий файл VMDK. Необхідність попереднього розподілу пам’яті змусила мене думати про дизайн Linux таким же чином, як і для справжнього обладнання. Я створював VMDK для 36 ГБ, 72 ГБ, 146 ГБ для операційної системи, розділяючи звичайний /, / завантажувальний, / usr, / var, / tmp, потім додав ще один VMDK для розділу "дані" або "зростання" (будь то / home, / opt або щось, що стосується програми). Знову ж таки, приємне місце у фізичних розмірах жорсткого диска в цю епоху становило 146 Гб, і оскільки попереднє розміщення було обов'язковою умовою (якщо не використовувати NFS), мені потрібно було бути консервативним з простором.

Поява тонкого резервування

У наступних випусках ESXi 4.x VMware розробив кращі функції щодо забезпечення тонкого забезпечення , і це змінило те, як я почав встановлювати нові системи. Додавши повний набір функцій у 5.0 / 5.1, новий тип гнучкості дозволив досягти більш креативних дизайнів. Зауважте, це йшло в ногу з розширеними можливостями на віртуальних машинах, з точки зору кількості vCPUS та скільки оперативної пам’яті, що може бути надано окремим віртуальним машинам. Більше типів серверів і додатків можна віртуалізувати, ніж раніше. Це правильно, оскільки обчислювальне середовище починало виходити абсолютно віртуальним.

LVM жахливий ...

На той час, коли повноцінна функція гарячих додавань на рівні VM була створена і загальна (2011-2012 рр.), Я працював з фірмою, яка прагнула будь-якою ціною підтримувати робочий час для VM клієнтів ( нерозумно ). Таким чином, це включає в себе онлайн-процесор / оперативну пам’ять VMware та ризикований розмір диска LVM на існуючих VMDK. Більшість систем Linux у цьому середовищі мали поодинокі установки VMDK з розділами ext3 поверх LVM. Це було жахливо, оскільки шар LVM додав складності та зайвого ризику для операцій. Наприклад, не вистачає місця в / usr, наприклад, може призвести до неправильних рішень, що врешті-решт означало відновлення системи з резервних копій ... Це частково стосувалося процесу та культури, але все ж ...

Снобізм розділів ...

Я скористався можливістю спробувати це змінити. Я трохи сноб-розділ в Linux і вважаю, що файлові системи повинні бути розділені для моніторингу та експлуатаційних потреб. Мені також не подобається LVM, особливо з VMware та можливістю робити те, що ви просите. Тому я розширив додавання файлів VMDK до розділів, які можуть потенційно зростати. / opt, / var, / home при необхідності можуть отримати власні файли віртуальної машини. І це були б сирі диски. Іноді це був простіший метод розширення конкретного низькорозмірного розділу на льоту.

Obamacare ...

Завдяки вбудованому дуже високопрофільному клієнтові я отримав завдання розробити довідковий шаблон Linux VM, який би використовувався для створення їх надзвичайно видимого середовища застосування. Вимоги до безпеки програми вимагають унікального набору кріплень , тому працювали з розробниками, щоб спробувати нав'язати розділи, що не ростуть, на один VMDK, а потім додати окремі VMDK для кожного монтажу, який мав потенціал зростання або мав конкретні вимоги (шифрування, аудит і т. д.) Отже, зрештою, ці відеомагнітофони складалися з 5 і більше VMDK, але забезпечували найкращу гнучкість для подальшого зміни розміру та захисту даних.

Що я сьогодні роблю ...

Сьогодні мій загальний дизайн для Linux та традиційних файлових систем - це ОС на одному тонкому VMDK (розділений) та дискретні VMDK для будь-чого іншого. Я гаряче додаю по мірі необхідності. Для просунутих файлових систем, таких як ZFS, це одна VMDK для ОС, а інша VMDK, яка виконує функцію zpool ZFS і може змінювати розміри, вирізати у додаткові файлові системи ZFS тощо.

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

Редагування - о, і це зробить оснащення трохи повільніше, але це, можливо, не буде проблемою.

Коли я працював в інфраструктурі конкретної «великої компанії з програмного забезпечення для віртуалізації», нам часто потрібно було збільшувати розмір файлової системи vm. У той час ми використовували ext3 / 4.

Збільшити віртуальний диск дуже просто, підбирати новий розмір пристрою в реальній операційній системі порівняно просто (простувати в / sys), змінити розмір файлової системи ext3 / 4 було просто, але те, що завжди здавалося неможливим (зробити це в реальному часі), було зміни розміру розділу.

Вам довелося використовувати gparted або переписати / змінити розмір таблиці розділів за допомогою fdisk - але вона завжди була заблокована ядром і вимагала перезавантаження, щоб ядро ​​отримало новий макет (partprobe теж не робив цього.)

Я перемістив багато систем до LVM, і розмір файлових систем став легким, майже приємним досвідом!

• Збільште зображення віртуального диска поза VM
• У В.М.
  • Poke / sys для перегляду метрики диска (відлуння "1"> / sys / class / scsi_device // пристрій / rescan)
  • pvresize / dev / sdX (змінити фізичний об'єм у LVM)
  • lvresize --extents + 100% БЕЗКОШТОВНО / dev / VG / lvolXX (зміни розміру логічного обсягу в LVM)
  • resize2fs (зміни розміру файлової системи)

Все це можна зробити безпечно за допомогою живої системи - і не потрібно перезавантажувати!

Чому б не голий диск? Мене це нервує - я не відчуваю, що голі диски ще досить широко прийняті, але я думаю, що ми на порозі набагато ширшого сприйняття. У списку розсилки btrfs була пов’язана нитка, пов’язана з цим:

http://www.spinics.net/lists/linux-btrfs/msg24730.html

Але голому диску просто знадобиться rescan і resize2fs.

Отже, підсумовуючи, так, уникайте таблиць розділів, якщо можете.

Хоча ваше запитання, яке було написано, стосується VMWare (ESXi), я хотів би додати ситуацію, коли я повернувся до використання таблиць розділів, маючи ту саму ідею щодо KVM.

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

Зрозуміло, це кутовий випадок, але варто подумати, якщо вам потрібна така установка.

Краще це робити чи ні, залежить від вашої системи.

Існують плюси і мінуси кожної установки.

Однак основними перевагами одного привода є:

1. Простота: Один привід має єдиний файл, який можна легко розподілити та тиражувати.
2. Вибір хост-операційної системи: Один файл буде розглядатися як єдиний блок даних, а значить, хост-ОС дізнається, що послідовності доступу до гостьової машини будуть у цьому одному файлі. Цього можна досягти в деяких конфігураціях хост-ОС, просто розмістивши всі образи диска в одному файлі, але це не обов'язково буде так.

Однак у багатоприводних є переваги.

1. Спорідненість з голим металом / ручне розташування: за допомогою одного диска ви замикаєтесь на одній спорідненості з накопичувачем.
2. Обмеження розміру: Якщо у вашій системі є обмеження щодо розміру накопичувача або файлів, ви можете вдарити їх у дуже великих системах.
3. Томи лише для читання для безпеки: це велика перевага. Якщо ваш основний обсяг для ОС читається лише на стороні VM, це забезпечує основні переваги безпеки, по суті, виключаючи можливість програм всередині VM від редагування базової ОС гостя. Використання окремого накопичувача даних дозволяє створювати диски лише для читання, які можна завантажувати для читання-запису для обслуговування та оновлень без лише даних шаблону чистого простору, що запобігає зміні життєво важливих каталогів ОС на сервері взагалі.

є ще один варіант: встановити дані програми на томи NFS. Вам потрібні хороші файли (не всі реалізації NFS однакові).

Коли обсяги NFS заповниться, розгорніть гучність, клієнт linux відразу побачить додатковий простір.

Ваша програма та постачальник повинні підтримувати свої дані про NFS, і вам потрібен ретельний дизайн NAS, але так ви робите з кожним рішенням для зберігання даних для вашого віртуалізованого середовища.

Ще один бонусний бал за цей підхід полягає в тому, що якщо ваш постачальник пам’яті має технологію знімків / клонування (наприклад, zfs чи Netapp), резервне копіювання даних та створення середовищ для тесту / розробника дуже просто.

Причина, чому вам все-таки потрібно зробити розділ диска для деяких дистрибутивів Linux, пов’язана з тим, що є завантажувач і всі застарілі фрагменти, що йдуть разом з ним, тобто емуляція BIOS. Це ускладнює зміну розміру диска, і багато хто може закінчитися використанням LVM або іншого подібного безглуздого.

Можна просто зробити файлову систему на всьому томі та встановити її /, яка буде працювати з дуже користувальницьким (або настроюваним / непомітним) дистрибутивом Linux. Востаннє, коли я спробував це з Ubuntu 12.04, інсталятор не знав, як з цим впоратися, оскільки він повинен встановити їх тупу таблицю розділів на весь джаз. Це одна з проблем розподілу загального призначення у віртуалізованому світі.

З іншого боку, можна фактично розмістити розділ на менш традиційне використання, наприклад, ChromeOS і CoreOS мають два кореневі розділи, доступні лише для читання, для оновлення системи.

Однією з причин, яка до цього часу не згадується, є те, що в деяких інфраструктурах, таких як Google Compute, продуктивність IO диска лінійно збільшується з розміром диска . Іншими словами, один великий розділений привід матиме кращі показники вводу-виводу, ніж декілька малих дисків.

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

На мій досвід кращим підходом є використання 1 VMDK для ОС, і я зазвичай розбиваю його наступним чином:

/dev/sda1 - /boot - 256M
/dev/sda2 - swap  - ~4GB
/dev/sda3 - /     - ~8GB

Я знайшов 8 ГБ, щоб вистачити для /, тому що я зазвичай встановлюю мінімальний дистрибутив Linux (~ 800 Мб) + програмне забезпечення, яке мені потрібно. Журнали також переходять до цього розділу, але якщо їх правильно налаштувати (логротировать протягом тижня) та відправити в інше місце (syslog / elastsearch), вони, як правило, не ставлять підряд для заповнення розділу.

Дані додаються як інший VMDK, і я зазвичай форматую файлову систему безпосередньо на голому диску (наприклад, / dev / sdb). Це дозволяє мені змінити розмір обсягу в VmWare і змінити його розмір безпосередньо в VM без необхідності перерозподілу / umount / перезавантаження.

Я розділяю з двох причин:

1. Документація - Колись мені "навчений" адміністратор ЕМС викрав LUN прямо з-під мене, тому що вони були недокументовані і здавалося, що він нерозподілений, а посеред ночі був підготовлений до бази даних Oracle, яка раптом перейшла в офлайн. Він переглянув мої LUN-адреси на інший том для непов’язаного додатка. Відтоді я параноїком щодо документації.
2. Надмірно забезпечений мій диск. За допомогою тарілок він зберігає дані про повільніші циліндри, а з SSD - це продовжує термін експлуатації / MTBF.