Савченко Андрей Александрович, ведущий программист ООО «Базальт СПО».
Закончил МИФИ в 2008 году по специальности физика атомного ядра и частиц. В 2008-2017 годах работал в НИЯУ МИФИ, занимаясь как физикой частиц высоких энергий, так и развитием высокопроизводительных вычислений (HPC). Участвует в разработке различных СПО проектов с 2004 года в широком спектре интересов,
в частности, является разработчиком Gentoo с 2014 года. В настоящее время работает в ООО «Базальт СПО», специализируясь на ВК Эльбрус.
Живая синхронизация данных является важным инструментом при построении надёжных, высокодоступных и масштабируемых информационных систем. В данном докладе будет рассказано об инструменте синхронизации данных файлового уровня clsync, будут приведены некоторые примеры его использования и рассмотрена архитектура приложения, разработанная для обеспечения надёжности и безопасности в широком спектре реальных задач.
Соавторы: Дмитрий Окунев, НИЯУ МИФИ.
Введение
Живая синхронизация данных – это важный инструмент обеспечения надёжности, высокой доступности и масштабируемости информационных систем. В данной работе рассматривается инструмент живой синхронизации на файловом уровне clsync[1], некоторые его применения и архитектура приложения, разработанного с учётом широких потребностей в безопасности и надёжности работы.
Живая синхронизация данных
Задачи живой синхронизации данных можно разделить на следующие основные категории:
Утилита clsync была разработана для решения этой задачи быстро, надёжно и безопасно.
Существуют разные подходы к репликации и синхронизации данных, в частности:
Сетевые файловые системы, за исключением полностью распределённых кластерных файловых систем, создают единую точку отказа, что в условиях не очень надёжной и перегруженной аппаратной инфраструктуры оказалось не приемлемым решением; в то же время распределённые кластерные файловые системы очень требовательны к оборудованию и сложны в эксплуатации. Блочная репликация оказалась слишком медленной и чувствительной к задержкам передачи данных (latency). Поэтому был избран путь живой репликации данных на файловом уровне.
Для мониторинга изменений файловой системы сперва было опробовано решение на основе lsyncd, в частности, для осуществления синхронизации контейнеров между узлами кластера и их резервного копирование. Однако, lsyncd оказался слишком требовательным к CPU (существенная часть кода написана на Lua), не пригодным к тонкой настройке и недостаточно надёжным.
Clsync
Для решения поставленной задачи было разработано собственное решение --- clsync, где мы постарались учесть недостатки lsyncd и оптимизировать решение для наших задач. В первую очередь работа была ориентирована на системы высокой доступности, для которых требуется:
По сути, clsync является демоном мониторинга изменений файловой системы по гибким правилам, основанным на регулярных выражениях, и выполнения произвольных действий при наступлении любых отслеживаемых событий. Однако, приложение весьма гибко и может быть использовано и в режиме работы обычного приложения для выполнения одноразовых операций, например, разовой синхронизации часто меняющихся данных с рекурсивной досинхронизацией изменений, возникших во время предыдущей синхронизации, что оказалось чрезвычайно полезным для задач web-хостинга или снятия точного образа с работающей системы без её останова.
Clsync написан на языке C стандарта C99, поддерживает различные механизмы уведомления о событиях файловой системы как на Linux, так и на BSD. Для Linux механизмом нотификации по-умолчанию является inotify, для FreeBSD — kqueue. В качестве бэкенда для синхронизации может использоваться любое приложение, скрипт или связываемая библиотека, но чаще всего применяется rsync.
Для обеспечения безопасности предусматриваются разнообразные механизмы защиты, некоторые из которых могут ухудшить производительность, поэтому предусмотрена возможность их опционального использования:
Для задач HPC, в частности, для синхронизации обновления программного обеспечения и конфигурации узлов кластера clsync оказался чрезвычайно полезен в связке с pdcp, а использование so-хендлеров (предоставляемых пользователем плагинов, загружаемых в качестве разделяемых библиотек) позволило существенно уменьшить задержки операций по сравнению с запуском скриптов.
[1] https://github.com/xaionaro/clsync
