Как мы приручили vGPU до режима авто без проблем

Привет, Хабр! На связи снова команда виртуализации платформы Astra Cloud. Решили рассказать, как мы укрощали тяжелую графику — от первых экспериментов до полноценного релиза.

Запрос от заказчиков звучал железобетонно: «Хотим тяжелую графику в виртуализации, как на рабочей станции, но чтобы управлялось централизованно». Мы ответили: «Сделаем». Как будто были другие варианты, ха!

Путь от «пощупать» до «выкатить в релиз» занял около года. Вот как это выглядело в фактах:

• эксперименты, ручное развертывание, первые восторженные крики «Оно работает!»;

• взялись за автоматизацию: написали скрипты, интеграцию с порталом, поняли, что ручной режим — это боль;

• выкатили первый полноценный релиз с vGPU в составе облачной платформы, и автоматизация наконец победила рутину;

• двигаемся дальше: расширяем поддержку GPU, улучшаем мониторинг, готовим новые фичи.

У нас только проверенные комбинации

Прежде чем рассказывать, как все устроено в теории — расскажем, на чем это работает у нас. Мы перепробовали разные конфигурации, железо и подходы, чтобы vGPU на нашей платформе работало не «вроде как», а стабильно и предсказуемо. 

В основе виртуализации — Astra Linux Special Edition (очередное обновление с поддержкой vGPU мы делаем именно для нее). Гипервизор — KVM, который поверх нашей ОС дает надежную среду.  Видеокарты — NVIDIA: мейнстрим со зрелой экосистемой драйверов и утилит. Конкретные вендоры, на которых все это тестировали, — ASUS и YADRO.

Мы довольны результатами. Но главное, что наше решение не завязано на конкретных вендорах. У клиентов могут быть любые другие серверы с GPU NVIDIA. Мы внедряем и на них, все работает. Теоретически ограничений с x86-совместимым железом нет, но на практике нюансы иногда встречаются. Для таких случаев в «Группе Астра» существует проект Ready For Astra: он проверяет совместимость конкретного оборудования с нашими решениями. Если клиент хочет гарантированную поддержку, то мы можем протестировать его серверы и выдать официальное заключение.

Немного матчасти: как делят GPU

Кто в теме, можете этот блок пропустить. Мы добавили его на всякий случай. Итак…

Большинство современных решений для виртуализации графики работает на архитектуре NVIDIA Ampere (анонсирована в мае 2020 года). Именно она принесла тензорные ядра третьего поколения с поддержкой формата TF32: вычисления ускоряются до 10 раз без изменения кода. Говоря проще — тензорные ядра делают нейросети и тяжелую графику быстрее, что позволяет виртуальным GPU обеспечивать приемлемую производительность даже в shared-среде.

Теперь главный вопрос: как один физический GPU работает сразу с несколькими виртуальными машинами? У NVIDIA два подхода.

Режим общего пула (Time-sliced vGPU) — самый распространенный

GPU очень быстро переключает контекст между ВМ, выделяя каждой строго определенный квант времени. Память (framebuffer) статически делится между всеми ВМ, переподписка VRAM невозможна. Одна карта NVIDIA A10 обслуживает до 24 concurrent vGPU-сессий.

+ гибкость: если одна ВМ не нагружает GPU, ее «свободные кванты» перераспределяются между другими. Идеально для неравномерной нагрузки: VDI-пулы с AutoCAD, Blender, среды разработки.

— меньшая предсказуемость: полностью исключить влияние «шумного соседа» нельзя.

Режим изолированного пула (MIG) появился вместе с Ampere

GPU нарезается на полностью изолированные экземпляры — каждому свои вычислительные ядра (SM), кэш L2 и контроллеры памяти. Например, одну физическую A100P или H100 с памятью 80 ГБ можно нарезать на 7 логических по 1g.10gb или создать одну крупную конфигурацию 3g.40gb для самых требовательных задач.

+ предсказуемость и аппаратная изоляция: ни одна соседняя ВМ не «украдет» ваши ресурсы. Идеально для high-end сценариев. Например, инференса LLM, где критична стабильность задержек.

— статичность: ресурсы делятся раз и навсегда, неиспользуемые мощности не перераспределяются в пользу соседа.

Важный нюанс для администраторов Windows и Linux

Здесь кроется подводный камень, о котором часто забывают. MIG — технология сугубо для вычислений (CUDA). MIG-backed vGPU-профили не работают с гостевыми ОС Windows. Если ваша задача — предоставить пользователям виртуальные рабочие столы (VDI) с графикой NVIDIA, ваш выбор классический time-sliced vGPU.

Тяжелая артиллерия в облаке

Вернемся к нашей практике. Так вот, связка vGPU с Astra Cloud Platform открывает для наших пользователей несколько крутых сценариев. 

Во-первых, полноценная работа с «тяжелой» графикой в облаке. Виртуальные рабочие станции с vGPU идеально подходят для:

• инженерных CAD-приложений (3D-моделирование, проектирование);

• работы с графическими редакторами и видео;

• задач, связанных с обработкой больших объемов визуальных данных.

