Створення розділяється сховища на базі CEPH RBD і GFS2

Більшість кластерних систем передбачає наявність файлової системи доступної зі всіх вузлів кластера. Ця файлова система використовується для зберігання, даних, для організації роботи деяких кластерних підсистем і т. д. Вимоги на продуктивність такої FS можуть сильно відрізнятися для різних завдань, однак, чим вона вище, тим вважається, що кластер більш стійкий і універсальний. NFS сервер на майстер-сайті є мінімальним варіантом такої FS. Для великих кластерів NFS доповнюється розгортанням LustreFS — високопродуктивної спеціалізованої розподіленої файлової системи, що використовує декілька серверів в якості сховища файлів і кілька метаинформационных серверів. Однак така конфігурація володіє рядом властивостей, які ускладнюють роботу з нею у разі, коли клієнти використовують незалежні віртуалізовані кластера. В системі HPC HUB vSC для створення поділюваної FS використовується широко відоме рішення CEPH і файлова система GFS2.
main

В рамках роботи над проектом HPC HUB, що базуються на OpenStack, постала задача створити надійне і високопродуктивне поділюване сховище для декількох груп віртуальних машин, кожна з яких представляє з себе маленький віртуальний HPC кластер. Кожен такий кластер видається окремому клієнту, який зсередини його повністю контролює. Таким чином, задача не може бути вирішена в рамках «звичайної» розподіленої системи, зібраної на фізичних комп'ютерах, т. к. Ethernet мережі кластерів ізольовані один від одного на рівні L2 для захисту даних клієнтів та їх мережевого трафіку один від одного. При цьому дані можна розмістити на кожній з віртуальних машин в рамках класичної поділюваної системи бо не вистачає можливостей кожної з машин і хочеться звільнити цінні процесорні ресурси відразу по закінченні розрахунків, не витрачаючи його на «переливання даних», особливо з урахуванням використання моделі pay-per-use. На щастя, не все так погано. У світлі того, що поділюване сховищі передбачається використовувати для HPC розрахунків, можна зробити кілька припущень про навантаження:

  • операції будуть проводиться великими блоками;
  • операції запису не будуть частими, а будуть перемежовуватися значними тимчасовими інтервалами;
  • операції запису можуть починатися відразу з усіх вузлів практично одночасно, але навіть у такому разі запис хочеться закінчити як можна швидше, щоб вузли продовжили рахунок.
Однорангова система з вузлами, на яких робиться розрахунок і одночасно зберігаються дані, суперечить парадигмі HPC в принципі, т. к. на сайті з'являються дві не синхронізовані активності: рахунок і запис даних з якогось іншого сайту. Ми вимушені були від нього відмовитися спочатку. Було вирішено будувати дворівневу систему. Підходів до такого сховища бачиться кілька:

  1. Розподілена файлова система, змонтована на віртуальний вузол через спеціально організоване мережеве пристрій, щоб уникнути втрат продуктивності від OpenStack-віртуалізації мережі.
    sch1
  2. Розподілена файлова система, змонтована на фізичний сайт і доступ до неї з гостьової системи через віртуальну файлову систему.
    sch2
  3. Класична розподілена файлова система всередині віртуального кластера поверх блочного пристрою гостя.
    sch3
  4. Розподілене блоковий пристрій, загальне для кожного віртуального вузла, і преднастроенная файлова система всередині віртуального кластера, що працює поверх цього загального пристрою.
    sch4
Спробуємо проаналізувати переваги і недоліки цих підходів.

У варіанті 1) класична розподілена файлова система (або якесь дерево) монтується в гостьову ОС. У цьому випадку сервера файлової системи видно з кожної системи і один одному. Це порушує ізоляцію мережі за рівнем L2 і потенційно дозволяє різним користувачам побачити трафік один одного з сохраняемыми даними. Крім того, для випадку CEPH можливі тільки кооперативні квоти (тобто користувач може переиспользовать допустиме дисковий простір за рахунок інших користувачів) в режимі монтування файлової системи через FUSE (filesystem in userspace), а не безпосередньо в ядрі. При монтуванні безпосередньо в ядрі квоти не підтримуються взагалі.

У варіанті 2) — віртуальна файлова система (virtio-9p в QEMU) поверх розподіленої файлової системи, змонтованої в хості — для роботи потрібно запускати QEMU від імені суперкористувача без пониження привілеїв, що знижує загальну захищеність системи ну або налаштовувати специфічні ACL для зберігання ідентифікаторів гостьових користувачів і гостьових прав доступу.

