← На главную

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

В этой статье мы подробно проанализируем, где лучше всего развертывать IIS, как обеспечить его отказоустойчивость и какие настройки безопасности являются обязательными для стабильной работы мобильных клиентов. Проанализируем ситуацию на примере классической корпоративной инфраструктуры: наличие кластера 1С, SQL-кластера и изолированной WiFi-сети.

Архитектурный выбор: на сервере приложений или на отдельном узле?

Рассмотрим первый и самый частый вопрос: можно ли ставить IIS непосредственно на серверы приложений 1С? Если ваша база небольшая (до 20-50 пользователей) и нагрузка минимальна, это допустимо. Однако в профессиональной среде с режимом работы 24/7/365 это считается плохой практикой по нескольким причинам:

1. Безопасность: Веб-сервер — это «лицо» вашей системы в сети (даже если это внутренняя WiFi-сеть). Любая уязвимость в IIS может дать злоумышленнику прямой доступ к серверу приложений, где исполняется бизнес-логика.
2. Ресурсы: Пул приложений IIS и рабочие процессы 1С (rphost) могут начать конкурировать за оперативную память и процессорное время, что приведет к деградации производительности всей системы.
3. Обновления: Обслуживание IIS (перезагрузка, обновление модулей) может потребовать прерывания работы сервера приложений.

Выясним причину, почему отдельный сервер предпочтительнее. Вынос веб-сервисов на отдельные виртуальные машины позволяет изолировать сегмент доступа от сегмента обработки данных. В идеале рекомендуется использовать схему с Reverse Proxy.

Использование Reverse Proxy как «золотого стандарта» безопасности

Разберем по шагам наиболее защищенную схему публикации мобильных сервисов. Вместо того чтобы открывать прямой доступ к IIS, на котором опубликована база 1С, мы ставим перед ним прокси-сервер.

Проанализируем преимущества такого подхода:

• Изоляция: Мобильные устройства подключаются только к прокси-серверу, который находится в DMZ или отдельном VLAN.
• Фильтрация: На уровне прокси можно настроить WAF (Web Application Firewall) для отсечения подозрительных HTTP-запросов и защиты от SQL-инъекций.
• Терминация SSL: Шифрование (HTTPS) заканчивается на прокси, что снимает вычислительную нагрузку с основных серверов 1С.

В качестве прокси-сервера мы рекомендуем использовать Nginx на Linux. Это решение потребляет значительно меньше ресурсов, чем IIS, и позволяет более гибко настраивать ограничения (например, Rate Limiting), чтобы один «зависший» мобильный телефон не заспамил сервер запросами.

Обеспечение отказоустойчивости через IIS ARR

Если ваша задача — обеспечить работу 24/7, один сервер IIS становится «точкой отказа». Рассмотрим, как кластеризовать IIS с помощью модуля Application Request Routing (ARR). Этот модуль превращает обычный IIS в балансировщик нагрузки.

Проанализируем процесс настройки:

1. Устанавливаются два сервера IIS в конфигурации Server Farm.
2. Настраивается Health Check: ARR будет регулярно опрашивать страницу публикации 1С. Если один узел перестанет отвечать, трафик мгновенно переключится на второй.
3. Настройка Client Affinity (Sticky Sessions): Это критически важный момент для 1С. Поскольку платформа хранит состояние сеанса, мобильный клиент должен на протяжении всего сеанса работать с одним и тем же узлом кластера. ARR умеет привязывать клиента по специальной Cookie.

Тонкая настройка IIS для стабильности мобильного клиента

Часто администраторы сталкиваются с тем, что мобильное приложение 1С внезапно «вылетает» или требует повторной авторизации. Рассмотрим причины, скрытые в стандартных настройках IIS, и исправим их.

Разберем параметры Application Pool (Пула приложений):

• Idle Time-out (минуты): По умолчанию стоит 20. Это значит, что если мобильный пользователь не нажимал кнопки 20 минут, IIS «прибьет» рабочий процесс. При следующем обращении пользователь будет ждать 10–15 секунд, пока всё инициализируется заново. Рекомендация: установите значение 0 (никогда не завершать).
• Regular Time Interval (Recycling): Стандартная настройка — перезагрузка каждые 1740 минут. Это происходит в непредсказуемое время и обрывает все активные сессии. Рекомендация: отключите автоматический ресайклинг или назначьте его на 3 часа ночи, когда пользователей точно нет.

Настройка прав доступа: принцип минимальных привилегий

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

Никогда не запускайте пул приложений от имени системного администратора. Правильный алгоритм выглядит так:

1. Создайте выделенную учетную запись (локальную или доменную, если необходимо) для работы пула приложений, например IIS_1C_Mobile.
2. Дайте этой учетной записи права «Чтение и выполнение» на папку bin установленной платформы 1С.
3. Дайте права «Полный доступ» (или как минимум «Изменение») только на папку, где лежит файл публикации default.vrd.
4. В настройках пула приложений IIS укажите эту учетную запись в разделе Identity.

Это гарантирует, что даже при взломе веб-сервера злоумышленник не сможет выйти за пределы каталога публикации и не получит доступ к конфигурационным файлам сервера или реестру Windows.

Linux против Windows: что выбрать для фронтенда?

В инфраструктуре, где всё построено на Windows, часто боятся внедрять Linux. Однако для роли входной точки (frontend) пара Linux + Nginx показывает себя лучше. Разберем почему:

• Устойчивость: Linux-системы могут работать годами без перезагрузки, а Nginx практически невозможно «уронить» большим количеством сетевых соединений.
• Keepalived: Вы можете поднять два маленьких сервера на Linux и объединить их через Keepalived (протокол VRRP). У них будет один виртуальный IP-адрес. Если одна виртуалка «умрет», вторая подхватит этот IP за миллисекунды, и пользователи даже не заметят сбоя.

Подведем итог. Оптимальная схема для вашего мобильного решения 1С выглядит следующим образом: два легких сервера на Linux с Nginx в качестве отказоустойчивого фронтенда, которые перенаправляют запросы на внутренний отказоустойчивый кластер IIS, размещенный на отдельных виртуальных машинах (не совмещенных с серверами приложений 1С). Такая многослойная защита обеспечит и высокую доступность 24/7, и надежную изоляцию ваших данных.