Ну, согласитесь, это несколько натянутые примеры? Я говорю про смерть или вред здоровью как прямое следствие ошибок или проблем. Нельзя сравнить это с обрушением моста или врачебной ошибкой.
Пограничными на сегодняшний день являются медицина и автомобили, напичканные электроникой.
Под чудовищным 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. Испытываем деградацию менее важного трафика, но не теряем виртуалки пользователя. Можно ещё и инфраструктурные сервисы сразу выключить, чтобы они не давали нагрузку.
Я не понял, это хорошая ирония или вы всерьёз? :)
Где реализована коммутация/маршрутизация/ACL - в железе или на CPU
Вероятность битовых ошибок и их исправление
Отказоустойчивость компонентов
Качество питания и устойчивость к скачкам в сети
Глубина и качество тестирования ПО, отвечающего за Control Plane
То же, но про взаимодействие с SDK чипа, реализующего программирование правил в железо.
Возможность обновления ПО (неактуально, правда, для старых коробок)
А кольца имело смысл собирать на L3 :)
Один из примеров в публикации - это ядро, собранное на кольцах под управлением RRPP - там одно неловкое движение и критический инцидент.
Подпишусь под каждым словом!
Да, бывало такое. И даже в масштабах ядра оператора сети, где не особо ожидаешь дублирования MAC'ов в отличие от сегмента клиентского оборудования.
И порой изменение MAC'а при вводе в эксплуатацию даже в инструкции по настройке прописывали)
Ну, согласитесь, это несколько натянутые примеры? Я говорю про смерть или вред здоровью как прямое следствие ошибок или проблем. Нельзя сравнить это с обрушением моста или врачебной ошибкой.
Пограничными на сегодняшний день являются медицина и автомобили, напичканные электроникой.
О, дааа, 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. Испытываем деградацию менее важного трафика, но не теряем виртуалки пользователя. Можно ещё и инфраструктурные сервисы сразу выключить, чтобы они не давали нагрузку.