B5. LVM і RAID

просунутийспирається на модуль 14

Мета

Модуль 14 стверджує, що RAID 5 на великих дисках ризикований: відновлення триває довго, весь цей час масив працює без запасу, а друга відмова знищує все. Тут ви зберете масив із дисків по 1 ГіБ, зламаєте його і виміряєте відновлення самі. Масштаб поміщається у ВМ, механіка та сама, що на 16 ТБ. Поверх масиву ви наріжете логічні томи і побачите знімок LVM як копіювання під час запису з модуля 12 на рівні блоків.

Після цієї роботи ви зможете:

• зібрати RAID 1 і RAID 5 через mdadm, прочитати /proc/mdstat і сказати, у якому стані масив і що він зараз робить;
• вивести диск із ладу, замінити його й довести контрольною сумою, що дані пережили відмову;
• заміряти час відновлення і порахувати, скільки він триватиме на дисках у 16 ТБ;
• розширити логічний том разом із файловою системою без розмонтування;
• пояснити, чому знімок спочатку не займає місця й від чого росте, і чому RAID не заміняє резервну копію.

Це робота того, хто відповідає за сервер із дисками: сповіщення про degraded-масив, заміна диска, оцінка, чи встигне масив відновитися до наступної відмови, і розмова після rm, яке дзеркало продублювало.

Завдання

Результат роботи — звіт із замірами: масив, який пережив відмову диска, час його відновлення, розрахунок для великих дисків і логічні томи зі знімком поверх нього.

Що зробити:

1. RAID 1 із двох дисків, файлова система, файл із відомою контрольною сумою. Відмова одного диска (mdadm --fail), перевірка, що дані читаються, заміна диска і синхронізація.
2. RAID 5 із трьох дисків, заповнений щонайменше наполовину. Відмова диска і замір часу повного відновлення за /proc/mdstat.
3. Друга відмова, поки триває відновлення: що сталося з масивом і даними.
4. LVM поверх /dev/md0: фізичний том, група томів, два логічні томи, один із них розширено на льоту разом із файловою системою.
5. Знімок логічного тому: зміна оригіналу, монтування знімка, старий стан у ньому, зростання зайнятості знімка.
6. Видалення файлу на справному масиві й перевірка, що надлишковість його не повернула.

Чого робити не треба. Завантаження з масиву і запис у /etc/mdadm/mdadm.conf не потрібні: усі етапи виконуються за один сеанс ВМ. RAID 6 і RAID 10 у роботу не входять. Системний диск ВМ у масив не включайте.

Обмеження. Програмний RAID через mdadm і томи через lvm2. btrfs із власним RAID лишається для розділу «Далі, якщо цікаво».

Що записати у звіт:

• контрольну суму файлу до відмови і після заміни диска;
• час і швидкість відновлення RAID 5 із /proc/mdstat і розрахунок для дисків на 16 ТБ;
• що сталося з масивом і даними після другої відмови під час відновлення;
• lvs і df -h до і після розширення тому;
• одне речення про видалений файл: чи повернув його масив.

Готово, коли:

• ви можете підтвердити командою кожне з восьми тверджень таблиці «Що треба вміти підтвердити»;
• звіт містить п’ять пунктів вище;
• розрахунок для 16 ТБ того самого порядку, що орієнтир з етапу 3, або ви пояснили, чому у вас інакше.

Перед початком

• Прочитайте в модулі 14 розділи «RAID», «Логічні томи» і «Як це насправді в Linux» (команди mdadm, vgs, lvs, iostat), а в модулі 12 розділ «Копіювання під час запису».
• Потрібна віртуальна машина з правами root і чотирма додатковими дисками. Контейнер не підходить, бо ділить блокові пристрої з господарем (див. огляд); у хмарній машині має бути можливість додати диски.
• Vagrant-машина з setup/Vagrantfile створює чотири диски по 1 ГіБ сама (потрібен Vagrant 2.2.14 або новіший), у ній уже стоять mdadm, lvm2, parted і gdisk. Заготовок і check.sh для цієї роботи немає.

Потрібна ВМ із додатковими дисками

