Как OpenStack Nova выбирает сервер для виртуальной машины и зачем облако делят на cells

За одним API находится несколько самостоятельных служб

В Nova пользовательский запрос поступает в REST API, а внутреннее взаимодействие во многих случаях проходит через сообщения RPC. Службы не являются одним процессом, которому просто дали несколько названий. API принимает и проверяет обращения, scheduler выбирает место размещения, compute взаимодействует с гипервизором, conductor координирует длительные действия и доступ к данным.

Для обмена используется oslo.messaging, который абстрагирует систему очередей. Состояние хранится в SQL-базах через слой объектов. Compute не обязан самостоятельно иметь прямой доступ к каждой управляющей базе: запросы могут проходить через conductor. Это разделение также участвует в поддержке обновлений, когда управляющие компоненты и вычислительные узлы некоторое время работают на соседних версиях.

Поэтому успешный HTTP-ответ о принятой операции не следует понимать как непосредственное выполнение всех действий гипервизором в том же соединении. Дальнейший путь включает координацию, выделение ресурсов и работу compute. Сам Nova отвечает за вычислительные instances, а ресурсы проекта шире: сеть, блочные тома и идентификация предоставляются связанными сервисами OpenStack. Облачный сервер собирается из нескольких согласуемых частей, даже если в пользовательском интерфейсе его создание выглядит одной кнопкой.

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

Cells делят состояние и сообщения, сохраняя общий вход

Cells v2 позволяют разбить множество compute-узлов на ячейки. Даже установка с одной рабочей ячейкой использует эту архитектурную модель. На уровне API остаётся общая база, которая, в частности, помогает находить местоположение instance. Основная информация об instances живёт в базах соответствующих cells.

При нескольких ячейках у каждой появляются своя очередь сообщений и conductor. На верхнем уровне работает отдельный super conductor. Нижние службы не получают неограниченный доступ ко всем глобальным данным и RPC-вызовам других частей облака. Такое разделение создаёт границы управления и уменьшает необходимость единого обмена «каждый с каждым».

Особое место занимает cell0. В ней нет compute-узлов: база используется для instances, которые не удалось разместить. Это не дополнительная зона, где могут работать виртуальные машины. Карты ячеек в API-базе связывают сведения о размещении с нужными подключениями к очереди и базе. Поэтому несколько названий cells без согласованной конфигурации не образуют законченного разбиения. Речь идёт о действительном разделении служебных путей, а не только о визуальных группах серверов в панели администратора.

Placement хранит ресурсы и свойства поставщиков

Placement предоставляет отдельную модель resource providers, inventories и allocations. Поставщиком может быть вычислительный узел, но общая модель допускает и другие источники ресурсов. Consumer, например instance, может использовать процессор и память одного provider и дисковый ресурс другого. Это описание учёта, а не перечень процессов, которые запускают виртуальную машину.

Resource classes задают количественные виды: VCPU, MEMORY_MB, DISK_GB и пользовательские классы. Traits описывают качественные особенности, которые не расходуются как количество. Например, требование определённой возможности устройства отличается от требования некоторого объёма памяти. Такое разделение позволяет выразить и ёмкость, и совместимость кандидата.

Различие между запасом и занятым объёмом также принципиально: наличие физического ресурса и выделение его конкретному consumer — разные записи модели. Placement отслеживает эти отношения и предоставляет API для запросов. Scheduler использует сведения для выбора, а compute реализует действия на хосте. Служба учёта не подменяет ни политику размещения целиком, ни гипервизор. Именно поэтому в общей архитектуре она выделена отдельным компонентом, хотя её данные напрямую влияют на возможность создать новый instance.

Фильтрация отвечает «можно ли», веса — «кого предпочесть»

Scheduler выбирает host не только по общему количеству свободной памяти. Запрос может содержать требования образа, характеристики flavor, ограничения группы серверов и другие условия. Часть предварительного отбора передаётся в Placement, затем фильтры исключают неподходящих кандидатов. Результат конкретного фильтра бинарен: узел проходит либо не проходит.

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

Affinity и anti-affinity задают отношения с другими instances группы: совместное или раздельное размещение по hosts. Предпочтение по загрузке — другой вид политики. Следовательно, «самый свободный сервер» не является универсальным определением результата Nova. Узел сначала должен соответствовать необходимым признакам и ограничениям, а затем участвовать в настроенном сравнении. Схема filtering workflow иллюстрирует именно отсев кандидатов, не работу пользовательского приложения и не измеренную скорость запуска виртуальной машины.

Availability zone не тождественна ячейке или отказоустойчивости

Availability zone — видимая пользователю логическая часть облака, позволяющая запрашивать размещение в определённой группе hosts без знания их конкретных адресов. Она может отражать местоположение, сеть или питание, но сама по себе не доказывает физическую независимость оборудования. Документация Nova прямо предупреждает, что AZ не следует автоматически считать доменом отказа.

Зоны определяются через метаданные host aggregates. Узел может участвовать в нескольких aggregates, но находиться только в одной availability zone. По умолчанию существуют особенности зоны для hosts без явного назначения, поэтому совпадающее имя не всегда объясняет физическую организацию. Aggregate, AZ и cell отвечают на разные вопросы и не являются взаимозаменяемыми уровнями одной обязательной иерархии.

Cell разделяет внутреннее состояние и обмен служебными сообщениями. Aggregate группирует hosts для административных возможностей. AZ предоставляет пользователю логический выбор размещения. Реальная независимость определяется инфраструктурой и политикой, которая связывает её с этими понятиями. Поэтому распределение экземпляров между двумя произвольно названными зонами само по себе не подтверждает разделение стоек, сетевых компонентов или источников питания. В архитектуре Nova эти различия позволяют отдельно управлять масштабом control plane, набором допустимых хостов и видимой моделью облака.