С начала декабря в режиме технического превью мы открыли доступ к Yandex BareMetal — сервису по аренде выделенных серверов.
Меня зовут Дмитрий Кравцов, я работаю в Yandex Infrastructure, разрабатываю инфраструктурные сервисы и сегодня покажу, как наши внутренние инструменты помогли нам лучше понять потребности клиентов облака. А также какие задачи нам нужно было решить, чтобы вывести сервис в продакшн, какие сценарии уже доступны для реализации, и какие возможности появятся дальше.
Сделать сервис, которым пользуешься сам
Представьте себе, что вы работаете в компании с активно растущей инфраструктурой. Вам повезло: у вас есть выделенная команда, которая занимается поддержкой и развитием необходимых инструментов для разработки. У вас даже есть своё облако, где можно быстро развернуть виртуальные машины (ВМ). Но специфика вашего приложения требует того, чтобы иметь доступ к железу.
Например, ваш сервис не cloud‑native, вам нужна L2-связность или аппаратная виртуализация, чтобы самому управлять параметрами гипервизора и более тонко и эффективно настраивать распределение ресурсов, а также создавать отказоустойчивые и масштабируемые конфигурации.
Когда речь идёт о командах Яндекса, у нас в этом случае есть преимущество — с такими задачами нам помогают ребята из Yandex Infrastructure, которые занимаются всем, на чём работают сервисы Яндекса, от дата‑центров и железа до сети и платформ разработки. У многих компаний таких возможностей нет. Так что нам было важно предоставить сервис, в котором уже учтён многолетний опыт инфраструктурных команд.
Какие очевидные и неочевидные трудности, по нашему опыту, могут возникнуть при аренде выделенных серверов:
Скорость получения и «наливки» серверов. В современном мире мало кто готов ждать нужное ему железо несколько дней, и даже bare metal хочется развернуть плюс‑минус за полчаса. Нужную преднастройку сервера, включая установку ОС и разметку дисков, хочется тоже получить в пару кликов.
В идеале нужно, чтобы клиент через простой интерфейс выбрал параметры и через полчаса после заказа получил сервер нужной конфигурации с настроенной сетью, публичным IP‑адресом, доступом по SSH и через KVM‑консоль.Долгий и сложный процесс оркестрации серверов. От момента установки в стойку и до выдачи пользователю сервер проживает целую жизнь — проходит преднастройку, разметку дисков, установку операционной системы, настройку сети, активацию базовых сервисов для пользователя. Такие комплексные процессы предполагают автоматизированное использование десятков микросервисов, и без грамотно построенной оркестрации тут не обойтись.
Поддержка нужных конфигураций сети и сетевых устройств. В случае аренды выделенных серверов дело осложняется тем, что у нас могут быть публичные и приватные сети с разными настройками. При создании или редактировании приватной маршрутизируемой подсети клиент обязательно должен выбрать пул и AZ. При этом хочется учитывать даже сложные конфигурации при обновлении и проводить сами обновления быстро.
Решение этих задач с нуля может занимать годы. Да, можно быстро придумать, как сделать это «на коленке»: взять базу данных и написать с нуля небольшое приложение, которое будет заниматься оркестрацией всех нужных процессов. Однако это сложно сделать надёжно: оркестрация должна быть максимально консистентной, уметь ретраить неудачные попытки, переживать различные сбои и деградировать умеренно при проблемах. А это в наших задачах не так легко, так как над серверами выполняется много различных операций, часть из них запускает пользователь, часть из них запрашивает клиент. Всё это помножено на несовершенство физического мира и аппаратные проблемы.
Инструменты инфраструктуры Яндекса и решения из опенсорс‑комьюнити пригодились нам, чтобы быстро и качественно решать эти задачи. В рамках обзора мы чуть подробнее остановимся на двух вещах:
Инструментах сетевой автоматизации Яндекса, которые помогают нам с решением задачи поддержки и быстрого изменения конфигураций сети и сетевых устройств
Temporal для оркестрации большого количества повторяющихся задач.
Инструменты сетевой автоматизации. Внутри Яндекса работает большая сетевая фабрика, поддерживаемая командами эксплуатации сети (NOC) и разработки (NOCDEV), где создаются сервисы для управления трафиком и работы над сетевым оборудованием. Коллеги уже не раз рассказывали, какие задачи можно решить с помощью таких инструментов сетевой автоматизации, как Annet или gnetcli. Так что мы решили взять лучшие наработки наших сетевых инженеров.
Annet — менеджер конфигураций сетевого оборудования, который уже знаком многим гостям наших конференций. Этот инструмент помогает автоматизировать обновление конфигурации на устройствах с учётом уже имеющейся истории предыдущих обновлений. Вместо того чтобы перезатирать ранее установленные настройки, Annet помогает сгенерировать нужную конфигурацию, сравнить её с текущей конфигурацией устройства, вычислить diff (разницу между конфигурациями), создать патч на основе diff и накатить его на оборудование.
В нашем сервисе нужно обслуживать много сетевых коробок разом, и сетевая фабрика, управляемая Annet, помогает сильно ускорить процесс обновления и сохранить гранулярность настройки. В нашей системе мы всегда имеем информацию об актуальных конфигурациях устройств и можем быстро накатить обновление по запросу клиентов на несколько устройств, как в параллельном режиме, так и в последовательном. Для этого мы даже построили отдельную от основного Яндекса и Yandex Cloud сетевую фабрику для Yandex BareMetal.
Основная задача Annet — собрать и выкатить diff конфигураций на устройство. Помимо непосредственно Annet для выкатки конфигураций на множество устройств мы используем и другие инструменты сетевой инфраструктуры Яндекса, которые реализуют многие полезные функции:
поддержка версионирования конфигураций;
поддержка выкатки конфигураций только на часть устройств (не на весь парк);
возможность роллбэка конфигураций одного или нескольких устройств.
Temporal нам нужен в первую очередь как механизм для асинхронного и надёжного выполнения большого количества зависимых задач с понятными гарантиями. Так, при работе с серверами есть много задач автоматизации:
налить ОС на сервер;
разметить диски, собрать RAID;
сконфигурировать сеть или изменить сетевые настройки;
поменять IP‑адрес на сервере;
выключить сервер;
перевести сервер в карантин и множество других.
Все эти задачи хочется решать надёжно, при этом не хочется разрабатывать свой собственный фреймворк для шедулинга абстрактных задач. Поэтому мы посмотрели на опенсорсные решения и решили попробовать Temporal. Для нас основными причинами такого выбора стали:
отличная интеграция с нашим приложением, написанным на Go;
возможность создавать workflow и activity, которые помогают решить все перечисленные выше задачи;
наличие очень удобной админки, в которой можно следить за всеми задачами, их статусами, анализировать ошибки;
возможность легко и просто получить логи/метрики/трейсы от наших тасок, что тоже ускоряет диагностику проблем.
Мы считаем, что это очень удобный инструмент, и рекомендуем его к использованию там, где вы хотите выполнять на вашем кластере различные задачи. Для нас Temporal отлично показал себя уже и в продакшн‑среде для реальных пользователей: с начала декабря мы запустили сервис в режиме Technical Preview, а до этого несколько недель сотрудники Яндекса были нашими самыми первыми пользователями в рамках внутреннего закрытого тестирования. О его итогах расскажу ниже.
Что показало внутреннее тестирование
Перед выходом в Technical Preview сервис Yandex BareMetal прошёл тестирование внутри Яндекса. Мы постарались максимально нагрузить серверы, проверить, насколько хорошо поддерживаются основные сценарии и насколько удобен интерфейс для их решения, собрать дополнительные запросы к возможностям сервиса, а также найти возможные пробелы в документации.
Как именно тестировали: просили пользователей развернуть свою собственную виртуализацию и оценить возможности физической L2-сети, а также использование таких сервисов облака, как Cloud Backup.
Для начала несколько забавных фактов по итогам тестов:
Всего за период тестирования мы выдали 112 серверов, вентиляторы на них суммарно накрутили за месяц 16 миллиардов оборотов.
Три самых популярных конфигурации оказались на 10G‑сети с SSD‑дисками. Суммарно это 83 сервера.
Максимальная зафиксированная температура процессора — 70°C.
Создано 33 маршрутизируемых приватных подсети и 60 изолированных L2-сегментов.
В пике по сети мы генерили 2,5 Гбит/с, суммарно прокачали немногим больше 10 ТБ.
За время тестирования мы заменили чуть меньше десятка жестких дисков и одну планку памяти.
Что смогли улучшить благодаря коллегам‑тестировщикам:
Добавили быструю переналивку ОС по кнопке. Иногда после долгих экспериментов с сервером хочется просто «начать сначала», а не заниматься ручной очисткой.
Ускорили перезагрузку сервера. Попытка загрузки сервера по сети отнимает много времени, но большинству пользователей она не нужна, поэтому по умолчанию мы её отключили.
Поддержали вставку из буфера обмена для iKVM. При отключенном SSH это единственный удобный способ исполнить сложную команду или ввести длинный пароль на сервере.
Какие сценарии уже показали клиентам на Yandex Scale
А что дальше?
Со 2 декабря сервис доступен в режиме Technical Preview, а это значит, что пользователи могут подать заявку и бесплатно протестировать сервис. На этом этапе клиентам доступны:
Клиентские ISO‑образы;
Мониторинг: сетевые и серверные метрики;
Бэкапы.
Весной 2025 года у пользователей Yandex BareMetal появятся новые возможности:
Интеграция с Cloud Interconnect, которая позволит создавать приватные сетевые соединения между локальной инфраструктурой и Yandex BareMetal.
Возможность работы через API/Terraform.
Также на следующих этапах мы планируем поддерживать новые высокопроизводительные конфигурации серверов. Запросить бесплатный доступ к сервису можно здесь — будем рады вашей обратной связи!