Руководство администратора KeyStack
===================================
Введение
--------
Полное наименование системы —  KeyStack.В
Краткое наименование системы  —  Платформа.
Разработчик системы — ITKey.
Краткое описание возможностей
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Платформа динамической инфраструктуры предназначена для предоставления сервисов IaaS.
Требования к квалификации персонала
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Системные администраторы Платформы отвечают за комплексную настройку инфраструктуры Платформы, предоставляемой в качестве услуги конечным потребителям, за устранение неисправностей, сбор диагностической информации и эскалацию неисправностей производителю аппаратной или программной составляющей Платформы.
Системные администраторы выполняют следующие функциональные обязанности в рамках работы с Платформой:
- настройка и диагностирование системы;
- обслуживание системного и прикладного программного обеспечения системы;
- администрирование базы данных;
- резервное копирование и восстановление данных;
- производство регламентных работ и анализ их результатов.
К системным администраторам предъявляются следующие требования:
- Навыки системного администрирования Linux;
- Прохождение обучения от компании ITKey по использованию компонентов, разработанных вендором: DRS, HA, Portal;
- Навыки работы со службами Платформы, в том числе способность самостоятельно осуществлять:
- мониторинг программными средствами, внешний осмотр аппаратной составляющей комплекса;
- изменение настроек Платформы;
- сбор диагностических данных и эскалацию сложных проблем по гарантийным обязательствам производителю.
Для обеспечения функционирования системы необходимо наличие как минимум одного системного администратора.
Перечень эксплуатационной документации
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Документация Платформы включает в себя следующие документы:
- Паспорт облака
- План по резервному копированию и восстановлению компонентов Платформы
- Рнструкция администратора
- Рнструкция пользователя
- Рнструкция РїРѕ резервному копированию Рё восстановлению всех компонентов
Назначение и условия применения
-------------------------------
Виды деятельности, функции
~~~~~~~~~~~~~~~~~~~~~~~~~~
В состав Платформы входят следующие подсистемы:
- Подсистема вычислительных ресурсов — обеспечивает виртуализацию вычислительных ресурсов и управление ими;
- Подсистема хранения данных — обеспечивает управление ресурсами хранения;
- Подсистема передачи данных — обеспечивает реализацию и управление виртуальной сетевой инфраструктурой;
- Подсистема мониторинга — обеспечивает сбор метрик с ресурсов Платформы, мониторинг Платформы и ее сервисов;
- Подсистема Оркестрации — обеспечивает возможность автоматизированного управления ресурсами виртуальной инфраструктуры Платформы.
Программные и аппаратные требования к Платформе
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Требования Рє инфраструктуре приведены РІ `Рнструкции РїРѕ установке <https://docs.keystack.ru/latest/keystack_installation/instructions_for_installing.html#id9>`_.
Подготовка к работе
-------------------
Перечень программного обеспечения, включающий системное, базовое и прикладное ПО, приведен в Пояснительной записке.
Системный администратор использует в работе следующие интерфейсы Платформы, доступные по представленным далее ссылкам:
- Портал самообслуживания;
- интерфейс Horizon;
- Opensearch;
- Grafana;
- Prometheus
- API компонентов Платформы.
Основным рабочим веб-интерфейсом является Horizon.
Помимо веб-интерфейса, в работе используется Openstack CLI.
Подключение к Порталу самообслуживания
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Подключение к Порталу самообслуживания производится с помощью веб-браузера. Для доступа к интерфейсам управления Портала самообслуживания могут использоваться браузеры актуальных версий:
- Google Chrome 72 и выше;
- Mozilla Firefox 63 и выше.
При запросе логина и пароля необходимо ввести учетные данные. Внешний вид формы аутентификации приведен на рисунке ниже.
.. figure:: Media/auth.png
:alt: auth
:figclass: bg-warning
:target: ../_images/auth.png
Рисунок 1 — Окно аутентификации в Портале самообслуживания
Главная страница интерфейса управления имеет тематическое боковое меню (далее в тексте — левое меню), с помощью которого выполняется переход к различным разделам интерфейса управления Платформы.
Подключение к интерфейсу управления Openstack CLI
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Перед началом работы в CLI необходимо получить исходный файл openrc и загрузить его на локальный компьютер администратора для установки переменных среды. Для получения файла openrc необходимо перейти в интерфейс портала администратора и скачать его на странице **Status Page**.
.. IMPORTANT::
Если используется библиотека Castellan, то при работе в Openstack CLI у администратора при каждом подключении будет запрашиваться пароль.
Openstack клиент можно установить на рабочее место администратора. Ниже приведен порядок установки Openstack клиента для различных ОС.
.. _openstack-linux:
Установка 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 <#openstack-linux>`__.
Запуск и выключение Платформы
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Запуск Платформы
^^^^^^^^^^^^^^^^
Почти все сервисы платформы — stateless, или имеют внутренние механизмы failover, прихода к консенсусу в кластере. Но есть сервис, на который надо обратить особое внимание — Galera Cluster. Поэтому в пункте `Выключение всех компонентов Платформы <#disabling-all-components>`__ важно было делать паузы перед выключением следующего узла и запомнить порядок выключения — это минимизирует до определенной степени шанс получить с "несобранным" кластером Galera Cluster с MariaDB после включения.
Порядок включения серверов Платформы в общем случае выглядит так:
1. Включите с паузами и по очереди управляющие узлы. Включайте в обратном порядке относительно выключения, т.е. если серверы были выключены в порядке 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.
2. Включите вычислительные узлы.
3. Выполните проверку всех узлов с помощью инструкций, приведенных в разделе `Порядок проверки сервисов при failover <#failover-service-check-order>`__.
4. Оповестите владельцев workload'ов о возможности запуска их нагрузок в облаке — либо самостоятельно включите инстансы в зависимости от технического регламента.
.. _disabling-all-components:
Выключение всех компонентов Платформы
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Для отключения платформы и её компонентов с сохранением данных необходимо выполнить следующие шаги:
1. Оповестить владельцев виртуальных машин о предстоящем отключении.
2. Выключить сервис DRS, деактивировав задание в панели администратора, затем последовательно подключившись к каждому контроллеру и введя команду ``systemctl stop kolla-drs-container.service``.
3. Выключить сервис HA, последовательно подключившись к каждому контроллеру и введя команду ``systemctl stop kolla-consul-container.service``.
4. Подключиться к серверу LCM для выполнения дальнейших действий.
Пример:
::
ssh lcm
source admin-openrc.sh
5. Зафиксировать состояние виртуальных машин на момент выключения региона, введя команду:
::
openstack server list --all-projects > VMs.$(date "+%Y-%m-%d-%H-%M-%S").txt
6. Выключить виртуальные машины средствами OpenStack, введя команду:
::
openstack server list --all-projects -c ID -f value | \
xargs -n1 openstack server stop
7. Проверить выключение всех виртуальных машин командой:
::
openstack server list --all-projects -c ID -c Status -f value | \
grep -v Active
.. NOTE::
Если проверка покажет наличие виртуальных машин в статсуе ``ACTIVE``, то необходимо повторить выключение каждой такой виртуальной машины индивидуально, введя команду ``openstack server stop <VM ID>``, подставляя в качестве ``VM ID`` значенем из столбца ID предыдущего вывода.
8. Выключить узлы-гипервизоры средствами операционной системы:
::
for HOST in $(openstack hypervisor list -c "Hypervisor Hostname" -f value);\
do \
ssh -x ${HOST} "shutdown -h now";\
done
9. Р’ строгом РїРѕСЂСЏРґРєРµ очерёдности 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 для ВМ, созданных из этих флейворов, в пределах хоста или пула ресурсов. Чем выше значение одного или другого приоритета, тем больше ресурсов получит ВМ в пределах пула или отдельного хоста.
Чтобы установить приоритет по выделению ресурсов для ВМ с помощью флейвора, выполните следующие действия:
1. На вкладке Ресурсы → Flavors нажмите выпадающий список в столбце "Actions" для нужного флейвора. Выберите "Pедактировать".
2. В открывшемся окне проверьте имя и ID флейвора.
3. Выберите ``quota:cpu_shares`` либо ``quota:cpu_quota`` в Quota priority key. Задайте значение для этого параметра в поле Quota priority value.
4. Нажмите "Применить".
.. figure:: Media/flavors.png
:alt: flavors
:figclass: bg-warning
:target: ../_images/flavors.png
Рисунок 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> — наименование флейвора.
На Портале администратора:
1. В левом меню Портала перейдите в раздел Ресурсы → Flavors.
2. Нажмите кнопку "Создать flavor".
3. Добавьте имя, описание, значения RAM и vCPUs для флейвора.
4. В разделе Extra specs укажите приоритеты для выделения ресурсов на ВМ, основанных на флейворе. Выберите ``quota:cpu_shares`` либо ``quota:cpu_quota`` в Quota priority key. Задайте значение для выбранного параметра в поле Quota priority value. Подробнее о приоритетах для ресурсов ВМ см. выше.
.. figure:: Media/new_flavor.png
:alt: New_flavor
:figclass: bg-warning
:target: ../_images/new_flavor.png
Рисунок 3 — Новый флейвор
5. Нажмите "Создать".
Удаление флейвора ВМ
''''''''''''''''''''
В Openstack CLI удаление флейвора ВМ выполняется командой:
``openstack flavor delete <flavor> [<flavor> ...]``
где <flavor> — наименование или ID флейвора. Одновременно может быть удалено несколько флейворов.
На Портале администратора для удаления флейвора выберите действия "Удалить" в столбце "Actions" для нужного флейвора.
Работа с шаблонами ВМ
^^^^^^^^^^^^^^^^^^^^^
Для упрощения и ускорения создания новых виртуальных машин используйте шаблоны ВМ на Портале администратора.
Создание шаблона
''''''''''''''''
1. В левом меню Портала перейдите в раздел Ресурсы → ВМ.
2. Нажмите кнопку "Создать ВМ".
3. Если нет шаблона, выберите действие Save as new template в открывшемся окне.
4. Заполните поле Project. После выбора проекта будут доступны для заполнения остальные поля.
.. figure:: Media/New_template.png
:alt: New_template
:figclass: bg-warning
:target: ../_images/New_template.png
Рисунок 4 — Новый шаблон ВМ
5. Нажмите "Создать".
Редактирование шаблона
''''''''''''''''''''''
1. В левом меню Портала перейдите в раздел Ресурсы → ВМ.
2. Нажмите кнопку "Создать ВМ".
3. Выберите действие Choose template в открывшемся окне. Название выбранного шаблона отобразится на месте кнопки Choose template, а справа будут параметры создаваемой ВМ.
4. Найдите нужный шаблон в окне Templates. Нажмите значок ``>`` в столбце "Params", чтобы посмотреть параметры шаблона.
5. Выберите дальнейшее действие с шаблоном в столбце "Actions":
- Для изменения параметров шаблона выберите Apply template.
- Для изменения названия шаблона (Template name) или его описания (Template description) выберите Edit template. Нажмите "Редактировать", чтобы применить изменения.
- Для удаления шаблона выберите Delete template.
.. figure:: Media/Templates.png
:alt: Templates
:figclass: bg-warning
:target: ../_images/Templates.png
Рисунок 5 — Редактирование шаблона ВМ
6. Если вы выбрали действие Apply template, название выбранного шаблона отобразится на месте кнопки Choose template. Настройте параметры шаблона на вкладке Template params.
7. Выберите, как сохранить изменения параметров шаблона:
- Чтобы применить изменения к отредактированному шаблону, нажмите Save current template.
- Чтобы сохранить его как новый шаблон, нажмите Save as new template.
Создание ВМ из шаблона
'''''''''''''''''''''''
1. В левом меню Портала перейдите в раздел Ресурсы → ВМ.
2. Нажмите кнопку "Создать ВМ".
3. Выберите действие Choose template в открывшемся окне.
4. Найдите нужный шаблон в окне Templates и выберите для него Apply template в столбце "Actions".
5. Название выбранного шаблона отобразится на месте кнопки Choose template, а справа будут параметры создаваемой ВМ. Настройте параметры создаваемой ВМ на вкладке New VM params.
6. Нажмите "Создать".
Новая виртуальная машина со статусом BUILD появится в списке машин на странице ВМ.
Работа с образами ВМ
^^^^^^^^^^^^^^^^^^^^
Просмотр списка образов
'''''''''''''''''''''''
Просмотр образов осуществляется на Портале администратора, в интерфейсе Horizon или с использованием Openstack CLI.
Для просмотра списка образов на Портале необходимо в левом меню перейти в раздел Ресурсы → Images. Пример вида раздела представлен на рисунке ниже.
.. figure:: Media/images.png
:alt: images
:figclass: bg-warning
:target: ../_images/images.png
Рисунок 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.
**Создание образа из файла**
Для создания образа в Портале администратора выполните следующие действия:
1. В левом меню Портала перейдите в раздел Ресурсы → Images.
2. Нажмите кнопку "Загрузить Image".
3. Заполните поля. Обязательно нужно указать имя образа, тип ОС и выбрать файл для образа. Пример заполнения см. на рисунке ниже.
4. Нажмите кнопку "Начать загрузку".
.. figure:: Media/img.png
:alt: img
:figclass: bg-warning
:target: ../_images/img.png
Рисунок 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. Для этого необходимо в левом меню перейти в раздел Диски, найти диск, из которого будет создаваться образ, и затем в выпадающем списке выбрать пункт меню "Загрузить образ".
В форме создания образа нужно выбрать формат диска (см. рисунок ниже), указать название образа и нажать кнопку "Загрузить".
.. figure:: Media/imgDisc.png
:alt: imgDisc
:figclass: bg-warning
:target: ../_images/imgDisc.png
Рисунок 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.
Для удаления образа в Портале администратора выполните следующие действия:
1. Перейдите в раздел Ресурсы → Images, выберите образ для удаления и нажмите значок ``X`` в столбце "Actions".
2. Проверьте имя и ID образа. Если все правильно, нажмите кнопку "Удалить" (см. рисунок ниже).
.. figure:: Media/imgDel.png
:alt: imgDel
:figclass: bg-warning
:target: ../_images/imgDel.png
Рисунок 9 — Удаление образа
Включение множества очередей (multiqueue) в Unix-подобных операционных систем
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
KeyStack поддерживает множества очередей (multiqueue) у образа виртуальной машины (ВМ) и отдельной ВМ для операционных систем семейства Linux.
**Ограничения**
Функция множества очередей virtio-net обеспечивает повышение производительности, но имеет некоторые ограничения:
- ОС ВМ ограничена ~ 200 векторами MSI. Для каждой очереди сетевого адаптера требуется вектор MSI, а также любое устройство virtio или назначенное устройство PCI. Определение экземпляра с несколькими сетевыми адаптерами virtio и виртуальными ЦП может привести к превышению лимита гостевого MSI.
- Множества очередей хорошо работают для входящего трафика, но иногда могут вызвать снижение производительности для исходящего трафика.
- Включение множества очередей увеличивает общую пропускную способность сети, но одновременно увеличивает потребление ресурсов CPU.
- Если функция множества очередей была включена на хосте, но не была включена администратором в ОС ВМ, векторы MSI будут использоваться впустую.
- Количество очередей автоматически устанавливается равным количеству виртуальных ЦП. Чем больше количество ЦП, тем выше пропускная способность сети.
**Примечание.** Для некоторых образов операционных систем, например, Centos6, недостаточно включить множества очередей только на уровне образа в конфигурации QEMU. Администратору ОС необходимо вручную включить функциональность с помощью ethtool на самой ВМ.
1. **Включение множества очередей для новых ВМ из образа**
Вариант включает множества очередей на уровне образа и будет работать для всех ВМ, созданных на базе этого образа после выполнения инструкции.
1. Создайте образ ВМ.
2. Получите список доступных образов, введя команду:
``openstack image list``
3. Скопируйте ID нужного образа.
4. Включите множество очередей, введя команду:
``openstack image set <IMG_ID> --property hw_vif_multiqueue_enabled=true``
2. **Проверка количества очередей**
1. Создайте ВМ, в которой больше одного ЦП, и подключитесь к ее консоли.
2. Посмотрите все сетевые интерфейсы, введя команду:
``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 — сетевой интерфейс, для которого нужно проверить подключение множества очередей.
4. Посмотрите текущее количество очередей, введя команду:
``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
3. **Установка нужного количества очередей для ВМ**
Количество очередей не может быть больше количества виртуальных ЦП.
1. Выполните команду:
``sudo ethtool -L <имя_сетевого_интерфейса> combined <число_очередей>``
Пример ввода:
``$ sudo ethtool -L eth0 combined 2``
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.
Для просмотра списка ВМ на Портале администратора необходимо выбрать Ресурсы → ВМ в левом меню интерфейса (см. рисунок ниже).
.. figure:: Media/vm.png
:alt: vm
:figclass: bg-warning
:target: ../_images/vm.png
Рисунок 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 используйте кнопки "Выключить инстанс", "Горячая перезагрузка инстанса" и "Холодная перезагрузка инстанса" (см. рисунок ниже).
.. figure:: Media/vmState.png
:alt: vmState
:figclass: bg-warning
:target: ../_images/vmState.png
Рисунок 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 — укажите одну или несколько групп безопасности из списка доступных.
.. figure:: Media/newVm.png
:alt: newVm
:figclass: bg-warning
:target: ../_images/newVm.png
Рисунок 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 и имя ВМ, статус, теги и т.д., которые отображаются внизу страницы.
.. figure:: Media/VM_monitoring.png
:alt: stats
:figclass: bg-warning
:target: ../_images/VM_monitoring.png
Рисунок 13 — Статистика по ВМ
Мониторинг производительности вычислительных узлов
'''''''''''''''''''''''''''''''''''''''''''''''''''
Вы можете просматривать информацию о потребляемых ресурсах вычислительных узлов (гипервизоров) в интерфейсе Портала администратора. На странице каждого гипервизора доступны графики со статистикой по таким показателям, как загрузка CPU, использование памяти и температура.
Для просмотра производительности вычислительного узла выберите Гипервизоры → Гипервизоры в левом меню Портала и нажмите ссылку с ID необходимого узла.
.. figure:: Media/hyper_stats.png
:alt: hyper_stats
:figclass: bg-warning
:target: ../_images/hyper_stats.png
Рисунок 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 и флейвора.
1. | Настройка гипервизора.
| Настройка предполагает добавление опций в загрузку ядра — isolcpus=2,3,4,5,6,7... - перечислите все ядра, которые нужно изолировать — добавление данной настройки предполагает перезагрузку сервера.
2. | Настройка сервиса nova-compute.
| Далее необходимо доработать конфигурацию сервиса nova-compute — добавьте в nova.conf гипервизора, на котором выполнена настройка isolcpus.
::
[compute]
cpu_dedicated_set=2-10 #указать желаемый набор ядер, который коррелирует с isolcpus
3. | Настройка host aggregate и flavor.
| Создайте агрегат, в который нужно добавить гипервизоры, где будет использоваться механизим CPU pinning. В метаданные агрегата добавьте параметр: pinned = true
4. Создайте флейвор нужного размера и добавьте в него метаданные:
::
aggregate_instance_extra_specs:pinned = true
hw:cpu_policy = dedicated
Рспользование механизма Memory ballooning
'''''''''''''''''''''''''''''''''''''''''
.. В новой структуре это будет отдельная статья. Полный контент для нее: https://docs.google.com/document/d/1XENBPS7EK1zRJEwH8qHCF9u1ICRYem1JdYy8afEkd80/edit?tab=t.0#heading=h.8dhxrpg67xf
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 необходимо выбрать Вычислительные ресурсы в†’ Рнстансы РІ левом меню, далее найти Р’Рњ, ресурсы которой необходимо изменить, Рё выбрать РІ контекстном меню "Рзменить размер инстанса" (СЃРј. СЂРёСЃСѓРЅРѕРє ниже).
.. figure:: Media/vmSize.png
:alt: vmSize
:figclass: bg-warning
:target: ../_images/vmSize.png
Рисунок 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" в таблице ВМ на вкладке Ресурсы → ВМ.
Чтобы сменить зону доступности ВМ:
1. На вкладке Ресурсы → ВМ выберите любую из виртуальных машин, расположенных не в своей зоне доступности.
2. Нажмите выпадающий список в столбце "Actions" и выберите "Placement management", а затем "Change AZ".
.. figure:: Media/AZ_change.png
:alt: AZchange
:figclass: bg-warning
:target: ../_images/AZ_change.png
Рисунок 16 – Смена зоны доступности ВМ
3. В открывшемся окне выберите зону доступности в выпадающем списке и нажмите "Применить".
.. figure:: Media/AZ_chaned.png
:alt: AZchanged
:figclass: bg-warning
:target: ../_images/AZ_chaned.png
Рисунок 17 — Выбор зоны доступности ВМ
Работа с группами серверов ВМ
'''''''''''''''''''''''''''''''
В KeyStack группы серверов ВМ (сервер-группы, server groups) применяются для объединения виртуальных машин в группы, которым можно присвоить определенные свойства. Группы серверов привязаны к конкретному проекту.
Для создания группы серверов ВМ в Портале администратора выполните следующие действия:
1. В левом меню Портала перейдите в раздел Ресурсы → Server Groups.
2. Нажмите кнопку "Создать Server Group".
3. Заполните поля. Обязательно нужно указать имя группы и политику расположения. При выборе anti-affinity policy необходимо также указать максимально возможное количество ВМ на хост. Когда все поля будут заполнены, нажмите кнопку "Создать".
.. figure:: Media/servergroup.png
:alt: SG
:figclass: bg-warning
:target: ../_images/servergroup.png
Рисунок 18 — Группы серверов ВМ
Для просмотра всех данных о группе серверов нажмите ID группы на странице списка всех групп.
Для удаления группы серверов ВМ найдите в списке нужную группу, нажмите выпадающий список в столбце "Actions" и выберите пункт "Удалить".
Для добавления ВМ в группу серверов или удаления из нее выполните следующие действия:
1. На вкладке Ресурсы → ВМ выберите виртуальную машину, которую нужно добавить в группу серверов или удалить из нее. Нажмите "Change Server Group" в столбце "Actions" для этой ВМ.
2. В открывшемся окне заполните поле "New server group". Чтобы добавить ВМ в группу, выберите эту группу из выпадающего списка. Чтобы удалить ВМ из группы, нажмите значок ``X`` и оставьте поле пустым. Текущая группа ВМ отображается в поле "Current Server Group".
3. Нажмите кнопку "Применить".
.. figure:: Media/SG_add.png
:alt: SG_add
:figclass: bg-warning
:target: ../_images/SG_add.png
Р РёСЃСѓРЅРѕРє 19 — Рзменение РіСЂСѓРїРїС‹ серверов для Р’Рњ
Удаление ВМ
'''''''''''
Удаление ВМ осуществляется в интерфейсе Портала администратора, Horizon или в OpenStack CLI.
Для удаления Р’Рњ РІ Horizon необходимо выбрать Вычислительные ресурсы в†’ Рнстансы РІ левом меню, далее найти Р’Рњ, которую необходимо удалить, Рё выбрать РІ контекстном меню РїСѓРЅРєС‚ "Удалить инстанс" (СЃРј. СЂРёСЃСѓРЅРѕРє ниже).
.. figure:: Media/vmRemove.png
:alt: vmRemove
:figclass: bg-warning
:target: ../_images/vmRemove.png
Рисунок 20 — Удаление ВМ
Если необходимо удалить несколько виртуальных машин, то нужно выбрать их в списке и выбрать в контекстном меню пункт "Удалить" (см. рисунок ниже).
.. figure:: Media/vmGroup.png
:alt: vmGroup
:figclass: bg-warning
:target: ../_images/vmGroup.png
Рисунок 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-миграцию ВМ с Портала администратора:
1. В левом меню Портала перейдите в раздел Ресурсы → ВМ и выберите любую машину из таблицы ВМ.
2. Нажмите выпадающий список в столбце "Actions" и выберите "Placement management", а затем "Live Migrate".
3. В открывшемся окне поставьте флажок "Ignore AZ restriciton", выберите нужный гипервизор и нажмите кнопку "Мигрировать".
.. figure:: Media/live_migrate.png
:alt: live_migrate
:figclass: bg-warning
:target: ../_images/live_migrate.png
Рисунок 22 — Live-миграция ВМ
Миграция ВМ с дисками между регионами
'''''''''''''''''''''''''''''''''''
При необходимости вы можете переносить виртуальные машины с дисками из одного региона в другой.
Чтобы перенести ВМ с дисками в другой регион:
1. На вкладке Ресурсы → ВМ выберите виртуальную машину с дисками для переноса.
2. Нажмите выпадающий список в столбце "Actions" и выберите "Placement management", а затем "Migrate to the region".
.. figure:: Media/VM_region.png
:alt: VM_region
:figclass: bg-warning
:target: ../_images/VM_region.png
Рисунок 23 – Перенос ВМ с дисками в другой регион
3. В открывшемся окне по очереди выберите регион, проект и сеть для переноса ВМ. Нажмите "Start migration".
.. figure:: Media/VM_region_new.png
:alt: VM_region_С‚_new
:figclass: bg-warning
:target: ../_images/VM_region_new.png
Рисунок 24 – Выбор параметров для переноса ВМ в другой регион
4. Дождитесь завершения процесса переноса. Обратите внимание, что в процессе миграции ВМ будет выключена, а ее диски выгружены.
Р’Рњ будет перенесена РІ РґСЂСѓРіРѕР№ регион Рё там запущена. После переноса Р’Рњ будет сразу работать. Рсходная Р’Рњ РЅРµ будет удалена.
Рвакуация Р’Рњ СЃ вычислительного узла
'''''''''''''''''''''''''''''''''''
В контейнере kolla_toolbox на управляющем узле необходимо выполнить команду для эвакуации ВМ на другие вычислительные узлы в составе кластера:
``nova host-evacuate-live <хостнейм_удалаяемого_узла>``
Аварийное восстановление ВМ (Nova rescue)
''''''''''''''''''''''''''''''''''''''''''
Вы можете проводить аварийное восстановление ВМ на Портале администратора. Такие ВМ будут загружены с указанного вами загрузочного образа (обычно с той же ОС, на которой ВМ работает), и к ней будут подключены все ее диски. Статус ВМ изменится на RESCUE.
1. На вкладке Ресурсы → ВМ выберите виртуальную машину, которую нужно перевести в статус RESCUE. Нажмите "Rescue VM" в столбце "Actions" для этой ВМ.
2. Заполните поля — пароль и образ. Выбранный образ должен иметь следующие свойства: 'hw_rescue_device': 'disk' и 'hw_rescue_bus': 'scsi'.
3. Нажмите кнопку "Запустить". ВМ перейдет в статус RESCUE, а инстанс будет перезагружен из выбранного образа.
.. figure:: Media/rescue.png
:alt: rescue
:figclass: bg-warning
:target: ../_images/rescue.png
Рисунок 25 — Аварийное восстановление ВМ
Чтобы перевести ВМ обратно в статус ACTIVE, выберите действие "Unrescue VM" в столбце "Actions" для этой ВМ.
Работа с моментальными снимками ВМ
'''''''''''''''''''''''''''''''''''
На Портале администратора вы можете создавать моментальные снимки ВМ, чтобы сохранить параметры виртуальных машин и в случае сбоя восстановить машины из этих снимков.
В данный момент технология создания таких снимков ВМ поддерживается только для драйверов Huawei Dorado.
.. Термин "моментальные снимки" - используем на Портале и в документах
Для создания моментального снимка ВМ:
1. На вкладке Ресурсы → ВМ выберите виртуальную машину.
2. Нажмите выпадающий список в столбце "Actions" и выберите "Volume management", а затем "Create snapshot of boot volume".
3. В открывшемся окне укажите имя и название снимка ВМ. Чтобы добавить дополнительные параметры, нажмите ``+`` для "Extra specs". Нажмите "Создать".
.. figure:: Media/new_snapshot.png
:alt: new_snapshot
:figclass: bg-warning
:target: ../_images/new_snapshot.png
Рисунок 26 — Создание снимка ВМ
Чтобы откатить ВМ к моментальному снимку:
1. На вкладке Ресурсы → ВМ выберите виртуальную машину.
2. Нажмите выпадающий список в столбце "Actions" и выберите "Volume management", а затем "Revert boot volume to latest snapshot".
3. В открывшемся окне подтвердите действие. Нажмите "Откатить".
.. figure:: Media/snapshot.png
:alt: snapshot
:figclass: bg-warning
:target: ../_images/snapshot.png
Рисунок 27 — Восстановление ВМ из снимка
.. note::
Функция отката ВМ к моментальному снимку поддерживается не всеми СХД. В таком случае выдается ошибка ``400`` вида ``It is not possible to revert server <id> to the latest snapshot: unsupported volume backend type.``
Клонирование существующих виртуальных машин с кастомизацией
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Необходимо выполнить следующие действия:
1. Подключитесь к Порталу самообслуживания.
2. На странице Project → Volumes → Volumes выберите диск, у которого в колонке "Attached To" указана ВМ, которую нужно скопировать (см. рисунок ниже).
3. Нажмите выпадающий список в столбце "Actions" и выберите пункт "Create Snapshot".
.. figure:: Media/cloning_1.png
:figclass: bg-warning
:target: ../_images/cloning_1.png
Рисунок 28 — Выбор диска
4. В открывшемся окне введите имя снимка в поле "Snapshot Name" и нажмите кнопку "Create Volume Snapshot (Force)" (см. рисунок ниже).
.. figure:: Media/cloning_2.png
:figclass: bg-warning
:target: ../_images/cloning_2.png
Рисунок 29 — Создание снимка
5. На странице Project → Volumes → Snapshots нажмите выпадающий список в столбце "Actions" в строке тестового снимка.
6. Выберите пункт "Launch as Instance" (см. рисунок ниже).
.. figure:: Media/cloning_3.png
:figclass: bg-warning
:target: ../_images/cloning_3.png
Рисунок 30 — Запуск клонированной ВМ
7. В открывшемся окне заполните следующее:
- Вкладка 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
8. Нажмите кнопку "Launch as Instance".
Подключение к VM по SSH должно быть доступно для следующих username/password:
- ``ubuntu/123456``
- ``root/1234567``
Диски
^^^^^^
Создание и управление дисками
'''''''''''''''''''''''''''''
Для просмотра списка дисков на Портале необходимо в левом меню перейти в раздел Ресурсы → Диски. Пример вида раздела представлен на рисунке ниже.
.. figure:: Media/disks.png
:figclass: bg-warning
:target: ../_images/disks.png
Рисунок 31 — Пример списка дисков
**Создание диска**
Для создания диска на Портале администратора выполните следующие действия:
1. В левом меню Портала перейдите в раздел Ресурсы → Диски.
2. Нажмите кнопку "Создать диск".
3. Укажите имя и размер диска. Проект для диска можно изменить в выпадающем списке "Проект" вверху. Пример заполнения см. на рисунке ниже. Чтобы создать диск из снимка, перейдите на вкладку From snapshot и выберите один из доступных снимков в поле Snapshot.
4. Нажмите кнопку "Создать".
.. figure:: Media/new_disk.png
:figclass: bg-warning
:target: ../_images/new_disk.png
Рисунок 32 — Создание диска
**Рзменение параметров РґРёСЃРєР°**
Для внесения изменений в параметры диска выполните следующие действия:
1. В левом меню Портала перейдите в раздел Ресурсы → Диски.
2. Нажмите выпадающий список в столбце "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". Нажмите "Прикрепить".
.. + миграция между бэкэндами в пределах одного типа
.. figure:: Media/edit_disk.png
:figclass: bg-warning
:target: ../_images/edit_disk.png
Р РёСЃСѓРЅРѕРє 33 — Рзменение параметров РґРёСЃРєР°
Установка параметров QoS для типов дисков
''''''''''''''''''''''''''''''''''''''''''
Для работы с QoS на Портале администратора необходимо перейти в раздел Ресурсы → Volume Types в левом меню.
**Volume Types**
Типы томов необходимы для логического объединения дисков, включенных в определенный том.
По умолчанию Платформа использует тип томов ``__DEFAULT__``. Другие типы томов можно создавать на свое усмотрение. Прежде чем устанавливать параметры QoS, убедитесь, что созданы нужные типы томов. Для просмотра типов томов перейдите в раздел Ресурсы → Volume Types.
Для создания нового типа томов выполните следующие действия:
1. В левом меню Портала перейдите в раздел Ресурсы → Volume Types.
2. Нажмите кнопку "Создать volume type", расположенную рядом с таблицей **Volume Types**.
3. Введите РёРјСЏ Рё описание типа томов. Чтобы создать приватный тип, доступный только администраторам, снимите флажок для опции "is public". Рти параметры можно изменить позже для уже созданного типа. Для этого нажмите выпадающий СЃРїРёСЃРѕРє РІ столбце "Actions" Рё выберите "Edit".
4. Нажмите кнопку "Создать".
.. figure:: Media/new_volume_type.png
:figclass: bg-warning
:target: ../_images/new_volume_type.png
Рисунок 34 — Создание типа томов
**Quality of Service**
Quality of Service (QoS) для дисков и томов — это квоты на производительность. QoS регулируют параметры производительности оборудования.
Создавайте QoS, настраивайте их параметры и связывайте их с типами дисков в этом разделе. Таблица **Volume Types** выше отобразит QoS, связанные с типами томов, в столбце "associated qos".
Для создания нового QoS выполните следующие действия:
1. В левом меню Портала перейдите в раздел Ресурсы → Volume Types.
2. Нажмите кнопку "Создать QoS", расположенную рядом с таблицей **Quality of Service**.
3. Заполните РІСЃРµ поля. Рти параметры можно изменить позже, нажав выпадающий СЃРїРёСЃРѕРє РІ столбце "Actions" Рё выбрав "Update".
4. Нажмите кнопку "Создать".
.. figure:: Media/QoS.png
:figclass: bg-warning
:target: ../_images/QoS.png
Рисунок 35 — QoS
Для изменения QoS выполните следующие действия:
1. В разделе Ресурсы → Volume Types перейдите к таблице **Quality of Service**.
2. Нажмите выпадающий список в столбце "Actions" и выберите нужный пункт в зависимости от цели:
- Чтобы изменить значения параметров QoS, нажмите "Update". В открывшемся окне укажите новые значения для существующих параметров и нажмите "Применить".
- Если какие-либо параметры QoS еще не указаны, добавьте их с помощью "Add specs". В открывшемся окне заполните значения для новых параметров и нажмите "Применить".
- Чтобы удалить параметры у QoS, нажмите "Unset". Выберите один из параметров в открывшемся окне и нажмите "Удалить". Повторите для всех параметров, которые нужно удалить.
- Чтобы удалить QoS, нажмите "Delete". Подтвердите действие, нажав "Удалить".
- Чтобы привязать QoS к типу томов, выберите "Associate". В открывшемся окне выберите тип и нажмите "Применить". Повторите для всех типов, которые нужно привязать к QoS.
- Чтобы отвязать QoS от типа томов, выберите "Disassociate". В открывшемся окне выберите тип и нажмите "Применить".
- Чтобы отвязать QoS от всех типов томов, выберите "Disassociate all". Подтвердите действие, нажав "Применить".
Создание и управление снимками дисков
''''''''''''''''''''''''''''''''''''''
На Портале администратора вы можете создавать моментальные снимки дисков, чтобы сохранить данные виртуальных машин на этих дисках и в случае сбоя восстановить машины из этих снимков.
В данный момент технология создания таких снимков дисков поддерживается только для драйверов Huawei Dorado.
Для создания моментального снимка диска:
1. На вкладке Ресурсы → ВМ выберите виртуальную машину.
2. Нажмите выпадающий список в столбце "Actions" и выберите "Volume management", а затем "Create snapshot of boot volume".
3. В открывшемся окне укажите имя и название снимка ВМ. Чтобы добавить дополнительные параметры, нажмите ``+`` для "Extra specs". Нажмите "Создать".
.. figure:: Media/new_snapshot.png
:alt: new_snapshot
:figclass: bg-warning
:target: ../_images/new_snapshot.png
Рисунок 36 — Создание снимка диска
Чтобы откатить ВМ к моментальному снимку:
1. На вкладке Ресурсы → ВМ выберите виртуальную машину.
2. Нажмите выпадающий список в столбце "Actions" и выберите "Volume management", а затем "Revert boot volume to latest snapshot".
3. В открывшемся окне подтвердите действие. Нажмите "Откатить".
.. figure:: Media/snapshot.png
:alt: snapshot
:figclass: bg-warning
:target: ../_images/snapshot.png
Рисунок 37 — Восстановление ВМ из снимка
.. note::
Функция отката ВМ к моментальному снимку поддерживается не всеми СХД. В таком случае выдается ошибка ``400`` вида ``It is not possible to revert server <id> to the latest snapshot: unsupported volume backend type.``
Добавление новых вычислительных узлов
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1. Подготовьте описание серверов для Netbox. Подробнее о Netbox см. в разделе `Подсистема хранения данных о физических серверах Netbox <#netbox-subsystem>`__.
Для этого нужно добавить в Netbox (пароль можно посмотреть в Vault в разделе Accounts) ``https://netbox.<domain_name>/dcim/devices/`` новое устройство (см. рисунок ниже).
.. figure:: Media/netbox.png
:alt: netbox
:figclass: bg-warning
:target: ../_images/netbox.png
Рисунок 38 — Добавление нового устройства в Netbox
Затем необходимо заполнить поля:
- Name — имя сервера;
- Device role — Server;
- Device type — выбрать соответствующий тип;
- Site — выбрать соответствующий сайт, например, ks-region1;
- Status — Active;
- Tenant — выбрать тенант;
- Role — выбрать роль в выпадающем списке (controller, compute или network);
- Status — Ready.
После того как устройство будет добавлено, зайдите в него и добавьте сетевые интерфейсы аналогично тому, как изображено на рисунке ниже.
.. figure:: Media/net.png
:alt: net
:target: ../_images/net.png
Рисунок 39 — Добавление сетевых интерфейсов
2. Теперь можно устанавливать операционную систему. Для этого требуется запустить пайплайн ``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``.
3. Нужно добавить новый сервер в inventory соответствующего окружения в gitlab.domain_name в группу compute ``https://<gitlab_url>/project_k/deployments/stage1/-/blob/dev-stage1/inventory`` (пример для stage1).
4. Теперь можно запускать 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 на новый гипервизор.
5. Проверьте, что гипервизор функционирует, как ожидается — создаются виртуальные машины, работает миграция, работает сетевая связность — доступ по 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>``
Удаление вычислительного узла из кластера
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1. Удалите описание сервера из Netbox: `https://netbox.<domain_name>/dcim/devices/`
2. Удалите сервер из inventory из группы [compute]: `https://<gitlab_url>/project_k/deployments/stage1/-/blob/dev-stage1/inventory` (пример для stage1).
3. Далее следует удалить связанные сущности в 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).
.. figure:: Media/NTP.png
:alt: NTP
:figclass: bg-warning
:target: ../_images/NTP.png
Рисунок 40 — NTP Config
Для внесения изменений в файл конфигурации NTP нажмите кнопку "Edit". Можно добавлять, изменять и удалять следующие настройки:
- часовой пояс;
- пулы;
- серверы.
Флажок "Enabled" отображает статус файла конфигурации.
.. figure:: Media/NTP_edit.png
:alt: NTP_edit
:figclass: bg-warning
:target: ../_images/NTP_edit.png
Р РёСЃСѓРЅРѕРє 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``.
**Перевод вычислительного узла в режим обслуживания**
Для перевода узла в режим обслуживания необходимо выполнить следующие действия:
1. На Портале администратора перейдите в раздел Гипервизоры → Гипервизоры.
2. В выпадающем списке "Actions" для этого узла выберите действие "Enable maintenance mode". ВМ при таком состоянии продолжают работать на узле, а новые ВМ не могут быть запущены.
На рисунке ниже показан процесс перевода гипервизора в maintenance mode.
.. figure:: Media/MMode.png
:alt: MMode
:figclass: bg-warning
:target: ../_images/MMode.png
Рисунок 42 — Вычислительные узлы с возможностью отключения
3. Дождитесь, когда статус гипервизора сменится с ``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 выполните следующие действия:
1. Перейдите в раздел Гипервизоры → Агрегаты.
2. Посмотрите, какие агрегаты отмечены лейблом ``no HA``. Рти агрегаты РІС‹ сможете эвакуировать.
3. Переведите один или несколько агрегатов в режим HA:
- Чтобы эвакуировать конкретный агрегат, выберите "Enable evacuation" в выпадающем списке "Actions" для этого агрегата. На рисунке ниже приведен пример.
- Чтобы эвакуировать все агрегаты, нажмите кнопку "Enable Evacuation For All" вверху.
.. figure:: Media/aggregates.png
:alt: aggregates
:figclass: bg-warning
:target: ../_images/aggregates.png
Р РёСЃСѓРЅРѕРє 43 — Рвакуация агрегатов
4. Подтвердите действие, нажав "Включить" в открывшемся окне.
Для вывода агрегатов из режима HA повторите действия выше с тем отличием, что в выпадающем списке "Actions" нужно будет выбрать "Disable evacuation", а при выборе всех агрегатов — нажать кнопку "Disable Evacuation For All".
Фенсинг узлов (fencing)
^^^^^^^^^^^^^^^^^^^^^^^
Фенсинг узлов (гипервизоров) проводит HA. Фенсинг — механизм исключения неисправного узла из кластера, чтобы этот узел больше не работал с ВМ. После проведения фенсинга узлы могут оказаться в статусе "fenced", что будет отражено на Портале администратора. Такие узлы опознаются по префиксу ``FENCED: `` в ``disabled_reason``.
Чтобы вывести узлы из этого состояния, выполните следующие действия:
1. В левом меню Портала перейдите в раздел Гипервизоры → Гипервизоры.
2. Найдите в таблице узел, который выделен желтым цветом и обозначен лейблом "fenced".
3. В выпадающем списке "Actions" для этого узла выберите действие "Disable Fence Mode".
.. figure:: Media/fenced.png
:alt: fenced
:figclass: bg-warning
:target: ../_images/fenced.png
Рисунок 44 — Узел в статусе "fenced"
Подсистема передачи данных
~~~~~~~~~~~~~~~~~~~~~~~~~~
В Платформе используется топология сети с плоскими VLAN, часть параметров GRE / VXLAN не поддерживается.
Просмотр сетей
^^^^^^^^^^^^^^
| Для просмотра виртуальных сетей с помощью клиента Openstack CLI нужно выполнить следующую команду:
| ``openstack network list``
| Просмотр подсетей выполняется командой:
| ``openstack subnet pool list``
Вы также можете просматривать сети и их подсети на Портале администратора. Для этого в левом меню Портала перейдите в раздел Ресурсы → Сети.
Просмотр настроек виртуальной сети
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Для просмотра настроек виртуальной сети могут использоваться интерфейсы Портала администратора, Horizon или OpenStack CLI.
Для просмотра настроек виртуальной сети в Horizon необходимо выполнить следующие действия:
1. Перейдите в раздел Проект → Сети. Будет отображен список сетей, к которым имеет доступ данный проект.
.. figure:: Media/nets.png
:alt: nets
:figclass: bg-warning
:target: ../_images/nets.png
Рисунок 45 — Список сетей проекта
2. Перейдите в карточку виртуальной сети щелчком мыши по ее названию. Вид раздела настроек виртуальной сети представлен на рисунке ниже.
.. figure:: Media/nets2.png
:alt: nets2
:figclass: bg-warning
:target: ../_images/nets2.png
Рисунок 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> — наименование создаваемой сети.
Для создания сети на Портале администратора:
1. В левом меню Портала перейдите в раздел Ресурсы → Сети и нажмите кнопку "Создать сеть".
2. В открывшемся окне заполните поля. Обязательно нужно указать имя сети, CIDR и внешний ID. Поддерживаются разные типы сетей: FLAT, VLAN, VXLAN и GRE.
3. Когда все поля будут заполнены, нажмите кнопку "Создать".
.. figure:: Media/network.png
:alt: network
:figclass: bg-warning
:target: ../_images/network.png
Рисунок 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).
Создание балансировщика нагрузки
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Балансировщики проекта отображаются при переходе в левом меню в раздел Сеть → Балансировщики нагрузки.
.. figure:: Media/lb.png
:alt: lb
:figclass: bg-warning
:target: ../_images/lb.png
Рисунок 48 — Список балансировщиков проекта
Для запуска мастера создания балансировщика нажмите кнопку "Создать балансировщик нагрузки".
В окне мастера создания балансировщика укажите имя балансировщика, выберите сеть.
.. figure:: Media/newLb.png
:alt: newLb
:figclass: bg-warning
:target: ../_images/newLb.png
Рисунок 49 — Создание балансировщика
Добавьте информацию Рѕ слушателе — заполните поля "РРјСЏ", "Протокол" Рё "РџРѕСЂС‚" (СЃРј. СЂРёСЃСѓРЅРѕРє ниже).
.. figure:: Media/info.png
:alt: info
:figclass: bg-warning
:target: ../_images/info.png
Рисунок 50 — Заполнение информации о слушателе
Далее необходимо заполнить информацию о пуле (см. рисунок ниже).
.. figure:: Media/pool.png
:alt: pool
:figclass: bg-warning
:target: ../_images/pool.png
Рисунок 51 — Заполнение информации о пуле
В настоящий момент балансировщик поддерживает три основных алгоритма балансировки:
1. LEAST_CONNECTIONS. Учитывает количество подключений, поддерживаемых серверами в текущий момент времени. Каждый следующий запрос передается серверу с наименьшим количеством активных подключений.
2. ROUND_ROBIN. Представляет собой перебор по кругу: первый запрос передается первому серверу, затем следующий запрос передается второму — и так до достижения последнего сервера, а затем все начинается сначала.
3. SOURCE_IP. В этом методе сервер, обрабатывающий запрос, выбирается произвольным образом и закрепляется (на сессию, в cookies) за конкретным источником запроса.
Далее укажите Р’Рњ для балансировки. Ртот шаг необязательный, Рё его можно выполнить после создания балансировщика (СЃРј. СЂРёСЃСѓРЅРѕРє ниже).
.. figure:: Media/vmLb.png
:alt: vmLb
:figclass: bg-warning
:target: ../_images/vmLb.png
Рисунок 52 — Добавление ВМ балансироки
Настройте параметры интервалов проверки доступности (см. рисунок ниже).
.. figure:: Media/rule.png
:alt: rule
:figclass: bg-warning
:target: ../_images/rule.png
Рисунок 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``
Система запросит ключ, который требуется ввести.
Как безопасно хранить пароли
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Включение Castellan в регионе
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Castellan — это библиотека, предоставляющая собой общий интерфейс для хранения, генерации и извлечения секретов. Она используется большинством сервисов OpenStack для управления секретами. Как библиотека, Castellan сама по себе не предоставляет хранилище секретов. Вместо этого требуется развертывание реализации на стороне сервера.
С помощью интеграции данной библиотеки в oslo.config и соответствующей настройки Vault можно хранить пароли сервисов OpenStack в Vault вместо текстовых файлов.
Поддерживаются следующие сервисы:
- AdminUI
- Barbican
- Cinder
- Consul
- DRS
- Glance
- Horizon
- Keystone
- Neutron
- Nova
- Placement
Для настройки хранения паролей сервисов в Vault:
#. Перейдите в веб-интерфейс GitLab.
#. Перейдите в репозиторий вашего региона **project_k** → **deployments** → **<имя региона>**.
#. Создайте файл ``globals.d/castellan.yml``, в котором определите переменную ``services_with_castellan`` со списком сервисов, например:
::
services_with_castellan:
- drs
- cinder
- glance
- neutron
- nova
- nova_cell
- keystone
- adminui
- placement
- horizon
- barbican
- consul
#. Дополнительно задайте следующие настройки для аутентификации в Vault с соответствующими значениями:
* При аутентификации через AppRole::
castellan_vault_approle_role_id: ""
castellan_vault_approle_secret_id: ""
* При использовании Vault Enterprise и namespaces::
castellan_vault_namespace: ""
* При аутентификации через токен::
castellan_vault_root_token_id: ""
#. Запустите пайплайн **Run pipeline** по умолчанию. Дождитесь завершения этапа **setup-castellan**.
#. Продолжите развёртывание региона.
Для проверки настройки хранения паролей сервисов в Vault:
#. По очереди зайдита на узлы Control, Compute, Network и проверьте конфигурационные файлы соответствующих сервисов. Они не должны содержать пароли в открытом виде.
Хеширование паролей сервисов
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Пароли к некоторым сервисам можно хранить в хешированном виде.
Реализовано для HAProxy в части:
* OpenSearch
* Prometheus
Для настройки сокрытия паролей сервисов путём хеширования выполните следующие шаги:
#. Перейдите в веб-интерфейс GitLab.
#. Перейдите в репозиторий вашего региона **project_k** → **deployments** → **<имя региона>**.
#. Откройте файл ``globals.d/REGION.yml`` и добавьте в него переменную со списком необходимых сервисов::
services_with_hashed_password:
- opensearch
- prometheus
- rabbitmq
- proxysql
#. Запустите пайплайн **Run pipeline** по умолчанию. Дождитесь завершения этапа **setup-castellan**.
#. Продолжите развёртывание региона.
Для проверки сокрытия паролей сервисов путём хеширования выполните следующие шаги:
#. Зайдите на узлы Control и проверьте конфигурационные файлы сервисов, использующих хеширование паролей::
/etc/kolla/haproxy/services.d/opensearch-dashboards.cfg
/etc/kolla/rabbitmq/definitions.json
/etc/kolla/proxysql/users/<name_service>.yml
/etc/kolla/haproxy/services.d/prometheus-alertmanager.cfg
Все пароли должны отображаться в виде хешей SHA256.
Хранение паролей экспортеров Prometheus в Vault
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Для настройки хранения паролей экспортеров Prometheus в Vault выполните следующие действия:
#. Перейдите в веб-интерфейс GitLab.
#. Перейдите в репозиторий вашего региона **project_k** → **deployments** → **<имя региона>**.
#. Откройте файл ``globals.d/REGION.yml`` и добавьте в него строки::
prometheus_mysqld_exporter_use_vault: true
prometheus_rabbitmq_exporter_use_vault: true
prometheus_openstack_exporter_use_vault: true
#. Создайте новый пайплайн **Run pipeline**.
#. В переменной ``KOLLA_ARGS`` укажите значение ``-t prometheus`` для выполнения пайплайна только для компонента Prometheus.
#. Запустите пайплайн и дождитесь завершения этапа **deploy**.
Для проверки настройки хранения паролей экспортеров Prometheus в Vault выполните следующие шаги:
#. Зайдите на узлы Control и проверьте конфигурационные файлы экспортёров Prometheus::
/etc/kolla/prometheus-mysqld-exporter/my.cnf
/etc/kolla/prometheus-rabbitmq-exporter/prometheus-rabbitmq-config.json
/etc/kolla/prometheus-openstack-exporter/clouds.yml
В файлах должны присутствовать строки с настройками доступа к Vault и не должно быть паролей в открытом виде.
Защита паролей в MariaDB, Redis, Grafana
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Для настройки хранения паролей MariaDB, Redis и Grafana в Vault выполните следующие действия:
#. Перейдите в веб-интерфейс GitLab.
#. Перейдите в репозиторий вашего региона **project_k** → **deployments** → **<имя региона>**.
#. Откройте файл ``globals.d/REGION.yml`` и добавьте в него строки, указав в переменной ``vault_addr`` URL с полным доменным именем сервиса Vault::
enable_vault_agent: "yes"
vault_approle_role_id: "{{ castellan_vault_approle_role_id }}"
vault_approle_secret_id: "{{ castellan_vault_approle_secret_id }}"
vault_region: "{{ OPENSTACK_ENV }}"
vault_region_pass: "passwords_yml"
vault_addr: "https://vault.itkey.com"
#. Создайте новый пайплайн **Run pipeline**.
#. В переменной ``KOLLA_ARGS`` укажите значение ``-t mariadb,redis,grafana`` для выполнения пайплайна только для этих компонентов.
#. Запустите пайплайн и дождитесь завершения этапа **deploy**.
Для проверки настройки хранения паролей MariaDB, Redis и Grafana в Vault выполните следующие шаги:
#. Зайдите на узлы Control и проверьте конфигурационные файлы этих сервисов::
/etc/kolla/mariadb/galera.cnf
/etc/kolla/mariabackup/my.cnf
/etc/kolla/redis/redis.conf
/etc/kolla/redis-sentinel/redis.conf
/etc/kolla/grafana/grafana.ini
В файлах должны присутствовать строки с настройками доступа к Vault и не должно быть паролей в открытом виде.
Переключение аутентификации libvirt с SASL на TLS
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Для переключения аутентификации libvirt с SASL на TLS выполните следующие действия:
#. Зайдите на каждый Compute-узел по SSH и удалите старые конфигурационные файлы::
# rm /etc/kolla/nova-libvirt/auth.conf
# rm /etc/kolla/nova-compute/auth.conf
#. Перейдите в веб-интерфейс GitLab.
#. Перейдите в репозиторий вашего региона **project_k** → **deployments** → **<имя региона>**.
#. Откройте файл ``globals.d/REGION.yml`` и добавьте в него строки::
libvirt_enable_sasl: false
libvirt_tls: "yes"
#. Перейдите в репозиторий **project_k** → **deployments** → **gen-pwd**.
#. Создайте новый пайплайн **Run pipeline**.
#. В переменной ``OPENSTACK_ENV`` укажите имя вашего региона.
#. Запустите пайплайн Run и дождитесь его завершения.
#. Перейдите в репозиторий вашего региона **project_k** → **deployments** → **<имя региона>**.
#. В переменной ``KOLLA_ARGS`` укажите значение ``-t nova`` для выполнения пайплайна только для компонента Nova.
#. Запустите пайплайн и дождитесь завершения этапа **deploy**.
Для проверки аутентификации libvirt с TLS выполните следующие действия на каждом Compute-узле:
#. Проверьте отсутствие файлов ``/etc/kolla/nova-libvirt/auth.conf`` и ``/etc/kolla/nova-compute/auth.conf``.
#. Проверьте, что в конфигурационном файле ``/etc/kolla/nova-libvirt/libvirtd.conf`` включена опция ``listen_tls`` и присутствуют строки с сертификатами TLS.
Механизм внешних плагинов
~~~~~~~~~~~~~~~~~~~~~~~~~
Пользовательские 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 <https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_reuse_roles.html>`_.
В созданной директории создайте 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 поставляется без преднастроенных панелей.
| Предполагается, что администраторы кастомизируют панели под бизнес-задачи.
Создание пользовательских панелей с использованием различных виджетов и визуализаций
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Процесс создания дашборда включает следующие этапы:
1. Выбор источника данных: происходит определение источника данных из OpenSearch для визуализации.
2. Добавление визуализаций: выбор и настройка виджетов и визуализаций для отображения данных.
3. Конфигурация фильтров: применение фильтров для уточнения отображаемых данных.
4. Определение компоновки: размещение визуализаций на дашборде с учетом их взаимодействия.
5. Сохранение и публикация: сохранение созданного дашборда и возможность его публикации для общего доступа.
.. figure:: Media/opensearch_new_dashboard_ui.png
:figclass: bg-warning
:target: ../_images/opensearch_new_dashboard_ui.png
Рисунок 54 — Создание пользовательской панели. Выбор визуализации
.. figure:: Media/opensearch_new_dashboard_ui_2.png
:figclass: bg-warning
:target: ../_images/opensearch_new_dashboard_ui_2.png
Рисунок 55 — Создание пользовательской панели. Применение фильтров
.. figure:: Media/opensearch_new_dashboard_ui_3.png
:figclass: bg-warning
:target: ../_images/opensearch_new_dashboard_ui_3.png
Рисунок 56 — Создание пользовательской панеи. Размещение визуализации
Подробнее о работе с OpenSearch Dashboards см. в документации `OpenSearch Dashboards <https://opensearch.org/docs/latest/dashboards/index/>`__.
Добавление нового output для сборщика логов
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Если требуется сбор логов в дополнительный output, необходимо выполнить следующие действия:
1. В репозитории региона в директории ``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>
2. Далее в интерфейсе Gitlab в репозитории региона запустите выполнение пайплайна с тегом ``common`` и лимитом на мастер-узлы:
::
`-t common --limit control`
.. figure:: Media/gitlab-run-pipeline-with-arg.png
:figclass: bg-warning
:target: ../_images/gitlab-run-pipeline-with-arg.png
Рисунок 57 — Запуск пайплайна с нужным тегом
3. Нажмите "Run Pipeline".
Создание шаблона индексов в OpenSearch
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| Для этого нужно перейти на страницу ``https://opensearch.<domain_name>``.
| Данная страница при первом входе сразу направит нас на страницу создания шаблонов.
| Далее необходимо выполнить следующие действия:
1. Нажмите кнопку "Create index patern".
2. В появившемся окне в поле "index patern name" укажите flog\* и нажмите "Next Step".
3. Далее в поле "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писок служб подсистем и соответствующие им лог-файлы
.. list-table::
:header-rows: 1
* - Служба
- Расположение файла
- Тип узла
* - **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 |br|
/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 |br|
/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 |br|
/var/log/kolla/horizon/horizon-access.log
- Управляющий узел
* - **Heat**
-
-
* - heat-api
- /var/log/kolla/heat/heat-api.log |br|
/var/log/kolla/heat/heat-api-cfn.log |br|
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) и др., а также комбинировать любые требуемые фильтры.
.. figure:: Media/audit.png
:alt: audit
:figclass: bg-warning
:target: ../_images/audit.png
Рисунок 58 — Фильтры событий аудита
Настройка дополнительного приемника журналов KeyStack в формате syslog
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Для вывода логов в удаленный сервис системного журнала (syslog) используется `fluent-plugin-remote_syslog <https://github.com/fluent-plugins-nursery/fluent-plugin-remote_syslog>`__ — плагин `Fluentd <http://fluentd.org>`__.
При работе с данным плагином необходимо выполнить следующие действия:
1. В репозитории региона `https://<gitlab_url>/project_k/deployments/<region_name>/config` создать файл ``fluentd/output/fluent-plugin-remote_syslog.conf``.
2. Файл будет иметь следующее содержание (при этом нужно заменить значения на свои):
::
<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**
Copyright (c) 2014-2017 Richard Lee. Copyright (c) 2022 Daijiro Fukuda.
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.
.. _components-deployment:
Деплой компонентов
^^^^^^^^^^^^^^^^^^
Для запуска деплоя какого-либо компонента запустите пайплайн из репозитория соответствующего окружения и укажите тег нужного компонента и лимит при необходимости.
Открыть страницу ``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>``.
.. figure:: Media/pipeline.png
:alt: pipeline
:figclass: bg-warning
:target: ../_images/pipeline.png
Рисунок 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:
1. Получите список L3-агентов и их идентификаторы:
``openstack network agent list --agent-type l3``
2. Выключите L3-агент на том узле, на который планируется внести изменения:
``openstack network agent set --disable <l3_agent_uuid>``
3. Подождите 5 минут.
4. Запустите пайлайн с тегом neutron и лимитом на тот сервер, на котором выключен L3-агент:
.. figure:: Media/params.png
:alt: params
:figclass: bg-warning
:target: ../_images/params.png
Рисунок 60 — Параметры запуска пайплайна
``openstack network agent set --enable <l3_agent_uuid>``
5. Подождите 30 минут, отслеживая сообщения в логах ``/var/log/kolla/neutron/neutron-l3-agent.log`` (в логах дождаться окончания синков на сотни секунд).
6. Повторите итерацию для каждого L3-агента (для каждого узла с ролью network).
Двухфакторная аутентификация(2FA)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
В KeyStack в качестве второго фактора используется пара сертификат/ключ для защиты аккаунта.
На первом этапе аутентификации пользователь указывает свой сертификат и ключ, на втором — имя пользователя и пароль от своей учетной записи.
Включение двухфакторной аутентификации (2FA)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1. Добавьте параметры в globals и файлы конфигурации региона:
::
kolla_enable_mtls_external: yes
2. Выполните деплой тега haproxy. Подробнее о запуске деплоя см. в разделе `Деплой компонентов <#components-deployment>`__.
Отключение двухфакторной аутентификации (2FA)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1. Рзмените параметры РІ globals Рё файлы конфигурации региона:
::
kolla_enable_mtls_external: no
2. Выполните деплой тега haproxy. Подробнее о запуске деплоя см. в разделе `Деплой компонентов <#components-deployment>`__.
Сертификат клиента для использования c 2FA
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Клиентский сертификат должен содержать следущий атрибуты:
1. Клиентский сертификат подписан центром сертификации, выпускающим сертификаты для региона Keystack.
2. Заданы назначения сертификата (OID):
- Проверка подлинности сервера (1.3.6.1.5.5.7.3.1)
- Проверка подлинности клиента (1.3.6.1.5.5.7.3.2)
3. Задан 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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1. Сохраните созданный сертификат, ключ и рутовый сертификат в операционную систему 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-integration:
Рнтеграция OpenStack СЃ LDAP
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Настройка данной интеграции состоит из нескольких частей:
1. | Создайте домен. Для этого при помощи OpenStack CLI выполните команду создания домена:
| ``openstack domain create ldap``, где ldap — это имя добавляемого домена (оно должно быть указано также в globals и участвовать в имени файла конфигурации для Keystone).
2. Добавьте параметры в 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​
3. При интеграции по ldaps протоколу, добавьте цепочку из рутовых и промежуточных сертификатов в файл ``certificates/ca/ca-bundle.crt``
4. Поместить пароль пользователя ``YOUR_SERVICE_USER_DN`` в Vault в файл паролей региона ``deployments/<regionname>/passwords_yml`` в поле ldap_password.
5. Выполните деплой тегов keystone и horizon. Подробнее о запуске деплоя см. в разделе `Деплой компонентов <#components-deployment>`__.
6. Проверьте, что видно пользователей и группы LDAP в Keystack в Openstack CLI:
::
# openstack user list --domain ldap
+------------------------------------------------------------------+----------------+
| ID | Name |
+------------------------------------------------------------------+----------------+
| f82090b43940df5f7b8e77fb5e4ddaf04e60cecebc5e94dd63a5e0f53f219fe5 | user1 |
+------------------------------------------------------------------+----------------+
# openstack group list --domain ldap
+------------------------------------------------------------------+--------+
| ID | Name |
+------------------------------------------------------------------+--------+
| ec6d01371e3160ab417c404fa07828a2e4c2d2e3147b762f9cf6f3555a601280 | group1 |
+------------------------------------------------------------------+--------+
7. Создайте проект в Openstack CLI или с помощью интерфейса Horizon:
::
openstack project create demo --domain ldap
8. Добавьте пользователей или группы в проект 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
~~~~~~~~~~~~~~~~~~~~~~~~~
Настройка данной интеграции состоит из нескольких частей:
1. При интеграции по протоколу LDAPs добавьте цепочку из рутовых и промежуточных сертификатов в файл ``certificates/ca/ca-bundle.crt``.
2. Поместите пароль пользователя ``YOUR_SERVICE_USER_DN`` в Vault в файл паролей региона ``deployments/<regionname>/passwords_yml`` в поле "ldap_password".
3. Создайте файл ``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"
4. Выполните деплой тега grafana. Подробнее о запуске деплоя см. в разделе `Деплой компонентов <#components-deployment>`__.
Рнтеграция OpenSearch СЃ LDAP
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Настройка данной интеграции состоит из нескольких частей:
1. При интеграции по протоколу LDAPs добавьте цепочку из рутовых и промежуточных сертификатов в файл ``certificates/ca/ca-bundle.crt``.
2. Поместите пароль пользователя ``YOUR_SERVICE_USER_DN`` в Vault в файл паролей региона ``deployments/<regionname>/passwords_yml`` в поле "ldap_password".
3. Создайте файл ``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"
4. Создайте новый файл ``config\opensearch\roles_mapping.yml`` с содержимым:
::
all_access:
backend_roles:
- "YOUR_ADMIN_GROUP"
readall:
backend_roles:
- "YOUR_READ_GROUP"
5. Выполните деплой тегов common и opensearch. Подробнее о запуске деплоя см. в разделе `Деплой компонентов <#components-deployment>`__.
Подсистема резервного копирования
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Реализовано резервное копирование данных LCM узла и баз данных для регионов Openstack. Резервные копии баз данных регионов шифруются алгоритмом AES-256 с использованием PBKDF2 для усиления безопасности ключа.
1. Резервное копирование LCM осуществляется через запуск запланированного задания в Gitlab из репозитория: ``https://<gtilab_url>/project_k/Deployments/backup``.
.. figure:: Media/copy.png
:alt: copy
:figclass: bg-warning
:target: ../_images/copy.png
Рисунок 61 — Резервное копирование LCM
Кроме того, выполнить резервное копирование LCM можно, запустив скрипт ``backupLCM.sh`` (находится в директории с инсталлятором).
Р’ результате выполнения скрипта ``backupLCM.sh`` РІ директории ``/installer/backup`` создается архив СЃ именем РІ формате ``backupLCM-31-08-2022-1661925161.tar.gz``. Ртот файл требуется скопировать РІ надежное хранилище данных.
2. Резервное копирования баз данных регионов Openstack осуществляется через запуск запланированного задания из соответствующего региону репозитория: https://<gitlab.domain_name> project_k/Deployments//-/pipeline_schedules.
.. figure:: Media/copyDb.png
:alt: copyDb
:figclass: bg-warning
:target: ../_images/copyDb.png
Рисунок 62 — Резервное копирование баз данных регионов Openstack
Восстановление LCM из резервной копии
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Восстановление осуществляется путем запуска скрипта ``restoreLCM.sh``.
Для запуска скрипта восстановления LCM необходимо положить резервную копию LCM с именем в формате ``backupLCM-31-08-2022-1661925161.tar.gz`` в ту же директорию рядом с ним, после чего запустить скрипт.
Восстановление базы данных регионов Openstack из резервной копии
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
За помощью в восстановлении баз данных регионов Openstack следует обратиться к вендору.
Подсистема хранения данных о физических серверах Netbox
-------------------------------------------------------
Netbox — компонент в составе инсталлятора, размещенный на LCM-узле. Данный сервис включен в базовую последовательность установку продукта. Netbox предоставляет собой веб-интерфейс для хранения и внесения информации о серверах, сетевых интерфейсах и других данных, которые будут использоваться при автоматизированной установке и настройке операционной системы для серверов.
Пользовательский веб-интерфейс доступен по адресу ``https://netbox.<domain_name>``.
.. figure:: Media/netbox_interface.png
:alt: netbox_interface
:figclass: bg-warning
:target: ../_images/netbox_interface.png
Р РёСЃСѓРЅРѕРє 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 — это процесс переключения на резервный узел при отказе активного узла.
1. На сервере, пережившем 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.
4. Если ошибки 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 всех управляющих узлов
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Восстановите Galera cluster.
2. Откройте страницу ``https://<LCM_URL>/project_k/deployments/<REGION>/-/pipelines`` → Run Pipeline.
``KOLLA_ANSIBLE_DEPLOY_ACTION – mariadb_recovery``
Дождитесь выполнения пайплайна и убедитесь, что работа сервисов восстановлена.
2. Перезапустите все контейнеры, кроме MariaDB и RabbitMQ.
3. Перезапустите контейнеры Openstack на узлах Compute.
Failover вычислительного узла
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
На сервере, пережившем failover, выполните следующие проверки:
1. Проверьте состояние контейнеров nova_compute на вычислительном узле. Выполните команду на вычислительном узле:
``docker ps -a | grep -i nova_compute``
Убедитесь, что контейнер nova_compute находится в состоянии ``Up``.
2. На вычислительном узле проверьте лог ``/var/log/kolla/nova/nova-compute.log`` на отсутствие событий ``ERROR`` или ``Traceback``.
3. При их наличии убедитесь, что на вычислительном узле нет запущенных ВМ. Для этого на LCM-узле (или любом узле с установленным клиентом OpenStack CLI) выполните команду :
``openstack server list --all --long | grep $(имя вычислительного узла)``
4. Если команда вернула информацию о каких-либо виртуальных машинах, тогда следует удалить их в контейнере ``nova_libvirt`` на вычислительном узле. Для этого для каждой ВМ:
#. Получите имя ВМ в среде libvirt, для этого выполните команду:
``openstack server show ${vmuuid} -c "OS-EXT-SRV-ATTR:instance_name" -f value``
#. Зайдите на вычислительный узел и выполните команду:
``docker exec nova_libvirt virsh undefine ${vm_name}``
5. Включите вычислительный узел. Для этого на LCM-узле (или любом узле с установленным клиентом OpenStack CLI) выполните команду:
``openstack compute service set --enable ${имя_вычислительного_узла} nova-compute``
Успешное выполнение приведенного выше сценария зависит от следующих факторов:
- Выход вычислительного узла из строя не связан с выходом из строя SDS (Ceph).
- Образы ВМ, работавших на этом вычислительном узле, находятся в консистентном состоянии.
- Образы ВМ, работавших на этом вычислительном узле, корректно эвакуировались с вычислительного узла.
Рекомендации по освоению
------------------------
Openstack CLI: https://docs.openstack.org/python-openstackclient/latest/index.html
Docker: https://docs.docker.com/engine/reference/commandline/docker/.
Рнтеграция СЃ LDAP: https://docs.openstack.org/keystone/pike/admin/identity-integrate-with-ldap.html
Термины и сокращения
--------------------
Термины
~~~~~~~
+--------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Термин | Определение |
+======================================+===============================================================================================================================================================================================================================================================================================================+
| Мониторинг платформы | Программные решения для мониторинга общего состояния Платформы динамической инфраструктуры. |
+--------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Мониторинг сервисов | Программные решения для мониторинга сервисов 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 (Время жизни) |
+-----------------------------------+------------------------------------------------------------------------------------------------------------------------+
| ВМ | Виртуальная машина |
+-----------------------------------+------------------------------------------------------------------------------------------------------------------------+
| ВУ | Вычислительный узел |
+-----------------------------------+------------------------------------------------------------------------------------------------------------------------+
| РР‘ | Рнформационная безопасность |
+-----------------------------------+------------------------------------------------------------------------------------------------------------------------+
| КЕ | Конфигурационная единица |
+-----------------------------------+------------------------------------------------------------------------------------------------------------------------+
| КСПД | Корпоративная сеть передачи данных |
+-----------------------------------+------------------------------------------------------------------------------------------------------------------------+
| ОС | Операционная система |
+-----------------------------------+------------------------------------------------------------------------------------------------------------------------+
| ПВР| Подсистема вычислительных ресурсов |
+-----------------------------------+------------------------------------------------------------------------------------------------------------------------+
| ПО | Программное обеспечение |
+-----------------------------------+------------------------------------------------------------------------------------------------------------------------+
| ППД | Подсистема передачи данных |
+-----------------------------------+------------------------------------------------------------------------------------------------------------------------+
| ППО | Прикладное программное обеспечение |
+-----------------------------------+------------------------------------------------------------------------------------------------------------------------+
| СПО | Системное программное обеспечение |
+-----------------------------------+------------------------------------------------------------------------------------------------------------------------+
| СУБД | Система управления базами данных |
+-----------------------------------+------------------------------------------------------------------------------------------------------------------------+
| СХД | Система хранения данных |
+-----------------------------------+------------------------------------------------------------------------------------------------------------------------+
| ЦОД | Центр обработки данных |
+-----------------------------------+------------------------------------------------------------------------------------------------------------------------+
| ЧТЗ | Частное техническое задание |
+-----------------------------------+------------------------------------------------------------------------------------------------------------------------+
| УЗ | Учетная запись |
+-----------------------------------+------------------------------------------------------------------------------------------------------------------------+
.. |br| raw:: html
<br>