- PVSM.RU - https://www.pvsm.ru -
В предыдущем выпуске [1] я описал фреймворк сетевой автоматизации. По отзывам у некоторых людей даже этот первый подход к проблеме уже разложил некоторые вопросы по полочкам. И это очень меня радует, потому что наша цель в цикле — не обмазать питоновскими скриптами анзибль, а выстроить систему.
Этот же фреймворк задаёт порядок, в котором мы будем разбираться с вопросом.
И виртуализация сети, которой посвящён этот выпуск, не особо укладывается в тематику АДСМ, где мы разбираем автоматику.
Но давайте взглянем на неё под другим углом.
Уже давно одной сетью пользуются многие сервисы. В случае оператора связи это 2G, 3G, LTE, ШПД и B2B, например. В случае ДЦ: связность для разных клиентов, Интернет, блочное хранилище, объектное хранилище.
И все сервисы требуют изоляции друг от друга. Так появились оверлейные сети.
И все сервисы не хотят ждать, когда человек настроит их вручную. Так появились оркестраторы и SDN.
Первый подход к систематической автоматизации сети, точнее её части, давно предпринят и много где внедрён в жизнь: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.
Вот с ним сегодня и поразбираемся.
И раз уж мы об этом заговорили, то стоит упомянуть предпосылки к виртуализации сети. На самом деле этот процесс начался не вчера.
Наверно, вы не раз слышали, что сеть всегда была самой инертной частью любой системы. И это правда во всех смыслах. Сеть — это базис, на который опирается всё, и производить изменения на ней довольно сложно — сервисы не терпят, когда сеть лежит. Зачастую вывод из эксплуатации одного узла может сложить большую часть приложений и повлиять на много клиентов. Отчасти поэтому сетевая команда может сопротивляться любым изменениям — потому что сейчас оно как-то работает (мы, возможно, даже не знаем как), а тут надо что-то новое настроить, и неизвестно как оно повлияет на сеть.
Чтобы не ждать, когда сетевики прокинут VLAN и любые сервисы не прописывать на каждом узле сети, люди придумали использовать оверлеи — наложенные сети — коих великое многообразие: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE итд.
Их привлекательность заключается в двух простых вещах:
— Настраиваются только конечные узлы — транзитные трогать не приходится. Это значительно ускоряет процесс, а иногда вообще позволяет исключить отдел сетевой инфраструктуры из процесса ввода новых сервисов.
— Нагрузка сокрыта глубоко внутри заголовков — транзитным узлам не нужно ничего знать о ней, об адресации на хостах, маршрутах наложенной сети. А это значит, нужно хранить меньше информации в таблицах, значит взять попроще/подешевле устройство.
В этом не совсем полноценном выпуске я не планирую разбирать все возможные технологии, а скорее описать фреймворк работы оверлейных сетей в ДЦ.
Вся серия будет описывать датацентр, состоящий из рядов однотипных стоек, в которых установлено одинаковое серверное оборудование.
На этом оборудовании запускаются виртуальные машины/контейнеры/серверлесс, реализующие сервисы.
В цикле сервером я буду называть программу, которая реализует серверную сторону клиент-серверной коммуникации.
Физические машины в стойках называть серверами не будем.
Физическая машина — x86-компьютер, установленный в стойке. Наиболее часто употребим термин хост. Так и будем называть её "машина" или хост.
Гипервизор — приложение, запущенное на физической машине, эмулирующее физические ресурсы, на которых запускаются Виртуальные Машины. Иногда в литературе и сети слово «гипервизор» используют как синоним «хост».
Виртуальная машина — операционная система, запущенная на физической машине поверх гипервизора. Для нас в рамках данного цикла не так уж важно, на самом ли деле это виртуальная машина или просто контейнер. Будем называть это "ВМ"
Тенант — широкое понятие, которое я в этой статье определю как отдельный сервис или отдельный клиент.
Мульти-тенантность или мультиарендность — использование одного и того же приложения разными клиентами/сервисами. При этом изоляция клиентов друг от друга достигается благодаря архитектуре приложения, а не отдельно-запущенным экземплярам.
ToR — Top of the Rack switch — коммутатор, установленный в стойке, к которому подключены все физические машины.
Кроме топологии ToR, разные провайдеры практикуют End of Row (EoR) или Middle of Row (хотя последнее — пренебрежительная редкость и аббревиатуры MoR я не встречал).
Underlay network или подлежащая сеть или андэрлей — физическая сетевая инфраструктура: коммутаторы, маршрутизаторы, кабели.
Overlay network или наложенная сеть или оверлей — виртуальная сеть туннелей, работающая поверх физической.
L3-фабрика или IP-фабрика — потрясающее изобретение человечества, позволяющее к собеседованиям не повторять STP и не учить TRILL. Концепция, в которой вся сеть вплоть до уровня доступа исключительно L3, без VLAN и соответственно огромных растянутых широковещательных доменов. Откуда тут слово «фабрика» разберёмся в следующей части.
SDN — Software Defined Network. Едва ли нуждается в представлении. Подход к управлению сетью, когда изменения на сети выполняются не человеком, а программой. Обычно означает вынесение Control Plane за пределы конечных сетевых устройств на контроллер.
NFV — Network Function Virtualization — виртуализация сетевых устройств, предполагающая, что часть функций сети можно запускать в виде виртуальных машин или контейнеров для ускорения внедрения новых сервисов, организации Service Chaining и более простой горизонтальной масштабируемости.
VNF — Virtual Network Function. Конкретное виртуальное устройство: маршрутизатор, коммутатор, файрвол, NAT, IPS/IDS итд.
Я сейчас намеренно упрощаю описание до конкретной реализации, чтобы сильно не запутывать читателя. Для более вдумчивого чтения отсылаю его к секции Ссылки [3]. Кроме того, Рома Горге, критикующий данную статью за неточности, обещает написать отдельный выпуск о технологиях виртуализации серверов и сетей, более глубокую и внимательную к деталям.
Большинство сетей сегодня можно явно разбить на две части:
Underlay — физическая сеть со стабильной конфигурацией.
Overlay — абстракция над Underlay для изоляции тенантов.
Это верно, как для случая ДЦ (который мы разберём в этой статьей), так и для ISP (который мы разбирать не будем, потому что уже было в СДСМ [4]). С энтерпрайзными сетями, конечно, ситуация несколько иная.
Картинка с фокусом на сеть:
Underlay — это физическая сеть: аппаратные коммутаторы и кабели. Устройства в андерлее знают, как добраться до физических машин.
Опирается он на стандартные протоколы и технологии. Не в последнюю очередь потому, что аппаратные устройства по сей день работают на проприетарном ПО, не допускающем ни программирование чипа, ни реализацию своих протоколов, соответственно, нужна совместимость с другими вендорами и стандартизация.
А вот кто-нибудь вроде Гугла может себе позволить разработку собственных коммутаторов и отказ от общепринятых протоколов. Но LAN_DC не Гугл.
Underlay сравнительно редко меняется, потому что его задача — базовая IP-связность между физическими машинами. Underlay ничего не знает о запущенных поверх него сервисах, клиентах, тенантах — ему нужно только доставить пакет от одной машины до другой.
Underlay может быть например таким:
Настраивается Underlay'ная сеть классическим образом: CLI/GUI/NETCONF.
Вручную, скриптами, проприетарными утилитами.
Более подробно андерлею будет посвящена следующая статья цикла.
Overlay — виртуальная сеть туннелей, натянутая поверх Underlay, она позволяет ВМ одного клиента общаться друг с другом, при этом обеспечивая изоляцию от других клиентов.
Данные клиента инкапсулируются в какие-либо туннелирующие заголовки для передачи через общую сеть.
Так ВМ одного клиента (одного сервиса) могут общаться друг с другом через Overlay, даже не подозревая какой на самом деле путь проходит пакет.
Overlay может быть например таким, как уже я упоминал выше:
Overlay'ная сеть обычно настраивается и поддерживается через центральный контроллер. С него конфигурация, Control Plane и Data Plane доставляются на устройства, которые занимаются маршрутизацией и инкапсуляцией клиентского трафика. Чуть ниже [5] разберём это на примерах.
Да, это SDN в чистом виде.
Существует два принципиально различающихся подхода к организации Overlay-сети:
Overlay может начинаться на коммутаторе доступа (ToR), стоящем в стойке, как это происходит, например, в случае VXLAN-фабрики.
Это проверенный временем на сетях ISP механизм и все вендоры сетевого оборудования его поддерживают.
Однако в этом случае ToR-коммутатор должен уметь разделять различные сервисы, соответственно, а сетевой администратор должен в известной степени сотрудничать с администраторами виртуальных машин и вносить изменения (пусть и автоматически) в конфигурацию устройств.
Тут я отошлю читателя к статье о VxLAN на хабре [6] нашего старого друга @bormoglotx [7].
В этой презентации с ENOG [8] подробно описаны подходы к строительству сети ДЦ с EVPN VXLAN-фабрикой.
А для более полного погружения в реалии, можно почитать цискину книгу A Modern, Open, and Scalable Fabric: VXLAN EVPN [9].
Замечу, что VXLAN — это только метод инкапсуляции и терминация туннелей может происходить не на ToR'е, а на хосте, как это происходит в случае OpenStack'а, например.
Однако, VXLAN-фабрика, где overlay начинается на ToR'е является одним из устоявшихся дизайнов оверлейной сети.
Другой подход — начинать и терминировать туннели на конечных хостах.
В этом случае сеть (Underlay) остаётся максимально простой и статичной.
А хост сам делает все необходимые инкапсуляции.
Для этого потребуется, безусловно, запускать специальное приложение на хостах, но оно того стоит.
Во-первых, запустить клиент на linux-машине проще или, скажем так, — вообще возможно — в то время как на коммутаторе, скорее всего, придётся пока обращаться к проприетарным SDN-решениям, что убивает идею мультивендорности.
Во-вторых, ToR-коммутатор в этом случае можно оставить максимально простым, как с точки зрения Control Plane'а, так и Data Plane'а. Действительно — с SDN-контроллером ему тогда общаться не нужно, и хранить сети/ARP'ы всех подключенных клиентов — тоже — достаточно знать IP-адрес физической машины, что кратно облегчает таблицы коммутации/маршрутизации.
Проще всего рассмотреть на примерах. И в качестве подопытного мы возьмём OpenSource'ную SDN платформу OpenContrail, ныне известную как Tungsten Fabric [10].
В конце статьи я приведу некоторые размышления на тему аналогии с OpenFlow и OpenvSwitch.
На каждой физической машине есть vRouter — виртуальный маршрутизатор, который знает о подключенных к нему сетях и каким клиентам они принадлежат — по сути — PE-маршрутизатор. Для каждого клиента он поддерживает изолированную таблицу маршрутизации (читай VRF). И собственно vRouter делает Overlay'ное туннелирование.
Чуть подробнее про vRouter — в конце статьи.
Каждая ВМ, расположенная на гипервизоре, соединяется с vRouter'ом этой машины через TAP-интерфейс [11].
TAP — Terminal Access Point — виртуальный интерфейс в ядре linux, которые позволяет осуществлять сетевое взаимодействие.
Если за vRouter'ом находится несколько сетей, то для каждой из них создаётся виртуальный интерфейс, на который назначается IP-адрес — он будет адресом шлюза по умолчанию.
Все сети одного клиента помещаются в один VRF (одну таблицу), разных — в разные.
Сделаю тут оговорку, что не всё так просто, и отправлю любознательного читателя в конец статьи.
Чтобы vRouter'ы могли общаться друг с другом, а соответственно и ВМ, находящиеся за ними, они обмениваются маршрутной информацией через SDN-контроллер.
Чтобы выбраться во внешний мир, существует точка выхода из матрицы — шлюз виртуальной сети VNGW — Virtual Network GateWay (термин мой).
Теперь рассмотрим примеры коммуникаций — и будет ясность.
VM0 хочет отправить пакет на VM2. Предположим пока, что это ВМ одного клиента.
Пакет в этом случае не попадает в физическую сеть — он смаршрутизировался внутри vRouter'а.
Гипервизор при запуске виртуальной машины сообщает ей:
vRouter'у через специальный API гипервизор сообщает:
И снова, реальная процедура взаимодействия упрощена в угоду понимания концепции.
Таким образом все ВМ одного клиента на данной машине vRouter видит как непосредственно подключенные сети и может сам между ними маршрутизировать.
А вот VM0 и VM1 принадлежат разным клиентам, соответственно, находятся в разных таблицах vRouter'а.
Смогут ли они друг с другом общаться напрямую, зависит от настроек vRouter и дизайна сети.
Например, если ВМ обоих клиентов используют публичные адреса, или NAT происходит на самом vRouter'е, то можно сделать и прямую маршрутизацию на vRouter.
В противной же ситуации возможно пересечение адресных пространств — нужно ходить через NAT-сервер, чтобы получить публичный адрес — это похоже на выход во внешние сети, о которых ниже.
При запуске машины происходит всё то же, что было описано выше.
И плюс ещё следующее:
На самом деле MPLS-метка выделяется vRouter'ом безусловно всегда — ведь неизвестно заранее, что машина будет взаимодействовать только с другими машинам за тем же vRouter'ом и это скорее всего даже не так.
То же самое происходит и в обратную сторону.
Overlay может меняться хоть каждую минуту. Примерно так это и происходит в публичных облаках, когда клиенты регулярно запускают и выключают свои виртуальные машины.
Центральный контроллер берёт на себя все сложности с поддержанием конфигурации и контролем таблиц коммутации/маршрутизации на vRouter.
Если говорить грубо, то контроллер запиривается со всеми vRouter'ами по BGP (или похожему на него протоколу) и просто передаёт маршрутную информацию. BGP, например, уже имеет Address-Family для передачи метода инкапсуляции MPLS-in-GRE [16] или MPLS-in-UDP [17].
При этом не меняется никоим образом конфигурация Underlay-сети, которую кстати, автоматизировать на порядок сложнее, а сломать неловким движением проще.
Где-то симуляция должна закончиться, и из виртуального мира нужно выйти в реальный. И нужен таксофон шлюз.
Практикуют два подхода:
Преимущество второго подхода в дешёвой горизонтальной масштабируемости — не хватает мощности — запустили ещё одну виртуалку со шлюзом. На любой физической машине, без необходимости искать свободные стойки, юниты, вывода питания, покупать саму железку, везти её, устанавливать, коммутировать, настраивать, а потом ещё и менять в ней сбойные компоненты.
Минусы же у виртуального шлюза в том, что единица физического маршрутизатора всё же на порядки мощнее многоядерной виртуалки, а его софт, подогнанный под его же аппаратную основу, работает значительно стабильнее (нет). Сложно отрицать и тот факт, что программно-аппаратный комплекс просто работает, требуя только настройки, в то время как запуск и обслуживание виртуального шлюза — занятие для сильных инженеров.
Одной своей ногой шлюз смотрит в виртуальную сеть Overlay, как обычная Виртуальная Машина, и может взаимодействовать со всеми другими ВМ. При этом она может терминировать на себе сети всех клиентов и, соответственно, осуществлять и маршрутизацию между ними.
Другой ногой шлюз смотрит уже в магистральную сеть и знает о том, как выбраться в Интернет.
То есть процесс выглядит так:
Трафик в обратную сторону проходит те же шаги в противоположном порядке.
VNGW1 устанавливает BGP-соседство с SDN-контроллером, от которого он получает всю маршрутную информацию о клиентах: за каким IP-адресом (vRouter'ом) находится какой клиент, и какой MPLS-меткой он идентифицируется.
Аналогично он сам SDN-контроллеру сообщает дефолтный маршрут с меткой этого клиента, указывая себя в качестве nexthop'а. А дальше этот дефолт приезжает на vRouter'ы.
На VNGW обычно происходит агрегация маршрутов или NAT-трансляция.
И в другую сторону в сессию с бордерами или Route Reflector'ами он отдаёт именно этот агрегированный маршрут. А от них получает маршрут по умолчанию или Full-View, или что-то ещё.
В плане инкапсуляции и обмена трафиком VNGW ничем не отличается от vRouter.
Если немного расширить область, то к VNGW и vRouter'ам можно добавить другие сетевые устройства, такие как файрволы, фермы очистки или обогащения трафика, IPS итд.
И с помощью последовательного создания VRF и правильного анонса маршрутов, можно заставлять трафик петлять так, как вам хочется, что и называется Service Chaining'ом.
То есть и тут SDN-контроллер выступает в роли Route-Reflector'а между VNGW, vRouter'ами и другими сетевыми устройствами.
Но фактически контроллер спускает ещё информацию об ACL и PBR (Policy Based Routing), заставляя отдельные потоки трафика ходить не так, как им велит маршрут.
Зачем ты всё время делаешь ремарку GRE/UDP?
Ну, вообще, это, можно сказать, специфично для Tungsten Fabric — можно вообще не брать во-внимание.
Но если брать, то сам TF, ещё будучи OpenContrail'ом поддерживал обе инкапсуляции: MPLS in GRE и MPLS in UDP.
UDP хорош тем, что в Source Port в его заголовке очень легко закодировать хэш-функцию от изначальных IP+Proto+Port, что позволит делать балансировку.
В случае GRE, увы, есть только внешние заголовки IP и GRE, которые одинаковы для всего инкапсулированного трафика и речь о балансировке не идёт — мало кто может заглянуть так глубоко внутрь пакета.
До некоторого времени маршрутизаторы, если и умели в динамические туннели, то только в MPLSoGRE, и только совсем недавно, научились в MPLSoUDP. Поэтому приходится делать всегда ремарку о возможности двух разных инкапсуляций.
Справедливости ради, стоит отметить, что TF вполне поддерживает и L2-связность с помощью VXLAN.
Ты обещал провести параллели с OpenFlow.
Они и правда напрашиваются. vSwitch в том же OpenStack'е делает весьма похожие вещи, используя VXLAN, у которого, кстати, тоже UDP-заголовок.
В Data Plane они работают примерно одинаково, существенно различается Control Plane. Tungsten Fabric использует XMPP для доставки информации о маршрутах на vRouter, в то время, как в OpenStack'е работает Openflow.
А можно чуть больше про vRouter?
Он делится на две части: vRouter Agent и vRouter Forwarder.
Первый запускается в User Space хостовой ОС и общается с SDN-контроллером, обмениваясь информацией о маршрутах, VRF и ACL.
Второй реализует Data Plane — обычно в Kernel Space, но может запускаться и на SmartNIC'ах — сетевых картах с CPU и отдельным программируемым чипом коммутации, что позволяет снять нагрузку с CPU хостовой машины, а сеть сделать быстрее и более предсказуемой.
Ещё возможен сценарий, когда vRouter — это DPDK-приложение в User Space.
vRouter Agent спускает настройки на vRouter Forwarder.
Что за Virtual Network?
Я обмолвился в начале статьи о VRF, что мол каждый тенант привязывается к своему VRF. И если для поверхностного понимания работы оверлейной сети этого было достаточно, то уже на следующей итерации надо делать уточнения.
Обычно в механизмах виртуализации сущность Virtual Network (можно считать это именем собственным) вводится отдельно от клиентов/тенантов/виртуальных машин — вполне себе самостоятельная вещь. А этот Virtual Network через интерфейсы уже можно подключить в один тенант, в другой, в два, да хоть куда. Так, например, реализуется Service Chaining, когда трафик нужно пропустить через определённые ноды в нужной последовательности, просто в правильной последовательности создавая и привзявая Virtual Network'и.
Поэтому как такового прямого соответствия между Virtual Network и тенантом нет.
Это весьма поверхностное описание работы виртуальной сети с оверлеем с хоста и SDN-контроллером. Но какую бы платформу виртуализации вы сегодня ни взяли, работать она будет похожим образом, будь то VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric или Juniper Contrail. Они будут отличаться видами инкапсуляций и заголовков, протоколами доставки информации на конечные сетевые устройства, но принцип программно настраиваемой оверлейной сети, работающей поверх сравнительно простой и статичной андерлейной сети останется прежним.
Можно сказать, что области создания приватного облака на сегодняшний день SDN на основе оверлейной сети победил. Впрочем это не значит, что Openflow нет места в современном мире — он используется в OpenStacke и в той же VMWare NSX, его, насколько мне известно, использует Google для настройки андерлейной сети.
Чуть ниже я привёл ссылки на более подробные материалы, если хочется изучить вопрос глубже.
А что там наш Underlay?
А в общем-то ничего. Он всю дорогу не менялся. Всё, что ему нужно делать в случае оверлея с хоста — это обновлять маршруты и ARP'ы по мере появления и исчезновения vRouter/VNGW и таскать пакеты между ними.
Давайте сформулируем список требований к Underlay-сети.
Работе самой Underlay-сети я посвятил здесь совсем мало времени. Это потому, что далее в серии я именно на ней и сосредоточусь, а Overlay мы будем затрагивать только вскользь.
Очевидно, я сильно ограничиваю нас всех, используя в качестве примера сеть ДЦ, построенную на фабрике Клоза с чистой IP-маршрутизацией и оверлеем с хоста.
Однако я уверен, что любую сеть, имеющую дизайн, можно описать в формальных терминах и автоматизировать. Просто я здесь преследую целью разобраться в подходах к автоматизации, а не запутать всех вообще, решая задачу в общем виде.
В рамках АДСМ мы с Романом Горге планируем опубликовать отдельный выпуск про виртуализацию вычислительных мощностей и её взаимодействие с виртуализацией сети. Оставайтесь на связи.
Автор: Марат
Источник [28]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/avtomatizatsiya/323112
Ссылки в тексте:
[1] предыдущем выпуске: https://habr.com/ru/post/453516/
[2] Image: https://fs.linkmeup.ru/images/adsm/1/kdpv.jpg
[3] Ссылки: #LINKS
[4] СДСМ: https://linkmeup.ru/sdsm
[5] ниже: #TF
[6] VxLAN на хабре: https://habr.com/ru/post/344326/
[7] @bormoglotx: https://habr.com/ru/users/bormoglotx/
[8] презентации с ENOG: https://www.enog.org/wp-content/uploads/presentations/enog-16/18-Scaleway-P14-fabric-ENOG16.pdf
[9] A Modern, Open, and Scalable Fabric: VXLAN EVPN: https://www.cisco.com/c/dam/en/us/td/docs/switches/datacenter/nexus9000/sw/vxlan_evpn/VXLAN_EVPN.pdf
[10] Tungsten Fabric: https://tungsten.io
[11] TAP-интерфейс: https://en.wikipedia.org/wiki/TUN/TAP
[12] Image: https://fs.linkmeup.ru/images/adsm/1/sdn-controller.png
[13] Image: https://fs.linkmeup.ru/images/adsm/1/vngw.png
[14] Image: https://fs.linkmeup.ru/images/adsm/1/inter-hv-dp.png
[15] Image: https://fs.linkmeup.ru/images/adsm/1/inter-hv-cp.png
[16] MPLS-in-GRE: https://tools.ietf.org/html/rfc4023
[17] MPLS-in-UDP: https://tools.ietf.org/html/rfc7510
[18] Image: https://fs.linkmeup.ru/images/adsm/1/outside-dp.png
[19] Image: https://fs.linkmeup.ru/images/adsm/1/outside-dp-reverse.png
[20] Image: https://fs.linkmeup.ru/images/adsm/1/outside-cp.png
[21] Tungsten Fabric Archvitecture: https://tungstenfabric.github.io/website/
[22] about:cloud: https://youtu.be/Kr6WIYPts8I?t=3157
[23] What Is Open vSwitch?: https://docs.openvswitch.org/en/latest/intro/what-is-ovs/
[24] Роману Горге: https://www.linkedin.com/in/roman-gorge-2b15896b/?originalSubdomain=se
[25] Александру Шалимову: https://www.alexander-shalimov.com
[26] Валентину Синицыну: https://www.linkedin.com/in/valentine-sinitsyn-b8b3a23a/
[27] Артёму Чернобаю: http://illustrators.ru/users/rabbits_manufactory
[28] Источник: https://habr.com/ru/post/458622/?utm_source=habrahabr&utm_medium=rss&utm_campaign=458622
Нажмите здесь для печати.