С:Предприятие 8.3.27.1936 + PostgreSQL Pro 1C

[George]

Полное бескомпромиссное руководство: Развёртывание 1С:Предприятие 8.3.27.1936 и сборка отказоустойчивого CLI-кластера на Ubuntu 24.04 LTS с СУБД PostgreSQL 15

Инструкция детально описывает процедуру «чистого» развёртывания инфраструктуры 1С с нуля. Включает в себя подготовку независимого физического диска для баз данных, корректную ручную конфигурацию локалей без оставления мусора в системе, ручное добавление актуального репозитория СУБД Postgres Pro 1C в обход ограничений Ubuntu 24.04 LTS (Noble Numbat), правильную процедуру регистрации юнитов systemd через механизм символических ссылок (link), а также полную логику объединения нод в отказоустойчивый кластер и управление базами через утилиту `rac`.

Параметры нашей тестовой схемы (адаптируйте под свою сеть):

• Нода 1 (Основной хост): 1c-node1.cloud-life.site (IP: 10.10.1.84)
  
• Нода 2 (Дополнительный хост): 1c-node2.cloud-life.site (IP: 10.10.1.85)
  
• Платформа 1С: 8.3.27.1936 (абсолютный путь установки: `/opt/1cv8/x86_64/8.3.27.1936/`)
  
• Порты служб: ragent — 1540, Главный менеджер кластера (Main Manager) — 1541, RAS — 1545, диапазон рабочих процессов — 1560:1591
  

Часть 1. Подготовка ОС, разметка накопителей и СУБД (Выполняется параллельно на Node1 и Node2)

1.1. Настройка сетевой идентификации серверов и локализации
Для работы распределенного кластера хосты обязаны мгновенно определять друг друга по доменным именам. Присваиваем имена хостам на каждом сервере отдельно.

На сервере node1 выполняем:

Код: bash

sudo hostnamectl set-hostname 1c-node1

На сервере node2 выполняем:

Код: bash

sudo hostnamectl set-hostname 1c-node2

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

Код: bash

sudo nano /etc/hosts

Вносим в файл следующие строки, жестко привязывая IP к именам (замените примеры на ваши реальные IP-адреса):

Код: text

10.10.1.84  1c-node1.cloud-life.site  1c-node1
10.10.1.85  1c-node2.cloud-life.site  1c-node2

Сохраняем изменения (`Ctrl + O`, затем `Enter`, выход `Ctrl + X`).

1С критично относится к системной локали для выполнения сортировок таблиц и обработки дат. Генерируем корректную локаль `ru_RU.UTF-8` и задаем её в качестве глобальной переменной окружения:

Код: bash

sudo apt update && sudo apt upgrade -y
sudo apt install -y locales
sudo locale-gen ru_RU.UTF-8
sudo update-locale LANG=ru_RU.UTF-8

Обязательно отправляем сервера в перезагрузку для полной переинициализации окружения: `sudo reboot`

1.2. Выделение и монтирование физического диска под СУБД
Вынесение баз данных на отдельный быстрый накопитель (SSD/NVMe) изолирует файлы данных от системного раздела, повышая скорость операций ввода-вывода (IOPS).

Находим имя нового подключенного диска (например, это будет `/dev/sdb`):

Код: bash

lsblk

Форматируем диск в отказоустойчивую файловую систему `ext4` и подготавливаем директорию монтирования, принятую в Postgres Pro:

Код: bash

sudo mkfs.ext4 -F /dev/sdb
sudo mkdir -p /var/lib/pgpro

Чтобы при изменении конфигурации оборудования или портов диски не перепутались местами, монтируем накопитель строго по его постоянному UUID. Узнаем идентификатор:

Код: bash

sudo blkid /dev/sdb

Копируем длинную строчку вида `UUID="xxxx-xxxx-xxxx"` (без кавычек).

Открываем конфигурационный файл монтирования файловых систем:

Код: bash

