Проблема: розсинхронізація конфігів на десятках серверів
Розробники правлять конфіги на п'яти серверах, а через 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>ваш_хеш_пароля</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 днів.
