4.4.3. Развёртывание кластера eCA-VA

Aladdin Enterprise CAУстановка и развёртываниеAladdin Enterprise CA

Программное средство обеспечивает объединение нескольких eCA-VA в кластер. Кластеризации обеспечивается в отказоустойчивом режиме c использованием внешнего средства балансировки нагрузки HAProxy ¹. Отказоустойчивый режим кластеризации обеспечивает как холодное “active‑passive” ², так и горячее “active-active” ³ резервирование. Горячее “active-active” резервирование возможно только при “source” ⁴ балансировке.

Развертывания кластера eCA-VA возможно в следующих вариантах:

В виртуальной инфраструктуре путем клонирования виртуальной машины основного узла.
С помощью переноса контейнера закрытого ключа службы OCSP основного узла.

Развертывание кластера в виртуальной среде с холодным резервированием “active-passive”

Кластер включает следующие узлы:

Виртуальная машина с установленным eCA-VA (далее - ВМ1) - основной узел кластера.
Клон ВМ1 eCA-VA (далее - ВМ2) - резервный узел кластера.
Клон ВМ1, созданный при необходимости при эксплуатации кластера (далее - ВМР) - дополнительный резервный узел кластера.
Виртуальная машина с установленной и настроенной СУБД (далее - ВМ3).
Виртуальная машина с установленным и настроенным средством балансировки нагрузки HAProxy (далее - ВМ4).

На всех указанных выше виртуальных машинах допускается использование только ОС, определенных требованиями в разделе Требования к программному обеспечению. Допускается использование одной виртуальной машины для реализации ВМ3 и ВМ4.

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

Выполните следующие действия на ВМ3:
- Выполнить установку одной из нижеприведённых СУБД:
  - PostgreSQL из состава ОС
  - Jatoba.
- Увеличьте максимальное количество подключений к СУБД, указав в параметре max_connections значение 2000⁵ в файле ⁶:
  - /var/lib/pgsql/15/data/postgresql.conf для СУБД PostgreSQL.
  - var/lib/jatoba/[версия]/data/ostgresql.conf для СУБД Jatoba.
- Перезапустите используемую СУБД выполнив команду с правами суперпользователя:
  - systemctl restart postgresql для СУБД PostgreSQL.
  - systemctl restart jatoba-[версия] для СУБД Jatoba.
Выполните следующие действия на ВМ1:
- Выполните установку eCA-VA с подключением внешней СУБД, установленной на ВМ3 (см. приложение Настройка подключения к внешней СУБД).
- Подключитесь локально к веб-интерфейсу eCA-VA под учетной записью администратора инициализации и выполните подключение к обслуживаемым eCA-CA (см. раздел Добавление подключения к eCA-CA).
- Подключитесь к веб-интерфейсу eCA-VA под учетной записью администратора и создайте для обслуживаемых eCA-CA Центры валидации (см. раздел Создание центра валидации), а при необходимости службы OCSP для них (см. раздел Создание службы OCSP созданного eCA-VA).
Средствами используемого гипервизора клонируйте ВМ1, тем самым создав ВМ2.
Запустите ВМ2 и дождитесь завершения запуска службы aeca-va.service.

Внимание! В случае, если на ВМ1 для каких-либо Центров валидации были созданы службы OCSP, у которых криптопровайдером является СКЗИ “КриптоПро CSP”, на ВМ2 необходимо выполнить аналогичную ВМ1 установку СКЗИ “КриптоПро CSP” и подключение внешней гаммы. В случае, если на ВМ1 для каких-либо Центров валидации были созданы службы OCSP, местом хранения закрытого ключа которых является ПАКМ “КриптоПро HSM”, необходимо выполнить на ВМ2 подключение СКЗИ “КриптоПро CSP” к тому же ПАКМ “КриптоПро HSM”.

Выполните следующие действия на ВМ4:
- Установите средство балансировки нагрузки HAProxy выполнив следующую команду с правами суперпользователя:
  - dnf install haproxy- для РЕД ОС, РОСА “ХРОМ” 12 Сервер и SberLinux OS Server.
  - apt install haproxy- для ОС Astra Linux SE.
  - apt-get install haproxy- для ОС Альт Сервер.
- Выполните редактирование конфигурационного файла /etc/haproxy/haproxy.cfg, приведя его к следующему виду:
```
global
    log /var/log/haproxy/log local0
    log /var/log/haproxy/log local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    user haproxy
    group haproxy
    daemon
defaults
    log global
    mode http
    option httplog
    option dontlognull
    timeout connect 5000
    timeout client 50000
    timeout server 50000
frontend ft_app
    bind *:443
    mode tcp
    default_backend bk_app
backend bk_app
    mode tcp
    server main DOMAINNAME_HOST1:443 check
    server clone DOMAINNAME_HOST2:443 check backup
listen stats
    bind *:8404
    stats enable
    stats uri /stats
    stats auth admin:password
```
где: - DOMAINNAME_HOST1 - доменное имя ВМ1. - DOMAINNAME_HOST2 - доменное имя ВМ2. - admin:password - имя и пароль учетной записи для доступа к панели мониторинга HAProxy.
- Перезапустите HAProxy выполнив следующую команду с правами суперпользователя systemctl restart haproxy.service.

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

