Обязательно ли размещать сервер 1С и веб-сервер на одной машине

← На главную

При настройке интеграции между различными информационными базами — например, между 1С:ERP Управление предприятием, 1С:Бухгалтерия предприятия и 1С:Документооборот — ключевым звеном выступают веб-сервисы и HTTP-сервисы. Часто возникает вопрос: обязаны ли веб-сервер (IIS или Apache) и служба кластера серверов 1С функционировать строго на одном физическом или виртуальном сервере, либо их можно разнести по разным узлам сети. Разберем технические требования, особенности настройки и практические рекомендации по распределению серверных мощностей.

Обязательно ли совместное размещение

Короткий ответ: нет, размещать веб-сервер и сервер 1С на одной машине не обязательно. Платформа «1С:Предприятие 8.3» полностью поддерживает распределенную схему, при которой веб-сервер принимает входящие запросы на одном хосте, а исполнение бизнес-логики и взаимодействие с СУБД берет на себя кластер 1С, расположенный на другом сетевом узле.

Такое разделение допустимо и работает штатно, однако требует соблюдения определенных технических условий при установке и администрировании.

Технические требования для выноса веб-сервера на отдельный узел

Проанализируем шаги и нюансы настройки, которые необходимо выполнить, если веб-сервер выносится на отдельную машину:

Установка компонентов 1С на веб-узле: На сервере под управлением IIS или Apache нет необходимости разворачивать серверную службу 1С (ragent) или покупать дополнительную лицензию на сервер «1С:Предприятия». Достаточно запустить дистрибутив платформы и выбрать для установки компонент «Модули расширения веб-сервера» (Web Server Extension Modules). Установка толстого клиента или конфигуратора опциональна — публикацию баз можно выполнить как через интерфейс конфигуратора, так и с помощью консольной утилиты webinst.
Строгое совпадение версий платформы: Релиз установленного модуля расширения веб-сервера обязан в точности соответствовать версии сборки кластера серверов 1С (вплоть до последнего числа билда). При обновлении кластера 1С обязательно обновляем модуль расширения на веб-сервере и выполняем повторную публикацию сервисов.
Совместимость разрядности: Разрядность модуля расширения 1С (x86 или x64) должна строго совпадать с разрядностью пула приложений IIS или процесса веб-сервера Apache. При этом разрядность удаленного сервера 1С может отличаться.
Связь через файл публикации: Подключение к удаленному кластеру настраивается в файле default.vrd. В строке соединения директивы ib указывается адрес кластера и имя опубликованной базы:


<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       base="/doc_integration"
       ib="Srvr=&quot;app-server.corp.local:1541&quot;;Ref=&quot;doc_base&quot;;">
    <ws>
        <point name="DMService"
               alias="dm.1cws"
               enable="true"/>
    </ws>
</point>

Настройка сетевых экранов (Firewall): Между машиной веб-сервера и сервером 1С должны быть открыты сетевые порты кластера: порт главного менеджера кластера (TCP 1541), порт агента сервера (TCP 1540) и диапазон рабочих процессов (по умолчанию TCP 1560-1591).

Подводные камни разделения и влияние на производительность

Рассмотрим, почему системные администраторы часто предпочитают держать веб-сервер и сервер 1С на одном хосте:

Сетевые задержки: При поступлении HTTP-запроса веб-модуль транслирует вызов в кластер 1С. Если веб-сервер и сервер 1С разделены физической сетью, на каждый вызов накладывается сетевой оверхед. При интенсивном обмене данными (например, при потоковой передаче файлов и вложений между ERP и «1С:Документооборот») это может приводить к снижению скорости отклика и ошибкам таймаута (в частности, HTTP 504 Gateway Timeout).
Доступ к файловым томам: Если в «1С:Документооборот» настроено хранение файлов в томах на сетевом диске, учетная запись системного процесса веб-сервера (например, IUSR или пул IIS) должна обладать полными правами на доступ к этим каталогам по UNC-путям.
Аутентификация: Сквозная авторизация пользователей через Active Directory (Kerberos/NTLM) при разнесении веб-сервера и кластера настраивается сложнее из-за необходимости делегирования учетных данных между узлами.

Когда отдельный веб-сервер действительно оправдан

Вынос веб-сервера на изолированный узел имеет смысл в следующих архитектурных сценариях:

Размещение в демилитаризованной зоне (DMZ): Если сервисы «1С:Документооборот» или мобильные клиенты должны быть доступны из глобальной сети Интернет, веб-сервер выносят в DMZ. Он выполняет роль защитного периметра, исключая прямой доступ из внешней сети к основному серверу 1С и СУБД.
Балансировка и терминирование SSL: Использование внешнего обратного прокси (Reverse Proxy на базе Nginx или HAProxy) для шифрования трафика, балансировки сотен входящих подключений и кэширования статических данных.

Как рационально распределить нагрузку при наличии двух серверов

Если в инфраструктуре имеется всего два мощных сервера, выделять один из них исключительно под веб-сервер нерационально, так как веб-сервер сам по себе потребляет минимум ресурсов процессора и оперативной памяти.

Разберем классическую и наиболее производительную схему разделения двух машин под связку ERP, БП и «1С:Документооборот»:

Первый сервер — Сервер СУБД: На машине разворачивается база данных (MS SQL Server или PostgreSQL). Вся оперативная память и быстрые дисковые массивы выделяются под кеш и операции СУБД.
Второй сервер — Сервер «1С:Предприятия» + Веб-сервер: На этой машине поднимается служба кластера 1С и веб-сервер (IIS/Apache). Внутренний обмен между веб-расширением и кластером 1С происходит локально на максимальной скорости без сетевых задержек.
Сетевой стык между серверами: Машина СУБД и машина 1С соединяются выделенным высокоскоростным сетевым интерфейсом (желательно 10 Гбит/с) с задержкой (latency) менее 1 мс. Это полностью исключает узкие места в передаче данных между 1С и SQL.

Если же сервер СУБД уже вынесен за рамки этих машин, второй сервер целесообразно объединить с первым в единый кластер 1С. С помощью механизма «Требования назначения функциональности» на второй узел можно делегировать выполнение фоновых и регламентных заданий, а также обработку входящих вызовов веб-сервисов, чтобы тяжелые расчеты не мешали работе интерактивных пользователей.