Когда виртуалки уже малы, а свой дата-центр рано: три конфигурации, которые мы собирали клиентам

У ключевой системы клиента время от времени проседала производительность: без явной причины, просто в какие-то моменты становилось хуже, а потом снова нормально. Классическая история для инфраструктуры на общих виртуальных машинах — соседей по гипервизору не видно, а их нагрузка иногда просаживает и вас.

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

Причём проблема редко настолько острая, чтобы сразу оправдать закупку своего железа, но и терпеть её бесконечно тоже не вариант. Дальше расскажем про три реальные конфигурации, которые мы собирали для клиентов с похожими запросами: ни одна не была придумана под красивую презентацию, каждую делали под конкретную задачу.

К этой развилке бизнес обычно приходит по одной из трёх причин. Нужна гарантированная производительность для ключевых систем вроде ERP, баз данных или аналитических платформ; важны гибкость и быстрое масштабирование; либо в приоритете контроль затрат и предсказуемая экономика инфраструктуры.

Свой сервер — это полный контроль, но и полная ответственность. Закупка, настройка, администрирование и соответствие требованиям регуляторов остаются на стороне компании, вместе с капитальными затратами и нужной экспертизой в команде. Даже если бюджет на своё железо найдётся, от этой ответственности он не избавляет.

Облачные виртуальные машины — противоположность: ресурсы поднимаются почти мгновенно, оплата гибкая, а по экономике и расширению это самый гибкий из всех вариантов. Но из-за общей виртуализации нет контроля над нагрузкой на конкретный гипервизор в моменте времени, отсюда и «плавающие» проблемы с производительностью.

Средний вариант — арендовать физическое, но не своё железо: изолированный сервер за минуты, без капитальных вложений, а обслуживание остаётся на стороне вендора. У нас в облаке жизненный цикл таких серверов автоматизирован — разворачивается и выводится из аренды автоматически, без ручных операций. Это и есть сервис Bare Metal от VK Cloud, дальше будем называть его просто «выделенные серверы», чтобы не превращать разбор в рекламный буклет.

Клиент пришёл с задачей стабилизировать сеть под серьёзной нагрузкой: нужна была предсказуемая пропускная способность и контролируемое распределение трафика по серверам, с возможностью быстро масштабироваться при росте нагрузки.

Под это мы развернули инфраструктуру из больше 50 выделенных серверов. Настроили три вещи: маршрутизацию публичного трафика через аппаратную сетевую фабрику, аллокацию собственных IP-адресов клиента (BYOIP) и приватную связность с виртуальной частью инфраструктуры.

Итог: инфраструктура уже сейчас стабильно держит свыше 300 Гбит публичного трафика, а при необходимости пропускную способность можно быстро нарастить до нескольких Тбит.

Отдельного упоминания заслуживает компонент ISP Router: через него мы подключаем к нашей сетевой фабрике чужую, не связанную с нами автономную систему клиента. Физически всё это работает как единая сеть: L2-связность соединяет выделенные серверы и виртуальные машины, VXLAN-транспорт в фабрике доходит от оборудования на уровне выделенных серверов до гипервизоров, а VLAN — до порта самого физического оборудования. В итоге получается один гибридный SDN на всё облако.

Что переносимо: если пиковый трафик регулярно упирается в потолок обычной виртуальной сети, а рост нужно закладывать не «на всякий случай», а с реальным запасом, точечный тюнинг архитектуры тут не спасёт. Нужна более жёсткая сетевая основа под ней.

Ещё один запрос пришёл от Skillbox. Компании нужно было перенести собственные приложения в облако, но сохранить привычную среду управления виртуальными ресурсами и не трогать CI/CD-процессы и контроль над инфраструктурой.

Мы развернули несколько compute- и storage-кластеров на выделенных серверах, выделили отдельные машины под базы данных и настроили объектное хранилище под бэкапы. Связность между сетевой фабрикой, проектом клиента в облаке и физическими серверами обеспечили через L2 Direct Connect.

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

Сейчас приложения Skillbox работают в виртуализации, которую полностью контролируют инженеры компании — с той же средой управления и теми же процессами, что были до переезда.

Что переносимо: если у вас уже есть своя платформа виртуализации, будь то VMware, Kubernetes или что-то самописное, и вы не готовы её ломать ради переезда в облако, разверните её поверх выделенных серверов. Так вы получите контроль привычной среды и инфраструктуру без капитальных вложений.

Третий клиент строил инфраструктуру под GPU-нагрузки. Нужны были изолированная среда с быстрым обменом данными между узлами и приватный доступ к данным: обмен между GPU-узлами и хранилищем не должен был идти через публичную сеть.

Мы развернули несколько GPU-серверов, соединили узлы через InfiniBand, вывели сервисный трафик на отдельный Ethernet-контур и настроили Private Link до S3.

InfiniBand здесь ключевая деталь: технология объединяет несколько физических машин в единое вычислительное пространство и убирает узкое место, свойственное обычному сетевому протоколу Ethernet. Это критически важно для задач вроде распределённого обучения нейросетей или рендеринга, где задержка при обмене данными между видеокартами разных серверов может свести на нет всю мощность железа.

Что переносимо: если вы уже упёрлись в задержки сети между GPU-узлами, физическая инфраструктура с InfiniBand нужна не ради избыточности: без неё часть вычислительной мощности будет просто простаивать.

Задачи разные, но сценарий один и тот же: команда упирается в потолок обычной виртуализации: по сети, по контролю над окружением или по доступу к железу. А свой сервер упирается в сроки и капитальные траты.

Три сигнала, что стоит присмотреться к выделенным серверам:

Причём в реальности редко получается «или одно, или другое». У клиентов, с которыми мы работали, выделенные серверы чаще дополняют обычные облачные ВМ в гибридной инфраструктуре, чем полностью их заменяют.

Это не универсальный ответ на все задачи, и сказать об этом стоит прямо, без реверансов в сторону маркетинга.

Поддержка уровня операционной системы и приложений всё равно остаётся на стороне клиента: провайдер отвечает за железо и его доступность, а дальше — ваша зона.

Если инфраструктуру нужно быстро и дёшево растягивать и сжимать, по деньгам и по масштабированию гибче именно облачные виртуальные машины, а не физические серверы. Плавающая производительность на гипервизоре — реальная плата за эту гибкость.

Физические серверы имеет смысл брать там, где важны предсказуемая производительность, изоляция или прямой доступ к GPU. То же самое касается случаев, когда этого требуют регуляторы, разрешающие работать только с подконтрольным оборудованием. Для остальных сценариев у обычных виртуалок больше гибкости и ниже порог входа.

Был ли у вас момент, когда виртуалки переставали справляться, а свой дата-центр ещё не окупался? Расскажите в комментариях, чем в итоге закрыли этот разрыв.

Особенно интересно, если в итоге получился гибридный вариант: часть нагрузки на облачных ВМ, часть — на физическом железе. Как вы делили нагрузку между ними?