Создание кластера серверов 1С: от планирования до запуска

Развертывание кластера серверов 1С:Предприятие — критически важный этап для организаций, работающих с высокими нагрузками или распределённой инфраструктурой. Кластер позволяет распределять вычислительные ресурсы между несколькими рабочими процессами (rphost), обеспечивает отказоустойчивость и упрощает масштабирование системы. Однако неправильная настройка может привести к падению производительности, конфликтам лицензий или даже потере данных.

Эта статья покрывает все этапы — от выбора аппаратной платформы до тонкой настройки параметров кластера. Мы рассмотрим особенности развертывания на Windows Server 2022 и Linux (CentOS/RHEL, Astra Linux), акцентируем внимание на типичных ошибках при работе с ragent и rmngr, а также дадим рекомендации по оптимизации для баз данных PostgreSQL и MS SQL. Инструкция актуальна для платформы 1С:Предприятие 8.3.23 и выше, включая облачные сценарии.

1. Подготовка инфраструктуры: требования к серверам и сети

Прежде чем приступать к установке, необходимо оценить текущие и будущие нагрузки. Кластер 1С чувствителен к задержкам сети и дисковой подсистеме — при латентности между узлами более 5 мс производительность падает на 30-40%. Это критично для систем с более чем 50 одновременно работающими пользователями.

Минимальные требования к серверу для рабочего процесса (rphost):

• 🖥️ Процессор: 4 ядра (рекомендуется Intel Xeon или AMD EPYC с поддержкой AVX2)
• 🧠 ОЗУ: 8 ГБ + 1 ГБ на каждые 10 пользователей (для PostgreSQL требуется отдельный пул памяти)
• 💾 Хранилище: SSD NVMe с производительностью не менее 3000 IOPS на операции чтения/записи
• 🌐 Сеть: 10 Гбит/с между узлами кластера (для виртуальных машин — отдельный VLAN)

Для центрального сервера кластера (rmngr) достаточно 2 ядер и 4 ГБ ОЗУ, но он должен располагаться на отдельной виртуальной машине или физическом сервере. Использование одного сервера для rmngr и rphost допускается только в тестовых средах!

⚠️ Внимание: Если вы планируете использовать PostgreSQL в качестве СУБД, убедитесь, что версия сервера не ниже 14.5. Более ранние версии имеют известные проблемы с блокировками при работе с кластером 1С.

Компонент	Минимальные требования	Рекомендуемая конфигурация
Центральный сервер (rmngr)	2 ядра, 4 ГБ ОЗУ	4 ядра, 8 ГБ ОЗУ, RAID 1 для системного диска
Рабочий процесс (rphost)	4 ядра, 8 ГБ ОЗУ	8+ ядер, 32 ГБ ОЗУ, NVMe SSD для временных файлов
СУБД (MS SQL/PostgreSQL)	4 ядра, 16 ГБ ОЗУ	16+ ядер, 64 ГБ ОЗУ, SAN или DAS с производительностью 10K+ IOPS
Сеть	1 Гбит/с	10 Гбит/с с поддержкой Jumbo Frames (MTU 9000)

2. Выбор операционной системы: Windows vs Linux

Платформа 1С:Предприятие официально поддерживает обе операционные системы, но есть ключевые различия в производительности и администрировании:

Windows Server 2019/2022:

• ✅ Проще в настройке для администраторов, знакомых с Active Directory и Group Policy
• ✅ Лучшая интеграция с MS SQL Server (оптимизированные драйверы)
• ❌ Более высокое потребление ресурсов (накладные расходы на GUI и службы)
• ❌ Лицензионные затраты на серверные CAL и СУБД

Linux (CentOS 7+, RHEL 8+, Astra Linux):

• ✅ Бесплатная лицензия (за исключением RHEL с подпиской)
• ✅ Более высокая стабильность при длительных нагрузках
• ✅ Оптимизированная работа с PostgreSQL
• ❌ Требует знания командной строки для настройки firewalld, SELinux

