Ctrl+K
Ctrl+K
PDF
Ctrl+K
PDF

Версии

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

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

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

В рекомендованном варианте развертывания узлы управления ПК СВ (далее фронтальные машины, фронты) и узлы контроллера домена (далее КД) разворачиваются как ВМ на 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"

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

имя сетевого моста на физических серверах который имеет выход в сеть для трафика СХД

mgmtnetwork

адрес менеджмент сети с указанием префикса

bckpnetwork

адрес сети СРК с указанием префикса

stornetwork

адрес сети СХД с указанием префикса

aldpro_domain

доменное имя будущего домена

local_web_ip

адрес bootstrap сервера из менеджмент сети

Примечание

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

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

Доменное имя не должно оканчиваться на .local.

Следующие переменные отвечают за создание ВМ на физических серверах. Узлы управления ПК СВ и узлы Контроллера Домена могут быть развернуты на отдельных серверах или на виртуальных машинах (рекомендуется развертывать как ВМ). Значение 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):

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 сервера на которых будут созданы ВМ для этих ресурсов.

Как видно из примера файла — узел с именем 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-х серверов

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

task vm_deploy

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

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

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

task info

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

Ниже представлен полный список аргументов с их описанием для команды task
Для создания ВМ - будущих узлов КД и узлов управления Брест запустите  task vm_deploy
Для добавления на все физические серверы и ВМ расположенные на них репозитории с текущего бутстрапа запустите  task add_repos
Для полной инсталляции ALD Pro запустите task aldpro_deploy
Для полной инсталляции Брест запустите task brest_deploy
Для получения IQN инициаторов iSCSI таргета запустите task iscsi_iqn
Для подключения iSCSI LUN запустите  task iscsi_connect
Для подключения 2 iSCSI LUN как хранилищ Брест запустите task iscsi_datastore
Для подготовки автоматизации перед развертыванием сетей и ВМ Брест запустите task terraform_config
Для развертывания сетей и ВМ Брест запустите task terraform_deploy
Для полной инсталляции RuBackup запустите task rubackup_deploy
Для полной инсталляции Astra Monitoring запустите task astra_monitoring_deploy
Для полной инсталляции BILLmanager запустите task bill_manager_deploy
Для полной инсталляции DCImanager запустите task dci_manager_deploy
Запуск команд в вышеописанной последовательности приведет к полному развертыванию AIC
task: Available tasks for this project:
* add_repos:                     Добавление репозиториев с bootstrap сервера
* aldpro_client:                 Инсталляция клиентской части ALD Pro
* aldpro_deploy:                 Полная инсталляция ALD Pro
* aldpro_deploy_replica:         Инсталляция реплики ALD Pro. На будущей реплике сперва должна быть выполнена клиентская часть ALD
* aldpro_server:                 Инсталляция севера ALD Pro
* astra_monitoring_client:       Инсталляция клиентов Astra Monitoring
* astra_monitoring_deploy:       Инсталляция сервера и клиентов Astra Monitoring
* astra_monitoring_server:       Инсталляция сервера Astra Monitoring
* bill_manager_deploy:           Инсталляция сервера BillManager
* brest_deploy:                  Полная инсталляция ПК СВ Брест (front, kvm, raft)
* brest_front:                   Инсталляция узлов управления ПК СВ Брест
* brest_kvm:                     Инсталляция узлов виртуализации ПК СВ Брест
* brest_post_scripts:            Донастройка Брест после его развертывания
* brest_raft:                    Инсталляция RAFT для всех узлов управления. Если RAFT уже существует, добавить в него дополнительный узел управления автоматизацией нельзя
* dci_manager_deploy:            Инсталляция сервера DCIManager
* iscsi_connect:                 Подключение iSCSI LUN
* iscsi_datastore:               Создание 2 хранилища в Брест из 2 наибольших подключенных LUN
* iscsi_iqn:                     Установка пакетов iSCSI, получение IQN инициаторов
* 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_prepare_hosts:              Подготовка 3 хостов перед созданием ВМ для фронтов Брест и ALD Pro
* vm_second_host:                Создание ВМ на втором хосте
* vm_third_host:                 Создание ВМ на третьем хост

Здесь описаны все основные и дополнительные аргументы команды "task".

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

task vm_prepare_hosts
task vm_first_host
task vm_second_host
task vm_third_host

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

Аргумент

Описание

vm_prepare_hosts

подготовка 3 хостов перед созданием ВМ для фронтов ПК СВ и ALD Pro

vm_first_host

создание ВМ на первом хосте

vm_second_host

создание ВМ на втором хосте

vm_third_host

