Установка и настройка сервера 1С:Предприятие с нуля до рабочего кластера

Чтобы развернуть сервер 1С, нужны четыре вещи: машина с достаточным железом, СУБД (PostgreSQL или MS SQL Server), серверная часть платформы 1С:Предприятия и настроенный кластер. Порядок установки именно такой: сначала система и СУБД, потом платформа, потом кластер и базы.

Клиент-серверный вариант нужен, когда файловая база начинает тормозить: в базе работают больше 5-10 человек, есть тяжёлые отчёты и закрытие месяца , нужны регламентные задания и управление сеансами. Ниже — весь путь от выбора сервера до мониторинга. Описано для платформы 8.3 с интерфейсом «Такси», Windows Server 2016 и новее либо современного дистрибутива Linux.

Подготовка: железо и операционная система

Сервер 1С и СУБД можно держать на одной машине или на двух. Для 10-30 пользователей обычно хватает одной машины, дальше разумнее разнести: отдельный сервер приложений 1С и отдельный сервер СУБД.

Ориентиры для одной машины (примерно, под обычную бухгалтерскую базу):

Что важно по выбору:

• ⚡ Диск влияет сильнее, чем процессор. Для баз и журналов транзакций берите SSD или NVMe.
• 🧠 Память: рабочие процессы 1С и СУБД делят её между собой. Если машина одна, часть ОЗУ нужно жёстко отдать СУБД, иначе их начнёт выгружать в своп.
• 🖥️ Частота ядра важнее их числа: многие операции 1С выполняются в один поток.
• 💾 Если база растёт, закладывайте диск с запасом в 2-3 раза: копии и временные файлы СУБД занимают место.

Что с ОС. На Windows Server проще: графическая консоль, привычное администрирование, но нужна лицензия на систему. На Linux серверная часть 1С работает так же, СУБД чаще всего PostgreSQL, лицензий на ОС не нужно, но администрировать придётся в консоли. Если в штате нет Linux-администратора, начните с Windows.

Выбор и установка СУБД

Платформа хранит данные во внешней СУБД. Поддерживаются MS SQL Server, PostgreSQL (в том числе сборки, которые поставляет 1С и Постгрес Про), IBM Db2 и Oracle. На практике выбирают из первых двух.

Сверяйте версию СУБД с таблицей совместимости для вашей платформы. Слишком новая версия, которую платформа ещё не поддерживает, приводит к ошибкам при создании базы.

PostgreSQL

Установите сборку, подходящую для вашей версии платформы. Дальше настройте postgresql.conf под железо. Стартовые ориентиры:

• shared_buffers — примерно 25% оперативной памяти, отданной СУБД;
• effective_cache_size — 50-75% этой же памяти;
• work_mem — небольшие значения (единицы-десятки мегабайт): он умножается на число одновременных операций;
• max_connections — с запасом на рабочие процессы 1С, но без раздувания.

Это отправная точка, а не готовый рецепт. После запуска смотрите нагрузку и подкручивайте.

MS SQL Server

При установке выберите сортировку без учёта регистра, как требует документация к вашей платформе. Ограничьте память сервера параметром максимальной памяти, чтобы остались ресурсы под систему и 1С. Файлы данных и журнал транзакций разнесите по разным дискам.

Установка платформы 1С:Предприятие с серверной частью

Скачайте дистрибутив платформы нужного релиза у себя на портале поддержки. Версия платформы на сервере и на клиентах должна совпадать по первым трём числам (например, 8.3.24) — иначе клиент не подключится или предложит обновиться.

Windows

1. Запустите установщик платформы от имени администратора.
2. В списке компонентов отметьте «Сервер 1С:Предприятия». Без него службы сервера не появится.
3. Если нужна консоль администрирования, отметьте и её (или поставьте на другой машине).
4. На шаге установки службы оставьте запуск от отдельной учётной записи. По умолчанию создаётся пользователь USR1CV8, и это правильный вариант: у него нет лишних прав.
5. После установки откройте оснастку служб и убедитесь, что служба «Агент сервера 1С:Предприятия 8.3» запущена и стоит автозапуск.

Каталог служебных данных кластера называется srvinfo. Если на системном диске мало места, задайте для него другой путь при настройке службы.

Linux

Серверная часть ставится из пакетов, которые идут в дистрибутиве. Их несколько: общие компоненты, сервер, а также библиотеки. Установка создаёт пользователя usr1cv8 и группу grp1cv8, от них работает сервис. Рабочие данные кластера лежат в домашнем каталоге этого пользователя (/home/usr1cv8/.1cv8).

После установки запустите службу сервера через systemctl и проверьте, что она висит в состоянии «active». Если сервис не стартует, смотрите журнал: journalctl покажет, на чём он упал.

Кластер серверов: агент, менеджер и рабочие процессы

Кластер — это логическая единица сервера 1С. Архитектура такая:

• Агент сервера (ragent) — служба, которая принимает подключения и управляет кластерами на машине. Слушает порт 1540.
• Менеджер кластера (rmngr) — управляет кластером, хранит список сеансов, блокировок. Порт 1541.
• Рабочие процессы (rphost) — выполняют всю работу: обслуживают сеансы пользователей и обращаются к СУБД. Порты берутся из диапазона, который задаётся в свойствах рабочего сервера.

При установке на сервере обычно уже создан кластер на локальной машине. Если его нет или нужен второй, создаёте его в консоли администрирования серверов.

Как создать информационную базу в кластере:

1. В консоли администрирования раскройте узел «Информационные базы» нужного кластера.
2. Команда создания новой базы открывается из контекстного меню.
3. Укажите имя базы (его увидят пользователи в списке), тип СУБД, имя сервера СУБД и имя базы данных.
4. Для пользователя СУБД введите логин и пароль. Включите создание базы данных, если её ещё нет.
5. Подтвердите. Платформа создаст пустую базу, дальше в неё загружают конфигурацию или выгрузку .dt.

Проверить кластер из командной строки можно утилитой администрирования rac, например rac cluster list покажет доступные кластеры, а rac help — полный список команд. Для работы rac должна быть запущена служба ras (по умолчанию слушает порт 1545).

Сеть и безопасность

Сервер должен быть доступен только тем, кому нужно. Откройте на межсетевом экране только то, что необходимо:

Практические правила:

• 🔒 Порт СУБД открыт только для сервера 1С, пользователям он не нужен.
• 🔒 Не публикуйте 1540-1541 и диапазон рабочих процессов в интернет. Для удалённой работы используйте VPN или веб-доступ через публикацию.
• 🔒 Задайте пароль администратора кластера и не храните его в открытом виде в скриптах.
• 🔒 Пароль пользователя СУБД сделайте сложным: через него любой с доступом к порту получит базу напрямую.
• Диапазон портов рабочих процессов сузьте до нужного, чтобы не открывать лишнего.

Если администратор кластера задан, консоль будет просить его пароль при подключении. Потеряли пароль — не пересоздавайте кластер. Остановите службу сервера, восстановите файлы кластера из резервной копии или обратитесь к тому, кто настраивал сервер.

Настройка производительности: соединения и процессы

Свойства рабочего сервера и кластера — главный рычаг. Их открывают в консоли администрирования.

Что стоит посмотреть:

• Количество информационных баз на рабочий процесс и количество соединений на рабочий процесс. Если в один rphost загнать слишком много сеансов, он станет узким местом, а память под него вырастет. Много маленьких процессов — расход на накладные расходы. Для типичной бухгалтерии хорошо работает среднее значение: несколько десятков соединений на процесс.
• Допустимый объём памяти рабочих процессов в свойствах кластера. Когда процесс превышает лимит, менеджер перезапускает его в безопасное время.
• Интервал перезапуска рабочих процессов (в секундах). Периодический перезапуск освобождает память, но обрывает вызовы на момент перезапуска. Для небольших баз ставят интервал от нескольких часов до суток.
• Безопасный расход памяти за один вызов — защита от тяжёлых запросов, которые съедают всю память.

Пример рассуждения: у вас 40 одновременных сеансов и 32 ГБ ОЗУ, из них 12 ГБ отдано СУБД. На 1С остаётся около 16-18 ГБ с запасом для системы. Если один рабочий процесс при таких сеансах разрастается до 4-5 ГБ, то 3-4 процесса по 10-15 соединений будут устойчивее одного большого.

Про неактивные сеансы. Зависшие соединения не освобождают лицензию и занимают память. Просмотрите список сеансов в консоли (узел «Сеансы» информационной базы) и завершайте ненужные вручную. Перед массовым завершением проверьте, что это не фоновые задания, которые выполняют долгую обработку.

Отдельно позаботьтесь об индексах и статистике СУБД: без регулярного обслуживания даже мощный сервер деградирует. В PostgreSQL это автоочистка и ручной VACUUM ANALYZE для больших таблиц, в MS SQL — задания обновления статистики и перестроения индексов.

Резервное копирование

Копировать нужно не только базу. Минимальный набор:

1. База данных СУБД — полная копия по расписанию и копии журнала транзакций, если нужна точка восстановления внутри дня.
2. Выгрузка информационной базы в .dt — страховка на случай несовместимости версий СУБД.
3. Каталог служебных данных кластера (srvinfo) — там хранится реестр кластера и настройки. Копировать его надёжнее при остановленной службе.
4. Файлы конфигурации и расширений, если вы их хранили вне базы, а также конфигурационные файлы postgresql.conf и pg_hba.conf или настройки SQL Server.

Пример копии PostgreSQL в сжатом формате:

pg_dump -h localhost -U postgres -Fc -f /backup/buh_$(date +%F).dump buh

Для MS SQL используйте план обслуживания или задание агента на BACKUP DATABASE. Копии храните на отдельном диске или другом сервере и раз в квартал пробуйте восстановить копию на тестовой машине: копия, которую ни разу не разворачивали, ничего не гарантирует.

Мониторинг и обновления

Что отслеживать постоянно:

• 📊 загрузку процессора и памяти на сервере 1С и сервере СУБД;
• 📊 свободное место на дисках с базами, журналом и копиями;
• 📊 число сеансов и размер процессов rphost;
• 📊 длительные запросы и блокировки в СУБД;
• 📊 успешность ночных копий и регламентных заданий.

Для этого хватает счётчиков системы и стандартных средств СУБД. В самой 1С есть технологический журнал и журнал регистрации: первый нужен, чтобы искать долгие вызовы и блокировки, второй — чтобы смотреть события пользователей и ошибки. Включайте технологический журнал на ограниченное время и на узкий набор событий, иначе он быстро забьёт диск.

Обновление платформы на сервере:

1. Скачайте новую версию и поставьте её рядом со старой (платформы живут в отдельных каталогах).
2. Подготовьте клиентские места: версия на клиенте должна совпасть с серверной.
3. Остановите работу пользователей, сделайте копию, обновите службу сервера на новую версию.
4. Проверьте запуск базы, проведите тестовый документ.

Конфигурации обновляют отдельно от платформы, по порядку релизов, и тоже сначала на копии.

Частые вопросы