Вопрос или проблема
У меня установлена версия OpenStack Antelope через Kolla-Ansible, и у меня есть несколько вычислительных узлов с типами томов LVM. Когда я создаю экземпляр, используя том LVM, я ожидаю, что и том, и экземпляр будут созданы на одном и том же узле. Однако они оказываются на разных узлах. Например, том находится на d13-compute43@localA#localA, тогда как экземпляр на d13-compute51
Возможно, стоит попробовать разделить Cinder и экземпляр по зонам доступности. Например, если у вас есть узлы openstack-01 и openstack-02, вы можете попытаться разместить nova и cinder в openstack-01 в az1 и создать том и вычислительный узел в той же зоне, например, az1.
Ответ или решение
Ваша проблема заключается в том, что виртуальная машина (VM) и связанные с ней объемы LVM (Logical Volume Manager) размещаются на разных хостах внутри вашей инфраструктуры OpenStack версии Antelope, установленной с использованием Kolla-Ansible. Рассмотрим возможные причины и решения этой ситуации, а также предложим подход для использования зон доступности (Availability Zones) для обеспечения размещения VM и ее объемов на одном и том же хосте.
Теория
В OpenStack компоненты управляются различными сервисами, где Nova отвечает за управление виртуальными машинами (инстансами), а Cinder – за управление блочными устройствами, такими как LVM. При создании инстанса, который использует блочный объем, эти сервисы могут вовлекать различные физические или виртуальные узлы. В результате необязательно, что инстанс и его блочный объем будут размещены на одном и том же узле.
Размещение инстансов и объемов на одном узле может быть желательно по ряду причин, включая минимизацию сетевой задержки между инстансом и его объемом, снижение нагрузки на сетевую инфраструктуру и упрощение управления ресурсами. Однако по умолчанию OpenStack не всегда гарантирует такое размещение.
Пример
Ваше описание ситуации говорит о том, что существуют определенные проблемы с политикой размещения. Например, в вашем случае объем размещается на d13-compute43@localA#localA, в то время как инстанс – на d13-compute51. Это может привести к увеличению времени доступа к данным и снижению пропускной способности из-за необходимости передачи данных между узлами.
Применение
Чтобы решить данную проблему, могут быть предприняты следующие шаги:
1. Использование Зон Доступности
Одним из решений является использование зон доступности (AZ) для четкого разграничения физических и виртуальных ресурсов:
-
Создание специализированных зон доступности. Для этого каждая пара хостов (один для Nova, другой для Cinder) должна быть назначена в одну и ту же зону доступности. Например,
openstack-01иopenstack-02могут быть помещены вaz1. -
Для создания инстансов и объемов в одной и той же зоне необходимо указать соответствующую AZ при написании команды (или при использовании API).
2. Конфигурация Фильтров Размещения
Конфигурационные изменения могут быть выполнены для использования фильтров размещения в Nova и Cinder:
-
Nova Scheduler: Настройте
AggregateInstanceExtraSpecsFilterиAvailabilityZoneFilter, чтобы убедиться, что инстанс создается в той же AZ, что и объем. -
Cinder Scheduler: Используйте
CapacityFilterиAvailabilityZoneFilter, чтобы гарантировать что объем создается в преференцированной AZ.
3. Настройка Достройки (Affinity) Политик
- Server Group Affinity/Anti-Affinity: Создайте серверные группы в Nova и используйте политики affinity для гарантии того, что инстанс и блочные объемы размещаются совместно. Добавьте инстанс и объем в одну серверную группу, которая требует их совместного размещения.
4. Проверка и Отладка
-
Используйте OpenStack CLI для проверки текущих конфигураций ваших зон доступности, и убедитесь, что Nova и Cinder используют одинаковые приоритеты размещения.
-
Проверьте логи Nova и Cinder для обнаружения конфигурационных ошибок, которые могут препятствовать корректной работе фильтров и политик.
Применяя эти методы, вы можете более эффективно управлять размещением инстансов и объемов LVM, устраняя проблемы производительности, связанные с их раздельным размещением. Убедитесь, что все изменения конфигурации протестированы в тестовой среде перед применением в рабочей, чтобы избежать сбоев и нецелесообразного распределения ресурсов.