Rsync
Last updated
Last updated
В предыдущей статье мы рассказывали о том, как настроить и контролировать репликацию базы данных MySQL или MariaDB. Однако, если речь идет о создании отказоустойчивого интернет-магазина или аналогичного проекта, нужно реплицировать не только базу данных, но и файлы. Это могут быть файлы изображений товаров, html-страниц, стилей CSS, скрипты и другие файлы.
Задача не совсем тривиальная, так как не все файлы должны реплицироваться, на мастер-сервере могут периодически появляться новые файлы и исчезать старые. Кроме того, процесс репликации не должен отнимать слишком много ресурсов, и результаты репликации файлов необходимо контролировать. Важно сделать так, чтобы репликация выполнялась только в том случае, если резервный сервер не переключился в состояние мастера, например, в результате выхода основного сервера из строя.
В этой статье мы расскажем, как настроить репликацию файлов при помощи программы rsync, а также как организовать мониторинг репликации файлов с помощью Zabbix.
Мы будем исходить из предположения, что файлы пользователя shopusr2 реплицируются с мастер-сервера host01master на резервный сервер host01slave.
При этом репликации подлежат все файлы из каталога /home/shopusr2/data, за исключением файлов, перечисленных в файле исключений, расположенном на резервном сервере host01slave.
Для установки программы rsync в ОС Debian 11 используйте следующие команды:
Чтобы узнать версию установленной программы, запустите ее с параметром --version:
Исходные коды программы можно загрузить на сайте https://rsync.samba.org/, а также здесь: https://github.com/WayneD/rsync/.
После установки rsync на мастер-сервере нужно отредактировать файл конфигурации /etc/rsyncd.conf. Также нужно создать файлы для ограничения доступа и для исключения из репликации файлов и каталогов, не требующих синхронизации между мастер-сервером и резервным сервером.
На мастер-сервере, с которого будут копироваться файлы на резервный сервер, необходимо подготовить файл конфигурации /etc/rsyncd.conf, а также файлы паролей для реплицируемых пользователей.
Для файлов паролей установите владельцем пользователя root и укажите для атрибутов значение 0600.
Создайте на мастер-сервере файл /etc/rsyncd.conf с таким содержимым:
Параметры uid и gid задают, соответственно, группу и пользователя, от имени которого будет выполнена синхронизация содержимого заданного каталога. В данном случае операции будут выполняться от имени пользователя root.
Параметр use chroot со значением yes предписывает программе rsync при выполнении операции менять корневой каталог на указанный в параметре path. Такое изменение выполняется из соображений безопасности.
Что же касается параметра path, то он задает путь к каталогу, для которого нужно выполнить синхронизацию файлов.
Для того чтобы не перегружать сервер в процессе репликации файлов, мы задали в файле конфигурации параметр max connections. Он задает максимальное количество одновременных подключений к сервису rsync, запущенному на мастер-сервере.
Параметр syslog facility задает уровень детализации сообщений от сервиса rsync для syslog. Можно указывать значения local0, local1, local2, local3, local4, local5, local6 и local7.
Далее в файле конфигурации /etc/rsyncd.conf должны следовать блоки определения синхронизируемых каталогов. В нашем случае это блок [shopusr2].
В нем задан путь path к каталогу /home/shopusr2/data, содержимое которого будет реплицироваться на сервер бекапов, произвольный комментарий comment, а также параметры auth users и secrets file, ограничивающие доступ к этому каталогу.
Параметр list позволяет просматривать список файлов и потребуется нам только для отладки.
Файл доступа на мастер-сервере /home/shopusr2/data/rsyncd.secrets должен содержать такую строку:
Здесь после двоеточия укажите пароль доступа, который будет нужен резервному серверу для подключения.
Установите для файла rsyncd.secrets владельца и права следующим образом:
После этого перезапустите сервис rsync и проверьте, что он работает:
Из соображений безопасности нужно ограничить доступ к порту 873 на мастер-сервере с помощью файрвола, разрешив его только для адреса IP резервного сервера.
На сервере реплики подготовьте для каждого реплицируемого пользователя файлы исключений и файлы паролей.
В файлах исключений нужно перечислить каталоги и файлы, которые не должны реплицироваться, например:
Конечно, вам нужно будет самим определить содержимое файла исключений для своего сайта.
Файлы паролей на резервном сервере должны содержать только строку пароля. Их нужно разместить в каталоге реплицируемого пользователя и назначить владельцем этого пользователя. Для нашего случая файл паролей находится здесь:
Установите для файла паролей атрибут 0600:
Проверьте, что после запуска сервис rsync занял порт 873 на мастер-сервере:
На время тестирования уберите символ комментария со строки list = yes в файле конфигурации /etc/rsyncd.conf на мастер-сервере и перезапустите rsync.
Далее на сервере реплики обратитесь к мастер-серверу по его адресу IP:
В ответ на эту команду на консоли появится список пользователей. В нашем случае здесь будет один пользователь shopusr2.
Просмотрите файлы от имени этого пользователя, указав пароль из файла rsync.secrets:
На консоли появится список файлов, доступных для репликации:
После этого проверьте работу команды репликации:
Параметры этой команды описаны в следующем разделе этой статьи. Результат выполнения синхронизации будет записан в журнал rsync_log.txt.
Для запуска и контроля результатов выполнения репликации файлов мы используем программу run_rsync_free.pl, доступную здесь: ссылка на GitHub.
Вам необходимо отредактировать программу, указав адрес IP и домены своих серверов. Кроме того, вместо сервиса keepalived вы можете использовать другие средства переключения с мастер-сервера на сервер бекапов, и это тоже необходимо учесть при подготовке своей программы репликации и мониторинга.
Сразу после запуска программа проверяет, что она работает на резервном сервере, и этот сервер находится в состоянии BACKUP. Для этого программа определяет имя хоста, а также проверяет содержимое файла node_keepalive_state.txt, в который сервис keepalived записывает состояние хоста:
Если имя хоста определилось как host01slave.domain.ru, а файл состояния keepalived содержит строку «INSTANCE_myshop_BACKUP», запускается процесс репликации. В противном случае репликация не выполняется, а на консоль выводится сообщение об ошибке.
Репликация файлов может выполняться довольно долго, поэтому в программе есть защита от повторного запуска. Она основана на использовании файла блокировки, а также функций, позволяющих проверить состояние блокировки, выполнить и отменить блокировку:
Функция do_sync запускает программу /usr/bin/rsync, которая синхронизирует файлы:
В качестве параметров этой функции нужно передать имя пользователя, для которого выполняется репликация файлов, а также адрес IP мастер-сервера.
При запуске rsync мы используем следующие параметры:
u — нужно выполнять только обновление файлов, но не перезаписывать обновленные файлы;
r — обрабатывать каталоги рекурсивно;
l — сохранять ссылки;
t — сохранять информацию о дате и времени файла;
vvv — выводить информацию о результатах работы в подробном виде;
delete-after — удалять файлы завершения передачи;
password-file — взять пароль из файла, указанного в этом параметре;
exclude-from — взять список исключений из файла, указанного в этом параметре;
bwlimit — ограничить скорость передачи данных значением, указанным в Кбайт/c.
Полный список параметров программы rsync можно посмотреть, например, здесь.
Если копирование файлов завершилось успешно, то подробный журнал копирования будет записан в переменную $log для дальнейшего анализа функцией analyze_log. В противном случае сообщение об ошибке будет сохранено в переменной $rc.
Функция do_sync возвращает хэш с кодом завершения rc, результатом анализа журнала синхронизации файлов sync_status_from_log, длительностью процесса синхронизации sync_duration, а также именем пользователя user и адресом IP мастер-сервера master_server_ip.
Задачей функции analyze_log является разбор файла журнала, созданного программой rsync в процессе синхронизации файлов. В ходе разбора функция отыскивает сообщения об ошибках, отфильтровывая «безобидные» сообщения:
Если ошибок не обнаружено, функция записывает в поле rc возвращаемого хэша строку «ok», а через хэш action передает статистику по выполненным действиям.
При ошибке в поле rc записывается строка «error», а в поле errors — ссылка на массив ошибок.
На следующем этапе наша программа записывает в хэш $sync_info информацию для отправки в Zabbix:
Прежде всего, при ошибке в переменную $shopusr2_error_rc записывается значение 1, а если команда rsync отработала правильно, то значение 0.
Если же ошибка была обнаружена в результате анализа журнала функцией analyze_log, то эта ситуация рассматривается как предупреждение. В переменную $shopusr2_warning_rc при этом записывается значение 1.
Появление предупреждения означает, что нужно проанализировать журнал выполнения программы rsync. При этом следует понять, насколько критична ошибка и как ее можно устранить. Если ошибка не критична, можно добавить соответствующий фильтр в функцию analyze_log. Возможно, потребуется отредактировать файл исключений.
И, наконец, в переменную $shopusr2_sync_duration записывается длительность выполнения команды синхронизации файлов.
Для отправки данных в Zabbix используется программа zabbix_sender. Для этой программы подготавливается файл с данными, который затем отправляется на все серверы Zabbix:
Адреса серверов Zabbix передаются программе run_rsync_free.pl при ее запуске в качестве параметра.
Для запуска программы run_rsync_free.pl каждые 10 минут вы можете использовать такое задание crontab:
Здесь вместо xxx.xxx.xxx.xxx и yyy.yyy.yyy.yyy укажите адреса ваших серверов Zabbix через запятую.
Мы подготовили шаблон мониторинга репликации файлов для Zabbix (рис. 1), доступный здесь: ссылка на GitHub.
Рис. 1. Шаблон мониторинга репликации файлов для Zabbix
В шаблоне определены метрики для обнаружения ошибок и предупреждений, появляющихся в процессе репликации, а также для контроля времени, необходимого для выполнения репликации.
Также в шаблоне предусмотрены триггеры, показанные на рис. 2.
Рис. 2. Триггеры шаблона мониторинга репликации файлов
Эти триггеры срабатывают, если возникают ошибки и предупреждения, а также если данные мониторинга репликации не поступают на сервер Zabbix слишком долго.
Автор: Александр Фролов.