Средствами используемого гипервизора клонируйте ВМ1, тем самым создав ВМР.
Запустите ВМР и дождитесь запуска службы aeca-va.service.

Внимание! В случае, если на ВМ1 для каких-либо Центров валидации были созданы службы OCSP, у которых криптопровайдером является СКЗИ “КриптоПро CSP”, на ВМР необходимо выполнить аналогичную ВМ1 установку СКЗИ “КриптоПро CSP” и подключение внешней гаммы. В случае, если на ВМ1 для каких-либо Центров валидации были созданы службы OCSP, местом хранения закрытого ключа которых является ПАКМ “КриптоПро HSM”, необходимо выполнить на ВМР подключение СКЗИ “КриптоПро CSP” к тому же ПАКМ “КриптоПро HSM”.
Выполните на ВМ4 редактирование конфигурационного файла /etc/haproxy/haproxy.cfg, добавив в секцию backend bk_app информацию о доменном имени ВМР в соответствии с примером, представленном ниже:
```
backend bk_app
mode tcp
server main DOMAINNAME_HOST1:443 check
server clone DOMAINNAME_HOST2:443 check backup
server clone DOMAINNAME_HOSTR:443 check backup
```
где DOMAINNAME_HOSTR - доменное имя ВМР.
Перезапустить HAProxy на ВМ4 выполнив следующую команду с правами суперпользователя: systemctl restart haproxy.service.
создайте резервные копии (см. Резервное копирование и восстановление данных):
- полную резервную копию (backup.sh без параметров) на основном узле кластера;
- резервную копию без БД (backup.sh с параметром “-nodb”) на резервном узле кластера. Это позволит восстанавливать резервный узел без влияния на базу данных eCA-VA и, как следствие, на работоспособность основного узла.

В результате выполненной настройки кластера все запросы, направляемые к eCA-VA через средство балансировки нагрузки HAProxy, будут перенаправляться на основной узел кластера ВМ1. При недоступности основного узла кластера все запросы будут перенаправляться на резервный узел кластера ВМ2. При недоступности ВМ2 все запросы будут перенаправляться на дополнительный резервный узел кластера ВМР. Для мониторинга состояния узлов кластера используйте панель мониторинга HAProxy. Для подключения к панели мониторинга введите в адресной строке веб-браузера http:/IP_VM4:8404/stats (где IP_VM4 - IP-адрес ВМ4) и пройдите идентификацию и аутентификацию с помощью имени и пароля учетной записи, указанных при настройка конфигурационного файла HAProxy.

Внимание! В случае дальнейшего создания Центров валидации со службами OCSP в развернутом в виртуальной инфраструктуре кластере необходимо сохранять соответствие перечня закрытых ключей служб OCSP, хранимых локально и в хранилище HDIMAGE СКЗИ “КриптоПро CSP” и контейнеров закрытого ключа администраторов (для взаимодействия с eCA-CA) на ВМ1, ВМ2 и всех дополнительных резервных узлах. Например, если активным узлом кластера являлся ВМ2, скопируйте созданные закрытые ключи служб OCSP и администраторов с ВМ2 на ВМ1, а затем перезапустите aeca‑va.service на ВМ1. Закрытые ключи служб OCSP, для которых при создании было выбрано место хранения “Локально”, хранятся в каталоге /opt/aecaVa/dist/cryptotoken. При копировании файлов необходимо назначать владельцем данных файлов на конечной ВМ пользователя “aeca”. Закрытые ключи служб OCSP, для которых при их создании было выбрано место хранения “Жесткий диск (HDIMAGE)”, по умолчанию хранятся в каталоге /var/opt/cprocsp/keys/aeca. При копировании файлов необходимо назначать владельцем данных файлов на конечной ВМ пользователя “aeca”, затем перезапускать на данной ВМ СКЗИ “КриптоПро CSP”. Закрытые ключи служб OCSP, для которых при их создании было выбрано место хранения ПАКМ “КриптоПро HSM”, не требуют копирования. Для поддержки работы с такими ключами необходимо сохранять подключение всех узлов кластера к одному ПАКМ “КриптоПро HSM”. Закрытые ключи администраторов для взаимодействия с eCA-CA расположены в каталоге /opt/aecaVa/dist/certificates/account.

Развертывание кластера с холодным резервированием “active-passive” путем переноса контейнеров закрытого ключа служб OCSP основного узла

Кластер включает следующие узлы:

Сервер с установленным eCA-VA (далее - ВМ1) - основной узел кластера.
Сервер с установленным eCA-VA, на который будет выполнен перенос контейнеров закрытого ключа служб OCSP Центров валидации (далее - АРМ2) - резервный узел кластера.
Сервер с установленным eCA-VA (далее - ВМ1), а который будет выполнен перенос контейнеров закрытого ключа служб OCSP Центров валидации (далее - АРМР) - дополнительный резервный узел кластера.
Сервер с установленной и настроенной СУБД (далее - АРМ3).
Сервер с установленным и настроенным средством балансировки нагрузки HAProxy (далее - АРМ4).

