Развитие виртуализации в Авито: от bare-metal серверов к Proxmox VE

Развитие виртуализации в Авито: от bare-metal серверов к Proxmox VE

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

История развития IT-платформы Авито с 2007 по 2026 год иллюстрирует этот путь. Каждый этап эволюции определялся не поиском абстрактно «современных» продуктов, а решением конкретных технических проблем — нехватки плотности размещения, медленной выдачи сред для разработчиков, ограничений изоляции и сложности операционного контроля.

Первые шаги: физические сервера и приход OpenVZ

В 2007 году инфраструктура проекта начиналась с нескольких изолированных физических серверов — bare-metal оборудования. Нагрузочное окружение и рабочая версия сайта (production) разделялись физически: отдельные системные блоки выполняли роль веб-серверов и баз данных. При ежемесячной аудитории около 130 тысяч уникальных посетителей такой подход обеспечивал максимальное действие железа без накладных расходов. Однако выделение ресурсов происходило вручную, а запуск новых компонентов требовал покупки и монтажа дополнительного оборудования.

К 2010 году рост нагрузки заставил перейти к первой системе виртуализации на базе OpenVZ. Эта технология контейнерного типа позволяет создавать изолированные виртуальные среды (VPS) поверх единого ядра операционной системы Linux. Команда развернула порядка 20–30 контейнеров под управлением 3–4 сетевых балансировщиков.

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

Эпоха LXC и автоматизация переноса окружений

В 2013 году на смену OpenVZ пришла технология LXC (Linux Containers). В отличие от предшественника, LXC опирается на штатные механизмы ядра Linux — пространства имен (namespaces) для изоляции процессов и контрольные группы (cgroups) для лимитирования оперативной памяти и процессора. Это исключило необходимость использования модифицированных ядер и повысило стабильность оборудования.

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

1. Остановка контейнера OpenVZ и создание архива его файловой системы (rootfs).
2. Перенос архива на новый физический сервер с LXC и распаковка в целевую директорию.
3. Изменение сетевого виртуального интерфейса с venet на стандартный eth0.
4. Корректировка системных файлов конфигурации сети (resolv.conf и fstab).
5. Отключение неиспользуемых системных служб внутри изолированного окружения через режим chroot.

К 2016 году инфраструктура Авито насчитывала сотни LXC-контейнеров, а основной программный монолит превысил один миллион строк кода.

Пределы контейнеризации и гибридный период

К 2017 году контейнеры перестали перекрывать все потребности платформы. Главными ограничениями LXC стали предел размещения (не более 64 контейнеров на один сервер того времени) и невозможность применения бесшовной миграции в реальном времени (live migration) без остановки обслуживания пользователей. Кроме того, отдельные корпоративные системы требовали запуска полностью независимых операционных систем.

В инфраструктуре начался гибридный период. Для задач глубокой изоляции и эмуляции оборудования были внедрены гипервизоры — специализированное ПО QEMU/libvirt и решения VMware. При этом основной веб-код продолжал работать в 300–500+ LXC-контейнерах, распределенных по 50+ физическим серверам. Сосуществование различных систем показало, что крупные сервисы редко эксплуатируют одну универсальную технологию: разные типы нагрузки требуют собственных инструментов виртуализации.

Переход к Proxmox VE и распределенному хранилищу Ceph

Современный этап развития инфраструктуры Авито строится на базе Proxmox VE (PVE) — открытой платформы управления кластерами виртуализации. Выбор PVE был обусловлен наличием удобного интерфейса, нативной поддержкой отказоустойчивых хранилищ Ceph, интеграцией с централизованной системой аутентификации LDAP и развитым сообществом.

В связке с Proxmox VE используется распределенная система хранения данных Ceph и ее блочный модуль RBD (RADOS Block Device). Ceph разбивает виртуальные диски на мелкие фрагменты и дублирует их по сети между несколькими физическими узлами. Если один из серверов выходит из строя, виртуальная машина автоматически перезапускается на здоровом узле без потери данных на диске.

Текущая архитектура включает более 20 независимых PVE-кластеров. Каждый кластер состоит из 15 гипервизоров (по 5 серверов в трех дата-центрах). Дисковые пулы Ceph обслуживают хранение данных, а автоматическое управление инфраструктурой выполняется через концепцию «инфраструктура как код» (IaC) с помощью Puppet и собственных REST API сервисов.

Сравнительный анализ этапов развития инфраструктуры

Уроки сетевой связности и инженерные риски

Один из главных выводов эксплуатации Proxmox VE касается работы сетевого сервиса Corosync, отвечающего за поддержание кворума между узлами кластера. В ранней конфигурации из 32+ гипервизоров все служебные команды и репликация данных передавались по единой сетевой карте с объединением каналов (bonding). В периоды высоких дисковых нагрузок служебный трафик Corosync задерживался, что приводило к ложным срабатываниям защиты и перезагрузке исправных серверов.

Инженеры решили эту проблему комплексом изменений:

• Горизонтальное дробление: отказ от монокластеров на 32+ узла в пользу кластеров по 15 гипервизоров.
• Оптимизация трафика: вынос конфигурационных данных виртуальных машин (pmxcfs) в профили управления Puppet.
• Доработка сторожевых сервисов: пересборка демона watchdog-mux с задержкой ожидания отклика от модулей высокой доступности (pve-ha-crm и pve-ha-lrm).

Официальный регламент проверки и чек-лист миграции

Для команд, планирующих внедрение Proxmox VE с хранилищем Ceph, официальная документация определяет порядок предварительной проверки и развертывания.

Обязательные условия перед началом работ:

1. Здоровое состояние хранилища: кластер Ceph должен находиться в статусе active + clean до создания любых блочных устройств.
2. Инициализация дискового пула: настройка пула выполняется официальной командой rbd pool init <имя_пула>.
3. Разделение прав доступа: в соответствии с принципом наименьших привилегий (least privilege), подключение виртуальных машин к Ceph выполняется под ограниченной учетной записью, а не под административным профилем admin.

Чек-лист безопасного перехода на кластерную виртуализацию:

• Инвентаризация и аудит: составление списка сервисов, зависимостей операционных систем и сетевых портов.
• Проверка резервного копирования: пробное восстановление данных из бекапа на изолированном стенде.
• Выделение служебной сети: организация отдельного сетевого интерфейса исключительно для трафика Corosync.
• Пилотная миграция: запуск некритичного сервиса с измерением задержек ввода-вывода (I/O) и проверкой поведения при имитации отказа узла.
• Документирование плана отката (rollback): фиксация сценария возврата нагрузки на исходное оборудование при обнаружении задержек.

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