SDN в Astra Cloud Platform: сети без ручной раздачи VLAN

Хабр, приветствую! На связи Андрей Иволга, менеджер по продукту компонента SDN в облачной платформе Astra Cloud. Сегодня моя очередь рассказывать про новые компоненты ее релиза 2.1. Напомню, что ранее наш архитектор Алексей Боровиков рассказывал, как мы с нуля написали IAM. Сегодня речь пойдет про сети. 

Короткое резюме для тех, кто торопится: в Astra Cloud Platform появился собственный программно-определяемый сетевой слой. Виртуальные сети, маршрутизация, NAT, DHCP, доступ во внешнюю инфраструктуру и диагностика связности теперь настраиваются из интерфейсов платформы, а не через отдельные ВМ с сетевыми функциями и правки на физическом оборудовании. Компонент называется APOS, но дальше по тексту буду называть его просто SDN, чтобы не никого не запутать. 

Итак, поехали в подробности)

Зачем вообще пилить свой SDN

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

Без специализированного сетевого компонента Astra Cloud Platform когда-то в начале своей разработки умела только то, что дает базовая виртуализация: подключить ВМ к сегменту. Все остальное: маршрутизация, NAT, доступ во внешку — реализовывалось руками, через отдельные ВМ с сетевыми функциями или конфигурацию физического оборудования.

На практике это давало три проблемы.

1. Неполный self-service. Создать ВМ можно было в один клик, а вот довести до нее законченный сетевой сценарий уже нет. Часть работы оставалась за пределами оркестрации платформы и требовала рук администратора.

2. Фрагментация конфигурации. Сведения о топологии и правилах трафика жили сразу в нескольких местах: в платформе, в подсистеме виртуализации, в сетевых ВМ, на физическом оборудовании. Диагностика превращалась в квест по нескольким системам сразу.

3. Разрыв с ожиданиями крупных заказчиков. Компании, которые переезжают с зарубежных платформ, привыкли к централизованному управлению сетями и к нормальному уровню автоматизации. Без своего SDN этот уровень было не обеспечить.

SDN эти проблемы порешал, естественно, предоставив Astra Cloud Platform специализированный программно-определяемый сетевой слой с собственной моделью сетевых ресурсов, мультитенантностью и публичными API. При этом облачная платформа сохраняет ответственность за жизненный цикл виртуальных машин и единый пользовательский опыт.

Тесные взаимоотношения компонентов наглядно со схемой

SDN в Astra Cloud Platform — один из функциональных компонентов. Взаимодействие с ним идет через платформенный IaaS-оркестратор. Он реализует сквозные сценарии, привязывает сетевые операции к жизненному циклу ВМ и обращается к публичным API SDN. Пользователи и администраторы видят только интерфейсы платформы, а что происходит на уровне SDN, их не касается. Это наши вопросики на уровне обслуживания) Как и должно быть у нормального сервиса.

Преображение архитектуры

Раньше физическое оборудование и отдельные сетевые ВМ оперировали VLAN, интерфейсами и маршрутами сами по себе, без всякой связи с тенантами и ролями Astra Cloud Platform. Изоляцию и доступ к сетевым операциям платформа была вынуждена собирать вручную. Ну, уж извините, Москва не сразу строилась, как говорится. 

С появлением SDN сетевые ресурсы теперь изначально создаются в тенантном контексте, а доступ к ним регулируется ролевой моделью этого компонента. Astra Cloud Platform сопоставляет свои тенанты и роли с моделью SDN и работает с ней через API. Функции разделились идеально (уровень «батюшка»). Платформа остается источником истины для тенантов и сквозных сценариев. SDN же — для самих сетевых ресурсов и конфигурации.

Похожая история произошла и с маршрутизацией, NAT и остальными сетевыми функциями. Раньше их тянули отдельные ВМ или физическое железо, каждую нужно было содержать, масштабировать и чинить отдельно. Теперь коммутация, маршрутизация, NAT, DHCP и подключение к внешним сетям выполняются централизованно, средствами SDN, а физическая сеть в основном отвечает за транспорт между узлами виртуализации и точку выхода наружу.

