Комментарии 4
Спасибо, что делитесь опытом.
Все-таки сеть Кло (может быть построена как) полная неблокирующая, (насколько я помню) логарифмическая по глубине и линейно-логарифмическая по объему, в которой выполнение единичной перекоммутации вычисляется и занимает log N единиц времени, а полной случайной - N log N единиц времени.
К DragonFly есть вопросы:
*Ладно, пусть она не полна (когда выигрывает у сети Клоза, не способна соединить абонентов совсем уж в произвольные пары), но есть ли оценки вероятности ее отказа при случайной коммутации? Одно дело, если при конкурентных параметрах она выполняет коммутацию для 99,99% случайных перестановок, другое дело, если только для 50% таких перестановок.
*Время вычисления путей коммутации. Если вдруг завтра откроют очень хорошую сеть: полную, неблокирующую, логарифмическую по глубине и линейно логарифмическую по объему, но маршруты коммутации в этой сети будут вычисляться за экспоненциальное время, вряд ли такая сеть окажется полезной. Каковы у DragonFly оценки времени поиска пути перекоммутации для единственной пары абонентов (коммутация остальных пар остается прежней) и время поиска путей случайной перекоммутации всех пар?
В стандартных ситуациях мы всё же не оперируем отдельными парами, поскольку маршрутная информация распространяется в агрегированном виде. Поэтому обычно говорим о скорости реакции сети на обрывы и скорости сходимости сети.
Детектирование аварии на линке и обновление FIB происходит за единицы миллисекунд. Из-за наличия нескольких путей при трафик переключается на альтернативные примерно в это же время.
Перекоммутаций как таковых никаких не происходит.
не способна соединить абонентов совсем уж в произвольные пары
Этот тезис не понял. Что Клоз, что Драгонфлай по сути представляет связность между любой парой хостов - вопрос только в диаметре. А так же в том, что нахождение пути не означает нахождение полосы.
Осилил и дочитал - огромное спасибо за такую колоссальную работу! :)
Понял, что DragonFly (с плюсами или без)) в реальности пощупать в ближайшее время не смогу. Такое станет реальностью только если будет какое-то решение по контроллеру Segment Routing с открытым исходным кодом для хостов виртуализации с учетом телеметрии от сетевых коробок.
И вот тогда это решение не то что "пробовать" в лабе, но и внедрять многие пойдут - просто потому что это более экономично с точки зрения CAPEX на сеть!
Динамика по BGP с Leaf/Spine и арбитром под MIN+1 как по мне не выглядит хорошо без ECN + Flow Label -> просто потому что мы надеемся на авось, о том "жирные" потоки будут перекладываться на MIN+1 линии -> а так есть хоть какой-то "условный" механизм обратной связи :)
А это тянет за собой IPv6 и так или иначе работу с хостами (чтобы переписывали Flow Label)... вообщем если вы не Яндекс - можно забыть :)
Осилил и дочитал - огромное спасибо за такую колоссальную работу! :)
Спасибо) Это было интересно
А это тянет за собой IPv6 и так или иначе работу с хостами (чтобы переписывали Flow Label)... вообщем если вы не Яндекс - можно забыть :)
На самом деле нет. Я описал решение, которое мы делаем в Яндексе - довольно простой контроллер, который следит за утилизация на основе собираемых метрик, плюс динамическое управление политиками ликинга маршрутов. Никакого SR или тем более SRv6. Если есть система управления конфигурацией, то в целом довольно доступно.
И вот тогда это решение не то что "пробовать" в лабе, но и внедрять многие пойдут - просто потому что это более экономично с точки зрения CAPEX на сеть!
А вот тут нет факт совсем. Потому что помимо CAPEX на железо, есть ещё ФОТ команд это разрабатывающих и поддерживающих, плюс более высокие эксплуатационные расходы.
Что ещё более важно, неизвестно на самом деле насколько Dragonfly подходит под задачи обычных ДЦ (публичные облака, baremetal и подобное), где очень неравномерный трафик, а управлять размещением пользовательских ресурсов и объёмом трафика мы не можем.
Топология Dragonfly для дата-центровых сетей