Как устроен ibsrv и когда он заменяет кластер серверов 1С

Автономный сервер 1С — это один процесс ibsrv, который обслуживает одну информационную базу без кластера, агента и консоли администрирования. Он появился в платформе 1С:Предприятие 8.3.14 и входит в состав сервера 1С. Данные база может хранить как в файле, так и в SQL-СУБД: автономный сервер не заменяет SQL, он заменяет связку «агент кластера + менеджер + рабочие процессы».

Отсюда главный ответ на вопрос «чем он отличается от SQL». SQL Server или PostgreSQL — это СУБД, где лежат таблицы. Автономный сервер — прослойка 1С, которая исполняет код конфигурации и раздаёт базу клиентам по HTTP. Сравнивать корректно автономный сервер с классическим кластером, а не с СУБД.

Как устроен автономный сервер 1С изнутри

В классическом клиент-серверном варианте работает несколько процессов:

• 🔹 ragent — агент сервера, принимает подключения (порт 1540);
• 🔹 rmngr — менеджер кластера (порт 1541), хранит реестр баз и сеансов;
• 🔹 rphost — рабочие процессы, исполняют код конфигурации;
• 🔹 консоль администрирования или ras + rac — для управления.

У автономного сервера всё это собрано в одном исполняемом файле ibsrv. Он:

• 🔸 обслуживает ровно одну информационную базу;
• 🔸 сам принимает HTTP-подключения — отдельный веб-сервер (IIS или Apache) не нужен;
• 🔸 не регистрирует базу в кластере: параметры подключения к данным задаются в командной строке или в конфигурационном файле;
• 🔸 работает с файловой базой или с базой в СУБД (MS SQL Server, PostgreSQL и другие, которые поддерживает платформа).

Клиенты подключаются к нему по адресу вида http://server:8314/. Тонкий клиент и веб-клиент работают так же, как с опубликованной на веб-сервере базой. Порт 8314 используется по умолчанию, его можно сменить параметром запуска.

Рядом с ibsrv в поставке лежит утилита ibcmd. Она умеет создавать базы, выгружать и загружать данные, работать с конфигурацией из командной строки — без Конфигуратора и без запущенного сервера. Для администрирования автономного сервера это основной инструмент.

Автономный сервер и кластер с SQL: сравнение по пунктам

Путаница «автономный сервер или SQL» возникает потому, что многие помнят старую дилемму «файловая база или клиент-серверная». Автономный сервер — третий вариант между ними.

Главные практические отличия:

1. Нет менеджера кластера. Нельзя посмотреть сеансы и блокировки в консоли, нельзя завершить сеанс оттуда, нет настроек отказоустойчивости.
2. Одна база — один процесс. Пять баз — пять экземпляров ibsrv на разных портах, каждый со своим конфигурационным файлом.
3. Только HTTP. Толстый клиент по протоколу 1С к автономному серверу не подключается так, как к кластеру. Пользователи работают в тонком или веб-клиенте.
4. СУБД остаётся той же. Если база лежит в PostgreSQL, то и с автономным сервером она будет лежать там же. Бэкапы средствами СУБД работают как раньше.

Когда автономный сервер подходит, а когда нет

Где он удобен

• ✅ Разработка и тестирование. Поднять копию базы для отладки за минуту, не трогая рабочий кластер. 1С:EDT использует автономный сервер для запуска баз в проекте.
• ✅ Небольшая организация с веб-доступом. Одна база, 5–15 пользователей, работа через браузер или тонкий клиент по интернету — без IIS и Apache.
• ✅ Контейнеры и автоматизация. Один процесс с одним конфигом легко упаковать в Docker и запускать из скриптов CI.
• ✅ Перевод файловой базы на веб-доступ. Файловая база остаётся файловой, но серверный код исполняется на сервере, а клиенты подключаются по HTTP.

Где лучше оставить кластер

• ❌ Много баз на одном сервере, которыми управляет администратор через консоль.
• ❌ Десятки и сотни пользователей, нужна балансировка между рабочими серверами.
• ❌ Нужен толстый клиент: старые обработки, обычные формы.
• ❌ Регламент требует контроля сеансов и лицензий через консоль или rac.

Требования к железу для автономного сервера

Официальных отдельных требований под ibsrv нет: он исполняет тот же серверный код, что и рабочий процесс кластера. Ориентиры по опыту для одной типовой базы (Бухгалтерия, ЗУП):

Это примерные цифры, а не норматив. Реальная потребность зависит от конфигурации и объёма данных.

Что учесть:

