Знайомство з сховищем Ceph в картинках

Хмарні файлові сховища продовжують набирати популярність, і вимоги до них продовжують рости. Сучасні системи вже не в змозі повністю задовольнити всі ці вимоги без значних витрат ресурсів на підтримку та масштабування цих систем. Під системою я розумію кластер з тим або іншим рівнем доступу до даних. Для користувача важлива надійність зберігання і висока доступність, щоб можна було завжди легко і швидко отримати, а ризик втрати даних прагнув до нуля. У свою чергу для постачальників і адміністраторів таких сховищ важлива простота підтримки, масштабованість і низька вартість апаратних і програмних компонентів.

Знайомтеся: Ceph
Ceph — це програмно визначається розподілена файлова система з відкритим вихідним кодом, позбавлена вузьких місць і єдиних точок відмови, яка представляє з себе легко масштабований до петабайтных розмірів кластер вузлів, що виконують різні функції, забезпечуючи зберігання і реплікацію даних, а також розподіл навантаження, що гарантує високу доступність і надійність. Система безкоштовна, хоча розробники можуть надати платну підтримку. Ніякого спеціального устаткування не потрібно.



При виході будь-якого диска, вузла або групи вузлів з ладу Ceph не тільки забезпечить збереження даних, але і сам відновить втрачені копії на інших вузлах до тих пір, поки вийшли з ладу вузли або диски не замінять на робочі. При цьому ребилд відбувається без секунди простою і прозоро для клієнтів.





Ролі вузлів і демони
Оскільки система програмно визначається і працює поверх стандартних файлових систем і мережних рівнів, можна взяти пачку різних серверів, набити їх різними дисками різного розміру, з'єднати все це щастя якої-небудь мережею (краще швидкої) і підняти кластер. Можна увіткнути в ці сервери за другий мережевій карті, і з'єднати їх другий мережею для прискорення межсерверного обміну даними. А експерименти з налаштуваннями і схемами можна легко проводити навіть у віртуальному середовищі. Мій досвід експериментів показує, що найбільш довгий в цьому процесі — це установка ОС. Якщо у нас є три сервера з дисками та налагодженою мережею, то підняття працездатного кластера з дефолтними налаштуваннями займе 5-10 хвилин (якщо все робити правильно).



Поверх операційної системи працюють демони Ceph, виконують різні ролі кластера. Таким чином один сервер може виступати, наприклад, і в ролі монітора (MON), і в ролі сховища даних (OSD). А інший сервер тим часом може виступати в ролі сховища даних і в ролі сервера метаданих (MDS). У великих кластерах демони запускаються на окремих машинах, але в малих кластерах, де кількість серверів сильно обмежено, деякі сервера можуть виконувати відразу дві або три ролі. Залежить від потужності сервера і самих ролей. Зрозуміло, все буде працювати спритніше на окремих серверах, але не завжди це можливо реалізувати. Кластер можна зібрати навіть з однієї машини і всього одного диска, і він буде працювати. Інша розмова, що це не матиме сенсу. Слід зазначити і те, що завдяки програмної яка визначається, сховище можна підняти навіть поверх RAID або iSCSI-пристрою, проте в більшості випадків це теж не буде мати сенсу.

В документації перераховано 3 види демонів:
  • Mon — демон монітора
  • OSD — демон сховища
  • MDS — сервер метаданих (необхідний тільки в разі використання CephFS)


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



Структура зберігання
Для початку коротко і зрозуміло. Кластер може мати один або багато пулів даних різного призначення і з різними налаштуваннями. Пули діляться на плейсмент-групи. У плейсмент-групах зберігаються об'єкти, до яких звертаються клієнти. На цьому логічний рівень закінчується, і починається фізичний, бо за кожною плейсмент-групою закріплений один головний диск і кілька дисків-реплік (скільки саме залежить від фактора реплікації пулу). Іншими словами, на логічному рівні об'єкт зберігається в конкретній плейсмент-групі, а на фізичному — на дисках, які за нею закріплені. При цьому диски фізично можуть знаходитися на різних вузлах або навіть в різних датацентрах.



Далі докладно & зрозуміло.

Фактор реплікації (RF)
Фактор реплікації — це рівень надлишковості даних. Кількість копій даних, яка буде зберігатися на різних дисках. За цей параметр відповідає змінна size. Фактор реплікації може бути різним для кожного пулу, і його можна змінювати " на льоту. Взагалі, в Ceph практично всі параметри можна змінювати «на льоту», миттєво одержуючи реакцію кластера. Спочатку у нас може бути size=2, і в цьому випадку, пул буде зберігати по дві копії одного шматка даних на різних дисках. Цей параметр пулу можна поміняти на size=3, і в цей же момент кластер почне перерозподіляти дані, розкладаючи ще одну копію вже наявних даних по дискам, не зупиняючи роботу клієнтів.

