Формула эффективности: аналитика потребления инфраструктуры и управление zVirt

• Сергей Мерещенко, лидер продукта Cloudlink, Orion soft

Давайте начинать. Я в команде Orion soft занимаюсь развитием продукта Cloudlink. В этом году мы сделали с ребятами еще несколько модулей, которые помогут перейти от простой инсталляции с виртуализацией zVirt к той парадигме, когда в вашей инфраструктуре может появиться частное облако, и оно может стать вам полезным.

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

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

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

На первом шаге поговорим про модуль zVirt Metrics, который позволяет обеспечить аналитику и, если надо, мониторинг ресурсов. Дальше, развивая инфраструктуру, можно перейти к централизованному управлению zVirt, к автоматизации выдачи ресурсов и подходам с самообслуживанием, но конкретно над zVirt. А на финальном третьем шаге я чуть-чуть расскажу про Cloudlink. Это частная облачная платформа, Cloud Management Platform, которая позволяет автоматизированно создавать ресурсы на разных платформах виртуализации.

С чего мы начали аналитику? Как и подобно, например, гонкам внутри «Формулы-1», помимо того, что нам важно знать, что происходит в инфраструктуре, надо все параметры анализировать. Можно выигрывать гонки, можно проигрывать гонки, но не понимать, почему так происходит. И внутри вашей инфраструктуры генерируется разное количество данных, но они все умеют работать с теми метриками, которые отдает платформа виртуализации, как-то их визуализировать и, что самое главное, принимать решения на основе этих данных, а не по догадкам каким-то, которые высказывают администраторы.

И что мы сделали? Мы внутри zVirt сделали отдельные эндпоинты, которые отдают метрики в формате Prometheus, а дальше с помощью системы сбора, модернизации, хранения и визуализации позволяют обеспечить вывод информации в удобном виде, а главное — в оперативном. То есть всегда у вас есть актуальная информация о том, что происходит в инфре.

Про что zVirt Metrics еще? Это когда в вашей инфраструктуре появляется не один Hosted Engine, а их может быть несколько. У них у всех разные API-эндпоинты, у них свои консоли управления. И при этом для того, чтобы централизованно собирать с них информацию, не всегда хватает инструментов. zVirt Metrics — это первый модуль, который позволяет это сделать.

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

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

Со всем этим можно работать через два портала. Портал аналитики и портал мониторинга.

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

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

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

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

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

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

Мы сделали задел на будущее, стартанули zVirt Metrics этим летом и вчера выпустили релиз 1.1, внутри которого довезли обновления, связанные с русским языком в дашбордах, с дополнительным ускорением для того, чтобы эти дашборды работали и визуально показывали информацию быстрее даже на большом количестве ресурсов. На нагрузочном тесте у нас эта система вполне справлялась с эмуляцией 800 хостов zVirt, внутри которых крутились виртуальные машины со стресс-тестами, их там было суммарно больше 6000.

Дальше мы идем в сторону того, чтобы вместе с релизами zVirt мы научились отдавать больше метрик с самой платформы виртуализации. А мы своим модулем сможем эти дополнительные метрики визуализировать.

Что это за метрики? Это основные метрики, связанные уже непосредственно с хостами виртуализации. До этого мы начинали со 140 метрик, о которых знал сам Hosted Engine, это «управлялка» zVirt. А теперь мы туда добавляем еще и информацию о самих хостах. И там же будет информация инвентарного типа о том, какие это модели серверов, их названия и так далее. Это тоже мы можем передавать в хранилище, а дальше визуализировать или использовать в аналитике.

Мы работаем с заказчиками, у которых в инфраструктуре появляются видеокарты. С этими видеокартами, во-первых, нужно понимать, что происходит. И мы в начале следующего года будем делать доработки под то, чтобы визуализировать метрики видеокарт.

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

Ну и сделать продукт таким, чтобы можно было подключить туда дополнительные продукты Orion soft и в едином месте видеть информацию не только по виртуализации, но, например, по контейнерам, по Termit и тому, что происходит с терминальным доступом и VDI.

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

Второй модуль, DC Manager, — это второй шаг. Он позволяет собрать точно так же разные Hosted Engine под одним крылом и не только показывать, что в инфраструктуре происходит, но и управлять.

Дальше можно поверх этого построить систему автоматизации, которая в конечном итоге помогает и админам, и руководству ускорять выводы виртуальных машин конкретным непосредственным пользователям, которые к вам за «виртуалками» и ресурсами приходят. Это могут быть не просто виртуальные машины, но еще и дополнительные PaaS-сервисы.

