Настройка сервера 1С 8.3 с нуля: от чистой Windows до боевой базы

Сервер 1С ставится за сорок минут. Дальше начинается настоящая работа: разобраться, под какой учёткой он крутится, куда пишет временные файлы и почему на тридцатом пользователе всё встало. Ниже — порядок, по которому мы в ITfresh поднимаем сервер приложений для офиса на 25–35 рабочих мест, и список мест, где чаще всего спотыкаются.

Ошибки этого этапа стоят дороже всех остальных, потому что вылезают через месяц — когда база уже наполнена и переставлять поздно.

Разрядность только x64. 32-битный сервер 1С упирается в ~1,7 ГБ на рабочий процесс и начинает сыпать «Недостаточно памяти» на ровном месте. Лицензия на 64-битный сервер входит в поставку КОРП; для ПРОФ она отдельная. Мы дважды видели, как клиент купил ПРОФ, поставил x86 «пока так» и через полгода получил падения в закрытии месяца.

Сервер приложений и СУБД — вместе или врозь? На 25–35 пользователях мы почти всегда ставим их на одну машину. Причина простая: сетевой стек между 1С и SQL — самый частый источник плавающих задержек, а на одной машине он превращается в shared memory. Разносить имеет смысл, когда база перевалила за 200–300 ГБ или когда СУБД обслуживает ещё что-то кроме 1С.

Ориентир по железу, который у нас работает на офисе бухгалтерии и торговли на 30 мест:

Отдельно про виртуализацию. 1С прекрасно живёт в ВМ, но не любит две вещи: динамическую память и overcommit процессора на хосте. Память выдаём фиксированно. Reservation на CPU ставим хотя бы на половину выделенного.

Установщик по умолчанию предлагает создать USR1CV8 и на этом успокаивается. Так делать можно, но тогда вы теряете контроль над тем, куда сервер ходит.

Мы заводим доменную сервисную учётку — например, svc_1cserver — и выдаём ей ровно четыре вещи:

1. Право «Вход в качестве службы» (Log on as a service) на самой машине.
2. Полный доступ к каталогу кластера — по умолчанию это C:\Program Files\1cv8\srvinfo, и мы почти всегда переносим его на диск данных.
3. Права на каталог временных файлов, если он вынесен отдельно.
4. Доступ к базе на стороне СУБД, если используется windows-аутентификация.

Пароль этой учётки ставим бессрочным и кладём в хранилище. Звучит банально. Но самая частая аварийная заявка «1С не запускается после перезагрузки» — это ротация пароля сервисной учётки политикой домена. Служба 1C:Enterprise 8.3 Server Agent молча не стартует, в журнале — 7000/7038, и весь офис стоит.

Проверить, под кем реально крутится агент, можно так:

Get-CimInstance Win32_Service -Filter "Name LIKE '%1C%'" |
  Select-Object Name, StartName, State, StartMode

Если в StartName видите LocalSystem — сервер работает с правами машины. Это не катастрофа, но доступ к сетевым шарам у него будет от имени компьютерной учётки, и выгрузки на файловый сервер начнут падать с «Отказано в доступе».

Порядок имеет значение. Если поставить сервер 1С раньше СУБД, вы получите рабочую конфигурацию, но потеряете возможность выбрать протокол подключения на этапе создания базы.

1. Обновляем ОС и ставим роли. Никаких «обновлю потом» — перезагрузка в середине настройки кластера ломает больше, чем экономит.
2. Ставим СУБД. MS SQL или PostgreSQL — решение принято на предыдущем шаге. Сразу задаём коллацию: для MS SQL под 1С это Cyrillic_General_CI_AS. Поменять потом = пересоздать инстанс.
3. Ставим сервер 1С. В мастере снимаем галку с ненужных компонентов: модули расширения веб-сервера ставим только если публикация действительно планируется.
4. Указываем сервисную учётку прямо в мастере, а не после.
5. Переносим каталог кластера на диск данных и правим параметр запуска службы.
6. Открываем порты и только потом создаём первую базу.

Каталог кластера переносится правкой ключа реестра службы — параметр -d в ImagePath:

sc.exe qc "1C:Enterprise 8.3 Server Agent"
# правим -d C:\Program Files\1cv8\srvinfo  ->  -d D:\1cv8\srvinfo
# службу останавливаем, каталог srvinfo копируем целиком, затем стартуем

Копировать надо именно целиком, вместе со скрытыми файлами: там лежат 1CV8Clst.lst и списки баз. Потеряете — потеряете и регистрацию информационных баз в кластере.

Кластер 1С использует три группы портов, и путаница в них даёт классический симптом «сервер виден, база не открывается».

Диапазон 1560–1591 открывают целиком, потому что рабочий процесс занимает свободный порт из диапазона при старте и после перезапуска он меняется. Прибивать конкретный порт правилом «1560 и хватит» — верный способ получить неработающую базу после ночного рестарта.

Правило для Windows Firewall одной строкой:

New-NetFirewallRule -DisplayName "1C Cluster" -Direction Inbound -Protocol TCP `
  -LocalPort 1540,1541,1560-1591 -Action Allow -Profile Domain

Обратите внимание на -Profile Domain. Открывать эти порты в публичный профиль не нужно ни при каких обстоятельствах. Сервер 1С не рассчитан на прямой выход в интернет: у него нет ни защиты от перебора, ни ограничения скорости подключений. Если удалённый доступ нужен — он идёт через терминальный сервер или веб-публикацию за обратным прокси, но не пробросом 1541 наружу.

Свежесозданный кластер работает на умолчаниях, и они рассчитаны на «средний сферический случай». Три из них мы правим всегда.

Интервал перезапуска рабочих процессов. Ставим 86400 секунд — сутки. Рабочий процесс 1С за день накапливает фрагментацию памяти и подтекает на тяжёлых отчётах. Ночной штатный перезапуск снимает проблему до того, как она станет заявкой. Вместе с ним задаём «допустимый объём памяти» и «интервал превышения» — тогда процесс, раздувшийся до порога, уйдёт на перезапуск сам, не дожидаясь суток.

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

Уровень отказоустойчивости. Ноль по умолчанию. Поднимать его на одиночном сервере смысла нет — он резервирует данные сеансов между серверами кластера, а сервер у нас один.

Что мы намеренно не трогаем на старте: «объём памяти рабочих процессов до вызова сервера лицензирования» и ручное распределение по требованиям назначения функциональности. Оба параметра решают конкретные задачи, и включать их «на всякий случай» — значит потом полдня искать, почему сеансы садятся не на тот процесс.

База создана, пользователи заведены, все довольны. Стоп. До боевого запуска мы прогоняем короткую приёмку — она занимает час и экономит недели.

1. Вход под тремя разными пользователями одновременно. Ловит забытые права на каталог кластера и упёршиеся лицензии.
2. Замер типовой операции. Открытие списка документов, проведение накладной, формирование ОСВ. Записываем время в секундах — это ваша точка отсчёта, без неё через полгода спор «раньше летало» будет неразрешим.
3. Ночной бэкап отработал и восстановился. Не «настроен», а именно восстановился на тестовый экземпляр. Бэкап, который ни разу не разворачивали, бэкапом не является.
4. Перезагрузка машины. Проверяем, что служба агента поднялась сама и база открылась без ручных действий.
5. Журнал регистрации и техжурнал пишутся туда, куда вы думаете. По умолчанию журнал регистрации складывается рядом с каталогом кластера и за полгода спокойно съедает десятки гигабайт.

Пятый пункт мы добавили после конкретного случая: у клиента-производственника диск C: заполнился журналом регистрации до нуля, сервер встал в субботу, а обнаружили это в понедельник утром. С тех пор журнал уезжает на диск данных, а на свободное место вешается мониторинг с порогом 15 %.

То, что мы отдаём клиенту вместе с сервером — и чем сами пользуемся при передаче на поддержку.

• Разрядность сервера x64, лицензия на него есть и активирована.
• Служба агента работает под доменной сервисной учёткой, пароль бессрочный и лежит в хранилище.
• Каталог srvinfo вынесен на диск данных, права на него у сервисной учётки полные.
• Порты 1540, 1541, 1560–1591 открыты только в доменном профиле; 1541 наружу не проброшен.
• Интервал перезапуска рабочих процессов — 86400 с, порог по памяти задан.
• Коллация СУБД — Cyrillic_General_CI_AS, файлы данных и журналов разнесены.
• Бэкап проверен восстановлением, а не только зелёной галкой в задании.
• Есть зафиксированные замеры трёх ключевых операций на пустой и на боевой базе.
• Журнал регистрации не на системном диске, мониторинг свободного места включён.
• Записана схема: кто владелец сервера, куда эскалировать, где лежат дистрибутивы и лицензии.

Последний пункт — не бюрократия. Через два года про сервер забудут все, кроме того, кто его настраивал, а он к тому моменту уже сменит работу.

Можно ли ставить сервер 1С и MS SQL на одну машину?

На офисе до 40–50 рабочих мест — да, и мы обычно так и делаем. Общение 1С и СУБД идёт через shared memory вместо сети, а это снимает целый класс плавающих задержек. Разносить стоит, когда база растёт за 200–300 ГБ либо когда СУБД обслуживает не только 1С.

Почему после перезагрузки сервера база перестала открываться?

В девяти случаях из десяти это сервисная учётная запись: политика домена сменила ей пароль, служба агента не стартовала. В системном журнале будут события 7000 или 7038. Второй по частоте вариант — правило фаервола, открывающее один порт вместо диапазона 1560–1591.

Обязательно ли выносить каталог srvinfo с диска C:?

Не обязательно, но настоятельно рекомендуется. Туда пишутся данные сеансов и журнал регистрации, объём растёт незаметно, и переполненный системный диск роняет весь сервер целиком, а не только 1С.

Что даёт перезапуск рабочих процессов раз в сутки?

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