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

Александр Васин

Ведущий разработчик в ГК Юзтех

Меня зовут Александр Васин, я ведущий разработчик в компании «Юзтех». Предлагаю поговорить об одной из главных болей современного мира IT, игнорировать которую довольно скоро станет невозможно — оптимизации IT-инфраструктуры. Здесь, на Хабре, я планирую написать цикл статей на эту тему, а начать предлагаю с основы: как возникли цифровые серверы, почему их стало не хватать, как мы решили помочь индустрии и создать информационный продукт Octopus, а также с какими проблемами столкнулись на пути.

Представьте: семья — папа, мама, сын и дочка — собирается в отпуск. Допустим, семья летит самолетом, поэтому на каждого человека можно взять по одному чемодану и загрузить его вещами не более 23 кг в каждом. В идеальной вселенной задача решается просто: взвешиваете все вещи, находите среднее значение, распределяете его на четверых. Однако в жизни есть миллион мелочей.

Например, чемоданы могут быть разными по объему. Получается, нужно учитывать плотность вещей? Допустим. Но чемоданы нужно доставить до самолета, а сын хочет везти свой багаж сам. Сил у него очевидно меньше, чем у папы и мамы, а значит, нагрузить его чемодан так же, как родительский, не получится. А вот дочка, наоборот, не хочет ничего везти. Так может, получится обойтись тремя чемоданами на всех? Но чтобы оптимизировать распределение вещей, придется потратить значительное количество времени и вручную, методом проб и ошибок, найти лучшее решение.

В бизнесе компании сталкиваются с похожими задачами. У вас есть серверы — они же чемоданы — и каждый вмещает в себя какое-то количество виртуальных машин, то есть вещей. И вам надо распределить нагрузку между серверами — по сути, решить ту же задачу, что со сборами в отпуск. Правда, с небольшим нюансом: обычно это не 3-4 чемодана, и даже не 100, а гораздо больше. Представили объем работ по оптимизации? Чтобы правильно подойти к решению такой задачи, важно начать с предыстории — и разделять этот «пирог» слой за слоем.

Как возникла виртуализация 

Основное развитие серверной виртуализации, которая и станет главным предметом наших статей, пришлось на 2000-е годы. До этого бизнес использовал разные физические серверы для работы независимых операционных систем; в начале века появилась возможность использовать один, разделенный на несколько виртуальных. Управлять ими можно с помощью специального программного обеспечения — гипервизора. Одним из первых решений стала разработка компании VMware — ESX Server и GSX Server. Новый подход значительно облегчил процесс управления IT-инфраструктурой, повысил надежность работы систем и сократил затраты на оборудование.

Виртуализация серверов позволила создавать центры обработки данных (ЦОД) — специальные объекты для обработки, хранения и распространения информации. Компаниям стало необязательно приобретать собственное «железо» — вместо этого можно арендовать соответствующий задачам виртуальный сервер.

Довольно быстро виртуализация стала стандартом IT, а количество задач и объем данных увеличились. В конечном счете это привело к тому, что не хватать стало даже виртуальных машин. Возможно, вы даже видели новость в мае 2025 года, что в Москве заканчиваются мощности ЦОД для крупных заказчиков. Здесь и начинается задача, которую мы решаем.

Из-за чего так трудно оптимизировать серверы и вещи в чемодане

Очевидно, что проблема не исчезнет сама собой: объем данных практически у всех компаний и госструктур стремительно увеличивается, а ЦОДы не успевают за спросом. Изучая вопрос, мы в «Юзтехе» выделили следующие причины возможного кризиса:

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

• Несбалансированная и неравномерная нагрузка. Ночью нагрузка снижается, днем в рабочие часы — растет. С пиковыми часами ничего не сделаешь: это данность, которую придется принять.

• Ручное распределение ресурсов. Во множестве компаний IT-специалисты пытаются оптимизировать загрузку ЦОДов вручную, что приводит к человеческим ошибкам, высоким трудозатратам и не слишком высокой эффективности.

• Ограниченная мощность. Доступных объемов часто не хватает для решения всех имеющихся задач, что приводит к нехватке ресурсов и возможным сбоям в обслуживании.

• Отсутствие автоматизированных централизованных инструментов управления ИТ-ресурсами. Это создает «бутылочные горлышки» из типовых ситуаций, требуя каждый раз изобретать велосипед вместо действий по алгоритму.

Если вспомнить изначальную задачу с чемоданами, то в случае со сборами в отпуск проблемы будут выглядеть так:

• У семьи слишком много вещей, и все они нужны. При этом из отпуска хочется привезти с собой сувениры — мест в чемодане может не хватить.

