Pull to refresh

Comments 13

Не до конца понятно, IP Fabric (Underlay network) — это что? Обычные Juniper-овские коммутаторы, которые управляются с контроллера? Или какая-то специфичная линейка оборудования? По схеме не вижу, чтобы они как-то были связаны с Contrail. Весь SDN работает только с виртуальными маршрутизаторами vMX?
см. ответ ниже
В случае моей лабы, все крутится на одном сервере, и в роли «IP fabric» выступает просто VMware vSwitch, к которому подключена каждая из машин своим единственным интерфейсом. В реальном ЦОДе фабрика будет состоять из кучи свичей/роутеров вроде Juniper EX/QFX/MX или любого другого вендора. Контрейл работает с оверлеем и ему не важно, из чего состоит фабрика.

vMX и Contrail SDN — перпендикулярны, одно не требует другое. vRouter, упоминаемый в статье — это не vMX, и не похож на него.

Тем не менее MX или vMX роутеры могут использоваться вместе с Contrail — обычно в качестве шлюза, соединяющего физическую сеть (Интернет и пр.) с виртуальной.

Спасибо за хороший вопрос.
Подождите, концепт SDNа обычно состоит в том, что есть некий контроллер (здесь contrail), в который вынесена вся обработка control plane (или я что-то не понимаю?). Вы говорите, что vMX и vRouter перпендикулярны контроллеру. Так чем же в предложенной вами схеме может управлять контроллер? Интересует общий случай, а не конкретно ваша лаба. И может ли контрейл управлять какими-то другими (какими?), не виртуальными, сетевыми железками? Иначе получается, что весь предлагаемый SDN ничто иное, как просто система управления NMS корзинами серверов.
Определение SDN — да, совершенно верно, разделение контрол и форвардинг + централизация форвардинга. Здесь все это применимо.

Далее смотрите, Contrail состоит из двух компонент — Contrail Controller (все вместе 4 типа нодов, см. в статье) и Contrail vRouter — это уже не часть контроллера, а forwarding plane компонента (софтверная, запущенная на сервере) — которыми контроллер как раз и командует. См. также картинку.

Когда я сказал что vMX перпендикулярен, имелось в виду что его можно использовать — можно не использовать. Теперь по поводу использовать. Для связи виртуальной сети и физической сети надо иметь роутер — физический (MX) или опять же виртуальный (vMX), вообще годится любой вендор. Этот роутер должен быть настроен примерно как MPLS PE. Ну так вот, в случае Juniper (v)MX, Contrail Controller может таки настраивать эти (v)MX сам — по протоколу NETCONF (это также отмечено на картинке).

Если что-то не ясно, спрашивайте, может завтра яснее получится изложить.
Перечитал и ужаснулся. Естественно, имелась в виду централизация контрол-плейна, а не форвардинга.
Вот есть абстрактный ЦОД с множеством стоек с блейдами, на которых крутятся множество ВМ. На каждой корзине на одной из ВМ ставится образ vRouter, эта ВМ является маршрутизатором для всех остальных ВМ в этой корзине. Всеми этими vRouterами в каждой корзине управляет один контроллер. Я так все понимаю?

Теперь для ЦОДа для подключения каждой корзины ставится пачка не важно каких коммутаторов (не обязательно qfabric или nexus) и одна PE (упростим). Контроллер может управлять этой же PE. Здесь тоже все верно понял?

А теперь вот вопрос — какой толк от всего этого SDNа, если он не может управлять коммутаторами? И для чего нужен функционал роутера в виде виртуальной машины? Все ВМ все равно по IP терминируются на единственной PE (ну пусть на двух), до каждой ВМ просто тянется влан.
1) Правильно с точностью до того, что vRouter это все-таки не виртуальная машина, а модуль ядра гипервизора — в случае если мы используем KVM-гипервизор, как это обычно предполагается. Правда если делать интеграцию с ESXi, то там vRouter это уже как раз виртуалка и все в точности как вы сказали.

2) Верно. Для разворачивания фабрики предполагается, что должны использоваться другие инструменты. У Джунипера это например OpenClos.

3) Здесь идея в том, что Contrail за счет того что он работает с оверлеем, позволяет вам получить SDN/NFV «прям щас», на любом физическом оборудовании. Никаких вланов через ЦОД больше не тянется, это тоже одно из преимуществ. Собственно одна из задач как раз избавиться от вланов. Как говорится, бродкастный домен = единая точка отказа. Нужна только L3 фабрика. Что если у вас более 4096 клиентов?

Я не понял вопрос насчет роутера в виде виртуальной машины. Это кому как, кому нужно, кому нет. Приложения и задачи разные. Есть концепция NFV (виртуализации сетевых функций), в которой предполагается что все сервисы должны делаться виртуально. Другое дело опять же кому и где это будет актуально. В общем для этого.
А если нужно именно L2 между парой ВМ, расположенных на разных корзинах? Здесь без SDNа?

И еще момент — получается весь предлагаемый SDN нужен ТОЛЬКО для виртуальных машин, к реальному физическому оборудованию (серверы, сетевые железки) он практически не относится (за исключением netconf на PE).

P.S. Как говорится, бродкастный домен = единая точка отказа. Нужна только L3 фабрика. Что если у вас более 4096 клиентов? Если грамотно все сделать, не будет в одном не разделенном L2 столько оборудования, которое будет создавать проблемы. Больше 4094 — есть QinQ. Кроме того, мне с трудом представляется схема, когда на один порт PE (хоть 100GE) будет создано больше 4094 статических сабов (не vitrual-template).
Связность по L2 Contrail обеспечивает, просто в оверлей упаковывается фрейм целиком. Собственно это работает по умолчанию. L3-оверлей он тоже умеет.

Основное применение — да, для облаков где все виртуальное. Есть вариант когда ваши свичи (любой в принципе вендор) терминируют VXLAN и Contrail с ними общается по OVSDB. Тогда и обычные bare-metal сервера можно подключать.
Ок, спасибо за разъяснение. Мир SDN становится все более освещенным)
зачем такое поднимать без vMX? оверлейный sdn без гейта — это вещь в себе.
Вы имеете в виду в лабе? У меня-то оно есть. Но просто установка vMX это немножко отдельная тема. А играться можно и без шлюза, смотря что хотим тестировать.

Также есть Simple Virtual Gateway — это когда из VRF напрямую дается доступ в сеть фабрики. Как-бы шлюз но без туннелирования. Для лабы годится.
Sign up to leave a comment.

Articles