Ctrl+K
Ctrl+K
PDF
Ctrl+K
PDF

Версии

Установка Платформы Astra Cloud через интерфейс командной строки

Содержание

Установка Платформы Astra Cloud через интерфейс командной строки#

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

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

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

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

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

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

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

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

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

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

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

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

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

  • ПК СВ «Брест» –– 4.0.0;

  • ALD Pro — 3.0.0;

  • RuBackup — 2.7;

  • Astra Monitoring — 1.0;

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

  • DCImanager — 6;

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

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

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

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

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

Примечание

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

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

Для работы как Astra Cloud Installer, так и самой Платформы Astra Cloud требуются следующие сети:

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

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

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

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

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

Примечание

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

Требования к подготовке программно-аппаратного окружения#

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

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

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

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

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

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

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

    • трафика СХД;

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

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

Примечание

Пример

Для развертывания Платформы Astra Cloud выделено три сети:

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

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

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

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

  1. В случае использовании iSCSI, для доступа к СХД, должны быть настроены 2 LUN (либо 3, в случае если для СРК RuBackup один из LUN дисков будет использоваться как внешнее хранилище), которые предоставляются через сеть, выделенную под СХД. Эти 2 LUN будут использованы как СХД ПВ. Логические и физические размеры секторов на LUN должны совпадать, в ином случае использование LUN как хранилища для BREST_LVM нельзя. Если возможности изменить размеры секторов нет, автоматизация установки Платформы Astra Cloud предоставляет код для подключения хранилищ типа LVM-LVM.

  2. Минимальный размер iSCSI LUN или OSD дисков, который будет использоваться для хранилища данных ПВ без развертывания DCImanager, — 150 ГБ в случае iSCSI LUN (при использовании хранилища типа BREST_LVM, в ином случае минимальный размер — 370 ГБ), или 370 ГБ в случае OSD диска Ceph. В случае развертывания DCImanager, минимальный размер — 200 ГБ в случае iSCSI LUN`(при использовании хранилища типа BREST_LVM, в ином случае минимальный размер — 570 ГБ), или 570 ГБ в случае :term:`OSD дисков Ceph. DCImanager является необязательным компонентом Платформы Astra Cloud, и требует отдельного лицензирования. Такие размеры хранилища являются минимальными для возможности установки, в процессе эксплуатации количество занимаемого пространства будет увеличиваться. В случае iSCSI LUN рекомендуется использовать хранилище типа BREST_LVM. Но в таком случае размер логических и физических блоков LUN дисков должен совпадать.

  3. Минимальный размер iSCSI LUN или OSD дисков, который будет использоваться для хранилища образов ПВ –– 50 ГБ в случае iSCSI LUN (при использовании хранилища типа BREST_LVM, в ином случае минимальный размер — 100 ГБ), или 100 ГБ в случае OSD диска Ceph.

  4. Минимальный размер iSCSI LUN для хранения РК СРК RuBackup, создаваемых расписанием, — 50 ГБ.

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

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

Примечание

Развертывание Платформы Astra Cloud версии 2.0 возможно двумя способами: устанавливая каждый компонент Платформы Astra Cloud в интерфейсе командной строки, используя предоставленные средства автоматизации развертывания (далее «автоматизация»), либо с использованием веб-интерфейса Astra Cloud Installer.

Создание установочного сервера Платформы Astra Cloud#

Установочный сервер Платформы Astra Cloud — это файл формата 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.8.3 с оперативным обновлением UU2, уровень защищенности «Воронеж»;

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

  • Веб-интерфейс Astra Cloud Installer;

  • Необходимые для развертывания Платформы Astra Cloud приложения и директории.

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

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

  • vCPU: 4 ядра;

  • RAM: 4 ГБ;

  • HDD: от 150 ГБ;

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

Примечание

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

К целевым серверам, которые будут являться клиентами PXE, должен быть добавлен сетевой интерфейс, подключенный к выделенному для PXE VLAN.

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

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

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

Подготовка Astra Cloud Installer сервера#

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

На Astra Cloud Installer сервере в домашней директории пользователя astra требуется организовать структуру папок. Для этого необходимо создать директорию с именем iso, полный путь до этой директории: /home/astra/iso. Она будет предназначена для хранения ISO компонентов платформы.

Примечание

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

В ней создать следующие директории: aldpro_iso, alse_iso, billmanager_iso, brest_iso, rubackup_iso. Каждая директория предназначена для ISO и их хэш-сумм конкретных компонентов Платформы Astra Cloud — 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

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

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

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

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

