Ctrl+K
Ctrl+K
PDF
Ctrl+K
PDF

Версии

Установка AIC через интерфейс командной строки (CLI)

Содержание

Установка AIC через интерфейс командной строки (CLI)#

Примечание

Развертывание AIC версии 1.3.1 возможно двумя способами — устанавливая каждый компонент ОП из консоли, используя предоставленные средства автоматизации развертывания (далее «автоматизация»), либо с использованием Графического инсталлятора AIC. Развертывание с помощью графического инсталлятора является предпочтительным.

Описание возможного сценария развертывания инфраструктуры#

Ключевые этапы развертывания инфраструктуры:

  • запуск виртуальной машины bootstrap сервера из Qcow2 образа;

  • загрузка ISO из личного кабинета в специальные директории на bootstrap сервере;

  • установка ОС на целевых серверах;

  • создание служебных виртуальных машин на целевых серверах;

  • подготовка и исполнение сценария установки основных компонентов, кроме СРК RuBackup (далее — Средство Резервного Копирования, СРК), Astra Monitoring, BILLmanager, DCImanager, Справочного центра, Market place;

  • подключение хранилищ iSCSI к ПК СВ»Брест» (далее — Подсистема виртуализации, Портал администратора);

  • развертывание ВМ со Средством резервного копирования, Astra Monitoring, BILLmanager, DCImanager, Справочным центром и Market place внутри Подсистемы виртуализации.

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

Схема расположения служб и виртуальных машин на целевых серверах:

../../_images/001_dop_Layout_of_services_and_VM.png

Версии продуктов и компонентов#

Версионность продуктов:

  • ПК СВ «Брест» — 3.3.3.UU1;

  • ALD Pro — 2.4.1;

  • RuBackup — 2.4;

  • Astra Monitoring — 0.7.1;

  • BILLmanager — 6.121 (редакция Hosting&Cloud for AIC);

  • DCImanager — 6;

  • ОС СН Astra Linux — SE 1.7.7, SE 1.7.6.UU2 (версия 1.7.7 используется для серверов управления и виртуализации ПК СВ «Брест», версия 1.7.6.UU2 для остальных серверов облачной платформы кроме DCImanager, для него используется версия ALSE 1.7.4.UU1).

Сетевая топология#

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

Рекомендуемая схема сетевого подключения:

../../_images/002_dop_recommended_network_scheme.png

Примечание

Данная схема является минимальной рабочей топологией. Она может быть расширена и дополнена, но не может быть упрощена.

Схема описывает сетевые соединения серверов виртуализации, топологию сетевых интерфейсов с точки зрения операционной системы, а также относительное расположение сервера bootstrap.

Для работы как установщика, так и самой платформы AIC требуются следующие сети:

  • PXE, используемая для сетевой установки ОС;

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

  • Storage, которая соединяет серверы виртуализации с СХД (iSCSI);

  • Backup для резервного копирования.

Сеть PXE должна быть нетегируемой (access), остальные, учитывая ожидаемую топологию, — тегируемые (trunk).

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

Необходимо выделять отдельный физический канал для целей сетевой установки ОС (PXE). Выделение отдельного физического канала для резервного копирования (Backup) допускается и рекомендуется, но не является обязательным.

На серверах виртуализации каждый VLAN подключается к сетевому мосту с соответствующим названием, указывающим на VLAN ID или роль, которую выполняет мост. Создание сетевых мостов на виртуальной машине bootstrap не целесообразно.

Примечание

На серверах виртуализации не допускается использование названий интерфейсов вида ethX. Это связано с особенностями работы агрегации сетевых каналов (bond). При сетевой автоматической установке ОС параметр ядра net.ifnames=0, который необходимо убрать, убирается автоматически. На сервере bootstrap механизм наименования сетевых интерфейсов значения не имеет.

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

Требования к программно-аппаратным ресурсам и конфигурации сети для развертывания сценария представлены в разделе Системные требования.

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

  1. Для корректной автоматизации развертывания AIC требуется предварительно настроить следующие VLAN:

    • для установки ОС с использованием PXE;

    • сети управления IPMI;

    • управляющего трафика (менеджмент сеть);

    • трафика СХД (в случае использования iSCSI);

    • трафика СРК.

  2. Должна быть возможность использовать одинаковые последние октеты IP-адресов для всех серверов AIC во всех сетях. То есть для каждой локальной ВМ и ВМ под управлением ПК СВ должна быть возможность задать одинаковый последний октет для всех сетей.

    Пример:

    Для развертывания AIC выделено три сети:

    • 192.168.22.0/24 — менеджмент сеть;

    • 10.22.22.0/24 — сеть СРК;

    • 10.205.17.0/24 — сеть СХД.

    В случае если в графическом инсталляторе или в файле с переменными для первого сервера управления ПК СВ будет задан адрес: 192.168.22.150, то, во время создания самой ВМ, ей будут добавлены все три сети и назначены адреса: 192.168.22.150, 10.22.22.150, 10.205.17.150.

  3. В случае использовании iSCSI, для доступа к СХД, должны быть настроены два LUN, которые предоставляются через сеть, выделенную под трафик СХД. Эти два LUN будут использованы как СХД ПК СВ. Логические и физические размеры секторов на LUN должны совпадать, в ином случае использование LUN как хранилища для ПК СВ типа BREST_LVM нельзя. Если возможности изменить размеры секторов нет, автоматизация установки AIC предоставляет код для подключения хранилищ типа LVM_LVM.

  4. Минимальный размер iSCSI LUN или OSD-дисков, который будет использоваться для хранилища данных ПК СВ — 150 ГБ в случае iSCSI LUN, или 335 ГБ в случае OSD-диска Ceph. В случае развертывания DCImanager, минимальный размер — 200 ГБ в случае iSCSI LUN, или 550 ГБ в случае OSD-дисков Ceph. DCImanager является необязательным компонентом AIC, и требует отдельного лицензирования. Такие размеры хранилища являются минимальными для возможности установки, в процессе эксплуатации количество занимаемого пространства будет увеличиваться. Минимальный размер iSCSI LUN или OSD-диска, который будет использоваться для хранилища образов ПК СВ — 50 ГБ в случае iSCSI LUN, или 100 ГБ в случае OSD-диска Ceph.

  5. Серверов ALD Pro может быть как два, так и три. Создание третьего сервера КД будет выполнено только в случае указания определенной переменной.

  6. Установочный сервер AIC (bootstrap сервер) и три основных сервера виртуализации ПК СВ должны быть размещены в едином сегменте сети (без промежуточных маршрутизаторов), обеспечивая коммутацию трафика на уровне L2.

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

Для установки необходим выделенный сервер или рабочая станция с установленной ОС СН Astra Linux версии не ниже 1.7.4 с графическим интерфейсом (GUI), уровень защищенности не важен. Рекомендуется использовать ALSE 1.7.4 без оперативных обновлений. На эту рабочую станцию будет установлен bootstrap.

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

Предполагается, что bootstrap сервер будет запущен в виде отдельной виртуальной машины на целевом сервере, или рабочей станции, имеющей выход в целевой VLAN (broadcast домен).

Установочный образ поставляется в виде Qcow2-файла, который необходимо скачать из личного кабинета.

Примечание

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

Поменять права можно выполнив команду:

sudo chown root:libvirt-qemu /var/lib/libvirt/images/<bootstrap_image_name>.qcow2

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

Установочный образ содержит:

  • ОС Astra Linux Special Edition (далее — ALSE) версии 1.7.6 с оперативным обновлением UU2, уровень защищенности «Орел»;

  • PXE сервер (DHCP, TFTP, FTP);

  • Графический инсталлятор AIC;

  • необходимые для развертывания AIC приложения и директории.

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

Минимальные требования к ВМ сервера bootstrap:

  • vCPU: 4 ядра;

  • RAM: 4 ГБ;

  • HDD: от 150 ГБ;

  • 2 адаптера Ethernet (в ВМ bootstrap сервера должно быть настроено 2 подсети: подсеть для PXE, подсеть для управляющей сети — менеджмент, по которой bootstrap сервер будет разворачивать AIC на всех серверах).

Примечание

