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

Сетевая инфраструктура для размещения Платформы должна быть подготовлена соответствующим образом: должны быть созданы все сети, описанные в разделе Сети Платформы. Сетям должны соответствовать 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, MC-LAG.
• 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-фабрики

Улучшенным вариантом интеграции является классическая интеграция с КСПД (подробнее — в разделе Классическая интеграция с КСПД) и протокол маршрутизации BGP для распространения хостовых маршрутов (/32) виртуальных машин.

Между узлами Платформы и маршрутизаторами сети передачи данных в специальных транспортных VLAN устанавливается BGP-соседство для передачи маршрутной информации, которая включает:

• Префикс /32 (адрес ВМ во внешней сети).
• Next Hop (адрес гипервизора в специальном транспортном VLAN).

Если в инсталляции проектируется несколько зон безопасности, для каждой зоны безопасности должны быть установлены свои BGP-соседства и должны быть свои специальные транспортные VLAN.

Специальные транспортные VLAN должны быть поданы на все сетевые, вычислительные и управляющие узлы с развернутыми NBGP-агентами.

Схема реализации приведена на (рисунок 4).

Рисунок 4 — Схема классической интеграция и BGP-маршрутизации для распространения маршрутов /32

1. Пространство имен ядра Linux расположено на вычислительном и сетевом узле.
2. Специальному транспортному VLAN 500, к которому подключены вычислительный, сетевой, управляющий узлы и два маршрутизатора сети, задана адресация 10.10.40.0/24.
3. Внешняя сеть Платформы 10.10.50.0/24, из которой ВМ, расположенная на вычислительном узле, получила адрес 10.10.50.50.
4. Адрес ВМ из внешней сети 10.10.50.50 анонсируется NBGP с управляющего узла с Next Hop 10.10.40.10, который принадлежит гипервизору.
5. На Платформе может быть несколько внешних сетей, связанных со специальным транспортным VLAN.
6. Специальный транспортный VLAN всегда принадлежит одной зоне безопасности.

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

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

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

Плюсы:

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

Минусы:

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

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

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

Плюсы:

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

Минусы:

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

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

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

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

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

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

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