создание ВМ на третьем хосте

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

  1. Копируется qcow2 образ ВМ.

  2. Указываются репозитории ALSE с bootstrap сервера.

  3. Происходит проверка наличия пакетов для работы libvirt QEMU с их установкой при их отсутствии.

  4. Выполняется остановка ненужных сетевых служб, таких как firewalld, dnsmaq, ModemManager и удаление пакетов этих сетевых служб.

  5. Осуществляется синхронизация времени серверов с bootstrap сервером.

  6. Устанавливаются нужные для работы Ansible ролей пакеты.

  7. Генерируется и перезаписывается UUID для libvirt, чтобы обеспечить живую миграцию ВМ под управлением ПК СВ.

  8. Останавливается и удаляется стандартная сеть libvirt, так как она не будет использоваться.

  9. Создаются 3 виртуальные сети libvirt с параметрами, указанными ранее в файле /home/astra/aic-code/inventory.yml.

  10. В файле /etc/hosts добавляются записи о других физических серверах с их доменным именем

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

  1. Скопированный ранее образ перемещается в директорию для образов libvirt с нужными правами.

  2. Создаются ВМ, согласно указанным переменным в файле group_vars/all.yml.

  3. Используя инструменты libvirt в каждой ВМ, задаются статичные IP-адреса, копируется публичный SSH-ключ с bootstrap сервера.

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

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

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

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

Репозиторий 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.3.0

Где:

Переменная

Описание

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

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

https://dc1-test.aicstand.ru

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

Примечание

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

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

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

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

#########
# Brest #
#########
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"

Где:

Переменная

Описание

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 символов;

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

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

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

  1. Пользователи и группы — информация о пользователях, их ролях и группах, а также права доступа.

  2. Виртуальные машины — данные о конфигурациях виртуальных машин, их состояниях, использовании ресурсов и связанных образах.

  3. Ресурсы — информация о ресурсах, таких как хосты, хранилища, сети и другие элементы, которые составляют облачную инфраструктуру.

  4. Шаблоны — настройки и параметры шаблонов для виртуальных машин, которые используются для их создания.

  5. Мониторинг — данные о производительности, статистике и событиях, связанных с работой виртуальных машин и хостов.

Заполнив переменные, следует внести правки в файл инвентарь (/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

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

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

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

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

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

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

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

Подключение 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.90

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

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

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

task iscsi_iqn

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

../../_images/task_iscsi.png

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

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

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

task iscsi_connect

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

Примечание

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

Для подключения 2 LUN как хранилищ ПК СВ в директории /home/astra/aic-code выполнить команду:

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

Примечание

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

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

onedatastore list

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

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

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

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

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

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

Примечание

Имя сетевых мостов будет взято из переменных 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: "5"

def_infra_vms_network_name_bkp: "Backup"
def_infra_net_size_bkp: "5"

def_infra_vms_image_url: "http://{{ local_web_ip }}/images/alse-1.7.4uu1-base-brest-mg13.1.1-amd64.qcow2"
def_infra_vms_image_ds_id: "100"
def_infra_vms_system_ds_id: "101"

Где:

Параметр

Описание

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_vms_image_ds_id

ID хранилища образов ПК СВ

def_infra_vms_system_ds_id

ID хранилища данных ПК СВ

Количество адресов обоих сетей (диапазон адресов) рекомендуется указывать одно значение для обоих сетей, также значение должно быть числом равным или превышающим количество развертываемых ВМ (3, либо 4 если планируется инсталляция 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
...
####################
# 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:

В блоке 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).

Примечание

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

Например, изменив имя ВМ для 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

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

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

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

task terraform_deploy

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

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

task terraform_post_scripts

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

Примечание

Повторный запуск команды 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 ресурсы не были удалены вручную.

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

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

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

############
# Rubackup #
############
rubackup_version: 2.1.0.45-1

rubackup_clnt_eth: "eth1"
rubackup_server_psql_password: "ABC_1234567890"
rubackup_server_psql_password_rubackup: "ABC_1234567890"

rbdbuser: "rubackup"

Где:

Клиентами СРК являются узлы КД ALD Pro и узлы управления ПК СВ.

У всех клиентов СРК должен быть настроен сетевой интерфейс из выделенной для СРК сети с одинаковым для всех клиентов именем, имя этого интерфейса необходимо указать как значение переменной rubackup_clnt_eth.

Примечание

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

Если некоторые клиенты СРК находятся на отдельных серверах и имеют разные имена сетевых интерфейсов в рамках сети СРК, необходимо сначала развернуть серверную часть СРК. Затем в группе узлов клиентов СРК (в файле инвентаре) нужно указать только те узлы, чье имя сетевого интерфейса соответствует значению переменной rubackup_clnt_eth. После этого следует запустить автоматизацию клиентской части СРК. Далее нужно изменить значение переменной rubackup_clnt_eth и внести в группу клиентов другие узлы, для которых это значение актуально. Этот процесс следует повторять до тех пор, пока все клиенты СРК не будут установлены.

Например, только для узлов ALD Pro имя сетевого интерфейса в сети СРК — eth4. В файле с переменными нужно задать соответствующее значение данной переменной, а в файле инвентаре изменить значения клиентской группы СРК:

rubackup_client:
  children:
    aldpro_server:
    aldpro_replica:

# Другой, более точный вариант указания только узлов КД:
rubackup_client:
   hosts:
     dc1-test:
     dc2-test:

Завершив автоматизацию клиентской части, снова измените значение переменной и имена узлов в группе клиентов СРК, после снова запустить развертывание клиентской части.

Примечание

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

Для удобства рекомендуется задавать пользователю «postgres» и администратору БД СРК одинаковый пароль.

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

task rubackup_deploy

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

  1. Все клиенты RuBackup автоматически авторизуются.

  2. Создаются клиентские группы: dc, brest, rubackup, по ним распределяются все клиенты.

  3. В клиентскую группу rubackup переносится клиент самого сервера RuBackup, в группу dc — контроллер домена и его реплики, в группу «brest» - серверы управления ПК СВ.

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

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

../../_images/token.png

Токен из вывода автоматизации также для удобства записывается в файл /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:

../../_images/rub_aut.png

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

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

Подключение к ВМ

Для подключения к удаленному столу ВМ рекомендуется использовать VNC-подключение. Для этого необходимо установить соответствующий пакет:

sudo apt install virt-viewer

Далее в веб-интерфейсе ПК СВ выбрать Подключение через VNC, после открыть загруженный файл командой:

remote-viewer имя_скаченного_файла.vv

Дополнительные, более подробные команды запуска инсталляции СРК 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):

