Инструкция по инсталляции облачной платформы

Подготовка

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

Узел Infrastructure (он же LCM — Life Cycle Manager) — предназначен для управления жизненным циклом облака;
Узлы Control Plane (контроллеры) — предназначены для выполнения служебных задач по управлению облаком;
Узлы Compute (гипервизоры) — предназначены для размещения рабочих нагрузок в виде виртуальных машин;
Узлы Network (сетевые) — предназначены для размещения компонентов програмно-определяемых сетей.

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

Запуск установки (инсталлятора), который установит на сервер LCM необходимые компоненты и сервисы для дальнейшей работы с облаком.
Выполнение сценариев (пайплайнов) системы управления облаком (CI/CD) для задач настройки/конфигурирования облака.

Развертывание сервера LCM

Инсталлятор разворачивает Облачную платформу на заранее подготовленной инфраструктуре (ВМ или физических серверах).

Требования

Требования, предъявляемые к узлу LCM (он же — узел Seed), одновременно являются требованиями к узлу, на котором возможно проведение процесса разработки и доработки компонентов облачной платформы, поскольку разработка производится при помощи встроенной в Gitlab среды разработки.

Поддерживаемые базовые ОС LCM

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

Для хоста:

Zed: Ubuntu 22.04 LTS

Для LCM:

Ubuntu 22.04 LTS

Требования к пакетам

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

docker
docker compose
git версии старше 2.28.0
openssl, curl, tar, jq

Инфраструктурные требования

Для установки и коректной работы LCM требуется наличие сетевой связности между сервером LCM и хостами контроллеров и гипервизоров:

C узла LCM должен быть доступ до IPMI всех серверов, до mgmt-интерфейсов и до VIP-адресов облака.
Со всех хостов должен быть доступен dhcp-сервер на узле LCM в сети PXE.
Создан пользователь в BMC серверов с правами administrator и включена опция Enable IPMI Over LAN. Включен Redfish.

Также для облачной инфраструктуры требуется выделить DNS-зону, в котором необходимо создать записи для следующих сервисов:

config.<имя домена> — информационный сервис облака;
ks-lcm.<имя домена> — система управления жизненным циклом облака (CI);
gitlab-runner.<имя домена> — исполнитель сценариев (пайплайнов);
nexus.<имя домена> — репозиторий пакетов, контейнеров и других артефактов облака;
vault.<имя домена> — хранилище паролей и сертификатов;
netbox.<имя домена> — хранилище настроек для сервиса Baremetal.

Доменное имя необходимо использовать второго уровня для генерации Wildcard-сертификата для сервисов LCM, например, demo.local.

Возможность разрешения данных имён в IP-адрес сервера LCM является обязательным, поскольку при установке облачной платформы используются сертификаты безопасности, связанные с указанными выше именами. Установка допускает использование разрешения имён либо через сервис DNS, либо через записи в файлах /etc/hosts. Пример записи в /etc/hosts:

<ip адрес LCM> config.<имя домена> ks-lcm.<имя домена> gitlab-runner.<имя домена> vault.<имя домена> nexus.<имя домена> netbox.<имя домена>

Для узлов Compute необходимо создать записи вида:

10.10.1.1 <имя сервера>-rmi.<имя домена>

Эти записи предназначены для разрешения IP-адреса BMC сервера в имя вида <имя сервера>-rmi.<имя домена>. Их нужно изменить на реальные адреса интерфейсов BMC узлов Compute.

Установка LCM

Процесс установки в автоматическом режиме производит развертывание и конфигурирование следующих компонентов на сервере LCM:

Пароля системы автоматизации (Gitlab);
SSH-ключей для беспарольного доступа на сервера;
Сертификатов для служб LCM;
Репозитория пакетов, контейнеров, артефактов Sonatype Nexus;
Системы автоматизации (GitLab-CI);
Репозиториев управления облаком (CI/CD);
Документирования сетей и девайсов Netbox (CMDB).

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

Ссылка на архив с инсталлятором: https://repo.itkey.com/repository/k-install/installer-ks2023.2.1.tgz

Для начала установки на подготовленном сервере LCM от имени пользователя root требуется распаковать любой удобной утилитой архив с инсталлятором в домашнюю директорию пользователя root. Распаковка должна быть произведена в поддиректорию с именем installer в домашней директории пользователя root. Пример команды разархивирования, выполняемой от имени пользователя root:

tar -xf <path>/installer-ks2023.2.1.tgz -C ~/

Вместо <path> нужно указать путь до директории со скачанным архивом инсталлятора. Запуск процесса установки облачной платформы осуществляется запуском команды ./installer.sh из директории инсталлятора (необходимо наличие прав root или запуск команды при помощи sudo).