Имя пользователя и пароль bootstrap сервера по умолчанию astra/astra.

К целевым серверам, которые будут являться клиентами PXE, должен быть добавлен сетевой интерфейс, подключенный к выделенному для PXE VLAN. Порты этого VLAN предпочтительно подключать в режиме access. Рекомендуемая пропускная способность портов — не менее 1 Гбит/с.

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

Нежелательно наличие работающих DHCP-серверов в этой сети, чтобы избежать сетевых проблем в ходе установки.

Для инсталляции AIC необходимо изменить 2 конфигурационных файла:

  • файл с переменными — /home/astra/aic-code/ansible/playbooks/group_vars/all.yml;

  • файл с адресацией всех серверов — /home/astra/aic-code/inventory.yml (далее — файл-инвентарь).

Примечание

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

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

Пример трех групп серверов для ALD Pro:

aldpro_server:
   hosts:
     dc1-test:

aldpro_replica:
   hosts:
     dc2-test:

aldpro_clients:
   children:
     aldpro_replica:
     brest_kvm_nodes:
     brest_fronts:

В этом примере есть три группы серверов, их имена — aldpro_server, aldpro_replica и aldpro_clients. В группу aldpro_server входит сервер с именем dc1-test, в группу aldpro_replica входит сервер с именем dc2-test. В группу aldpro_clients входят не серверы, а группы серверов, такие как aldpro_replica, brest_kvm_nodes, brest_fronts.

Подготовка bootstrap сервера#

Перед началом развертывания AIC необходимо загрузить на bootstrap сервер ISO компонентов облачной платформы (далее — ОП).

AIC 1.3.1 использует для развертывания сертифицированные ФСТЭК ISO-образы для каждого компонента ОП. На bootstrap сервере в домашней директории пользователя astra требуется организовать структуру папок. Для этого необходимо создать директорию с именем iso, полный путь до этой директории: /home/astra/iso. Она будет предназначена для хранения ISO-компонентов ОП.

В ней создать следующие директории: aldpro_iso, alse_iso, billmanager_iso, brest_iso, rubackup_iso. Каждая директория предназначена для ISO и их хэш-сумм конкретных компонентов AIC — ALD Pro, ALSE, BILLmanager, ПК СВ, RuBackup.

Создать эти директории можно командой:

mkdir -p /home/astra/iso/aldpro_iso /home/astra/iso/alse_iso /home/astra/iso/billmanager_iso /home/astra/iso/brest_iso /home/astra/iso/dci_manager_iso /home/astra/iso/rubackup_iso

После выполнения команды необходимо загрузить из личного кабинета Группы Астра на bootstrap сервер ISO-образ и файл с хэш-суммой каждого компонента AIC, — ALD Pro, ALSE, BILLmanager, ПК СВ, RuBackup. Разместить их следует в соответствующих директориях.

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

Файлы должны иметь указанные имена, рядом с каждым ISO (кроме ISO для RuBackup, DCImanager и BILLmanager) должен быть расположен файл с его хэш-суммой. ISO-образ для BILLmanager и файл с его md5 суммой изначально размещены на bootstrap сервере в нужной директории.

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

Пример структуры каталогов и файлов внутри директории /home/astra/iso:

/home/astra/iso/
├── aldpro_iso
│   ├── ALD_Pro_2.4.1.gost
│   └── ALD_Pro_2.4.1.iso
├── alse_iso
│   ├── base-1.7.4.11-23.06.23_17.13.iso
│   ├── base-1.7.4.11-23.06.23_17.13.iso.gost
│   ├── installation-1.7.6.15-15.11.24_17.20.iso
│   ├── installation-1.7.6.15-15.11.24_17.20.iso.gost
│   ├── installation-1.7.7.6-10.03.25_13.44.iso
│   └── installation-1.7.7.6-10.03.25_13.44.iso.gost
├── billmanager_iso
│   ├── billmgr.aic.iso
│   └── billmgr.aic.iso_md5sum.txt
├── brest_iso
│   ├── brest-3.3.3.uu1-for-astra-1.7.7.iso
│   └── brest-3.3.3.uu1-for-astra-1.7.7.iso.gost
├── dci_manager_iso
│   ├── dci6_repo.iso
│   └── dci_latest.iso
└── rubackup_iso
└── rubackup-release_2.4.0.42_astra-1.7.iso

Примечание

DCImanager является необязательным компонентом AIC. В случае его установки, — скачать нужные для него ISO (dci_latest.iso и dci6_repo.iso) можно на странице официальной документации. Репозиторий для ALSE 1.7.4.UU1 (base-1.7.4.11-23.06.23_17.13.iso) необходим только для DCImanager. Если в инсталляции AIC не планируется установка DCImanager — этот репозиторий и файл с его хэш-суммой не требуются.

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

dci_install: true

Значение true нужно указывать только в случае, если в инсталляции AIC планируется устанавливать DCImanager. В ином случае у переменной должно быть значение false. Этот параметр отвечает за необходимость верификации базового репозитория ALSE 1.7.4 с оперативным обновлением UU1, а также за дальнейшее монтирование этого ISO как репозитория на bootstrap сервер.

После подготовки структуры репозиториев ISO-образов необходимо проверить целостность этих образов (хэш-суммы и корректность загруженных ISO). Для этого на bootstrap сервере перейти в директорию /home/astra/aic-code и выполнить команду:

task iso_verify

Эта команда запустит автоматизацию проверки валидности скаченных ISO. Автоматизация проверит корректность расположения ISO в соответствующих директориях и соответствие хэш-сумм этих ISO с хэш-суммами, указанными в файлах .iso.gost.

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

../../_images/013_dop_code_example.png

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

Примечание

Выполнить проверку валидности скаченных ISO и их хэш-сумм можно также используя Графический инсталлятор AIC.

Установка ОС на целевые серверы#

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

  1. Найти и выписать MAC-адреса сетевых интерфейсов трех целевых серверов (будут использоваться в переменных установщика).

  2. Настроить RAID-массив: тома должны быть сконфигурированы заранее и иметь от 200 до 500 ГБ свободного пространства.

  3. Определить название целевого накопителя. (Как правило, это /dev/sda, для установки с использованием RAID-контроллера).

  4. Настроить UEFI целевых серверов, включив поддержку виртуализации (например, Intel vDT-x).

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

Примечание

При установке по сети рекомендуется использовать режим загрузки UEFI, по возможности избегая DUAL и Legacy BIOS. Если firmware сервера и сетевой карты предоставляет выбор между загрузкой по PXE или iPXE — необходимо использовать PXE.

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

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

Ранее установленные операционные системы и данные на этих серверах будут уничтожены.

Работа на bootstrap сервере на этом этапе выполняется осуществляется от пользователя root, либо с добавлением «sudo» к каждой команде.

Скрипты подготовки сервера автоматической сетевой установки ОС#

Автоматизированная сетевая установка ОС состоит из следующих этапов:

  1. Настройка и запуск необходимых служб (производится скриптом):

    • dhcpd — обеспечивает настройку временной сети;

    • tftpd — предоставляет загрузчик и ядро;

    • vsftpd — файловый сервер для репозиториев и других файлов.

  1. Создание файлов, необходимых для установки (производится скриптом):

    • grub.cfg — меню загрузки, с возможностью выбора ОС для установки, в контексте установщика AIC используется единственная опция по умолчанию;

    • recipe — т.н. файл рецепта, позволяющий установщику ОС создать партиции на диске, согласно заданным параметрам;

    • preseed — т.н. файл ответов, содержащий параметры установки ОС, которые в ручном режиме задавались бы пользователем;

    • postinst.sh — скрипт, исполняемый на финальном этапе установки.

  2. Перезапуск целевых серверов в режим загрузки по сети с последующей автоматической установкой ОС по сети (производится оператором/администратором).

Перед началом настройки нужно перейти в папку deploy_pxe_bash:

cd /home/astra/deploy_pxe_bash/

В папке находятся скрипты, облегчающие настройку сервера автоматической сетевой установки ОС.