На этом считаю, что небольшое вводное интро «было-стало» можно заканчивать. Переходим к практической пользе.

Ай да SDN! Ай да молодец! Или сценарии применения

Если раскладывать новую архитектуру Astra Cloud Platform с SDN на рабочую конкретику, то я бы выделил следующие сценарии.

Изолированные сети для тенантов

Уже частично проговорили, но скажу еще раз. Для разных клиентов, подразделений и проектов SDN создает независимые сетевые контуры. Сети, маршрутизаторы и порты рождаются сразу в тенантном контексте, а доступ к ним ограничен ролевой моделью. Несколько тенантов спокойно живут на одной инфраструктуре виртуализации, но их сетевые ресурсы друг друга не видят.

Подключение ВМ без ручного VLAN на каждый сегмент

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

Маршрутизация между сетями без выделенного ВМ-роутера

Внутри одного тенанта можно нарезать несколько сетей и связать их виртуальными маршрутизаторами SDN. Например разложить инфраструктуру на frontend, application и database. Маршрутизация тоже распределенная и выполняется на узлах виртуализации, поэтому трафику между ВМ не нужно идти через отдельную ВМ-маршрутизатор. Меньше промежуточных звеньев плюс единая точка отказа при обработке трафика вообще пропадает.

DHCP и адресация

На сетях работает управляемый DHCP. ВМ получает адрес автоматически, при необходимости порт можно закрепить за конкретным IP. Все это живет в единой модели ресурсов, поэтому сеть, подсеть, порт и выделенный адрес всегда согласованы между собой.

Выход во внешние сети и публикация сервисов

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

Статическая и динамическая маршрутизация, включая BGP

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

Зеркалирование трафика

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

Диагностика без похода в дата-центр

SDN умеет моделировать путь пакета внутри программно-определяемой сети: через какие логические элементы и правила должен пройти трафик и на каком участке рвется связность. Централизованная (как вы поняли уже, наверное, это мое любимое слово) картина топологии сильно сокращает время на то, чтобы понять, где именно сломалось, еще до разбора физической инфраструктуры.

Данные продолжают идти, даже если управление упало

Control plane и обработка пользовательского трафика в SDN разделены. Если управляющие компоненты временно недоступны, уже настроенные сети продолжают передавать трафик как ни в чем не бывало. Создавать и менять ресурсы, конечно, в этот момент нельзя, но зато то, что уже работает, продолжает функционировать.

Все через API

Основные операции доступны через публичные REST API, так что можно встроить SDN в свои оркестраторы и автоматизацию. Для ручной работы есть отдельные WebUI и CLI, админский и пользовательский, так что автоматику можно сочетать с руками там, где нужна тонкая настройка.

Роадмап или что дальше

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

Мы плавно двигаемся вот куда:

• функции сетевой безопасности и микросегментации;

• управляемые балансировка и VPN;

• интеграция с партнерскими виртуальными сетевыми функциями;

• мультирегиональные сетевые сценарии;

• подключение контейнерных и физических нагрузок к виртуальным сетям.

Ценность SDN налицо

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

Отдельно хочу отметить, что мы недавно запустили «Защищённое аттестованное облако» — оно существенно облегчает вопрос аттестации ИС в уже готовом изолированном, защищенном и аттестованном контуре и предназначено для ГИС вплоть до К1 и ИСПДн до УЗ1. Присмотритесь) Решение на базе Astra Cloud Platform.

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

Зрелость нам идет

Знаете, что реально чувствуется в этом релизе? Платформа выросла. Особенно приятно слышать такие слова именно от заказчиков. 

«У вас очень зрелый продукт», — и мы таем, как мороженко. А потом, вдохновленные, идем апдейтиться дальше. 

По моему скромному мнению, SDN входит в число компонентов, из-за которых Astra Cloud Platform действительно стали считать серьезным решением для построения частных и публичных облаков.

Лайки, комментарии с вопросиками — милости просим! 

На этом передаю слово коллегам, про остальные обновления Astra Cloud Platform 2.1 расскажем еще не один раз.