Во-вторых, автоматизация там, где она реально нужна. Это ключевое отличие от «ручного режима». Администратор или разработчик может заказать и развернуть ВМ с vGPU в пару кликов, просто выбрав нужный профиль и параметры. 

В-третьих, интеграция с «Боцманом» — платформой контейнеризации «Группы Астра». В перспективе это откроет сценарии с гетерогенными приложениями, где часть компонентов работает с GPU, а часть — в легковесных контейнерах. 

На текущий момент поддерживается полная конфигурация в режиме time-sliced, vGPU MIG от NVIDIA пока не реализована через веб-интерфейс.

Мы естественно не останавливаемся на достигнутом. В ближайших планах по этому направлению:

• Горячая миграция ВМ с vGPU — появится в следующей версии с обновлением ОС Astra Linux Special Edition.

• Планирование ресурсов — администраторы смогут создавать GPU пулы для тенантов, кластеров и отдельных ВМ в рамках конкретного гипервизора.

• Распределение ресурсов по группам — возможность разграничивать доступ к GPU-ресурсам на уровне групп доступа. 

• Квотирование и аккаунтинг (учет потребления) — чтобы понимать, кто, сколько и на что тратит GPU-ресурсы. Это и для биллинга, и для внутренней оптимизации.

Под капотом дела такие

!!! Внимание, сугубо техническая информация, всем настроится на восприятие.

Для размещения ВМ с ресурсами vGPU платформа виртуализации должна постоянно располагать актуальными данными о состоянии GPU на узлах кластера. Для этого на каждом гипервизоре, оснащенном GPU с поддержкой vGPU, формируется информация о доступных ресурсах:

• Наличие Virtual Function (VF) — предоставляемых технологией SR-IOV независимых виртуальных устройств, которые разделяют ресурсы единого физического устройства (в нашем случае — GPU);

• Доступные профили VF;

• Количество свободных VF в данный момент.

Далее вступает в работу встроенная система мониторинга: она выполняет сбор данных о vGPU с помощью специального модуля и передает их на сервер управления для использования в процессе размещения ВМ.

Когда пользователь выполняет запрос о создании ВМ, планировщик системы виртуализации автоматически (аналогично логике поиска PCI passthrough устройств) проверяет гипервизоры на наличие всех требуемых компонентов vGPU (тип VF, соответствие запрошенному профилю, достаточное количество свободных VF).

Как только подходящий узел определен специально для таких случаев Linux- фреймворк Mediated Device создает новое mdev-устройство, использующее ресурсы родительского физического GPU. Это устройство и будет использоваться гипервизором для подключения к процессу ВМ, и далее —  в гостевой ОС в качестве графического адаптера.

Важная функция платформы — поддержка высокой доступности ВМ (High Availability, HA) —  также использует описанный выше алгоритм планировщика. При сбое узла виртуализации и необходимости перезапуска ВМ на новом узле, планировщик ищет хост с подходящим набором доступных ресурсов vGPU и размещает ВМ без потери предоставляемых функций.

vGPU в облачном интерфейсе

Вы справедливо можете сказать: «Звучит заманчиво — а как это настраивается?». Показываем. 

После подключения и предварительной настройки узла виртуализации функционал vGPU полноценно доступен в системе управления виртуализацией Astra Cloud. Видеокарты видны в интерфейсе и назначаются на ВМ — без ручных операций на гипервизоре.

Выделить ресурс vGPU для ВМ можно двумя способами.

При создании шаблона ВМ. В разделе ввода-вывода появился отдельный блок vGPU — рядом с привычным механизмом назначения PCI-устройств. Там выбирается тип устройства и поддерживаемый профиль из списка. После создания шаблона каждая машина, развернутая по нему, автоматически получает свой экземпляр vGPU.

*Минутка гордости) Поддержка ресурсов GPU в шаблоне — мощный инструмент, активно применяемый в задачах массового развертывания ВМ. Нашей главной целью была именно автоматизация процесса назначения виртуальных устройств — и реализованное решение позволило полностью уйти от необходимости в ручных действиях при распределении ресурсов.

Для уже созданной виртуальной машины. В разделе изменение конфигурации ВМ — подключить можно в любой момент, не пересоздавая ВМ.

Сейчас поддерживаются типы профилей vGPU-Q, vGPU-B. 

Профили типа A и C тестирования не проходили и не имеют официальной поддержки. Расширение списка — в планах, но пока не в приоритете: если вашему сценарию нужен другой профиль, напишите нам — это поможет поднять задачу в бэклоге. 

Лицензирование vGPU. С подвохом ли вопрос?)

Все знают, что официальные лицензии NVIDIA vGPU — штука недешевая и не всегда удобная в приобретении. У нас же клиенты часто спрашивают: «А можно как-то проще?»

Мы не продаем лицензии напрямую. Вместо этого мы предоставляем клиентам возможность решать этот вопрос через наших партнеров. У «Группы Астра» имеется целая сеть проверенных, которые помогают с лицензированием, как с получением, так и с сопровождением. Либо клиент может обратиться к своему привычному интегратору, и тот уже разрулит все формальности. 

Мы даем гибкость и это осознанное решение. Вот такие пироги.

Вопросы, уточнения — все в комментарии. Готовы ответить.