Эффективное сетевое управление: эволюция платформы виртуализации SpaceVM
Сергей Алексанков, заместитель технического директора ООО «ДАКОМ М», - рассказывает об этапах масштабирования SpaceVM и подходах к разработке собственного SDN-контроллера
На облачном столе
Облачная платформа SpaceVM, основа нашей экосистемы виртуализации, представляет собой полностью отечественный продукт, позволяющий решать те же задачи, что и всем известная платформа от VMware, но с большей адаптивностью для российских пользователей, как коммерческих, так и государственных.
Вся линейка Space совместима с ПО и оборудованием российских производителей. Функционал платформы позволяет перенести в облако веб-сайты, все необходимые приложения, а также рабочие станции сотрудников — с виртуализацией рабочих столов через комплекс Space VDI и с предоставлением доступа к ним через клиентское ПО Space Client.
Также платформа полностью обеспечивает работу телекоммуникационных сервисов, виртуальных маршрутизаторов, межсетевых экранов, почтовых и прокси-серверов.
Перенос системы на виртуальную платформу позволяет бизнесу снизить расходы на ЦОД, повысить отказоустойчивость всех систем и приложений, а также значительно упростить работу ИТ-отдела за счет более прозрачного и удобного администрирования.
Поскольку все продукты Space изначально создавались в целях построения общей экосистемы отечественного ПО, платформа виртуализации SpaceVM выступает базой для объединения различных технологий и решений российских вендоров.
Эволюция SpaceVM
о мере работы и накопления опыта мы столкнулись с тем, что созданная нами платформа в ее первоначальном виде, с родной архитектурой и заложенными в проект решениями, стала тяжелее поддаваться масштабированию. Это стало знаком того, что наша компания открыта к концептуальному обновлению продукта, которое включает в себя переосмысление его архитектуры. Ведь изначально сетевая подсистема была задумана для работы на уровне небольшого корпоративного облака.
Это совпало с тем, что выросли и потребности наших заказчиков: например, они хотят использовать платформу на сетях большего размера, включая «распределенные» центры обработки данных. А это уже требует решения таких задач, как возможность использования платформы множеством отделов с изоляцией виртуальных машин друг от друга в рамках одной и той же сети без снижения времени отклика и пропускной способности сети.
Поэтому, столкнувшись с производительными и архитектурными ограничениями платформы, мы начали думать о том, как их обойти, и пришли к идее перехода на SDN — программно-определяемые сети.
Сама идея лежала на поверхности, ее уже частично реализовали наши российские конкуренты в своих аналогах. Эталонный виртуальный сетевой контроллер VMware NSX проповедует подход SDN. И именно такой подход избавляет нас от всех описанных ограничений. Поэтому мы и начали разработку сетевой подсистемы с подходом SDN.
Уже сейчас текущая реализация сетевой подсистемы SpaceVM позволяет повысить надежность и отказоустойчивость корпоративных сетей. А внедрение нового SDN-контроллера снижает зависимость сетевых подсистем от живучести основного контроллера и от необходимости периодической корректировки конфигурационных файлов, используемых узлами в текущем моменте.
Подход SDN с протоколом OpenFlow позволяет достаточно легко обеспечить работу всей сети в заданном режиме: требуется лишь корректно выполнить единичную настройку правил для работы SDN-коммутатора на узлах. Если где-то узел «отвалится», а потом «вернется», контроллер самостоятельно, без вашего вмешательства, все оперативно синхронизирует. Теперь он сам назначает конфигурации, и при этом даже в случае его падения риски отсутствуют: он спокойно поднимется в другом месте и снова раздаст нужную конфигурацию для пользователей. Для применения данного подхода требуется лишь наличие эталонной конфигурации, которую можно хранить в базе основного контроллера.
Как мы создавали свой SDN-контроллер:
Open source vs собственная разработка
Компания «ДАКОМ М» активно развивает собственное проприетарное ПО, однако для создания сетевого контроллера провела масштабное исследование рынка проектов open source, чтобы выявить их сильные и слабые стороны и оценить возможность их использования в качестве основы для своего продукта. Сначала был рассмотрен популярный OVN, затем — Ryu и, наконец, Neutron, который используется в OpenStack-средах.
Однако везде выявлялись недостатки: в OVN оказалась неприемлемой обратная связь компонентов на узлах, Neutron показал недостаточную гибкость в настройках под наши задачи, а Ryu продемонстрировал низкую скорость конфигурирования. Поскольку мы позиционируем продукт в конкретной нише — как платформу для организации частного облака, функции, необходимые для публичных провайдерских облаков, нам оказались не нужны: в нашем случае они избыточны. Так что первым критерием для нас стал отказ от готовых решений open source.
Управление через веб-интерфейс
Новый контроллер требовалось вписать в существующую архитектуру нашей платформы SpaceVM, так как мы не хотели делать его отдельным внешним модулем. Цель состояла в том, чтобы все работало максимально прозрачно для пользователя, чтобы наш сетевой SDN-контроллер был вписан в платформу и им можно было управлять через единый веб-интерфейс. Для этого нужно было подобрать изящные архитектурные решения: облегчить процесс администрирования для пользователя, избежать непонятной «кучи» микросервисов, которые, непрозрачно взаимодействуя между собой, создают задержки и увеличивают время отклика при конфигурировании. Поэтому мы решили полностью интегрировать логику работы с сетевым уровнем в наш веб-интерфейс, обеспечив максимальную отзывчивость.
Язык программирования — Go
В качестве основного языка при написании SDN контроллера был выбран GO, обеспечивающий многопоточность, компилируемость и эффективную работу на распределенных сетях и позволяющий значительно повысить производительность.
Переход от RPC к RabbitMQ
В текущей реализации для связи между узлами мы используем только модуль вызова удаленных процедур RPC, однако считаем его избыточным для задач управления в новом сетевом контроллере. Поэтому мы решили вынести уровень взаимодействия модулей и узлов в сети на модуль очередей RabbitMQ.
Глобальная модернизация
После релиза SDN-контроллера и обновления платформы SpaceVM мы постепенно пройдемся по всем текущим возможностям нашей сетевой подсистемы, чтобы полностью модернизировать ее и довести до уровня нашей сетевой экосистемы. Это позволит повысить скорость работы, улучшить производительность, внедрить микросегментацию для точечного использования виртуальных машин, а также более гибко выполнять изоляцию разных пользователей в рамках одной сети.
Речь идет о виртуальных и внешних сетях, традиционных сетях второго уровня и сетях на базе VXLAN с возможностью гибко встраиваться в фабрику предприятия при объединении ее с нашей платформой. Дальше идут L3-сети со статической маршрутизацией. Кроме того, мы добавим технологию DPI для проверки сетевых пакетов по экстра-режиму. Такой функционал мы хотим реализовать в 2025 г., и все это тоже будет управляться с помощью веб-интерфейса. То есть пользователю не придется привыкать к новой логике управления: на вид все будет по-прежнему, но с новыми ощущениями, более высокой производительностью и надежностью.
Также в следующем году мы планируем сделать динамическую маршрутизацию между виртуальными и внешними сетями с помощью протоколов BGP по OSPF.
Переход к прозрачной виртуальной сети: новые возможности SpaceVM
В дальнейшем SpaceVM получит возможность интеграции с другими платформами виртуализации, что позволит упростить пользователям доступ к виртуальным сетям и узлам. В актуальной сетевой архитектуре платформы основной метод создания виртуальных сетей основан на использовании сетей, построенных посредством виртуальных каналов второго уровня (L2), каждый из которых оснащен индивидуальным виртуальным коммутатором на каждом узле и отдельными аплинками.
Такие решения просты в применении, но их нельзя назвать гибкими, поскольку пользователю нужно знать, какие физические интерфейсы у него используются на каждом узле и в каком количестве, тип коммутаторов и прочую низовую информацию по железу. Это может быть приемлемым для продвинутых пользователей, но для людей, «отдаленных от серверной», не погруженных в тему физики сетей, такой вариант не подойдет.
Однако им на помощь может прийти так называемая виртуальная сеть с L2-связанностью. В этом случае пользователь просто создает на огромном пуле ресурсов виртуальную сеть и дальше уже не думает о том, как она будет связываться с другими серверами и виртуальными машинами, какие там есть физические интерфейсы и т. д. В результате получается полностью прозрачная сеть, использование которой решает проблемы масштабируемости. Данный формат частично задействован в текущей реализации сетевой подсистемы, но лишь в целях создания сетей в рамках кластера SpaceVM.
Новейший метод позволит пользователю объединить виртуальные сети SpaceVM с внешней VxLAN-фабрикой, что значительно упростит интеграцию с сетями на различных платформах и сделает этот процесс максимально удобным в практическом применении.