Нещодавно на нашому кластері виникла необхідність оновити систему збереження, Lustre. Щоб спростити собі такі задачі на майбутнє, вирішив написати кілька нотаток, які стосуватимуться різних аспектів роботи з "Люстрою".
Спершу, в ролі огляду, що ж таке Lustre -- моя стаття та презентація з семінару, присвяченому кластеробудуванню в Західній Україні. Зауважу, що відбувся він доволі давно - майже рік тому. З того часу багато що змінилося. Оракл, якому належала Lustre після придбання Sun, повідомив про припинення її розробки. Однак, зразу виникло кілька фірм, що розробляють та підтримують цю, безперечно, перспективну розподілену файлову систему. Серед них слід виділити Whamcloud, куди пішли ключові розробники - Eric Barton і Andreas Dilger, щоб продовжити роботу над Lustre.
Текст нижче стосується, в основному, Lustre 1.8. Надалі описуватиметься Lustre 2.0, яка дуже схожа у всіх аспектах, однак має і суттєві відмінності.
За відгуки, виявлені помилки та пропозиції по тексту буду вдячним :-)
Презентація доступна тут.
Система збереження даних Lustre
Олег Фаренюк
3 листопада 2010
Хочу подякувати Тарасу Пацагану за можливість розповісти про нашу систему збереження даних та цінні зауваження в процесі роботи над доповіддю.
1 Вибір системи збереження
Часто в процесі наукових розрахунків виникає потреба читати або зберігати великі об'єми даних. Щоб зробити цей процес ефективним, використовують виділені Системи Збереження Даних (СЗД). Які вимоги до такої системи?
- Зручність використання на кластері, по можливості - прозорість для користувачів.
- Надійна робота з OS Linux.
- Сумісність з POSIX-стандартом розподілених файлових систем.
- Однаковий доступ з різних вузлів.
- Надійна робота з OS Linux.
- Надійність.
- Висока продуктивність - адже з нею може одночасно працювати багато клієнтів,
кожен із своїми потоками даних. Їй доведеться працювати в наступних умовах:
- Великі потоки даних.
- Велика кількість мало пов'язаних (нелокальних) звертань.
- Доступ одночасно з десятків вузлів.
- Великі потоки даних.
- Масштабованість:
- Безболісне збільшення кількості клієнтів.
- Розмір - багато терабайт.
- Можливість додавати жорсткі диски та вузли СЗД.
- Безболісне збільшення кількості клієнтів.
- Простота та зручність в обслуговуванні.
- Підтримка квот.
- Підтримка квот.
Кілька років тому ми проаналізували багато можливих варіантів. З великою перевагою виграв один - кластерна файлова система Lustre. Вона по своїй суті розподілена, розробляється1 якраз для використання в кластерах та датацентрах, з відкритими джерельними текстами, та відтворює POSIX-семантику роботи з файлами, тому прозора для більшості (навіть багатопоточних) програм. Крім того, для неї є дуже хороші рекомендації - вона використовується в системах від маленьких, з кількома вузлами, до величезних, із десятками тисяч, пропускною здатністю в сотні терабайт на секунду і розміром в пентабайти. Зокрема, 15 з 30 найпотужніших кластерів з TOP500 використовують саме її.
2 Компоненти Lustre
Складається Lustre2 з наступних логічних елементів:
- MGS - Management Server, сервер керування,
- MDS - Metadata Server, сервер метаданих,
- MDT - Metadata Target, цільовий пристрій метаданих,
- OSS - Object Storage Server(s), об'єктні сервери збереження даних,
- OST - Object Storage Target, об'єктні цільові пристрої збереження даних.
- Клієнти.
Кожен сервер працює з своїми цільовими пристроями (targets), MDS з MDT, OSS з OST. Коротко опишемо їх функції та призначення.
MGS - сервер конфігурацій файлових систем (ФС), єдиний на кластер. До нього звертаються всі екземпляри ФС Lustre та клієнти. Вимагає для своїх потреб невеликий блочний пристрій, розміром кілька десятків мегабайт3. Необхідний розмір не залежить від розміру файлових систем, що послуговуються MGS. Передбачена можливість суміщати MGS з MDS.
MDS - сервер метаданих, тобто імен файлів, директорій, прав доступу, тощо. Він єдиний для конкретної ФС. Самі метадані зберігаються у відповідному цільовому пристрої, MDT. MDT потребує окремого блочного пристрою але може суміщатися з MGS, якщо MDS єдиний. Так як MGS/MDS критичні для роботи ФС, передбачено можливість автоматичної заміни при збої, так званий failover. Фактично MDT - спеціальна файлова система, модифікована ext3/ext4, монтування якої запускає відповідний сервер, а розмонтування - зупиняє.
Аналогічно, OSS - сервер що безпосередньо здійснює ввід-вивід даних та їх передачу мережею клієнтам. Для збереження даних він використовує OST4. Кожен OSS може використовувати один чи більше цільовий пристрій OST. Розмір одного OST - до 8Тб (за певних умов - до 16Тб), при цьому частини одного файлу можуть знаходитися на різних OST. Це може знадобитися для покращення швидкодії або подолання обмеження у 8Тб на файл. OSS можна легко додавати до ФС, збільшуючи доступний простір; і навпаки, відключення OSS не впливає на працездатність ФС як цілого. Зрозуміло, що файли, які знаходяться на відключеному OSS стають недоступними. Є можливість керування розташуванням файлів на OSS. Наприклад, перш ніж вимикати конкретний сервер даних, можна вивести всі файли з нього.
Клієнтом може бути будь-яка машина з Linux та відповідним клієнтським програмним забезпеченням. Ядро з модифікаціями, що мають відношення до Lustre, не є необхідним! Всі клієнти бачать одну і ту ж, синхронізовану і когерентну ФС, з тими ж правами доступу та іншими атрибутами. Єдина серйозна вимога - UserID та GroupID повинні на всіх вузлах-клієнтах бути тими самими, а їх годинники - синхронізованими5.
Важливе уточнення - клієнтами тут називаються відповідні вузли та драйвери Lustre, що працюють на них. Користувацьке програмне забезпечення в нормі працює з файлами звичайним чином, не знаючи нічого про Lustre. Отож, з точки зору клієнта, робота з ФС виглядає так:
- Клієнт звертається до MDS, отримує метадані файлу та інформацію про його структуру.
- Для читання чи запису інформація про структуру передається LOV (logical object volume), який визначає, які дані з яких саме OST належать цьому файлу.
- Клієнт блокує відповідні ділянки файлу, після чого здійснює серію операцій вводу-виводу, звертаючись безпосередньо до OST.
Завдяки такому розподілу функцій, більшість звертань та потік даних не йде через якийсь конкретний вузол, доступ є розподіленим, тому ймовірність виникнення вузьких місць мала. Найважливіше - все це відбувається прозоро для програм, що працюють з файловою системою.
Знаходитися всі описані компоненти, MGS, MDS, OSS та клієнти, можуть як на одному вузлі, так і практично в будь-яких комбінаціях6 на різних.
Працюють ці логічні елементи поверх фізичних (backend) пристроїв. "Бекендом" може служити практично будь-який блочний пристрій - розділи дисків, RAID7, LVM-томи, loopback-пристрої8. На даний момент Lustre несумісна з SELinux, і вимагає повного вимкнення цього механізму.
Для зв'язу між вузлами можуть використовуватися звичайний Ethernet, Infiniband, Mellanox, тощо.
3 Встановлення Lustre
Розглянемо встановлення СЗД на базі Lustre на прикладі кластера ІФКС.
Базова операційна система - Linux, кластерний дистрибутив Rocks, на базі CentOS9. Rocks має roll для роботи з Lustre, однак було вирішено що зручнішим буде встановити її самостійно. Мова йтиме про останню стабільну на той момент версію Lustre 1.810. Апаратна конфігурація наступна: один вузол виділено для MGS та MDS, два - під OSS. Мережевий інтерфейс до решти кластера - Gigabit Ethernet. В кластер, за виключенням вузлів СЗД, входить 17 обчислювальних вузлів та координуюча машина.
MDS/MGS в ролі бекенда використовує RAID1, з двома активними та одним резервним жорстким диском. Операційна система може вантажитися з будь-якого з них11. MGS та MDT використовують різні блочні пристрої, що довзоляє підтримувати одночасно кілька екземплярів Lustre.
OSS - RAID5 з 5 активних та одного резервного диска. На перший погляд це не дуже ефективно - 1/3 об'єму недоступна для безпосереднього використання. Однак такий підхід виправданий. Протягом 2010 року двічі відбулися подвійні збої. Першого - зіпсувалися два диски, а третій, після виходу з ладу якого вже не було б можливості відновити дані, заледве зміг протриматися до кінця
реконструкції RAID і зразу після був замінений. Другого разу подвійна відмова була викликана тимчасовим збоєм контролера дисків, однак зрозумілим це стало далеко не зразу. Варто ще раз нагадати - жодне резервування не позбавляє необхідності робити резервні копії.
Перший крок розгортання Lustre - заборонити SELinux, скачати та заінсталювати вказані нижче пакети Lustre та перезавантажити вузли.
- kernel-2.6.18-164.11.1.el5_lustre.1.8.3 - ядро з підтримкою
Lustre (на вузлах-клієнтах не обов'язкове)
- e2fsprogs-1.41.10, модифікований для роботи з Lustre
- lustre-ldiskfs-3.0.9-2.6.18_164.11.1.el5_lustre.1.8.3
- lustre-1.8.3-2.6.18_164.11.1.el5_lustre.1.8.3
- lustre-modules-1.8.3-2.6.18_164.11.1.el5_lustre.1.8.3
- lustre-client-1.8.3-2.6.18_164.11.1.el5_lustre
Всі перераховані пакети - у варіанті у варіанті x86_64, ext3. Далі - вказати, яким мережевим інтерфейсом має користуватися Lustre. Для цього у файл /etc/modprobe.conf додається рядок типу options lnet networks=tcp0.
Далі створюється MGS, та монтується щоб запустити відповідний сервіс:
# mkfs.lustre --mgs /dev/<mgs-block-device> # mkdir /mnt/mgs # mount -t lustre /dev/<mgs-block-device> /mnt/mgs
Форматується пристрій MDT, вказуючи адресу MGS, що зберігатиме конфігурацію (краще вказувати IP-адресу а не hostname), монтується:
# mkfs.lustre --mdt --mgsnode=<MGS-node-IP>@tcp0 \ --fsname=lustre0 /dev/<mdt-block-device> # mkdir /mnt/mdt1 # mount -t lustre /dev/<mdt-block-device> /mnt/mdt1
lustre0 - ім'я, що використовуватиметься в майбутньому для ідентифікації цієї FS.
На даний момент, якщо всі операції пройшли успішно, MDS працює і можна приступати до створення OSS. Виконується воно аналогічно. Для кожного OSS:
# mkfs.lustre --ost --mgsnode=<MGS-node-IP>@tcp0 \ --fsname=lustre0 /dev/<ost-block-device> # mkdir /mnt/ost1 # mount -t lustre /dev/<ost-block-device> /mnt/ost1
Після їх успішного монтування можна пробувати використовувати щойно створену файлову систему. Щоб монтування сервісів відбувалося автоматично, необхідно додати наступні рядки до fstab:
/dev/<mgs-block-device> /dev/mgs lustre defaults,_netdev 0 0 /dev/<mdt-block-device> /dev/mdt1 lustre defaults,_netdev 0 0 і /dev/<ost-block-device> /dev/ost lustre defaults,_netdev 0 0
_netdev вказує, що це мережева ФС і слід спершу завантажити мережеві сервіси.
Клієнти можуть монтувати ФС так:
mount -t lustre <MGS-node-IP>@tcp0:/lustre0 <mount-point>
де крім типу ФС та точки монтування вказується MGS-вузол, мережевий інтерфейс та ім'я ФС, яке було їй присвоєне раніше - lustre0. Для автоматичного монтування потрібно додати у файл /etc/fstab наступний рядок:
<MGS-node-IP>@tcp0 <mount-point> defaults,_netdev 0 0
Порядок запуску сервісів Lustre важливий, і має бути таким: MGS, всі OST, MDT, клієнти. Він не є обов'язковим, система гнучка та стійка, але має ряд переваг. Нормальний порядок зупинки зворотній: всі клієнти, MDT, всі OST, і якщо зупинено всі екземпляри Lustre на кластері - MGS.
4 Заключні зауваження
Багато питань залишилися невисвітленими: вибір розміру MGS, MDT, конфігурація смуг (stripe) та інших опцій Lustre i RAID-ів, різні переконфігурування: оновлення Lustre, зміна адреси MGS, failover; вирішення типових проблем, тощо. Кожне з цих питань вимагатиме окремої великої статті. Однак документація Lustre дуже хороша, а складність використання, в порівнянні з першою версією, що використовувалася на кластері ІФКС, 1.4, зменшилася на порядок. В Інтернеті є форуми, присвячені їй та багато цікавих обговорень. Практично з кожною проблемою вже хтось стикався.
На цій пораді - користуватися документацією та пошуком в Інтернет, даний огляд кластерної файлової системи Lustre і закінчимо.
Footnotes:
1Oracle, якому після покупки Sun дісталася і Lustre, в грудні 2010-го року оголосив про припинення подальшої розробки. Розробку пробують продовжити кілька груп розробників, наскільки ці спроби будуть успішними поки невідомо.
2Звичайно, мається на увазі її "екземпляр".
3На кластері ІФКС для нього виділено 200Мб, з яких використовується 17.
4Який, як і MDT, є певною файловою системою.
5Тому необхідно використовувати NTP.
6Хоча тут є певні нюанси.
7Завдяки яким поломки окремих жорстких дисків не приводять до втрати даних чи хоча б необхідності зупиняти систему збереження даних.
8Тобто можна створити повноцінну, хай і непрактичну для реальної роботи, файлову систему Lustre у вигляді всього лиш кількох файлів.
9Який, у свою чергу, є варіантом RedHat Enterprise, очищеним від не-вільного вмісту.
10На основній СЗД кластера насправді було здійснено перехід з версії 1.6 на 1.8. Однак, цей процес, хоча і цікавий, але не дуже актуальний у ввідному огляді Lustre, та й його опис вимагатиме ще однієї такої ж статті, тому далі розмова про інсталяцію з нуля.
11Щоб не виникала ситуація, коли дані цілі, однак скористатися ними не можна через те, що неможливо завантажити базову операційну систему.
File translated from
TEX
by
TTHgold,
version 4.00.
On 11 Aug 2011, 07:16.
Немає коментарів:
Дописати коментар