LVM поверх RAID - Наш Блогосайт Linux та «лірика»

Здавалося б, навіщо може знадобитися поєднання LVM та RAID? Адже обидві ці системи багато в чому дублюють один одного, дозволяючи об'єднувати диски та їх розділи в єдині логічні томи, забезпечувати розшарування даних між ними (так званий стрипінг) для збільшення швидкодії або, навпаки, дзеркалювання для підвищення надійності. Однак все виявляється не так просто.

Уявімо ситуацію, що є три накопичувачі (в даному випадку SSD, але щодо HDD сказане нижче ще суттєвіше) - один об'ємом на півтерабайта, і два однакових - по 120 ГБ. І є природне бажання об'єднати їх у логічно єдиний простір, причому бажано з виграшем у продуктивності за рахунок стрипінгу (як я неодноразово говорив, дзеркалювання в побутових умовах вважаю невиправданим). Причому з деяких причин найпростіший і найкращий спосіб це зробити (тобто через пул ZFS) не підходить - знову ж таки з причин, про які раніше йшлося багато разів.

Саме таку ситуацію було колись описано — і завдання було вирішено тоді «в лоб», тобто не оптимальним чином: просто об'єднанням у групу томів великого розділу на великому носії та обох «маленьких» цілком. Спочатку - зі створенням логічних томів у режимі стрипінгу. Однак очевидно, що розшаровувати дані можна лише на потрійний об'єм найменшого носія. І в результаті «ліміт на стрипінг» був досить швидко вичерпаний — інші логічні томи, що лежать за межами 120 ГБ, можна було створювати лише в лінійному режимі.

Ось тут і можна згадати про те, що в групу томів LVM можуть об'єднуватися не тільки дискові розділи, а й уже мультидискові системи, тобто RAID різного рівня. Хоча в рамках поставленого завдання, повторюю, має сенсговорити тільки про масиви Level 0. І тому наступного разу в тій самій ситуації я про це згадав. А саме — знайшов права root'а на довгі часи:

Потім обнулив розмітку на обох менших носіях:

Розмітив за допомогою cfdisk кожен із них на один розділ з ідентифікатором типу файлової системи fd (Linux raid autodetect). Так, оскільки справа відбувалася в Linux Mint (конкретно в реліз-кандидатній 17.2 Rafaela), не забув встановити потрібний пакет:

У цьому дистрибутиві, як відомо, за замовчуванням він відсутній. Після цього можна було зайнятися створенням масиву нульового рівня:

Щоправда, у наведеному рівнянні значення імені пристрою /dev/md0 умовно — як це зазвичай серед Ubuntu'єва племені, після перезавантаження воно чарівним чином перетворюється на /dev/md127 , і навіть опція --auto=yes , нібито спеціально призначена для запобігання цього явища не допомагає (в причини вдаватися тут не буду).

Однак у разі це було принципово і не страшно. Набагато цікавіше виявилося те, що графічна утиліта, що описувалася раніше, system-config-lvm в упор не бачить RAID'а ні як /dev/md0 , ні як /dev/md127 , ні до розмітки його в якості єдиного розділу, ні після неї (і надання йому Id 8e, Linux LVM VG Size - воно дорівнює сумі обсягів розділу великого диска і RAID'а, а подвійний обсяг останнього якраз і лімітує максимальний обсяг логічних томів з чергуванням, який, як неважко підрахувати, становитиме близько 480 МБ проти 360 МБ, яким він був при об'єднанні трьох окремих фізичних томів.

Одночасно з цим виникає каталог /dev/data , поки що порожній: його вмістом будуть файли пристроїв логічних томів, які зараз і потрібно створити. І ось це — заняття значно більшемоторне, що вимагає знання опцій команди lvcreate, численних і не очевидних, особливо при використанні чергування. Благодитися в їх пошуках немає необхідності - утворена командою vgcreate група томів буде чудово видно утилітою system-config-lvm. І створення всередині неї логічних томів з файловими системами та точками їх монтування - справа нескладної техніки, яка докладно описана раніше:

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