Основные скрипты для настройки:

  • 01.deploy-services.sh — создает структуру каталогов, монтирует ISO-образы, настраивает и запускает сервисы dhcpd, tftpd, vsftpd;

  • 02.render-preseeding.sh — параметризует и размещает файлы preseed, grub.cfg, recipe и скрипты в нужных каталогах.

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

  • 99.clean-up.sh — в зависимости от аргументов, останавливает службы или удаляет результаты работы первых двух скриптов;

  • 98.backup.sh — делает резервную копию сгенерированных конфигурационных файлов. Предполагается к использованию при обращении в службу технической поддержки.

Инициализация значений параметров#

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

# полный путь к файлу переменных vars
/home/astra/deploy_pxe_bash/vars

Обязательному изменению подлежат:

  • название сетевого интерфейса DHCP;

  • MAC-адреса целевых серверов. MAC-адрес — адрес сетевого интерфейса на соответствующем целевом сервере, где происходит установка;

  • имена целевых серверов;

  • oбъем корневого раздела root, на котором будет установлена ОС.

Остальные переменные в файле vars могут быть оставлены по умолчанию.

Примечание

Количество целевых серверов — от 3 до 10.

Конфигурации целевых серверов должны совпадать по именам устройств накопителей (/dev/sdX), куда устанавливается операционная система, по объему этих накопителей (допустим объем, превышающий тот, что будет указан в переменной размера корневой файловой системы) и по имени устройства сетевого интерфейса PXE.

Переменные файла vars

Указание версии ОС для установки:

OSVERSIONS="1.7.7.6"

Где OSVERSIONS — версия ALSE. Так как для серверов виртуализации ПК СВ Брест используется ALSE 1.7.7.6, то переменная должна принять именно такое значение.

Название интерфейса на bootstrap сервере, имеющего выход в, выделенную для сетевой установки, сеть:

DHCPINT='eth1'

Примечание

Интерфейсу, указанному в переменной DHCPINT, будет назначен дополнительный временный IP-адрес 10.0.9.11. Во время установки по сети всем серверам AIC будет назначен IP-адрес из этой временной сети.

Сетевая коммуникация во время установки происходит в L2 домене и не использует маршрутизацию. Адресное пространство сети существует только в момент установки, поэтому сеть и называется временной. Изменение IP-адреса этой временной сети допускается только в случае возникновения наложения (конфликта) IP-адресов с существующими сетями.

Имена серверов виртуализации (значение hostname, которое установится на целевых машинах) и MAC-адреса интерфейсов целевых серверов, которые подключены к выделенному VLAN (MAC-адреса записываются в файл /etc/dhcp/dhcpd.conf):

# target 1
TARGETMAC1=88:88:88:ee:ee:ee
TARGETHOSTNAME1=aichost1

# target 2
TARGETMAC2=88:88:88:ee:ee:ee
TARGETHOSTNAME2=aichost2

# target 3
TARGETMAC3=88:88:88:ee:ee:ee
TARGETHOSTNAME3=aichost3

Название интерфейса, в сети которого производится установка. В случае, если наименование интерфейса неизвестно, или в процессе установки ОС возникли ошибки с получением сетевых настроек, в значении данной переменной нужно указать auto:

NETCFGIFACE=auto

Метод разбивки целевого диска: обычные разделы (regular) или LVM. Рекомендуется оставить значение по умолчанию и менять только в случае установки ОС на LVM тома:

METHODREG=1
METHODLVM=0

Во время разбивки диска на целевом сервере создаются разделы swap и / (root). Предполагаемые размеры этих разделов указываются в мегабайтах (значения указанного диапазона записываются в файл recipe в разделе для partman):

SWAPSIZE=8196
SWAPMAXSIZE=8196
ROOTSIZE=40000
ROOTMAXSIZE=50000

Имя пользователя и пароль для выставления на целевой ОС:

USERNAME='aicadmin'
PASSWORD='astra-01'

Примечание

По умолчанию в процессе создания файла preseed скрипт заменит и в самом файле preseed, и в файле vars пароль, который задается открытым текстом, захешированным значением, полученным из вывода утилиты openssl passwd -6. При необходимости сменить задаваемый пароль нужно ввести новое значение открытым текстом и запустить скрипт еще раз. При повторном запуске скрипта без изменения значения пароля (при наличии захешированного) используется ранее заданное значение.

Название целевого диска для установки ОС. Рекомендуется оставить значение по умолчанию (записывается в файл preseed):

TARGETDISK=sda

Набор пакетов для установки. Записывается в файл preseed. По умолчанию производится установка с графическим интерфейсом, но в закомментированном виде представлены примеры для установки без графической оболочки:

# без графической оболочки
BASEPACKAGES="Base"
PACKAGES="ssh htop ifenslave vlan bridge-utils parted bash-completion uuid-runtime open-iscsi astra-kvm"

# с графической оболочкой (рекомендуется)
BASEPACKAGES="Base, Fly, Fly-ssh, Fly-virtualization"
PACKAGES="ssh htop ifenslave vlan bridge-utils parted bash-completion xrdp firefox uuid-runtime"

Значения оставшихся переменных, не перечисленных выше, рекомендуется оставить по умолчанию.

Установка ОС по сети#

После редактирования параметров и расположения iso-образов в /iso, требуется запустить скрипты:

Для запуска скриптов утилитой task, находясь в директории /home/astra/deploy_pxe_bash, выполнить команду:

task pxe_all

Примечание

Исполнение команды task pxe_all эквивалентно последовательному запуску скриптов:

sudo ./01.deploy-services.sh
sudo ./02.render-preseeding.sh

Ход исполнения каждого из скриптов журналируется, журнал записывается в директроию:

deploy_pxe_bash/logs/pxe_server_deploy.log

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

Прежде, чем перезапускать целевые машины в режим сетевой загрузки для последующей установки, рекомендуется ознакомиться с подразделом «Настройка сети на целевых машинах»

После успешного завершения установки ОС на серверы, требуется остановить сервисы PXE.

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

task pxe_clean

Примечание

Исполнение команды task pxe_clean эквивалентно запуску:

sudo ./99.clean-up.sh cleanup

В ходе очистки:

  • останавливаются службы dhcpd, tftpd, vsftpd;

  • удаляются сгенерированные конфигурационные файлы;

  • удаляется IP-адрес временной сети;

  • размонтируются ISO-образы, используемые при установке.

Загруженные ISO-образы не удаляются.

Настройка сети на целевых машинах#

По умолчанию настройка постоянной конфигурации сети на целевых серверах производится после установки ОС.

Передача файлов конфигурации сетевых интерфейсов на целевые серверы

Для настройки сетевых подключений используется пакет ifupdown, с основным файлом конфигурации /etc/network/interfaces. Так как выполнение конфигурирования сети, описываемая этим файлом, — сложный процесс, правка и применение этого файла на только что установленной системе может занять определенное время.

При наличии готовых файлов interfaces администратор может выложить эти файлы в папке скриптов /srv/ftp/scripts с названием вида:

interfaces_<MAC-адрес>

Где <MAC-адрес> — адрес сетевого интерфейса на соответствующем целевом сервере, где происходит установка. MAC-адрес должен быть в нижнем регистре без разделителей.

Пример:

  • для целевого сервера А, подключенного к сети с PXE сервером интерфейсом с адресом: 88:99:00:cc:bb:aa, наименование файла будет иметь вид: interfaces_889900ccbbaa

  • для целевого сервера Б с адресом: 88:99:00:cc:bb:bb — interfaces_889900ccbbbb.

Имена интерфейсов можно узнать, загрузившись в окружение с включенным механизмом predictable names (убрав из параметров загрузки net.ifnames=0).

На финальном этапе установки скрипт postinst.sh, исполняемый на сервере, скачивает предназначенный этому серверу файл interfaces, основываясь на своем MAC-адресе. Если этого не происходит, генерируется файл по умолчанию, где определен только PXE-интерфейс сервера, получающий адрес по DHCP, т.е. в этом случае сервер после загрузки ОС получит тот же адрес, который был получен для сетевой установки. Таким образом Администратору предоставляется сетевой доступ не только через BMC, но и через CLI