/home/astra/iso/
├── aldpro_iso
│   ├── ALDPro-3.0.0.gost
│   └── ALDPro-3.0.0.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.8.3.8-21.08.25_15.43-di.iso
│   └── installation-1.8.3.8-21.08.25_15.43-di.iso.gost
├── billmanager_iso
│   ├── billmgr.aic.base.iso
│   ├── billmgr.aic.base.iso.gost
│   └── billmgr.aic.standard.iso
├── brest_iso
│   ├── brest-4.0.0-for-astra-1.8.3.uu1.iso
│   └── brest-4.0.0-for-astra-1.8.3.uu1.iso.gost
├── dci_manager_iso
│   ├── dci_latest.iso
│   └── dci6_repo.iso
└── rubackup_iso
    ├── rubackup-release_2.7.0.0.0.30_astra-1.7.iso
    └── rubackup-release_2.7.0.0.0.30_astra-1.8.iso

Примечание

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

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

dci_install: true

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

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

task iso_verify

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

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

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

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

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

Примечание

На целевые серверы, предназначенные для инсталляции Astra Cloud Platform, необходимо установить ОС СН ALSE 1.8.3.UU1.

Установка ОС выполняется вручную администратором платформы. Установочный образ ОС нужно взять с установочного сервера Платформы Astra Cloud, предварительно удостоверившись, что его хэш-сумма совпадает с хэш-суммой, указанной в файле .gost на предыдущем этапе.

После загрузки с установочного ISO-образа, откроется меню с выбором вариантов установки. Рекомендуется выбрать пункт Графическая установка:

../../_images/grafic_ust.png

Примечание

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

Далее в открывшемся окне с условиями Лицензионного соглашения следует перейти в конец документа и выбрать значение Да в поле Принимаете ли Вы условия настоящей лицензии. После этого начнется процесс установки:

  1. В открывшемся окне Настройка клавиатуры выбор способа переключения между национальной и латинской раскладкой не важен. После завершения автоматической загрузки основных компонентов и определения сетевой карты выполнится автоматическая настройка сети. Установщик получит IP-адрес через протокол DHCP.

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

    Если в сети нет DHCP-сервера, а среда установки Платформы Astra Cloud не имеет выход в интернет, то получение IP-адреса завершится с ошибкой:

    ../../_images/no_DHCP.png

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

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

    Примечание

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

  3. После указания шлюза откроется окно для ввода адреса DNS-серверов. Так как в процессе инсталляции облачной платформы будет развернута Подсистема идентификации и аутентификации (компонент контроллера домена ALD Pro), которая будет выступать в качестве корневого DNS-сервера, задавать DNS-сервер в процессе инсталляции ОС не требуется. Поле для ввода необходимо оставить пустым.

    Примечание

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

  4. Далее необходимо задать имя сервера.

    Примечание

    Имя сервера должно быть длиной от 1 до 15 символов. Допускается использование латинских букв, цифр, дефиса и подчеркивания. Имя не должно начинаться или оканчиваться на дефис, не должно быть «зарезервированным словом» (например, localhost, null) и не должно совпадать с именами уже существующих серверов в сети.

  5. Следующее окно — окно для указания имени домена.

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

    Сервер будет введен в домен во время инсталляции ALD Pro, на текущем этапе поле необходимо оставить пустым.

  6. Далее выполняется настройка учетных записей пользователей и паролей:

    1. В окне Имя учетной записи администратора задать имя администратора. Требования к имени учетной записи администратора аналогичны требованиям к имени сервера.

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

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

  8. Следующий раздел установки — Разметка дисков:

    ../../_images/razmetka_diskov.png

    В зависимости от необходимости настройки LVM следует выбрать один из представленных в меню вариантов. Если настройка LVM не планируется, необходимо выбрать пункт Авто – использовать весь диск, затем выбрать диск, на котором будет установлена ОС. Далее следует указать схему разметки диска. Выбор схемы разметки не влияет на инсталляцию платформы. После выбора схемы разметки откроется окно с выбранными ранее параметрами разметки дисков. При необходимости можно вернуться на предыдущие этапы, либо настроить RAID.

  9. Удостоверившись в корректности информации, представленной в сводной таблице, выбрать пункт Закончить разметку и записать изменения на диск, и дополнительно подтвердить внесение изменения на диск.

На этом сбор предварительной информации будет завершен, запустится процесс установки ОС.

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

В процессе установки базовой системы установщик предложит выбрать ядро для установки (linux-6.1-generic и linux-6.12-generic). Для корректной работы ПК СВ 4.0.0 строго необходимо выбрать ядро linux-6.1-generic.

После установки ядра linux-6.1-generic откроется окно Выбор программного обеспечения. В данном окне следует отметить только 3 пункта из списка: Графический интерфейс Fly, Средства Виртуализации и Средства удаленного подключения SSH:

../../_images/PO_choise.png

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

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

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

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

В последнем окне — Завершение установки нажать на кнопку Продолжить, после чего будет выполнен системный постустановочный скрипт, по завершению которого ОС будет установлена, а сервер перезагружен.

