Кластер 1С на базе CentOS

Автор: | 08.04.2018
6 комментариев

Дано:

  • сервер с CentOS 7: 2 шт.;
  • лицензия на сервер 1С:Предприятия 8.3: 2 шт.;
  • свободный системный администратор: 1 шт.

Задача: заставить это работать.

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

Часть 0. Подготовка

Итак, у нас есть два настроенных сервера (физических или виртуальных) с CentOS 7. Пусть это будут v83node1 и v83node2 с IP-адресами 172.16.0.101 и 172.16.0.102 соответственно. Так же у нас будет v83sql, который является виртуальным IP-адресом (VIP) 172.16.0.200. Подразумевается, что в сети присутствует сервер DNS, который в состоянии правильно разрешить доменные имена в IP-адреса. Если это не так, то нужно соответствующим образом заполнить файл /etc/hosts:

172.16.0.101     v83node1 v83node1.example.local
172.16.0.102     v83node2 v83node2.example.local
172.16.0.200     v83sql v83sql.example.local

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

Для установки необходимого ПО нам потребуются дополнительные репозитории. Это Extra Packages for Enterprise Linux (EPEL), репозиторий с пропатченной для 1С версией PostgreSQL от российской компании Postgres Professional, а так же официальный репозиторий PostgreSQL (если у вас один сервер, то данный репозиторий не обязателен). Подключим их:

[root@v83node1 ~]# yum install epel-release https://1c.postgrespro.ru/keys/postgrespro-1c-centos96.noarch.rpm https://download.postgresql.org/pub/repos/yum/9.6/redhat/rhel-7-x86_64/pgdg-centos96-9.6-3.noarch.rpm

Так как репозитории postgrespro-1c и pgdg96 содержат одинаковые пакеты, то необходимо задать правильные приоритеты для yum. В противном случае у вас наверняка возникнет ситуация, когда пропатченный PostgreSQL будет заменён «ванильным» и 1С работать не будет. Установим необходимый плагин и зададим приоритет postgrespro-1c над pgdg96:

[root@v83node1 ~]# yum install yum-plugin-priorities
[root@v83node1 ~]# sed -i '/^gpgkey/ a priority=1' /etc/yum.repos.d/postgrespro-1c.repo
[root@v83node1 ~]# sed -i '/^gpgkey/ a priority=2' /etc/yum.repos.d/pgdg-96-centos.repo

Теперь можно установить сервер PostgreSQL и repmgr. Последний позволяет управлять потоковой репликацией, но не является обязательным для её работы:

[root@v83node1 ~]# yum install postgresql96-server repmgr96

Для корректной работы репликации настроим SSH-аутентификацию по ключам для пользователя postgres, предварительно задав ему пароль. Сам же ключ создаётся без пароля. Обратите внимание, что при выполнении команды ssh-copy-id на v83node1 в аргументах указываем v83node2 и наоборот. Выполняем на v83node1:

[root@v83node1 ~]# passwd postgres
[root@v83node1 ~]# su postgres
bash-4.2$ ssh-keygen
bash-4.2$ ssh-copy-id -i ~/.ssh/id_rsa.pub postgres@v83node2
bash-4.2$ exit

И на v83node2:

[root@v83node2 ~]# passwd postgres
[root@v83node2 ~]# su postgres
bash-4.2$ ssh-keygen
bash-4.2$ ssh-copy-id -i ~/.ssh/id_rsa.pub postgres@v83node1
bash-4.2$ exit

Часть 1. Настройка PostgreSQL Primary

Все операции выполняются на v83node1.

Произведём инициализацию базы данных:

[root@v83node1 ~]# service postgresql-9.6 initdb
Initializing database:                                     [  OK  ]

Отредактируем /var/lib/pgsql/9.6/data/pg_hba.conf в соответствии со своими нуждами и политиками безопасности. Так как данная конфигурация будет распространена на другой сервер, то следует предусмотреть все возможные варианты подключения. Приведённые ниже настройки разрешают все локальные подключения и межсерверное взаимодействие без пароля. Так лучше не делать! 😉

# TYPE   DATABASE      USER   ADDRESS           METHOD
local    all           all                      trust
host     all           all    127.0.0.1/32      trust
host     all           all    ::1/128           trust
host     all           all    172.16.0.101/32   trust
host     replication   all    172.16.0.101/32   trust
host     all           all    172.16.0.102/32   trust
host     replication   all    172.16.0.102/32   trust
host     all           all    172.16.0.200/32   trust

