Программное обеспечение «Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition» обеспечивает возможность кластеризации c использованием внешнего средства балансирования нагрузки.

Доступны следующие варианты развертывания кластера Aladdin eCA:

  • развертывание кластера в виртуальной инфраструктуре, порядок которого представлен в разделе 4.1 ниже;
  • развертывание кластера с помощью переноса контейнеров закрытого ключа основного узла, порядок которого представлен в разделе 4.2 ниже.

Развертывание кластера Aladdin eCA в виртуальной инфраструктуре

Кластер конфигурируется по схеме «Active‑Passive Failover», куда входят следующие узлы:

    • виртуальная машина с установленным и инициализированным программным обеспечением «Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition» (ВМ1) – основной узел кластера;
    • клон виртуальной машины ВМ1, созданный сразу после завершения инициализации на ВМ1 программного обеспечения «Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition» (ВМ2) – резервный узел кластера[1];
    • виртуальная машина с установленной и настроенной СУБД (ВМ3);
    • виртуальная машина с установленным и настроенным средством балансирования нагрузки HAProxy (ВМ4).

На всех указанных выше виртуальных машинах допускается использование только следующих ОС:

    • Astra Linux Special Edition версия 1.7, уровень защищённости «Смоленск»;
    • Astra Linux Special Edition версия 1.7, уровень защищённости «Воронеж»;
    • Astra Linux Special Edition версия 1.7, уровень защищённости «Орел»;
    • Astra Linux Special Edition версия 1.8, уровень защищённости «Смоленск»;
    • Astra Linux Special Edition версия 1.8, уровень защищённости «Воронеж»;
    • Astra Linux Special Edition версия 1.8, уровень защищённости «Орел»;
    • РЕД ОС версия 7.3, сертифицированная редакция, конфигурация «Сервер»;
    • РЕД ОС версия 8, конфигурация «Сервер»;
    • ОС Альт 8 СП, релиз 10, вариант исполнения Сервер.

Допускается использование единой виртуальной машины для реализации ВМ3 и ВМ4.

  1. На ВМ3 выполнить установку одной из нижеприведённых систем управления базами данных[2]:
    • PostgreSQL из состава ОС;
    • Jatoba 4.

      2. На ВМ3 увеличить максимальное количество подключений к СУБД, отредактировав файл /var/lib/pgsql/15/data/postgresql.conf (или var/lib/jatoba/4/data/postgresql.conf, если используется СУБД Jatoba)[3], указав для параметра max_connections значение 2000[4]:

max_connections = 2000

      3. На ВМ3 перезапустить используемую СУБД, выполнив команду sudo systemctl restart postgresql (или sudo systemctl restart jatoba‑[версия] если используется СУБД Jatoba).

      4. На ВМ1 выполнить установку программного обеспечения «Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition» в соответствии с разделом 5 настоящего руководства, при этом подключив к Aladdin eCA внешнюю СУБД, установленную на ВМ3, в соответствии c «Приложение 2. Настройка подключения к внешней СУБД» настоящего руководства.

      5. На ВМ1 выполнить первичную настройку программного обеспечения «Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition» в соответствии разделом 6 настоящего документа.

      6. На ВМ1 выполнить первичное лицензирование в соответствии с разделом 2.1 эксплуатационного документа «Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition. Руководство администратора. Часть 2. Функции управления Центра сертификации Aladdin Enterprise Certification Authority» RU.АЛДЕ.03.01.020 32 01‑2.

      7. На ВМ1 выполнить создание центра сертификации в соответствии с разделом 3.1 эксплуатационного документа «Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition. Руководство администратора. Часть 2. Функции управления Центра сертификации Aladdin Enterprise Certification Authority» RU.АЛДЕ.03.01.020 32 01‑2.

      8. Средствами используемого гипервизора клонировать ВМ1 (клон ВМ1 далее по тексту обозначены «ВМ2»).

      9. Запустить ВМ2 и ожидать завершения запуска aeca‑ca.service на ВМ2.

В случае создания на ВМ1 Центра сертификации, закрытый ключ которого хранится на КриптоПро HSM, необходимо после запуска ВМ2 восстановить ее подключение к КриптоПро HSM и перезапустить aeca‑ca.service.

     10. На ВМ4 выполнить установку средства балансирования нагрузки HAProxy:

РЕД ОС[5]

sudo dnf install haproxy  

Astra Linux SE

sudo apt install haproxy  

Альт Сервер

sudo apt‑get install haproxy

     11. На ВМ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 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.

      12. На ВМ4 перезапустить HAProxy путем запуска команды sudo systemctl restart haproxy.service

В результате приведенной настройки кластера все запросы, направляемые к Aladdin eCA через средство балансирования нагрузки HAProxy, будут перенаправляться на основной узел кластера (ВМ1). В случае недоступности основного узла кластера все запросы, направляемые к Aladdin eCA через средство балансирования нагрузки HAProxy, будут перенаправляться на резервный узел кластера (ВМ2). Для мониторинга состояния узлов кластера может быть использована панель мониторинга, доступная по адресу http://IP_VM4:8404/stats, где IP_VM4 – IP‑адрес ВМ4 (для входа в панель мониторинга потребуется ввод логина и пароля, указанных в файле /etc/haproxy/haproxy.cfg на ВМ4).

В случае дальнейшего создания Центров сертификации в развернутом в виртуальной инфраструктуре кластере необходимо сохранять соответствие перечня закрытых ключей, хранимых локально и в хранилище КриптоПро 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».

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

  1. Средствами используемого гипервизора клонировать ВМ1 (клон далее по тексту «ВМР»).

      2. Запустить ВМР и дождаться запуска aeca‑ca.service на ней.

      3. На ВМ4 отредактировать файл /etc/haproxy/haproxy.cfg– внести в него IP‑адрес ВМР в секцию backend bk_app под строкой, соответствующей последнему резервному узлу. Если последний резервный узел – это ВМ2, то это под строкой: server clone IP_VM2:443 check backup). Таким образом должна получиться секция вида:

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‑адрес ВМР.

      4. На ВМ4 перезапустить HAProxy путем запуска команды sudo systemctl restart haproxy.service.

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

[1] ВМ2 создается в ходе развертывания кластера Aladdin eCA в виртуальной инфраструктуре путем клонирования ВМ1 на шаге 8

[2] Справочная информация по установке и настройке СУБД приведена в разделах  для РЕД ОС,  для Astra Linux и 4.5.2 для Альт Сервер настоящего руководства

[3] Путь к файлу может отличаться в зависимости от версии PostgreSQL или Jatoba

[4] Значение 200 указано из необходимости наличия 1000 подключений для каждого экземпляра программного обеспечения «[Категория] [Тема]», взаимодействующего с СУБД

[5] При установке HAProxy на РЕД ОС необходимо выполнить отключение SELinux в соответствии с официальной документацией ОС:

Развертывание кластера Aladdin eCA с помощью переноса контейнеров закрытого ключа основного узла

Кластер конфигурируется по схеме «Active‑Passive Failover», куда входят следующие узлы:

    • сервер с установленным и инициализированным программным обеспечением «Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition» (АРМ1) – основной узел кластера;
    • сервер с установленным и инициализированным программным обеспечением «Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition», для которого будет выполнен перенос контейнеров закрытого ключа (АРМ2) – резервный узел кластера;
    • сервер с установленной и настроенной СУБД (АРМ3);
    • сервер с установленным и настроенным средством балансирования нагрузки HAProxy (АРМ4).

На всех указанных выше серверах допускается использование только следующих ОС:

    • Astra Linux Special Edition версия 1.7, уровень защищённости «Смоленск»;
    • Astra Linux Special Edition версия 1.7, уровень защищённости «Воронеж»;
    • Astra Linux Special Edition версия 1.7, уровень защищённости «Орел»;
    • Astra Linux Special Edition версия 1.8, уровень защищённости «Смоленск»;
    • Astra Linux Special Edition версия 1.8, уровень защищённости «Воронеж»;
    • Astra Linux Special Edition версия 1.8, уровень защищённости «Орел»;
    • РЕД ОС версия 7.3, сертифицированная редакция, конфигурация «Сервер»;
    • РЕД ОС версия 8, конфигурация «Сервер»;
    • ОС Альт 8 СП, релиз 10, вариант исполнения Сервер.

