Перейти к основному содержимому

Отчёт Jepsen по анализ устойчивости NATS JetStream 2.12.1 и что это значит для инженеров KOMRAD SIEM

· 8 мин. чтения
КОМРАД
КОМРАД
Команда КОМРАД

Аннотация​

Для пользователей KOMRAD SIEM результаты анализа имеют следующие практические следствия: В начале декабря 2025 года компания Jepsen, являющаяся де-факто отраслевым стандартом в области верификации распределенных систем, опубликовала результаты аудита NATS версии 2.12.1. Поскольку NATS выступает фундаментальным компонентом транспортного слоя (KOMRAD Bus) в архитектуре нашего SIEM-решения, мы считаем необходимым провести открытый технический разбор данного отчета. В настоящей статье рассматриваются методология тестирования, выявленные аномалии в подсистеме JetStream, а также архитектурные компромиссы между производительностью и строгой линеаризуемостью данных.

Детальный разбор аудита Jepsen для NATS 2.12.1

Введение​

Надежность транспортных подсистем является критическим параметром для систем класса SIEM (Security Information and Event Management), где потеря событий безопасности недопустима, а требования к пропускной способности экстремально высоки. KOMRAD SIEM использует NATS в качестве высокопроизводительной шины данных для маршрутизации событий между компонентами нормализации, корреляции и хранения.

Выбор NATS обусловлен его исключительной скоростью и простотой эксплуатации. Однако, как и любая распределенная система, претендующая на обеспечение гарантий доставки (At-Least-Once), NATS JetStream подвержен рискам, связанным с CAP-теоремой. Недавнее исследование Кайла Кингсбери (Kyle Kingsbury), автора проекта Jepsen, проливает свет на граничные условия эксплуатации NATS, что дает нам возможность лучше понимать границы применимости и векторы настройки системы.

Методология тестирования Jepsen​

Аудит проводился на версии NATS Server 2.12.1 с использованием официального Java-клиента. Тестовый стенд включал кластеры из 3 и 5 узлов, работающих в контейнерах LXC под управлением Debian 12. Для симуляции сбоев применялась библиотека Jepsen, а также специализированная файловая система LazyFS.

Ключевой особенностью методологии Jepsen является введение «немезиды» (nemesis) — процесса, который генерирует детерминированные сбои:

  • Сетевые разделения (partitions).
  • Паузы процессов (GC pauses, зависания планировщика).
  • Аварийные завершения процессов (crashes).
  • Симуляция отключения питания (power failure) и порчи данных на диске (bitflips, truncation).

Исследование фокусировалось на проверке гарантий сохранности данных в подсистеме JetStream, которая использует алгоритм консенсуса Raft для репликации логов.

Ключевые результаты анализа​

Отчет Jepsen выявил несколько сценариев, при которых поведение NATS отклонялось от ожидаемой модели строгой согласованности. Ниже приведен детальный разбор обнаруженных аномалий.

1. Асинхронный сброс данных на диск (Lazy fsync)​

Одним из наиболее обсуждаемых аспектов архитектуры NATS является политика работы с дисковой подсистемой. Тесты показали, что по умолчанию NATS вызывает системный вызов fsync для фиксации данных на физическом носителе лишь один раз в две минуты. При этом подтверждение записи (acknowledgement) отправляется клиенту немедленно после записи в страничный кэш ОС (page cache).

Суть проблемы: В случае скоординированного сбоя питания (отказ всего ЦОД или стойки) или каскадного падения ядер ОС на нескольких узлах в течение интервала сброса буфера (2 минуты), данные, которые клиент считает сохраненными, будут безвозвратно утеряны. В тестах Jepsen это приводило к потере десятков тысяч сообщений.

Комментарий для пользователей KOMRAD: Это сознательное архитектурное решение разработчиков NATS, направленное на достижение максимальной пропускной способности (throughput). Для большинства сценариев обработки потоковых данных (логов) риск одновременного сбоя питания на всех узлах кластера считается приемлемым компромиссом ради скорости. Однако администраторам следует учитывать, что NATS по умолчанию не гарантирует Durability (долговечность) на уровне, аналогичном транзакционным СУБД (PostgreSQL, etcd), где fsync вызывается перед каждым коммитом.

2. Риск Split-Brain при сбое одного узла​

Вторым следствием политики «ленивого» fsync стала уязвимость к возникновению ситуации Split-Brain (расщепления мозга) при сбое даже одного узла. Кайлом Кингсбери было продемонстрировано, что комбинация аварийной перезагрузки ОС на одном узле и сетевых задержек может привести к тому, что кластер разделится во мнениях относительно истории лога.

Механизм возникновения аномалии следующий:

  1. Лидер подтверждает запись, имея кворум в памяти (но не на диске).
  2. Один из узлов кворума перезагружается и теряет данные из памяти.
  3. Оставшиеся узлы формируют новый кворум, в котором подтвержденной записи уже не существует.
  4. В результате возникает устойчивая дивергенция реплик.

3. Уязвимость к повреждению метаданных (.blk и snapshot)​

Наиболее тревожным открытием стало поведение NATS при физическом повреждении файлов данных. Jepsen обнаружил, что инверсия одного бита (bitflip) или усечение файлов .blk (где хранятся сами сообщения) или файлов снапшотов Raft может приводить к катастрофическим последствиям.

В ряде тестов повреждение данных на меньшинстве узлов (например, на 1 из 5) приводило к тому, что лидер кластера принимал решение удалить весь поток (Stream) вместе со всеми накопленными данными. Это указывает на недостаточность текущих механизмов проверки целостности (checksums) и логики восстановления Raft-машины состояний при обнаружении коррупции. Разработчики NATS признали проблему и присвоили ей высокий приоритет:

В ходе обсуждения выявленных аномалий ведущие инженеры Synadia дали разъяснения относительно механики повреждения данных. NATS использует контрольные суммы (checksums) как для отдельных сообщений, так и для файлов состояния:

  • Механика усечения (Truncation): Если при восстановлении обнаруживается несовпадение контрольной суммы сообщения, текущее поведение системы заключается в усечении блока данных до момента сбоя. Это связано с тем, что повреждение может затронуть метаданные длины сообщения; в таком случае корректное определение границ следующего сообщения становится невозможным, и система вынуждена отбрасывать весь «хвост» блока (postfix).

  • Проблема синхронизации (Reconciliation): На данный момент в NATS отсутствует активный механизм автоматического заполнения образовавшихся «дыр» в середине потока (mid-stream gaps) за счет репликации с соседних узлов, хотя восстановление хвоста лога работает корректно.

  • Новая политика безопасности: изменена стратегия обработки поврежденных снапшотов. Ранее система могла автоматически удалять поврежденный снапшот и пытаться продолжить работу («papering over issues»), что создавало риск расхождения состояний. Новая логика подразумевает более агрессивное обнаружение ошибок: система откажется запускать поврежденные компоненты (Streams или Consumers), сообщая о статусе Unhealthy («X is not current: group node missing»). Это критически важно для защиты мета-слоя от опасных вторичных эффектов.

Значение для экосистемы KOMRAD SIEM​

Публикация данного отчета — позитивное событие для экосистемы. Открытое тестирование Jepsen является «знаком качества» зрелости продукта: через него проходили Kafka, Elasticsearch, PostgreSQL и другие гиганты индустрии.

Для пользователей KOMRAD SIEM результаты анализа имеют следующие практические следствия:

  1. Валидация выбора архитектуры: Несмотря на выявленные граничные случаи, NATS подтвердил свою способность работать под экстремальной нагрузкой. Проблемы с потерей данных воспроизводились только в условиях жесткой симуляции аварий (LazyFS), которые в реальной инфраструктуре встречаются крайне редко при соблюдении стандартов эксплуатации ЦОД.
  2. Рекомендации по инфраструктуре:
    • Для минимизации рисков, описанных в пункте про повреждение файлов, мы настоятельно рекомендуем использовать файловые системы с контролем целостности (например, ZFS) или надежные RAID-массивы с регулярной проверкой (scrubbing).
    • Для защиты от проблемы Lazy fsync необходимо обеспечивать бесперебойное питание серверных стоек.
  3. Перспективы обновлений: Команда NATS оперативно отреагировала на отчет. Критическая ошибка, приводившая к потере потока при крахе процесса (найденная в версии 2.10.22), уже исправлена в версии 2.10.23. Ожидается, что механизмы защиты от битовых ошибок будут усилены в ближайших патчах ветки 2.12.x.

Заключение​

Исследование Jepsen демонстрирует, что NATS 2.12.1 — это мощный инструмент, который, однако, требует понимания его настроек персистентности. В контексте KOMRAD SIEM, где приоритетом является скорость обработки миллионов событий в секунду, использование NATS остается оправданным.

Мы продолжаем внимательно следить за развитием ядра NATS и интегрируем стабильные патчи безопасности в компоненты KOMRAD Bus по мере их выхода. Прозрачность, которую обеспечивает тестирование Jepsen, позволяет нам строить более предсказуемые и надежные системы безопасности.

В следующей версии KOMRAD SIEM 4.6 будет использоваться NATS JetStream со всеми последними патчами безопасности, включая патчи закрывающие уязвимости обнаруженные в данном анализе. Выход сертифицированной версии KOMRAD SIEM 4.6 ожидается в первой половине 2025 года.

Список литературы и ресурсов​

  1. Kingsbury, K. (2025). NATS 2.12.1 Analysis. Jepsen.io. URL: https://jepsen.io/analyses/nats-2.12.1
  2. Ongaro, D., & Ousterhout, J. (2014). In Search of an Understandable Consensus Algorithm. USENIX ATC '14. (Raft Paper). URL: https://raft.github.io/raft.pdf
  3. Brewer, E. A. (2000). Towards robust distributed systems. PODC '00. (CAP Theorem). URL: https://people.eecs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf
  4. Linux Programmer's Manual. fsync(2) — synchronize a file's in-core state with storage device. URL: https://man7.org/linux/man-pages/man2/fsync.2.html
  5. Synadia Communications. NATS Documentation. URL: https://docs.nats.io/
  6. Ramos, M., Azevedo, J., Kingsbury, K., et al. (2024). When Amnesia Strikes: Understanding and Reproducing Data Loss Bugs with Fault Injection. Proc. VLDB Endow., 17(11), 3017–3030. URL: doi.org/10.14778/3681954.368198
  7. louwrentius (2020). Scrub Your NAS Hard Drives Regularly if You Care About Your Data. URL: [https://louwrentius.com/scrub-your-nas-hard-drives-regularly-if-you-care-about-your-data.html]
  8. Twigg, N., & Synadia Team. (2025). Issue #7549: Stream data corruption handling explanation. GitHub. URL: https://github.com/nats-io/nats-server/issues/7549
  9. Twigg, N. (2025). Pull Request #7566: Meta recovery robustness. GitHub. URL: https://github.com/nats-io/nats-server/pull/7566

Оригинал исследования доступен на сайте jepsen.io: NATS 2.12.1 Analysis