Переходим к непосредственной настройке PostgreSQL. В файле /var/lib/pgsql/9.6/data/postgresql.conf отредактируем как минимум приведённые ниже параметры. Хорошей идеей будет сразу настроить PostgreSQL в соответствии со своими потребностями, так как это приведёт к значительному увеличению быстродействия. Для начальных значений есть смысл использовать PgTune, дополнительную информацию можно найти в разделе методической поддержки 1С:ИТС. Более глубокое понимание даст чтение документации, практика и тесты… много тестов:

listen_addresses = '*'
wal_level = replica
synchronous_commit = off
archive_mode = on
archive_command = '/bin/true'
max_wal_senders = 3
max_replication_slots = 2
hot_standby = on

Примечания. Помним, что данные настройки будут применены к standby-серверу. Поэтому параметрам listen_addresses и hot_standby присваиваем универсальные значения. Значение max_wal_senders должно быть как минимум на 1 больше, чем планируемое количество ведомых серверов. Выключение synchronous_commit приводит к заметному росту производительности, но в случае непредвиденного сбоя могут быть потеряны последние транзакции (с настройками по умолчанию за 600 мс до сбоя).

С данными настройками потоковая репликация будет асинхронной. Если нужна синхронная репликация, то в этом случае нельзя выключать synchronous_commit (но можно настроить, например, указав remote_write) и потребуется добавить в postgresql.conf параметр synchronous_standby_names = '*'. Расплатой за синхронность будет существенное падение производительности.

Отредактируем файла /etc/repmgr/9.6/repmgr.conf. В отличии от настроек PostgreSQL, настройки repmgr индивидуальны для каждого сервера:

node_id=1
node_name='v83node1'
conninfo='host=v83node1 dbname=repmgr'
data_directory='/var/lib/pgsql/9.6/data'
replication_user='postgres'
replication_type=physical
use_replication_slots=yes

Необходимо задать уникальные значения для node_id и node_name, а так же указать корректную строку подключения к локальной базе данных.

Запустим PostgreSQL, создадим базу данных для repmgr, после чего зарегистрируем primary-сервер.

[root@v83node1 ~]# chkconfig postgresql-9.6 on
[root@v83node1 ~]# service postgresql-9.6 start
Starting postgresql-9.6 (via systemctl):                   [  OK  ]
[root@v83node1 ~]# /usr/pgsql-9.6/bin/createdb -U postgres repmgr
[root@v83node1 ~]# su postgres
bash-4.2$ /usr/pgsql-9.6/bin/repmgr -f /etc/repmgr/9.6/repmgr.conf primary register
NOTICE: attempting to install extension "repmgr"
NOTICE: "repmgr" extension successfully installed
NOTICE: primary node record (id: 1) registered
bash-4.2$ exit

Часть 2. Настройка PostgreSQL Standby

Все операции выполняются на v83node2. По сути, настройка сводится к копированию конфигурации с primary-сервера.

Отредактируем файл /etc/repmgr/9.6/repmgr.conf:

node_id=2
node_name='v83node2'
conninfo='host=v83node2 dbname=repmgr'
data_directory='/var/lib/pgsql/9.6/data'
replication_user='postgres'
replication_type=physical
use_replication_slots=yes

Далее выполняем клонирование конфигурации с primary-сервера (директория /var/lib/pgsql/9.6/data должна быть пустой):

[root@v83node2 ~]# su postgres
bash-4.2$ /usr/pgsql-9.6/bin/repmgr -h v83node1 -d repmgr -f /etc/repmgr/9.6/repmgr.conf standby clone
NOTICE: destination directory "/var/lib/pgsql/9.6/data" provided
NOTICE: starting backup (using pg_basebackup)...
HINT: this may take some time; consider using the -c/--fast-checkpoint option
NOTICE: standby clone (using pg_basebackup) complete
NOTICE: you can now start your PostgreSQL server
HINT: for example: pg_ctl -D /var/lib/pgsql/9.6/data start
HINT: after starting the server, you need to register this standby with "repmgr standby register"
bash-4.2$ exit

Теперь можно запустить PostgreSQL и зарегистрировать standby-сервер:

[root@v83node2 ~]# chkconfig postgresql-9.6 on
[root@v83node2 ~]# service postgresql-9.6 start
Starting postgresql-9.6 (via systemctl):                   [  OK  ]
[root@v83node2 ~]# su postgres
bash-4.2$ /usr/pgsql-9.6/bin/repmgr -f /etc/repmgr/9.6/repmgr.conf standby register
NOTICE: standby node "v83node2" (id: 2) successfully registered
bash-4.2$ exit