Примечание

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

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

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

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

    Для этого добавить сетевые мосты для трех сетей (Менеджмент сеть, сеть для трафика СРК, сеть для трафика СХД) на каждом из целевых серверов. Сетевой мост для сети СХД нужен только в случае если в качестве СХД будет использован 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 до целевых серверов. Для этого требуется на установочном сервере Платформы Astra Cloud сгенерировать ключи командой: :

    ssh-keygen

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

    ssh-copy-id <login>@<IP>

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

    Примечание

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

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

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

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

Адреса серверов управления ПВ:

  • 192.168.22.233;

  • 192.168.22.234;

  • 192.168.22.235.

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

  • 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.245 — Marketplace.

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

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

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

Установка Платформы Astra Cloud#

Создание репозиториев из ISO на Astra Cloud Installer сервере#

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

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

task iso_deploy

Автоматизация настроит на Astra Cloud Installer сервере apache2. Директория /mnt будет доступна всем серверам по 80 порту адреса Astra Cloud Installer сервера. В каталоге /mnt будут созданы директории alse1838, alse17615, aldpro, brest, rubackup_alse17, rubackup_alse18. В них будут примонтированы соответствующие ISO. Это позволит серверам облачной платформы использовать ISO, расположенные на Astra Cloud Installer сервере, как репозитории для компонентов Платформы Astra Cloud.

Примечание

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

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

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

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

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

Допустимое количество серверов управления ПВ — 3, 5, 7. Использовать другое количество серверов не допускается. Ограничения обусловлены наличием механизма отказоустойчивости RAFT, рассчитанного на нечетное количество серверов (от 3-х). Кроме того, использование более 7 серверов управления ПВ значительно снижет скорость его работы.

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

all:
  vars:
    ansible_user: "astra"

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

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

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

В вышеприведенном примере указано 3 сервера контроллера домена с именами: dc1-test, dc2-test, dc3-test и IP-адресами: 192.168.22.230, 192.168.22.231, 192.168.22.232; 3 сервера управления ПВ с именами: node1-test, node2-test, node3-test и IP-адресами 192.168.22.233, 192.168.22.234, 192.168.22.235.

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

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

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

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

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

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

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

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

...
local_web_ip: "192.168.22.21"
...
######################################
# 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"

frnthosts_in_kvm:
aichost1: true
aichost2: true
aichost3: true

aldphosts_in_kvm:
aichost1: true
aichost2: true
aichost3: true

vm_to_brest:
aichost1: node1-test
aichost2: node2-test
aichost3: node3-test

vm_to_aldp:
aichost1: dc1-test
aichost2: dc2-test
aichost3: dc3-test
...
aldpro_domain: "aicstand.ru"

Где:

Переменная

Описание

local_web_ip

Адрес Astra Cloud Installer сервера из Менеджмент сети

management_bridge

Имя сетевого моста на целевых серверах, который имеет выход в Менеджмент сеть

backup_bridge

Имя сетевого моста на целевых серверах, который имеет выход в сеть для трафика СРК

storage_bridge

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

vm_disk_size

Размер диска, который будет создан для каждой ВМ, в ГБ. Значение должно быть 50 или более

vm_username

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

vm_password

Пароль пользователя, который будет создан на каждой ВМ

mgmtnetwork

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

bckpnetwork

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

stornetwork

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

aldpro_domain

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

frnthosts_in_kvm

Перечисление имен целевых серверов, на которых будут развернуты ВМ — серверы управления ПВ

aldphosts_in_kvm

Перечисление имен целевых серверов, на которых будут развернуты ВМ — серверы контроллера домена

vm_to_brest

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

vm_to_aldp

Соотношение имени целевого сервера и имени виртуальной машины, на которой будет развернут сервер контроллера домена

Перечисление имен целевых серверов и их сопоставление с именами ВМ может показаться запутанным.

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

...
aic_default_infra:
  hosts:
    ald1-test:
      ansible_host: 192.168.22.230
    ald2-test:
      ansible_host: 192.168.22.231
    ald3-test:
      ansible_host: 192.168.22.232
    front1-test:
      ansible_host: 192.168.22.233
    front2-test:
      ansible_host: 192.168.22.234
    front3-test:
      ansible_host: 192.168.22.235
    front4-test:
      ansible_host: 192.168.22.236
    front5-test:
      ansible_host: 192.168.22.237
    aicserver:
      ansible_host: 192.168.22.74
      ansible_user: aicadmin
    aicserver2:
      ansible_host: 192.168.22.75
      ansible_user: aicadmin
    aicserver3:
      ansible_host: 192.168.22.76
      ansible_user: aicadmin
    aicserver4:
      ansible_host: 192.168.22.77
      ansible_user: aicadmin
    aicserver5:
      ansible_host: 192.168.22.78
      ansible_user: aicadmin

############################
# VM on 3 physical servers #
############################
vm_hosts:
  hosts:
    aicserver1:
    aicserver2:
    aicsevrer3:
    aicserver4:
    aicserver5:

...
frnthosts_in_kvm:
  aicserver1: true
  aicserver2: true
  aicserver3: true
  aicserver4: true
  aicserver5: true

aldphosts_in_kvm:
  aicserver1: true
  aicserver2: true
  aicserver3: true
  aicserver4: false
  aicserver5: false

vm_to_brest:
  aicserver1: front1-test
  aicserver2: front2-test
  aicserver3: front3-test
  aicserver4: front4-test
  aicserver5: front5-test

vm_to_aldp:
  aicserver1: ald1-test
  aicserver2: ald2-test
  aicserver3: ald3-test
  aicserver4:
  aicserver5:
...

В данном примере 5 серверов управления ПВ и 3 сервера ALD Pro. Сопоставление имен целевых серверов и локальных ВМ говорит о том, что на 1-3 серверах будут развернуты ВМ для серверов управления ПВ и ВМ для серверов КД. А на 4 и 5 серверах будут развернуты только ВМ для серверов управления ПВ.

В переменных frnthosts_in_kvm, aldphosts_in_kvm, vm_to_brest и vm_to_aldp всегда должны быть перечислены все целевые серверы, на которых будут расположены ВМ.

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

task vm_deploy

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

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

task info

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

Ниже представлен полный список аргументов, с их описанием для команды task
Для проверки целостности скаченных из личного кабинета ISO запустите  task iso_verify
Для установки и настройка apache2, монтирование ISO компонентов Платформы Astra Cloud как репозитории на этот Astra Cloud Installer, запустите  task iso_deploy
Для создания ВМ – будущих серверов КД и серверов управления ПВ запустите  task vm_deploy
Для добавления на все целевые серверы и ВМ расположенные на них репозитории с текущего Astra Cloud Installer запустите 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_deploy
Для первоначальной настройки BILLmanager и создания в нем необходимых ресурсов запустите task bill_post_install
Для удаления всех ресурсов в BILLmanager запустите task bill_resources_clean
Для полной инсталляции RuBackup запустите task rubackup_deploy
Для подключения iSCSI LUN к ВМ с сервером RuBackup запустите task rubackup_iscsi_connect
Для добавления LUN диска как пул RuBackup запустите task rubackup_iscsi_pool
Для полной инсталляции Astra Monitoring запустите task am_deploy
Для полной инсталляции Marketplace запустите task marketplace_deploy
Для инсталляции DCImanager до этапа получения лицензии запустите task dci_part1
Для продолжения инсталляции DCImanager после добавления файла с лицензией запустите task dci_part2
Запуск команд в вышеописанной последовательности приведет к полному развертыванию ACP
task: Available tasks for this project:
* add_repos:                       Добавление репозиториев с Astra Cloud Installer
* 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_post_scripts:             Донастройка ALD Pro после развертывания
* aldpro_server:                   Инсталляция севера ALD Pro
* am_client:                       Инсталляция клиентов Astra Monitoring
* am_client_billm:                 Инсталляция клиента Astra Monitoring для BILLmanager
* am_deploy:                       Инсталляция сервера и клиентов Astra Monitoring
* am_server:                       Инсталляция сервера Astra Monitoring
* apache2_deploy:                  Установка и настройка apache2 на Astra Cloud Installer
* bill_deploy:                     Инсталляция сервера BILLmanager
* bill_first_login:                Первоначальная настройка BILLmanager
* bill_ldap:                       Настрйока ldap на BillManager
* bill_post_install:               Первоначальная настройка BILLmanager, LDAP, создание ресурсов
* bill_resources:                  Создание ресурсов в BillManager
* bill_resources_clean:            Удаление ресурсов в BillManager
* brest_changes_hosts:             Добавление записей в /etc/hosts о серверах виртуализации ПВ
* brest_deploy:                    Полная инсталляция ПВ
* brest_front:                     Инсталляция серверов управления ПВ
* brest_kvm:                       Инсталляция серверов виртуализации ПВ
* brest_post_scripts:              Донастройка ПВ после его развертывания
* brest_raft:                      Инсталляция RAFT для всех серверов управления. Если RAFT уже существует, добавить в него дополнительный сервер управления автоматизацией нельзя
* brest_token:                     Синхронизация токена доступа между всеми серверами ПВ
* check_version:                   Проверка версий ALSE и компонентов Платформы Astra Cloud на соответствие версий
* dci_part1:                       Инсталляция сервера DCIмanager до получения лицензии
* dci_part2:                       Инсталляция сервера DCIмanager после получения лицензии
* 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 как репозиторий на Astra Cloud Installer
* iso_alse:                        Монтирование ISO ALSE как репозиторий на Astra Cloud Installer
* iso_brest:                       Монтирование ISO ПВ как репозиторий на Astra Cloud Installer
* iso_deploy:                      Установка и настройка apache2, монтирование ISO компонентов Платформы Astra Cloud ак репозиторий на Astra Cloud Installer
* iso_rubackup:                    Монтирование ISO RuBackup как репозиторий на Astra Cloud Installer
* iso_verify:                      Проверка целостности скаченных из личного кабинета ISO
* marketplace_deploy:              Установка и настройка сервера Marketplace
* rubackup_api:                    Инсталляция модуля REST API RuBackup
* rubackup_client:                 Инсталляция клиентской части RuBackup
* rubackup_deploy:                 Инсталляция сервера и клиентов RuBackup
* rubackup_iscsi_connect:          Подключение iSCSI LUN к серверу RuBackup
* rubackup_iscsi_pool:             Добавление LUN диска как пул на сервере 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_host:                         Создание ВМ на серверах виртуализации
* vm_post_deploy:                  Увеличение размера диска ВМ
* vm_prepare_hosts:                Подготовка 3-х серверов виртуализации перед созданием ВМ для серверов управления ПВ и ALD Pro

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

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

