Обеспечение непрерывной работы системы 1С при физическом выходе из строя одного из серверов или обрыве связи — одна из самых сложных задач для системного администратора. Ситуация осложняется, когда серверы географически удалены друг от друга и связаны только через интернет. В такой конфигурации возникают проблемы с задержками (latency), синхронизацией данных СУБД и переключением клиентских лицензий. Рассмотрим подробнее основные стратегии решения этой задачи, начиная от простых программных методов и заканчивая сложными кластерными архитектурами.
Прежде чем приступать к объединению серверов, проанализируем, где находятся критические точки отказа. В типовой схеме их три:
Важно понимать, что простое наличие двух серверов 1С не гарантирует надежности, если база данных SQL остается в единственном экземпляре. Для достижения реальной отказоустойчивости нам необходимо дублировать и синхронизировать оба уровня системы.
Рассмотрим бюджетный вариант, который не требует дорогостоящего оборудования и лицензий Enterprise-уровня. Суть метода заключается в использовании единого доменного имени для подключения клиентов и автоматической смене IP-адреса в записях DNS при падении основного узла.
Для реализации этого подхода выполним следующие шаги:
Server 1C и MS SQL Server.server1c.com актуальным IP-адресом.ping или попытку подключения к порту 1541).Пример логики скрипта мониторинга на резервном сервере:
$PrimaryServerIP = "217.74.109.205"
$IsAlive = Test-Connection -ComputerName $PrimaryServerIP -Count 2 -Quiet
Если (-not $IsAlive) Тогда
# Запускаем обновление DynDNS на текущий сервер
Start-Process "C:\DynDNS\Updater.exe" -ArgumentList "/force /update"
# Опционально: запуск служб 1С, если они были в стопе
Start-Service "1C:Enterprise 8.3 Server Agent"
КонецЕсли
Важный момент: этот метод имеет существенный минус — задержку обновления кэша DNS на стороне провайдеров и клиентских машин. Пользователи могут продолжать пытаться подключиться к старому IP в течение некоторого времени.
Если бюджет позволяет использовать MS SQL Server версии Enterprise и Windows Server со службой Failover Clustering, разберем более профессиональный подход. Группы доступности AlwaysOn позволяют иметь несколько копий базы данных на разных серверах, которые синхронизируются в реальном времени.
Проанализируем технические требования для этой схемы:
Active Directory (контроллеры домена должны быть доступны обоим серверам).WireGuard или аппаратных решений Cisco/MikroTik) для обеспечения защищенного канала связи с низким latency.Cluster Witness (свидетеля). Поскольку у нас всего два сервера, нам нужен третий узел или файловая шара в облаке, чтобы избежать ситуации Split-Brain (когда оба сервера считают себя главными).В этой конфигурации 1С подключается не к конкретному серверу SQL, а к Availability Group Listener — виртуальному имени, которое всегда указывает на активную ноду. Если основной SQL падает, переключение на резерв происходит за считанные секунды, и сеансы 1С (при наличии настроенного кластера 1С) могут продолжить работу.
Выясним, как поступить, если связь между офисами нестабильна или имеет низкую пропускную способность. В этом случае синхронные методы (AlwaysOn) будут тормозить работу 1С, так как система будет ждать подтверждения записи данных с удаленного сервера. Оптимальным решением станет использование механизма РИБ.
Разберем алгоритм действий:
Resilio Sync или Syncthing, которые работают по протоколу P2P и отлично справляются с передачей данных через нестабильный интернет.В этом случае пользователи в одном офисе работают с сервером А, а в другом — с сервером Б. Если один сервер "умирает", все пользователи переключаются на второй. После восстановления связи данные автоматически синхронизируются через планы обмена.
Посмотрим на ситуацию со стороны веб-доступа. Если публикация базы выполнена через интернет (HTTP/HTTPS), мы можем установить перед серверами 1С балансировщик трафика. Рассмотрим использование Nginx.
Проанализируем пример конфигурации Nginx для отказоустойчивости:
upstream backend_1c {
server 192.168.1.10:80 weight=5; # Основной сервер
server 192.168.2.10:80 backup; # Резервный сервер
}
server {
listen 80;
server_name server1c.com;
location /base1 {
proxy_pass http://backend_1c;
proxy_connect_timeout 5s;
proxy_next_upstream error timeout http_502;
}
}
В данной схеме Nginx сам проверяет доступность основного сервера. Если он выдает ошибку или таймаут, запрос мгновенно перенаправляется на backup сервер. Это самое элегантное решение для пользователей, работающих через тонкий клиент или веб-браузер.
Критически важно учесть вопрос защиты программного обеспечения. Программные лицензии 1С привязаны к "железу". Если вы используете программные ключи, при переключении на второй физический сервер 1С потребует новую активацию. Чтобы избежать этой проблемы, рекомендуется:
L2 Stretch).Подведем итог: выбор решения зависит от ваших ресурсов. Если вам нужна максимальная надежность и данные должны быть актуальны "секунда в секунду", ваш путь — это SQL AlwaysOn через защищенный VPN-канал. Если же бюджет ограничен, а каналы связи не идеальны, рассмотрите вариант с РИБ и автоматизированной синхронизацией файлов обмена. Для веб-клиентов обязательно используйте балансировщик типа Nginx, который скроет от пользователя процесс переключения между серверами.