Подключение облака к КСПД

Сетевая инфраструктура для размещения Платформы должна быть подготовлена соответствующим образом: должны быть созданы все сети, описанные в разделе Сети Платформы. Сетям должны соответствовать IP-адресация с необходимыми масками, VLAN, должны быть выделены пулы для IP Loopback и служебного Kubernetes.

Подготовка сетевой инфраструктуры решает следующие задачи:

• Бесшовная интеграция.
• Изоляция управляющих и рабочих нагрузок.
• Гибкость управления.

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

Для подключения к КСПД используется:

• Трёх- или пятишаговая CLOS Spine-Leaf фабрика.
• Коммутаторы Border-Leaf для North-South трафика.
• МСЭ-ферма для фильтрации межзонного трафика.
• Data Center Gateway для связи между ЦОД и с внешними сетями.
• Серверы подключаются как по L2, так и по L3 (зависит от требований Заказчика).

Пример трёхшаговой Spine-Leaf фабрики приведён на рисунке 1.

Рисунок 1 — Пример схемы трёхшаговой Spine-Leaf фабрики

Сетевая фабрика должна соответствовать следующим требованиям:

• Коммутаторы Leaf — поддержка BGP, EVPN-VXLAN (RFC 8365), VxLAN, MC-LAG.
• Пропускная способность коммутаторов Leaf — 25 Гбит/с на порт подключения серверов, 100 Гбит/с на порт подключения к Spine.
• Коммутаторы Spine — поддержка BGP, EVPN-VXLAN.
• Пропускная способность коммутаторов Spine — 100 Гбит/с на порт.
• Коммутаторы Border Leaf — поддержка BGP, EVPN-VXLAN, VxLAN.
• Firewall — поддержка BGP.
• Data Center Gateway — поддержка L3VPN, EVPN.

Данный вариант выбирается в случае, если не известны параметры подлежащей сети (сетевой фабрики).

В качестве подключения используется MC-LAG или любое другое отказоустойчивое подключение по L2, согласованное с Заказчиком. При этом для Платформы используются типы сетей типа VxLAN и типа VLAN. Маршрутизация с КСПД осуществляется на пограничных маршрутизаторах или L3 коммутаторах. Маршрутизация внутри облака в проектных сетях осуществляется виртуальными роутерами.

Принципиальная схема интеграции приведена на рисунке 2.

Рисунок 2 — Схема классической интеграции с КСПД

Данная схема является наиболее универсальной, но наименее гибкой.

Мультитенантная EVPN-фабрика является ещё одним способом интеграции с КСПД по L2.

Такая фабрика сможет распространять /32 маршруты к ВМ как с помощью type2 (MAC, IP), так и с помощью type5 (IP). Коммутаторы Leaf используют инкапсуляцию VxLAN, поэтому нет необходимости использовать VxLAN сети самообслуживания (проектные сети) в Платформе, а также в связи с этим, не рекомендуется использовать NAT.

В данной реализации часть функционала передаётся на EVPN-фабрику и, соответственно, появляется возможность строить дополнительные сервисы: например, отказоустойчивый anycast-балансировщик (рисунок 3).

Рисунок 3 — Схема мультитенантной EVPN-фабрики

При интеграции в ЦОД необходимо выбрать вариант реализации функции межсетевого экранирования. Этот выбор будет во многом обусловлен требованиями ИБ и повлияет на эффективность процессов самообслуживания.

В данной реализации фильтрацию трафика между проектами выполняет централизованная МСЭ-ферма (рисунок 4).

Рисунок 4 — Схема, при которой фильтрацию трафика выполняет централизованная МСЭ-ферма

Плюсы:

• Ферма МСЭ — единая точка фильтрации трафика.
• Фильтрация как трафика от ВМ во внешний мир и обратно, так и трафика между проектами.
• Понятная функциональная аппаратная часть и программное обеспечение фермы МСЭ.

Минусы:

• Неоптимальный форвардинг трафика.
• Плохо масштабируется с ростом рабочей нагрузки.
• Требуется автоматизация управления фермой МСЭ и синхронизацией с Платформой.

В данном варианте используются группы безопасности (Security Groups), расположенные максимально близко к ВМ, непосредственно на её портах. Трафик между проектами не выходит за пределы сетевой фабрики (рисунок 5).

Рисунок 5 — Схема использования группы безопасности, расположенной на портах ВМ

Плюсы:

• Фильтрация трафика производится максимально близко к ВМ на гипервизоре.
• Оптимальный форвардинг трафика.
• Максимальная интеграция с облачной платформой.
• Нет единой точки отказа.

Минусы:

• Существенно меньшие функциональные возможности.
• Команде эксплуатации потребуется адаптироваться.
• В некоторых случаях может возникнуть вопрос по производительности.

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

NGFW не входит в комплект поставки Платформы (рисунок 6).

Рисунок 6 — Схема использования виртуальных NGFW

Основные свойства решения:

• Размещение виртуального NGFW в проекте клиента.
• Влияние на производительность NGFW за счёт масштабирования выделенных ресурсов.
• Подключение внешних каналов к портам NGFW.
• Управление политиками безопасности.
• Сегментация внутренней облачной инфраструктуры.

Сравнительный анализ всех вариантов фильтрации трафика приведён в таблице 1.