Установка без использования инсталлятора

Содержание

Установка без использования инсталлятора#

Создание репозиториев из ISO на bootstrap сервере#

После того как на bootstrap сервер будут загружены нужные ISO и будет выполнена валидация их хэш-сумм, следующим этапом автоматизации развертывания AIC необходимо сделать из ISO репозитории, которые в дальнейшем будут подключены ко всем хостам AIC.

Для запуска автоматизации создания репозиториев из ISO нужно находясь в директории /home/astra/aic-code выполнить команду:

task iso_deploy

Автоматизация настроит на bootstrap сервере apache2, директория /mnt будет доступна всем узлам по 80 порту адреса bootstrap сервера. В каталоге /mnt будут созданы директории alse177, alse176uu2, aldpro, brest, rubackup. В них будут примонтированы соответствующие ISO.

Это позволит хостам облачной платформы использовать ISO расположенные на bootstrap сервере как репозитории для компонентов AIC.

Создание виртуальных машин для серверов управления и контроллеров домена#

В рекомендованном варианте развертывания узлы управления ПК СВ (далее фронтальные машины, фронты) и узлы контроллера домена (далее КД) разворачиваются как ВМ на 3-х физических серверах, которые будут являться узлами виртуализации ПК СВ.

На каждом из 3 серверов создается виртуальная машина (далее ВМ) с 1 узлом управления и 1 узлом КД (рекомендуется использовать не 3 узла КД, а 2. Соответственно на третьем сервере будет развернута только ВМ с третьим узлом управления ПК СВ).

Необходимые для изменения переменные#

Пример вида файла /home/astra/aic-code/ansible/playbooks/group_vars/all.yml:

######################################
# VM for Brest fronts, ALD Pro hosts #
######################################
management_bridge: "br200"
backup_bridge: "br169"
storage_bridge: "br170"
vm_disk_size: "50"
vm_username: "astra"
vm_password: "astra"

mgmtnetwork: "192.168.22.0/24"
bckpnetwork: "10.22.22.0/24"
stornetwork: "10.205.17.0/24"

frnthost1_in_kvm: true
aldphost1_in_kvm: true

frnthost2_in_kvm: true
aldphost2_in_kvm: true

frnthost3_in_kvm: true
aldphost3_in_kvm: false
...
aldpro_domain: "aicstand.ru"
...
local_web_ip: "192.168.22.21"

Где:

Переменная	Описание
management_bridge	имя сетевого моста на физических серверах который имеет выход в менеджмент сеть
backup_bridge	имя сетевого моста на физических серверах который имеет выход в сеть для трафика СРК
storage_bridge	имя сетевого моста на физических серверах который имеет выход в сеть для трафика СХД
vm_disk_size	размер диска который будет создан для каждой ВМ в ГБ, значение должно быть 50 или более
vm_username	имя пользователя который будет создан на каждой ВМ
vm_password	пароль пользователя который будет создан на каждой ВМ
mgmtnetwork	адрес менеджмент сети с указанием префикса
bckpnetwork	адрес сети СРК с указанием префикса
stornetwork	адрес сети СХД с указанием префикса
aldpro_domain	доменное имя будущего домена
local_web_ip	адрес bootstrap сервера из менеджмент сети

Примечание

Указание доменного имени на этом этапе необходимо для корректного внесения автоматизацией записей серверам друг о друге.

Предупреждение

Доменное имя не должно оканчиваться на .local, оно также должно совпадать с доменным именем заданным на этапе установки ОС на физические серверы, то есть совпадать с значением переменной DOMAINNAME из файла /home/astra/deploy_pxe_bash/vars.

Следующие переменные отвечают за создание ВМ на физических серверах. Узлы управления ПК СВ и узлы Контроллера Домена могут быть развернуты на отдельных серверах или на виртуальных машинах (рекомендуется развертывать как ВМ). Значение true указывает на использование ВМ.

Переменная	Описание
frnthost1_in_kvm	будет ли ВМ для первого фронта ПК СВ развернута на 1-м физическом сервере
aldphost1_in_kvm	будет ли ВМ для первого узла КД развернута на 1-м физическом сервере
frnthost2_in_kvm	будет ли ВМ для второго фронта ПК СВ развернута на 2-м физическом сервере
aldphost2_in_kvm	будет ли ВМ для второго узла КД развернута на 2-м физическом сервере
frnthost3_in_kvm	будет ли ВМ для третьего фронта ПК СВ развернута на 3-м физическом сервере
aldphost3_in_kvm	будет ли ВМ для третьего узла КД развернута на 3-м физическом сервере

Пример вида части файла-инвентаря отвечающего за создание ВМ для фронтов ПК СВ, узлов КД (/home/astra/aic-code/inventory.yml):

all:
  vars:
     ansible_user: "astra"

aic_default_infra:
  hosts:
    dc1-test:
      ansible_host: 192.168.22.230
    dc2-test:
      ansible_host: 192.168.22.231
  # dc3-test:
  #  ansible_host: 192.168.22.232
    node1-test:
      ansible_host: 192.168.22.233
    node2-test:
      ansible_host: 192.168.22.234
    node3-test:
      ansible_host: 192.168.22.235
    aichost1:
      ansible_host: 192.168.22.74
      ansible_user: aicadmin
    aichost2:
      ansible_host: 192.168.22.75
      ansible_user: aicadmin
    aichost3:
      ansible_host: 192.168.22.76
      ansible_user: aicadmin

############################
# VM on 3 physical servers #
############################
vm_hosts:
  hosts:
    aichost1:
    aichost2:
    aichost3:

Блок aic_default_infra содержит узлы, используемые AIC кроме ВМ под управлением ПК СВ.

Требуется указать имена и адреса узлов КД (dc1-test, dc2-test), фронтов ПК СВ (node1-test, node2-test, node3-test), а также указать 3 сервера на которых будут созданы ВМ для этих ресурсов.

Предупреждение

Третья строка из части файла-инвентаря выше (ansible_user: «astra») отвечает за имя пользователя на всех узлах кроме тех которым пользователь задан отдельно, как например для 3-х физических серверов (aichost1..3).

Значение переменной vm_username должно совпадать со значением в третьей строке из части файла-инвентаря выше, то есть со значением глобальной переменной ansible_user.

Если для каких-либо ресурсов будут использованы не ВМ, а физические сервера, нужно указать в инвентаре имя пользователя, в случае если он отличается от заданного в третьей строке из части файла-инвентаря выше, по аналогии с указанием имени пользователя для 3-х физических серверов.

Имена серверов не должны содержать в себе спецсимволы кроме «-«.

Как видно из примера файла — узел с именем dc3-test (третий узел контроллера домена) закомментирован, а в файле с переменным, переменная aldphost3_in_kvm имеет значение false. Это означает что используется только 2 узла КД.

Если планируется использовать 3 узла, то необходимо раскомментировать строки узлы dc3-test, а переменной aldphost3_in_kvm задать значение true.

Только для 3-х физических серверов помимо имени и адреса также указывается пользователь, из-под которого на серверах будет выполняться автоматизация.

Примечание

В случае если пользователь не указывается, предполагается, что имя пользователя — astra. Если для каких-либо ресурсов будут использованы не ВМ, а физические сервера, нужно указать в инвентаре имя пользователя, в случае если он отличается от astra.

Предупреждение

Имена 3-х физических серверов в блоке aic_default_infra на которых будут созданы ВМ должны быть такими же, как и hostname этих серверов.

В ином случае ВМ не будут развертываться, и все узлы контроллера домена и узлы управления ПК СВ будут вынесены на отдельные физические серверы, вместо параметров серверов предназначенных для ВМ нужно указать параметры 3-х основных узлов виртуализации ПК СВ.

Блок переменных vm_hosts, отвечает за указание серверов, на которых будут развернуты ВМ. В нем нужно указать заданные ранее имена всех трех серверов.

Примечание

Необходимо предварительно обеспечить беспарольный доступ по SSH пользователю «astra» до указанного в файле-инвентаре пользователя на каждом их 3-х серверов

Предупреждение

При развертывании AIC в виртуальном окружении требуется предварительно создать файл .pxe_interface на первом сервере из группы vm_hosts в домашней директории указанного для сервера пользователя.

После заполнения обоих файлов можно запускать развертывание ВМ, для этого перейти в директорию /home/astra/aic-code/ и выполнить команду:

task vm_deploy

Это запустит развертывание всех ВМ.

Помимо общего развертывания, есть возможности более детально развертывания.

Чтобы узнать все аргументы команды task, находясь в директории /home/astra/aic-code/ следует выполнить:

task info

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

Ниже представлен полный список аргументов с их описанием для команды task
Для проверки целостности скаченных из личного кабинета ISO запустите  task iso_verify
Для установки и настройка apache2, монтирование ISO компонентов AIC как репозитории на этот bootstrap, запустите  task iso_deploy
Для создания ВМ - будущих узлов КД и узлов управления Брест запустите  task vm_deploy
Для добавления на все физические серверы и ВМ расположенные на них репозитории с текущего бутстрапа запустите  task add_repos
Для полной инсталляции ALD Pro запустите task aldpro_deploy
Для полной инсталляции Брест запустите task brest_deploy
Для создания подразделений в контроллере домена запустите task aldpro_create_ou
Для донастройки параметров ALD Pro запустите task aldpro_post_scripts
Для получения IQN инициаторов iSCSI таргета запустите task iscsi_iqn
Для подключения iSCSI LUN запустите  task iscsi_connect
Для создания на 2-х iSCSI LUN хранилищ Брест типа brest-lvm запустите task iscsi_brest_lvm_datastore
Для создания на 2-х iSCSI LUN хранилищ Брест типа lvm-lvm запустите task iscsi_lvm_lvm_datastore
Для подготовки автоматизации перед развертыванием сетей и ВМ Брест запустите task terraform_config
Для развертывания сетей и ВМ Брест запустите task terraform_deploy
Для донастройки ВМ под управлением Брест после их развертывания запустите task terraform_post_scripts
Для ввода в домен ALD Pro развернутых ВМ под управлением Брест запустите task aldpro_client_brest
Для полной инсталляции BILLmanager запустите task bill_manager_deploy
Для настройки LDAP в BILLmanager запустите task bill_manager_ldap
Для полной инсталляции RuBackup запустите task rubackup_deploy
Для полной инсталляции Astra Monitoring запустите task astra_monitoring_deploy
Для инсталляции клиента Astra Monitoring на сервере BILLmanager запустите task astra_monitoring_billm
Для полной инсталляции Справочного центра запустите task help_center_deploy
Для полной инсталляции Marketplace запустите task marketplace_deploy
Для инсталляции DCImanager до этапа получения лицензии запустите task dci_part1
Для продолжения инсталляции DCImanager после добавления файла с лицензией запустите task dci_part2
Запуск команд в вышеописанной последовательности приведет к полному развертыванию AIC