Для новых развертываний рекомендуем Linux, если в вашей команде есть администраторы с опытом работы в этой ОС. Для legacy-систем или небольших организаций (<50 пользователей) может быть проще остаться на Windows.

3. Установка центрального сервера кластера (rmngr)

Центральный сервер кластера (rmngr) управляет рабочими процессами, балансировкой нагрузки и лицензиями. Его установка включает несколько критичных шагов:

Шаг 1. Установка пакетов

На Windows запустите установщик 1С:Предприятие и выберите компонент Сервер 1С:Предприятия. На Linux используйте команды:

# Для CentOS/RHEL
sudo yum install 1c-enterprise83-server
sudo yum install 1c-enterprise83-ws  # Веб-сервер (опционально)

Для Debian/Ubuntu
sudo apt-get install 1c-enterprise83-server

Шаг 2. Инициализация кластера

После установки выполните команду инициализации (пример для Linux):

sudo /opt/1C/v8.3/x86_64/ras --daemon cluster --port=1541 --range=1560:1591 --d /var/1C/clusters/main

Параметры:

• --port=1541 — порт для подключения менеджера кластера
• --range=1560:1591 — диапазон портов для рабочих процессов
• --d /var/1C/clusters/main — каталог хранения данных кластера

Шаг 3. Проверка статуса

Убедитесь, что служба запущена:

sudo systemctl status srv1cv83  # Для Linux
sc query "1C:Enterprise 8.3 Server Agent"  # Для Windows

⚠️ Внимание: Если вы используете Docker для развертывания кластера, убедитесь, что контейнеры имеют доступ к хостовым портам в диапазоне 1540-1591. В противном случае рабочие процессы не смогут подключиться к менеджеру.

Установлены пакеты 1C-enterprise83-server|

Создан каталог для данных кластера (/var/1C/clusters/main)|

Открыты порты 1540-1591 в firewall|

Служба srv1cv83 запущена и активна|

4. Добавление рабочих процессов (rphost)

Рабочие процессы (rphost) выполняют основную вычислительную нагрузку. Их количество зависит от числа пользователей и типа задач:

• 📊 Для фоновых задач: 1 процесс на 20-30 пользователей
• 🖥️ Для интерактивной работы: 1 процесс на 10-15 пользователей
• 🔄 Для регламентных заданий: отдельный процесс с приоритетом Low

Команда для добавления рабочего процесса (Linux):

sudo /opt/1C/v8.3/x86_64/ragent --daemon --port=1541 --register \
--name=worker1 --port-range=1560:1591 \
--mem-limit=4096 --mem-limit-cr=3500 \
--perf-cnt-interval=60

Параметры, требующие особого внимания:

• --mem-limit=4096 — лимит памяти в МБ (указывайте на 10-15% меньше физической памяти сервера)
• --perf-cnt-interval=60 — интервал сбора статистики производительности (по умолчанию 300 секунд)
• --priority=Normal — приоритет процесса (Low для фоновых задач)

Для Windows аналогичные настройки выполняются через Консоль администрирования сервера 1С (1CEnterprise.exe с ключом /Admin).

5. Настройка балансировки нагрузки и отказоустойчивости

Кластер 1С поддерживает два механизма балансировки:

1. Динамическая балансировка — распределение по текущей загрузке процессов (рекомендуется для большинства сценариев).
2. Статическая балансировка — распределение по заранее определённым правилам (полезно для критичных задач).

Для включения динамической балансировки отредактируйте файл конфигурации кластера (/var/1C/clusters/main/conf.cfg на Linux или реестр на Windows):

[cluster]
enable_dynamic_balance = true
balance_check_interval = 30  # Интервал проверки загрузки (секунды)
max_sessions_per_process = 50  # Максимум сессий на один rphost

Для отказоустойчивости настройте резервирование рабочих процессов:

[failover]
enable = true
reserve_process_count = 2  # Количество резервных процессов
health_check_interval = 10  # Интервал проверки "жизни" процесса

⚠️ Внимание: При использовании PostgreSQL в кластерном режиме (Patroni или pg_auto_failover) убедитесь, что параметр max_connections в СУБД превышает количество возможных подключений от рабочих процессов 1С минимум на 30%. Иначе возможны ошибки типа "Sorry, too many clients already".

