Под чудовищным legacy я тут подразумеваю такие штуки как Frame Relay, SDH, попытки синхронизации времени через IP-сеть или непосредственно Ethernet. NAT!
И это в некотором смысле добро, потому что всё, что поверх продолжает работать. Просто весь багаж техдолга вынесен на уровень фундамента :)
Я как раз приводил примеры проблем в сети, которые с виду простые, но локализовать их не так-то просто. Тут или нужны хорошие полные инструкции по диагностике, либо профессиональная интуиция.
И они требуют как раз знания инструментария.
Ну а без технических подробностей, потому что публикация рассчитана немного на другую аудиторию, и у меня есть места, где их как раз в достатке)
На самом деле мне близки вещи, которые вы описали. И согласен почти со всем.
Однако для того, чтобы что-то случилось, об этом нужно говорить. Говорить нужно много и при любой возможности, прожужжать всем уши и стучаться через все каналы. И тогда, после того, как каждый будет знать, что есть NETCONF, появится и запрос.
Это мне так кажется. Возможно, ошибаюсь, потому что тот же gRPC элементарно решал насущные задачи разработчиков, поэтому стал стандартом де-факто для межсервисного взаимодействия. Возможно, новые интерфейсы для сети не решают их. Или не делают этого пока - спрос ещё не созрел.
Но, я уверен, что как и со многими другими технологиями (тот же gRPC, или k8s, Go, React, OSquery, GraphQL) они сначала зарождаются в недрах компаний, для которых это вопрос выживания, а потом становятся распространены в индустрии, то же самое произойдёт (уже происходит) с NETCONF/YANG, gNMI и whitebox'ами.
YANG же не является официально аббревиатурой и Yet Another Next Generation - это просто по приколу назвали, разве нет?))
Ну как. В RFC этого нет. На вики и в других местах написано так. Если подумать, то YANG - это наследник SMIng - SMI NextGen. Поэтому я не удивлюсь, что разработчики, которые третий раз переизобретают язык просто с усталости назвали его "ещё один Next Gen" :)
По поводу бума новых моделей управления, как можно жить в этом хаосе? Надо ли сформировать аля-OSI модель и уровневое распределение для новых и приходящих протоколов и технологий, в честь которых пишутся эти статьи?
Я говорю в статье - сейчас Кембрийский взрыв. Победит самый приспособленный протокол. В самом конце, кстати, я попробовал показать в каком хаосе мы содержим свои сети - и ничего, живём :)
Не соглашусь.
Базовый MPLS ещё очень долго будет необходим.
Если не как транспорт, то как сервисный заголовок. А-ля MPLSoGRE.
На магистралях операторов он неискореним в ближайшее десятилетие.
У тех же операторов весь сервисный уровень это BGP MPLS L3VPN или L2VPN.
В ДЦ, в ритейле, даже в энтерпрайзе — да, там ему всё меньше места.
Мы используем Whitebox. Думаю, что на одном из следующих NextHop кто-нибудь об этом сделает доклад)
А можете рассказать, каким образом Whitebox-свитчи позволили сэкономить вагон? Они ведь не настолько драматически дешевле, а количество возникающих с ними проблем требует или поддержки или своего штата экспертов.
Ну и что было мотивацией использовать их вместо зрелых и оттестированных вендорских железок?
потерять целую стойку и даунтайм для кучи клиентов
Всё-таки парадигма публичного Облака предполагает, что клиент запускает N>1 экземпляров в разных AZ, ставит под балансер, и ещё накручивает автоскейлер. Выпадение одной стойки будет болезненным, но не фатальным. Внутренние сервисы такое переживают, не вздрагивая.
Ну а вопросы открытых ОС для whitebox'ов стоит обсуждать совсем отдельно)
И ещё где-то выше писал, что MC-LAG — это только одна из технических сложностей при реализации дуал-хоминга.
(иначе отказ линка приведет к каскадным отказам по производительности)
На самом деле нет — всё решает QoS. Испытываем деградацию менее важного трафика, но не теряем виртуалки пользователя. Можно ещё и инфраструктурные сервисы сразу выключить, чтобы они не давали нагрузку.
— Не понял про спайн вверх ногами.
— SDN в Облаке и в хвост и в гриву — для построения оверлейной сети. Там сильно кастомизированный Tungsten Fabric. Для андерлея фабрики — нет — он там и не нужен. Для магистрали есть мысли-идеи, а-ля Egress Peer Engineering.
— Вендор лок страшен тем, что кончатся чипы у вендора — и ты перед сложным решением, что нужно редизайнить сеть. Или тем, что ты не можешь манипулировать ценой, рассматривая альтернативных поставщиков. Ну и в конце концов — просто перестанет поддерживать фичу, как, например, MPLS на новых коробках)
Получается машинки подключены одним хвостом 10/25Gb, им хватает?
Уровень spine2 позволяет предоставить дешёвую полосу внутри AZ и не делать сеть узким местом. Расширить стык между двумя кусками такой сети гораздо сложнее, чем нарастить число спайнов второго уровня.
Грубо говоря, если у вас на границе двух таких сегментов будет стоять свитч/рутер на 32х100Gb/s порта вы сразу ограничены в 3,2Tb/s. Много это или мало?
А если сегментов 3? А 5? А 20? Я не теоретизирую — это реальная необходимость)
Кроме того это задача оптимизации — до какой степени гранулярным делать плейсмент потребителей в AZ?
Здесь не просто нужно размещать мощности клиентов (и свои инфраструктурные тоже) близко друг к другу, но и контролировать, что его новые экземпляры уместятся в этот сегмент. А если не уместятся — и у него network-intensive операции окажутся между сегментами?
А если клиента два, но они очень активно ходят друг к другу?
А если клиент оказался в одном сегменте, а сервис Облака (например, его S3-бакет) в другом?
В общем, Клоз, позволяет надстраивать уровни и не превращать плейсмент в гору «если», сеть в узкое место, а отладку дропов — в ад. При этом, насколько я знаю, у больших число уровней Клоза доходит до 4 или даже 5 (без пруфов))
Про MLAG ответил ниже.
Ссылок, боюсь нет. Именно про dual-homing серверов большие ребята особо не рассказывают. Знаю из личных разговоров и по косвенным признакам в публичных публикациях.
Хосты действительно способны такой канал забить?
Карточки такие уже есть на рынке некоторое время. Вопрос за приложениями.
Несколько клиентов, интенсивно (очень) пишущих на диски (распределённые по ДЦ), вполне могут нагенерить большой объём трафика.
Или GPU-кластера, считающие ML-задачки.
На нагрузочных тестах мы приближались к таким цифрам.
Да, именно не особо крупные облака обычно это делают. А тем более, если это коммерческие ДЦ.
Но у больших играет уже фактор масштаба: два свитча — это ведь не просто +1 свитч в стойку — это возрастающая вдвое СКС, требующая уже иных подходов, это увеличивающееся количество спайнов.
Ну и кроме того только MC-LAG позволит forwarding-агенту на хосте не знать о двуторье.
А MC-LAG — это проприетарная технология, привязывающая вас к вендору, чего вы точно не хотите, когда покупаете свитчи тысячами.
Если использовать BGP до хоста, то соответственно на нём нужна контролька, понимающая его и умеющая программировать forwarfing-агент.
Я не говорю, что это всё невозможно — мы сделали прототип. Но на данный момент архитектура и компенсационные меры эффективнее, чем удвоенная СКС.
Я тут разделил их на два шага, но фактически на данный момент это один — устройство перезагружается в новой версии ПО с целевым конфигом.
Вероятно, в следующих версиях автоматизации это поменяется. Отдельно в будущем напишу про это.
О, дааа, MTU, однозначно, достоин лавров самой неведомой чертовщины!
Под чудовищным legacy я тут подразумеваю такие штуки как Frame Relay, SDH, попытки синхронизации времени через IP-сеть или непосредственно Ethernet. NAT!
И это в некотором смысле добро, потому что всё, что поверх продолжает работать. Просто весь багаж техдолга вынесен на уровень фундамента :)
Я как раз приводил примеры проблем в сети, которые с виду простые, но локализовать их не так-то просто. Тут или нужны хорошие полные инструкции по диагностике, либо профессиональная интуиция.
И они требуют как раз знания инструментария.
Ну а без технических подробностей, потому что публикация рассчитана немного на другую аудиторию, и у меня есть места, где их как раз в достатке)
На самом деле мне близки вещи, которые вы описали. И согласен почти со всем.
Однако для того, чтобы что-то случилось, об этом нужно говорить. Говорить нужно много и при любой возможности, прожужжать всем уши и стучаться через все каналы.
И тогда, после того, как каждый будет знать, что есть NETCONF, появится и запрос.
Это мне так кажется. Возможно, ошибаюсь, потому что тот же gRPC элементарно решал насущные задачи разработчиков, поэтому стал стандартом де-факто для межсервисного взаимодействия.
Возможно, новые интерфейсы для сети не решают их. Или не делают этого пока - спрос ещё не созрел.
Но, я уверен, что как и со многими другими технологиями (тот же gRPC, или k8s, Go, React, OSquery, GraphQL) они сначала зарождаются в недрах компаний, для которых это вопрос выживания, а потом становятся распространены в индустрии, то же самое произойдёт (уже происходит) с NETCONF/YANG, gNMI и whitebox'ами.
Это всё ещё так :) И даже не 1%, а 30-50
С dip-переключателями сам успел ещё на какой-то авайке столкнуться. И да, SSH, конечно, намного удобней) Это бесспорно.
В подкасте как-то была у нас рубрика "История связи". К сожалению, мы не довели её до конца. Но было довольно любопытно.
Нет)
Ответил ниже случайно. А удалить коммент, похоже, нельзя.
Ну как. В RFC этого нет. На вики и в других местах написано так. Если подумать, то YANG - это наследник SMIng - SMI NextGen. Поэтому я не удивлюсь, что разработчики, которые третий раз переизобретают язык просто с усталости назвали его "ещё один Next Gen" :)
Я говорю в статье - сейчас Кембрийский взрыв. Победит самый приспособленный протокол. В самом конце, кстати, я попробовал показать в каком хаосе мы содержим свои сети - и ничего, живём :)
Базовый MPLS ещё очень долго будет необходим.
Если не как транспорт, то как сервисный заголовок. А-ля MPLSoGRE.
На магистралях операторов он неискореним в ближайшее десятилетие.
У тех же операторов весь сервисный уровень это BGP MPLS L3VPN или L2VPN.
В ДЦ, в ритейле, даже в энтерпрайзе — да, там ему всё меньше места.
А можете рассказать, каким образом Whitebox-свитчи позволили сэкономить вагон? Они ведь не настолько драматически дешевле, а количество возникающих с ними проблем требует или поддержки или своего штата экспертов.
Ну и что было мотивацией использовать их вместо зрелых и оттестированных вендорских железок?
Всё-таки парадигма публичного Облака предполагает, что клиент запускает N>1 экземпляров в разных AZ, ставит под балансер, и ещё накручивает автоскейлер. Выпадение одной стойки будет болезненным, но не фатальным. Внутренние сервисы такое переживают, не вздрагивая.
Ну а вопросы открытых ОС для whitebox'ов стоит обсуждать совсем отдельно)
И ещё где-то выше писал, что MC-LAG — это только одна из технических сложностей при реализации дуал-хоминга.
На самом деле нет — всё решает QoS. Испытываем деградацию менее важного трафика, но не теряем виртуалки пользователя. Можно ещё и инфраструктурные сервисы сразу выключить, чтобы они не давали нагрузку.
— SDN в Облаке и в хвост и в гриву — для построения оверлейной сети. Там сильно кастомизированный Tungsten Fabric. Для андерлея фабрики — нет — он там и не нужен. Для магистрали есть мысли-идеи, а-ля Egress Peer Engineering.
— Вендор лок страшен тем, что кончатся чипы у вендора — и ты перед сложным решением, что нужно редизайнить сеть. Или тем, что ты не можешь манипулировать ценой, рассматривая альтернативных поставщиков. Ну и в конце концов — просто перестанет поддерживать фичу, как, например, MPLS на новых коробках)
Сейчас — да.
Грубо говоря, если у вас на границе двух таких сегментов будет стоять свитч/рутер на 32х100Gb/s порта вы сразу ограничены в 3,2Tb/s. Много это или мало?
А если сегментов 3? А 5? А 20? Я не теоретизирую — это реальная необходимость)
Кроме того это задача оптимизации — до какой степени гранулярным делать плейсмент потребителей в AZ?
Здесь не просто нужно размещать мощности клиентов (и свои инфраструктурные тоже) близко друг к другу, но и контролировать, что его новые экземпляры уместятся в этот сегмент. А если не уместятся — и у него network-intensive операции окажутся между сегментами?
А если клиента два, но они очень активно ходят друг к другу?
А если клиент оказался в одном сегменте, а сервис Облака (например, его S3-бакет) в другом?
В общем, Клоз, позволяет надстраивать уровни и не превращать плейсмент в гору «если», сеть в узкое место, а отладку дропов — в ад. При этом, насколько я знаю, у больших число уровней Клоза доходит до 4 или даже 5 (без пруфов))
Ссылок, боюсь нет. Именно про dual-homing серверов большие ребята особо не рассказывают. Знаю из личных разговоров и по косвенным признакам в публичных публикациях.
Карточки такие уже есть на рынке некоторое время. Вопрос за приложениями.
Несколько клиентов, интенсивно (очень) пишущих на диски (распределённые по ДЦ), вполне могут нагенерить большой объём трафика.
Или GPU-кластера, считающие ML-задачки.
На нагрузочных тестах мы приближались к таким цифрам.
Но у больших играет уже фактор масштаба: два свитча — это ведь не просто +1 свитч в стойку — это возрастающая вдвое СКС, требующая уже иных подходов, это увеличивающееся количество спайнов.
Ну и кроме того только MC-LAG позволит forwarding-агенту на хосте не знать о двуторье.
А MC-LAG — это проприетарная технология, привязывающая вас к вендору, чего вы точно не хотите, когда покупаете свитчи тысячами.
Если использовать BGP до хоста, то соответственно на нём нужна контролька, понимающая его и умеющая программировать forwarfing-агент.
Я не говорю, что это всё невозможно — мы сделали прототип. Но на данный момент архитектура и компенсационные меры эффективнее, чем удвоенная СКС.
Вероятно, в следующих версиях автоматизации это поменяется. Отдельно в будущем напишу про это.