Пул
Пул — це логічний абстрактний контейнер для організації зберігання даних користувача. Будь-які дані зберігаються в пулі у вигляді об'єктів. Кілька пулів можуть бути розмазані по одним і тим же дисків (а може і по різним, як налаштувати за допомогою різних наборів плейсмент-груп. Кожен пул має ряд параметрів: фактор реплікації, кількість плейсмент-груп, мінімальна кількість живих реплік об'єкта, необхідне для роботи і т. д. Кожного пулу можна налаштувати свою політику реплікації (по містах, датацентрах, стійок або навіть дисків). Наприклад, пул під хостинг може мати фактор реплікації size=3, а зоною відмови будуть датацентри. І тоді Ceph буде гарантувати, що кожен шматочок даних має по одній копії до трьох датацентрах. Тим часом, пул для віртуальних машин може мати фактор реплікації size=2, а рівнем відмови вже буде серверна стійка. І в цьому випадку, кластер буде зберігати тільки дві копії. При цьому, якщо у нас дві стійки з сховищем віртуальних образів в одному датацентрі, і дві стійки в іншому, система не буде звертати увагу на датацентри, і обидві копії даних можуть полетіти в один датацентр, проте гарантовано в різні стійки, як ми і хотіли.

Плейсмент-група (PG)
Плейсмент-групи — це сполучна ланка між фізичним рівнем зберігання (диски) і логічною організацією даних (пули).

Кожен об'єкт на логічному рівні зберігається в конкретній плейсмент-групі. На фізичному рівні, він лежить в потрібній кількості копій на різних фізичних дисках, які в цю плейсмент-групу включені (насправді не диски, а OSD, але зазвичай один OSD це і є один диск, і для простоти я буду називати це диском, хоча нагадаю, що за ним може бути і RAID-масив або iSCSI-пристрій). При факторі реплікації size=3, кожна плейсмент група включає в себе три диска. Але при цьому кожен диск знаходиться в безлічі плейсмент-груп, і для будь-яких груп він буде первинним, для інших — реплікою. Якщо OSD входить, наприклад, до складу трьох плейсмент-груп, то при падінні такого OSD, плейсмент-групи виключать його з роботи, і на його місце кожна плейсмент-група вибере робочий OSD і розмаже по ньому дані. За допомогою даного механізму і досягається досить рівномірний розподіл даних і навантаження. Це досить просте і одночасно гнучке рішення.



Монітори
Монітор — це демон, що виконує роль координатора, з якого починається кластер. Як тільки у нас з'являється хоча б один робочий монітор, у нас з'являється Ceph-кластер. Монітор зберігає інформацію про здоров'я і стан кластера, обмінюючись різними картами з іншими моніторами. Клієнти звертаються до моніторів, щоб дізнатися, на які OSD писати/читати дані. При розгортанні нового сховища, насамперед створюється монітор (або кілька). Кластер може прожити на одному моніторі, але рекомендується робити 3 або 5 моніторів, щоб уникнути падіння всієї системи через падіння єдиного монітора. Головне, щоб їх було непарним, щоб уникнути ситуацій роздвоєння свідомості (split-brain). Монітори працюють кворуму, тому якщо впаде більше половини моніторів, кластер заблокується для запобігання неузгодженості даних.

OSD (Object Storage Device)
OSD — це юніт сховища, який зберігає самі дані і обробляє запити клієнтів, обмінюючись даними з іншими OSD. Зазвичай це диск. І зазвичай за кожен OSD відповідає окремий OSD-демон, який може запускатися на будь-якій машині, на якій встановлено цей диск. Це друге, що треба додавати в кластер, при розгортанні. Один монітор і один OSD — мінімальний набір для того, щоб підняти кластер і почати ним користуватися. Якщо на сервері крутиться 12 дисків під сховище, то на ньому буде запущено стільки ж OSD-демонів. Клієнти працюють безпосередньо з самими OSD, минаючи вузькі місця і досягаючи, тим самим, розподілу навантаження. Клієнт завжди записує об'єкт на первинний OSD для будь-плейсмент групи, а вже далі даний OSD синхронізує дані з іншими (вторинними) OSD з цієї ж плейсмент-групи. Підтвердження успішної запису може відправлятися клієнту відразу ж після запису на первинний OSD, а може після досягнення мінімального кількості записів (параметр пулу min_size). Наприклад, якщо фактор реплікації size=3, а min_size=2, то підтвердження про успішну запису відправиться клієнтові, коли об'єкт запишеться хоча б на два OSD з трьох (включаючи первинний).