У варіанті 3) при відсутності дискового простору на фізичних серверах ми можемо використовувати тільки віддалені блокові пристрої якогось розподіленого сховища. Цей варіант недоцільний з кількох причин:

  • для доступу до даних потрібно в 2 рази більше пропускної здатності мережі. Дані спочатку передаються із розподіленого сховища на конкретний віртуальний вузол і тільки потім відсилаються фінального споживача;

  • як правило всі такі системи підтримують надмірність за даними, що неприйнятно. Наприклад, при налаштуваннях за замовчуванням для CEPH корисний об'єм сховища зменшується у 4 рази від доступного обсягу дисків. Всі мережеві навантаження, що забезпечують роботу розподіленої FS також будуть усередині віртуального мережевого простору. І, що найважче, останній варіант фактично потребує виділення фізичних вузлів під виртуалки сховища, що призводить до різкого зниження загальної ефективності.
У варіанті 4) ми вирішили спробувати розподілене блочний пристрій на базі CEPH і якусь файлову систему всередині кластера, що працює з таким пристроєм. Насправді гість, звичайно ж, бачить пристрій не як блочний пристрій CEPH, а як звичайний віртуальний VirtIO SCSI або, за бажанням, VirtIO block. Ми вибрали VirtIO SCSI з дуже простої причини — через підтримки SCSI команди unmap, аналог широко відомої команди SATA TRIM, яка надсилається гостьовою системою при видаленні файлів і звільняє місце у віртуальному сховищі.

Вибір файлової системи для гостя теж проста. Тут є всього два варіанти:

  • OCFS2,
  • GFS2.
Екзотику, яка не підтримується в mainstream Linux, для комерційної експлуатації використовувати не хотілося. Так як в якості базової системи узятий CentOS 7, то OCFS2 теж відпадає. Кропіткої пересборкой ядра бажання займатися не було. Крім того, GFS2 підтримує зміну розмірів файлової системи в змонтованому стані, що може бути корисно для нашого випадку.

Конфігурація розділяється сховища
Установка CEPH чудово описана в документації docs.ceph.com/docs/master/start і особливих проблем не викликала. Зараз система працює з одного надлишкової копією даних і без авторизації. Мережа CEPH ізольована від клієнтської мережі. Створення блочного пристрою також проблем не викликало. Все стандартно.

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

Перше і найголовніше, що треба знати, це те, що підняти цю файлову систему на Ubuntu у вас, швидше за все, не вийде. Або вам доведеться зібрати багато маловикористовуваних за межами RedHat-а пакетів під Ubuntu, дозволивши купу нетривіальних конфліктів рівня API.

Під RedHat-подібною системою послідовність більш або менш зрозуміла. Нижче наведені команди для гостьової системи CentOS 7.

Першим ділом, відключаємо SELinux. GFS2 з ним працювати не буде. Це офіційна інформація від виробника.

vi /etc/sysconfig/selinux # треба перезавантажиться, але це можна зробити пізніше

Ставимо базовий софт:

ням -y install ntp epel-release vim openssh-server net-tools

Включаємо/відключаємо потрібні сервіси:

chkconfig ntpd on
chkconfig firewalld off

NTP необхідний для роботи системи, на нього зав'язані всі розподілені блокування областей блочного пристрою. Система налаштовується для ізольованого від зовнішнього світу кластера, тому firewall'и вимикаємо. Далі ставимо потрібну програмну обв'язку на кожному з вузлів кластера:

ням -y install gfs2-utils lvm2-cluster pcs fence-agents-all
chkconfig pcsd on # запускаємо PaceMaker - серце RedHat кластера
lvmconf --enable-cluster # необхідно для роботи GFS2 в розподіленому режимі 
echo <PASSWORD> | passwd --stdin hacluster # пароль для адміністратора кластера. Виберіть свій :)
reboot # для відключення SELinux і застосування налаштувань LVM

Зверніть увагу, користувача 'hacluster' створювати не треба, він створюється сам при інсталяції пакетів. Надалі його пароль вам знадобиться для створення мережі взаємної авторизації між машинами кластера.

Тепер можна створити розподілене сховище, якщо це не було зроблено раніше. Робиться на будь-якому вузлі CEPH, тобто в нашому випадку на фізичному сайті:

rbd create my-storage-name --image-format 2 --size 6291456 # розмір в Мб!
sudo rbd map rbd/my-storage-name
sudo mkfs.gfs2 -p lock_dlm -t gfs2:fs -j17 /dev/rbd0
sudo rbd unmap /dev/rbd0

