При работе с сервером 1С, особенно если к нему необходимо подключаться извне через интернет, часто возникает потребность в обеспечении высокой доступности и отказоустойчивости. Если у вас есть несколько внешних IP-адресов от разных провайдеров, вы, вероятно, сталкиваетесь с проблемой переключения между ними в случае падения одного из интернет-каналов. Традиционное решение, которое часто используется, — это ручное редактирование файла hosts на каждой клиентской машине для сопоставления имени сервера 1С с актуальным IP-адресом. Однако этот подход крайне неудобен и неэффективен, особенно при большом количестве клиентов или частых переключениях. В этом руководстве мы подробно рассмотрим, как решить эту задачу, избегая правок файла hosts, используя современные сетевые технологии и правильную конфигурацию кластера 1С.
Прежде чем перейти к решениям, давайте разберем, почему вообще возникает эта проблема с файлом hosts. Когда клиентское приложение 1С подключается к серверу, оно сначала соединяется с указанным в параметрах подключения адресом (это может быть IP или доменное имя). Однако затем кластер 1С в ответ на запрос сообщает клиенту имя активного рабочего сервера так, как оно прописано при создании самого кластера 1С. В большинстве случаев это именно внутреннее имя сервера (например, svr27), а не внешний IP-адрес или полностью определенное доменное имя (FQDN). Поскольку клиент находится вне локальной сети сервера, его операционная система не может самостоятельно разрешить это внутреннее имя в IP-адрес через публичные DNS-серверы, что приводит к ошибке "Этот хост неизвестен". Вот почему администраторам приходится вручную вносить записи в файл hosts, сопоставляя внутреннее имя сервера с его внешним IP-адресом (например, 192.1.1.222 svr27). Наша задача — уйти от этой ручной работы.
Один из самых эффективных и надежных способов решения проблемы — это применение специализированных DNS-сервисов, которые предоставляют функциональность DNS Failover (отказоустойчивость DNS). Этот подход позволяет связать одно доменное имя с несколькими IP-адресами и автоматически переключаться между ними.
Мы регистрируем официальное доменное имя (например, 1c.yourcompany.com) и настраиваем его у провайдера DNS-услуг, поддерживающего функцию Failover (например, Cloudflare, Amazon Route 53, DynDNS или Яндекс.Облако DNS). Мы указываем несколько IP-адресов вашего сервера (основной и резервный) для этого доменного имени. DNS-провайдер постоянно отслеживает доступность каждого из этих IP-адресов (с помощью health checks). В случае, если основной IP-адрес становится недоступным (например, из-за падения интернет-канала), DNS-сервис автоматически изменяет запись, направляя все запросы к вашему доменному имени на резервный IP-адрес. Этот процесс происходит на уровне DNS-серверов в интернете, поэтому для клиентских машин смена IP-адреса происходит абсолютно незаметно. Клиенты всегда обращаются к одному и тому же доменному имени, а DNS-система обеспечивает перенаправление на актуальный работающий IP.
Шаги по реализации:
1c.yourcompany.com), а не как внутреннее имя.Если ваши внешние IP-адреса не статичны, а динамически выдаются провайдером (хотя в вашем случае они статичны, DDNS также может быть полезен в связке с маршрутизаторами), или если вы хотите использовать более простое решение без сложной настройки Failover на публичных DNS, можно рассмотреть DDNS. Эта технология позволяет присвоить постоянное доменное имя серверу, даже если его IP-адрес меняется. Специальная утилита (часто встроенная в маршрутизатор) или скрипт отслеживает текущий активный IP-адрес и автоматически обновляет соответствующую DNS-запись на DDNS-сервере. Таким образом, клиенты всегда обращаются к одному и тому же доменному имени (например, yourserver.dyndns.org), а DDNS-сервис направляет их на текущий работающий IP-адрес.
В вашем случае, с двумя статическими IP, DDNS сам по себе не обеспечит автоматического переключения при падении одного канала. Однако, в сочетании с функцией Failover на маршрутизаторе (о которой мы поговорим ниже), DDNS может быть частью решения, если роутер может обновить DDNS-запись, указывая на текущий активный внешний IP.
Современные маршрутизаторы, особенно профессионального и полупрофессионального уровня (например, MikroTik, Keenetic), обладают мощными функциями для работы с несколькими интернет-провайдерами. Мы можем использовать их возможности для автоматического переключения между каналами.
Ваш маршрутизатор, в который подключены два провайдера, можно настроить таким образом, чтобы он автоматически определял падение одного интернет-канала и переключал весь исходящий и входящий трафик на резервный канал. Это называется режимом Failover. Многие маршрутизаторы также позволяют настроить балансировку нагрузки, распределяя трафик между обоими каналами, но для нашей задачи приоритетнее именно отказоустойчивость.
Принцип работы: Маршрутизатор постоянно мониторит доступность каждого провайдера (например, пингуя шлюз провайдера или внешний ресурс, такой как Google DNS). Если основной канал перестает отвечать, роутер перемаршрутизирует все пакеты через резервный канал. При этом он меняет внешний IP-адрес, через который доступен ваш сервер.
Совмещение с DNS-сервисами: Если вы используете только маршрутизатор, то при переключении канала внешний IP-адрес сервера изменится, и клиенты потеряют связь. Чтобы избежать этого, необходимо использовать маршрутизатор в связке с DNS Failover или DDNS. Роутер переключает канал, а затем либо сообщает DDNS-сервису новый активный IP, либо DNS Failover-сервис самостоятельно обнаруживает изменение. Если вы используете DNS Failover, настроенный у стороннего провайдера (Cloudflare, Route 53), маршрутизатор просто обеспечивает переключение трафика, а DNS-провайдер сам обнаружит изменение доступности IP-адресов. Если же вы хотите, чтобы роутер сам обновлял DNS, это возможно только с DDNS-сервисами, поддерживающими такую функцию на маршрутизаторе (например, KeenDNS для роутеров Keenetic).
Пример настройки на MikroTik:
На роутерах MikroTik можно создать правила netwatch для мониторинга доступности шлюзов провайдеров и скрипты, которые будут активировать/деактивировать маршруты по умолчанию.
/tool netwatch
add host=8.8.8.8 interval=10s timeout=5s up-script="/ip route set [find comment=main_route] distance=1" down-script="/ip route set [find comment=main_route] distance=10"
add host=8.8.4.4 interval=10s timeout=5s up-script="/ip route set [find comment=backup_route] distance=1" down-script="/ip route set [find comment=backup_route] distance=10"
/ip route
add dst-address=0.0.0.0/0 gateway=192.168.1.1 distance=1 comment=main_route
add dst-address=0.0.0.0/0 gateway=192.168.2.1 distance=2 comment=backup_route
Этот пример показывает базовый принцип: при недоступности основного шлюза (через пинг 8.8.8.8) маршрут с комментарием main_route получает более высокий distance (приоритет падает), и активируется маршрут с меньшим distance (резервный).
Для более крупных, сложных и требовательных к отказоустойчивости инфраструктур мы можем рассмотреть внедрение балансировщиков нагрузки (Load Balancers). Это решение обеспечивает максимальную прозрачность переключения и высокую доступность.
Балансировщик нагрузки — это специализированное устройство или программное обеспечение, которое устанавливается "перед" вашим сервером 1С. Все клиентские подключения сначала поступают на балансировщик, а уже он распределяет их между доступными серверами или, в нашем случае, перенаправляет трафик через доступный интернет-канал. Балансировщик постоянно отслеживает работоспособность обоих интернет-каналов и/или доступность самого сервера 1С. В случае отказа одного канала, он мгновенно переключает весь трафик на другой, резервный канал.
Типы балансировщиков:
ngx_http_upstream_module), HAProxy, или решений от облачных провайдеров (например, Application Load Balancer в AWS или Cloud Load Balancing в Google Cloud).Преимущества: Балансировщики нагрузки обеспечивают практически бесшовное переключение для клиентов, а также могут выполнять другие полезные функции, такие как SSL-терминирование, кэширование, защита от DDoS-атак.
Реализация: Мы настраиваем балансировщик так, чтобы он имел один внешний IP-адрес (или FQDN, который разрешается в этот IP) и перенаправлял запросы на внутренний IP сервера 1С через активный внешний канал. Мониторинг каналов и переключение будет выполнять сам балансировщик.
Как уже было сказано, одной из ключевых проблем является то, что кластер 1С сообщает клиенту свое внутреннее имя. Чтобы полностью избавиться от правок hosts, мы должны убедиться, что кластер 1С сам себя идентифицирует по полностью определенному доменному имени (FQDN), которое может быть разрешено извне.
При создании или редактировании кластера серверов 1С, а также при добавлении информационных баз, убедитесь, что в качестве имени сервера указано ваше публичное FQDN (например, srv1c.yourdomain.com), а не внутреннее имя машины (например, SERVER1C). Это FQDN должно быть тем же, которое вы зарегистрировали и настроили в DNS Failover сервисе.
Важно: Это FQDN должно быть разрешимо через публичный DNS, который настроен на отказоустойчивость одним из вышеописанных методов.
Почему это важно: Когда клиентское приложение 1С подключается к серверу, оно получает от кластера именно это FQDN-имя. Поскольку это FQDN, публичная система DNS (настроенная на отказоустойчивость) сможет успешно разрешить его в текущий активный IP-адрес. Таким образом, клиенту не понадобится запись в файле hosts, и он всегда сможет подключиться к актуальному IP-адресу.
Убедитесь, что на самом сервере 1С, где установлен кластер, FQDN правильно разрешается в его собственный локальный или внешний IP. В некоторых случаях может потребоваться добавить запись в файл hosts *на самом сервере 1С*, чтобы он сам мог обращаться к себе по FQDN: 127.0.0.1 srv1c.yourdomain.com (или его локальный IP). Это предотвратит возможные проблемы с самоидентификацией кластера.
Для тонкого клиента 1С существует возможность указать несколько IP-адресов или доменных имен через точку с запятой в строке подключения. Этот метод может быть полезен как временное решение или в определенных сценариях, но он не полностью решает проблему автоматического переключения без правок hosts или DNS.
Мы можем использовать следующую строку для подключения в тонком клиенте:
Srvr="IP1;IP2;FQDN_Server";Ref="MyBase";
Где:
IP1 и IP2 — это внешние IP-адреса ваших интернет-каналов.FQDN_Server — это доменное имя вашего сервера (например, 1c.yourcompany.com), настроенное через DNS Failover.MyBase — имя вашей информационной базы.Принцип работы: Клиент 1С будет пытаться подключиться к первому адресу в списке. Если он недоступен, клиент попробует следующий. Однако, если IP1 и IP2 — это просто статические IP-адреса, а кластер 1С все равно вернет внутреннее имя, то проблема с hosts останется, если FQDN_Server не будет разрешаться корректно. Этот метод наиболее эффективен, когда вы используете FQDN_Server, который, в свою очередь, разрешается в актуальный IP через DNS Failover.
Оговорки: Это решение не является полностью автоматическим и прозрачным, если не комбинируется с полноценной DNS-системой отказоустойчивости. Оно скорее предоставляет возможность ручного или полуавтоматического переключения на стороне клиента.
Для обеспечения надежного и отказоустойчивого доступа к серверу 1С с несколькими внешними IP-адресами без необходимости ручного редактирования файла hosts на клиентских машинах, мы рекомендуем следующий комплексный подход:
srv1c.yourdomain.com), которое будет разрешаться через DNS Failover. Это критически важный шаг для обхода проблемы с внутренним именем сервера.Комбинируя эти подходы, мы сможем создать надежную инфраструктуру, которая автоматически переключается между интернет-каналами, предоставляя клиентам постоянный доступ к серверу 1С без какого-либо ручного вмешательства или правок системных файлов.