bare metal server что такое
Что такое «облако в bare metal»?
Определенное снижение производительности на уровне конечного пользователя происходит из-за внедрения слоя гипервизора. В то время как гипервизор обеспечивает видимость, гибкость и возможности управления, требуемые для управления несколькими машинами на одной «железке», он также привносит и определенные затраты процессорной мощности.
Для приложений, требующих высокий уровень пропускной способности для данных, изрядные проблемы может создать эффект «шумного соседа», который может быть вызван виртуализированной облачной средой.
В виртуализированной облачной среде виртуальные машины «сражаются», например, за мощности ввода-вывода в системах с интенсивной обработкой данных.
ЧТО ТАКОЕ BARE METAL-ПОДХОД К СОЗДАНИЮ ОБЛАКОВ?
Идея bare metal состоит в использовании выделенных серверов для создания облаков. Этому словосочетанию еще не придумали адекватного перевода на русский язык, в некоторых источниках встречается «голое железо» или «чистое железо».
В среде bare metal виртуальные машины инсталлируются прямо на железо, а не в хост операционной системы.
Облако на «голом железе» обеспечивает возможность заменить виртуальную облачную среду средой с выделенными серверами, что дает возможность «сэкономить» ресурсы на виртуализации, не жертвуя при этом гибкостью, масштабируемостью и эффективностью. Сервера bare metal не содержат гипервизор, и не виртуализированы, но могут быть предоставлены в пользование клиенту через подобную облаку модель услуг.
Bare-Metal Deployment — или как обеспечивается эластичность облака в System Center 2012 SP1 Virtual Machine Manager
Всем огненного понедельника, коллеги и энтузиасты!
Сегодня, 29 апреля, понедельник — до праздников осталось совсем немного — и почему бы немного не пополнить багаж знаний перед долгожданным отдыхом (ну в формате лайт — без жестких и заумных нравоучений). На этот раз хотелось бы немного поговорить про то, как устроена функции Bare-Metal развертывания гипервизоров на сервера — или, другими словами — как обеспечить автоматизацию эластичности вашего частного облака на базе System Center 2012 SP1.
Более подробно под катом.
Немного об облаке, об эластичности
Прежде чем подробно и детально рассказать про процесс «голо-железного развертывания», стоит немного уделить внимания, той характеристике, той особенности облачной модели, которую покрывает данный процесс. Давайте вспомним про основные характеристики облачной модели согласно NIST (National Institute of Standards and Technology). Чтобы не нагонять тоску, перечислю сразу все основные отличительные особенности облака от традиционной модели потребления ИТ.
1) Измеряемы услуги. Подразумевается, что любая услуга которая предоставляется через облака должна быть измеряема, что в конечном счете ведет к тому, что у услуги появляется стоимость — в результате измеряемость служит инструментом для билинга ИТ-сервисов.
2) Моментальная эластичность. Данный компонент подразумевает то, что облако, независимо от уровня модели услуг (IaaS, PaaS или SaaS), должно быть способным к моментальному (относительно моментальному) увеличению или уменьшению объема своих ресурсов. Именно про увеличение объема ресурсов с точки зрения эластичности мы сегодня с вами и поговорим в контексте SCVMM 2012 SP1. Ведь автоматизация процесса развертывания гипервизоров и включения их в хост-группы и облака является ничем иным как обеспечением эластичности в сторону увеличения объема ресурсов.
3) Пул ресурсов. Очень важной особенностью облака является абстракция от физических хостов, как ресурсов, до уровня их вычислительных мощностей. Иными словами теперь для получения сервиса или услуги вы учитываете не количество серверов, но объем их ресурсов, которые сгруппированы по категориям — ЦП, ОЗУ, Дисковые ресурсы и сети передачи данных — все основные объекты виртуализации, которые нам давно известны.
4) Широкополосный доступ. Вещь вполне естественная, так как мы с вами говорим про «очень клиент-серверную», даже правильнее сказать сервис-ориентированную архитектуру (SOA) — то нагрузка и требования к каналу передачи данных сильно возрастает — причем это справедливо как для провайдера (ему нужно обеспечить множество качественных подключений), так и со стороны клиента (объем трафика для обмена сильно возрастает при такой модели).
5) Самообслуживание по требованию. Под данным постулатом подразумевается наличие инструмента для либо автоматизированного, либо полностью автоматического процесса предоставления услуги или сервиса конечному пользователю. Обычно этим инструментом служит веб-портал, который служит интерфейсом между конечным пользователем и процессами оркестрации (автоматизации рабочего потока), вовлеченных в предоставление и развертывание конкретного сервиса или услуги.
Bare-Metal или «Голожелезяк»
Теперь, когда мы с вами вспомнили про основные характеристики облака, мы поняли также какое место в облачных характеристиках занимает процесс BMD (Bare-Metal Deployment), самое время рассмотреть его более подробно.
Что можно, а что нет?
Прежде чем разобрать процесс развертывания гипервизора на голое железо, неполохо было бы ознакомиться с требованиями к данному процессу.
Вкратце — нам нужны сервера с BMC-котроллером (например, iLO, iDRAC, SMASH, IPMI и прочие), а также учетные данные для доступу к серверу через этот самый контроллер.
PXE-сервер на базе Windows Server 2008 R2 или Windows Server 2012 также будет далеко не лишним, а необходимым компонентом.
Также нам очень будет нужен установленный пакет WAIK — Windows Automation and Installation Toolkit.
Также нам понадобиться генерализированный образ гипервизора (Windows Server 2008 R2 или Windows Server 2012 — Hyper-V Server тоже подойдет) в формате виртуального жесткого диска VHD.
Не стоит также забывать, что вы должны включить функции виртуализации на процессорах вашего сервера, активировать BMC-контроллер и знать его учетные данные для доступа, а также настроить сервер на загрузку через сеть с помощью PXE.
Если взглянуть на процесс последовательно, то картина будет такая.
1) VMM-серверу необходим компонент WAIK c подготовленным образом WInPE.
2) Далее нам, как я уже говорил, понадобиться развернутый сервер WDS (Windows Deployment Services).
3) DHCP-сервер также нам понадобиться для выдачи IP-адресов.
5) Далее VMM установит своего агента на сервере WDS.
6) Далее на WDS-сервере будет создана папка %WDS_Image_Source%\RemoteInstall (т.е. в директории где у вас хранятся образы на WDS-сервере будет создана поддиректория RemoteInstall для служебных целей).
7) Далее кастомизированный образ WInPE от VMM-сервера публикуется на сервере WDS — под процессом публикации подразумевается внедрение в образ VMM-агента и сертификата безопасности).
На данный момент времени мы рассмотрели с вами процесс настройки конфигурации.
Сам процесс
1) Перезагрузка через OOB (Out-of-Band Management). Здесь как раз сервер VMM использует свои нативные возможности общения с внешними BMC-контроллерами серверов — конкретно он отправляет сигнал на перезагрузку сервера.
2) Далее целевой сервер загружается через PXE и хочет получить загрузку с нашего WDS-сервера.
3) Прежде чем предоставить возможность целевому серверу через PXE, WDS-сервер авторизует загрузку в VMM-сервере.
4) После этого целевой сервер получает от WDS-сервера кастомизированный WinPE-образ.
5) После этого целевой сервер запускает скрипты на исполнение команд общего назначения (GCE-скрипты — General Command Execution). Этот момент очень важный, так как включает в себя обновление прошивок вашего сервера в автоматическом режиме, управление RAID-контроллером вашего сервера для создания разделов жесткого диска и прочее. Все эти параметры задаются в профиле хоста в VMM-сервере.
6) Далее происходит загрузка VHD-образа с необходимым нам гипервизором из библиотеки VMM.
7) После добавляются драйвера необходимые для конкретной модели оборудования.
8) Далее происходит процесс установки сервера, его настройки и включения в домен.
9) Установка VMM-агента и включение роли Hyper-V.
10) Исполнение дополнительных пост-инсталляционных скриптов. Примерами таких скриптов могут служить механизмы объединения сетевых адаптеров в агрегаты, настройки iSCSI-соединений. Такими примерами могут служить любые команды на удаленное исполнение.
Я упомянул по ходу статьи такие слова, хост-профили или профили хостов, а также про VHD-диск, который необходим для развертывания.
Давайте более подробно посмотрим как настроить профиль хоста и связать его с VHD-диском.
2) Введите имя профиля.
3) Выберите необходимый VHD-образ с гипервизором Hyper-V нужной версии (кстати, для развертывания на голое железо VMM может похвастаться только поддержкой Hyper-V — другие гипревизоры он не может разворачивать).
4) В области настройки оборудования перейдите к пункту фильтрации драйверов Driver filter и укажите метку драйвера для ваших серверов.
5) Во вкладке настройки ОС укажите всю необходимую информацию.
6) В поле настроек хоста можно ничего не трогать и нажать клавишу Next и на вкладке Summary — нажмите клавишу Fininsh для завершения процесса создания профиля хоста.
Теперь давайте рассмотрим процесс развертывания хоста на железку в данном случае на Dell R710.
2) В пункте расположения ресурсов выберите “Physical computer to be provisioned into Hyper-V” и нажмите Next.
3) Далее введите данные для получения административного уровня доступа к вашему BMC-контроллеру (рекомендую даже создать «Run As» учетку для того чтобы руками это постоянно не делать — я про производственную среду).
В данном случае я выбираю протокол IPMI.
4) В области обнаружения (Discovery Scope) укажите IP-адрес, сконфигурированный на BMC-контроллере.
5) На целевых ресурсах (Target Resources) VMM должен сказать «сервере детектед!»
6) После этого в опциях развертывания (Deployment Options) укажите имя, которое вы вводили или у вас оно задано для BMC-адаптера.
7) После этого проверьте все данные на валидность и нажмите Finish для того, чтобы приступить к процессу развертывания сервера — можно идти и пить кофе!
Небольшой итог
Итак, коллеги, — мы с вами рассмотрели как работает функция автоматического развертывания гипервизора Hyper-V на голое железо с помощью инструментов SC VMM и компонентов Windows Server. Также мы с вами обсудили какую важную задачу с точки зрения облачной модели предоставления и потребления услуг решает данный механизм. Остается надеется, что в будущих версиях можно будет и сторониие гипервизоры также заливать на железо — это на случай гетерогенных сценариев. Но, невозможных вещей не бывает — на сегодняшний день вы сможете решить эту задачу с помощью System Center Configuration Manager, но это уже другая история…
С уважением,
человек-огонь
Георгий А. Гаджиев
Эксперт по информационной инфраструктуре
Microsoft Corporation.
Bare-Metal Provisioning своими руками, или Автоматическая подготовка серверов с нуля
Привет, я Денис и одно из моих направлений деятельности – разработка инфраструктурных решений в X5. Сегодня хотел бы поделиться с вами о том, как можно на базе общедоступных инструментов развернуть автоматическую систему подготовки серверов. На мой взгляд, это интересное, простое и гибкое решение.
Под подготовкой подразумевается: сделать из нового сервера из коробки, полностью настроенный сервер с о.с. Linux или c гипервизором ESXi (разливка серверов Windows в данной статье не обсуждается).
Зачем нужна автоматизация?
Допустим, есть задача: массово подготавливать сервера с нуля, в пике – 30 в день. Сервера разных производителей и моделей, на них могут устанавливаться различные ОС, может иметься или отсутствовать гипервизор.
Какие операции входят в процесс настройки (без автоматизации):
Суть автоматизации – исключить участие человека из процесса подготовки сервера. Максимально, насколько это возможно.
Благодаря автоматизации сокращается время простоя между операциями и появляется возможность подготовить несколько серверов одновременно. Также сильно снижается вероятность возникновения ошибок из-за человеческого фактора.
Как происходит автоматическая настройка серверов?
Разберем все этапы детально.
У вас есть linux-сервер, который вы используете в качестве PXE инсталл-сервера. На нем установлены и настроены службы: DHCP, TFTP.
Итак, загружаем сервер (который необходимо настроить) по PXE. Вспомним, как это работает:
Рассмотрим пример конфигурации PXE-сервера (меню pxelinux).
Ядро и initramfs на данном этапе – это промежуточный linux-образ, с помощью которого и будет происходить основная подготовка и настройка сервера.
Как вы видите, загрузчик передает много параметров ядру. Часть этих параметров используется самим ядром. А некоторые мы можем использовать для своих целей. Об этом будет рассказано далее, а пока можно просто запомнить, что все переданные параметры будут доступны в промежуточном linux-образе через /proc/cmdline.
Где их взять, ядро и initramfs?
За основу, можно выбрать любой linux-дистрибутив. На что обращаем внимание при выборе:
Итак, мы указали ядро и initramfs, которые должны быть загружены. В результате на данном этапе, загрузив промежуточный образ linux по PXE, мы получим консоль ОС.
Отлично, но теперь нужно передать управление нашей “автоматизации”.
Это можно сделать так.
Предположим, после загрузки образа мы планируем передавать управление в скрипт mount.sh.
Включим скрипт mount.sh в автозапуск. Для этого потребуется модифицировать initramfs:
Итак, загружается образ, в котором в автозапуске стартует скрипт mount.sh. Далее скрипт mount.sh в процессе выполнения анализирует переданные параметры (script_cmd=) и запускает необходимую программу/скрипт.
label toolkit-auto
kernel …
append … nfs_toolkit_script=scripts/mount.sh script_cmd=master-install.sh
label toolkit-shell
kernel …
append … nfs_toolkit_script=scripts/mount.sh script_cmd=/bin/bash
Здесь в левой части — меню PXE, в правой – схема передачи управления.
C передачей управления мы разобрались. В зависимости от выбора PXE-меню запускается либо скрипт автонастройки, либо консоль для отладки.
В случае автоматической настройки монтируются необходимые директории с инсталл-сервера, в которых присутствуют:
Дерево скриптов (порядок их запуска) выглядит примерно так:
Как идентифицировать сервер, который мы подготавливаем?
Здесь есть все, что нужно: вендор, модель, серийный номер. Если вы не уверены, что эта информация представлена во всех серверах, можете идентифицировать их по MAC-адресу. Либо обоими способами одновременно, если вендоры серверов разные и на некоторых моделях информация о серийном номере просто отсутствует.
На основе полученной информации монтируются сетевые папки с инсталл-сервера и подгружается все необходимое (утилиты, прошивки и прочее).
Какими утилитами и как конфигурировать сервер?
Приведу утилиты для linux для некоторых производителей. Все утилиты доступны на официальных сайтах вендоров.
С прошивками, я думаю, все понятно. Обычно они поставляются в виде упакованных исполняемых файлов. Исполняемый файл контролирует процесс обновления прошивки и сообщает код возврата.
BIOS и IPMI обычно настраиваются через шаблоны. При необходимости шаблон можно редактировать перед самой загрузкой.
Утилиты RAID у некоторых вендоров тоже могут настраивать по шаблону. Если это не так, то придется написать сценарий настройки.
Порядок настройки RAID чаще всего следующий:
Как получить настройки для конкретного сервера?
Предположим, настройки всех серверов будут храниться на инсталл-сервере. В таком случае, чтобы ответить на наш вопрос, нужно сначала решить: каким образом передавать настройки в инсталл-сервер.
На первых порах вполне можно обойтись текстовыми файлами. (В будущем можно использовать текстовый файл как резервный способ передачи настроек).
Можно «расшарить» текстовый файл на инсталл-сервере. И добавить его монтирование в скрипт mount.sh.
Строки будут, например, такого вида:
Эти строки будут передаваться в файл инженером с его рабочей машины. И далее при настройке сервера параметры для конкретного сервера будут прочитаны из файла.
Но, в перспективе, лучше, задействовать БД для хранения настроек, состояний и журналов инсталляций серверов.
Конечно, одной БД не обойтись, и потребуется создать клиентскую часть, с помощью которой будут передаваться настройки в базу. Реализовать это сложнее, по сравнению с текстовым файлом, но, на самом деле, все не так трудно, как кажется. Минимальную версию клиента, который будет просто передавать данные в БД, вполне посильно написать самому. А улучшать клиентскую программу в дальнейшем можно будет и в свободном режиме (отчеты, печать этикеток, отправка уведомлений и прочее, что придет в голову).
Сделав определенный запрос в базу и указав серийный номер сервера, получим необходимые параметры для настройки сервера.
Плюс, нам не потребуется придумывать блокировки для одновременного доступа, как в случае с текстовым файлом.
Журнал настройки можем на всех этапах писать в БД и процесс установки контролировать через события и флаги этапов подготовки.
Теперь мы знаем, как:
Что насчет разных типов устанавливаемого ПО? Как установить гипервизор, скопировать ВМ и настроить все это?
В случае развертывания образа файловой системы (linux) на железо все довольно просто:
Приведу здесь несколько строк из файла автоответов ks_esxi.cfg:
На этом этапе установлен и настроен гипервизор, скопированы виртуальные машины.
Как теперь настроить виртуальные машины?
Мы немного схитрили: во время установки задали параметр guestinfo.esxihost.id = «$SYSSN» в файле VM1.vmx, указали в нем серийный номер физического сервера.
Теперь после старта виртуальная машина (с установленным пакетом vmware-tools) может получить доступ к этому параметру:
То есть ВМ сумеет идентифицировать себя (она знает серийный номер физического хоста), сделать запрос к БД инсталл-сервера и получить параметры, которые нужно настроить. Это все оформляется в скрипт, который должен быть запущен автоматом при старте guestos vm (но однажды: RunOnce).
Теперь мы знаем, как:
Полагаю, уникальность данного решения в гибкости, простоте, его возможностях и универсальности.
Напишите, пожалуйста, в комментариях, что вы думаете.
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.