task vm_prepare_hosts
task vm_host
vm_post_deploy

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

Аргумент

Описание

vm_prepare_hosts

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

vm_host

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

vm_post_deploy

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ВМ получат названия, сформированные из имени целевого сервера и указания предназначения виртуальной машины, например aichost1-front, aichost3-ald.

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

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

После развертывания ВМ на них необходимо добавить локальные репозитории с Astra Cloud Installer сервера — репозитории ALSE 1.7.6.UU2 для серверов КД, а также 1.8.3.UU1 для серверов управления и виртуализации ПВ. Также на этом этапе подключается репозиторий ПВ 4.0.0 на предназначенные для ПВ серверы виртуализации и репозиторий aic, заранее расположенный на установочном сервере.

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

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

task add_repos

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

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

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

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

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

Где:

Переменная

Описание

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:

Имена и адреса серверов КД указывались при создании ВМ.

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

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

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

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

Имя и значения группы 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_ntp

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

raft_floating_name: "raftleader"
raft_floating_ip: "192.168.22.100"

Где:

Переменная

Описание

brest_version

Версия ПВ (Компонент ПК СВ «Брест»)

freeipa_admin_pass

Пароль администратора FreeIPA, необходимо оставить без изменений

freeipa_brestadmin

Имя администратора ПВ (он будет добавлен в домен)

freeipa_brestadmin_pass

Пароль администратора ПВ

db_name

Имя основной БД ПВ

db_user

Имя администратора основной БД ПВ

db_user_pass

Пароль администратора основной БД ПВ

raft_floating_name

Короткое плавающее имя кластера управления ПВ (эта A-запись будет добавлена в DNS ALD Pro)

raft_floating_ip

Адрес короткого плавающего имени кластера управления ПВ (RAFT)

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

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

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

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

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

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

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

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

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

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

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

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

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

aic_default_infra:
  hosts:
...
    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
...
###############
# Brest hosts #
###############

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

brest_raft:
  children:
    brest_fronts:

brest_kvm_nodes:
  hosts:
    aichost1:
    aichost2:
    aichost3:

Имена и адреса серверов управления ПВ указывались при создании ВМ.

Примечание

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

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

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

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

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

Изменение значения группы brest_raft не допускается.

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

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

task brest_deploy

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

Примечание

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

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

task brest_front
task brest_kvm
task brest_raft
task brest_post_scripts
task brest_changes_hosts

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

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

Команда

Описание

brest_front

Инсталляция серверов управления ПВ

brest_kvm

Инсталляция серверов виртуализации ПВ

brest_raft

Настройка механизма RAFT

brest_post_scripts

Выполнение постустановочных действий

brest_changes_hosts

Добавление серверам системы виртуализации записей в /etc/hosts

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

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

Для проверки корректности настройки механизма RAFT следует на любом из серверов управления ПВ от имени пользователя root (для этого следует выполнить команду sudo -i) выполнить команду:

sudo 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) в контроллере домена и донастройка его серверной конфигурации#

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

../../_images/011_dop_domain_structure.png

Структура организована по двум основным разделам:

  1. ACP — для управления административными и пользовательскими ресурсами.

  2. AIC AD — для управления облачными ресурсами и клиентскими аккаунтами с разделением на тенантную и сервисную структуры управления.

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

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

task aldpro_create_ou

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

Примечание

Также будет создан пользователь astracloud_user, он является примером пользователя для работы с VDC. Пароль пользователя — ABC_1234567890.

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

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

Примечание

Автоматизация установки Платформы Astra Cloud 2.0 предоставляет только автоматизацию для подключения к ПВ 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 portal #
################
iscsi_portal:
  - 10.205.17.90
# - 10.205.17.91

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

Вносить изменения в файл-инвентарь необходимости нет, заполнив переменную, отвечающую за порталы, можно запускать первый этап подключения 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 выполнить команду:

task 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 на Astra Cloud Installer сервере следует выполнить команду:

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 на Astra Cloud Installer сервере выполнить команду:

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. Он будет необходим для следующего этапа развертывания Платформы Astra Cloud.

