Масштабирование информационной системы 1С: Предприятие становится критически важным этапом развития компании, когда один центральный сервер перестает справляться с растущим количеством пользователей и объемом транзакций. Добавление второго сервера в инфраструктуру позволяет не только распределить нагрузку, но и обеспечить отказоустойчивость всей системы в целом. Этот процесс требует тщательной подготовки сетевой среды и понимания архитектуры кластера серверов 1С.
В данной инструкции мы рассмотрим технические нюансы подключения дополнительного узла к существующему кластеру. Вы узнаете, как правильно настроить взаимодействие между узлами, избежать конфликтов портов и обеспечить корректную работу рабочих процессов (rphost).
Перед началом работ необходимо убедиться, что базовая инфраструктура готова к приему нового узла. Ошибки на этапе предварительной настройки могут привести к нестабильной работе базы данных или полному отказу кластера. Мы последовательно разберем каждый этап, от подготовки операционной системы до настройки менеджера кластера.
Подготовка инфраструктуры и системные требования
Первым шагом является обеспечение идентичности или совместимости версий программного обеспечения на всех узлах кластера. Сервер 1С: Предприятия, который вы планируете добавить, должен иметь ту же версию платформы, что и основной управляющий сервер, либо быть совместимой с ним версией в рамках одного мажорного релиза. Различия в минорных версиях могут привести к невозможности регистрации сервера в кластере или ошибкам при запуске рабочих процессов.
Особое внимание следует уделить сетевым настройкам. Между будущим вторым сервером и основным менеджером кластера должен быть открыт доступ по необходимым портам. По умолчанию используется диапазон портов 1540-1554 для взаимодействия компонентов кластера. Если в вашей сети настроены строгие правила брандмауэра, необходимо добавить соответствующие исключения для исполняемых файлов ragent.exe и rphost.exe.
⚠️ Внимание: Убедитесь, что имя хоста второго сервера разрешается в IP-адрес как самим сервером, так и основным узлом кластера. Проблемы с DNS могут привести к тому, что сервер будет виден в консоли администрирования, но рабочие процессы на нем не запустятся.
Также критически важно проверить наличие необходимых библиотек и зависимостей в операционной системе. Для Linux-серверов это могут быть специфические пакеты glibc или libstdc++, версии которых должны совпадать с требованиями дистрибутива 1С. На Windows-серверах убедитесь, что установлены все последние обновления системы, так как агент сервера может зависеть от конкретных обновлений безопасности ядра ОС.
Установка программного обеспечения на второй узел
Процесс инсталляции на втором сервере практически идентичен установке на первичный узел, за исключением некоторых ключевых моментов конфигурации. Запустите дистрибутив платформы 1С: Предприятие и выберите компонент "Сервер 1С: Предприятия". В мастере установки вам будет предложено выбрать тип установки: "Полная", "Выборочная" или "Модификация". Для нового узла рекомендуется выбрать Выборочную установку, чтобы контролировать состав устанавливаемых компонентов.
На этапе выбора компонентов убедитесь, что отмечены только необходимые службы. Вам нужен "Агент сервера 1С: Предприятия" и, при необходимости, "Менеджер кластера серверов 1С: Предприятия". Однако, если у вас уже есть действующий центральный менеджер кластера, устанавливать второй менеджер на этот узел не требуется, если вы не планируете создавать резервный центральный сервер для отказоустойчивости самого менеджера.
- 🖥️ Убедитесь, что путь установки совпадает с путем на основном сервере для упрощения администрирования.
- 🔐 Задайте надежный пароль для системного пользователя, от имени которого будут запускаться службы 1С.
- ⚙️ Отключите автоматический запуск служб сразу после установки, чтобы сначала провести ручную настройку конфигурационных файлов.
После завершения копирования файлов не спешите запускать службы. Сначала необходимо проверить параметры запуска. В некоторых случаях, особенно при миграции со старых версий, требуется ручная правка параметров реестра или конфигурационных файлов в директории bin. Использование стандартных настроек по умолчанию может быть недостаточным для высоконагруженных систем.
☑️ Готовность к установке
Регистрация сервера в кластере 1С
После установки ПО необходимо зарегистрировать новый физический сервер в логическом кластере. Это действие выполняется через оснастку Администрирование серверов 1С Предприятия (mmc-консоль) или с помощью утилиты командной строки ras. Подключитесь к основному менеджеру кластера и в дереве объектов найдите узел "Центральные серверы 1С: Предприятия".
Добавление нового сервера осуществляется через контекстное меню папки "Серверы". В открывшемся окне необходимо указать сетевое имя нового хоста или его IP-адрес. Система автоматически попытается связаться с агентом сервера на указанном адресе. Если соединение успешно, вы увидите новый узел в списке, помеченный зеленым индикатором статуса.
Важным параметром при регистрации является вес сервера. Этот параметр определяет приоритет распределения рабочих процессов менеджером кластера. Если вы устанавливаете второй сервер на менее мощное "железо", целесообразно установить для него меньший вес, чем у основного узла. Это позволит балансировщику нагрузки направлять больше соединений на более производительную машину.
| Параметр | Значение по умолчанию | Рекомендация для 2-го сервера | Влияние на работу |
|---|---|---|---|
| Вес сервера | 100 | 50-100 (в зависимости от CPU) | Приоритет выделения rphost |
| Порт агента | 1545 | 1545 (или следующий свободный) | Сетевое взаимодействие |
| Диапазон портов | 1560-1591 | 1560-1591 (пересекающийся) | Порты рабочих процессов |
| Макс. рабочих процессов | 0 (без ограничений) | Ограничить по кол-ву ядер | Защита от перегрузки |
Что такое "Вес сервера" в кластере 1С?
Вес сервера — это относительная величина, используемая менеджером кластера для принятия решений о размещении рабочих процессов. Сервер с весом 200 будет получать в два раза больше рабочих процессов, чем сервер с весом 100, при условии наличия свободных ресурсов. Это не абсолютное ограничение, а коэффициент вероятности распределения.>
Настройка рабочих процессов и кластеров
После успешной регистрации физического сервера необходимо настроить логические кластеры, которые будут использовать ресурсы нового узла. В консоли администрирования раскройте дерево до нужного кластера информационных баз. Для каждого кластера можно задать параметры распределения рабочих процессов между доступными серверами.
По умолчанию менеджер кластера автоматически распределяет нагрузку. Однако для тонкой настройки можно использовать параметры "Центральный сервер" и "Рабочие серверы" для конкретного кластера ИБ. Вы можете явно указать, какие физические серверы могут обслуживать запросы к конкретной базе данных. Это полезно, если вы хотите выделить второй сервер исключительно для фоновых заданий или отчетов, разгрузив основной сервер от интерактивных пользователей.
При настройке рабочих процессов обратите внимание на параметры памяти. Для второго сервера имеет смысл установить жесткие лимиты на использование оперативной памяти процессом rphost.exe, чтобы избежать ситуации, когда один "тяжелый" запрос исчерпает все ресурсы узла. Используйте опцию Лимит памяти рабочего процесса в свойствах кластера.
⚠️ Внимание: Интерфейсы и параметры конфигурации могут изменяться в новых релизах платформы 1С. Перед внесением изменений в продакшн-среду сверьте актуальные настройки в документации к вашей конкретной версии платформы на сайте поддержки пользователей 1С.
Также рекомендуется настроить расписание перезапуска рабочих процессов. На втором сервере это можно сделать со сдвигом по времени относительно основного сервера, чтобы обеспечить плавное перераспределение сессий пользователей без заметных для них задержек. Автоматическая очистка памяти и перезапуск "зависших" процессов — ключевой элемент стабильности.
Особенности лицензирования при масштабировании
Вопрос лицензирования является одним из самых критичных при расширении инфраструктуры. Лицензии на сервер 1С: Предприятие (на 8, 16, 32, 64 и более ядер) привязываются к конкретному физическому или виртуальному серверу через ключ защиты (USB или программный). При установке второго сервера вам потребуется приобрести и активировать отдельную лицензию для этого узла.
Если вы используете программные лицензии (пин-коды), процесс активации проходит через утилиту hasp_update или интерфейс управления ключами. Важно, чтобы тип лицензии соответствовал архитектуре сервера. Например, лицензия на 32 ядра не может быть установлена на сервер с 64 ядрами, если не используется специальный режим работы или виртуализация с ограничением видимых ядер.
Для клиентских лицензий (на 5, 10, 20, 50, 100, 300, 500 рабочих мест) ситуация иная. Они могут быть установлены на любой сервер кластера, но суммарное количество одновременно подключенных сеансов не должно превышать купленный объем. В кластерной архитектуре лицензии проверяются централизованно, поэтому достаточно установить пакет клиентских лицензий на один из серверов, чтобы они стали доступны всему кластеру.
- 💳 Убедитесь, что ключи защиты HASP видны операционной системе второго сервера.
- 🔑 При использовании виртуальных машин проверьте, что лицензия привязана к корректному идентификатору оборудования.
- 📄 Сохраните файлы лицензий (.lic) в надежном месте для быстрого восстановления при сбоях.
В случае использования облачных лицензий 1С (1С:Линк), процесс упрощается. Достаточно авторизовать второй сервер в облаке через консоль управления, и лицензии будут выданы динамически в зависимости от потребности. Однако для локальных инсталляций классическая схема с ключами защиты остается основной.
Мониторинг и тестирование нового кластера
После завершения настройки и запуска служб необходимо провести комплексное тестирование работоспособности второго сервера. Первым индикатором успеха является появление рабочих процессов на новом узле при подключении пользователей. Используйте консоль администрирования или утилиту rmngr для мониторинга состояния кластера в реальном времени.
Обратите внимание на логи событий Windows или системные логи Linux (/var/log/syslog или журналы 1С в каталоге установки). Отсутствие ошибок при старте агента и регистрации в кластере — хороший знак, но реальную нагрузку сервер испытывает только при работе пользователей. Проведите нагрузочное тестирование, эмулируя работу 10-20 пользователей.
Для глубокого анализа используйте технологический журнал (ТЖ) 1С: Предприятие. Настройте сбор логов на втором сервере аналогично основному. Анализируя ТЖ, вы сможете увидеть, насколько равномерно распределяются запросы между серверами и нет ли аномальных задержек на новом узле. Параметры времени выполнения и потребления памяти должны быть сопоставимы на обоих серверах.
⚠️ Внимание: Если вы заметили, что все пользователи подключаются только к первому серверу, проверьте настройки веса серверов и наличие сетевых задержек между клиентами и вторым сервером. Менеджер кластера может считать второй сервер "недоступным" из-за таймаутов сети.
Регулярный мониторинг позволит выявить проблемы до того, как они повлияют на бизнес-процессы. Настройте систему оповещения (например, через Zabbix или Prometheus) для отслеживания доступности службы ragent и количества свободных рабочих процессов.
Можно ли добавить второй сервер 1С другой версии платформы?
Технически кластер 1С поддерживает работу серверов с разными минорными версиями платформы (например, 8.3.20 и 8.3.22), если они совместимы. Однако версия менеджера кластера (центрального сервера) должна быть не ниже версии самого старого сервера в кластере. Рекомендуется поддерживать одинаковые версии на всех узлах для избежания ошибок совместимости метаданных и форматов данных.
Что делать, если второй сервер не виден в консоли администрирования?
В первую очередь проверьте сетевую доступность порта 1545 (порт агента) с основного сервера. Убедитесь, что служба "Агент сервера 1С: Предприятия" запущена на втором узле. Также проверьте файл hosts и настройки DNS: имена серверов должны разрешаться в IP-адреса корректно с обеих сторон. Часто проблема кроется в брандмауэре Windows или iptables на Linux.
Нужна ли отдельная лицензия SQL-сервера для второго узла 1С?
Нет, лицензирование СУБД (Microsoft SQL Server, PostgreSQL) зависит от количества ядер процессора на сервере, где установлена сама база данных, а не от количества серверов 1С, подключающихся к ней. Если база данных находится на отдельном сервере, лицензируется именно он. Серверы 1С выступают лишь клиентами по отношению к СУБД.
Как перенести работающие сессии на второй сервер без разрыва соединения?
Мгновенно перенести активные сессии без разрыва невозможно. Однако можно настроить плавный переход: уменьшите вес первого сервера до 0 или ограничьте количество рабочих процессов на нем. Новые подключения будут идти на второй сервер, а старые сессии освободятся по мере выхода пользователей из системы или перезапуска рабочих процессов по расписанию.