6. Оптимизация производительности кластера

Производительность кластера зависит не только от "железа", но и от правильных настроек. Вот ключевые параметры для оптимизации:

1. Настройки рабочих процессов (rphost):

• 🔧 --mem-limit: Установите на 10% меньше физической памяти сервера (например, 32 ГБ для сервера с 36 ГБ ОЗУ).
• ⚡ --perf-cnt-interval: Уменьшите до 30 секунд для более оперативного мониторинга.
• 📉 --priority: Для фоновых задач используйте Low, для интерактивных — Normal.

2. Настройки кластера (rmngr):

• 🔄 balance_check_interval: Оптимальное значение — 15-30 секунд.
• 🚦 max_sessions_per_process: Не превышайте 50 сессий на процесс для стабильной работы.
• 🗄️ temp_data_path: Укажите путь к NVMe SSD для временных файлов (например, /mnt/nvme/1c_temp).

3. Настройки СУБД:

Параметр	MS SQL	PostgreSQL
max_worker_threads	Авто (или не более 2×количество ядер)	Установите в postgresql.conf равным количеству ядер × 2
work_mem	Н/Д	16-32 МБ (для сложных запросов)
maintenance_work_mem	Н/Д	512 МБ - 1 ГБ (для VACUUM)
checkpoint_completion_target	Н/Д	0.9 (для снижения пиковых нагрузок на диск)

Для мониторинга производительности используйте утилиты:

• 📈 1С:Администратор сервера (входит в дистрибутив)
• 🔍 perfmon (Windows) или vmstat/iostat (Linux)
• 📊 Grafana + Prometheus с экспортером 1c-metrics-exporter

7. Безопасность кластера: защита от несанкционированного доступа

Кластер 1С по умолчанию не шифрует трафик между узлами, что создаёт риски при передаче данных по сети. Минимальный набор мер безопасности:

1. Шифрование трафика:

• 🔒 Настройте TLS 1.2+ для соединений между rmngr и rphost:

[cluster]
use_ssl = true
ssl_cert_file = /etc/1c/ssl/server.crt
ssl_key_file = /etc/1c/ssl/server.key

2. Аутентификация:

• 🔑 Отключите анонимный доступ в файле conf.cfg:

[security]
allow_anonymous = false
auth_required = true

3. Сетевая изоляция:

• 🌐 Ограничьте доступ к портам кластера (1540-1591) только для доверенных IP в firewalld/iptables.
• 🛡️ Разместите кластер в отдельной подсети (VLAN) с доступом только для серверов приложений и баз данных.

4. Аудит и мониторинг:

• 📜 Включите логирование событий кластера:

[logging]
log_file = /var/log/1c/cluster.log
log_level = info  # Уровни: error, warn, info, debug
max_log_size = 100  # Максимальный размер лога в МБ

⚠️ Внимание: Если вы используете 1С:Предприятие в облаке (например, 1C:Fresh или AWS), проверьте, поддерживает ли ваш провайдер шифрование трафика между узлами кластера. Некоторые облачные решения по умолчанию используют незашифрованные соединения внутри частной сети.

8. Типичные ошибки и их решение

Даже при правильной настройке кластера могут возникать ошибки. Вот наиболее распространённые проблемы и способы их устранения:

Ошибка	Причина	Решение
Не удалось подключиться к кластеру (err=10061)	Порт 1541 заблокирован firewall или служба rmngr не запущена	Проверьте netstat -tulnp | grep 1541 (Linux) или Test-NetConnection -Port 1541 (Windows)
Недостаточно лицензий для подключения	Лицензии привязаны к другому серверу или истекли	Проверьте лицензии в Консоли администрирования или через rac license
Ошибка блокировки базы данных (SQLDeadlock)	Конфликты транзакций в СУБД при высокой нагрузке	Увеличьте max_worker_threads в СУБД и настройте read_committed_snapshot=on (MS SQL)
Рабочий процесс аварийно завершён (segfault)	Нехватка памяти или повреждение данных в временных файлах	Увеличьте --mem-limit и проверьте права на каталог временных файлов