• Если исходить из принципа «каждый член семьи везет свою вещь», то может оказаться, что чемоданы детей будут для них субъективно тяжелее, чем для взрослых — и сын с дочкой не смогут поднять сумки.

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

• Даже при идеальном распределении в пути могут возникнуть неприятности: например, у чемодана сломается колесо или разойдется молния. Это сорвет нужный темп перемещения и может привести к тому, что семья не успеет на самолет. 

Похоже, проще вообще никуда не ехать, а остаться дома. Хорошо, что сервер — это не чемодан, а для оптимизации IT-инфраструктуры существуют работающие решения.

Какие методы оптимизации существуют и для чего мы сделали платформу Octopus

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

Вот эти способы:

• Ручное управление. Контроль и управление ресурсами через платформу виртуализации. Недостатки: не работает в определенных ситуациях, например, при масштабировании или при человеческой ошибке.

• Дополнительный функционал гипервизоров. Например, планировщик распределенных ресурсов (Distributed Resource Scheduler, DRS) — инструмент автоматической балансировки виртуальных машин между разными хостами. Или механизм высокой доступности (High Availability, HA) — функция VMware, которая обеспечивает автоматическое восстановление в случае сбоя физического сервера или другого критического отказа. Недостатки: есть не у всех гипервизоров, а если есть, то стоят очень дорого.

• Системы мониторинга, встроенные в гипервизор или независимые. Недостатки: нет функционала рекомендаций или действий, которое позволило бы автоматизировать управление проблемными компонентами системы.

Мы в «Юзтехе» тщательно исследовали имеющиеся на рынке решения и поняли, что им всем далеко до идеала. Так что мы решили выпустить свой цифровой продукт на основе искусственного интеллекта для автоматической оптимизации серверов — Octopus. В отличие от большинства конкурентов, он позволяет комплексно подходить к оптимизации.

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

Опасения разумны и единственный убедительный ответ — пилотное использование на оборудовании заказчика. Те, кто соглашается попробовать Octopus в деле, видят, что он легко устанавливается, интегрируется с клиентской системой и работает с внешними API. Причем если у компании есть какой-то запрос, который еще не реализован в Octopus, мы готовы его рассмотреть и честно назвать сроки, в которые мы сможем добавить дополнительный функционал.

Если продолжать сравнение со сборами в отпуск, то окажется, что Octopus — тот самый помощник, который собрал бы все чемоданы за короткое время, с максимальным эффектом и соблюдением приватности. И да, он учтет пожелание уместить все вещи не в 4, а в 3 чемодана — если, конечно, объем чемоданов это позволяет.

Как работает Octopus в сравнении с другими решениями

• Octopus vs Turbonomic

Turbonomic — это платформа, которую мы считаем единственным полным аналогом Octopus. Конечно, у него есть множество достоинств — достаточно сказать, что это проект всемирно известного IBM с налаженным сервисом. Но из-за своего монструозного размера Turbonomic неповоротлив: для того, чтобы запуститься, ему нужно 8 ядер и 32 Гб оперативной памяти. Повторюсь — речь только о запуске, когда обработка еще даже не началась. Чтобы запустить Octopus и проанализировать минимальное окружение, потребуется более чем в 2 раза меньше ресурсов: 4 ядра и 8 Гб оперативки. Работать со стабильным окружением Turbonomic начинает с памятью от 64 Гб. Octopus уже на 12 гигабайтах справляется с 3-4 тысячами виртуальных машин.

Turbonomic заявляет о себе как о платформе, которая совершает анализ в режиме реального времени. И для этого они держат все данные в оперативной памяти — неудивительно, что им нужны повышенные мощности. У нас такого обещания нет, но, если разобраться и копнуть глубже, выяснится, что и Octopus, и Turbonomic живет одинаковыми 10-минутными циклами. За это время происходит сбор данных, проводится анализ и выдается результат в виде рекомендаций. Уже сейчас мы можем сделать этот процесс быстрее, но в этом пока нет необходимости. Заявлять о работе в режиме реального времени нам тем более не нужно: 10 минут — тот самый интервал, которого хватает для большинства задач.

Еще одно существенное преимущество Octopus — цена. Его стоимость в два раза ниже Turbonomic, если говорить о базовых ценах без скидок для больших объемов. При этом Turbonomic поддерживает только зарубежные гипервизоры, а до российских им нет дела: вполне объяснимая логика для международного гиганта IBM, заточенного под европейский и американский рынок.

Но для российского IT-сегмента с его политикой импортозамещения этот вопрос становится критичным. Octopus поддерживает такие отечественные платформы, как Astra, «Брест», «Базис» и zVirt. А еще мы работаем с VMWare, Hyper-V и Zabbix. Конечно, по количеству мы пока сильно уступаем Turbonomic. С другой стороны, мы функционируем по той же модели, поэтому количество поддерживаемых ПО для нас вопрос времени. А главное — мы поддерживаем именно то, что доступно и востребовано на российском рынке.

