Руководство администратора KeyStack

Введение

Полное наименование системы — KeyStack.

Краткое наименование системы — Платформа.

Разработчик системы — ITKey.

Краткое описание возможностей

Платформа динамической инфраструктуры предназначена для предоставления сервисов IaaS.

Требования к квалификации персонала

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

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

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

К системным администраторам предъявляются следующие требования:

Навыки системного администрирования Linux;
Прохождение обучения от компании ITKey по использованию компонентов, разработанных вендором: DRS, HA, Portal;
Навыки работы со службами Платформы, в том числе способность самостоятельно осуществлять:
- мониторинг программными средствами, внешний осмотр аппаратной составляющей комплекса;
- изменение настроек Платформы;
- сбор диагностических данных и эскалацию сложных проблем по гарантийным обязательствам производителю.

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

Перечень эксплуатационной документации

Документация Платформы включает в себя следующие документы:

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

Назначение и условия применения

Виды деятельности, функции

В состав Платформы входят следующие подсистемы:

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

Программные и аппаратные требования к Платформе

Требования к инфраструктуре приведены в Инструкции по установке.

Подготовка к работе

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

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

Портал самообслуживания;
интерфейс Horizon;
Opensearch;
Grafana;
Prometheus
API компонентов Платформы.

Основным рабочим веб-интерфейсом является Horizon.

Помимо веб-интерфейса, в работе используется Openstack CLI.

Подключение к Порталу самообслуживания

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

Google Chrome 72 и выше;
Mozilla Firefox 63 и выше.

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

Рисунок 1 — Окно аутентификации в Портале самообслуживания

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

Подключение к интерфейсу управления Openstack CLI

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

Important

Если используется библиотека Castellan, то при работе в Openstack CLI у администратора при каждом подключении будет запрашиваться пароль.

Openstack клиент можно установить на рабочее место администратора. Ниже приведен порядок установки Openstack клиента для различных ОС.

Установка Openstack клиента под Linux

Установка клиента Openstack:

sudo pip install python-openstackclient

Для проверки корректности настроек можно выполнить команду openstack server list, которая возвращает список ВМ.

Обновление клиента Openstack:

sudo pip install --upgrade python-openstackclient

Удаление клиента Openstack:

sudo pip uninstall python-openstackclient

Установка OpenStack CLI под Windows

Требуется установка последней версии Python с официального сайта http://python.org/downloads/windows. Дальнейшие инструкции выполняются в PowerShell.

Проверка работоспособности Python:

pip

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

Установка, обновление и удаление клиента Openstack выполняются аналогично разделу Установка Openstack клиента под Linux.

Запуск и выключение Платформы

Запуск Платформы

Почти все сервисы платформы — stateless, или имеют внутренние механизмы failover, прихода к консенсусу в кластере. Но есть сервис, на который надо обратить особое внимание — Galera Cluster. Поэтому в пункте Выключение всех компонентов Платформы важно было делать паузы перед выключением следующего узла и запомнить порядок выключения — это минимизирует до определенной степени шанс получить с “несобранным” кластером Galera Cluster с MariaDB после включения.

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

Включите с паузами и по очереди управляющие узлы. Включайте в обратном порядке относительно выключения, т.е. если серверы были выключены в порядке controller1 → controller2 → controller3, то тогда, выдерживая достаточные паузы в 5-10 минут после загрузки Linux, производите включение в порядке controller3 → controller2 → controller1. При этом крайне желательно после загрузки сервера (в данном примере controller1) выполнить проверку статуса MariaDB.

Пример:

ssh controller1
mysql -uroot  -pPassW0rd  -s -s --execute="SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';"
wsrep_local_state_comment       Synced

Если в течение 5 минут статус не перейдет в Synced, все равно продолжайте с запуском остальных управляющих узлов. Когда узлы будут запущены, и позже будут запущены контейнеры consul-server, произойдет автоматический ребутстрап кластера MariaDB.

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

Выключение всех компонентов Платформы

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

Оповестить владельцев виртуальных машин о предстоящем отключении.
Выключить сервис DRS, деактивировав задание в панели администратора, затем последовательно подключившись к каждому контроллеру и введя команду systemctl stop kolla-drs-container.service.
Выключить сервис HA, последовательно подключившись к каждому контроллеру и введя команду systemctl stop kolla-consul-container.service.
Подключиться к серверу LCM для выполнения дальнейших действий.

Пример:

ssh lcm
source admin-openrc.sh

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

openstack server list --all-projects > VMs.$(date "+%Y-%m-%d-%H-%M-%S").txt

Выключить виртуальные машины средствами OpenStack, введя команду:

openstack server list --all-projects -c ID -f value | \
 xargs -n1 openstack server stop

Проверить выключение всех виртуальных машин командой:

openstack server list --all-projects -c ID -c Status -f value | \
 grep -v Active

Note

Если проверка покажет наличие виртуальных машин в статсуе ACTIVE, то необходимо повторить выключение каждой такой виртуальной машины индивидуально, введя команду openstack server stop <VM ID>, подставляя в качестве VM ID значенем из столбца ID предыдущего вывода.

Выключить узлы-гипервизоры средствами операционной системы:

for HOST in $(openstack hypervisor list -c "Hypervisor Hostname" -f value);\
  do \
   ssh -x ${HOST} "shutdown -h now";\
  done

В строгом порядке очерёдности control3 → control2 → control1, с паузами достаточными для полного выключения сервера (время зависит от используемого аппаратного комплекса и должно быть уточнено в момент проведения ПСИ) средствами операционной системы выключить узлы слоя управления, проверяя процесс выключения и состояние серверов через IPMI:

ssh -x ctl3 ‘shutdown -h now’
# пауза до полного выключения
ssh -x ctl2 ‘shutdown -h now’
# пауза до полного выключения
ssh -x ctl1 ‘shutdown -h now’
# пауза до полного выключения

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

Описание операций

В частной инсталляции Платформы не все опции команд Openstack CLI могут быть использованы, поэтому они приводятся для справки. Некоторые виды и типы интеграций могут быть недоступны и через API.

Управление квотами проекта

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

Управление квотами проекта осуществляется через CLI.

Пример запроса квот проекта по API (CLI)

С помощью команды openstack quota show --default можно увидеть список всех квот по умолчанию:

openstack quota show --default

+------------------------------+----------+

| Field                        | Value    |

+------------------------------+----------+

| backup-gigabytes             | 1000     |

| backups                      | 10       |

| cores                        | 100      |

| fixed-ips                    | -1       |

| floating-ips                 | 10       |

| gigabytes                    | 650      |

| gigabytes___DEFAULT__        | -1       |

| gigabytes_volumes-huawei     | -1       |

| gigabytes_volumes-huawei-new | -1       |

| gigabytes_volumes-ssd        | -1       |

| groups                       | 10       |

| health_monitors              | None     |

| injected-file-size           | 10240    |

| injected-files               | 5        |

| injected-path-size           | 255      |

| instances                    | 50       |

| key-pairs                    | 10000    |

| l7_policies                  | None     |

| listeners                    | None     |

| load_balancers               | None     |

| name                         | None     |

| networks                     | 100      |

| per-volume-gigabytes         | -1       |

| pools                        | None     |

| ports                        | 10000    |

| project                      | None     |

| project_name                 | admin    |

| properties                   | 128      |

| ram                          | 358400   |

| rbac_policies                | 10000    |

| routers                      | 10       |

| secgroup-rules               | 10000    |

| secgroups                    | 10000    |

| server-group-members         | 100      |

| server-groups                | 50       |

| snapshots                    | 10       |

| snapshots___DEFAULT__        | -1       |

| snapshots_volumes-huawei     | -1       |

| snapshots_volumes-huawei-new | -1       |

| snapshots_volumes-ssd        | -1       |

| subnet_pools                 | -1       |

| subnets                      | 100      |

| volumes                      | 50       |

| volumes___DEFAULT__          | -1       |

| volumes_volumes-huawei       | -1       |

| volumes_volumes-huawei-new   | -1       |

| volumes_volumes-ssd          | -1       |

+------------------------------+----------+

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

openstack quota show f538ffe832f34890ab5402995ff73102

+------------------------------+------------------+

| Field                        | Value            |

+------------------------------+------------------+

| backup-gigabytes             | 1000             |

| backups                      | 10               |

| cores                        | 100              |

| fixed-ips                    | -1               |

| floating-ips                 | 10               |

| gigabytes                    | 1000             |

| gigabytes___DEFAULT__        | -1               |

| gigabytes_volumes-huawei     | -1               |

| gigabytes_volumes-huawei-new | -1               |

| gigabytes_volumes-ssd        | -1               |

| groups                       | 10               |

| health_monitors              | None             |

| injected-file-size           | 10240            |

| injected-files               | 5                |

| injected-path-size           | 255              |

| instances                    | 40               |

| key-pairs                    | 10000            |

| l7_policies                  | None             |

| listeners                    | None             |

| load_balancers               | None             |

| name                         | None             |

| networks                     | 100              |

| per-volume-gigabytes         | -1               |

| pools                        | None             |

| ports                        | 500              |

| project_name                 | xcloud-devops    |

| properties                   | 128              |

| ram                          | 200000           |

| rbac_policies                | 10000            |

| routers                      | 100              |

| secgroup-rules               | 1000             |

| secgroups                    | 1000             |

| server-group-members         | 10               |

| server-groups                | 10               |

| snapshots                    | 100              |

| snapshots___DEFAULT__        | -1               |

| snapshots_volumes-huawei     | -1               |

| snapshots_volumes-huawei-new | -1               |

| snapshots_volumes-ssd        | -1               |

| subnet_pools                 | -1               |

| subnets                      | 100              |

| volumes                      | 100              |

| volumes___DEFAULT__          | -1               |

| volumes_volumes-huawei       | -1               |

| volumes_volumes-huawei-new   | -1               |

| volumes_volumes-ssd          | -1               |

+------------------------------+------------------+

Работа с флейворами ВМ

Просмотр списка флейворов ВМ

Просматривайте флейворы на Портале администратора либо в в Openstack CLI.

Просмотр списка флейворов в Openstack CLI выполняется командой:

openstack flavor list

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

+-----+-----------+-------+------+-----------+-------+-----------+
| ID  |   Name    |  RAM  | Disk | Ephemeral | VCPUs | Is_Public |
+-----+-----------+-------+------+-----------+-------+-----------+
|  1  | m1.tiny   | 512   |    1 |         0 |     1 | True      |
+-----+-----------+-------+------+-----------+-------+-----------+

Для просмотра списка флейворов на Портале администратора перейдите в раздел Ресурсы → Flavors.

Настройка приоритетов на базе cpu-shares и cpu-quotes для ВМ с помощью флейворов

В разделе Ресурсы → Flavors на Портале администратора вы можете установить приоритеты для выделения ресурсов при наличии конкуренции за них. Для этого используйте либо quota:cpu_shares, либо quota:cpu_quota, но не оба параметра сразу. Параметры определяют приоритет потребления CPU и Memory для ВМ, созданных из этих флейворов, в пределах хоста или пула ресурсов. Чем выше значение одного или другого приоритета, тем больше ресурсов получит ВМ в пределах пула или отдельного хоста.

Чтобы установить приоритет по выделению ресурсов для ВМ с помощью флейвора, выполните следующие действия:

На вкладке Ресурсы → Flavors нажмите выпадающий список в столбце “Actions” для нужного флейвора. Выберите “Pедактировать”.
В открывшемся окне проверьте имя и ID флейвора.
Выберите quota:cpu_shares либо quota:cpu_quota в Quota priority key. Задайте значение для этого параметра в поле Quota priority value.
Нажмите “Применить”.

Рисунок 2 — Настройка приоритетов для флейворов

Добавленные квоты появятся в столбце “extra_specs” в таблице флейворов.

Создание флейвора ВМ

В Openstack CLI создание нового флейвора выполняется командой flavor create. Пример:

openstack flavor create --ram 512 --disk 1 --vcpus 1 <flavor-name>

где ram — размер оперативной памяти, disk — объем диска в GB, vcpus — количество vCPU, а <flavor-name> — наименование флейвора.

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

openstack flavor create
      [--id <id>]
      [--ram <size-mb>]
      [--disk <size-gb>]
      [--ephemeral <size-gb>]
      [--swap <size-mb>]
      [--vcpus <vcpus>]
      [--rxtx-factor <factor>]
      [--public | --private]
      [--property <key=value>]
      [--project <project>]
      [--description <description>]
      [--project-domain <project-domain>]
      <flavor-name>

где:

–id <id> — ID шаблона; ‘auto’ создает UUID (значение по умолчанию: auto);

–ram <MB> — размер памяти в MB (значение по умолчанию: 256MB);

–disk <GB> — размер диска в GB (значение по умолчанию: 0GB);

–ephemeral <GB> — размер эфемерного диска в GB (значение по умолчанию: 0GB);

–swap <MB> — дополнительный размер swap в MB (значение по умолчанию: 0MB);

–vcpus <vcpus> — количество vCPU (значение по умолчанию: 1);

–rxtx-factor <factor> — RX/TX фактор (значение по умолчанию: 1.0);

–public — шаблон доступен в других проектах (значение по умолчанию);

–private — шаблон недоступен в других проектах;

–property <key=value> — дополнительные свойства флейвора (опция может использоваться несколько раз для установки различных свойств);

–project <project> — разрешает доступ к флейвору из проекта <project> (по имени проекта или его ID), опция используется совместно с –private;

–description <description> — описание флейвора;

–project-domain <project-domain> — домен проекта (имя домена или его ID). Опция используется в случае конфликтов между названиями проектов;

–<flavor-name> — наименование флейвора.

На Портале администратора:

В левом меню Портала перейдите в раздел Ресурсы → Flavors.
Нажмите кнопку “Создать flavor”.
Добавьте имя, описание, значения RAM и vCPUs для флейвора.
В разделе Extra specs укажите приоритеты для выделения ресурсов на ВМ, основанных на флейворе. Выберите quota:cpu_shares либо quota:cpu_quota в Quota priority key. Задайте значение для выбранного параметра в поле Quota priority value. Подробнее о приоритетах для ресурсов ВМ см. выше.

Рисунок 3 — Новый флейвор

Нажмите “Создать”.

Удаление флейвора ВМ

В Openstack CLI удаление флейвора ВМ выполняется командой:

openstack flavor delete <flavor> [<flavor> ...]

где <flavor> — наименование или ID флейвора. Одновременно может быть удалено несколько флейворов.

На Портале администратора для удаления флейвора выберите действия “Удалить” в столбце “Actions” для нужного флейвора.

Работа с шаблонами ВМ

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

Создание шаблона

В левом меню Портала перейдите в раздел Ресурсы → ВМ.
Нажмите кнопку “Создать ВМ”.
Если нет шаблона, выберите действие Save as new template в открывшемся окне.
Заполните поле Project. После выбора проекта будут доступны для заполнения остальные поля.

Рисунок 4 — Новый шаблон ВМ

Нажмите “Создать”.

Редактирование шаблона

В левом меню Портала перейдите в раздел Ресурсы → ВМ.
Нажмите кнопку “Создать ВМ”.
Выберите действие Choose template в открывшемся окне. Название выбранного шаблона отобразится на месте кнопки Choose template, а справа будут параметры создаваемой ВМ.
Найдите нужный шаблон в окне Templates. Нажмите значок > в столбце “Params”, чтобы посмотреть параметры шаблона.
Выберите дальнейшее действие с шаблоном в столбце “Actions”:
- Для изменения параметров шаблона выберите Apply template.
- Для изменения названия шаблона (Template name) или его описания (Template description) выберите Edit template. Нажмите “Редактировать”, чтобы применить изменения.
- Для удаления шаблона выберите Delete template.

Рисунок 5 — Редактирование шаблона ВМ

Если вы выбрали действие Apply template, название выбранного шаблона отобразится на месте кнопки Choose template. Настройте параметры шаблона на вкладке Template params.
Выберите, как сохранить изменения параметров шаблона:
- Чтобы применить изменения к отредактированному шаблону, нажмите Save current template.
- Чтобы сохранить его как новый шаблон, нажмите Save as new template.

Создание ВМ из шаблона

В левом меню Портала перейдите в раздел Ресурсы → ВМ.
Нажмите кнопку “Создать ВМ”.
Выберите действие Choose template в открывшемся окне.
Найдите нужный шаблон в окне Templates и выберите для него Apply template в столбце “Actions”.
Название выбранного шаблона отобразится на месте кнопки Choose template, а справа будут параметры создаваемой ВМ. Настройте параметры создаваемой ВМ на вкладке New VM params.
Нажмите “Создать”.