При форматуванні файлової системи вказується ім'я кластера — у нашому випадку 'gfs2' і ім'я файлової системи в рамках кластера 'fs', кількість журналів '-j17', яке повинне бути дорівнює кількості вузлів (у нашому випадку-17), що одночасно працюють з цим кластером і протокол блокування для виділення дискового простору (у нашому випадку 'lock_dlm' — розподілена блокування). Імена кластерів і файлової системи повинні будуть вказані при монтуванні розділу. В ізольованій мережі всередині кластера можна використовувати одні і ті ж імена для різних кластерів. Це не викликає проблем.

Тепер залишається тільки налаштувати монтування у гостьовій ОС. Конфігурація виконується з однієї з машин кластера один раз.

pcs cluster destroy --all # кластер треба знищити, якщо він вже існував

Створення мережі взаємної авторизації:

pcs cluster auth master n01 n02 n03 n04 -u hacluster -p 1q2w3e4r --force

тут, master і n01..n04 — це віртуальні хости, на яких буде доступний загальний розділ.

Створюємо кластер за замовчуванням. Зверніть увагу, ім'я кластера має збігатися з використаним при створенні файлової системи на попередньому кроці.
pcs cluster setup --name gfs2 master n01 n02 n03 n04
pcs cluster start --all # стартувати кластер прямо зараз
pcs cluster --enable all # стартувати кластер при перезавантаженні віртуального хосту

Запуск службових демонів — clvmd & dlm:

pcs property set no-quorum-policy=ignore
pcs stonith create local_stonith fence_kdump pcmk_monitor_action="metadata"
pcs resource create dlm ocf:pacemaker:controld op monitor interval=30s \
on-fail=fence clone interleave=true ordered=true
pcs resource create clvmd ocf:heartbeat:clvm op monitor interval=30s \
on-fail=fence clone interleave=true ordered=true
pcs constraint order start dlm-clone then clvmd-clone
pcs constraint colocation add clvmd-clone with dlm-clone

Монтування GFS2 розділу у /shared, загальна блочний пристрій — sdb:

pcs resource create clusterfs Filesystem device="/dev/sdb" \
directory="/shared" fstype="gfs2" "options=noatime,nodiratime" op \
monitor interval=10s on-fail=fence clone interleave=true
pcs constraint order start clvmd-clone then clusterfs-clone
pcs constraint colocation add clusterfs-clone with clvmd-clone

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

pcs status resources

Врешті-решт, якщо у вас все вийшло правильно, ви повинні побачити, що файлова система /shared буде доступна на кожному з вузлів.

Тести продуктивності
Для тестів використовувався простий скрипт, послідовно читає і записує дані з кожного з вузлів через dd, наприклад:

dd if=/shared/file of=/dev/null bs=32M iflag=direct
dd if=/root/file of=/shared/file bs=32M oflag=direct

Розмір блоку виставлений великий, читання проводиться в режимі 'direct' для тестування власне файлової системи, а не швидкості роботи з дисковим кешем. Результати вийшли наступні:

pic1
Рис.1. Одночасне читання зі всіх віртуальних вузлів кластерів різних розмірів. Продуктивність одного вузла.

pic2
Рис.2. Одночасне читання зі всіх віртуальних вузлів кластерів різних розмірів. Сукупна продуктивність.

pic3
Рис.3. Одночасний запис зі всіх віртуальних вузлів кластерів різних розмірів. Продуктивність одного вузла.

pic4
Рис.4. Одночасний запис зі всіх віртуальних вузлів кластерів різних розмірів. Сукупна продуктивність

Висновки
Які можна зробити висновки:

  • читання практично впирається у пропускну здатність мережі (~9 Гбіт, Infiniband, IPoIB) і непогано масштабується при збільшенні кількості вузлів віртуального кластера;

  • запис впирається в практичний стеля і не масштабується. Але з урахуванням зроблених припущень нас це поки влаштовує. Механізм, який зумовив наявність такої стелі, нам залишився поки не ясний.
Підводні камені
До підводних каменів можна віднести необхідність коректного зупинки як мінімум останньою зі всіх віртуальних машин, що використовують кластер. Інакше файлова система може опинитися в стані, що вимагає відновлення. Серйозною проблемою є також коректна налаштування fencing для відключення від pcs вузла кластера, що втратив синхронізацію з іншими. Але про це в наступних статтях.

Матеріал підготовлений Андрієм Ніколаєвим, Денисом Луньовим, Ганною Субботіної.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.