В современных реалиях вопрос обеспечения непрерывности бизнес-процессов при использовании облачных серверов за рубежом становится критически важным. Рассмотрим ситуацию: основной сервер 1С находится во Франкфурте, а работа офиса в России полностью зависит от стабильности международного интернет-канала. Проанализируем, как можно развернуть дублирующий сервер в РФ и настроить синхронизацию данных так, чтобы при отключении интернета работа компании не остановилась.
Разберем основные технические решения, их преимущества и недостатки, а также дополнительные инструменты для обеспечения высокой доступности данных.
РИБ (Распределенные информационные базы) — это стандартный механизм платформы 1С, предназначенный для обмена данными между территориально удаленными узлами. В нашем случае мы создаем «Главный узел» во Франкфурте и «Подчиненный узел» в России.
Проанализируем шаги по реализации этого метода:
Преимущество этого метода в том, что он работает на уровне логики 1С. Если интернет пропадет, пользователи в РФ продолжат работать в локальной базе. Как только связь восстановится, система автоматически выполнит синхронизацию и «сольет» все изменения в центральный узел. Это единственный метод, который корректно решает проблему коллизий, когда одни и те же данные были изменены в обеих базах одновременно.
Если ваша база работает на MS SQL Server, можно рассмотреть технологию Log Shipping (пересылка логов транзакций). Рассмотрим подробнее этот процесс:
Принцип работы заключается в том, что основной сервер во Франкфурте периодически делает бэкап лога транзакций и пересылает его на сервер в РФ, где этот лог «накатывается» на резервную копию базы. Это позволяет держать в России актуальную копию базы с минимальным отставанием.
Однако здесь есть важный нюанс: база в РФ при таком сценарии находится в состоянии Restoring или Standby (только для чтения). Если интернет пропадет, системному администратору потребуется вручную перевести базу в рабочий режим (RECOVERY), чтобы пользователи смогли вводить данные. Автоматического «прозрачного» переключения для пользователей 1С в данном случае добиться сложно.
Для крупных инсталляций (при наличии лицензий MS SQL Server Enterprise) оптимальным решением станет использование Distributed Availability Groups. В отличие от обычного кластера, распределенная группа позволяет объединить два независимых кластера в разных локациях.
Выясним преимущества этой технологии для трансграничной работы:
Если вы используете PostgreSQL, мы рекомендуем настроить потоковую репликацию. Разберем по шагам, как это работает в условиях нестабильной связи:
Для передачи данных используются WAL-логи (Write Ahead Logs). Чтобы сервер в РФ мог «догнать» основной сервер после длительного обрыва связи, необходимо использовать слоты репликации или настроить хранилище архивных логов. Мы можем использовать параметр archive_command, который будет складывать логи в доступное место, откуда сервер в России сможет их забирать самостоятельно.
Начиная с версии платформы 8.3.18, в 1С появился функционал Автономного сервера. Изначально он создавался для мобильных приложений, но его логику можно применить для локальных рабочих мест. Рассмотрим ситуацию: локальный сервер 1С в РФ выступает как промежуточное звено. Он кэширует данные и обеспечивает работу пользователей даже без связи с центральным сервером, синхронизируя изменения в фоновом режиме, когда канал свободен.
При настройке параллельной работы важно помнить о проблеме «двух голов» (split-brain). Если связь разорвана и пользователи начали работать в обеих базах независимо, последующее слияние данных может привести к дублированию номеров документов или конфликтам версий объектов. Именно поэтому РИБ считается наиболее безопасным методом для 1С, так как он штатно обрабатывает такие ситуации.
Также проанализируем ситуацию с точки зрения законодательства. Согласно 152-ФЗ «О персональных данных», первичный сбор данных граждан РФ должен производиться на территории России. Наличие сервера в РФ, который первым принимает данные, а затем транслирует их во Франкфурт, поможет вам соответствовать требованиям регуляторов.
Для базы объемом 50 Гб синхронизация каждые 5 минут может создать высокую нагрузку на канал. Посмотрим, как минимизировать объем передаваемых данных:
В заключение отметим: если ваша цель — автоматическое и бесшовное переключение пользователей без участия админа, лучше всего смотреть в сторону РИБ с коротким интервалом обмена. Если же важна полная идентичность баз и вы готовы к ручному переключению в случае аварии — выбирайте Always On или Log Shipping.