Робота вимагає щонайменше чотирьох блокових пристроїв. Файли-петлі (losetup) підійдуть для перших етапів, а от для вимірювання відновлення краще додати віртуальній машині справжні віртуальні диски: на петлях ви заміряєте сторінковий кеш, а не диски.

Етапи

1. Підготовка пристроїв.

   Чотири диски по 1 ГіБ. Перевірте lsblk, що ядро їх бачить.

2. RAID 1 і перша відмова.

   Зібрати дзеркало з двох дисків, створити ФС, записати файл із відомою контрольною сумою.

   Позначити один диск як збійний (mdadm --fail), переконатися, що дані читаються, замінити диск і дочекатися синхронізації. Дивитися /proc/mdstat під час процесу.

   Спершу дочекайтесь початкової синхронізації

   Свіжозібраний масив одразу починає початкову синхронізацію. Поки вона триває, mdadm --remove тихо не спрацьовує, і диск лишається у стані (F), хоч команда й повернула нуль. Виглядає так, ніби відмова й заміна «не працюють».

   Тому перед кроком із відмовою:

   while grep -qE 'resync|recovery' /proc/mdstat; do sleep 2; done

   І --fail із --remove подавайте окремими командами з паузою між ними.

3. RAID 5 і вимірювання відновлення.

   Зібрати з трьох дисків, заповнити хоча б наполовину, вивести диск із ладу й заміряти час повного відновлення.

   Порахуйте: якщо на 1 ГіБ пішло N секунд, скільки триватиме відновлення масиву з дисків на 16 ТБ? Це число і є аргумент з модуля 14.

   Для звірки, заміри на віртуальних дисках поверх SSD: початкова синхронізація масиву на 2 ГіБ — 6 с, відновлення після заміни диска — 7 с при швидкості близько 150 МБ/с. Екстраполяція на 16 ТБ дає близько 30 годин. На справжніх дисках, що обертаються, швидкість того самого порядку, тож і висновок той самий.

   Під час відновлення прочитайте дані й переконайтеся, що масив працює, хоч і в стані degraded. Подивіться, що станеться з продуктивністю.

4. Друга відмова під час відновлення.

   Виведіть із ладу другий диск, поки триває відновлення. Зафіксуйте, що саме сталося з даними. Це найважливіший експеримент роботи.

5. LVM поверх масиву.

   Фізичний том на /dev/md0, група томів, два логічні томи. Розширте один із них на льоту разом із файловою системою.

6. Знімок.

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

   Простежте, як зростає зайнятість знімка в міру зміни оригіналу: це копіювання під час запису в чистому вигляді (модуль 12).

7. RAID — не резервна копія.

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

Що треба вміти підтвердити

Твердження	Чим доводиться
Масив зібрано й він працює	cat /proc/mdstat
Масив пережив відмову диска	mdadm --detail /dev/md0 у стані degraded
Дані не постраждали	контрольна сума файлу до і після
Ви заміряли відновлення	час і швидкість із /proc/mdstat
Ви знаєте, що буде на 16 ТБ	розрахунок у звіті
Логічний том розширено без зупинки	lvs, df -h до і після
Знімок містить старий стан	diff вмісту оригіналу і знімка
RAID не рятує від видалення	опис експерименту 7

Часті помилки

Масив «зник» після перезавантаження. Бракує запису в /etc/mdadm/mdadm.conf, і не перезібрано initramfs (модуль 5).

Відновлення «миттєве». Ви заміряли синхронізацію порожнього масиву. Заповніть його даними, бо класичний md відновлює весь простір, а не лише зайнятий.

Знімок переповнився. Знімок LVM має власний обмежений розмір, і коли змін накопичується більше, він стає недійсним. Це очікувана поведінка.

Файлову систему не розширено. lvextend збільшує том, але не файлову систему на ньому. Потрібен resize2fs або одразу lvextend -r.

Далі, якщо цікаво

Порівняти з btrfs у режимі RAID 1: там відновлюються лише зайняті блоки, і на напівпорожньому масиві різниця в часі буде разючою (модуль 15).