На всех указанных выше серверах допускается использование только следующих ОС, определенных требованиями в разделе Требования к программному обеспечению. Допускается использование одного сервера для реализации АРМ3 и АРМ4.

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

Выполните следующие действия на АРМ3:
- Выполнить установку одной из нижеприведённых СУБД:
  - PostgreSQL из состава ОС
  - Jatoba.
- Увеличьте максимальное количество подключений к СУБД, указав в параметре max_connections значение 2000 ⁷ в файле ⁸:
  - /var/lib/pgsql/15/data/postgresql.conf для СУБД PostgreSQL.
  - var/lib/jatoba/[версия]/data/ostgresql.conf для СУБД Jatoba.
- Перезапустите используемую СУБД выполнив команду с правами суперпользователя:
  - systemctl restart postgresql для СУБД PostgreSQL.
  - systemctl restart jatoba-[версия] для СУБД Jatoba.
Выполните следующие действия на АРМ1:
- Выполните установку eCA-VA с подключением внешней СУБД, установленной на ВМ3 (см. приложение Настройка подключения к внешней СУБД).
- Подключитесь локально к веб-интерфейсу eCA-VA под учетной записью администратора инициализации и выполните подключение к обслуживаемым eCA-CA (см. раздел Добавление подключения к eCA-CA).
- Подключитесь к веб-интерфейсу eCA-VA под учетной записью администратора и создайте для обслуживаемых eCA-CA Центры валидации (см. раздел Создание центра валидации), а при необходимости службы OCSP для них (см. раздел Создание службы OCSP созданного eCA-VA).
На АРМ2 выполните установку eCA-VA с подключением внешней СУБД ⁹, установленной на АРМ3 (см. приложение Настройка подключения к внешней СУБД).

Внимание! В случае, если на АРМ1 для каких-либо Центров валидации были созданы службы OCSP, у которых криптопровайдером является СКЗИ “КриптоПро CSP”, на АРМ2 необходимо выполнить аналогичную АРМ1 установку СКЗИ “КриптоПро CSP” и подключение внешней гаммы. В случае, если на АРМ1 для каких-либо Центров валидации были созданы службы OCSP, местом хранения закрытого ключа которых является ПАКМ “КриптоПро HSM”, необходимо выполнить на АРМ2 подключение СКЗИ “КриптоПро CSP” к тому же ПАКМ “КриптоПро HSM”.

Если на АРМ1 была создана служба OCSP, закрытый ключ которой хранится локально, скопируйте с АРМ1 содержимое каталога /opt/aecaVa/dist/cryptotoken в каталог /opt/aecaa/dist/cryptotoken АРМ2.
Если на АРМ1 была создана служба OCSP, закрытый ключ которой расположен в хранилище HDIMAGE СКЗИ “КриптоПро CSP”, скопируйте с АРМ1 контейнер закрытого ключа из каталога /var/opt/cprocsp/keys/aeca в каталог /var/opt/cprocsp/keys/aeca АРМ2. При этом необходимо назначить владельцем данного файла на АРМ2 пользователя aeca (по умолчанию), и перезапустить на АРМ2 СКЗИ “КриптоПро CSP”.
Скопируйте с АРМ1 содержимое каталога /opt/aecaVa/dist/certificates в каталог /opt/aecaVa/dist/certificates АРМ2.
Если на АРМ2 установлена РЕД ОС, РОСА “ХРОМ” 12 Сервер или SberLinux OS Server, то выполните с правами суперпользователя следующие команды в терминале на АРМ2:
- restorecon -Rv /opt/aecaVa/dist/cryptotoken
- restorecon -Rv /opt/aecaVa/dist/certificates
Перезапустите на АРМ2 службу aeca-va.service выполнив с правами суперпользователя следующую команду:

systemctl restart aeca-va.service

Выполните следующие действия на ВМ4:
- Выполните установку средства балансировки нагрузки HAProxy выполнив следующую команду с правами суперпользователя:
  - dnf install haproxy- для РЕД ОС, РОСА “ХРОМ” 12 Сервер и SberLinux OS Server.
  - apt install haproxy- для ОС Astra Linux SE.
  - apt-get install haproxy- для ОС Альт Сервер.
- На АРМ4 выполните редактирование конфигурационного файла /etc/haproxy/haproxy.cfg, приведя его к следующему виду:
```
global
    log /var/log/haproxy/log local0
    log /var/log/haproxy/log local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    user haproxy
    group haproxy
    daemon
defaults
    log global
    mode http
    option httplog
    option dontlognull
    timeout connect 5000
    timeout client 50000
    timeout server 50000
frontend ft_app
    bind *:443
    mode tcp
    default_backend bk_app
backend bk_app
    mode tcp
    server main DOMAINNAME_HOST1:443 check
    server clone DOMAINNAME_HOST2:443 check backup
listen stats
    bind *:8404
    stats enable
    stats uri /stats
    stats auth admin:password
```
  где:
  - DOMAINNAME_HOST1 - доменное имя АРМ1.
  - DOMAINNAME_HOST2 - доменное имя АРМ2.
  - admin:password - имя и пароль учетной записи для доступа к панели мониторинга HAProxy.
На АРМ4 перезапустите HAProxy выполнив следующую команду с правами суперпользователя: systemctl restart haproxy.service

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