* add_repos:                       Добавление репозиториев с bootstrap сервера
* aldpro_client:                   Инсталляция клиентской части ALD Pro
* aldpro_client_brest:             Инсталляция клиентской части ALD Pro для ВМ в ПК СВ Брест
* aldpro_create_ou:                Создание подразделений в ALD Pro для RBAC модели
* aldpro_deploy:                   Полная инсталляция ALD Pro
* aldpro_deploy_replica:           Инсталляция реплики ALD Pro. На будущей реплике сперва должна быть выполнена клиентская часть ALD
* aldpro_post_scripts:             Донастройка ALD Pro после развертывания
* aldpro_server:                   Инсталляция севера ALD Pro
* apache2_deploy:                  Установка и настройка apache2 на bootstrap
* astra_monitoring_billm:          Инсталляция клиента Astra Monitoring для BILLmanager
* astra_monitoring_client:         Инсталляция клиентов Astra Monitoring
* astra_monitoring_deploy:         Инсталляция сервера и клиентов Astra Monitoring
* astra_monitoring_server:         Инсталляция сервера Astra Monitoring
* bill_manager_deploy:             Инсталляция сервера BILLmanager
* bill_manager_ldap:               Настрйока ldap на BillManager
* brest_deploy:                    Полная инсталляция ПК СВ Брест (front, kvm, raft)
* brest_front:                     Инсталляция узлов управления ПК СВ Брест
* brest_kvm:                       Инсталляция узлов виртуализации ПК СВ Брест
* brest_post_scripts:              Донастройка Брест после его развертывания
* brest_raft:                      Инсталляция RAFT для всех узлов управления. Если RAFT уже существует, добавить в него дополнительный узел управления автоматизацией нельзя
* brest_token:                     Синхронизация токена доступа между всеми узлами управления для ALD Pro синхронизации и создания среды с помощью Terraform
* check_version:                   Проверка версий ALSE и компонентов AIC на соответствие версий
* dci_part1:                       Инсталляция сервера DCIManager до получения лицензии
* dci_part2:                       Инсталляция сервера DCIManager после получения лицензии
* help_center_deploy:              Установка и настройка сервера с сайтом инструкций
* iscsi_brest_lvm_datastore:       Создание 2-х хранилищ в Брест типа brest-lvm из 2-х наибольших подключенных LUN
* iscsi_connect:                   Подключение iSCSI LUN
* iscsi_iqn:                       Установка пакетов iSCSI, получение IQN инициаторов
* iscsi_lvm_lvm_datastore:         Создание 2-х хранилищ в Брест типа lvm-lvm из 2-х наибольших подключенных LUN
* iso_aldpro:                      Монтирование ISO ALD Pro как репозиторий на bootstrap
* iso_alse:                        Монтирование ISO ALSE как репозиторий на bootstrap
* iso_brest:                       Монтирование ISO Брест как репозиторий на bootstrap
* iso_deploy:                      Установка и настройка apache2, монтирование ISO компонентов AIC как репозитории на bootstrap
* iso_rubackup:                    Монтирование ISO RuBackup как репозиторий на bootstrap
* iso_verify:                      Проверка целостности скаченных из личного кабинета ISO
* marketplace_deploy:              Установка и настройка сервера Маркетплейса
* rubackup_api:                    Инсталляция модуля REST API RuBackup
* rubackup_client:                 Инсталляция клиенсткой части RuBackup
* rubackup_deploy:                 Инсталляция сервера и клиентов RuBackup
* rubackup_post_install:           Авторизация, настройка клиентов RuBackup
* rubackup_server:                 Инсталляция сервера RuBackup
* rubackup_token:                  Генерация свежего токена для RuBackup
* terraform_clean:                 Обнуление состояния terraform
* terraform_config:                Настройка переменных и VM для создания в Брест и синхронизация токена доступа на узлах управления
* terraform_deploy:                Создание ВМ в ПК СВ Брест
* terraform_destroy:               Удаление всех ВМ в ПК СВ Брест
* terraform_post_scripts:          Донастройка ВМ под управлением ПК СВ Брест после их развертывания
* vm_deploy:                       Полное развертывание на 3-х серверах ВМ для фронтов Брест и ALD Pro
* vm_first_host:                   Создание ВМ на первом хосте
* vm_post_deploy:                  Увеличние размера диска ВМ
* vm_prepare_hosts:                Подготовка 3-х хостов перед созданием ВМ для фронтов Брест и ALD Pro
* vm_second_host:                  Создание ВМ на втором хосте
* vm_template:                     Создание шаблонного образа ВМ из ISO на 1-ом из 3-х серверов AIC
* vm_third_host:                   Создание ВМ на третьем хосте

Как видно из вывода — помимо аргумента vm_deploy есть другие аргументы относящиеся к развертыванию ВМ для фронтов ПК СВ, узлов КД:

task vm_prepare_hosts
task vm_template
task vm_first_host
task vm_second_host
task vm_third_host
vm_post_deploy

Запуск общего развертывания аналогичен поочередному запуску этих аргументов task.

Аргумент	Описание
vm_prepare_hosts	подготовка 3 хостов перед созданием ВМ для фронтов ПК СВ и ALD Pro
vm_template	создание шаблонных ВМ, qcow2 файлов, которые будут использованы для ВМ фронтов ПК СВ и ALD Pro
vm_first_host	создание ВМ на первом хосте
vm_second_host	создание ВМ на втором хосте
vm_third_host	создание ВМ на третьем хосте
vm_post_deploy	увеличение размера дисков ВМ до указанного в переменной «vm_disk_size» значения

После общего запуска развертывания для каждого физического сервера выполняются следующие действия:

Указываются репозитории ALSE с bootstrap сервера.
Происходит проверка наличия пакетов для работы libvirt QEMU с их установкой при их отсутствии.
Выполняется остановка ненужных сетевых служб, таких как firewalld, dnsmaq, ModemManager, а после удаление пакетов этих сетевых служб.
Осуществляется синхронизация времени серверов с bootstrap сервером.
Устанавливаются нужные для работы автоматизации пакеты.
Останавливается и удаляется стандартная сеть libvirt, так как она не будет использоваться.
Создаются 3 виртуальные сети libvirt с параметрами, указанными ранее в файле /home/astra/aic-code/inventory.yml.
В файле /etc/hosts добавляются записи о других физических серверах с их доменным именем.
На первом из 3-х физических серверов создаются шаблонные ВМ используя PXE с bootstrap, устанавливая ОС ALSE 1.7.6uu2 и ALSE 1.7.7 по сети из ISO.
Для каждого шаблона ВМ создается свой файл с хэш-суммой, все файлы шаблонных ВМ копируются на bootsrap сервер.
На каждый из серверов копируются шаблонные ВМ, из инх создаются ВМ для КД и узлов управления ПК СВ, предварительно проверив их хэш-сумму.
Созданным ВМ назначаются статичные IP-адреса согласно файлу-инвентарю, а также копируется публичный SSH ключ с bootstrap сервера.
Происходит проверка размера диска каждой ВМ. В случае если он не был увеличен до значения в переменной vm_disk_size, выполняется автоматизация его увеличения.

Итогом автоматизации являются настроенные ВМ для развертывания на них остальных ресурсов AIC.

В названии виртуальных машин, расположенных на первом сервере, стоит цифра 1, на втором — цифра 2, на третьем — цифра 3, например: aldphost1, frnthost2.

В случае возникновения ошибок необходимо удалить ВМ и ее диск на том хосте, где они возникли. Диски ВМ расположены по пути /var/lib/libvirt/images. После чего перезапустить автоматизацию.

Добавление репозиториев на созданные ВМ#

После развертывания ВМ на них необходимо добавить локальные репозитории с bootstrap сервера — репозитории ALSE 1.7.6 с оперативным обновлением uu2 на всех узлы используемые AIC, а также репозиторий ПК СВ 3.3.3 на узлы, предназначенные для ПК СВ.

Репозиторий ALD Pro будет добавлен автоматизацией во время инсталляции этого компонента.

Для запуска автоматизации добавления репозиториев необходимо, находясь в директории /home/astra/aic-code, выполнить команду:

task add_repos

После этого можно переходить к развертыванию компонентов AIC.

Установка контроллеров домена#

На предыдущем этапе были подготовлены узлы, в том числе для развертывания на них КД.

Перед запуском развертывания необходимо указать переменные в файле /home/astra/aic-code/ansible/playbooks/group_vars/all.yml:

###########
# ALD Pro #
###########
aldpro_domain: "aicstand.ru"
aldpro_admin_password: "=mvp1CL@st="
aldpro_version: 2.4.1

Где:

Переменная	Описание
aldpro_domain	Доменное имя
aldpro_admin_password	Пароль администратора домена
aldpro_version	Версия ALD Pro

Значение переменной aldpro_domain заполнялось на этапе развертывание ВМ для фронтов ПК СВ, узлов КД. Повторно менять ее значение не нужно, так как на 3 физических серверах в файле /etc/hosts уже есть записи содержащие указанное в этой переменной доменное имя.

Для входа в веб-интерфейс ALD Pro необходимо использовать пароль указанный в переменной aldpro_admin_password.

Предупреждение

Значение переменной «aldpro_version» необходимо оставить без изменений.

Пароль администратора домена не должен содержать в себе символы «$», «|», «!», «#».

После заполнения файла с переменными необходимо внести изменения в файл-инвентарь (/home/astra/aic-code/inventory.yml):

aic_default_infra:
  hosts:
    dc1-test:
      ansible_host: 192.168.22.230
    dc2-test:
      ansible_host: 192.168.22.231
   # dc3-test:
   #  ansible_host: 192.168.22.232
...
#################
# ALD Pro hosts #
#################

aldpro_server:
  hosts:
    dc1-test:

aldpro_replica:
  hosts:
    dc2-test:
  # dc3-test:

aldpro_clients:
  children:
    aldpro_replica:
    brest_kvm_nodes:
    brest_fronts:

Имена и адреса узлов КД указывались при создании ВМ, необходимо проверить, что с bootstrap сервера обеспечен беспарольный доступ по SSH до этих узлов.

Как видно из примера файла — используются 2 узла КД, третий узел закомментирован. На этапе создания ВМ, третий узел КД тоже был закомментирован, ВМ для него не была создана.