Новая виртуальная машина со статусом BUILD появится в списке машин на странице ВМ.

Работа с образами ВМ

Просмотр списка образов

Просмотр образов осуществляется на Портале администратора, в интерфейсе Horizon или с использованием Openstack CLI.

Для просмотра списка образов на Портале необходимо в левом меню перейти в раздел Ресурсы → Images. Пример вида раздела представлен на рисунке ниже.

Рисунок 6 — Пример списка образов

Для просмотра списка образов в Openstack CLI выполните команду: openstack image list

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

+--------------------------------------+-----------------------------------+--------+
| ID                                   | Name                              | Status |
+--------------------------------------+-----------------------------------+--------+
| 42f43e9d-7c53-46fa-ad87-846ef524d721 | CentOS-7-x86_64-GenericCloud-1905 | active |

Создание образа

Создание образа осуществляется в Портале самообслуживания, в интерфейсе Horizon или с использованием Openstack CLI. Образ можно создать путем загрузки файла в формате либо путем создания из существующего диска. Поддерживаются следующие форматы: raw, vhd, vhdx, vmdk, vdi, iso, ploop, qcow2, aki, ari и ami.

Создание образа из файла

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

В левом меню Портала перейдите в раздел Ресурсы → Images.
Нажмите кнопку “Загрузить Image”.
Заполните поля. Обязательно нужно указать имя образа, тип ОС и выбрать файл для образа. Пример заполнения см. на рисунке ниже.
Нажмите кнопку “Начать загрузку”.

Рисунок 7 — Создание образа из файла

Для загрузки образа размером более 20GB рекомендуется использовать клиента командной строки.

Для загрузки образа в Openstack CLI выполните команду: openstack image create --private --container-format bare --disk-format qcow2 --file <имя_файла.raw> <имя_образа>

Если необходимо загрузить образ с поддержкой резервного копирования или смены пароля, добавьте свойства для работы с qemu-guest-agent: openstack image create --private --container-format bare --disk-format qcow2 --file <имя_файла.raw> --property hw_qemu_guest_agent=yes --property os_require_quiesce=yes <имя_образа>

Создание образа из существующего диска

Вы можете создать образ из существующего диска в интерфейсе Horizon. Для этого необходимо в левом меню перейти в раздел Диски, найти диск, из которого будет создаваться образ, и затем в выпадающем списке выбрать пункт меню “Загрузить образ”.

В форме создания образа нужно выбрать формат диска (см. рисунок ниже), указать название образа и нажать кнопку “Загрузить”.

Рисунок 8 — Создание образа из существующего диска

Загрузка образов в Glance

Вы можете загружать образы гостевых ВМ в Glance. Запрос на создание и загрузку образов в Glance передается в модуль states через Terraform в виде переменной user_images.

В файл tf_states/variables.tf добавьте переменную user_images следующего вида:

variable "user_images" {
   description = "Pass user images as map"
   type        = map(any)
   default     = {
      # Below is an example of user image definition
      "ubuntu-24.04-x64" = {
         image_source_url = "https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img"
         container_format = "bare"
         disk_format = "qcow2"
         min_disk_gb = 5
         visibility = "public"
         properties = {
            os_distro = "ubuntu"
            os_type = "linux"
            os_version = "24.04"
            os_require_quiesce = "True"
            ssh_key = "allow"
            hw_machine_type = "q35"
         }
      }
   }
}

После чего убедитесь, что эта переменная используется в модуле tf_states, вызываемом из файла tf_states/main.tf:

module "tf_states" {
  ...
  user_images    = var.user_images
}

Выгрузка образа

Выгрузка образа в файл выполняется в Openstack CLI следующей командой: openstack image save --file <file-name> <image-id>

где <file-name> — имя локального файла, а <image-id> — ID образа.

Удаление образа

Удалить образ ВМ можно на Портале администратора или в интерфейсе Horizon.

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

Перейдите в раздел Ресурсы → Images, выберите образ для удаления и нажмите значок X в столбце “Actions”.
Проверьте имя и ID образа. Если все правильно, нажмите кнопку “Удалить” (см. рисунок ниже).

Рисунок 9 — Удаление образа

Включение множества очередей (multiqueue) в Unix-подобных операционных систем

KeyStack поддерживает множества очередей (multiqueue) у образа виртуальной машины (ВМ) и отдельной ВМ для операционных систем семейства Linux.

Ограничения

Функция множества очередей virtio-net обеспечивает повышение производительности, но имеет некоторые ограничения:

ОС ВМ ограничена ~ 200 векторами MSI. Для каждой очереди сетевого адаптера требуется вектор MSI, а также любое устройство virtio или назначенное устройство PCI. Определение экземпляра с несколькими сетевыми адаптерами virtio и виртуальными ЦП может привести к превышению лимита гостевого MSI.
Множества очередей хорошо работают для входящего трафика, но иногда могут вызвать снижение производительности для исходящего трафика.
Включение множества очередей увеличивает общую пропускную способность сети, но одновременно увеличивает потребление ресурсов CPU.
Если функция множества очередей была включена на хосте, но не была включена администратором в ОС ВМ, векторы MSI будут использоваться впустую.
Количество очередей автоматически устанавливается равным количеству виртуальных ЦП. Чем больше количество ЦП, тем выше пропускная способность сети.

Примечание. Для некоторых образов операционных систем, например, Centos6, недостаточно включить множества очередей только на уровне образа в конфигурации QEMU. Администратору ОС необходимо вручную включить функциональность с помощью ethtool на самой ВМ.

Включение множества очередей для новых ВМ из образа

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

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

openstack image list
Скопируйте ID нужного образа.
Включите множество очередей, введя команду:

openstack image set <IMG_ID> --property hw_vif_multiqueue_enabled=true

Проверка количества очередей

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

ip link show

Ожидаемый вывод:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo qlen 1000
link/ether fa:16:3e:e0:91:1e brd ff:ff:ff:ff:ff:ff

Здесь eth0 — сетевой интерфейс, для которого нужно проверить подключение множества очередей.

Посмотрите текущее количество очередей, введя команду:

ethtool -l <имя_сетевого_интерфейса>

Ожидаемый вывод:

Channel parameters for external:
Pre-set maximums:
RX:             n/a
TX:             n/a
Other:          n/a
Combined:       1
Current hardware settings:
RX:             n/a
TX:             n/a
Other:          n/a
Combined:       1

Установка нужного количества очередей для ВМ

Количество очередей не может быть больше количества виртуальных ЦП.

Выполните команду:

sudo ethtool -L <имя_сетевого_интерфейса> combined <число_очередей>

Пример ввода:

$ sudo ethtool -L eth0 combined 2

Проверьте новое количество очередей, введя команду:

ethtool -l <имя_сетевого_интерфейса>

Ожидаемый вывод:

Channel parameters for external:
Pre-set maximums:
RX:             n/a
TX:             n/a
Other:          n/a
Combined:       1
Current hardware settings:
RX:             n/a
TX:             n/a
Other:          n/a
Combined:       2

Работа с ВМ

Просмотр списка ВМ

Просмотр списка ВМ проекта осуществляется в интерфейсе Портала администратора, Horizon или в Openstack CLI.

Для просмотра списка ВМ на Портале администратора необходимо выбрать Ресурсы → ВМ в левом меню интерфейса (см. рисунок ниже).

Рисунок 10 — Список ВМ на Портале администратора

Используйте фильтры в правом верхнем углу интерфейса для быстрого поиска нужных ВМ по определенным параметрам, таким как образ (image), MAC-адрес (MAC address), IP и LUN ID.

Просмотр списка ВМ в CLI выполняется командой server list. Полный перечень опций выглядит следующим образом:

openstack server list
      [--sort-column SORT_COLUMN]
      [--reservation-id <reservation-id>]
      [--ip <ip-address-regex>]
      [--name <name-regex>]
      [--instance-name <server-name>]
      [--status <status>]
      [--flavor <flavor>]
      [--image <image>]
      [--host <hostname>]
      [--all-projects]
      [--project <project>]
      [--project-domain <project-domain>]
      [--user <user>]
      [--user-domain <user-domain>]
      [--long]
      [-n | --name-lookup-one-by-one]
      [--marker <server>]
      [--limit <num-servers>]
      [--deleted]
      [--changes-before <changes-before>]
      [--changes-since <changes-since>]
      [--locked | --unlocked]
      [--tags <tag>]
      [--not-tags <tag>]

где:

–sort-column SORT_COLUMN — столбцы для сортировки данных (несуществующие столбцы игнорируются);

–reservation-id <reservation-id> — возвращать экземпляры ВМ, соответствующие резервированию;

–ip <ip-address-regex> — регулярное выражение для отбора ВМ по соответствующим адресам;

–name <name-regex> — регулярное выражение для отбора ВМ по имени;

–instance-name <server-name> — регулярное выражение для отбора ВМ по имени инстанса;

–status <status> — отбирать ВМ по указанному статусу;

–flavor <flavor> — отбирать ВМ по указанному шаблону ВМ (по наименованию или ID);

–image <image> — отбирать ВМ по указанному образу (по наименованию или ID);

–host <hostname> — отбирать ВМ по гипервизору размещения;

–all-projects — включать в выборку все проекты;

–project <project> — отбирать ВМ в указанном проекте (по наименованию или ID);

–project-domain <project-domain> — отбирать ВМ по домену проекта (по наименованию или ID). Опция используется в случае конфликтов между названиями проектов;

–user <user> — отбирать ВМ указанного пользователя (по имени или ID);

–user-domain <user-domain> — отбирать ВМ по домену пользователя (по имени или ID). Опция используется в случае конфликтов между именами пользователей;

–long — выводить дополнительные поля;

-n, –no-name-lookup — пропустить разрешение имен шаблонов ВМ и образов. Не используется совместно с опцией –name-lookup-one-by-one;

–name-lookup-one-by-one — при разрешении имен шаблонов ВМ и образов искать из по мере необходимости. Не используется совместно с опцией –no-name-lookup|-n;

–marker <server> — последняя ВМ предыдущей страницы. Выводит весь список ВМ после <server>, если не указано иное. Если используется с опцией –deleted, маркер <server> должен быть идентификатором (ID), иначе допускается использование наименование ВМ или ID;

–limit <num-servers> — максимальное количество ВМ в выводимом списке. Если указывается значение -1, тогда выводятся все ВМ. Если указанное значение <num-servers> превышает значение конфигурационного параметра osapi_max_limit, то выводится osapi_max_limit ВМ;

–deleted — выводить только удаленные ВМ;

–changes-before <changes-before> — выводить список ВМ, измененных до указанного момента времени. Указываемое время должно быть в формате ISO 8061 (например, 2016-03-05T06: 27: 59Z);

–changes-since <changes-since> — выводить список ВМ, измененных после указанного момента времени. Указываемое время должно быть в формате ISO 8061 (например, 2016-03-05T06: 27: 59Z);

–locked — выводить в список только заблокированные ВМ;

–unlocked — выводить в спискок только незаблокированные ВМ;

–tags <tag> — выводить ВМ с указанными тегами. Может использоваться несколько раз для отбора ВМ по нескольким тегам;

–not-tags <tag> — выводить только те ВМ, у которых нет указанного тега. Может использоваться несколько раз для указания нескольких тегов.

Запуск, перезапуск и остановка ВМ

Запуск, перезапуск и остановка ВМ осуществляется в интерфейсе Портала администратора, Horizon или в OpenStack CLI.

Для управления состоянием ВМ в интерфейса Horizon используйте кнопки “Выключить инстанс”, “Горячая перезагрузка инстанса” и “Холодная перезагрузка инстанса” (см. рисунок ниже).

Рисунок 11 — Кнопки управления состоянием ВМ

Текущий статус виртуальной машины отображается в столбце “Status” (см. рисунок выше).

В Openstack CLI операции запуска, перезапуска и остановки ВМ выполняются командами server start, server reboot и server stop соответственно. Синтаксис команд:

openstack server start <server> [<server> ...]
openstack server reboot [--hard | --soft] [--wait] <server>
openstack server stop <server> [<server> ...]

где:

<server> [ …] — ВМ или список ВМ (имя ВМ или ID);

–hard — “жесткая” перезагрузка;

–soft — “мягкая” перезагрузка;

–wait — дождаться завершения перезагрузки.

Создание ВМ

Создание ВМ осуществляется в интерфейсе Портала администратора, Horizon или в OpenStack CLI.

Для создания ВМ в Horizon необходимо выбрать Вычислительные ресурсы → Инстансы в левом меню интерфейса и нажать кнопку “Запустить инстанс”.

В форме “Создание нового инстанса” необходимо указать параметры создаваемой ВМ (см. рисунок ниже):

Instance — укажите имя ВМ;
Volume size — размер диска в GB;
Image — выберите образ из списка доступных;
Flavor — шаблон виртуальной машины, выберите из списка доступных
Key pairs — создайте новую ключевую пару или используйте существующую в проекте;
Network — укажите сеть, в которой будет доступна ВМ из списка сетей;
Security groups — укажите одну или несколько групп безопасности из списка доступных.

Рисунок 12 — Создание новой ВМ

Создание ВМ в Openstack CLI выполняется следующей командой:

openstack server create
      (--image <image> | --image-property <key=value> | --volume <volume>)
      [--password <password>]
      --flavor <flavor>
      [--security-group <security-group>]
      [--key-name <key-name>]
      [--property <key=value>]
      [--file <dest-filename=source-filename>]
      [--user-data <user-data>]
      [--description <description>]
      [--availability-zone <zone-name>]
      [--host <host>]
      [--hypervisor-hostname <hypervisor-hostname>]
      [--boot-from-volume <volume-size>]
      [--block-device-mapping <dev-name=mapping>]
      [--nic <net-id=net-uuid,v4-fixed-ip=ip-addr,v6-fixed-ip=ip-addr,port-id=port-uuid,auto,none>]
      [--network <network>]
      [--port <port>]
      [--hint <key=value>]
      [--use-config-drive | --no-config-drive | --config-drive <config-drive-volume>|True]
      [--min <count>]
      [--max <count>]
      [--wait]
      [--tag <tag>]
      <server-name>

где:

–image <image> — создать ВМ с использованием существующего образа (наименование или ID);

–image-property <key=value> — изменяемые свойства используемого образа;

–volume <volume> — создать ВМ с использованием указанного диска (наименование или ID). Данная опция автоматически создает отображение блочного устройства с индексом загрузки 0. Не следует использовать дублирующее сопоставление с использованием опции –block-device-mapping;

–password <password> — установить пароль для создаваемой ВМ;

–flavor <flavor> — использовать указанный шаблон (наименование или ID);

–security-group <security-group> — группа безопасности, назначаемая ВМ. Может использоваться несколько раз для назначения нескольких групп безопасности;

–key-name <key-name> — используемая ключевая пара (необязательный параметр);

–property <key=value> — установить дополнительные свойства ВМ (может указываться несколько раз для установки нескольких свойств);

–file <dest-filename=source-filename> — добавить в образ ВМ указанный файл (может указываться несколько раз для добавления разных файлов);

–user-data <user-data> — файл данных пользователя для обслуживания с сервера метаданных;

–description <description> — описание создаваемой ВМ;

–availability-zone <zone-name> — установить зону доступности ВМ;

–host <host> — создать ВМ с использованием службы Nova на конкретном гипервизоре;

–hypervisor-hostname <hypervisor-hostname> — создавать ВМ на указанном гипервизоре;

–boot-from-volume <volume-size> — при использовании в сочетании с параметром –image или –image-property этот параметр создает сопоставление блочного устройства с индексом загрузки 0 и сообщает службе compute создать том заданного размера (в GB) из указанного образа и использовать его в качестве корневого тома. Корневой том не будет удален при удалении ВМ. Этот параметр является взаимоисключающим с параметром –volume;

–block-device-mapping <dev-name=mapping> — создать блочное устройство. Блочное устройство указывается в формате <dev-name>=<id>:<type>:<size(GB)>:<delete-on-terminate>, где:

<dev-name> — наименование блочного устройства, например, vdb, xvdc (обазательный параметр);
<id> — наименование или ID тома, снапшота или образа (обязательный параметр);
<type> — volume (том), snapshot (снапшот) или image (образ). Значение по умолчанию — volume;
<size(GB)> — размер тома, если он создается из снапшота или образа (необязательный параметр);
<delete-on-terminate> — true или false, удалять при удалении ВМ. Значение по умолчанию — false (необязательный параметр);