Во избежание проблем с установкой, выкладываемые файлы должны быть корректными и не содержать ошибок. Пакеты ifenslave, vlan и bridge-utils для настройки соединений типа bond, vlan и bridge указаны в файле preseed и устанавливаются автоматически. Как правило, этих пакетов достаточно для нужд серверов виртуализации.

Механизмы именования сетевых интерфейсов

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

  1. Традиционный метод: система назначает имя ethX в момент инициализации интерфейса (определяется в параметрах загрузки: net.ifnames=0).

  2. Механизм predictable names назначает имя вида eno1 или ens1p0, в соответствии с расположением устройства в древе PCI.

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

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

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

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

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

В процессе автоматической установки ОС из параметров загрузки убирается параметр net.ifnames=0, что включает механизм predictable names. Для его отключения следует:

  1. На уже установленной ОС вернуть параметр net.ifnames=0, отредактировав в файле /etc/default/grub строку GRUB_CMDLINE_LINUX_DEFAULT:

    #GRUB_CMDLINE_LINUX_DEFAULT="<param> net.ifnames=0 <param>"

  2. Обновить grub.cfg командой:

    update-grub

  3. Привязать соответствующие имена к MAC-адресам интерфейсов в новом правиле udev:

    # /etc/udev/rules.d/10-network-names.rules
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="aa:bb:cc:dd:ee:11", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="aa:bb:cc:dd:ee:22", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="aa:bb:cc:dd:ee:33", NAME="eth2"

  4. Поставить systemd запрет на переписывание переименованных интерфейсов, выполнив команду:

    sudo ln -s /dev/null /etc/systemd/network/99-default.link

  5. Отредактировать файл /etc/network/interfaces, заменив или добавив туда новые именования:

    auto enp1s0f0
iface enp1s0f0 inet manual

auto enp1s0f1
iface enp1s0f1 inet manual

auto bond0
iface bond0 inet manual
...

auto eth1
iface eth1 inet manual

auto eth2
iface eth2 inet manual

auto bond0
iface bond0 inet manual
...

Удалять или комментировать старые имена до следующей загрузки не требуется. При возникновении проблем, сервер применит сетевые настройки с ранее заданными именами.

Генерация SSH-ключа пользователя#

Для последующего выполнения Ansible-плейбуков необходимо обеспечить наличие SSH-ключа на всех целевых серверах. Для добавления SSH-ключей на этапе установки ОС, в конфигурационном файле следует оставить значение по умолчанию.

GENERATESSHKEY=1

Скрипт автоматически сгенерирует SSH-ключ и разместит его в указанной директории файлового сервера. На завершающем этапе установки операционной системы публичная часть ключа будет скопирована в файл ~/.ssh/authorized_keys целевого пользователя (по умолчанию — aicadmin), что обеспечить доступ Ansible без дополнительной ручной настройки.

Возможные ошибки на этапе установки ОС#

  1. Сервис DHCP возвращает ошибки при попытке запуска.

    • удостовериться, что сетевому интерфейсу, имеющему выход в PXE-сеть, был назначен второй адрес: 10.0.9.11/24;

    • удостовериться, что в файле с переменными было корректно определено значение переменной DHCPINT. В переменной должно быть указано имя сетевого интерфейса PXE-сети, с временно назначенным вторым адресом 10.0.9.11/24.

  2. Целевой сервер не загружается в среду установки.

    • удостовериться, что в UEFI целевого сервера в разделе Boot для загрузки выбран корректный сетевой интерфейс, имеющий доступ к PXE-сети (зависит от модели сервера);

    • во время загрузки посмотреть статус DHCP, где логируется событие выдачи IP-адреса;

    • удостовериться, что в секции host в файле конфигурации DHCP (/etc/dhcp/dhcpd.conf) корректно заполняются данные;

    • удостовериться, что адрес сервера установки уникален в сети.

  3. Целевой сервер загрузился в среду установки, но программа-установщик не получает настройки сети.

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

    • удостовериться, что секции host в файле конфигурации DHCP раскомментированы и корректно заполнены;

    • посмотреть название сетевого интерфейса и указать его меню GRUB в секции netcfg/choose_interface (файл /srv/tftp/debian-installer/amd64/grub/grub.cfg);

    • войти в shell (для запуска терминала нажать Alt+F2…F7) и проверить получение адреса командой:

      udhcpc -i <имя_интерфейса>

    • исключить нахождение других работающих DHCP-серверов в той же сети.

  4. Установщик выдает ошибку на этапе создания разделов жесткого диска:

    • удостовериться в правильности указанных размеров партиций в файле /srv/ftp/recipes/recipe_regular;

    • удостовериться в правильности указанного названия целевого диска в файле /srv/tftp/se/preseeds/preseed_1.7.7.6_regular.cfg.

  5. Целевой сервер успешно загрузился после установки ОС, но сетевая конфигурация не была применена.

    • в общем случае настройка сети производится после установки и загрузки в новую ОС;

    • удостовериться, что подготовленный файл interfaces (при наличии) назван корректно (interfaces_<MAC-адрес целевого сервера>) и был расположен в папке scripts до запуска скриптов и начала установки;

    • удостовериться в отсутствии ошибок в файле interfaces;

    • удостовериться, что пакеты vlan, bridge-utils и ifenslave были установлены (перечислены в файле preseed в числе других дополнительных пакетов).

