← На главную

При построении отказоустойчивых и масштабируемых систем на базе платформы 1С:Предприятие часто возникает вопрос: можно ли объединить в один кластер центральный сервер с разрядностью x64 и дополнительные серверы с 32-разрядной архитектурой? Рассмотрим подробнее, как устроено межсерверное взаимодействие в кластере 1С, с какими специфическими проблемами можно столкнуться и как их правильно решать.

Особенности взаимодействия серверов разной разрядности

С точки зрения сетевого взаимодействия, кластер 1С прекрасно функционирует на узлах с различной архитектурой и операционными системами. Главный менеджер кластера (rmngr) общается с рабочими процессами (rphost) на рабочих серверах по сетевым протоколам. При этом процессы не обращаются напрямую к адресному пространству оперативной памяти соседних узлов.

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

Подводные камни смешанной архитектуры кластера

Проанализируем основные риски и узкие места, с которыми можно столкнуться при использовании 32-битных рабочих серверов в составе кластера:

1. Жесткое ограничение оперативной памяти для 32-битных процессов: В 32-разрядном рабочем процессе rphost максимальный объем адресного пространства ограничен 2 ГБ (в редких случаях до 3–3,2 ГБ при специальной настройке ОС). Если балансировщик кластера направляет тяжелое фоновое задание или ресурсоемкий отчет на 32-битный рабочий процесс, происходит исчерпание памяти (ошибка Out of Memory), что приводит к аварийному завершению процесса.
2. Слепота менеджера кластера к разрядности: Менеджер кластера rmngr распределяет сеансы пользователей на основе замеряемых показателей производительности и количества сеансов, но не учитывает разрядность процесса и лимиты памяти в 2 ГБ для 32-битных узлов.
3. Ограничения внешних компонент и COM-объектов: Запуск 32-битных внешних компонент (файлы .dll) или COM-соединений привязан к разрядности исполняемого процесса rphost. Запуск 32-битной компоненты на 64-битной службе сервера (или наоборот) приводит к ошибке выполнения.

Проблема с нехваткой сетевых портов и зависанием сеансов

Рассмотрим реальную проблему, с которой сталкиваются администраторы при тонкой настройке рабочих процессов. Для предотвращения разрастания 32-битных процессов по памяти в настройках кластера часто задают жесткое ограничение по количеству сеансов на один процесс (например, не более 25 сеансов на рабочий процесс).

При такой настройке платформа 1С автоматически порождает множество новых процессов rphost при росте числа подключений пользователей. Для каждого нового процесса rphost требуется выделение отдельного сетевого порта из диапазона IP-портов кластера. Если диапазон доступных портов ограничен, то при попытке открыть очередной процесс у сервера банально заканчиваются свободные порты. Это проявляется в виде зависания сеансов, нереагирования пользователей и ошибок переподключения.

Способы решения и рекомендации по настройке

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

1. Расширение диапазона сетевых портов: При настройке малого количества сеансов на один процесс (например, 25 сеансов) обязательно увеличьте диапазон портов в настройках кластера серверов 1С и в сетевом экране (файрволе), чтобы у операционной системы всегда был запас свободных сокетов для запуска новых процессов rphost.
2. Использование правил "Требования назначения функциональности": В консоли администройства кластера настройте правила распределения сервисов. Запретите 32-битным узлам выполнять тяжелые сервисы (например, сервис фоновых заданий или полнотекстового поиска), закрепив их за 64-битным центральным сервером.
3. Дробление процессов и настройка перезапуска: На 32-битных серверах настраивайте запуск нескольких процессов rphost с ограничением количества сеансов и регулярным интервалом перезапуска рабочих процессов для борьбы с фрагментацией памяти.
4. Перевод кластера на единую 64-разрядную платформу: Оптимальным долгосрочным решением является полный отказ от 32-битных узлов и перевод всех серверов кластера на 64-разрядную версию платформы 1С:Предприятие. Это полностью снимет ограничения по памяти для процессов rphost.