Для диагностики сложных ошибок используйте утилиты:

• 🔧 rac — консольная утилита администрирования кластера (rac cluster list, rac process list)
• 📡 truss/strace (Linux) или Process Monitor (Windows) — для отслеживания системных вызовов
• 📈 1C:Технологический журнал — включите его в настройках кластера для детальной отладки

Если ошибка повторяется, проверьте базу знаний ИТС по коду ошибки или обратитесь в поддержку 1С с логами (/var/log/1c/ или C:\Program Files\1cv8\logs\).

Что делать, если кластер не стартует после обновления?

1. Проверьте совместимость версий rmngr и rphost (они должны быть одинаковыми).

2. Удалите файлы блокировок в каталоге кластера (*.lck).

3. Запустите rmngr в режиме отладки: /opt/1C/v8.3/x86_64/ragent --debug --port=1541 и изучите вывод.

FAQ: Частые вопросы по настройке кластера 1С

Можно ли разместить кластер 1С на виртуальных машинах?

Да, но с учётом следующих ограничений:

• 🖥️ Виртуальные машины должны иметь гарантированные ресурсы (резервирование CPU и RAM).
• 💾 Хранилище должно быть на SSD с низкой латентностью (например, VMware VSAN или Ceph).
• 🌐 Сетевые адаптеры виртуальных машин должны использовать VMXNET3 (VMware) или virtio (KVM).

Для производственных систем с более чем 100 пользователями рекомендуем физические серверы.

Как масштабировать кластер при росте нагрузки?

Есть два основных способа:

1. Горизонтальное масштабирование: Добавьте новые рабочие процессы (rphost) на существующие или новые серверы. Используйте команду:

   sudo /opt/1C/v8.3/x86_64/ragent --daemon --port=1541 --register --name=worker2

2. Вертикальное масштабирование: Увеличьте ресурсы существующих серверов (ОЗУ, CPU) и перезапустите процессы с новыми лимитами:

   sudo systemctl restart srv1cv83@worker1

Для баз данных PostgreSQL также рассмотрите возможность добавления реплик для чтения (read replicas).

Как перенести кластер на другой сервер?

Процедура переноса включает следующие шаги:

1. Остановите все рабочие процессы: rac cluster stop.
2. Скопируйте каталог кластера (например, /var/1C/clusters/main) на новый сервер.
3. Установите на новом сервере ту же версию 1С:Предприятие.
4. Запустите менеджер кластера с теми же параметрами (--port, --range).
5. Обновите DNS-записи или настройки балансировщика нагрузки.

Для минимизации простоя используйте репликацию каталога кластера заранее (например, через rsync или DRBD).

Нужно ли обновлять кластер при выходе новой версии 1С?

Обновление кластера рекомендуется в следующих случаях:

• 🔄 Выход новой мажорной версии платформы (например, с 8.3.22 на 8.3.23).
• 🛡️ Исправление критичных уязвимостей (информация публикуется на сайте 1С).
• ⚡ Добавление новых функций, критичных для вашего бизнес-процесса (например, поддержка HTTP/2 в веб-сервере).

Перед обновлением:

1. Создайте резервную копию каталога кластера.
2. Проверьте совместимость новой версии с вашей СУБД.
3. Обновите сначала тестовую среду и протестируйте критичные сценарии.

Как настроить резервное копирование кластера?

Резервное копирование кластера включает два компонента:

1. Конфигурационные файлы: Регулярно архивируйте каталог кластера (например, /var/1C/clusters/main) с помощью tar или rsync.
2. Данные СУБД: Используйте native-инструменты:
   • Для MS SQL: sqlcmd -Q "BACKUP DATABASE [BaseName] TO DISK='path'"
   • Для PostgreSQL: pg_basebackup -D /backup/pg -U replicator

Рекомендуемая частота:

• 📁 Конфигурационные файлы — ежедневно.
• 🗃️ Данные СУБД — согласно политике компании (от ежедневного инкрементального до еженедельного полного бэкапа).