В группе aldpro_server всегда указывается только 1 хост, лидер КД.

В группе aldpro_replica указываются «реплики» КД.

В группе aldpro_clients указываются группы, которые будут являться клиентами КД, то есть «реплики» КД, узлы управления и виртуализации ПК СВ. Менять имя этой группы или значения не рекомендуется. В случае изменения имени какой-либо группы, необходимо проверить что все ее упоминания также были изменены на новое значение. Клиенты ALD Pro после выполнения автоматизации развертывания получат hostname равные имени узлов в файле инвентаре.

Примечание

Все узлы КД равноправны, несмотря на разделение узлов КД на лидера и реплик. Между ними будет настроена двунаправленная репликация с периодичностью синхронизации баз данных примерно раз в 5-10 минут.

Такое разделение представлено исключительно для удобства заполнения файла инвентаря и работы автоматизации.

Для запуска развертывания КД ALD Pro необходимо в директории /home/astra/aic-code/ выполнить команду:

task aldpro_deploy

Команда запустит автоматизацию для полной инсталляции клиентской и серверной частей ALD Pro.

Дополнительные, более подробные команды запуска инсталляции этапов развертывания ALD Pro:

task aldpro_server
task aldpro_client
task aldpro_deploy_replica

В этом порядке команды должны быть выполнены чтобы прийти к результату команды task aldpro_deploy. На узлах будущих реплик КД сперва должна выполниться установка клиентской части, после чего эти узлы будут «повышены» по полноценнных серверов КД.

Описание команд:

Команда	Описание
aldpro_server	инсталляция серверной части ALD Pro, лидера КД
aldpro_client	инсталляция клиентской части ALD Pro
aldpro_deploy_replica	инсталляция реплик ALD Pro

Порядок выполнения этапов важен, на узлах будущих реплик КД сперва должна выполниться установка клиентской части, после чего эти узлы будут «повышены» по полноценных серверов КД.

Примечание

Процесс повышения клиента до реплики КД занимает от 30 до 240 минут.

После успешного развертывания КД, следует перейти в веб-интерфейс ALD Pro, чтобы убедиться, что все нужные узлы вошли в домен. Для этого в браузере, например одного из 3 серверов, на которых были развернуты ВМ следует перейти по адресу:

https://dc1-test.aicstand.ru

Авторизовавшись, перейти во вкладку Компьютеры и убедиться, что в представленном списке указаны все узлы из группы файла инвентаря aic_default_infra.

Примечание

Состояние настроенной репликации будет отображаться только через 5-10 минут после завершения развертывания реплик, первая синхронизации БД лидера и реплик КД также произойдет через 5-10 минут.

В случае если реплика КД не инициализировалась, ее статус в разделе Управление доменом — Сайты и службы — Контроллеры домена — <FQDN реплики> в строке Состояние подсистемы будет указано «Ошибка». В этом случае, перед повторной установки реплики, необходимо выполнить ряд действий по удалению ее как резервного контроллера домена.

Примечание

Если у реплики в поле Состояние подсистемы указано «Устанавливается» даже после 4-х часов ожидания, рекомендуется выполнить ее удаление в качестве резервного контроллера домена с последующей переинициализацией.

Для этого на реплике которую не удалось инициализировать необходимо выполнить команду:

sudo astra-freeipa-server -U -y

В тексте вывода будут указаны предупреждения и ошибки:

WARNING:
IPA server is not configured on this system. If you want to install the
IPA server, please install it using 'ipa-server-install'.
WARNING: Failed to connect to Directory Server to find information about
replication agreements. Uninstallation will continue despite the possible
existing replication agreements.
Client uninstall complete.
The ipa-client-install command failed. See /var/log/ipaclient-uninstall.log for more information
Uninstall of client side components failed!
The ipa-server-install command failed. See /var/log/ipaserver-uninstall.log for more information
Use of uninitialized value $fieldname in hash element at /usr/sbin/pam-auth-update line 704, <PROFILE> line 1.
Use of uninitialized value $fieldname in hash element at /usr/sbin/pam-auth-update line 705, <PROFILE> line 1.
Use of uninitialized value $fieldname in hash element at /usr/sbin/pam-auth-update line 704, <PROFILE> line 1.
Use of uninitialized value $fieldname in hash element at /usr/sbin/pam-auth-update line 705, <PROFILE> line 1.

Такой вывод является нормальным. Он появляется из-за некорректной инициализации узла как реплики контроллера домена.

В консоли лидера КД выполнить команды:

sudo -i
ipa-replica-manage del <FQDN удаляемой реплики>

Например, если реплика, которую не удалось инициализировать имеет имя dc2-test, команда будет выглядеть как ipa-replica-manage del dc2-test.aicstand.ru.

Для проверки удаления реплики необходимо в веб-интерфейсе ALD Pro в разделе Управление доменом — Сайты и службы — Контроллеры домена убедиться что пункта с удаляемой репликой в списке больше нет.

Далее в разделе Роли и службы сайта — Служба разрешения имен в списке Имя зоны необходимо выбрать имя домена. В поисковой строке нужно указать имя удаляемой реплики. Все записи что будут найдены поиском необходимо удалить.

На лидере КД необходимо удалить сертификаты реплики, для этого нужно выполнить команды:

sudo rm -f /etc/ssl/freeipa/<FQDN удаляемой реплики>.*
sudo rm -f /etc/ssl/freeipa/gc-<FQDN удаляемой реплики>.*

Например, если реплика которую не удалось инициализировать имеет имя dc2-test, команды примут следующий вид:

sudo rm -f /etc/ssl/freeipa/dc2-test.aicstand.ru.*
sudo rm -f /etc/ssl/freeipa/gc-dc2-test.aicstand.ru.*

Для того чтобы убедиться, что не осталось соглашений о репликации с удаленным контроллером домена, на лидере КД необходимо выполнить команду:

ldapsearch -D "cn=directory manager" -W -b "cn=topology,cn=ipa,cn=etc,dc=<домен второго уровня>,dc=<домен первого уровня>"

Для домена aicstand.ru команда примет следующий вид:

ldapsearch -D "cn=directory manager" -W -b "cn=topology,cn=ipa,cn=etc,dc=aicstand,dc=ru"

Уровни домена указываются поочередно. Например для домена aicstand.ru.local команда будет выглядеть как:

ldapsearch -D "cn=directory manager" -W -b "cn=topology,cn=ipa,cn=etc,dc=aicstand,dc=ru,dc=local"

После ввода команды требуется ввести пароль администратора домена. В выводе будут показаны все соглашения о репликации. Каждое из соглашений будет идти после закомментированной строки с ее именем, например:

# dc1-test.aicstand.ru-to-dc2-test.aicstand.ru, domain, topology, ipa, etc, aic
 stand.ru
dn: cn=dc1-test.aicstand.ru-to-dc2-test.aicstand.ru,cn=domain,cn=topology,cn=ipa,cn=etc,dc=aicstand,dc=ru
ipaReplTopoSegmentDirection: both
objectClass: iparepltoposegment
objectClass: top
cn: dc1-test.aicstand.ru-to-dc2-test.aicstand.ru
ipaReplTopoSegmentLeftNode: dc1-test.aicstand.ru
ipaReplTopoSegmentRightNode: dc2-test.aicstand.ru
ipaReplTopoSegmentStatus: autogen

В выводе выше показан пример для соглашения о репликации между серверами КД dc1-test.aicstand.ru и dc2-test.aicstand.ru.

Если в выводе команды будет запись про соглашении о репликации с удаляемым КД, необходимо выполнить команду:

ldapdelete -D "cn=directory manager" -W "cn=dc1-test.aicstand.ru-to-dc2-test.aicstand.ru,cn=domain,cn=topology,cn=ipa,cn=etc,dc=aicstand,dc=ru"

Где выражение после «-W» является названием соглашении о репликации.

После чего необходимо выполнить команду:

sudo ipa-replica-manage clean-dangling-ruv

Данная команда удалит некорректные записи о репликации в случае если такие имеются.

Последним этапом является поиск артефактов реплики в аттрибутах LDAP. Для этого также на каждом активном сервере КД необходимо выполнить команду:

ldapsearch -x -H "ldaps://<FQDN текущего КД>" -D "cn=directory manager" -W -b "cn=mapping tree,cn=config" "(objectClass=*)" nsslapd-referral nsds50ruv nsruvReplicaLastModified -o ldif-wrap=no | grep "deleted_fqdn"

В случае если сервер КД на котором выполняется команда имеет FQDN dc1-test.aicstand.ru, аргумент -H примет значение ldaps://dc1-test.aicstand.ru. Если у команды будет пустой вывод, значит никаких артефактов нет. В ином случае вывод будет формата:

# dc1-test.aicstand.ru-to-dc2-test.aicstand.ru, replica, dc\3Dcb\2Caicstand\3Dru, mapping tree, config
dn: cn=dc1-test.aicstand.ru-to-dc2-test.aicstand.ru,cn=replica,cn=dc\3Dcb\2Caicstand\3Dru,cn=mapping tree,cn=config
nsds50ruv: {replica 7 ldap://dc1-test.aicstand.ru:389} 68076acb000000070000 6821e43a000000070000
nsruvReplicaLastModified: {replica 7 ldap://dc2-test.aicstand.ru:389} 00000000

На серверах КД, которые покажут наличие артефакта, необходимо создать файл с содержанием:

dn: cn=dc1-test.aicstand.ru-to-dc2-test.aicstand.ru,cn=replica,cn=dc\3Dcb\2Caicstand\3Dru,cn=mapping tree,cn=config
changetype: modify
delete: nsds50ruv
nsds50ruv: {replica 7 ldap://dc1-test.aicstand.ru:389} 68076acb000000070000 6821e43a000000070000
-
delete: nsruvReplicaLastModified
nsruvReplicaLastModified: {replica 7 ldap://dc2-test.aicstand.ru:389} 00000000

Где строки dn, nsds50ruv и nsruvReplicaLastModified будут равны строкам из полученного ранее артефакта. Файл может иметь любое имя, например cleanup_dc2-test.aicstand.ru.ldif, но его имя должно оканчится на .ldif.

Далее на сервере КД на котором был создан файл необходимо выполнить команду:

ldapmodify -x -H "ldaps://dс1-test.aicstand.ru" -D "cn=directory manager" -W -f cleanup_dc2-test.aicstand.ru.ldif

Где в аргументе -H указывается FQDN сервера КД на котором выполняется команда, а в аргументе -f указывается название созданного файла.

После выполнения этих действия для повторной инициализации реплики необходимо находясь в директории /home/astra/aic-code/ на bootstrap сервере выполнить поочередно команды:

task aldpro_client
task aldpro_deploy_replica

Установка сервиса виртуализации#

Развернув КД следует перейти к развертыванию сервиса виртуализации — ПК СВ.

Перед запуском развертывания нужно изменить значения переменных,относящиеся к ПК СВ, в файле /home/astra/aic-code/ansible/playbooks/group_vars/all.yml:

#########
# Brest #
#########
brest_version: "3.3.3"
freeipa_admin_pass: "{{ aldpro_admin_password }}"
freeipa_brestadmin: "badmin"
freeipa_brestadmin_pass: "=mvp1CL@st="

db_name: "brest"
db_user: "dbuser"
db_user_pass: "=mvp1CL@st="

raft_floating_name: "raftleader"
raft_floating_ip: "192.168.22.100"

Где:

Переменная	Описание
brest_version	версия ПК СВ (RAFT)
freeipa_admin_pass	пароль администратора FreeIpa, необходимо оставить без изменений
freeipa_brestadmin	имя администратора ПК СВ (он будет добавлен в домен)
freeipa_brestadmin_pass	пароль администратора ПК СВ
db_name	имя основной БД ПК СВ
db_user	имя администратора основной БД ПК СВ
db_user_pass	пароль администратора основной БД ПК СВ
raft_floating_name	короткое плавающее имя кластера управления ПК СВ (эта A-запись будет добавлена в DNS ALD Pro)
raft_floating_ip	адрес короткого плавающего имени кластера управления ПК СВ (RAFT)

Предупреждение

Указываемые пароли должны:

состоять минимум из 8 символов;
содержать спецсимволы, цифры, буквы нижнего и верхнего регистра;
не содержать в себе символы «$», «#», «|».

Адрес короткого плавающего имени кластера управления ПК СВ должен быть в менеджмент сети.

Основная БД ПК СВ хранит в себе все данные о кластере ПК СВ:

Пользователи и группы — информация о пользователях, их ролях и группах, а также права доступа.
Виртуальные машины — данные о конфигурациях виртуальных машин, их состояниях, использовании ресурсов и связанных образах.
Ресурсы — информация о ресурсах, таких как хосты, хранилища, сети и другие элементы, которые составляют облачную инфраструктуру.
Шаблоны — настройки и параметры шаблонов для виртуальных машин, которые используются для их создания.
Мониторинг — данные о производительности, статистике и событиях, связанных с работой виртуальных машин и хостов.

Заполнив переменные, следует внести правки в файл инвентарь (/home/astra/aic-code/inventory.yml):

aic_default_infra:
  hosts:
...
    brest1:
      ansible_host: 192.168.22.233
    brest2:
      ansible_host: 192.168.22.234
    brest3:
      ansible_host: 192.168.22.235
    aichost1:
      ansible_host: 192.168.22.74
      ansible_user: aicadmin
    aichost2:
      ansible_host: 192.168.22.75
      ansible_user: aicadmin
    aichost3:
      ansible_host: 192.168.22.76
      ansible_user: aicadmin
...
###############
# Brest hosts #
###############

brest_fronts:
  hosts:
    brest1:
    brest2:
    brest3:

brest_raft:
  children:
    brest_fronts:

brest_kvm_nodes:
  hosts:
    aichost1:
    aichost2:
    aichost3:

Имена и адреса узлов управления ПК СВ указывались при создании ВМ, необходимо проверить что с bootstrap сервера обеспечен беспарольный доступ по SSH до этих узлов.

Примечание

3 сервера на которых были развернуты ВМ — фронты ПК СВ и узлы КД являются и узлами виртуализации ПК СВ.

В случае, если узлы виртуализации планируется вынести на отдельные серверы, или использовать большее количество узлов виртуализации, их следует добавить в группу aic_default_infra по аналогии с текущем примером файла (такая же табуляция, указание не только имена и адреса, но и имени пользователя), а также указать их имена в группе brest_kvm_nodes.

В группе brest_fronts указываются имена узлов управления ПК СВ (далее — фронты, фронтальные машины).

В группе brest_raft указывается группа узлов, на которой будет развернут RAFT, то есть узлы управления ПК СВ. Менять значения этой группы не нужно.

В группе brest_kvm_nodes указываются имена узлов виртуализации ПК СВ.

Заполнив оба файла, можно переходить к развертыванию сервиса виртуализации.

Для этого в директории /home/astra/aic-code выполнить команду:

task brest_deploy

Эта команда запустит автоматизацию для полной инсталляции сервиса виртуализации, как и узлов управления, так и узлов виртуализации.

Примечание

В случае если во время развертывания на узлах виртуализации возникнет ошибка с текстом «HTTP Error 401: Unauthorized», необходимо дождаться пока все реплики КД корректно инициализируются (статус узла в разделе Управление доменом — Сайты и службы — Контроллеры домена — <FQDN реплики> в строке Состояние подсистемы будет указан как «Установлена»), после чего перезагрузить все узлы КД. Как только узлы будут перезагружены можно снова запускать развертывание сервиса виртуализации.

Дополнительные, более подробные команды запуска инсталляции этапов развертывания сервиса виртуализации:

task brest_front
task brest_kvm
task brest_raft
task brest_post_scripts

В таком порядке команды должны быть выполнены чтобы прийти к результату выполнения команды task brest_deploy.

Описание команд:

Команда	Описание
brest_front	инсталляция узлов управления ПК СВ
brest_kvm	инсталляция узлов виртуализации ПК СВ
brest_raft	настройка механизма RAFT
brest_post_scripts	выполнение пост-установочных действий

Одним из пост-установочных действий является добавления в директории /root на трех серверах управления ПК СВ скрипта backup_db.sh, который выполняет резервное копирование базы данных кластера при условии, что текущий сервер является лидером кластера управления ПК СВ. Резервная копия базы данных помещается в каталог /backup расположенный на этих же узлах. Также скрипт ротирует резервные копии, с периодичностью в 15 дней. Выполнение скрипта добавляется в таблицу планировщика задач cron, с периодичностью запуска скрипта каждый день, в 00:05.

После успешного развертывания сервиса виртуализации необходимо проверить его работоспособность.

Для проверки корректности настройки механизма RAFT на любом из узлов управления ПК СВ из-под пользователя root выполнить команду:

onezone show 0

Пример вывода команды:

root@node1-test:~# onezone show 0
ZONE 0 INFORMATION
ID                : 0
NAME              : OpenNebula

ZONE SERVERS
ID NAME            ENDPOINT
 0 node1-test.aics http://192.168.22.233:2633/RPC2
 1 node2-test.aics http://192.168.22.234:2633/RPC2
 2 node3-test.aics http://192.168.22.235:2633/RPC2

HA & FEDERATION SYNC STATUS
ID NAME            STATE      TERM       INDEX      COMMIT     VOTE  FED_INDEX
 0 node1-test.aics leader     51         65         65         2     -1
 1 node2-test.aics follower   51         65         65         -1    -1
 2 node3-test.aics follower   51         65         65         2     -1

ZONE TEMPLATE
ENDPOINT="http://localhost:2633/RPC2"
root@node1-test:~#

Узел с именем node1-test является лидером кластера RAFT. Если бы RAFT был некорректно настроен, то все узлы имели бы значение STATE - follower.

Далее необходимо зайти в его веб-интерфейс, для этого в браузере, например одного из 3 серверов, на которых были развернуты ВМ следует перейти по имени RAFT:

https://raftleader.aicstand.ru

После авторизации необходимо проверить, что узлы виртуализации были корректно инициализированны.

Создание OU (Organizational Units) в контроллере домена и донастройка его серверной конфигурации#

После развертывания ПК СВ нужно настроить организационную структуру в контроллере домена. Она будет иметь следующий вид:

В подразделении «aic_adm_root» добавляется пользователь администратор ПК СВ.

Для создания такой иерархической структуры нужно находясь в директории /home/astra/aic-code выполнить команду:

task aldpro_create_ou

После чего в веб-интерфейсе ALD Pro можно будет посмотреть на созданную иерархическую структуру подразделений.

Также перед тем, как переходить к созданию ресурсов в ПК СВ необходимо выполнить донастройку серверной части КД.

Примечание

Дополнительную настройку серверной части КД нужно выполнять только после того как все реплики КД корректно инициализируются. Так как клиент повышается до реплики в течении 30 — 120 минут, этот этап вынесен в действия после развертывания ПК СВ.

Чтобы убедиться в корректности инициализации реплик КД, в веб-интерфейсе ALD Pro необходимо перейти в раздел Управления доменом, далее в Сайты и службы. В этом окне отображаются все контроллеры домена. Для того чтобы убедиться корректность инициализации реплик нужно поочередно выбрать каждую реплику из списка. Пример отображаемой информации:

Важно обратить внимание на Роли компьютера. Если узел пока не стал репликой — у него будут отсутствовать роли, не будет никаких соглашений о репликации, а также в пункте Версия ALD Pro вместо версии будет текст «Неизвестно». Только после того, как все реплики корректно инициализируются, следует запускать автоматизацию донастройки серверной части КД.

Для этого находясь в директории /home/astra/aic-code нужно выполнить команду:

task aldpro_post_scripts

Данная команда запустит донастройку DNS на всех серверах КД.

Подключение iSCSI к сервису виртуализации#

Для хранилищ образов и данных ВМ под управлением ПК СВ рекомендуется использовать либо iSCSI, либо Ceph.

Примечание

Автоматизация установки ОП AIC 1.3 базовой редакции не предоставляет автоматизацию для развертывание и подключения к ПК СВ кластера Ceph.

Предоставляемая автоматизация может быть использована только для создания хранилищ на iSCSI LUN. Создать хранилище типа «brest-lvm» возможно только на LUN у которых одинаковые размеры логических и физических секторов, в ином случае будет создано хранилище типа «lvm-lvm».

Подключение iSCSI к сервису виртуализации разбито на 3 этапа:

установка пакетов iSCSI и получение IQN инициаторов;
подключения iSCSI LUN;
добавление 2 iSCSI LUN как хранилищ ПК СВ.

iSCSI LUN подключаются к узлам управления и виртуализации ПК СВ.

Перед переходом к первому этапу подключения iSCSI следует в файле с переменными (/home/astra/aic-code/ansible/playbooks/group_vars/all.yml) указать адрес портала, который раздает минимум 2 iSCSI LUN. За адрес портала отвечает соответствующая переменная:

################
# iSCSI portal #
################
iscsi_portal:
  - 10.205.17.90
# - 10.205.17.91

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

Вносить изменения в файл инвентарь необходимости нет, заполнив переменную, отвечающую за порталы — можно запускать первый этап подключения iSCSI.

Для этого в директории /home/astra/aic-code выполнить команду:

task iscsi_iqn

После вызова этой команды на узлы управления и виртуализации ПК СВ будут установлены пакеты open-iscsi и lvm2, а также на экране будут следующий вывод с IQN каждого из узлов:

Необходимо добавить эти узлы по полученным IQN как инициаторов таргета ISCSI групп. У iSCSI есть возможность настроить iSCSI таргет для приема подключений от любых инициаторов без необходимости добавлять IQN каждого инициатора вручную. Это может быть реализовано путем настройки таргета на анонимный доступ или выставления более широких правил доступа, все индивидуально.

После добавления узлов как инициаторов при таковой необходимости, следует перейти ко второму этапу работы с iSCSI — подключению LUN.

Для этого в директории /home/astra/aic-code выполнить команду:

task iscsi_connect

После выполнении автоматизации вызываемой этой командой, ко всем узлам будут подключены iSCSI LUN. Будут подключены все LUN раздаваемые указанным адресом, но для хранилищ ПК СВ будут использованы только 2 LUN с наибольшим объемом.

Примечание

Рекомендуется использовать предварительно очищенные LUN, то есть необходимо удалить всю содержащуюся на них информацию перед подключением их как хранилищ ПК СВ.

Перед создания хранилищ в ПК СВ необходимо проверить размеры секторов подключенных LUN-дисков. Для этого на любом узле управления ПК СВ следует выполнить команду sudo fdisk -l /dev/<LUN-диск>:

astra@node1-test:~# fdisk -l /dev/sda
Диск /dev/sda: 500 GiB, 536870912000 байт, 1048576000 секторов
Модель диска: engine-n2
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 512 байт
Размер I/O (минимальный/оптимальный): 4096 байт / 4096 байт

В выводе присутствует строка «Размер сектора». Если размеры логических и физических секторов совпадают, то для создания 2-х хранилищ типа «brest-lvm» в ПК СВ находясь в директории /home/astra/aic-code выполнить команду:

task iscsi_brest_lvm_datastore

Во время работы автоматизации на лидера RAFT будут скопированы 2 шаблона для хранилищ, выбраны 2 наибольших по объему подключенных iSCSI LUN, которые и будут использованы как хранилища для данных и образов ПК СВ.

Примечание

Так как используемые для хранилищ LUN должны быть пусты, в самом начале этого этапа автоматизации происходит проверка на наличие групп томов, физических томов и логических разделов. Если же LUN не пусты и на них есть какие-то компоненты LVM — автоматизация прекратит работу, сообщив о найденных компонентах LVM. Также будет выполнена проверка на идентичность размеров секторов, если размеры логических и физических секторов не будут идентичны — автоматизация остановится и выводит информационное сообщение об этом.

После проверки на наличие компонентов LVM выполняется очистка таблицы dmsetup — из нее удаляются все записи о ранее созданных виртуальных блочных устройствах. Этот шаг необходим, поскольку при повторном использовании LUN, ранее задействованных в хранилище ПК СВ, наличие старых записей в dmsetup может помешать их корректной инициализации как новых хранилищ.

ПК СВ не сразу определяет корректные параметры хранилищ, после подключения 2 LUN следует подождать 5 минут, чтобы все хранилища корректно инициализировались.

Если же размеры физических и логических секторов не совпадают, то использовать LUN-диски для хранилища типа BREST_lvm нельзя. В случае, если на СХД нет возможности пересоздать LUN с идентичными размерами секторов, то необходимо использовать хранилища типа LVM-LVM.

Для создания из 2-х наибольших по размеру LUN хранилищ типа LVM-LVM, находясь в директории /home/astra/aic-code, на bootstrap сервере необходимо выполнить команду:

task iscsi_lvm_lvm_datastore

Убедиться в том, что хранилища подключились успешно, можно посмотрев на их список в самом веб-интерфейсе ПК СВ в меню Хранилища. Либо зайти на узел лидер RAFT, и из-под пользователя root выполнив команду:

onedatastore list

Если хранилища подключились успешно, после выполнение команды в консоли должен быть следующий вывод:

root@node1-test:~# onedatastore list
  ID NAME                SIZE AVA CLUSTERS IMAGES TYPE DS      TM      STAT
lvm-lvm-system    500.0G 100 0             0 sys  -       lvm_lvm on
lvm-images        200.0G 100 0             0 img  lvm     lvm_lvm on
files              28.7G 78% 0             0 fil  fs      ssh     on
default            28.7G 78% 0             0 img  fs      ssh     on
system                 - -   0             0 sys  -       ssh     on

В примере вывода видно, что были подключены и использованы 2 LUN, размер в 500 и 200 ГБ. Слева от имени хранилища указан его ID. Он будет необходим для следующего этапа развертывания AIC.

В случае, если требуется переподключить хранилища ПК СВ типа BREST_lvm, или же удалить существующие LUN и пересоздать их с другими параметрами для хранилищ типа BREST_lvm, простое удаление компонентов LVM не является корректным методом.

Так как хранилища типа BREST_lvm используют кластерную блокировку «SAN-Lock», то очистка LUN разделена на 2 этапа — удаление группы томов и физических томов.

Перед началом удаления компонентов LVM необходимо удалить в веб-интерфейсе ПК СВ существующие хранилища. Для этого нужно перейти в раздел Хранилища, выбрать оба созданных ранее хранилища, после чего удалить.

Перед началом удаления компонентов LVM предварительно необходимо удостовериться что на всех хостах включена кластерная блокировка, то есть в файле /etc/lvm/lvm.conf у переменной use_lvmlockd = 1 установлено значение 1. Для удобства очистки LUN рекомендуется выполнять все действия под пользователем root.

Чтобы узнать какие группы томов и физические тома используются хранилищами, на узле лидере RAFT следует выполнить команду pvs:

root@node1-test:~# pvs
  PV         VG         Fmt  Attr PSize    PFree
  /dev/sda   vg-one-100 lvm2 a--  <499,97g 499,97g
  /dev/sdb   vg-one-101 lvm2 a--  <199,97g 199,97g

Имена групп томов содержат в себе ID хранилищ, в данном случае у хранилища с ID 100 используется группой томов с именем vg-one-100 и физический том с именем /dev/sda, а у хранилища с ID 101 группа томов с именем vg-one-101 и физический том с именем /dev/sdb.

Далее на всех узлах управления ПК СВ, кроме текущего лидера RAFT нужно выполнить команду:

root@node2...3-test:~# vgchange --lockstop

На лидере RAFT для удаления групп томов используемых хранилищами ПК СВ следует выполнить команды:

root@node1-test:~# vgremove vg-one-100
root@node1-test:~# vgremove vg-one-101

Перед удалением физических томов также на лидере RAFT нужно выполнить команду:

root@node1-test:~# systemctl stop sanlock.service lvmlockd.service

Также нужно выключить кластерную блокировку, для этого в файле /etc/lvm/lvm.conf нужно найти строку use_lvmlockd = 1 и поменять значение 1 на 0. После чего можно удалять оба физических тома:

root@node1-test:~# pvremove /dev/sda
root@node1-test:~# pvremove /dev/sdb

Выполнение этих команд очистит компоненты LVM от созданных автоматизацией хранилищ. Для пересоздания хранилищ достаточно выполнить находясь в директории /home/astra/aic-code команду iscsi_brest_lvm_datastore.

Создание сетей и ВМ под управлением ПК СВ#

Создание сетей и ВМ под управлением ПК СВ также осуществляется автоматизацией.

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

Примечание

Имя сетевых мостов будет взято из переменных management_bridge, backup_bridge, которые заполнялись на этапе создания ВМ для узлов управления ПК СВ и КД.

Блок файла /home/astra/aic-code/ansible/playbooks/group_vars/all.yml, отвечающий за этап создания ресурсов ПК СВ:

#############
# Terraform #
#############
def_infra_vms_network_name_mgmt: "Management"
def_infra_net_size_mgmt: "7"

def_infra_vms_network_name_bkp: "Backup"
def_infra_net_size_bkp: "7"

def_infra_vms_image_url: "http://{{ local_web_ip }}/vm_template"
def_infra_marketplace_image_url: "http://{{ local_web_ip }}/marketplace/marketplace.qcow2"
def_infra_vms_image_ds_id: "101"
def_infra_vms_system_ds_id: "100"

Где:

Параметр	Описание
def_infra_vms_network_name_mgmt	имя, которое будет назначено менеджмент сети в ПК СВ
def_infra_net_size_mgmt	количество адресов менеджмент сети в ПК СВ
def_infra_vms_network_name_bkp	имя, которое будет назначено сети СРК в ПК СВ
def_infra_net_size_bkp	количество адресов сети СРК в ПК СВ
def_infra_vms_image_url	путь до qcow2 образа для ВМ под управлением ПК СВ на bootstrap сервере (необходимо оставить без изменений)
def_infra_marketplace_image_url	путь до qcow2 образа маркетплейса ПК СВ на bootstrap сервере (необходимо оставить без изменений)
def_infra_vms_image_ds_id	ID хранилища образов ПК СВ
def_infra_vms_system_ds_id	ID хранилища данных ПК СВ

Количество адресов обоих сетей (диапазон адресов) рекомендуется указывать одно значение для обоих сетей, также значение должно быть числом равным или превышающим количество развертываемых ВМ (включая, если планируется инсталляция DCImanager).

Необходимые для изменений блоки файла инвентаря (/home/astra/aic-code/inventory.yml):

brest_default_infra:
  hosts:
    rubackup-server:
      ansible_host: 192.168.22.240
    monitoring:
      ansible_host: 192.168.22.241
    bill-manager:
      ansible_host: 192.168.22.242
  # dci-manager:
  #   ansible_host: 192.168.22.243
    help:
      ansible_host: 192.168.22.244
    marketplace:
      ansible_host: 192.168.22.245
...
####################
# Astra Monitoring #
####################
mon_server:
  hosts:
    monitoring:

mon_clients:
  children:
    aic_default_infra:
    rubackup_server:

###############
# BILLManager #
###############
bill_server:
  hosts:
    bill-manager:

###############
# DCI Manager #
###############
#dci_server:
#  hosts:
#    dci-manager:

############
# RuBackup #
############
rubackup_server:
  hosts:
    rubackup-server:

rubackup_client:
  children:
    aldpro_server:
    aldpro_replica:
    brest_raft:

###############
# Help Center #
###############
hc_server:
  hosts:
    help:

###############
# Marketplace #
###############
marketplace_server:
  hosts:
    marketplace:

В блоке brest_default_infra указываются все ВМ под управлением ПК СВ. В этом блоке нужно указать имена и адреса узлов. ВМ получат hostname равные заданным в этом файле именам.

Если какой-то компонент развертывать не планируется, необходимо закомментировать имя и адрес такого компонента в блоке brest_default_infra, а также закомментировать соответствующую компоненту группу узлов. На примере файла выше — ВМ для DCImanager развернута не будет.

Кроме блока brest_default_infra в файле инвентаре есть блоки для соответствующих компонентов AIC, которые будут развернуты на ВМ под управлением ПК СВ:

mon_server — группа узлов, в которой должно быть указано имя ВМ предназначенной для Astra Monitoring;
mon_clients — группа узлов, в которой должно быть указано имя группы всех узлов (aic_default_infra), а также имя ВМ предназначенной для RuBackup;
bill_server — группа узлов, в, которой должно быть указано имя ВМ предназначенной для BILLmanager;
dci_server — группа узлов, в которой должно быть указано имя ВМ предназначенной для DCImanager;
rubackup_server — группа узлов, в которой должно быть указано имя ВМ предназначенной для RuBackup;
rubackup_client — группа узлов, в которой указываются имена групп в которых содержаться клиенты СРК, это группы всех узлов КД (aldpro_server, aldpro_replica), группа узлов на которых был настроен RAFT (brest_raft);
hc_server — группа узлов, в которой должно быть указано имя ВМ предназначенной для справочного центра;
marketplace_server — группа узлов, в которой должно быть указано имя ВМ предназначенной для маркетплейса.

Примечание

После смены имени ВМ, необходимо изменить имя в соответствующих группах, в которые должна входить эта ВМ.

Например, изменив имя ВМ для RuBackup сервера в блоке brest_default_infra, имя ВМ также нужно изменить в блоках rubackup_server и mon_clients.

Имена групп изменять нельзя.

При создании сетей ПК СВ, первым адресом их диапазона будет являться адрес первой ВМ из группы узлов brest_default_infra указанной в файле инвентаре.

При заполнении обоих файлов необходимо обратить внимание на значение переменных def_infra_net_size_mgmt и def_infra_net_size_bkp, а также на указанные адреса ВМ в группе узлов brest_default_infra.

Так как первый адрес диапазона равен адресу первой ВМ из группы brest_default_infra - необходимо проверить, что остальные адреса будут входить в указанный диапазон адресов сети.

Примечание

Для ВМ под управлением ПК СВ рекомендуется задавать адреса последовательно, для избежания потенциальных ошибок и дальнейшего удобства пользования.

У каждом ВМ под управлением ПК СВ будет 2 сети — основная сеть (менеджмент) и сеть для трафика СРК.

Развертывание сетей и ВМ под управлением сетей состоит из двух частей — конфигурирование файлов автоматизации после заполнения файла с переменными и файла инвентаря, и само развертывание.

Для конфигурирования файлов автоматизации после изменений обоих файлов, в директории /home/astra/aic-code выполнить команду:

task terraform_config

Предупреждение

Команду необходимо запускать при любом изменения адресов или переменных описанных в этом разделе, так как выполнение этой команды конфигурирует файлы автоматизации для развертывания сетей и ВМ под управлением ПК СВ.

Перед повторным выполнением команды task terraform_config необходимо выполнить команду task terraform_clean, которая очищает созданные конфигурационные файлы.

Для непосредственно развертывания, в директории /home/astra/aic-code выполнить команду:

task terraform_deploy

После выполнения команды сети и ВМ под управлением ПК СВ будут развернуты.

По завершению работы вызываемой этой командой автоматизации, сети и ВМ под управлением ПК СВ будут развернуты.

Во время развертывания ресурсов ПК СВ может возникнуть ошибка:

Она означает что определенные ВМ, в данном случае ВМ для DCImanager и маркетплейса не успели создаться и запуститься. В случае возникновении такой ошибки следует удалить все созданные автоматизацией ресурсы в ПК СВ, вручную, либо запустив команду task terraform_destroy. Проверив что в ПК СВ не остались созданные ранее ресурсы, следует перезапустить автоматизацию развертывания, выполнив команду task terraform_deploy.

В случае если во время развертывания ресурсов ПК СВ «Брест» возникнет ошибка формата:

Необходимо удалить созданные ресурсы в ПК СВ, после чего перезапустить автоматизацию развертывания.

Последним этапом работы является донастройка созданных ВМ, для этого выполнить команду:

task terraform_post_scripts

Подготовительные действия включают в себя добавления репозиториев ALSE с bootstrap сервера, удаление утилиты one-context и удаление записи «127.0.1.1» из файла /etc/hosts. Эти действия также будут выполнены при развертывание компонентов AIC в ВМ под управлением ПК СВ при запуске развертывания этих компонентов, на указанной для компонента ВМ, что позволяет не выполнять эти действия вручную в случае создания ВМ для компонентов не используя автоматизацию.

Примечание

Повторный запуск команды task terraform_deploy в случае ручного удаления части созданных развертыванием ресурсов, возможен только после полного ручного удаления всех ресурсов, развернутых ранее командой task terrform_deploy, а также выполнения команды task terraform_clean.

При развертывании ресурсов ПК СВ также создается файл «состояния» развертываемой инфраструктуры. За счет этого, в случае ручного удаления части развертываемых ресурсов — реальное стояние инфраструктуры и состояние, описанное в файле, будет отличным друг от друга. Из-за этого при выполнении команды task terraform_deploy будут возникать ошибки с текстом *NO EXIS*T, что и будет обозначать различия между реальным состоянием инфраструктуры, и состоянием описанным в файле. Реальное состояние инфраструктуры и состояние, описанное в файле, всегда должно быть идентичным.

Команда task terraform_clean удаляет файл с состоянием инфраструктуры, что сообщает автоматизации развертывания о том, что никакие ресурсы ПК СВ не были развернуты. Так как реальное состояние инфраструктуры и состояние в файле должны быть идентичными, нужно также удалить все созданные ранее в ПК СВ ресурсы.

Ошибка с тексом ALLOCATED обозначает что ресурс уже был создан, но он имеет другой ID. В случае возникновения этой ошибки, также нужно вручную удалить развертываемые командой task terrform_deploy ресурсы, а после запустить команду task terraform_clean.

Для полного удаления созданных в ПК СВ ресурсов выполнить команду:

task terraform_destroy

Эта команда будет выполнена успешно только в случае, если никакие развернутые командой task terraform_deploy ресурсы не были удалены вручную.

Создав все ресурсы в ПК СВ, виртуальные машины под его управлением необходимо ввести в домен. Для этого также находясь в директории /home/astra/aic-code нужно выполнить команду:

task aldpro_client_brest

Проверить корректность выполнения этого этапа автоматизации можно в веб-интерфейсе ALD Pro. В разделе Пользователи и компьютеры**нужно перейти в подраздел **Компьютеры. В открывшемся списке должны отображаться все развернутые на текущий момент узлы AIC, то есть узлы управления и виртуализации ПК СВ, имя лидера RAFT, все узлы контроллера домена, а также все созданные ВМ под управлением ПК СВ.

Установка BILLmanager#

После успешного создания ресурсов в ПК СВ, необходимо перейти к следующему этапу развертыванию AIC — BILLmanager.

BILLmanager развертывается под управлением ПК СВ, виртуальная машина для него уже была создана на предыдущих этапах.

В файле с переменными /home/astra/aic-code/ansible/playbooks/group_vars/all.yml для BILLmanager предусмотрена только одна переменная:

###############
# Billmanager #
###############
project_id: "2"

В этой переменной указывается ID внутреннего провайдера BILLmanager, который будет отвечать за интеграцию BILLmanager с ПК СВ. Создание провайдера в BILLmanager доступно в его веб-интерфейсе, после его инсталляции и активации лицензии, на этапе установки значение этой переменной менять не нужно.

Для запуска автоматизации развертывания находясь в директории /home/astra/aic-code необходимо выполнить команду:

task bill_manager_deploy

Итогом работы автоматизации будет установленное ПО BILLmanager.

Для работы BILLmanager необходима лицензия. Обратите внимание на то, что редакция развертываемого BILLmanager — «Hosting&Cloud». В конце вывода развертывания на экран будет выведено значение параметра inode_id:

В случае утери этого значения, узнать его повторно можно выполнив на узле с установленным BILLmanager команду:

ls -i /usr/local/mgr5/etc/billmgr.lic | cut -d' ' -f1

Также, значение inode_id будет сохранено в файле inode_id.txt в домашней директории пользователя на ВМ где был развернут BILLmanager:

astra@bill-manager:~$ cat inode_id.txt
2239104

Заказав лицензию в личном кабинете на сайте my.ispsystem.com, поддержке ISPsystem необходимо будет передать значение inode_id, а также номер приобретенной лицензии.

После передачи этих данных, будет получена лицензия BILLmanager для его активации. Лицензия имеет длину около 2000 символов.

Примечание

Номер лицензии и сама лицензия — разные сущности.

После получения лицензии на узле с установленным BILLmanager от пользователя root выполнить команду:

echo "полученная_лицензия" > /usr/local/mgr5/etc/billmgr.lic

Предупреждение

Необходимо выполнять именно команду echo. Использовать текстовые редакторы для добавления лицензии в файл нельзя.

Использование текстовых редакторов изменит уникальный номер инсталляции inode_id.

Веб-интерфейс BILLmanager не будет доступен до активации лицензии.

После записи лицензии необходимо перезапустить службы BILLmanager командой:

killall core

Или же командой:

/usr/local/mgr5/sbin/mgrctl -m billmgr exit

Для входа в веб-интерфейс BILLmanager после активации лицензии необходимо перейти в браузере по адресу ВМ с установленным BILLmanager:

https://<IP>/billmgr?func=logon

Открывшаяся страница будет иметь следующий вид:

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

После инсталляции BILLmanager и активации его лицензии необходимо настроить его интеграцию с ПК СВ. Для этого в веб-интерфейсе BILLmanager необходимо создать сущность «провайдер», которая будет использоваться для интеграции с ПК СВ. Изначально в BILLmanager «провайдер» существует по умолчанию. При необходимости, можно использовать значения по умолчанию, не создавая нового «провайдера».

Для создания нового «провадйера» в веб-интерфейсе BILLmanager необходимо перейти в раздел Провайдер, подраздел Провайдеры, нажать Создать. Требований к параметрам «провайдера» нет.

После того как провайдер будет создан, в общем списке всех текущих провайдеров левее его имени будет указан его ID. Изначально параметр ID не отображается, для включения его отображения необходимо в настройках таблицы «провайдеров» включить отображение параметра «id»:

ID провайдера нужно указать в переменной project_id в файле /home/astra/aic-code/ansible/playbooks/group_vars/all.yml.

После этого для запуска автоматизации настройки интеграции BILLmanager с ПК СВ находясь в директории /home/astra/aic-code нужно выполнить команду:

task bill_manager_ldap

Установка RuBackup под управлением ПК СВ#

СРК RuBackup является виртуальной машиной под управлением ПК СВ. ВМ для этого компонента AIC была создана на предыдущем этапе, перед развертыванием СРК нужно только изменить относящиеся к нему переменные (файл /home/astra/aic-code/ansible/playbooks/group_vars/all.yml):

############
# Rubackup #
############
rubackup_version: "2.4.0.42"
rubackup_server_psql_password: "ABC_1234567890"
rubackup_server_psql_password_rubackup: "ABC_1234567890"
rbdbuser: "rubackup"
rbapitype: "database"

Где:

Параметр	Описание
rubackup_version	версия СРК (необходимо оставить без изменений)
rubackup_server_psql_password	пароль пользователя postgres БД RuBackup
rubackup_server_psql_password_rubackup	пароль администратора БД RuBackup
rbdbuser	имя администратора БД СРК (необходимо оставить без изменений)
rbapitype	тип авторзации в СРК (необходимо оставить без изменений)

Обратите внимание на то, что клиентами СРК являются узлы КД ALD Pro и узлы управления ПК СВ. У каждого клиента СРК есть сетевой интерфейс со статичным IP-адресом из выделенной для СРК сети.

Пароль администратора БД СРК должен состоять минимум из 12 символов и содержать минимум 1 цифру, а также 1 заглавную букву и минимум 1 специальный символ.

Для удобства млжно задать пользователю postgres и администратору БД СРК одинаковый пароль (не рекомендуется в продуктивной среде). Заполнив файл с переменными, для запуска развертывания СРК RuBackup (находясь в директории /home/astra/aic-code) нужно выполнить команду:

task rubackup_deploy

На последнем этапе развертывания выполняются следующие действия:

Все клиенты RuBackup автоматически авторизуются.
Создаются клиентские группы: dc, brest, rubackup, по ним распределяются все клиенты. В клиентскую группу rubackup переносится клиент самого сервера RuBackup, в группу dc — контроллер домена и его реплики, в группу brest — серверы управления ПК СВ.
Для каждого клиента (кроме клиента самого сервера RuBackup) создаются правила глобального расписания резервного копирования каталогов и файлов содежащих конфигурационные файлы AIC.

Для каждого клиента (кроме клиента самого сервера RuBackup) создаются правила глобального расписания резервного копирования каталогов и файлов содержащих конфигурационные файлы AIC.

Также в конце вывода будут указаны сгенерированные API токены RuBackup, на экран будет выведен CSRF токен:

Токен из вывода автоматизации также для удобства записывается в файл /home/astra/api-tokens на сервере СРК, пример содержания этого файла:

astra@rubackup-server:~$ cat /home/astra/api-tokens
# BEGIN ANSIBLE MANAGED BLOCK
csrf_token: 2904dcc7-7749-4a81-b860-2cbf08162dad
# END ANSIBLE MANAGED BLOCK

Полученный CSRF токен REST API необходимо авторизовать, для этого в веб-браузер ВМ с СРК нужно перейти по адресу https://api.rubackup.local:5656/api/v1, в самом верху справа будет кнопка Authorize:

Нажав на нее, ввести полученный в выводе CSRF-токен.

API необходим для возможности сборка метрик Astra Monitoring.

Дополнительные, более подробные команды запуска инсталляции СРК RuBackup:

task rubackup_server
task rubackup_client
task rubackup_api
task rubackup_post_install
task rubackup_token

В таком порядке эти команды должны быть выполнены чтобы прийти к результату выполнения команды task rubackup_deploy.

Описание команд:

Команда	Описание
rubackup_server	инсталляция серверной части СРК
rubackup_client	инсталляция клиентской части СРК
rubackup_api	инсталляция и настройка модуля REST API на сервер СРК
rubackup_post_install	авторизация клиентов СРК, настройка глобального расписания для них
rubackup_token	генерация CSRF-токена REST API RuBackup

Примечание

При перезагрузке RuBackup сервера, либо службы rubackup_server.service — токен для REST API нужно генерировать и авторизовать заново. Используя команду task rubackup_token можно сгенерировать новый токен не запуская весь процесс развертывания заново.

Для проверки работоспособности находясь в графической сессии виртуальной машины с сервером RuBackup следует в терминале выполнить команду:

rbm&

Эта команда запустит оконное приложение менеджера администратора RuBackup (rbm):

В окне приложения необходимо указать:

имя сервера, пользователя и тип аутентификации RuBackup DB;
в поле Имя сервера RuBackup можно указать либо localhost, либо IP-адрес самой ВМ;
значение Имя пользователя находится в переменной rbdbuser, а Пароль в переменной rubackup_server_psql_password_rubackup.

Находясь в оконном приложении менеджера администратора RuBackup, следует проверить что все клиенты СРК авторизованы, находятся в сети, распределены по группам, в разделе Глобальное расписание созданы расписания для создания РК каталогов и файлов содержащих конфигурационные файлы AIC.

Установка Astra Monitoring под управлением ПК СВ#

Astra Monitoring развертывается под управлением ПК СВ, следовательно ВМ для AM уже была создана ранее.

Перед развертыванием Astra Monitoring в веб-интерфейсе BILLmanager необходимо создать сущности «обработчика» и «сотрудника». Перед созданием «обработчика» необходимо создать шаблон виртуальной сети в ПК СВ, он должен быть создан из-под пользователя с административными правами.

Для создания шаблона виртуальной сети необходимо в информационной панели ПК СВ выбрать раздел Сеть, подраздел Сетевые шаблоны нажать на кнопку Создать. Требования к названию и описанию шаблона нет. В после кластеры необходимо выбрать текущий кластер ПК СВ.

Во вкладке Конфигурация рекомендуется указать сетевой мост менеджмент сети, так как в дальнейшем по этому шаблону в VDC BILLmanager будут создаваться виртуальные сети.

Заполнив разделы Адреса и Контекст в соответствии с топологией сети можно создавать шаблон. Для этого, необходимо выбрать пункт Создать. Заполнять разделы Безопасность и Qos необязательно.

Для создания «обработчика» в общем меню веб-интерфейса BILLmanager нужно выбрать раздел Интеграция, подраздел Обработчики услуг. Во время создания обработчика необходимо корректно его настроить:

в разделе Тип продукта необходимо выбрать Виртуальный дата-центр, в разделе Модуль обработки выбрать Брест. В разделе Настройка интеграции в поле Адрес сервера необходимо указать адрес RAFT ПК СВ с протоколом http;
в поле Имя пользователя необходимо указать имя администратора ПК СВ, в поле Пароль указать пароль администратора ПК СВ;
в поле Токен указать действующий токен администратора ПК СВ. Параметры портов изменять не нужно.

Чтобы узнать действующий токен администратора ПК СВ, зайдя веб-интерфейс ПК СВ, из-под пользователя администратора, в информационной панели необходимо выбрать пункт Настройки. Далее перейти во вкладку Аутентификация:

В ней, правее строки Токен входа, выбрать Управление токенами входа. В открывшемся окне будут представлены все текущие токены входа. В поле Токен, при настройки обработчика BILLmanager, необходимо вставить значение любого действующего токена.

Пример заполненных параметров обработчика BILLmanager, этапа Настройка интеграции:

Нажав Далее откроется раздел Параметры обработчика услуг. В поле Наименование можно указать любое значение, поле Сортировка можно оставить пустым. В поле Домен необходимо указать имя текущего домена, в полях Кластеры и Узлы выбрать Выделить все. В поле Хранилища выбрать 2 созданных ранее хранилища. Использовать системные хранилища с ID «1», «2» нельзя. В поле Сети выбрать созданный ранее шаблон виртуальной сети ПК СВ.

Пример заполненных параметров обработчика BILLmanager, этапа Параметры обработчика услуг:

Для того чтобы узнать ID созданного обработчика, как и в случае получения ID провайдера, необходимо настроить вид таблицы, включив отображение параметра «id». ID созданного обработчика необходимо указать в переменной handler_id в файле /home/astra/aic-code/ansible/playbooks/group_vars/all.yml, в блоке переменных для Astra Monitoring.

Помимо обработчика, в веб-интерфейсе BILLmanager также необходимо создать сотрудника. Для этого в разделе Пользователи нужно выбрать подраздел Сотрудники, нажать на кнопку Создать. К значениям полей при создании сотрудника требований нет. Предоставлять Полный доступ не требуется, а раздел Настройки доступа следует оставить без изменений.

Перед развертыванием необходимо изменить переменные в файле /home/astra/aic-code/ansible/playbooks/group_vars/all.yml:

####################
# Astra Monitoring #
####################
oneexporter_password: "{{ '=mvp1CL@st=' | b64encode }}"
exporterwebuser_password: "{{ '=mvp1CL@st=' | b64encode }}"
billm_api_user: "monitoring"
billm_api_pass: "{{ '=mvp1CL@st=' | b64encode }}"
billm_handler_id: "1"

Где:

Переменная	Описание
oneexporter_password	пароль пользователя «exporteruser». Этот пользователь будет через API получать данные для метрик AM
exporterwebuser_password	пароль пользователя «exporterwebuser». Этот пользователь будет получать данные для метрик с веб-интерфейса ПК СВ
billm_api_user	имя созданного в веб-интерфейсе BILLmanager сотрудника. Он будет использоваться для сбора данные метрик Astra Monitoring из BILLmanager используя API
billm_api_pass	пароль созданного в веб-интерфейсе BILLmanager сотрудника
billm_handler_id	ID созданного в веб-интерфейсе обработчика BILLmanager

Примечание

Значения переменных выше — =mvp1CL@st=. Все символы левее и правее их изменять нельзя. Они предназначены для кодирования значения переменной в base64, именно значения в такой кодировки являются допустимыми для Astra Monitoring.

Изменив значения переменных, запустить развертывание можно в директории /home/astra/aic-code выполнив команду:

task astra_monitoring_deploy

Для сбора метрик в ПК СВ, в процессе развертывания в FreeIPA будет создан специальный сервисный пользователь.

Клиентами Astra Monitoring являются узлы КД, узлы управления и виртуализации ПК СВ, сервер RuBackup. На каждого клиента AM будет установлен отдельный экспортер, позволяющий собирать нужные логи.

Кроме общего развертывания есть возможность отдельно развернуть серверную и клиентскую части:

task astra_monitoring_server
task astra_monitoring_client

При раздельной инсталляции, используя 2 команды выше — в первую очередь нужно развернуть серверную часть, после клиентскую.

Также необходимо отдельной командой развернуть клиентскую часть Astra Monitoring на сервере с BILLmanager. Для этого также находясь в директории /home/astra/aic-code необходимо выполнить команду:

task astra_monitoring_billm

Установка клиентской части Astra Monitoring на сервере с BILLmanager вынесена в отдельный шаг, так как она требует наличие отдельного обработчика и сотрудника в BILLmanager, создать которых можно только активировав лицензию BILLmanager.

После развертывания, для проверки корректности установки, можно перейти в браузере по адресу ВМ с сервером AM, приняв лицензионное соглашения нужно ввести данные для входа, после перейти в раздел Объекты наблюдения в нем выбрать Объекты:

Для доступа к визуализации сбора информации нужно перейти в браузере по адресу ВМ с сервером AM (http) указав порт 3000. В разделе Dashboards можно найти все доски, объединенные по логическим группам.

Данные для входа в веб-интерфейс Astra Monitoring:

логин: admin-internal;
пароль: admin.

Данные для входа в Grafana (сервис визуализации собираемой информации):

логин: admin;
пароль: password.

Это значения по умолчанию, поменять их можно вручную после развертывания.

Развертывание cправочного центра#

Справочный центр представляет собой веб-документацию облачной платформы AIC. Он включает архитектурные описания, руководства для пользователей и администраторов, а также калькулятор, позволяющий рассчитать необходимое количество процессорных ядер и объем оперативной памяти для узлов виртуализации ПК СВ с учетом планируемой нагрузки.

Справочный центр размещается в отдельной ВМ под управлением ПК СВ, ВМ была создана на этапе создания ресурсов в ПК СВ. Для того чтобы запустить автоматизацию развертывания справочного центра, находясь в директории /home/astra/aic-code необходимо выполнить команду:

task help_center_deploy

В конце работы автоматизации на экране будут указаны ссылки по которым можно перейти в развернутый справочный центр. Главная страница справочного центра имеет следующий вид:

Основные разделы веб-документации доступны через навигационное меню слева. В нижней части панели предусмотрен выбор версии платформы AIC, в соответствии с которой отображается актуальное содержание справочного центра.

Калькулятор для расчета нужного количества ядер и оперативной памяти для узлов виртуализации ПК СВ представлен в виде .xlsx файла.

Для его открытия необходимо установить пакет libreoffice, установить его можно выполнив команду:

sudo apt install -y libreoffice

После чего файл будет корректно открываться в libreoffice. Калькулятор представляет собой набор таблиц с возможностью расчета количества узлов виртуализации в зависимости от планируемой нагрузки.

Развертывание Маркетплейса ПК СВ#

Маркетплейс реализован в виде виртуальной машины под управлением программного комплекса ПК СВ. Эта ВМ создается на одном из ранних этапов установки AIC. В процессе автоматизированного развертывания также формируется магазин приложений с названием aic_marketplace. Виртуальная машина маркетплейса используется для передачи и публикации сервисов в этот магазин.

Автоматизация выполняемая на самой ВМ с маркетплейсом отправляет специальный API-запрос, после которого с определенной периодичностью, примерно раз в 10 минут, ПК СВ будет связываться с этой ВМ и получать из нее доступные сервисы, публикуя их в магазине приложений aic_marketplace.

Для запуска автоматизации отправления специального API-запроса, находясь в директории /home/astra/aic-code нужно выполнить команду:

task marketplace_deploy

После чего примерно через 10 минут в магазине приложений aic_marketplace появятся доступные для развертывания сервисы.

Пример содержания магазина приложений aic_marketplace:

Из примера видно что GitFlic доступен как сервис для размещения в ПК СВ. Для развертывания сервиса необходимо выбрать его шаблон (он всегда будет иметь тип ШАБЛОН СЕРВИСА). Открыв шаблон сервиса необходимо загрузить его в хранилище ПК СВ. Для этого нужно нажать на кнопку Импорт в хранилище:

В открывшемся окне, выбрав хранилище для загрузки, следует выбрать пункт Загрузить, после чего в ПК СВ будет создан шаблон сервиса, шаблон ВМ с этим сервисом, а также сам сервис будет загружен как образ в хранилище образов ПК СВ.

После того как образ будет загружен (статус ГОТОВО), для размещения сервиса необходимо перейти в раздел Шаблоны, подраздел Сервисы. В этом списке шаблонов сервисов появится шаблон загруженного сервиса:

Открыв шаблон сервиса можно создать из него ВМ. Для этого нужно выбрать Создать экземпляр:

Указав сети, которые будет использовать сервис, и задав ВМ имя, можно запустить ее создание. после создания ВМ будет отображаться в списке всех ВМ в разделе Экземпляры ВМ.

Пользователь этой ВМ — astra, его пароль — astra. Веб-интерфейс GitFlic будет доступен по адресу ВМ, протоколу http, для входа в в графе почта нужно указать adminuser@admin.local, пароль — qwerty123.

Развертывание DCImanager#

DCImanager также развертывается под управлением ПК СВ, следовательно виртуальная машина для него уже была развернута.

Так как DCImanager является необязательным компонентом AIC, перед изменением конфигурационного файла автоматизации, необходимо скачать по ссылке из официальной документации DCImanager (два ISO файла — dci_latest.iso и dci6_repo.iso. Скачанные файлы необходимо расположить в каталог /home/astra/iso/dci_manager_iso/ на bootstrap сервере. Первый ISO образ содержит установочный образ DCImanager, второй ISO образ содержит репозиторий необходимый для установки DCImanager.

Перед развертыванием нужно изменить файл /home/astra/aic-code/ansible/playbooks/group_vars/all.yml:

###############
# DCI Manager #
###############
dci_install: true
email: "admin1@example.com"
password: "123!@#qweASD"
platform_name: "Platform_04"
DataCenter_name2: "DC1"
unit: "1"
default_gw_ip: "192.168.22.1"
mac: "AA:BB:C1:AD:EE:F2"
rack_name: "rack31"
srv_name: "srv124"
ipmi_address: "10.10.10.10"
ipmi_user: "user"
ipmi_pass: "passw0rd"

Где:

Переменная	Описание
dci_install	переменная отвечающая за необходимость развертывания DCImanager, ее значение должно быть «true»
email	логин для подключения к DCImanager, указывается именно адрес электронной почты
password	пароль для подключения к DCImanager
platform_name	наименование платформы
DataCenter_name2	наименование локации
unit	номер юнита в стойке, в этом юните должен располагаться управляющий локацией сервер
default_gw_ip	шлюз для менеджмент сети. При создании ВМ шлюз не указывался, а он необходим для корректной работы DCImanager
mac	MAC-адрес управляющего локацией сервера
rack_name	наименование стойки, в которой должен располагаться управляющий локацией сервер
srvname	имя управляющего локацией сервера
ipmi_address	IPMI адрес управляющего локацией сервера
ipmi_user	IPMI логин управляющего локацией сервера
ipmi_pass	IPMI пароль управляющего локацией сервера

Для понимания переменных, нужно знать основные определения DCImanager.

Администратор может подключить к DCImanager 6 оборудование независимо от его территориального расположения и дата-центра, в котором оно находятся. Для этого в платформе есть локации.

Локация — интерфейс, через который DCImanager 6 управляет оборудованием из одного дата-центра. Под каждую локацию в дата-центре отводится специальный сервер, который служит DHCP-сервером и хранилищем шаблонов операционных систем (ОС) для всех серверов в локации. Именно параметры этого сервера задаются в переменных для развертывания.

DCImanager 6 позволяет систематизировать оборудование в локации по стойкам, в которых оно расположено. При создании локации указывается необходимое количество стоек и их размер в юнитах.

Все переменные кроме email, password и default_gw_ip и default_gw_dev являются шаблонными. Для развертывания с отсутствием подготовленных для DCImanager серверов достаточно поменять только 3 ранее указанных переменных

Для запуска развертывания в директории /home/astra/aic-code выполнить команду:

task dci_part1

Для работы DCImanager необходима лицензия. Во время работы автоматизации будет выведен уникальный «отпечаток» сервера:

Значение этого «отпечатка» также будет сохранено в файле fingerprint.txt в домашней директории пользователя на ВМ где был развернут DCImanager.

Для получения лицензии необходимо зайти на сайт ISP System — https://www.ispsystem.ru/dcimanager, и пройдя авторизацию, запросить лицензию по полученному в выводе «отпечатку».

Полученную лицензию нужно записать в файл /home/astra/aic-code/ansible/roles/dci_manager/after_license/files/dci_license на bootstrap сервере. В этом файле должен быть только текст полученной лицензии, в нем не должно быть пустых строк или лишних символов.

После создания этого файла необходимо запустить второй этап автоматизации развертывания DCImanager:

task dci_part2

Для доступ в веб-интерфейс нужно перейти по адресу ВМ с DCImanager (протокол https). Страница для входа в веб-интерфейс имеет следующий вид:

E-mail и пароль указывались в переменных email и password, в данном случае это admin1@example.com и 123!@#qweASD.

Версии

Установка без использования инсталлятора

Содержание

Установка без использования инсталлятора#

Создание репозиториев из ISO на bootstrap сервере#

Создание виртуальных машин для серверов управления и контроллеров домена#

Необходимые для изменения переменные#

Добавление репозиториев на созданные ВМ#

Установка контроллеров домена#

Установка сервиса виртуализации#

Создание OU (Organizational Units) в контроллере домена и донастройка его серверной конфигурации#

Подключение iSCSI к сервису виртуализации#

Создание сетей и ВМ под управлением ПК СВ#

Установка BILLmanager#

Установка RuBackup под управлением ПК СВ#

Установка Astra Monitoring под управлением ПК СВ#

Развертывание cправочного центра#

Развертывание Маркетплейса ПК СВ#

Развертывание DCImanager#