Закуска
В нашей московской сети в качестве коммутаторов аггрегации используются коммутаторы Extreme Summit X670V-48x. Для надёжности они застэкированы через модули VIM4-40G4X (это 4 порта по 40G-ethernet). Сейчас в каждом стэке по 2 шасси, но уже есть тикеты на добавление третьего.
Соответственно, все линки равномерно (т.е. пополам) распределены между двумя шасси и аггрегированы при помощи LACP. Если с одним шасси что-то случится, мы получим деградацию по полосе, но обслуживание продолжится.
Первое
Первым, во что мы уткнулись, перенося нагрузку на Extreme, была такая штука. Переключаем провайдера – физика поднялась, а LACP не собрался. Вот всё правильно, а толку – нет. Точно такие же настройки в сторону другого провайдера – там всё работает. А тут – хоть ногами пинай… Можно было бы потерять уйму времени на разборки с поддержкой, но выручили коллеги из AS8359: Андрей и Павел. Быстро рекомендовали строчку:
configure sharing 1 lacp system-priority 1
Помогло. Самое странное в этом деле – что проблема возникает не со всеми партнёрами. С нашими цисками – нет проблем, а вот если на другой стороне ASR9000 – скорее всего, будет проблема. Но не всегда. В общем, разбираться лень. Запомнили и повторяем как мантру.
Второе
Свитчи у нас 10-гигабитные, а трафика – сильно больше. Поэтому у нас много агрегрированных линков (LAG). Ну, а внутри LAG'а нужно балансировать, причём делать это так, чтобы все ноги были бы задействованы как можно равномернее, ибо упереться одной ногой очень неприятно. Так вот пока было 8 ног в одном LAG, всё было хорошо, но вдруг одна лямбда взглюкнула и упала. Запас по суммарной полосе у нас всегда есть, потеря одной десятки – не проблема. Но странным образом равномерно заполненные ноги расслоились. Некоторые поднялись выше (это ожидаемо), другие – снизились. Опа!
Первый раз разобраться не успели – починили жертву, всё нормализовалось. Но осадок остался. Следующий раз мы вернулись к этому вопросу, когда добавляли ещё две лямдбы. Смотрим – опять расслоение. Выключаем «лишние» две штуки – всё ровно. Включаем – караул! Экспериментально проверили, что расслоение происходит, если количество активных ног в LAG не является степенью 2.
Задумались, пообщались с поддержкой. А те и говорят: используйте custom. Признаться, я не поверил, ибо если верить документации, то custom с настройками по умолчанию полностью равен L3_L4. Меня убедили коллеги из MSK-IX, которые эту проблему уже вымучали.
Мы перенастроили наши LAG на использование метода custom, и теперь у нас равномерность балансировки не зависит от количества активных ног в LAG'е. Для этого, правда, пришлось удалить старые настройки и создать LAG заново, ибо алгоритм балансировки задаётся только в момент создания LAG'а. Но когда это нас пугало?
enable sharing 1:1 grouping 1:1-5, 2:1-5 algorithm address-based custom lacp
Десерт
На десерт осталось моё любимое :) Port-channel. Как на всяких цисках делается агрегация портов? Создаётся специальный порт – Port-channel, он настраивается, включается. Затем в него добавляются физические порты (конфигурационно не совсем так, но сейчас это неважно). Понадобилось добавить – добавляй! Появились лишние – удаляй. Любой. Удобно, чёрт возьми!
В XOS история другая: конфигурация LAG'а привязывается к одному из физических портов (он становится config master). Такой порт обязан быть членом LAG'а. Я могу добавлять и удалять порты сколько угодно, если только config master не трогается. А вот если нужно переместить и последний (master) порт, то всё. Единственный вариант – это удаление одного sharing и создание нового. Упсик…
Как в любой приличной конторе, мы очень любим переделывать за собой. По разным причинам, но хаускипинга у нас хватает. Соответственно, мы уже несколько раз прекрасно прикладывались к этим граблям. Не буду говорить за других членов нашей команды, но лично мне – не понравилось.
Судите сами: к порту нужно настраивать VLAN'ы (кстати, в EXTREME'альной идеологии не vlan вешаются на порт, а порты – на vlan. Соответственно, одной строкой навесить весь перечень vlan на порт нельзя), STP (господа офицеры, молчать!) и прочие безобразия. Ясен пень, что с таким объёмом настроек ошибиться – как пару байт переслать. В общем, где вы, мои любимые cisco-style portchannel'ы? Впрочем, не всё так плохо. Если config master порт уходит в down, то сам LAG остаётся жив (иначе было бы совсем х… плохо). Даже когда мы отключали то шасси, на котором находится config master, всё продолжало работать. Ну, хоть так…
От безнадёги открыл я feature-request FR4-4584728621 в прошлом году. Как вы понимаете, не реализовано. И нет уверенности, что об этом производитель вообще задумался.
Спасение утопающих – дело рук самих утопающих. Смотрел я как-то раз на циске один портчэннел:
#sh int po1 eth
Port-channel1 (Primary aggregator)
Age of the Port-channel = 174d:06h:35m:37s
Logical slot/port = 2/1 Number of ports = 4
HotStandBy port = null
Port state = Port-channel Ag-Inuse
Protocol = LACP
Port security = Disabled
И заметил прекрасную строчку Logical Slot/Port. «Ои?» сказал я. Откуда на этой нестэкируемой нерасширяемой циске второй слот?! Когда я понял, что это логический слот, у меня родился ПЛАН!
А что если использовать в качестве config master порта такой порт, который никогда не будет использован? Нет, купленных портов нам жалко, поэтому они все будут использованы. А как насчёт несуществующего порта? Такого, который находится на слоте (в стэке), которого нет. Тогда нам пофиг, какие именно порты входят в конкретный LAG. Все настройки мы будем делать на этом виртуальном слоте. Добавлять и удалять из него порты по мере потребности. Да, мы уменьшим количество шасси в одном стэке, но так ли много стэков из 8 шасси вы видели? Я толще 3 не видел.
Тогда всё получается просто. Объявляем виртуальный слот, берём как можно больше портов (мы же все LAG будем на его портах объявлять) и вперёд!
configure slot 8 module X670V-48x
enable sharing 8:1 grouping 8:1, 1:1-5, 2:1-5 algorithm address-based custom lacp
Чтобы добавить новые порты:
configure sharing 8:1 add ports 1:48, 2:48
enable ports 1:48, 2:48
Теперь можно спокойно переключать в новые порты. LACP будет всё время активен. А потом зачищаем старые порты, чтобы их под что-нить полезное использовать:
disable ports 1:1, 2:1
configure sharing 8:1 delete ports 1:1, 2:1
Беглое тестирование в лабе показало жизненность идеи. Но предупреждаю сразу: пока в бою мы это не эскплуатировали, хотя тикет на внедрение уже есть.
Я попробовал достучаться до разработчиков и сделал на форуме Extreme тему. Ответы можете прочитать сами.
Мне кажется, что сделать интерфейс командной строки, который позволил бы удобно работать с LAG, должно быть относительно просто, учитывая, что встроенные механизмы есть. Я думаю, просто все сетевики страдают над этой проблемой в гордом одиночестве, поэтому предлагаю поднять градус этой проблемы. Если вы пользователь Extreme, обратитесь в поддержку. Сошлитесь на указанный FR и требуйте долива пены после отстоя пива. Напишите в приведённую ветку форума всё, что вы думаете о производителе. Пусть это будет такой сетевой флэш-моб.
Наши предыдущие публикации:
» Реализуем безопасный VPN-протокол
» Реализуем ещё более безопасный VPN-протокол
» Лишние элементы или как мы балансируем между серверами
» Blowfish на страже ivi
» Неперсонализированные рекомендации: метод ассоциаций
» По городам и весям или как мы балансируем между узлами CDN
» I am Groot. Делаем свою аналитику на событиях
» Все на одного или как мы построили CDN
Комментарии (20)
CMHungry
26.08.2015 16:17+1Просто непривычные для вас свитчи. Кстати, стеки на них — решение удобное, но… обновление софта, например, приведет к полной перезагрузке шасси целиком.
А так — дешёвые, да. Со своими нюансами. В целом — нормальные свитчи.
ramax
26.08.2015 16:25Ну, вот был Force10 — тоже непривычный. Но там есть port-channel. И порты можно двигать.
Да, запомнить эту особенность можно. Но удобнее от этого не станет.
Насчёт обновления софта… есть у нас процедура. ;) И примерно такая же для обновления стэков цисок. Как-нить напишу. :)
Да, в целом — нормальные свитчи. В них есть логика. Но, как было сказано — дьявол в деталях. :) Есть и другие приколы. Может, позже расскажу. ;)
MetallicAt
26.08.2015 16:49А config-master траффик на себя не принимает? Как-бы не получилось, что кусок траффика отправляется в рельсу…
ramax
26.08.2015 16:56Не, там нормально. Есть ещё понятие current master. Если config master поднят, то он же и current master. Если config master упал, то кто-то другой становится current master. Работает даже если выключить слот, на котором config master. Проверено неоднократно. :)
После восстановления current master возвращается (начиная с какой-то версии XOS) на config master.
Если б работало как-то иначе, это был бы не свитч, а кусок чего-то странного и неаппетитного.MetallicAt
26.08.2015 17:29Того, что вы тут уже написали, в принципе, достаточно чтоб считать этот свитч куском чего-то странного.
Не очень понятно зачем надо было придумывать велосипед с квадратными колесами.ramax
26.08.2015 17:41В целом — все производители одинаковые. ;) У меня есть много баек про всех.
Extreme — вменяем. Его можно осознать. Но да, в части LAG приходится придумывать костыли (мне тут в личной переписке ещё рассказали) из-за позиции производителя. На мой вкус — неправильной позиции.
eurypterid
26.08.2015 16:54> Для надёжности они застэкированы через модули
сомнительное в плане надежности решение — иметь на двух железках общий контрол-плейн. А софт обновлять? А внезапные креши?
Что касается балансировки в LAG, вероятно в режиме custom хешируется 4 бита вместо 3-х. По тем же самым полям.
Night_Snake
26.08.2015 18:32Кстати а MLAG вы используете? Вообще так-то да, стэки — не самое надежное решение.
ramax
26.08.2015 18:41Нет, MLAG не используем. Тому есть причины:
1) объём настройки резко возврастает (каждый LAG надо два раза настраивать)
2) больше двух шасси в MLAG не включишь (а мы тут добавляем в стэк третьего)
3) MLAG — как мультикаст: есть у многих. Правильно не работает ни у кого (ладно, MSK-IX смог запустить, но у них узкое применение).
4) я не вижу проблем с надёжностью стэка. Он примерно такой же надёжный, как два супервизора в «холодильнике». А может, и надёжнее (есть тут у нас одно шасси «холодильника» с дефектом бэкплейна в одном слоте. И вот уже 2 года мы ничего с этим поделать не можем).
Единственное, чем MLAG может быть лучше стэка — это отсутствием ограничения полосы в стэке.
Подумывали использовать MLAG в сторону кольца (как раз по заветам MSK-IX), но там другая проблема: это должно быть симметричное кольцо из 4 вершин (математики, отвяньте!). У нас такую топологию собрать не получается.Night_Snake
26.08.2015 18:541) а какже скриптование? ;) я с самого начала для MC-LAG на джунипере сделал скриптик, который готовит конфигурацию. Чтобы не путаться
2) можно делать MLAG между шасси (стеком наращиваем емкость портов, MLAG'ом обеспечиваем отказоустойчивость.
3) я не работал именно с MLAG, у меня в наличии только Juniper и их MC-LAG — работает вполне себе. А что там неправильно настроить-то можно?
4) вместо двух супов в холодильнике мы пользуем VSS, и я очень-очень хочу от него уйти, потому что он, вроде бы, дает гарантию того самого failover, с другой стороны — судя по опыту это нифига не так. Но со стороны [начальства] похоже. вообще стековая конфигурация удобна только в настройке. Закладываться на нее, как на fail-tolerance решение это наивно.
Насчет MLAG и кольца вообще не очень понял — может, поделитесь презентацией? Для колец у extreme есть EAPS (простихосспади), и у кого-то оно «даже работает», но нафиг-нафиг.eurypterid
26.08.2015 19:25+1MC-LAG на джуниперах (MX'ах) — имхо ничем не лучше стека, хотя за последние пару лет стали стабильней.
Те же самые проблемы общего (пусть и частично) контролплейна и синхронизации ARP'ов, ipv6 нейборов, запрет на использование *STP и т.д.Night_Snake
26.08.2015 21:09Мы пользуем на QFX уже год как (даже полтора) — к mc-lag ни одного нарекания. STP (RSTP) использовать можно (даже нужно), насчет l3 не подскажу — не юзал. При этом бонус в том, что control-plane у каждого остается свой.
ramax
26.08.2015 21:051) ну да, можно что-то наскриптовать. Но если можно этого не делать, то зачем?
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 кольцо перейти — тогда потребность отпадёт как таковая.Night_Snake
26.08.2015 21:161) как раз для избежания п.3 и скриптовать ;) ну хотя тут у каждого свои условия: количество новых интерфейсов в день/неделю/месяц, колиество человек, которые занимаются настройкой, парк железа и т.д.
2) Да, MLAG между стеками. Зачем — я уже пояснил выше. И нет, это не одно и то же… Вместо одного control plane у вас два. Со всеми плюсами минусами. Как по мне — вполне разумное решение.
3) А у вас был опыт практического использования? У нас по MC-LAG включены хранилки и виртуальные фермы. Как-нибудь распишу наш кейс в статье. И нормально работает.
4) Да, это тот же стек. И именно поэтому я хочу от него уйти, т.к. у него на двоих один cp.
phantasm1c
27.08.2015 07:54+2Самого главного в настройке LAG-а не указали — настройки хэширования при custom-алгоритме:
configure sharing address-based custom hash-algorithm crc-16
Это сделает балансировку по нечётному количеству портов равномерной. В противном в случае на трёхпортовом LAG-е, к примеру, один порт будет загружен на 50% сильнее чем остальные.
И ещё важный ньюанс при использовании экстримов:
Если Вы столкнулись с багом и решили обновить прошивку на свитче — не обновляйте на новую версию. Новая версия может и решит ваш баг, но привнесёт новые. Нужно обновить на ту же версию, но с последним патчем: например была версия 15.3.1.4, стала 15.3.1.4-patch44. Патчи — это багфиксы, без изменения функционала.ramax
27.08.2015 09:44До crc16 не дошли — проверено, что достаточно по умолчанию. На нечетность первым делом проверяли. Но тут возможна магия версии XOS.
Да, поддержка рекомендовала такую штуку. Кстати, с каким-то обновлением появилось crc32 — даже в лабе не включали.
Статья была про LACP, а не «про все гадости, которые есть». ;) Поэтому про софт и т.п. не писал специально.phantasm1c
27.08.2015 14:17Ну, возможно стоит написать и про остальные гадости в последующих постах.
Многие админы довольно крупных операторов связи, использующих Extreme, не знают про особенность с версией XOS (что баги фиксят патчи, а не новая версия прошивки). После того как узнали, открыли для себя что экстримы не такие уж и глючные какими их рисуют.
«с каким-то обновлением появилось crc32» — ну оно наверняка появилось только на некоторых моделях свитчей. Т.к. этот алгоритм должен уметь ASIC, аппаратная начинка свитча.
Night_Snake
Касался экстримов только краешком, но за жизненные описания спасибо :) А OSPF у вас на них крутится? Узнаете много нового, я думаю ;)
ramax
Пока что нет. Но подумываем-прикидываем. Читаем релиз ноутсы. :) По нашему долгосрочному плану — будем запускать.