../../_images/rbm.png

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

  • имя сервера, пользователя и тип аутентификации RuBackup DB;

  • в поле Имя сервера RuBackup можно указать либо localhost, либо IP-адрес самой ВМ;

  • значение Имя пользователя находится в переменной rbdbuser, а Пароль в переменной rubackup_server_psql_password_rubackup.

Находясь в оконном приложении менеджера администратора RuBackup, необходимо проверить что все клиенты СРК авторизованы, находятся в сети, а также что для каждого клиента есть расписание на создание РК директории /etc/.

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

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

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

oneexporter_password: "{{ '=mvp1CL@st=' | b64encode }}"
exporterwebuser_password: "{{ '=mvp1CL@st=' | b64encode }}"

Где:

Переменная

Описание

oneexporter_password

пароль пользователя «exporteruser». Этот пользователь будет через API получать данные для метрик AM

exporterwebuser_password

пароль пользователя «exporterwebuser». Этот пользователь будет получать данные для метрик с веб-интерфейса ПК СВ

Примечание

Значения переменных выше — =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 команды выше — в первую очередь нужно развернуть серверную часть, после клиентскую.

После развертывания для проверки его корректности можно перейти в браузере по адресу ВМ с сервером AM.

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

../../_images/objects.png

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

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

  • логин: admin-internal;

  • пароль: admin.

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

  • логин: admin;

  • пароль: password.

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

Установка BILLmanager#

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

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

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

task bill_manager_deploy

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

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

Для работы BILLmanager необходима лицензия.

Редакция развертываемого BILLmanager — Hosting&Cloud.

В конце вывода развертывания на экран будет выведено значение параметра inode_id:

../../_images/ignore.png

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

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

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

Далее, поддержке ISPsystem нужно передать значение inode_id и номер лицензии. В ответ будет получена лицензия BILLmanager. Лицензия имеет длину около 2000 символов.

Примечание

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

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

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

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

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

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

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

killall core

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

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

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

В случае если зайти в веб-интерфейс BILLmanager до активации лицензии, веб интерфейс не откроется, вместо этого будет отображаться ошибка:

../../_images/bill_mist.png

Это не является ошибкой инсталляции. После добавления лицензии и перезапуске служб BILLmanager веб-интерфейс будет открываться корректно.

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

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

Так как DCImanager не является обязательным компонентом AIC, перед началом работы с файлами для развертывания необходимо скачать 2 образа, расположить их в директорию «/rep/iso» на bootstrap сервере. Первый ISO содержит установочный образ DCImanager, второй образ содержит репозиторий необходимый для установки DCImanager.

Оба образа можно скачать в личном кабинете, в директории с файлами для «AIC 1.1» — dci6_repo.iso, dci_latest.iso.

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

Имена образов изменять нельзя.

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

###############
# DCI Manager #
###############
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"

Где:

Переменная

Описание

email

логин для подключения к DCImanager, указывается именно адрес электронной почты

password

пароль для подключения к DCImanager

platform_name

наименование платформы

DataCenter_name2

наименование локации

unit

номер юнита в стойке, в этом юните должен располагаться управляющий локацией сервер

default_gw_ip

шлюз для менеджмент сети. При создании ВМ шлюз не указывался, а он необходим для корректной работы DCImanager

default_gw_dev

наименования сетевой интерфейса менеджмент сети

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 серверов достаточно поменять только 4 ранее указанных переменных

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

task dci_manager_deploy

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

После вывода «отпечатка», автоматизация будут ожидать ввода лицензии. Для получения лицензии необходимо зайти на сайт ISP System. Авторизовавшись нужно запросить лицензию по полученному в выводе «отпечатку».

После чего полученную лицензию (она имеет текстовый вид) вставить в консоль, нажать Enter, после чего развертывание будет продолжено.

Содержание