Говорячи про цілісність файлової система (ФС) Lustre, слід розділяти дві її складові -- цілісність базових файлових системи (backing file systems), які зберігають всі дані Lustre, та власне логічну цілісність файлової системи, доступної користувачам. Базова ФС є варіантом ext3/ext4, і для ї перевірки використовується спеціальний варіант e2fsck. Перевірка цілісності ФС Lustre як цілого здійснюється спеціалізованою програмою, lfsck.
В нормі потреб для додаткових перевірок базових файлових систем немає. Вона залишається цілісною, завдяки використанню журналювання. Єдиний виняток, коли перевірка e2fsck необхідна -- ситуації, в яких журналювання безпомічне, такі як апаратні збої, помилки вводу-виводу, тощо. Взагалі, згідно документації ("27.1 Recovering from Errors or Corruption on a Backing File System", Lustre 2.0 Operations Manual), Lustre здатна справитися з більшістю неузгодженостей, що можуть виникнути, і потреба користуватися e2fsck/lfsck виникає рідко.
Однак іноді потреба (чи бажання :) виконати перевірку таки є. Як це зробити для невеликих Lustre-систем описано нижче. Чому саме невеликих? Їх простіше вимкнути як ціле, перевірити і запустити знову. З великими системами зробити так важче. Так ось, проблема мінімізації недоступності Lustre чи окремих її частин під час перевірок тут не має особливо високого пріоритету.
Деякі важливі зауваження:
- Рекомендується запускати утиліти, логуючи їх роботу, наприклад програмою script, щоб можна було проаналізувати вивід, наприклад знайти пошкоджені об'єкти.
- Варто спершу запускати в режимі "-n" -- без внесення змін.
- Щоб бути впевненим в тому, що дефекти справжні, а не артефакти журналювання, можна змонтувати ФС та зразу розмонтувати, давши можливість виконати записи, що знаходилися в журналі. Зрозуміло, що робити це слід, коли Lustre зупинена. (Приклад: mount -t ldiskfs /dev/{ostdev} /mnt/ost; umount /mnt/ost)
Для точності ілюстрацій наведено приклади реальної роботи по перевірці ФС. Крім того, для більшої автентичності, пишуться справжні імена пристроїв -- тобто конкретні /dev/md3, а не більш загальні /dev/<mgs-device>. Звичайно, який пристрій виконує які ролі розшифровується.
Отож, повна перевірка файлової системи на цілісність:
1. Зупиняємо всі сервери Lustre.
Зміни ФС в процесі роботи різних утиліт будуть приводити до появи несправжніх повідомлень про помилки навіть на повністю справній файловій системі.
2. Перевіряємо базові файлові системи MGS/MDS/OSS
[root@mgsnode ~]# mount -t ldiskfs /dev/md3 /mnt/mgs [root@mgsnode ~]# umount /mnt/mgs [root@mgsnode ~]# e2fsck -fn /dev/md3 e2fsck 1.41.90.wc3 (28-May-2011) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information MGS: 21/52224 files (0.0% non-contiguous), 5790/52176 blocks
/dev/md3 -- блочний пристрій, на якому знаходяться дані MGS.
Нагадуємо, що пара mount i негайний umount служить для реалізації змін із журнала, якщо такі очікують в ньому. Також, зрозуміло, що MGS i MDS цілком можуть бути на одному вузлі, і тоді mgsnode == mdsnode.
Перевірка закінчилася успішно.
[root@mdsnode ~]# mount -t ldiskfs /dev/md4 /mnt/mdt [root@mdsnode ~]# umount /mnt/mdt/ [root@mdsnode ~]# e2fsck -fn /dev/md4 e2fsck 1.41.90.wc3 (28-May-2011) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information lustre0-MDT0000: 32/13719736 files (0.0% non-contiguous), 1831661/13717472 blocks
/dev/md4 -- блочний пристрій, на якому знаходяться дані MGT.
Перевірка закінчилася успішно.
Тепер для кожного OSS:
[root@oss0 ~]# mount -t ldiskfs /dev/md4 /mnt/ost0 [root@oss0 ~]# umount /mnt/ost0/ [root@oss0 ~]# e2fsck -fn /dev/md4 e2fsck 1.41.90.wc3 (28-May-2011) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information lustre0-OST0000: 214/238166016 files (0.0% non-contiguous), 14966122/952638208 blocks
/dev/md4 -- блочний пристрій, на якому знаходяться дані OST.
Перевірка закінчилася успішно.
Якщо в процесі роботи знайдено помилки -- аналізуємо їх, виконуємо ту ж команду, але без ключа "-n", щоб виправити їх, та сподіваємося на краще. І на резервні копії, в народі - бекапи.
Коли ж процес (нарешті) закінчено успішно, можна переходити до наступного етапу.
2. Генерація баз даних для lfsck
Бази даних, які генеруватимуться на базі даних з MDS будуть потрібні при генерації баз для OSS, і всі вони -- для перевірки файлової системи. Тому їх слід розташувати так, щоб всі вузли, яких це стосується, могли до них доступитися. Використання NFS-директорій не бажане, так як може призвести до сильного сповільнення процесу через те, що в процесі генерації здійснюється багато дрібних звертань, зокрема записів. Краще створювати бази на локальній ФС вузлів, а потім або класти в доступну по NFS директорію, або просто копіювати на вузли, де вони потрібні.
2.1 MDS
Генерація може тривати досить довго, наприклад у нас, із 4 млн файлів - 4-6 годин, розмір отриманого файла з базою MDS -- 2.5Гб. На порожній ФС - менше хвилини, розмір приблизно 100Кб. Якщо на момент перевірки ФС змонтована, обов'язково використовувати ключ -n, інакще ФС буде пошкоджено!
[root@mdtnode tmp]# e2fsck -n -v --mdsdb ./mdsdb /dev/md4
e2fsck 1.41.90.wc3 (28-May-2011)
Warning: skipping journal recovery because doing a read-only filesystem check.
lustre0-MDT0000 lustre database creation, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Pass 6: Acquiring MDT information for lfsck
MDS: ost_idx 0 max_id 161
MDS: got 8 bytes = 1 entries in lov_objids
MDS: max_files = 32
MDS: num_osts = 1
MDS: 'lustre0-MDT0000_UUID' mdt idx 0: compat 0xc rocomp 0x1 incomp 0x1c
32 inodes used (0.00%)
0 non-contiguous files (0.0%)
0 non-contiguous directories (0.0%)
# of inodes with ind/dind/tind blocks: 0/0/0
1831661 blocks used (13.35%)
0 bad blocks
1 large file
14 regular files
9 directories
0 character device files
0 block device files
0 fifos
0 links
0 symbolic links (0 fast symbolic links)
0 sockets
--------
23 files
(На момент конкретно цієї перевірки файлова система була фактично порожньою, але це на так суттєво).
2.2 OSS
Отриманий на поперденьому етапі mdsdb робимо доступним на вузлах з OSS. Для генерації баз даних OSS він буде використовуватися в режимі тільки читання. Тому можна розмістити його в NFS-директорії, або просто скопіювати на вузли.
[root@ossX tmp]# ls
mdsdb
[root@ossX tmp]# e2fsck -n -v --mdsdb ./mdsdb --ostdb ./ost0db /dev/md4
e2fsck 1.41.90.wc3 (28-May-2011)
lustre0-OST0000 lustre database creation, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Pass 6: Acquiring OST information for lfsck
OST: 'lustre0-OST0000_UUID' ost idx 0: compat 0x2 rocomp 0 incomp 0xa
OST: num files = 193
OST: last_id = 193
246 inodes used (0.00%)
0 non-contiguous files (0.0%)
0 non-contiguous directories (0.0%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 200
14966122 blocks used (1.57%)
0 bad blocks
1 large file
200 regular files
37 directories
0 character device files
0 block device files
0 fifos
0 links
0 symbolic links (0 fast symbolic links)
0 sockets
--------
237 files
Важливий нюанс -- якщо для OST використовується окремий журнал (наприклад, як в описаній раніше конфігурації), то для генерації бази доведеться OST розмонтувати:
[root@ossX tmp]# e2fsck -n -v --mdsdb ./mdsdb --ostdb ./ost0db /dev/md4 e2fsck 1.41.90.wc3 (28-May-2011) device /dev/md4 mounted by lustre per /proc/fs/lustre/obdfilter/lustre0-OST0000/mntdev Warning! /dev/md4 is mounted. e2fsck: Device or resource busy while checking ext3 journal for lustre0-OST0000 [root@ossX tmp]# umount /mnt/ost0/
Можливо це обмеження якось можна обійти. Так як наша система невелика, ми вирішили не ризикувати і просто розмонтували.
Якщо файлова система має дефекти, під час генерації баз даних можуть виникати повідомлення типу: "******* WARNING: Filesystem still has errors *******". Нічого спеціально з тим робити не потрібно -- все так чи по іншому вирішуватиметься на наступному етапі.
2.3 Перевірка власне файлової системи Lustre
Вибираємо котрийсь із клієнтів (бажано, щоб це був не один із вузлів, на яких виконуються сервери "Люстри"). Робимо на ньому доступними згенеровані вище бази. Монтуємо "люстру", та запускаємо перевірку:
[root@compute-0-14 tmp]# lfsck -n -v --mdsdb ./mdsdb --ostdb ./ost0db \/lustre0 lfsck 1.41.90.wc3 (28-May-2011) MDSDB: ./mdsdb OSTDB[0]: ./ost0db MOUNTPOINT: /lustre0 MDS: max_id 161 OST: max_id 193 lfsck: ost_idx 0: pass1: check for duplicate objects lfsck: ost_idx 0: pass1 OK (0 files total) lfsck: ost_idx 0: pass2: check for missing inode objects lfsck: ost_idx 0: pass2 OK (0 objects) lfsck: ost_idx 0: pass3: check for orphan objects [0] uuid lustre0-OST0000_UUID [0] last_id 161 [0] zero-length orphan objid 0:32 [0] zero-length orphan objid 0:64 <skipped>
[0] zero-length orphan objid 0:155 [0] zero-length orphan objid 0:156 [0] zero-length orphan objid 0:157 [0] zero-length orphan objid 0:158 [0] zero-length orphan objid 0:159 lfsck: ost_idx 0: pass3 OK (193 files total) lfsck: pass4: check for 0 duplicate object references lfsck: pass4 OK (no duplicates) lfsck: fixed 0 errors
У нашому випадку система цілісна. Оці "[0] zero-length orphan objid" це нормально. Вони зазвичай не свідчать про помилку, а виникають тому що певний індекс об'єктів на OSS (OST: max_id 193 у виводі команд вище) виділяється із запасом. Детальніше про це можна почитати тут: "26.3.4 Fixing a Bad LAST_ID on an OST" (Lustre 2.0 Operations Manual).
3. Можливі помилки
В реальності із збоями файлової системи (за шість років експлуатації) стикатися поки не доводилося, тому подальші міркування чисто теоретичні. Деталі див. "27.2 Recovering from Corruption in the Lustre File System" (Lustre 2.0 Operations Manual).
- "Підвішені" inode -- inode виділено, але об'єкт не існує. Зустрічається, коли були збої OSS. Що з ними робити -- див. "27.2.1 Working with Orphaned Objects", але там чесно сказано що простіше відновити файли з резервної копії.
- На OSS існують "підвішені" (orphan) об'єкти, для яких не існує inode. Трапляються під час збоїв MDS. По суті близькі до знайомих багатьом lost clusters епохи DOS/FAT :-). lfsck з опцією -l помістить їх у папку lost+found, де їх можна буде переглянути та вирішити, що з ними робити. lfsck з опцією -d їх просто видалятиме.
- Декілька inode посилаються на той же об'єкт. Трапляються під час збоїв MDS. lfsck з опцією -с зробить копії об'єктів у незалежні файли. Зазвичай один з файлів буде в порядку, а інші (створені "копії") міститимуть сміття. На жаль, lfsck не може сказати, котрий із них буде котрим.
- Якщо після генерації баз даних ФС змінювалася, можуть повідомлятися помилки, яких насправді немає. Варто повторити генерацію, не допускаючи змін ФС до завершення перевірки.
Про вирішення інших проблем з Lustre також можна почитати тут: "26. Lustre Troubleshooting" (Lustre 2.0 Operations Manual).
Немає коментарів:
Дописати коментар