• Octopus vs VMware DRS

Один из главных недостатков гипервизора VMWare — это неспособность платформы работать с внешними метриками, которые могут быть точнее или разнообразнее внутренних. Возьмем для примера метрику Zabbix. Она берется изнутри операционной системы виртуальной машины, и поэтому, по нашему опыту, на порядок точнее, чем гипервизор, который работает извне. Когда мы сравнивали метрики, получалось, что Zabbix выдает значения цифру в цифру, а результаты VMWare отличались на 100-200 Мб при общей емкости 1 Гб, то есть на 20% от общего объема. Подчеркну, что это исключительно наш опыт — возможно, у кого-то накоплены другие данные о точности.

Octopus работает с разными метриками — как с собственными, так и с внешними. К примеру, недавно мы интегрировались с российской системой мониторинга «Пульт», работающей на открытой платформе Zabbix. Ну а если заказчик попросит наладить интеграцию Octopus с ПО, с которым мы пока не работаем, то мы готовы решить эту задачу за пару месяцев.

В целом, DRS — это отличная платформа в своей нише, но она занимается только перемещением, не предлагая ресайзинг, то есть изменения виртуальных машин. Чтобы получить ресайзинг, бизнесу нужно покупать дополнительную продукцию VMWare. У Octopus эта функция входит в базу.

Конечно, можно потратиться и купить дополнительный пакет, но, во-первых, это будет заметно дороже, а во-вторых, эти дополнительные решения ограничены. Например, в Octopus можно увидеть рекомендацию, что надо добавить 2 гигабайта памяти, нажать галочку — и память добавится. В такой же ситуации VMWare тоже подаст сигнал, что не хватает памяти, но вот быстро отреагировать на это не получится: у программы просто нет встроенного функционала для быстрого устранения подобных ситуаций.

Какой алгоритм использует Octopus, чтобы быть эффективным

Рецепт эффективности Octopus — это использование нескольких алгоритмов, в том числе искусственного интеллекта и метода машинного обучения (AI ML). Зачем? Потому что и в случае с оптимизацией IT-инфраструктуры, и в случае с чемоданами перед нами задача со звездочкой. Первое — это масштаб. Если у заказчика 100 или 200 виртуальных машин, то возможно, ему и не нужен весь спектр наших услуг — с таким количеством машин может справиться подготовленный специалист, имеющий хорошую метрику с рекомендациями. Другое дело, когда речь идет об объемах, превышающих 500 виртуальных машин. Здесь спасти могут только компьютерные технологии.

Второе — многомерность задачи. Изначально распределение мощностей — это стандартная задача о рюкзаке, которую все проходят в технических вузах и ответ для которой можно найти подбором. Но такая задача в своем типовом варианте учитывает только два измерения. Например, вес и размер — поместится или не поместится содержимое в рюкзак при заданном весе и объеме. У нас же на сервере огромное количество измерений.

Стандартное измерение в виртуальной машине (ВМ) — пара процессор-память. Итак, смотрим, какие метрики используются при анализе производительности процессора. Использование процессора системными службами и программами, время ожидания ответа, задержка, время простоя процессора. Это то, что первым приходит в голову, а на самом деле их штук 15 — и каждая добавляет новое измерение.

Дальше смотрим память — тут метрик еще больше: объем оперативной памяти, к которому ВМ получила доступ в предыдущий период измерения; объем физической памяти хоста, который был отдан ВМ; объем физической памяти, которую ВМ потребляет с хоста; объем оперативной памяти ВМ, зарезервированный гипервизором для работы ВМ; объем оперативной памяти, которую удалось сжать. Опять же, это далеко не полный список. Эти параметры важно учитывать при решении задачи о рюкзаке.

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

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

Чтобы гарантировать надежность работы, в Octopus задача по умолчанию решается линейным программированием. А вот с помощью ML мы прогнозируем, какой будет загрузка виртуальных машин в перспективе. Если наш прогноз расходится с реальным поведением машины за последние 30 минут, то мы выбираем решения, которые пришли с линейным программированием. Если же прогноз совпадает с действительностью, то используется ML-решение.

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

Чтобы не быть голословным, приведу немного статистики Octopus. Платформа позволяет сократить рутинные задачи на 10%, высвободить до 30% вычислительных мощностей и увеличить скорость обработки данных в 3–4 раза. Чтобы прийти к таким результатам, нам пришлось потрудиться и решить огромное количество задач. Но об этом предлагаю поговорить в следующих статьях. А пока — идем паковать чемоданы. В смысле, совершенствовать свой продукт дальше.