Внимание! В случае, если на АРМ1 для каких-либо Центров валидации были созданы службы OCSP, у которых криптопровайдером является СКЗИ “КриптоПро CSP”, на АРМР необходимо выполнить аналогичную АРМ1 установку СКЗИ “КриптоПро CSP” и подключение внешней гаммы. В случае, если на АРМ1 для каких-либо Центров валидации были созданы службы OCSP, местом хранения закрытого ключа которых является ПАКМ “КриптоПро HSM”, необходимо выполнить на АРМР подключение СКЗИ “КриптоПро CSP” к тому же ПАКМ “КриптоПро HSM”.

Выполните на АРМ4 редактирование конфигурационного файла /etc/haproxy/haproxy.cfg, добавив в секцию backend bk_app информацию о доменном имени АРМР в соответствии с примером, представленном ниже:

backend bk_app
mode tcp
server main DOMAINNAME_HOST1:443 check
server clone DOMAINNAME_HOST2:443 check backup
server clone DOMAINNAME_HOSTR:443 check backup

где DOMAINNAME_HOSTR - доменное имя АРМР.

Перезапустите на АРМ4 HAProxy выполнив следующую команду с правами суперпользователя: systemctl restart haproxy.service

В результате в кластере появится дополнительный резервный узел. Все описанные выше рекомендации и уточнения по работе с узлом АРМ2, также относятся и к узлу АРМР.

В результате приведенной настройки кластера все запросы, направляемые к eCA-VA через средство балансирования нагрузки HAProxy, будут перенаправляться на основной узел кластера АРМ1. В случае недоступности основного узла кластера все запросы, направляемые к eCA-VA через средство балансирования нагрузки HAProxy, будут перенаправляться на резервный узел кластера АРМ2. Для мониторинга состояния узлов кластера используйте панель мониторинга HAProxy. Для подключения к панели мониторинга введите в адресной строке веб-браузера http:/IP_ARM4:8404/stats (где IP_ARM4 - IP-адрес АРМ4) и пройдите идентификацию и аутентификацию с помощью имени и пароля учетной записи, указанных при настройка конфигурационного файла HAProxy.

Внимание! В случае дальнейшего создания Центров валидации со службами OCSP в развернутом в виртуальной инфраструктуре кластере необходимо сохранять соответствие перечня закрытых ключей служб OCSP, хранимых локально и в хранилище HDIMAGE СКЗИ “КриптоПро CSP” и контейнеров закрытого ключа администраторов (для взаимодействия с eCA-CA) на АРМ1, АРМ2 и всех дополнительных резервных узлах. Например, если активным узлом кластера являлся АРМ2, скопируйте созданные закрытые ключи служб OCSP с АРМ2 на АРМ1, а затем перезапустите aeca‑ca.service на АРМ1. Закрытые ключи служб OCSP, для которых при создании было выбрано место хранения “Локально”, хранятся в каталоге /opt/aecaVa/dist/cryptotoken. При копировании файлов необходимо назначать владельцем данных файлов на конечном АРМ пользователя “aeca”. Закрытые ключи служб OCSP, для которых при их создании было выбрано место хранения “Жесткий диск (HDIMAGE)”, по умолчанию хранятся в каталоге /var/opt/cprocsp/keys/aeca. При копировании файлов необходимо назначать владельцем данных файлов на конечном АРМ пользователя “aeca”, затем перезапускать на данном АРМ СКЗИ “КриптоПро CSP”. Закрытые ключи служб OCSP, для которых при их создании было выбрано место хранения ПАКМ “КриптоПро HSM”, не требуют копирования. Для поддержки работы с такими ключами необходимо сохранять подключение всех узлов кластера к одному ПАКМ “КриптоПро HSM”. Закрытые ключи администраторов для взаимодействия с eCA-CA расположены в каталоге /opt/aecaVa/dist/certificates/account.

Развертывания кластера в виртуальной среде с горячим резервированием “active-active”

Кластер включает следующие узлы:

Виртуальная машина с установленным eCA-VA (далее - ВМ1) - основной узел кластера.
Клон ВМ1 eCA-VA (далее - ВМ2) - резервный узел кластера.
Клон ВМ1, созданный при необходимости при эксплуатации кластера (далее - ВМР) - дополнительный резервный узел кластера.
Виртуальная машина с установленной и настроенной СУБД (далее - ВМ3).
Виртуальная машина с установленным и настроенным средством балансировки нагрузки HAProxy (далее - ВМ4).

На всех указанных выше виртуальных машинах допускается использование только ОС, определенных требованиями в разделе Требования к программному обеспечению настоящего руководства. Допускается использование одной виртуальной машины для реализации ВМ3 и ВМ4.

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

Выполните следующие действия на ВМ3:
- Выполнить установку одной из нижеприведённых СУБД:
  - PostgreSQL из состава ОС
  - Jatoba.
- Увеличьте максимальное количество подключений к СУБД, указав в параметре max_connections значение 2000¹⁰ в файле ¹¹:
  - /var/lib/pgsql/15/data/postgresql.conf для СУБД PostgreSQL.
  - var/lib/jatoba/[версия]/data/ostgresql.conf для СУБД Jatoba.