Допускается использование одного сервера для реализации АРМ3 и АРМ4.

  1. На АРМ3 выполнить установку одной из нижеприведённых систем управления базами данных[1]:
    • PostgreSQL из состава ОС;
    • Jatoba 4.

      2. На АРМ3 увеличить максимальное количество подключений к СУБД, отредактировав файл /var/lib/pgsql/15/data/postgresql.conf (или var/lib/jatoba/4/data/postgresql.conf, если используется СУБД Jatoba)[2], указав для параметра max_connections значение 2000[3]:

max_connections = 2000

      3. На АРМ3 перезапустить используемую СУБД, выполнив команду sudo systemctl restart postgresql (или sudo systemctl restart jatoba‑[версия] если используется СУБД Jatoba).

      4. На АРМ1 выполнить установку программного обеспечения «Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition» в соответствии с разделом 5 настоящего руководства, при этом подключив к Aladdin eCA внешнюю СУБД, установленную на АРМ3, в соответствии c «Приложение 2. Настройка подключения к внешней СУБД» настоящего руководства.

      5. На АРМ1 выполнить первичную настройку программного обеспечения «Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition» в соответствии разделом 6 настоящего документа.

      6. На АРМ1 выполнить первичное лицензирование в соответствии с разделом 2.1 эксплуатационного документа «Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition. Руководство администратора. Часть 2. Функции управления Центра сертификации Aladdin Enterprise Certification Authority» RU.АЛДЕ.03.01.020 32 01‑2.

      7. На АРМ1 выполнить создание центра сертификации в соответствии с разделом 3.1 эксплуатационного документа «Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition. Руководство администратора. Часть 2. Функции управления Центра сертификации Aladdin Enterprise Certification Authority» RU.АЛДЕ.03.01.020 32 01‑2.

     8. На АРМ2 выполнить установку программного обеспечения «Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition» в соответствии с разделом 5 настоящего руководства, при этом подключив[4] к Aladdin eCA внешнюю СУБД, установленную на АРМ3, в соответствии c «Приложение 2. Настройка подключения к внешней СУБД» настоящего руководства.

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

В случае, если на АРМ1 был создан Центр сертификации, местом хранения закрытого ключа которого является ПАКМ «КриптоПро HSM», необходимо выполнить на АРМ2 подключение КриптоПро CSP к тому же ПАКМ «КриптоПро HSM».

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

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

      10. На АРМ1 скопировать содержимое каталога /opt/aecaCa/dist/certificates и заменить им содержимое каталога /opt/aecaCa/dist/certificates на АРМ2.

      11. В случае, если в качестве ОС на АРМ2 используется «РЕД ОС версия 7.3, сертифицированная редакция, конфигурация «Сервер» или «РЕД ОС версия 8, конфигурация «Сервер», необходимо выполнить следующие команды в терминале на АРМ2:

sudo restorecon ‑Rv /opt/aecaCa/dist/cryptotoken
 
sudo restorecon ‑Rv /opt/aecaCa/dist/certificates

      12. Произвести на АРМ2 перезапуск сервиса для обеспечения работы ЦС с перенесенными контейнерами. Перезапуск производится посредством команды

sudo systemctl restart aeca‑ca.service

      13. На APM4 выполнить установку средства балансирования нагрузки HAProxy:

РЕД ОС[5]

sudo dnf install haproxy  

Astra Linux SE

sudo apt install haproxy  

Альт Сервер

sudo apt‑get install haproxy

      14. На АРМ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 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.

      15. На АРМ4 перезапустить HAProxy путем запуска команды sudo systemctl restart haproxy.service

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

В случае дальнейшего создания Центров сертификации в развернутом кластере необходимо сохранять соответствие перечня закрытых ключей, хранимых локально и в хранилище КриптоПро 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».

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

  1. Выполнить для АРМР действия, производимые для АРМ2 в пунктах 8, 9, 10, 11, 12 выше данного раздела (при их выполнении вместо АРМ2 использовать АРМР).

      2. На АРМ4 отредактировать файл /etc/haproxy/haproxy.cfg– внести в него IP‑адрес АРМР в секцию backend bk_app под строкой, соответствующей последнему резервному узлу. Если последний резервный узел – это АРМ2, то это под строкой: server clone IP_ARM2:443 check backup). Таким образом должна получиться секция вида:

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‑адрес АРМР.           

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

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