При різних варіантах налаштування цих параметрів, ми будемо спостерігати і різну поведінку.

Якщо size=3 і min_size=2: все буде добре, поки що 2 з 3 OSD плейсмент-групи живі. Коли залишиться всього лише 1 живою OSD, кластер заморозить операції даної плейсмент-групи, поки не оживе хоча б ще один OSD.

Якщо size=min_size, то плейсмент-група буде блокуватися при падінні будь-якого OSD, що входить до її складу. А з-за високого рівня размазанности даних, більшість падінь хоча б одного OSD буде закінчуватися заморожуванням всього або майже всього кластера. Тому параметр size завжди повинен бути хоча б на один пункт більше параметра min_size.

Якщо size=1, кластер буде працювати, але смерть будь OSD буде означати безповоротну втрату даних. Ceph дозволяє виставити цей параметр одиницю, але навіть якщо адміністратор робить це з певною метою на короткий час, він ризик бере на себе.

Диск OSD складається з двох частин: журнал і самі дані. Відповідно, дані спочатку записуються в журнал, а потім вже в розділ даних. З одного боку це дає додаткову надійність і деяку оптимізацію, а з іншого боку — додаткову операцію, що позначається на продуктивності. Питання продуктивності журналів розглянемо нижче.

Алгоритм CRUSH
В основі механізму децентралізації та розподілу лежить так званий CRUSH-алгоритм (Controlled Replicated Under Scalable Hashing), що грає важливу роль в архітектурі системи. Цей алгоритм дозволяє однозначно визначити місце розташування об'єкта, на основі хеш імені об'єкта і певною карти, яка формується виходячи з фізичної та логічної структур кластера (датацентри, зали, ряди, стійки, вузли, диски). Карта не включає в себе інформацію про місцезнаходження даних. Шлях до даних кожний клієнт визначає самостійно, з допомогою CRUSH-алгоритму та актуальною карти, яку він попередньо запитує у монітора. При додаванні диска або падіння сервера, карта оновлюється.

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

Приклад:



Клієнт хоче записати якийсь об'єкт object1 в пул Pool1. Для цього він дивиться в карту плейсмент-груп, яку йому раніше люб'язно надав монітор, і бачить, що Pool1 розділений на 10 плейсмент-груп. Далі з допомогою CRUSH-алгоритму, який на вхід приймає ім'я об'єкта і загальна кількість плейсмент-груп в пулі Pool1, обчислюється ID плейсмент-групи. Слідуючи карті, клієнт розуміє, що за цією плейсмент-групою закріплено три OSD (припустимо, їх номери: 17, 9 і 22), перший з яких є первинним, а значить клієнт буде робити запис саме на нього. До речі, їх три, тому що в цьому пулі встановлений фактор реплікації size=3. Після успішної запису об'єкта на OSD_17, робота клієнта закінчена (це якщо параметр пулу min_size=1), а OSD_17 повторює цей об'єкт на OSD_9 і OSD_22, закріплені за цією плейсмент-групою. Важливо розуміти, що це спрощене пояснення роботи алгоритму.

За замовчуванням наша CRUSH-плоска карта, всі ноди знаходяться в одному просторі. Однак, можна цю площину легко перетворити в дерево, розподіливши сервери за стійок, стійки по рядах, ряди по залах, зали з датацентрах, а датацентри по різних містах і планетам, вказавши який рівень вважати зоною відмови. Оперуючи такою новою картою, Ceph буде грамотно розподіляти дані, враховуючи індивідуальні особливості організації, запобігаючи сумні наслідки пожежі в датацентрі або падіння метеорита на ціле місто. Більше того, завдяки цьому гнучкого механізму, можна створювати додаткові шари, як на верхніх рівнях (датацентри і міста), так і на нижніх (наприклад, додаткове поділ на групи дисків в рамках одного сервера).

Кешування
Ceph передбачає кілька способів збільшення продуктивності кластера методами кешування.

Primary-Affinity
У кожного OSD є кілька ваг, і один з них відповідає за те, якою OSD в плейсмент-групі буде первинним. А, як ми з'ясували раніше, клієнт пише дані саме на первинний OSD. Так от, можна додати в кластер пачку SSD дисків, зробивши їх завжди первинними, знизивши вагу primary-affinity HDD дисків до нуля. І тоді запис буде здійснюватися завжди спочатку на швидкий диск, а потім вже не поспішаючи правильно на повільні. Цей метод самий неправильний, проте найпростіший в реалізації. Головний недолік в тому, що одна копія даних завжди буде лежати на SSD і потрібно дуже багато таких дисків, щоб повністю покрити реплікацію. Хоча цей спосіб хтось і застосовував на практиці, але його я скоріше згадав для того, щоб розповісти про можливості управління пріоритетом запису.