Часть 3. Проверка работы PostgreSQL

Доверяй, но проверяй. Никогда не доверяй и всегда проверяй.

Проверим состояние со стороны primary-сервера (v83node1). Видно, что v83node2 (application_name) подключен с IP-адреса 172.16.0.102 (client_addr):

[root@v83node1 ~]# psql -U postgres -c 'SELECT * FROM pg_stat_replication;' -d repmgr -x
-[ RECORD 1 ]----+------------------------------
pid              | 11550
usesysid         | 99160
usename          | repmgr
application_name | v83node2
client_addr      | 172.16.0.102
client_hostname  |
client_port      | 46472
backend_start    | 2018-03-14 17:39:35.011805+03
backend_xmin     |
state            | streaming
sent_location    | 6/E001180
write_location   | 6/E001180
flush_location   | 6/E001180
replay_location  | 6/E001180
sync_priority    | 0
sync_state       | async

Со стороны standby-сервера (v83node2) команда будет другая и показывает статус репликации:

[root@v83node2 ~]# psql -U postgres -c 'SELECT * FROM pg_stat_wal_receiver;' -d repmgr -x
-[ RECORD 1 ]---------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
pid                   | 8112
status                | streaming
receive_start_lsn     | 6/E000000
receive_start_tli     | 1
received_lsn          | 6/E001180
received_tli          | 1
last_msg_send_time    | 2018-03-14 17:42:13.268053+03
last_msg_receipt_time | 2018-03-14 17:42:24.859852+03
latest_end_lsn        | 6/E001180
latest_end_time       | 2018-03-14 17:39:43.112174+03
slot_name             | repmgr_slot_2
conninfo              | user=repmgr dbname=replication host=v83node1 port=5432 application_name=v83node2 fallback_application_name=walreceiver sslmode=prefer sslcompression=1 krbsrvname=postgres

Так же состояние репликации можно проверить с любого сервера средствами repmgr:

[root@v83node1 ~]# sudo -u postgres /usr/pgsql-9.6/bin/repmgr -f /etc/repmgr/9.6/repmgr.conf cluster show
 ID | Name     | Role    | Status    | Upstream | Location | Connection string
----+----------+---------+-----------+----------+----------+-----------------------------
 1  | v83node1 | primary | * running |          | default  | host=v83node1 dbname=repmgr
 2  | v83node2 | standby |   running | v83node1 | default  | host=v83node2 dbname=repmgr

Для проверки репликации на практике посмотрим список баз на v83node2:

[root@v83node2 ~]# psql -U postgres -c '\list'
                                  Список баз данных
    Имя    | Владелец | Кодировка | LC_COLLATE  |  LC_CTYPE   |     Права доступа
-----------+----------+-----------+-------------+-------------+-----------------------
 postgres  | postgres | UTF8      | ru_RU.UTF-8 | ru_RU.UTF-8 |
 repmgr    | repmgr   | UTF8      | ru_RU.UTF-8 | ru_RU.UTF-8 |
 template0 | postgres | UTF8      | ru_RU.UTF-8 | ru_RU.UTF-8 | =c/postgres          +
           |          |           |             |             | postgres=CTc/postgres
 template1 | postgres | UTF8      | ru_RU.UTF-8 | ru_RU.UTF-8 | =c/postgres          +
           |          |           |             |             | postgres=CTc/postgres
(4 строки)

Создадим на v83node1 новую базу данных:

[root@v83node1 ~]# psql -U postgres -c 'CREATE DATABASE test;'
CREATE DATABASE

И снова проверим список баз на v83node2:

[root@v83node2 ~]# psql -U postgres -c '\list'
                                  Список баз данных
    Имя    | Владелец | Кодировка | LC_COLLATE  |  LC_CTYPE   |     Права доступа
-----------+----------+-----------+-------------+-------------+-----------------------
 postgres  | postgres | UTF8      | ru_RU.UTF-8 | ru_RU.UTF-8 |
 repmgr    | repmgr   | UTF8      | ru_RU.UTF-8 | ru_RU.UTF-8 |
 template0 | postgres | UTF8      | ru_RU.UTF-8 | ru_RU.UTF-8 | =c/postgres          +
           |          |           |             |             | postgres=CTc/postgres
 template1 | postgres | UTF8      | ru_RU.UTF-8 | ru_RU.UTF-8 | =c/postgres          +
           |          |           |             |             | postgres=CTc/postgres
 test      | postgres | UTF8      | ru_RU.UTF-8 | ru_RU.UTF-8 |
