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-агент.
Я не говорю, что это всё невозможно — мы сделали прототип. Но на данный момент архитектура и компенсационные меры эффективнее, чем удвоенная СКС.
Я тут разделил их на два шага, но фактически на данный момент это один — устройство перезагружается в новой версии ПО с целевым конфигом.
Вероятно, в следующих версиях автоматизации это поменяется. Отдельно в будущем напишу про это.
А вот это любопытно. Никогда не проверял, убеждённый, что Майнхоф — это мужчина :) Исправил. Но, учитывая, что я тут обыгрываю двойное авторство в виде двойной фамилии, думаю, это допустимо)
Нет)
Ответил ниже случайно. А удалить коммент, похоже, нельзя.
Ну как. В 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-агент.
Я не говорю, что это всё невозможно — мы сделали прототип. Но на данный момент архитектура и компенсационные меры эффективнее, чем удвоенная СКС.
Вероятно, в следующих версиях автоматизации это поменяется. Отдельно в будущем напишу про это.
Исправил.Но, учитывая, что я тут обыгрываю двойное авторство в виде двойной фамилии, думаю, это допустимо)