До 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.
В разных регионах по-разному. Где-то побольше, где-то поменьше. В целом, у нас такая информация считается закрытой, поэтому скажу так: у нас в регионах к узлам подключены десятки гигабит (на один узел, чтобы не было разночтений).
К ACE за все время использования ни единой претензии не было.
У меня к нему сейчас только одна претензия — новым клиентам больше не продаётся. В общем, убила его циска. Может, там и была нехватка производительности, ещё какие-то проблемы — этого я уже никогда не узнаю.
Я правильно понимаю, что сервер балансировщик L7 не состоянии перемолоть больше чем 10gbps?
1) на момент принятия решения я не имел данных об аппаратных балансировщиках, тянущих больше 10Гбит/с. Может, сейчас уже есть. Но ценник всё равно будет космический.
2) предположим, что сервер с Haproxy/nginx может тянуть 20Гбит. Ладно! Гуляем на все 40, как Нетфликс!!! Их всё равно надо купить много штук, поставить в стойку, как-то зарезервировать, обеспечить сетью (портами, полосой) на все эти гигабиты. И сделать это на каждом нашем узле — не только в Москве. Много. Дорого. Хреново в обслуживании (просто за счёт количества).
Да, если есть конкретные требования к server affinity, как у JDima, то да, там вариантов нет. Но если задача на прикладном уровне позволяет обойтись без привязки клиента к серверу (а я бы для всех веб-проектов рекомендовал делать без привязки), то нет смысла в «тяжелом» L7-балансировщике.
Да, мои соболезнования!
Но некоторые элементы этого метода можно перенять и вам. Я так понимаю, у вас всё равно стоит какое-то количество L7-балансировщиков, которые обеспечивают sticky cookie. А вот между ними можно балансировать / резервировать по такой методике, как у нас. Тогда, если между балансерами есть репликация состояний, то всё отработает, как надо.
Да, поддержка рекомендовала такую штуку. Кстати, с каким-то обновлением появилось 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.
У меня к нему сейчас только одна претензия — новым клиентам больше не продаётся. В общем, убила его циска. Может, там и была нехватка производительности, ещё какие-то проблемы — этого я уже никогда не узнаю.
1) на момент принятия решения я не имел данных об аппаратных балансировщиках, тянущих больше 10Гбит/с. Может, сейчас уже есть. Но ценник всё равно будет космический.
2) предположим, что сервер с Haproxy/nginx может тянуть 20Гбит. Ладно! Гуляем на все 40, как Нетфликс!!! Их всё равно надо купить много штук, поставить в стойку, как-то зарезервировать, обеспечить сетью (портами, полосой) на все эти гигабиты. И сделать это на каждом нашем узле — не только в Москве. Много. Дорого. Хреново в обслуживании (просто за счёт количества).
Да, если есть конкретные требования к server affinity, как у JDima, то да, там вариантов нет. Но если задача на прикладном уровне позволяет обойтись без привязки клиента к серверу (а я бы для всех веб-проектов рекомендовал делать без привязки), то нет смысла в «тяжелом» L7-балансировщике.
Да там же всё написано: дорого и ненужно.
Это физика. Балансировщик подключен к свитчу. Можно, конечно, и к двум свитчам подключать, но я не видел смысла это отображать.
Но некоторые элементы этого метода можно перенять и вам. Я так понимаю, у вас всё равно стоит какое-то количество L7-балансировщиков, которые обеспечивают sticky cookie. А вот между ними можно балансировать / резервировать по такой методике, как у нас. Тогда, если между балансерами есть репликация состояний, то всё отработает, как надо.