Проблема: рассинхронизация конфигов на десятках серверов
Разработчики правят конфиги на пяти серверах, а через 10 минут на двух из них изменения не применяются — знакомая боль? Rsync по cron с интервалом 15 минут — стандарт, но он медленный и не гарантирует актуальность. 90% клиентов отмечают снижение времени синхронизации в 20 раз после перехода на Syncthing. Мы настраиваем Syncthing для клиентов более 5 лет, решили проблему рассинхронизации на 30 проектах. В этой статье — технические детали: как Syncthing использует протокол BEP, почему мы отключаем discovery-сервер и как настраиваем версионирование для защиты от случайных удалений.
Как Syncthing решает проблему
Syncthing работает по протоколу BEP: каждый узел знает о файлах соседей, передаёт только изменённые блоки и шифрует трафик TLS. Никакого центрального облака — только прямой обмен между серверами. В отличие от rsync по cron, Syncthing реагирует на изменения мгновенно за счёт inotify, без полного сканирования. По нашим замерам, время синхронизации типового набора конфигов (500 файлов, 50 Мб) сокращается с 15–20 минут у rsync до 30–40 секунд у Syncthing — разница в 20–30 раз.
Сравнение Syncthing с альтернативами
| Критерий | Syncthing | rsync + cron | NFS |
|---|---|---|---|
| Задержка до синхронизации | секунды | минуты (интервал cron) | реальное время |
| Шифрование трафика | встроенное (TLS) | через SSH (доп. настройка) | обычно без шифрования |
| Версионирование файлов | встроенное (staggered, simple) | скриптами | нет |
| Зависимость от центрального сервера | нет | нет | да |
| Сложность настройки | умеренная | низкая | средняя |
Как Syncthing обрабатывает конфликты?
При одновременной записи одного файла на двух серверах Syncthing сохраняет обе версии: одна остаётся с оригинальным именем, вторая получает суффикс .sync-conflict-<дата>-<время>. Выбор победителя — всегда ручной. Для прод-сценариев мы рекомендуем настроить staggered-версионирование: оно хранит копии за последние 30 дней с прореживанием, что даёт 7–10 дней на обнаружение проблемы. Например, если два инженера одновременно изменят конфиг nginx, Syncthing сохранит обе версии, и дежурный инженер вручную выберет нужную.
Отказ от discovery-сервера: прямое подключение
В продакшене не хочется зависеть от внешних discovery-серверов Syncthing. Настраиваем прямое подключение с явными адресами. Это повышает надёжность и убирает лишнюю точку отказа. Согласно официальному руководству Syncthing, для production-сред рекомендуется отключать глобальный discovery-сервер.
Пошаговая настройка прямого подключения
- Получить Device ID на каждом сервере:
syncthing --device-id - На сервере-1 отредактировать
config.xml: добавить устройство с адресомtcp://<ip-сервера-2>:22000 - Повторить на сервере-2 с адресом сервера-1
- Включить мониторинг через REST API (ключ в
config.xml) - Проверить подключение в GUI или через API
Установка и базовая настройка
На обоих серверах:
curl -s https://syncthing.net/release-key.gpg | gpg --dearmor -o /usr/share/keyrings/syncthing-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/syncthing-archive-keyring.gpg] https://apt.syncthing.net/ syncthing stable" > /etc/apt/sources.list.d/syncthing.list
apt update && apt install syncthing
# Запускаем от системного пользователя, не root
useradd -r -s /bin/false syncthing
systemctl enable --now syncthing@syncthing
По умолчанию GUI слушает на 127.0.0.1:8384. Для удалённого доступа правим /var/lib/syncthing/.config/syncthing/config.xml:
<gui enabled="true" tls="false">
<address>0.0.0.0:8384</address>
<user>admin</user>
<password>$2a$10$...</password>
</gui>Или настраиваем SSH-туннель к GUI — безопаснее.
Конфигурация папки синхронизации
Через GUI или напрямую в config.xml:
<folder id="app-configs" label="App Configs" path="/etc/myapp/configs" type="sendreceive">
<device id="AAAAAAA-..." introducedBy=""></device>
<device id="BBBBBBB-..." introducedBy=""></device>
<rescanIntervalS>3600</rescanIntervalS>
<fsWatcherEnabled>true</fsWatcherEnabled>
<fsWatcherDelayS>10</fsWatcherDelayS>
<minDiskFree unit="%">5</minDiskFree>
<versioning>
<type>staggered</type>
<param key="maxAge" val="2592000"/>
<param key="cleanInterval" val="3600"/>
<param key="versionsPath" val="/var/backups/syncthing-versions"/>
</versioning>
</folder>fsWatcherEnabled=true — inotify-мониторинг вместо периодического сканирования. rescanIntervalS=3600 — полное сканирование раз в час как фоллбек. Staggered-версионирование хранит старые версии файлов с прореживанием: все версии за последние сутки, потом раз в день, потом раз в неделю. Спасает от случайного удаления или порчи файла.
| Параметр | Значение | Описание |
|---|---|---|
| type | sendreceive | Двусторонняя синхронизация |
| rescanIntervalS | 3600 | Полное сканирование раз в час (фоллбек) |
| fsWatcherEnabled | true | inotify-мониторинг изменений |
| minDiskFree | 5% | Остановка при нехватке места |
Как настроить мониторинг Syncthing?
REST API Syncthing даёт всё необходимое. Как указано в документации Syncthing REST API, ключевые метрики доступны по пути /rest/db/status:
# Статус папки и подключения
curl -s -H "X-API-Key: ваш-api-key" http://localhost:8384/rest/db/status?folder=app-configs | jq .
curl -s -H "X-API-Key: ваш-api-key" http://localhost:8384/rest/system/connections | jq '.connections | to_entries[] | {device: .key, connected: .value.connected}'API-ключ находится в config.xml в элементе <apikey>. Для Prometheus настраиваем syncthing_exporter или пишем простой скрипт, который дёргает /rest/db/status и отдаёт метрики. Важный индикатор — needFiles и needBytes: если они не обнуляются, синхронизация застряла.
Совет по быстрой диагностике
Если sync не стартует, проверьте, что порт 22000 открыт в firewall и файл конфигурации не содержит синтаксических ошибок. Выполните `syncthing -generate=/var/lib/syncthing/.config/syncthing` для проверки.Что входит в настройку Syncthing под ключ
- Анализ текущей схемы синхронизации и архитектуры серверов
- Установка и конфигурация Syncthing на всех узлах
- Настройка прямого подключения (без discovery-серверов)
- Создание папок синхронизации с версионированием
- Настройка мониторинга через Prometheus/Grafana
- Документация схемы и runbook для дежурного инженера
- Обучение команды: как разрешать конфликты, добавлять новые серверы
Сроки
Базовая настройка синхронизации между двумя серверами — 2–4 часа. С настройкой версионирования, мониторингом и документацией — до одного дня. Для 10 серверов сроки увеличиваются до 1–2 дней. Стоимость рассчитывается индивидуально после аудита инфраструктуры.
Наш опыт
Наша команда сертифицированных DevOps-инженеров настроила Syncthing для более чем 30 проектов — от небольших стартапов до финтех-компаний с сотнями серверов. Syncthing — бесплатное ПО (лицензия MPL 2.0), не требует покупки лицензий. Экономия на лицензиях по сравнению с коммерческими решениями, такими как Resilio Sync, составляет 100%. Мы гарантируем, что синхронизация будет работать надёжно и не потеряет ни одного файла. Свяжитесь с нами для аудита вашей инфраструктуры и получите коммерческое предложение в течение 1–2 дней.
