Комментарии 10
Можно поподробней про IGP на eBGP - все спайны в одной AS ? Пиры на IPv6 Link-Local или надо выделять адресацию?
Привет!
Изначально пошли в историю, когда даже у спайнов (их у нас 8 одном "поде" в моменте) была уникальная AS-ка. Но вот практика показала, что этот вариант не очень, так как при росте количества лифоф анонсов bgp (ненужных по факту) становится уж очень много, и RFC 7938 не просто так рекомендует использовать единую AS-ку на спайны.
Потому теперь да - каждый сервер\лиф - своя AS-ка. Спайны - своя одинаковая в рамках пода, суперспайны - своя одинаковая для всех.
По части IPv6 Link-Local - увы не все вендоры дают возможность строить BGP так. Вернее - вроде бы все дают, но некоторые ВНЕЗАПНО не позволяют гонять af ipv6 в таком кейсе.
Потому пошли в историю с выделением адресации "ручками" роботом
Вы молодцы. А как решён вопрос с pxe загрузкой?
Или проще отдельный гигабит под него в менеджмент свич?
Федя, привет!
проще отдельный гигабит под него в менеджмент свич
Бинго! У нас выделенный менеджмент контур под это всё дело и на серверах есть дополнительная сетёвка на материнке (LoM), который для этого и существует в том числе ну и как Breaking Glass если что.
Но потенциально рассматриваем отказ от такого подхода - тестируем автоматику, которая один из data-портов сервера будет сажать в "выделенный" (но локализованный в пределах коммутатора) VLAN-чик, с выдачей IP по DHCP.
про оверлей не совсем понятно, примерно такая схема?
VM → VPP → SRv6 encapsulation → IPv6 fabric → VPP → VM
тут условно аналогом VNI будет SID, точнее в нем будет Tenаnt-ID?
SRv6 вещь хорошая, но еще хуже поддерживаемая вендорами нежели VXLAN EVPN.
Да и encap/decap не офлоадитсяся на серверах и кушает CPU, что на широких линках несет значимые расходы.
SRv6 без централизованного контроллера приводит к плохому TE, а централизованный контроллер — весьма сложная и ресурсоемкая вещь.
А так, идея классная — L3 фабрика от хоста. Сам был автором похожей конструкции :-)
По части телеметрии рекомендую взглянуть на IOAM. Для него даже в VPP кажется планинчик был.
Пару вопросов:
— какова ширина физического канала до хоста?
— чем строите TE (если ваши вагоны не крашенные, значит нет QoS на андерлее)
— как решаете проблему VPP связанную с низколатентным трафиком? (архитектура VPP ориентирована на максимальную утилизацию полосы в жертву латентности)
— чем обеспечивается потребность в L2 между VM? (Как с т.з датаплейна, так и контролплейна)
Привет, Антон!
Важный момент для понимания - у нас много крутых программистов, которые пилят свой SDN (на базе VPP и SRv6). Ну и какой SDN без контрол-плейна? Он же (контрол-плейн) и несёт в себе функцию контроллера для SRv6.
Ну и кстати, ребята нанимают !
На всякий случай, обзор есть тут - https://habr.com/ru/companies/mws/articles/867064/
И вот в этом видео - vk, youtube
Чуть глубже. где уже рассматриваются специфичные кейсы - вот по ссылкам что выше:
https://habr.com/ru/companies/mws/articles/909050/ - про реализацию DHCP например
https://habr.com/ru/companies/mws/articles/936840/ - про SRv6-шные кишки
Ну это так, что бы понять примерный уровень погружённости в SRv6 и VPP, который у нас есть )
encap/decap не офлоадитсяся на серверах
Не совсем понял куда тут планируется "офлоадить"? на какие-то DPU-шки? Туда пока не смотрим - получается дороговато. Сказать толком нечего, но думаю технически решаемо (https://docs.nvidia.com/doca/archive/doca-v2-5-0/nvidia+doca+release+notes/index.html ) - так что вопрос приложения усилий.
Пока главное не обрабатывать в linux kernel, поэтому "оффлоадим" в VPP
— какова ширина физического канала до хоста?
До Compute-ноды 0 4x25G карточки. Почему не 100? Пока практика показывает что спрос внешний больше на cpu и память у пользователей.
На всяких граничных серверах 4x100G.
— чем строите TE
Такого пока тупо НЕ НУЖНО. Но это опять таки вопрос установки в точке A правильного SID-а и корректной его обработки в точке B. То есть задача SDN-а.
низколатентным трафиком
Я даже пока не понял, увы что за кейс, и что за "проблема". Можешь немного раскрыть? Я врядли отвечу, но может быть найду того, кто сможет ответить. А может не найду ))
L2 между VM
(открываю ящик Пандоры) Ну камон, кому в 26-м году нужен true L2 между VM? Что за кейсы?
Тут важно понимать, что "продвинутый" провайдер облака это, в основном, не про IaaS (VM-ки любой школьник продавать может xD), а про PaaS и более высокоуровневые абстракции.
Ну а, если прям "ОЧЕНЬ НАДО ПЛАТИМ МИЛЛИОН РУБЛЕЙ", то всегда есть https://www.rfc-editor.org/rfc/rfc9252.html#name-bgp-based-ethernet-vpn-evpn ну или "базовый" https://datatracker.ietf.org/doc/html/draft-filsfils-spring-srv6-network-programming-02#page-11
Про офлоадинг — речь про аппаратный разбор SRH. Разгрузка обработки End.DX4/DT6. По аналогии с разгрузкой VXLAN на сетевой карте.
Операция далеко не бесплатная, хоть на VPP она и делается сильно шутсрее чем в ядре, но всеж за счет ресурсов компьюта(не бесплатных)
Ваш ответ понял — используете софтовую разгрузку на VPP за счет векторизации операций.
Обратите внимание, что использование AVX2/AVX512 сильно не бесплатны для CPU и тротлят ему частоту, что снижает эффективность утилизации гипервизора в целом.
Про скорость линков тоже понял. Странно что не 2х100G. С учетом трафика SDS это не очень толстая полоса. К примеру, нам в расчетных характеристиках и 2х100G было тесно для обеспечения высоких IOPS. Не говоря уж про сверхплотные гипервизоры.
Если TE вам не нужно, то как гарантируете полосу и латентность своим клиентам? Как боритесь с кейсом ассиметричной нагрузки разными клиентами? А трафик хранилки относительно клиентов?
Понятно что все это делается SIDами, но только при программировании всего пути по фабрике с пристройкой QoS. Возможно вы знаете альтернативный способ?
Низколатентный трафик — трафик требующий приоритета не по ширине полосы, а по очереди в буферах rx/tx. У клиента виртуализации полно сценариев где он ожидает привычный джиттер без переподписки. (кеши, HFT, кворумные механизмы, невросетки, синхронные репликации и т.д)
Не знаю как у вас, но обычно и в самой платформе виртуализации есть низколатентный трафик (например при живой миграции VM требуется синхронизировать виртуальную память и на определенных сценариях нагрузки клиентской VM латентность сети становится узким местом)
L2 связность в VPC — камон, даже в 2126 потребность в L2 останется в корпоративном сегменте. Огромное число проприоритарных решений использует L2-протоколы (HFT, репликации, дискаверинг, мультимедиа и т.д)
Да даже банальные тестовые среды инфраструктурных компонент без L2 становятся болью.
Мы в далеком прошлом сбежали из одного Клауда на последнюю букву русского алфавита, потому что устали строить свой оверлей поверх из VPC чтоб запустить нормально IPv6.
А подавляюще большинство т.н отечественного софта из реестра отечественного ПО для резервирования все еще использует VRRP и требует единый боардкаст домен.
Увы, все мечтают избавится от L2, но все прикручивают для него костыли. И лучше, когда они системные.
Для L2 в SRv6 тоже все есть, но придется или городить свой контролплейн или откатится к уже решенной задаче — SRv6 + EVPN.
Ну и про VMки продавать может любой школьник — это конечно очень оптимистично. VMки со SLA, быстрыми дисками и быстрой сетью (хотяб уровня VMWARE) в РФ крайне проблематично получить. А там где их получить можно встречаются все те же иностранные вендоры. «Продвинутый» провайдер облака IaaS для корпоративных клиентов — это не тот, кто предоставляет массу PaaS-услуг, а тот кто выдерживает SLA по базовым метрикам IaaS. Так, чтоб миграция корпората своей привычной инфрой с железяк с VMWare в облако проходила без боли и унижения :-)
А потом уже можно апсейлить PaaS бусами…
P.S: мы когда проектировали компонент SDN для он-прем платформы, выбрали решение EVPN как контролплейн и MPLS как датаплейн. При том, что VPР занимается лейблингом. И тоже IPv6-only андерлей. Собственно я потому на TE и делаю акцент, что в нашей схеме мы не придумали эффективный TE без подпорок. А в SRv6 это сделать проще.
Сеть, с которой всё начинается: как устроен Underlay в MWS Cloud Platform