–nic <net-id=net-uuid,v4-fixed-ip=ip-addr,port-id=port-uuid,auto,none> — создать сетевой адаптер. Опция используется несколько раз для создания нескольких адаптеров. Необходимо указывать ID сети или ID порта, но не оба сразу;

net-id — подключить сетевой адаптер к сети с UUID net-uuid;
port-id — подключить сетевой адаптер к порту с UUID port-uuid;
v4-fixed-ip — фиксированный IPv4-адрес сетевого адаптера (необязательный параметр);
none — сеть не подключена;
auto — автоматическое выделение сети.

–network <network> — создать сетевой адаптер и подключить к сети. Можно указывать несколько раз для создания нескольких сетевых адаптеров. Данная опция является оболочкой для опции –nic net-id=<network>, которая обеспечивает простой синтаксис для стандартного варианта подключения новой ВМ к сети. Для более сложных случаев рекомендуется использовать полный синтаксис –nic;

–port <port> — создать сетевой адаптер и подключить его к порту. Можно указывать несколько раз для создания нескольких сетевых адаптеров. Данная опция является оболочкой для опции –nic port-id=<port>, которая обеспечивает простой синтаксис для стандартного подключения новой ВМ к заданному порту. Для более сложных случаев рекомендуется использовать полный синтаксис –nic;

–hint <key=value> — подсказки для планировщика (необязательный параметр);

–use-config-drive — разрешает использование конфигурационного диска;

–no-config-drive — запрещает использование конфигурационного диска;

–config-drive <config-drive-volume>|True — устаревшая опция указания использования указанного тома в качестве диска конфигурации. Заменено на –use-config-drive;

–min <count> — минимальное количество ВМ для запуска. Значение по умолчанию — 1;

–max <count> — максимальное количество ВМ для запуска. Значение по умолчанию — 1;

–wait — дождаться окончания сборки;

–tag <tag> — теги ВМ. Можно указывать несколько раз для добавления нескольких тегов;

<server-name> — наименование ВМ.

Создание ВМ с поддержкой secure boot

Предварительные требования:

образ, из которого будет создаваться виртуальная машина, должен быть собран с поддержкой UEFI;
в метаданные образа добавлены свойства os_secure_boot=required и hw_firmware_type=uefi.

Добавить свойства можно через Horizon или CLI: openstack image set --property hw_firmware_type=uefi --property os_secure_boot=required $IMAGE.

Администратор может запретить безопасную загрузку даже при наличии необходимых свойств в метаданных образа: openstack flavor set --property os:secure_boot=disabled $FLAVOR

Также есть возможность запрашивать безопасную загрузку, если хост ее поддерживает. Это делается через настройку метаданных образа: openstack image set --property os_secure_boot=optional $IMAGE

Узнать, поддерживает ли хост безопасную загрузку, можно таким образом:

COMPUTE_UUID=$(openstack resource provider list --name $HOST -f value -c uuid)
openstack resource provider trait list $COMPUTE_UUID | grep COMPUTE_SECURITY_UEFI_SECURE_BOOT

Мониторинг производительности ВМ

Вы можете просматривать потребление ресурсов виртуальных машин в интерфейсе Портала администратора. На странице каждой ВМ доступны графики со статистикой по таким показателям, как CPU (cpu), память (mem), входящий и исходящий трафик сети (network_in и network_out). Статистика обновляется каждые 10 минут.

Для просмотра производительности ВМ выберите Ресурсы → ВМ в левом меню Портала и нажмите ссылку с ID любой машины.

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

Рисунок 13 — Статистика по ВМ

Мониторинг производительности вычислительных узлов

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

Для просмотра производительности вычислительного узла выберите Гипервизоры → Гипервизоры в левом меню Портала и нажмите ссылку с ID необходимого узла.

Рисунок 14 — Статистика по вычислительным узлам

Метрики вычислительных узлов отображают следующую информацию:

cpu — загрузка процессора в процентах;
memory — загрузка памяти в процентах;
network_interface_state — состояние сетевых интерфейсов, 1/0 (вкл/выкл);
disk_reads — количество считываний с каждого диска , io/s (операций в секунду);
disk_writes — количество записей на каждый диск, io/s (операций в секунду);
network_packets_received — количество пакетов, полученных каждым сетевым интерфейсом, p/s (пакетов в секунду);
network_packets_transmitted — количество пакетов, отправленных каждым сетевым интерфейсом, p/s (пакетов в секунду);
power_supply_state — состояние блока(-ов) питания, 1/0 (вкл/выкл);
power_supply_count — количество блоков питания по типам в единицах;
temperature — температура по датчикам в градусах Цельсия.

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

CPU Pinning

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

Его настройка включает несколько шагов: настройку гипервизора, настройку сервиса nova-compute, настройку host aggregate и флейвора.

Настройка гипервизора.

Настройка предполагает добавление опций в загрузку ядра — isolcpus=2,3,4,5,6,7… - перечислите все ядра, которые нужно изолировать — добавление данной настройки предполагает перезагрузку сервера.
Настройка сервиса nova-compute.

Далее необходимо доработать конфигурацию сервиса nova-compute — добавьте в nova.conf гипервизора, на котором выполнена настройка isolcpus.

[compute]
cpu_dedicated_set=2-10 #указать желаемый набор ядер, который коррелирует с isolcpus

Настройка host aggregate и flavor.

Создайте агрегат, в который нужно добавить гипервизоры, где будет использоваться механизим CPU pinning. В метаданные агрегата добавьте параметр: pinned = true
Создайте флейвор нужного размера и добавьте в него метаданные:

aggregate_instance_extra_specs:pinned = true
hw:cpu_policy = dedicated

Использование механизма Memory ballooning

Memory ballooning — это технология управления оперативной памятью в виртуализированных средах, включая OpenStack. Она позволяет гипервизору динамически изменять объем оперативной памяти, доступной виртуальной машине, в зависимости от текущих потребностей.

Как работает memory ballooning:

В каждой ВМ устанавливается специальный драйвер (balloon driver), который взаимодействует с гипервизором. Гипервизор использует этот драйвер, чтобы запрашивать у ВМ “освободить” или “предоставить” память.
Когда гипервизору требуется освободить память, он посылает запрос balloon-драйверу в ВМ. Balloon-драйвер “заполняет” память ВМ с помощью выделения фиктивных блоков памяти, которые более не используются ВМ. Эти блоки памяти возвращаются гипервизору и могут быть перераспределены другим ВМ.
Когда ВМ требуется больше памяти, гипервизор может “сдуть” balloon, освобождая память, ранее выделенную другим ВМ.

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

Требование к образам Windows:

наличие Balloon драйвера, включен в VirtIO Windows Driver Pack,
установленая служба BalloonService (тип запуска службы - Auto).

Требования к образам Linux:

наличие VirtIO драйверов. Модуль virtio_balloon обычно включён в большинство современных дистрибутивов.

Изменение ресурсов ВМ

Изменение ресурсов виртуальной машины используется для увеличения или уменьшения количества виртуальных CPU или RAM виртуальной машины. Изменение ресурсов ВМ осуществляется в интерфейсе Портала администратора, Horizon или в OpenStack CLI.

Для изменения ресурсов ВМ в Horizon необходимо выбрать Вычислительные ресурсы → Инстансы в левом меню, далее найти ВМ, ресурсы которой необходимо изменить, и выбрать в контекстном меню “Изменить размер инстанса” (см. рисунок ниже).

Рисунок 15 — Меню изменения размера ВМ

В окне изменения размера нужно указать новый шаблон ВМ.

Изменение размера ВМ реализуется путем создания новой ВМ и копирования исходного диска ВМ в новый. Это двухэтапный процесс: первый шаг — изменение размера, второй шаг — либо подтверждение и успеха операции и освобождение старой ВМ, либо объявление возврата операции (освобождение новой ВМ и запуск старой ВМ).

В OpenStack CLI изменение размера ВМ выполняется командой server resize:

openstack server resize
    [--flavor <flavor> | --confirm | --revert]
    [--wait]
    <server>

где:

–flavor <flavor> — новый шаблон ВМ;

–confirm — подтверждение завершения операции изменения размера ВМ;

–revert — восстановление состояния ВМ до изменения;

–wait — дождаться окончания операции;

<server> — изменяемая ВМ (имя или ID).

Работа с зонами доступности ВМ

В KeyStack зоны доступности (Availability Zone, AZ) применяются для физической изоляции гипервизоров и обеспечения отказоустойчивости.

В результате ручной миграции зона доступности виртуальной машины может отличаться от зоны доступности гипервизора, где она находится. Подобные ВМ отмечаются лейблом “wrong AZ” в таблице ВМ на вкладке Ресурсы → ВМ.

Чтобы сменить зону доступности ВМ:

На вкладке Ресурсы → ВМ выберите любую из виртуальных машин, расположенных не в своей зоне доступности.
Нажмите выпадающий список в столбце “Actions” и выберите “Placement management”, а затем “Change AZ”.

Рисунок 16 – Смена зоны доступности ВМ

В открывшемся окне выберите зону доступности в выпадающем списке и нажмите “Применить”.

Рисунок 17 — Выбор зоны доступности ВМ

Работа с группами серверов ВМ

В KeyStack группы серверов ВМ (сервер-группы, server groups) применяются для объединения виртуальных машин в группы, которым можно присвоить определенные свойства. Группы серверов привязаны к конкретному проекту.

Для создания группы серверов ВМ в Портале администратора выполните следующие действия:

В левом меню Портала перейдите в раздел Ресурсы → Server Groups.
Нажмите кнопку “Создать Server Group”.
Заполните поля. Обязательно нужно указать имя группы и политику расположения. При выборе anti-affinity policy необходимо также указать максимально возможное количество ВМ на хост. Когда все поля будут заполнены, нажмите кнопку “Создать”.

Рисунок 18 — Группы серверов ВМ

Для просмотра всех данных о группе серверов нажмите ID группы на странице списка всех групп.

Для удаления группы серверов ВМ найдите в списке нужную группу, нажмите выпадающий список в столбце “Actions” и выберите пункт “Удалить”.

Для добавления ВМ в группу серверов или удаления из нее выполните следующие действия:

На вкладке Ресурсы → ВМ выберите виртуальную машину, которую нужно добавить в группу серверов или удалить из нее. Нажмите “Change Server Group” в столбце “Actions” для этой ВМ.
В открывшемся окне заполните поле “New server group”. Чтобы добавить ВМ в группу, выберите эту группу из выпадающего списка. Чтобы удалить ВМ из группы, нажмите значок X и оставьте поле пустым. Текущая группа ВМ отображается в поле “Current Server Group”.
Нажмите кнопку “Применить”.

Рисунок 19 — Изменение группы серверов для ВМ

Удаление ВМ

Удаление ВМ осуществляется в интерфейсе Портала администратора, Horizon или в OpenStack CLI.

Для удаления ВМ в Horizon необходимо выбрать Вычислительные ресурсы → Инстансы в левом меню, далее найти ВМ, которую необходимо удалить, и выбрать в контекстном меню пункт “Удалить инстанс” (см. рисунок ниже).

Рисунок 20 — Удаление ВМ

Если необходимо удалить несколько виртуальных машин, то нужно выбрать их в списке и выбрать в контекстном меню пункт “Удалить” (см. рисунок ниже).

Рисунок 21 — Удаление группы ВМ

Удаление ВМ в CLI выполняется командой server delete. Синтаксис команды: openstack server delete [--wait] <server> [<server> ...]

где:

–wait — дождаться завершения удаления;

<server> [<server> …] — ВМ (список ВМ) для удаления (имя ВМ или ID).

Миграция ВМ

Миграция ВМ в CLI выполняется командой server migrate. Синтаксис команды:

openstack server migrate --os-compute-api-version 2.87
      [--live-migration]
      [--host <hostname>]
      [--shared-migration | --block-migration]
      [--disk-overcommit | --no-disk-overcommit]
      [--wait]
      <server>

где:

–live-migration — выполнить live-миграцию ВМ. Нужно использовать опцию –host для указания целевого вычислительного узла;

–host <hostname> — выполнить миграцию на вычислительный узел <hostname>;

–shared-migration — выполнить общую live-миграцию (миграция по умолчанию);

–block-migration — выполнить блочную live-миграцию;

–disk-overcommit — разрешить избыточную фиксацию диска на целевом управляющем узле;

–no-disk-overcommit — не выполнять избыточную фиксацию диска на целевом управляющем узле;

–wait — дождаться завершения миграции;

<server> — мигрируемая ВМ (имя или ID).

Миграция ВМ с перегрузкой по памяти

При работе с ВМ с перегруженной памятью компонент Nova по умолчанию использует следующую формулу: Тайм-аут = базовый_тайм-аут (800 сек) * объем оперативной памяти (ГБ). Таким образом, live-миграция нагруженных ВМ с большим объемом ОЗУ может занимать много времени.

Существует механизм принудительного завершения миграции по истечении тайм-аута, который может использовать два сценария реализации:

Посткопирование (post-copy) — производится перенос ВМ на целевой вычислительный узел и постепенное донесение содержимого оперативной памяти. Работа ВМ до полного переноса памяти проходит в режиме пониженной производительности.
Автоматическая сходимость (auto converge) — если миграция не может завершиться, то компонент начинает замедлять работу процессора ВМ до тех пор, пока процесс копирования памяти не станет быстрее, чем изменение памяти ВМ.

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

Note

Сценарий механизма администратор может выбрать при инсталляции на свое усмотрение. Для этого в репозитории региона необходимо создать файл config/nova/nova-compute.conf с содержимым:

[libvirt]
live_migration_completion_timeout = 800
live_migration_permit_post_copy = False
live_migration_permit_auto_converge = False

Администратор задаёт таймаут в секундах в формате целого числа и устанавливает значение True для выбранного сценария.

Также существует возможность принудительной отмены миграции. Когда большая ВМ достаточно долго находится в статусе миграции при live-миграции, становится доступно новое действие — отмена миграции. Это действие можно выполнить с помощью кнопки “Stop migration” в интерфейсе ВМ.

Live-миграция ВМ

Если у ВМ выставлено свойство availability_zone, при live-миграции этой ВМ не предлагаются хосты (гипервизоры) из других зон доступности. Это можно изменить, выбрав опцию “Ignore AZ restriciton” в интерфейсе ВМ, после чего для миграции станут доступны все хосты, а live-миграция будет проводиться с ключом force.

Чтобы провести live-миграцию ВМ с Портала администратора:

В левом меню Портала перейдите в раздел Ресурсы → ВМ и выберите любую машину из таблицы ВМ.
Нажмите выпадающий список в столбце “Actions” и выберите “Placement management”, а затем “Live Migrate”.
В открывшемся окне поставьте флажок “Ignore AZ restriciton”, выберите нужный гипервизор и нажмите кнопку “Мигрировать”.

Рисунок 22 — Live-миграция ВМ

Миграция ВМ с дисками между регионами

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

Чтобы перенести ВМ с дисками в другой регион:

На вкладке Ресурсы → ВМ выберите виртуальную машину с дисками для переноса.
Нажмите выпадающий список в столбце “Actions” и выберите “Placement management”, а затем “Migrate to the region”.

Рисунок 23 – Перенос ВМ с дисками в другой регион

В открывшемся окне по очереди выберите регион, проект и сеть для переноса ВМ. Нажмите “Start migration”.

Рисунок 24 – Выбор параметров для переноса ВМ в другой регион

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

ВМ будет перенесена в другой регион и там запущена. После переноса ВМ будет сразу работать. Исходная ВМ не будет удалена.

Эвакуация ВМ с вычислительного узла

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

nova host-evacuate-live <хостнейм_удалаяемого_узла>

Аварийное восстановление ВМ (Nova rescue)

Вы можете проводить аварийное восстановление ВМ на Портале администратора. Такие ВМ будут загружены с указанного вами загрузочного образа (обычно с той же ОС, на которой ВМ работает), и к ней будут подключены все ее диски. Статус ВМ изменится на RESCUE.

На вкладке Ресурсы → ВМ выберите виртуальную машину, которую нужно перевести в статус RESCUE. Нажмите “Rescue VM” в столбце “Actions” для этой ВМ.
Заполните поля — пароль и образ. Выбранный образ должен иметь следующие свойства: ‘hw_rescue_device’: ‘disk’ и ‘hw_rescue_bus’: ‘scsi’.
Нажмите кнопку “Запустить”. ВМ перейдет в статус RESCUE, а инстанс будет перезагружен из выбранного образа.

