Дьявол кроется в деталях – я всегда вспоминаю об этом, когда разбираюсь с чем-то новым. Новый софт или новая железка могут быть какими угодно крутыми и технически, и экономически, но обязательно найдётся такая мелочь, которая вроде бы непринципиальна, но крови пьёт безумно много. Вот про несколько таких ненасытных мелочей в сетевом оборудовании Extreme Networks я и хочу рассказать под катом.
В нашей московской сети в качестве коммутаторов аггрегации используются коммутаторы Extreme Summit X670V-48x. Для надёжности они застэкированы через модули VIM4-40G4X (это 4 порта по 40G-ethernet). Сейчас в каждом стэке по 2 шасси, но уже есть тикеты на добавление третьего.
Соответственно, все линки равномерно (т.е. пополам) распределены между двумя шасси и аггрегированы при помощи LACP. Если с одним шасси что-то случится, мы получим деградацию по полосе, но обслуживание продолжится.
Первым, во что мы уткнулись, перенося нагрузку на Extreme, была такая штука. Переключаем провайдера – физика поднялась, а LACP не собрался. Вот всё правильно, а толку – нет. Точно такие же настройки в сторону другого провайдера – там всё работает. А тут – хоть ногами пинай… Можно было бы потерять уйму времени на разборки с поддержкой, но выручили коллеги из AS8359: Андрей и Павел. Быстро рекомендовали строчку:
Помогло. Самое странное в этом деле – что проблема возникает не со всеми партнёрами. С нашими цисками – нет проблем, а вот если на другой стороне ASR9000 – скорее всего, будет проблема. Но не всегда. В общем, разбираться лень. Запомнили и повторяем как мантру.
Свитчи у нас 10-гигабитные, а трафика – сильно больше. Поэтому у нас много агрегрированных линков (LAG). Ну, а внутри LAG'а нужно балансировать, причём делать это так, чтобы все ноги были бы задействованы как можно равномернее, ибо упереться одной ногой очень неприятно. Так вот пока было 8 ног в одном LAG, всё было хорошо, но вдруг одна лямбда взглюкнула и упала. Запас по суммарной полосе у нас всегда есть, потеря одной десятки – не проблема. Но странным образом равномерно заполненные ноги расслоились. Некоторые поднялись выше (это ожидаемо), другие – снизились. Опа!
Первый раз разобраться не успели – починили жертву, всё нормализовалось. Но осадок остался. Следующий раз мы вернулись к этому вопросу, когда добавляли ещё две лямдбы. Смотрим – опять расслоение. Выключаем «лишние» две штуки – всё ровно. Включаем – караул! Экспериментально проверили, что расслоение происходит, если количество активных ног в LAG не является степенью 2.
Задумались, пообщались с поддержкой. А те и говорят: используйте custom. Признаться, я не поверил, ибо если верить документации, то custom с настройками по умолчанию полностью равен L3_L4. Меня убедили коллеги из MSK-IX, которые эту проблему уже вымучали.
Мы перенастроили наши LAG на использование метода custom, и теперь у нас равномерность балансировки не зависит от количества активных ног в LAG'е. Для этого, правда, пришлось удалить старые настройки и создать LAG заново, ибо алгоритм балансировки задаётся только в момент создания LAG'а. Но когда это нас пугало?
На десерт осталось моё любимое :) 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 в прошлом году. Как вы понимаете, не реализовано. И нет уверенности, что об этом производитель вообще задумался.
Спасение утопающих – дело рук самих утопающих. Смотрел я как-то раз на циске один портчэннел:
И заметил прекрасную строчку Logical Slot/Port. «Ой» сказал я. Откуда на этой нестэкируемой нерасширяемой циске второй слот?! Когда я понял, что это логический слот, у меня родился ПЛАН!
А что если использовать в качестве config master порта такой порт, который никогда не будет использован? Нет, купленных портов нам жалко, поэтому они все будут использованы. А как насчёт несуществующего порта? Такого, который находится на слоте (в стэке), которого нет. Тогда нам пофиг, какие именно порты входят в конкретный LAG. Все настройки мы будем делать на этом виртуальном слоте. Добавлять и удалять из него порты по мере потребности. Да, мы уменьшим количество шасси в одном стэке, но так ли много стэков из 8 шасси вы видели? Я толще 3 не видел.
Тогда всё получается просто. Объявляем виртуальный слот, берём как можно больше портов (мы же все LAG будем на его портах объявлять) и вперёд!
Чтобы добавить новые порты:
Теперь можно спокойно переключать в новые порты. LACP будет всё время активен. А потом зачищаем старые порты, чтобы их под что-нить полезное использовать:
Беглое тестирование в лабе показало жизненность идеи. Но предупреждаю сразу: пока в бою мы это не эскплуатировали, хотя тикет на внедрение уже есть.
Я попробовал достучаться до разработчиков и сделал на форуме Extreme тему. Ответы можете прочитать сами.
Мне кажется, что сделать интерфейс командной строки, который позволил бы удобно работать с LAG, должно быть относительно просто, учитывая, что встроенные механизмы есть. Я думаю, просто все сетевики страдают над этой проблемой в гордом одиночестве, поэтому предлагаю поднять градус этой проблемы. Если вы пользователь Extreme, обратитесь в поддержку. Сошлитесь на указанный FR и требуйте долива пены после отстоя пива. Напишите в приведённую ветку форума всё, что вы думаете о производителе. Пусть это будет такой сетевой флэш-моб.
Наши предыдущие публикации:
» Реализуем безопасный VPN-протокол
» Реализуем ещё более безопасный VPN-протокол
» Лишние элементы или как мы балансируем между серверами
» Blowfish на страже ivi
» Неперсонализированные рекомендации: метод ассоциаций
» По городам и весям или как мы балансируем между узлами CDN
» I am Groot. Делаем свою аналитику на событиях
» Все на одного или как мы построили CDN
Закуска
В нашей московской сети в качестве коммутаторов аггрегации используются коммутаторы 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
