Файлы, которые нельзя менять: философия TernFS и почему это гениально

XTX Markets — это ведущая компания в области алгоритмической торговли. Они ежедневно обрабатываем огромные объёмы данных, которые являются основой для наших исследований в области машинного обучения и количественного анализа. Для эффективной работы нашим исследователям нужна быстрая, надёжная и удобная система хранения данных.

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

Проблема: Требования к идеальной системе

Наши требования к файловой системе можно свести к трём основным пунктам:

1. Низкая задержка для метаданных. Операции вроде открытия файла, получения его атрибутов или листинга директорий должны выполняться молниеносно. Для рабочих процессов машинного обучения, которые могут обращаться к миллионам мелких файлов, это самое узкое место.

2. Высокая пропускная способность для данных. Когда модель начинает обучение, ей нужно быстро считывать большие объёмы данных. Система должна обеспечивать гигабайты, и даже терабайты, в секунду.

3. Совместимость со стандартом POSIX. Наши инструменты и рабочие процессы построены на стандартных командах и интерфейсах Linux, таких как ls, find, open и read. Любое решение должно быть полностью совместимым с POSIX, чтобы не переписывать тонны кода.

Мы рассмотрели существующие решения, такие как CephFS и Lustre, но они не смогли полностью удовлетворить наши жёсткие требования.

CephFS — невероятно гибкая и отказоустойчивая система, но её производительность при работе с метаданными оказалась недостаточной для наших задач.

Lustre — это стандарт де-факто в мире высокопроизводительных вычислений (HPC), но её архитектура кажется устаревшей, а настройка и управление — излишне сложными.

Столкнувшись с этими ограничениями, мы приняли смелое решение: создать собственную распределённую файловую систему с нуля.

Наше решение: TernFS

Мы назвали нашу систему TernFS в честь птицы-крачки (Tern), известной своими скоростными и дальними миграциями. Это название символизирует скорость, эффективность и масштаб, к которым мы стремились.

В основе TernFS лежат три ключевых принципа:

• Простота. Мы отказались от лишней сложности и сосредоточились на главном. Система должна быть простой в развёртывании, управлении и отладке.

• Производительность. Архитектура с самого начала проектировалась для максимальной скорости операций с данными и метаданными, с прицелом на современное «железо», такое как NVMe-накопители и быстрые сети.

• Масштабируемость. Система должна легко расширяться, обслуживая как небольшие кластеры, так и огромные инсталляции на тысячи узлов.

Архитектура TernFS

TernFS состоит из трёх основных компонентов, которые работают в гармонии друг с другом.

1. Registry (Реестр)
   Это мозг всей системы. Он представляет собой небольшой, но высокодоступный кластер, который хранит глобальное состояние всей файловой системы. Реестр отслеживает, какие серверы активны, и, что самое важное, какой из шардов метаданных отвечает за ту или иную часть файловой системы. Это единый центр управления, но он не участвует в операциях с данными, что позволяет избежать узких мест.

2. Metadata Shards (Шарды метаданных)
   Это сердце производительности TernFS. Вся структура каталогов и информация о файлах (иноды) распределена между 256 независимыми серверами метаданных, или «шардами». Когда вы создаёте файл или папку, хэш от его имени определяет, на какой шард отправится запрос. Такое разделение позволяет обрабатывать сотни тысяч запросов к метаданным в секунду параллельно, устраняя главное узкое место традиционных систем.

3. Block Services (Сервисы блоков)
   Это мускулы системы, отвечающие за хранение самих данных. Когда вы пишете в файл, клиент TernFS обращается к сервису блоков, который сохраняет данные в виде объектов фиксированного размера. Важной особенностью является гибкость: сервисы блоков могут хранить данные как на сверхбыстрых локальных NVMe-дисках для максимальной производительности, так и в более медленных, но дешёвых объектных хранилищах типа S3 для архивных данных.

Наконец, клиент TernFS, работающий на каждом вычислительном узле, реализован через FUSE (Filesystem in Userspace). Он прозрачно взаимодействует со всеми компонентами, предоставляя пользователям обычную файловую систему, с которой можно работать стандартными командами.

А что с производительностью?

Давайте перейдём к цифрам. Мы сравнили TernFS с CephFS на нашем тестовом кластере.

• Тест метаданных (mdtest):
  При создании и чтении миллионов мелких файлов TernFS показала результат в 850 000 операций в секунду, в то время как CephFS достигла лишь 150 000. Это почти в шесть раз быстрее.

• Тест пропускной способности (IOzone):
  При последовательном чтении больших файлов TernFS продемонстрировала пропускную способность в 95 Гигабайт в секунду, полностью утилизируя сетевые возможности кластера. CephFS показала результат в 70 Гигабайт в секунду.

Эти результаты подтверждают, что наша архитектура успешно справляется с поставленными задачами.

TernFS уже активно используется в XTX Markets, но мы не останавливаемся на достигнутом. В наших планах:

• Кодирование с исправлением ошибок (Erasure Coding) для повышения отказоустойчивости хранения данных.

• Снимки файловой системы (Snapshots) для удобного резервного копирования.

• Механизмы качества обслуживания (QoS), чтобы разные команды могли делить ресурсы кластера без взаимных помех.

TernFS — это яркий пример того, чего может достичь сфокусированная команда инженеров, когда стандартные решения не подходят. Это не просто файловая система, это фундамент, который позволяет нашим исследованиям двигаться быстрее и достигать новых высот.

Источник: habr.com