Андрей Савченко

Avatar1

Савченко Андрей Александрович, ведущий программист ООО «Базальт СПО».
Закончил МИФИ в 2008 году по специальности физика атомного ядра и частиц. В 2008-2017 годах работал в НИЯУ МИФИ, занимаясь как физикой частиц высоких энергий, так и развитием высокопроизводительных вычислений (HPC). Участвует в разработке различных СПО проектов с 2004 года в широком спектре интересов, в частности, является разработчиком Gentoo с 2014 года. В настоящее время работает в ООО «Базальт СПО», специализируясь на ВК Эльбрус.


Clsync – инструмент живой синхронизации данных

Живая синхронизация данных является важным инструментом при построении надёжных, высокодоступных и масштабируемых информационных систем. В данном докладе будет рассказано об инструменте синхронизации данных файлового уровня clsync, будут приведены некоторые примеры его использования и рассмотрена архитектура приложения, разработанная для обеспечения надёжности и безопасности в широком спектре реальных задач.


Соавторы: Дмитрий Окунев, НИЯУ МИФИ.

Тезисы

Введение
Живая синхронизация данных – это важный инструмент обеспечения надёжности, высокой доступности и масштабируемости информационных систем. В данной работе рассматривается инструмент живой синхронизации на файловом уровне clsync[1], некоторые его применения и архитектура приложения, разработанного с учётом широких потребностей в безопасности и надёжности работы.

Живая синхронизация данных
Задачи живой синхронизации данных можно разделить на следующие основные категории:

  • Обеспечение систем высокой доступности (high availability, HA)
  • Реализация резервного копирования данных
  • Обеспечение внутрикластерной синхронизации данных

Утилита clsync была разработана для решения этой задачи быстро, надёжно и безопасно.

Существуют разные подходы к репликации и синхронизации данных, в частности:

  • Единые сетевые файловые хранилища
  • Репликация данных блочного уровня
  • Файловая репликация

Сетевые файловые системы, за исключением полностью распределённых кластерных файловых систем, создают единую точку отказа, что в условиях не очень надёжной и перегруженной аппаратной инфраструктуры оказалось не приемлемым решением; в то же время распределённые кластерные файловые системы очень требовательны к оборудованию и сложны в эксплуатации. Блочная репликация оказалась слишком медленной и чувствительной к задержкам передачи данных (latency). Поэтому был избран путь живой репликации данных на файловом уровне.

Для мониторинга изменений файловой системы сперва было опробовано решение на основе lsyncd, в частности, для осуществления синхронизации контейнеров между узлами кластера и их резервного копирование. Однако, lsyncd оказался слишком требовательным к CPU (существенная часть кода написана на Lua), не пригодным к тонкой настройке и недостаточно надёжным.

Clsync
Для решения поставленной задачи было разработано собственное решение --- clsync, где мы постарались учесть недостатки lsyncd и оптимизировать решение для наших задач. В первую очередь работа была ориентирована на системы высокой доступности, для которых требуется:

  • Высокая производительность (сравнимая с производительностью локальной файловой системы).
  • Высокая доступность (отказ в обслуживании не более нескольких секунд)
  • Высокая надёжность
  • Универсальность

По сути, clsync является демоном мониторинга изменений файловой системы по гибким правилам, основанным на регулярных выражениях, и выполнения произвольных действий при наступлении любых отслеживаемых событий. Однако, приложение весьма гибко и может быть использовано и в режиме работы обычного приложения для выполнения одноразовых операций, например, разовой синхронизации часто меняющихся данных с рекурсивной досинхронизацией изменений, возникших во время предыдущей синхронизации, что оказалось чрезвычайно полезным для задач web-хостинга или снятия точного образа с работающей системы без её останова.

Clsync написан на языке C стандарта C99, поддерживает различные механизмы уведомления о событиях файловой системы как на Linux, так и на BSD. Для Linux механизмом нотификации по-умолчанию является inotify, для FreeBSD — kqueue. В качестве бэкенда для синхронизации может использоваться любое приложение, скрипт или связываемая библиотека, но чаще всего применяется rsync.

Для обеспечения безопасности предусматриваются разнообразные механизмы защиты, некоторые из которых могут ухудшить производительность, поэтому предусмотрена возможность их опционального использования:

  • Использование unshare для изоляции пространств имён с возможностью тонкой настройки
  • Использование capabilities и сброс ненужных привилегий
  • Запрет выхода за пределы наблюдаемой директории при помощи pivot_root, chroot
  • и umount
  • Использование seccomp фильтрации
  • Разделение процесса на привилегированную и непривилегированную части

Для задач HPC, в частности, для синхронизации обновления программного обеспечения и конфигурации узлов кластера clsync оказался чрезвычайно полезен в связке с pdcp, а использование so-хендлеров (предоставляемых пользователем плагинов, загружаемых в качестве разделяемых библиотек) позволило существенно уменьшить задержки операций по сравнению с запуском скриптов.

[1] https://github.com/xaionaro/clsync

Организаторы

При поддержке