Після річного затишшя у розробці робота над новою гілкою відмовостійкої розподіленої файлової системи и другий кандидат у релізи. Нещодавно зміна власників компанії, що розвиває LizardFS, було прийнято нове керівництво та змінилися розробники. Останні два роки проект відсторонився від спільноти і не приділяв йому належної уваги, але нова команда має намір відродити колишні відносини з спільнотою та налагодити із нею тісну взаємодію. Код проекту написаний мовами С і С++ ліцензій GPLv3.
ЯщіркаFS розподіленою кластерною файловою системою, що дозволяє розосередити дані по різних серверах, але уявити до них доступ у формі єдиного великого розділу, робота з яким здійснюється за аналогією з традиційними дисковими розділами. У розділі з LizardFS, що вмонтовується, підтримуються POSIX-атрибути файлів, ACL, блокування, сокети, канали, файли пристроїв, символічні та жорсткі посилання. Система немає єдиної точки відмови, всі компоненти резервуються. Підтримується розпаралелювання операцій із даними (кілька клієнтів можуть одночасно звертатися до файлів).
Для забезпечення відмовостійкості дані розбиваються на репліки, які розподіляються по різних вузлах з резервуванням (на різних вузлах розміщується кілька копій), - у разі виходу з ладу вузлів або накопичувачів, система продовжує роботу без втрати інформації і автоматично перерозподіляє дані з урахуванням вузлів, що залишилися. Для розширення сховища достатньо підключити до нього нові вузли без припинення роботи на обслуговування (система сама реплікує частину даних на нові сервери та збалансує сховище з урахуванням нових серверів). Аналогічно можна вчинити і для скорочення розміру кластера — можна просто відключити застаріле обладнання, що виводиться зі складу.
Дані та метадані зберігаються окремо. Для роботи рекомендується встановлювати два сервери метаданих, що працюють у режимі master-slave, а також як мінімум два сервери зберігання даних (chunkserver). Додатково для резервування метаданих можуть застосовуватися лог-сервери, що зберігають інформацію про зміну метаданих та дозволяють відновити роботу у разі пошкодження всіх наявних серверів метаданих. Кожен файл розбивається на блоки (chunk) розміром до 64 МБ. Блоки розподіляються по серверам зберігання відповідно до обраного режиму реплікації: стандартний (явне визначення кількості копій для розміщення на різних вузлах, у тому числі в прив'язці до окремих каталогів — для важливих даних кількість копій можна збільшити, а для несуттєвих зменшити), XOR (RAID5 ) та EC (RAID6).
Сховище може масштабуватись до петабайтних розмірів. З областей застосування згадуються ведення архівів, зберігання образів віртуальних машин, мультимедійних даних, резервних копій, використання як DRC (Disaster Recovery Center) та як сховище у кластерах високопродуктивних обчислень. LizardFS забезпечує дуже високу швидкість читання файлів будь-якого розміру, а при записі показує хорошу продуктивність при записі цілком великих та середніх файлів, коли немає постійної модифікації, інтенсивної роботи з відкритими файлами та одноразових операцій з купою дрібних файлів.
Серед особливостей ФС також можна відзначити наявність підтримки снапшотів, що відображають стан файлів у певний час, та вбудовану реалізацію «кошика» (файли не видаляються відразу і якийсь час доступні для відновлення). Доступ до розділу може бути обмежений IP-адресою або паролем (за аналогією з NFS). Є механізми квот та управління якістю сервісу, що дозволяють обмежити розмір та пропускну здатність для деяких категорій користувачів. Можливе створення територіально розподілених сховищ, сегменти яких розміщені у різних датацентрах.
Проект LizardFS був заснований у 2013 році як форк , і відрізняється, головним чином, наявністю режиму реплікації на базі кодів корекції помилок Ріда-Соломона (аналог raidzN), розширеною підтримкою ACL, наявністю клієнта для платформи Windows, додатковими оптимізаціями (напірмер, при суміщенні клієнта та сервера зберігання блоки по можливості віддаються з поточного вузла, а метадані кешуються в пам'яті), більш гнучкою системою налаштування, підтримкою запобіжного читання даних, квотами на каталоги та внутрішніми переробками.
Реліз LizardFS 3.13.0 планується випустити наприкінці грудня. Основним нововведенням LizardFS 3.13 є задіяння для забезпечення стійкості до відмови (перемикання master-серверів у разі збою) алгоритму досягнення консенсусу (Використовується власна реалізація uRaft, яка раніше застосовувалася в комерційних продуктах). Використання uRaft спрощує налаштування та скорочує затримки при відновленні після збою, але вимагає наявності щонайменше трьох працюючих вузлів, один з яких використовується для кворуму.
З інших змін: новий клієнт на базі підсистеми FUSE3, вирішення проблем із коригуванням помилок, плагін nfs-ganesha переписаний мовою Сі. В оновленні 3.13.0-rc2 виправлено кілька критичних помилок, які робили попередні тестові випуски гілки 3.13 малопридатними для використання (виправлення для гілки 3.12 поки не опубліковані, а оновлення з 3.12 на 3.13, як і раніше, призводить до повної втрати даних).
У 2020 році робота буде зосереджена на розробці
, нового повністю переписаного ядра LizardFS, яке, як запевняють розробники, забезпечить збільшення продуктивності в три рази, порівняно з гілкою 3.12. В Agama буде здійснено перехід на подієво-орієнтовану архітектуру (event driven), асинхронне введення/виведення на базі , роботу переважно у просторі користувача (для зниження залежності від механізмів кешування ядра). Додатково буде запропоновано нову підсистему налагодження та аналізатор мережевої активності з підтримкою автотюнінгу продуктивності.
У клієнт LizardFS буде додано повну підтримку версіонування операцій запису, яка підвищить надійність відновлення після збою, вирішить проблеми, що виникають при спільному доступі різних клієнтів до одних даних, і дозволить досягти значного збільшення продуктивності. Клієнт буде переведений на власну мережну підсистему, що працює у просторі користувача. Перший робочий прототип LizardFS на базі Agama планується підготувати у другому кварталі 2020 року. У той же час обіцяють реалізувати кошти для інтеграції LizardFS із платформою Kubernetes.
Джерело: opennet.ru