Здесь мы показали, что мы несколько zVirt собрали как раз в одной консоли, и мы по ним можем собирать разную информацию, то есть понимать, какое количество центров данных, кластеров, доменов хранения, дисков, сетей на каждой из частей этих виртуализаций находится. Но не просто понимаем, но еще и можем, например, управлять хостами: перевести хост в обслуживание, добавить новый хост, вывести хост из этого кластера, переместить в другой. Это все будет сделано в едином интерфейсе модуля DC Manager.

Вторая важная вещь — что от управления zVirt мы можем перейти к автоматизированной выдаче ресурсов. И как это выглядит? Мы сканируем те виртуальные ресурсы и виртуальные машины, которые были созданы мимо модуля DC Manager напрямую на платформе виртуализации. Дальше их можно будет затянуть в портал самообслуживания, распределить по проектам и сделать их управляемыми. И дальше доступ к этим машинам могут получить не только администраторы, но и, например, пользователи, разработчики, DevOps, тестировщики, но со своими ограничениями. Там можно очень гибко настроить ролевую модель.

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

А так выглядит портал самообслуживания, в который попадают либо администраторы, либо конечные пользователи, и могут даже сложные сервисы. Здесь на примере StarVault. Его не очень хорошо видно. Но его можно запускать как в single instance автоматизированно, как и в high availability, выбирая разное количество ресурсов CPU, памяти и дисков на старте и меняя, например, параметры запуска, на каком конкретно zVirt из подключенных запускать данный ресурс.

Точно так же мы продолжаем развивать и модуль DC Manager. И основная задача на этот год — это сделать управление такой сущностью zVirt, как SDN, чтобы была гибче возможность управлять из одного централизованного портала и распределенной сетью.

Точно так же про заказ виртуальных GPU. Это про то что заказчикам, у которых возникает задача покрутить что-то, связанное с искусственным интеллектом, нужны «виртуалки», которые это умеют позволять, которые позволяют прокидывать виртуальные видеокарты либо «целиковые» видеокарты внутрь, а дальше, соответственно, их надо как-то учитывать. Здесь еще важный момент — что их надо уметь квотировать и не выдавать лишние ресурсы тем, кто их не просил. И это одна из ближайших доработок, которая уже может быть протестирована у вас.

Я уже говорил, что у нас есть в модуле Metrics задел на сбор логов. И здесь про сбор логов — это про то, что мы из zVirt будем собирать c разных инсталляций логи в одно место для того, чтобы удобнее за ними наблюдать.

Мы прошли два шага. Первый — это аналитика и мониторинг. Второй — это централизация ресурсов управления, автоматизация управления zVirt. А следующий шаг — это Cloudlink, облачная платформа, которая может быть установлена у вас внутри, поверх существующей системы виртуализации. И ключевая фишка в том, что она может объединять и дополнительные платформы виртуализации.

Здесь эволюционно показано следующее: в zVirt Metrics есть определенный набор функциональности, он же есть в zVirt DC Manager, он же есть и в Cloudlink, но Cloudlink — это самая «раскачанная» система, продукт. В нем появляется дополнительная возможность, например, биллить ресурсы за разные сущности. Это могут быть и лицензии, например, установленных операционных систем внутри. Это могут быть IP-адреса. Это могут быть части видеокарт, гигабайты видеокарт. Разные элементы могут быть сконфигурированы под ваши задачи. Здесь больше про то, что биллинг реально очень гибкий, и можно разные ресурсы считать и дальше понимать, сколько они стоили той или иной команде.

Про гибридность. Здесь ключевое еще то, что помимо объединения разных on-prem-виртуализаций, мы еще умеем подключаться к внешним облакам — Yandex Cloud и К2 Cloud. Внутри них вы можете заказывать виртуальные ресурсы, на которые будут накатаны те PaaS-сервисы, которые точно так же запускаются у вас в zVirt, вы их точно так же можете запустить и на внешних облаках.

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

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

Зачем это нужно? Мне кажется, невозможно выиграть гонку, если использовать старые технологии, старые стратегии. Нужно постоянно развиваться.

Спасибо, что вы пришли слушать про то, как мы развиваемся. Но мы здесь, в Orion soft, хотим помогать вам развиваться, поэтому давайте делать это вместе.

Всем спасибо!