Комментарии 25
>Современный датацентр заметно отличается от традиционной корпоративной сети. Приложения больше ориентируются на L3 коммутацию вместо предположения, что все соединения находятся в одной подсети, больше траффика идет «горизонтально» нежели «вертикально» и т.д. Несомненно, главное отличие — гигантский масштаб.
Я бы не стал обобщать. «Датацентр» — очень растяжимое понятие.
>Традиционная архитектура сети включает уровни ядра, агрегации и доступа.
Может, не надо насиловать труп? Никто уже много лет не строит сети ЦОДов по трехуровневой модели, и никто давно уже не предлагает строить сети таким образом. Эта концепция умерла еще до моды на collapsed core.
Ориентация на L3 — это хорошо, но мало кому доступно (не забывайте, что требования диктуются приложениями, и не все они поддаются модификации — где-то для простейшего резервирования active/standby без потребности в масштабировании проще всего задействовать VRRP, где-то нужен конкретно L2 мультикаст). Потому есть компромиссный вариант — те самые костыли, которые позволяют организовать CLOS фабрику с транспортом L2. У нее все те же преимущества, что и у вашей «современной сети», за исключением п.5 («Ориентация на L3») и п.2 («Меньше проприетарных протоколов», ибо TRILL существует только в powerpoint).
В недостатках вашего решения упоминается «сложными QoS правилами». Что имеется в виду? DCB к примеру есть? Какой вообще функционал поддерживается или не поддерживается?
Что не так с netflow? Ему на L3 самое место.
Я бы не стал обобщать. «Датацентр» — очень растяжимое понятие.
>Традиционная архитектура сети включает уровни ядра, агрегации и доступа.
Может, не надо насиловать труп? Никто уже много лет не строит сети ЦОДов по трехуровневой модели, и никто давно уже не предлагает строить сети таким образом. Эта концепция умерла еще до моды на collapsed core.
Ориентация на L3 — это хорошо, но мало кому доступно (не забывайте, что требования диктуются приложениями, и не все они поддаются модификации — где-то для простейшего резервирования active/standby без потребности в масштабировании проще всего задействовать VRRP, где-то нужен конкретно L2 мультикаст). Потому есть компромиссный вариант — те самые костыли, которые позволяют организовать CLOS фабрику с транспортом L2. У нее все те же преимущества, что и у вашей «современной сети», за исключением п.5 («Ориентация на L3») и п.2 («Меньше проприетарных протоколов», ибо TRILL существует только в powerpoint).
В недостатках вашего решения упоминается «сложными QoS правилами». Что имеется в виду? DCB к примеру есть? Какой вообще функционал поддерживается или не поддерживается?
Что не так с netflow? Ему на L3 самое место.
Про QoS хороший вопрос.
Когда то заинтересовался этим решением, стал копать, что же у них интегрировано в Линукс. Предполагая их подход, что вы можете пользоваться стандартными утилитами Линукс (а мы уже далее позаботимся о том, чтобы переложить это на язык железа), выяснилось, что с QoS пока (дело было 3-4 месяца назад) плохо. Доступ к документации я не получил, но ответ был такой — QoS есть в железе, можете пользоваться специальным CLI, интеграции с Линукс нет. И мне показалось, что подтекст был такой, что в ДЦ QoS не шибко актуальная тема, проще BW увеличить, чем с QoS морочится.
Когда то заинтересовался этим решением, стал копать, что же у них интегрировано в Линукс. Предполагая их подход, что вы можете пользоваться стандартными утилитами Линукс (а мы уже далее позаботимся о том, чтобы переложить это на язык железа), выяснилось, что с QoS пока (дело было 3-4 месяца назад) плохо. Доступ к документации я не получил, но ответ был такой — QoS есть в железе, можете пользоваться специальным CLI, интеграции с Линукс нет. И мне показалось, что подтекст был такой, что в ДЦ QoS не шибко актуальная тема, проще BW увеличить, чем с QoS морочится.
Это в целом так, гораздо проще контролировать QoS в его обычном понимании на эндпойнтах. Тут приведен живой пример, когда TE, то есть форвардинг/маршрутизация, и QoS неразрывно переплетены, при этом классический контроль на эндпойнтах никуда не пропадает.
>гораздо проще контролировать QoS в его обычном понимании на эндпойнтах
Нет, контролировать его на ендпоинтах в общем случае просто невозможно. QoS — это традиционно превращение хаотичной потери пакетов на линках в избирательную. Ендпоинт не может дропать чужие пакеты. И свитч должен принимать решения самостоятельно — он не успеет никого спросить, что делать с пакетами.
>И мне показалось, что подтекст был такой, что в ДЦ QoS не шибко актуальная тема, проще BW увеличить
Очень даже актуальная. Самый жесткий пример — если вы строите FCoE, то вам нужно обеспечить 0 потерь. Как механизмами безусловной приоритезации, так и сигнализацией отправителю о перегрузках.
Нет, контролировать его на ендпоинтах в общем случае просто невозможно. QoS — это традиционно превращение хаотичной потери пакетов на линках в избирательную. Ендпоинт не может дропать чужие пакеты. И свитч должен принимать решения самостоятельно — он не успеет никого спросить, что делать с пакетами.
>И мне показалось, что подтекст был такой, что в ДЦ QoS не шибко актуальная тема, проще BW увеличить
Очень даже актуальная. Самый жесткий пример — если вы строите FCoE, то вам нужно обеспечить 0 потерь. Как механизмами безусловной приоритезации, так и сигнализацией отправителю о перегрузках.
В теории много чего актуально.
На практике, проще и эффективнее, и дешевле (если посчитать OPEX и CAPEX) пропускную способность увеличить.
На практике, проще и эффективнее, и дешевле (если посчитать OPEX и CAPEX) пропускную способность увеличить.
А где конкретно экономия? Я вижу только один фактор — можно набрать более глупых людей, не умеющих делать QoS на свитчах. В остальном экономии как бы и нет. Сопровождать это, если не переборщить с числом классов, особо не требуется. Настроил и забыл. В капексе тем более как-то разницы нет, уж базовый функционал есть на всем железе.
BW обычно следует увеличивать не горизонтально, а вертикально, иначе все равно кто-то будет упираться в емкость отдельных каналов. Т.е. 1G => 10G => 40G. Каждый переход обычно стоит приличных денег.
А дальше у вас есть канал до другого датацентра. Как правило — либо темное волокно, либо, что хуже, провайдерский канал. И тут уж по-любому надо озаботиться приоритезацией, потому что эта емкость стоит чертовски дорого.
Ну и удачи пускать FCoE без QoS. Один единственный потерянный пакет — и обмен с массивами в лучшем случае надолго замирает. Не уверен, что оно вообще захочет работать без DCBX.
А еще представьте себе, что сотни мегабит голосового трафика будут гоняться по тем же линкам, по которым бегают сотни TCP соединений. В среднем за полминуты утилизация линка может быть несерьезные 20% к примеру. Но если собрать и проанализировать дамп пакетов, или просто проверить счетчики дропов на интерфейсах… Теряться-то может как трафик между абонентами, так и SPAN трафик. Потеря второго как правило хуже, так как если слова выпали из разговора, то никто никого не переспросит, и у вас будет несколько косячная запись.
В общем, да, широкие каналы — это круто, но и на них надо бы приоритезацию организовывать. Это вовсе не дорого и не сложно.
BW обычно следует увеличивать не горизонтально, а вертикально, иначе все равно кто-то будет упираться в емкость отдельных каналов. Т.е. 1G => 10G => 40G. Каждый переход обычно стоит приличных денег.
А дальше у вас есть канал до другого датацентра. Как правило — либо темное волокно, либо, что хуже, провайдерский канал. И тут уж по-любому надо озаботиться приоритезацией, потому что эта емкость стоит чертовски дорого.
Ну и удачи пускать FCoE без QoS. Один единственный потерянный пакет — и обмен с массивами в лучшем случае надолго замирает. Не уверен, что оно вообще захочет работать без DCBX.
А еще представьте себе, что сотни мегабит голосового трафика будут гоняться по тем же линкам, по которым бегают сотни TCP соединений. В среднем за полминуты утилизация линка может быть несерьезные 20% к примеру. Но если собрать и проанализировать дамп пакетов, или просто проверить счетчики дропов на интерфейсах… Теряться-то может как трафик между абонентами, так и SPAN трафик. Потеря второго как правило хуже, так как если слова выпали из разговора, то никто никого не переспросит, и у вас будет несколько косячная запись.
В общем, да, широкие каналы — это круто, но и на них надо бы приоритезацию организовывать. Это вовсе не дорого и не сложно.
Про настроил и забыл это только мечтать. Равно как и о том, чтобы один раз задокументировать классы и т.п., и далее строго их использовать. Люди это основная статья расходов. Нанимать команду высококлассных специалистов никто не будет, всегда будут инженеры средней руки, которые берут на себя большую часть рутины.
И как быть в гетерогенных сетях? Вроде бы у всех вендоров QoS одинаковый, но чуть глубже и начинается интересно. А как быть с простым железом на доступе? Там КоС сделан как китайский Бог на душу положит.
Запускал пару проектов с узлами во всех федеральных округах. Каналы надо было по 3-5 Мбит/с. Разбирательства с качеством там такая песня была. И это не какой-то один провайдер — за несколько месяцев пилотных тестов перепробовали всех, что смогли, ± у всех одинаково. В проекте ставили оборудование спец., которое требовало каналы с % потерь не более 0.5. Итог: арендовали полосу в 2.5 раза больше, на оборудовании включили режим дублирования (каждый пакет передается в 2-х экземплярах).
А голос, ну вот Skype, Viber, Google Talks, Facetime как то нормально уживаются. Все пользуются и нормально, бывает проблемки, но и в традиционной TDM телефонии такое бывало.
И как быть в гетерогенных сетях? Вроде бы у всех вендоров QoS одинаковый, но чуть глубже и начинается интересно. А как быть с простым железом на доступе? Там КоС сделан как китайский Бог на душу положит.
Запускал пару проектов с узлами во всех федеральных округах. Каналы надо было по 3-5 Мбит/с. Разбирательства с качеством там такая песня была. И это не какой-то один провайдер — за несколько месяцев пилотных тестов перепробовали всех, что смогли, ± у всех одинаково. В проекте ставили оборудование спец., которое требовало каналы с % потерь не более 0.5. Итог: арендовали полосу в 2.5 раза больше, на оборудовании включили режим дублирования (каждый пакет передается в 2-х экземплярах).
А голос, ну вот Skype, Viber, Google Talks, Facetime как то нормально уживаются. Все пользуются и нормально, бывает проблемки, но и в традиционной TDM телефонии такое бывало.
>Нанимать команду высококлассных специалистов никто не будет
Никто? Никто-никто? Точно?
Впрочем, достаточно одного грамотного архитектора и толпы макак, работающих строго по инструкции. Для сопровождения QoS само собой.
>Вроде бы у всех вендоров QoS одинаковый
Откуда такая глупость? QoS может быть совершенно разным даже в разных моделях одной линейки железа одного вендора. Ну что же, я полагаю, «средней руки инженер» должен уметь читать. Или не должен?
>Разбирательства с качеством там такая песня была
У меня много сотен несколькомегабитных каналов связи с участием многих десятков провайдеров. Ну что же — где надо, чтобы качественно, там L3VPN (в случае потерь заебем провайдера насмерть, и он устранит потери, проверено). Где только интернет — полоса постоянно мониторится, при проблемах трафик автоматически за секунды переключается на резерв (нет, мониторинг куда серьезнее, чем средствами кипалайвов IGP — на важных каналах любого рода он тоже работает). Вот жду выхода через несколько месяцев NG-PFR, он многое упростит, там обещают фейловер при brownout за 2 секунды, а мониторинг организован в первую очередь наблюдением за data plane TCP трафиком, а кипалайвы пускают только когда трафика нет. Текущая версия PfR на мой взгляд непригодна к использованию в продакшне.
Для справки, катастрофическим уровнем потерь я считаю где-то 0,2%. То, что выше, очень сильно бьет по TCP.
>А голос, ну вот Skype, Viber, Google Talks, Facetime как то нормально уживаются.
Корпоративный голос — это обычно RTP пакеты, а сигнализация — SIP/H.323/SCCP. Скайпы-фейстаймы — фигня. Не фигня — обеспечить качественную передачу тысяч одновременных голосовых соединений как между оператором и клиентом, так и до систем звукозаписи, данные с которых потом и в суде могут слушаться.
Но опять же, вопрос в масштабах и требованиях к качеству сервиса.
Никто? Никто-никто? Точно?
Впрочем, достаточно одного грамотного архитектора и толпы макак, работающих строго по инструкции. Для сопровождения QoS само собой.
>Вроде бы у всех вендоров QoS одинаковый
Откуда такая глупость? QoS может быть совершенно разным даже в разных моделях одной линейки железа одного вендора. Ну что же, я полагаю, «средней руки инженер» должен уметь читать. Или не должен?
>Разбирательства с качеством там такая песня была
У меня много сотен несколькомегабитных каналов связи с участием многих десятков провайдеров. Ну что же — где надо, чтобы качественно, там L3VPN (в случае потерь заебем провайдера насмерть, и он устранит потери, проверено). Где только интернет — полоса постоянно мониторится, при проблемах трафик автоматически за секунды переключается на резерв (нет, мониторинг куда серьезнее, чем средствами кипалайвов IGP — на важных каналах любого рода он тоже работает). Вот жду выхода через несколько месяцев NG-PFR, он многое упростит, там обещают фейловер при brownout за 2 секунды, а мониторинг организован в первую очередь наблюдением за data plane TCP трафиком, а кипалайвы пускают только когда трафика нет. Текущая версия PfR на мой взгляд непригодна к использованию в продакшне.
Для справки, катастрофическим уровнем потерь я считаю где-то 0,2%. То, что выше, очень сильно бьет по TCP.
>А голос, ну вот Skype, Viber, Google Talks, Facetime как то нормально уживаются.
Корпоративный голос — это обычно RTP пакеты, а сигнализация — SIP/H.323/SCCP. Скайпы-фейстаймы — фигня. Не фигня — обеспечить качественную передачу тысяч одновременных голосовых соединений как между оператором и клиентом, так и до систем звукозаписи, данные с которых потом и в суде могут слушаться.
Но опять же, вопрос в масштабах и требованиях к качеству сервиса.
> Никто? Никто-никто? Точно?
Кто-то конечно так делает, но в среднем такого нет.
> достаточно одного грамотного архитектора и толпы макак
и 95% времени грамотный архитектор смотрит, чтобы макаки делали по инструкции, а не так как им кажется или разбирается в косяках или думает, как сделать так, чтобы макаки накосячить не смогли в принципе.
> в случае потерь заебем провайдера насмерть, и он устранит потери, проверено
Если не возражаете, то я спрошу у вас совета, как этого добиться. Это не сарказм =)
Кстати, 0,2% за какой период? Как часто бывает больше 0.2%? Что делаете, если нарушают? Насколько для вас это критично?
За большой голос ничего не скажу, опыта такого не имею.
Но инсталляций до 100 устройств видел полностью работающих через инет не мало, и сделаны на всем подряд SIP/H.323/SCCP + Скайп. И нормально, а по деньгам красотища.
Кто-то конечно так делает, но в среднем такого нет.
> достаточно одного грамотного архитектора и толпы макак
и 95% времени грамотный архитектор смотрит, чтобы макаки делали по инструкции, а не так как им кажется или разбирается в косяках или думает, как сделать так, чтобы макаки накосячить не смогли в принципе.
> в случае потерь заебем провайдера насмерть, и он устранит потери, проверено
Если не возражаете, то я спрошу у вас совета, как этого добиться. Это не сарказм =)
Кстати, 0,2% за какой период? Как часто бывает больше 0.2%? Что делаете, если нарушают? Насколько для вас это критично?
За большой голос ничего не скажу, опыта такого не имею.
Но инсталляций до 100 устройств видел полностью работающих через инет не мало, и сделаны на всем подряд SIP/H.323/SCCP + Скайп. И нормально, а по деньгам красотища.
>и 95% времени грамотный архитектор смотрит, чтобы макаки делали по инструкции
Архитектор не смотрит, как они работают. Если они не способны изучить готовые сжатые инструкции по конфигурации QoS конкретно в их инфраструктуре, то это — профнепригодность. И кстати пары инженеров может быть достаточно для поддержки сети на много сотен устройств… Можно «один умный, другой глупый» (но тогда страшно в отпуск человека отпускать), можно «все умные» (оптимально).
>Если не возражаете, то я спрошу у вас совета, как этого добиться.
Цепочка эскалации от сервис-менеджера до директора департамента и выше.
>Кстати, 0,2% за какой период?
Зависит от лени и важности канала. Обычно минуты или часы.
>Что делаете, если нарушают?
Заявка, пинок менеджеру, дальше по обстоятельствам.
>Насколько для вас это критично?
Зависит от канала. Где-то проблемой считается 0.2% потерь в течение нескольких секунд — на такое заводятся заявки. Если речь идет о минутах, то тут уже звонок менеджеру.
>И нормально, а по деньгам красотища.
А как вы мониторите качество сервиса? Мы например в реальном времени отслеживаем RTCP с аппаратов (рядом с моим рабочим местом на мониторах даже красивые графики непрерывно рисуются, обычно полностью зеленые, но при дропах сразу начинающие краснеть), IP SLA и ряд других метрик. А вам известно, насколько качественно работает у вас телефония? Или вы по отзывам пользователей оцениваете сервис? :)
Архитектор не смотрит, как они работают. Если они не способны изучить готовые сжатые инструкции по конфигурации QoS конкретно в их инфраструктуре, то это — профнепригодность. И кстати пары инженеров может быть достаточно для поддержки сети на много сотен устройств… Можно «один умный, другой глупый» (но тогда страшно в отпуск человека отпускать), можно «все умные» (оптимально).
>Если не возражаете, то я спрошу у вас совета, как этого добиться.
Цепочка эскалации от сервис-менеджера до директора департамента и выше.
>Кстати, 0,2% за какой период?
Зависит от лени и важности канала. Обычно минуты или часы.
>Что делаете, если нарушают?
Заявка, пинок менеджеру, дальше по обстоятельствам.
>Насколько для вас это критично?
Зависит от канала. Где-то проблемой считается 0.2% потерь в течение нескольких секунд — на такое заводятся заявки. Если речь идет о минутах, то тут уже звонок менеджеру.
>И нормально, а по деньгам красотища.
А как вы мониторите качество сервиса? Мы например в реальном времени отслеживаем RTCP с аппаратов (рядом с моим рабочим местом на мониторах даже красивые графики непрерывно рисуются, обычно полностью зеленые, но при дропах сразу начинающие краснеть), IP SLA и ряд других метрик. А вам известно, насколько качественно работает у вас телефония? Или вы по отзывам пользователей оцениваете сервис? :)
>Я бы не стал обобщать. «Датацентр» — очень растяжимое понятие.
Да, можно уточнить, что это под крупные инсталляции одного эксплуатанта. В мире это обобщается в datacenter customer, без деления на подвиды. Крупнейшая инсталляция на текущий момент — свыше 10К коммутаторов у одной компании.
>никто давно уже не предлагает строить сети таким образом.
Cisco Virtualized Multi-Tenant Data Center Design Guide Version 2.2, last Updated: March 6, 2013. Труп подозрительно жив и бодр.
Ориентация на L3 как раз и предназначена для построения свежих решений, наследственные приложения так и обозначены — слабые места.
Варианты со стекированием, MLAG и прочее как раз добавляют проблем, от которых и предлагается избавиться. Не хотите избавляться — вас же не заставляют :)
Что работает — есть в даташите.
Да, можно уточнить, что это под крупные инсталляции одного эксплуатанта. В мире это обобщается в datacenter customer, без деления на подвиды. Крупнейшая инсталляция на текущий момент — свыше 10К коммутаторов у одной компании.
>никто давно уже не предлагает строить сети таким образом.
Cisco Virtualized Multi-Tenant Data Center Design Guide Version 2.2, last Updated: March 6, 2013. Труп подозрительно жив и бодр.
Ориентация на L3 как раз и предназначена для построения свежих решений, наследственные приложения так и обозначены — слабые места.
Варианты со стекированием, MLAG и прочее как раз добавляют проблем, от которых и предлагается избавиться. Не хотите избавляться — вас же не заставляют :)
Что работает — есть в даташите.
>это под крупные инсталляции одного эксплуатанта
Да и тут тоже не факт, что сказанное вами про, например, преимущественно горизонтальный трафик верно.
>Cisco Virtualized Multi-Tenant Data Center Design Guide Version 2.2, last Updated: March 6, 2013.
Выпущено много лет назад. «Updated» может подразумевать «исправлена очепятка».
Почитайте Virtualized Multiservice Data Center (VMDC) 3.0, существовавший как минимум в декабре 2012.
Кстати, «multi-tenant» подразумевает подавляющее превосходство вертикального трафика.
>Не хотите избавляться — вас же не заставляют
Хотим, но не можем. И мало кто может.
Да и тут тоже не факт, что сказанное вами про, например, преимущественно горизонтальный трафик верно.
>Cisco Virtualized Multi-Tenant Data Center Design Guide Version 2.2, last Updated: March 6, 2013.
Выпущено много лет назад. «Updated» может подразумевать «исправлена очепятка».
Почитайте Virtualized Multiservice Data Center (VMDC) 3.0, существовавший как минимум в декабре 2012.
Кстати, «multi-tenant» подразумевает подавляющее превосходство вертикального трафика.
>Не хотите избавляться — вас же не заставляют
Хотим, но не можем. И мало кто может.
>VMDC 3.0
Тоже отлично предлагает три уровня. Скромно упоминает о двухуровневой топологии.
>Хотим, но не можем. И мало кто может.
В какой-то момент проще сменить платформу.
Тоже отлично предлагает три уровня. Скромно упоминает о двухуровневой топологии.
>Хотим, но не можем. И мало кто может.
В какой-то момент проще сменить платформу.
>Тоже отлично предлагает три уровня.
www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Data_Center/VMDC/3-0/DG/VMDC_3-0_DG.pdf
Не сказал бы.
CLOS, кстати, ничем особо не отличается от collapsed core помимо наличия N ядер, где N может быть >2.
>В какой-то момент проще сменить платформу.
Платформу? Но корпоративный ЦОД может иметь много сотен разнообразных платформ и приложений. Вы не зацикливайтесь на единичных интернет-компаниях, их мало, и у них, кстати, тоже есть внутренняя инфраструктура с не самыми гибкими сервисами, будь то SAP, ораклиные базы, FC или FCoE хранилища и так далее.
www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Data_Center/VMDC/3-0/DG/VMDC_3-0_DG.pdf
Не сказал бы.
CLOS, кстати, ничем особо не отличается от collapsed core помимо наличия N ядер, где N может быть >2.
>В какой-то момент проще сменить платформу.
Платформу? Но корпоративный ЦОД может иметь много сотен разнообразных платформ и приложений. Вы не зацикливайтесь на единичных интернет-компаниях, их мало, и у них, кстати, тоже есть внутренняя инфраструктура с не самыми гибкими сервисами, будь то SAP, ораклиные базы, FC или FCoE хранилища и так далее.
Базовая архитектура в документе — три уровня.
Если вы не можете сменить платформу — значит это решение не подходит.
Если вы не можете сменить платформу — значит это решение не подходит.
Чем картинки 2-3 и 2-4 отличаются от идеализируемых вами?
Или вы про сервисный уровень? А в предложенной вами архитектуре балансировщики, файрволы и т.д. будут работать на уровне leaf, или, и того хуже, spine?
И почему на вашей картинке тоже три уровня — core, leaf и spine? Непорядок…
Или вы про сервисный уровень? А в предложенной вами архитектуре балансировщики, файрволы и т.д. будут работать на уровне leaf, или, и того хуже, spine?
И почему на вашей картинке тоже три уровня — core, leaf и spine? Непорядок…
2-3 не отличается, 2-4 добавляет еще один уровень Aggregation-Edge.
Балансировщики и прочее работают на нодах, нет необходимости ставить «аппаратный».
Разница на нашем варианте и Циски (за исключением 2-3) простая — у них весь spine уровень подключен к следующему.
В 2-3 и нашей картинке выход в сеть подключен отдельно.
Балансировщики и прочее работают на нодах, нет необходимости ставить «аппаратный».
Разница на нашем варианте и Циски (за исключением 2-3) простая — у них весь spine уровень подключен к следующему.
В 2-3 и нашей картинке выход в сеть подключен отдельно.
>В 2-3 и нашей картинке выход в сеть подключен отдельно.
Мне лень рисовать, так что попробуем словами.
Возьмите картинку. Переместите две левые leaf ноды наверх (не меняя соединений между узлами). Опаньки, у вас на картинке четко прорисовался тот же самый aggregation-edge! И даже есть еще один, четвертый уровень! А как же предсказуемые задержки? Почему так много уровней? Непорядок…
Мне лень рисовать, так что попробуем словами.
Возьмите картинку. Переместите две левые leaf ноды наверх (не меняя соединений между узлами). Опаньки, у вас на картинке четко прорисовался тот же самый aggregation-edge! И даже есть еще один, четвертый уровень! А как же предсказуемые задержки? Почему так много уровней? Непорядок…
А у вас случаем нет возможности получить в лабу Pluribus? Среди всех модных стартапов сетевых — это мой фаворит.
Интересно, посмотреть реальные возможности.
Интересно, посмотреть реальные возможности.
НЛО прилетело и опубликовало эту надпись здесь
Хм… А чем современная модель проще? Гибче, я еще могу понять…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Cumulus Linux для сети в датацентре