root@lcm:~/installer# ./installer.sh
*** KeyStack Installer v1.0 (ks2023.2.1) ***
Enter the home dir for the installation [/installer]:
Enter the IP address of this machine [10.220.107.179]:
Enter the root domain name for the KeyStack: demo.local

Доменное имя должно быть второго уровня.

Возможные ошибки при развёртывании LCM

Отсутствие каких-либо репозиториев в Gitlab

Если это пустой репозиторий в Gitlab, значит, при git push могла произойти внутренняя ошибка сервиса Gitlab. В этом случае нужно перейти в каталог, где лежат все репозитории /installer/repo, зайти в каталог репозитория, где произошла ошибка, и выполнить команды:

git push -u origin --all
git push -u origin --tags

После этого нужно убедиться, что данные репозитория появились в Gitlab.

Развертывание облачной платформы

Требования

Требования к базовой ОС узлов

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

egrep '(vmx|svm)' /proc/cpuinfo

Предварительная конфигурация

После успешной установки на экране отобразится сообщение с текущей конфигурацией облачной платформы. После этого можно перейти в браузере по адресу http://config.<имя домена> для получения общей информации об инсталляции и доступа к основным параметрам конфигурации. Пример такой страницы приведён на рисунке ниже:

Рисунок 1 — Пример страницы с общей информацией об инсталляции

Для обеспечения корректной работы браузеров с компонентами облачной платформы требуется добавить Root CA (корневой) сертификат в Доверенные корневые центры сертификации системы пользователя.

После выполнения этих шагов требуется перейти по адресу CI/CD системы и использовать пароль GitLab root, полученный на странице с информацией. В интерфейсе CI/CD системы будет доступно несколько репозиториев. Пример интерфейса приведён на рисунке ниже.

Рисунок 2 — Репозитории в Gitlab

Пароли и сертификаты Облачной платформы

Все пароли и сертификаты для облака хранятся в сервисе Vault по адресу: https://vault.<имя домена>.

Рисунок 3 — Интерфейс хранилища секретов

Рутовый токен можно найти на сервере LCM в файле /installer/data/vault/config/unseal_info. Там же находятся ключи для разблокировки Vault после перезагрузки.

Все сертификаты автоматически генерируются при инсталляции сервера LCM с помощью программы openssl.

Инсталлятор создает корневой центр сертификации: Root CA сертификат и приватный ключ. Срок действия — 10 лет.
Инсталлятор создает Wildcard сертификат и приватный ключ для сервисов Gitlab, Nexus, Vault, Netbox и делает их доверенными центру сертификации Root CA. Также создается цепочка сертификатов вида chain-cert.pem для сервисов. Срок действия — 2 года.
Инсталлятор активирует в Vault хранилище pki с именем installer для хранения сертификатов и создает в этом хранилище Центр сертификации на основе центра сертификации Root CA. Также он создает роль, которая может выписывать сертификаты на основе запросов пользователей. Срок действия — 2 года.

Сервис по наливке Baremetal серверов

Установка и настройка Bifrost

Зайти в Gitlab, перейти в репозиторий project_k → deployments → gen-pwd. Перейти в Build → Pipelines → Run Pipeline. Внести в поле “OPENSTACK_ENV” значение bifrost, как на рисунке ниже, и запустить пайплайн с помощью кнопки “Run Pipeline”.

Рисунок 4 — Запуск пайплайн-генерации секретов для bifrost

Запустить задачу create-config, как на рисунке ниже.

Рисунок 5 — Запуск задачи генерации секретов для bifrost

Дождаться окончания работы пайплайна.

Перейти репозиторий project_k → deployments → bifrost.

Открыть на редактирование файл inventory и заменить в нем LCM_IP на IP-адрес LCM-узла.

Открыть на редактирование файл globals.d/REGION.yml и заменить в нем eth0 на имя интерфейса на LCM-узле.

Перейти в Build → Pipelines → Run Pipeline и запустить пайплайн с помощью кнопки “Run Pipeline”.

Рисунок 6 — Запуск задачи установки bifrost

Дождаться окончания работы задачи setup, запустить задачу deploy-bifrost и дождаться окончания ее работы.

Зайти на LCM-узел по ssh и выполнить команду:

# docker exec -ti bifrost_deploy bash
(bifrost-deploy)# mcedit /etc/dnsmasq.conf

Поменять значения:

listen-address=<IP-адрес LCM-узла> dhcp-option=6,<IP-адрес LCM-узла> dhcp-boot=tag:ipxe,http://<IP-адрес LCM-узла>:8080/boot.ipxe