В случае если требуется переподключить хранилища ПВ типа 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:

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

    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

    Где:

    • </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

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

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

В ПВ будут созданы две сети — сеть управления (Менеджмент) и сеть СРК. Будет ли создана сеть СХД, — определит значение одной из переменных. Для каждого компонента Платформы Astra Cloud под управлением ПВ будет создан свой Шаблон ВМ, для удобства пересоздания отдельных ВМ.

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

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

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

#############
# Terraform #
#############
image_ds_id: "100"
system_ds_id: "101"

############
# Rubackup #
############
...
rubackup_external_iscsi_storage: true

Где:

Параметр

Описание

image_ds_id

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

system_ds_id

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

rubackup_external_iscsi_storage

Необходимость подключения iSCSI LUN как внешнего СХД (принимает значения true либо false)

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

Использование внешнего СХД для СРК RuBackup необязательно, но настоятельно рекомендовано. Автоматизация предусматривает использование только iSCSI LUN.

В случае, если переменная rubackup_external_iscsi_storage примет значение true, ВМ, предназначенной для СРК RuBackup, будет дополнительно добавлена сеть СХД, а во время инсталляции самого СРК будут выполнены действия по добавлению третьего, наибольшего по размеру, LUN диска в качестве дополнительного пула.

Необходимые для изменений блоки файла-инвентаря /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
    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:
    brest_kvm_nodes:

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

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

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

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

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

Помимо блока brest_default_infra в файле-инвентаре описаны группы для соответствующих компонентов Платформы Astra Cloud, которые будут развернуты на ВМ под управлением ПВ:

  • 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), а также группа серверов, которые являются серверами виртуализации ПВ (brest_kvm_nodes);

  • 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 с Astra Cloud Installer сервера, удаление утилиты one-context и записи 127.0.1.1 из файла /etc/hosts, проверку мандатного контроля целостности.

Примечание

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

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

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

Ошибка с текстом ALLOCATED обозначает, что ресурс уже был создан, но он имеет другой ID. В случае возникновения этой ошибки, также нужно вручную удалить развертываемые командой task terraform_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. В разделе Пользователи и компьютеры нужно перейти в подраздел Компьютеры. В открывшемся списке должны отображаться все развернутые на текущий момент серверы Платформы Astra Cloud, то есть серверы управления и виртуализации ПВ, имя лидера RAFT, все серверы контроллера домена, а также все созданные ВМ под управлением ПВ.

Установка BILLmanager#

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

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

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

###############
# Billmanager #
###############
admin_pw: "ABC_1234567890"
billm_root_password: "passw@rd"
billm_api_user: "monitoring"
billm_api_pass: "=mvp1CL@st="
lic_type: "base"

Где:

Параметр

Описание

admin_pw

Пароль администратора BILLmanager

billm_root_password

Пароль пользователя root на ВМ с BILLmanager

billm_api_user

Пользователь для сбора метрик Astra Monitoring

billm_api_pass

Пароль пользователя для сбора метрик Astra Monitoring

lic_type

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

Примечание

Для установки BILLmanager будет использоваться ISO, соответствующий редакции Astra Cloud Installer, загруженный во время подготовки к установке Платформы Astra Cloud.

Переменная lic_type должна быть равна редакции платформы.

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

task bill_deploy

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

../../_images/id_node.png

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

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

Примечание

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

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

Итогом работы автоматизации будет установленное ПО BILLmanager редакции «Hosting&Cloud».

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

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

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

      Примечание

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

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

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

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

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

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

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

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

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

Примечание

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

127.0.0.1 download.ispsystem.com

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

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

  1. После инсталляции BILLmanager в нем необходимы создать ресурсы для возможности сбора метрик Astra Monitoring, интеграции с ПВ, а также настроить подключение LDAP. Для этого выполнить команду:

    task bill_post_install

    Итогом выполнения автоматизации является первоначальная настройка BILLmanager, создание пользователя admin с административными правами, создание провайдера и обработчика для работы клиентской части Astra Monitoring, интеграция с ПВ, а также добавление подключения LDAP.

    Примечание

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

    task bill_resources_clean

    Созданные ресурсы можно увидеть в веб-интерфейсе BILLmanager (на Портале самообслуживания).

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

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

Где ``<IP>`` --- IP-адрес BILLmanager, заданный на этапе Инфраструктура.

    Примечание

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

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

    ../../_images/billmgr_1.png

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

    Примечание

    Логин для входа — admin, пароль был задан ранее в переменной admin_pw.

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

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

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

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

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

    ############
