openstack ironic что это
Русские Блоги
Введение в OpenStack-Ironic Bare Metal
1. Ироничное краткое введение
Два, Почему Обеспечение Голого Металла
Here are a few use-cases for bare metal (physical server) provisioning in cloud; there are doubtless many more interesting ones:
（1）High-performance computing clusters
（2）Computing tasks that require access to hardware devices which can’t be virtualized
（3）Database hosting (some databases run poorly in a hypervisor)
（4）Single tenant, dedicated hardware for performance, security, dependability and other regulatory requirements
（5）Or, rapidly deploying a cloud infrastructure
Это официальный сайт, быстро переведите:
1. Высокопроизводительные вычисления;
2. Не может использовать виртуализированные вычислительные задачи;
3. Хост базы данных;
4. Единый арендатор, выделенное оборудование, безопасность, надежность и другие требования;
5. Быстрое развертывание облачной инфраструктуры (например, развертывание виртуализированного узла).
В-третьих, использование Ironic в проектах OpenStack
В настоящее время в архитектуре OpenStack Ironic по-прежнему вызывается через Nova, имитируя драйвер виртуализации Nova (другие драйверы виртуализации включают KVM,VMware, Xen и др.) Реализовать драйвер виртуализации на базе Ironic.
Предварительная настройка PXE, IPMI и др. После завершения соответствующей настройки Ironic пользователи могут использовать Nova API для создания экземпляра физической машины. Nova используется для управления жизненным циклом виртуальных машин, Ironic используется для управления жизненным циклом физических машин и предоставляет Nova интерфейс API для управления физическими машинами.
Для Nova развертывание физической машины через Ironic аналогично развертыванию виртуальной машины. Процесс вызова такой же. Создание экземпляра выполняется через интерфейс Nova, но в основе лежит планировщик nova и Драйвер nova-compute отличается. Базовый драйвер виртуальной машины использует технологию виртуализации, в то время как физическая машина использует технологии PXE и IPMI.
Будучи независимым модулем в openstack, Ironic должен взаимодействовать с keystone, nova, нейтронами, cinder и swift. Так же, как Nova создает виртуальную машину, ей требуются соответствующие службы аутентификации, сетевые службы и блоки. Услуги хранения, услуги хранения объектов и т. Д.
В-четвертых, Иронический и Гипервизор
Основные гипервизоры включают в себя: VMware ESXi, MicrosoftHyper-VИли Citrix XenServer.
Ironic может напрямую управлять узлами на физических машинах, добавлять и удалять узлы физических машин, управлять питанием и развертывать системы. Из-за неоднородности физических машин разных производителей, для разных серверов, Ironic предоставляет механизм подключаемых модулей, различные поставщики могут разрабатывать подключаемые модули Ironic для своих собственных серверов. Предоставьте соответствующий драйвер. Пользователи могут выбрать подходящий драйвер в соответствии со своими потребностями.
Пять, ироническая логическая структура
Пользователь запускает пустой экземпляр через Nova API и Nova Scheduler, после чего запрос соединяется со службой Ironic Conductor через Ironic API, затем с соответствующим драйвером и, наконец, завершает развертывание экземпляра, чтобы предоставить пользователю успешно развернутую службу физического компьютера.
Интервью с Деванандой ван дер Вином (Devananda van der Veen), техническим руководителем проекта OpenStack Ironic
Мы представляем девятое из серии интервью с техническими руководителями проекта OpenStack в блоге Mirantis. Наша цель – обучить более широкое сообщество технических специалистов и помочь людям понять, как они могут внести вклад в проект OpenStack и извлечь из него выгоду. Естественно, ниже изложена точка зрения интервьюируемого, а не компании Mirantis.
Ниже приведено интервью с Деванандой ван дер Вином (Devananda van der Veen), техническим руководителем проекта OpenStack Ironic.
Mirantis: Расскажите о себе.
Девананда ван дер Вин: Я – старший системный инженер в HP Cloud. Работаю здесь уже более 1.5 лет, в данный момент возглавляю проект Ironic. До этого я работал консультантом и администратором БД MySQL.
Вопрос: Какова Ваша история взаимоотношений с OpenStack? Почему Вы участвуете в проекте?
Ответ: Многие годы я работал с Монти Тэйлором (Monty Taylor) и, когда он заговорил со мной об OpenStack, моя реакция была: «О, э, здорово! Звучит прикольно!». На тот момент я уже хотел переключиться с MySQL на что-то новое и мне было ясно, что OpenStack будет следующим этапом в развитии технологий. MySQL показала по-настоящему бурный рост, начиная примерно с 2005 г. Поэтому я тогда направил свою карьеру в то русло, и я вижу, что сейчас то же самое происходит и с OpenStack. Я считаю, что процесс, в создании которого мы здесь участвуем, окажет влияние на всю сферу ИТ, и я хочу быть частью этого.
Вопрос: Каковы Ваши обязанности в качестве технического руководителя проекта Ironic?
Ответ: Определение направления и координация деятельности разработчиков, во многом те же обязанности, что и в других технических проектах OpenStack. Я отвечаю за разработку концепции, осуществляю управление проверкой кода, руководство разработчиками, но нахожусь в стороне от непосредственно разработки. Вдохновляю сообщество на развитие вокруг Ironic.
Вопрос: Что самое существенное из того, что Вам необходимо сделать, чтобы поддерживать активность проекта?
Ответ: Я хочу создать проект, содействуя которому большое количество различных вендоров аппаратных средств ощущали бы себя комфортно и не чувствовали, что они конкурируют за проприетарные биты или дробят проект на части. Собственно Ironic представляет собой сервис по провижинингу аппаратных средств или «голого железа» в OpenStack. У всех вендоров аппаратных средств, таких как HP, Dell и IBM, имеются инструменты собственной разработки для управления «железом», например, механизм удаленного управления серверами iLO компании HP или контроллер удаленного доступа DRAC компании Dell. Все они привносят дополнительную функциональность в стандартную спецификацию интерфейса IPMI, а некоторые из них реализуют его немного иначе.
Вопрос: Вы можете объяснить, какова роль проекта Ironic в рамках OpenStack? Почему он важен?
Ответ: Это можно объяснить двумя разными способами, я постараюсь выбрать один.
До сих пор в процессе развития OpenStack нам приходилось использовать другие инструменты для развертывания OpenStack, будь то пара серверов в вашем серверном шкафу или стойке либо целый дата-центр. Оборудование обязательно было внешним по отношению к OpenStack.
Роль Ironic заключается в том, чтобы обеспечить уровень провижининга аппаратных средств, которого раньше в OpenStack не было. На основе данной роли одна из целей Ironic – сделать возможным TripleO (OpenStack-on-OpenStack). Весь инструментарий, который вы используете для развертывания комплексного приложения в облаке, может быть повторно использован для развертывания облака, которое в итоге является другим комплексным приложением.
Вопрос: В чем различие между Ironic и TripleO?
Ответ: Ironic – это сервис, который управляет мощностью физической машины и пишет образ на машину. Кроме того, у нас в планах сделать возможными и другие задачи по управлению. TripleO располагается на более высоком уровне в стеке и использует не только Ironic, но и множество других сервисов для развертывания облака OpenStack и управления им.
Вопрос: Расскажите о сообществе Ironic – кто содействует проекту?
Ответ: HP, Red Hat, Mirantis, IBM и другие. Из числа вендоров аппаратных средств с нами сотрудничают и HP, и IBM. До сих пор IBM по большей части участвовала в смежном проекте – создании драйвера IPMI целиком на языке Python, который был перенесен из xCAT в сообщество OpenStack. Он будет использован Ironic как более масштабируемая замена библиотеке ipmitool, унаследованной из кода Baremetal компонента Nova.
Вопрос: Вам бы хотелось видеть большую вовлеченность со стороны вендоров аппаратных средств?
Ответ: Да, хотелось бы. Несомненно, мне бы хотелось видеть Dell. Пока что они не задействованы в нашем проекте. Ironic – очень молодой проект, и, возможно, некоторые вендоры аппаратных средств пока еще серьезно не участвовали в нем, просто потому что не был готов код. Я думаю, мы стремительно приближаемся к уровню полной готовности кода, когда народ сможет быстро к нам присоединиться и добавить свои собственные аппаратные драйверы.
Вопрос: Чего достигло сообщество Ironic на данный момент?
Ответ: Провижининг «голого железа» унаследовал большое количество ограничений, поскольку изначально была попытка его запуска в рамках процесса Nova Compute. Последние месяца 4 или около того мы «вырывали» Ironic из состава Nova, превращая его в автономный сервис OpenStack самого высокого уровня. Он имеет собственный API-сервис, который можно масштабировать. У него есть собственные очередь сообщений и серверная часть БД, а также сервис Conductor – что-то среднее между сервисами Nova Conductor и Nova Compute. Совсем недавно мы добавили поддержку DevStack и конструктора образа диска, а также python-клиента; тесты Tempest находятся в разработке. Все это необходимо для любого проекта OpenStack, но мне кажется, это довольно большое достижение для небольшой команды за период всего в 4 месяца!
Вопрос: Какие возможности реализует Ironic в следующем релизе OpenStack?
Ответ: Я не могу точно сказать, какие функциональные возможности Ironic будут доступы в Icehouse.
Вопрос: Если бы Вы могли взмахнуть волшебной палочкой прямо сейчас и превратить Ironic именно в то, чем Вы хотите его видеть, что бы это было на данный момент?
Ответ: Я бы хотел его видеть масштабируемым и отказоустойчивым. Мое определение высокой доступности в данном контексте – это его устойчивость к сбоям, а не полное отсутствие таковых. Отказ аппаратных средств неизбежен, но Ironic должен быть способным восстанавливаться после сбоев.
Я бы хотел видеть в его составе разные драйверы от различных вендоров аппаратных средств. Я бы хотел, чтобы сами драйверы были общедоступными, а не проприетарными. Мне бы хотелось, чтобы Ironic мог управлять всевозможными видами аппаратных средств, начиная с ARM-устройств и заканчивая «большим железом» – всем существующим разнообразием оборудования, о котором я лично могу не знать. Я бы хотел, чтобы другие люди внесли вклад в виде драйверов для того, чтобы все это было реализуемым и осуществимым.
Вопрос: Есть ли какие-либо заблуждения относительно Ironic?
Ответ: Одно из них – это то, что Ironic не является БД конфигурации и что он не будет хранить историю состояний. Меня спрашивали: «Вы будете отслеживать скорость работы вентилятора, температуру ЦП, а затем предпринимать какие-либо действия, если что-то перегреется?». Мой ответ: «Нет!».
Но самым большим заблуждением на данный момент является то, что можно использовать Nova Compute или Ironic для реализации незащищенных многопользовательских облаков на основе «голого железа». Это наша цель, но на сегодня мы точно еще не достигли ее. Есть ряд существенных скрытых проблем, связанных с безопасностью незащищенных пользователей облаков, работающих на базе «голого железа». Если бы я снова мог взмахнуть волшебной палочкой, я бы хотел, чтобы все эти проблемы были решены. Это потребует огромной совместной работы вендоров аппаратных средств по разработке надежного аппаратного обеспечения, а также решения вопросов безопасности на уровне встроенного ПО, а не только относительно загрузки сети и изоляции пользователей. Некоторая работа над этим уже ведется, но я считаю, что мы все еще далеки от решения данных проблем. Тем временем, я хочу, чтобы люди знали, что сегодня нельзя запускать облака под незащищенными пользователями на «голом железе».
Вопрос: Еще один вопрос из серии «мне бы хотелось». Кого бы Вы хотели видеть в числе людей, задействованных в проекте Ironic? Кто Ваш идеальный участник на данный момент?
Ответ: Разработчики, которые знают, как работать с сообществом открытого исходного кода, поскольку их не всегда легко найти. Люди с хорошим опытом администрирования систем в дополнение к программированию, поскольку большая часть того, чем мы занимаемся в Ironic, происходит на низком уровне. Да, он написан на Python, но мы делаем многое для интеграции с такими процессами, как DHCP, IPMI и PXE, и мне будут нужны люди, которые понимают в вопросах безопасности встроенного ПО. Потребность в таких членах команды, как мне кажется, на данный момент не полностью удовлетворена.
Вопрос: Спасибо, что уделили нам время.
Bare metal за 5 минут: как мы из андерклауда сделали облачный сервис для аренды выделенных серверов
Хоть мы тогда и сами об этом не знали, но создавать сервис для аренды выделенных серверов мы начали два года назад. При запуске новых регионов публичного облака нам требовалось оперативно развернуть множество серверов разных конфигураций по всему миру, но целыми днями заниматься этим вручную никто не хотел. Вместо людей со стальными нервами мы нашли более изящное решение в лице Ironic — сервиса OpenStack для провижининга «голого железа». Совместно с другими инструментами он позволял и раскатывать образ, и настраивать систему, и на тот момент этого уже было достаточно. Позже в Ironic появились такие возможности, что это решение начало закрывать вообще все наши задачи по управлению инфраструктурой в облаке. А раз уж мы справились с этим, то почему бы не сделать на основе служебного инструмента публичный сервис с автоматической подготовкой выделенных серверов? О том, что из этого вышло — под катом.
Шёл 2014 год…
Серверы мы деплоили на коленке через PXE boot и kickstart. Это решение хоть и работало, но имело недостатки:
Сети переключались вручную;
Выбор сервера и его перевод в загрузку по PXE выполнялся вручную;
Сборка рейда и обновление прошивок — тоже manual mode.
Сначала для решения проблемы мы хотели просто написать свой bash-скрипт, который и будет всё делать. К счастью, руки до этого так и не дошли, и мы рассмотрели все существующие на тот момент варианты:
MaaS — предлагался как коробочное решение от одной очень солидной компании за не менее солидную сумму;
Cobbler — тут нам сказать особо нечего, так как в команде не нашлось инженеров с необходимым знанием технологии;
Foreman — казался неплохим решением, тем более что мы использовали Puppet;
OpenStack Ironic — хоть инженеров с опытом по этому продукту в команде тогда и не нашлось, но у нас уже был опыт работы с Openstack по виртуализации. Так что ставка была сделана на то, что в будущем мы сможем красиво всё собрать в один OpenStack. Понятное дело, в этом мы глубоко заблуждались, но об этом позже.
В итоге автоматизировать деплой серверов мы решили с помощью Ironic, а эти работы в дальнейшем положили начало куда более масштабному проекту. Рассказываем, как так вышло.
Шаг 1: автоматизируем управление внутренней инфраструктурой облака
Наши решения работают на основе разных технологий Intel: облачные сервисы — на процессорах Intel Xeon Gold 6152, 6252 и 5220, кеш-серверы CDN — на Intel Xeon Platinum, а в апреле 2021 мы также одними из первых в мире начали интеграцию Intel Xeon Scalable 3-го поколения (Ice Lake) в серверную инфраструктуру своих облачных сервисов. Чтобы вручную управлять всем этим пулом железа для сервисных целей облака, ежедневно разворачивать по всему миру серверы с разными конфигурациями и всё это ещё и как-то поддерживать, нам требовался либо целый штат специалистов, либо инструменты автоматизации, которые бы обеспечили высокий темп экспансии в регионы и облегчили жизнь нашим админам. Как уже говорилось, для этих целей мы решили использовать Ironic. На момент внедрения — два года назад — это был уже достаточно зрелый сервис со следующими возможностями:
Удалённое управление серверами;
Сбор информации о конфигурациях и коммутации ещё не запущенных серверов;
Установка ОС на произвольном сервере;
Настройка сети с использованием протоколов 802.1q и 802.3ad.
Нас такое решение вполне устраивало, поэтому на нём мы и остановились, а для настройки операционной системы на сервере решили использовать cloud-init. Рабочий процесс был простым и прозрачным:
Сначала формировался загрузочный ISO-диск с информацией о настройках сервера, пакетах и сетевых интерфейсах.
На физическом сервере запускался процесс исследования с помощью компонента Ironic Inspect.
Затем этот сервер Ironic загружал с конфигурационным образом.
Начинался процесс автоматической установки CentOS, настраивались сетевые интерфейсы, ставились пакеты.
Подробней весь жизненный цикл можно увидеть на следующей схеме:
Так всё и продолжалось, пока Ironic становился более зрелым продуктом. Со скрипом, но всё же в нём появились новые возможности, в том числе и всё необходимое для автоматизированного управления RAID-контроллерами, обновления прошивок и развёртывания образов системы с произвольных HTTP-ресурсов через интернет. Так что со временем у нас появилось полноценное решение для автоматизации вообще всех задач по управлению инфраструктурой в облаке — им стала связка Ironic с cloud-init и используемой нами CI/CD. Чем не задел на что-то большее?
Шаг 2: планируем создание новой услуги из андерклауда
Сначала мы использовали инструмент только для служебных целей. Он хорошо справлялся с автоматизацией задач по управлению инфраструктурой облака, но этим наши планы не ограничивались: нам также требовалось подготовить решение для провижининга арендуемых заказчиками выделенных серверов. Оно бы пришлось как нельзя кстати, так как упрощало аренду серверов bare metal для потенциальных клиентов, а сомнений в их наличии у нас не было. На тот момент пользователи и без того часто заказывали у нас выделенные серверы — обычно они разворачивали на них продакшн-среды для высоконагруженных приложений, так как «голое железо» оказывалось производительней и безопасней виртуальных машин, к тому же на нём не было «шумных соседей». Вот только времени на подготовку каждого физического сервера у нас уходило в разы больше, ведь для этого всё требовалось делать вручную:
Сначала выбирать из пула доступных наиболее подходящий сервер;
Затем применять определённую конфигурацию для оборудования (настроить сетевые интерфейсы, RAID-контроллеры);
Постоянно поддерживать в актуальной версии системное ПО (firmware или версию BIOS);
Загружать и устанавливать операционную систему, выполнять пост-инстал скрипты.
Автоматический провижининг избавил бы нас от лишних сложностей. К тому же его потенциал не ограничивался упрощением подготовки серверов: он вполне мог лечь в основу полноценного облачного сервиса, с помощью которого пользователи будут за несколько минут разворачивать узлы bare metal, а арендовать выделенный сервер будет не сложней виртуального. Так из внутреннего компонента мы решили развивать новую услугу для пользователей облака — Bare-Metal-as-a-Service.
Шаг 3: автоматизируем провижининг выделенных серверов в публичном облаке
С помощью автоматизации мы планировали решить несколько задач: ускорить подготовку выделенных серверов, сделать возможной одновременную работу сразу с несколькими из них, сократить простой между операциями и исключить человеческий фактор. Добиться этого нам удалось с помощью общедоступных инструментов и пары собственных доработок. Объяснить, как всё работает, проще всего на конкретном примере — теперь для того, чтобы сервер стал доступен для заказа клиентом, мы выполняем следующие действия:
Заносим сервер в CMDB (сейчас для этого у нас уже есть NetBox).
Через Redfish выполняем преднастройку BIOS — активируем загрузку по PXE и настраиваем её режимы, — а также создаём пользователей для удалённого управления.
Проверяем работоспособность сервера и передаём управление Ironic.
Инженер добавляет сервер в нужную плайсмент-группу.
Убеждаемся, что данные в CMDB и Ironic совпадают — в противном случае на этом этапе требуется ручное вмешательство оператора.
После успешной проверки данных Ironic выполняет настройку RAID и BIOS, а также первоначальную очистку сервера с помощью ATA Secure Erase или shred в зависимости от того, что поддерживает RAID-контроллер.
Вот и всё, сервер попадает в пул доступных для заказа. Решение обеспечивает все наши текущие потребности и реализовано на общедоступных инструментах, так что нам не нужно ежемесячно платить за сторонний продукт и мы ни с кем не связаны лицензионными обязательствами. С поставленными задачами оно справляется на все сто — пользователи с помощью этого решения создают узлы bare metal почти так же быстро, как и виртуальные машины.
Шаг 4: добавляем новую услугу в облачную экосистему
Сейчас пользователи часто используют услугу Bare-Metal-as-a-Service в сочетании с другими нашими сервисами. Это позволяет им быстро получить готовую и гибкую инфраструктуру с простым управлением выделенными серверами и виртуальными машинами, приватными и публичными сетями, а также другими облачными решениями. Заказчикам такой подход помогает эффективно и экономично использовать ресурсы, а мы в результате успешно развиваем собственную экосистему сервисов, так как клиенты пользуются сразу комплексом наших решений. Помимо прочего, это открывает для заказчиков новые сценарии использования публичного облака — например, можно держать продакшн-среды на выделенных серверах, а при всплесках нагрузки за минуту разворачивать дополнительные мощности на виртуальных машинах, которые затем можно легко удалить. Чтобы новая услуга стала такой важной частью нашей экосистемы сервисов, после работ над автоматическим провижинингом нам предстояло решить ещё много задач.
Для начала, чтобы пользоваться новым сервисом было просто, заказ выделенных серверов мы сделали схожим с деплоем виртуальных машин — теперь для этого достаточно выбрать нужные характеристики, подключить публичную, приватную или сразу несколько сетей и через несколько минут получить готовый к работе сервер. Это решение уже прошло испытание боем: когда одному нашему клиенту не хватало виртуальных машин, он в тот же день оформил заказ и без проблем переехал на bare metal. С некоторыми другими задачами всё оказалось не так просто — остановимся на паре из них.
Избавляемся от «шумных соседей»
Главное отличие публичного сервиса от внутреннего компонента — наличие уникальных пользователей. Несмотря на то что все серверы живут в одном пуле, заказчикам как-то нужно обеспечить их изолированность друг от друга. Мы добились этого с помощью механизма мультитенантности. Готовые SDN-решения для этого не подходили, так как из-за них нам потребовалось бы ответвляться от существующей инфраструктуры. Нам также нужно было предусмотреть мультиплатформенность, поскольку наши облака распределены по всему миру и сетевое оборудование может варьироваться от региона к региону. В поисках подходящих решений нам пришлось досконально изучить вопрос, оптимальным вариантом оказался Networking-Ansible ML2 Driver. Правда, без ложки дёгтя в нём не обошлось — драйвер не умел объединять порты в MLAG, чего нам очень хотелось. Тогда мы сами научили его нужным образом агрегировать каналы на наших коммутаторах, но тут же столкнулись с другой проблемой при настройке интерфейсов внутри самого физического сервера.
Мы ожидали от cloud-init, что при выборе пользователем нескольких сетей они будут настроены с помощью сабинтерфейсов, но этого почему-то не происходило. Как оказалось, проблема была в том, что cloud-init недополучает из config-drive информацию о VLAN-ах, если порт настраивается транком. К счастью, на просторах opendev мы нашли патч, который мог бы исправить эту проблему. Сложность была в том, что он ещё находился в разработке, так что тут нам опять пришлось поработать напильником, чтобы самим довести патч до ума.
Теперь всё работает следующим образом:
Сетевые интерфейсы по умолчанию автоматически агрегируются и в транк перебрасываются как публичные, так и приватные сети. Пользователи же могут сконфигурировать свой ландшафт любым удобным образом, объединяя публичные и приватные сети в своём проекте — это позволяет им максимально эффективно использовать ресурсы;
По умолчанию все порты сервера находятся в несуществующей сети, но мы уже знаем в какой коммутатор воткнут каждый из них. Когда пользователь заказывает сервер, портам открывается доступ к PXE-серверам, запускается загрузчик, заливается образ, а дальше порты конфигурируются в целевую схему и сервер отдаётся клиенту.
Получается следующая схема потоков трафика:
Ну и заодно мы не забываем про VXLAN для bare metal и сейчас ведём разработку решения, позволяющего работать с сетью, используя эту технологию.
Пишем драйвер консоли для iDRAC
Без serial console траблшутинг bare metal был бы неполным, так как для пользователя она остаётся единственным способом подключения к серверу, если привычные варианты — SSH и RDP — вдруг оказываются недоступны. Проблема возникла при имплементации сервиса, когда стало понятно, что в Ironic отсутствует поддержка виртуальной консоли iDRAC. Чтобы всё же получить к ней доступ, нам пришлось самим написать драйвер. Для этого мы изучили имеющиеся драйверы в Ironic для работы с консолями iLo и IPMI, а затем написали собственное решение по схожему принципу. Получившийся драйвер отлично справляется со своими задачами, но только в тех случаях, когда образ пользователя умеет отдавать диагностику в COM-порт — к счастью, в современных версиях Linux и Windows проблем с этим не возникает даже из коробки. Вот только с виртуальной консолью проблемы на этом не кончились.
Следующая сложность возникла с проксированием портов самой консоли. За их работу отвечает компонент Nova — nova-serialproxy — принцип работы которого слегка отличается, но в целом схож с компонентом nova-novncproxy. Проблема обнаружилась на одном из этапов работы serial console, который организован следующим образом:
Пользователь запрашивает serial console в личном кабинете — создаётся запрос посредством REST API.
Компонент nova-api обращается к nova-compute для получения URL с валидным токеном и открытием веб-сокета на подключение.
API нашего личного кабинета получает этот URL и делает по нему обращение уже непосредственно в nova-serialproxy.
Затем происходит проксирование запроса nova-serialproxy к ironic-conductor на порт физического сервера для подключения к его виртуальной консоли.
Вот наглядное описание этой цепочки действий:
Проблема возникала на четвёртом этапе — иногда в этот момент пользователи в течение непродолжительного времени получали ошибку «Address already in use». Мы не сразу поняли, с чем связано такое поведение, так как обнаружить порт консоли занятым каким-то другим процессом в списке прослушиваемых портов нам никак не удавалось. Первым делом мы решили изучить socat, с помощью которого осуществлялось взаимодействие с виртуальной консолью от контроллера. Однако, найти корень проблемы так и не получалось, в том числе из-за того, что на момент обращения пользователей в службу поддержки ошибки уже не возникало. Но однажды нам повезло: в тот раз проблема никак не решилась сама собой и ещё была актуальна, когда клиент о ней сообщил.
Тогда нам удалось обнаружить, что HAproxy на контроллерах проксирует соединение к БД, где ему для инициализации подключения назначался порт консоли. Решение оказалось довольно простым: мы стали резервировать порты с помощью параметра ядра net.ipv4.ip_local_reserved_ports и выбрали диапазон в плоскости 48 тысяч, где конечный порт для консоли в момент подготовки сервера для аренды автоматически указывался в соответствии с последним октетом iDRAC-адреса.
Шаг 5: запускаем bare metal во всех регионах публичного облака
В результате этих работ из служебного компонента нам удалось сделать полноценный сервис в составе публичного облака. Останавливаться на этом мы не планируем и первым делом расширяем географию присутствия облака: теперь, помимо виртуальных машин, во всех новых регионах мы сразу будем предоставлять и выделенные серверы. Развиваться будет и сам сервис: в ближайшие полтора года мы планируем создать решения на базе серверов bare metal для работы с большими данными и CaaS-сервисами, в том числе с Managed Kubernetes, а также внедрить возможность разворачивать приложения из нашего маркетплейса на выделенных серверах. Подробней обо всём этом мы ещё расскажем отдельно — stay tuned.