приведены несколько роутеров марки Cisco — для первых двух одновременно поддерживается восемь одинаковых маршрутов, а для последнего поддерживается до 32-х одинаковых маршрутов.
Сразу видно, что человек темой не занимался. Пусть на Sup2T попробует сделать больше 16 ECMP, а я буду ржать в сторонке.
Если через балансер / offload проходит только половина трафика (от клиента к серверу), то такое устройство не может знать о состоянии TCP-соединения. Вдруг сервер уже давно RST послал? А ACK вообще был? Соответственно, это остаётся простой, тупой L3 балансер. Чем он лучше роутера? Без стейтов — ничем.
Польза была бы, если такое устройство могло «подсасывать» состояния TCP-соединений из серверов, из ядра ОС. Но я про такие устройства не слышал.
Почитал, кстати, про Yahoo и l3dsr. Бедняжки. Им бы MPLS на серверах…
ИМХО, в наш век мифа о мобильном интернете, если приложение не обрабатывает разрыв какой-либо HTTP-сессии, я бы сказал, что автор приложения не прав.
А если приложение разумно такую ситуацию обрабатывает, то anycast в общем смысле не страшен. Кроме приложений, которые вот совсем никак не могут быть stateless (имею в виду — неотрывными от конкретного сервера, который обрабатывает запросы). Грубо говоря: статику с anycast качать — без проблем, а вот свою почту прочитать — наверное, на anycast никак не сделать. NTP сделать на anycast — да, а вот SIP — вряд ли.
Спасибо, уже копаем в этом направлении. :) Но чуть-чуть по-другому. По результатам беру на себя обязательство написать статью.
Насчет flow-spec — ждём обновления от циски. Обещали добавить в этом году.
1) Ну, соотношение не 1 к 1000, но да, исходящего сильно больше. Так вот если балансер в режиме полного проксирования, то он всю эту полосу должен через себя пропустить. Поэтому 20Гбит на балансер — не смешно.
Перенаправление — это редиректор. Это совсем другая история… С ним, конечно, по полосе уже не такие ограничения. Но по-прежнему остаётся проблема единой точки отказа.
Думаю, следующую статью напишу про внутренности кластера — там станет понятно, на чём мы остановились.
2) нет, ни в коем случае. В кэширующем кластере узлы неравноценны по контенту. Но количество узлов кластера увеличивает суммарную нагрузочную способность. Опять же, это внутренности кластера.
До crc16 не дошли — проверено, что достаточно по умолчанию. На нечетность первым делом проверяли. Но тут возможна магия версии XOS.
Да, поддержка рекомендовала такую штуку. Кстати, с каким-то обновлением появилось crc32 — даже в лабе не включали.
Статья была про LACP, а не «про все гадости, которые есть». ;) Поэтому про софт и т.п. не писал специально.
1) ну да, можно что-то наскриптовать. Но если можно этого не делать, то зачем?
2) больше двух шасси в MLAG не собрать. Как мне порты наращивать? Делать MLAG между стэками? Это мы на исходную возвращаемся: стэк решает поставленные задачи.
3) Дело не в ошибках настройки. Дело в том, как оно потом работает. Так вот не очень оно потом работает… Ну, и под MLAG я понимаю технологию в целом, без вендор-специфики.
4) VSS — то же стэкирование через ethernet. У кого-то оно лучше сделано. У кого-то хуже. Но я бы, конечно, два супа бы рекомендовал. Мне шибко понравилось. ;) Но и в конфигурации с двумя супами тоже приколов хватает по синхронизации. В целом-то там всё теже методы синхронизации используются. Только шина другая. Вообще, и то, и другое, для резервирование подходит. Нужно только проверять риски для каждой конкретной инсталляции.
Насчет MLAG для кольца вот почитай: community.gns3.com/people/matt.raio/blog/2015/04/18/you-can-do-mlag-and-lacp-with-extreme
EAPS/ERPS у нас исторически не запустился (надо было другое оборудование в кольце иметь), а сейчас думаем на полное L3 кольцо перейти — тогда потребность отпадёт как таковая.
Нет, MLAG не используем. Тому есть причины:
1) объём настройки резко возврастает (каждый LAG надо два раза настраивать)
2) больше двух шасси в MLAG не включишь (а мы тут добавляем в стэк третьего)
3) MLAG — как мультикаст: есть у многих. Правильно не работает ни у кого (ладно, MSK-IX смог запустить, но у них узкое применение).
4) я не вижу проблем с надёжностью стэка. Он примерно такой же надёжный, как два супервизора в «холодильнике». А может, и надёжнее (есть тут у нас одно шасси «холодильника» с дефектом бэкплейна в одном слоте. И вот уже 2 года мы ничего с этим поделать не можем).
Единственное, чем MLAG может быть лучше стэка — это отсутствием ограничения полосы в стэке.
Подумывали использовать MLAG в сторону кольца (как раз по заветам MSK-IX), но там другая проблема: это должно быть симметричное кольцо из 4 вершин (математики, отвяньте!). У нас такую топологию собрать не получается.
В целом — все производители одинаковые. ;) У меня есть много баек про всех.
Extreme — вменяем. Его можно осознать. Но да, в части LAG приходится придумывать костыли (мне тут в личной переписке ещё рассказали) из-за позиции производителя. На мой вкус — неправильной позиции.
Не, там нормально. Есть ещё понятие current master. Если config master поднят, то он же и current master. Если config master упал, то кто-то другой становится current master. Работает даже если выключить слот, на котором config master. Проверено неоднократно. :)
После восстановления current master возвращается (начиная с какой-то версии XOS) на config master.
Если б работало как-то иначе, это был бы не свитч, а кусок чего-то странного и неаппетитного.
Ну, вот был Force10 — тоже непривычный. Но там есть port-channel. И порты можно двигать.
Да, запомнить эту особенность можно. Но удобнее от этого не станет.
Насчёт обновления софта… есть у нас процедура. ;) И примерно такая же для обновления стэков цисок. Как-нить напишу. :)
Да, в целом — нормальные свитчи. В них есть логика. Но, как было сказано — дьявол в деталях. :) Есть и другие приколы. Может, позже расскажу. ;)
Если проект маленький, то такая штука может быть полезна. А если проект уже нормального размера, то количество узлов CDN легко обгоняет количество агентов. Опять же, агент должен быть как можно ближе к клиенту, и агентов должно быть больше. В идеале — каждый абонент должен быть агентом статистики. Ну, а дальше — работаем с собранными данными и решаем проблемы.
Иногда бывает нужно в порядке диагностики (поддержки) посмотреть, что там сервер отвечает. Для этого нужен VPN или проксик максимально близко к клиенту. Ну, логику вы уже поняли: либо прокси, либо удаленный доступ к компу клиента.
ИМХО, все эти сети диагностики CDN — фуфло и маркетинг.
Да, асимметричный. Сильно. Но только зачем увеличивать количество элементов в цепочке? Зачем вообще выделенный балансировщик на региональном узле?
Кроме того, если только в одну сторону — это уже сразу L3/L4 балансировка, никакого L7. Об это писал в статье.
Каждый следующий виток “закольцованного” broadcast flood сопровождается экспоненциальным ростом количества unknown unicast пакетов в сегменте сети.
Так broadcast или unknown unicast? Они немного по-разному себя ведут и по-разному сеть убивают. Во всяком случае, broadcast-шторм не порождает unknown unicast пакеты.
в сети одного из наших клиентов случился бродкастовый шторм, который мгновенно перекинулся к нам
Вы меня пугаете! У вас L2 не отделён от клиентского?
На тот момент Brocade нам не предлагали. Да, и есть ещё такой момент: наличие 2 * 10Г не означает пропускную способность 20 Гбит. Я видел балансер, который имел на борту 2 десятки, но пропускная способность была 4Гбит «в зависимости от задействованных функций». Так что на это обязательно надо смотреть.
Про Exchange сказать ничего не могу — не боролся с ним. Я так понимаю, это всё тот же вопрос server affinity.
Сразу видно, что человек темой не занимался. Пусть на Sup2T попробует сделать больше 16 ECMP, а я буду ржать в сторонке.
Польза была бы, если такое устройство могло «подсасывать» состояния TCP-соединений из серверов, из ядра ОС. Но я про такие устройства не слышал.
Почитал, кстати, про Yahoo и l3dsr. Бедняжки. Им бы MPLS на серверах…
А если приложение разумно такую ситуацию обрабатывает, то anycast в общем смысле не страшен. Кроме приложений, которые вот совсем никак не могут быть stateless (имею в виду — неотрывными от конкретного сервера, который обрабатывает запросы). Грубо говоря: статику с anycast качать — без проблем, а вот свою почту прочитать — наверное, на anycast никак не сделать. NTP сделать на anycast — да, а вот SIP — вряд ли.
Насчет flow-spec — ждём обновления от циски. Обещали добавить в этом году.
Перенаправление — это редиректор. Это совсем другая история… С ним, конечно, по полосе уже не такие ограничения. Но по-прежнему остаётся проблема единой точки отказа.
Думаю, следующую статью напишу про внутренности кластера — там станет понятно, на чём мы остановились.
2) нет, ни в коем случае. В кэширующем кластере узлы неравноценны по контенту. Но количество узлов кластера увеличивает суммарную нагрузочную способность. Опять же, это внутренности кластера.
Да, поддержка рекомендовала такую штуку. Кстати, с каким-то обновлением появилось crc32 — даже в лабе не включали.
Статья была про LACP, а не «про все гадости, которые есть». ;) Поэтому про софт и т.п. не писал специально.
2) больше двух шасси в MLAG не собрать. Как мне порты наращивать? Делать MLAG между стэками? Это мы на исходную возвращаемся: стэк решает поставленные задачи.
3) Дело не в ошибках настройки. Дело в том, как оно потом работает. Так вот не очень оно потом работает… Ну, и под MLAG я понимаю технологию в целом, без вендор-специфики.
4) VSS — то же стэкирование через ethernet. У кого-то оно лучше сделано. У кого-то хуже. Но я бы, конечно, два супа бы рекомендовал. Мне шибко понравилось. ;) Но и в конфигурации с двумя супами тоже приколов хватает по синхронизации. В целом-то там всё теже методы синхронизации используются. Только шина другая. Вообще, и то, и другое, для резервирование подходит. Нужно только проверять риски для каждой конкретной инсталляции.
Насчет MLAG для кольца вот почитай: community.gns3.com/people/matt.raio/blog/2015/04/18/you-can-do-mlag-and-lacp-with-extreme
EAPS/ERPS у нас исторически не запустился (надо было другое оборудование в кольце иметь), а сейчас думаем на полное L3 кольцо перейти — тогда потребность отпадёт как таковая.
1) объём настройки резко возврастает (каждый LAG надо два раза настраивать)
2) больше двух шасси в MLAG не включишь (а мы тут добавляем в стэк третьего)
3) MLAG — как мультикаст: есть у многих. Правильно не работает ни у кого (ладно, MSK-IX смог запустить, но у них узкое применение).
4) я не вижу проблем с надёжностью стэка. Он примерно такой же надёжный, как два супервизора в «холодильнике». А может, и надёжнее (есть тут у нас одно шасси «холодильника» с дефектом бэкплейна в одном слоте. И вот уже 2 года мы ничего с этим поделать не можем).
Единственное, чем MLAG может быть лучше стэка — это отсутствием ограничения полосы в стэке.
Подумывали использовать MLAG в сторону кольца (как раз по заветам MSK-IX), но там другая проблема: это должно быть симметричное кольцо из 4 вершин (математики, отвяньте!). У нас такую топологию собрать не получается.
Extreme — вменяем. Его можно осознать. Но да, в части LAG приходится придумывать костыли (мне тут в личной переписке ещё рассказали) из-за позиции производителя. На мой вкус — неправильной позиции.
После восстановления current master возвращается (начиная с какой-то версии XOS) на config master.
Если б работало как-то иначе, это был бы не свитч, а кусок чего-то странного и неаппетитного.
Да, запомнить эту особенность можно. Но удобнее от этого не станет.
Насчёт обновления софта… есть у нас процедура. ;) И примерно такая же для обновления стэков цисок. Как-нить напишу. :)
Да, в целом — нормальные свитчи. В них есть логика. Но, как было сказано — дьявол в деталях. :) Есть и другие приколы. Может, позже расскажу. ;)
Иногда бывает нужно в порядке диагностики (поддержки) посмотреть, что там сервер отвечает. Для этого нужен VPN или проксик максимально близко к клиенту. Ну, логику вы уже поняли: либо прокси, либо удаленный доступ к компу клиента.
ИМХО, все эти сети диагностики CDN — фуфло и маркетинг.
Кроме того, если только в одну сторону — это уже сразу L3/L4 балансировка, никакого L7. Об это писал в статье.
На серверных портах надо держать включенным bpdu-guard. «Правила техники безопасности написаны кровью».
Так broadcast или unknown unicast? Они немного по-разному себя ведут и по-разному сеть убивают. Во всяком случае, broadcast-шторм не порождает unknown unicast пакеты.
Вы меня пугаете! У вас L2 не отделён от клиентского?
Про Exchange сказать ничего не могу — не боролся с ним. Я так понимаю, это всё тот же вопрос server affinity.