Винос журналів на SSD
Взагалі, левова частка продуктивності залежить від журналів OSD. Здійснюючи запис, демон спочатку пише дані в журнал, а потім саме сховище. Це правильно завжди, окрім випадків використання BTRFS в якості файлової системи на OSD, яка може робити це паралельно завдяки техніці copy-on-write, але я так і не зрозумів, наскільки вона готова до промислового застосування. На кожен OSD йде власний журнал, і за замовчуванням він знаходиться на тому ж диску, що й самі дані. Однак, журнали з чотирьох або п'яти дисків можна винести на один SSD, непогано прискоривши операції запису. Метод не дуже гнучкий і зручний, але досить простий. Недолік методу в тому, що при вильоті SSD з журналом, ми втратимо відразу кілька OSD, що не дуже приємно і вносить додаткові труднощі у всю подальшу підтримку, яка скаліруется із зростанням кластера.

Кеш-тиринг
Ортодоксальність даного методу в його гнучкості і масштабованості. Схема така, що у нас є пул з холодними даними і пул з гарячими. При частому зверненні до об'єкта, той як би нагрівається і потрапляє в гарячий пул, який складається з найшвидших SSD. Потім, якщо об'єкт остигає, він потрапляє в холодний пул з повільними HDD. Дана схема дозволяє легко змінювати SSD в гарячому пулі, який у свою чергу може бути будь-якого розміру, бо параметри нагріву і охолодження регулюються.


З точки зору клієнта

Ceph надає для клієнта різні варіанти доступу до даних: блочний пристрій, файлова система або об'єктне сховище.



Блочний пристрій (RBD, Rados Block Device)
Ceph дозволяє в пулі даних створити блочний пристрій RBD, і надалі змонтувати його на операційних системах, які це підтримують (на момент написання статті були тільки різні дистрибутиви linux, однак FreeBSD і VMWare теж працюють в цю сторону). Якщо клієнт не підтримує RBD (наприклад Windows), то можна використовувати проміжний iSCSI target з підтримкою RBD (наприклад, tgt-rbd). Крім того, таке блочний пристрій підтримує снапшоти.

Файлова система CephFS
Клієнт може змонтувати файлову систему CephFS, якщо у нього linux з версією ядра 2.6.34 або новіше. Якщо версія ядра старше, то можна змонтувати її через FUSE (Filesystem in User Space). Для того, щоб клієнти могли підключати Ceph як файлову систему, необхідно в кластері підняти хоча б один сервер метаданих (MDS)

Шлюз об'єктів
З допомогою шлюзу НАRGW (RADOS Gateway) можна дати клієнтам можливість користуватися сховищем через RESTful Amazon S3 або OpenStack Swift сумісний API.

...
Всі ці рівні доступу до даних працюють поверх рівня RADOS. Список можна доповнити, розробивши свій шар доступу до даних за допомогою librados API (через який і працюють перераховані вище шари доступу). На даний момент є биндинги C, Python, Ruby, Java та PHP

RADOS (Reliable Autonomic Distributed Object Store), якщо в двох словах, то це шар взаємодії клієнтів і кластера.

Вікіпедія говорить, що сам Ceph написаний на C++ і Python, а в розробці беруть участь компанії Canonical, CERN, Cisco, Fujitsu, Intel, Red Hat, SanDisk, and SUSE.

Враження

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

Те, що Ceph гнучкий, простий і зручний, ми з'ясували. Кластер можна підняти на будь-якому залозі в звичайній мережі, витративши мінімум часу і сил, при цьому Ceph сам буде піклуватися про збереження даних, вживаючи необхідних заходів у разі збоїв заліза. У тому, що Ceph гнучкий, простий і масштабований сходиться безліч точок зору. Однак відгуки про продуктивності зустрічаються досить різноманітні. Можливо хтось не впорався з журналами, когось підвела мережу і затримки в операціях вводу/виводу. Тобто, змусити кластер працювати — легко, але змусити його працювати швидко — можливо, складніше. Тому, я закликаю до ІТ-фахівцям, які мають досвід використання Ceph в продакшені. Поділіться в коментарях про негативні враження.

Посилання
Сайт Ceph
Вікіпедія
Документація
GitHub
Книга рецептів Ceph
Книга Learning Ceph

Джерело: Хабрахабр

0 коментарів

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