OpenStack* Enhanced Platform Awareness

Что это такое и как это можно использовать для повышения производительности NFV?

Обзор

Enhanced Platform Awareness (EPA) — это принцип, опирающийся на набор функций OpenStack Nova*, которые называются пакетами хостов и зонами доступности. Для ознакомления с EPA прочтите документ OpenStack* Enhanced Platform Awareness — Enabling Virtual Machines to Automatically Take Advantage of Advanced Hardware Capabilities(https://01.org/sites/default/files/page/openstack-epa_wp_fin.pdf).

Планировщик Nova использует пакеты хостов и зоны доступности, чтобы определить, на каком хосте следует запускать виртуальную машину. Этот выбор производится в зависимости от возможностей хоста и затребованной функциональности виртуальной машины (ВМ). Большая часть этих функций появилась в выпуске Grizzly, а в выпуске Kilo была доработана до набора фильтров и весов, которые используются планировщиком Nova для определения необходимости развертывания ВМ. Пример реализации NFV см. на портале Intel® Network Builders в документе A Path to Line-Rate-Capable NFV Deployments with Intel® Architecture and the OpenStack* Kilo Release.

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

Архитектура OpenStack

В архитектуре OpenStack наибольшее значение имеет компонент Nova*. Кроме того, мы вкратце рассмотрим использование Glance для упрощения настройки в будущем.

Разновидности, атрибуты фильтров и дополнительные спецификации

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

INSTANCE_ID = “c32ac737-1788-4420-b200-2a107d5ad335”
nova boot --flavor 2 --image $INSTANCE_ID testinstance

В этом примере flavor 2 — это шаблон разновидности с именем m1.bigger, содержащий следующее:

  • 1 виртуальный ЦП;
  • 2 ГБ оперативной памяти;
  • 10 ГБ рутового диска;
  • 20 ГБ временного диска.

Управление разновидностями

Разновидность — это тип гостевого экземпляра или шаблона виртуального оборудования. Разновидность задает набор ресурсов ВМ, в том числе количество виртуальных ЦП, объем памяти и место на диске, выделяемое экземпляру ВМ. Пример разновидности экземпляра: зона ядра с 16 виртуальными ЦП и 16 384 МБ оперативной памяти.

Дополнительные сведения

Корпорация IBM представила атрибуты дополнительных спецификаций для некоторых своих решений в этом примере
(http://www-01.ibm.com/support/knowledgecenter/SST55W_4.3.0/liaca/liacaflavorextraspecs.html)

Дополнительные спецификации

Разновидность может включать не только базовые, но и дополнительные свойства. Эти дополнительные спецификации представляют собой пары «параметр — значение», их можно использовать для расширенной настройки в дополнение к настройке, предоставляемой базовыми свойствами разновидности. Эта настройка зависит от гипервизора.

Расширенная настройка, предоставляемая дополнительными спецификациями разновидности, может включать следующее. Обратите внимание, что все пары «параметр — значение», присоединенные к полю дополнительной спецификации, предназначены для фильтров планировщика.

Настройка ограничения операций ввода-вывода для заданного типа экземпляра
nova-manage flavor set_key --name m1.small --key quota:disk_read_bytes_sec --value 10240000
nova-manage flavor set_key --name m1.small --key quota:disk_write_bytes_sec --value 10240000

Настройка ограничения ЦП для заданного типа экземпляра
nova-manage flavor set_key --name m1.small --key quota:cpu_quota --value 5000
nova-manage flavor set_key --name m1.small --key quota:cpu_period --value 2500

Настройка ограничения пропускной способности для сетевого трафика экземпляра
nova-manage flavor set_key --name m1.small --key quota:vif_inboud_average --value 10240
nova-manage flavor set_key --name m1.small --key quota:vif_outboud_average --value 10240

Дополнительные сведения

OpenStack. Введение в разновидности образов: http://docs.openstack.org/openstack-ops/content/flavors.html

Изменение спецификаций разновидностей (из документа Установка и настройка OpenStack в Oracle®Solaris 11.2 корпорации Oracle): http://docs.orack-aggregate1le.com/cd/E36784_01/html/E54155/flavoredit.html

«Набираем скорость: закрепление ЦП и топология NUMA в OpenStack», Стив Гордон, старший технический менеджер по продуктам, корпорация Red Hat: http://redhatstackblog.redhat.com/2015/05/05/cpu-pinning-and-numa-topology-awareness-in-openstack-compute/

Дополнительные спецификации и пространства имен

extra_specs — дополнительное свойство, содержащее пары «параметр — значение». Если параметр extra specs содержит двоеточие (:), то все перед двоеточием считается пространством имен, а все после двоеточия считается параметром, с которым производится сравнение.

Вот пример параметра без указания области.

nova flavor-key 1 set capabilities:vcpus='>= 6'
nova flavor-key 1 set capabilities:vcpus_used='== 0'
nova flavor-show 1

+----------------------------+-----------------------------------------------------------------------+  
| Property                   | Value                                                                 |  
+----------------------------+-----------------------------------------------------------------------+  
| OS-FLV-DISABLED:disabled   | False                                                                 |  
| OS-FLV-EXT-DATA:ephemeral  | 0                                                                     |  
| disk                       | 0                                                                     |  
| extra_specs                | {u'capabilities:vcpus': u'>= 6', u:capabilities:vcpus_used': u'== 0'} |   
| id                         | 1                                                                     |  
| name                       | m1.tiny                                                               |  
| os-flavor-access:is_public | True                                                                  |  
| ram                        | 512                                                                   |  
| rxtx_factor                | 1.0                                                                   |  
| swap                       |                                                                       |  
| vcpus                      | 1                                                                     |  
+----------------------------+-----------------------------------------------------------------------+  

extra_specs полезно использовать при включении нескольких фильтров, чтобы избежать конфликтов.

Стратегии фильтрации

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

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

RamFilter

В документации для разработчиков OpenStack простота фильтров подчеркивается на примере RamFilter (https://github.com/openstack/nova/blob/master/nova/scheduler/filters/exact_ram_filter.py). Этот фильтр запрашивает точный объем памяти, необходимый для запуска гостевого образа.

class ExactRamFilter(filters.BaseHostFilter):
    """Exact RAM Filter."""

    def host_passes(self, host_state, filter_properties):
        """Return True if host has the exact amount of RAM available."""
        instance_type = filter_properties.get('instance_type')
        requested_ram = instance_type['memory_mb']
        if requested_ram != host_state.free_ram_mb:
            LOG.debug("%(host_state)s does not have exactly "
                      "%(requested_ram)s MB usable RAM, it has "
                      "%(usable_ram)s.",
                      {'host_state': host_state,
                       'requested_ram': requested_ram,
                       'usable_ram': host_state.free_ram_mb})
            return False

        return True

Метод класса host_passes возвращает значение True, если объем памяти, запрошенный для гостевого образа, в точности соответствует доступному объему на хосте, который в данный момент изучается на предмет отбора. Чуть более сложная и более полезная версия этого фильтра использует ram_allocation_ratio и производит сравнение с учетом коэффициентов выделения виртуальной памяти по отношению к физической памяти; по умолчанию этот коэффициент составляет не менее 1,5.

JsonFilter

Этот фильтр позволяет операторам записывать возможности хостов, соответствующих правилам, на основе простого синтаксиса, подобного JSON. Для сравнения свойств состояния хостов используются операторы «=», «<», «>», «in», «<=» и «>=». Вместе с ними можно использовать и логические операторы not, or и and. Убедитесь, что JsonFilter добавлен в параметр scheduler_default_filters в /etc/nova/nova.conf для поддержки этой функциональности.

В приведенном ниже примере из теста будут отфильтрованы все хосты с ОЗУ больше или равной 1024 МБ и со свободным местом на диске больше или равном 200 ГБ.

['and',
['>=', '$free_ram_mb', 1024],
['>=', '$free_disk_mb', 200 * 1024]
]

Параметр scheduler_hints используется во множестве фильтров для команды загрузки Nova при запуске гостевого экземпляра.

nova boot --image cirros-0.3.1-x86_64-uec --flavor 1 \
--hint query=['>=','$free_ram_mb',1024] test-instance

ComputeCapabilitiesFilter

Фильтр ComputeCapabilitiesFilter выдает только хосты, характеристики которых удовлетворяют запрошенным требованиям. Если не указаны extra_specs, то выводятся все хосты.

Ранее мы уже говорили о дополнительных спецификациях и пространствах имен: во избежание конфликтов при задействовании AggregateInstanceExtraSpecsFilter используйте пространство имен capabilities, добавляя дополнительные спецификации.

ImagePropertiesFilter

ImagePropertiesFilter отфильтровывает хосты на основе свойств, определенных в образе экземпляра. Он передает хосты, способные поддерживать указанные свойства образа, содержащиеся в экземпляре. К свойствам относится архитектура, тип гипервизора, версия гипервизора (только для гипервизоров Xen) и режим виртуальных машин.

Например, для экземпляра может требоваться хост с процессором архитектуры ARM* с гипервизором QEMU*. Можно добавить к образу свойства с помощью следующей команды:

glance image-update $img-uuid --property architecture=x86_64 \
   --property hypervisor_type=qemu

Фильтр проверяет следующие свойства образа

  • Architecture: архитектура системы, требуемая для образа. Примеры значений: i686, x86_64, arm и ppc64.
  • hypervisor_type: гипервизор, требуемый для образа. Примеры значений: xen, qemu и xenapi.
  • hypervisor_version_requires: версия гипервизора, требуемая для образа. Это свойство поддерживается только для типа гипервизоров Xen. Его можно использовать, чтобы реализовать поддержку нескольких версий гипервизоров и предотвратить возможность работы экземпляров с новыми версиями Xen на устаревших версиях гипервизора. Если это свойство доступно, его значение сравнивается с версией гипервизора хоста.

Чтобы отфильтровать доступные хосты по версии гипервизора, добавьте свойство hypervisor_version_requires к образу в качестве метаданных и передайте оператор и требуемую версию гипервизора в качестве значения:

glance image-update img-uuid --property hypervisor_type=xen \
   --property hypervisor_version_requires=">=4.3"

hypervisor_type: описывает двоичный интерфейс приложений (ABI) гипервизора, требуемый для образа. Примеры: xen — паравиртуальный ABI Xen 3.0, hvm — встроенный ABI, uml — паравиртуальный ABI пользовательского режима Linux, exe — виртуальный исполняемый ABI контейнера.

Хост может поддерживать несколько гипервизоров. Например, хост может определять [u'i686', u'qemu', u'hvm'] и [u'x86_64', u'qemu', u'hvm']. Если для гостевого экземпляра заданы свойства образа [u'x86_64', u'qemu', u'hvm'], то этот гостевой экземпляр может быть развернут на этом хосте.

Свойства образа для гостевого экземпляра можно задавать в виде подмножеств. Например, если для гостевого экземпляра заданы свойства образа [u'x86_64', u'hvm'], то этот гостевой экземпляр можно развернуть на хосте с поддерживаемым гипервизором [u'x86_64', u'qemu', u'hvm'].

Вес фильтров

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

Вес хостов в планировщике фильтров основывается на параметре конфигурации scheduler_weight_classes. По умолчанию этот параметр имеет значение nova.scheduler.weights.all_weighers, при котором выбирается единственный доступный весовой коэффициент: RamWeigher. После этого хосты «взвешиваются» и сортируются по весу в порядке по убыванию.

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

В конце процесса планировщик сортирует выбранные хосты по весу и создает на них экземпляры.

Зоны доступности и пакеты хостов

Объединение хостов в пакеты

С помощью пакетов можно группировать хосты, обладающие какой-либо общей функциональностью или возможностью. При этом критерии группировки могут быть как крайне простыми (например, объем установленной памяти или тип ЦП), так и достаточно сложными (например, топология NUMA). Использование пакетов хостов в OpenStack осуществляется совершенно произвольно и не ограничивается никакими рамками.

Для создания пакета хостов используется команда novaaggregate-create.


$ nova aggregate-create rack-aggregate1 
+----+-----------------+-------------------+-------+----------+ 
| Id | Name            | Availability Zone | Hosts | Metadata | 
+----+-----------------+-------------------+-------+----------+ 
| 1  | rack-aggregate1 | None              |       |          | 
+----+-----------------+-------------------+-------+----------+ 

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

$ nova aggregate-create rack-aggregate2 tokyo-az 
+----+-----------------+-------------------+-------+----------+ 
| Id | Name            | Availability Zone | Hosts | Metadata | 
+----+-----------------+-------------------+-------+----------+ 
| 2  | test-aggregate2 | test-az           |       |          | 
+----+-----------------+-------------------+-------+----------+ 

Эта команда создает пакет внутри зоны доступности Tokyo, а не в зоне доступности по умолчанию. С помощью пакетов можно дополнительно разделять зоны доступности при запуске гостевого экземпляра с помощью команды загрузки Nova.

Добавьте хост в пакет хостов: rack-aggregate2. Поскольку этот пакет хостов определяет зону дос­тупности tokyo-az, при добавлении хоста в этот пакет хост попадает в зону доступности tokyo-az.

$ nova aggregate-add-host 2 stack-compute1
Aggregate 2 has been successfully updated.

+----+-----------------+-------------------+---------------------+------------------------------------+ 
| Id | Name            | Availability Zone | Hosts               | Metadata                           | 
+----+-----------------+-------------------+---------------------+------------------------------------+ 
| 2  | test-aggregate2 | tokyo-az          | [u'stack-compute1'] | {u'availability_zone': u'tokyo-az'}| 
+----+-----------------+-------------------+---------------------+------------------------------------+

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

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

Интерфейс командной строки

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

nova aggregate-list

Вывод списка всех пакетов хостов.

nova aggregate-create <name> [availability-zone]

Создание нового пакета с именем <имя> в зоне доступности [зона_доступности] (необязательно), если она указана. Команда возвращает идентификатор нового созданного пакета. Хосты могут быть доступными для нескольких пакетов хостов. Соблюдайте осторожность при добавлении хоста в еще один пакет, если этот хост также входит в зону доступности. Будьте внимательны при использовании команд aggregate-set-metadata и aggregate-update во избежание путаницы при загрузке экземпляров разных зон доступности. При невозможности добавить какой-либо определенный хост в зону доступности, для которой он не предназначен, возникнет ошибка.

nova aggregate-delete <id>

Удалить пакет с идентификатором <ИД>

nova aggregate-details <id>

Показать сведения о пакете с идентификатором <ИД>

nova aggregate-add-host <id> <host>

Добавить хост с именем <хост> в пакет с идентификатором <ИД>

nova aggregate-remove-host <id> <host>

Удалить хост с именем <хост> из пакета с идентификатором <ИД>

nova aggregate-set-metadata <id> <key=value> [<key=value> ...]

Добавить или обновить метаданные (пары «параметр — значение»), связанные с пакетом с идентификатором <ИД>

nova aggregate-update <id> <name> [<availability_zone>]

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

nova host-list

Вывести список всех хостов службы.

nova host-update --maintenance [enable | disable]

Поместить хост в режим обслуживания или вывести хост из режима обслуживания.

Зоны доступности

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

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

Чтобы указать зону доступности, в которой будет запущен гостевой экземпляр, добавьте параметр availability-zone к команде загрузки Nova.

nova boot --flavor 2 --image 1fe4b52c-bda5-11e2-a40b-f23c91aec05e \ 
   --availability-zone tokyo-az testinstance 
nova show testinstance 
+-------------------------------------+--------------------------------------------------------------+ 
| Property                            | Value                                                        | 
+-------------------------------------+--------------------------------------------------------------+ 
| status                              | BUILD                                                        | 
| updated                             | 2013-05-21T19:46:06Z                                         | 
| OS-EXT-STS:task_state               | spawning                                                     | 
| OS-EXT-SRV-ATTR:host                | styx                                                         | 
| key_name                            | None                                                         | 
| image                               | cirros-0.3.1-x86_64-uec(64d985ba-2cfa-434d-b789-06eac141c260)| 
| private network                     | 10.0.0.2                                                     | 
| hostId                              | f038bdf5ff35e90f0a47e08954938b16f731261da344e87ca7172d3b     | 
| OS-EXT-STS:vm_state                 | building                                                     | 
| OS-EXT-SRV-ATTR:instance_name       | instance-00000002                                            | 
| OS-EXT-SRV-ATTR:hypervisor_hostname | styx                                                         | 
| flavor                              | m1.bigger (2)                                                | 
| id                                  | 107d332a-a351-451e-9cd8-aa251ce56006                         | 
| security_groups                     | [{u'name': u'default'}]                                      | 
| user_id                             | d0089a5a8f5440b587606bc9c5b2448d                             | 
| name                                | testinstance                                                 | 
| created                             | 2013-05-21T19:45:48Z                                         | 
| tenant_id                           | 6c9cfd6c838d4c29b58049625efad798                             | 
| OS-DCF:diskConfig                   | MANUAL                                                       | 
| metadata                            | {}                                                           | 
| accessIPv4                          |                                                              | 
| accessIPv6                          |                                                              | 
| progress                            | 0                                                            | 
| OS-EXT-STS:power_state              | 0                                                            | 
| OS-EXT-AZ:availability_zone         | tokyo-az                                                     |
| config_drive                        |                                                              | 
+-------------------------------------+--------------------------------------------------------------+

В этом примере указывается, что экземпляр разновидности m1.bigger будет запущен в зоне доступности центра обработки данных в Токио. Зона доступности хоста задается в файле nova.conf с помощью свойства node_availability_zone. Следующие параметры также можно настроить для зон доступности в файле /etc/nova/nova.conf:

default_availability_zone = nova

Зона доступности по умолчанию для вычислительного узла

default_schedule_zone = None

Зона доступности, используемая по умолчанию

internal_service_availability_zone = internal

Зона доступности, с которой связаны внутренние службы

Администраторы могут представить пакет хостов в виде зоны доступности.

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

Планировщик и фильтры

Обзор

Определение действий рабочего процесса для развертывания гостевого экземпляра

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

Вот процесс для использования пакетов хостов.

1. Проверьте, включены ли в планировщике пакеты хостов.

$ cat /etc/nova/nova.conf | grep scheduler_default_filters
scheduler_default_filters=AggregateInstanceExtraSpecsFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter

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

  • Хосты работают и включены? (ComputeFilter)
  • Хосты находятся в запрошенной зоне доступности? (AvailabilityZoneFilter)
  • На хостах достаточный объем ОЗУ? (RamFilter)
  • Хосты могут обслужить этот запрос? (ComputeFilter)
  • Хосты соответствуют дополнительным спецификациям, сопоставленным с типом экземпляра? (ComputeCapabilitiesFilter).
  • Хосты соответствуют свойствам архитектуры, типа гипервизора и режима ВМ, указанным для образа экземпляра? (ImagePropertiesFilter.

Дополнительные фильтры см. в разделе «Планировщик» в справочнике по настройке  (http://docs.openstack.org/liberty/config-reference/content/section_compute-scheduler.html).

2. Создайте пакет хостов.

nova aggregate-create rack-aggregate1 tokyo-az

Эта команда создает новый пакет хостов в токийской зоне доступности и создает идентификатор.

+----+----------------+-------------------+-------+----------+ 
| Id | Name           | Availability Zone | Hosts | Metadata | 
+----+----------------+-------------------+-------+----------+ 
| 1  | rack-aggregate1| tokyo-az          |       |          | 
+----+----------------+-------------------+-------+----------+

3. Добавьте характеристики пакета хостов с помощью идентификатора rack-aggregate1.

nova aggregate-set-metadata 1 fastnic=true

4. Добавьте хосты в пакет rack-aggregate1, чтобы планировщик мог запускать гостевые экземпляры.

nova aggregate-add-host 1 styx
nova aggregate-add-host 1 kerberos

+----+------------------+-------------------+--------------------- -+----------------------+ 
| Id | Name             | Availability Zone | Hosts                 | Metadata             | 
+----+------------------+-------------------+-----------------------+----------------------+ 
| 1  | rack-aggregate1  | nova              | [u'styx', u'kerberos']| {u'fastnic': u'true'}| 
+----+------------------+-------------------+-----------------------+----------------------+

5. Создайте разновидность m1.bigger и примените свойство rack-aggregate1.

nova flavor-create m1.bigger 6 16384 80 4
nova-manage instance_type set_key --name= m1.bigger --key=rack-aggregate1 --value=true

При этом будет создана новая разновидность и задано свойство extra_specs, что подтверждается командой flavor-show.

nova flavor-show m1.biggerc

+----------------------------+----------------------------+ 
| Property                   | Value                      | 
+----------------------------+----------------------------+ 
| OS-FLV-DISABLED:disabled   | False                      | 
| OS-FLV-EXT-DATA:ephemeral  | 0                          | 
| disk                       | 80                         | 
| extra_specs                | {u'fastnic': u'true'}      | 
| id                         | 42                         | 
| name                       | m1.bigger                  | 
| os-flavor-access:is_public | True                       | 
| ram                        | 16384                      | 
| rxtx_factor                | 1.0                        | 
| swap                       |                            | 
| vcpus                      | 4                          | 
+----------------------------+----------------------------+

6. Операторы могут использовать разновидность, чтобы гарантировать запуск гостевых экземпляров в rack-aggregate1.

$ nova boot --image f69a1e3e-bdb1-11e2-a40b-f23c91aec05e --flavor m1.bigger

Теперь зона доступности test-az определена и содержит один хост, поэтому пользователь может загрузить экземпляр и запросить эту зону доступности.

$ nova boot --flavor 10 --image 64d985ba-2cfa-434d-b789-06eac141c260 \    --availability-zone tokyo-az testinstance
$ nova show testinstance

+-------------------------------------+----------------------------------------------------------------+ 
| Property                            | Value                                                          | 
+-------------------------------------+----------------------------------------------------------------+ 
| status                              | BUILD                                                          | 
| updated                             | 2015-05-21T11:36:023                                           | 
| OS-EXT-STS:task_state               | spawning                                                       | 
| OS-EXT-SRV-ATTR:host                | devstack                                                       | 
| key_name                            | None                                                           | 
| image                               | cirros-0.3.1-x86_64-uec (64d985ba-2cfa-434d-b789-06eac141c260) | 
| private network                     | 10.0.0.2                                                       | 
| hostId                              | f038bdf5ff35e90f0a47e08954938b16f731261da344e87ca7172d3b       | 
| OS-EXT-STS:vm_state                 | building                                                       | 
| OS-EXT-SRV-ATTR:instance_name       | instance-00000002                                              | 
| OS-EXT-SRV-ATTR:hypervisor_hostname | styx                                                           | 
| flavor                              | m1.bigger (10)                                                 | 
| id                                  | 107d332a-a351-451e-9cd8-aa251ce56006                           | 
| security_groups                     | [{u'name': u'default'}]                                        | 
| user_id                             | d0089a5a8f5440b587606bc9c5b2448d                               | 
| name                                | testinstance                                                   | 
| created                             | 2015-05-21T11:36:023                                           | 
| tenant_id                           | 6c9cfd6c838d4c29b58049625efad798                               | 
| OS-DCF:diskConfig                   | MANUAL                                                         | 
| metadata                            | {}                                                             | 
| accessIPv4                          |                                                                | 
| accessIPv6                          |                                                                | 
| progress                            | 0                                                              | 
| OS-EXT-STS:power_state              | 0                                                              | 
| OS-EXT-AZ:availability_zone         | tokyo-az                                                       | 
| config_drive                        |                                                                | 
+-------------------------------------+----------------------------------------------------------------+ 

В приведенных выше примерах показано, как пакет хостов предоставляет механизм на основе API, при помощи которого администраторы облака могут задавать зоны доступности. Еще одно назначение пакетов хостов — группировка хостов, обладающих определенной возможностью. При создании нестандартных разновидностей можно задать требование какой-либо возможности. Когда поступает запрос на загрузку экземпляра такого типа, будут рассмотрены только хосты в пакетах, где в метаданных указана эта возможность.

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

$ nova aggregate-set-metadata 1 fastnic=true
Aggregate 1 has been successfully updated.

+----+-----------------+-------------------+-------+----------------------------+ 
| Id | Name            | Availability Zone | Hosts | Metadata                   | 
+----+-----------------+-------------------+-------+----------------------------+ 
| 1  | rack-aggregate1 | None              | []    | {u'fastnic': u'true'}      | 

Планировщику в этом случае известно следующее:

  • для разновидности m1.bigger требуется, чтобы параметр fastnic имел значение true;
  • у всех хостов в пакете rack-aggregate1 задано fastnic=true;
  • хосты kerberos и styx входят в состав пакета rack-aggregate1.

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

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

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

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

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

Новым является и планировщик с кэшированием. Он использует существующие средства для применения фильтров и весов планировщика, но кэширует список доступных хостов. Когда запрос пользователя передается планировщику с кэшированием, планировщик пытается запланировать выделение гостевого экземпляра на основе кэшированного списка хостов, что повышает производительность планировщика.

Появился новый фильтр планировщика AggregateImagePropertiesIsolation. Этот новый фильтр планирует запуск экземпляров на хостах на основе совпадения свойств образа для заданной области пространства имен со свойствами пакета хостов. Хосты, не входящие ни в один пакет хостов, остаются доступными для экземпляров на основе всех образов. Новые параметры настройки службы Nova aggregate_image_properties_isolation_namespace и aggregate_image_properties_isolation_separator определяют, какие свойства образа учитываются фильтром.

Настройка фильтрации для доверенных вычислительных групп
с архитектурой Intel®

В выпуске OpenStack Folsom появились доверенные вычислительные группы. В них при запуске гостевого экземпляра для определения его разрешений на использование целевого хоста используется сервер аттестации. См. следующие материалы.

http://wiki.openstack.org/TrustedComputingPools
https://github.com/openstack/nova/blob/master/nova/scheduler/filters/trusted_filter.py

1. Задайте следующее значение в nova.conf

scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler,TrustedFilter

2. Добавьте раздел trusted computing в nova.conf

[trusted_computing]       
server=10.10.10.10       
port=8181       
server_ca_file=/etc/nova/ssl.10.1.71.206.crt       
api_url=/AttestationService/resources/PoolofHosts       
auth_blob=i-am-openstack 

3. Добавьте требование trusted к существующей разновидности, выполнив следующую команду.

nova-manage instance_type set_key m1.tiny trust:trusted_host trusted

4. Перезапустите служб nova-compute и nova-scheduler service.

Сквозная работа PCI и SR-IOV

Убедитесь, что для вычислительного узла включена сквозная работа PCI согласно http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM

Настройте Nova

  • Вычислительный узел:

pci_passthrough_whitelist: Список разрешенных PCI-устройств, доступных для виртуальных машин.

Пример:

pci_passthrough_whitelist=[{ "vendor_id":"8086","product_id":"1520"}]

определяет все PCI-устройства на платформе с параметром vendor_id, равным 0 x 8086, и параметром product_id, равным 0 x 1520, как доступные для назначения экземплярам.

  • Узел контроллера:

pci_alias: An alias for a PCI passthrough device requirement.

Пример:

pci_alias={"vendor_id":"8086", "product_id":"1520", "name":"a1"}

определяет, что pci alias 'a1' представляет запрос на PCI-устройства с параметром vendor_id, равным 0 x 8086, и параметром product_id, равным 0 x 1520.

  • Узел планировщика:

включите фильтр PCI-устройств.

Пример:

scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler scheduler_available_filters=nova.scheduler.filters.all_filters scheduler_available_filters=nova.scheduler.filters.pci_passthrough_filter.PciPassthroughFilter scheduler_default_filters=RamFilter,ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilter 

Создайте разновидность

Примечание. Этот шаг не требуется для поддержки сетевых адаптеров SR-IOV.

Дополнительные сведения о передаче запросов PCI-устройств посредством создания портов см. по адресу https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking.

Настройте разновидность, запрашивающую PCI-устройства. Пример:

nova flavor-key  m1.large set  "pci_passthrough:alias"="a1:2"

Обновите разновидность, которой требуется два PCI-устройства, каждое с параметром vendor_id, равным 0 x 8086, и параметром product_id, равным 0 x 1520.

Создайте виртуальную машину

Дополнительные сведения о передаче идентификатора порта запроса PCI-устройства: https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking.

nova boot --image new1 --key_name test --flavor m1.large 123

Создайте виртуальную машину с требованием PCI. Образ в этом случае содержит драйвер для назначенных устройств, test — пара из параметра и значения.

Проверьте экземпляр назначения

nova show 123

Для проверки состояния ВМ перед тем, как она станет активной.

nova ssh --private 123 -i test.pem

для входа в гостевой экземпляр. Команда lspci выводит список всех устройств.

Проверка состояния PCI с исправлениями APIPCI

Исправления API PCI предоставляют гипервизору серверов и ОС возможность показывать информацию о PCI для экземпляров и вычислительных узлов, а также предоставляют конечную точку для отображения информации о PCI.

  • Получите исправления по адресу https://github.com/yjiang5/pci_api.git, примените исправление или скопируйте файлы подключаемого модуля расширения. Обновите файл политик, добавив две новые политики, и перезапустите службу API Nova.

"compute_extension:instance_pci": "",    "compute_extension:pci": "rule:admin_api",

  • Попробуйте использовать API PCI.

nova pci-list node_id

показывает все PCI-устройства вычислительного узла с идентификатором node_id (используйте команду novahypervisor-list для получения всех compute_node в системе)

nova list

получает назначение PCI-устройства экземпляру, os-pci:pci содержит идентификатор PCI-устройства.

nova pci-show id

показывает информацию о PCI-устройстве.

Примечание о сквозном использовании PCI-устройств

  • alias "device_type"

Определять псевдоним с помощью device_type не обязательно. В настоящее время не существует способа определения типа PCI-устройства из гипервизора, поэтому пока не задавайте device_type в псевдониме:

pci_alias={"vendor_id":"8086", "product_id":"1520", "name":"a1, "device_type":"NIC""}

Если псевдоним с device_type определен в nova.conf, то device_type будет входить в состав спецификации запроса PCI, поэтому попытка запланировать выделение вычислительного узла согласно такому запросу будет безуспешной. Такое поведение нуждается в доработке путем усовершенствования планировщика, который можно настраивать так, чтобы не обращать внимания на тип устройства.

Дополнительные сведения

https://wiki.openstack.org/wiki/Pci_passthrough

https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking

Заключение

Надеемся, что информация и примеры в этом документе помогли вам понять, как лучше использовать разновидности EPA, пакеты хостов и зоны доступности для оптимизации развертывания OpenStack. Для получения дополнительных сведений прочтите статьи и посмотрите видеоролики, перечисленные в следующем разделе.

Дополнительные сведения

Информационные документы и сопутствующая документация

OpenStack* Enhanced Platform Awareness - Enabling Virtual Machines to Automatically Take Advantage of Advanced Hardware Capabilities (https://01.org/sites/default/files/page/openstack-epa_wp_fin.pdf).

Разработка высокопроизводительных гибких решений SDN и NFV с помощью открытой эталонной архитектуры серверных сетевых платформ Intel® (http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/software-defined-networks-onp-paper.pdf)

Лекции на видео

«Разделяй и властвуй»: разделение ресурсов в облаке OpenStack (https://www.youtube.com/watch?v=H6I3fauKDb0)

Усовершенствования OpenStack для поддержки сценариев использования NFV (https://www.youtube.com/watch?v=5hZmE8ZCLLo)

Предоставление конечным пользователям облачных приложений с помощью хранилища артефактов Glance (https://www.youtube.com/watch?v=mbRrWFMBlLM)

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

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