(5 строк)

Как видим, репликация работает.

Часть 4. Настройка keepalived

Данный раздел должен был называться «Настройка автоматической обработки отказов». Но данный вопрос требует более ответственного подхода, чем «хаутушечка» в Интернете. Поэтому если вам нужна статья для настройки автоматической обработки отказов, то вам не нужна автоматическая обработка отказов. Вместо этого упростим ручную миграцию primary-сервера путём настройки VIP. Установим keepalived:

[root@v83node1 ~]# yum install keepalived

Отредактируем файл /etc/keepalived/keepalived.conf на v83node1:

! Configuration File for keepalived

global_defs {
    notification_email {
        admin@example.com
    }
    notification_email_from v83node1@example.com
    smtp_server smtp.example.com
    smtp_connect_timeout 10
}

vrrp_script chk_repmgr {
    script "/etc/keepalived/repmgr_check"
    interval 3
    timeout 2
    weight 100
    rise 2
    fall 2
    user postgres
}

vrrp_instance v83node1 {
    state MASTER
    interface eth1
    dont_track_primary
    track_script {
        chk_repmgr
    }
    virtual_router_id 100
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass Pa$w0rd
    }
    virtual_ipaddress {
        172.16.0.200/24 dev eth1 label eth1:1
    }
    smtp_alert
}

Описание основных параметров:

  • global_defs — секция с глобальными параметрами, в частности можно задать настройки для уведомлений по электронной почте;
  • vrrp_script — секция описываем скрипт для проверки состояния PostgreSQL (primary или standby), его вес и периодичность вызова;
  • state — задает режим работы при запуске;
  • interface — на каком интерфейсе работать;
  • dont_track_primary — не принимать во внимание состояние сетевого интерфейса;
  • track_script — скрипт для дополнительной оценки состояния, в случае положительного вызова его вес будет прибавлен к приоритету сервера
  • virtual_router_id — уникальный идентификатор VIP, должен быть одинаковым на всех серверах;
  • priority — приоритет сервера при выборе нового мастера, чем выше значение тем больше приоритет;
  • advert_int — частота оповещения мастером других серверов через широковещательный адрес 224.0.0.18 (в секундах);
  • authentication — задаёт пароль (не более 8 символов), должен быть одинаковым на всех серверах;
  • virtual_ipaddress — собственно сам VIP, можно указать несколько;
  • smtp_alert — отправлять уведомления о событиях по электронной почте.

На v83node2 конфигурационный файл будет отличаться секцией vrrp_instance. Поменяли режим при запуске и понизили приоритет:

vrrp_instance v83node1 {
    state BACKUP
    interface eth1
    dont_track_primary
    track_script {
        chk_repmgr
    }
    virtual_router_id 100
    priority 50
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass Pa$w0rd
    }
    virtual_ipaddress {
        172.16.0.200/24 dev eth1 label eth1:1
    }
    smtp_alert
}

Пример скрипта /etc/keepalived/repmgr_check:

 #!/bin/bash
/usr/pgsql-9.6/bin/repmgr -f /etc/repmgr/9.6/repmgr.conf node check --role | grep "node is primary"

Запустим keepalived и проверим, что VIP появился на указанном интерфейсе:

[root@v83node1 ~]# systemctl enable keepalived
Created symlink from /etc/systemd/system/multi-user.target.wants/keepalived.service to /usr/lib/systemd/system/keepalived.service.
[root@v83node1 ~]# systemctl start keepalived
[root@v83node1 ~]# ip -4 addr show dev eth1
eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    inet 172.16.0.101/24 brd 172.16.0.255 scope global eth1
    inet 172.16.0.200/24 global secondary eth1:1

Если всё настроили правильно, то при миграции primary-сервера PostgreSQL виртуальный IP-адрес последует за ним.

Часть 5. Примеры переключения primary-сервера

Плановое ручное переключение

Если по каким-то причинам надо поменять primary и standby местами, то сделать это можно одной командой. Внимание! Данная команда запускает довольно сложную серию операций на двух серверах, поэтому перед запуском убедитесь в надёжности вашего оборудования, стабильности сетевого соединения, отсутствии активных клиентов и наличии резервной копии (в первую очередь наличие резервной копии!). Выполним на standby-сервере:

[root@v83node2 ~]# sudo -u postgres /usr/pgsql-9.6/bin/repmgr -f /etc/repmgr/9.6/repmgr.conf standby switchover
NOTICE: executing switchover on node "v83node2" (ID: 2)
NOTICE: local node "v83node2" (ID: 2) will be promoted to primary; current primary "v83node1" (ID: 1) will be demoted to standby
NOTICE: stopping current primary node "v83node1" (ID: 1)
NOTICE: issuing CHECKPOINT
DETAIL: executing server command "/usr/pgsql-9.6/bin/pg_ctl  -D '/var/lib/pgsql/9.6/data' -W -m fast stop"
NOTICE: current primary has been cleanly shut down at location 0/A000028
NOTICE: promoting standby to primary
DETAIL: promoting server "v83node2" (ID: 2) using "/usr/pgsql-9.6/bin/pg_ctl  -w -D '/var/lib/pgsql/9.6/data' promote"
server promoting
NOTICE: STANDBY PROMOTE successful
DETAIL: server "v83node2" (ID: 2) was successfully promoted to primary
NOTICE: setting node 1's primary to node 2
NOTICE: starting server using "/usr/pgsql-9.6/bin/pg_ctl  -w -D '/var/lib/pgsql/9.6/data' start"
NOTICE: NODE REJOIN successful
DETAIL: node 1 is now attached to node 2
NOTICE: replication slot "repmgr_slot_2" deleted on node 1
NOTICE: switchover was successful
DETAIL: node "v83node2" is now primary and node "v83node1" is attached as standby
NOTICE: STANDBY SWITCHOVER has completed successfully

Вернуть всё обратно можно той же командой, только выполнить её теперь надо на v83node1.

Аварийное ручное переключение и восстановление

Случилось страшное — primary-сервер упал:

[root@v83node2 ~]# sudo -u postgres /usr/pgsql-9.6/bin/repmgr -f /etc/repmgr/9.6/repmgr.conf cluster show
 ID | Name     | Role    | Status        | Upstream | Location | Connection string
----+----------+---------+---------------+----------+----------+-----------------------------
 1  | v83node1 | primary | ? unreachable |          | default  | host=v83node1 dbname=repmgr
 2  | v83node2 | standby |   running     | v83node1 | default  | host=v83node2 dbname=repmgr

WARNING: following issues were detected
  - when attempting to connect to node "v83node1" (ID: 1), following error encountered :
"could not connect to server: Connection refused
        Is the server running on host "v83node1" (172.16.0.101) and accepting
        TCP/IP connections on port 5432?"
  - node "v83node1" (ID: 1) is registered as an active primary but is unreachable

Если вы понимаете, что быстро вернуть в строй его не получится, то можно перевести standby-сервер в режим primary:

[root@v83node2 ~]# sudo -u postgres /usr/pgsql-9.6/bin/repmgr -f /etc/repmgr/9.6/repmgr.conf standby promote
NOTICE: promoting standby to primary
DETAIL: promoting server "v83node2" (ID: 2) using "/usr/pgsql-9.6/bin/pg_ctl  -w -D '/var/lib/pgsql/9.6/data' promote"
server promoting
NOTICE: STANDBY PROMOTE successful
DETAIL: server "v83node2" (ID: 2) was successfully promoted to primary

Снова проверим состояние кластера:

[root@v83node2 ~]# sudo -u postgres /usr/pgsql-9.6/bin/repmgr -f /etc/repmgr/9.6/repmgr.conf cluster show
 ID | Name     | Role    | Status    | Upstream | Location | Connection string
----+----------+---------+-----------+----------+----------+-----------------------------
 1  | v83node1 | primary | - failed  |          | default  | host=v83node1 dbname=repmgr
 2  | v83node2 | primary | * running |          | default  | host=v83node2 dbname=repmgr

WARNING: following issues were detected
  - when attempting to connect to node "v83node1" (ID: 1), following error encountered :
"could not connect to server: Connection refused
        Is the server running on host "v83node1" (172.16.0.101) and accepting
        TCP/IP connections on port 5432?"

Как видим, роль v83node2 была повышена до primary, но и у v83node1 тоже primary. Исправим это, указав соответствующий node-id:

[root@v83node2 ~]# sudo -u postgres /usr/pgsql-9.6/bin/repmgr -f /etc/repmgr/9.6/repmgr.conf primary unregister --node-id 1
[root@v83node2 ~]# sudo -u postgres /usr/pgsql-9.6/bin/repmgr -f /etc/repmgr/9.6/repmgr.conf cluster show
 ID | Name     | Role    | Status    | Upstream | Location | Connection string