- Перезапустите используемую СУБД выполнив команду с правами суперпользователя:
  - systemctl restart postgresql для СУБД PostgreSQL.
  - systemctl restart jatoba-[версия] для СУБД Jatoba.
Выполните следующие действия на ВМ1:
- Выполните установку eCA-VA с подключением внешней СУБД, установленной на ВМ3 (см. приложение Настройка подключения к внешней СУБД).
- Подключитесь локально к веб-интерфейсу eCA-VA под учетной записью администратора инициализации и выполните подключение к обслуживаемым eCA-CA (см. раздел Добавление подключения к eCA-CA).
- Подключитесь к веб-интерфейсу eCA-VA под учетной записью администратора и создайте для обслуживаемых eCA-CA Центры валидации (см. раздел Создание центра валидации), а при необходимости службы OCSP для них (см. раздел Создание службы OCSP созданного eCA-VA).
Средствами используемого гипервизора клонируйте ВМ1, тем самым создав ВМ2.
Запустите ВМ2 и дождитесь завершения запуска службы aeca-va.service.

Внимание! В случае, если на ВМ1 для каких-либо Центров валидации были созданы службы OCSP, у которых криптопровайдером является СКЗИ “КриптоПро CSP”, на ВМ2 необходимо выполнить аналогичную ВМ1 установку СКЗИ “КриптоПро CSP” и подключение внешней гаммы. В случае, если на ВМ1 для каких-либо Центров валидации были созданы службы OCSP, местом хранения закрытого ключа которых является ПАКМ “КриптоПро HSM”, необходимо выполнить на ВМ2 подключение СКЗИ “КриптоПро CSP” к тому же ПАКМ “КриптоПро HSM”.
Выполните следующие действия на ВМ4:
- Установите средство балансировки нагрузки HAProxy выполнив следующую команду с правами суперпользователя:
  - dnf install haproxy - для РЕД ОС, РОСА “ХРОМ” 12 Сервер и SberLinux OS Server.
  - apt install haproxy - для ОС Astra Linux SE.
  - apt-get install haproxy - для ОС Альт Сервер.
- Выполните редактирование конфигурационного файла /etc/haproxy/haproxy.cfg, приведя его к следующему виду:
```
global
  log /var/log/haproxy/log local0
  log /var/log/haproxy/log local1 notice
  chroot /var/lib/haproxy
  stats socket /run/haproxy/admin.sock mode 660 level admin
  stats timeout 30s
  user haproxy
  group haproxy
  daemon
defaults
  log global
  mode http
  option httplog
  option dontlognull
  timeout connect 5000
  timeout client 50000
  timeout server 50000
frontend ft_app
  bind *:443
  mode tcp
  default_backend bk_app
backend bk_app
  mode tcp
  balance source
  hash-type consistent
  server main DOMAINNAME_HOST1:443 check
  server clone DOMAINNAME_HOST2:443 check
listen stats
  bind *:8404
  stats enable
  stats uri /stats
  stats auth admin:password
```
где - DOMAINNAME_HOST1 - доменное имя ВМ1. - DOMAINNAME_HOST2 - доменное имя ВМ2. - admin:password - имя и пароль учетной записи для доступа к панели мониторинга HAProxy.
- Перезапустите HAProxy выполнив следующую команду с правами суперпользователя: systemctl restart haproxy.service.

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

Средствами используемого гипервизора клонируйте ВМ1, тем самым создав ВМР.
Запустите ВМР и дождитесь запуска службы aeca-va.service.

Внимание! В случае, если на ВМ1 для каких-либо Центров валидации были созданы службы OCSP, у которых криптопровайдером является СКЗИ “КриптоПро CSP”, на ВМР необходимо выполнить аналогичную ВМ1 установку СКЗИ “КриптоПро CSP” и подключение внешней гаммы. В случае, если на ВМ1 для каких-либо Центров валидации были созданы службы OCSP, местом хранения закрытого ключа которых является ПАКМ “КриптоПро HSM”, необходимо выполнить на ВМР подключение СКЗИ “КриптоПро CSP” к тому же ПАКМ “КриптоПро HSM”.
Выполните на ВМ4 редактирование конфигурационного файла /etc/haproxy/haproxy.cfg, добавив в секцию backend bk_app информацию о доменном имени ВМР в соответствии с примером, представленном ниже:
```
backend bk_app
mode tcp
balance source
hash-type consistent
server main DOMAINNAME_HOST1:443 check
server clone DOMAINNAME_HOST2:443 check
server clone DOMAINNAME_HOSTR:443 check
```
где IP_VMR - это IP-адрес ВМР.
Перезапустите HAProxy на ВМ4, выполнив следующую команду с правами суперпользователя: systemctl restart haproxy.service.

В результате в кластер будет добавлен дополнительный резервный узел.

В результате выполненной настройки средство балансировки нагрузки HAProxy будет выбирать узел кластера на основе хэш-суммы источника IP-адреса и перенаправлять на него запросы. Это гарантирует, что одни и те же пользователи используют один и тот же узел кластера. Для мониторинга состояния узлов кластера используйте панель мониторинга HAProxy. Для подключения к панели мониторинга введите в адресной строке веб-браузера http:/IP_VM4:8404/stats, где IP_VM4 - IP-адрес ВМ4. Пройдите идентификацию и аутентификацию с помощью имени и пароля учетной записи администратора, указанных при настройка конфигурационного файла.

