Моя шпаргалка :)

Полное бескомпромиссное руководство: Развёртывание 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 выполняем:
sudo hostnamectl set-hostname 1c-node1
На сервере node2 выполняем:
sudo hostnamectl set-hostname 1c-node2
Далее на обоих серверах открываем текстовый редактор для настройки локального сопоставления адресов:
sudo nano /etc/hosts
Вносим в файл следующие строки, жестко привязывая IP к именам (замените примеры на ваши реальные IP-адреса):
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` и задаем её в качестве глобальной переменной окружения:
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`):
lsblk
Форматируем диск в отказоустойчивую файловую систему `ext4` и подготавливаем директорию монтирования, принятую в Postgres Pro:
sudo mkfs.ext4 -F /dev/sdb
sudo mkdir -p /var/lib/pgpro
Чтобы при изменении конфигурации оборудования или портов диски не перепутались местами, монтируем накопитель строго по его постоянному UUID. Узнаем идентификатор:
sudo blkid /dev/sdbКопируем длинную строчку вида `UUID="xxxx-xxxx-xxxx"` (без кавычек).

Открываем конфигурационный файл монтирования файловых систем:
sudo nano /etc/fstabДобавляем в самый конец файла следующую запись (опция `noatime` отключает постоянное обновление времени последнего чтения файлов СУБД, заметно снижая нагрузку на контроллер диска):
UUID=ВАШ_СКОПИРОВАННЫЙ_UUID_ИЗ_КОМАНДЫ_BLKID /var/lib/pgpro ext4 defaults,noatime 0 2
Выполняем принудительное монтирование всех объявленных дисков, создаем системную группу и учетную запись администратора СУБД с назначением домашних директорий на новом накопителе, после чего выставляем безопасные права доступа:
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, преобразуем его в бинарный формат и сохраняем:
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`:
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
Обновляем индексы пакетов операционной системы и производим установку серверной части СУБД:
sudo apt update
sudo apt install -y postgrespro-1c-15-server
Инсталлятор автоматически обнаружит примонтированный в `/var/lib/pgpro` пустой раздел и развернет на нем структуру каталогов базы данных (`/var/lib/pgpro/15/data/`). Запускаем службу, добавляем её в сценарии автозагрузки ОС и сразу переходим в консоль базы для смены мастер-пароля администратора:
sudo systemctl enable postgrespro-1c-15
sudo systemctl start postgrespro-1c-15
sudo -u postgres psql
Внутри открывшегося интерактивного терминала СУБД (приглашение ввода `postgres=#`) выполняем следующий SQL-запрос, устанавливающий постоянный пароль суперпользователя:
ALTER USER postgres WITH PASSWORD 'ВашНадежныйПарольСУБД';
\q
1.4. Конфигурация сети СУБД для взаимодействия внутри кластера 1С
По умолчанию СУБД принимает сетевые пакеты только с локального адреса обратной петли (`127.0.0.1`). Открываем сетевой доступ для связи серверов между собой.

Открываем конфигурационный файл параметров Postgres Pro:
sudo nano /var/lib/pgpro/15/data/postgresql.conf
Находим директиву `listen_addresses` (используйте поиск `Ctrl + W`), раскомментируем её (убрав знак `#` в начале строки) и указываем значение `*`, что заставит СУБД слушать все доступные сетевые интерфейсы сервера:
listen_addresses = '*'Сохраняем файл и выходим.

Теперь открываем файл разграничения прав доступа к СУБД по хостам:
sudo nano /var/lib/pgpro/15/data/pg_hba.confПрокручиваем файл в самый низ к правилам IPv4 локальных подключений и добавляем строчку авторизации для вашей внутренней подсети, в которой разворачиваются ноды (например, подсеть `10.10.1.0/24`), разрешая авторизацию с парольной проверкой по протоколу MD5:
host    all             all             10.10.1.0/24            md5Сохраняем файл, выходим и перезапускаем службу для применения сетевых параметров:
sudo systemctl restart postgrespro-1c-15
1.5. Установка платформы 1С:Предприятие 8.3.27.1936 и регистрация служб (systemctl link)
Для корректного построения печатных форм серверу 1С требуются шрифты TrueType от Microsoft и библиотеки рендеринга. Устанавливаем необходимые зависимости:
sudo apt install -y ttf-mscorefonts-installer libfontconfig1 libglib2.0-0 libxml2
Создаем временную директорию, распаковываем туда ранее загруженный дистрибутив сервера и запускаем установку всех `.deb` компонентов одной командой:
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) на файлы служб с указанием точного абсолютного пути версии:
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`) и производим их запуск:
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
Убеждаемся, что службы успешно запущены и слушают порты администрирования:
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С, очищаем содержимое рабочих директорий реестров, пересоздаем чистый каталог, возвращаем на него права владельца службы и запускаем сервер обратно:

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 отдельно:

/opt/1cv8/x86_64/8.3.27.1936/rac cluster list 127.0.0.1:1545
Копируем из консоли параметр cluster : UUID (длинный уникальный идентификатор).

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

/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С:

/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].

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

/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 мы обязаны явно передать аргумент --cluster-port=1541. Если его не указать, 1С присвоит порту менеджера значение 0. В дальнейшем, при попытке повысить роль этого сервера, подсистема синхронизации реестров упадет с фатальной ошибкой ClusterConfigService не найден, так как ноды не будут знать, по какому сетевому порту осуществлять обмен файлами 1cv8clst.lst.[/i]

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

/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

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

/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 сервера кластера:

/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. Комплексная проверка состояния репликации кластера

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

/opt/1cv8/x86_64/8.3.27.1936/rac server list 127.0.0.1:1545 --cluster=[CLUSTER_UUID]
Обе ноды в консоли обязаны отображать статус using : main и порт cluster-port : 1541.

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

/opt/1cv8/x86_64/8.3.27.1936/rac manager list 127.0.0.1:1545 --cluster=[CLUSTER_UUID]
Запрашиваем список кластерных служб для проверки активации механизмов репликации:

/opt/1cv8/x86_64/8.3.27.1936/rac service list 127.0.0.1:1545 --cluster=[CLUSTER_UUID]
Критические сервисы управления конфигурацией ClusterConfigService и ClusterStateService автоматически активируют двухстороннюю синхронизацию и дублирование данных. При падении любой из нод вторая продолжит полноценно обслуживать сессии пользователей.

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

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

/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:

/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:

/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, необходимые для администрирования:

/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С с ФИЗИЧЕСКИМ СТИРАНИЕМ таблиц из СУБД:

/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:

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