Действия после установки ОС#

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

  1. Настроить сетевые интерфейсы на целевых серверах, в соответствии с утвержденной сетевой топологией. Для этого добавить сетевые мосты для трех сетей (менеджмент сеть, сеть для трафика СРК, сеть для трафика СХД) на каждом из целевых серверов. Сетевой мост для сети СХД нужен только в случае если как СХД будет использован iSCSI либо иной вариант СХД требующий выделенную сеть.

    Сетевые мосты, относящиеся к одной сети, должны иметь одинаковые имена на всех серверах. Например, если мост менеджмент сети на первом сервере называется br200, то на втором и на третьем серверах он должен называться так же.

    Пример готовой конфигурации сети в файле /etc/network/interfaces:

    source /etc/network/interfaces.d/*

# --- networks in use:
# vlan 200 - management       : 192.168.22.0/24
# vlan 170 - iSCSI            : 10.205.17.0/24
# vlan 169 - backup           : 10.22.222.0/24

# -------------------------------------------------------------
auto lo
iface lo inet loopback

# bond0 lacp

auto eno1
iface eno1 inet manual

auto eno2
iface eno2 inet manual

auto bond0
iface bond0 inet manual
    mtu 9000
    bond-slaves eno1 eno2
    bond-mode 802.3ad
    bond-miimon 100
    bond-lacp-rate fast
    bond-xmit-hash-policy layer3+4
    bond-updelay 200
    bond-downdelay 200

# -------------------------------------------------------------
# vlan 200 - mgmt

auto bond0.200
iface bond0.200 inet manual
    vlan-raw-device bond0

auto br200
iface br200 inet static
    mtu 9000
    address 192.168.22.74/24
#    address 192.168.22.75/24
#    address 192.168.22.76/24
    bridge_ports bond0.200
    bridge_stp on

# -------------------------------------------------------------
# vlan 170 - iSCSI

auto bond0.170
iface bond0.170 inet manual
    vlan-raw-device bond0

auto br170
iface br170 inet static
    mtu 9000
    address 10.205.17.14/24
#    address 10.205.17.15/24
#    address 10.205.17.16/24
    bridge_ports bond0.170
    bridge_stp on

# -------------------------------------------------------------
# vlan 169 - backup

auto bond0.169
iface bond0.169 inet manual
    vlan-raw-device bond0

auto br169
iface br169 inet static
    address 10.22.22.14/24
#    address 10.22.22.15/24
#    address 10.22.22.16/24
    bridge_ports bond0.169
    bridge_stp on

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

  2. Удостовериться в наличии беспарольного доступа к серверам по SSH с bootstrap сервера. Ключи создаются и распространяются на этапе установки ОС, но, если это не было сделано, требуется сгенерировать ключи командой:

    ssh-keygen

    Затем разместить ключи на каждом сервере командой:

    ssh-copy-id.

    Обе команды запускаются на bootstrap сервере от имени пользователя astra.

  3. В файле /etc/hosts на bootstrap сервере добавить записи обо всех целевых серверах и серверах виртуализации, которые предназначены для ресурсов ПК СВ и ALD Pro. Записи должны включать в себя FQDN (это доменное имя будет использоваться при развертывании AIC).

    Пример записей о серверах:

    /etc/hosts
192.168.22.74 aichost1.aicstand.ru aichost1
192.168.22.75 aichost2.aicstand.ru aichost2
192.168.22.76 aichost2.aicstand.ru aichost3

192.168.22.233 node1-test.aicstand.ru node1-test
192.168.22.234 node2-test.aicstand.ru node2-test
192.168.22.235 node3-test.aicstand.ru node3-test

192.168.22.230 dc1-test.aicstand.ru dc1-test
192.168.22.231 dc2-test.aicstand.ru dc2-test

192.168.22.240 rubackup-server.aicstand.ru rubackup-server
192.168.22.241 monitoring.aicstand.ru monitoring
192.168.22.242 bill-manager.aicstand.ru bill-manager
192.168.22.243 dci-manager.aicstand.ru dci-manager
192.168.22.244 help.aicstand.ru help
192.168.22.245 marketplace.aicstand.ru marketplace

Пример сетевой конфигурации, используемой в этой инструкции:

  • основные 3 сети:

    • 192.168.22.0/24 — Менеджмент сеть, создан сетевой мост br200;

    • 10.22.22.0/24 — Сеть СРК, создан сетевой мост br169;

    • 10.205.17.0/24 — Сеть СХД, создан сетевой мост br170.

  • адреса целевых серверов:

    • 192.168.22.74;

    • 192.168.22.75;

    • 192.168.22.76.

  • адреса cерверам управления ПК СВ:

    • 192.168.22.233;

    • 192.168.22.234;

    • 192.168.22.235.

  • адреса cерверов Контроллера Домена:

    • 192.168.22.230;

    • 192.168.22.231.

  • адрес портала iSCSI:

    • 10.205.17.90.

  • адреса ВМ под управлением ПК СВ:

    • 192.168.22.240 — СРК RuBackup;

    • 192.168.22.241 — Astra Monitoring;

    • 192.168.22.242 — BILLmanager;

    • 192.168.22.243 — DCImanager;

    • 192.168.22.244 — Справочный центр;

    • 192.168.22.245 — Marketplace.

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

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

После сетевой установки ОС на серверах необходимо оставить настроенным сетевой интерфейс, подключенный к сети, используемой для установки.

Установка AIC#

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

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

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

task iso_deploy

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

Примечание

Монтирование является временным, в случае выключения или перезагрузки bootstrap сервера — ISO-образы потребуется монтировать заново.

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

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

На каждом из трех серверов создается виртуальная машина (далее ВМ) с одним сервером управления и одним сервером КД.

Примечание

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

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

Пример вида файла /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.

Сетевые мосты, указанные в переменных management_bridge, backup_bridge и storage_bridge (при использовании iSCSI) должны быть предварительно созданы на всех трех серверах и иметь одинаковые имена.

Использование одинаковой сети для менеджмент сети и сети СРК не допускается.

В случае, если для инсталляции AIC в качестве СХД планируется использовать не iSCSI, а FC, или иной тип хранилища, для которого не нужна выделенная сеть, переменные storage_bridge и stornetwork нужно закомментировать. В таком случае виртуальная сеть СХД не будет создана и не будет подключена к ВМ серверам управления ПК СВ.

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

Переменная

Описание

frnthost1_in_kvm

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

aldphost1_in_kvm

будет ли ВМ для первого сервера КД развернута на первом целевом сервере

frnthost2_in_kvm

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

aldphost2_in_kvm

будет ли ВМ для второго сервера КД развернута на втором целевом сервере

frnthost3_in_kvm

будет ли ВМ для третьего сервера управления ПК СВ развернута на третьем целевом сервере

aldphost3_in_kvm

будет ли ВМ для третьего сервера КД развернута на третьем целевом сервере

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

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

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

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

Примечание

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

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

Третья строка из части файла-инвентаря выше (ansible_user: "astra") отвечает за имя пользователя на всех серверах кроме тех, которым пользователь задан отдельно, как например для трех целевых серверов (aichost1..3). Значение переменной vm_username должно совпадать со значением в третьей строке из части файла-инвентаря выше, то есть со значением глобальной переменной ansible_user.

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

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

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

Автоматизация создания локальных ВМ использует PXE на bootstrap сервере, в случае, если интерфейс с выходом в PXE-сеть на bootstrap сервере или на первом сервере AIC были убраны — их необходимо вернуть.

Важно предварительно обеспечить беспарольный доступ по SSH пользователю astra до указанного в файле-инвентаре пользователя на каждом их трех серверов. В случае, если во время установке ОС по PXE у переменной GENERATESSHKEY было значение 1 — беспарольный доступ был обеспечен еще во время установки ОС.

При развертывании ОП AIC в виртуальном окружении требуется проверить содержимое файла .pxe_interface на первом сервере из группы vm_hosts в домашней директории указанного для сервера пользователя. Файл должен содержать в себе одну строку, в которой будет указан сетевой интерфейс имеющего выход в сеть PXE. Указывать в файле имя сетевого моста не допускается.

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

task vm_deploy

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

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

task info

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

task info

Ниже представлен полный список аргументов с их описанием для команды task
Для проверки целостности скаченных из личного кабинета ISO запустите  task iso_verify
Для установки и настройка apache2, монтирование ISO компонентов AIC как репозитории на этот bootstrap, запустите  task iso_deploy
Для создания ВМ --- будущих серверов КД и серверов управления Брест запустите  task vm_deploy
Для добавления на все физические серверы и ВМ расположенные на них репозитории с текущего bootstrap запустите  task add_repos
Для полной инсталляции ALD Pro запустите task aldpro_deploy
Для полной инсталляции Брест запустите task brest_deploy
Для создания подразделений в контроллере домена запустите task aldpro_create_ou
Для получения 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_ntp:                      Настройка NTP на серверах и клиентах ALD Pro
* aldpro_ntp_after_brest:          Настройка NTP на ВМ под управлением ПК СВ Брест
* 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_changes_hosts:             Добавление записей в /etc/hosts о серверах ПК СВ Брест
* brest_deploy:                    Полная инсталляция ПК СВ Брест
* brest_front:                     Инсталляция серверов управления ПК СВ Брест
* brest_kvm:                       Инсталляция серверов виртуализации ПК СВ Брест
* brest_kvm_reboot:                Перезагрузка серверов виртуализации
* 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:                 Инсталляция клиенстcкой части RuBackup
* rubackup_deploy:                 Инсталляция сервера и клиентов RuBackup
* rubackup_post_install:           Авторизация, настройка клиентов RuBackup
* rubackup_server:                 Инсталляция сервера RuBackup
* rubackup_token:                  Генерация свежего токена для RuBackup
* terraform_clean:                 Обнуление состояния terraform
* terraform_config:                Настройка переменных и ВМ для создания в Брест и синхронизация токена доступа на серверах управления
* 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:                   Создание ВМ на третьем сервере

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

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

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

vm_template

создание шаблонных ВМ, Qcow2 файлов, которые будут использованы для ВМ серверов управления `` ПК СВ`` «Брест» и КД ALD Pro

vm_first_host

создание ВМ на первом сервере виртуализации

vm_second_host

создание ВМ на втором сервере виртуализации

vm_third_host

создание ВМ на третьем сервере виртуализации

vm_post_deploy

увеличение размера дисков ВМ до значения, указанного в переменной vm_disk_size

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

  1. Выполняется проверки корректности значений переменных для этого этапа, проверки наличия на серверах AIC указанных в переменных сетевых мостов.

  2. Добавляются репозитории ALSE с bootstrap сервера.

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

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

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

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

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

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

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

  10. На первом из трех целевых серверов создаются шаблонные ВМ, используя PXE с bootstrap, устанавливая ОС СН ALSE 1.7.6.UU2 и ALSE 1.7.7 по сети из ISO.

  11. Для каждого шаблона ВМ создается свой файл с хэш-суммой, все файлы шаблонных ВМ копируются на bootstrap сервер.

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

  13. Созданным ВМ назначаются статичные IP-адреса согласно файлу-инвентарю, а также с bootstrap сервера копируется публичный SSH-ключ.

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

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

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

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

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

После развертывания ВМ на них необходимо добавить локальные репозитории с bootstrap сервера — репозитории ALSE 1.7.6.UU2 для серверов КД, а также 1.7.7 для серверов управления и виртуализации ПК СВ. Также на этом этапе подключается репозиторий ПК СВ 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 заполнялось на этапе развертывание ВМ для серверов управления ПК СВ и серверов КД. Повторно менять ее значение не нужно, так как на трех целевых серверах в файле /etc/hosts уже есть записи, содержащие указанное в этой переменной доменное имя.

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

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

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

Пароль администратора КД должен:

  • состоять минимум из 8 символов;

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

  • не содержать в себе следующие спецсимволы: $, |, !, #, <, >, \, /, (, ).

После заполнения файла с переменными необходимо внести изменения в файл-инвентарь /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 до этих серверов.

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

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

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

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

Примечание

Несмотря на разделение серверов КД на лидера и реплику, все серверы КД равноправны. Между ними будет настроена двунаправленная репликация с периодичностью синхронизации баз данных раз в 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 task aldpro_post_scripts

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

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

Команда

Описание

aaldpro_server

инсталляция серверной части ALD Pro, лидера КД

aldpro_client

инсталляция клиентской части ALD Pro

aldpro_deploy_replica

инсталляция реплик ALD Pro

aldpro_post_scripts

форсирование настройки реплик КД, настройка DNS

aldpro_ntp

настройка NTP на серверах и клиентах ALD Pro

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

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

https://<FQDN лидера КД>

Имя администратора — admin, пароль задавался в переменной aldpro_admin_password.

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

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

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

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

#########
# Brest #
#########
brest_version: "3.3.3.uu1"
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"

Где:

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

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

  • состоять минимум из 8 символов;

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

  • не содержать в себе следующие спецсимволы: $, |, !, #, <, >, \, /, (, ).

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

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

  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 к этим серверам управления.

Примечание

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

В случае если серверы виртуализации планируется вынести на отдельные серверы, или использовать большее количество серверов виртуализации, их следует добавить в группу 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, выполняющего резервное копирование базы данных Кластер`а, при условии, что текущий сервер является лидером кластера управления :term:`ПК СВ. Резервная копия базы данных помещается в каталог /backup, расположенный на этих же серверах. Также скрипт ротирует резервные копии, с периодичностью в 15 дней. Выполнение скрипта добавляется в таблицу планировщика задач cron, с периодичностью запуска скрипта каждый день, в 00:05.

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

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

sudo 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.

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

https://raftleader.aicstand.ru

Примечание

Логин указывался в переменной freeipa_brestadmin, а пароль в переменной freeipa_brestadmin_pass.

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

Создание OU (Organizational Units) в контроллере домена.#

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

docs/installation/011_dop_domain_structure.png

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

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

task aldpro_create_ou

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

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

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

Примечание

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

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

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

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

  1. Установка пакетов iSCSI и получение IQN инициаторов;

  2. Подключения iSCSI LUN;

  3. Добавление двух iSCSI LUN как хранилищ ПК СВ.

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

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

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

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

task iscsi_iqn

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

../../_images/mu_001_console.png

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

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

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

bashtask iscsi_connect

После выполнении автоматизации, вызываемой этой командой, ко всем серверам будут подключены iSCSI LUN. Будут подключены все LUN, раздаваемые указанным адресом, но для хранилищ ПК СВ будут использованы только два 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 байт

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

task iscsi_brest_lvm_datastore

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

Примечание

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

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

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

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

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

task iscsi_lvm_lvm_datastore

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

onedatastore list

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

root@node1-test:~# onedatastore list
  ID NAME                SIZE AVA CLUSTERS IMAGES TYPE DS      TM      STAT
 100 lvm-lvm-system    500.0G 100 0             0 sys  -       lvm_lvm on
 101 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

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

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

Так как хранилища типа BREST_LVM используют кластерную блокировку SAN-Lock, очистка LUN должна быть разделена на 2 этапа:

  • удаление групп томов;

  • удаление физических томов.

Перед началом процесса удаления компонентов LVM необходимо выполнить следующие шаги:

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

  • удостовериться, что на всех серверах, входящих в Кластер Brest_LVM, включена кластерная блокировка, то есть в файле /etc/lvm/lvm.conf у переменной use_lvmlockd установлено значение 1.

Примечание

Все действия выполняются под учетной записью пользователя root.

Для удаления структуры Brest_LVM выполнить следующие действия:

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

    pvs:

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

      <pre class="western"><span style="color: rgb(255,0,0);">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</span></pre>

Где:

``</dev/sda>`` и ``</dev/sdb>`` --- имена блочных устройств, используемых в физических томах;

``<vg-one-100>`` --- имя группы томов для хранилища с ID 100 на физическом томе ``/dev/sda``;

``<vg-one-101>`` --- имя группы томов для хранилища с ID 101 на физическом томе ``/dev/sdb``.

  2. Для остановки работы системы блокировок LVM, на всех серверах, входящих в Кластер Brest_LVM, кроме текущего лидера RAFT, выполнить команду:

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

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

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

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

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

  5. Выключить кластерную блокировку. Для этого в файле /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

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

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

В ПК СВ будут созданы две сети — сеть управления (менеджмент) и сеть СРК. Количество создаваемых виртуальных машин можно задать вручную в файле-инвентаре. Для каждого компонента 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_vms_network_name_bkp: "Backup"

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: "100"
def_infra_vms_system_ds_id: "101"

Где:

Параметр

Описание

def_infra_vms_network_name_mgmt

имя, которое будет назначено менеджмент сети в ПК СВ

def_infra_net_size_bkp

количество адресов сети СРК в ПК СВ

def_infra_vms_image_url

путь до Qcow2-образа для ВМ под управлением ПК СВ на bootstrap сервере (необходимо оставить без изменений)

def_infra_marketplace_image_url

путь до Qcow2-образа Market place ПК СВ на bootstrap сервере (необходимо оставить без изменений)

def_infra_vms_image_ds_id

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

def_infra_vms_system_ds_id

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

Необходимые для изменений блоки файла-инвентаря /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 — группа серверов, в которой должно быть указано имя ВМ, предназначенной для Market place.

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

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

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

Переименование групп не допускается.

Примечание

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

Развертывание сетей и ВМ под управлением сетей состоит из двух частей:

  1. Конфигурирование файлов автоматизации после заполнения файла с переменными и файла-инвентаря, и непосредственно развертывание.

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

    task terraform_config

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

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

    Перед повторным выполнением команды task terraform_config необходимо выполнить команду:

    task terraform_clean

    Команда task terraform_clean очищает созданные командой task terraform_config конфигурационные файлы.

  2. Для развертывания сетей, в директории /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 EXIST, что и будет обозначать различия между реальным состоянием инфраструктуры, и состоянием описанным в файле. Реальное состояние инфраструктуры и состояние, описанное в файле, всегда должно быть идентичным.

Команда 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 также будет выполнена настройка службы синхронизации времени Chrony. Настройка заключается в виде изменения групповой политики автоматического изменения конфигурационного файла Chrony. При необходимости запустить только автоматизацию этой донастройки можно выполнив команду:

task aldpro_ntp_after_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 редакции «Hosting&Cloud».

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

  1. Активировать лицензию Портала самообслуживания. Для этого:

    1. Подключиться по SSH к ВМ, выполнив в интерфейсе командной строки команду:

      ssh <имя_сервисного_пользователя>@<IP_адрес_портала>

    2. Получить идентификатор установки inode_id, выполнив команду:

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

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

      locadm@bill-manager:~$ sudo -i ls -i /usr/local/mgr5/etc/billmgr.lic | cut -d' ' -f1
427636
locadm@bill-manager:~$

      Примечание

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

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

    3. Запросить лицензию в Личном кабинете ISPsystem , либо в службе технической поддержки ISPpsystem, указав значение inode_id, а также номер приобретенной лицензии. Лицензия имеет длину около 2000 символов.

      Примечание

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

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

      sudo echo <содержимое_файла_полученной_лицензия> > /usr/local/mgr5/etc/billmgr.lic

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

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

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

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

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

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

Примечание

По завершении работы автоматизации, на сервер с BILLmanager в файл /etc/hosts будет добавлена запись:

127.0.0.1 download.ispsystem.com

Данная запись ускорит работу веб-интерфейса BILLmanager в закрытом контуре. В случае установки AIC в открытом контуре, — данную запись необходимо удалить либо закомментировать.

В случае, если BILLmanager будет переустановлен на этой же ВМ, запись нужно будет предварительно удалить.

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

    sudo passwd

    Примечание

    Если пароль не был задан вручную, (по умолчанию пароль для пользователя root не задается), его необходимо задать на данном этапе.

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

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

    Примечание

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

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

    ../../_images/014_dop_billmanager_registration.png

  4. Ознакомиться с условиями Лицензионного соглашения и нажать на кнопку Согласен в правой нижней части экрана:

    ../../_images/45_BillMGR_accept.png

  5. Выполнить настройку Портала самообслуживания. Для этого:

    1. В открывшемся окне вкладки Обязательные настройки:

      • в поле Имя сервера указать имя сервера Портала самообслуживания;

      • в поле Часовой пояс в выпадающем списке выбрать соответствующий часовой пояс;

      • поле Время сервера будет заполнено автоматически, в соответствии с указанным часовым поясом;

      • в поле Обновлять ПО автоматически в выпадающем списке выбрать оптимальный вариант;

      • в поле Наименование провайдера задать название провайдера;

      • в поле URL биллинга сохранить значение по умолчанию;

      • в поле Страна в выпадающем списке выбрать соответствующую страну;

      • в поле Валюта в выпадающем списке выбрать валюту для расчетов;

      • в поле Язык по умолчанию в выпадающем списке выбрать требуемый язык;

      • Нажать на кнопку Далее:

      ../../_images/46_BillMGR_initial_setup.png

    2. В открывшемся окне вкладки Дополнительные настройки:

      • в полях Логин, Пароль и Подтверждение указать учетные данные Пользователя;

      • в полях ФИО и Email указать контактные данные Пользователя;

      • в поле Доступ с панели управления в выпадающем списке выбрать оптимальное значение;

      • если необходимо привязать сессию к IP, поставить соответствующий флаг;

      • нажать на кнопку Далее:

      ../../_images/47_BillMGR_initial_setup_2.png

    3. В открывшемся окне вкладки Создание компании:

      • в поле Юридический статус в выпадающем списке выбрать соответствующий статус;

      • в поле Наименование указать название компании;

      • нажать на кнопку Завершить установку:

      ../../_images/48_BillMGR_Initial_company.png

    4. Получить ID провайдера, выполнив следующие действия:

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

        • во вкладке Провайдер — Провайдеры основного меню слева Портала самообслуживания нажать на кнопку Создать:

          ../../_images/005_dop_providers_BILL.png

        • в открывшемся окне Создание нового провайдера задать наименование нового провайдера, e-mail для отправки уведомлений, URL биллинга и валюту расчетов. Остальные поля не обязательны к заполнению и могут остаться пустыми. Нажать на кнопку ОК:

          ../../_images/021_bill_provider_add.png

        Примечание

        Создание провайдера не является обязательным шагом. Может быть использован провайдер, созданный системой по умолчанию.

      • для отображения ID Провайдера в таблица свойств всех провайдеров во вкладке Провайдер — Провайдеры в меню Настройка таблицы включить отображение параметра ID. Нажать на кнопку Найти:

      ../../_images/006_dop_provider_ID_BILL.png

      Таблица свойств провайдеров будет дополнена столбцом с их идентификаторами:

      ../../_images/007_dop_provider_ID1_BILL.png

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

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

    task bill_manager_ldap

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

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

  1. Перед развертыванием СРК необходимо изменить, относящиеся к ней, переменные в файле `/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 и администратору БД СРК может быть задан одинаковый пароль (не рекомендуется в продуктивной среде).

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

    task rubackup_deploy

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

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

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

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

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

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

Полученный CSRF-токен REST API необходимо авторизовать, для этого:

  1. В веб-браузере ВМ с СРК перейти по адресу:

    https://api.rubackup.local:5656/api/v1

  2. В верхнем правом углу открывшегося окна нажать на кнопку Authorize:

    ../../_images/010_dop_rubackup_api.png

  3. В открывшемся окне ввести полученный в выводе CSRF-токен.

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

Примечание

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

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

sudo apt install virt-viewer

Далее на Портале Администратора загрузить файл для ПО Virt Viewer либо выбрать подключение к консоли VNC через веб-браузер:

../../_images/016_dop_vnc.png

При подключении с использованием ПО Virt Viewer, открыть скаченный файл командой:

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

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

task rubackup_server
task rubackup_client
task rubackup_api
task rubackup_post_install
task rubackup_post_brest
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 нужно генерировать и авторизовать заново. Для выполнения генерации нового токена, без необходимости запускать весь процесс развертывания заново, на Bootstrap сервере в директории /home/astra/aic-code выполнить команду:

task rubackup_token

Для проверки работоспособности:

  1. В графической сессии виртуальной машины с сервером RuBackup, в терминале выполнить команду:

    rbm

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

  2. В открывшемся окне для входа в Приложение:

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

    • в поле Имя пользователя указать rubackup;

    • в поле Пароль указать значение переменной rubackup_server_psql_password_rubackup

    • в поле Тип аутентификации оставить значение по умолчанию.

    • нажать на кнопку Войти:

    ../../_images/71_rubackup.png

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

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

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

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

    Примечание

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

    Порядок действий на данном этапе:

    1. На Портале администратора выбрать пункт основного меню слева Сеть — Сетевые шаблоны и в открывшемся окне Шаблоны виртуальных сетей нажать на кнопку +:

      ../../_images/52_Brest_Net_create.png

    2. В открывшемся окне Создать шаблон виртуальной сети во вкладке Общие:

      1. В поле Название указать название создаваемого шаблона.

      2. В разделе Кластеры выбрать текущий Кластер ПК СВ:

      ../../_images/53_NetTemplate_name.png

    3. Во вкладке Конфигурация:

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

      2. В поле Режим работы сети в выпадающем списке выбрать значение Bridged:

      ../../_images/54_NetTemplate_config.png

    4. Во вкладке Адреса указать IP-адрес сети и ее емкость, в соответствии с топологией сети:

      ../../_images/55_NetTemplate_address.png

    5. Во вкладке Контекст, в соответствии с топологией сети, указать адрес сети, маску и шлюз. Нажать на кнопку Создать:

      ../../_images/56_NetTemplate_context.png

    Примечание

    Заполнение разделов Безопасность и Qos не является обязательным.

    Шаблон виртуальной сети будет создан.

  2. Получить токен администратора для подсистемы виртуализации. Для этого:

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

      ../../_images/56.1_administrative_portal.1.png

    2. Перейти в свойства данного пользователя:

      ../../_images/56.2_administrative_portal.2.png

    с. В открывшемся окне свойств пользователя перейти во вкладку Аутентификация и нажать кнопку Управление токенами входа:

    ../../_images/57_User_Token_get.png

    1. Скопировать из списка токенов наиболее подходящий:

      ../../_images/019_token_list.png

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

    1. Во вкладке Интеграция — Обработчики услуг основного меню слева нажать на кнопку + в верхней левой части экрана:

      ../../_images/58_Integration_list_new.png

    2. В открывшемся окне вкладки Тип продукта выбрать Виртуальный дата-центр:

      ../../_images/59_Integration_Type_new.png

    3. В открывшемся окне вкладки Модуль обработки выбрать Брест, нажав на кнопку Добавить:

      ../../_images/60_Integraion_brest.png

    4. В открывшемся окне Настройка интеграции заполнить данные обработчика:

      1. В поле Адрес сервера указать адрес RAFT ПК СВ с протоколом «http».

      2. В полях Имя пользователя и Пароль указать учетные данные администратора ПК СВ «Брест.

      3. В поле Токен указать ранее скопированный токен администратора ПК СВ.

      4. В полях Порт XML-RPC API, Порт OneFlow API, Порт VNC API и Порт VNC Proxy оставить значения по умолчанию.

      5. Нажать на кнопку Далее:

      ../../_images/61_Integration_creation.png

    5. В открывшемся окне Параметры обработчика услуг:

      1. В поле Наименование задать наименование обработчика.

      2. Поле Сортировка не обязательно к заполнению.

      3. В поле Домен указать наименование текущего домена.

      4. В полях Кластеры и Узлы в выпадающем списке выбрать Выделить все.

      5. В поле Хранилища в выпадающем списке выбрать два ранее созданных хранилища.

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

        Использование системных хранилищ с ID 1, 2 не допускается.

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

      7 В поле Общая группа в выпадающем списке выбрать группу brestadmins.

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

      2. Нажать на кнопку Завершить:

      ../../_images/62_Integration_options.png

    6. Скопировать ID обработчика из списка обработчиков после его создания.

      Примечание

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

      docs/installation/img/62.1_Integration_list_ID.png

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

  4. Создать пользователя для подсистемы мониторинга. Для этого:

    1. На Портале самообслуживания перейти во вкладку Пользователи — Сотрудники основного меню слева и нажать на кнопку Создать:

      ../../_images/63_Bill_user_list_new.png

    2. В открывшемся окне Создание нового сотрудника:

      1. В полях Логин, ФИО (ru) и Пароль ввести учетные данные Пользователя, заданного ранее в блоке Мастера установки – Astra Monitoring;

      2. В поле Email указать адрес электронной почты;

      3. В поле Полный доступ поставить флаг;

      4. Нажать на кнопку Ок:

      ../../_images/64_Mon_user_add.png

    3. Наделить созданного сотрудника правами обработчика услуг. Для этого:

      1. Перейти во вкладку Права меню пользователя:

        ../../_images/017_dop_employee_rights.png

      2. В открывшемся окне Права пользователя в поле Обработчик услуг поставить флаг. Нажать на кнопку Вкл:

        ../../_images/018_dop_employee_rights_list.png

Перед развертыванием Astra Monitoring необходимо изменить файл с переменными /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 получать данные для метрик Astra Monitoring

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.

Пароли пользователей exporteruser и exporterwebuser должны:

  • состоять минимум из 8 символов;

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

  • не содержать в себе следующие спецсимволы: $, |, !, #, <, >, \, /, (, ).

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

task astra_monitoring_deploy

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

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

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

task astra_monitoring_server
task astra_monitoring_client

Примечание

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

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

task astra_monitoring_billm

Примечание

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

После развертывания, для проверки корректности установки подсистемы мониторинга Astra Monitoring:

  • перейти в веб-интерфейс Astra Monitoring по адресу:<IP_адрес_AM>;

  • войти в веб-интерфейс Astra Monitoring (логин и пароль по умолчанию admin-internal/admin может быть изменен после развертывания);

  • перейти по адресу: <IP_адрес_AM>:3000, для доступа к сервису визуализации собираемой информации Grafana;

  • войти в сервис Grafana (логин и пароль по умолчанию admin/password может быть изменен после развертывания);

  • при первом входе принять условия Лицензионного соглашения, нажав на кнопку Принять в правом нижнем углу экрана:

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

Системное время на сервере, с которого осуществляется вход на портал Grafana, должно совпадать со временем на серверах контроллера домена.

../../_images/69_AM_License.png

  • перейти в раздел Объекты наблюдения — Объекты.

Пример вида меню Объекты:

../../_images/020_objects.png

В разделе Dashboards представлены все графики и отчеты, сгруппированные по логическим категориям.

Развертывание компонента HelpСenter#

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

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

task help_center_deploy

После завершения процесса установки, перейти в справочный центр можно по ссылке в выводе командной строки, либо по IP-адресу (http://<IP_адрес_helpceneter>) или доменному имени ВМ. В случае успешной установки откроется интерфейс справочного центра:

../../_images/70_helpcenter.png

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

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

Примечание

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

sudo apt install -y libreoffice

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

Развертывание компонента Market place#

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

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

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

task marketplace_deploy

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

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

../../_images/mu_006_mp_1.png

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

../../_images/mu_007_mp_2.png

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

../../_images/mu_008_mp_3.png

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

../../_images/mu_009_mp_4.png

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

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

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

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

Так как DCImanager является необязательным компонентом AIC, перед изменением конфигурационного файла автоматизации, необходимо скачать по ссылкам на странице официальной документации два 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: false
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

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

srv_name

имя управляющего локацией сервера

ipmi_address

IPMI адрес управляющего локацией сервера

ipmi_user

IPMI логин управляющего локацией сервера

ipmi_pass

IPMI пароль управляющего локацией сервера

Примечание

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

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

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

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

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

task dci_part1

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

Пример «отпечатка» установки:

"fingerprint": "H4sIAAAAAAAA/zXOQW4CMQwF0LtkzSKOHSfmMiM7iUsFGiqGoaoQd2+k0qX1v973M7T9dhvrfXnoZR9bOD5fh3DS7RSOoQA36uauXsgEFHKl1kVjRayJ3YblVEA55jokKo8ZFQVps5klHMI6vpfz+JlYNG/MKqTNtD

QHduzoGUr3VrEy1titI8eeTN2YKWESAGGrDm1i10t/Y/PYPj/W5f1oHAiIXVpOqAlAMxcTBkmpapEYaxwmRNlToUxAUJ27NiJNRbRM7n49j/VP3r+63sf/0usXmbnIRCMBAAA="

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

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

Полученный ответ разместить на bootstrap сервере в файле по пути: /home/astra/aic-code/ansible/roles/dci_manager/after_license/files/dci_license, создав файл с именем dci_license.

Примечание

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

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

task dci_part2

После завершения процесса установки, перейти к настройке DCImanager. Для этого:

  1. Открыть кабинет DCImanager по адресу:

    https://<IP_адрес_DCI>

  2. Авторизоваться, использовав для входа учетные данные, заданные при конфигурировании DCImanager.

    Примечание

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

  3. Нажать на кнопку Войти:

    ../../_images/67_DCI_Login.png

Конфигурационные файлы со значениями по умолчанию#

Файл с переменными /home/astra/aic-code/ansible/playbooks/group_vars/all.yml:

---
################
# Repositories #
################
local_web_ip: "192.168.22.21"
aldpro_repo:
  - "deb http://{{ local_web_ip }}/aldpro/ 1.7_x86-64 main base"
alse177_repository:
  - "deb http://{{ local_web_ip }}/alse177/ 1.7_x86-64 main contrib non-free"
alse176uu2_repository:
  - "deb http://{{ local_web_ip }}/alse176uu2/ 1.7_x86-64 main contrib non-free"
astra_brest_repository:
  - "deb http://{{ local_web_ip }}/brest brest main non-free"
alse174uu1_repository:
  - "deb http://{{ local_web_ip }}/alse174uu1/ 1.7_x86-64 main contrib non-free"

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

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

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

#########
# Brest #
#########
brest_version: "3.3.3.uu1"
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"
#############
# Terraform #
#############
def_infra_vms_network_name_mgmt: "Management"
def_infra_vms_network_name_bkp: "Backup"

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: "100"
def_infra_vms_system_ds_id: "101"

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


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

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

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

Файл с адресацией серверов /home/astra/aic-code/inventory.yml:

---
all:
  vars:
    ansible_user: "astra"

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

aic_default_infra:
  hosts:
    dc1-test:
      ansible_host: 192.168.22.230
    dc2-test:
      ansible_host: 192.168.22.231
    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:

#################
# ALD Pro hosts #
#################
aldpro_server:
  hosts:
    dc1-test:

aldpro_replica:
  hosts:
    dc2-test:

aldpro_clients:
  children:
    aldpro_replica:
    brest_kvm_nodes:
    brest_fronts:

###############
# Brest hosts #
###############
brest_fronts:
  hosts:
    node1-test:
    node2-test:
    node3-test:

brest_raft:
  children:
    brest_fronts:

brest_kvm_nodes:
  hosts:
    aichost1:
    aichost2:
    aichost3:

####################
# 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:
Содержание