Внимание! В случае дальнейшего создания Центров валидации со службами OCSP в развернутом в виртуальной инфраструктуре кластере необходимо сохранять соответствие перечня закрытых ключей служб OCSP, хранимых локально и в хранилище HDIMAGE СКЗИ “КриптоПро CSP” и контейнеров закрытого ключа администраторов (для взаимодействия с eCA-CA) на ВМ1, ВМ2 и всех дополнительных резервных узлах. Например, если активным узлом кластера являлся ВМ2, скопируйте созданные закрытые ключи служб OCSP и администраторов с ВМ2 на ВМ1, а затем перезапустите aeca‑va.service на ВМ1. Закрытые ключи служб OCSP, для которых при создании было выбрано место хранения “Локально”, хранятся в каталоге /opt/aecaVa/dist/cryptotoken. При копировании файлов необходимо назначать владельцем данных файлов на конечной ВМ пользователя “aeca”. Закрытые ключи служб OCSP, для которых при их создании было выбрано место хранения “Жесткий диск (HDIMAGE)”, по умолчанию хранятся в каталоге /var/opt/cprocsp/keys/aeca. При копировании файлов необходимо назначать владельцем данных файлов на конечной ВМ пользователя “aeca”, затем перезапускать на данной ВМ СКЗИ “КриптоПро CSP”. Закрытые ключи служб OCSP, для которых при их создании было выбрано место хранения ПАКМ “КриптоПро HSM”, не требуют копирования. Для поддержки работы с такими ключами необходимо сохранять подключение всех узлов кластера к одному ПАКМ “КриптоПро HSM”. Закрытые ключи администраторов для взаимодействия с eCA-CA расположены в каталоге /opt/aecaVa/dist/certificates/account.

Развертывание кластера с горячим резервированием “active-active” путем переноса контейнеров закрытого ключа служб OCSP cпервого узла

Кластер включает следующие узлы:

Сервер с установленным eCA-VA (далее - АРМ1) - первый узел кластера.
Сервер с установленным eCA-VA, на который будет выполнен перенос контейнеров закрытого ключа служб OCSP Центров валидации (далее - АРМ2) - второй узел кластера.
Сервер с установленным eCA-VA, на который будет выполнен перенос контейнеров закрытого ключа служб OCSP Центров валидации (далее - АРМР) - дополнительный узел кластера.
Сервер с установленной и настроенной СУБД (далее - АРМ3).
Сервер с установленным и настроенным средством балансировки нагрузки HAProxy (далее - АРМ4).

На всех указанных выше серверах допускается использование только следующих ОС, определенных требованиями в разделе Требования к программному обеспечению настоящего руководства. Допускается использование одного сервера для реализации АРМ3 и АРМ4.

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

Выполните следующие действия на АРМ3:
- Выполнить установку одной из нижеприведённых СУБД:
  - PostgreSQL из состава ОС
  - Jatoba.
- Увеличьте максимальное количество подключений к СУБД, указав в параметре max_connections значение 2000 ¹² в файле ¹³:
  - /var/lib/pgsql/15/data/postgresql.conf для СУБД PostgreSQL.
  - var/lib/jatoba/[версия]/data/ostgresql.conf для СУБД Jatoba.
- Перезапустите используемую СУБД, выполнив команду с правами суперпользователя:
  - systemctl restart postgresql для СУБД PostgreSQL.
  - systemctl restart jatoba-[версия] для СУБД Jatoba.
Выполните следующие действия на АРМ1:
- Выполните установку eCA-VA с подключением внешней СУБД, установленной на ВМ3 (см. приложение Настройка подключения к внешней СУБД).
- Подключитесь локально к веб-интерфейсу eCA-VA под учетной записью администратора инициализации и выполните подключение к обслуживаемым eCA-CA (см. раздел Добавление подключения к eCA-CA).
- Подключитесь к веб-интерфейсу eCA-VA под учетной записью администратора и создайте для обслуживаемых eCA-CA Центры валидации (см. раздел Создание центра валидации), а при необходимости службы OCSP для них (см. раздел Создание службы OCSP созданного eCA-VA).
На АРМ2 выполните установку eCA-VA с подключением внешней СУБД ¹⁴, установленной на АРМ3 (см. приложение Настройка подключения к внешней СУБД).