----+----------+---------+-----------+----------+----------+-----------------------------
 2  | v83node2 | primary | * running |          | default  | host=v83node2 dbname=repmgr

После этих операций вернуть primary-сервер в строй просто так уже нельзя. Предварительно его надо будет завести в кластер как standby-сервер (см. часть 2).

Часть 6. Установка сервера 1С:Предприятия

У сервера 1С:Предприятия внушительный список зависимостей, поэтому предварительно установим их:

[root@v83node1 ~]# yum install ImageMagick cabextract curl fontconfig freetype glib2 java-1.8.0-openjdk krb5-libs krb5-workstation libgsf unixODBC xorg-x11-font-utils

Для корректного отображения интерфейса тонкого клиента необходимы Microsoft Core Fonts (за подробностями см. mscorefonts2.sourceforge.net):

[root@v83node1 ~]# yum install https://downloads.sourceforge.net/project/mscorefonts2/rpms/msttcore-fonts-installer-2.6-1.noarch.rpm

Теперь переходим к установке самого сервера. У 1С нет своего репозитория, поэтому установочные пакеты необходимо предварительно скачать с сайта и распаковать в любую удобную директорию:

[root@v83node1 ~]# ls -1 /opt/dist/8.3.11.3034
1C_Enterprise83-common-8.3.11-3034.x86_64.rpm
1C_Enterprise83-common-nls-8.3.11-3034.x86_64.rpm
1C_Enterprise83-server-8.3.11-3034.x86_64.rpm
1C_Enterprise83-server-nls-8.3.11-3034.x86_64.rpm
1C_Enterprise83-ws-8.3.11-3034.x86_64.rpm
1C_Enterprise83-ws-nls-8.3.11-3034.x86_64.rpm

После чего установить:

[root@v83node1 ~]# yum install /opt/dist/8.3.11.3034/*.rpm
Зависимости определены

============================================================
 Package                        Архитектура     Версия     
============================================================
Установка:
 1C_Enterprise83-common         x86_64          8.3.11-3034
 1C_Enterprise83-common-nls     x86_64          8.3.11-3034
 1C_Enterprise83-server         x86_64          8.3.11-3034
 1C_Enterprise83-server-nls     x86_64          8.3.11-3034
 1C_Enterprise83-ws             x86_64          8.3.11-3034
 1C_Enterprise83-ws-nls         x86_64          8.3.11-3034

Итого за операцию
============================================================
Установить  6 пакетов

После завершения установки сервер сразу готов к работе, поэтому запустим его:

[root@v83node1 ~]# chkconfig srv1cv83 on
[root@v83node1 ~]# service srv1cv83 start
Starting 1C:Enterprise 8.3 server: OK

Запускаем оснастку «Администрирование серверов 1С Предприятия» и пробуем подключиться к серверу:

Дальнейшая процедура настройки сервера 1С:Предприятия достаточно хорошо освещена в документации, прилагаемой к серверу.

Кластер 1С на базе CentOS: 6 комментариев

  1. Роман

    Привет, у меня бидэ)
    на слейве при попытке переключить его в мастер выбивает

    [root@slave1 9.6]# sudo -u postgres /usr/pgsql-9.6/bin/repmgr -f /etc/repmgr/9.6/repmgr.conf standby switchover
    NOTICE: executing switchover on node «slave1» (ID: 2)
    ERROR: unable to determine whether demotion candidate is able to make replication connection to promotion candidate

    Что с этим делать?

    Ответить ↓
    1. LB Автор записи

      Операция switchover взаимная и для её выполнения кластер должен быть работоспособным, то есть с живым primary-сервером и рабочей сетью. Если мастер недоступен, то для переключения следует выполнять «standby promote», но после этой операции бывший primary одной командой в строй не вернуть.

      Ответить ↓
      1. Роман

        В этом весь цимес.
        Они в одной подсети и прекрасно пингуются и по IP и по именам.

  2. Алексей

    Поддерживаю Романа. такая же ошибка. кто-нибудь решил?

    Ответить ↓
  3. andy

    1с устанавливаем на primary.
    Вопрос, нужно ли ее утанавливать для Второго. т.к как я понял, что реплицыруются только postgres

    Ответить ↓

Добавить комментарий для LB Отменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *