Перейти к содержимому
Аладдин Р.Д.Аладдин Р.Д.Аладдин Р.Д.

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

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

Раздел: Отказоустойчивое (кластерное) исполнение. Материалы по компонентам.

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

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

  • В виртуальной инфраструктуре путём клонирования виртуальной машины основного узла.

  • С помощью переноса контейнеров закрытого ключа основного узла.

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

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

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

  • Виртуальная машина с установленным и инициализированным eCA-CA (далее - ВМ1) - основной узел кластера.

  • Клон ВМ1, созданный сразу после завершения инициализации на ВМ1 eCA-CA (далее - ВМ2) - резервный узел кластера.

  • Виртуальная машина с установленной и настроенной СУБД (далее - ВМ3).

  • Виртуальная машина с установленным и настроенным средством балансировки нагрузки HAProxy (далее - ВМ4).

  • Клон ВМ1, созданный при необходимости при эксплуатации кластера (далее - ВМР) – дополнительный резервный узел кластера.

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

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

  • Выполните следующие действия на ВМ3:

    • Выполнить установку одной из нижеприведённых СУБД:

      • PostgreSQL из состава ОС

      • Jatoba.

    • Увеличьте максимальное количество подключений к СУБД, указав в параметре max_connections значение 2000 5 в файле 6:

      • /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-CA (см. Установка программы) с подключением внешней СУБД, установленной на ВМ3 (см. приложение Настройка подключения к внешней СУБД).

    • Подключитесь к веб-интерфейсу eCA-CA под учётной записью администратора инициализации технологического центра сертификации.

    • Выполните первичное лицензирование eCA-CA (см. документ “Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition. Руководство администратора. Часть 2. Функции управления Центра сертификации Aladdin Enterprise Certification Authority”).

    • Выполните инициализацию Центра сертификации (см. документ “Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition. Руководство администратора. Часть 2. Функции управления Центра сертификации Aladdin Enterprise Certification Authority”).

  • Средствами используемого гипервизора клонируйте ВМ1, тем самым создав ВМ2.

  • Запустите ВМ2 и дождитесь завершения запуска службы aeca-ca.service.

    Внимание! В случае, если на ВМ1 был создан Центр сертификации, у которого криптопровайдером какого-либо алгоритма является СКЗИ “КриптоПро CSP”, на ВМ2 необходимо выполнить аналогичную ВМ1 установку СКЗИ “КриптоПро CSP” и подключение внешней гаммы. В случае, если на ВМ1 был создан Центр сертификации, местом хранения закрытого ключа которого является ПАКМ “КриптоПро 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 IP_VM1:443 check
      server clone IP_VM2:443 check backup
      listen stats
      bind *:8404
      stats enable
      stats uri /stats
      stats auth admin:password

      где:

      • IP_VM1 – IP-адрес ВМ1.
      • IP_VM2 – IP-адрес ВМ2.
      • admin:password – имя и пароль учётной записи для доступа к панели мониторинга HAProxy.

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

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

  • Средствами используемого гипервизора клонируйте ВМ1, тем самым создав ВМР.

  • Запустите ВМР и дождитесь запуска службы aeca-ca.service.

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

  • Выполните следующие действия на ВМ4:

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

      backend bk_app
      mode tcp
      server main IP_VM1:443 check
      server clone IP_VM2:443 check backup
      server clone IP_VMR:443 check backup

      где IP_VMR - это IP-адрес ВМР.

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

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

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

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

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

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

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

  • Сервер с установленным и инициализированным eCA-CA (далее - АРМ1) - основной узел кластера.

  • Сервер с установленным и инициализированным eCA-CA, на который будет выполнен перенос контейнера закрытого ключа (далее - АРМ2) - резервный узел кластера.

  • Сервер с установленным и инициализированным eCA-CA, на который будет выполнен перенос контейнера закрытого ключа (далее - АРМР) – дополнительный резервный узел кластера.

  • Сервер с установленной и настроенной СУБД (далее - АРМ3).

  • Сервер с установленным и настроенным средством балансировки нагрузки HAProxy (далее - АРМ4).

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

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

  • Выполните следующие действия на АРМ3:

    • Выполнить установку одной из нижеприведённых СУБД:

      • PostgreSQL из состава ОС

      • Jatoba.

    • Увеличьте максимальное количество подключений к СУБД, указав в параметре max_connections значение 20007 в файле 8:

      • /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-CA (см. Установка программы) с подключением внешней СУБД, установленной на ВМ3 (см. приложение Настройка подключения к внешней СУБД).

    • Подключитесь к веб-интерфейсу eCA-CA под учётной записью администратора инициализации технологического центра сертификации.

    • Выполните первичное лицензирование eCA-CA (см. документ “Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition. Руководство администратора. Часть 2. Функции управления Центра сертификации Aladdin Enterprise Certification Authority”).

    • Выполните инициализацию Центра сертификации (см. документ “Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition. Руководство администратора. Часть 2. Функции управления Центра сертификации Aladdin Enterprise Certification Authority”).

  • На АРМ2 выполните установку eCA-CA (см. Установка программы) с подключением внешней СУБД 9, установленной на АРМ3 (см. Настройка подключения к внешней СУБД).

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

  • Если на АРМ1 был создан Центр сертификации, закрытый ключ которого хранится локально, скопируйте с АРМ1 содержимое каталога /opt/aecaCa/dist/cryptotoken в каталог /opt/aecaCa/dist/cryptotoken АРМ2.

  • Если на АРМ1 был создан Центр сертификации, закрытый ключ которого расположен в хранилище HDIMAGE СКЗИ “КриптоПро CSP”, скопируйте с АРМ1 контейнер Центра сертификации (имя файла будет соответствовать первым 8 символам идентификатора Центра сертификации) из каталога /var/opt/cprocsp/keys/aeca в каталог /var/opt/cprocsp/keys/aeca АРМ2. При этом необходимо назначить владельцем данного файла на АРМ2 пользователя “aeca”, и перезапустить на АРМ2 СКЗИ “КриптоПро CSP”.

  • Скопируйте с АРМ1 содержимое каталога /opt/aecaCa/dist/certificates в каталог /opt/aecaCa/dist/certificates АРМ2.

  • Если на АРМ2 установлена РЕД ОС, РОСА “ХРОМ” 12 Сервер или SberLinux OS Server, то выполните с правами суперпользователя следующие команды в терминале на АРМ2:

    Окно терминала
    restorecon -Rv /opt/aecaCa/dist/cryptotoken
    restorecon -Rv /opt/aecaCa/dist/certificates

  • Выполните на АРМ2 перезапуск aeca-ca.service для обеспечения работы Центра сертификации с перенесёнными контейнерами выполнив с правами суперпользователя следующую команду:

    Окно терминала
    systemctl restart aeca-ca.service

  • Выполните следующие действия на ВМ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 IP_ARM1:443 check
      server clone IP_ARM2:443 check backup
      listen stats
      bind *:8404
      stats enable
      stats uri /stats
      stats auth admin:password

      где:

      • IP_ARM1 – IP-адрес АРМ1.
      • IP_ARM2 – IP-адрес АРМ2.
      • admin:password – имя и пароль учётной записи администратора для доступа к панели мониторинга HAProxy.

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

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

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

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

backend bk_app
mode tcp
server main IP_ARM1:443 check
server clone IP_ARM2:443 check backup
server clone IP_ARMR:443 check backup

где IP_ARMR - это IP-адрес АРМР.

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

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

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

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

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

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

  • Виртуальная машина с установленным и инициализированным eCA-CA (далее - ВМ1) - первый узел кластера.

  • Клон ВМ1, созданный сразу после завершения инициализации на ВМ1 eCA-CA (далее - ВМ2) - второй узел кластера.

  • Клон ВМ1, созданный при необходимости при эксплуатации кластера (далее - ВМР) - дополнительный узел кластера.

  • Виртуальная машина с установленной и настроенной СУБД (далее - ВМ3).

  • Виртуальная машина с установленным и настроенным средством балансировки нагрузки HAProxy (далее - ВМ4).

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

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

  • Выполните следующие действия на ВМ3:

    • Выполнить установку одной из нижеприведённых СУБД:

      • PostgreSQL из состава ОС

      • Jatoba.

    • Увеличьте максимальное количество подключений к СУБД, указав в параметре max_connections значение 200010 в файле 11:

      • /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-CA (см. Установка программы) с подключением внешней СУБД, установленной на ВМ3 (см. Настройка подключения к внешней СУБД).

    • Подключитесь к веб-интерфейсу eCA-CA под учётной записью администратора инициализации технологического центра сертификации.

    • Выполните первичное лицензирование eCA-CA (см. документ “Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition. Руководство администратора. Часть 2. Функции управления Центра сертификации Aladdin Enterprise Certification Authority”).

    • Выполните инициализацию Центра сертификации (см. документ “Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition. Руководство администратора. Часть 2. Функции управления Центра сертификации Aladdin Enterprise Certification Authority”).

  • Средствами используемого гипервизора клонируйте ВМ1, тем самым создав ВМ2.

  • Запустите ВМ2 и дождитесь завершения запуска службы aeca-ca.service.

Внимание! В случае, если на ВМ1 был создан Центр сертификации, у которого криптопровайдером какого-либо алгоритма является СКЗИ “КриптоПро CSP”, на ВМ2 необходимо выполнить аналогичную ВМ1 установку СКЗИ “КриптоПро CSP” и подключение внешней гаммы. В случае, если на ВМ1 был создан Центр сертификации, местом хранения закрытого ключа которого является ПАКМ “КриптоПро 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 IP_VM1:443 check
      server clone IP_VM2:443 check
      listen stats
      bind *:8404
      stats enable
      stats uri /stats
      stats auth admin:password

      где:

      • IP_VM1 – IP-адрес ВМ1.
      • IP_VM2 – IP-адрес ВМ2.
      • admin:password – имя и пароль учётной записи для доступа к панели мониторинга HAProxy.

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

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

  • Средствами используемого гипервизора клонируйте ВМ1, тем самым создав ВМР.

  • Запустите ВМР и дождитесь запуска службы aeca-ca.service.

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

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

    backend bk_app
    mode tcp
    balance source
    hash-type consistent
    server main IP_VM1:443 check
    server clone IP_VM2:443 check
    server clone IP_VMR:443 check

    где IP_VMR - это IP-адрес ВМР.

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

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

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

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

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

Заголовок раздела «Развёртывание кластера с горячим резервированием “active-active” путём переноса контейнера закрытого ключа первого узла»

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

  • Сервер с установленным и инициализированным eCA-CA (далее - АРМ1) – первый узел кластера.

  • Сервер с установленным и инициализированным eCA-CA, для которого будет выполнен перенос контейнеров закрытого ключа (далее - АРМ2) – второй узел кластера.

  • Сервер с установленным и инициализированным eCA-CA, для которого будет выполнен перенос контейнеров закрытого ключа (далее - АРМР) – дополнительный узел кластера.

  • Сервер с установленной и настроенной СУБД (далее - АРМ3).

  • Сервер с установленным и настроенным средством балансировки нагрузки HAProxy (далее - АРМ4).

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

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

  • Выполните следующие действия на АРМ3:

    • Выполнить установку одной из нижеприведённых СУБД:

      • PostgreSQL из состава ОС

      • Jatoba.

    • Увеличьте максимальное количество подключений к СУБД, указав в параметре max_connections значение 2000 12 в файле 13:

      • /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-CA (см. Установка программы) с подключением внешней СУБД, установленной на АРМ3 (см.  Настройка подключения к внешней СУБД).

    • Подключитесь к веб-интерфейсу eCA-CA под учётной записью администратора инициализации технологического центра сертификации.

    • Выполните первичное лицензирование eCA-CA (см. документ “Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition. Руководство администратора. Часть 2. Функции управления Центра сертификации Aladdin Enterprise Certification Authority”).

    • Выполните инициализацию Центра сертификации (см. документ “Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition. Руководство администратора. Часть 2. Функции управления Центра сертификации Aladdin Enterprise Certification Authority”).

  • На АРМ2 выполните установку eCA-CA (см. Установка программы) с подключением внешней СУБД 14, установленной на АРМ3 (см. Настройка подключения к внешней СУБД).

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

  • Если на АРМ1 был создан Центр сертификации, закрытый ключ которого хранится локально, скопируйте с АРМ1 содержимое каталога /opt/aecaCa/dist/cryptotoken в каталог /opt/aecaCa/dist/cryptotoken АРМ2.

  • Если на АРМ1 был создан Центр сертификации, закрытый ключ которого расположен в хранилище HDIMAGE СКЗИ “КриптоПро CSP”, скопируйте с АРМ1 контейнер Центра сертификации (имя файла будет соответствовать первым 8 символам идентификатора Центра сертификации) из каталога /var/opt/cprocsp/keys/aeca в каталог /var/opt/cprocsp/keys/aeca АРМ2. При этом необходимо назначить владельцем данного файла на АРМ2 пользователя “aeca”, и перезапустить на АРМ2 СКЗИ “КриптоПро CSP”.

  • Скопируйте с АРМ1 содержимое каталога /opt/aecaCa/dist/certificates в каталог /opt/aecaCa/dist/certificates АРМ2.

  • Если на АРМ2 установлена РЕД ОС, РОСА “ХРОМ” 12 Сервер или SberLinux OS Server, то выполните с правами суперпользователя следующие команды в терминале на АРМ2:

    Окно терминала
    restorecon -Rv /opt/aecaCa/dist/cryptotoken
    restorecon -Rv /opt/aecaCa/dist/certificates

  • Выполните на АРМ2 перезапуск aeca-ca.service для обеспечения работы Центра сертификации с перенесенными контейнерами выполнив с правами суперпользователя следующую команду:

    Окно терминала
    systemctl restart aeca-ca.service

  • Выполните следующие действия на АРМ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 IP_VM1:443 check
      server clone IP_VM2:443 check
      listen stats
      bind *:8404
      stats enable
      stats uri /stats
      stats auth admin:password

      где:

      • IP_ARM1 – IP-адрес АРМ1.
      • IP_ARM2 – IP-адрес АРМ2.
      • admin:password – имя и пароль учётной записи для доступа к панели мониторинга HAProxy.

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

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

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

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

backend bk_app
mode tcp
balance source
hash-type consistent
server main IP_ARM1:443 check
server clone IP_ARM2:443 check
server clone IP_ARMR:443 check

где IP_ARMR - это IP-адрес АРМР.

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

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

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

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

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

Заголовок раздела «4.3 Обновление ПО узлов кластера eCA-CA»

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

  • Выполните резервное копирование данных на всех узлах кластера (см. раздел Резервное копирование и восстановление данных).

  • Для кластера по схеме “active-passive” на всех резервных узлах произведите остановку службы eCA-CA выполнив следующую команду с правами суперпользователя: systemctl stop aeca-ca.service.

  • Для кластера по схеме “active-active” на всех узлах, на которые был перенесён закрытый ключ, произведите остановку службы eCA-CA выполнив следующую команду с правами суперпользователя: systemctl stop aeca-ca.service.

  • Для кластера по схеме “active-passive” выполнить обновление ПО eCA-CA на основном узле (см. раздел Обновление программы).

  • Для кластера по схеме “active-active” выполнить обновление ПО eCA-CA на узле, на котором был создан закрытый ключ (см. раздел Обновление программы).

  • Вне зависимости от схемы кластера выполните обновление ПО eCA-CA на всех остальных узлах кластера (см. раздел Обновление программы).

Критерием правильности установки обновления ПО кластера является отображение информации о новой версии в окне “О программе” веб-интерфейса и работоспособность всех узлов кластера. Работоспособность узлов можно посмотреть в панели мониторинга HAproxy. Для подключения к панели мониторинга введите в адресной строке веб-браузера http:/IP_Haproxy:8404/stats (где IP_Haproxy - IP-адрес ВМ4 или АРМ4) и пройдите идентификацию и аутентификацию с помощью имени и пароля учётной записи, указанных при настройка конфигурационного файла HAProxy.

Footnotes

Заголовок раздела «Footnotes»

  1.  Серверное программное обеспечение для обеспечения высокой доступности и балансировки нагрузки для TCP- и HTTP-приложений посредством распределения входящих запросов на несколько обслуживающих серверов. ↩

  2.  Это конфигурация отказоустойчивых кластеров, в которой одни узлы назначаются активными, а другие — резервными, готовыми взять на себя работу в случае отказа активного узла. ↩

  3.  Это архитектурный подход построения кластера, при котором оба или все узлы активны и работают одновременно, обрабатывая запросы и трафик. ↩

  4.  Это режим, при котором балансировщик выбирает узел кластера на основе хэш-суммы источника IP-адреса, с которого клиенты отправляют запросы. Это гарантирует, что одни и те же пользователи используют один и тот же узел кластера. ↩

  5.  Значение 2000 указано из необходимости наличия 1000 подключений для каждого экземпляра eCA-CA, взаимодействующего с СУБД. ↩

  6.  Путь к файлу может отличаться в зависимости от версии PostgreSQL или Jatoba. ↩

  7.  Значение 2000 указано из необходимости наличия 1000 подключений для каждого экземпляра eCA-CA, взаимодействующего с СУБД. ↩

  8.  Путь к файлу может отличаться в зависимости от версии PostgreSQL или Jatoba. ↩

  9.  В конфигурационном файле eCA-CA на АРМ2 необходимо указывать параметры СУБД, аналогичные указанным СУБД АРМ1. ↩

  10.  Значение 2000 указано из необходимости наличия 1000 подключений для каждого экземпляра eCA-CA, взаимодействующего с СУБД. ↩

  11.  Путь к файлу может отличаться в зависимости от версии PostgreSQL или Jatoba. ↩

  12.  Значение 2000 указано из необходимости наличия 1000 подключений для каждого экземпляра eCA-CA, взаимодействующего с СУБД. ↩

  13.  Путь к файлу может отличаться в зависимости от версии PostgreSQL или Jatoba. ↩

  14.  В конфигурационном файле eCA-CA на АРМ2 необходимо указывать параметры СУБД, аналогичные указанным СУБД АРМ1. ↩