Диапазон адресов DHCP для выдачи IP-адресов серверам:

dhcp-range=10.0.0.10,10.0.0.100,255.255.255.0,24h

Маршрут для IP-адресов, выданных по DHCP:

dhcp-option=3,10.0.0.254

Сохранить изменения F2 и выйти F10.

Перезапустить сервис dnsmasq:

(bifrost-deploy)# systemctl restart dnsmasq

Изменение пользователя и пароля для IPMI серверов гипервизора

Перейти в secret_v2/deployments/bifrost/rmi, где bifrost — название репозитория с настройками сервиса bifrost. Затем поменять пароль в поле “password” на пароль от интерфейса IPMI BMC-серверов, и пользователя в поле “user” на пользователя интерфейса IPMI BMC-серверов.

Рисунок 7 — Изменение пароля IPMI в хранилище секретов для сервиса Baremetal

На всех серверах нужно создать одинакового пользователя с именем и паролем, который должен быть записан в Vault. Это необходимо для работы сервиса автоэвакуации ВМ при сбое гипервизора и для сервиса Baremetal.

Развертывание серверов с помощью сервиса Baremetal

Настройка Netbox

До начала работ по наливке серверов необходимо заполнить данные в Netbox.

Наливка серверов

Перейти в Gitlab в репозиторий project_k → services → baremetal.

Перейти в Build → Pipelines → Run Pipeline.

Рисунок 8 — Запуск пайплайн развертывания серверов

Заполнить переменные для пайплана:

TARGET_ROLE — роль для серверов, определенная в Netbox. Для контроллеров — controller, для узлов Network — network, для узлов Compute — compute.
TARGET_CLOUD — имя тега в Netbox для региона.
TARGET_NODE — имя конкретного узла для деплоя только одного узла.
IRONIC_ENV — окружение для деплоя узлов (по умолчанию — BIFROST).
IRONIC_SSH_KEY — можно добавить свои ключи SSH на узел (формат — один ключ на строку).
IRONIC_IMAGE_URL — путь до образа системы Linux, который будет установлен на узел. Образ должен быть в формате qcow2. Тамже рядом с образом должен лежать файл с md5 хэш образа, формат имени {имя-образа}.md5.
IRONIC_IMAGE_ROOTFS_UUID — для установки системы на софт-рейд нужно указать UUID рутового раздела в образе. https://docs.openstack.org/ironic/yoga/admin/raid.html#image-requirements
IPA_KERNEL_NAME — путь до IPA kernel image.
IPA_RAMDISK_NAME — путь до IPA initramfs image.
KOLLA_ANSIBLE_IMG_TAG — тег контейнера с kolla-ansible, используемый для пайплайна.
KEYSTACK_RELEASE — тег релиза Keystack.
CI_DEBUG_TRACE — для выведения отладочной информации в пайплайне поставить значение true.

После заполнения данных нажать кнопку “Run Pipeline”. Запустится пайплан для деплоя серверов, необходимо дождаться окончания работы.

Рисунок 9 — Пайплайн развертывания серверов

Развертывание облака

Развертывание облачной платформы

Необходимо зайти в Gitlab, перейти в репозиторий project_k → deployments → region1. Здесь находятся демонстрационные настройки для региона region1.

Для создания настроек нового региона нужно сделать форк данного репозитория и назвать его по имени нового региона. Зайти в репозиторий нового региона, перейти в Settings → General → Advanced и нажать кнопку “Remove fork relationship”.

Дальнейшее описание касается демонстрационного региона region1.

Файлы конфигурации облачной платформы

Зайти в Gitlab, перейти в репозиторий project_k → deployments → region1.

Открыть на редактирование файл inventory и заполнить его своими данными:

заполнить группы [control], [network], [compute] данными по образцу.

Открыть на редактирование файл globals.d/REGION.yml и заполнить его своими данными:

kolla_internal_vip_address — виртуальный IP-адрес для внутреннего VIP-адреса (для балансировки запросов);
kolla_external_vip_address — виртуальный IP-адрес для внешнего VIP-адреса (для балансировки запросов);
network_interface — имя интерфейса для managment-сети, на которых будет разворачиваться Openstack;
neutron_external_interface — имя интерфейса для связи с внешним миром, например, сетями провайдеров, маршрутизаторами и плавающими IP-адресами.

Открыть на редактирование файл globals.d/octavia.yml и заполнить его своими данными:

octavia_amp_network_cidr — блок IP-адресов для amphora сервиса Octavia Openstack.

Открыть на редактирование файл tf_states/settings.tf и заполнить его своими данными:

В блоке variable "pub_net":

cidr — блок IP-адресов для FIP;
allocation_start — начало блока IP-адресов для FIP;
allocation_end — конец блока IP-адресов для FIP;
dns — ДНС-сервера для FIP.

В блоке resource "openstack_compute_aggregate_v2" "dev_region":

hosts — имена серверов гипервизоров.

Запуск задачи с предварительной настройкой региона

Необходимо зайти в Gitlab и перейти в репозиторий project_k → deployments → gen-pwd.
Затем перейти в Build → Pipelines → Run Pipeline.
Заполнить переменные для пайплана, как на рисунке ниже:

OPENSTACK_ENV — имя региона и репозитория в Gitlab с настройками региона;
VIP_INTERNAL — Внутренний VIP-адрес для региона;
VIP_EXTERNAL — Внешний VIP-адрес для региона.

Рисунок 10 — Запуск пайплайна генерации секретов для region1

После заполнения данных нажать кнопку “Run Pipeline”.

Запустить задачу create-config, как на рисунке ниже.

Рисунок 11 — Запуск задачи генерации секретов для region1

Дождаться окончания работы пайплайна.

Изменение пароля для IPMI серверов гипервизора

Нужно зайти в Vault и перейти в secret_v2/deployments/region1/passwords_yml, где region1 — название репозитория с настройками региона. Затем поменять пароль в поле “ipmi_password” на пароль от интерфейса IPMI BMC серверов гипервизора.

Рисунок 12 — Изменение пароля IPMI в хранилище секретов региона.

На всех серверах нужно создать одинакового пользователя с именем и паролем, который должен быть записан в Vault. Это необходимо для работы сервиса автоэвакуации ВМ при сбое гипервизора и для сервиса Baremetal.

Запуск задачи по развертыванию региона

Перейти в репозиторий project_k → deployments → region1.
Перейти в Build → Pipelines → Run Pipeline.
Заполнить переменные для пайплана, как на рисунке ниже:

KOLLA_ARGS — переменная для передачи дополнительных тегов:
- –limit host1 — выполнение скрипта для отдельного узла Openstack;
- –tags cinder — выполнение скрипта для отдельного компонента.
KOLLA_ANSIBLE_DEPLOY_ACTION — список задач для kolla-ansible;
KOLLA_ANSIBLE_IMG_TAG — переменная для версии образа с kolla-ansible, скачиваемого из репозитория Nexus;
KEYSTACK_RELEASE — переменная, в которой указывается ветка git шаблона конфигурации в репозитории project_k → keystack.

Рисунок 13 — Запуск пайплайн развертывания облака для region1.

После заполнения данных нажать кнопку “Run Pipeline”.

Рисунок 14 — Задачи пайплайн развертывания облака для region1.

Задачи в пайплайн развертывания облака:

setup — подготовка паролей и настроек для развертывания облака;
bootstrap-servers — подготовка узлов для загрузки конфигурации (установка необходимых пакетов и конфигурирование компонентов ОС);
deploy — развертывание и запуск сервисов Openstack на узлах;
postconfig — применение квот развернутого облака;
states — наполнение развернутого облака демо-конфигурацией;
rally — валидация компонентов облака;
tempest — тестирование развернутого облака на соответствие конфигурации;
backup-db — бэкап БД MariaDB развернутого облака.

Дождаться окончания работы задачи setup.

Запустить задачу bootstrap-servers, дождаться окончания работы задачи.

Запустить задачу deploy, дождаться окончания работы задачи.

Получение openrc из Vault

На LCM-узле в консоли выполнить команду:

docker exec -ti vault vault read secret_v2/data/deployments/region1/openrc -format=json | jq -r '.data.data.value' > openrc-region1

Где region1 — название региона и репозитория в Gitlab в группе project_k → deployments.

В конец файла добавить строку:

export OS_CACERT=/installer/data/ca/cert/chain-cert.pem

По аналогии сделать для остальных регионов.

Подключение дисковых массивов

iSCSI

Протокол iSCSI является протоколом хранения данных, инкапсулирующим фреймы SCSI для передачи по IP-сетям. Для подключения iSCSI необходимо выполнить следующие действия:

Зайти в репозиторий региона.
Открыть на редактирование файл globals.d/region.yml.
Внести в файл следующие опции:

Enable_cinder_backend_iscsi: “yes”

Enable_cinder_backend_lvm: “no”

Запустить новый пайплайн с KOLLA_ARGS: -t cinder.

NFS

NFS - это сетевая файловая система, которая является методом обеспечения доступности файловой системы по сети. Для ее подключения необходимо выполнить следующие действия:

Зайти в репозиторий региона.
Открыть на редактирование файл globals.d/REGION.yml.
Внести в файл следующую опцию:

Enable_cinder_backend_nfs: “yes”

Создать новый файл в каталоге config с именем nfs_shares и внести в него записи для каждого узла хранения:

storage01:/kolla_nfs

storage02:/kolla_nfs

На узлах хранения storage01 и storage02 создать файл /etc/exports, в котором будут храниться тома:

/kolla_nfs 192.168.5.0/24(rw,sync,no_root_squash).

В данном примере /kolla_nfs - это каталог на узле хранения, в который будет смонтирован nfs; 192.168.5.0/24 - сеть хранения; rw,sync,no_root_squash - действие, делающее общий ресурс синхронным для чтения и записи и запрещающее удаленным пользователям root иметь доступ ко всем файлам.

Далее на узлах хранения запустить сервис nfsd:

systemctl start nfs

Запустить новый пайплайн с KOLLA_ARGS: -t cinder.

FC

Для подключения Huawei Dorado с поддержкой FC необходимо выполнить следующие действия:

Зайти в репозиторий региона.
Открыть на редактирование файл globals.d/REGION.yml.
Внести в файл следующие опции:

Enable_multipathd: “yes”

Enable_cinder_backend_lvm: “no”

Default_volume_type: “huawei_storage”

Создать новый файл в каталоге config/cinder с именем nfs_shares и внести в него записи:

<?xml version='1.0' encoding='UTF-8'?>
<config>
    <Storage>
        <Product>Dorado</Product>
        <Protocol>FC</Protocol>
        <UserName>user</UserName>
        <UserPassword>{{ lookup('hashi_vault', 'secret={{ vault_engine }}/data/{{ vault_prefix }}/{{ OPENSTACK_ENV | lower }}/huawei')['data']['UserPassword'] }}</UserPassword>
        <RestURL>https://IP_ADDRESS:8088/deviceManager/rest/</RestURL>
    </Storage>
    <LUN>
        <StoragePool>NAME_POOL</StoragePool>
        <LUNType>Thin</LUNType>
    </LUN>
    <FC>
        <Initiator Name="*" ALUA="1" FAILOVERMODE="1" PATHTYPE="0" />
    </FC>
</config>

Создать файл в каталоге config с именем cinder.conf с внести в него данные:

[DEFAULT]
default_volume_type = {{ default_volume_type }}
enabled_backends = huawei_storage
enforce_multipath_for_image_xfer = true
use_multipath_for_image_xfer = true

[huawei_storage_high]
allowed_direct_url_schemes = cinder
cinder_huawei_conf_file = /etc/cinder/nfs_shares
enforce_multipath_for_image_xfer = true
use_multipath_for_image_xfer = true
volume_backend_name = huawei_storage
volume_driver = cinder.volume.drivers.huawei.huawei_driver.HuaweiFCDriver
backend_host = huawei

Создать файл в каталоге config с именем multipath.conf и внести в него данные:

defaults {
   user_friendly_names no
   find_multipaths yes
}

blacklist {
}

devices {
  device {
     vendor "HUAWEI"
     product "XSG1"
     path_grouping_policy "multibus"
     path_selector "service-time 0"
     path_checker "tur"
     prio "const"
     failback "immediate"
     dev_loss_tmo 30
     fast_io_fail_tmo 5
     no_path_retry 15
  }
}

Запустить новый пайплайн с KOLLA_ARGS:
- -t cinder, multipath.

Описание системы обновления LCM

Реализованная система обновления разделена на две основные составляющие части:

Обновление репозиториев в Gitlab.
Обновление и добавление новых контейнеров Openstack в Nexus.

Для обновления этих компонентов используются сценарии (пайплайны), созданные в gitlab-ci.

Обновление репозиториев и контейнеров

В репозитории project_k/services/upgrade, который размещен в Gitlab, есть один пункт в пайплайне, отвечающий за обновление компонентов LCM.

Для обновления компонентов необходимо выполнить следующие действия:

Зайти на узел LCM по ssh, а затем перейти в каталог /installer/update.
Скачать или переместить ранее скачанное обновление в этот каталог.
В репозитории project_k/deployments/upgrade зайти в раздел CI/CD и выбрать “Pipelines”, чтобы открыть пайплайны.

Рисунок 15 - Выбор нужного пайплайна

Запустить новый пайплайн, нажав кнопку “Run pipeline”.

Рисунок 16 - Запуск выбранного пайплайна

Рисунок 17 - Запуск процесса обновления

После успешного завершения пайплайна необходимо удалить все из каталога /installer/update.