Внимание! В случае, если на АРМ1 для каких-либо Центров валидации были созданы службы OCSP, у которых криптопровайдером является СКЗИ “КриптоПро CSP”, на АРМ2 необходимо выполнить аналогичную АРМ1 установку СКЗИ “КриптоПро CSP” и подключение внешней гаммы. В случае, если на АРМ1 для каких-либо Центров валидации были созданы службы OCSP, местом хранения закрытого ключа которых является ПАКМ “КриптоПро HSM”, необходимо выполнить на АРМ2 подключение СКЗИ “КриптоПро CSP” к тому же ПАКМ “КриптоПро HSM”.
Если на АРМ1 была создана служба OCSP, закрытый ключ которой хранится локально, скопируйте с АРМ1 содержимое каталога /opt/aecaVa/dist/cryptotoken в каталог /opt/aecaa/dist/cryptotoken АРМ2.
Если на АРМ1 была создана служба OCSP, закрытый ключ которой расположен в хранилище HDIMAGE СКЗИ “КриптоПро CSP”, скопируйте с АРМ1 контейнер закрытого ключа из каталога /var/opt/cprocsp/keys/aeca в каталог /var/opt/cprocsp/keys/aeca АРМ2. При этом необходимо назначить владельцем данного файла на АРМ2 пользователя “aeca”, и перезапустить на АРМ2 СКЗИ “КриптоПро CSP”.
Скопируйте с АРМ1 содержимое каталога /opt/aecaVa/dist/certificates в каталог /opt/aecaVa/dist/certificates АРМ2.
Если на АРМ2 установлена РЕД ОС, РОСА “ХРОМ” 12 Сервер или SberLinux OS Server, то выполните с правами суперпользователя следующие команды в терминале на АРМ2:
- restorecon -Rv /opt/aecaVa/dist/cryptotoken
- restorecon -Rv /opt/aecaVa/dist/certificates
Выполните на АРМ2 перезапуск aeca-Va.service с перенесёнными контейнерами при помощи команды с правами суперпользователя:
Окно терминала
```
systemctl restart aeca-ca.service
```
На APM4 выполните установку средства балансировки нагрузки HAProxy выполнив следующую команду с правами суперпользователя:
- dnf install haproxy- для РЕД ОС, РОСА “ХРОМ” 12 Сервер и SberLinux OS Server.
- apt install haproxy- для ОС Astra Linux SE.
- apt-get install haproxy- для ОС Альт Сервер.

На АРМ4 выполните редактирование конфигурационного файла /etc/haproxy/haproxy.cfg, приведя его к следующему виду:

global
    log /var/log/haproxy/log local0
    log /var/log/haproxy/log local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    user haproxy
    group haproxy
    daemon
defaults
    log global
    mode http
    option httplog
    option dontlognull
    timeout connect 5000
    timeout client 50000
    timeout server 50000
frontend ft_app
    bind *:443
    mode tcp
    default_backend bk_app
backend bk_app
    mode tcp
    balance source
    hash-type consistent
    server main DOMAINNAME_HOST1:443 check
    server clone DOMAINNAME_HOST2:443 check
listen stats
    bind *:8404
    stats enable
    stats uri /stats
    stats auth admin:password

где:

DOMAINNAME_HOST1 - доменное имя АРМ1.
DOMAINNAME_HOST2 - доменное имя АРМ2.
admin:password - имя и пароль учетной записи, которые будут использоваться для доступа к панели мониторинга HAProxy.

На АРМ4 перезапустите HAProxy выполнив следующую команду с правами суперпользователя:
Окно терминала

В кластер можно подключать дополнительные резервные узлы АРМР. Для подключения нового резервного узла АРМР необходимо выполнить действия, аналогичные действиям по подключения узла АРМ2:

Внимание! В случае, если на АРМ1 для каких-либо Центров валидации были созданы службы OCSP, у которых криптопровайдером является СКЗИ “КриптоПро CSP”, на АРМР необходимо выполнить аналогичную АРМ1 установку СКЗИ “КриптоПро CSP” и подключение внешней гаммы. В случае, если на АРМ1 для каких-либо Центров валидации были созданы службы OCSP, местом хранения закрытого ключа которых является ПАКМ “КриптоПро HSM”, необходимо выполнить на АРМР подключение СКЗИ “КриптоПро CSP” к тому же ПАКМ “КриптоПро HSM”.

backend bk_app
mode tcp
balance source
hash-type consistent
server main DOMAINNAME_HOST1:443 check
server clone DOMAINNAME_HOST2:443 check
server clone DOMAINNAME_HOSTR:443 check

где DOMAINNAME_HOSTR - это доменное АРМР.

Перезапустите на АРМ4 HAProxy выполнив следующую команду с правами суперпользователя:

systemctl restart haproxy.service

В результате в кластере появится дополнительный резервный узел.

В результате выполненной настройки средство балансировки нагрузки HAProxy будет выбирать узел кластера на основе хэш-суммы источника IP-адреса и перенаправлять на него запросы. Это гарантирует, что одни и те же пользователи используют один и тот же узел кластера. Для мониторинга состояния узлов кластера может быть использована панель мониторинга, доступная по адресу http:/IP_ARM4:8404/stats, где IP_ARM4 - IP-адрес АРМ4 (для входа в панель мониторинга потребуется ввод логина и пароля, указанных в файле /etc/haproxy/haproxy.cfg на АРМ4).