[1] Справочная информация по установке и настройке СУБД приведена в разделах  для РЕД ОС,  для Astra Linux и 4.5.2 для Альт Сервер настоящего руководства

[2] Путь к файлу может отличаться в зависимости от версии PostgreSQL или Jatoba

[3] Значение 200 указано из необходимости наличия 1000 подключений для каждого экземпляра программного обеспечения «[Категория] [Тема]», взаимодействующего с СУБД

[4] В конфигурационном файле Aladdin eCA на АРМ2 необходимо указывать параметры СУБД, аналогичные указанным на шаге 5

[5] При установке HAProxy на РЕД ОС необходимо выполнить отключение SELinux в соответствии с официальной документацией ОС:

Обновление программных компонент Aladdin eCA узлов кластера Aladdin eCA

Обновление кластера Aladdin eCA включает в себя предварительную приемку программного компонента Aladdin eCA, который будет устанавливаться на узлы кластера, остановку работающих программных компонент Aladdin eCA на узлах кластера и выполнение последовательного обновления программных компонент Aladdin eCA на каждом узле кластера.

Обновление производится для кластера Aladdin eCA, сконфигурированного по схемам, описанных в подразделах 4.1 и 4.2 настоящего Приложения.

В кластер Aladdin eCA входят следующие узлы:

  • сервер с установленным и инициализированным программным обеспечением «Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition» (АРМ1) – основной узел кластера;
  • сервера с установленным и инициализированным программным обеспечением «Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition» (АРМ2‑узлы) – резервные узлы кластера:
    • это либо клоны сервера АРМ1, созданные сразу после завершения инициализации на АРМ1 (подраздел 4.1 настоящего Приложения);
    • либо сервера, для которого выполнен перенос контейнеров закрытого ключа с АРМ1 (подраздел 4.2 настоящего приложения).
  • сервер с установленной и настроенной СУБД (АРМ3);
  • сервер с установленным и настроенным средством балансирования нагрузки HAProxy (АРМ4).

Обновления программных компонент Aladdin eCA узлов кластера Aladdin eCA включает в себя:

    • обновление программного компонента Aladdin eCA на основном узле кластера (АРМ1);
    • обновление программного компонента Aladdin eCA на резервных узлах кластера (АРМ2‑узлах).

Номер сборки устанавливаемых программных компонент Aladdin eCA должен быть одинаковым для основного и резервных узлов кластера.

Иначе программные компоненты Aladdin eCA на узлах кластера не могут быть запущены[1].

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

  • Предварительно произвести действия по приёмке программного компонента Aladdin eCA в соответствии с разделом 3 настоящего руководства;
  • На АРМ1‑узле произвести резервное копирование данных программного компонент Aladdin eCA в соответствии с разделом 10 настоящего документа для возможности восстановить данные в случае неисправности;
  • На АРМ2‑узлах произвести резервное копирование данных программного компонент Aladdin eCA в соответствии с разделом 10 настоящего документа для возможности восстановить данные в случае неисправности;
  • На АРМ2‑узлах произвести остановку программного компонента Aladdin eCA путем выполнения команды sudo systemctl stop aeca‑ca.service;

Это действие необходимо для избежания ошибок и вызвано тем, что программный компонент Aladdin eCA на основном узле (АРМ1) и программные компоненты Aladdin eCA на резервных узлах (АРМ2‑узлах) работают с одной схемой базы данных (АРМ3). И при обновлении программного компонента Aladdin eCA на одном узле происходит обновление схемы базы данных до новой версии, с которой программные компоненты Aladdin eCA на других узлах могут работать некорректно.

  • На АРМ1 произвести обновление программного компонента Aladdin eCA в соответствии с разделом 12 настоящего руководства;
  • На каждом АРМ2‑узле произвести обновление программного компонента Aladdin eCA в соответствии с разделом 12 настоящего руководства.

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

[1] Описание проверок при запуске, осуществляемых программным компонентом Aladdin eCA, см в разделе 6.