# Rubackup #
############
rubackup_version: "2.7.0.0.0.30"
rubackup_server_psql_password: "ABC_1234567890"
rubackup_server_psql_password_rubackup: "ABC_1234567890"
rubackup_external_iscsi_storage: true

    Где:

    Параметр

    Описание

    rubackup_version

    Версия СРК (необходимо оставить без изменений)

    rubackup_server_psql_password

    Пароль пользователя postgres БД RuBackup

    rubackup_server_psql_password_rubackup

    Пароль администратора БД RuBackup

    rubackup_external_iscsi_storage

    Необходимость подключения iSCSI LUN как внешнего СХД (принимает значения true либо false)

    Примечание

    Необходимость подключения iSCSI LUN как внешнего СХД определялась на этапе создания ВМ под управлением ПВ.

    Клиентами СРК являются серверы КД 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, создаются правила глобального расписания резервного копирования каталогов и файлов, содержащих конфигурационные файлы Платформы Astra Cloud.

      Для каждого клиента СРК создается расписание создания РК директорий /home, /etc, /root. На всех клиентах, кроме сервера СРК, создается расписание РК директории /opt/rubackup, на сервере СРК создается расписание РК директории /opt/rubackup/etc.

      Для лидера КД создание расписания создания РК FreeIPA как ресурса, для всех серверов управления ПВ создания РК директории /var/lib/one, /backup.

      Создание РК по расписанию выполняется ежедневно, с 00:00, между запуском каждого расписания есть интервал в 5 минут.

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

../../_images/mu_003_token_CSRF.png

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

Пример содержания файла с токеном CSRF

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

Примечание

Авторизовывать токен нужно только для работы веб-интерфейса СРК — Tucana.

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

Для авторизации CSRF-токена REST API выполнить следующие действия:

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

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

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

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

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

Примечание

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

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

sudo apt install virt-viewer

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

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

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

task rubackup_server
task rubackup_client
task rubackup_api
task rubackup_post_install
task rubackup_token

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

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

Команда

Описание

rubackup_server

Инсталляция серверной части СРК

rubackup_client

Инсталляция клиентской части СРК

rubackup_api

Инсталляция и настройка модуля REST API на сервер СРК

rubackup_post_install

Авторизация клиентов СРК, настройка глобального расписания для них

rubackup_token

Генерация CSRF-токена REST API RuBackup

Примечание

При перезагрузке RuBackup сервера, либо службы rubackup_server.service, токен для REST API нужно генерировать и авторизовать заново. Для выполнения генерации нового токена, без необходимости повторно запускать весь процесс развертывания, на Astra Cloud Installer сервере в директории /home/astra/aic-code выполнить команду:

task rubackup_token

Для подключения внешнего СХД (одного iSCSI LUN) и добавление LUN диска как блочное устройство в пул, необходимо выполнить две команды: для установки необходимых пакетов и получения IQN, и для непосредственного создания пула:

task rubackup_iscsi_connect
task rubackup_iscsi_pool

Примечание

Вышеуказанные команды ничего не сделают в случае, если у переменной rubackup_external_iscsi_storage значение отличное от true.

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

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

Как и в случае подключения iSCSI LUN к серверам управления и виртуализации ПВ, после выполнения команды task rubackup_iscsi_connect в консоли будет выведен IQN, который, при необходимости, нужно авторизовать:

../../_images/rubackup_IQN.png

Итогом работы команды task rubackup_iscsi_pool является созданный в RuBackup блочный пул с названием iscsi_pool, состоящий из 1 блочного устройства, которым является наибольший по размеру iSCSI LUN из подключенных ранее.

Примечание

Пул будет создан с настройками по умолчанию, кроме хэш-функции. Для созданного пула выбрана хеш-функция sha2 с длиной хеша в 512 бит для повышения безопасности.

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

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

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

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

    rbm&

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

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

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

    • в поле Имя пользователя ввести значение rubackup;

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

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

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

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

  3. Проверить, что все клиенты СРК авторизованы, находятся в сети, распределены по группам. В разделе Глобальное расписание созданы расписания для создания РК каталогов и файлов, содержащих конфигурационные файлы Платформы Astra Cloud. В случае подключения внешнего СХД, в разделе Хранилища, подразделе Пулы будет представлен пул с именем iscsi_pool, а в подразделе Блочные устройства будет указан LUN диск.

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

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

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

####################
# Astra Monitoring #
####################
oneexporter_password: "=mvp1CL@st="
exporterwebuser_password: "=mvp1CL@st="

Где:

Переменная

Описание

oneexporter_password

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

exporterwebuser_password

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

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

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

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

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

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

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

task am_deploy

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

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

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

task am_server
task am_client
task am_client_billm

