Сопровождение облака и управление ресурсами

Создание первоначальных ресурсов в OpenStack

Через dctl можно создать первоначальные ресурсы в OpenStack. Для этого используется команда cloud prepare.

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

  1. Ключ SSH undercloud_key для пользователя admin

  2. Группу безопасности ssh_access с разрешением на доступ по SSH и ICMP

  3. Набор публичных типов инстансов, если указан параметр --flavors.

  4. Образы виртуальных машин, если они указаны в параметре --images.

  5. Публичная сеть для назначения плавающих IP-адресов, если указан параметр --public-network.

  6. Приватная сеть с типом geneve для создания виртуальных машин в проекте admin, если указан параметр --public-network.

  7. Маршрутизатор, если указано в параметре --public-network.

Параметры можно указывать в виде JSON или в виде строки k1=v1,k2=v2....

Примеры:

  1. Параметр flavors в виде JSON:

    dctl cloud prepare moncloud --flavors '{"max_multiplier": 8, "disk_sfx": "ssd"}'
    
  2. Параметр flavors в виде строки:

    dctl cloud prepare moncloud --flavors max_multiplier=8,disk_sfx=ssd
    

    Имена типов инстансов строятся по шаблону cpu<cpu_num>.ram<ram_gb>.<disk_sfx><disk_gb>. Имена параметризуются только в рамках параметра disk_sfx, который равен disk по умолчанию.

    Подсказка

    Замените disk_sfx на hdd или ssd, если на узлах компьютах для ВМ настроены SSD или HDD диски.

    Число созданных типов инстансов зависит от параметра max_multiplier. Для значения max_multiplier=4 будут созданы публичные типы инстансов:

    • простые: cpu1.ram1.disk50, cpu2.ram2.disk100, cpu4.ram4.disk200;

    • с повышенными ресурсами: cpu2.ram8.disk50, cpu4.ram32.disk100, cpu8.ram64.disk200.

  3. Параметр images с несколькими путями:

    dctl cloud prepare moncloud --images /home/stack/images/image1.qcow2 /home/stack/images/image2.qcow2
    

Подсказка

Образы необходимо подготовить заранее самостоятельно и сложить в каталог, например, /home/stack/images.

  1. Параметр public-network в виде JSON:

    dctl cloud prepare moncloud --public-network '{"vlan_id": 100, "cidr": "10.10.10.10/24", "gateway": "10.10.10.254"}'
    
  2. Параметр public-network в виде строки:

    dctl cloud prepare moncloud --public-network vlan_id=100,cidr=10.10.10.10/24,gateway=10.10.10.254
    
  3. Параметр flavors с указанием extra_specs для PCI-ресурсов, например, для GPU:

    dctl cloud prepare moncloud --flavors disk_sfx=ssd,extra_specs='{"pci_passthrough:alias": "ga102gl:1"}'
    

Подсказка

Команду можно запускать несколько раз для добавления новых ресурсов. Ресурсы, которые уже были созданы при предыдущем запуске, будут пропущены, и команда продолжит выполнение для остальных ресурсов:

dctl cloud prepare moncloud --images /home/stack/new_images

Мониторинг

После установки облака будет доступна Grafana по адресу облака на порту 3000.

Доступ к API облака

После развёртывания облака на узле развёртывания появляется файл <deployment-name>rc.

Для управления ресурсами через CLI выполните:

source <deployment-name>rc

Например:

source moncloudrc

Обратите внимание, что управление ресурсами развёрнутого облака на узле развёртывания также требует предварительного source stackrc с того же узла.

Файл <deployment-name>rc содержит переменные окружения, где указывается адрес сервиса аутентификации Keystone и учётные данные для пользователя admin.

Чтобы посмотреть IP-адрес для вашего облака выполните:

dctl instance show <deployment-name>

Например:

dctl instance show moncloud

Web-доступ к управлению облаком также доступен по указанному адресу.

Типы инстансов

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

openstack flavor create cpu<cpu_num>.ram<ram_gb>.disk<disk_gb> \
   --vcpus <cpu_num> \
   --ram <ram_mb> \
   --disk <disk_gb>

Примечание

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

Если на узлах был настроен GPU, то для создания типа инстанса с поддержкой GPU используется команда:

openstack flavor create --private \
 gpu-<gpu_alias>-x<gpu_num>.cpu<cpu_num>.ram<ram_gb>.disk<disk_gb> \
 --property pci_passthrough:alias='<gpu_alias>:<gpu_num>'

Назначение признаков узлам

Чтобы поделить узлы по признаку SSD/HDD или с/без GPU - существует механизм trait’ов.

Посмотреть их можно для конкретного узла через Placement API:

openstack resource provider trait list <resource_provider_uuid>

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

openstack trait list --sort-column name

Из интересных существующих trait’ов есть STORAGE_DISK_HDD/STORAGE_DISK_SSD - но они не назначаются узлам автоматически. Для этого используется команда:

openstack resource provider trait set --trait <trait_name> \
 <resource_provider_uuid>

Чтобы использовать свой trait, можно использовать команды:

openstack trait create CUSTOM_HAS_GPU
openstack resource provider trait set --trait CUSTOM_HAS_GPU \
 <resource_provider_with_gpu>

Далее запрещаем типу инстанса без GPU занимать узлы с GPU:

openstack flavor set cpu1.ram1.hdd10 --property trait:CUSTOM_HAS_GPU=forbidden

Или наоборот:

openstack flavor set cpu1.ram1.hdd10 --property trait:STORAGE_DISK_HDD=required

Физические сети

Если на узлах были настроены интерфейсы, то для создания сети с поддержкой SR-IOV или проброса интерфейсов необходимо указать физическую сеть, совпадающую с той, что была настроена на узлах в поле Physical Network Name:

openstack network create --provider-physical-network <physnet_name> \
 --provider-network-type [vlan/flat] <network_name>

В таких сетях можно создавать порты с пробросом физических интерфейсов:

openstack port create --network <network_name> \
 --vnic-type direct-physical <port_name>

или виртуальных функций SR-IOV:

openstack port create --network <network_name> --vnic-type direct <port_name>

Важно

Для таких портов работает облачный DHCP, только в случае выполнения любого из условий:

  1. physnet_name сети совпадает с datacentre,

  2. для физического интерфейса при развёртывании был выбран режим SR-IOV + Switchdev (ASAP^2/Truflow).

В случае, если оба условия не соблюдаются, для портов этого типа требуется использовать статические IP-адреса одним из способов:

  1. создайте виртуальную машину с обычным портом в сети с поддержкой DHCP и добавьте вторым портом интерфейс без DHCP,

4. зайдите в виртуальную машину и настройте статический IP-адрес для второго интерфейса вручную, например, через ip addr и ip route. Используйте IP-адрес, назначенный облаком для второго интерфейса.

или

5. заведите вручную DHCP-сервер для портов без DHCP за пределами облачных серверов или на отдельной виртуальной машине в облаке. Неудобство такого способа в том, что в интерфейсе управления облаком будут отображаться IP-адреса, отличные от фактических, назначенных DHCP-сервером.