sudo nano /etc/fstab

Добавляем в самый конец файла следующую запись (опция `noatime` отключает постоянное обновление времени последнего чтения файлов СУБД, заметно снижая нагрузку на контроллер диска):

Код: text

UUID=ВАШ_СКОПИРОВАННЫЙ_UUID_ИЗ_КОМАНДЫ_BLKID /var/lib/pgpro ext4 defaults,noatime 0 2

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

Код: bash

sudo mount -a
sudo groupadd -r postgres || true
sudo useradd -r -g postgres -s /bin/bash -c "PostgreSQL Administrator" -m -d /var/lib/pgpro postgres || true
sudo chown -R postgres:postgres /var/lib/pgpro
sudo chmod 700 /var/lib/pgpro

1.3. Добавление официального репозитория СУБД Postgres Pro 15 (1C Edition) и установка пакетов
В Ubuntu 24.04 традиционный метод добавления ключей авторизации через `apt-key` является устаревшим и заблокирован из соображений безопасности. Используем новый стандарт хранения ключей в каталоге `keyrings` и подключаем репозиторий с явным указанием пути шифрования.

Создаем директорию под доверенные ключи, скачиваем публичный PGP-ключ шифрования с официального сервера репозиториев Postgres Pro, преобразуем его в бинарный формат и сохраняем:

Код: bash

sudo mkdir -p /etc/apt/keyrings
wget --quiet -O - https://postgrespro.ru | sudo gpg --dearmor --yes -o /etc/apt/keyrings/postgrespro-1c.gpg

Генерируем конфигурационный файл списка источников пакетов `postgrespro-1c.list`. Обратите внимание на обязательное явное указание ветки `/pg1c-15/ubuntu` и кодового имени дистрибутива `noble`:

Код: bash

echo "deb [signed-by=/etc/apt/keyrings/postgrespro-1c.gpg] http://postgrespro.ru noble main" | sudo tee /etc/apt/sources.list.d/postgrespro-1c.list

Обновляем индексы пакетов операционной системы и производим установку серверной части СУБД:

Код: bash

sudo apt update
sudo apt install -y postgrespro-1c-15-server

Инсталлятор автоматически обнаружит примонтированный в `/var/lib/pgpro` пустой раздел и развернет на нем структуру каталогов базы данных (`/var/lib/pgpro/15/data/`). Запускаем службу, добавляем её в сценарии автозагрузки ОС и сразу переходим в консоль базы для смены мастер-пароля администратора:

Код: bash

sudo systemctl enable postgrespro-1c-15
sudo systemctl start postgrespro-1c-15
sudo -u postgres psql

Внутри открывшегося интерактивного терминала СУБД (приглашение ввода `postgres=#`) выполняем следующий SQL-запрос, устанавливающий постоянный пароль суперпользователя:

Код: sql

ALTER USER postgres WITH PASSWORD 'ВашНадежныйПарольСУБД';
\q

1.4. Конфигурация сети СУБД для взаимодействия внутри кластера 1С
По умолчанию СУБД принимает сетевые пакеты только с локального адреса обратной петли (`127.0.0.1`). Открываем сетевой доступ для связи серверов между собой.

Открываем конфигурационный файл параметров Postgres Pro:

Код: bash

sudo nano /var/lib/pgpro/15/data/postgresql.conf

Находим директиву `listen_addresses` (используйте поиск `Ctrl + W`), раскомментируем её (убрав знак `#` в начале строки) и указываем значение `*`, что заставит СУБД слушать все доступные сетевые интерфейсы сервера:

Код: text

listen_addresses = '*'

Сохраняем файл и выходим.

Теперь открываем файл разграничения прав доступа к СУБД по хостам:

Код: bash

sudo nano /var/lib/pgpro/15/data/pg_hba.conf

Прокручиваем файл в самый низ к правилам IPv4 локальных подключений и добавляем строчку авторизации для вашей внутренней подсети, в которой разворачиваются ноды (например, подсеть `10.10.1.0/24`), разрешая авторизацию с парольной проверкой по протоколу MD5:

Код: text

host    all             all             10.10.1.0/24            md5

Сохраняем файл, выходим и перезапускаем службу для применения сетевых параметров:

Код: bash

sudo systemctl restart postgrespro-1c-15

1.5. Установка платформы 1С:Предприятие 8.3.27.1936 и регистрация служб (systemctl link)
Для корректного построения печатных форм серверу 1С требуются шрифты TrueType от Microsoft и библиотеки рендеринга. Устанавливаем необходимые зависимости:

Код: bash

sudo apt install -y ttf-mscorefonts-installer libfontconfig1 libglib2.0-0 libxml2

Создаем временную директорию, распаковываем туда ранее загруженный дистрибутив сервера и запускаем установку всех `.deb` компонентов одной командой:

Код: bash

mkdir ~/1c_distr && tar -xzf server64_8_3_27_1936.tar.gz -C ~/1c_distr
cd ~/1c_distr
sudo apt install ./*.deb

Внимание! Так как файлы юнитов systemd в актуальных версиях платформы 1С поставляются изолированно внутри каталога `/opt/1cv8/x86_64/8.3.27.1936/`, подсистема инициализации Linux (`systemd`) о них ничего не знает. Нам необходимо принудительно зарегистрировать службы кластера сервера (`srv1cv8`) и сервера удаленного администрирования (`ras`), связав их символическими ссылками с системным диспетчером.

Создаем ссылки (link) на файлы служб с указанием точного абсолютного пути версии:

Код: bash

sudo systemctl link /opt/1cv8/x86_64/8.3.27.1936/srv1cv8-8.3.27.1936@.service
sudo systemctl link /opt/1cv8/x86_64/8.3.27.1936/ras-8.3.27.1936.service

Перезагружаем конфигурацию диспетчера systemd, добавляем созданные экземпляры служб в автозагрузку ОС (экземпляр сервера инициализируем с суффиксом по умолчанию — `default`) и производим их запуск:

Код: bash

sudo systemctl daemon-reload
sudo systemctl enable srv1cv8-8.3.27.1936@default.service
sudo systemctl enable ras-8.3.27.1936.service
sudo systemctl start srv1cv8-8.3.27.1936@default.service
sudo systemctl start ras-8.3.27.1936.service

Убеждаемся, что службы успешно запущены и слушают порты администрирования:

Код: bash

sudo systemctl status srv1cv8-8.3.27.1936@default.service
sudo systemctl status ras-8.3.27.1936.service

Часть 2. Пошаговая сборка отказоустойчивого кластера 1С через интерфейс CLI (rac)

2.1. Глубокая очистка автоматического локального мусора (Выполняется на Node1 и Node2)
При самом первом старте процесса ragent служба автоматически генерирует в домашнем каталоге пользователя usr1cv8 конфигурацию изолированного "Локального кластера". При попытке объединить ноды этот дефолтный каталог (reg_0) вызовет критический конфликт адресов: «На сервере существует каталог реестра кластера... Возможно, сервер уже является центральным для другого кластера». Мы полностью очистим этот мусор.

Останавливаем сервер 1С, очищаем содержимое рабочих директорий реестров, пересоздаем чистый каталог, возвращаем на него права владельца службы и запускаем сервер обратно:

Код: bash

sudo systemctl stop srv1cv8-8.3.27.1936@default.service
sudo rm -rf /home/usr1cv8/.1cv8/1C/1cv8/*
sudo mkdir -p /home/usr1cv8/.1cv8/1C/1cv8
sudo chown -R usr1cv8:grp1cv8 /home/usr1cv8/.1cv8
sudo systemctl start srv1cv8-8.3.27.1936@default.service

2.2. Удаление авто-сгенерированных кластеров через утилиту командной строки rac

Выводим списки автоматически созданных кластеров на node1 и node2 отдельно:

Код: bash

/opt/1cv8/x86_64/8.3.27.1936/rac cluster list 127.0.0.1:1545

Копируем из консоли параметр cluster : UUID (длинный уникальный идентификатор).

Принудительно удаляем локальные кластеры на обеих нодах:

Код: bash

/opt/1cv8/x86_64/8.3.27.1936/rac cluster remove 127.0.0.1:1545 --cluster=UUID_ВАШЕГО_ЛОКАЛЬНОГО_КЛАСТЕРА

Убеждаемся, что удаление прошло успешно — повторный вызов команды /opt/1cv8/x86_64/8.3.27.1936/rac cluster list 127.0.0.1:1545 обязан вернуть пустой вывод на обоих серверах.

2.3. Создание единого центрального кластера

Все последующие команды выполняются исключительно на управляющей ноде — node1.

Инициализируем создание нашего нового единого Production-кластера 1С:

Код: bash

/opt/1cv8/x86_64/8.3.27.1936/rac cluster insert 127.0.0.1:1545 --host=1c-node1.cloud-life.site --port=1541 --name="1c.cloud-life.site"

Команда вернет созданный cluster : UUID (например, 7e6188fb-535a-4bcc-b5c5-f85cf8ca75ec). Сохраняем его, во всех последующих командах он будет фигурировать как параметр [CLUSTER_UUID].

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

Код: bash

/opt/1cv8/x86_64/8.3.27.1936/rac cluster list 127.0.0.1:1545

В выводе отобразится, что данный хост (1c-node1.cloud-life.site) автоматически зарегистрирован в системе как первый управляющий сервер со статусом using : main и рабочим портом менеджера cluster-port : 1541.

2.4. Присоединение node2 в качестве рабочего сервера кластера

КРИТИЧЕСКИ ВАЖНО: При добавлении хоста через интерфейс командной строки CLI мы обязаны явно передать аргумент

Код: bash

--cluster-port=1541

. Если его не указать, 1С присвоит порту менеджера значение 0. В дальнейшем, при попытке повысить роль этого сервера, подсистема синхронизации реестров упадет с фатальной ошибкой ClusterConfigService не найден, так как ноды не будут знать, по какому сетевому порту осуществлять обмен файлами 1cv8clst.lst.[/i]

Регистрируем вторую ноду внутри созданного кластера в начальном обычном статусе (normal):

Код: bash

/opt/1cv8/x86_64/8.3.27.1936/rac server insert 127.0.0.1:1545 --cluster=[CLUSTER_UUID] --agent-host=1c-node2.cloud-life.site --agent-port=1540 --port-range=1560:1591 --name="Центральный сервер 2" --using=normal --cluster-port=1541

2.5. Перевод node2 в полноценный режим отказоустойчивого Main Server

Запрашиваем актуальный список серверов внутри нашего кластера:

Код: bash

/opt/1cv8/x86_64/8.3.27.1936/rac server list 127.0.0.1:1545 --cluster=[CLUSTER_UUID]

В появившемся списке находим блок, соответствующий agent-host : 1c-node2.cloud-life.site, и копируем значение строки server : UUID (это внутренний уникальный идентификатор зарегистрированного сервера, далее обозначаемый как [NODE2_SERVER_UUID]).

Повышаем роль второй ноды до статуса центрального Main сервера кластера:

Код: bash

/opt/1cv8/x86_64/8.3.27.1936/rac server update 127.0.0.1:1545 --cluster=[CLUSTER_UUID] --server=[NODE2_SERVER_UUID] --using=main

2.6. Комплексная проверка состояния репликации кластера

Проверяем итоговый список серверов:

Код: bash

/opt/1cv8/x86_64/8.3.27.1936/rac server list 127.0.0.1:1545 --cluster=[CLUSTER_UUID]

Обе ноды в консоли обязаны отображать статус using : main и порт cluster-port : 1541.

Запрашиваем список запущенных менеджеров кластера. В системе должно функционировать минимум два главных менеджера:

Код: bash

/opt/1cv8/x86_64/8.3.27.1936/rac manager list 127.0.0.1:1545 --cluster=[CLUSTER_UUID]

Запрашиваем список кластерных служб для проверки активации механизмов репликации:

Код: bash

/opt/1cv8/x86_64/8.3.27.1936/rac service list 127.0.0.1:1545 --cluster=[CLUSTER_UUID]

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

2.7. Проверка доступности кластера с резервного хоста

Переходим в консоль сервера node2 и запрашиваем список локальных кластеров:

Код: bash

/opt/1cv8/x86_64/8.3.27.1936/rac cluster list 127.0.0.1:1545

В выводе команды на node2 должен корректно отобразиться наш единый кластер 1c.cloud-life.site. Это подтверждает, что реестры синхронизированы, а обе ноды работают в единой связке.

При настройке списков баз данных на клиентских рабочих местах пользователей (в окне запуска 1С) строку подключения к кластеру необходимо указывать перечислением через точку с запятой: 1c-node1.cloud-life.site:1541;1c-node2.cloud-life.site:1541.


Часть 3. CLI-управление информационными базами данных (rac)

3.1. Создание абсолютно новой информационной базы с её физической инициализацией в СУБД

Если база еще не создана внутри PostgreSQL, мы можем скомандовать кластеру 1С автоматически создать пустую схему таблиц в СУБД с помощью флага --create-database:

Код: bash

/opt/1cv8/x86_64/8.3.27.1936/rac infobase insert 127.0.0.1:1545 --cluster=[CLUSTER_UUID] --name="Production_Base" --desc="Основная рабочая база данных" --dbms="PostgreSQL" --db-server="10.10.1.84" --db-name="prod_db_1c" --db-user="postgres" --db-pwd="ВашПарольСуперпользователяСУБД" --license-distribution=allow --create-database

3.2. Регистрация в кластере 1С информационной базы, которая уже физически существует в PostgreSQL

Если вы перенесли базу или развернули бэкап стандартными средствами СУБД, для её публикации в кластере 1С используется аналогичная команда, но СТРОГО БЕЗ флага --create-database:

Код: bash

/opt/1cv8/x86_64/8.3.27.1936/rac infobase insert 127.0.0.1:1545 --cluster=[CLUSTER_UUID] --name="Existing_Base" --desc="Подключение существующей базы" --dbms="PostgreSQL" --db-server="10.10.1.84" --db-name="existing_db_name" --db-user="postgres" --db-pwd="ВашПарольСуперпользователяСУБД" --license-distribution=allow

3.3. Получение полного списка зарегистрированных информационных баз

Команда выведет все базы, подключенные к кластеру, и их уникальные UUID, необходимые для администрирования:

Код: bash

/opt/1cv8/x86_64/8.3.27.1936/rac infobase list 127.0.0.1:1545 --cluster=[CLUSTER_UUID]

3.4. Полное удаление информационной базы из кластера 1С

Сначала находим нужный infobase : UUID базы с помощью команды infobase list, после чего производим её удаление.

Вариант А: Отключение базы из списка 1С с ФИЗИЧЕСКИМ СТИРАНИЕМ таблиц из СУБД:

Код: bash

/opt/1cv8/x86_64/8.3.27.1936/rac infobase drop 127.0.0.1:1545 --cluster=[CLUSTER_UUID] --infobase=UUID_ВАШЕЙ_ИНФОБАЗЫ --clear-database

Вариант Б: Отключение базы из списка 1С с СОХРАНЕНИЕМ всех данных внутри PostgreSQL:

Код: bash

/opt/1cv8/x86_64/8.3.27.1936/rac infobase drop 127.0.0.1:1545 --cluster=[CLUSTER_UUID] --infobase=UUID_ВАШЕЙ_ИНФОБАЗЫ