Примечание

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

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

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

  1. Перейти в веб-интерфейс Astra Monitoring по адресу:

    <IP_адрес_AM>`

    Примечание

    Для входа в веб-интерфейс Astra Monitoring использовать следующие учетные данные:

    Логин: admin-internal;

    Пароль: admin.

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

  2. Для доступа к сервису визуализации собираемой информации Grafana перейти по адресу:

    <IP_адрес_AM>:3000

    Примечание

    Для входа в сервис Grafana использовать следующие учетные данные:

    Логин: admin;

    Пароль: password.

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

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

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

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

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

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

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

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

В случае, если метрика Статус провайдеров имеет значение отличное от OK, необходимо убедиться, что в настройках обработчика услуг Brestaic на Портале самообслуживания указан корректный токен. Токен должен быть создан от имени пользователя администратора ПВ, быть в целевой группе brestadmins.

Для корректной работы Astra Monitoring необходима лицензия. Для ее получения следует отправить запрос через личный кабинет, выбрав Запрос на услуги, продукт Astra Cloud Platforrm, компонент Astra Monitoring. Процесс оформления запроса представлен на странице Технической поддержки

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

Магазин приложений (далее Маркетплейс) в Платформе Astra Cloud реализован в виде виртуальной машины под управлением ПВ. ВМ для него была создана на предыдущих этапах. В процессе автоматизированного развертывания формируется магазин приложений с названием 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 является необязательным компонентом Платформы Astra Cloud, перед изменением конфигурационного файла автоматизации, необходимо удостовериться, что на этапе подготовки Astra Cloud Installer сервера были скачены по ссылкам из официальной документации два ISO-файла: dci_latest.iso и dci6_repo.iso. Скачанные файлы необходимо расположить в каталоге /home/astra/iso/dci_manager_iso/ на Astra Cloud Installer сервере. Первый ISO-образ содержит установочный образ DCImanager, второй ISO-образ содержит репозиторий, необходимый для установки DCImanager.

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

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

Где:

Переменная

Описание

dci_install

Переменная, отвечающая за необходимость развертывания DCImanager, ее значение должно быть true

email

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

password

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

platform_name

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

DataCenter_name2

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

unit

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

default_gw_ip

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

mac

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

rack_name

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

srv_name

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

ipmi_address

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

ipmi_user

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

ipmi_pass

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

Примечание

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

Переменная dci_install заполнялась на предыдущих шагах. Необходимо удостовериться, что в ПВ создана ВМ для DCImanager.

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

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

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

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

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

task dci_part1

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

Примечание

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

../../_images/dci_1.png

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

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

Полученную лицензию записать в файл: /home/astra/aic-code/ansible/roles/dci_manager/after_license/files/dci_license на Astra Cloud Installer сервере.

Примечание

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

После создания этого файла необходимо запустить второй этап автоматизации развертывания 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"
alse1838_repository:
  - "deb http://{{ local_web_ip }}/alse1838/ 1.8_x86-64 main contrib non-free"
alse17615_repository:
  - "deb http://{{ local_web_ip }}/alse17615/ 1.7_x86-64 main contrib non-free"
alse17411_repository:
  - "deb http://{{ local_web_ip }}/alse17411/ 1.7_x86-64 main contrib non-free"
astra_brest_repository:
  - "deb http://{{ local_web_ip }}/brest brest main non-free"
aldpro_repo:
  - "deb http://{{ local_web_ip }}/aldpro/ 1.{{ alse_release }}_x86-64 main base"

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

frnthosts_in_kvm:
  aichost1: true
  aichost2: true
  aichost3: true

aldphosts_in_kvm:
  aichost1: true
  aichost2: true
  aichost3: true

vm_to_brest:
  aichost1: node1-test
  aichost2: node2-test
  aichost3: node3-test

vm_to_aldp:
  aichost1: dc1-test
  aichost2: dc2-test
  aichost3: dc3-test

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

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

#########
# Brest #
#########
brest_version: "4.0.0"
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 #
#############
image_ds_id: "100"
system_ds_id: "101"

############
# Rubackup #
############
rubackup_version: "2.7.0.0.0.30"
rubackup_server_psql_password: "ABC_1234567890"
rubackup_server_psql_password_rubackup: "ABC_1234567890"
rubackup_external_iscsi_storage: true

####################
# Astra Monitoring #
####################
oneexporter_password: "=mvp1CL@st="
exporterwebuser_password: "=mvp1CL@st="

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

###############
# Billmanager #
###############
admin_pw: "ABC_1234567890"
billm_root_password: "passw@rd"
billm_api_user: "monitoring"
billm_api_pass: "=mvp1CL@st="
lic_type: "base"

Файл с адресацией серверов /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
    dc3-test:
      ansible_host: 192.168.22.232
    node1-test:
      ansible_host: 192.168.22.233
    node2-test:
      ansible_host: 192.168.22.234
    node3-test:
      ansible_host: 192.168.22.235
    aichost1:
      ansible_host: 192.168.22.74
      ansible_user: aicadmin
    aichost2:
      ansible_host: 192.168.22.75
      ansible_user: aicadmin
    aichost3:
      ansible_host: 192.168.22.76
      ansible_user: aicadmin

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

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

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

###############
# Marketplace #
###############
marketplace_server:
  hosts:
    marketplace:
Содержание