Рисунок 25 — Аварийное восстановление ВМ

Чтобы перевести ВМ обратно в статус ACTIVE, выберите действие “Unrescue VM” в столбце “Actions” для этой ВМ.

Работа с моментальными снимками ВМ

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

Для создания моментального снимка ВМ:

На вкладке Ресурсы → ВМ выберите виртуальную машину.
Нажмите выпадающий список в столбце “Actions” и выберите “Volume management”, а затем “Create snapshot of boot volume”.
В открывшемся окне укажите имя и название снимка ВМ. Чтобы добавить дополнительные параметры, нажмите + для “Extra specs”. Нажмите “Создать”.

Рисунок 26 — Создание снимка ВМ

Чтобы откатить ВМ к моментальному снимку:

На вкладке Ресурсы → ВМ выберите виртуальную машину.
Нажмите выпадающий список в столбце “Actions” и выберите “Volume management”, а затем “Revert boot volume to latest snapshot”.
В открывшемся окне подтвердите действие. Нажмите “Откатить”.

Рисунок 27 — Восстановление ВМ из снимка

Клонирование существующих виртуальных машин с кастомизацией

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

Подключитесь к Порталу самообслуживания.
На странице Project → Volumes → Volumes выберите диск, у которого в колонке “Attached To” указана ВМ, которую нужно скопировать (см. рисунок ниже).
Нажмите выпадающий список в столбце “Actions” и выберите пункт “Create Snapshot”.

Рисунок 28 — Выбор диска

В открывшемся окне введите имя снимка в поле “Snapshot Name” и нажмите кнопку “Create Volume Snapshot (Force)” (см. рисунок ниже).

Рисунок 29 — Создание снимка

На странице Project → Volumes → Snapshots нажмите выпадающий список в столбце “Actions” в строке тестового снимка.
Выберите пункт “Launch as Instance” (см. рисунок ниже).

Рисунок 30 — Запуск клонированной ВМ

В открывшемся окне заполните следующее:

Вкладка Details: Instance name: VM_with_Customization
Вкладка Flavor: Allocated: m1.tiny
Вкладка Network: Allocated: private
Вкладка Configuration: Load Customization Script from a file: Загрузить конфигурационный скрипт в виде файла или Customization Script: Ввести конфигурационный скрипт в поле ввода текста

В качестве примера конфигурационного скрипта можно привести следующий скрипт:

#cloud-config
ssh_pwauth: yes
chpasswd:
  list: |
    ubuntu:123456
    root:1234567
  expire: False

Нажмите кнопку “Launch as Instance”.

Подключение к VM по SSH должно быть доступно для следующих username/password:

ubuntu/123456
root/1234567

Диски

Создание и управление дисками

Для просмотра списка дисков на Портале необходимо в левом меню перейти в раздел Ресурсы → Диски. Пример вида раздела представлен на рисунке ниже.

Рисунок 31 — Пример списка дисков

Создание диска

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

В левом меню Портала перейдите в раздел Ресурсы → Диски.
Нажмите кнопку “Создать диск”.
Укажите имя и размер диска. Проект для диска можно изменить в выпадающем списке “Проект” вверху. Пример заполнения см. на рисунке ниже. Чтобы создать диск из снимка, перейдите на вкладку From snapshot и выберите один из доступных снимков в поле Snapshot.
Нажмите кнопку “Создать”.

Рисунок 32 — Создание диска

Изменение параметров диска

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

В левом меню Портала перейдите в раздел Ресурсы → Диски.
Нажмите выпадающий список в столбце “Actions” и выберите нужный пункт в зависимости от цели:

Чтобы изменить размер диска, нажмите “Change size”. Новый размер должен быть больше текущего значения. В открывшемся окне укажите размер диска в ГБ и нажмите “Сохранить”.

Чтобы удалить диск, нажмите “Delete volume”. Чтобы удалить вместе с диском все снимки, выберите опцию “Remove any snapshots along with the volume”. Подтвердите действие, нажав “Удалить”.

Чтобы изменить тип томов, к которому принадлежит диск, нажмите типа “Change type”. В открывшемся окне выберите тип в поле “Type”. Если планируете миграцию диска, поменяйте значение с “Never” на “On demand” в “Migrate the volume when it is re-typed”. Нажмите “Применить”.

Если диск не прикреплен к ВМ, нажмите “Attach to server”. В открывшемся окне выберите ВМ в поле “Сервер”. Чтобы при удалении ВМ был удален и этот диск, выберите опцию “Delete on termination”. Нажмите “Прикрепить”.

Рисунок 33 — Изменение параметров диска

Установка параметров QoS для типов дисков

Для работы с QoS на Портале администратора необходимо перейти в раздел Ресурсы → Volume Types в левом меню.

Volume Types

Типы томов необходимы для логического объединения дисков, включенных в определенный том.

По умолчанию Платформа использует тип томов __DEFAULT__. Другие типы томов можно создавать на свое усмотрение. Прежде чем устанавливать параметры QoS, убедитесь, что созданы нужные типы томов. Для просмотра типов томов перейдите в раздел Ресурсы → Volume Types.

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

В левом меню Портала перейдите в раздел Ресурсы → Volume Types.
Нажмите кнопку “Создать volume type”, расположенную рядом с таблицей Volume Types.
Введите имя и описание типа томов. Чтобы создать приватный тип, доступный только администраторам, снимите флажок для опции “is public”. Эти параметры можно изменить позже для уже созданного типа. Для этого нажмите выпадающий список в столбце “Actions” и выберите “Edit”.
Нажмите кнопку “Создать”.

Рисунок 34 — Создание типа томов

Quality of Service

Quality of Service (QoS) для дисков и томов — это квоты на производительность. QoS регулируют параметры производительности оборудования.

Создавайте QoS, настраивайте их параметры и связывайте их с типами дисков в этом разделе. Таблица Volume Types выше отобразит QoS, связанные с типами томов, в столбце “associated qos”.

Для создания нового QoS выполните следующие действия:

В левом меню Портала перейдите в раздел Ресурсы → Volume Types.
Нажмите кнопку “Создать QoS”, расположенную рядом с таблицей Quality of Service.
Заполните все поля. Эти параметры можно изменить позже, нажав выпадающий список в столбце “Actions” и выбрав “Update”.
Нажмите кнопку “Создать”.

Рисунок 35 — QoS

Для изменения QoS выполните следующие действия:

В разделе Ресурсы → Volume Types перейдите к таблице Quality of Service.
Нажмите выпадающий список в столбце “Actions” и выберите нужный пункт в зависимости от цели:

Чтобы изменить значения параметров QoS, нажмите “Update”. В открывшемся окне укажите новые значения для существующих параметров и нажмите “Применить”.

Если какие-либо параметры QoS еще не указаны, добавьте их с помощью “Add specs”. В открывшемся окне заполните значения для новых параметров и нажмите “Применить”.

Чтобы удалить параметры у QoS, нажмите “Unset”. Выберите один из параметров в открывшемся окне и нажмите “Удалить”. Повторите для всех параметров, которые нужно удалить.

Чтобы удалить QoS, нажмите “Delete”. Подтвердите действие, нажав “Удалить”.

Чтобы привязать QoS к типу томов, выберите “Associate”. В открывшемся окне выберите тип и нажмите “Применить”. Повторите для всех типов, которые нужно привязать к QoS.

Чтобы отвязать QoS от типа томов, выберите “Disassociate”. В открывшемся окне выберите тип и нажмите “Применить”.

Чтобы отвязать QoS от всех типов томов, выберите “Disassociate all”. Подтвердите действие, нажав “Применить”.

Создание и управление снимками дисков

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

Для создания моментального снимка диска:

На вкладке Ресурсы → ВМ выберите виртуальную машину.
Нажмите выпадающий список в столбце “Actions” и выберите “Volume management”, а затем “Create snapshot of boot volume”.
В открывшемся окне укажите имя и название снимка ВМ. Чтобы добавить дополнительные параметры, нажмите + для “Extra specs”. Нажмите “Создать”.

Рисунок 36 — Создание снимка диска

Чтобы откатить ВМ к моментальному снимку:

На вкладке Ресурсы → ВМ выберите виртуальную машину.
Нажмите выпадающий список в столбце “Actions” и выберите “Volume management”, а затем “Revert boot volume to latest snapshot”.
В открывшемся окне подтвердите действие. Нажмите “Откатить”.

Рисунок 37 — Восстановление ВМ из снимка

Добавление новых вычислительных узлов

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

Для этого нужно добавить в Netbox (пароль можно посмотреть в Vault в разделе Accounts) https://netbox.<domain_name>/dcim/devices/ новое устройство (см. рисунок ниже).

Рисунок 38 — Добавление нового устройства в Netbox

Затем необходимо заполнить поля:
- Name — имя сервера;
- Device role — Server;
- Device type — выбрать соответствующий тип;
- Site — выбрать соответствующий сайт, например, ks-region1;
- Status — Active;
- Tenant — выбрать тенант;
- Role — выбрать роль в выпадающем списке (controller, compute или network);
- Status — Ready.
После того как устройство будет добавлено, зайдите в него и добавьте сетевые интерфейсы аналогично тому, как изображено на рисунке ниже.

Рисунок 39 — Добавление сетевых интерфейсов
Теперь можно устанавливать операционную систему. Для этого требуется запустить пайплайн https://<gitlab_url>/project_k/Deployments/baremetal/-/pipelines и поменять значения для следующих параметров:
- TARGET_ROLE — compute, controller или network;
- TARGET_CLOUD — ks-region1;
- IRONIC_IMAGE_URL — во всех сценариях, кроме TARGET_ROLE=network, оставить как есть, в противном случае — указать http://LCM_IP:8080/ubuntu-20.04-mellanox-keystack.qcow2.
Нужно добавить новый сервер в inventory соответствующего окружения в gitlab.domain_name в группу compute https://<gitlab_url>/project_k/deployments/stage1/-/blob/dev-stage1/inventory (пример для stage1).
Теперь можно запускать kolla-ansible bootstap:

https://<gitlab_url>/project_k/Deployments/<ENV>/-/pipelines

Пример для stage1:

https://<gitlab_url>/project_k/deployments/stage1/-/pipelines

Run pipeline → Run pipeline → bootstrap-servers.

Run pipeline → Run pipeline → deploy c указанием –limit на новый гипервизор.

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

Создайте виртуальную машину на требуемом гипервизоре через CLI:

openstack server create --image <image_id> --flavor <flavor_id> --availability-zone nova:<hypervisor_host_name> --nic net-id=<network_id> Test-VM
Проверьте, что она создалась и перешла в статус ACTIVE, через openstack server show <server_id>.
Добавьте к ней FIP и проверить SSH-доступ (должно быть соответствующее разрешающее правило).
Убедитесь, что виртуальную машину можно мигрировать (миграция ВМ возможна такая: Mirantis → Keystack или Keystack → Keystack). Сделать это можно через CLI:

openstack server migrate --os-compute-api-version 2.87 --live-migration <instance_id> --host <new_host_name>

Удаление вычислительного узла из кластера

Удалите описание сервера из Netbox: https://netbox.<domain_name>/dcim/devices/
Удалите сервер из inventory из группы [compute]: https://<gitlab_url>/project_k/deployments/stage1/-/blob/dev-stage1/inventory (пример для stage1).
Далее следует удалить связанные сущности в Openstack (предполагается, что виртуальных машин на сервере нет):

HOST_FOR_REMOVAL=<computeN>

openstack --os-compute-api-version 2.87 compute service list --host $HOST_FOR_REMOVAL --service nova-compute -f value -c ID | xargs openstack --os-compute-api-version 2.87 compute service delete

openstack network agent list --host $HOST_FOR_REMOVAL -f value -c ID | while read agent_id; do openstack network agent delete $agent_id; done

openstack resource provider list --name $HOST_FOR_REMOVAL -f value -c uuid | xargs openstack resource provider show --allocations -f json |jq .allocations | jq 'keys[]' | xargs -n1 openstack resource provider allocation delete

openstack resource provider list --name $HOST_FOR_REMOVAL -f value -c uuid | xargs openstack resource provider delete

Настройки региона

Файлы конфигурации (Конфиги)

NTP Config

На Портале администратора можно просматривать и менять некоторые настройки серверов NTP (Network Time Protocol).

Рисунок 40 — NTP Config

Для внесения изменений в файл конфигурации NTP нажмите кнопку “Edit”. Можно добавлять, изменять и удалять следующие настройки:

часовой пояс;
пулы;
серверы.

Флажок “Enabled” отображает статус файла конфигурации.

Рисунок 41 — Изменение настроек NTP Config

Изменения файла на Портале администратора передаются в GitLab и там сохраняются. Для того, чтобы применить настройки, их нужно запустить с помощью пайплайна, применив bootstrap-servers и host configs.

Пример:

https:///project_k/deployments/<REGION_NAME>/-/pipelines

Run pipeline → Run pipeline → bootstrap-servers → host configs.

Режим обслуживания вычислительных узлов (гипервизоров)

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

На Портале администратора можно отследить процесс перехода гипервизора в режим обслуживания (maintenance mode). Для этого нужно перейти в раздел Гипервизоры → Гипервизоры и посмотреть значение в столбце “admin_state”. При выборе действия “Enable maintenance mode” гипервизор переходит в режим обслуживания, а статус и значение “admin_state” меняется на EnteringMaintenanceMode.

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

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

На Портале администратора перейдите в раздел Гипервизоры → Гипервизоры.
В выпадающем списке “Actions” для этого узла выберите действие “Enable maintenance mode”. ВМ при таком состоянии продолжают работать на узле, а новые ВМ не могут быть запущены.

На рисунке ниже показан процесс перевода гипервизора в maintenance mode.

Рисунок 42 — Вычислительные узлы с возможностью отключения

Дождитесь, когда статус гипервизора сменится с EnteringMaintenanceMode на новый. Если по какой-то причине гипервизор не перешел в maintenance mode, это будет отображено в статусе так: disabled (Service was transitioned to Error.). В столбце “admin_state” будет описана причина — например, Error (Live migration of server N failed). В таком случае можно либо повторно попробовать перевести гипервизор в режим обслуживания, нажав “Enable maintenance mode” — либо вернуть его в статус “enabled”, выбрав “Enable Service”.

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

Если гипервизор переведен в режим обслуживания, эвакуация ВМ происходит параллельно. Примерно 3-5 машин могут быть эвакуированы за раз. При этом в качестве причины отключения узла (disable_reason) выставляется maintenance mode: disable_service_by_uuid(token, service_id, reason='maintenance mode', region=region).

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

Эвакуация агрегатов

Агрегат (host aggregate) — это группа вычислительных узлов, объединенных логически на основе таких характеристик, как аппаратные средства или показатели производительности. Один вычислительный узел можно назначить как одному, так и нескольким агрегатам.

На Портале администратора список агрегатов доступен в разделе Гипервизоры → Агрегаты. Вы можете переводить агрегаты в режим высокой доступности (high availability, или HA) и тем самым эвакуировать их. Если для агрегата не включен режим HA, возле его название есть лейбл no HA.

Для перевода агрегата в режим HA выполните следующие действия:

Перейдите в раздел Гипервизоры → Агрегаты.
Посмотрите, какие агрегаты отмечены лейблом no HA. Эти агрегаты вы сможете эвакуировать.
Переведите один или несколько агрегатов в режим HA:
- Чтобы эвакуировать конкретный агрегат, выберите “Enable evacuation” в выпадающем списке “Actions” для этого агрегата. На рисунке ниже приведен пример.
- Чтобы эвакуировать все агрегаты, нажмите кнопку “Enable Evacuation For All” вверху.
Рисунок 43 — Эвакуация агрегатов
Подтвердите действие, нажав “Включить” в открывшемся окне.

Для вывода агрегатов из режима HA повторите действия выше с тем отличием, что в выпадающем списке “Actions” нужно будет выбрать “Disable evacuation”, а при выборе всех агрегатов — нажать кнопку “Disable Evacuation For All”.

Фенсинг узлов (fencing)

Фенсинг узлов (гипервизоров) проводит HA. Фенсинг — механизм исключения неисправного узла из кластера, чтобы этот узел больше не работал с ВМ. После проведения фенсинга узлы могут оказаться в статусе “fenced”, что будет отражено на Портале администратора. Такие узлы опознаются по префиксу FENCED: `` в ``disabled_reason.

Чтобы вывести узлы из этого состояния, выполните следующие действия:

В левом меню Портала перейдите в раздел Гипервизоры → Гипервизоры.
Найдите в таблице узел, который выделен желтым цветом и обозначен лейблом “fenced”.
В выпадающем списке “Actions” для этого узла выберите действие “Disable Fence Mode”.

Рисунок 44 — Узел в статусе “fenced”

Подсистема передачи данных

В Платформе используется топология сети с плоскими VLAN, часть параметров GRE / VXLAN не поддерживается.

Просмотр сетей

Для просмотра виртуальных сетей с помощью клиента Openstack CLI нужно выполнить следующую команду:

openstack network list

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

openstack subnet pool list

Вы также можете просматривать сети и их подсети на Портале администратора. Для этого в левом меню Портала перейдите в раздел Ресурсы → Сети.

Просмотр настроек виртуальной сети

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

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

Перейдите в раздел Проект → Сети. Будет отображен список сетей, к которым имеет доступ данный проект.

Рисунок 45 — Список сетей проекта

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

Рисунок 46 — Отображение настроек виртуальной сети

Для просмотра виртуальной сети с помощью клиента Openstack CLI необходимо подключиться по протоколу SSHv2 к управляющему узлу control1 и выполнить следующую команду в контейнере kolla_toolbox:

openstack network show <имя_виртуальной_сети>

Для просмотра свойств подсетей (subnet) с помощью клиента Openstack CLI необходимо выполнить команду в контейнере kolla_toolbox:

openstack subnet show <имя_subnet>

Создание виртуальной сети и соответствующей ей подсети

Для создания сети используется команда openstack network create. Полный синтаксис команды:

openstack network create
    [--share | --no-share]
    [--enable | --disable]
    [--project <project>]
    [--description <description>]
    [--mtu <mtu>]
    [--project-domain <project-domain>]
    [--availability-zone-hint <availability-zone>]
    [--enable-port-security | --disable-port-security]
    [--external | --internal]
    [--default | --no-default]
    [--qos-policy <qos-policy>]
    [--transparent-vlan | --no-transparent-vlan]
    [--provider-network-type <provider-network-type>]
    [--provider-physical-network <provider-physical-network>]
    [--provider-segment <provider-segment>]
    [--dns-domain <dns-domain>]
    [--tag <tag> | --no-tag]
    --subnet <subnet>
    <name>

где:

–share — сеть доступна другим проектам;

–no-share — сеть недоступна другим проектам;

–enable — включить сеть;

–disable — отключить сеть;

–project — проект владельца сети (наименование или ID);

–description — описание сети;

–mtu — установить указанный MTU;

–project-domain <project-domain> — домен проекта (наименование или ID). Опция используется в случае конфликтов между названиями проектов;

–availability-zone-hint <availability-zone> — зона доступности, в которой необхоодимо создать сеть;

–enable-port-security — включить защиту порта по умолчанию для портов, созданных в этой сети (опция по умолчанию);

–disable-port-security — отключить защиту порта по умолчанию для портов, созданных в этой сети;

–external — признак внешней сети;

–internal — признак внутренней сети;

–default — признак использования сети в качестве внешней по умолчанию;

–no-default — не использовать сеть в качестве внешней по умолчанию;

–qos-policy <qos-policy> — политика QoS для подключения к этой сети (имя или идентификатор);

–transparent-vlan — сделать сеть VLAN прозрачной;

–no-transparent-vlan — не делать сеть VLAN прозрачной;

–provider-network-type <provider-network-type> — физический механизм реализации виртуальной сети. Например: flat, geneve, gre, local, vlan, vxlan;

–provider-physical-network <provider-physical-network> — имя физической сети, в которой реализована виртуальная сеть;

–provider-segment <provider-segment> — VLAN ID для сетей VLAN или Tunnel ID для сетей GENEVE / GRE / VXLAN;

–dns-domain <dns-domain> — установить DNS-домен для этой сети;

–tag <tag> — добавить тег к сети. Может использоваться несколько раз для указания нескольких тегов;

–no-tag — нет тегов, связанных с сетью;

–subnet <subnet> — подсеть IPv4 для фиксированных IP-адресов (в нотации CIDR);

<name> — наименование создаваемой сети.

Для создания сети на Портале администратора:

В левом меню Портала перейдите в раздел Ресурсы → Сети и нажмите кнопку “Создать сеть”.
В открывшемся окне заполните поля. Обязательно нужно указать имя сети, CIDR и внешний ID. Поддерживаются разные типы сетей: FLAT, VLAN, VXLAN и GRE.
Когда все поля будут заполнены, нажмите кнопку “Создать”.

Рисунок 47 — Создание сети на Портале администратора

Создание подсети

Для создания подсети используется команда openstack subnet crate. Полный синтаксис команды:

openstack subnet create
      [--project <project>]
      [--project-domain <project-domain>]
      [--subnet-pool <subnet-pool>]
      [--prefix-length <prefix-length>]
      [--subnet-range <subnet-range>]
      [--dhcp | --no-dhcp]
      [--dns-publish-fixed-ip | --no-dns-publish-fixed-ip]
      [--gateway <gateway>]
      [--ip-version {4,6}]
      [--network-segment <network-segment>]
      --network <network>
      [--description <description>]
      [--allocation-pool start=<ip-address>,end=<ip-address>]
      [--dns-nameserver <dns-nameserver>]
      [--host-route destination=<subnet>,gateway=<ip-address>]
      [--service-type <service-type>]
      [--tag <tag> | --no-tag]
      <name>

где:

–project <project> — проект владельца (наименование или ID);

–project-domain <project-domain> — домен проекта (наименование или ID). Опция используется в случае конфликтов между названиями проектов;

–subnet-pool <subnet-pool> — пул адресов, из которого эта подсеть получит CIDR (наименование или идентификатор);

–prefix-length <prefix-length> — длина префикса для выделения подсети из пула подсетей;

–subnet-range <subnet-range> — диапазон подсети в нотации CIDR (требуется, если –subnet-pool не указан, в противном случае — необязательный);

–dhcp — разрешить DHCP (по умолчанию);

–no-dhcp — запретить DHCP;

–dns-publish-fixed-ip — включить публикацию фиксированных IP-адресов в DNS;

–no-dns-publish-fixed-ip — отключить публикацию фиксированных IP-адресов в DNS;

–gateway <gateway> — шлюз подсети. Доступны три варианта:

<ip-address> — конкретный IP-адрес для использования в качестве шлюза — например, –gateway 192.168.9.1,;
‘auto’ — адрес шлюза должен автоматически выбираться из самой подсети — например, –gateway auto;
‘none’ — подсеть не использует шлюз — например, –gateway none.

–ip-version <IP_VERSION> — версия IP (значение по умолчанию — 4). Версия 6 не доступна в Платформе;

–network-segment <network-segment> — сегмент сети, который нужно связать с этой подсетью (наименование или ID);

–network <network> — сеть, к которой принадлежит эта подсеть (наименование или ID);

–description <description> — описание подсети;

–allocation-pool start=<ip-address>,end=<ip-address> — IP-адреса пула распределения для этой подсети — например, start = 192.168.199.2, end = 192.168.199.254. Можно использовать несколько раз для добавления нескольких пулов;

–dns-nameserver <dns-nameserver> — DNS-сервер для этой подсети. Можно использовать несколько раз для указания нескольких DNS;

–host-route destination=<subnet>,gateway=<ip-address> — дополнительный маршрут для этой подсети — например, destination=10.10.0.0/16,gateway=192.168.71.254. Можно использовать несколько раз для добавления нескольких маршрутов;

–service-type <service-type> — тип сервиса для подсети — например, network:floatingip_agent_gateway. Можно использовать несколько раз для указания нескольких типов сервиса;

–tag <tag> — теги подсети. Можно использовать несколько раз для добавления нескольких тегов;

–no-tag — не ассоциировать теги с этой подсетью;

<name> — наименование подсети.

Изменение параметров сети

Изменение параметров сети выполняется командой network set. Полный синтаксис команды:

openstack network set
      [--name <name>]
      [--enable | --disable]
      [--share | --no-share]
      [--description <description>]
      [--mtu <mtu>]
      [--enable-port-security | --disable-port-security]
      [--external | --internal]
      [--default | --no-default]
      [--qos-policy <qos-policy> | --no-qos-policy]
      [--tag <tag>]
      [--no-tag]
      [--provider-network-type <provider-network-type>]
      [--provider-physical-network <provider-physical-network>]
      [--provider-segment <provider-segment>]
      [--dns-domain <dns-domain>]
      <network>

где:

–name <name> — установить наименование сети;

–enable — включить сеть;

–disable — выключить сеть;

–share — сделать доступной для других проектов;

–no-share — сделать недоступной для других проектов;

–description <description> — описание сети;

–mtu <mtu> — установить MTU;

–enable-port-security — включить защиту порта в этой сети;

–disable-port-security — выключить защиту порта в этой сети;

–external — установить сеть как внешнюю;

–internal — установить сеть как внутреннюю;

–default — установить эту сеть как внешнюю по умолчанию;

–no-default — не использовать эту сеть как внешнюю по умолчанию;

–qos-policy <qos-policy> — политика QoS для подключения к этой сети (наименование политики или ID);

–no-qos-policy — удалить политику QoS для подключения к этой сети;

–tag <tag> — теги сети. Можно использовать несколько раз для добавления нескольких тегов;

–no-tag — очистить теги сети. Указывается как –tag, так и –no-tag, чтобы перезаписать текущие теги;

–provider-network-type <provider-network-type> — физический механизм реализации виртуальной сети. Например: flat, geneve, gre, local, vlan, vxlan;

–provider-physical-network — наименование физической сети, в которой реализована виртуальная сеть;

–provider-segment <provider-segment> — VLAN ID для сетей VLAN или Tunnel ID для сетей GENEVE / GRE / VXLAN;

–dns-domain <dns-domain> — установить DNS-домен для этой сети;

network — изменяемая сеть (имя или ID).

Изменение параметров подсети

Изменение параметров подсети выполняется командой subnet set. Полный синтаксис команды:

openstack subnet set
      [--name <name>]
      [--dhcp | --no-dhcp]
      [--dns-publish-fixed-ip | --no-dns-publish-fixed-ip]
      [--gateway <gateway>]
      [--network-segment <network-segment>]
      [--description <description>]
      [--tag <tag>]
      [--no-tag]
      [--allocation-pool start=<ip-address>,end=<ip-address>]
      [--no-allocation-pool]
      [--dns-nameserver <dns-nameserver>]
      [--no-dns-nameservers]
      [--host-route destination=<subnet>,gateway=<ip-address>]
      [--no-host-route]
      [--service-type <service-type>]
      <subnet>

где:

–name <name> — установить имя подсети;

–dhcp — включить DHCP;

–no-dhcp — выключить DHCP;

–dns-publish-fixed-ip — включить публикацию фиксированных IP-адресов в DNS;

–no-dns-publish-fixed-ip — отключить публикацию фиксированных IP-адресов в DNS;

–gateway <gateway> — шлюз подсети. Доступны три варианта:

<ip-address> — конкретный IP-адрес для использования в качестве шлюза — например, –gateway 192.168.9.1,;
‘auto’ — адрес шлюза должен автоматически выбираться из самой подсети — например, –gateway auto;
‘none’ — подсеть не использует шлюз — например, –gateway none.

–network-segment <network-segment> — сегмент сети, который нужно связать с этой подсетью (имя или ID). Разрешается устанавливать сегмент, если текущее значение — None. Сеть также должна иметь только один сегмент, и только одна подсеть может существовать в сети;

–description <description> — установить описание подсети;

–tag <tag> — теги подсети. Можно использовать несколько раз для добавления нескольких тегов;

–no-tag — очистить теги подсети. Указывается как –tag, так и –no-tag, чтобы перезаписать текущие теги;

–allocation-pool start=<ip-address>,end=<ip-address> — IP-адреса пула для этой подсети — например, start = 192.168.199.2, end = 192.168.199.254. Можно указывать несколько раз для добавления нескольких пулов адресов;

–no-allocation-pool — удалить пулы из этой подсети. Указывается как –allocation-pool, так и –no-allocation-pool, чтобы перезаписать информацию о текущем пуле;

–dns-nameserver <dns-nameserver> — DNS-сервер для этой подсети. Можно использовать несколько раз для указания нескольких DNS-серверов;

–no-dns-nameservers — удалить информацию о DNS-серверах в этой подсети. Необходимо использовать –no-dns-nameserver и –dns-nameserver, чтобы перезаписать информацию о DNS-серверах;

–host-route destination=<subnet>,gateway=<ip-address> — – дополнительный маршрут для этой подсети — например, destination=10.10.0.0/16,gateway=192.168.71.254. Можно использовать несколько раз для добавления нескольких маршрутов;

–no-host-route — очистить информацию о маршрутах для этой подсети. Необходимо использовать -no-host-route и –host-route, чтобы перезаписать информацию о маршрутах;

–service-type <service-type> — тип сервиса для подсети — например, network:floatingip_agent_gateway. Можно использовать несколько раз для указания нескольких типов сервиса;

subnet — изменяемая подсеть (имя или ID).

Создание балансировщика нагрузки

Балансировщики проекта отображаются при переходе в левом меню в раздел Сеть → Балансировщики нагрузки.

Рисунок 48 — Список балансировщиков проекта

Для запуска мастера создания балансировщика нажмите кнопку “Создать балансировщик нагрузки”.

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

Рисунок 49 — Создание балансировщика

Добавьте информацию о слушателе — заполните поля “Имя”, “Протокол” и “Порт” (см. рисунок ниже).

Рисунок 50 — Заполнение информации о слушателе

Далее необходимо заполнить информацию о пуле (см. рисунок ниже).

Рисунок 51 — Заполнение информации о пуле

В настоящий момент балансировщик поддерживает три основных алгоритма балансировки:

LEAST_CONNECTIONS. Учитывает количество подключений, поддерживаемых серверами в текущий момент времени. Каждый следующий запрос передается серверу с наименьшим количеством активных подключений.
ROUND_ROBIN. Представляет собой перебор по кругу: первый запрос передается первому серверу, затем следующий запрос передается второму — и так до достижения последнего сервера, а затем все начинается сначала.
SOURCE_IP. В этом методе сервер, обрабатывающий запрос, выбирается произвольным образом и закрепляется (на сессию, в cookies) за конкретным источником запроса.

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

Рисунок 52 — Добавление ВМ балансироки

Настройте параметры интервалов проверки доступности (см. рисунок ниже).

Рисунок 53 — Добавление правила. Параметры интервалов проверки доступности

После указания всех параметров балансировщика нажмите кнопку “Создать балансировщик нагрузки” и дождитесь завершения операции.

Подсистема хранения секретов Vault

Подсистема обычно является часть платформы, располагается на LCM-узле и находится по адресу https://netbox.<domain_name>.

Вся чувствительная информация должна храниться в этой системе.

Основной файл с секретами passwords_yml должен быть расположен в такой структуре: deployments/itkey/<prod\stage><region>/passwords_yml.

Структура может быть произвольной. Привязаться к существующей можно, изменив соответствующие CI/CD переменные в gitlab.domain_name для репозитория с файлами конфигурации, относящемуся к региону, например: https://<gitlab.domain_name>/project_k/deployments/stage1 → открыть → Settings → CI/CD → Variables:

vault_addr — адрес Vault (https://FQDN);

vault_engine — путь к хранилищу (secret store v2);

vault_method — jwt или password;

vault_password — заполните, если используется пароль для доступа к Vault;

vault_prefix — путь до passwords_yml региона (не включительно), например, deployments/itkey/prod/region1;

vault_role — itkey_deployments (не менять);

vault_username — укажите имя пользователя для доступа в Vault в случае использования парольной аутентификации;

В случае перезапуска контейнера Vault или перезапуска LCM сервера Vault необходимо разблокировать unseal-ключом, полученным при установке и сохраненном в надежном месте, сделать это можно так:

docker exec -it vault vault operator unseal

Система запросит ключ, который требуется ввести.

Как надежно хранить пароли

Хранение паролей сервисов в Vault

Castellan — это библиотека, предоставляющая собой общий интерфейс для хранения, генерации и извлечения секретов. Она используется большинством сервисов OpenStack для управления секретами. Как библиотека, Castellan сама по себе не предоставляет хранилище секретов. Вместо этого требуется развертывание реализации на стороне сервера. С помощью интеграции данной библиотеки в oslo.config и корректной настройки Vault можно хранить пароли сервисов OpenStack в Vault вместо текстовых файлов.

Поддерживаются следующие сервисы:

AdminUI
Cinder
DRS
Glance
Keystone
Neutron
Nova
Placement

Для настройки хранения паролей сервисов в Vault необходимо в globals.d/castellan.yml определить services_with_castellan — список сервисов, для которых необходимо включить хранение паролей в Vault.

services_with_castellan:
   - drs
   - cinder
   - glance
   - neutron
   - nova
   - nova_cell
   - keystone
   - adminui

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

При аутентификации через AppRole:

castellan_vault_approle_role_id: ""
castellan_vault_approle_secret_id: ""

При использовании Vault Enterprise и namespaces:

castellan_vault_namespace: ""

При аутентификации через токен:

castellan_vault_root_token_id: ""

Хранение паролей экспортеров prometheus в Vault

Для настройки хранения паролей экспортеров prometheus в Vault необходимо в globals.d/REGION.yml добавить строки:

prometheus_mysqld_exporter_use_vault: true
prometheus_rabbitmq_exporter_use_vault: true
prometheus_openstack_exporter_use_vault: true

Хеширование паролей сервисов

Пароли к некоторым сервисам можно хранить в хешированном виде.

Реализовано для HAProxy в части:

OpenSearch
Prometheus

Для настройки хеширования паролей сервисов необходимо в globals.d/REGION.yml определить services_with_hashed_password — список сервисов, для которых необходимо включить сокрытие паролей, например:

services_with_hashed_password:
   - opensearch
   - prometheus
   - rabbitmq
   - proxysql

Дальнейшие действия

Необходимо запустить пайплайн для развертывания нужных компонентов. При этом должна автоматически запуститься задача setup-castellan, которая предзаполнит значения паролей в Vault.

Механизм внешних плагинов

Пользовательские Ansible роли

Для добавления настраиваемых Ansible ролей перейдите в репозиторий региона и создайте директорию client_config со следующей структурой:

group_vars/              # Директория общих переменных для ролей
roles/                   # Директория для хранения ролей
   some-role/            # Директория соответствующая названию роли
      tasks/             # Директория файлов с задачами
         main.yml        # Основной файл задач роли
      handlers/          # Директория обработчиков событий, которые выполняются при вызове из задач через ``notify``
         main.yml        # Основной файл обработчиков
      templates/         # Директория jinja2-шаблонов, которые можно использовать для динамического создания конфигурационных файлов
         ntp.conf.j2     # Jinja2-шаблон
      files/             # Директория статических файлов роли, которые могут быть скопированы на целевые хосты без изменений
         bar.txt         # Статический файл
      vars/              # Директория переменных роли с высоким приоритетом. Используются для ключевых параметров, которые редко изменяются
         main.yml        # Файл с переменными
      defaults/          # Директория переменных по умолчанию, которые могут быть переопределены. Имеют самый низкий приоритет
         main.yml        # Файл с переменными
      meta/              # Директория с метаданными роли, такие как зависимости и информация о поддержке
         main.yml        # Файл зависимостей
      library/           # Директория для хранения пользовательских модулей Ansible
      module_utils/      # Директория для хранения вспомогательных утилит и библиотек, которые могут использоваться в пользовательских модулях
      lookup_plugins/    # Директория для хранения пользовательских плагинов для функций lookup, которые используются для получения данных из внешних источников
client-config.yml        # Конфигурационный файл для использования ролей (ansible плейбук)

Note

Более детальную информацию о подготовке пользовательских Ansible ролей можно прочесть в официальной документации Ansible.

В созданной директории создайте Ansible плейбук client-config.yml. Вариант содержимого client-config.yml:

---
- hosts: all
  roles:
    - some_role

Для применения создайте новый пайплайн: Build → Pipelines → Run Pipeline, затем запустите его. После завершения шага setup запустите задачу client-config.

Important

Перед запуском задачи client-config необходимо убедиться, что в директории <regionname>/client_config/roles присутствует директория some_role.

Мониторинг

Подсистема мониторинга предназначена для решения задач мониторинга Платформы и ее сервисов.

За мониторинг Платформы отвечают компоненты, построенные на базе решений Opensearch, Prometheus и Grafana.

Описание работы с OpenSearch, панели (OpenSearch Dashboards) и запросы

OpenSearch — инструмент для поиска и анализа данных в документах с открытым исходным кодом. Разработанный на основе Elasticsearch, OpenSearch предоставляет эффективное хранилище и обработку данных, а также масштабируемую архитектуру.

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

В составе настоящего релиза OpenSearch поставляется без преднастроенных панелей.

Предполагается, что администраторы кастомизируют панели под бизнес-задачи.

Создание пользовательских панелей с использованием различных виджетов и визуализаций

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

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

../_images/opensearch_new_dashboard_ui.png

Рисунок 54 — Создание пользовательской панели. Выбор визуализации

../_images/opensearch_new_dashboard_ui_2.png

Рисунок 55 — Создание пользовательской панели. Применение фильтров

../_images/opensearch_new_dashboard_ui_3.png

Рисунок 56 — Создание пользовательской панеи. Размещение визуализации

Подробнее о работе с OpenSearch Dashboards см. в документации OpenSearch Dashboards.

Добавление нового output для сборщика логов

Если требуется сбор логов в дополнительный output, необходимо выполнить следующие действия:

В репозитории региона в директории config/fluentd/output (создать при отсутствии) создайте (или отредактируйте при наличии) файл 03-opensearch.conf.

Содержание 03-opensearch.conf:

<match **>
@type copy
<store>
       @type opensearch
       hosts http://{{ opensearch_address }}:{{ opensearch_port }},https://адрес_нового_сборщика:порт_нового_сборщика
{% if fluentd_opensearch_path != '' %}
       path {{ fluentd_opensearch_path }}
{% endif %}
{% if fluentd_opensearch_scheme == 'https' %}
       ssl_version {{ fluentd_opensearch_ssl_version }}
       ssl_verify {{ fluentd_opensearch_ssl_verify }}
{% if fluentd_opensearch_cacert | length > 0 %}
       ca_file {{ fluentd_opensearch_cacert }}
{% endif %}
{% endif %}
{% if fluentd_opensearch_user != '' and fluentd_opensearch_password != ''%}
       user {{ fluentd_opensearch_user }}
       password {{ fluentd_opensearch_password }}
{% endif %}
       logstash_format true
       logstash_prefix {{ opensearch_log_index_prefix }}
       reconnect_on_error true
       reload_connections false
       reload_on_failure true
       request_timeout {{ fluentd_opensearch_request_timeout }}
       suppress_type_name true
       ssl_verify false
       <buffer>
       @type file
       path /var/lib/fluentd/data/opensearch.buffer/openstack.*
       flush_interval 15s
       chunk_limit_size 10M
       </buffer>
</store>
</match>

Далее в интерфейсе Gitlab в репозитории региона запустите выполнение пайплайна с тегом common и лимитом на мастер-узлы:
```
`-t common --limit control`
```

../_images/gitlab-run-pipeline-with-arg.png

Рисунок 57 — Запуск пайплайна с нужным тегом

Нажмите “Run Pipeline”.

Создание шаблона индексов в OpenSearch

Для этого нужно перейти на страницу https://opensearch.<domain_name>.
Данная страница при первом входе сразу направит нас на страницу создания шаблонов.
Далее необходимо выполнить следующие действия:

Нажмите кнопку “Create index patern”.
В появившемся окне в поле “index patern name” укажите flog* и нажмите “Next Step”.
Далее в поле “Time field” выберите из выпадающего списка @timestamp и нажмите “Create index pattern”.

Настройка глубины хранения индексов в OpenSearch

Данная настройка выполняется в самом OpenSearch. Для этого нужно перейти на сайт https://opensearch.<domain_name> → Index Management → Index Policies и добавить или изменить политику:

{
      "policy": {
          "policy_id": "Retention",
          "description": "hot warm delete workflow",
          "schema_version": 16,
          "default_state": "hot",
          "states": [
              {
                  "name": "hot",
                  "actions": [
                      {
                          "retry": {
                              "count": 3,
                              "backoff": "exponential",
                              "delay": "1m"
                          },
                          "replica_count": {
                              "number_of_replicas": 1
                          }
                      }
                  ],
                  "transitions": [
                      {
                          "state_name": "warm",
                          "conditions": {
                              "min_index_age": "30d"
                          }
                      }
                  ]
              },
              {
                  "name": "warm",
                  "actions": [
                      {
                          "retry": {
                              "count": 3,
                              "backoff": "exponential",
                              "delay": "1m"
                          },
                          "replica_count": {
                              "number_of_replicas": 0
                          }
                      }
                  ],
                  "transitions": [
                      {
                          "state_name": "delete",
                          "conditions": {
                              "min_index_age": "60d"
                          }
                      }
                  ]
              },
              {
                  "name": "delete",
                  "actions": [
                     `{
                          "retry": {
                              "count": 3,
                              "backoff": "exponential",
                              "delay": "1m"
                          },
                          "delete": {}
                      }
                  ],
                  "transitions": []
              }
          ],
          "ism_template": [
              {
                  "index_patterns": [
                      "flog-*"
                  ],
                  "priority": 100,
              }
          ]
      }
}

В данной политике hot–индексы хранятся 30 дней с репликой 1 и переходят в warm.

warm–индексы хранятся 60 дней с репликой 0 и переходят в delete.

delete–индексы удаляются через 90 дней.

Просмотр состояния сервисов мониторинга Платформы

Просмотр состояния контейнеров OpenSearch (выполняется на управляющих узлах):

docker ps –f name=opensearch

Просмотр состояния контейнера Prometheus (выполняется на управляющих узлах):

docker ps –f name=prometheus

Просмотр состояния Kibana (выполняется на управляющих узлах):

docker ps –f name=kibana

Просмотр состояния fluentd (на любом сервере):

docker ps | grep fluentd

Настройка глубины хранения метрик в Prometheus

Это конфигурируемая опция. Чтобы изменить параметры глубины хранения, внесите изменения в globals.yml соответствующего региона в параметр prometheus_cmdline_extras, например:

prometheus_cmdline_extras: "--storage.tsdb.retention.time=60d --storage.tsdb.retention.size=500GB"

и запустите пайплайн в gitlab: https://<gitlab_url>/project_k/deployments/<REGION>/-/pipelines→ Run Pipeline с параметрами:

KOLLA_ANSIBLE_DEPLOY_ACTION – deploy
KOLLA_ARGS – -t prometheus

Файлы журналов компонентов Платформы

В таблице 1 представлен список служб подсистем и соответствующие им лог-файлы.

Таблица 1 — Cписок служб подсистем и соответствующие им лог-файлы

Служба	Расположение файла	Тип узла
Nova
nova-api	/var/log/kolla/nova/nova-api.log	Управляющий узел
nova-manage	/var/log/kolla/nova/nova-manage.log	Управляющий узел
placement	/var/log/kolla/nova/placement-api.log /var/log/kolla/nova/placement-api-access.log	Управляющий узел
nova-conductor	/var/log/kolla/nova/nova-conductor.log	Управляющий узел
nova-scheduler	/var/log/kolla/nova/nova-scheduler.log	Управляющий узел
nova-consoleauth	/var/log/kolla/nova/nova-consoleauth.log	Управляющий узел
nova-novncproxy	/var/log/kolla/nova/nova-novncproxy.log	Управляющий узел
nova-compute	/var/log/kolla/nova/nova-compute.log	Вычислительный узел
Libvirt	/var/log/kolla/libvirt/libvirtd.log	Вычислительный узел
Cinder
cinder-api	/var/log/kolla/cinder/cinder-api.log /var/log/kolla/cinder/cinder-api-access.log	Управляющий узел
cinder-manage	/var/log/kolla/cinder/cinder-manage.log	Управляющий узел
cinder-scheduler	/var/log/kolla/cinder/cinder-scheduler.log	Управляющий узел
cinder-volume	/var/log/kolla/cinder/cinder-volume.log	Управляющий узел
cinder-wsgi	/var/log/kolla/cinder/cinder-wsgi.log	Управляющий узел
Glance
glance-api	/var/log/kolla/glance/glance-api.log	Управляющий узел
Keystone
keystone	/var/log/kolla/keystone/*	Управляющий узел
Neutron
neutron-server	/var/log/kolla/neutron/neutron-server.log	Управляющий узел
neutron-openvswitch-agent	/var/log/kolla/neutron/neutron-openvswitch-agent.log	Сетевой узел
neutron-dhcp-agent	/var/log/kolla/neutron/neutron-dhcp-agent.log	Сетевой узел
neutron-l3-agent	/var/log/kolla/neutron/neutron-l3-agent.log	Сетевой узел
neutron-metadata-agent	/var/log/kolla/neutron/neutron-metadata-agent.log	Сетевой узел
neutron-metering-agent	/var/log/kolla/neutron/neutron-metering-agent.log	Сетевой узел
OpenvSwitch	Сетевой узел Вычислительный узел
Openvswitch DB	/var/log/kolla/openvswitch/ovsdb-server.log	Сетевой узел
neutron-openvswitch-agent	/var/log/kolla/neutron/neutron- openvswitch -agent.log	Сетевой узел Вычислительный узел
Horizon
horizon	/var/log/kolla/horizon/horizon.log /var/log/kolla/horizon/horizon-access.log	Управляющий узел
Heat
heat-api	/var/log/kolla/heat/heat-api.log /var/log/kolla/heat/heat-api-cfn.log heat-engine /var/log/kolla/heat/heat-engine.log	Управляющий узел
Rabbitmq
rabbitmq	/var/log/kolla/rabbitmq/*	Управляющий узел
Mariadb
mariadb	/var/log/kolla/mariadb/mariadb.log	Управляющий узел
Octavia
octavia-api	/var/log/kolla/octavia/octavia-api.log	Управляющий узел
octavia-housekeeping	/var/log/kolla/octavia/octavia-housekeeping.log	Управляющий узел
octavia-worker	/var/log/kolla/octavia/octavia-worker.log	Сетевой узел
octavia-health-manager	/var/log/kolla/octavia/octavia-health-manager.log	Сетевой узел
Opensearch
opensearch	/var/log/kolla/opensearch/kolla_logging.log	Управляющий узел
opensearch-dashoards	/var/log/kolla/opensearch/opensearch-dashboards.log	Управляющий узел

Логирование

Лог событий аудита

На Портале администратора можно отслеживать все события, которые произошли в системе OpenStack, на вкладке “Лог событий аудита”. Для этого нужно перейти в Логирование → CADF-события.

События можно фильтровать по различным параметрам, например, по типу (Event type), результату (Outcome) и др., а также комбинировать любые требуемые фильтры.

Рисунок 58 — Фильтры событий аудита

Настройка дополнительного приемника журналов KeyStack в формате syslog

Для вывода логов в удаленный сервис системного журнала (syslog) используется fluent-plugin-remote_syslog — плагин Fluentd.

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

В репозитории региона https://<gitlab_url>/project_k/deployments/<region_name>/config создать файл fluentd/output/fluent-plugin-remote_syslog.conf.
Файл будет иметь следующее содержание (при этом нужно заменить значения на свои):

<match **>
  @type remote_syslog
  host <remote_syslog_IP_address>
  port 514
  protocol tcp
</match>

Где (заменить значения на свои):
- match ** — регулярное выражение соответствия “всем” логам;
- host <remote_syslog_IP_address> — ip-адрес (fqdn) сервиса syslog;
- port 514 — порт прослушивания сервиса syslog;
- protocol tcp — протокол передачи данных.

После развертывания kolla-ansible конфигурационный файл (td-agent.conf) контейнера fluentd будет содержать следующие данные:

# Outputs
# Included from conf/output/00-local.conf.j2:

# Included from /etc/kolla/config/fluentd/output/fluent-plugin-remote_syslog.conf:
<match **>
  @type remote_syslog
  host 10.120.120.125
  port 514
  protocol tcp
</match>

Пример возможной конфигурации плагина fluent-plugin-remote_syslog с секциями

<match foo.bar>
  @type remote_syslog
  host example.com
  port 514
  severity debug
  program fluentd
  hostname ${tag[1]}

  <buffer tag>
  </buffer>

  <format>
    @type single_value
    message_key message
  </format>
</match>

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

name	type	placeholder support	description
hostname	string	support	departure of log
host	string	support	syslog target host
port	integer (default: `514`)		syslog target port
host_with_port	string	support	parameter for : style
facility	string (default: `"user"`)	support	syslog facility
severity	string (default: `"notice"`)	support	syslog severity
program	string (default: `"fluentd"`)	support	syslog program name
protocol	enum (udp, tcp) (default: `udp`)		transfer protocol
tls	bool (default: false)		use TLS (tcp only)
ca_file	string		ca_file path (tls mode only)
verify_mode	integer		SSL verification mode (tls mode only)
packet_size	integer (default: `1024`)		size limitation for syslog packet
timeout	integer		TCP transfer timeout. if value is 0, wait forever
timeout_exception	bool (default: `false`)		if value is true, raise exception by transfer timeout
keep_alive	bool (default: `false`)		use TCP keep alive
keep_alive_idle	integer		set TCP keep alive idle time
keep_alive_cnt	integer		set TCP keep alive probe count
keep_alive_intvl	integer		set TCP keep alive probe interval

Конфигурационные параметры для секции buffer

name	default
flush_mode	interval
flush_interval	5
flush_thread_interval	0.5
flush_thread_burst_interval	0.5

Конфигурационные параметры для секции format

name	default
@type	ltsv

License

See LICENSE for details.

Подсистема хранения кода и запуска пайплайнов (Gitlab)

Структура репозиториев в gitlab.domain_name `https://<gitlab_url>`

Все репозитории хранятся в группе project_k.

Kolla ansible — репозиторий, в котором хранятся плэйбуки и роли ansible от текущего релиза. Носит информативный характер и в жизненном цикле участия не принимают.

Kolla — репозиторий с исходным кодом для сборки образов docker для компонентов Openstack. Носит информативный характер и в жизненном цикле участия не принимает.

Keystack — репозиторий, который содержит базовые файлы конфигурации со значениями параметров для сервисов, рекомендуемыми вендором.

Dib — репозиторий для сборки образов операционных систем.

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

Deployments — группа, которая содержит набор репозиториев для создания и управления регионами/инсталляциями Openstack, а также общие репозитории для всех площадок — baremetal, bifrost и backup.

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

Bifrost — репозиторий, который содержит код для запуска контейнера bifrost, используемого логикой baremetal.

Деплой компонентов

Для запуска деплоя какого-либо компонента запустите пайплайн из репозитория соответствующего окружения и укажите тег нужного компонента и лимит при необходимости.

Открыть страницу https://gitlab.domain_name/project_k/deployments/<REGION>/-/pipelines → Run Pipeline.

KOLLA_ANSIBLE_DEPLOY_ACTION — выберите “deploy”.

KOLLA_ARGS — укажите тег компонента, который собираемся деплоить. Например, для Cinder укажите -t cinder, а для ограничения набора серверов для обновления — --limit <server/role name>.

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

Деплой компонентов opensearch/drs/adminui/prometheus/grafana/ha

Для деплоя данных сервисов нужно убедиться в наличии соответствующих переменных в REGION.yml соответствующего региона https://gitlab.domain_name/project_k/deployments/<REGION>/globals.d/REGION.yml.

Если все эти переменные существуют и имеют значение “yes”, то они будут установлены при деплое региона.

enable_grafana: "yes"
enable_prometheus: "yes"
enable_prometheus_alertmanager: "yes"
enable_drs: "yes"
enable_adminui: "yes"
enable_consul: "yes"
enable_opensearch: "no"

Если какие-то переменные отсутствовали, или же у них было выставлено значение “no”, то их можно установить отдельно.

Для этого добавьте переменную со значением “yes”, если переменной не было, либо выставите это значение, если было “no” — например, enable_opensearch: “yes”.

Далее откройте страницу https://gitlab.domain_name/project_k/deployments/<REGION>/-/pipelines → Run Pipeline.

KOLLA_ANSIBLE_DEPLOY_ACTION — выберите “deploy”.

KOLLA_ARGS — укажите тег компонента, который нужно деплоить. Для OpenSearch нужно указать -t opensearch.

Деплой компонентов, связанных с NEUTRON

Neutron — сетевая служба, бесконтрольный деплой которой приведет к нарушению сетевой доступности облака, поэтому выкатка этого компонента выполняется с предварительной подготовкой и нюансами.

Деплой тега neutron на сервера с ролью control — обязательно указывать лимит на 1 узел, затем после выполнения пайплайна можно указать лимит на оставшиеся 2 узла и запустить пайплайн.

Деплой тега neutron на сервера с ролью network:

Получите список L3-агентов и их идентификаторы:

openstack network agent list --agent-type l3

Выключите L3-агент на том узле, на который планируется внести изменения:

openstack network agent set --disable <l3_agent_uuid>

Подождите 5 минут.
Запустите пайлайн с тегом neutron и лимитом на тот сервер, на котором выключен L3-агент:

Рисунок 60 — Параметры запуска пайплайна

openstack network agent set --enable <l3_agent_uuid>

Подождите 30 минут, отслеживая сообщения в логах /var/log/kolla/neutron/neutron-l3-agent.log (в логах дождаться окончания синков на сотни секунд).
Повторите итерацию для каждого L3-агента (для каждого узла с ролью network).

Двухфакторная аутентификация(2FA)

В KeyStack в качестве второго фактора используется пара сертификат/ключ для защиты аккаунта. На первом этапе аутентификации пользователь указывает свой сертификат и ключ, на втором — имя пользователя и пароль от своей учетной записи.

Включение двухфакторной аутентификации (2FA)

Добавьте параметры в globals и файлы конфигурации региона:

kolla_enable_mtls_external: yes

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

Отключение двухфакторной аутентификации (2FA)

Измените параметры в globals и файлы конфигурации региона:

kolla_enable_mtls_external: no

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

Сертификат клиента для использования c 2FA

Клиентский сертификат должен содержать следущий атрибуты: 1. Клиентский сертификат подписан центром сертификации, выпускающим сертификаты для региона Keystack. 2. Заданы назначения сертификата (OID):

Проверка подлинности сервера (1.3.6.1.5.5.7.3.1)
Проверка подлинности клиента (1.3.6.1.5.5.7.3.2)

Задан Subject, совпадающий с основным доменом региона Keystack.

Использование OpenStack CLI c 2FA

openstack --os-cacert CA_CERT --os-cert CLIENT_CERT --os-key CLIENT_KEY <commands>

–os-cacert CA_CERT — рутовый сертификат или цепочка
–os-cert CLIENT_CERT — сертификат клиент
–os-key CLIENT_KEY — ключ к сертификату клиента

Использование Horizon и Adminui c 2FA

Сохраните созданный сертификат, ключ и рутовый сертификат в операционную систему Linux и выполните команду:

openssl pkcs12 -export -in CLIENT_CERT -inkey CLIENT_KEY -certfile CA_CERT -out client01.p12 -passout pass:password

2. Импортируйте получившийся сертификат в формате p12 в используемый браузер. Пример для Chrome: <Настройки - Конфиденциальность и безопасность - Безопасность - Настроить сертификаты - Сертификаты - Личные>. 3. Перейдите по адресу Horizon или AdminUI и выберите сертификат для авторизации в всплывающем окне. 4. Используйте данные от своего аккаунта (имя пользователя и пароль) для авторизации в Horizon или AdminUI.

Интеграция OpenStack с LDAP

Настройка данной интеграции состоит из нескольких частей:

Создайте домен. Для этого при помощи OpenStack CLI выполните команду создания домена:

openstack domain create ldap, где ldap — это имя добавляемого домена (оно должно быть указано также в globals и участвовать в имени файла конфигурации для Keystone).
Добавьте параметры в globals и файлы конфигурации:

globals.yml соответствующего региона (в интерфейсе Horizon в выпадающем списке домены будут отображаться в той последовательности, в которой были указаны. В данном случае первым будет default, затем — ldap):

keystone_ldap_url: "ldaps://LDAP_SERVER_NAME:LDAP_PORT"​
horizon_keystone_multidomain: "True"
horizon_keystone_domain_choices:
  Default: default
  Ldap: ldap

keystone.ldap.conf соответствующего региона https://<gtilab_url>/project_k/deployments/<regionname>/config/keystone/domains/keystone.ldap.conf (значения параметров, начинающихся с YOUR, нужно заполнить своими данными):

[identity]
driver = ldap

[ldap]
group_allow_create = False
group_allow_delete = False
group_allow_update = False
group_desc_attribute = description
group_id_attribute = cn
group_member_attribute = member
group_name_attribute = cn
group_objectclass = group
group_filter = "YOUR FILTER"
password = "{{ ldap_password }}"
query_scope = sub
suffix = "YOUR_DN_SUFFIX"
user_tree_dn = "YOUR_DN_TREE"
url = "{{ keystone_ldap_url }}"
user = YOUR_SERVICE_USER_DN
user_filter = "YOUR FILTER"
user_allow_create = False
user_allow_delete = False
user_allow_update = False
user_enabled_attribute = userAccountControl
user_enabled_default = 512
user_enabled_mask = 2
user_id_attribute = cn
user_mail_attribute = mail
user_name_attribute = sAMAccountName
user_objectclass = person
user_pass_attribute = userPassword
group_tree_dn = "YOUR_GROUP_TREE_DN"
page_size = 0​

При интеграции по ldaps протоколу, добавьте цепочку из рутовых и промежуточных сертификатов в файл certificates/ca/ca-bundle.crt
Поместить пароль пользователя YOUR_SERVICE_USER_DN в Vault в файл паролей региона deployments/<regionname>/passwords_yml в поле ldap_password.
Выполните деплой тегов keystone и horizon. Подробнее о запуске деплоя см. в разделе Деплой компонентов.
Проверьте, что видно пользователей и группы LDAP в Keystack в Openstack CLI:

# openstack user list --domain ldap
+------------------------------------------------------------------+----------------+
| ID                                                               | Name           |
+------------------------------------------------------------------+----------------+
| f82090b43940df5f7b8e77fb5e4ddaf04e60cecebc5e94dd63a5e0f53f219fe5 | user1          |
+------------------------------------------------------------------+----------------+

# openstack group list --domain ldap
+------------------------------------------------------------------+--------+
| ID                                                               | Name   |
+------------------------------------------------------------------+--------+
| ec6d01371e3160ab417c404fa07828a2e4c2d2e3147b762f9cf6f3555a601280 | group1 |
+------------------------------------------------------------------+--------+

Создайте проект в Openstack CLI или с помощью интерфейса Horizon:

openstack project create demo --domain ldap

Добавьте пользователей или группы в проект demo и дайте им права в них в Openstack CLI:

openstack role add --project demo --user user1 --user-domain ldap member
openstack role add --project demo --group group1 --user-domain ldap member

Интеграция Grafana с LDAP

Настройка данной интеграции состоит из нескольких частей:

При интеграции по протоколу LDAPs добавьте цепочку из рутовых и промежуточных сертификатов в файл certificates/ca/ca-bundle.crt.
Поместите пароль пользователя YOUR_SERVICE_USER_DN в Vault в файл паролей региона deployments/<regionname>/passwords_yml в поле “ldap_password”.
Создайте файл grafana.yml в папке globals.d региона (значения параметров, начинающихся с YOUR, нужно заполнить своими данными):

grafana_security_ldap_enabled: "yes"
grafana_security_ldap_host: "LDAP_SERVER_NAME"
grafana_security_ldap_port: "LDAP_PORT"
grafana_security_ldap_use_ssl: "true"
grafana_security_ldap_start_tls: "false"
grafana_security_ldap_ssl_skip_verify: "false"
grafana_security_ldap_bind_dn: "YOUR_SERVICE_USER_DN"
grafana_security_ldap_bind_password: "{{ ldap_password }}"
grafana_security_ldap_search_filter: "YOUR FILTER"
grafana_security_ldap_search_base_dns: "YOUR_DN_TREE"

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

Интеграция OpenSearch с LDAP

Настройка данной интеграции состоит из нескольких частей:

При интеграции по протоколу LDAPs добавьте цепочку из рутовых и промежуточных сертификатов в файл certificates/ca/ca-bundle.crt.
Поместите пароль пользователя YOUR_SERVICE_USER_DN в Vault в файл паролей региона deployments/<regionname>/passwords_yml в поле “ldap_password”.
Создайте файл opensearch.yml в папке globals.d региона (значения параметров, начинающихся с YOUR, нужно заполнить своими данными):

enable_opensearch_ldap: "yes"
opensearch_admin_tls: "CN=backend.EXT_VIP_FQDN"
opensearch_ldap_hosts:
  - "LDAP_SERVER_NAME:LDAP_PORT"
opensearch_ldap_bind_dn: "YOUR_SERVICE_USER_DN"
opensearch_ldap_password: "{{ ldap_password }}"
opensearch_ldap_userbase: "YOUR_DN_TREE"
opensearch_ldap_rolebase: "YOUR_GROUP_TREE_DN"
opensearch_ldap_verify_hostnames: "false"
opensearch_ldap_enable_ssl: "true"
fluentd_opensearch_password: "{{ ldap_password }}"
fluentd_opensearch_user: "YOUR_SERVICE_USER_DN"

Создайте новый файл config\opensearch\roles_mapping.yml с содержимым:

all_access:
  backend_roles:
  - "YOUR_ADMIN_GROUP"
readall:
  backend_roles:
  - "YOUR_READ_GROUP"

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

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

Реализовано резервное копирование данных LCM узла и баз данных для регионов Openstack. Резервные копии баз данных регионов шифруются алгоритмом AES-256 с использованием PBKDF2 для усиления безопасности ключа.

Резервное копирование LCM осуществляется через запуск запланированного задания в Gitlab из репозитория: https://<gtilab_url>/project_k/Deployments/backup.

Рисунок 61 — Резервное копирование LCM

Кроме того, выполнить резервное копирование LCM можно, запустив скрипт backupLCM.sh (находится в директории с инсталлятором).

В результате выполнения скрипта backupLCM.sh в директории /installer/backup создается архив с именем в формате backupLCM-31-08-2022-1661925161.tar.gz. Этот файл требуется скопировать в надежное хранилище данных.

Резервное копирования баз данных регионов Openstack осуществляется через запуск запланированного задания из соответствующего региону репозитория: https://<gitlab.domain_name> project_k/Deployments//-/pipeline_schedules.

Рисунок 62 — Резервное копирование баз данных регионов Openstack

Восстановление LCM из резервной копии

Восстановление осуществляется путем запуска скрипта restoreLCM.sh.

Для запуска скрипта восстановления LCM необходимо положить резервную копию LCM с именем в формате backupLCM-31-08-2022-1661925161.tar.gz в ту же директорию рядом с ним, после чего запустить скрипт.

Восстановление базы данных регионов Openstack из резервной копии

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

Подсистема хранения данных о физических серверах Netbox

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

Пользовательский веб-интерфейс доступен по адресу https://netbox.<domain_name>.

Рисунок 63 — Интерфейс Netbox

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

В Netbox всегда можно отследить внесенные изменения (время, автора изменений и т.д.) в разделе Change Log (Operations → Logging → Change Log).

Кроме того, можно осуществлять операции с целой группой сущностей, а не с каждой по отдельности. Для этого необходимо выделить выбранные сущности и нажать Edit Selected под таблицей с ними. Другие кнопки позволяют настроить параметры по-другому: например, переименовать или удалить.

Базовая настройка сервиса

Для базовой настройки сервиса достаточно заполнить следующие разделы: Organization, Customization, IPAM, Provisioning и Devices.

В первую очередь нужно настроить параметры в разделах Sites и Tenancy. Последовательность создания сущностей для работы с Netbox такая: сайт-группа → регион → сайт.

Tenants

Чтобы добавить тенанта, откройте разделы в следующем порядке: Organization → Tenancy → Tenant.

Пример:

Name,Group,Description
itkey,,

Site Groups

Чтобы создать сайт-группу в Netbox, откройте разделы в следующем порядке: Organization → Sites → Site Groups.

Пример:

Name,Sites,Description
Group1,1,

Region

Добавьте регион в Netbox. Откройте Organization → Sites → Regions.

Пример:

Name,Sites,Description
BELARUS,1,

Site

Чтобы определеить сайт, откройте Organization → Sites → Sites. Сайты здесь — основная сущность.

Пример:

Name,Status,Facility,Region,Group,Tenant,Description
Site1,Active,,Group1,SK,,

Custom Fields

В разделе Custom Fields можно создавать дополнительные поля и задавать набор предопределенных параметров для каждого из них. Пример таких добавочных полей — два поля: role и state.

Дополнительные поля создаются и конфигурируются в Customization → Customization → Custom Fields.

Custom Fields, необходимые для работы Gitlab.domain_name Pipelines:

Name,Content types,Label,Group name,Type,Required,Description,ID,Default,Search weight,Filter logic,UI visibility,Cloneable,Display weight,Choices,Created,Last updated

role,dcim.device,role,,Multiple selection,False,,2,,100,Loose,Read/Write,False,100,"['controller', 'compute', 'network', 'osd', 'mon', 'baremetal']",2023-06-26 11:21,2023-06-26 11:21

state,dcim.device,state,,Selection,False,,1,,100,Loose,Read/Write,False,100,"['free', 'maintenance', 'production', 'ready', 'setup', 'shred']",2023-06-26 09:43,2023-06-26 09:43

Tags

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

Теги необходимо создать в Customization → Customization → Tags соответственно регионам/деплойментам у заказчика.

IPAM

Раздел IPAM включает настройки для модулей IPAM и содержит все, что относится к сетям. Префикс для сети создается в разделе IPAM → Prefixes → Prefixes. Затем нужно выбрать сайт и VLAN для префикса.

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

VLAN
Prefix

Manufacturers

Чтобы определить производителей в Netbox, откройте Devices → Device Types → Manufacturers и заполните там данные, т.е. марку сервера. Если марка отсутствует, ее необходимо добавить.

Пример:

ID,Name,Device Types,Inventory Items,Platforms,Description,Slug,Tags

42,Accedian,1,0,0,,accedian,

47,Adam Hall,1,0,0,,adam-hall,

1,APC,19,0,0,,apc,

6,Arista,40,0,0,,arista,

58,Asrock,2,0,0,,asrock,

19,ATEN,2,0,0,,aten,

12,Avocent,8,0,0,,avocent,

33,Backblaze,1,0,0,,backblaze,

15,Brocade,2,0,0,,brocade,

45,Cabeus,2,0,0,,cabeus,

25,Chenbro,1,0,0,,chenbro,

2,Cisco,64,44,0,,cisco,

3,Dell,37,0,0,,dell,

17,Delta,4,0,0,,delta,

14,Dlink,2,0,0,,dlink,

24,EMC,7,0,0,,emc,

35,Extreme,1,0,0,,extreme,

43,Fiberstore,6,0,0,,fiberstore,

59,FlyghtPro,0,0,0,,flyghtpro,

46,Flyht Pro,1,0,0,,flyht-pro,

52,Furukawa,1,0,0,,furukawa,

20,Geist,2,0,0,,geist,

21,Gigabyte,7,0,0,,gigabyte,

60,Graphcore,1,0,0,,graphcore,

28,HGST,4,0,0,,hgst,

4,HP,46,0,0,,hp,

38,Huawei,2,0,0,,huawei,

44,Intel,4,0,0,,intel,

5,Juniper,11,0,0,,juniper,

40,KEMP,1,0,0,,kemp,

41,KINX,1,0,0,,kinx,

56,Lenovo,1,0,0,,lenovo,

53,Lextron,1,0,0,,lextron,

57,Mellanox,1,0,0,,MELLANOX,

49,MikroTik,1,0,0,,mikrotik,

48,NetApp,2,0,0,,netapp,

13,Nokia,1,0,0,,nokia,

29,Noname,27,0,0,,noname,

16,NSFOCUS,1,0,0,,nsfocus,

7,Opengear,2,0,0,,opengear,

22,Oracle,7,0,0,,oracle,

10,Organiser,2,0,0,,organiser,

30,Panduit,2,0,0,,panduit,

32,Patchpanel,1,0,0,,patchpanel,

54,Pure Storage,1,0,0,,pure-storage,

26,QNAP,1,0,0,,qnap,

31,Quicknet,2,0,0,,quicknet,

11,Raritan,5,0,0,,raritan,

36,Rittal,4,0,0,,rittal,

23,Riverbed,2,0,0,,riverbed,

55,SNR,1,0,0,,snr,

9,std_config,0,0,0,,std_config,

37,STS,0,0,0,,sts,

39,Sun,2,0,0,,sun,

8,Supermicro,73,0,0,,supermicro,

34,Synology,1,0,0,,synology,

50,TP-LINK,1,0,0,,tp-link,

27,Tyan,1,0,0,,tyan,

51,Unknown,1,0,0,,unknown,

18,Vertiv,2,0,0,,vertiv,

Device Role

Чтобы определить роли устройств, откройте Device Types → Device Roles и выберите, что именно нужно установить. Обычно это Server.

Пример:

Name,Devices,VMs,Color,VM Role,Description

Access Switch,0,0,#2196f3,False,

Cable management,0,0,#111111,False,

Console Server,0,0,#009688,False,

Core Switch,0,0,#2196f3,False,

Customer equipment,0,0,#e91e63,False,

DCcore,0,0,#4caf50,False,

Disk enclosure,0,0,#3f51b5,False,

Network HW,0,0,#4caf50,False,

PDU,0,0,#607d8b,False,

Patch Panel,0,0,#03a9f4,False,

Planned,0,0,#f44336,False,

Power,0,0,#ff9800,False,

Rack mount boxes,0,0,#795548,False,

Rack mounting kit,0,0,#111111,False,

Router,0,0,#9c27b0,False,

SAN,0,0,#ff9800,False,

Server,5,0,#673ab7,False,

Server enclosure,1,0,#2196f3,False,

Device Type

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

Ниже приведен пример для блейд-корзины DELL M1000e. Данный пример будет далее дополняться:

Device Type,Manufacturer,Part number,Height (U),Full Depth,Instances

Dell M1000e,Dell,,10,True,1

M620,Dell,,0,True,4

M830,Dell,,0,True,1

Devices

Здесь все заполняется по данным заказчика:

Device
Порты
Бонды
IP Address (rmi)
IP Address (mgmt)
IP Address (vxlan)
IP Address (strg), если требуется

Аварийные ситуации. Восстановление данных

Порядок проверки сервисов при failover

На узле, где был произведен failover, выполните команду:

docker ps -a | grep -v Up

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

Особое внимание обратить в случае присутствия контейнеров со статусом Restarting.

Проверка состояния кластера RabbitMQ

На управляющем узле, где был произведен failover, выполните команду:

docker exec -it rabbitmq rabbitmqctl cluster_status

В выводе команды должно быть три узла кластера. Все узлы должны быть как в списке nodes.disc, так и в списке running_nodes.

Пример:

docker exec -it rabbitmq rabbitmqctl cluster_status
warning: the VM is running with native name encoding of latin1 which may cause Elixir to malfunction as it expects utf8. Please ensure your locale is set to UTF-8 (which can be verified by running "locale" in your shell)
Cluster status of node rabbit@host1 ...
[{nodes,[{disc,['rabbit@host1','rabbit@host2',
'rabbit@host3']}]},
{running_nodes,['rabbit@host13','rabbit@host2',
'rabbit@host3']},
{cluster_name,<<"rabbit@host1">>},
{partitions,[]},
{alarms,[{'host3',[]},
{'rabbit@host2',[]},
{'rabbit@host1',[]}]}]

Пайплайн по зачистке RabbitMQ и рестарту сервисов

Пайплайн по зачистке RabbitMQ (RMQ) и рестарту сервисов можно применять в случаях, перечисленных далее (по мониторингу или при соответствующих проверках через CLI).

При постоянном росте на протяжении 5 минут следующих метрик:

“Messages ready to be delivered to consumers”
“Messages pending consumer acknowledgement”
“Unroutable messages dropped”
“Unacknowledged messages”

При постоянном снижении на протяжении 5 минут следующих метрик:

“Total queues”
“Total channels”
“Total connections”

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

Если вы столкнулись с описанными выше проблемами с RabbitMQ, свяжитесь со службой поддержки.

Проверка состояния кластера MariaDB

Зайдите vault в хранилище секретов соответствующего региона и в passwords_yml найдите “database_password”.

После этого на управляющем узле, пережившем failover, выполните:

mysql -uroot -pPASSWORD -s -s --execute="SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';"

где PASSWORD — пароль, прочитанный из Vault.

Пример:

ssh control1
mysql -uroot  -pPassW0rd  -s -s --execute="SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';"
wsrep_local_state_comment       Synced

Состояние узла MariaDB должно быть “Synced”.

На этом же узле необходимо проверить количество активных узлов в кластере MariaDB:

Пример:

mysql -uroot  -pPassW0rd -s -s --execute="SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';"
wsrep_cluster_size      3

В кластере Wsrep должно быть 3 активных узла.

Проверка вспомогательных компонентов мониторинга и логирования

На узле, пережившем failover, выполните:

docker ps -a | egrep 'opensearch|prometheus|fulentd|grafana'

Все контейнеры должны быть в запущенном (“Up”) состоянии.

Проверьте журналы сервисов по пути /var/log/kolla/<service.name>/*.log.

Получить список состояний компонентов сервиса nova в OpenStack

openstack compute service list | grep $(HOSTNAME)

где $(HOSTNAME) — имя целевого узла, пережившего failover.

Вывод должен показать состояние всех компонентов nova на узле, пережившем failover как “Up”.

Пример:

openstack  compute service list | grep control1
|  3 | nova-conductor   | control1   | internal | enabled | up    | 2023-08-08T13:38:00.000000 |
| 33 | nova-scheduler   | control1   | internal | enabled | up    | 2023-08-08T13:38:03.000000 |
| 42 | nova-consoleauth | control1   | internal | enabled | up    | 2023-08-08T13:37:57.000000 |

Получите список состояний компонентов сервиса Cinder в OpenStack:

openstack volume service list | grep $(HOSTNAME)

где $(HOSTNAME) — имя целевого узла.

Вывод должен показать состояние всех компонентов Cinder на узле, пережившем failover как “Up”.

Пример:

openstack  volume service  list | grep control1
| cinder-scheduler | control1 | nova | enabled | up    | 2023-08-08T13:38:25.000000 |
| cinder-backup    | control1 | nova | enabled | up    | 2023-08-08T13:38:27.000000 |

Проверка журналов компонентов neutron на предмет актуальных ошибок

ls -t /var/log/kolla/neutron/ | egrep -v 'log..' | grep neutron | xargs -l1 -I {} tail -n 200 /var/log/kolla/neutron/{} | grep -i error

Вывод данной команды должен быть пустым.

Далее нужно зайти по ssh на любой узел с Openstack клиентом и, используя файл admin-openrc.sh, обратиться к API OpenStack, чтобы получить статус компонентов сервиса neutron.

Пример:

openstack network agent list | grep network1
| 02480c02-1827-4007-b31a-08c4cb599826 | Metadata agent            | network1    | None              | True  | UP    | neutron-metadata-agent    |
| 67dd92dc-465e-4c28-a52d-9e76b85f66bb | Open vSwitch agent        | network1    | None              | True  | UP    | neutron-openvswitch-agent |
| a0411328-04d9-46b3-a0a2-0c4e23b8eb06 | L3 agent                  | network1    | nova              | True  | UP    | neutron-l3-agent          |
| bf2b46eb-74a5-40b6-bc40-e0e6fb035dd4 | DHCP agent                | network1    | nova              | True  | UP    | neutron-dhcp-agent        |

Failover одного управляющего узла

Failover — это процесс переключения на резервный узел при отказе активного узла.

На сервере, пережившем failover, нужно проверить журналы Keystone и MariaDB:

grep -P -ri '(error|trace|\=5\d{2})' /var/log/kolla/keystone/\*.log
grep -P -ri '(error|trace|\=5\d{2})' /var/log/kolla/mariadb/\*.log

В журналах не должно быть записей 5хх, Traceback, Error.

Если ошибки 5хх, Traceback, Error встречаются только в Keystone — перезапустите контейнеры Keystone:

docker restart keystone

При возникновении проблем в MariaDB требуется понять и устранить причину в логах.

Failover двух управляющих узлов

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

Обычно 5 мминут достаточно, чтобы узлы galera добавились в кластер и синхронизировали свое состояние.

При этом крайне желательно после загрузки сервера (в данном примере — controller1) выполнить проверку статуса MariaDB.

Пример:

ssh controller2
mysql -uroot  -pPassW0rd  -s -s --execute="SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';"
wsrep_local_state_comment       Synced

ssh controller3
mysql -uroot  -pPassW0rd  -s -s --execute="SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';"
wsrep_local_state_comment       Synced

Failover всех управляющих узлов

Восстановите Galera cluster.
Откройте страницу https://<LCM_URL>/project_k/deployments/<REGION>/-/pipelines → Run Pipeline.

KOLLA_ANSIBLE_DEPLOY_ACTION – mariadb_recovery

Дождитесь выполнения пайплайна и убедитесь, что работа сервисов восстановлена.

Перезапустите все контейнеры, кроме MariaDB и RabbitMQ.
Перезапустите контейнеры Openstack на узлах Compute.

Failover вычислительного узла

На сервере, пережившем failover, выполните следующие проверки:

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

docker ps -a | grep -i nova_compute

Убедитесь, что контейнер nova_compute находится в состоянии Up.

На вычислительном узле проверьте лог /var/log/kolla/nova/nova-compute.log на отсутствие событий ERROR или Traceback.
При их наличии убедитесь, что на вычислительном узле нет запущенных ВМ. Для этого на LCM-узле (или любом узле с установленным клиентом OpenStack CLI) выполните команду :

openstack server list --all --long | grep $(имя вычислительного узла)

Если команда вернула информацию о каких-либо виртуальных машинах, тогда следует удалить их в контейнере nova_libvirt на вычислительном узле. Для этого для каждой ВМ:
1. Получите имя ВМ в среде libvirt, для этого выполните команду:
  
  openstack server show ${vmuuid} -c "OS-EXT-SRV-ATTR:instance_name" -f value
2. Зайдите на вычислительный узел и выполните команду:
  
  docker exec nova_libvirt virsh undefine ${vm_name}
Включите вычислительный узел. Для этого на LCM-узле (или любом узле с установленным клиентом OpenStack CLI) выполните команду:

openstack compute service set --enable ${имя_вычислительного_узла} nova-compute

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

Выход вычислительного узла из строя не связан с выходом из строя SDS (Ceph).
Образы ВМ, работавших на этом вычислительном узле, находятся в консистентном состоянии.
Образы ВМ, работавших на этом вычислительном узле, корректно эвакуировались с вычислительного узла.

Термины и сокращения

Термины

Термин	Определение
Мониторинг платформы	Программные решения для мониторинга общего состояния Платформы динамической инфраструктуры.
Мониторинг сервисов	Программные решения для мониторинга сервисов IaaS, PaaS, SaaS Платформы динамической инфраструктуры.
Платформа	Платформа (Платформа динамической инфраструктуры) — это автоматизированная система по предоставлению сервисов IaaS, PaaS, SaaS.
Платформа автоматизации ИТ процессов	Платформа автоматизации, основанная на ППО MF Service Manager.
Платформа виртуализации	Программное обеспечение, предоставляемое Исполнителем.
Платформа контейнеризации	Решение виртуализации, при котором ядро операционной системы поддерживает несколько изолированных экземпляров пространства пользователя вместо одного. Эти экземпляры (обычно называемые контейнерами или зонами) с точки зрения пользователя полностью идентичны отдельному экземпляру операционной системы.

Сокращения

Сокращение	Расшифровка
AD	Active Directory (Службы каталогов корпорации Microsoft для операционных систем семейства Windows Server)
API	Application Programming Interface (Интерфейс программирования приложений)
CLI	Command line interface (Интерфейс командной строки)
FQDN	Fully Qualified Domain Name (Полностью определенное доменное имя)
HTTP	HyperText Transfer Protocol (Протокол передачи гипертекста)
HTTPS	HyperText Transfer Protocol Secure (Расширение протокола HTTP для поддержки шифрования в целях повышения безопасности)
IaaS	Infrastructure as a Service (Инфраструктура как сервис)
SaaS	Software as a service (Программное обеспечение как услуга)
SLA	Service Level Agreement (Соглашение об уровне предоставления услуги)
SDS	Software-defined storage (Программно-определяемое хранилище)
TTL	Time To Live (Время жизни)
ВМ	Виртуальная машина
ВУ	Вычислительный узел
ИБ	Информационная безопасность
КЕ	Конфигурационная единица
КСПД	Корпоративная сеть передачи данных
ОС	Операционная система
ПВР	Подсистема вычислительных ресурсов
ПО	Программное обеспечение
ППД	Подсистема передачи данных
ППО	Прикладное программное обеспечение
СПО	Системное программное обеспечение
СУБД	Система управления базами данных
СХД	Система хранения данных
ЦОД	Центр обработки данных
ЧТЗ	Частное техническое задание
УЗ	Учетная запись