Іноді виникає потреба перенести дані з OSS кудись. Оце "кудись" залежить від мотивів перенесення. OSS може потребувати обслуговування, може заплановано апгрейд. Він може бути в аварійному стані, і дані слід терміново з нього забрати. І тому подібне.
Процедура такої міграції в Lustre є, вона добре описана в документації, доволі проста та надійна. Хоча, звичайно, страшно :-). Довелося робити її на практиці. Нижче описано міграцію з OSS на прикладі нашої системи, нічого суттєво нового, в порівнянні із документацією немає, просто "приклад з життя".
Версія Lustre достатньо старенька -- 2.0, про апгрейд до новіших версій, думаю, напишу в майбутньому. Процедуру міграції описано тут: "14.6 Adding a New OST to a Lustre File System" та наступних главах того ж документу, "14.7 Removing and Restoring OSTs", "14.7.1 Removing an OST from the File System".
1. Створення нового OSS
Спочатку було створено новий OSS, згідно процедури, описаної раніше: "Інсталяція Lustre 2.0":
[new_oss]# mke2fs -b 4096 -O journal_dev /dev/md3 263040 mke2fs 1.41.90.wc3 (28-May-2011) Discarding device blocks: failed - Invalid argument Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 0 inodes, 263040 blocks 0 blocks (0.00%) reserved for the super user First data block=0 0 block group 32768 blocks per group, 32768 fragments per group 0 inodes per group Superblock backups stored on blocks:
[new_oss]# mkfs.lustre --ost --index=1 --mgsnode=192.168.1.123@tcp0 \
--fsname=lustre0 --mkfsoptions="-J device=/dev/md3 \
-E stride=64,stripe_width=256" --param failover.mode=failout \
/dev/md4
Permanent disk data:
Target: lustre0-OST0003
Index: 1
Lustre FS: lustre0
Mount type: ldiskfs
Flags: 0x62
(OST first_time update )
Persistent mount opts: errors=remount-ro,extents,mballoc
Parameters: mgsnode=192.168.1.123@tcp failover.mode=failout
device size = 7536681MB
formatting backing filesystem ldiskfs on /dev/md4
target name lustre0-OST0003
4k blocks 1929390336
options -J device=/dev/md3 -E stride=64,stripe_width=256 -i 16384 -I 256 -q -O dir_index,extents,uninit_bg -F
mkfs_cmd = mke2fs -j -b 4096 -L lustre0-OST0003 -J device=/dev/md3 -E stride=64,stripe_width=256 -i 16384 -I 256 -q -O dir_index,extents,uninit_bg -F /dev/md4 1929390336
Writing CONFIGS/mountdata
Детально процес описаний за посиланням вище, лише декілька зауважень:
Зауваження 1: "--index=1" вказано, щоб новому OSS присвоїло ім'я lustre0-OST0003, а не lustre0-OSTffff, як воно поривалося, але потім мені стало зрозуміло, що, можливо, це зайве --- при монтуванні (після встановлення зв'язку з MDS?), воно само їх пронумерує.
Зауваження 2: Якщо базова файлова система вже була сформатована під Lustre-OSS, слід дати ключ: "--reformat", інакше, з міркувань безпеки, воно відмовиться форматувати.
Зауваження 3: Якщо перед переформатуванням базової файлової системи OSS не переформатувати розділ журналу (у прикладі вище -- /dev/md3), форматування OSS проходитиме успішно, лише в кінці дасть дещо загадкове повідомлення про помилку:
mkfs.lustre: Unable to mount /dev/md4: Invalid argument
Правда, повідомлення в системному журналі, /var/log/messages, буде трішки зрозумілішим:
Nov 7 17:36:49 new_oss kernel: LDISKFS-fs: External journal has more than one user (unsupported) - 2
2. Монтування нового OSS
Тут все просто:
[new_oss]# mkdir /mnt/ost1 [new_oss]# mount -t lustre /dev/md4 /mnt/ost1
Якщо змонтувалося успішно, можна продовжувати.
3. Тимчасова інактивація OSS
Щоб нові дані не потрапляли на OSS, який виводиться з експлуатації, його слід деактивувати на MDS. При цьому він стане доступним лише для читання. Увага, якщо після цього планується забирати з нього дані, деактивувати на клієнтах не можна!
Процедура описана в документації: "14.7.1 Removing an OST from the File System".
Спочатку слід вияснити номер пристрою, який деактивуватиметься, OSS0 в нашому випадку:
[mds]# lctl dl | grep " osc " 5 UP osc lustre0-OST0000-osc-MDT0000 lustre0-MDT0000-mdtlov_UUID 5 6 UP osc lustre0-OST0001-osc-MDT0000 lustre0-MDT0000-mdtlov_UUID 5 7 UP osc lustre0-OST0003-osc-MDT0000 lustre0-MDT0000-mdtlov_UUID 5
Його номер -- 5.
Деактивація (виконується на MDS):
[mds]# lctl --device 5 deactivate
В нормі не дає ніяких повідомлень. Деактивація тимчасова, після перезавантаження він знову буде активним. Про постійну деактивацію -- див трішки нижче.
Перевірити, чи деактивувався, можна (на MDS) так:
[mds]# cat /proc/fs/lustre/lov/lustre0-MDT0000-mdtlov/target_obd 0: lustre0-OST0000_UUID INACTIVE 1: lustre0-OST0001_UUID ACTIVE 2: lustre0-OST0003_UUID ACTIVE
4. Міграція даних
Міграція здійснюється просто -- за допомогою "lfs find" знаходяться всі файли з OSS0, їх список передається утиліті lfs_migrate. Взагалі, міграцію можна використовувати не лише "звільняючи" OSS, але і для перебалансування системи після додання нових OSS, перерозподілу файлів між ними і т.д. Детальніше див. документацію.
Виконується ця операція на одному із клієнтів (наприклад, на вузлі кластера):
[lustre_client]# lfs find --obd lustre0-OST0000 /lustre0 | lfs_migrate -y > migration_log 2>&1 &
"--obd" для "lfs find" вказує шукати файли, які знаходяться на переданому їй OSS (lustre0-OST0000 в нашому випадку). "-y" для lfs_migrate -- відповідати "так" на запитання та перестороги команди. lfs_migrate виводить лог виконання, де перераховує файли, які переміщено:
/lustre0/some_folder/other_folder/file1: done
/lustre0/some_folder/other_folder/file21: done
...
Цей вивід перенапрявляємо у файл --- міграція може бути довгою.
Файли при тому перерозподілятимуться між всіма іншими OSS так, щоб система була якомога збалансованішою.
Під час міграції цілком можна повноцінно працювати із "Люстрою" --- якщо файли ще на OSS0, вони відкриватимуться з нього,
Увага! БЕКАПИ, резервні копії -- ЦЕ ВАЖЛИВО! Ні один трюк, всілякі там рейди, міграції і т.д., не замінить їх!
Якщо OSS просто вийшов з ладу, чи з інших причин недоступний, можна видалити всю метаінформацію про файли, які на ньому знаходилися, і відновити їх з резервної копії, згідно сформованого при цьому списку:
[lustre_client]# lfs find --obd <OST UUID> -print0 <mount_point> | \
tee /tmp/files_to_restore | xargs -0 -n 1 unlink
5. Остаточна деактивація і заміна OSS
Якщо OSS буде відсутнім тривалий час, або взагалі на завжди, слід його "остаточно" деактивувати спершу на MGS, потім на MDS та клієнтах:[mgs]# lctl conf_param lustre0-OST0000.osc.active=0 [clientX]# lctl set_param osc.lustre0-OST0000-*.active=0
Знову активувати, за потреби, можна, встановивши active=1. Постійна деактивація здійснюється командою "conf_param", як у прикладі вище, тимчасова -- "set_param".
Увага: Після деактивації ім'я OSS все ще залишається в системі. Не варто його використовувати повторно для іншого OSS!
Зауваження: якщо під час деактивації на клієнтах неправильно задати назву, воно скаже щось типу:
[clientX]# lctl set_param lustre0-OST0000.osc.active=0
error: set_param: /proc/{fs,sys}/{lnet,lustre}/lustre0-OST0000/osc/active: Found no match
Якщо глянути на клієнті в /proc/fs/lustre/osc, буде видно щось таке:
[clientX]# cd /proc/fs/lustre/osc [clientX]# ls lustre0-OST0000-osc-<some-long-hex-number> lustre0-OST0001-osc-<some-long-hex-number> num_refs
звідти і потреба в "*".
Заключне слово
Ось і все :-) Успішних міграцій. Будуть запитання чи бачите помилку -- пишіть!
А, мало не забув -- користуватися на свій страх і ризик, жодних гарантій ;-)
Немає коментарів:
Дописати коментар