Ця стаття написана для того, щоб допомогти вибрати для себе відповідне рішення та зрозуміти відмінності між такими SDS як Gluster, Ceph та Vstorage (Virtuozzo).
У тексті використовуються посилання на статті з детальнішим розкриттям тих чи інших проблем, тому описи будуть максимально короткими з використанням ключових моментів без зайвої води та вступної інформації, яку ви зможете за бажання самостійно видобути на просторах інтернету.
Насправді звичайно торкнуті теми вимагають тони тексту, але в сучасному світі все більше і більше люди не люблять багато читати))), тому можна швидко прочитати і зробити вибір, а якщо що незрозуміло пройтися за посиланнями або погуглити незрозумілі слова))), а ця стаття як прозора обгортка для цих глибоких тем, що показує начинку, – головні ключові моменти кожного рішення.
Глюстер
Почнемо з Gluster, який активно використовується у виробників гіперконвергентних платформ із SDS на базі open source для віртуальних середовищ і його можна знайти на сайті RedHat у розділі storage, де пропонується вибрати із двох варіантів SDS: Gluster або Ceph.
Gluster складається з стека трансляторів - служби, які виконують всі роботи з розподілу файлів і т.д. Brick - служба яка обслуговує один диск, Volume - том (пул) - який поєднує ці brick'і. Далі йде служба розподілу файлів груп за рахунок функції DHT(distributed hash table). Службу Sharding включати в опис не будемо, оскільки в нижче викладених посиланнях буде опис проблем, пов'язаних з нею.
При записі файл повністю лягає в brick та його копія паралельно пишеться на brick другого сервера. Далі другий файл вже записуватиметься в другу групу з двох brіsk (або більше) на різних серверах.
Якщо файли приблизно одного розміру і тому складаються тільки з однієї групи, то все нормально, але за інших умов виникнуть з описів такі проблеми:
- місце в групах утилізується нерівномірно, це залежить від розмірів файлів і якщо в групі недостатньо місця для запису файлу - ви отримаєте помилку, файл не буде записано і не буде перерозподілено в іншу групу;
- при записі одного файлу IO йде лише одну групу, інші простоюють;
- не можна отримати IO всього тому під час запису одного файла;
- і загальна концепція виглядає менш продуктивною за рахунок відсутності розподілу даних по блоках, де простіше здійснити балансування та вирішити проблему рівномірного розподілу, а не як зараз файл лягає в брик повністю.
З офіційного опису також мимоволі приходить розуміння, що gluster працює як файлове сховище поверх класичного апаратного RAID. Були спроби розробки нарізати (Sharding) файли на блоки, але все це доповнення, яке накладає втрати продуктивності до вже існуючого архітектурного підходу плюс використання таких вільно поширюваних компонентів з обмеженням у продуктивності як Fuse. Немає сервісів метаданих, що обмежує за можливостями продуктивності та відмовостійкості сховище при розподілі файлів на блоки. Більш хороші показники продуктивності можна спостерігати при конфігурації “Distributed Replicated” і кількість нод має бути не менше 6 для організації надійної 3 репліки з оптимальним розподілом навантаження.
Ці висновки також пов'язані з описом досвіду використання і при порівнянні з , а також є опис досвіду до приходу розуміння цієї більш продуктивної та надійнішої конфігурації
У малюнку показано розподіл навантаження при запису двох файлів, де копії першого файлу розкладаються по трьох перших серверах, які об'єднані в volume 0 групу і три копії другого файлу лягають на другу групу volume1 з трьох серверів. Кожен сервер має один диск.
Загальний висновок такий, що використовувати можна Gluster, але з розумінням того, що у продуктивності та стійкості до відмови будуть обмеження, які створюють труднощі за певних умов гіперконвергентного рішення, де ресурси потрібні ще й для обчислювальних навантажень віртуальних середовищ.
Є деякі також показники продуктивності Gluster, яких можна досягти за певних умов обмежуючись в
Сеф
Тепер розглянемо Сeph з описів архітектури, які мені вдалося Також є порівняння між , де можна відразу зрозуміти, що Ceph бажано розгортати на окремих серверах, тому що його сервісам необхідні всі ресурси заліза при навантаженнях.
Архітектура більш складно ніж Gluster і є такі сервіси як служби метаданих, але весь стек компонентів досить непростий і не дуже гнучкий для використання його у вирішенні з віртуалізацією. Дані укладаються по блоках, що виглядає більш продуктивним, але є в ієрархії всіх служб (компонентів), втрати та latency за певних навантажень та аварійних умов у приклад наступна
З опису архітектури серцем виступає CRUSH, завдяки якому вибирається місце розміщення даних. Далі йде PG - це найскладніша абстракція (логічна група) для розуміння. PG потрібні для того, щоб CRUSH був більш ефективним. Основне призначення PG - угруповання об'єктів для зниження ресурс-споживання, підвищення продуктивності та масштабованості. Адресація об'єктів на пряму, окремо, без об'єднання їх у PG була б дуже затратною. OSD – це сервіс кожного окремого диска.
Кластер може мати один або багато пулів даних різного призначення та з різними налаштуваннями. Пули поділяються на плейсмент-групи. У плейсмент-групах зберігаються об'єкти, до яких звертаються клієнти. На цьому логічний рівень закінчується, і починається фізичний, тому що за кожною плейсмент-групою закріплений один головний диск та кілька дисків-реплік (скільки залежить від фактора реплікації пула). Іншими словами, логічно об'єкт зберігається в конкретній плейсмент-групі, а на фізичному — на дисках, які за нею закріплені. При цьому диски фізично можуть бути на різних вузлах або навіть у різних датацентрах.
У цій схемі плейсмент-групи виглядають як необхідний рівень для гнучкості всього рішення, але в той же час і як зайва ланка цього ланцюжка, що мимоволі наводить думки про втрату продуктивності. Наприклад при записі даних системі необхідно розбивати їх на ці групи і потім фізично на головний диск і на диски для реплік. Тобто функція Хеш працює при пошуку і вставці об'єкта, але є побічний ефект - це дуже великі витрати і обмеження на перебудову хеша (при додаванні, видаленні диска). Ще одна проблема хеша – це чітко прибите розташування даних, які не можна міняти. Тобто якщо якось диск відчуває підвищене навантаження, то система не може не писати на нього (вибравши інший диск), хеш функція зобов'язує розташовувати дані за правилом, незалежно від того наскільки диску погано, тому Ceph їсть багато пам'яті при перебудові PG в у разі self-healing або збільшення сховища. Висновок, що Ceph працює добре (хоч і повільно), але тільки коли немає масштабування, аварійних ситуацій та оновлення.
Є звичайно варіанти підвищення продуктивності за рахунок кешування та кеш-тирінгу, але при цьому необхідно хороше залізо і все одно будуть втрати. Але в цілому Ceph виглядає привабливіше ніж Gluster для продуктива. Також при використанні цих продуктів необхідно враховувати важливий фактор – це високий рівень компетенцій, досвіду та професіоналізму з великим акцентом на linux, тому що дуже важливо все правильно розгорнути, налаштувати та підтримувати, що накладає ще більше відповідальності та навантаження на адміністратора.
Vstorage
Ще цікавіше виглядає архітектура у , яку можна використовувати спільно з гіпервізором на тих же вузлах, на тому ж , але дуже важливо правильно все налаштувати, щоб досягти хорошої продуктивності. Тобто розгорнувши такий продукт з коробки, на яку потрапило конфігурації без урахування рекомендацій відповідно до архітектури, буде дуже легко, але не продуктивно.
Що ж може співіснувати для зберігання поряд з сервісами гіпервізора kvm-qemu, а це лише кілька служб, де знайдено компактну оптимальну ієрархію компонентів: сервіс клієнта, що монтується через FUSE (модифікований, не open source), служба метаданих MDS (Metadata service), служба блоків даних Chunk service, яка фізично дорівнює одному диску і на цьому все. За швидкістю звичайно оптимально використовувати стійку відмову схему в дві репліки, але якщо задіяти кешування і журнали на диски SSD, то завадостійке кодування (erase coding або raid6) можна пристойно розігнати на гібридній схемі або навіть краще на all flash. З EC(erase coding) деякий мінус: при зміні одного блоку даних необхідно перерахувати суми парності. Для обходу втрат на цю операцію Сeph пише в EC відкладено і проблеми з продуктивністю можуть статися при певному запиті, коли, наприклад, знадобляться рахувати всі блоки, а у випадку з Virtuozzo Storage запис змінених блоків здійснюється використовуючи підхід “log-structured file system”, що мінімізує витрати на обчислення парності. Щоб прикинути приблизно варіанти з прискоренням роботи у EC та без, є – цифри можна отримати приблизно залежить від коефіцієнта точності виробника обладнання, але результат обчислень добре допомагає запланувати конфігурацію.
Проста схема компонентів зберігання не означає, що ці компоненти не поглинають Але якщо підрахувати всі витрати заздалегідь, можна розраховувати спільну роботу поруч із гипервизором.
Існує схема порівняння споживання ресурсів заліза службами Seph і Virtuozzo storage.
Якщо раніше порівнювати Gluster і Ceph можна було за старими статтями, використовуючи найважливіші рядки, то з Virtuozzo складніше. Статей з цього продукту не так багато і інформацію можна черпати тільки з документації на або російською якщо розглядати Vstorage як сховища, що використовується в деяких гіперконвергентних рішеннях в таких компаніях як та Акроніс.
Спробую допомогти з описом цієї архітектури, тому тексту буде трохи більше, але щоб самому розібратися в документації необхідно багато часу, а наявну документацію можна використовувати тільки як довідник за допомогою перегляду змісту або пошук за ключовим словом.
Розглянемо процес запису в гібридній конфігурації заліза з вище описаними компонентами: запис починає йти на той вузол з якого її ініціював клієнт (служба точки монтування FUSE), але компонент майстер служби метаданих (MDS) звичайно направить клієнта на пряму до потрібного сервісу сервісу (службі зберігання) блоків CS), тобто MDS не бере участі в процесі запису, а просто спрямовує на необхідний сервіс обслуговування. Загалом можна навести аналогію запису з розливом води бочками. Кожна бочка це блок даних в 256МБ.
Тобто один диск, це якась кількість таких бочок, тобто об'єм диска поділити на 256МБ. Кожна копія розливається на один вузол, друга майже паралельно вже на інший вузол і т.д. Якщо у нас три репліки і є SSD диски для кешу (під читання та журнали запису), то підтвердження запису буде відбуватися після запису журналу в SSD, а паралельне скидання з SSD буде продовжуватися на HDD, як у фоновому режимі. У разі трьох реплік коміт запис буде після підтвердження від SSD третього вузла. Може здатися, що суму швидкості запису трьох SSD можна поділити на три і ми отримаємо швидкість запису однієї репліки, але запис копій йде паралельно і швидкість мережі Latency зазвичай вище, ніж у SSD, і по суті продуктивність запису буде залежати від мережі. У зв'язку з цим, щоб побачити реальні IOPS необхідно правильно навантажити весь Vstorage по тобто тестувати реальне навантаження, а не пам'ять і кеш, де необхідно врахувати правильний розмір блоку даних, кількість потоків і т.д.
Вище згаданий журнал запису на SSD працює так, що як тільки в нього потрапляють дані, то відразу зчитуються службою і пишуться на HDD. Служб метаданих (MDS) дещо на кластер та їх кількість визначається кворумом, який працює за алгоритмом Paxos. З точки зору клієнта точка монтування FUSE, це папка кластерного сховища, яка одночасно видно всім нодам кластера, кожна нода має змонтованого клієнта за таким принципом, тому кожному вузлу доступне це сховище.
Для продуктивності будь-якого з вище описаного підходу дуже важливо, на етапі планування та розгортання, правильно налаштувати мережу, де буде балансування за рахунок агрегації та правильно підібрана пропускна спроможність мережного каналу. В агрегації важливо правильно підібрати режим хешування та розміри кадрів. Є також дуже сильна відмінність від вище описаних SDS, це fuse з технологією fast path у Virtuozzo Storage. Який повз модернізований fuse на відміну від інших open source рішень, значно додає IOPS-ів і дозволяє не обмежуватися горизонтальним або вертикальним масштабуванням. Загалом у порівнянні з вище описаними архітектурами ця виглядає більш потужною, але за таке задоволення звичайно необхідно купувати ліцензії на відміну від Сeph і Gluster.
Підбиваючи підсумки можна підкреслити топом із трьох: перше місце за продуктивністю та надійністю архітектури займає Virtuozzo Storage, друге Ceph та третє Gluster.
Критерії, за яким вибраний Virtuozzo Storage: це оптимальний набір компонентів архітектури, модернізований під цей підхід Fuse з fast path, гнучкий набір конфігурації заліза, менше споживання ресурсів та можливість спільного використання з compute (обчисленнями/віртуалізації), тобто повністю підходить для гіперконвергентного рішення , у складі якого і йде. Друге місце Ceph, тому що це більш продуктивна архітектура перед Gluster, за рахунок оперування блоками, а також більш гнучкими сценаріями та можливістю роботи у більш масштабних кластерах.
У планах є бажання написати порівняння між vSAN, Space Direct Storage, Vstorage та Nutanix Storage, тестування Vstorage на устаткуванні HPE, Huawei, а також сценарії інтеграції Vstorage із зовнішніми апаратними СХД, тому якщо стаття вам сподобалася, то непогано було б отримати від вас відгуки , які могли б посилити мотивацію на нові статті з урахуванням ваших зауважень та побажань.
Джерело: habr.com