Внимание! В случае дальнейшего создания Центров валидации со службами OCSP в развернутом в виртуальной инфраструктуре кластере необходимо сохранять соответствие перечня закрытых ключей служб OCSP, хранимых локально и в хранилище HDIMAGE СКЗИ “КриптоПро CSP” и контейнеров закрытого ключа администраторов (для взаимодействия с eCA-CA) на АРМ1, АРМ2 и всех дополнительных резервных узлах. Например, если активным узлом кластера являлся АРМ2, скопируйте созданные закрытые ключи служб OCSP с АРМ2 на АРМ1, а затем перезапустите aeca‑ca.service на АРМ1. Закрытые ключи служб OCSP, для которых при создании было выбрано место хранения “Локально”, хранятся в каталоге /opt/aecaVa/dist/cryptotoken. При копировании файлов необходимо назначать владельцем данных файлов на конечном АРМ пользователя “aeca”. Закрытые ключи служб OCSP, для которых при их создании было выбрано место хранения “Жесткий диск (HDIMAGE)”, по умолчанию хранятся в каталоге /var/opt/cprocsp/keys/aeca. При копировании файлов необходимо назначать владельцем данных файлов на конечном АРМ пользователя “aeca”, затем перезапускать на данном АРМ СКЗИ “КриптоПро CSP”. Закрытые ключи служб OCSP, для которых при их создании было выбрано место хранения ПАКМ “КриптоПро HSM”, не требуют копирования. Для поддержки работы с такими ключами необходимо сохранять подключение всех узлов кластера к одному ПАКМ “КриптоПро HSM”. Закрытые ключи администраторов для взаимодействия с eCA-CA расположены в каталоге /opt/aecaVa/dist/certificates/account.

Обновление ПО узлов кластера

Процесс обновления кластера eCA-VA:

Выполните резервное копирование данных на всех узлах кластера (см. раздел Резервное копирование и восстановление данных).
Для кластера по схеме “active-passive” на всех резервных узлах выполните остановку службы eCA-VA выполнив следующую команду с правами суперпользователя: systemctl stop aeca-va.service.
Для кластера по схеме “active-active” на всех узлах, на которые были перенесены закрытые ключи служб OCSP и администраторов, выполните остановку службы eCA-VA выполнив следующую команду с правами суперпользователя: systemctl stop aeca-va.service.
Для кластера по схеме “active-passive” выполнить обновление ПО eCA-VA на основном узле (см. раздел Обновление программы).
Для кластера по схеме “active-active” выполнить обновление ПО eCA-VA на узле, на котором расположены закрытые ключи служб OCSP и администраторов (см. раздел Обновление программы).
Вне зависимости от схемы кластера выполните обновление ПО eCA-VA на всех остальных узлах кластера (см. раздел Обновление программы).

Критерием правильности установки обновления ПО кластера является отображение информации о новой версии в окне “О программе” веб-интерфейса и работоспособность всех узлов кластера. Работоспособность узлов можно посмотреть в панели мониторинга HAproxy, доступной по адресу http:/IP_ARM4:8404/stats, где IP_ARM4 - IP-адрес АРМ4 (для входа в панель мониторинга потребуется ввод логина и пароля, указанных в файле /etc/haproxy/haproxy.cfg).

Серверное программное обеспечение для обеспечения высокой доступности и балансировки нагрузки для TCP- и HTTP-приложений посредством распределения входящих запросов на несколько обслуживающих серверов ↩
Это конфигурация отказоустойчивых кластеров, в которой одни узлы назначаются активными, а другие - резервными, готовыми взять на себя работу в случае отказа активного узла. ↩
Это архитектурный подход построения кластера, при котором оба или все узлы активны и работают одновременно, обрабатывая запросы и трафик. ↩
Это режим, при котором балансировщик выбирает узел кластера на основе хэш-суммы источника IP-адреса, с которого клиенты отправляют запросы. Это гарантирует, что одни и те же пользователи используют один и тот же узел кластера. ↩
Значение 2000 указано из необходимости наличия 1000 подключений для каждого экземпляра eCA-VA, взаимодействующего с СУБД. ↩
Путь к файлу может отличаться в зависимости от версии PostgreSQL или Jatoba. ↩
Значение 2000 указано из необходимости наличия 1000 подключений для каждого экземпляра eCA-VA, взаимодействующего с СУБД. ↩
Путь к файлу может отличаться в зависимости от версии PostgreSQL или Jatoba. ↩
В конфигурационном файле на АРМ2 необходимо указывать параметры СУБД, аналогичные указанным СУБД АРМ1. ↩
Значение 2000 указано из необходимости наличия 1000 подключений для каждого экземпляра eCA-VA, взаимодействующего с СУБД. ↩
Путь к файлу может отличаться в зависимости от версии PostgreSQL или Jatoba. ↩
Значение 200 указано из необходимости наличия 1000 подключений для каждого экземпляра eCA-VA, взаимодействующего с СУБД. ↩
Путь к файлу может отличаться в зависимости от версии PostgreSQL или Jatoba. ↩
В конфигурационном файле на АРМ2 необходимо указывать параметры СУБД, аналогичные указанным СУБД АРМ1. ↩

4.4.3. Развёртывание кластера eCA-VA

Развертывание кластера в виртуальной среде с холодным резервированием “active-passive”

Развертывание кластера с холодным резервированием “active-passive” путем переноса контейнеров закрытого ключа служб OCSP основного узла

Развертывания кластера в виртуальной среде с горячим резервированием “active-active”

Развертывание кластера с горячим резервированием “active-active” путем переноса контейнеров закрытого ключа служб OCSP cпервого узла

Обновление ПО узлов кластера

Footnotes