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

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

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

Железо под аренду 1С: сколько ресурсов закладывать

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

Ориентировочные цифры для расчёта на одного пользователя средней нагрузки (бухгалтерия, торговля):

Пример. Вы планируете 40 пользователей на сервере 1С: 40 × 0,5 ГБ = 20 ГБ под сеансы, плюс 8 ГБ на операционную систему, СУБД и запас. Итого стоит брать сервер на 32 ГБ памяти и 8 ядер.

🔹 Разделяйте роли. Сервер приложений 1С и СУБД лучше держать на разных машинах, как только клиентов станет больше десятка. Это снимает конкуренцию за память.

🔹 Выбирайте СУБД заранее. Платформа работает с PostgreSQL, Microsoft SQL Server и другими поддерживаемыми СУБД. PostgreSQL не требует отдельной лицензии, SQL Server — требует.

🔹 Не экономьте на сети. Канал между сервером и клиентами должен выдерживать одновременную работу всех сеансов, а между сервером 1С и СУБД — быть быстрым и стабильным.

Лицензии и юридическая сторона сдачи в аренду

Это самый чувствительный раздел. Лицензия на 1С выдаётся для использования программы на вашем предприятии. Передавать доступ к программе третьим лицам по договору аренды можно не по любой лицензии.

Не сдавайте в аренду копии, купленные для собственного использования, без письменного подтверждения прав. Для сервисной работы существуют отдельные условия лицензирования, и их нужно уточнить напрямую у фирмы «1С» или у обслуживающего франчайзи до заключения договоров с клиентами.

Что проверить перед запуском:

1. Тип лицензии. Программная или аппаратная (ключ защиты), на сколько рабочих мест и для серверной ли она работы.
2. Условия вашего партнёрского статуса. Есть ли у вас право оказывать услуги по размещению программ у себя.
3. Лицензии на каждое рабочее место клиента. Одна лицензия на сервер не покрывает всех подключённых пользователей: клиентские лицензии считаются отдельно.
4. Лицензии на операционную систему и терминальный доступ. При работе через удалённый рабочий стол нужны клиентские лицензии на службы удалённых рабочих столов (RDS CAL) для каждого пользователя или устройства.
5. Лицензия на СУБД. Для SQL Server считается отдельно, для PostgreSQL платить не нужно.

Договор с клиентом должен отвечать на несколько вопросов:

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

Платформа, к слову, сама следит за использованием лицензий. Посмотреть, кто занимает лицензию, можно в консоли кластера или командой rac session list --licenses.

Как настроить кластер серверов 1С для нескольких клиентов

Кластер серверов 1С состоит из главного менеджера кластера, рабочих процессов и службы агента сервера. Установка серверной части на Windows или Linux идёт из того же дистрибутива платформы. Версию платформы на сервере выбирайте так, чтобы она была не ниже требуемой самой свежей конфигурацией клиентов.

Служба и порты

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

Создание кластера и баз

Порядок действий через консоль администрирования серверов 1С:

1. Подключитесь к центральному серверу, создайте или выберите кластер.
2. Добавьте администратора кластера — отдельную учётную запись, а не пользователя операционной системы с правами администратора.
3. Создайте информационную базу: укажите имя, тип СУБД, адрес сервера СУБД и имя базы. Включите создание базы в СУБД, если она ещё не создана.
4. Загрузите конфигурацию клиента или разверните базу из выгрузки .dt.

Изоляция клиентов друг от друга

Каждому арендатору — своя информационная база и свой пользователь СУБД. Не используйте одного администратора СУБД на все базы.

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

Удалённый доступ пользователей: как подключать арендаторов

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

Через удалённый рабочий стол

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

Через веб-публикацию

Публикуете базу на веб-сервере (IIS на Windows или Apache на Linux) через Администрирование → Публикация на веб-сервере в конфигураторе. Для интернета обязательно используйте HTTPS: сертификат ставят на веб-сервер, а не на сервер 1С.

🔸 Ограничьте доступ по IP, если у клиента статический адрес. 🔸 Включите двухфакторную защиту на уровне входа в терминальный сервер. 🔸 Не публикуйте консоль администрирования кластера наружу.

Регламентное обслуживание и резервное копирование

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

Минимальный регламент:

• 📅 Ежедневно. Выгрузка каждой базы и копия на отдельное хранилище.
• 📅 Еженедельно. Проверка, что копию действительно можно развернуть.
• 📅 Ежемесячно. Проверка свободного места, журналов СУБД, журнала регистрации и состояния кластера.
• 📅 После каждого обновления конфигурации. Свежая копия до обновления и контроль после.

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

Как делать копии

Есть два уровня. Первый — выгрузка информационной базы в .dt средствами платформы. Второй — копия средствами СУБД (для PostgreSQL это pg_dump, для SQL Server — собственная резервная копия). Для серьёзных клиентов делают оба: копия СУБД восстанавливается быстрее на большом объёме, а .dt пригодится для переноса и независима от СУБД.

Пример скрипта выгрузки баз по расписанию

Ниже пример .bat для Windows, который выгружает одну базу в файл с датой в имени. Замените имена сервера, базы, пользователя и пути на свои. Пароль в самом файле хранить небезопасно: ограничьте права на файл и по возможности используйте отдельного пользователя с минимальными правами.

@echo off
set SERVER=srv-1c
set BASE=client_01
set USER=backup_user
set PASS=ChangeMe
set DEST=D:\backup\%BASE%
set STAMP=%date:~6,4%-%date:~3,2%-%date:~0,2%

if not exist "%DEST%" mkdir "%DEST%"

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" DESIGNER /S "%SERVER%\%BASE%" /N "%USER%" /P "%PASS%" /DumpIB "%DEST%\%BASE%_%STAMP%.dt" /Out "%DEST%\log_%STAMP%.txt"

forfiles /p "%DEST%" /m *.dt /d -14 /c "cmd /c del @path"

Что делает скрипт: подключается к базе в режиме конфигуратора без интерфейса, выгружает её в .dt, пишет журнал и удаляет копии старше 14 дней. Номер версии платформы в пути замените на установленный.

Запускайте скрипт через планировщик заданий Windows от отдельной служебной учётной записи. Если баз много, сделайте цикл по списку или отдельный файл на каждую.

Для PostgreSQL получится проще и быстрее:

pg_dump -U postgres -F c -f /backup/client_01_$(date +%F).dump client_01

Параметр -F c создаёт сжатый архив, который восстанавливается командой pg_restore.

Типичные проблемы при аренде 1С и как их устранить

Большинство жалоб от арендаторов сводится к нескольким причинам.

«Всё тормозит»

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

Для диагностики откройте в консоли кластера список сеансов и найдите долгие вызовы. Там видно, какой пользователь и какая база занимают рабочий процесс.

Базы «зависают» после работы

Часто это сеансы, которые остались после обрыва связи. Завершить их можно в консоли администрирования. Перед этим убедитесь, что это действительно мёртвые подключения.

Сервер упёрся в количество лицензий

Проверьте список сеансов с лицензиями и закройте «зависшие». Если лицензий действительно не хватает, это вопрос не настройки, а закупки.

Рост размера базы

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

Конфликт обновлений

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

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