• 💾 Файловая база + ibsrv. Узкое место — диск. Файл 1Cv8.1CD держите на локальном SSD сервера, не на сетевой папке.
• 🧠 СУБД на той же машине. Память делится между ibsrv и СУБД. Для PostgreSQL или MS SQL оставьте примерно половину ОЗУ и ограничьте её в настройках СУБД.
• 🌐 Сеть. Клиенты ходят по HTTP. Для доступа из интернета ставьте перед ibsrv обратный прокси с HTTPS (например, nginx) и не публикуйте порт 8314 напрямую.
• 🔑 Лицензии. Автономный сервер — часть серверной платформы. Клиентские лицензии нужны так же, как при обычной работе; какие именно серверные лицензии покрывают ваш случай, уточните у партнёра 1С по условиям вашего договора.

Как запустить автономный сервер и подключить к нему базу

Кластера здесь нет, поэтому «регистрации базы в кластере» тоже нет. Подключение к данным описывается параметрами запуска ibsrv или файлом конфигурации. Ниже — порядок для Windows, на Linux команды те же, отличаются пути.

Шаг 1. Найдите исполняемые файлы

Они лежат в каталоге платформы, например C:\Program Files\1cv8\8.3.24.1548\bin\. Номер версии — ваш, платформа должна быть не ниже 8.3.14. Проверьте, что там есть ibsrv.exe и ibcmd.exe. Если их нет — при установке не выбран компонент сервера.

Шаг 2. Подготовьте каталог данных

Автономному серверу нужен свой рабочий каталог для служебных файлов: кэш, журналы, временные данные. Создайте его заранее, например D:\ibsrv\buh\. Для каждой базы — отдельный каталог.

Шаг 3. Запустите сервер для файловой базы

cd "C:\Program Files\1cv8\8.3.24.1548\bin"
ibsrv.exe --data=D:\ibsrv\buh --name=buh --db-path=D:\Bases\Buh --http-port=8314

Для базы в PostgreSQL вместо --db-path указываются параметры СУБД:

ibsrv.exe --data=D:\ibsrv\buh --name=buh --dbms=PostgreSQL --db-server=localhost --db-name=buh --db-user=postgres --db-pwd=*** --http-port=8314

Точный список параметров для вашей версии выводит ibsrv.exe --help — сверьтесь с ним, набор опций расширялся от релиза к релизу.

Шаг 4. Вынесите настройки в файл

Длинную командную строку неудобно поддерживать. Утилита ibcmd умеет сформировать конфигурационный файл из тех же параметров:

ibcmd.exe server config init --db-path=D:\Bases\Buh --name=buh > D:\ibsrv\buh\config.yml
ibsrv.exe --config=D:\ibsrv\buh\config.yml --data=D:\ibsrv\buh

Файл в формате YAML можно поправить вручную: сменить порт, путь к базе, параметры СУБД.

Шаг 5. Подключите клиентов

В окне запуска 1С нажмите Добавить → Добавление в список существующей информационной базы. Тип расположения — на веб-сервере, адрес — http://имя-сервера:8314/. Веб-клиент открывается по тому же адресу в браузере.

Шаг 6. Сделайте из процесса службу

Пока ibsrv запущен в окне консоли, закрытие окна останавливает базу. Для постоянной работы оформите его службой:

• 🪟 Windows — через sc create с полной командой запуска в параметре binPath= или через обёртку вроде NSSM;
• 🐧 Linux — unit-файл systemd с ExecStart=/opt/1cv8/x86_64/8.3.24.1548/ibsrv --config=/srv/ibsrv/buh/config.yml --data=/srv/ibsrv/buh и Restart=on-failure.

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

Обслуживание и мониторинг производительности

Консоли кластера нет, поэтому привычные инструменты администратора недоступны. Чем их заменить:

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

• 🗂 Файловая база. Копировать 1Cv8.1CD «на ходу» нельзя — копия может оказаться битой. Либо останавливайте ibsrv на время копирования, либо делайте выгрузку через ibcmd infobase dump.
• 🐘 База в СУБД. Бэкап средствами СУБД (pg_dump, план обслуживания MS SQL) работает без остановки сервера, как и при кластере.

Что смотреть при тормозах

1. Загрузка процессора процессом ibsrv. Постоянные 100 % одного ядра — тяжёлый серверный код или регламентное задание.
2. Память процесса. Рост без остановки до перезапуска — повод собрать технологический журнал и проверить фоновые задания.
3. Диск. Для файловой базы смотрите очередь диска: на HDD автономный сервер упрётся в него быстрее, чем в процессор.
4. Регламентные задания. Они выполняются внутри того же процесса. Тяжёлые задания (обмены, загрузка классификаторов) переносите на ночь.

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

Новая версия платформы ставится в отдельный каталог. Автономный сервер нужно перезапустить уже из нового каталога: поправьте путь в службе или unit-файле. Клиенты должны быть той же версии — иначе тонкий клиент предложит обновиться или откажется подключаться.

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